Terraform 도입 시 겪는 초기 혼란과 구조화 전략
1. 문제 상황: Terraform 도입 초기의 혼란
인프라를 코드로 관리하기 위해 Terraform을 도입했지만, 예상과 달리 초기 단계에서 많은 혼란이 발생했다. 처음에는 다음과 같은 문제들이 이어졌다.
- 코드가 점점 복잡해지면서 유지보수가 어려워짐
- state 파일 관리에 대한 개념 부족으로 팀원 간 충돌 발생
- 모듈화에 대한 기준이 없어 디렉토리 구조가 중구난방
- 작은 수정에도 전체 리소스가 재생성될 우려
Terraform은 선언형 방식이므로 코드에 의한 변경 사항이 곧 인프라에 적용된다. 이 점이 초기엔 부담으로 다가왔고, 적절한 전략이 없으면 생산성보다 리스크가 더 컸다.
2. 해결 과정: 구조화와 모듈화 전략 수립
2.1 폴더 구조 정립
먼저 리소스 규모가 커질 것을 고려해 폴더 구조를 다음과 같이 정리했다.
/terraform
/modules
/network
/compute
/storage
/environments
/dev
/staging
/prod
공통적으로 사용하는 리소스는 modules 폴더에 모듈화하고, 실제 환경별로 environments에 각각 구성되도록 나눴다.
2.2 백엔드 스토리지 도입
Terraform의 상태 파일은 인프라의 상태를 담고 있으므로 버전 관리와 잠금(locking)이 필요하다. 이를 위해 다음과 같은 구성을 적용했다.
- AWS S3를 백엔드 스토리지로 설정
- DynamoDB를 이용한 상태 잠금(lock) 처리
terraform {
backend "s3" {
bucket = "my-terraform-states"
key = "prod/terraform.tfstate"
region = "ap-northeast-2"
dynamodb_table = "terraform-locks"
encrypt = true
}
}
2.3 모듈화 기준 수립
모듈을 만들 때에는 다음 기준을 적용했다.
- 하나의 모듈은 단일 책임을 가진 리소스로 제한
- 입력 변수(input variable)를 명확히 정의
- 출력 변수(output)를 통해 상호 연동 구조 확보
예를 들어, VPC 모듈은 오직 네트워크 리소스만을 다루고, 컴퓨트 리소스는 별도 모듈로 분리하였다.
3. 팀 협업을 위한 전략
3.1 Code Review 프로세스 도입
Terraform 코드 역시 애플리케이션 코드처럼 코드 리뷰를 필수로 적용했다. terraform plan 결과를 함께 공유하고 변경 범위를 명확히 이해한 후에만 apply를 진행했다.
3.2 tfsec과 같은 정적 분석 도구 활용
보안 정책을 자동화하기 위해 tfsec을 적용했다. 이 도구를 통해 S3 버킷의 퍼블릭 액세스나 RDS의 암호화 여부 등을 자동으로 검사할 수 있었다.
tfsec .
4. 배운 점과 정리
Terraform은 강력한 도구이지만, 초기에 구조화 없이 사용하면 오히려 리스크를 키울 수 있다. 따라서 다음과 같은 전략이 필요하다.
- 폴더 구조와 모듈화 기준을 사전에 정리
- State 파일의 백엔드 구성은 초기에 반드시 적용
- 팀 단위에서는 리뷰, 정적 분석, 린한 모듈화가 핵심
이러한 구조화를 통해 Terraform을 안정적으로 운용할 수 있으며, 점차 IaC(인프라스트럭처 코드)의 진정한 효과를 경험할 수 있었다.