Terraform 설명: “이게 뭐지?”에서 실제로 이해하기까지 🚀

발행: 3일 전 (2026년 3월 1일 오후 01:29 GMT+9)

16 분 소요

원문: Dev.to

Source: Dev.to

프로덕션을 새벽 2시에 망가뜨리고 살아남아 이야기를 전하는 3학년 공학 학생이 올린 글.

이런 상황을 상상해 보세요: AWS 콘솔을 통해 EC2 인스턴스를 직접 설정했습니다—보안 그룹, IAM 역할, VPC 구성—모두 수작업으로. 정상적으로 동작하고, 자신이 천재가 된 듯한 기분이 듭니다.

그런데 팀원이 실수로 인스턴스를 삭제해 버렸습니다.

화면을 바라보며, 어떤 설정을 선택했는지 기억이 나지 않습니다. 작성하려고 했던 문서는 빈 Notion 페이지일 뿐이고, 현재 새벽 2시이며 6시간 뒤에 데모가 있습니다.

바로 이 상황이 제가 AWS 콘솔을 여기저기 클릭하는 것을 멈추고 Terraform을 실제로 배우기 시작하게 만든 계기였습니다. 솔직히 말해서, 더 일찍 시작했더라면 좋았을 텐데요.

Terraform이 실제로 해결하는 문제는 무엇인가?

교과서적인 답변 대신 실제 예시를 들어 보겠습니다.

AWS에 다음을 설정해야 한다고 가정해 보세요:

EC2 인스턴스(서버)
보안 그룹(방화벽 규칙)
S3 버킷(파일 저장소)
IAM 역할(권한)

AWS 콘솔을 통해 수동으로 진행한다면 다음과 같은 일이 발생합니다:

EC2 인스턴스를 만들기 위해 15개의 화면을 클릭합니다.
IAM 역할을 연결하는 것을 잊어버립니다.
다시 돌아가서 수정합니다.
똑같은 작업을 스테이징 환경에도 해야 합니다.
하나의 설정을 잘못하면 스테이징과 프로덕션이 이유 없이 달라집니다.
새로운 팀원이 합류했는데, 여러분이 무엇을 만들었는지, 왜 그렇게 만들었는지 전혀 모릅니다.

Terraform을 사용하면 이 모든 과정을 하나의 파일에 코드로 작성하고, 버전 관리가 가능하며, 재현할 수 있습니다. 스테이징과 프로덕션이 동일해야 한다면 같은 코드를 실행하면 됩니다. 팀원이 합류하면 파일을 읽는 순간 모든 내용을 바로 이해할 수 있습니다.

핵심 약속은 인프라가 코드가 되어 미스터리가 아니라는 것입니다.

Infrastructure as Code — 내 동급생에게 설명하듯이

잠시 공식 정의는 제쳐두세요.

개발자들이 앱을 만들기 위해 코드를 작성하는 걸 알고 있죠? 코드를 실행하기 전까지는 앱이 존재하지 않아요. **Infrastructure as Code (IaC)**도 같은 개념입니다—하지만 웹 앱을 만드는 대신 서버, 네트워크, 데이터베이스, 클라우드 리소스를 구축하는 것이죠.

IaC가 나오기 전에는 시스템 관리자들이 서버에 SSH로 접속해 모든 것을 수동으로 설정했습니다. 동작은 했지만, 다음과 같은 문제가 있었습니다:

속도가 느렸습니다.
일관성이 없었습니다(각 서버가 조금씩 달랐습니다).
어디에도 문서화되지 않았습니다.
문제가 생기면 정확히 어떻게 복구해야 할지 아무도 몰랐습니다.

IaC는 이 상황을 뒤집습니다. 원하는 구성을 파일에 기술하고 명령을 실행하면, 도구가 매번 동일하게 구축해 줍니다.

레시피에 비유해 보세요. 요리사는 같은 레시피를 사용해 같은 요리를 100번 만들 수 있습니다. 레시피가 없던 시절에는 매일 요리하는 사람에 따라 요리가 조금씩 달랐습니다.

Source: …

왜 나는 다른 도구보다 Terraform을 선택했는가

다른 IaC 도구—AWS CloudFormation, Ansible, Pulumi—도 있습니다. 학습자로서 내가 Terraform을 선택한 이유는 다음과 같습니다:

클라우드에 구애받지 않습니다. 동일한 도구로 AWS, GCP, Azure 등 여러 클라우드를 다룰 수 있습니다. 서로 다른 클라우드를 시도하기 위해 세 가지 도구를 배우고 싶지 않았습니다.
거대한 커뮤니티. 막히는 경우(자주 발생함) Stack Overflow 답변, 블로그 포스트, 혹은 GitHub 이슈 중에 이미 내 문제와 정확히 같은 해결책을 찾을 수 있습니다.
실제로 기업에서 사용합니다. 채용 공고와 DevOps/클라우드 역할을 살펴보면 거의 항상 Terraform이 요구됩니다. 이를 배우는 것이 실질적인 투자처럼 느껴졌습니다.
학습 곡선이 가치가 있었습니다. 쉽지는 않지만 몇 개 프로젝트를 진행하면 감이 잡힙니다.

핵심 개념 — 실제로 중요한 내용

🔌 프로바이더

프로바이더는 기본적으로 Terraform에게 어떤 클라우드나 서비스와 통신할지 알려주는 플러그인입니다.

provider "aws" {
  region = "us-east-1"
}

이는 Terraform에게 “우리는 AWS와 작업하고 있으며, us-east-1 리전의 리소스를 원한다”는 의미입니다. GCP, Azure, Kubernetes, GitHub, Datadog 등 거의 모든 서비스에 대한 프로바이더가 있습니다.

🧱 리소스

리소스는 실제로 만들고자 하는 대상입니다—예를 들어 EC2 인스턴스, S3 버킷, 데이터베이스 등이 있습니다.

resource "aws_instance" "my_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

형식은 항상 resource "type" "local_name" 입니다. 로컬 이름은 코드 내 다른 곳에서 해당 리소스를 참조하기 위해 사용하는 이름일 뿐입니다.

📦 변수

값을 코드 곳곳에 하드코딩하는 대신 변수를 사용합니다. 이렇게 하면 코드를 재사용할 수 있습니다.

variable "instance_type" {
  default = "t2.micro"
}

resource "aws_instance" "my_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = var.instance_type
}

이제 인스턴스 유형을 바꾸고 싶다면 한 곳만 수정하면 됩니다—열 파일을 뒤져서 바꿀 필요가 없습니다.

🗂️ 상태 파일

처음에 가장 헷갈렸던 부분입니다. Terraform은 terraform.tfstate 라는 파일을 유지하며, 여기에는 이미 생성된 리소스가 기록됩니다. 이 파일을 통해 구성 파일을 업데이트했을 때 어떤 부분을 변경해야 하는지 판단합니다.

두 가지 중요한 사항을 직접 겪으며 배웠습니다:

절대 수동으로 편집하지 마세요. JSON 형식이라 편집이 가능해 보이지만, 직접 수정하면 Terraform이 심각하게 혼란스러워집니다.
비밀 정보가 포함돼 있다면 GitHub에 커밋하지 마세요. 팀 프로젝트에서는 원격 상태(예: S3 + DynamoDB)를 사용하세요.

⚙️ 핵심 명령어

terraform init      # Downloads providers, sets up the working directory
terraform plan      # Shows what WILL happen before you do anything
terraform apply     # Actually creates/changes the infrastructure
terraform destroy   # Tears everything down

terraform plan 은 최고의 친구입니다. apply 하기 전에 항상 실행하세요. Terraform이 수행할 작업—생성, 변경, 삭제—을 정확히 보여주므로 예상치 못한 일이 없습니다.

📝 HCL (HashiCorp Configuration Language)

HCL은 Terraform 설정 파일을 작성하는 언어입니다. JSON도 아니고 YAML도 아니며, 독자적인 문법을 가지고 있습니다. 하지만 익숙해지면 꽤 읽기 쉽습니다. 위 예시들은 모두 HCL로 작성되었습니다.

실제 예시: AWS에서 EC2 인스턴스 시작하기

다음은 보안 그룹과 함께 EC2 인스턴스를 시작하기 위한 간단하고 작동하는 Terraform 설정입니다:

# main.tf

provider "aws" {
  region = "us-east-1"
}

variable "instance_type" {
  default = "t2.micro"
}

resource "aws_security_group" "allow_ssh" {
  name        = "allow_ssh"
  description = "Allow SSH inbound traffic"

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

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

resource "aws_instance" "my_server" {
  ami                    = "ami-0c55b159cbfafe1f0"
  instance_type          = var.instance_type
  vpc_security_group_ids = [aws_security_group.allow_ssh.id]

  tags = {
    Name = "MyTerraformServer"
  }
}

output "instance_ip" {
  value = aws_instance.my_server.public_ip
}

실행 방법:

terraform init
terraform plan
terraform apply

그게 전부입니다. AWS 콘솔을 클릭할 필요가 없습니다. 설정을 잊어버릴 일도 없습니다. 오직 코드만 있습니다.

초보자 실수 (제가 모두 저질렀던 것들)

apply 전에 terraform plan을 사용하지 않음
몇 번이나 apply를 바로 실행했습니다. 한 번은 의도치 않게 프로덕션 리소스를 수정했죠. 항상 먼저 plan을 실행하세요.
상태 파일이나 .terraform 폴더를 Git에 커밋
이 파일들을 즉시 .gitignore에 추가하세요:
```
.terraform/
*.tfstate
*.tfstate.backup
```
민감한 값을 하드코딩
AWS 비밀 키, 데이터베이스 비밀번호, 혹은 기타 자격 증명을 .tf 파일에 직접 넣지 마세요. 환경 변수나 AWS Secrets Manager 같은 도구를 사용하세요.
Terraform이 선언형이라는 점을 이해하지 못함
무엇을 원하는지를 기술하는 것이지, 어떻게 만들지는 기술하지 않습니다. 절차적으로 생각하는 습관을 버리는 데 시간이 좀 걸렸어요.
Terraform이 만든 리소스를 수동으로 변경
콘솔에서 EC2 인스턴스 크기를 직접 조정하면 Terraform이 이를 인식하지 못합니다. 다음 plan에서 드리프트가 표시되고, 변경 사항을 되돌리려 할 수 있습니다.

How Terraform Fits Into Real DevOps Workflows

In actual companies, Terraform doesn’t just run on a developer’s laptop. It’s wired into CI/CD pipelines.

Typical setup:

Developer opens a PR with infrastructure changes.
CI (e.g., GitHub Actions) runs terraform plan automatically and posts the output as a comment on the PR.
After review and merge, CI runs terraform apply automatically.
State is stored remotely in S3 with a DynamoDB lock so no two people apply at the same time.

Tools like Terraform Cloud or Atlantis make this even smoother. You end up with a full audit trail of who changed what infrastructure, when, and why — just like code reviews for application code.

This is why knowing Terraform isn’t just a nice‑to‑have in 2025; it’s a core skill if you’re serious about cloud or DevOps.

실제로 배운 점

작게 시작하세요: 하나의 리소스, 하나의 프로바이더, 작동하도록 만드세요.
사용 중인 특정 리소스에 대한 Terraform 문서를 읽으세요 — 문서가 정말 좋습니다.
팀 프로젝트에서는 원격 상태가 선택 사항이 아닙니다; 초기에 설정하세요.
인프라 코드를 애플리케이션 코드처럼 다루세요: 검토하고, 버전 관리하고, 문서화하세요.

terraform destroy는 만족스럽지만 동시에 두렵습니다. 신중하게 사용하세요.

최종 생각

Terraform은 겉보기에는 위협적으로 보이지만 첫 번째 작동하는 구성을 작성하면 완전히 이해가 됩니다. 개념 자체가 복잡한 것은 아니며, 처음엔 익숙하지 않을 뿐입니다.

만약 여러분이 학생이거나 초기 경력 엔지니어로 DevOps나 클라우드 분야에 진입하려 한다면, Docker와 Kubernetes와 함께 Terraform을 배우는 것은 정말 강력한 조합입니다. 거의 모든 채용 공고에 등장하는 스킬이기도 합니다.

저는 제 학습 과정을 공개적으로 기록하고 있습니다 — 비슷한 여정을 걷고 있다면 언제든지 연결하거나 제가 진행 중인 작은 프로젝트와 노트를 올려놓은 GitHub를 확인해 주세요.

Terraform을 사용해 본 경험은 어떠셨나요? 댓글에 남겨 주세요 — 특히 제 실수보다 더 큰 실수를 해보셨다면 👇