🏗️
Terraform (IaC) 치트시트

Terraform 최신 기준 초보자 완벽 가이드: 시스템 요구사양, HCL 문법 기초, init/plan/apply/destroy 4대 라이프사이클, 변수(Variables)·로컬(Locals)·출력(Outputs), 상태(State) 관리 및 S3+DynamoDB 원격 백엔드, 재사용 모듈(Module) 및 AWS/Docker 실전 인프라 프로비저닝
#terraform#iac#cloud#aws#hcl#devops#infrastructure#opentofu#docker#state최종 업데이트: 2026-10-09
Terraform (IaC) 치트시트 핵심 명령어 및 실전 가이드

## 1. 필수 사전 설치 요건 & 시스템 요구사양 (Prerequisites & System Requirements)

**Terraform**은 HashiCorp에서 개발한 세계 표준 **코드형 인프라(IaC, Infrastructure as Code)** 도구입니다. AWS, Azure, GCP, Kubernetes, Docker 등 다양한 클라우드 및 온프레미스 인프라 리소스를 HCL(HashiCorp Configuration Language) 코드로 선언하고, 버전 관리 및 자동 배포할 수 있습니다.

초보자도 클라우드 비용 없이 로컬에서 시작할 수 있도록 필수 사전 환경 구성부터 시작합니다.

### 💻 시스템 설치 및 실행 요구사양 (System Requirements)

| 항목 | 최소 사양 (Minimum) | 권장 사양 (Recommended) | 참고 및 비고 |
| :--- | :--- | :--- | :--- |
| **운영체제 (OS)** | Linux 64-bit (Ubuntu 20.04+, RHEL 8+), macOS 12+, Windows 10/11 64-bit | Linux (Ubuntu 22.04 LTS+) 또는 macOS (Apple Silicon) | POSIX 호환 64-bit OS 권장 |
| **CPU** | 1 코어 이상 (x86_64, ARM64) | 2 코어 ~ 4 코어 이상 | 대규모 인프라 DAG 의존성 그래프 계산 및 병렬 API 호출 |
| **메모리 (RAM)** | 1 GB 이상 | 2 GB ~ 4 GB 이상 | 수백 개 리소스 상태(State) 갱신 및 Plan Diff 비교 연산 |
| **디스크 (Storage)** | 500 MB 이상의 여유 공간 | 5 GB ~ 10 GB 이상의 고속 SSD | 프로바이더 플러그인 캐시(`.terraform/providers`) 및 모듈 저장소 |
| **네트워크 / 런타임** | Terraform 1.9+ 또는 OpenTofu 1.8+ CLI 단일 바이너리 | tfenv (다중 버전 관리자) 권장 | 아웃바운드 HTTPS (Terraform Registry 및 클라우드 API 443 포트) |

---

### 📦 OS별 Terraform CLI 설치 방법

Terraform은 단일 실행 바이너리로 배포되므로 설치가 매우 간편합니다:

```bash
# 🍏 [1] macOS (Homebrew)
brew tap hashicorp/tap
brew install hashicorp/tap/terraform

# 🐧 [2] Linux (Ubuntu / Debian)
sudo apt-get update && sudo apt-get install -y gnupg software-properties-common curl
curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt-get update && sudo apt-get install -y terraform

# 🪟 [3] Windows (PowerShell - winget 또는 choco)
winget install Hashicorp.Terraform
# 또는: choco install terraform

# ⚡ [4] 다중 버전 관리 도구 tfenv 사용 시 (강력 추천)
# 프로젝트별로 Terraform 버전을 다르게 관리할 때 필수
git clone --depth=1 https://github.com/tfutils/tfenv.git ~/.tfenv
echo 'export PATH="$HOME/.tfenv/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

tfenv install 1.9.5
tfenv use 1.9.5

# 설치 확인
terraform -version
```

---

### 🔑 클라우드 공급자(AWS) 인증 환경 설정

AWS 인프라를 프로비저닝할 경우, CLI 환경에서 인증 토큰을 읽을 수 있도록 설정합니다:

```bash
# 방법 1: AWS CLI 공식 설정 도구
aws configure
# AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
# AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
# Default region name [None]: ap-northeast-2
# Default output format [None]: json

# 방법 2: 터미널 환경 변수로 직접 주입
export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
export AWS_DEFAULT_REGION="ap-northeast-2"
```

---

## 2. 직관적인 멘탈 모델 (Mental Model & Architecture)

Terraform은 **원하는 인프라의 최종 상태(Desired State)**를 코드로 정의하면, **현재 인프라의 실제 상태(Current State)**와 비교하여 차이점만 자동으로 계산해 적용하는 **선언적(Declarative) 엔진**입니다.

```text
[Terraform 워크플로우 멘탈 모델]

 ┌─────────────────┐
 │ main.tf (HCL)   │ ──(작성)──► "어떤 인프라를 만들 것인가?" (선언적 코드)
 └────────┬────────┘
          │
          ▼ 1. terraform init
 ┌─────────────────┐
 │ .terraform/     │ ──(다운로드)──► AWS/Docker Provider 플러그인 & 모듈 초기화
 └────────┬────────┘
          │
          ▼ 2. terraform plan
 ┌─────────────────┐
 │ Plan Diff Report│ ──(비교)──► Desired State (코드) vs Current State (실제 클라우드)
 └────────┬────────┘             결과: +2 to add, ~1 to change, -0 to destroy
          │
          ▼ 3. terraform apply
 ┌─────────────────┐             ┌──────────────────────────────────────────┐
 │ Cloud Resources │ ──(호출)──► │ AWS VPC, EC2, S3, Docker Container 생성  │
 └────────┬────────┘             └──────────────────────────────────────────┘
          │
          ▼ 4. 상태 저장
 ┌─────────────────┐
 │ terraform.      │ ──(동기화)──► 실제 프로비저닝된 리소스의 ID, IP, 속성을
 │ tfstate         │              JSON 형식의 단일 진실 공급원(Single Source of Truth)으로 보관
 └─────────────────┘
```

### 🔑 Terraform 핵심 4대 구성요소
1. **Provider (공급자)**: AWS, Azure, GCP, Docker, Kubernetes 등 대상 플랫폼의 API와 통신하는 플러그인.
2. **Resource (리소스)**: VPC, EC2, S3 버킷, 도커 컨테이너 등 실제로 생성하고 관리할 인프라 객체.
3. **State (상태 파일)**: 코드와 실제 클라우드 인프라 리소스를 1:1로 매핑해두는 JSON 메타데이터 (`terraform.tfstate`).
4. **Data Source (데이터 소스)**: 이미 클라우드에 존재하는 리소스(예: 최신 Ubuntu AMI ID, 기존 VPC ID)를 읽어와 코드에서 참조.

---

## 3. [초보자 1단계] 헬로월드: 로컬 파일 프로바이더로 무과금 즉시 실습

클라우드 계정이나 결제 카드 등록 없이 내 컴퓨터 로컬 환경에서 Terraform의 전체 라이프사이클(`init ➔ plan ➔ apply ➔ destroy`)을 즉시 실습할 수 있는 최소 동작 예제입니다.

### 📝 완전한 실행 코드 (`main.tf`)

작업용 빈 폴더(`terraform-quickstart/`)를 생성하고 아래 `main.tf` 파일을 작성합니다:

```hcl
# 1. 테라폼 설정 블록 및 요구 프로바이더 명시
terraform {
  required_version = ">= 1.5.0"

  required_providers {
    # 로컬 파일 시스템을 조작하는 공식 local 프로바이더
    local = {
      source  = "hashicorp/local"
      version = "~> 2.5.0"
    }
  }
}

# 2. 로컬 파일 리소스 정의
resource "local_file" "hello_world" {
  filename = "${path.module}/lucky_output.txt"
  content  = "안녕하세요! LuckyTechWorld Terraform 퀵스타트 실습 파일입니다.\n생성 시각: 2026-10-09\n"

  # 파일 권한 설정 (읽기/쓰기)
  file_permission = "0644"
}

# 3. 생성 결과 출력 (Output)
output "created_file_name" {
  description = "성공적으로 생성된 파일의 경로"
  value       = local_file.hello_world.filename
}
```

### 💻 터미널 명령어 실행 단계

```bash
# 1. 프로바이더 플러그인 초기화 및 다운로드
terraform init

# 2. 변경 계획 확인 (Dry-run 실행 계획 검토)
terraform plan

# 3. 실제 리소스 프로비저닝 (자동 승인 옵션: -auto-approve)
terraform apply -auto-approve

# 4. 생성된 파일 확인
cat lucky_output.txt

# 5. 리소스 정리 및 삭제
terraform destroy -auto-approve
```

### 🖥️ 예상 콘솔 출력 결과

```text
$ terraform init
Initializing the backend...
Initializing provider plugins...
- Finding hashicorp/local versions matching "~> 2.5.0"...
- Installing hashicorp/local v2.5.1...
- Installed hashicorp/local v2.5.1 (signed by HashiCorp)

Terraform has been successfully initialized!

$ terraform apply -auto-approve
Terraform used the selected providers to generate the following execution plan.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.hello_world will be created
  + resource "local_file" "hello_world" {
      + content         = "안녕하세요! LuckyTechWorld Terraform 퀵스타트 실습 파일입니다.\n생성 시각: 2026-10-09\n"
      + file_permission = "0644"
      + filename        = "./lucky_output.txt"
      + id              = (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + created_file_name = "./lucky_output.txt"

local_file.hello_world: Creating...
local_file.hello_world: Creation complete after 0s [id=3b98e...]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Outputs:

created_file_name = "./lucky_output.txt"
```

> **포인트**: 실행 후 디렉토리에 `.terraform/` (프로바이더 플러그인 캐시), `.terraform.lock.hcl` (의존성 잠금 파일), 그리고 `terraform.tfstate` (인프라 상태 파일)이 생성된 것을 확인할 수 있습니다.

---

## 4. [2단계] HCL 핵심 문법: 변수(Variables), 로컬(Locals), 출력(Outputs) & 의존성

하드코딩을 피하고 환경별(개발/운영)로 유연하게 인프라를 재사용하기 위해 **입력 변수(Variables)**, **중간 계산값(Locals)**, **출력값(Outputs)**을 분리합니다.

### 📝 파일 분리 모범 구조

```text
├── main.tf          # 메인 리소스 선언
├── variables.tf     # 입력 변수 타입 및 기본값 선언
├── terraform.tfvars # 실제 주입할 변수 값 (Git 커밋 주의)
└── outputs.tf       # 배포 후 확인할 주요 결과값
```

#### 1. `variables.tf` (변수 정의)
```hcl
variable "environment" {
  type        = string
  description = "배포 환경 (dev, stage, prod)"
  default     = "dev"

  validation {
    condition     = contains(["dev", "stage", "prod"], var.environment)
    error_message = "environment 값은 dev, stage, prod 중 하나여야 합니다."
  }
}

variable "server_count" {
  type        = number
  description = "생성할 인스턴스 수량"
  default     = 2
}

variable "allowed_ips" {
  type        = list(string)
  description = "접근 허용 IP 대역 목록"
  default     = ["10.0.0.0/16", "192.168.1.0/24"]
}
```

#### 2. `main.tf` (Locals 및 리소스 참조)
```hcl
locals {
  # 변수들을 조합하여 공통 태그 및 프로젝트 접두사 생성
  service_name = "lucky-api"
  app_prefix   = "${local.service_name}-${var.environment}"

  common_tags = {
    Environment = var.environment
    ManagedBy   = "Terraform"
    Project     = local.service_name
  }
}

# count 반복문을 사용한 다중 파일 생성
resource "local_file" "server_configs" {
  count    = var.server_count
  filename = "${path.module}/server_${count.index + 1}.conf"
  content  = "Server Hostname: ${local.app_prefix}-${count.index + 1}\nAllowed CIDR: ${join(", ", var.allowed_ips)}\n"
}

# 암시적 의존성: server_configs 생성이 완료된 후 파일 요약본 생성
resource "local_file" "manifest" {
  filename = "${path.module}/deployment_manifest.json"
  content = jsonencode({
    prefix    = local.app_prefix
    total     = var.server_count
    tags      = local.common_tags
    files     = local_file.server_configs[*].filename
  })

  # 명시적 의존성이 필요한 경우 depends_on 추가 (대부분은 속성 참조로 자동 해결됨)
  depends_on = [local_file.server_configs]
}
```

#### 3. `outputs.tf` (출력값 정의)
```hcl
output "deployed_files" {
  description = "생성된 모든 서버 설정 파일 목록"
  value       = local_file.server_configs[*].filename
}

output "manifest_file" {
  description = "생성된 매니페스트 파일 경로"
  value       = local_file.manifest.filename
}
```

### 💻 실행 및 변수 동적 주입

```bash
# 1. 명령줄에서 변수 즉시 재정의 (-var)
terraform apply -var="environment=prod" -var="server_count=3" -auto-approve

# 2. 특정 변수 출력값만 질의
terraform output -json deployed_files
```

---

## 5. [3단계] 실전 클라우드 프로비저닝: AWS VPC, Security Group & EC2 인스턴스

실무에서 가장 널리 쓰이는 패턴으로, AWS 계정에 **네트워크(VPC, Subnet, IGW), 보안 그룹(Security Group), 최신 Ubuntu AMI 자동 조회, EC2 가상머신**을 원클릭으로 구축합니다.

### 📝 완전한 AWS 인프라 코드 (`aws_infra.tf`)

```hcl
terraform {
  required_version = ">= 1.5.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.50.0"
    }
  }
}

provider "aws" {
  region = "ap-northeast-2" # 서울 리전
}

# 1. VPC 네트워크 생성
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name = "lucky-vpc-prod"
  }
}

# 2. 퍼블릭 서브넷 생성
resource "aws_subnet" "public" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.1.0/24"
  availability_zone       = "ap-northeast-2a"
  map_public_ip_on_launch = true # 공인 IP 자동 할당

  tags = {
    Name = "lucky-public-subnet-2a"
  }
}

# 3. 인터넷 게이트웨이(IGW) 및 라우팅 테이블 연결
resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.main.id

  tags = {
    Name = "lucky-igw"
  }
}

resource "aws_route_table" "public_rt" {
  vpc_id = aws_vpc.main.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.igw.id
  }

  tags = {
    Name = "lucky-public-rt"
  }
}

resource "aws_route_table_association" "public_assoc" {
  subnet_id      = aws_subnet.public.id
  route_table_id = aws_route_table.public_rt.id
}

# 4. 웹 서버 보안 그룹 (HTTP 80, SSH 22 허용)
resource "aws_security_group" "web_sg" {
  name        = "lucky-web-sg"
  description = "Allow HTTP and SSH inbound traffic"
  vpc_id      = aws_vpc.main.id

  ingress {
    description = "HTTP from anywhere"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "SSH from admin"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"] # 실무에서는 회사 공인 IP로 제한 권장
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "lucky-web-sg"
  }
}

# 5. Data Source: 최신 공식 Ubuntu 22.04 LTS AMI 자동 검색
data "aws_ami" "ubuntu" {
  most_recent = true
  owners      = ["099720109477"] # Canonical 공식 계정 ID

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
}

# 6. EC2 인스턴스 생성 및 초기화 스크립트(user_data) 주입
resource "aws_instance" "web_server" {
  ami                    = data.aws_ami.ubuntu.id
  instance_type          = "t3.micro"
  subnet_id              = aws_subnet.public.id
  vpc_security_group_ids = [aws_security_group.web_sg.id]

  # 서버 기동 시 Nginx 자동 설치 및 웰컴 페이지 배포
  user_data = <<-EOF
              #!/bin/bash
              apt-get update -y
              apt-get install -y nginx
              echo "<h1>Welcome to LuckyTechWorld Terraform Web Server!</h1>" > /var/www/html/index.html
              systemctl enable --now nginx
              EOF

  tags = {
    Name = "lucky-web-server"
  }
}

# 7. 배포 완료 후 공인 IP 출력
output "web_public_ip" {
  description = "웹 서버 접속용 공인 IP 주소"
  value       = aws_instance.web_server.public_ip
}

output "web_url" {
  description = "브라우저 접속 URL"
  value       = "http://${aws_instance.web_server.public_ip}"
}
```

---

## 6. [4단계] 원격 백엔드(Remote Backend) & State Lock (S3 + DynamoDB)

로컬 머신에 `terraform.tfstate` 파일을 두고 작업하면 팀원 간 상태 동기화가 불가능하고, 동시에 `terraform apply`를 실행할 경우 인프라 상태가 깨집니다. 실무에서는 **AWS S3(원격 저장소)**와 **DynamoDB(동시 실행 방지 분산 락)**를 결합하여 백엔드를 구성합니다.

```text
[S3 + DynamoDB Remote State 아키텍처]

  팀원 A (terraform apply) ───┐
                               ├──► [DynamoDB Lock 테이블] (LockID 획득 성공 ➔ 작업 진행)
  팀원 B (terraform apply) ───┘    └─► (Lock 충돌 발생 시: "Acquiring state lock: Resource busy" 에러로 안전 차단)
                                            │
                                            ▼
                                   [S3 Bucket: tfstate]
                                   • AES-256 서버 암호화
                                   • 버전 관리(Versioning)로 실수 복구
```

### 📝 원격 백엔드 설정 코드 (`backend.tf`)

```hcl
terraform {
  backend "s3" {
    bucket         = "lucky-terraform-remote-states"   # 사전에 생성된 S3 버킷명
    key            = "services/lucky-api/terraform.tfstate" # 저장될 경로
    region         = "ap-northeast-2"
    encrypt        = true                              # 서버 측 암호화 (KMS/AES256)
    dynamodb_table = "lucky-terraform-locks"           # 상태 락용 DynamoDB 테이블 (LockID 키 필수)
  }
}
```

### 🛠️ 핵심 State 관리 CLI 명령어 모음

```bash
# 1. 로컬 상태 파일을 원격 S3 백엔드로 마이그레이션
terraform init -migrate-state

# 2. 현재 상태 파일에 등록된 모든 리소스 식별자 조회
terraform state list

# 3. 특정 리소스의 세부 상태 JSON 속성 확인
terraform state show aws_instance.web_server

# 4. 실제 클라우드 리소스는 남겨두고 테라폼 관리 대상에서만 제외 (State 삭제)
terraform state rm aws_instance.web_server

# 5. 기존에 콘솔로 수동 생성한 클라우드 리소스를 테라폼 코드로 가져오기 (Import)
terraform import aws_instance.web_server i-0123456789abcdef0

# 6. CI/CD 작업 중단 등으로 락이 풀리지 않을 때 강제 락 해제
terraform force-unlock <LOCK-ID>
```

---

## 7. [5단계] 재사용 가능한 모듈(Module) 패턴 & 멀티 환경(dev/prod) 분리

반복되는 인프라 구성(예: 웹 서버 클러스터, 데이터베이스)은 **자식 모듈(Child Module)**로 캡슐화하고, `environments/dev`와 `environments/prod`에서 각기 다른 파라미터로 호출합니다.

### 📁 권장 프로젝트 디렉토리 구조

```text
lucky-infrastructure/
├── modules/
│   └── ec2_web/
│       ├── main.tf
│       ├── variables.tf
│       └── outputs.tf
└── environments/
    ├── dev/
    │   ├── main.tf
    │   ├── variables.tf
    │   └── terraform.tfvars
    └── prod/
        ├── main.tf
        ├── variables.tf
        └── terraform.tfvars
```

### 📝 1. 모듈 정의 (`modules/ec2_web/main.tf`)

```hcl
variable "instance_name" { type = string }
variable "instance_type" { type = string, default = "t3.micro" }
variable "subnet_id"     { type = string }

resource "aws_instance" "this" {
  ami           = "ami-0c2acfcb2ac4d02a0" # 예시 AMI
  instance_type = var.instance_type
  subnet_id     = var.subnet_id

  tags = {
    Name = var.instance_name
  }
}

output "instance_id" {
  value = aws_instance.this.id
}
```

### 📝 2. 개발 환경에서 모듈 호출 (`environments/dev/main.tf`)

```hcl
module "dev_web_server" {
  source = "../../modules/ec2_web"

  instance_name = "lucky-web-dev"
  instance_type = "t3.micro"
  subnet_id     = "subnet-01234567"
}

output "dev_server_id" {
  value = module.dev_web_server.instance_id
}
```

---

## 8. 실무 주의사항 & 프로덕션 체크리스트 (Best Practices)

### 🚨 1. 절대 하지 말아야 할 실수 & 트러블슈팅

1. **State 파일을 Git 리포지토리에 커밋하지 마세요**:
   - `terraform.tfstate` 파일에는 데이터베이스 암호, 민감한 API 토큰 등이 **평문(Plaintext)**으로 기록됩니다.
   - 프로젝트 루트의 `.gitignore` 파일에 반드시 아래 항목을 포함하세요:
     ```gitignore
     # Terraform 무시 목록
     .terraform/
     *.tfstate
     *.tfstate.*
     crash.log
     *.tfvars
     !example.tfvars
     override.tf
     override.tf.json
     ```
2. **State Lock 충돌 에러 (`Error: Error acquiring the state lock`)**:
   - 이전 작업이 강제 종료되었거나 다른 팀원이 배포 중일 때 발생합니다.
   - 실제로 다른 작업이 진행 중이 아님을 확인한 후, 에러 메시지에 표시된 Lock ID를 이용해 해제합니다:
     ```bash
     terraform force-unlock <LOCK-ID>
     ```

---

### 🛡️ 2. 프로덕션 안전장치: 리소스 수명주기(Lifecycle) 규칙

실수로 데이터베이스나 중요 스토리지 리소스가 삭제(`destroy`)되는 참사를 코드로 원천 차단합니다.

```hcl
resource "aws_db_instance" "production_db" {
  allocated_storage = 20
  engine            = "mysql"
  instance_class    = "db.t3.medium"
  db_name           = "luckydb"
  # ...

  lifecycle {
    # 1. 실수로 terraform destroy 실행 시 삭제 거부 (가장 중요한 안전장치)
    prevent_destroy = true

    # 2. 다운타임 없이 리소스를 교체할 때 새 리소스를 먼저 생성 후 기존 리소스 삭제
    create_before_destroy = true

    # 3. 외부 자동화 도구로 변경된 태그 등의 드리프트 무시
    ignore_changes = [
      tags["LastUpdated"]
    ]
  }
}
```

---

### 💰 3. 프로덕션 운영 & CI/CD 체크리스트

| 점검 항목 | 권장 설정 및 실무 가이드 |
| :--- | :--- |
| **코드 포맷 및 문법 검증** | 커밋 전 항상 `terraform fmt -recursive` 및 `terraform validate`를 실행하여 팀 컨벤션을 통일합니다. |
| **드리프트 감지 (Drift Detection)** | 콘솔에서 누군가 수동으로 리소스를 변경했는지 정기적으로 감지합니다: `terraform plan -detailed-exitcode`. |
| **CI/CD 파이프라인 분리** | Pull Request 단계에서는 `terraform plan` 결과를 PR 코멘트로 자동 출력하고, Main 브랜치 머지 시에만 `terraform apply`를 자동 실행합니다. |
| **비용 예측 도구 (Infracost)** | PR 단계에서 인프라 변경에 따른 예상 AWS 월 청구 비용 증감($)을 자동으로 계산하여 과도한 인스턴스 과금을 사전에 차단합니다. |
| **보안 정적 분석 (Tfsec / Trivy)** | `trivy config .` 또는 `tfsec .` 도구를 실행하여 열려있는 0.0.0.0/0 보안 그룹이나 암호화되지 않은 S3 버킷을 배포 전에 자동 감지합니다. |
💬
Terraform (IaC) 치트시트

의견 및 질문

댓글 수정

댓글 삭제
