ECS와 Terraform의 역할 분리

지난 포스팅(EKS와 Terraform의 역할 분리)에서는 EKS 환경에서 인프라와 애플리케이션의 역할을 분리하는 패턴에 대해 다루었습니다. 그렇다면 AWS의 또 다른 대표 컨테이너 서비스인 ECS(Elastic Container Service)는 어떨까요?

 

ECS는 모든 구성 요소가 AWS API 리소스로 정의되는 '네이티브' 서비스인 만큼, 관리 방식에서 EKS와는 또 다른 유연함을 보여줍니다. 특히 "인프라 구축부터 앱 배포까지 전부 Terraform으로 중앙 통제할 것인가, 아니면 배포 영역만큼은 별도의 CI/CD 도구로 분리할 것인가?"라는 고민은 ECS 운영의 핵심적인 갈림길이 되기도 합니다.

 

조직의 규모와 배포 빈도에 따라 정답은 달라질 수 있습니다. 이번 글에서는 ECS 환경에서 실무적으로 가장 많이 사용되는 두 가지 관리 패턴을 비교해 보고, 우리 팀의 상황에 가장 적합한 아키텍처는 무엇일지 살펴보겠습니다.

---

1. 통합 관리 패턴: All-in-Terraform

인프라(네트워크, 클러스터)부터 애플리케이션(태스크 정의, 서비스)까지 모든 생명주기를 Terraform 코드로 중앙 통제하는 방식입니다.

• 관리 영역: VPC, ALB, IAM, ECS Cluster뿐만 아니라 aws_ecs_task_definition(컨테이너 이미지, CPU/메모리)과 aws_ecs_service(실행할 컨테이너 수)까지 모두 Terraform에 정의합니다.
• 생명주기 (배포 흐름):
  1. 개발자가 애플리케이션 코드를 수정하고 Docker 이미지를 ECR(컨테이너 레지스트리)에 푸시합니다.
  2. Terraform 코드(보통 variables.tf의 이미지 태그 값)를 새로운 이미지 버전으로 업데이트합니다.
  3. terraform apply를 실행합니다.
  4. Terraform이 ECS에 새로운 태스크 정의를 등록하고 서비스를 업데이트하여 롤링 배포를 진행합니다.
• 장점: 모든 설정이 Terraform 코드(SSOT, 단일 진실 공급원)에 있어 전체 시스템의 상태를 파악하고 복원하기가 매우 쉽습니다.
• 단점: 단순한 애플리케이션 코드 수정 후 배포할 때도 무거운 인프라 검증(terraform plan/apply) 과정을 거쳐야 하므로 배포 속도가 느려집니다.

 

2. 역할 분리 패턴: 인프라(Terraform) + 배포(CI/CD)

Terraform은 클러스터와 빈 껍데기만 만들고, 실제 애플리케이션 배포와 업데이트는 Jenkins, GitHub Actions 등의 CI/CD 도구가 AWS API를 직접 호출하여 처리하는 방식입니다. 규모 있는 기업에서 가장 선호하는 표준적인 접근법입니다.

• 관리 영역:
  • Terraform: VPC, ALB, IAM, ECS Cluster를 생성합니다. 그리고 최초의 깡통 aws_ecs_task_definition과 aws_ecs_service를 만듭니다.
  • CI/CD (배포 도구): 컨테이너 이미지를 빌드하고, 새로운 태스크 정의를 생성한 뒤 ECS 서비스를 업데이트합니다.
• 생명주기 (배포 흐름):
  1. 인프라 변경은 기존대로 terraform apply를 통해 이루어집니다.
  2. 애플리케이션 배포 시, CI/CD 파이프라인이 새 이미지를 빌드하고 aws ecs update-service 같은 AWS CLI/SDK 명령을 직접 실행하여 배포합니다. 이 과정에서 Terraform은 전혀 개입하지 않습니다.
• 핵심 기술 (Drift 방지): 
  • 이 패턴을 사용할 때는 CI/CD가 변경한 값을 Terraform이 덮어쓰지 않도록, Terraform 코드 내에 
    lifecycle { ignore_changes = [task_definition, desired_count] }
    블록을 반드시 선언해야 합니다.
• 장점: 인프라 팀과 개발 팀의 역할이 완벽히 분리되며, 애플리케이션 배포 속도가 비약적으로 빠릅니다.
• 단점: Terraform 코드만 봐서는 현재 어떤 버전의 애플리케이션 이미지가 서비스에 떠 있는지 알 수 없습니다.

 

패턴 비교 요약

비교 항목	통합 관리 패턴 (All-in-Terraform)	역할 분리 패턴 (Terraform + CI/CD)
적합한 조직	스타트업, 소규모 팀, 단일 목적의 프로젝트	중대형 기업, 마이크로서비스 아키텍처(MSA)
배포 빈도	하루 수 회 미만 (가끔 배포)	하루 수십 회 이상 (빈번한 배포)
상태 관리	Terraform이 100% 관리	인프라는 Terraform, 앱 상태는 AWS 자체에 위임
구축 난이도	낮음 (단일 도구 사용)	중간 (ignore_changes 등 상태 충돌 관리 필요)