테라폼(Terraform) 이해하기

1. 테라폼이란 무엇인가?

"인프라를 코드로 관리한다 (Infrastructure as Code, IaC)"

"코드로 인프라를 모두 관리하기에, 코드가 곧 인프라다."

 

테라폼은 하시코프(HashiCorp)사가 만든 오픈 소스 도구로, 클라우드 인프라 구축의 사실상 업계 표준(Standard)입니다.

💡 핵심 철학: "무엇을(What)" 원해?

테라폼의 가장 큰 특징은 선언적(Declarative)이라는 점입니다.

구분	절차적 (Procedural)	선언적 (Declarative) - Terraform
방식	"A서버 켜고, IP 연결하고, 방화벽 열어." (순서 중시)	"난 웹 서버 1대와 열린 방화벽이 필요해." (결과 중시)
도구	쉘 스크립트, Ansible 등	Terraform, Kubernetes
특징	과정을 일일이 지시함	현재 상태와 목표 상태의 차이(Gap)만 계산하여 수행

핵심: 이미 서버가 있다면 건너뛰고, 없다면 만듭니다. 불필요한 중복 작업을 하지 않습니다.

⚙️ 아키텍처 구조

테라폼은 크게 두 부분으로 나뉩니다.

• 코어(Core): 사용자가 작성한 코드(설계도)를 해석하고 계획을 세웁니다.
• 프로바이더(Provider): AWS, GCP 같은 실제 클라우드와 API로 통신하여 리소스를 생성하는 '팔과 다리' 역할을 합니다.

---

2. 왜 써야 하는가? (4가지 핵심 가치)

과거 수동 작업의 비효율과 휴먼 에러를 해결하기 위해 사용합니다.

1. 시간 효율 (Speed): 수동으로 며칠 걸리던 작업을 코드 실행 한 번으로 수 분 내에 완료합니다. (반나절 이내 구축 가능)
2. 보안 (Security): Sentinel 같은 정책 도구를 통해 배포 전 코드를 검사하여 보안 사고를 예방합니다.
3. 멀티 클라우드 (Multi-Cloud): AWS, GCP, Azure, 온프레미스를 하나의 도구, 하나의 문법으로 통합 관리합니다.
4. 표준화 (Standardization): 검증된 모듈을 사용하여 누가 배포하든 항상 동일한 품질과 환경을 보장합니다.

---

3. 핵심 워크플로우 (The Workflow)

테라폼을 다룬다면 이 4단계 리듬을 반드시 기억해야 합니다. (핵심적으로는, Plan => Apply ; 플랜과 적용!)

1. terraform init (준비): 작업에 필요한 프로바이더(플러그인)를 다운로드합니다. (프로젝트 시작 시 1회만 하며 됨)
2. terraform plan (미리보기) ⭐: 가장 중요한 단계입니다. 코드를 실행하면 어떤 리소스가 생성/변경/삭제될지 시뮬레이션해줍니다.
   • 출력 예: Plan: 2 to add, 0 to change, 0 to destroy.
3. terraform apply (적용): yes를 입력하면 실제로 클라우드에 리소스를 생성합니다.
4. terraform destroy (삭제): 생성된 모든 리소스를 제거합니다. (운영 환경 주의!)

---

4. 실전 코드 작성법 (GCP 예시)

테라폼은 HCL(HashiCorp Configuration Language)을 사용합니다. JSON보다 읽기 쉽고 직관적입니다.

A. 파일 구조 (Best Practice)

보통 한 폴더에 다음 3가지 파일을 기본으로 둡니다.

• main.tf: 리소스(서버, 네트워크 등)를 정의하는 본체.
• variables.tf: 자주 바뀌는 값(Region, ID 등)을 변수로 분리.
• outputs.tf: 생성 후 확인할 값(IP 주소 등)을 출력.

B. 코드 예시: GCP 네트워크 생성

서울 리전에 pepsi-vpc라는 네트워크를 만드는 코드입니다.

📄 main.tf

Terraform

 

# 1. 프로바이더 설정 (GCP와 통신 선언)
provider "google" {
  project = "pepsi-migration-proj"
  region  = "asia-northeast3" # 서울 리전
}

# 2. VPC 네트워크 생성 (그릇 만들기)
resource "google_compute_network" "vpc_network" {
  name                    = "pepsi-core-vpc"
  auto_create_subnetworks = false # 정교한 제어를 위해 false 설정
}

# 3. 서브넷 생성 (실제 IP 대역 할당)
resource "google_compute_subnetwork" "subnetwork" {
  name          = "pepsi-seoul-subnet"
  ip_cidr_range = "10.0.1.0/24"
  region        = "asia-northeast3"
  network       = google_compute_network.vpc_network.id # 위에서 만든 VPC ID 참조
}

📄 variables.tf

Terraform

 

variable "region" {
  description = "기본 리전 설정"
  default     = "asia-northeast3"
}

C. 상태 파일 (terraform.tfstate) ⚠️

• 역할: 테라폼이 관리하는 '장부'입니다. 현재 인프라 상태와 코드의 매핑 정보를 담고 있습니다.
• 주의: 이 파일이 꼬이거나 삭제되면 테라폼은 인프라를 인식하지 못해 중복 생성하거나 에러를 냅니다.
• 관리: 실무에서는 절대 로컬 PC에 두지 않고, GCS(구글 스토리지) 버킷에 저장하여 팀원과 공유하고 안전하게 보호합니다(Backend 설정).

---

5. 실무 활용 시나리오 (Use Cases)

Scenario 1: 환경의 완벽한 복제 (Dev → Prod)

• 상황: 개발계에서 검증된 환경을 운영계에 똑같이 만들어야 합니다.
• 해결: main.tf 코드는 그대로 두고, 변수(variables.tf)만 개발용에서 운영용으로 바꿔서 apply 합니다. 토씨 하나 틀리지 않은 쌍둥이 환경이 만들어집니다.

Scenario 2: 멀티 클라우드 & 마이그레이션

• 상황: AWS의 DNS(Route53)를 사용하면서 백엔드는 GCP(Cloud Run)를 써야 합니다.
• 해결: 하나의 코드 파일에 provider "aws"와 provider "google"을 같이 씁니다. AWS 정보를 읽어와 GCP에 주입하는 과정을 한 번의 실행으로 자동화합니다.

Scenario 3: 재해 복구 (Disaster Recovery)

• 상황: 도쿄 리전(Main)이 지진으로 다운되었습니다. 오사카(DR)로 옮겨야 합니다.
• 해결: 코드에서 variable "region" 값만 '오사카'로 바꾸고 apply를 실행합니다. 수 분 안에 수백 대의 서버가 오사카에서 되살아납니다.