제가 저지른 Terraform 실수, 당신이 겪지 않도록

Source: Dev.to

저는 4 년 동안 Terraform을 전문적으로 작성해 왔으며, 같은 기간 동안 Terraform 실수를 해왔습니다. 아래는 실제로 시간, 돈, 혹은 잠을 빼앗은 실수들과 각각에서 배운 점들입니다.

실수 1: 모든 것을 위한 하나의 거대한 상태 파일

시작했을 때, 모든 것을 하나의 상태 파일에 넣는 것이 우아하게 느껴졌습니다—진실의 단일 소스이며, 이해하기도 간단했습니다.

하지만 단일 모듈에서 실수가 발생하면서 apply 중에 전체 상태 파일을 사용할 수 없게 되었습니다. 두 명의 엔지니어가 동시에 변경을 적용하려다 state‑lock 충돌이 발생했습니다. 상태 파일은 50 MB까지 커졌고, 플랜 실행 시간이 8 분 정도로 늘어났습니다.

지금은 이렇게 합니다

서비스별·환경별로 하나의 상태 파일을 사용합니다. 설정 작업이 약간 추가되지만, 운영상의 안전성은 크게 향상됩니다.

실수 2: 변수에 비밀 정보 저장

I know, obviously bad, but I still did it.

I was moving fast on a new project, needed to pass a database password to the application config, and thought I would fix it later. The password lived in a tfvars file for 8 months, and the file was committed to Git for 3 months before I noticed.

지금은 이렇게 합니다

비밀은 AWS Secrets Manager 또는 Parameter Store에 저장합니다. Terraform은 비밀 값이 아니라 비밀 ARN을 읽습니다.

실수 3: Terraform을 구성 관리에 사용하기

Terraform은 인프라를 프로비저닝합니다; 구성 관리용으로 설계된 것이 아닙니다.

remote-exec와 user_data를 사용하여 EC2 인스턴스에 패키지를 설치하고, 설정 파일을 작성하며, 서비스를 관리하는 Terraform 리소스를 작성했습니다. 누군가 수동으로 변경을 가하면서 서버가 드리프트되기 전까지는 잘 동작했습니다. Terraform은 구성이 올바르다고 판단했지만, 실제 서버는 그렇지 않았습니다.

지금 하는 일

철저한 분리를 유지합니다: Terraform은 프로비저닝을 담당하고; Ansible(또는 다른 CM 도구)은 구성을 담당합니다. 책임을 겹치게 하지 마세요.

실수 4: 폭발 반경 무시

프로젝트 초기에 저는 VPC, 서브넷, 보안 그룹, RDS, ECS 클러스터, 그리고 애플리케이션 서비스를 모두 한 번에 관리하는 루트 레벨 모듈을 가지고 있었습니다.

애플리케이션 서비스 설정에 오타가 생겨 Terraform이 모든 리소스에 대한 종속성을 평가하게 되었습니다. 플랜에는 제가 건드릴 줄 몰랐던 리소스들의 변경 사항이 표시되었습니다. 저는 당황해서 terraform apply -target을 실행했고, 더 많은 드리프트를 일으켰으며, 이를 고치는 데 4 시간을 소비했고, 그 결과 20 분의 불필요한 다운타임이 발생했습니다.

이제 나는 이렇게 합니다

인프라 계층별 별도 모듈을 만들고, 그 사이에 명시적인 인터페이스를 두세요. 애플리케이션 설정의 변경이 실수로 네트워킹 리소스에 영향을 미치지 않도록 합니다.

실수 5: Terraform 상태 마이그레이션을 계획하지 않음

상태 구조가 커지면 terraform state mv 명령을 사용해 리소스를 상태 파일 간에 이동해야 합니다—리소스당 하나씩. 200+ 리소스가 있으면 이는 상당한 프로젝트가 되며, 실수를 하면 리소스가 고아가 되거나 중복될 수 있습니다.

현재 제가 하는 방법

프로젝트가 12 개월 후에 어떤 모습을 가질지에 맞춰 상태 구조를 설계합니다, 오늘만을 위해 설계하지 않습니다. 처음부터 더 세분화된 상태를 사용하는 것이 나중에 거대한 모놀리스를 분할하는 것보다 훨씬 쉽습니다.

실수 6: 수동 워크스페이스 관리

저는 Terraform 워크스페이스를 사용해 스테이징과 프로덕션 환경을 관리했으며, 서로 다른 워크스페이스가 서로 다른 상태이자 환경이라고 가정했습니다.

문제는 잘못된 워크스페이스에서 terraform apply를 실행하는 것을 방지하는 메커니즘이 없다는 것입니다. 저는 한 번 프로덕션이 아닌 스테이징에 적용해야 할 파괴적인 변경을 프로덕션에 적용해, 짧은 서비스 중단을 일으킨 적이 있습니다. 이는 충분히 방지할 수 있었던 일입니다.

현재 제가 하는 방법

환경별로 별도의 디렉터리를 사용합니다. 디렉터리 구조만으로도 현재 작업 중인 환경이 명확히 드러나므로 실수를 크게 줄일 수 있습니다.

모든 사례에서 보이는 패턴

Every mistake I made with Terraform came from optimizing for the short term. A single state file is simpler to set up than many; user data is faster than setting up Ansible; workspaces are less overhead than separate directories.

The short‑term convenience always came with a long‑term cost.

Terraform is a tool for managing infrastructure that will outlast any individual engineer’s involvement. Design for that.

I am building Step2Dev to make the right Terraform practices the default, not the exception. More at .

What Terraform mistake cost you the most? Drop it in the comments.