State가 깨지거나 merge conflict이 났다면?

원격 state 백엔드+락, state pull·리소스 import로 정렬하고, 팀이 동시에 apply하지 않는 프로세스가 필요합니다.

모듈 버전을 어떻게 고정하나요?

프로바이더·모듈 소스/버전, .terraform.lock.hcl을 VCS에 커밋해 동일한 바이너리로 plan을 재현하세요.

destroy가 무섭다면?

워크스페이스 분리, prevent_destroy·라이프사이클, 스테이징 dry-run, 백업·drift detect를 먼저 쓰세요.

배럴(모놀리식) .tf vs 작은 모듈?

팀·재사용·환경(스테이징) 단위로 모듈화하고, 루트는 조합·백엔드·var만 남기는 것이 읽기 쉽습니다.

Terraform 실전 가이드 | IaC·AWS | 핵심 개념과 실전 활용

2026년 4월 7일 · 5분 읽기 · 수정 2026년 4월 18일 고급

이 글의 핵심

Terraform으로 인프라를 코드로 관리하는 실전 가이드. 기본 문법, AWS 리소스, State 관리, Module, Workspace, Best Practices까지 실무 예제로 정리. Start now.

이 글의 핵심

Terraform으로 인프라를 코드로 관리하는 실전 가이드입니다. 기본 문법, AWS 리소스, State 관리, Module, Workspace, Best Practices까지 실무 예제로 정리했습니다.

실무 경험 공유: 수동 인프라 관리를 Terraform으로 자동화하면서, 배포 시간을 2시간에서 10분으로 단축하고 인프라 오류를 90% 줄인 경험을 공유합니다.

들어가며: “인프라 관리가 복잡해요”

실무 문제 시나리오

시나리오 1: 콘솔에서 수동으로 클릭해요

AWS 콘솔에서 리소스를 생성합니다. 실수가 많고 재현이 어렵습니다. 시나리오 2: 환경마다 다르게 설정해요

개발/스테이징/프로덕션 설정이 달라 혼란스럽습니다. Terraform으로 일관성을 유지합니다. 시나리오 3: 인프라 변경 이력이 없어요

누가 언제 무엇을 바꿨는지 모릅니다. Terraform은 Git으로 관리합니다.

1. Terraform이란?

핵심 특징

Terraform은 인프라를 코드로 관리하는 IaC 도구입니다. 주요 장점:

선언적: 원하는 상태를 정의
멀티 클라우드: AWS, GCP, Azure 지원
State 관리: 현재 상태 추적
Plan: 변경 사항 미리 확인
모듈: 재사용 가능한 구성

2. 설치

설치

# Windows (Chocolatey)
choco install terraform
# macOS
brew install terraform
# 확인
terraform version

3. 기본 문법

첫 번째 리소스

# main.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}
provider "aws" {
  region = "us-east-1"
}
resource "aws_s3_bucket" "example" {
  bucket = "my-terraform-bucket-12345"
  tags = {
    Name        = "My bucket"
    Environment = "Dev"
  }
}

명령어

# 초기화
terraform init
# Plan (변경 사항 확인)
terraform plan
# Apply (적용)
terraform apply
# Destroy (삭제)
terraform destroy

4. 변수

변수 정의

# variables.tf
variable "region" {
  description = "AWS region"
  type        = string
  default     = "us-east-1"
}
variable "instance_type" {
  description = "EC2 instance type"
  type        = string
  default     = "t3.micro"
}
variable "tags" {
  description = "Common tags"
  type        = map(string)
  default     = {
    Environment = "Dev"
    Project     = "MyApp"
  }
}

변수 사용

# main.tf
provider "aws" {
  region = var.region
}
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = var.instance_type
  tags = var.tags
}

변수 값 전달

# CLI
terraform apply -var="region=ap-northeast-2"
# 파일
# terraform.tfvars
region = "ap-northeast-2"
instance_type = "t3.small"

5. Output

다음은 hcl 예제 코드입니다.

# outputs.tf
output "instance_id" {
  description = "EC2 instance ID"
  value       = aws_instance.web.id
}
output "instance_public_ip" {
  description = "Public IP"
  value       = aws_instance.web.public_ip
}
output "s3_bucket_name" {
  description = "S3 bucket name"
  value       = aws_s3_bucket.example.id
}

# Output 확인
terraform output
terraform output instance_public_ip

6. 실전 예제: VPC + EC2

다음은 hcl 예제 코드입니다.

# vpc.tf
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  tags = {
    Name = "main-vpc"
  }
}
resource "aws_subnet" "public" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.1.0/24"
  availability_zone       = "us-east-1a"
  map_public_ip_on_launch = true
  tags = {
    Name = "public-subnet"
  }
}
resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id
  tags = {
    Name = "main-igw"
  }
}
resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.main.id
  }
  tags = {
    Name = "public-rt"
  }
}
resource "aws_route_table_association" "public" {
  subnet_id      = aws_subnet.public.id
  route_table_id = aws_route_table.public.id
}
# ec2.tf
resource "aws_security_group" "web" {
  name        = "web-sg"
  description = "Security group for web server"
  vpc_id      = aws_vpc.main.id
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
  subnet_id     = aws_subnet.public.id
  vpc_security_group_ids = [aws_security_group.web.id]
  user_data = <<-EOF
              #!/bin/bash
              yum update -y
              yum install -y httpd
              systemctl start httpd
              systemctl enable httpd
              echo "Hello from Terraform" > /var/www/html/index.html
              EOF
  tags = {
    Name = "web-server"
  }
}

7. State 관리

Remote State (S3)

# backend.tf
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-lock"
    encrypt        = true
  }
}

State 명령어

# State 확인
terraform state list
# 특정 리소스 확인
terraform state show aws_instance.web
# State 이동
terraform state mv aws_instance.old aws_instance.new
# State에서 제거
terraform state rm aws_instance.web

8. Module

Module 정의

# modules/vpc/main.tf
variable "cidr_block" {
  type = string
}
variable "name" {
  type = string
}
resource "aws_vpc" "main" {
  cidr_block = var.cidr_block
  tags = {
    Name = var.name
  }
}
output "vpc_id" {
  value = aws_vpc.main.id
}

Module 사용

# main.tf
module "vpc" {
  source = "./modules/vpc"
  cidr_block = "10.0.0.0/16"
  name       = "production-vpc"
}
resource "aws_subnet" "public" {
  vpc_id     = module.vpc.vpc_id
  cidr_block = "10.0.1.0/24"
}

9. Workspace

터미널에서 다음 명령어를 실행합니다.

# Workspace 생성
terraform workspace new dev
terraform workspace new staging
terraform workspace new prod
# Workspace 전환
terraform workspace select dev
# 현재 Workspace
terraform workspace show
# Workspace 목록
terraform workspace list

Workspace별 설정

locals {
  env = terraform.workspace
  instance_type = {
    dev     = "t3.micro"
    staging = "t3.small"
    prod    = "t3.medium"
  }
}
resource "aws_instance" "web" {
  instance_type = local.instance_type[local.env]
}

취업·면접과 연결하기

State·Module·Workspace는 IaC·데브옵스 면접 빈출입니다. 기술 면접 완벽 대비 가이드와, 과제 병행은 코딩 테스트 완벽 대비 가이드와 같이 잡아 두면 좋습니다.

10. Terraform Core 내부: 그래프·의존성·apply

10.1 구성 → DAG(방향 비순환 그래프)

terraform plan은 먼저 모든 .tf를 합쳐 설정(Configuration)을 만들고, 각 resource·data·module 호출을 노드로 두고 의존성 엣지를 만듭니다. depends_on이 없어도 참조(aws_vpc.main.id)만으로 암시적 의존성이 생깁니다. 이 그래프가 적용 순서와 병렬화 가능 여부를 결정합니다.

10.2 State와 실제 인프라의 정렬

Terraform은 원하는 상태(desired)와 state에 기록된 현재 상태를 비교해 변경 집합을 만듭니다. Remote backend(S3+DynamoDB 잠금)를 쓰면 팀이 동시 apply로 state를 깨뜨리는 것을 줄일 수 있습니다. state drift(콘솔에서 수동 변경)가 생기면 다음 plan이 예상과 다르게 나오므로, 운영 표준은 Terraform만으로 변경하거나 import/refresh 절차를 문서화하는 것입니다.

10.3 `lifecycle`과 무중단 교체

resource "aws_launch_template" "app" {
  # ...
  lifecycle {
    create_before_destroy = true
  }
}

롤링·블루그린과 연계할 때는 리소스 타입별로 이름 변경 시 재생성 여부를 미리 확인해야 합니다. prevent_destroy는 실수로 destroy하는 것을 막는 안전장치로 쓰입니다.

10.4 `moved`·`import` 블록(1.1+)

리소스 주소를 바꿀 때 기존 state를 유지하려면 moved 블록으로 이전을 표현할 수 있습니다. 이미 클라우드에 존재하는 리소스를 코드로 가져올 때는 import 블록 또는 terraform import로 state에 연결합니다. 대규모 이전에서는 스테이징에서 먼저 검증하는 것이 안전합니다.

11. 프로덕션 패턴과 트러블슈팅

11.1 CI에서의 표준 흐름

terraform fmt -check — 포맷 고정
terraform validate — 구문·프로바이더 스키마
terraform plan -out=tfplan — 변경 미리보기(승인 아티팩트로 저장)
승인 후 terraform apply tfplan

환경별 workspace와 별도 state 키(prod/terraform.tfstate, dev/...)를 매핑해 두면 실수로 프로덕션 state를 건드리는 위험을 줄입니다.

11.2 자주 나는 오류

증상	원인 후보	대응
`Error acquiring the state lock`	다른 apply·중단된 CI	DynamoDB 잠금 레코드 확인, 동시 실행 금지
`Resource already exists`	코드와 실제 리소스 이름 충돌	import 또는 이름 변경
`Cycle` 에러	`depends_on`·모듈 출력 순환	그래프를 끊을 리소스 분리
Provider 버전 업 후 대규모 diff	스키마 변경	CHANGELOG 확인, `plan`을 스테이징에서 선행 검증
SG `cidr_blocks` 문법 오류	HCL에서 CIDR은 문자열	`"0.0.0.0/0"` 형태로 수정

11.3 보안 그룹·시크릿 운영

프로덕션에서는 SSH를 0.0.0.0/0에 개방한 예제는 교육용으로만 두고, 실제로는 Bastion·SSM Session Manager·VPN 뒤로 제한합니다. State에는 RDS 비밀번호 등이 들어갈 수 있으므로 S3 암호화·KMS·IAM 최소 권한을 기본값으로 둡니다.

정리 및 체크리스트

핵심 요약

Terraform: 인프라를 코드로 관리
선언적: 원하는 상태를 정의
State: 현재 상태 추적
Module: 재사용 가능한 구성
Workspace: 환경별 관리
멀티 클라우드: AWS, GCP, Azure

프로덕션 체크리스트

같이 보면 좋은 글

Kubernetes 실전 가이드
GitHub Actions CI/CD 가이드
AWS 완벽 가이드

이 글에서 다루는 키워드

Terraform, IaC, AWS, DevOps, Infrastructure, Cloud, Automation

자주 묻는 질문 (FAQ)

Q. Terraform vs CloudFormation, 어떤 게 나은가요?

A. Terraform은 멀티 클라우드를 지원합니다. CloudFormation은 AWS 전용입니다. 멀티 클라우드는 Terraform, AWS만 사용하면 둘 다 괜찮습니다.

Q. State 파일을 Git에 커밋해도 되나요?

A. 아니요, 절대 안 됩니다. 민감한 정보가 포함될 수 있습니다. S3 같은 Remote Backend를 사용하세요.

Q. 학습 곡선이 가파른가요?

A. 기본 문법은 간단합니다. 하지만 클라우드 지식이 필요합니다.

Q. 프로덕션에서 사용해도 되나요?

A. 네, 많은 기업에서 프로덕션 인프라를 Terraform으로 관리합니다.

심화 부록: 구현·운영 관점

이 부록은 앞선 본문에서 다룬 주제(「Terraform 실전 가이드 | IaC·AWS·State·Module·Workspace·Best Practices」)를 구현·런타임·운영 관점에서 다시 압축합니다. 도메인별 세부 구현은 글마다 다르지만, 입력 검증 → 핵심 연산 → 부작용(I/O·네트워크·동시성) → 관측의 흐름으로 장애를 나누면 원인 추적이 빨라집니다.

내부 동작과 핵심 메커니즘

flowchart TD
  A[입력·요청·이벤트] --> B[파싱·검증·디코딩]
  B --> C[핵심 연산·상태 전이]
  C --> D[부작용: I/O·네트워크·동시성]
  D --> E[결과·관측·저장]

sequenceDiagram
  participant C as 클라이언트/호출자
  participant B as 경계(런타임·게이트웨이·프로세스)
  participant D as 의존성(API·DB·큐·파일)
  C->>B: 요청/이벤트
  B->>D: 조회·쓰기·RPC
  D-->>B: 지연·부분 실패·재시도 가능
  B-->>C: 응답 또는 오류(코드·상관 ID)

불변 조건(Invariant): 버퍼 경계, 프로토콜 상태, 트랜잭션 격리, FD 상한 등 단계별로 문장으로 적어 두면 디버깅 비용이 줄어듭니다.
결정성: 순수 층과 시간·네트워크·스케줄에 의존하는 층을 분리해야 테스트와 장애 분석이 쉬워집니다.
경계 비용: 직렬화, 인코딩, syscall 횟수, 락 경합, 할당·GC, 캐시 미스를 의심 목록에 둡니다.
백프레셔: 생산자가 소비자보다 빠를 때 버퍼·큐·스트림에서 속도를 줄이는 신호를 어디에 둘지 정의합니다.

프로덕션 운영 패턴

영역	운영 관점 질문
관측성	요청 단위 상관 ID, 에러율·지연 p95/p99, 의존성 타임아웃·재시도가 대시보드에 보이는가
안전성	입력 검증·권한·비밀·감사 로그가 코드 경로마다 일관적인가
신뢰성	재시도는 멱등 연산에만 적용되는가, 서킷 브레이커·백오프·DLQ가 있는가
성능	캐시·배치 크기·커넥션 풀·인덱스·백프레셔가 데이터 규모에 맞는가
배포	롤백 룬북, 카나리/블루그린, 마이그레이션·피처 플래그가 문서화되어 있는가
용량	피크 트래픽·디스크·FD·스레드 풀 상한을 주기적으로 검증하는가

스테이징은 데이터 양·네트워크 RTT·동시성을 프로덕션에 가깝게 맞출수록 재현율이 올라갑니다.

확장 예시: 엔드투엔드 미니 시나리오

앞선 본문 주제(「Terraform 실전 가이드 | IaC·AWS·State·Module·Workspace·Best Practices」)를 배포·운영 흐름에 맞춰 옮긴 체크리스트입니다. 도메인에 맞게 단계 이름만 바꿔 적용할 수 있습니다.

입력 계약 고정: 스키마·버전·최대 페이로드·타임아웃·에러 코드를 경계에 둔다.
핵심 경로 계측: 요청 ID, 단계별 지연, 외부 호출 결과 코드를 로그·메트릭·트레이스에서 한 흐름으로 본다.
실패 주입: 의존성 타임아웃·5xx·부분 데이터·락 대기를 스테이징에서 재현한다.
호환·롤백: 설정/마이그레이션/클라이언트 버전을 되돌릴 수 있는지 확인한다.
부하 후 검증: 피크 대비 p95/p99, 에러율, 리소스 상한, 알림 임계값을 점검한다.

handle(request):
  ctx = newCorrelationId()
  validated = validateSchema(request)
  authorize(validated, ctx)
  result = domainCore(validated)
  persistOrEmit(result, idempotentKey)
  recordMetrics(ctx, latency, outcome)
  return result

문제 해결(Troubleshooting)

증상	가능 원인	조치
간헐적 실패	레이스, 타임아웃, 외부 의존성, DNS	최소 재현 스크립트, 분산 트레이스·로그 상관관계, 재시도·서킷 설정 점검
성능 저하	N+1, 동기 I/O, 락 경합, 과도한 직렬화, 캐시 미스	프로파일러·APM으로 핫스팟 확인 후 한 가지씩 제거
메모리 증가	캐시 무제한, 구독/리스너 누수, 대용량 버퍼, 커넥션 미반납	상한·TTL·힙/FD 스냅샷 비교
빌드·배포만 실패	환경 변수, 권한, 플랫폼 차이, lockfile	CI 로그와 로컬 diff, 런타임·이미지 버전 핀
설정 불일치	프로필·시크릿·기본값, 리전	스키마 검증된 설정 단일 소스와 배포 매트릭스 표준화
데이터 불일치	비멱등 재시도, 부분 쓰기, 캐시 무효화 누락	멱등 키·아웃박스·트랜잭션 경계 재검토

권장 순서: (1) 최소 재현 (2) 최근 변경 범위 축소 (3) 환경·의존성 차이 (4) 관측으로 가설 검증 (5) 수정 후 회귀·부하 테스트.

배포 전에는 git add → git commit → git push 후 npm run deploy 순서를 권장합니다.

이 글이 도움이 되셨나요?

여러분의 피드백은 더 나은 콘텐츠를 만드는 데 도움이 됩니다

문제가 있거나 개선 제안이 있으시면 연락처로 알려주세요.

Keyboard Shortcuts

이 글의 핵심

이 글의 핵심

들어가며: “인프라 관리가 복잡해요”

실무 문제 시나리오

누가 언제 무엇을 바꿨는지 모릅니다. Terraform은 Git으로 관리합니다.

1. Terraform이란?

핵심 특징

2. 설치

설치

3. 기본 문법

첫 번째 리소스

명령어

4. 변수

변수 정의

변수 사용

변수 값 전달

5. Output

6. 실전 예제: VPC + EC2

7. State 관리

Remote State (S3)

State 명령어

8. Module

Module 정의

Module 사용

9. Workspace

Workspace별 설정

취업·면접과 연결하기

10. Terraform Core 내부: 그래프·의존성·apply

10.1 구성 → DAG(방향 비순환 그래프)

10.2 State와 실제 인프라의 정렬

10.3 lifecycle과 무중단 교체

10.4 moved·import 블록(1.1+)

11. 프로덕션 패턴과 트러블슈팅

11.1 CI에서의 표준 흐름

11.2 자주 나는 오류

11.3 보안 그룹·시크릿 운영

정리 및 체크리스트

핵심 요약

프로덕션 체크리스트

같이 보면 좋은 글

이 글에서 다루는 키워드

자주 묻는 질문 (FAQ)

Q. Terraform vs CloudFormation, 어떤 게 나은가요?

Q. State 파일을 Git에 커밋해도 되나요?

Q. 학습 곡선이 가파른가요?

Q. 프로덕션에서 사용해도 되나요?

심화 부록: 구현·운영 관점

내부 동작과 핵심 메커니즘

프로덕션 운영 패턴

확장 예시: 엔드투엔드 미니 시나리오

문제 해결(Troubleshooting)

이 글이 도움이 되셨나요?

10.3 `lifecycle`과 무중단 교체

10.4 `moved`·`import` 블록(1.1+)