DevOps팀의 Terraform 모험

서비스와 스테이지·QA 환경이 늘면서 반복 작업과 실수가 잦아지자, 컬리 DevOps팀은 우선 비운영 환경에 Terraform을 도입하고 운영 환경 확장을 염두에 둔 모듈·환경 코드 구조를 설계했다. 태그는 `locals`와 `merge`로 재사용하고, Launch Template의 선택적 EBS 설정은 `dynamic` block과 객체 타입 변수로 표현해 환경 코드의 반복을 줄였다. 처음에는 환경을 생성하는 자동화에 집중했지만, tfstate가 실제 인프라와 코드의 동기화 및 리소스 메타데이터를 관리한다는 점을 놓친 설계를 재검토해 상태 파일을 별도 S3 버킷에서 관리하고 DevOps팀이 코드와 상태를 우선 관리하기로 했다. 적용 과정에서는 리소스 의존성과 순환 참조, 수동 변경 후 코드 동기화, plan 검증 없는 병합이 주요 위험으로 드러났으며, Terraform 도입에는 코드 작성뿐 아니라 상태 관리와 팀의 리뷰·운영 원칙이 함께 필요하다는 교훈을 얻었다.

• Terraform 도입 전에는 반복되는 환경 생성과 운영으로 인한 실수, 관리 복잡도를 구체적인 문제로 정의한다.
• 모듈 코드는 재사용 가능한 리소스 구성을, 환경 코드는 환경별 설정을 담당하도록 역할을 나눈다.
• 반복되는 태그는 `locals`와 `merge`로 묶고, 선택적 중첩 설정은 `dynamic` block과 객체 타입 변수로 표현할 수 있다.
• tfstate는 단순한 결과 파일이 아니라 실제 리소스와 코드의 동기화 및 의존성 정보를 관리하므로 원격 저장소와 접근 정책을 신중히 설계한다.
• `terraform plan` 결과를 코드 리뷰와 배포 전에 확인하고, 리소스 의존성과 수동 변경 후 코드 동기화 방식을 팀에서 합의한다.