Terraform plan과 state drift: 코드와 실제 인프라가 달라질 때 확인할 순서

Terraform 코드가 바뀌지 않았는데 plan에 변경이나 교체가 보이면 실제 클라우드 리소스와 state가 달라진 drift를 의심해야 한다. plan은 실행 전 검토할 기회이지, 자동 승인 신호가 아니다.

plan에서 생성·변경·삭제를 구분한다

리소스 이름만 보고 승인하지 말고 어떤 속성이 바뀌며 교체가 필요한지 확인한다. 특히 삭제 후 재생성은 IP, 데이터, 연결 대상에 영향을 줄 수 있다. 예상하지 않은 대량 변경이면 apply를 멈추고 대상 workspace·변수·provider 컨텍스트부터 확인한다.

terraform plan

예를 들어 코드에서 관리하는 노드 수는 2인데 콘솔에서 같은 리소스를 3으로 바꿨다면, 다음 plan에서 코드의 2로 되돌리는 변경이 제안될 수 있다. 바로 적용해 덮어쓰기 전에 콘솔 변경이 긴급 조치였는지 확인한다. plan 출력과 저장된 계획 파일에는 식별 정보나 민감한 값이 포함될 수 있으므로 외부에 그대로 공유하지 않는다.

state는 팀이 함께 관리하는 운영 데이터다

state 파일에는 리소스 식별 정보가 들어갈 수 있으므로 안전한 원격 저장과 접근 권한, 잠금이 필요하다. 개인 컴퓨터의 state를 서로 덮어쓰면 동시에 실행한 변경이 충돌할 수 있다. state를 직접 편집하거나 지우기보다 Terraform의 관리 절차와 백업을 사용한다.

drift는 숨기지 말고 원인을 결정한다

콘솔에서 긴급 변경을 했다면 코드에 반영할지, 실제 리소스를 코드 상태로 되돌릴지 결정해야 한다. ignore 규칙으로 plan을 조용히 만들기 전에 그 차이가 의도적인지와 보안·비용 영향을 검토한다.

앞의 노드 2개·실제 3개 예시에서 수동 변경이 긴급 대응이라면 코드를 바꾸고 검증할지, 조치가 끝난 뒤 다시 2개로 줄일지 결정해야 한다. 후자를 택하면 서비스 용량이 줄어드는 영향까지 확인한다.

저장한 plan으로 검토 대상과 적용 대상을 맞춘다

검토한 뒤 다시 만든 plan은 그사이의 코드·변수·실제 상태 변화 때문에 내용이 달라질 수 있다. 승인 절차가 필요한 변경이라면 계획을 파일로 저장하고 사람이 읽을 수 있는 출력으로 검토한 뒤, 승인한 파일을 적용하는 흐름을 고려한다.

terraform plan -out=review.tfplan
terraform show review.tfplan
terraform state list

첫 명령은 현재 구성을 기준으로 계획 파일을 만들고, 둘째는 예정 변경을 읽으며, 셋째는 state가 추적하는 리소스 목록을 확인한다. 계획에 삭제·교체가 있으면 영향 대상을 하나씩 검토하고 예상 밖의 대량 변경이면 적용하지 않는다. 계획 파일과 state에는 식별 정보나 민감한 값이 들어갈 수 있으므로 저장 위치와 접근 권한을 제한하고 공개 게시물이나 채팅에 그대로 붙이지 않는다.

핵심 요약

Terraform plan은 코드와 실제 인프라의 차이를 보여 주는 검토 단계다. 생성·변경·삭제·교체를 구분하고, state는 잠금과 최소 권한이 있는 공유 운영 데이터로 다루자. drift는 무시하지 말고 코드와 현실 중 어느 쪽을 기준으로 할지 명시적으로 결정해야 한다.