핵심 인사이트

1. 본질: IaC (Infrastructure as Code, 코드로서의 인프라)는 인프라 구성을 사람이 읽고 버전 관리할 수 있는 코드로 정의하는 패러다임이며, Terraform은 멀티 클라우드를 지원하는 가장 널리 사용되는 IaC 도구다. 불변 인프라(Immutable Infrastructure)는 "수정하지 않고 교체"하는 원칙으로 설정 드리프트(Configuration Drift)를 근본적으로 제거한다.
2. 가치: IaC는 인프라 프로비저닝을 자동화하고 재현 가능하게 만들어, 환경 간 불일치 문제("개발에선 됐는데 운영에서 안 됨")를 해결하며, GitOps와 결합하면 인프라 변경의 감사 추적(Audit Trail)이 완벽히 가능하다.
3. 판단 포인트: 기술사 시험에서는 IaC의 선언형 vs. 절차형 접근 방식, Terraform의 Plan-Apply-Destroy 워크플로우, 불변 인프라와 가변 인프라(Mutable Infrastructure)의 트레이드오프, GitOps 연계 방안을 논리적으로 서술해야 한다.

Ⅰ. 개요 및 필요성

전통적인 인프라 관리 방식에서는 시스템 관리자가 CLI나 GUI를 통해 수동으로 서버를 프로비저닝하고 설정을 변경하였다. 이 방식은 시간이 지남에 따라 "설정 드리프트(Configuration Drift)" 현상이 발생한다. 처음에는 동일하게 설정된 서버들이 개별 수동 패치·설정 변경으로 인해 서로 달라지고, 어느 서버에 무엇이 설치되어 있는지 아무도 정확히 알 수 없는 상태가 된다.

IaC는 이 문제를 해결하기 위해 인프라를 코드로 선언하여, Git으로 버전 관리하고, 자동화 파이프라인으로 일관되게 프로비저닝한다. HashiCorp의 Terraform은 HCL (HashiCorp Configuration Language)이라는 선언형 언어를 사용하여 AWS·Azure·GCP·온프레미스를 포함한 수백 개의 프로바이더를 단일 도구로 관리한다.

불변 인프라 원칙은 한 걸음 더 나아간다. 서버 설정을 변경해야 할 때 기존 서버를 수정하는 대신, 새 이미지를 빌드하고 새 인스턴스를 배포한 뒤 기존 인스턴스를 종료한다. 이렇게 하면 운영 환경이 항상 알려진 상태(Known State)를 유지한다.

📢 섹션 요약 비유: IaC는 건물 설계 도면이다. 건물을 처음 짓거나, 똑같은 건물을 100개 지을 때도 도면대로 짓기 때문에 결과가 항상 동일하다. 불변 인프라는 건물에 문제가 생기면 고치는 게 아니라 새 건물로 이사하는 방식이다.

Ⅱ. 아키텍처 및 핵심 원리

2-1. Terraform 워크플로우

┌──────────────────────────────────────────────────────────────────────┐
│                   Terraform 핵심 워크플로우                           │
├──────────────────────────────────────────────────────────────────────┤
│                                                                       │
│  HCL 코드 작성 (.tf 파일)                                            │
│       │                                                               │
│       ▼                                                               │
│  ┌─────────────────────────────────────────────────────────────────┐ │
│  │  terraform init  → Provider 플러그인 다운로드·초기화             │ │
│  └─────────────────────────────────────────────────────────────────┘ │
│       │                                                               │
│       ▼                                                               │
│  ┌─────────────────────────────────────────────────────────────────┐ │
│  │  terraform plan  → 현재 상태 vs. 원하는 상태 차이 계산 (Dry-Run)│ │
│  │                    변경 사항 미리보기 (No 실제 변경)              │ │
│  └─────────────────────────────────────────────────────────────────┘ │
│       │  변경 계획 검토 후 승인                                       │
│       ▼                                                               │
│  ┌─────────────────────────────────────────────────────────────────┐ │
│  │  terraform apply → 실제 인프라 변경 실행                         │ │
│  │                    terraform.tfstate 파일 업데이트               │ │
│  └─────────────────────────────────────────────────────────────────┘ │
│       │                                                               │
│       ▼ (정리 시)                                                     │
│  ┌─────────────────────────────────────────────────────────────────┐ │
│  │  terraform destroy → 관리 중인 인프라 전체 삭제                  │ │
│  └─────────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────────┘

2-2. Terraform HCL 구조 예시

# AWS EC2 인스턴스 선언형 정의 예시
provider "aws" {
  region = "ap-northeast-2"    # 서울 리전
}

resource "aws_instance" "web_server" {
  ami           = "ami-0c9c942bd7bf113a2"
  instance_type = "t3.micro"

  tags = {
    Name        = "web-server"
    Environment = var.environment
  }
}

2-3. 불변 인프라 vs. 가변 인프라 비교

📢 섹션 요약 비유: 가변 인프라는 낡은 옷을 계속 수선하는 것이고, 불변 인프라는 낡은 옷을 버리고 공장에서 새로 만든 새 옷으로 교체하는 것이다. 새 옷은 항상 공장에서 나온 완벽한 상태다.

Ⅲ. 비교 및 연결

3-1. IaC 도구 비교

3-2. GitOps와의 연계

GitOps는 Git 저장소를 단일 진실 원천(Single Source of Truth)으로 사용하여 인프라와 애플리케이션을 선언적으로 관리하는 운영 방식이다. Terraform 코드를 Git에 저장하고, PR (Pull Request) 기반 리뷰·승인 프로세스를 거쳐 terraform apply를 자동 실행한다.

3-3. Terraform State 관리

Terraform은 관리 중인 인프라 상태를 terraform.tfstate 파일에 저장한다. 팀 협업을 위해 Remote Backend(S3 + DynamoDB 잠금)를 사용하며, 상태 파일에는 민감 정보가 포함될 수 있어 암호화 및 접근 제어가 필수다.

📢 섹션 요약 비유: GitOps는 인프라 변경을 법원 판결처럼 처리하는 것이다. 변경안(PR)을 제출하면, 검토(리뷰)를 거쳐, 승인(머지)이 나야 실행된다. 모든 과정이 Git에 기록되어 누가 언제 무엇을 바꿨는지 영구 보존된다.

Ⅳ. 실무 적용 및 기술사 판단

4-1. 엔터프라이즈 Terraform 구조화 패턴

대규모 조직에서는 Terraform 코드를 모듈(Module) 단위로 재사용 가능하게 구성하고, 환경별(Dev·Staging·Prod) 분리된 State 파일로 관리한다. Terraform Cloud 또는 Spacelift를 활용하여 원격 실행·협업·정책 적용(Sentinel Policy)을 중앙화한다.

4-2. 보안 고려사항

4-3. 불변 인프라 구현 패턴

AWS에서 불변 인프라를 구현할 때: Packer로 AMI (Amazon Machine Image)를 빌드하고 → Terraform으로 새 Auto Scaling Group 생성 → 트래픽을 새 그룹으로 이전 → 기존 그룹 폐기. 이 패턴을 Blue/Green 불변 인프라 배포라고 한다.

📢 섹션 요약 비유: Terraform 모듈은 레고 키트의 표준 블록이다. 회사 전체가 동일한 블록 규격을 쓰면, 새 서비스를 만들 때마다 처음부터 설계하지 않고 검증된 블록을 가져다 조립하면 된다.

Ⅴ. 기대효과 및 결론

IaC와 불변 인프라의 결합은 인프라 관리의 패러다임을 "예술"에서 "공학"으로 전환시킨다. 설정 드리프트 제거, 완전한 재현 가능성, Git 기반 감사 추적, 빠른 롤백이 동시에 실현된다. Terraform의 멀티 클라우드 지원은 벤더 락인 없이 인프라를 일관되게 관리할 수 있는 기반을 제공한다.

기술사 시험에서는 ① IaC의 선언형 철학과 Terraform Plan-Apply 워크플로우, ② 불변 인프라의 설정 드리프트 해결 원리, ③ GitOps 연계를 통한 감사 추적 및 변경 통제, ④ 엔터프라이즈 Terraform 모듈화·보안 관리 방안을 체계적으로 서술해야 고득점 답안이 된다.

📢 섹션 요약 비유: IaC는 "건설 회사가 모든 건물을 도면으로 관리하는 것"이고, 불변 인프라는 "건물에 문제가 생기면 수리 대신 철거 후 신축"하는 방식이다. 둘을 합치면 항상 새것 같은 완벽한 상태의 인프라를 유지할 수 있다.

📌 관련 개념 맵

👶 어린이를 위한 3줄 비유 설명

1. IaC는 요리 레시피야. 레시피가 있으면 누가 만들어도, 어느 주방에서 만들어도 항상 같은 맛이 나. 인프라도 코드(레시피)가 있으면 어느 클라우드에서 실행해도 항상 똑같이 만들어져.
2. 불변 인프라는 "닳으면 수선하지 말고 새것으로 교체하는" 소모품 방식이야. 서버가 이상해지면 고치는 게 아니라, 새 서버를 완전히 새로 만들어서 교체해. 항상 새것 같은 상태를 유지할 수 있어.
3. GitOps는 인프라를 바꾸려면 설계도(코드)를 먼저 바꾸고, 팀원들의 검토와 승인을 받아야 하는 시스템이야. 누가 언제 무엇을 바꿨는지 Git에 다 기록되니까 나중에 문제가 생겨도 원인을 찾기 쉬워.