2026년 클라우드 솔루션 리포트: 코드형 인프라
디지털서비스 이슈리포트 2026-4호
이 글은 제가 NIA [한국지능정보사회진흥원]의 < 디지털서비스 이슈리포트 > 2026년 4월호에 기고한 글입니다. 원본 글 '[디지털서비스 이슈리포트2026-4] AI 수직통합이 시장을 지배한다.'를 이곳 브런치에서도 공유합니다.
(엔터프라이즈 CIO/CTO 들께 도움이 되었으면 하는 바램에서 정리하다 보니 길어졌습니다.. :( )
들어가며: 인프라를 선언하는 시대에서, AI가 인프라를 쓰는 시대로
2026년 현재, '코드형 인프라(Infrastructure as Code, IaC)'는 클라우드 운영의 문법이자 기본 전제가 되었다. 서버를 수동으로 구성하던 시대는 이미 먼 과거이며, 하시코프(HashiCorp)의 테라폼(Terraform)이 제시한 HCL(HashiCorp Configuration Language)로 인프라를 선언하고, CI/CD 파이프라인이 이를 자동으로 배포하는 워크플로가 엔터프라이즈의 사실상 표준으로 자리 잡은 지 오래다. 글로벌 IaC 시장 규모는 2025년 기준 약 13억 달러에서 2034년 94억 달러로 성장할 것으로 전망되며[1], 대다수 클라우드 사용자가 어떤 형태로든 IaC를 실천하고 있는 것이 현실이다.
그런데 이 시리즈에서 앞서 다룬 관측성(1월호)이나 보안(3월호) 영역과 IaC 사이에는 근본적인 차이가 있다. 데이터독(Datadog)이나 크라우드스트라이크(CrowdStrike) 같은 관측성·보안 도구들은 태생이 상용 SaaS였다. 기업은 이들을 '돈 내고 쓰는 것'으로 전제하고 도입했으며, 벤더 종속의 가능성을 감수한 채 의사결정을 내렸다. 반면 IaC의 핵심 도구들 — 테라폼, 앤서블(Ansible), 쿠버네티스(Kubernetes) — 은 오픈소스로 시작해 업계 표준이 되었다. 기업은 '커뮤니티의 것이니 안전하다'는 전제 위에 수년간의 인프라 코드, 상태 파일, 모듈 라이브러리, 팀의 전문성을 쌓아 올렸다.
문제는 이 전제가 무너졌을 때의 충격이 다른 영역과 비교할 수 없을 만큼 크다는 점이다. 관측성 도구를 교체하는 것은 창문을 바꾸는 것과 같다. 창문이 달라져도 집의 구조는 그대로다. 대시보드와 알림을 다시 설정하면 된다. 그러나 IaC 도구를 교체하는 것은 집의 설계도와 골조를 바꾸는 것에 가깝다. 현재 인프라의 전체 상태를 기록하고 있는 상태 파일(State File)을 마이그레이션하고, 수만 줄에 달하는 인프라 정의 코드를 재작성하며, 이를 구동하는 CI/CD 파이프라인을 재설계하고, 팀이 수년간 축적한 스킬셋까지 전환해야 한다. 이 높은 전환 비용이야말로 IaC 영역에서 라이선스와 벤더 전략의 변화가 유독 큰 파장을 일으키는 구조적 원인이다.
2023년 8월, 하시코프는 테라폼의 라이선스를 MPL 2.0(Mozilla Public License, OSI 승인 오픈소스)에서 BSL 1.1(Business Source License 1.1, SPDX 공식 식별자는 BUSL-1.1, OSI 미승인의 '소스 가용(source-available)' 라이선스)로 전환했다. 소스 코드는 여전히 공개되어 있고 사내 사용도 무료이지만, 테라폼을 호스팅해 경쟁 관계의 관리형 서비스로 판매하는 행위는 '추가 사용 제한 조항(Additional Use Grant)'이 금지하며, 그 범위를 넘어 상업적으로 제공하려면 하시코프와 별도 상용 계약을 맺어야 한다.
주목할 만한 조항은 'Change Date'다. 하시코프는 각 테라폼 릴리스가 공개된 시점으로부터 4년 후 해당 버전을 MPL 2.0으로 자동 전환하도록 명시했다. 이는 BSL을 SSPL이나 Elastic License 2.0처럼 영구 제한을 두는 소스 가용 라이선스와 구별하는 핵심 요소로, 오픈토푸가 시간이 지나면 테라폼의 해당 버전 스냅샷을 합법적으로 흡수할 수 있는 시한부 장치이기도 하다.
이는 테라폼만의 사건이 아니었다. 2018년 MongoDB(SSPL), 2021년 Elasticsearch(SSPL/Elastic License), 2024년 Redis(SSPL/RSALv2)에 이어 반복되는 패턴의 IaC 버전이었다. 회사가 오픈소스로 생태계를 키운 뒤, 대형 클라우드 사업자가 이를 관리형 서비스로 수익화하자 라이선스를 제한하고, 커뮤니티가 포크(Fork)로 응수하는 흐름이다(Elasticsearch와 Redis는 이후 AGPL을 추가 선택지로 제공해 부분적으로 오픈소스 경로를 복원했다). 그러나 앞서 설명한 IaC의 높은 전환 비용 때문에, 테라폼의 BSL 전환이 생태계에 미친 충격은 다른 어떤 사례보다도 깊고 오래 지속되었다.
이후 3년간의 전개는 이례적일 만큼 빠르고 다층적이었다. BSL 발표 불과 한 달 만인 2023년 9월, 리눅스 재단(Linux Foundation) 산하에서 오픈토푸(OpenTofu)가 포크되어 원래의 오픈소스 라이선스를 지키겠다고 선언했다. 2024년 4월 IBM이 64억 달러에 하시코프 인수를 발표했고, 2025년 2월 규제 승인이 완료되면서 테라폼은 레드햇(Red Hat)의 앤서블, 오픈시프트(OpenShift)와 한 지붕 아래 놓이게 되었다. 2025년에는 IBM-레드햇 포트폴리오 통합이 본격화되는 한편, 풀루미(Pulumi)는 테라폼의 HCL까지 자사 플랫폼에서 네이티브로 지원하겠다며 "양쪽 다 품는다" 전략을 펼쳤다. 그리고 2026년, 모든 주요 벤더가 일제히 AI 에이전트를 IaC의 핵심 전략으로 내세우며 경쟁의 축이 '라이선스 전쟁'에서 'AI 에이전트 전쟁'으로 이동하고 있다.
이 격변의 한가운데에서 CIO와 CTO는 두 가지 질문에 답해야 한다. 첫째, "우리 인프라 코드의 소유권은 누구에게 있는가?" — 이는 라이선스 조건, 벤더 종속의 깊이, 전환 전략의 존재 여부를 묻는 질문이다. 둘째, "AI가 인프라 코드를 쓸 때, 누가 그 코드를 검증하는가?" — 이는 AI 에이전트 시대의 거버넌스, 정책 집행, 책임 소재를 묻는 질문이다. 이 두 질문은 단순한 도구 선택을 넘어, 조직의 인프라 자동화 철학 자체를 결정짓는 전략적 판단이다.
본 리포트는 이 두 질문의 답을 찾는 과정이다. 2026년 IaC 생태계를 구성하는 6개 핵심 벤더와 프로젝트 — 테라폼, 오픈토푸, 풀루미, 크로스플레인, 스페이스리프트, 앤서블 — 을 심층 분석하고, AWS CDK, 애저 바이셉(Azure Bicep) 등 클라우드 서비스 제공자(CSP)의 네이티브 IaC 도구가 왜 업계 표준이 되지 못했는지도 함께 짚는다.
2026년을 가르는 세 갈래 긴장
개별 벤더를 논하기에 앞서, 2026년 IaC 시장을 관통하는 세 가지 거시적 흐름을 짚어 본다. 기능 체크리스트가 도구 선택의 기준이던 시대는 지났고, 2026년에는 다른 질문이 앞선다. '누구의 규칙 위에서 운영할 것인가', '코드를 쓰는 주체가 인간인가 AI인가', 그리고 '클라우드 사업자의 도구만으로 충분한가'.
라이선스 대분열 이후: 세 갈래의 길과 '듀얼 엔진' 시대
앞에서 BSL 전환의 배경과 충격을 짚었다면, 여기서는 그 이후 엔터프라이즈가 실제로 어떻게 대응하고 있는지를 살펴본다.
테라폼의 라이선스 전환이 촉발한 분열은 2026년 현재 세 갈래의 길로 정리되었다. 첫 번째 길은 IBM/하시코프 진영이다. IBM은 인수 후 테라폼을 레드햇의 앤서블, 오픈시프트, 그리고 왓슨엑스(watsonx)와 결합하여 하이브리드 클라우드 자동화의 '원스톱 포트폴리오'를 구축하고 있다. 테라폼이 인프라를 프로비저닝하고(Day 0, 초기 구축), 앤서블이 그 위의 구성과 운영을 자동화하며(Day 1-2, 운영·관리), 왓슨엑스가 지능형 의사결정을 지원하는 분업 체계다. 이 전략의 매력은 하나의 벤더 관계로 인프라 자동화의 전체 라이프사이클을 커버할 수 있다는 점이지만, 반대로 그만큼 깊은 벤더 종속을 의미하기도 한다.
두 번째 길은 오픈토푸다. 리눅스 재단 산하에서 출발한 이 프로젝트는 2025년 4월 CNCF(Cloud Native Computing Foundation) 샌드박스에 합류하며 제도적 정당성을 확보했고, 이후 레지스트리 사용량이 전년 대비 300% 이상 성장하는 등 실질적인 채택이 빠르게 늘고 있다[2]. 오라클(Oracle)과 VM웨어(VMware) 같은 대형 벤더가 오픈토푸 전환을 선언한 것도 주목할 만하다[3]. 커뮤니티 주도의 오픈 거버넌스를 전면에 내세우면서, 상태 파일 암호화와 에페메럴 리소스(Ephemeral Resources) 등 오픈토푸가 선제 도입한 기능으로 기술적 차별화를 이어가고 있다.
세 번째 길은 풀루미의 '생태계 포용' 전략이다. 파이썬(Python), 타입스크립트(TypeScript) 등 범용 언어로 인프라를 정의하는 차별적 접근을 유지하면서도, 2026년 1분기부터 테라폼의 HCL까지 퍼스트클래스 언어로 지원하고 풀루미 클라우드(Pulumi Cloud)에서 테라폼/오픈토푸 상태 파일을 직접 관리할 수 있게 했다. 하시코프 계약 잔여분을 풀루미 크레딧으로 이전해 주는 프로그램까지 갖추며, 테라폼 이탈 수요를 적극 흡수하고 있다.
흥미로운 것은 대다수의 엔터프라이즈가 이 세 갈래 중 하나만 선택하지 않는다는 점이다. 이미 성숙한 커뮤니티(깃허브 약 2만 5천 스타, 70명 이상의 활성 기여자[17])를 기반으로, 현장에서는 레거시는 테라폼으로 유지하고 그린필드에는 오픈토푸를 적용하는 '듀얼 엔진(Dual Engine)' 전략이 확산되고 있으며, HCP 테라폼(HCP Terraform, 구 Terraform Cloud)의 지속적인 가격 인상도 이 확산을 가속하는 요인이다. 양쪽을 하나의 화면에서 통합 관리하기 위한 오케스트레이션 플랫폼 — 스페이스리프트, Scalr, env0 — 이 새로운 레이어로 부상한 것도 이 맥락이다.
AI 에이전트가 인프라 코드를 쓴다: '더 많은 IaC'의 시대
라이선스 분열이 IaC 생태계의 '정치적' 지형을 바꿨다면, AI 에이전트의 등장은 '기술적' 지형을 근본적으로 재편하고 있다. 2026년 IaC 시장에서 AI는 벤더의 마케팅 슬로건이 아니라, 실제 제품의 핵심 기능으로 구현되기 시작했다.
여기서 먼저 짚어야 할, 언뜻 생각과 반대인 사실이 있다. AI가 인프라 자동화의 주역으로 떠오르면서 "IaC가 필요 없어지는 것 아닌가?"라는 질문이 자연스럽게 나온다. AI 에이전트가 클라우드 API를 직접 호출하여 서버를 생성하고 네트워크를 구성하면, 굳이 테라폼 코드를 거칠 필요가 있을까? 그러나 업계의 결론은 정반대다. AI 에이전트가 클라우드 API를 직접 호출하면 감사 추적(Audit Trail)이 불가능해지고, 롤백 전략이 부재하며, 거버넌스가 무력화된다. IaC는 AI 시대에 오히려 자율 인프라 관리의 '거버넌스 레이어(Governance Layer)' 또는 '검증 계층(Verification Layer)'으로서 더 필수적인 존재가 된다(여기서의 '거버넌스 레이어'는 뒤의 크로스플레인 섹션에서 다룰 쿠버네티스식 '런타임 컨트롤 플레인'과는 구분되는 개념이다). AI가 생성한 인프라 코드도 결국 버전 관리, 코드 리뷰, 정책 검증, 상태 관리라는 IaC의 안전망을 통과해야 하기 때문이다. 즉, AI는 IaC를 대체하는 것이 아니라 IaC를 '더 많이' 만들어내며, 그 결과 더 많은 배포, 더 많은 드리프트(Drift, 실제 인프라가 선언된 상태와 달라지는 현상) 가능성, 더 넓은 거버넌스 표면적이 생긴다.
이 인식 위에서, 2026년 IaC 벤더들은 일제히 AI 에이전트 전략을 내놓았다. 풀루미의 네오(Neo)는 업계 최초의 IaC 전용 AI 에이전트를 표방하고, IBM/하시코프의 프로젝트 인프라그래프(Project Infragraph)는 왓슨엑스 기반의 에이전틱 자동화로 '자율 인프라(Autonomous Infrastructure)'를 표방한다. 업바운드(Upbound)의 크로스플레인 2.0은 AI 에이전트가 쿠버네티스 API를 통해 인프라와 상호작용하는 '인텔리전트 컨트롤 플레인'을 내세우고, 스페이스리프트는 자연어로 인프라를 프로비저닝하는 스페이스리프트 인텐트(Spacelift Intent)를 출시하면서도 IaC를 '시스템 오브 레코드(System of Record)'로 유지하는 이원 모델을 제시한다. 레드햇의 앤서블 라이트스피드(Ansible Lightspeed)는 생성형 AI로 앤서블 플레이북을 작성하는 어시스턴트로, 복수의 외부 모델을 지원하는 BYOM(Bring Your Own Model) 접근을 취한다. 각 벤더의 세부 전략은 뒤의 벤더별 분석에서 짚는다. 이것이 '라이선스 전쟁'을 뒤잇는 'AI 에이전트 전쟁'의 전선이다.
이 모든 AI 에이전트가 공유하는 도전 과제는 거버넌스의 역설이다. 구글 클라우드의 2025년 DORA(DevOps Research and Assessment) 보고서에 따르면 개발자의 90%가 이미 AI 도구를 사용하고 있으며, 업무 시간의 약 4분의 1을 AI 어시스턴트와 협업하는 데 할애한다([9]에서 재인용). AI가 인프라 코드를 쓰는 속도는 인간이 리뷰하는 속도를 이미 압도한다. 따라서 코드로 정의된 정책(Policy-as-Code), 자동화된 드리프트 감지, 에이전트의 실행 범위를 제한하는 가드레일(Guardrail)이 AI 에이전트 도입의 전제 조건이 된다. AI가 더 많은 IaC를 만들수록, 더 정교한 거버넌스가 필요하다는 역설 — 이것이 2026년 IaC 시장의 핵심 긴장이다.
CSP 네이티브 IaC는 왜 표준이 되지 못했나
IaC를 논할 때 빠지지 않는 질문이 있다. "왜 클라우드 사업자의 자체 도구를 쓰면 안 되나?" AWS에는 CDK(Cloud Development Kit)가 있고, 마이크로소프트 애저(Azure)에는 바이셉(Bicep)이 있으며, 구글 클라우드(GCP)에는 컨피그 커넥터(Config Connector)가 있다. 각각 자기 클라우드에 최적화된 IaC 도구이며, CDK의 경우 타입스크립트나 파이썬 같은 범용 언어로 인프라를 정의할 수 있어 개발자 경험도 나쁘지 않다.
그러나 이 도구들이 업계 표준이 되지 못한 이유는 단순하고도 결정적이다. 멀티클라우드 환경에서 사용할 수 없다는 것이다. 전형적인 엔터프라이즈는 AWS 70%, 애저 20%, GCP 10%와 같은 비율로 복수의 클라우드를 사용한다. CSP 네이티브 도구를 쓰면 세 개의 서로 다른 언어, 세 개의 상태 관리 시스템, 세 개의 배포 파이프라인을 운영해야 한다. 테라폼이 IaC의 사실상 표준이 된 이유는 바로 '하나의 도구로 모든 클라우드를 관리할 수 있다'는 가치를 제공했기 때문이며, 이 가치는 CSP 도구가 구조적으로 제공할 수 없는 것이다. GCP의 클라우드 디플로이먼트 매니저(Cloud Deployment Manager)는 사실상 폐기 방향으로 가고 있고, GCP 자체가 테라폼을 가장 적극적으로 지원하는 CSP라는 점이 이 현실을 단적으로 보여준다.
다만 CSP는 IaC 생태계에서 무의미한 존재가 아니라, 오히려 '킹메이커(Kingmaker)'에 가깝다. 모든 IaC 도구는 CSP가 공급하는 프로바이더(Provider, 플러그인) 없이는 작동하지 않으며, 오픈토푸 포크 직후 AWS·구글 클라우드가 초기 지지를 선언한 것도 하시코프 단일 벤더에 대한 견제를 겸한 전략적 움직임이었다. 또한 단일 클라우드에 '올인'한 조직이라면 CDK의 타입 안전성(Type Safety)과 컴파일 타임 검증 같은 네이티브 도구의 장점은 여전히 유효하다. 결국 판단 기준은 의외로 단순하다. 단일 클라우드 전략이라면 CDK나 바이셉도 선택지에 올릴 수 있지만, 멀티클라우드 또는 향후 전환의 가능성이 조금이라도 있다면, 클라우드 중립적인 IaC 도구 — 테라폼, 오픈토푸, 풀루미, 크로스플레인 — 가 사실상 필수다.
주요 벤더별 솔루션 심층 분석
본 장에서는 2026년 IaC 생태계를 구성하는 6개 벤더와 프로젝트를 심층 분석한다. 6개를 같은 축 위에 나란히 놓기에 앞서, 이들이 실제로는 서로 다른 두 축에서 움직인다는 점을 먼저 짚어야 한다. 하나는 라이프사이클 축으로, 인프라를 '만드는' Day 0(프로비저닝)과 '운영하는' Day 1-2(구성 관리)로 나뉜다. 다른 하나는 실행 모델 축으로, 사람 또는 CI가 명령을 트리거하는 '명령형 실행'과 컨트롤러가 상태를 상시 조정하는 '선언형 리콘실리에이션(reconciliation)'으로 갈린다. 이 두 축 위에 6개 벤더를 배치하면 다음과 같다.
Day 0 × 명령형: 테라폼(Terraform), 오픈토푸(OpenTofu), 풀루미(Pulumi) — IaC 엔진 3파전
Day 0 × 선언형 리콘실리에이션: 크로스플레인(Crossplane) — 쿠버네티스 컨트롤 플레인을 인프라로 확장
Day 1-2 × 명령형: 앤서블(Ansible) — 구성 관리의 원조이자 에이전틱 AI의 실행 계층
전체를 감싸는 상위 레이어: 스페이스리프트(Spacelift) — 엔진 중립의 오케스트레이션 플랫폼
즉 이들은 하나의 레이어에서 경쟁하는 것이 아니라, IaC 생태계의 서로 다른 역할을 담당한다. 실제 엔터프라이즈에서는 이 중 2~3개를 함께 사용하는 것이 일반적이며, 본 분석은 "어떤 도구가 가장 좋은가"보다 "어떤 도구가 우리 조직의 어떤 문제를 풀어주는가"라는 관점에서 읽어야 한다.
테라폼(Terraform): 제국의 통합, 자유의 축소
테라폼은 2026년에도 IaC 시장에서 여전히 선두의 자리를 지키고 있다. 하시코프가 2014년에 처음 공개한 이후 10년 넘게 쌓아 온 생태계의 깊이는 쉽게 대체할 수 없는 자산이다. 3,000개 이상의 클라우드 서비스를 지원하는 프로바이더 생태계, 수십만 개의 커뮤니티 모듈, 그리고 "테라폼 엔지니어"라는 직군이 별도로 존재할 만큼 축적된 인력 풀은 엔터프라이즈가 테라폼에서 쉽게 벗어나지 못하는 구조적 이유다.
그러나 2026년의 테라폼은 더 이상 독립적인 오픈소스 도구가 아니다. 앞에서 다룬 IBM 인수 이후, 테라폼은 레드햇의 자동화 포트폴리오와 통합되는 과정에 있다. 앞서 짚은 '테라폼-앤서블' 분업 체계 안에서 테라폼은 Day 0(프로비저닝)의 엔진 역할을 맡으며, 레드햇 앤서블 프로바이더(Ansible Provider for Terraform)의 공식 지원과 HCP 테라폼 액션(HCP Terraform Actions)을 통한 엔드투엔드 통합이 로드맵에 올라 있다.
AI 전략: 프로젝트 인프라그래프(Project Infragraph)
테라폼의 AI 전략은 IBM의 소프트웨어 포트폴리오 전체를 관통하는 야심 찬 구상이다. 2025년 9월에 프리뷰된 프로젝트 인프라그래프[4]는 HCP(HashiCorp Cloud Platform)를 IBM의 주요 소프트웨어 — 앤서블, 오픈시프트, 왓슨엑스 오케스트레이트(watsonx Orchestrate), 콘서트(Concert, 앱 리스크 관측), 터보노믹(Turbonomic, 자원 최적화), 클라우더빌리티(Cloudability, 비용 관리) — 와 연결하는 실시간 인프라 그래프이자 에이전틱 자동화의 기반이다. IBM이 표방하는 비전은 인프라, 애플리케이션, 서비스, 소유권을 하나의 관계형 그래프로 묶어 '상태의 단일 기록(Single System of Record)'을 확보한 뒤, 그 위에서 AI가 인프라의 현재 상태를 추론하고 런북과 구성 변경을 제안·실행하는 '자율 인프라(Autonomous Infrastructure)'를 구현하는 것이다. 볼트(Vault)의 보안 데이터와 왓슨엑스의 추론 능력이 결합되면, 운영자의 개입 빈도를 최소화하는 폐쇄 루프 자동화가 가능해진다는 구상이다.
이 비전이 실현되면 테라폼은 단순한 프로비저닝 도구를 넘어 IBM 하이브리드 클라우드 전략의 핵심 축으로 격상되지만, 그만큼의 벤더 종속이 수반된다는 점은 냉정하게 따져봐야 할 대목이다.
그림 1: HCP 테라폼 Run 화면사용자들의 고충
테라폼 사용자들의 가장 큰 불안은 BSL 라이선스가 가져온 법적 모호성이다. "제품에 테라폼을 임베드해도 되는가?", "MSP가 고객에게 테라폼 기반 서비스를 제공하는 것이 '경쟁 서비스'에 해당하는가?" 같은 질문에 명쾌한 답이 없는 상황이 계속되고 있다. HCP 테라폼의 지속적인 가격 인상, IBM 인수 이후 외부 프로그래밍 언어 지원 중단도 불만 요인이다. IBM의 포트폴리오 통합이 고객에게 실질적 가치로 이어질지, 더 깊은 벤더 종속으로 귀결될지는 아직 미지수다.
오픈토푸(OpenTofu): 커뮤니티 포크, 엔터프라이즈 대안으로 부상하다
BSL 전환 발표 한 달 뒤인 2023년 9월에 포크된 오픈토푸는 출발부터가 '테라폼이 지켜야 했던 약속을 대신 지키겠다'는 선언이었다. 2026년 현재, 그 선언은 제도적 정당성과 기술적 차별화, 그리고 실질적인 엔터프라이즈 채택이라는 세 축에서 현실이 되고 있다.
그러나 오픈토푸의 진정한 차별화는 기술에 있다. 테라폼 v1.5.x 코드에서 포크된 뒤 '드롭인 대체재(Drop-in Replacement)'의 호환성을 유지하면서, 테라폼이 구현하지 않았거나 거부한 기능을 선제적으로 출시해 왔다. 대표적인 것이 상태 파일 암호화다. 테라폼의 상태 파일에는 데이터베이스 비밀번호, API 키 같은 민감 정보가 평문으로 저장되는데, 오픈토푸는 AWS KMS, GCP KMS, 오픈바오(OpenBao) 등을 이용해 상태 파일을 AES-GCM으로 암호화한다(v1.7). 여기서 더 나아가, 최신 v1.11에서는 '에페메럴 리소스(Ephemeral Resources)'를 도입해 임시 토큰처럼 단일 실행 중에만 필요한 민감 정보가 아예 상태 파일에 저장되지 않도록 설계했다[11]. 이 흐름 — '저장된 비밀의 보호'에서 '비밀이 애초에 저장되지 않는 설계'로 — 은 규제가 엄격한 금융·의료 산업에서 오픈토푸를 선택하는 핵심 동인이 되고 있다.
엔터프라이즈 채택의 흐름도 이를 뒷받침한다. 미국 대형 자산운용사 피델리티(Fidelity)는 5만 개 이상의 상태 파일과 400만 개 이상의 리소스를 테라폼에서 오픈토푸로 이전한 사례를 공개했고[18], 스페이스리프트에서는 전체 배포의 약 절반이 이미 오픈토푸로 실행되고 있다. 오라클은 자사 엔터프라이즈 제품인 E-비즈니스 스위트(E-Business Suite) 클라우드 매니저의 최신 버전에서 테라폼을 오픈토푸로 교체했다. 이는 '대안의 가능성'이 아니라 '진행 중인 이전'이 현실이 되었음을 보여준다.
그림 2 오픈토푸 홈페이지(https://opentofu.org/)사용자들의 고충
오픈토푸의 가장 큰 약점은 공식 매니지드 서비스의 부재다. HCP 테라폼처럼 벤더가 직접 운영하는 통합 플랫폼이 없어, 엔터프라이즈 운영을 위해서는 서드파티 플랫폼 선정이 필수적이다. 인력 시장에서도 "오픈토푸 경험자"라는 채용 공고는 아직 드물어, 실질 스킬 갭은 작더라도 조직 내 도입을 설득할 때 걸림돌이 되기도 한다. CNCF 샌드박스 단계라는 점도 일부 보수적인 엔터프라이즈에게는 장기 지속 가능성에 대한 의문을 남긴다.
풀루미(Pulumi): 적의 언어까지 품는다
풀루미는 IaC의 근본적인 질문을 다시 던진다. "인프라를 정의하는 언어가 왜 HCL 같은 전용 언어여야 하는가?" 테라폼의 HCL은 선언적이고 배우기 쉽다는 장점이 있지만, 조건부 로직이 복잡해지거나 동적 구성이 필요할 때 표현력의 한계에 부딪힌다. 풀루미는 이 문제를 정면으로 해결한다. 파이썬, 타입스크립트 등 개발자가 이미 익숙한 범용 프로그래밍 언어로 인프라를 정의할 수 있으며, 조건문, 반복문, 함수, 클래스, 테스트 프레임워크를 그대로 사용할 수 있다. 인프라 코드가 애플리케이션 코드와 같은 언어, 같은 IDE, 같은 테스트 도구 안에서 작성되므로, '인프라 엔지니어'와 '개발자'의 경계가 희미해진다.
2026년의 풀루미를 정의하는 두 가지 전략적 움직임이 있다. 하나는 앞서 핵심 이슈에서 소개한 테라폼 생태계 포용 전략이다. 2026년 1분기 일반 공개를 목표로, 풀루미 클라우드에서 테라폼/오픈토푸 상태 파일을 직접 관리하고 HCL을 퍼스트클래스 언어로 지원한다[5]. 여기서 주목할 점은 풀루미가 이를 "리프트앤시프트가 아닌 공존"이라 표현한다는 것이다. `pulumi convert --from terraform` 명령으로 코드를 변환할 수 있지만, 기존 테라폼 투자를 일거에 폐기하라는 것이 아니라 하이브리드 환경에서 점진적으로 풀루미의 장점을 취하라는 메시지다.
AI 전략: 풀루미 네오(Pulumi Neo) — 업계 최초 IaC AI 에이전트
두 번째 전략적 움직임은 AI 에이전트다. 2025년 9월에 공개된 풀루미 네오는 업계 최초의 IaC 전용 AI 에이전트로, CEO 조 더피(Joe Duffy)가 회사 인력의 상당 부분을 네오 개발에 집중 배치했을 만큼 전략적 베팅이 짙게 깔려 있는 제품이다. 네오는 단순한 코드 생성 어시스턴트가 아니라, 인프라의 의존성을 파악하고, 변경을 실행하며, 결과를 모니터링하고, 컴플라이언스를 유지하는 전 과정을 자율적으로 수행하는 '디지털 플랫폼 엔지니어'를 지향한다.
초기 성과는 주목할 만하다. 풀루미에 따르면, 미국 물류 기업 워너 엔터프라이즈(Werner Enterprises)는 네오 도입 후 인프라 프로비저닝 시간을 3일에서 4시간으로 단축했으며, SOC 2 컴플라이언스를 유지하면서 기능 배포 속도를 75% 향상시켰다. 베타 고객들은 기존 팀 규모로 10배의 인프라 딜리버리를 달성하고, 정책 위반을 90% 감소시켰다고 보고한다[6](이 수치는 풀루미가 공개한 것으로 독립 검증은 되지 않았다는 점은 감안해야 한다). 풀루미의 차세대 거버넌스 기능 — AI 기반 자동 수정(Remediation), 사전 구축 컴플라이언스 팩, 폴리시 파인딩스(Policy Findings) 허브 — 은 네오와 통합되어, 정책 위반이 발견되면 AI가 자동으로 수정 흐름을 실행하는 폐쇄 루프를 형성한다. 네오는 또한 모델 컨텍스트 프로토콜(Model Context Protocol, MCP) 서버를 통해 커서(Cursor), VS 코드(VS Code), 클로드 코드(Claude Code) 같은 개발 도구와 직접 통합된다. 프리뷰 기간 동안에는 풀루미의 모든 사용자에게 무료로 제공된다. "IaC 에이전트를 개발자의 에디터 안으로 가져오는" 접근은 인프라 작업과 애플리케이션 개발 사이의 경계를 한층 더 흐리는 시도다.
그림 3: 풀루미 네오 화면 예제사용자들의 고충
풀루미의 자유는 양날의 검이다. 범용 언어로 인프라를 정의할 수 있다는 것은 같은 인프라를 열 가지 방식으로 쓸 수 있다는 뜻이기도 하며, 팀 규모가 커질수록 코드 컨벤션 관리가 중요한 과제가 된다. 프로바이더 생태계도 과제로, 테라폼 프로바이더를 브릿지(Bridge)로 사용할 수 있지만 호환성 이슈가 간혹 발생하고 네이티브 프로바이더는 아직 테라폼만큼 넓지 않다. 네오는 현재 퍼블릭 프리뷰이며, 풀루미가 스타트업 규모로 테라폼 생태계 대비 체급이 작다는 점도 장기적 지속 가능성에 대한 의문을 남긴다.
크로스플레인(Crossplane): 컨트롤 플레인이라는 완전히 다른 길
그러나 앞서 다룬 세 벤더 — 테라폼, 오픈토푸, 풀루미 — 는 사실은 하나의 공통점을 공유한다. 모두 CLI 기반의 '실행 후 종료' 모델이라는 점이다. 엔지니어가 `terraform apply`나 `pulumi up`을 실행하면, 도구가 인프라를 프로비저닝하고 상태 파일을 업데이트한 후 프로세스를 종료한다. 누군가가 AWS 콘솔에서 수동으로 리소스를 변경하면(이른바 '드리프트'), 다음 실행 때까지 그 변경은 감지되지 않는다. 크로스플레인은 이 근본적인 한계를 정면으로 돌파한다.
크로스플레인은 쿠버네티스(Kubernetes)의 컨트롤 플레인을 인프라 관리로 확장한 프로젝트다. 인프라를 쿠버네티스 리소스로 선언하면, 컨트롤러가 실제 클라우드 상태(Observed State)를 지속적으로 감시하며 선언된 상태(Desired State)와 맞춰주는 리콘실리에이션 루프(Reconciliation Loop)를 상시 돌린다. 누군가가 수동으로 리소스를 변경하면 컨트롤러가 이를 즉시 감지하고 자동으로 원래 상태로 복구한다.
물론 테라폼의 `apply` 역시 상태 파일과 실제 인프라를 비교해 차이(diff)를 만든다는 점에서 논리적으로는 리콘실리에이션의 일종이다. 차이는 '누가 언제 트리거하느냐'에 있다. 테라폼은 사람 또는 CI의 명시적 명령을 기다리는 반면, 크로스플레인 컨트롤러는 이 루프를 지속적·자율적으로 실행한다. 'plan→apply를 사람이 실행'하는 대신 '선언하면 시스템이 알아서 유지'하는 접근이며, 쿠버네티스가 파드(Pod)의 상태를 끊임없이 조정하는 것과 동일한 메커니즘을 클라우드 인프라 전체로 확장한 것이다.
결과적으로 드리프트 대응 시간에도 결정적 차이가 생긴다. 테라폼은 다음 `apply` 때 감지·수정하는 반면, 크로스플레인은 수 초~수 분 내 자동 복구한다.
2025년 11월, 크로스플레인은 CNCF 졸업(Graduated) 지위를 획득하며, 쿠버네티스, 프로메테우스, 엔보이(Envoy)와 같은 클라우드 네이티브 핵심 프로젝트와 동일한 성숙도를 인정받았다. 이는 단순한 타이틀이 아니다. CNCF 졸업은 운영 성숙도, 광범위한 채택, 강건한 거버넌스 모델에 대한 엄격한 심사를 통과해야 얻을 수 있는 것이며, 크로스플레인 커뮤니티는 3,000명 이상의 기여자와 450개 이상의 참여 기업을 보유하고 있다[7]. 나이키(Nike), NASA 사이언스 클라우드, SAP 등이 대표적 프로덕션 사용자이며, 업바운드(Upbound)는 크로스플레인이 누적 1,000개 이상의 조직에 채택되고 1억 회 이상 다운로드되었다고 밝히고 있다[12].
크로스플레인이 가장 빛을 발하는 영역은 플랫폼 엔지니어링(Platform Engineering)이다. 플랫폼 팀이 크로스플레인의 컴포지션(Composition) 기능을 이용해 조직에 맞는 커스텀 API — 예를 들어 'Environment', 'Application', 'DatabaseService' 같은 — 를 정의하면, 개발자는 인프라의 세부 구현을 몰라도 이 API를 호출하는 것만으로 필요한 리소스를 프로비저닝할 수 있다. "인프라 티켓을 끊는 대신 API를 호출한다"는 운영 모델이다. 쿠버네티스의 RBAC(Role-Based Access Control) 시스템을 그대로 활용해 하나의 컨트롤 플레인에서 여러 팀의 접근 권한을 세밀하게 관리할 수 있다는 점도 엔터프라이즈에게 매력적이다.
AI 전략: 업바운드 크로스플레인 2.0 — AI 에이전트를 위한 컨트롤 플레인
업바운드(Upbound)가 오픈소스 크로스플레인 2.0을 기반으로 내놓은 상용 제품은 '인텔리전트 컨트롤 플레인'을 표방한다. 핵심 아이디어는 AI 에이전트가 쿠버네티스 API를 통해 인프라와 상호작용하는 일관된 제어점(Control Point)을 제공하는 것이다. 크로스플레인 2.0은 모델 컨텍스트 프로토콜(MCP)을 통해 클로드(Claude)와 오픈AI(OpenAI) 모델을 인프라 운영에 직접 통합할 수 있게 하며, 자연어 정책 기반 컴플라이언스 감사, 이슈 탐지와 권장 수정안 제시, 성능 패턴에 기반한 동적 리소스 스케일링 같은 기능을 지능형 컨트롤러(Intelligent Controllers)의 형태로 제공한다. "AI 에이전트는 인간처럼 파편화된 시스템 사이를 오갈 수 없다. 선언된 상태, 실제 상태, 정책, 지식을 한곳에 모은 통합 제어점이 있어야 제대로 동작한다"는 것이 업바운드의 논지다[12].
이 비전은 이미 현장에 도달하고 있다. 2026년 3월 쿠브콘 EU(KubeCon EU)에서 포르투갈의 밀레니엄 BCP(Millennium bcp) 은행은 "뱅킹에서의 자가 치유 인프라" 사례를 공개했다. 크로스플레인이 개발자 도구를 넘어 금융권 미션 크리티컬 영역에 도달했음을 보여주는 상징적 레퍼런스다.
그림 4 업바운드 콘솔 리소스 그래프 예제사용자들의 고충
크로스플레인의 가장 큰 진입 장벽은 학습 곡선이다. CRD(Custom Resource Definition), 컨트롤러, 리콘실리에이션 루프(Reconciliation Loop), RBAC 등 쿠버네티스 자체에 대한 깊은 이해가 전제되어야 하므로, 쿠버네티스를 도입하지 않은 조직에게는 시작조차 어렵다. 컴포지션 작성도 "테라폼 모듈보다 더 어렵다"는 평가가 나올 만큼 복잡하다. 현실적으로 엔터프라이즈에서는 "테라폼 대신 크로스플레인"이라는 대체 선택보다는, 테라폼으로 기반 인프라를 관리하면서 크로스플레인으로 개발자 셀프서비스를 제공하는 상보적 관계가 일반적이다. 이는 크로스플레인의 가치를 증명하면서도, 도구가 하나 더 늘어나는 복잡성 부담을 수반한다.
스페이스리프트(Spacelift): BSL의 당사자에서 분열의 수혜자로
지금까지 다룬 벤더들이 "인프라를 어떤 언어로, 어떤 방식으로 정의할 것인가"에 대한 답이었다면, 스페이스리프트는 다른 질문에 답한다. "정의한 인프라 코드를, 여러 도구에 걸쳐 어떻게 통제할 것인가?" 테라폼, 오픈토푸, 풀루미, 클라우드포메이션(CloudFormation), 앤서블 — 이 모든 IaC 도구를 단일 플랫폼에서 오케스트레이션하는 것이 스페이스리프트의 존재 이유다.
이 포지셔닝이 특히 의미를 갖는 것은 앞서 설명한 '듀얼 엔진' 시대의 맥락에서다. 레거시에는 테라폼, 신규 프로젝트에는 오픈토푸, 개발자 주도 프로젝트에는 풀루미를 병행하는 조직에게, 이 모든 도구의 스택(Stack)을 하나의 대시보드에서 관리하고, 통합된 정책을 적용하며, 드리프트를 감지하고, 감사 로그를 생성하는 레이어는 선택이 아니라 필수가 된다. 2025년 7월에 시리즈 C로 5,100만 달러를 유치한 것은[8], 이 시장의 성장 가능성에 대한 투자자들의 확신을 보여준다.
스페이스리프트의 이력은 그 자체로 IaC 라이선스 전쟁의 축소판이기도 하다. 테라폼 위에 관리형 서비스를 제공하는 비즈니스 모델을 구축했던 스페이스리프트는 BSL 전환이 사업 모델의 재정비를 요구한 당사자였다. 하지만 이에 대한 대응은 빨랐다. 오픈토푸를 네이티브로 지원하고, 테라폼에서 오픈토푸로의 마이그레이션 가이드를 제공하며, 궁극적으로 어떤 IaC 엔진이든 관리할 수 있는 벤더 중립적 플랫폼으로 포지셔닝을 확장했다. BSL 전환의 당사자였던 플랫폼이 생태계 분열의 수혜자로 전환한 사례다.
AI 전략: 스페이스리프트 인텔리전스(Spacelift Intelligence)
2026년 3월에 발표된 스페이스리프트 인텔리전스[9]는 두 가지 구성 요소로 이루어진다. 첫째, 스페이스리프트 인텐트(Spacelift Intent)는 자연어로 인프라를 프로비저닝하는 기능으로, 이미 일반 공개(GA) 상태다. "us-west-2에 PostgreSQL RDS를 하나 만들어줘"라고 입력하면 인텐트가 해당 리소스를 프로비저닝한다. 핵심은 이 기능이 기존 IaC 파이프라인을 대체하는 것이 아니라 보완한다는 점이다. 스페이스리프트는 인텐트를 프로토타이핑과 실험용 빠른 배포 경로로 포지셔닝하면서, 프로덕션 환경에서는 여전히 IaC 코드가 '시스템 오브 레코드(System of Record)'로 남아야 한다고 명확히 한다. "AI로 빠르게 만들고, IaC로 안전하게 관리한다"는 이원 모델이다.
둘째, AI 어시스턴트는 인프라 상태 질의, 정책 생성, 드리프트 진단, 가이드 온보딩을 자연어로 수행하는 범용 AI 인터페이스다. 스페이스리프트가 이 기능을 출시한 맥락은 명확하다. "개발자가 AI 도구의 도움으로 코드를 쓰는 속도가 폭발적으로 빨라졌는데, 전통적인 IaC 파이프라인의 속도가 이를 따라가지 못한다"는 문제 인식이다.
그림 5: 스페이스리프트 스택 대시보드사용자들의 고충
"또 다른 레이어"라는 비판은 스페이스리프트가 마주하는 가장 본질적인 질문이다. IaC 엔진 위에 관리 플랫폼까지 도입하면 아키텍처 복잡성이 증가하며, 소규모 팀에게는 과잉 투자가 될 수 있다. HCP 테라폼이나 IBM 브랜드 대비 낮은 인지도, 공개 가격표 없이 영업 상담이 필요한 가격 모델도 마찰 요인이다. 벤더 종속을 피하려 도입한 오케스트레이션 플랫폼이 그 자체로 새로운 종속 지점이 될 수 있다는 역설도 간과할 수 없다.
앤서블(Ansible): 에이전틱 AI의 가드레일이 되다
앤서블은 본 리포트에서 다루는 여섯 벤더 중 유일하게 '순수한 IaC 도구'로 분류되지 않는 존재다. 테라폼이나 오픈토푸가 "무엇을 만들 것인가"(Day 0, 인프라 프로비저닝)에 답한다면, 앤서블은 "만든 후 어떻게 설정하고 운영할 것인가"(Day 1-2, 구성 관리 및 운영 자동화)에 답한다. 서버에 패키지를 설치하고, 보안 설정을 적용하며, 패치를 배포하고, 정기적인 운영 작업을 자동화하는 것이 앤서블의 본령이다. 그러나 앤서블을 IaC 리포트에 포함한 이유는 두 가지다.
첫째, 앤서블의 자동화 범위가 IaC와 겹치는 영역이 넓어지고 있다. 앤서블도 AWS, 애저, GCP의 클라우드 모듈을 통해 인프라 프로비저닝이 가능하며, 쿠버네티스 리소스를 관리하는 모듈도 갖추고 있다. 상태 파일이 없다는 구조적 한계 때문에 테라폼을 대체하지는 못하지만, 경량 프로비저닝에서는 충분히 활용되고 있다.
둘째, 더 중요한 이유로, 앤서블이 IBM 산하에서 테라폼과 공식적인 역할 분담 체계를 형성하고 있다는 점이다. 앞서 설명한 Day 0/Day 1-2 분업 체계에서 앤서블은 후반부 — 구성 관리와 운영 자동화 — 의 주인공이며, 이 조합은 인프라 라이프사이클 전체를 하나의 벤더 관계로 커버하겠다는 IBM 하이브리드 클라우드 전략의 핵심 축이다.
앤서블의 아키텍처적 강점은 에이전트리스(Agentless) 설계에 있다. 대상 서버에 별도의 에이전트를 설치할 필요 없이 SSH나 WinRM으로 접속하여 작업을 수행한다. 이 덕분에 쿠버네티스가 아닌 VM, 베어메탈 서버, 네트워크 장비, 심지어 스토리지 어레이까지 — 자동화 대상의 범위가 본 리포트에서 다루는 어떤 도구보다도 넓다. 2025년 10월에 일반 공개된 앤서블 오토메이션 플랫폼(Ansible Automation Platform) 2.6[10]은 이벤트 기반 앤서블(Event-Driven Ansible), 셀프서비스 자동화 포탈, 자동화 가치 측정 대시보드를 갖추고 있으며, IBM 파워(Power), IBM Z, IBM 리눅스원(LinuxONE)에서도 네이티브로 실행된다.
AI 전략: 앤서블 라이트스피드(Ansible Lightspeed)
레드햇과 IBM 리서치가 공동으로 개발한 앤서블 라이트스피드는 생성형 AI 기반의 플레이북 작성 어시스턴트다. 자연어로 "nginx를 설치하고 방화벽 80번 포트를 열어줘"라고 요청하면, 라이트스피드가 해당 작업을 수행하는 앤서블 플레이북을 생성한다. 여기서 주목할 점은 BYOM(Bring Your Own Model) 접근이다. 라이트스피드는 현재 레드햇 AI, 오픈AI, 애저 오픈AI(Azure OpenAI) 모델을 지원하고 있으며, IBM 왓슨엑스(watsonx.ai)와 구글 제미나이(Gemini)는 로드맵에 포함되어 있다. 특정 AI 벤더에 종속되지 않으면서 AI 역량을 확보하려는 엔터프라이즈의 니즈에 부합하는 설계다.
그러나 라이트스피드보다 더 전략적으로 주목해야 할 것은 레드햇이 최근 제시한 새로운 포지셔닝이다. 레드햇은 앤서블을 "에이전틱 AI 시스템의 신뢰 가능한 실행 계층(Trusted Execution Layer)"으로 규정하며, AI 에이전트가 프로덕션 시스템에 직접 접근하는 것이 아니라 앤서블을 거쳐 검증된 워크플로를 통해 작업하도록 하는 아키텍처를 추진하고 있다[13]. 이 비전의 구체화된 결과물이 앤서블 오토메이션 플랫폼에 기술 프리뷰로 포함된 MCP 서버다[16]. 흥미로운 점은 이 MCP 서버가 영구 배포가 아니라 실행 환경 내에서 일회성으로 동작하는 '단명(Short-Lived) 컨테이너'로 구현된다는 것이다. 각 MCP 서버 인스턴스는 필요한 순간에만 올라오고, 역할 기반 접근 제어로 에이전트별 권한이 제한되며, 작업이 끝나면 사라진다. 영구적으로 떠 있는 MCP 서버가 만드는 공격 표면을 원천 차단하려는 설계로, 보안을 중시하는 엔터프라이즈 환경에 최적화되어 있다. 결국 레드햇의 메시지는 단순하다. AI 에이전트가 인프라를 '운전'하되, 앤서블이라는 '가드레일' 안에서만 주행해야 한다는 것이다.
그림 6: 앤서블 오토메이션 플랫폼 자동화 대시보드사용자들의 고충
앤서블 사용자들이 가장 자주 토로하는 혼란은 IaC와의 경계 모호성이다. 앤서블로도 클라우드 리소스를 프로비저닝할 수 있으나, 상태 파일이 없어 현재 인프라 상태를 추적할 수 없고, 멱등성(Idempotency) 보장이 모듈마다 다르다. "어디까지가 앤서블이고 어디부터가 테라폼인가?"라는 질문에 명쾌한 답이 없는 상황이 반복된다. 대규모 인벤토리에서 SSH 기반 실행의 속도 문제도 지적된다. 또한 무료 앤서블과 상용 오토메이션 플랫폼 사이의 기능 격차 — 이벤트 기반 자동화, 셀프서비스 포탈, 라이트스피드 등 핵심 기능이 상용 전용 — 는 레드햇/IBM 종속이라는 또 다른 과제를 남긴다. 마지막으로, 복잡한 워크플로를 YAML로 정의하는 데에는 근본적 한계가 있어, 로직이 복잡해질수록 가독성이 급락한다. 풀루미가 '왜 인프라를 HCL 같은 전용 언어로만 써야 하는가'라고 물었던 바로 그 문제가, 앤서블의 YAML에서도 반복되는 셈이다.
맺으며: CIO/CTO를 위한 IaC 전략 제언
2026년의 IaC 생태계는 3년 전과 완전히 다른 풍경이다. 테라폼이라는 단일 표준이 지배하던 시대는 끝났고, 라이선스 분열과 AI 에이전트의 등장이 동시에 진행되면서 선택지는 늘어났지만 의사결정의 복잡도도 함께 높아졌다. 본 리포트에서 분석한 6개 벤더는 하나의 레이어에서 경쟁하는 것이 아니라, 인프라 자동화의 서로 다른 단계와 역할을 담당한다. 따라서 "어떤 도구가 가장 좋은가?"라는 질문보다 "우리 조직에 필요한 레이어는 무엇이고, 각 레이어에서 최선의 선택은 무엇인가?"라는 질문이 더 생산적이다.
국내 CIO/CTO의 맥락에서 한 가지 덧붙이자면, 2026년은 한국 공공 클라우드 정책이 크게 전환되는 해이기도 하다. 공공 분야에 클라우드 서비스를 공급하려면 기존에는 클라우드 보안인증제(CSAP, 과학기술정보통신부 고시에 따라 한국인터넷진흥원이 평가·인증하는 공공 클라우드 보안 기준)를 획득한 뒤 국가정보원의 보안적합성 검증을 다시 받아야 하는 '이중 규제' 구조였다.
2026년 상반기부터 제도 개선 절차가 착수될 전망으로, CSAP의 등급 체계가 국가망보안체계(N2SF, National Network Security Framework)의 기밀(C)·민감(S)·공개(O) 체계에 맞춰 통일되고, CSAP를 별도로 취득하지 않아도 보안적합성 검증을 통해 공공 진출이 가능해지는 방향이다. 단계적 시행이므로 등급별 적용 범위와 시점은 향후 고시에 따라 구체화될 것으로 보이며, 이 흐름은 수많은 공공 시스템과 레거시 인프라를 이식·관리해야 하는 새로운 IaC 수요로 이어진다[14].
국내 CSP인 네이버클라우드가 테라폼 프로바이더를 공식 지원하고 활용 가이드를 적극적으로 공개하는 것도[15], 한국 시장에서 테라폼이 사실상의 표준으로 자리 잡았음을 보여주는 단면이다. 달리 말해, 테라폼이 한국 시장의 사실상 표준이라는 것은 본 리포트에서 다룬 BSL 라이선스 리스크가 한국 공공·금융 인프라에도 예외 없이 적용된다는 의미이기도 하다. 글로벌 논의와 국내 현실 사이의 시차가 점차 좁혀지고 있는 지금, 아래 네 가지 전략적 제언을 드린다.
제언 1: IaC 도구를 '레이어별'로 선택하라
하나의 도구로 인프라 자동화의 모든 것을 해결하려는 유혹을 경계할 것을 권한다. 2026년의 IaC 생태계는 이미 명확한 레이어로 분화되었으며, 레이어별로 최선의 도구를 조합하는 것이 현실적이다.
프로비저닝 엔진(Day 0): 테라폼·오픈토푸·풀루미의 영역. 기존 테라폼 투자가 깊다면 테라폼을 유지하되, 신규 프로젝트에는 오픈토푸를 병행하는 듀얼 엔진 전략이 현실적이다. 개발자 주도 팀이라면 풀루미의 범용 언어 접근도 고려할 만하다.
구성 및 운영 자동화(Day 1-2): 앤서블의 영역. 특히 VM, 베어메탈, 네트워크 장비 등 쿠버네티스 밖의 인프라가 많은 조직에서는 앤서블의 에이전트리스 아키텍처가 다른 도구로 대체하기 어려운 가치를 제공한다.
개발자 셀프서비스 플랫폼: 쿠버네티스 도입이 성숙한 조직이라면 크로스플레인을 플랫폼 엔지니어링의 백본으로 검토할 수 있다. 인프라 티켓 문화를 API 문화로 전환하는 지렛대가 된다.
오케스트레이션 레이어: 단일 엔진(테라폼만)을 운영한다면 HCP 테라폼이 경제적이지만, 멀티 엔진 환경에서는 엔진 중립의 스페이스리프트가 자연스럽다. 어느 쪽이든 거버넌스와 가시성의 중심이 되어야 한다.
단, 조합에는 비용이 따른다. 다음 다섯 가지는 조합 전략을 세울 때 반드시 동시에 설계되어야 한다.
상태(State)의 단일 소스 문제: 여러 엔진이 같은 리소스의 소유권을 다투면 드리프트가 무한 발생한다.
정책 엔진 중복: Sentinel·CrossGuard·OPA·Kyverno가 레이어마다 반복된다.
RBAC 단절: HCP·쿠버네티스·스페이스리프트·AAP의 권한 체계가 SSO/IdP로 수렴하지 않으면 권한 귀속이 미궁에 빠진다.
시크릿 배포 경로의 파편화: 엔진마다 별도 경로를 거치므로 회전·폐기 정책이 일관되지 않는다.
의존성 그래프의 단절: 엔진 내부 DAG와 엔진 간 결합의 타입 안전성이 부재하다.
어떤 벤더도 "우리 하나로 충분하다"고 말하지만, 현실은 2~3개 도구의 조합이 최적인 경우가 대부분이다.
제언 2: 라이선스 리스크를 기술 부채처럼 관리하라
테라폼의 BSL 전환이 보여준 교훈은 명확하다. 오픈소스 도구의 라이선스 변경은 예고 없이, 그리고 기존 사용자까지 소급하는 형태로 올 수 있다. 이는 테라폼만의 문제가 아니다. 몽고DB, 엘라스틱서치, 레디스에 이어 반복되는 패턴이며, 이 목록에 다음으로 추가될 도구가 무엇인지는 아무도 모른다.
따라서 핵심 IaC 도구의 라이선스 조건을 연 1회 이상 정기적으로 검토하고, 주요 도구별 전환 시나리오(마이그레이션 플레이북)를 미리 준비해둘 것을 권한다. 테라폼에서 오픈토푸로의 전환은 호환성이 높아 상대적으로 수월하지만, 그조차도 상태 파일 마이그레이션, CI/CD 파이프라인 수정, 팀 교육이라는 작업을 수반한다.
라이선스 재변경 가능성을 선제 평가하는 한 가지 지표는 해당 프로젝트의 저작권 집중도다. 단일 벤더에 Contributor License Agreement(CLA)로 저작권이 집중된 프로젝트는 라이선스를 다시 바꿀 수 있는 반면, 리눅스 커널처럼 저작권이 기여자 전원에 분산된 프로젝트는 재변경이 사실상 불가능하다. 또한 상용 계약 갱신 시에는 'Grandfather 조항' — 향후 라이선스가 바뀌더라도 기존 사용권은 계약 시점의 조건으로 유지된다는 합의 — 을 명시적으로 협상하는 것도 실무적 안전장치가 된다.
"오픈소스이므로 무료이고, 무료이므로 영원히 안전하다"는 가정은 더 이상 유효하지 않다. 라이선스 리스크를 기술 부채와 동일한 수준으로 관리하는 조직만이, 다음 번 라이선스 변경에서도 주도권을 유지할 수 있다.
제언 3: AI IaC 에이전트를 도입하되, 가드레일부터 설계하라
풀루미 네오의 고객 사례(프로비저닝 3일→4시간), 스페이스리프트 인텐트의 자연어 배포, 앤서블 라이트스피드의 플레이북 자동 생성 — AI IaC 에이전트의 생산성 향상은 이미 실증되고 있다. 이 흐름을 무시하는 것은 경쟁력 저하를 자초하는 것과 같다.
그러나 "AI가 만든 인프라 코드"를 검증 없이 프로덕션에 배포하는 것은 위험하다. AI는 그럴듯한 코드를 빠르게 만들어내지만, 보안 그룹의 미묘한 설정 오류나 비용 폭증을 유발하는 리소스 사이징 실수를 범할 수 있다. 따라서 AI 에이전트 도입의 순서는 명확하다. 먼저, 코드로 정의된 정책(Policy-as-Code)을 구축해야 한다. OPA(Open Policy Agent), 센티넬(Sentinel), 풀루미 크로스가드(CrossGuard) 등의 정책 엔진이 AI가 생성한 코드를 자동으로 검증하는 안전망이 되어야 한다.
다음으로는 AI 에이전트의 실행 범위를 티어(Tier)별로 점진 확대할 것을 권한다.
Tier 1 — 코드 생성 어시스턴트: 개발 환경에서 AI가 IaC 코드를 제안하고, 인간 엔지니어가 리뷰·승인.
Tier 2 — 스테이징 자동 배포: 스테이징 환경에서 AI가 정책 검증을 통과한 변경을 자율 배포. 프로덕션은 여전히 인간 승인.
Tier 3 — 프로덕션 자율 운영: 드리프트 감지와 롤백, 비긴급 변경의 자율 실행까지 AI에 위임. 가장 엄격한 가드레일·감사·킬 스위치가 전제.
스페이스리프트가 제시한 "인텐트로 빠르게 만들고, IaC 파이프라인으로 안전하게 관리한다"는 이원 모델은 Tier 1~2 사이의 좋은 참조가 된다.
제언 4: "우리 클라우드 도구를 쓰면 되지 않나?"라는 질문에 답을 준비하라
경영진이나 CSP 영업으로부터 "AWS CDK(또는 애저 바이셉)면 충분하지 않나?"라는 질문은 반드시 나온다. 본문에서 짚었듯 단일 클라우드 전략이라면 CSP 네이티브 도구도 선택지에 올릴 수 있지만, 멀티클라우드 또는 향후 전환의 가능성이 조금이라도 있다면 클라우드 중립적인 IaC 도구가 필수다.
정작 중요한 것은 이 판단 기준을 미리 정리해 문서화해 두는 일이다. 그래야 도구 선정 논의가 나올 때마다 원점에서 반복되는 비생산적인 왕복을 줄일 수 있다. "왜 테라폼(또는 오픈토푸, 풀루미)을 쓰는가?"에 대한 조직 차원의 합의된 답변을 갖추는 것, 그것이 IaC 거버넌스의 출발점이다.
글의 서두에서 던졌던 두 질문으로 돌아온다. "우리 인프라 코드의 소유권은 누구에게 있는가?" 그리고 "AI가 인프라 코드를 쓸 때, 누가 그 코드를 검증하는가?" 3년 전이었다면 전자는 '당연히 커뮤니티', 후자는 '아직 먼 미래의 이야기'였을 것이다. 그러나 2026년의 답은 훨씬 복잡해졌다. 소유권은 라이선스와 포트폴리오 전략 안에서 협상해야 하는 대상이 되었고, AI가 쓴 코드를 검증하는 주체는 이제 조직의 거버넌스 설계 역량 그 자체가 되었다. 결국 IaC는 더 이상 엔지니어링의 기술 선택 문제가 아니라, 조직이 자신의 인프라를 어떤 규율 아래 운영할 것인가를 묻는 경영의 질문이다. 이 두 질문에 답할 수 있는 조직만이 다음 3년의 격변을 주도권을 쥔 채 통과할 것이다.
참고 문헌
[1] Precedence Research, "Infrastructure as Code Market Size to Reach USD 9.40 Bn by 2034," https://www.precedenceresearch.com/infrastructure-as-code-market
[2] Matt Asay, "OpenTofu becomes the real deal," InfoWorld, https://www.infoworld.com/article/3852167/opentofu-becomes-the-real-deal.html
[3] DevPro Journal, "The OpenTofu Switch Trend: Are Industry Players Abandoning the Terraform Ship?," https://www.devprojournal.com/technology-trends/open-source/the-opentofu-switch-trend-are-industry-players-abandoning-the-terraform-ship/
[4] IBM Newsroom, "HashiCorp Previews the Future of Agentic Infrastructure Automation with Project Infragraph," Sep 25, 2025, https://newsroom.ibm.com/2025-09-25-hashicorp-previews-the-future-of-agentic-infrastructure-automation-with-project-infragraph
[5] Pulumi Blog, "Pulumi for All Your IaC — Including Terraform and HCL," https://www.pulumi.com/blog/all-iac-including-terraform-and-hcl/
[6] PR Newswire, "Introducing Pulumi Neo, the Industry's First AI-Powered Platform Engineer," Sep 16, 2025, https://www.prnewswire.com/news-releases/introducing-pulumi-neo-the-industrys-first-ai-powered-platform-engineer-302556718.html
[7] InfoQ, "Crossplane Reaches Production Maturity by Graduating CNCF," Nov 2025, https://www.infoq.com/news/2025/11/crossplane-grad/
[8] PR Newswire, "Spacelift Raises $51M Series C to Redefine Enterprise Infrastructure Automation," Jul 10, 2025, https://www.prnewswire.com/news-releases/spacelift-raises-51m-series-c-to-redefine-enterprise-infrastructure-automation-302501578.html
[9] PR Newswire, "Launch of Spacelift Intelligence Brings New, AI-Enhanced Operating Model to Drowning Infrastructure Teams," Mar 18, 2026, https://www.prnewswire.com/news-releases/launch-of-spacelift-intelligence-brings-new-ai-enhanced-operating-model-to-drowning-infrastructure-teams-302717517.html
[10] Red Hat Blog, "What's new in Red Hat Ansible Automation Platform 2.6," Oct 2025, https://www.redhat.com/en/blog/whats-new-in-ansible-automation-platform-2.6
[11] OpenTofu, "What's new in OpenTofu 1.11," https://opentofu.org/docs/intro/whats-new/
[12] Upbound Blog, "Introducing Upbound Crossplane 2.0 — The AI-Native Control Plane for the Agentic Era," https://www.upbound.io/blog/introducing-upbound-crossplane-2-0
[13] Techzine Global, "Red Hat makes Ansible the execution layer for agentic AI systems," Mar 5, 2026, https://www.techzine.eu/blogs/infrastructure/139296/red-hat-makes-ansible-the-execution-layer-for-agentic-ai-systems/
[14] 전자신문, "[단독]클라우드, 내년부터 CSAP 없어도 공공 진출 가능해진다," 2025-12-12, https://www.etnews.com/20251212000235
[15] NAVER Cloud, "네이버 클라우드 플랫폼에서 terraform 활용 — ansible 연동," https://medium.com/naver-cloud-platform/%EC%9D%B4%EB%A0%87%EA%B2%8C-%EC%82%AC%EC%9A%A9%ED%95%98%EC%84%B8%EC%9A%94-%EB%84%A4%EC%9D%B4%EB%B2%84-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%ED%94%8C%EB%A0%9B%ED%8F%BC%EC%97%90%EC%84%9C-terraform-%ED%99%9C%EC%9A%A9-1-ansible-%EC%97%B0%EB%8F%99-eac66c6ad494
[16] Red Hat Blog, "IT automation with agentic AI: Introducing the MCP server for Red Hat Ansible Automation Platform," Jan 30, 2026, https://www.redhat.com/en/blog/it-automation-agentic-ai-introducing-mcp-server-red-hat-ansible-automation-platform
[17] Scalr, "From Fork to Future: How OpenTofu's Community-First Approach is Reshaping Infrastructure as Code" (Spacelift Q4 2024 Survey 인용), https://scalr.com/learning-center/from-fork-to-future-how-opentofus-community-first-approach-is-reshaping-infrastructure-as-code-2/
[18] OpenTofu Blog, "Fidelity Investments Shares Its Migration Story from Terraform to OpenTofu," https://opentofu.org/blog/fidelity-investment-migration/