"AI와 함께 Terraform을 쓴다"는 말이 이제는 흔해졌다. 그런데 어떤 AI와 함께 쓰느냐가 결과를 가른다. AWS가 키운 신예 Kiro와, 전 세계 개발자가 선택한 범용 강자 Claude Code. Terraform을 위한 파트너로는 누가 더 어울릴까?
🎯 이 글에서 다루는 것
Kiro와 Claude Code의 근본 철학 차이 (Spec-driven vs Prompt-native)
각자의 Terraform 통합 방식 (Kiro Powers vs MCP Server)
AWS 네이티브 통합 vs 멀티 클라우드/벤더 중립의 트레이드오프
실전 시나리오별 선택 가이드
AI 기반 IaC 작성 시 흔히 빠지는 함정
📌 왜 지금 이 비교가 중요한가
불과 1~2년 전만 해도 Terraform을 작성한다는 것은 Registry 문서를 열어놓고, 공식 모듈 README를 뒤지고, 오래된 블로그 글의 버전 호환성을 검증하는 고된 작업이었습니다. 그런데 2025년 후반부에 들어서면서 풍경이 완전히 달라졌습니다.
AWS는 Kiro라는 AI 기반 IDE를 정식 출시했고, re:Invent 2025에서 HashiCorp와 손잡고 Terraform Power를 공개했습니다. 같은 시기에 Anthropic의 Claude Code는 HashiCorp의 공식 Terraform MCP Server와 맞물리며, 단순한 코드 자동완성을 넘어 Registry API와 실시간으로 대화하는 에이전트로 진화했습니다.
즉, "AI로 Terraform을 쓴다"는 선택지가 둘로 갈라진 시대가 온 것입니다. 어느 쪽이 내 팀에 맞을지 판단하지 못하면, 초기 생산성은 올라가도 장기적으로 유지보수 비용이 늘어날 수 있습니다.
🔍 Kiro — AWS가 직접 설계한 "스펙 기반" IDE
Kiro의 정체성
Kiro는 2025년 여름 AWS가 선보인 에이전틱 AI IDE(+CLI)입니다. 가장 큰 특징은 Spec-driven Development, 즉 코드를 짜기 전에 요구사항(Requirements) → 설계(Design) → 태스크(Tasks) 세 단계의 스펙을 먼저 자동 생성하고, 사용자의 리뷰를 거친 뒤 실행한다는 점입니다. 요구사항은 EARS 노테이션이라는 공식 표기법으로 작성됩니다.
쉽게 말하면, Vibe coding(감 잡아서 코딩)의 장점은 유지하면서, 복잡한 프로젝트에서 AI가 제멋대로 질주하는 문제를 스펙이라는 울타리로 막는 구조입니다.
Kiro의 Terraform 통합 방식 — "Powers"
Kiro는 Powers라는 독특한 확장 메커니즘을 가집니다. Power는 MCP 서버, 스티어링 파일(가이드라인), 훅(자동화 작업)을 하나의 번들로 묶은 것입니다. HashiCorp가 직접 launch partner로 참여한 Terraform Power를 설치하면, "Terraform", "infrastructure" 같은 단어가 대화에 등장할 때만 자동으로 활성화됩니다.
일관된 거버넌스: Steering 파일에 "Lambda는 ARM64 Graviton 사용, S3는 Intelligent-Tiering 기본" 같은 조직 규칙을 영구 저장
Kiro가 빛나는 순간
AWS 환경에서 레거시 모더나이제이션 프로젝트를 진행할 때, Kiro는 기존 코드베이스를 분석하고 CloudFormation/CDK/Terraform 중 조직 선호도에 맞춰 IaC를 생성해줍니다. 내부적으로 EKS/ECS MCP, Cost MCP, Diagram MCP 등을 오케스트레이션하기 때문에, "AWS만 쓰는 팀"에게는 스위스 군용 칼과 같습니다.
🤖 Claude Code — 벤더 중립, 유연한 범용 강자
Claude Code의 정체성
Claude Code는 Anthropic의 Claude 모델을 기반으로 한 에이전틱 코딩 도구입니다. 터미널 CLI를 중심으로 VS Code/JetBrains 플러그인, GitHub Actions, Slack 통합까지 지원합니다. Kiro가 "스펙을 먼저"를 외친다면, Claude Code는 **"자연어 대화를 통한 유연한 탐색"**에 가깝습니다.
최근에는 Skills라는 기능이 추가되어, 특정 도메인의 베스트 프랙티스(Terraform, HCP Terraform 등)를 Claude가 자동으로 로드하고 따라가도록 할 수 있습니다. Kiro의 Powers와 기능적으로 유사하지만, 설계가 더 개방적입니다.
Claude Code의 Terraform 통합 방식 — "MCP Server + Skills"
HashiCorp가 공식 유지 중인 Terraform MCP Server를 Claude Code에 연결하면, Claude는 Terraform Registry API와 직접 대화합니다. 설정은 간단합니다:
# Claude Code에 Terraform MCP Server 등록
claude mcp add terraform -s user -t stdio \
-- docker run -i --rm hashicorp/terraform-mcp-server
HCP Terraform(구 Terraform Cloud)을 쓴다면 토큰을 함께 넘기면 됩니다:
claude mcp add terraform -s user -t stdio \
-e TFE_TOKEN=your-token-here \
-- docker run -i --rm hashicorp/terraform-mcp-server
이렇게만 해두면, 다음 대화에서 Claude는 Provider의 최신 버전과 스키마를 실시간 조회하며 코드를 작성합니다. 학습 데이터 컷오프에 묶여 사라진 리소스 인자를 쓰거나, 이미 deprecated된 문법을 남발하는 문제가 크게 줄어듭니다.
간단한 프롬프트 예시
Using the latest AWS provider, generate a Terraform module named `vpc_subnet`
that creates a VPC with a configurable CIDR, a variable number of public and
private subnets, NAT gateways per AZ, route tables, and outputs the VPC ID
and subnet IDs. Use official HashiCorp modules where possible.
Claude는 MCP를 거쳐 Registry에서 공식 terraform-aws-modules/vpc/aws 모듈의 최신 사용법을 확인하고, 이를 기반으로 스캐폴드를 내놓습니다. 추가로 보안 검사(Checkov, tfsec) 나 GitHub Actions 같은 다른 MCP와도 쉽게 결합할 수 있어, 다중 도구 오케스트레이션에 강합니다.
Claude Code가 빛나는 순간
멀티 클라우드 (AWS + Azure + GCP) 또는 하이브리드 클라우드 환경
기존 VS Code/JetBrains/터미널 중심 워크플로우를 유지하고 싶은 팀
GitHub Actions에 Claude Code를 넣어 "주간 Provider 업데이트 자동 탐지" 같은 에이전틱 워크플로우를 돌리고 싶은 팀
⚖️ 정면 비교표
항목
Kiro
Claude Code
개발 주체
AWS
Anthropic
핵심 철학
Spec-driven (EARS 노테이션)
Prompt-native + Skills
기본 인터페이스
독립 IDE + CLI
터미널 CLI + VS Code/JetBrains 플러그인
Terraform 통합
Terraform Power (HashiCorp 공식 번들)
Terraform MCP Server + Terraform Skill
클라우드 친화성
AWS 네이티브 (EKS/ECS/Cost MCP 등 내장)
벤더 중립 (AWS/Azure/GCP 균등 대응)
거버넌스 저장 방식
Steering 파일 (영구 규칙)
AGENTS.md, Skill 파일
자동화 훅
Hooks (fmt/lint/scan 자동 실행)
GitHub Actions 기반 에이전틱 워크플로우
학습 곡선
스펙 단계에 익숙해져야 함
일반 채팅에 가까워 진입 쉬움
오프라인/에어갭
제약 있음
제약 있음 (MCP는 Docker 로컬 실행 가능)
💻 같은 작업, 다른 접근 — "ECS Fargate + ECR" 배포 시나리오
Kiro에서의 흐름
채팅창에 자연어로 요청 → Requirements.md가 EARS 표기로 자동 생성
리뷰 후 승인하면 Design.md가 생성 (HashiCorp 공식 모듈 사용 등 반영)
Tasks.md로 분할된 작업을 하나씩 혹은 일괄 실행
Hook이 terraform fmt, tfsec, checkov를 자동 실행
"terraform-infra 디렉터리에 멀티 아키텍처 Docker 이미지를 빌드해
ECR에 푸시하고, ECS Fargate로 프론트/백엔드 2티어를 배포하는 스펙을 만들어줘.
kreuzwerker/docker와 aws provider를 사용하고, 백엔드는 Task Role로
Secrets Manager에서 OpenAI API 키를 읽게 해줘."
Claude Code에서의 흐름
.mcp.json에 Terraform MCP + AWS Diagram MCP 등록
자연어 프롬프트 → Claude가 Registry 조회하며 바로 HCL 작성
필요 시 terraform plan 실행 결과를 Claude에게 다시 피드백 → 반복 수정
GitHub Actions 워크플로우에 Claude Code를 걸어 PR 기반 리뷰 자동화
두 방식 모두 훌륭한 결과를 냅니다. 차이는 "구조화된 산출물(spec/requirements/tasks)을 조직에 남기고 싶으냐" vs "빠른 대화와 반복으로 최단 경로를 가고 싶으냐" 입니다.
⚠️ 주의사항 / 흔한 실수
1. AI가 만든 IaC를 그대로 apply하지 말 것
특히 Kiro의 Vibe 모드를 시험 삼아 쓴 사례에서, "Hello World 컨테이너 하나 띄워줘"라는 요청이 월 $150~200짜리 프로덕션 급 EKS 클러스터로 변신한 일화가 보고되었습니다. AI의 "친절한 기본값"은 청구서에 치명적일 수 있습니다.
2. MCP 서버는 Local-only를 원칙으로
HashiCorp Terraform MCP Server는 공식 문서에서 **"untrusted MCP client나 LLM과는 절대 함께 쓰지 말 것"**을 경고합니다. 신뢰되지 않은 원격 MCP 엔드포인트에 Terraform 상태나 TFE 토큰을 노출하면, 그 순간 인프라 키가 털립니다.
3. Steering/Skill 파일에 크레덴셜 넣지 말 것
AI가 규칙을 영구 기억하게 할 수 있다는 것은 장점이지만, 동시에 비밀번호·API 키를 무심코 넣으면 컨텍스트에 평생 따라다니게 됩니다. Secrets Manager/SSM Parameter Store 참조만 기록하십시오.
4. AI 의존과 엔지니어링 역량의 균형
"Claude가 짜준 VPC가 왜 잘 돌아가는지 모르겠다"는 상태는 재앙의 씨앗입니다. AI는 force-multiplier이지 아키텍처 이해의 대체재가 아닙니다. 특히 주니어 엔지니어는 스펙/생성 코드를 꼼꼼히 리뷰하며 학습 루프에 태우는 것이 필수입니다.
✅ 정리 / 마무리
결론부터 말씀드리면, 어느 하나가 절대적으로 우월하지 않습니다. 선택 기준은 단순합니다:
조직 전체가 AWS에 올라타 있고, 스펙 기반으로 산출물을 남기고 싶다면 → Kiro
멀티 클라우드/하이브리드이거나, 기존 VS Code·GitHub Actions 워크플로우를 유지하고 싶다면 → Claude Code
보안·거버넌스 규칙을 조직 차원에서 강제하고 싶다면 → Kiro의 Steering + Hook 조합이 유리
에이전틱 자동화(주간 Provider 업데이트 탐지 등)를 CI에 엮고 싶다면 → Claude Code + GitHub Actions
저는 개인적으로 두 도구를 배타적 선택이 아니라 보완적 도구로 씁니다. 설계와 스펙 초안은 Kiro에게 맡기고, 실제 모듈 리팩토링·멀티클라우드 브릿지·CI 자동화는 Claude Code에게 넘기는 식으로 말이지요.
결국 AI가 바꾼 것은 Terraform 그 자체가 아니라 "엔지니어가 어디에 시간을 쓰는가" 입니다. 문법 외우기와 버전 체크는 AI에게 넘기고, 우리는 아키텍처 판단과 비용·보안 리뷰에 집중하면 됩니다. 그게 2026년 IaC 엔지니어의 새로운 일하는 법입니다.
