원문 캡처 · masterpoint.io
원문 캡처 · masterpoint.io

Terraform, OpenTofu, Pulumi의 계획 결과를 요청한 변경 사항과 대조하고 오류를 고치도록 AI 에이전트에 맡기는 검증·수정 절차를 소개한다. 인프라 변경을 자동으로 적용하게 하는 방식이 아니라, 계획 검토를 돕되 운영 환경 적용은 막고 사람이 최종 검토하도록 하는 접근이다.

인프라 코드(IaC)는 작은 변경도 데이터베이스를 교체하거나 애플리케이션의 접근을 차단할 수 있다. CI/CD가 계획 결과를 풀 리퀘스트에 올리더라도, 사람이 예상 밖의 변경이나 오류를 발견해 에이전트에 전달하고 다시 결과를 기다리는 일이 반복될 수 있다. 검증·수정 루프에서는 에이전트가 계획 결과를 읽고 요구 사항과 비교해 코드를 고친 뒤 다시 확인한다.

앤스로픽의 Claude Code 문서는 에이전트가 작업을 마쳤다고 판단해도 실행 가능한 검사가 없으면 실수가 발견될 때까지 사람이 검증 절차를 맡게 된다고 설명한다. 앤스로픽은 에이전트가 변경 사항을 시험하고 피드백을 살펴 수정할 수 있도록 통과·실패 결과를 제공할 것을 권한다.

계획 결과로 확인할 수 있는 변경

이 방식은 의도한 결과와 실행 가능한 검사가 분명한 IaC 작업에 적용할 수 있다. 예를 들어 기존 인프라를 가져오거나 모듈을 리팩터링할 때 계획 결과에 예상 밖의 변경이 있는지 확인하고, 목표와 일치할 때까지 수정할 수 있다.

기존에 직접 만든 AWS 애플리케이션 로드 밸런서(ALB)를 Terraform으로 가져오는 사례에서는, 기존 작동 방식은 유지하고 ManagedBy 태그만 추가하는 것을 허용된 변경으로 정한다. 첫 계획에서 대상 그룹 이름이 실제 이름과 달라 교체가 제안되면 에이전트가 이름을 고친다. 다음 계획에서 코드가 기본값을 사용해 ALB의 idle_timeout 변경이 제안되면 기존 값으로 맞춘다. 최종 계획에는 예상한 가져오기 7건과 합의된 태그 변경만 남고, 생성되거나 삭제되는 리소스는 없어야 한다.

Terraform 모듈 리팩터링 사례에서는 보안 그룹 14개를 루트 모듈에서 공용 하위 모듈로 옮긴다. moved 블록으로 기존 상태 주소를 새 주소에 대응시키며, 주소가 잘못돼 일부 보안 그룹을 다시 만들 계획이 나오면 에이전트가 매핑을 고친다. 다음 계획에서 기존 태그가 제거될 것으로 나타나면 모듈에서 해당 태그를 유지한다. 최종 계획은 14개 주소 이동을 보여 주고 실제 리소스 변경은 없어야 한다.

계획만으로 실제 동작까지 입증할 수는 없다. 예를 들어 보안 그룹 규칙이 계획에 있어도 애플리케이션이 데이터베이스에 연결되지 않을 수 있다. 이런 동작을 확인하려면 별도의 샌드박스 계정에 적용한 뒤 애플리케이션 환경에서 검사해야 한다. ECS 작업이 RDS 연결 시간 초과를 겪는 상황에서는 VPC Reachability Analyzer로 관련 네트워크 인터페이스 사이의 TCP 포트 5432 경로를 분석할 수 있다. 분석 상태가 succeeded가 되면 NetworkPathFound와 Explanations를 확인한다. 보안 그룹이 차단 원인으로 표시되면 에이전트가 HCL을 수정하고, 허용된 변경 범위 안에서 샌드박스에 적용한 뒤 분석을 다시 실행할 수 있다.

저장소에 둘 지침과 안전장치

먼저 형식 검사, 유효성 검사, 린트, 보안 검사를 실행해야 한다. 설정 방법은 Terraform·OpenTofu CI 체크리스트에서 다룬다. 계획이 완성돼도 요청 범위를 벗어난 변경이 포함될 수 있으므로, 에이전트는 바뀌어야 할 것과 그대로 남아야 할 것을 모두 완료 기준과 대조해야 한다.

조직에서 허용한다면 에이전트가 Terraform·OpenTofu 계획이나 Pulumi 미리보기를 직접 읽을 수 있다. 계획을 승인된 CI/CD 시스템이나 Spacelift, HCP Terraform(이전 Terraform Cloud), Atlantis 같은 인프라 자동화 플랫폼에서만 실행해야 하는 조직도 있다. 이 경우 에이전트는 변경 사항을 올리고 실행이 끝날 때까지 기다린 뒤, 사용 가능한 MCP 연동, API 또는 CLI로 결과를 가져온다. Spacelift MCP는 제안된 실행과 로그를 읽는 방법 중 하나다. 계획은 텍스트 또는 JSON 표현으로 읽을 수 있다.

반복 작업은 저장소의 CLAUDE.md나 AGENTS.md 같은 지침 파일과 에이전트 스킬에 나눠 둘 수 있다. 원문의 Spacelift 예시 지침은 다음과 같다.

--- name: tf-verify-spacelift description: Verify Terraform/OpenTofu changes in this repo through Spacelift. --- Define the intended outcome, what must stay unchanged, and the checks that will confirm success. If any of these are unclear, ask the user before proceeding. After each push, use the Spacelift MCP to find the proposed run for the correct stack and latest commit. Wait for the plan, read its output, and compare it with the agreed result. Fix the underlying cause of errors or unexpected differences without skipping checks or hiding changes, then push again. Keep using the Spacelift MCP to check each new run until the plan matches the agreed result. Keep the acceptance criteria unchanged. Stop and ask for help if the same error or unintended plan output remains after five attempts, or if you are blocked by something that requires human input. Explain the blocker, what you have tried, and link the relevant runs. When the plan matches the agreed result, return the run URL, commit, a short comparison of expected and actual changes, and anything the plan cannot prove. Never trigger, confirm, or discard runs; never apply; never modify state directly; never merge; never widen access; never add ignore_changes to make the plan pass.

GitHub Actions를 쓴다면 Spacelift 지침을 gh로 해당 워크플로 실행 결과를 읽는 방식으로 바꾸고, 워크플로와 브랜치 보호 설정은 수정하지 못하도록 해야 한다. HCP Terraform, Atlantis 등에서도 결과를 가져오는 방법을 해당 플랫폼에 맞춰야 한다. 일회성 프롬프트에도 완료 기준과 검증 방법, 최소 권한을 명시할 수 있다. Stop 훅을 이용해 작업 완료 전에 검증 스크립트를 요구하는 방법도 있다.

이 루프에는 측정 가능한 완료 기준, 에이전트가 읽을 수 있는 실행 결과와 로그, 운영 환경 적용을 막는 권한·안전장치, 명확한 인계 절차가 필요하다. 예를 들어 모듈 리팩터링의 기준은 클라우드 리소스 변경 0건과 예상한 주소 이동 14건일 수 있다. 연결 문제라면 보안 그룹 규칙 추가와 애플리케이션에서 확인한 데이터베이스 쿼리 성공 등을 기준으로 삼을 수 있다. 기존 인프라를 가져올 때는 명시적으로 합의한 태그 변경 등을 제외하고 기존 AWS 리소스를 바꾸지 않는 것이 기준이 될 수 있다.

같은 오류나 예상 밖의 계획 결과가 다섯 번의 시도 뒤에도 반복되면 중단하고 사람에게 도움을 요청하도록 한다. 문제를 해결하는 대신 ignore_changes를 추가하면 Terraform이 지정된 속성을 더는 조정하지 않아 계획에서 변경이 사라질 수 있으므로, 이를 통과 수단으로 쓰지 못하게 해야 한다. 예시에서는 에이전트가 풀 리퀘스트를 열고 Spacelift MCP로 실행 결과와 AWS 정보를 읽을 수 있지만, 적용은 샌드박스 계정에서만 할 수 있도록 권한을 제한한다.

사람이 계속 검토할 부분

에이전트는 풀 리퀘스트와 함께 예상 변경과 실제 변경의 비교, 필요한 동작 검사 결과, 발견해 고친 예상 밖의 변경, 아직 검증하지 못한 부분을 반환해야 한다. 작업이 막혔다면 구체적인 문제와 시도한 내용, 관련 실행 결과도 제시해야 한다.

사람은 코드와 최종 계획을 검토하고 완료 기준이 의도한 변경을 제대로 담았는지 확인해야 한다. 샌드박스 테스트가 확인해 주는 것은 시험한 환경의 동작뿐이며, 운영 환경 배포에는 별도의 계획 검토와 검사가 필요하다. Masterpoint는 엔지니어 또는 팀원에게 검토를 요청하기 전에 에이전트와 사람이 인프라 계획을 먼저 검토하는 방식을 권한다.

ClickOps로 만든 인프라를 Terraform으로 가져오는 사례는 기존 인프라를 Terraform 또는 OpenTofu로 가져오는 방법에서도 다룬다.