--- title: "2026년 코드형 인프라 판세 정리…테라폼 이후엔 라이선스와 AI 에이전트가 전쟁터다" published: 2026-05-08T18:05:03.993Z canonical: https://jeff.news/article/2316 --- # 2026년 코드형 인프라 판세 정리…테라폼 이후엔 라이선스와 AI 에이전트가 전쟁터다 2026년 코드형 인프라 시장은 테라폼 단일 표준 시대에서 벗어나 오픈토푸, 풀루미, 크로스플레인, 스페이스리프트, 앤서블이 각 레이어를 나눠 갖는 구조로 바뀌고 있다. 테라폼의 BSL 전환과 IBM 인수는 라이선스 리스크를 전면에 올렸고, AI 에이전트는 IaC를 대체하기보다 더 많은 코드와 더 강한 거버넌스를 요구하는 방향으로 흘러가고 있다. 한국 공공 클라우드와 네이버클라우드 테라폼 생태계까지 고려하면 국내 조직도 더 이상 남의 얘기로 보기 어렵다. ## 테라폼 단일 표준 시대가 끝나고 있음 - 2026년 코드형 인프라(IaC)는 더 이상 “테라폼 쓰면 끝”인 시장이 아님 - 테라폼은 여전히 3,000개 이상의 클라우드 서비스를 지원하는 프로바이더 생태계와 수십만 개 커뮤니티 모듈을 가진 선두 도구임 - 하지만 2023년 8월 하시코프가 테라폼 라이선스를 MPL 2.0에서 BSL 1.1로 바꾸면서, “커뮤니티 도구라 안전하다”는 전제가 깨짐 - 사내 사용은 무료지만, 테라폼을 호스팅해 경쟁 관리형 서비스로 파는 행위는 제한됨 - IaC 도구 교체가 유독 아픈 이유는 상태 파일과 운영 지식이 한꺼번에 묶여 있기 때문임 - 관측성 도구를 바꾸는 건 대시보드와 알림을 다시 만드는 수준에 가깝지만, IaC는 인프라 설계도와 골조를 바꾸는 느낌임 - 상태 파일(State File), 수만 줄의 인프라 정의 코드, CI/CD 파이프라인, 팀의 숙련도까지 같이 움직여야 함 - 그래서 라이선스 변경 하나가 단순한 법무 이슈가 아니라 인프라 전략 문제가 됨 - 테라폼 이후의 길은 크게 세 갈래로 갈라짐 - IBM/하시코프 진영은 테라폼을 레드햇 앤서블, 오픈시프트, 왓슨엑스와 묶어 하이브리드 클라우드 자동화 포트폴리오로 키우는 중임 - 오픈토푸(OpenTofu)는 리눅스 재단 산하 포크로, 원래의 오픈소스 약속을 지키겠다는 쪽임 - 풀루미(Pulumi)는 범용 언어 기반 IaC를 유지하면서 테라폼의 HCL과 상태 파일까지 품겠다는 전략을 들고 나옴 > [!IMPORTANT] > 엔터프라이즈 현장에서는 하나만 고르는 분위기가 아님. 레거시는 테라폼, 신규 프로젝트는 오픈토푸, 개발자 주도 팀은 풀루미를 섞는 `듀얼 엔진` 또는 `멀티 엔진` 전략이 현실적인 선택지로 떠오르고 있음. ## AI 에이전트는 IaC를 없애지 않고 더 많이 만든다 - “AI가 클라우드 API를 직접 호출하면 IaC가 필요 없어지는 거 아냐?”라는 질문에 업계 답은 반대에 가까움 - AI가 직접 서버를 만들고 네트워크를 바꾸면 감사 추적, 롤백, 코드 리뷰, 정책 검증이 비어버림 - 그래서 IaC는 AI 시대에 오히려 거버넌스 레이어이자 검증 계층으로 더 중요해짐 - AI가 만든 인프라 변경도 결국 버전 관리와 정책 검증, 상태 관리를 통과해야 안전함 - 주요 벤더들은 이미 AI 에이전트를 IaC 전략의 중심에 올려놓음 - 풀루미 네오(Neo)는 IaC 전용 AI 에이전트를 표방하며, 인프라 의존성 파악부터 변경 실행, 모니터링, 컴플라이언스 유지까지 노림 - IBM/하시코프의 프로젝트 인프라그래프(Project Infragraph)는 인프라·앱·서비스·소유권을 관계형 그래프로 묶고, 왓슨엑스 기반 에이전트 자동화를 얹는 구상임 - 스페이스리프트 인텐트(Spacelift Intent)는 자연어로 인프라를 만들되, 프로덕션에서는 IaC를 시스템 오브 레코드로 남기는 이원 모델을 제시함 - 앤서블 라이트스피드(Ansible Lightspeed)는 자연어로 플레이북을 만들고, 앤서블을 에이전틱 AI의 신뢰 가능한 실행 계층으로 포지셔닝함 - 문제는 AI가 코드를 쓰는 속도가 인간 리뷰 속도를 압도한다는 점임 - 구글 클라우드의 2025년 DORA 보고서 인용에 따르면 개발자의 90%가 이미 AI 도구를 쓰고, 업무 시간의 약 4분의 1을 AI 어시스턴트와 협업하는 데 쓴다고 함 - AI가 더 많은 IaC를 만들수록 더 많은 배포, 더 많은 드리프트, 더 넓은 거버넌스 표면이 생김 - 코드로 정의된 정책(Policy-as-Code), 자동 드리프트 감지, 에이전트 실행 범위 제한이 선택이 아니라 전제가 됨 ```mermaid sequenceDiagram participant 개발자 participant AI에이전트 participant IaC파이프라인 participant 정책엔진 participant 클라우드 개발자->>AI에이전트: 자연어로 인프라 변경 요청 AI에이전트->>IaC파이프라인: 인프라 코드 생성 IaC파이프라인->>정책엔진: 보안·비용·권한 정책 검증 정책엔진-->>IaC파이프라인: 승인 또는 차단 IaC파이프라인->>클라우드: 검증된 변경 적용 클라우드-->>IaC파이프라인: 실제 상태 반환 IaC파이프라인-->>개발자: 변경 결과와 감사 기록 제공 ``` ## 오픈토푸와 풀루미가 테라폼의 빈틈을 파고든다 - 오픈토푸는 “테라폼 호환 오픈소스 대안”에서 꽤 빠르게 엔터프라이즈 선택지로 올라옴 - 2023년 9월 BSL 발표 한 달 만에 포크됐고, 2025년 4월에는 클라우드 네이티브 컴퓨팅 재단(CNCF) 샌드박스에 합류함 - 레지스트리 사용량이 전년 대비 300% 이상 성장했고, 오라클과 VM웨어 같은 대형 벤더도 전환을 선언함 - 피델리티는 5만 개 이상의 상태 파일과 400만 개 이상의 리소스를 테라폼에서 오픈토푸로 옮긴 사례를 공개함 - 오픈토푸의 기술적 차별점은 보안 쪽에서 꽤 선명함 - 테라폼 상태 파일에는 데이터베이스 비밀번호나 API 키 같은 민감 정보가 평문으로 들어갈 수 있음 - 오픈토푸는 상태 파일 암호화를 도입해 AWS KMS, GCP KMS, 오픈바오 등을 이용한 AES-GCM 암호화를 지원함 - 최신 버전에서는 에페메럴 리소스(Ephemeral Resources)로 임시 토큰 같은 민감 정보가 애초에 상태 파일에 저장되지 않도록 설계함 - 풀루미는 “왜 인프라를 전용 언어로만 써야 하냐”는 질문에서 출발함 - 파이썬, 타입스크립트 같은 범용 언어로 인프라를 정의하니 조건문, 반복문, 함수, 테스트 프레임워크를 그대로 쓸 수 있음 - 2026년 1분기부터는 테라폼 HCL도 퍼스트클래스 언어로 지원하고, 풀루미 클라우드에서 테라폼·오픈토푸 상태 파일을 직접 관리하는 방향으로 감 - 기존 테라폼 투자를 버리라는 게 아니라, 하이브리드 환경에서 점진적으로 풀루미의 장점을 가져가라는 메시지임 - 풀루미 네오는 생산성 수치를 세게 밀고 있음 - 미국 물류 기업 워너 엔터프라이즈는 네오 도입 후 인프라 프로비저닝 시간이 3일에서 4시간으로 줄었다고 함 - 베타 고객들은 기존 팀 규모로 10배의 인프라 딜리버리, 정책 위반 90% 감소를 보고했다고 풀루미가 밝힘 - 다만 이 수치는 벤더 발표 기준이라, 독립 검증 전까지는 “가능성은 크지만 숫자는 조심해서 보자” 쪽이 맞음 ## 크로스플레인은 아예 실행 모델이 다르다 - 테라폼·오픈토푸·풀루미가 `실행 후 종료` 모델이라면, 크로스플레인은 쿠버네티스식 상시 조정 모델임 - `terraform apply`나 `pulumi up`은 사람이든 CI든 명령을 실행해야 실제 상태를 비교하고 바꿈 - 크로스플레인은 인프라를 쿠버네티스 리소스로 선언하면 컨트롤러가 계속 실제 상태를 감시함 - 누군가 AWS 콘솔에서 수동으로 리소스를 바꾸면, 컨트롤러가 이를 감지해 수 초에서 수 분 안에 선언된 상태로 되돌릴 수 있음 - 이 방식은 플랫폼 엔지니어링과 궁합이 좋음 - 플랫폼 팀이 `Environment`, `Application`, `DatabaseService` 같은 조직 맞춤 API를 만들 수 있음 - 개발자는 VPC, 서브넷, 보안 그룹 세부 구현을 몰라도 API 호출만으로 필요한 리소스를 받을 수 있음 - “인프라 티켓을 끊는 문화”를 “내부 API를 호출하는 문화”로 바꾸는 지렛대가 됨 - 성숙도 신호도 꽤 강함 - 크로스플레인은 2025년 11월 CNCF 졸업 지위를 얻음 - 커뮤니티는 3,000명 이상의 기여자와 450개 이상의 참여 기업을 보유함 - 나이키, NASA 사이언스 클라우드, SAP 등이 프로덕션 사용자로 언급되고, 업바운드는 누적 1,000개 이상 조직과 1억 회 이상 다운로드를 주장함 - 대신 진입 장벽은 확실히 높음 - 커스텀 리소스 정의(CRD), 컨트롤러, 리콘실리에이션 루프, 역할 기반 접근 제어(RBAC)를 이해해야 함 - 쿠버네티스를 이미 깊게 쓰는 조직이 아니면 도입 자체가 꽤 부담스러움 - 현실적으로는 테라폼을 완전히 대체하기보다, 테라폼으로 기반 인프라를 관리하고 크로스플레인으로 개발자 셀프서비스를 제공하는 조합이 많음 ## 스페이스리프트와 앤서블은 다른 레이어를 잡는다 - 스페이스리프트는 IaC 엔진이 아니라 여러 엔진을 통제하는 오케스트레이션 레이어에 가까움 - 테라폼, 오픈토푸, 풀루미, 클라우드포메이션, 앤서블을 단일 플랫폼에서 관리하는 포지션임 - 레거시는 테라폼, 신규는 오픈토푸, 일부 팀은 풀루미를 쓰는 조직에서는 통합 정책·드리프트 감지·감사 로그가 필요해짐 - 2025년 7월 시리즈 C로 5,100만 달러를 유치한 것도 이 레이어의 수요를 보여줌 - 스페이스리프트 인텐트는 자연어 배포를 지원하지만, 프로덕션의 기준점은 여전히 IaC 코드임 - 예를 들어 “특정 리전에 PostgreSQL RDS를 만들어줘” 같은 요청을 자연어로 처리할 수 있음 - 하지만 스페이스리프트는 이를 프로토타이핑과 실험용 빠른 경로로 보고, 운영 환경에서는 IaC가 시스템 오브 레코드로 남아야 한다고 못 박음 - 이 균형감은 꽤 현실적임. AI로 빨리 만들되, 운영 책임은 코드와 정책으로 남기는 방식임 - 앤서블은 Day 1-2 운영 자동화 쪽의 핵심 도구로 다시 중요해지고 있음 - 테라폼이 “무엇을 만들 것인가”라면 앤서블은 “만든 뒤 어떻게 설정하고 운영할 것인가”에 답함 - 에이전트리스 구조라 SSH나 WinRM으로 VM, 베어메탈, 네트워크 장비, 스토리지까지 폭넓게 다룰 수 있음 - IBM 산하에서 테라폼은 프로비저닝, 앤서블은 구성 관리와 운영 자동화를 맡는 분업 구도가 강화되고 있음 - 레드햇은 앤서블을 에이전틱 AI의 가드레일로 포지셔닝하고 있음 - 앤서블 라이트스피드는 자연어로 플레이북을 생성하는 AI 어시스턴트임 - 레드햇 AI, 오픈AI, 애저 오픈AI 모델을 지원하고, 왓슨엑스와 제미나이는 로드맵에 있음 - 앤서블 오토메이션 플랫폼의 MCP 서버는 실행 환경 안에서 필요한 순간만 뜨는 단명 컨테이너로 설계돼 공격 표면을 줄이려 함 > [!WARNING] > AI 에이전트가 프로덕션 인프라에 직접 손대는 구조는 위험함. 최소한 정책 검증, 권한 제한, 감사 로그, 롤백 경로, 킬 스위치가 먼저 있어야 함. ## 한국 조직도 이 판을 남 얘기로 보기 어렵다 - 국내 공공 클라우드 제도 변화는 IaC 수요를 더 키울 가능성이 큼 - 2026년 상반기부터 클라우드 보안인증제(CSAP)와 국가망보안체계(N2SF) 정합성을 맞추는 제도 개선이 추진될 전망임 - 공공 시스템과 레거시 인프라를 클라우드로 이식하고 관리해야 하는 수요가 늘면, IaC는 선택지가 아니라 운영 기본기가 됨 - 공공·금융은 라이선스와 감사, 보안 정책에 민감하니 테라폼 BSL 리스크도 그대로 따라옴 - 네이버클라우드가 테라폼 프로바이더와 활용 가이드를 적극 지원하는 것도 의미가 있음 - 한국 시장에서도 테라폼이 사실상 표준으로 자리 잡았다는 신호임 - 동시에 테라폼에 깊게 의존한 조직일수록 라이선스 변경, 가격 인상, 벤더 포트폴리오 통합의 영향을 더 크게 받음 - 지금 필요한 건 “테라폼 계속 쓸까?”가 아니라 “전환 시나리오와 거버넌스 설계를 갖고 있나?”에 가까움 - CIO·CTO가 봐야 할 질문은 결국 두 개임 - 우리 인프라 코드의 소유권은 누구에게 있는가 - AI가 인프라 코드를 쓸 때, 누가 그 코드를 검증하는가 - 이 답이 없으면 도구를 아무리 잘 골라도 다음 라이선스 변경이나 AI 자동화 사고 앞에서 주도권을 잃기 쉬움 --- ## 기술 맥락 - IaC 도구 선택은 문법 취향 문제가 아니에요. 테라폼을 쓰면 넓은 프로바이더 생태계와 인력 풀을 얻지만, BSL 이후에는 라이선스와 벤더 전략까지 같이 떠안게 되거든요. 그래서 기존 투자가 큰 조직은 테라폼을 유지하되, 신규 영역에서 오픈토푸를 시험하는 식의 듀얼 엔진 전략이 현실적이에요. - 오픈토푸가 흥미로운 이유는 단순히 “공짜 테라폼”이라서가 아니에요. 상태 파일 암호화와 에페메럴 리소스처럼 민감 정보가 상태에 남는 문제를 직접 건드리고 있어서, 규제가 강한 조직에서는 기술적 명분도 생겨요. 특히 상태 파일이 수만 개 단위로 쌓인 조직은 이 차이가 꽤 크게 느껴질 수 있어요. - 크로스플레인은 같은 IaC라도 운영 철학이 달라요. 테라폼 계열은 사람이 실행하는 시점에 상태를 맞추지만, 크로스플레인은 쿠버네티스 컨트롤러가 계속 실제 상태를 관찰하고 되돌려요. 그래서 드리프트를 빠르게 잡아야 하는 플랫폼 팀에는 매력적이지만, 쿠버네티스 이해도가 낮은 조직에는 학습 비용이 먼저 와요. - AI 에이전트가 들어오면 IaC가 줄어드는 게 아니라 검증할 코드가 더 늘어나요. 자연어로 인프라를 만들 수 있어도, 그 결과가 보안 정책을 어기거나 비용 폭탄을 만들면 운영 책임은 조직에 남거든요. 그래서 정책 코드, 권한 제한, 감사 로그가 AI 도입보다 먼저 설계돼야 해요. - 한국 조직은 공공 클라우드 제도 변화와 국내 CSP의 테라폼 지원 때문에 이 흐름을 더 가까이 보게 될 가능성이 커요. 특히 공공·금융처럼 감사와 규정 준수가 중요한 곳은 도구 기능뿐 아니라 라이선스, 상태 소유권, 시크릿 흐름까지 같이 봐야 해요. ## 핵심 포인트 - 테라폼의 BSL 전환 이후 IaC 생태계는 테라폼, 오픈토푸, 풀루미 중심의 다중 엔진 구조로 재편됨 - AI 에이전트는 클라우드 API를 직접 호출하기보다 IaC를 검증 계층으로 더 많이 활용하는 방향으로 가고 있음 - 오픈토푸는 상태 파일 암호화와 에페메럴 리소스로 테라폼과 기술적으로 차별화 중 - 크로스플레인은 쿠버네티스식 리콘실리에이션으로 드리프트를 지속적으로 자동 복구하는 다른 모델을 제시 - 국내 공공 클라우드 제도 변화와 네이버클라우드 테라폼 지원 때문에 한국 조직도 IaC 라이선스와 거버넌스를 전략 이슈로 봐야 함 ## 인사이트 이 글의 핵심은 도구 비교표가 아니라 ‘인프라 코드의 소유권’과 ‘AI가 만든 인프라 변경을 누가 검증하느냐’라는 질문임. 개발팀 입장에선 테라폼을 계속 쓸지 말지만 볼 게 아니라, 상태 파일·정책·권한·시크릿·감사 로그를 어느 레이어에서 통제할지부터 정해야 한다.