Claude Code와 Terraform으로 AWS 배포까지 가져가는 법
사이드 프로젝트가 멈추는 지점은 기능 구현보다 배포인 경우가 많습니다. 로컬에서는 돌아가지만 AWS 계정, VPC, ECS, RDS, 보안 그룹, 로그를 만나면 갑자기 일이 커집니다.
Claude Code와 Terraform을 같이 쓰면 이 구간을 "클릭으로 찍어 맞추는 작업"에서 "코드로 남기고 검토하는 작업"으로 바꿀 수 있습니다. AI가 대신 책임지는 것이 아니라, 사람이 검토할 수 있는 인프라 설계도를 만드는 방식입니다.
배포는 구현의 끝이 아니라 제품의 시작입니다
로컬 구현만 끝난 상태는 사용자가 만질 수 없는 코드입니다. 실제 서비스가 되려면 배포, 환경 변수, 로그, 장애 확인, 확장 기준이 이어져야 합니다. 이 단계에서 콘솔을 손으로 누르기 시작하면 재현성이 떨어집니다. 어떤 설정을 언제 바꿨는지 남지 않고, 다음 프로젝트에서 같은 환경을 다시 만들기도 어렵습니다.
장면 요약: 클릭은 빠르지만, 나중에 설명할 기록을 남기지 않습니다.
Terraform 같은 IaC 도구는 원하는 인프라 상태를 코드로 적어둡니다. VPC, 서브넷, ECS 서비스, RDS 같은 리소스를 파일로 관리하면 변경 이력과 리뷰가 가능해집니다.
Claude Code가 잘 도와주는 구간
AI는 터미널 기반 작업과 로그 해석에 강합니다. AWS CLI, Terraform plan, 배포 로그처럼 텍스트로 드러나는 작업은 Claude에게 맡길 수 있는 부분이 많습니다.
Terraform 파일의 리소스 관계 설명
`plan` 결과에서 위험한 변경 찾기
ECS 서비스와 타겟 그룹 상태 확인
CloudWatch 로그에서 실패 원인 후보 좁히기
CPU, 메모리, 태스크 수 조정 제안
다만 실행 권한을 무제한으로 주는 방식은 위험합니다. Claude가 명령을 제안하고, 사람이 변경 범위와 비용 영향을 확인하는 흐름이 안전합니다.
인프라 작업을 맡길 때 필요한 맥락
좋은 요청은 "AWS에 배포해줘"가 아닙니다. 배포 대상과 제한 조건이 있어야 합니다.
어떤 런타임인지: Node, Spring, Python 등
어떤 배포 단위인지: 컨테이너, 정적 사이트, 서버리스 등
데이터베이스가 필요한지
예상 트래픽과 비용 상한은 어느 정도인지
공개 API와 내부 API를 어떻게 나눌지
로그와 에러 추적은 어디로 보낼지
이 정보가 있어야 AI가 인프라 선택을 마음대로 채우지 않습니다. 인프라는 한 번 만들어지면 비용과 보안에 바로 연결되므로 맥락이 더 중요합니다.
콘솔 클릭보다 코드 리뷰가 안전합니다
AWS 콘솔에서 직접 바꾸는 설정은 빠르게 느껴지지만, 나중에 누가 무엇을 바꿨는지 찾기 어렵습니다. 특히 보안 그룹, 퍼블릭 접근, 태스크 권한, 데이터베이스 설정은 작은 변경도 위험이 큽니다.
Terraform으로 변경을 남기면 PR에서 diff를 볼 수 있습니다. Claude에게도 "이 plan에서 삭제되는 리소스가 있는지", "비용이 늘어나는 변경이 있는지", "공개 접근이 생기는지"처럼 구체적으로 검토를 맡길 수 있습니다. 배포 자동화의 핵심은 클릭 수를 줄이는 것이 아니라 변경을 설명 가능한 상태로 만드는 것입니다.
장면 요약: 배포는 됐다는 말보다 다시 볼 수 있는 기록이 더 중요합니다.
바로 적용할 체크리스트
처음부터 완전 자동 배포를 목표로 잡지 않아도 됩니다. 한 프로젝트에 아래 순서만 적용해도 운영 난이도가 내려갑니다.
현재 로컬 실행 방법을 README에 명확히 적습니다.
필요한 환경 변수와 외부 리소스를 목록으로 만듭니다.
Terraform으로 최소 배포 리소스만 먼저 정의합니다.
Claude에게 `plan` 결과를 설명하게 하고 위험한 변경을 표시하게 합니다.
배포 후 로그 확인 명령을 문서화합니다.
Sentry 같은 모니터링 도구를 붙이고 첫 에러 분석을 AI에게 맡겨봅니다.
AI Native 개발자는 코드를 빨리 쓰는 사람에서 끝나지 않습니다. 배포와 운영을 코드로 남기고, AI가 그 코드를 읽고 진단하게 만드는 사람이 됩니다.