terraform plan은 수행할 작업에 대해 정직합니다. 문제는 이 출력이 매우 장황하고, 반복적이며, 실제 변경 사항(예: -/+ replace가 예정된 데이터베이스 인스턴스)과 섞여 있는 미미한 변경 사항(예: 재계산된 태그)으로 가득 차 있다는 점입니다. 400줄에 달하는 플랜(plan) 속에서 위험한 변경 사항은 숨겨지게 됩니다.

이것은 AI가 실제로 잘하는 종류의 작업입니다. 구조화된 텍스트를 훑어보고, 중요한 항목을 표시하며, 나머지는 무시하는 것이죠. 하지만 단순히 "Claude에 플랜을 붙여넣기" 하는 것은 올바른 워크플로우(workflow)가 아닙니다. 효과적으로 작동하는 특정한 방식이 있습니다.

사람들이 실수하는 이유

자연스러운 본능은 플랜 출력 내용을 복사하여 채팅창에 붙여넣는 것입니다:

Terraform will perform the following actions:

  # aws_instance.web will be updated in-place
...

모델은 각 줄에 대해 문장으로 응답할 것입니다. 당신은 스크롤을 내리고, 훑어보게 될 것입니다. 그러다 30개의 일상적인 업데이트 중간에 섞여 있는 데이터베이스의 -/+ replace를 놓치게 될 것입니다.

이는 로그 뭉치를 붙여넣고 "뭐 잘못된 거 있어?"라고 묻는 것과 동일한 실패 방식입니다. 모델은 너무 공손해서 내용을 건너뛰지 못합니다. 당신은 모델에게 건너뛰라고 말해야 합니다.

실제로 작동하는 형식: JSON

terraform show -json tfplan은 텍스트 형식보다 추론하기 훨씬 쉬운 플랜의 구조화된 표현을 출력합니다. 두 가지 이유가 있습니다:

1. "actions" 필드가 명시적입니다. 각 resource_change에는 change.actions 배열이 있습니다 — ["create"], ["delete"], ["update"], 또는 교체(replace)를 위한 ["delete", "create"]가 포함됩니다. 모호함이 없습니다.
2. 붙여넣기 전에 필터링할 수 있습니다. jq를 사용하면 위험한 변경 사항만 추출하고 노이즈를 제거하여, 400줄짜리 플랜 대신 20줄 정도의 요약본을 AI에 입력할 수 있습니다.

이렇게 시도해 보세요:

terraform plan -out=tfplan
terraform show -json tfplan > plan.json

...

이것이 AI의 입력값이 됩니다. 압축되어 있고, 모호하지 않으며, 인간의 결정이 필요한 변경 사항으로 사전 필터링되어 있습니다.

플랜이 숨기는 것을 잡아내는 프롬프트

위험한 변경 사항(dangerous-changes)이 담긴 JSON을 확보했다면, 프롬프트는 간단합니다:

여기 delete(삭제) 및 replace(교체) 작업만 보여주는 Terraform 플랜 요약이 있습니다. 각 리소스에 대해 다음을 알려주세요: (1) 어떤 데이터가 위험에 처해 있는지 (없음 / 상태(state)는 유지되나 데이터는 유실 / 데이터 + 상태 모두 유실), (2) 해당되는 경우 무엇이 교체를 유발했는지 (새로운 리소스를 강제하는 필드에 대해 change.before와 change.after를 비교할 것), (3) 권장 조치 — 진행(proceed), 먼저 스냅샷 생성(snapshot first), 또는 차단(block).

이제 모델은 발견된 항목당 세 가지 명확한 출력을 생성하는 지시된 작업(directed task)을 갖게 되었습니다. 응답은 훑어보기 쉽고(scannable), 실행 가능하며(actionable), 짧습니다.

비교를 위해, 동일한 프롬프트를 가공되지 않은 텍스트 플랜(raw text plan)에 적용하면 갈팡질팡하는 에세이 같은 결과가 나옵니다.

실제 예시

다음은 최근 변경 사항에서 발췌한 (민감 정보가 삭제된) 플랜 요약입니다:

[
  {
    "address": "aws_instance.bastion",
...

이에 대한 Claude의 검토 내용(의역):

1. aws_instance.bastion — 교체(Replace)는 괜찮습니다. 배스천(bastion) 호스트에는 영구 데이터가 없습니다. 점프 호스트(jump-host) 접속이 잠시 중단됩니다 (~2분). 진행하십시오.
2. aws_db_instance.main — 위험(DANGEROUS). 데이터베이스 교체는 skip_final_snapshot = false이고 스냅샷이 생성될 것임을 확인하지 않는 한 데이터 유실을 의미합니다. 플랜 JSON의 change.after에서 skip_final_snapshot을 확인하십시오. 만약 true라면, 차단(BLOCK)하십시오. 만약 false라면, 스냅샷이 데이터를 저장하겠지만 복구는 수동 작업입니다. 무엇보다 먼저 수동 스냅샷을 생성할 것을 권장합니다.
3. aws_s3_bucket.logs-old — 삭제(Delete). 버킷에 객체가 있다면 기본적으로 실패합니다. 만약 force_destroy = true라면, 모든 객체가 버킷과 함께 삭제됩니다. 버킷이 현재 활발히 사용 중인지 확인하십시오.

이것이 바로 제가 적용(apply)하기 전에 원하는 형태의 검토입니다. AI가 없었다면 데이터베이스 교체는 잡아냈겠지만, 서두르다가 S3 버킷의 force_destroy 뉘앙스를 놓쳤을지도 모릅니다.

Sentinel / OPA / Checkov는 어떤가요?

이 도구들은 _정책(policies)_을 강제합니다 — 예:

저는 두 가지를 모두 사용합니다. CI(지속적 통합)에서의 Checkov는 일관된 규칙 위반을 잡아냅니다. Plan(계획)에 대한 AI 리뷰는 문맥적인 위반 사항, 즉 기술적으로는 교체(replace)가 허용되지만 운영상 위험한 사례들을 잡아냅니다.

CI 통합

이 워크플로우가 검증되면 자동화할 수 있습니다. 간단한 GitLab CI 작업은 다음과 같습니다:

plan-review:
  stage: review
  needs: [plan]
...

두 단락의 YAML 코드만으로는 완전히 프로덕션 환경에 적용할 수준은 아니지만, 패턴은 다음과 같습니다: 위험한 변경 사항을 감지하고, 이를 문맥적 리뷰를 위해 AI로 보내고, 결과물을 사람이 검토할 수 있는 곳에 게시하는 것입니다.

핵심은 AI 리뷰를 '기억해서 해야 하는 일'이 아니라 워크플로우의 일부로 만드는 것입니다. 400줄짜리 Plan에서 교체(replace) 사항을 놓칠 정도로 지쳤을 때, AI에게 그것에 대해 물어봐야 한다는 사실조차 기억하지 못할 것이기 때문입니다.

AI가 Plan에 대해 알려줄 수 없는 것들

AI는 해당 변경이 의도된(intended) 것인지 알려줄 수 없습니다. 데이터베이스의 교체는 의도적인 것일 수 있습니다(엔진을 마이그레이션하는 경우 등). 이 경우 스냅샷을 먼저 찍으라는 조언은 번거로운 오버헤드가 됩니다. AI는 구조를 보고, 당신은 의도를 봅니다. 이 둘이 결합된 것이 바로 워크플로우입니다.

또한 AI는 변경 사항이 완전한지(complete) 알려줄 수 없습니다. 때로는 Plan이 단독으로는 안전해 보이지만, 당신이 잊어버린 의존성 때문에 다운스트림(downstream)의 무언가를 망가뜨릴 수 있습니다. AI는 당신의 다운스트림 의존성을 알지 못합니다. 당신만이 알고 있습니다.

검토자는 여전히 당신입니다. AI는 주의가 필요한 Plan의 부분들을 빠르게 걸러주는 필터일 뿐입니다.

Terraform 안전성에 관한 전체 프롬프트 세트는 Terraform 카테고리를 참조하세요 — terraform-plan-review-checklist와 terraform-dangerous-changes-review가 포함되어 있습니다.

이 기사는 원래 DevOps AI ToolKit — 클라우드 엔지니어를 위한 실용적인 AI 워크플로우 — 에서 게시되었습니다.