Claude Code와 Terraform으로 AWS 배포까지 가져가는 법

사이드 프로젝트를 만들 때 가장 많이 멈추는 지점은 구현이 아닙니다. 로컬에서는 잘 돌아가는데, 실제로 배포하려는 순간부터 막막해집니다. AWS 콘솔에 들어가면 VPC, 서브넷, ECS, RDS, IAM 같은 단어가 한꺼번에 나옵니다. 어느 버튼을 눌러야 하는지, 어떤 순서로 만들어야 하는지, 잘못 만들면 비용이 얼마나 나올지 감이 잘 오지 않습니다.

그래서 많은 프로젝트가 “거의 다 만들었는데 배포만 남은 상태”에서 멈춥니다. 하지만 실제 개발 완료의 기준은 로컬 구현이 아닙니다. 사용자가 접속할 수 있는 프로덕션 배포와 안정적 운영까지 가야 합니다.

AI Native 개발자에게 중요한 변화는 여기서 시작됩니다. AI는 이제 애플리케이션 코드만 돕는 도구가 아니라, 배포와 인프라 진단, 운영 컨텍스트까지 함께 다루는 도구가 될 수 있습니다.

AI는 터미널과 클라우드 명령어를 잘 다룹니다

클라우드 환경의 많은 작업은 결국 명령어로 제어됩니다. AWS 리소스를 확인하고, 로그를 조회하고, 배포 상태를 점검하고, 설정값을 비교하는 일은 대부분 CLI와 파일을 통해 처리할 수 있습니다.

이 지점에서 Claude Code 같은 AI 코딩 도구가 강점을 가집니다. 터미널 명령어를 만들고, 출력 결과를 읽고, 다음에 어떤 명령을 실행해야 할지 판단하는 흐름에 잘 맞기 때문입니다.

예를 들어 ECS 로그를 확인하거나, 배포된 서비스의 상태를 조회하거나, 타겟 그룹에 인스턴스가 제대로 붙었는지 확인하는 작업은 사람이 콘솔을 돌아다니며 클릭할 수도 있습니다. 하지만 AI에게 필요한 맥락과 명령어 실행 권한이 있으면, 로그를 읽고 문제 후보를 좁히는 작업을 훨씬 빠르게 진행할 수 있습니다.

물론 이것은 인프라를 몰라도 된다는 뜻이 아닙니다. 오히려 반대입니다. 사람이 최종 판단을 하려면 인프라의 구조를 이해해야 합니다. 다만 모든 설정을 손으로 외우고 클릭하는 방식에서 벗어나, 코드와 명령어 중심으로 이해하고 AI에게 일부 실행을 맡길 수 있다는 뜻입니다.

IaC는 인프라를 코드로 남기는 방식입니다

AWS 콘솔에서 직접 리소스를 만드는 방식은 처음에는 편해 보입니다. 버튼을 누르면 바로 생기기 때문입니다. 하지만 시간이 지나면 문제가 생깁니다. 누가 어떤 설정을 바꿨는지 알기 어렵습니다. 개발 환경과 운영 환경의 설정이 조금씩 달라질 수 있습니다. 같은 환경을 다시 만들려면 기억에 의존해야 합니다. 리소스 생성 순서가 꼬이면 의존성 문제도 생깁니다.

이 문제를 줄이기 위한 접근이 IaC, Infrastructure as Code입니다. 인프라를 콘솔 클릭이 아니라 코드로 정의하는 방식입니다. 원하는 최종 상태를 코드에 남겨두고, 도구가 그 상태에 맞게 리소스를 만들거나 수정하게 합니다.

이 방식의 장점은 분명합니다. 변경 이력이 남습니다. 같은 환경을 반복해서 만들 수 있습니다. 리뷰와 협업이 가능해집니다. 문제가 생겼을 때 이전 상태와 비교하기도 쉬워집니다.

Terraform은 반복 가능한 인프라 설계도입니다

Terraform은 IaC를 구현하는 대표적인 도구입니다. `main.tf` 같은 파일에 VPC, 서브넷, ECS, RDS, IAM 역할 같은 리소스를 정의합니다.

이 파일은 인프라의 설계도에 가깝습니다. 한 번 만들어둔 설계도를 기반으로 같은 환경을 다시 만들 수 있고, 변경이 필요하면 코드를 수정한 뒤 적용할 수 있습니다.

비유하자면 Terraform은 붕어빵 틀과 비슷합니다. 손으로 매번 모양을 맞추는 것이 아니라, 틀을 만들어두고 같은 형태를 반복해서 찍어낼 수 있습니다. 문제가 생기면 틀의 어느 부분을 고쳐야 하는지도 추적할 수 있습니다.

개발자에게 이 방식이 중요한 이유는 인프라가 더 이상 완전히 별개의 세계가 아니기 때문입니다. 애플리케이션 코드가 어떤 리소스 위에서 돌아가는지, CPU와 메모리가 어떻게 잡혀 있는지, 네트워크와 권한이 어떻게 연결되는지 이해해야 장애 대응과 확장이 가능해집니다.

Claude Code는 배포와 진단 흐름을 도울 수 있습니다

Terraform 코드가 준비되면 `terraform apply` 같은 명령으로 정의된 인프라를 실제 환경에 적용합니다. 이 과정에서 어떤 리소스가 추가되고, 어떤 설정이 바뀌는지 확인할 수 있습니다.

문제는 배포가 항상 한 번에 끝나지 않는다는 점입니다. 타겟 그룹에 대상이 등록되지 않았을 수 있습니다. ECS 서비스가 정상 배포되지 않았을 수 있습니다. 로그에 권한 오류나 네트워크 문제가 남아 있을 수 있습니다.

이전에는 사람이 콘솔과 로그를 오가며 하나씩 확인해야 했습니다. 이제는 AI가 AWS CLI 명령어를 만들고, 로그를 읽고, 다음에 확인할 지점을 제안할 수 있습니다.

예를 들어 “현재 ECS 서비스가 왜 정상 배포되지 않았는지 확인해줘”라고 요청하면 AI는 서비스 상태, 태스크 로그, 타겟 그룹 상태, 보안 그룹, 환경 변수 같은 후보를 순서대로 살펴볼 수 있습니다.

중요한 것은 AI에게 최종 판단을 완전히 넘기는 것이 아닙니다. AI가 문제 후보를 빠르게 좁히도록 하고, 사람은 그 결과가 시스템 구조와 맞는지 검토하는 방식입니다.

확장도 코드 변경으로 처리할 수 있습니다

서비스가 배포된 뒤에는 트래픽과 부하에 맞춰 확장이 필요합니다. ECS Fargate 태스크의 CPU나 메모리를 늘려야 할 수 있고, 특정 리소스의 설정을 바꿔야 할 수도 있습니다.

이 작업도 콘솔에서 즉흥적으로 클릭해서 바꾸면 추적이 어렵습니다. Terraform 코드로 관리하면 어떤 값을 왜 바꿨는지 남길 수 있습니다. 리뷰도 가능하고, 이전 상태로 돌아가기도 쉽습니다.

AI는 이 과정에서 현재 설정을 읽고, 어떤 값이 병목인지 추론하고, Terraform 변수나 리소스 설정을 어떻게 바꾸면 되는지 제안할 수 있습니다. 개발자의 역할은 여기서 넓어집니다. 단순히 API 코드를 작성하는 사람이 아니라, 서비스가 어떤 인프라 위에서 돌아가고 어디에서 병목이 생기는지 이해하는 사람으로 바뀝니다.

모니터링을 붙이면 AI에게 시스템의 눈이 생깁니다

배포 이후에는 모니터링이 필요합니다. 에러가 어디서 났는지, 어떤 API가 느린지, 어떤 브라우저나 환경에서 문제가 생겼는지 알아야 합니다. Sentry 같은 APM/옵서빌리티 도구는 이런 정보를 모아줍니다. 여기에 AI를 연결하면 상황이 달라집니다. AI가 단순히 코드만 보는 것이 아니라, 실제 운영 중 발생한 에러와 성능 데이터를 함께 볼 수 있습니다.

예를 들어 특정 API에서 에러가 반복된다면, AI는 에러 메시지와 스택 트레이스, 관련 코드, 최근 변경 사항을 함께 보고 원인 후보를 제안할 수 있습니다. 어떤 파일을 수정해야 할지, 어떤 테스트를 추가해야 할지도 함께 제안할 수 있습니다.

이것이 “AI에게 시스템의 눈을 달아준다”는 의미입니다. 코드만 주는 AI보다 운영 컨텍스트를 함께 가진 AI가 훨씬 더 실질적인 도움을 줄 수 있습니다.

AI로 다루는 범위는 코드 작성에서 운영까지 확장됩니다

AI를 코드 생성기로만 쓰면 개발자의 역할은 크게 바뀌지 않습니다. 조금 더 빨리 코드를 만들 뿐입니다. 하지만 AI를 Terraform, AWS CLI, 로그, 모니터링 도구와 연결하면 흐름이 달라집니다. 로컬 구현, 배포, 진단, 확장, 운영 개선까지 하나의 작업 흐름으로 묶을 수 있습니다.

앞으로의 개발자는 모든 인프라 세부 설정을 손으로 외우는 사람이 아니라, 인프라를 코드로 이해하고 AI가 실행 가능한 형태로 작업을 나누며, 결과를 검증할 수 있는 사람이 되어야 합니다.

로컬에서 돌아가는 코드를 만드는 것은 시작점입니다. 실제 가치는 사용자가 접속할 수 있고, 문제가 생겼을 때 진단할 수 있으며, 트래픽이 늘어도 확장할 수 있는 서비스로 만드는 데서 나옵니다. AI Native 개발자의 경쟁력은 바로 이 지점에서 생깁니다.