Cloud & DevOps

Terraform 입문 — 인프라를 코드로 관리하기

한 줄 요약: Terraform은 AWS, GCP, Azure 등 클라우드 인프라를 코드(.tf 파일)로 정의하고, terraform apply 한 명령으로 프로비저닝하는 IaC(Infrastructure as Code) 도구다. 수동으로 AWS 콘솔에서 서버를 만드는 대신, 코드로 인프라를 관리하면 재현 가능성, 버전 관리, 코드 리뷰가 가능해진다. 인프라를 수동으로 관리하면 재현 불가능, 문서화 누락, 환경 차이 문제가 생깁니다.

by Lee발행: 2026-04-12

한 줄 요약: Terraform은 AWS, GCP, Azure 등 클라우드 인프라를 코드(.tf 파일)로 정의하고, terraform apply 한 명령으로 프로비저닝하는 IaC(Infrastructure as Code) 도구다.

수동으로 AWS 콘솔에서 서버를 만드는 대신, 코드로 인프라를 관리하면 재현 가능성, 버전 관리, 코드 리뷰가 가능해진다. 이 가이드는 Terraform의 핵심 개념과 실전 워크플로우를 정리한다.

IaC가 필요한 이유

인프라를 수동으로 관리하면 재현 불가능, 문서화 누락, 환경 차이 문제가 생깁니다. Terraform으로 인프라를 코드로 선언하면 Git으로 버전 관리하고, 동일한 환경을 반복 생성할 수 있습니다.

Terraform의 워크플로우는 Write → Plan → Apply의 3단계다. .tf 파일에 원하는 인프라 상태를 선언하고, terraform plan으로 변경 사항을 미리 확인한 뒤, terraform apply로 실제 적용한다. 핵심은 '선언적'이라는 것 — 어떻게 만들지가 아니라 무엇을 원하는지를 정의한다.

AWS EC2 인스턴스 생성 예시
# main.tf
provider "aws" {
  region = "ap-northeast-2"  # 서울
}

resource "aws_instance" "app" {
  ami           = "ami-0c9c942bd7bf113a2"
  instance_type = "t3.micro"
  tags = { Name = "my-app-server" }
}

resource "aws_security_group" "app_sg" {
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

State 파일은 Terraform이 현재 인프라 상태를 추적하는 JSON 파일이다. 로컬에 저장하면 팀 협업이 불가능하므로, S3 + DynamoDB 또는 Terraform Cloud를 사용해 원격 state를 관리한다. State 파일에는 비밀 정보(DB 비밀번호 등)가 포함될 수 있으므로 암호화 저장이 필수다.

기본 개념

Provider: AWS, GCP 등 클라우드 제공자
Resource: 생성할 인프라 (EC2, S3 등)
State: 현재 인프라 상태 추적
Plan/Apply: 변경사항 미리보기 후 적용

모듈화와 환경 분리

모듈로 반복되는 인프라 패턴을 재사용한다. VPC, ECS 클러스터, RDS 인스턴스 등을 모듈로 만들어 dev/staging/prod 환경에서 변수만 바꿔 사용한다. Workspaces 또는 디렉토리 분리로 환경을 관리한다.

주의: terraform destroy는 모든 리소스를 삭제한다. 프로덕션 환경에서는 절대 실행하지 말 것. prevent_destroy = true lifecycle 설정으로 중요 리소스의 실수 삭제를 방지하라.

Terraform 대안

Pulumi: TypeScript/Python/Go 등 범용 언어로 인프라를 정의한다. 프로그래밍 언어의 조건문, 루프, 함수를 그대로 사용할 수 있어 Terraform의 HCL보다 표현력이 높다. AWS CDK: AWS 전용이지만 TypeScript로 CloudFormation을 생성한다. OpenTofu: Terraform의 오픈소스 포크로, HashiCorp의 라이선스 변경(BSL) 이후 대안으로 떠올랐다. Terraform과 거의 호환되며 Linux Foundation이 관리한다.

1인 개발자 관점에서 이 주제가 왜 중요한가

이 글의 주제(Terraform 입문 — 인프라를 코드로 관리하기)를 다룰 때 저는 버셀 + 깃허브 액션으로 자동 배포를 운영하는 입장 관점에서 봅니다. 단순히 새 기능을 소개하는 입장이 아니라, 12개 한국어 사이트를 1인으로 운영하면서 매일 클로드 코드를 켜두고 작업하는 입장이라 의사결정의 기준이 다소 좁고 실용적인 편입니다. 신기술이 출시될 때마다 곧바로 도입하기보다는 우선 한두 사이트에 시범 도입해 두고, 운영 부담이 늘지 않는지 며칠 지켜본 뒤 전체 확산을 결정하는 식입니다.

가장 자주 보는 변수는 12개 사이트를 동시에 운영할 때 변수 분리 비용, 그리고 한국어 응답 품질의 미세한 한계입니다. 두 변수는 신기술을 도입할지 말지 결정할 때 거의 매번 영향을 줍니다. 글의 본문은 위의 두 축을 직접 명시하지는 않지만, 본문에서 다루는 항목을 이 축에 비춰 보시면 본인 환경에 맞는지 빠르게 판단할 수 있습니다. 특히 한국 결제 시 VAT 10% 환급 절차 같은 운영 변수는 도구 자체 성능보다 더 큰 영향을 주는 경우가 많기 때문에 본문 비교표를 볼 때 같이 떠올리시면 좋습니다.

한 가지 더 강조하면, Cloud & DevOps 영역의 글을 읽을 때 저는 본문이 다루는 도구·서비스가 ① 한국 결제 가능 여부 ② 한국어 응답 품질 ③ 종량제 비용의 예측 가능성 ④ 1인 개발자 학습 시간 대비 효과, 네 항목을 모두 충족해야 실제 도입을 결정합니다. 네 항목 중 하나라도 명확하지 않으면 도입을 1~2주 미루는 편이고, 그 사이 같은 카테고리의 다른 글도 확인합니다.

본문의 각 비교·코드·체크리스트는 이 네 항목 중 어느 부분에 영향을 주는지 의식하면서 보시면 더 빠르게 결론에 도달하실 수 있습니다. 본 사이트의 다른 Cloud & DevOps 글과 함께 보시면 같은 평가 축이 반복되는 것을 확인하실 수 있습니다. 토픽 페이지 또는 같은 카테고리 태그를 따라가시면 동일한 평가 기준이 적용된 글을 한 번에 모아 보실 수 있습니다.

본인 환경에 적용하기 전 확인할 체크포인트

본문의 내용을 본인 환경에 적용하기 전에 다음 항목을 빠르게 확인하시면 도입 실패 가능성을 줄일 수 있습니다.

공식 문서 버전 일치 — 본문 작성 시점과 현재 배포 버전이 다른 경우, 같은 명령어가 다르게 동작할 수 있습니다.
한국 결제·환율 검증 — 카드 결제, 부가가치세 처리, 원화 환산 시점에 따라 실제 청구액이 본문 예시와 다를 수 있습니다.
기존 스택과의 호환성 — Next.js·Vercel·Supabase 같은 기본 스택과 충돌이 없는지 패키지 의존성을 먼저 확인하세요.
롤백 절차 사전 정리 — 도입 후 문제가 생겼을 때 1회 명령으로 이전 상태로 되돌릴 수 있는 절차를 도입 전에 메모해 두시면 운영 부담이 크게 줄어듭니다.

위 네 항목을 모두 통과하면 보통 1~2시간 내에 도입을 마칠 수 있고, 통과하지 못한 항목이 있다면 그 항목을 우선 해결한 뒤 다시 시작하는 것이 효율적입니다.

자주 묻는 질문

다른 대안과 비교했을 때 어떤 상황에 적합한가요?

Terraform은 AWS·GCP·Azure 등 여러 클라우드를 한 도구로 섞어 쓰거나, 인프라를 선언적으로 관리하고 팀 리뷰를 거치고 싶을 때 가장 잘 맞습니다. HCL이라는 전용 언어만 익히면 되니 진입 장벽도 낮은 편입니다. 반대로 인프라에 조건문·반복문·함수 같은 프로그래밍 로직을 많이 넣고 싶다면 TypeScript나 Python을 그대로 쓰는 Pulumi가 더 표현력이 좋고, AWS 한 곳만 쓴다면 CloudFormation을 생성해 주는 AWS CDK가 더 자연스럽습니다. 라이선스가 BSL로 바뀐 게 부담되거나 완전한 오픈소스가 필요하면 거의 호환되는 OpenTofu로 넘어가는 선택지도 있습니다. 서버 한두 대를 콘솔에서 클릭 몇 번으로 끝낼 규모라면 굳이 Terraform까지 도입할 필요는 없습니다.

더 깊게 공부하려면 어떤 자료를 보면 좋을까요?

먼저 HashiCorp 공식 문서의 Terraform Registry에서 본인이 쓰는 provider(예: aws, google) 페이지를 보시는 게 가장 빠릅니다. resource마다 어떤 인자를 받는지 전부 정리돼 있어서 사실상 레퍼런스 사전 역할을 합니다. 그다음 단계로 추천하는 키워드는 원격 state 관리(S3 backend + DynamoDB 락)와 module 작성법 두 가지입니다. 이 둘만 익혀도 1인 dev/staging/prod 환경 분리까지 무리 없이 갈 수 있습니다. learn.hashicorp.com의 단계별 튜토리얼은 terraform plan/apply 흐름을 손으로 따라 해 볼 수 있게 돼 있어 입문 직후에 한 번 훑어 보시길 권합니다.

Terraform 입문, 한 줄로 정리하면 어떻게 되나요?

콘솔에서 손으로 만들던 클라우드 인프라를 .tf 파일에 무엇을 원하는지 선언해 두고, terraform plan으로 변경 사항을 미리 확인한 뒤 terraform apply 한 명령으로 프로비저닝하는 도구입니다. 핵심은 Write → Plan → Apply 흐름과, 현재 인프라 상태를 추적하는 State 파일을 원격(S3 등)에 안전하게 두는 것 두 가지입니다. 이렇게 하면 인프라를 Git으로 버전 관리하고 코드 리뷰하며 동일 환경을 반복 생성할 수 있게 됩니다.

실무에서 처음 도입할 때 가장 먼저 확인할 것은 무엇인가요?

State 파일을 어디에 둘지부터 정하세요. 로컬에 두면 팀 협업이 불가능하고 실수로 덮어쓰기 쉬우니, 처음부터 S3 + DynamoDB 락이나 Terraform Cloud로 원격 state를 잡고 시작하는 편이 안전합니다. State에는 DB 비밀번호 같은 민감 정보가 평문으로 들어갈 수 있어 암호화 저장도 필수입니다. 그다음 워크플로우는 항상 terraform plan으로 변경 사항을 눈으로 확인한 뒤 apply하는 습관을 들이고, dev/staging/prod는 디렉토리나 Workspaces로 분리해 운영 환경에 실험적 변경이 새어 들어가지 않게 하세요.

가장 자주 발생하는 실수나 함정은 무엇인가요?

가장 무서운 사고는 terraform destroy를 운영 환경에서 무심코 실행해 리소스 전체가 날아가는 것입니다. 중요 리소스에는 lifecycle 블록의 prevent_destroy = true를 걸어 실수 삭제를 막아두세요. 그다음 흔한 실수는 콘솔에서 손으로 인프라를 바꿔 실제 상태와 State 파일이 어긋나는 drift로, 이러면 다음 apply가 예상 밖으로 동작합니다. 인프라 변경은 무조건 코드로만 하는 규칙을 지켜야 합니다. State 파일을 Git에 그대로 커밋해 비밀번호를 노출하는 것도 자주 보는 함정이니 원격 state + 암호화로 분리하세요.

terraformIaC인프라클라우드자동화