AWS와 Terraform으로 인프라를 코드로 관리하는 법 🏗️

콘솔 클릭 한 번으로 만든 서버, 누가 만들었는지 아무도 모른다.
코드로 남기지 않으면 그 인프라는 곧 유령이 된다.

코드 한 장으로 동일한 인프라를 반복 배포하는 IaC의 일관성과 통제감을 "설계도로 동시에 지어지는 도시"로 표현

 

🎯 이 글에서 다루는 것

• AWS가 무엇이고, 왜 클라우드의 표준이 되었는지
• Terraform이 무엇이고, IaC(Infrastructure as Code)가 왜 필요한지
• AWS + Terraform 조합이 만들어내는 자동화의 힘
• Terraform의 핵심 워크플로우 5단계 (init → plan → apply → destroy)
• 실무에서 팀이 함께 인프라를 관리하는 방법

---

📌 도입 / 배경

여러분이 AWS 콘솔에서 EC2 인스턴스를 손으로 만들었다고 상상해 보세요.

 

리전은 ap-northeast-2, 인스턴스 타입은 t3.medium, 보안 그룹 설정에 포트 22 오픈… 하나하나 클릭해서 완성. 뿌듯합니다. 그런데 6개월 뒤, 동일한 환경을 스테이징 서버로 하나 더 만들어야 한다면? 그때 설정이 뭐였더라?

 

이게 수동 인프라 관리의 함정입니다.

• 설정 기록이 없다
• 누가 무엇을 바꿨는지 추적이 안 된다
• 환경마다 미묘하게 달라진다
• 새 팀원이 오면 처음부터 다시 설명해야 한다

이 문제를 해결하기 위해 등장한 것이 바로 IaC(Infrastructure as Code), 그리고 그 대표 도구인 Terraform입니다.

---

🔍 AWS란 무엇인가?

AWS(Amazon Web Services) 는 아마존이 운영하는 글로벌 클라우드 컴퓨팅 플랫폼입니다. 전 세계 수십 개 리전에 데이터센터를 보유하고, 기업이 서버를 직접 사지 않아도 인터넷을 통해 컴퓨팅 자원을 빌려 쓸 수 있게 해줍니다.

AWS의 핵심 서비스

카테고리	서비스	한 줄 설명
컴퓨팅	EC2	가상 서버 (VM)
스토리지	S3	객체 스토리지 (파일 저장)
서버리스	Lambda	서버 없이 코드 실행
네트워크	VPC	가상 사설 네트워크
보안/접근제어	IAM	권한 관리
데이터베이스	RDS	관리형 관계형 DB

 

AWS의 가장 큰 특징은 사용한 만큼만 비용을 내는 구조입니다. 사용하지 않는 자원은 꺼두면 되고, 트래픽이 폭증하면 몇 분 안에 확장할 수 있습니다.

---

🔍 Terraform이란 무엇인가?

Terraform은 HashiCorp가 만든 IaC 도구입니다. 인프라를 코드로 정의하고 관리할 수 있게 해주는 도구로, AWS뿐만 아니라 Azure, GCP, 온프레미스 환경까지 하나의 언어로 관리할 수 있습니다.

HCL — Terraform의 언어

Terraform은 HCL(HashiCorp Configuration Language) 이라는 전용 언어를 사용합니다. JSON처럼 생겼지만 훨씬 읽기 쉽습니다.

# AWS 프로바이더 설정
provider "aws" {
  region = "ap-northeast-2"
}

# EC2 인스턴스 생성
resource "aws_instance" "web_server" {
  ami           = "ami-0c9c942bd7bf113a2"  # Amazon Linux 2
  instance_type = "t2.micro"

  tags = {
    Name = "MyWebServer"
  }
}

이 코드 한 파일이 AWS 콘솔에서 클릭 10번 해야 하는 작업을 대신합니다.

프로바이더(Provider) 개념

Terraform이 AWS와 대화하려면 프로바이더가 필요합니다. 프로바이더는 Terraform과 특정 클라우드 서비스를 연결해주는 플러그인입니다.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

AWS 외에도 azurerm(Azure), google(GCP) 등 수백 개의 프로바이더가 존재합니다.

---

🔍 AWS + Terraform, 왜 같이 써야 하나?

기업 환경에서 AWS를 쓰다 보면 금방 이런 상황이 생깁니다.

• 개발 팀 → 개발 환경 VPC 필요
• QA 팀 → 테스트 환경 VPC 필요
• 운영 팀 → 프로덕션 환경 VPC 필요

세 환경이 구조는 같지만 설정값이 조금씩 다릅니다. 수작업으로 각각 만들면?

• 실수가 생깁니다
• 나중에 세 환경이 조금씩 달라져서 "내 환경에서는 됐는데 왜 프로덕션에서 안 되지?" 문제가 생깁니다

Terraform으로 코드화하면 변수 하나만 바꿔서 세 환경을 동일하게 배포할 수 있습니다.

# variables.tf
variable "environment" {
  description = "배포 환경"
  type        = string
  default     = "dev"
}

variable "instance_type" {
  description = "EC2 인스턴스 타입"
  type        = string
  default     = "t2.micro"
}

---

💻 Terraform 기본 워크플로우 5단계

Terraform으로 AWS 인프라를 관리하는 핵심 워크플로우입니다.

1단계: 코드 작성 (Write)

.tf 파일에 인프라를 정의합니다. 앞서 본 HCL 코드 작성 단계입니다.

my-terraform-project/
├── main.tf          # 핵심 리소스 정의
├── variables.tf     # 변수 선언
├── outputs.tf       # 출력값 정의
└── provider.tf      # 프로바이더 설정

---

2단계: terraform init — 초기화

terraform init

이 명령어는 프로젝트를 처음 시작할 때 반드시 실행해야 합니다. 실행하면:

• .terraform/ 폴더 생성
• 필요한 프로바이더 플러그인 자동 다운로드
• 외부 모듈 초기화

Initializing provider plugins...
- Finding hashicorp/aws versions matching "~> 5.0"...
- Installing hashicorp/aws v5.31.0...
- Installed hashicorp/aws v5.31.0 (signed by HashiCorp)

💡 팁: .terraform/ 폴더는 .gitignore에 반드시 추가하세요. 크기도 크고 각 환경에서 직접 다운받아야 합니다.

---

3단계: terraform plan — 계획 확인

terraform plan

실제로 아무것도 변경하지 않고, 변경 예상 내용만 출력합니다. 배포 전 필수 검토 단계입니다.

Terraform will perform the following actions:

  # aws_instance.web_server will be created
  + resource "aws_instance" "web_server" {
      + ami           = "ami-0c9c942bd7bf113a2"
      + instance_type = "t2.micro"
      ...
    }

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

+는 생성, ~는 변경, -는 삭제를 의미합니다. -가 보이면 반드시 의도한 삭제인지 확인하세요.

---

4단계: terraform apply — 실제 배포

terraform apply

plan에서 확인한 내용을 실제 AWS에 적용합니다. 실행 전 한 번 더 확인을 요청합니다.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

배포가 완료되면 terraform.tfstate 파일이 생성/업데이트됩니다. 이 파일이 현재 인프라 상태를 기록하는 핵심 파일입니다.

⚠️ 주의: terraform apply -auto-approve로 확인 생략이 가능하지만, 프로덕션 환경에서는 절대 사용하지 마세요.

---

5단계: terraform destroy — 인프라 삭제

terraform destroy

생성한 모든 리소스를 삭제합니다. 테스트 환경 정리나 개발 완료 후 리소스 삭제에 활용합니다. AWS 비용 절감에 매우 효과적입니다.

---

🔍 실무 워크플로우 — 팀과 함께 관리하기

모듈화로 재사용성 높이기

공통 구성 요소는 모듈로 만들어 재사용합니다.

# VPC 모듈 재사용 예시
module "dev_vpc" {
  source      = "./modules/vpc"
  environment = "dev"
  cidr_block  = "10.0.0.0/16"
}

module "prod_vpc" {
  source      = "./modules/vpc"
  environment = "prod"
  cidr_block  = "10.1.0.0/16"
}

 

같은 VPC 모듈을 개발/프로덕션 환경에 재사용. 코드 중복 없이 일관성을 유지합니다.

---

원격 상태 관리 — S3 + DynamoDB

팀원 여러 명이 동시에 terraform apply를 실행하면 상태 파일 충돌이 발생합니다. 이를 방지하기 위해 원격 상태 관리를 설정합니다.

terraform {
  backend "s3" {
    bucket         = "my-terraform-state-bucket"
    key            = "prod/terraform.tfstate"
    region         = "ap-northeast-2"
    dynamodb_table = "terraform-lock"  # 동시 실행 방지 (Lock)
    encrypt        = true
  }
}

• S3: 상태 파일을 중앙에서 저장
• DynamoDB: 동시에 여러 사람이 apply하지 못하도록 잠금(Lock) 관리

---

Git + CI/CD와 연동

실무에서는 Terraform을 Git 브랜치 전략과 결합해 사용합니다.

feature 브랜치 → PR 생성 → terraform plan 자동 실행 → 코드 리뷰 → main 병합 → terraform apply 자동 실행

GitHub Actions나 GitLab CI를 활용하면 이 과정을 완전 자동화할 수 있습니다.

---

⚠️ 주의사항 / 흔한 실수

🔴 상태 파일을 Git에 커밋하지 마세요

terraform.tfstate에는 리소스 ID, IP, 심지어 비밀번호가 평문으로 들어있을 수 있습니다. 반드시 .gitignore에 추가하고 S3 같은 원격 백엔드를 사용하세요.

# .gitignore
*.tfstate
*.tfstate.backup
.terraform/

🔴 terraform destroy는 신중하게

프로덕션 환경에서 실수로 실행하면 모든 리소스가 삭제됩니다. prevent_destroy 설정을 중요 리소스에 추가하는 습관을 들이세요.

resource "aws_db_instance" "production" {
  lifecycle {
    prevent_destroy = true  # destroy 명령 실행 시 오류 발생
  }
}

🔴 Access Key를 코드에 하드코딩하지 마세요

# ❌ 절대 이렇게 하지 말 것
provider "aws" {
  access_key = "AKIAXXXXXXXXXXXXXXXX"
  secret_key = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
}

# ✅ 환경 변수 또는 IAM Role 사용
provider "aws" {
  region = "ap-northeast-2"
  # AWS CLI 환경 변수 또는 IAM Role로 자동 인증
}

---

✅ 정리 / 마무리

AWS와 Terraform의 조합을 정리하면 이렇습니다.

구분	내용
AWS	클라우드 리소스를 제공하는 플랫폼
Terraform	그 리소스를 코드로 관리하는 도구
핵심 워크플로우	init → plan → apply → destroy
팀 협업 핵심	S3 원격 상태 + DynamoDB Lock + Git 브랜치 전략
최대 강점	일관성, 재사용성, 변경 추적, 자동화

 

클라우드 인프라가 복잡해질수록 수작업 관리의 한계는 빠르게 드러납니다. Terraform으로 인프라를 코드로 관리하는 습관을 들이면, 환경이 늘어나도 자신 있게 배포하고 유지보수할 수 있습니다.

 

다음 단계로 추천하는 학습 방향:

• Terraform Module 레지스트리 활용 (registry.terraform.io)
• Terraform Cloud / Atlantis를 이용한 GitOps 파이프라인 구축
• terraform import로 기존 수동 생성 리소스를 코드로 가져오기