Infrastructure-as-Code는 잘못된 추상화임

IaC의 문제: 복잡성을 코드로 옮겼을 뿐

Defang의 Lio가 쓴 글. 2000년대 초반에는 VPS에 SSH로 접속해서 scp로 코드 올리고 screen 세션에서 서버 돌리면 끝이었음. 클라우드 시대가 오면서 클러스터, 데이터베이스, 로드밸런서, IAM, VPC 같은 복잡성이 폭발적으로 늘어남.

IaC(Terraform 등)는 이 복잡성을 제거한 게 아니라 대시보드 클릭 수백 번을 수천 줄의 클라우드 종속 코드로 바꿔놓은 것뿐임. 저자 표현으로는 "어셈블리 언어를 작성하는 것과 같음."

Docker Compose를 추상화 레이어로

• 대부분의 팀이 로컬 개발에 이미 Docker Compose를 쓰고 있으니, 이걸 클라우드 배포의 입력 포맷으로 쓰자는 제안임
• 핵심은 VM 위에서 docker compose up을 실행하는 게 아니고, K8s도 아님. 클라우드 네이티브 프리미티브(컨테이너, 관리형 DB, 로드밸런서, VPC, DNS, 시크릿)를 직접 프로비저닝함
• postgres/redis 같은 스테이트풀 이미지는 RDS/CloudSQL, ElastiCache/Memorystore 같은 관리형 서비스로 자동 매핑됨. 백업과 HA가 앱 변경 없이 따라옴
• Compose 스펙이 최근 AI 모델 의존성 선언도 지원하기 시작함 → Bedrock/VertexAI로 매핑 가능

Defang의 구현 방식

• Defang CLI가 diff를 계산하고, 컨테이너 이미지를 빌드하고, 사용자의 AWS/GCP/DigitalOcean 계정에 직접 배포함
• 내부적으로 Pulumi(오픈소스)를 사용함. 사용자 클라우드 계정 안에서 단기 실행 컨테이너가 Pulumi를 돌림
• 배포 후에는 앱과 인프라만 남음. 컨트롤 플레인 없음, 크로스 계정 접근 없음, 상주 러너 없음
• 배포 모드 3가지: affordable, balanced, HA. 같은 입력이면 같은 플랜이 나옴
• LLM은 빌드/런타임 실패 해석에 활용됨. 수천 줄 로그를 실행 가능한 피드백으로 변환

왜 이게 필요한가

Joel Spolsky의 "모든 비자명한 추상화는 새어나간다"를 인정하면서도, 목표는 클라우드를 숨기는 게 아니라 앱을 한 번 정의하고 어떤 클라우드든 매핑할 수 있게 하는 것임. 기존 PaaS와 달리 벤더 종속을 피할 수 있음.

엔터프라이즈 고객들이 점점 더 자체 클라우드 계정, 자체 리전, 자체 통제 하에 소프트웨어 배포를 원하는 추세임. LLM에 민감 데이터를 보내는 앱이 늘면서 프라이빗 배포의 중요성이 더 커지고 있음.