AI를 활용한 Terraform: AWS 인프라 구축 (Cursor + MCP)

현대 DevOps에서 AI를 활용한 Terraform이 중요한 이유

작은 설정을 넘어선 모든 것에 대해 Terraform을 작성하는 것은 빠르게 지루한 작업이 됩니다. 여러 모듈, 리소스 간의 상호 의존성, 그리고 AWS 특유의 독특한 특성들을 다루기 시작하면 워크플로우가 느려집니다. 대부분의 시간은 코드를 작성하는 데 쓰이지 않습니다. 문서를 확인하고, 예외 케이스(edge cases)를 수정하며, terraform apply를 다시 실행하는 데 소비됩니다. 많은 팀이 이를 가속화하기 위해 AI를 활용한 Terraform을 실험하고 있습니다. 하지만 실제로 AI가 적절한 컨텍스트(context)를 가지고 있지 않다면, 이는 부분적으로만 효과가 있습니다.

Terraform MCP 서버와 Cursor AI로 완전한 AWS 인프라 구축하기 - 전체 튜토리얼

전통적인 Terraform 워크플로우 방식

전형적인 워크플로우는 다음과 같습니다:

1. Terraform 문서 읽기
2. 모듈 및 리소스를 수동으로 작성
3. terraform plan 실행
4. 오류 수정
5. 반복

작은 설정의 경우 이는 관리 가능한 수준입니다. 하지만 프로덕션(production) 인프라의 경우, 이는 반복적이고 느려집니다. 대부분의 엔지니어는 Terraform 레지스트리 문서, AWS 문서, 그리고 자신의 코드베이스 사이를 끊임없이 오가게 됩니다.

컨텍스트 없는 AI 활용 Terraform의 한계

명백한 아이디어는 AI를 사용하여 Terraform을 생성하는 것입니다. 대부분의 경우 다음과 같이 시작합니다: “공용 및 사설 서브넷(public and private subnets)이 있는 VPC를 위한 Terraform을 생성해줘”

결과물은 얻을 수 있습니다. 하지만:

• 오래된 인자(arguments)를 사용할 수 있음
• 사용자의 모듈 구조를 무시함
• 의존성(dependencies)이 불완전함
• terraform apply 단계에서 자주 실패함

👉 핵심 문제: AI는 사용자의 인프라 컨텍스트(context)를 이해하지 못합니다.

우리의 첫 번째 시도 (RAG 실패) (2024년 말 - 현대적 에이전트의 등장 이전)

이를 해결하기 위해 우리는 다음을 사용하여 내부 도구를 구축했습니다:

• 벡터 데이터베이스 (Vector database)
• RAG (Retrieval-Augmented Generation, 검색 증강 생성)

아이디어는 Terraform 문서를 가져와 벡터 데이터베이스에 인덱싱한 후 에이전트에게 제공하는 것이었습니다.
이는 약간의 도움은 되었지만, 실제로는 실패했습니다:

• 반복(Iteration)이 어려움 - terraform plan 및 apply 루프 - 오류 수정
• 컨텍스트 크기(Context size)의 제한
• 프로젝트 구조에 대한 인지 부족
• 결과물을 정교화할 수 없음

코드를 생성하기는 했지만, 단순한 인프라에 대해서만 가능했습니다.

복잡한 인프라의 경우 몇 번의 반복(iteration) 후에 실패하곤 했습니다. 우리는 이를 더 최적화하려고 시도하지 않았는데, 그 과정 중에 Cursor 에이전트(agents)가 매우 강력해지면서 이러한 반복 문제를 거의 해결했기 때문입니다.

MCP Server + Cursor로 무엇이 바뀌었나

Terraform MCP Server를 도입하고 이를 Cursor와 함께 사용하면서 동작 방식이 바뀌었습니다. 시스템이 맹목적으로 코드를 생성하는 대신, 이제 다음과 같은 정보에 접근할 수 있게 되었습니다:

• Terraform 모듈 문서 (module documentation)
• 입력/출력 구조 (Input/output structures)
• 리소스 관계 (Resource relationships)

차이는 확연했습니다. 결과물이 완벽하지는 않았지만, 실제로 사용할 수 있는 수준에 훨씬 가까워졌습니다.

MCP가 워크플로우를 실제로 바꾸는 방식

높은 수준(high level)에서 보면, MCP는 에디터(Cursor)와 Terraform 컨텍스트(context) 사이의 가교 역할을 합니다. AI는 추측하는 대신 다음과 같은 작업을 수행할 수 있습니다:

• 모듈 정의 조회 (Look up module definitions)
• 필수 입력값 이해 (Understand required inputs)
• 리소스 간의 의존성 추적 (Follow dependencies across resources)

이것이 표준적인 AI 사용 방식과의 핵심적인 차이점입니다.

⚙️ MCP Server가 내부적으로 실제로 하는 일

MCP를 통한 개선은 단순히 프롬프팅(prompting)이 좋아진 것이 아니라, 구조화된 Terraform 지식에 접근할 수 있게 된 것입니다. MCP 서버는 AI가 실제 Terraform 데이터를 쿼리(query)할 수 있도록 도구(tools)를 노출합니다.

주요 MCP 기능:

• Provider 문서 조회 (Provider Documentation Lookup): 리소스, 데이터 소스(data sources), 함수에 대한 전체 문서를 가져옵니다.
• 모듈 탐색 (Module Discovery): 레지스트리(registry)에서 사용 예시가 포함된 Terraform 모듈을 찾습니다.
• 모듈 상세 정보 (Module Details): 입력값, 출력값 및 구성 패턴(configuration patterns)을 검색합니다.
• 정책 검색 (Policy Search): 베스트 프랙티스(best practices) 및 보안 정책을 식별하는 데 도움을 줍니다.

👉 간단히 말하자면: AI가 추측하는 대신, 엔지니어가 하는 것처럼 정보를 찾아볼 수 있게 된 것입니다.

AI를 활용한 Terraform vs 수동 vs MCP (비교)

실제로 대부분의 팀은 먼저 AI를 시도해 보지만, 컨텍스트(context) 없이는 결과가 신뢰할 수 없다는 것을 깨닫게 됩니다. MCP는 바로 그 간극을 메워줍니다.

실제 사례: AWS 인프라 구축

현실적인 설정을 예로 들어보겠습니다:

• 퍼블릭 및 프라이빗 서브넷(subnet)을 포함한 VPC
• NAT 게이트웨이(NAT Gateway) 및 인터넷 게이트웨이(Internet Gateway)
• 애플리케이션 로드 밸런서(Application Load Balancer, ALB)
• 오토 스케일링 그룹(Auto Scaling group, EC2)
• CloudFront 배포(distribution)
• Cloudflare DNS
• 접속을 위한 점프 박스(Jump box)

이는 전형적인 프로덕션(production) 스타일의 설정입니다. 이를 수동으로 작성하는 것은 시간이 많이 걸리며, 특히 의존성(dependencies)을 올바르게 연결할 때 더욱 그렇습니다.

우리의 접근 방식
모든 것을 수동으로 작성하는 대신, 문제를 더 작은 단계로 나누고 AI를 가이드했습니다.

🧠 인프라 생성을 위해 사용된 전체 프롬프트(Full Prompt)
모호한 프롬프트 대신, AI를 안내하기 위해 구조화된 단계별 접근 방식을 사용했습니다.

코드 생성을 시작하세요. 단계별로 진행하세요. 현재 단계가 완료된 후에만 다음 단계로 넘어가세요.

단계: VPC 및 네트워크 인프라 생성

• vpc 모듈 사용
• 적절한 CIDR 블록으로 VPC 생성
• 2개의 가용 영역(AZs)에 걸쳐 퍼블릭 및 프라이빗 서브넷 생성
• 인터넷 게이트웨이 설정
• 퍼블릭 서브넷에 NAT 게이트웨이 구성
• 퍼블릭/프라이빗 서브넷을 위한 라우트 테이블(route tables) 구성

단계: 보안 그룹(Security Groups) 생성

• ALB 보안 그룹 (HTTP/HTTPS 인바운드 허용)
• EC2 보안 그룹
  • ALB로부터의 트래픽 허용
  • VPC로부터의 SSH 허용
  • 모든 아웃바운드 트래픽 허용

단계: 오토 스케일링 그룹(Auto Scaling Group) 생성

• autoscaling 모듈 사용
• EC2 인스턴스를 위한 런치 템플릿(launch template) 생성
• 인스턴스에 ubuntu AMI 사용
• 프라이빗 서브넷에 걸쳐 ASG 구성
• "vikas-aws"라는 이름의 키 페어(keypair) 사용
• nginx를 설치하고 간단한 html 페이지를 생성하는 유저 데이터(user data) 스크립트 추가

단계: 점프 박스(jumpbox) 생성

• 퍼블릭 서브넷에 점프 박스 생성
• 퍼블릭 IP를 갖도록 설정
• 인터넷으로부터의 SSH 허용

단계: 애플리케이션 로드 밸런서(Application Load Balancer) 생성

• alb 모듈 사용
• 퍼블릭 서브넷에 ALB 생성
• HTTP 리스너(listener) 구성
• 오토 스케일링 그룹에 연결

단계: CloudFront 배포

• ALB를 오리진(origin)으로 하여 CloudFront 구성
• 캐싱 TTL을 0으로 설정

단계: DNS 구성

• Cloudflare를 통해 DNS 처리 (Route53 사용 안 함)

실제로, 문제를 이와 같이 단계별로 나누는 것은 단일

프롬프트(prompts)입니다. 생성된 Terraform의 모습은 다음과 같습니다. 단순화된 예시:

module "vpc" {
  source = "terraform-aws-modules/vpc/aws"
  version = "5.0.0"
  name   = "demo-vpc"
  cidr   = "10.0.0.0/16"
  azs    = [ "us-east-1a", "us-east-1b" ]
  public_subnets  = [ "10.0.1.0/24", "10.0.2.0/24" ]
  private_subnets = [ "10.0.3.0/24", "10.0.4.0/24" ]
  enable_nat_gateway = true
  single_nat_gateway = true
}

이것이 즉시 완벽하게 작동하는 것은 아니었지만, 다음과 같은 장점이 있었습니다:

• 구조(Structure)가 올바름
• 입력값(Inputs)이 대부분 유효함
• 의존성(Dependencies)이 정렬됨

이것만으로도 상당한 시간을 절약할 수 있습니다.

실제 사용을 통해 개선된 점
실제 사용 사례 기준:
이전:

• 인프라 조립에 2~4시간 소요
• 수많은 문서 조회 필요
• 여러 번의 적용(apply) 실패

이후:

• 초기 설정이 몇 분 만에 생성됨
• 구조적 오류 감소
• 빠른 반복(iteration)

대부분의 팀에서 가장 큰 이점은 컨텍스트 스위칭(context switching)의 감소입니다.

운영 고려 사항
이 접근 방식에는 여전히 규율이 필요합니다:

• 항상 terraform plan을 실행할 것
• 변경 사항을 주의 깊게 검토할 것
• 생성된 코드를 맹목적으로 신뢰하지 말 것

IAM 정책 및 보안 구성은 항상 수동으로 검토해야 합니다.

AI를 활용한 Terraform이 가장 효과적인 경우
대부분의 팀에서 이 접근 방식은 다음과 같은 상황에서 잘 작동합니다:

• 새로운 인프라를 구축할 때
• 모듈(modules)을 빠르게 스캐폴딩(scaffold)해야 할 때
• 반복적인 작업을 줄이고 싶을 때

검증 없이 또는 맹목적으로 사용할 경우 효과가 떨어집니다.

이 접근 방식을 사용하지 말아야 할 때
다음과 같은 경우에는 의존하지 마십시오:

• 인프라에 엄격한 컴플라이언스(compliance)가 요구될 때
• 생성된 코드를 이해하지 못할 때
• 결정론적(deterministic)이고 감사(audited) 가능한 구성이 필요할 때

이것은 Terraform 전문 지식을 대체하는 것이 아닙니다.

DevOps 워크플로우에서의 위치
이 접근 방식은 다음과 자연스럽게 통합됩니다:

• Git 기반 워크플로우
• CI/CD 파이프라인
• 인프라 리뷰

배포 프로세스는 변하지 않으며, 오직 코드가 작성되는 방식만 바뀝니다.

자주 묻는 질문 (FAQ)
AI를 활용한 Terraform이란 무엇인가요?
AI를 활용한 Terraform은 AI 도구를 사용하여 인프라 코드를 더 효율적으로 생성하고 관리하는 것을 의미합니다.

Terraform MCP 서버란 무엇인가요?

이것은 모듈(modules)과 문서(documentation)를 포함하여 AI 도구에 Terraform 컨텍스트(context)를 제공합니다. AI가 생성한 Terraform은 프로덕션(production) 환경에서 안전할까요? 네, 하지만 적절한 검증(validation)과 검토(review)를 거친 후에만 그렇습니다. 결론: Terraform 자체는 변하지 않았습니다. 변하고 있는 것은 엔지니어가 Terraform과 상호작용하는 방식입니다. AI + MCP 서버를 사용하여 Terraform을 활용하면 인프라를 작성할 때 발생하는 마찰(friction)을 줄일 수 있으며, 특히 반복적인 설정(repetitive setups)에서 더욱 효과적입니다. 이것이 엔지니어링적 판단(engineering judgment)을 대체하는 것은 아니지만, 워크플로(workflow)를 더욱 효율적으로 만들어 줍니다. 관련 읽을거리: https://www.kubeblogs.com/how-civo-kubernetes-routes-pod-traffic-single-egress-ip-explained/ https://www.kubeblogs.com/gp3-vs-gp2-ebs-volume-aws/