기존 인프라 관리를 코드로 하던 시대를 넘어, 인프라를 ‘정말 소프트웨어처럼’ 다루는 최신 패러다임이 뜨고 있습니다. IaS가 무엇이며 왜 주목받는지 궁금하지 않으신가요?
지금 Software Infra 업계에서 말하는 Infrastructure as Software(IaS)는 단순히 “인프라를 코드로 적는다”를 넘어, 인프라를 하나의 소프트웨어 제품처럼 설계·개발·테스트·배포·버전관리하는 방식으로 빠르게 확장되고 있습니다.
Software Infra에서 말하는 IaS의 정의: “인프라를 일반 프로그래밍 언어로 만든다”
IaS는 클라우드 인프라를 TypeScript, Python, Go, Java, C# 같은 일반 목적 언어로 정의하고, 애플리케이션 개발에 쓰던 소프트웨어 공학 도구를 그대로 적용하는 접근입니다. 핵심은 다음 한 줄로 요약됩니다.
- 인프라를 DSL(YAML/HCL/JSON)이 아니라 일반 언어의 타입·함수·클래스·패키지로 모델링한다.
- 그 위에 테스트, 코드 리뷰, CI/CD, 패키지 배포, 버전 전략까지 소프트웨어 방식으로 얹는다.
즉, IaC가 “인프라도 코드로 관리하자”였다면, IaS는 “인프라를 애플리케이션처럼 개발하고 운영하자”에 가깝습니다.
Software Infra 트렌드로 IaS가 뜨는 이유: IaC의 ‘표현력 한계’가 커졌기 때문
IaC는 인프라 자동화의 표준이 되었지만, 규모가 커질수록 흔히 이런 벽을 만납니다.
- 추상화가 빈약함: 템플릿/모듈 수준을 넘어 “조직 표준 인프라 패턴”을 우아하게 캡슐화하기 어렵습니다.
- 테스트가 불편함: 유닛 테스트/스냅샷 테스트 같은 소프트웨어식 검증을 붙이기 까다롭습니다.
- 복잡한 로직 표현이 제한적임: 조건·반복·분기·의존성 관리가 늘어나면, 선언형 템플릿이 급격히 난해해집니다.
반면 IaS는 일반 언어의 장점을 그대로 가져옵니다.
- 조건/반복/함수/클래스 등 풀 언어 기능으로 복잡한 토폴로지와 규칙을 자연스럽게 표현
- 타입 시스템으로 잘못된 설정을 더 이르게 감지(IDE 자동완성, 정적 분석 등)
- 표준 테스트 프레임워크로 인프라 변경을 “검증 가능한 소프트웨어 변경”으로 다룸
- 패키지 관리로 공통 인프라 컴포넌트를 배포·버전업하며 재사용
결국 IaS는 Software Infra 환경에서 점점 복잡해지는 멀티 클라우드, 쿠버네티스, 보안/정책 요구사항을 소프트웨어 엔지니어링 방식으로 흡수하기 위한 진화로 받아들여지고 있습니다.
Software Infra 실무 관점 핵심: 인프라를 “객체”로 다루고, 엔지니어링 툴체인을 적용한다
IaS에서는 VPC, 서브넷, 클러스터, 로드밸런서 같은 리소스가 단순 설정 묶음이 아니라, 타입이 있는 객체가 됩니다. 그 결과로 생기는 변화는 명확합니다.
리소스가 ‘설정’이 아니라 ‘모델’이 됨
공통 패턴(예: 표준 네트워크 + 관측성 + 보안 기본값)을 함수/클래스로 캡슐화해 재사용할 수 있습니다.테스트 가능한 인프라로 전환
“배포해 보고 문제 없으면 OK”가 아니라, 변경을 PR로 올리고 테스트로 위험을 줄인 뒤 배포하는 흐름을 만들 수 있습니다.CI/CD에 자연스럽게 합류
애플리케이션과 동일한 파이프라인에서 인프라 변경을 함께 검증하고 반영해, 배포 품질과 속도를 동시에 끌어올립니다.
정리하면, IaS는 인프라를 코드로 적는 수준을 넘어 인프라를 ‘제품화’하려는 팀(플랫폼 엔지니어링 조직 포함)에게 특히 강력한 선택지가 됩니다.
Software Infra에서 IaC의 한계를 넘다: 복잡해진 클라우드를 소프트웨어처럼 다루는 이유
왜 흔한 IaC(인프라스트럭처 코드)만으로는 복잡한 멀티클라우드 AI 인프라를 감당하지 못할까요? 결론부터 말하면, 오늘날의 인프라는 “리소스 나열”이 아니라 “행동하는 시스템”에 가깝기 때문입니다. GPU 클러스터, 쿠버네티스, 멀티 리전/멀티 클라우드, 보안·컴플라이언스 정책까지 한데 얽힌 환경에서는 YAML/HCL 중심 IaC만으로 추상화·검증·테스트·재사용을 끝까지 밀어붙이기 어렵습니다. 그래서 Software Infra 영역에서 IaS(Infrastructure as Software)가 “다음 단계”로 부상합니다.
IaC가 커질수록 드러나는 구조적 한계
IaC는 “인프라를 코드로 남겨 재현 가능하게 만든다”는 점에서 혁신적이었지만, 대규모 환경으로 가면 다음 벽에 부딪힙니다.
- 표현력의 벽:
조건/반복/분기 같은 로직이 늘어날수록 DSL은 읽기 어려운 템플릿 조합이 됩니다. 멀티 리전에서 리소스 수가 폭증하거나, 서비스별 예외 규칙이 쌓일수록 “정적 선언”만으로는 한계가 분명해집니다. - 추상화의 벽:
모듈이 있어도 대개 “파라미터 뭉치” 수준에 머무르기 쉽습니다. 공통 패턴(예: 표준 VPC+EKS+Observability+보안 가드레일)을 진짜 제품처럼 감싸려면, 함수/클래스/타입 기반의 강한 추상화가 필요합니다. - 테스트의 벽:
변경 전후의 안전성을 IaC만으로 충분히 검증하기 어렵습니다. “배포해 보고 깨지면 롤백”은 AI 워크로드처럼 비용이 큰 인프라에서는 치명적입니다. - 조직 확장의 벽:
플랫폼 팀과 서비스 팀이 협업할수록, 인프라가 단순 스크립트가 아니라 내부 플랫폼(제품)이 됩니다. 이때 필요한 것은 템플릿 파일이 아니라 SDK/라이브러리 형태의 배포물입니다.
멀티클라우드·AI 인프라가 IaC를 더 빨리 무너뜨리는 이유
AI 인프라는 일반 웹 서비스 인프라보다 “상태 공간”이 큽니다. 즉, 고려해야 할 조합이 폭발합니다.
- GPU 리소스의 스케줄링/가용성: 노드 타입, GPU 세대, 스팟/온디맨드, 리전별 쿼터 등 변수가 많습니다.
- 고성능 네트워크와 스토리지: 성능 요구사항에 따라 CNI, 네트워크 정책, 스토리지 클래스, 캐시/파이프라인이 함께 설계되어야 합니다.
- 멀티클러스터 운영: 학습/서빙/배치가 다른 클러스터에서 돌고, 각 클러스터의 정책과 관측(로그·메트릭·트레이싱) 구성이 달라집니다.
- 컴플라이언스·데이터 레지던시: 리전 제한, 암호화, 퍼블릭 노출 금지, 태그 강제 같은 규칙은 예외 처리까지 포함하면 로직이 됩니다.
이 모든 것을 “리소스 선언의 집합”으로만 관리하면, 결국 사람 머리로 검증해야 하는 구간이 늘어나고, 변경 속도는 느려지며, 장애 확률은 올라갑니다.
IaS가 만드는 ‘애플리케이션 수준의 인프라 엔지니어링’
IaS의 핵심은 인프라를 소프트웨어 객체로 모델링하고, 소프트웨어 공학 툴체인을 그대로 적용하는 것입니다. 이 관점이 중요한 이유는, 인프라가 더 이상 “설정 파일”이 아니라 제품처럼 진화해야 하는 코드베이스이기 때문입니다.
- 타입 기반 설계(Real Types):
VPC, 클러스터, 버킷 같은 리소스가 타입을 갖고 IDE 자동완성/정적 검증을 받습니다. 잘못된 속성 조합이나 필수 값 누락을 더 빨리 잡습니다. - 진짜 추상화(Real Abstractions):
“회사 표준 웹서비스 스택”을 함수/클래스로 캡슐화해WebServiceStack(props)처럼 호출하게 만들 수 있습니다. 이때 표준 네트워크, 보안, 로깅, 모니터링, 비용 태그까지 한 번에 포함됩니다. - 테스트 가능한 인프라(Real Tests):
유닛 테스트로 “이 설정이면 퍼블릭 서브넷이 생성되면 안 된다”, “GPU 노드는 특정 보안 그룹을 반드시 가져야 한다” 같은 규칙을 검증할 수 있습니다. 통합 테스트로는 스테이징에 실제 배포해 최소 기능을 확인하는 흐름도 자연스럽게 붙습니다. - 패키지/버전 관리(Real Package Management):
플랫폼 팀이 인프라 컴포넌트를 라이브러리로 배포하고, 서비스 팀은 버전 업그레이드만으로 보안 정책 강화나 비용 최적화를 받아갈 수 있습니다. - CI/CD에 자연스럽게 탑승:
PR → 테스트/정책 검사 → 승인 → 배포의 파이프라인이 앱 개발과 같은 수준으로 정교해집니다.
결국 Software Infra의 관점에서 IaS는 “IaC를 버리는 것”이 아니라, IaC의 목표(자동화·재현성)를 유지하면서도 복잡한 현실을 다루기 위해 소프트웨어 공학을 끝까지 끌어오는 방식입니다.
IaS 없이 어려운 것들: 현실적인 체크리스트
아래 항목이 늘어날수록 IaS의 효용은 급격히 커집니다.
- 서비스/팀 수가 늘며 표준 스택을 강제하고 싶다
- 멀티 리전/멀티 클라우드로 조건부 토폴로지가 많다
- 보안/컴플라이언스 요구가 강해 정책을 코드로 검증해야 한다
- AI/GPU 워크로드로 인해 실수 한 번의 비용이 크다
- “플랫폼을 제품처럼” 제공하기 위해 SDK/라이브러리가 필요하다
이 지점에서 질문은 “IaC로도 되지 않나?”가 아니라, “인프라를 소프트웨어처럼 다루지 않으면, 이 복잡도를 무엇으로 감당할 것인가?”로 바뀝니다. IaS는 바로 그 질문에 대한 가장 실용적인 답입니다.
Software Infra 관점에서 본 IaS: 기존 IaC를 뛰어넘는 기술적 차이와 장점 분석
IaC와 IaS, 같은 “코드 기반”이라도 무엇이 어떻게 다를까요? 핵심은 표현 수단이 DSL(YAML/HCL)에서 ‘일반 목적 프로그래밍 언어’로 이동하면서, 인프라가 더 이상 설정 파일이 아니라 테스트·추상화·패키징이 가능한 ‘진짜 소프트웨어’가 된다는 점입니다. Software Infra 트렌드에서 IaS가 “IaC 이후의 다음 단계”로 자주 언급되는 이유도 여기에 있습니다.
Software Infra에서 IaC가 부딪히는 지점: 규모가 커질수록 ‘설정 언어’의 한계
IaC는 인프라를 선언적으로 정의하고 버전 관리·리뷰·자동화를 가능하게 만들었습니다. 하지만 대규모 조직이나 멀티 환경(멀티 리전/멀티 클라우드/수십~수백 서비스)으로 갈수록 다음 문제가 자주 나타납니다.
- 추상화의 한계: 모듈/템플릿으로는 공통 패턴을 재사용할 수 있지만, “정교한 옵션 조합”이나 “환경별 예외 처리”가 늘면 템플릿이 비대해집니다.
- 복잡한 로직의 표현력 부족: 조건/반복/검증 로직을 억지로 끼워 넣으면 가독성이 급락하고, 도구별로 지원 방식도 제각각입니다.
- 테스트가 어색함: 코드 품질을 담보하는 표준적인 유닛 테스트·스냅샷 테스트를 적용하기 어렵거나, 결국 수동 검증/리허설에 의존하게 됩니다.
- 패키징/버전 전략이 빈약: “조직 표준 VPC”, “표준 K8s 클러스터”, “보안 기본값” 같은 자산을 제품처럼 버전업하고 배포하기가 어렵습니다.
IaS는 이 병목을 “인프라를 애플리케이션 개발 방식으로 다룬다”는 접근으로 정면 돌파합니다.
Software Infra의 핵심 전환: IaS는 인프라를 ‘코드’가 아니라 ‘소프트웨어’로 취급한다
IaS의 차별점은 단순히 TypeScript/Python/Go 같은 언어로 작성한다는 것에 그치지 않습니다. 소프트웨어 공학 툴체인 전체를 인프라에 적용해, 인프라를 “프로그램”으로 만들고 “제품”으로 운영합니다.
- 타입 시스템(Real Types): 리소스 속성과 입력값이 타입으로 모델링되어 IDE 자동완성, 정적 분석, 컴파일 단계 오류 탐지가 가능해집니다.
- 추상화(Real Abstractions): 함수/클래스/인터페이스로 패턴을 캡슐화해, 조직 표준을 “라이브러리”로 배포할 수 있습니다.
- 테스트(Real Tests): Jest/pytest/go test 같은 표준 프레임워크로 인프라 구성 로직을 유닛 테스트하고, 변경 영향도를 스냅샷 테스트로 검증할 수 있습니다.
- 패키지 관리(Real Package Management): npm/pip/Maven 등으로 인프라 컴포넌트를 패키지화하고, 버전 정책(semver)과 의존성 관리를 적용할 수 있습니다.
- CI/CD 통합(Real CI/CD): 애플리케이션 파이프라인에 인프라 변경 검증(테스트·정책 체크)을 자연스럽게 끼워 넣어 “배포 가능한 인프라 소프트웨어”로 운영합니다.
결과적으로 IaS는 인프라를 ‘선언문 모음’이 아니라 ‘실행 가능한 설계(프로그램)’로 끌어올립니다.
Software Infra 기술 비교: IaC는 “정의”, IaS는 “설계 + 구현 + 검증”까지 포함한다
IaC와 IaS의 기술적 차이는 운영 단계에서 더 크게 드러납니다.
Software Infra에서의 표현력: 조건·반복·조합이 ‘언어 기능’이 된다
- IaC: 제한된 조건/반복 기능 또는 템플릿 엔진에 의존 → 복잡한 분기(예: 리전/등급/컴플라이언스별 토폴로지)가 늘수록 난해해짐
- IaS: 일반 언어의 제어 흐름을 그대로 사용 → 예를 들어
- 환경별 리소스 구성(개발/스테이징/운영)
- 테넌트별 격리 전략
- 멀티 리전 DR 토폴로지 를 명확한 코드 구조로 모델링 가능
Software Infra에서의 재사용: 모듈이 아니라 “플랫폼 SDK”가 된다
IaS의 강점은 공통 패턴을 컴포넌트(클래스/함수)로 제공할 수 있다는 점입니다.
- “표준 웹서비스 스택”을
WebServiceStack(props)같은 형태로 제공 - 내부적으로 VPC/서브넷/로드밸런서/쿠버네티스/관측성/보안 기본값을 묶어 배포
- 서비스 팀은 짧은 코드로 표준 인프라를 소비하고, 플랫폼 팀은 이 컴포넌트를 버전업하며 개선을 전파
즉, IaS는 Software Infra를 ‘플랫폼 제품’처럼 유통하게 만들어 조직 전체의 일관성을 높입니다.
Software Infra에서의 품질 관리: 테스트 가능한 인프라가 된다
IaS는 인프라 코드를 테스트 가능한 형태로 만들기 쉽습니다.
- 유닛 테스트: “특정 태그/암호화 옵션/네트워크 정책이 항상 포함되는가?”
- 스냅샷/골든 파일 테스트: “이 PR에서 생성되는 리소스 변화가 의도된 범위인가?”
- 정책 테스트: “퍼블릭 노출 금지, 특정 리전 제한, 필수 로깅 활성화” 같은 규칙을 코드로 검증
이 과정이 CI에서 자동화되면, 인프라 변경은 더 이상 “적용해 보고 확인”이 아니라 “테스트로 증명하고 머지”하는 방식으로 바뀝니다.
Software Infra 관점의 결론: IaS가 제공하는 ‘장점’은 기술이 아니라 운영 모델의 변화다
IaS가 IaC를 뛰어넘는 지점은 결국 운영 모델입니다.
- 인프라가 리뷰 가능한 산출물을 넘어, 테스트·버전·배포 가능한 소프트웨어가 된다
- 플랫폼 팀이 인프라를 SDK/라이브러리로 제품화해 서비스 팀에 제공할 수 있다
- 타입/테스트/패키징/CI를 통해 변경 리스크를 줄이고, 대규모 환경에서 표준화와 확장성을 동시에 확보한다
정리하면, IaC가 “인프라를 코드로 관리”하는 시대를 열었다면, IaS는 Software Infra를 애플리케이션 개발의 규율로 운영하게 만드는 다음 단계입니다.
Software Infra를 위한 IaS의 내부 구조와 실전 활용법: 객체 모델링부터 CI/CD까지
IaS에서는 인프라 리소스를 코드 속 ‘객체’로 다룹니다. 이 한 가지 전환만으로도 타입 안정성, 재사용성, 테스트 가능성이 급격히 올라가고, 결국 개발부터 배포까지의 전 과정을 “소프트웨어 개발 프로세스”로 재구성할 수 있습니다. 여기서는 IaS가 내부적으로 어떤 구조로 돌아가며, Software Infra 현장에서 바로 써먹을 수 있는 아키텍처 패턴까지 연결해 보겠습니다.
Software Infra 관점의 IaS 내부 구조: “리소스 객체 + 그래프 + 상태”로 이해하기
IaS 툴(Pulumi, CDK 계열, cdktf 등)의 구현 방식은 조금씩 달라도, 실전에서 중요한 핵심 구조는 크게 비슷합니다.
1) 리소스를 “타입이 있는 객체”로 모델링 (Resource Object Model)
IaS에서 VPC, 서브넷, 로드밸런서, 쿠버네티스 클러스터, IAM 정책 같은 것들은 보통 다음 형태로 표현됩니다.
- 클래스/타입:
Vpc,Subnet,Cluster처럼 명확한 타입을 가짐 - 속성(프로퍼티): CIDR, AZ, 태그, 암호화 옵션 등 필드가 정형화됨
- 참조(의존성):
subnet.vpcId처럼 다른 리소스의 출력값을 입력으로 사용
이때 얻는 실질적인 이점은 단순합니다.
- IDE 자동완성 + 타입 체크로 잘못된 속성/파라미터를 작성 단계에서 차단
- 공통 인프라 패턴을 함수/클래스로 캡슐화해 조직 표준을 코드로 강제
- 복잡한 조건(환경별, 리전별, 기능 플래그별)을 일반 언어의 제어문으로 자연스럽게 표현
2) 코드 실행 결과로 “리소스 그래프(Dependency Graph)”를 만든다
IaS는 선언 파일을 그대로 적용하는 방식과 달리, 프로그램을 실행해 다음을 산출합니다.
- 어떤 리소스를 만들지
- 리소스 간 의존성이 무엇인지
- 어떤 값이 다른 리소스의 입력으로 흘러가는지
즉, 인프라가 정적인 템플릿이 아니라 실행 결과로 생성되는 그래프가 됩니다. 이 구조 덕분에 다음 같은 설계가 쉬워집니다.
- 동일 패턴을 여러 번 찍어내는 멀티 리전/멀티 스택 구성
- 특정 조건에서만 생성되는 리소스(예: 프로덕션에서만 WAF, DR 리전에서만 복제)
- “플랫폼 팀이 만든 컴포넌트”를 서비스 팀이 조립하는 구조
3) 상태(State)와 미리보기(Preview)로 변경을 통제한다
대부분의 IaS 도구는 “현재 배포된 현실”과 “코드가 원하는 목표”를 비교하기 위해 상태를 유지합니다.
- Preview/Plan: 어떤 리소스가 생성/수정/삭제될지 사전에 계산
- Diff: 변경 폭을 정량화해 리뷰 가능하게 만듦
- State 관리: 원격 백엔드(S3, DB, SaaS 등)를 통해 팀 협업 시 충돌을 방지
Software Infra에서 중요한 포인트는, 이 단계가 단순 운영 편의가 아니라 배포 안정성의 핵심 통제 지점이라는 것입니다. “삭제 예정 리소스가 무엇인지”, “교체(replace)가 발생하는지” 같은 위험 신호를 PR 단계에서 잡아낼 수 있습니다.
Software Infra 실전 모델링: 컴포넌트(재사용 단위)를 먼저 설계하라
IaS를 도입할 때 가장 흔한 실패는 “그냥 Terraform 하던 걸 TypeScript/Python으로 옮김”입니다. IaS의 장점은 언어가 아니라 추상화 단위(컴포넌트)에서 터집니다.
패턴 A) 얇은 래퍼가 아닌 “의도(intent) 중심 컴포넌트” 만들기
- 나쁜 예:
createVpc(),createSubnet()처럼 리소스를 1:1로 감싼 함수만 잔뜩 늘어남 - 좋은 예:
WebServiceStack,DataPlatformNetwork,SecureK8sCluster처럼 팀이 원하는 표준 아키텍처를 한 덩어리로 제공
의도 중심 컴포넌트가 되면, 서비스 팀의 코드는 보통 이렇게 바뀝니다.
- “어떤 리소스를 어떤 옵션으로 만들지” → “우리 서비스는 어떤 종류의 플랫폼 위에서 돌아가는지”
- 설정 파일 수십 줄 → 한두 개의 명확한 파라미터(예:
public: false,compliance: "pci")
패턴 B) 입력/출력을 계약(Contract)으로 고정해 버전업을 가능하게
컴포넌트는 결국 “내부 구현이 바뀌어도 외부 사용 방식이 유지되는” 것이 핵심입니다.
- 입력 계약: 서비스 팀이 반드시 제공해야 하는 값(도메인, 환경, 스케일 등)
- 출력 계약: 다른 스택이 안전하게 참조할 값(엔드포인트, IAM Role ARN 등)
- 버전 정책:
v1은 유지보수,v2에서만 파괴적 변경 허용
이렇게 해야 플랫폼 팀이 보안/관측/비용 최적화를 컴포넌트 업데이트만으로 전파할 수 있습니다.
Software Infra 테스트 전략: “유닛 → 스냅샷 → 통합” 3단으로 구축
IaS의 큰 차별점은 인프라가 테스트 가능한 소프트웨어 산출물이 된다는 점입니다. 추천하는 테스트 레이어는 아래 3단입니다.
1) 유닛 테스트: 정책과 조합 로직을 검증
- “프로덕션이면 퍼블릭 IP 금지”
- “모든 스토리지는 암호화 옵션 강제”
- “태그가 반드시 들어가야 함(비용/소유자/환경)”
- “특정 리전에서는 특정 인스턴스 타입 금지”
이런 규칙은 선언형 템플릿에서도 가능은 하지만, IaS에서는 일반 언어 조건문으로 훨씬 정확하고 예외 처리도 깔끔합니다.
2) 스냅샷/구조 테스트: 생성된 리소스 그래프가 기대와 같은지 확인
- 생성 리소스 타입/개수 검증
- 특정 속성(예:
publicAccessBlock=true) 존재 여부 검증 - 네이밍 규칙 및 태그 규칙 검증
핵심은 “클라우드에 실제 배포하지 않고도” PR에서 구조적 퇴행(regression)을 막는 것입니다.
3) 통합 테스트: 샌드박스 환경에 실제 배포 후 동작 확인
- 배포 후 엔드포인트 헬스체크
- IAM 권한이 과도하지 않은지 최소 권한 검증
- 네트워크 경로/보안그룹 동작 확인
- 쿠버네티스 애드온/관측 스택 정상 동작 확인
통합 테스트는 비용이 들기 때문에, 모든 PR에 강제하기보다 야간/릴리즈 후보에만 돌리는 방식이 운영적으로 안정적입니다.
Software Infra CI/CD 운영 패턴: PR에서 “미리보기 + 정책 + 승인”을 자동화
IaS를 “진짜 소프트웨어”로 운영하려면 CI/CD에서 다음 4가지를 고정 루틴으로 만드는 것이 좋습니다.
- PR 생성 시 Preview 실행
- 변경 요약(생성/수정/삭제)을 PR 코멘트로 남김
- 정책 검사(Policy as Code) 통과
- 퍼블릭 노출, 암호화, 태그, 리전 제한, 데이터 레지던시 등
- 테스트 실행(유닛/스냅샷 중심)
- 빠르게 실패시키고, 리뷰 비용을 줄임
- 승인 후 Apply/Deploy
- 브랜치 머지 또는 수동 승인 게이트로 운영 안정성 확보
추가로, 규모가 커지면 “한 저장소에서 모든 것을 배포”하기보다 스택/환경 단위로 배포 권한과 파이프라인을 분리하는 것이 안전합니다(예: dev는 자동, prod는 승인이 필수).
Software Infra 조직 적용 팁: 플랫폼 팀과 서비스 팀의 경계를 코드로 정의
IaS를 도입할 때 기술보다 더 큰 난관은 책임 경계입니다. 실전에서는 아래처럼 나누는 방식이 효과적입니다.
- 플랫폼 팀
- 표준 컴포넌트(네트워크, 쿠버네티스, 관측, 보안 베이스라인) 제공
- 정책/가드레일을 코드로 강제
- 버전업과 마이그레이션 가이드 제공
- 서비스 팀
- 플랫폼 컴포넌트 조합 + 서비스별 설정만 관리
- 애플리케이션 릴리즈와 인프라 변경을 같은 파이프라인에서 조율
