CDK vs Terraform

학습 목표

Terraform과 CDK가 같은 IaC 철학(선언·멱등)을 공유하지만 엔진·상태가 다름을 설명할 수 있다.

state file vs CloudFormation stack이 plan·drift·협업에 미치는 차이를 설명할 수 있다.

plan/apply와 synth/diff/deploy 워크플로를 1:1로 대응시킬 수 있다.

멀티 클라우드·팀 언어·추상화 관점에서 어느 쪽을 고를지 근거를 들 수 있다.

두 도구를 공존시키는 패턴(terraform-cdk, 스택 분리)을 개괄할 수 있다.

문제 상황

• Part 1 Terraform으로 S3·VPC·remote state를 잡았는데 — AWS만 쓰면 CDK가 낫다는 말만 듣고 기준이 없음
• CDK cdk diff는 익숙한데 terraform plan과 뭐가 다른지 — state가 어디 있나 헷갈림
• 팀은 TypeScript 앱 + HCL 인프라 — 언어 이원화가 맞는 선택인지
• GCP VM + AWS RDS — CDK만으로는 불가; Terraform은 되는데 CDK 버릴지 고민
• Terraform module registry vs CDK construct hub — 재사용 생태계 비교가 안 됨
• 멱등은 둘 다 된다는데 — CFn rollback과 TF state corruption은 다른 실패 모드
• 7편 NetworkStack을 TF로 짜고 App을 CDK로 — 섞어도 되나

Part 1 Terraform과 Part 2 CDK 개요·hands-on을 봤다. 이번 편은 선택·공존을 위한 비교 축을 고정한다. CDK 테스트·CI는 9편, drift·import 심화는 20편이다.

1. 같은 철학, 다른 엔진

둘 다 desired state in code — 콘솔 클릭 대신 선언·리뷰·적용.

공통	Terraform	AWS CDK
선언적	HCL resource 블록	Construct props
멱등	동일 code → plan no change	동일 synth → deploy no-op
버전 관리	Git + PR	Git + PR
차이	Terraform Core + provider	synth → CloudFormation

• 엔진이 다르면 상태 저장소·실패·드리프트 도구도 다름
• "CDK vs TF"가 아니라 "CFn 엔진 vs TF 엔진" 으로 보면 명확

2. 상태 — state file vs CloudFormation stack

Terraform

• state — 리소스 address → cloud ID 매핑 (4편)
• remote backend — S3 + locking (DynamoDB)
• plan — desired(HCL) + state + API refresh
• 위험 — state 손상·누수 · lock 경합

AWS CDK

• CDK 자체 state 파일 없음 — CloudFormation stack이 실제·배포 기록
• cdk diff — synth template vs deployed stack
• 위험 — stack rollback · REPLACE · template 한도

	Terraform	CDK (via CFn)
진실의 원천	code + state	code → template + stack
협업 키	shared backend	shared stack (계정·리전)
드리프트	plan refresh · import	CFn drift detection
민감 정보	state에 속성 노출 가능	template·stack output 주의

• state는 TF 필수 운영 주제 — CDK는 CFn 운영에 가깝다
• import — TF terraform import vs CFn resource import (20편)

3. 워크플로 — plan/apply vs synth/diff/deploy

# Terraform
terraform init
terraform plan -out=tfplan
terraform apply tfplan

# AWS CDK
cdk synth
cdk diff
cdk deploy

단계	Terraform	CDK
준비	init (provider·backend·module)	bootstrap (최초 asset, 6편)
미리보기	plan	synth + diff
적용	apply	deploy
삭제	destroy	destroy
CI 산출물	plan file·JSON	cdk.out template

• plan file — 승인된 변경 고정 (19편 거버넌스)
• synth — API 호출 없음; PR에 template diff 가능 (9편)
• 둘 다 CI에서 미리보기 → 승인 → 적용 패턴 동일

4. 언어와 추상화

같은 S3 버킷 — 표현만 다르다.

# code/s3-bucket.example.tf
resource "aws_s3_bucket" "artifacts" {
  bucket = "myapp-artifacts-${var.env}"

  versioning {
    enabled = true
  }
}

// code/s3-bucket.example.ts
import * as s3 from "aws-cdk-lib/aws-s3";

new s3.Bucket(this, "Artifacts", {
  bucketName: `myapp-artifacts-${env}`,
  versioned: true,
});

	Terraform	CDK
언어	HCL (+ JSON/YAML 선택)	TS·Python·Go 등
재사용	module (source·version)	Construct L2/L3
로직	count·for_each·locals	일반 언어 loop·조건
타입	terraform validate	TS 컴파일 / Py 런타임
레지스트리	Terraform Registry	Construct Hub·npm/PyPI

• HCL 단순·제한적 로직 — 복잡 조건은 module로 숨김
• CDK 과도한 런타임 로직 — synth 결과 예측 어려움 (지양)
• TF module ≈ CDK L2/L3 Construct — 4편·7편과 연결

5. 에코시스템과 멀티 클라우드

축	Terraform	CDK
클라우드	AWS·GCP·Azure·K8s·다수 provider	AWS 중심 (주력)
K8s	kubernetes provider	cdk8s (별 프로젝트)
서드파티	provider 광범위	AWS 서비스 깊이
커뮤니티	업계 사실 표준	AWS·TS/Python 팀

• 멀티 클라우드·SaaS (Cloudflare, Datadog provider) → Terraform 유리
• AWS 단일·서비스 밀집 (IAM·Lambda·ECS 패턴) → CDK 유리
• CDK for Terraform (cdktf) — TF provider + TS/Python — 6절

6. 워크로드별 선택

시나리오	추천	이유
AWS only + 앱과 같은 언어	CDK	타입·리팩터·L3 패턴
멀티 클라우드 / K8s + 클라우드	Terraform	provider 통합
플랫폼 팀 HCL + 앱 팀 TS	분리 또는 cdktf	소유권·스킬
기존 TF module 대량	Terraform	sunk cost·registry
CFn 네이티브·SAM 근처	CDK	synth = CFn
작은 팀·단순 스택	둘 다 OK	한 가지로 통일이 더 중요

• 잘못된 질문 — "어느 게 더 좋나" → **"우리 제약에서 어느 엔진이 맞나"
• 조직 표준 하나 — TF+CDK 혼재는 CI·권한·온보딩 비용 ↑

7. 공존과 마이그레이션

스택·레이어 분리

Terraform:  VPC · DNS · shared RDS  (멀티 클라우드·플랫폼)
CDK:        앱 스택 · Lambda · API   (AWS·앱 팀)
연결:       TF output → CDK context / SSM Parameter

• 7편 cross-stack — CDK 내부; TF→CDK는 output·SSM·data source
• 경계 문서화 — 누가 VPC를 소유하는지

CDK for Terraform (cdktf)

• TypeScript/Python으로 Terraform provider 호출
• state는 Terraform — CDK 문법만 빌림
• 멀티 클라우드 + 앱 언어 둘 다 필요할 때 타협안

Terraform에서 CDK 리소스 참조

• CDK 배포 output → TF data / remote state
• 역방향도 가능 — 단방향 의존 권장 (순환 금지)

패턴	설명
TF only	단순·멀티 클라우드
CDK only	AWS·TS/Python 팀
TF base + CDK app	흔한 하이브리드
cdktf	TF 엔진 + 고급 언어

8. 실무 체크리스트

질문	Terraform	CDK
상태를 직접 관리해야 하나?	예 (backend)	아니오 (CFn)
GCP/Azure도 같은 도구로?	예	아니오
앱 repo에 인프라 넣을까?	가능 (HCL)	자연스러움 (TS)
plan 승인 파일?	native	template diff
롤백	state·수동 복구	CFn 자동 rollback

• 도입 시 PoC 하나 — 동일 S3·Lambda를 양쪽 짜 보고 CI·온보딩 비교
• 9편 — 선택한 쪽 테스트·배포 파이프라인

정리

• 철학 동일 — 선언·멱등·Git; 엔진 상이 — TF Core vs CloudFormation
• 상태 — TF state file vs CFn stack
• 워크플로 — plan/apply ≈ synth+diff/deploy
• 선택 — 멀티 클라우드·HCL 표준 → TF; AWS·앱 언어·L3 → CDK
• 공존 — 플랫폼 TF + 앱 CDK, cdktf 중간지대
• 9편 — CDK 테스트·snapshot·CI

다음에 다룰 것

• CDK 테스트와 배포
• cdk deploy/diff, snapshot test, CI 파이프라인 연동

---

해당 내용은 HashiCorp Terraform documentation, AWS CDK Developer Guide, Brikman Terraform: Up & Running 3/E 를 기반으로 합니다.