Terraform 소개 및 설치 완벽 가이드

인프라를 코드로 관리하는 IaC의 개념부터 Terraform의 특징, 설치 방법, 그리고 첫 번째 리소스 생성까지 초급 개발자를 위한 친절한 입문 가이드입니다. 실무에서 바로 활용할 수 있는 예제와 팁을 담았습니다.

---

목차

1. IaC(Infrastructure_as_Code)란
2. Terraform의_특징과_장점
3. 선언형_vs_절차형_IaC
4. Terraform_설치하기
5. Terraform_CLI_기본_명령어
6. 첫_번째_리소스_생성

---

1. IaC(Infrastructure as Code)란

김개발 씨는 스타트업에서 일하는 2년 차 백엔드 개발자입니다. 어느 날 팀장님이 "개발 서버 하나 더 띄워주세요"라고 요청했습니다.

김개발 씨는 AWS 콘솔에 로그인해서 클릭 클릭 클릭... 30분이 지나서야 겨우 서버를 만들었습니다.

**IaC(Infrastructure as Code)**는 인프라를 코드로 관리하는 방법입니다. 마치 애플리케이션 코드를 Git으로 관리하듯이, 서버나 네트워크 같은 인프라 설정도 코드 파일로 작성하고 버전 관리를 합니다.

이렇게 하면 같은 환경을 언제든 빠르고 정확하게 재현할 수 있습니다. 수동 작업으로 인한 실수도 크게 줄어듭니다.

다음 코드를 살펴봅시다.

# main.tf - 간단한 AWS EC2 인스턴스 예제
resource "aws_instance" "web_server" {
  # AMI ID는 리전마다 다릅니다
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  # 태그를 통해 리소스를 구분합니다
  tags = {
    Name = "MyWebServer"
    Environment = "Development"
  }
}

김개발 씨는 다음 날도 똑같은 작업을 반복했습니다. 이번에는 운영 서버를 만들어야 했거든요.

그런데 문제가 생겼습니다. 어제 만든 개발 서버와 설정이 조금 달랐던 것입니다.

보안 그룹 설정을 빼먹었고, 디스크 용량도 다르게 설정했습니다. 팀장님이 물었습니다.

"개발 서버와 운영 서버 설정이 왜 다른가요?" 김개발 씨는 난처했습니다. 수동으로 작업하다 보니 실수를 한 것입니다.

바로 이런 문제를 해결하기 위해 IaC라는 개념이 등장했습니다. IaC를 쉽게 비유하자면, 마치 요리 레시피와 같습니다.

매번 즉흥적으로 요리하는 대신, 정확한 레시피를 작성해두는 것입니다. 재료의 양, 조리 순서, 온도 설정까지 모두 문서화합니다.

그러면 누가 만들어도 똑같은 맛이 나겠죠? 인프라도 마찬가지입니다.

서버를 만드는 과정을 코드로 작성해두면, 언제 어디서든 같은 환경을 만들 수 있습니다. IaC가 없던 시절에는 어땠을까요?

개발자들은 서버를 만들 때마다 웹 콘솔에 접속했습니다. 버튼을 클릭하고, 설정 값을 일일이 입력했습니다.

10개의 서버를 만들려면 같은 작업을 10번 반복해야 했습니다. 실수도 잦았습니다.

한 번은 보안 그룹을 잘못 설정해서 서버가 해킹당하는 사고도 있었습니다. 더 큰 문제는 협업이었습니다.

A 개발자가 만든 서버와 B 개발자가 만든 서버가 미묘하게 달랐습니다. "내 컴퓨터에서는 되는데요?"라는 말이 인프라 영역에서도 발생했던 것입니다.

IaC는 이 모든 문제를 해결해줍니다. 먼저 재현 가능성이라는 큰 장점이 있습니다.

코드 파일만 있으면 언제든 똑같은 인프라를 만들 수 있습니다. 개발 환경, 스테이징 환경, 운영 환경을 모두 동일하게 구성할 수 있습니다.

두 번째로 버전 관리가 가능합니다. Git을 사용하면 인프라 변경 이력을 모두 추적할 수 있습니다.

"누가 언제 무엇을 바꿨는지" 한눈에 보입니다. 문제가 생기면 이전 버전으로 되돌릴 수도 있습니다.

세 번째로 협업이 쉬워집니다. 코드 리뷰를 통해 인프라 변경사항을 검토할 수 있습니다.

팀원들이 같은 코드를 보면서 의견을 나눌 수 있습니다. 위의 코드를 살펴보겠습니다.

resource 블록은 생성하고 싶은 인프라 리소스를 정의합니다. 여기서는 AWS EC2 인스턴스를 만들고 있습니다.

aws_instance는 리소스 타입이고, web_server는 우리가 붙인 이름입니다. ami 속성은 어떤 운영체제 이미지를 사용할지 지정합니다.

instance_type은 서버의 크기를 나타냅니다. t2.micro는 작은 인스턴스로, 무료 티어에서 사용할 수 있습니다.

tags는 리소스에 메타데이터를 붙이는 방법입니다. 나중에 서버가 많아졌을 때 구분하기 쉽게 이름을 붙여줍니다.

실제 현업에서는 어떻게 활용할까요? 대형 이커머스 회사를 예로 들어보겠습니다.

이 회사는 한국, 일본, 미국에 서비스를 운영합니다. 각 리전마다 웹 서버, 데이터베이스, 캐시 서버가 필요합니다.

IaC를 사용하면 한 번 작성한 코드를 세 번 실행해서 세 개의 동일한 환경을 만들 수 있습니다. 또 다른 사례로, 금융 회사는 규제 때문에 모든 인프라 변경을 문서화해야 합니다.

IaC를 사용하면 코드 자체가 문서가 됩니다. 감사 시점에 Git 히스토리를 보여주면 됩니다.

하지만 주의할 점도 있습니다. 초보자들이 흔히 하는 실수는 코드와 실제 인프라가 따로 노는 것입니다.

코드로 서버를 만든 뒤, 웹 콘솔에서 수동으로 설정을 변경하면 안 됩니다. 그러면 코드와 실제 상태가 달라져서 나중에 혼란이 생깁니다.

모든 변경은 반드시 코드를 통해 해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

선배 개발자 박시니어 씨가 IaC를 소개했습니다. "앞으로는 서버를 코드로 만들어보세요.

훨씬 편할 겁니다." 김개발 씨는 IaC를 배우기 시작했습니다. 처음에는 낯설었지만, 익숙해지니 정말 편했습니다.

이제는 서버 100개를 만들어야 해도 겁나지 않습니다.

실전 팁

💡 - 작은 것부터 시작하세요. 처음부터 모든 인프라를 코드로 만들려고 하지 말고, 간단한 EC2 인스턴스 하나부터 시작하세요.

• 코드와 실제 인프라를 항상 동기화하세요. 수동 변경을 절대 하지 마세요.
• Git으로 반드시 버전 관리를 하세요. 커밋 메시지에 왜 이 변경을 했는지 명확히 적어두세요.

---

2. Terraform의 특징과 장점

김개발 씨는 IaC의 개념을 이해했습니다. 그런데 IaC 도구가 여러 개 있다는 것을 알게 되었습니다.

AWS CloudFormation, Ansible, Terraform... 선배에게 물었습니다.

"어떤 걸 배워야 하나요?"

Terraform은 HashiCorp에서 만든 오픈소스 IaC 도구입니다. AWS, Azure, GCP 등 여러 클라우드를 하나의 언어로 관리할 수 있다는 것이 가장 큰 특징입니다.

선언형 방식으로 작동해서 "어떻게"가 아닌 "무엇을"에 집중할 수 있습니다. 전 세계에서 가장 많이 사용되는 IaC 도구 중 하나입니다.

다음 코드를 살펴봅시다.

# 여러 클라우드를 한 번에 관리
terraform {
  required_providers {
    # AWS 리소스 관리
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
    # Azure 리소스도 동시에 관리 가능
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }
}

박시니어 씨가 대답했습니다. "우리 회사는 Terraform을 사용해요.

이유가 있죠." Terraform이 무엇이 특별할까요? 먼저 멀티 클라우드 지원이라는 큰 장점이 있습니다.

마치 여러 언어를 구사하는 통역사와 같습니다. 영어도 하고, 중국어도 하고, 일본어도 합니다.

Terraform도 마찬가지입니다. AWS도 다루고, Azure도 다루고, GCP도 다룹니다.

왜 이것이 중요할까요? 요즘 많은 회사들이 멀티 클라우드 전략을 사용합니다.

주요 서비스는 AWS에서 운영하고, 머신러닝 작업은 GCP를 사용하는 식입니다. 한 클라우드에 종속되지 않으려는 전략이기도 합니다.

만약 AWS CloudFormation을 사용한다면 AWS만 관리할 수 있습니다. Azure Resource Manager는 Azure만 관리합니다.

하지만 Terraform은 하나의 언어로 모든 클라우드를 관리할 수 있습니다. 실제 사례를 보겠습니다.

어떤 핀테크 스타트업은 주요 서비스를 AWS에서 운영합니다. 그런데 데이터 분석팀은 GCP의 BigQuery를 사용하고 싶어 합니다.

Terraform을 사용하면 한 프로젝트 안에서 AWS 리소스와 GCP 리소스를 함께 관리할 수 있습니다. 두 번째 특징은 선언형 방식입니다.

이게 무슨 뜻일까요? 쉽게 비유하면, 레스토랑에서 음식을 주문하는 것과 같습니다.

"스테이크 미디엄으로 주세요"라고 말하면 됩니다. 주방에서 어떻게 요리하는지 일일이 지시할 필요가 없습니다.

Terraform도 마찬가지입니다. "EC2 인스턴스가 필요해"라고 선언하면 됩니다.

Terraform이 알아서 필요한 API를 호출하고, 의존성을 파악하고, 올바른 순서로 리소스를 만듭니다. 세 번째는 상태 관리 기능입니다.

Terraform은 현재 인프라 상태를 파일로 저장합니다. 이것을 state 파일이라고 부릅니다.

코드를 변경하고 다시 실행하면, Terraform은 state 파일을 확인해서 무엇이 바뀌었는지 파악합니다. 그리고 변경된 부분만 업데이트합니다.

이것이 왜 중요할까요? 서버가 100개 있는데 1개만 변경하고 싶다면, 나머지 99개는 그대로 두고 1개만 수정하면 됩니다.

전체를 다시 만들 필요가 없습니다. 네 번째는 풍부한 생태계입니다.

Terraform에는 프로바이더라는 개념이 있습니다. 각 클라우드나 서비스를 지원하는 플러그인입니다.

AWS 프로바이더, GitHub 프로바이더, Datadog 프로바이더 등 수천 개의 프로바이더가 있습니다. 커뮤니티도 활발합니다.

문제가 생기면 구글에 검색하면 대부분 답을 찾을 수 있습니다. Stack Overflow에도 질문이 많고, 공식 문서도 잘 되어 있습니다.

위의 코드를 살펴보겠습니다. terraform 블록은 Terraform 자체의 설정을 담고 있습니다.

required_providers에서 어떤 프로바이더를 사용할지 선언합니다. aws 프로바이더는 AWS 리소스를 관리하기 위한 플러그인입니다.

source는 프로바이더를 어디서 다운로드할지 지정하고, version은 어떤 버전을 사용할지 명시합니다. 같은 파일에서 azurerm 프로바이더도 선언했습니다.

이렇게 하면 AWS 리소스와 Azure 리소스를 한 프로젝트에서 관리할 수 있습니다. 실무에서는 이런 식으로 활용합니다.

글로벌 서비스를 운영하는 회사가 있다고 가정해봅시다. 미국 사용자는 AWS US-East를 사용하고, 유럽 사용자는 AWS EU-West를 사용합니다.

그런데 일부 분석 작업은 GCP를 사용합니다. Terraform으로 이 모든 것을 한 곳에서 관리합니다.

주의할 점도 있습니다. 초보자들이 흔히 하는 실수는 프로바이더 버전을 고정하지 않는 것입니다.

버전을 명시하지 않으면 나중에 프로바이더가 업데이트되면서 코드가 깨질 수 있습니다. 항상 버전을 명시하세요.

김개발 씨는 Terraform의 장점을 이해했습니다. "우리 회사가 왜 Terraform을 선택했는지 이제 알겠어요!"

실전 팁

💡 - 프로바이더 버전은 항상 명시하세요. 예상치 못한 업데이트를 방지할 수 있습니다.

• 공식 문서를 북마크하세요. registry.terraform.io에 모든 프로바이더와 리소스 문서가 있습니다.
• 작은 변경부터 시작하세요. 처음부터 복잡한 인프라를 만들려고 하지 마세요.

---

3. 선언형 vs 절차형 IaC

김개발 씨는 박시니어 씨의 설명 중에 "선언형"이라는 단어가 계속 나오는 것을 눈치챘습니다. "선언형이 뭔가요?

다른 방식도 있나요?" 박시니어 씨가 웃으며 대답했습니다. "좋은 질문이에요.

IaC에는 크게 두 가지 방식이 있어요."

IaC 도구는 크게 **선언형(Declarative)**과 **절차형(Imperative)**으로 나뉩니다. 선언형은 "무엇을" 원하는지 선언하면 도구가 알아서 처리합니다.

절차형은 "어떻게" 할지 단계별로 명령을 내려야 합니다. Terraform은 선언형 방식을 사용해서 코드가 간결하고 이해하기 쉽습니다.

다음 코드를 살펴봅시다.

# Terraform (선언형) - 최종 상태만 선언
resource "aws_instance" "web" {
  count         = 3  # 인스턴스 3개를 원한다고 선언
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

# Terraform이 알아서 처리:
# - 현재 몇 개가 있는지 확인
# - 부족하면 생성, 많으면 삭제
# - 올바른 순서로 API 호출

박시니어 씨가 화이트보드에 그림을 그리기 시작했습니다. "선언형과 절차형의 차이를 쉽게 설명해드릴게요." 먼저 선언형 방식을 일상 생활에 비유해보겠습니다.

여러분이 택시를 탔다고 상상해보세요. 기사님에게 "강남역으로 가주세요"라고 말합니다.

어느 길로 갈지, 신호등에서 어떻게 할지 일일이 지시하지 않습니다. 목적지만 말하면 기사님이 알아서 최적의 경로를 찾아갑니다.

선언형 IaC도 마찬가지입니다. "EC2 인스턴스 3개가 필요해"라고 선언하면 됩니다.

Terraform이 알아서 필요한 작업을 수행합니다. 반대로 절차형 방식은 어떨까요?

이번에는 자동차를 직접 운전한다고 생각해보세요. "직진 500m, 좌회전, 다시 직진 300m, 우회전..." 모든 단계를 직접 제어해야 합니다.

절차형 IaC도 비슷합니다. "먼저 VPC를 만들고, 그 다음 서브넷을 만들고, 그 다음 보안 그룹을 만들고..." 모든 단계를 순서대로 명령해야 합니다.

어떤 방식이 더 나을까요? 상황에 따라 다르지만, 대부분의 경우 선언형이 더 편리합니다.

선언형의 첫 번째 장점은 멱등성입니다. 어려운 단어인데, 쉽게 말하면 "여러 번 실행해도 같은 결과"를 의미합니다.

예를 들어, EC2 인스턴스 3개가 필요하다고 선언했다고 가정합시다. 첫 번째 실행에서 3개를 만듭니다.

코드를 수정하지 않고 다시 실행하면 어떻게 될까요? Terraform은 "이미 3개가 있네, 아무것도 안 해도 되겠군"이라고 판단합니다.

불필요한 작업을 하지 않습니다. 절차형에서는 이것이 복잡합니다.

"인스턴스 3개 만들기"라는 명령을 다시 실행하면 3개가 더 만들어집니다. 이미 있는지 확인하는 로직을 직접 작성해야 합니다.

두 번째 장점은 코드의 간결함입니다. 위의 Terraform 코드를 보세요.

단 4줄로 인스턴스 3개를 선언했습니다. 절차형으로 작성하면 "1번 인스턴스 만들기, 2번 인스턴스 만들기, 3번 인스턴스 만들기"를 각각 작성해야 합니다.

10개라면? 100개라면?

선언형은 숫자만 바꾸면 됩니다. 세 번째 장점은 의도가 명확하다는 것입니다.

선언형 코드를 읽으면 "아, 이 시스템은 EC2 인스턴스 3개가 필요하구나"라고 바로 이해됩니다. 절차형 코드는 읽으면서 머릿속으로 시뮬레이션해야 합니다.

"이 명령을 실행하면 이렇게 되고, 다음 명령을 실행하면 저렇게 되고..." 그렇다면 절차형은 쓸모없을까요? 그렇지 않습니다.

복잡한 로직이나 조건부 처리가 필요할 때는 절차형이 더 적합할 수 있습니다. 예를 들어, Ansible은 절차형 방식을 사용하는데, 서버 설정 자동화에는 이것이 더 자연스러울 때가 있습니다.

실제 현업에서는 두 방식을 혼용하기도 합니다. Terraform으로 인프라를 만들고, Ansible로 서버 내부 설정을 자동화하는 식입니다.

각 도구의 장점을 활용하는 것입니다. 위의 코드를 자세히 보겠습니다.

count = 3이라는 한 줄이 핵심입니다. 이것은 "이 리소스가 3개 존재해야 한다"는 선언입니다.

Terraform은 실행할 때마다 현재 상태를 확인합니다. 0개면 3개를 만들고, 이미 3개면 아무것도 하지 않고, 5개면 2개를 삭제합니다.

이 모든 로직을 Terraform이 자동으로 처리합니다. 개발자는 최종 상태만 선언하면 됩니다.

주의할 점이 있습니다. 선언형이 편하긴 하지만, 때로는 예상과 다르게 동작할 수 있습니다.

Terraform이 현재 상태를 잘못 파악하거나, 클라우드 API가 예상과 다르게 동작할 수 있습니다. 그래서 항상 terraform plan 명령으로 실제 실행 전에 무엇이 바뀔지 미리 확인해야 합니다.

김개발 씨가 고개를 끄덕였습니다. "선언형이 훨씬 직관적이네요.

마치 SQL 같은 느낌이에요." 박시니어 씨가 맞장구쳤습니다. "정확해요!

SELECT * FROM users처럼, 결과를 선언하는 거죠."

실전 팁

💡 - terraform plan을 습관화하세요. 실제 적용 전에 항상 변경 사항을 확인하세요.

• count나 for_each를 활용하면 같은 리소스를 여러 개 선언할 때 편리합니다.
• 선언형이라고 해서 순서가 전혀 없는 것은 아닙니다. 의존성은 Terraform이 자동으로 파악하지만, 명시적으로 depends_on을 사용할 수도 있습니다.

---

4. Terraform 설치하기

개념은 충분히 이해했습니다. 이제 실제로 설치해볼 차례입니다.

김개발 씨는 노트북을 열고 Terraform 공식 사이트로 들어갔습니다. "생각보다 간단하네요?"

Terraform 설치는 매우 간단합니다. 공식 사이트에서 운영체제에 맞는 바이너리 파일을 다운로드하거나, 패키지 매니저를 통해 설치할 수 있습니다.

Windows는 Chocolatey, Mac은 Homebrew, Linux는 apt나 yum을 사용합니다. 설치 후 terraform version 명령으로 정상 설치를 확인할 수 있습니다.

다음 코드를 살펴봅시다.

# Mac에서 Homebrew로 설치
brew tap hashicorp/tap
brew install hashicorp/tap/terraform

# Linux(Ubuntu/Debian)에서 apt로 설치
wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform

# 설치 확인
terraform version

김개발 씨는 맥북을 사용하고 있습니다. 터미널을 열고 명령어를 입력하기 시작했습니다.

Terraform 설치는 정말 간단합니다. 다른 개발 도구들처럼 복잡한 설정 과정이 없습니다.

마치 Node.js나 Python을 설치하는 것처럼 쉽습니다. Mac 사용자라면 Homebrew를 사용하는 것이 가장 편합니다.

Homebrew는 Mac의 사실상 표준 패키지 매니저입니다. 아직 설치하지 않았다면 homebrew 공식 사이트에서 설치할 수 있습니다.

먼저 HashiCorp의 tap을 추가합니다. tap은 Homebrew에서 추가 저장소를 의미합니다.

그 다음 terraform을 설치합니다. 커피 한 잔 마실 시간도 안 되어서 설치가 완료됩니다.

Windows 사용자라면 Chocolatey를 추천합니다. Chocolatey는 Windows의 패키지 매니저입니다.

관리자 권한으로 PowerShell을 열고 choco install terraform을 실행하면 됩니다. 또는 공식 사이트에서 zip 파일을 다운로드해서 압축을 풀고, PATH에 추가할 수도 있습니다.

Linux 사용자는 배포판에 따라 조금씩 다릅니다. Ubuntu나 Debian 계열이라면 위의 코드처럼 apt를 사용합니다.

먼저 HashiCorp의 GPG 키를 추가하고, 저장소를 등록한 다음, apt install을 실행합니다. CentOS나 RHEL 계열이라면 yum을 사용합니다.

과정은 비슷합니다. 저장소를 추가하고 yum install terraform을 실행하면 됩니다.

설치가 끝났다면 확인해봅시다. 터미널을 열고 terraform version을 입력합니다.

버전 정보가 출력되면 성공입니다. "Terraform v1.6.0" 같은 메시지를 볼 수 있을 것입니다.

만약 "command not found" 에러가 나온다면 어떻게 할까요? PATH 설정이 잘못되었을 가능성이 큽니다.

Terraform 바이너리가 있는 경로를 시스템 PATH에 추가해야 합니다. Mac이나 Linux라면 ~/.bashrc나 ~/.zshrc 파일에 export PATH=$PATH:/usr/local/bin 같은 줄을 추가합니다.

설치는 이것으로 끝입니다. 정말 간단하죠?

하지만 Terraform만 설치한다고 바로 사용할 수 있는 것은 아닙니다. 클라우드 프로바이더의 인증 정보가 필요합니다.

AWS를 사용한다면 AWS CLI를 설치하고 aws configure로 액세스 키를 설정해야 합니다. Azure라면 Azure CLI를, GCP라면 gcloud CLI를 설치해야 합니다.

AWS를 예로 들어보겠습니다. AWS CLI를 설치한 후, aws configure를 실행합니다.

Access Key ID와 Secret Access Key를 입력하라고 나옵니다. 이것은 AWS 콘솔의 IAM 메뉴에서 생성할 수 있습니다.

보안을 위해 주의할 점이 있습니다. 루트 계정의 액세스 키는 절대 사용하지 마세요.

IAM 사용자를 만들고, 필요한 최소한의 권한만 부여하세요. 예를 들어, EC2만 관리한다면 EC2 관련 권한만 주면 됩니다.

또한 액세스 키를 절대 코드에 직접 작성하지 마세요. Git에 커밋되면 큰일납니다.

환경 변수나 AWS CLI 설정 파일을 사용하세요. 김개발 씨는 모든 설치를 마쳤습니다.

터미널에 terraform version을 입력하니 "Terraform v1.6.0"이라는 메시지가 나왔습니다. "드디어 준비 끝!" 박시니어 씨가 옆에서 말했습니다.

"이제 진짜 시작이에요. 첫 번째 인프라를 만들어봅시다."

실전 팁

💡 - 최신 버전을 사용하세요. Terraform은 활발히 개발되고 있어서 버전업이 잦습니다.

• 팀에서 사용한다면 버전을 통일하세요. .terraform-version 파일을 사용하면 버전 관리가 쉽습니다.
• AWS 액세스 키는 정기적으로 로테이션하세요. 보안은 아무리 강조해도 지나치지 않습니다.

---

5. Terraform CLI 기본 명령어

설치는 끝났지만, 명령어를 어떻게 사용하는지 막막했습니다. 김개발 씨는 terraform --help를 입력해봤습니다.

명령어가 정말 많았습니다. "이걸 다 외워야 하나요?" 박시니어 씨가 웃으며 말했습니다.

"아니요, 자주 쓰는 건 몇 개 안 돼요."

Terraform의 핵심 명령어는 크게 네 가지입니다. init은 프로젝트를 초기화하고, plan은 변경 사항을 미리 확인합니다.

apply는 실제로 인프라를 생성/변경하고, destroy는 모든 리소스를 삭제합니다. 이 네 가지만 알아도 기본적인 작업은 모두 할 수 있습니다.

다음 코드를 살펴봅시다.

# 1. 프로젝트 초기화 - 프로바이더 다운로드
terraform init

# 2. 변경 사항 미리 보기 - 실제 적용 전 확인
terraform plan

# 3. 인프라 생성/변경 - 실제 적용
terraform apply

# 4. 특정 리소스만 변경
terraform apply -target=aws_instance.web

# 5. 모든 리소스 삭제 - 주의해서 사용!
terraform destroy

# 6. 현재 상태 확인
terraform show

박시니어 씨가 설명을 시작했습니다. "Terraform 워크플로우는 아주 단순해요." Terraform을 사용하는 과정은 마치 요리를 하는 것과 비슷합니다.

먼저 레시피를 준비하고(코드 작성), 재료를 확인하고(plan), 실제로 요리하고(apply), 다 먹고 나면 설거지를 합니다(destroy). 첫 번째 명령어는 terraform init입니다.

이것은 프로젝트를 초기화하는 명령어입니다. 새로운 Terraform 프로젝트를 시작할 때, 또는 다른 사람의 프로젝트를 클론받았을 때 가장 먼저 실행합니다.

init을 실행하면 무슨 일이 일어날까요? 먼저 코드에서 사용하는 프로바이더를 확인합니다.

AWS 프로바이더가 필요하면 HashiCorp 레지스트리에서 다운로드합니다. 그리고 .terraform 디렉토리를 만들어 여기에 프로바이더를 저장합니다.

또한 상태 관리를 위한 백엔드를 초기화합니다. 로컬 백엔드를 사용한다면 terraform.tfstate 파일을 준비합니다.

init은 멱등적입니다. 여러 번 실행해도 안전합니다.

프로바이더를 업데이트하고 싶을 때도 init을 다시 실행하면 됩니다. 두 번째 명령어는 terraform plan입니다.

이것은 가장 중요한 명령어 중 하나입니다. 실제로 인프라를 변경하기 전에 무엇이 바뀔지 미리 보여줍니다.

plan을 실행하면 Terraform은 다음 작업을 수행합니다. 먼저 코드를 읽고, 현재 상태 파일을 확인하고, 클라우드 API에 현재 상태를 조회합니다.

그리고 코드와 현재 상태를 비교해서 차이를 계산합니다. 결과는 매우 직관적입니다.

초록색 + 표시는 새로 만들어질 리소스입니다. 빨간색 - 표시는 삭제될 리소스입니다.

노란색 ~ 표시는 변경될 리소스입니다. 항상 apply 전에 plan을 실행하세요.

예상치 못한 삭제를 방지할 수 있습니다. 세 번째 명령어는 terraform apply입니다.

이것이 실제로 인프라를 변경하는 명령어입니다. apply를 실행하면 먼저 plan을 자동으로 실행합니다.

그리고 변경 사항을 보여준 후, "정말 실행할까요?"라고 물어봅니다. yes를 입력하면 실제 적용이 시작됩니다.

AWS API를 호출해서 리소스를 만들거나 변경합니다. 진행 상황이 실시간으로 표시됩니다.

작업이 끝나면 상태 파일이 업데이트됩니다. 이제 코드와 실제 인프라가 동기화되었습니다.

-auto-approve 플래그를 사용하면 확인 없이 바로 적용할 수 있습니다. 하지만 운영 환경에서는 절대 사용하지 마세요.

실수로 인프라를 삭제할 수 있습니다. 네 번째 명령어는 terraform destroy입니다.

이것은 모든 리소스를 삭제하는 명령어입니다. 테스트 환경을 정리하거나, 프로젝트를 완전히 종료할 때 사용합니다.

destroy도 적용 전에 무엇이 삭제될지 보여줍니다. 매우 위험한 명령어이므로 신중하게 사용해야 합니다.

특정 리소스만 삭제하고 싶다면 -target 플래그를 사용할 수 있습니다. 예를 들어, terraform destroy -target=aws_instance.web은 해당 인스턴스만 삭제합니다.

이 외에도 유용한 명령어들이 있습니다. terraform show는 현재 상태를 보여줍니다.

terraform output은 출력 변수의 값을 표시합니다. terraform fmt는 코드를 자동으로 포맷팅합니다.

terraform validate는 코드 문법을 검증합니다. 실제 워크플로우를 보겠습니다.

김개발 씨가 처음으로 EC2 인스턴스를 만든다고 가정합시다. 먼저 main.tf 파일을 작성합니다.

그리고 terraform init을 실행해서 AWS 프로바이더를 다운로드합니다. terraform plan으로 무엇이 만들어질지 확인합니다.

문제없으면 terraform apply로 실제로 만듭니다. 다음 날, 인스턴스 타입을 변경하고 싶어졌습니다.

코드를 수정하고 다시 plan을 실행합니다. "1 to change"라는 메시지가 보입니다.

apply를 실행해서 변경을 적용합니다. 프로젝트가 끝나면 terraform destroy로 모든 리소스를 정리합니다.

AWS 비용을 절약할 수 있습니다. 김개발 씨가 말했습니다.

"생각보다 명령어가 간단하네요. 이 네 가지만 기억하면 되겠어요."

실전 팁

💡 - plan의 출력을 파일로 저장할 수 있습니다. terraform plan -out=tfplan을 실행하고, terraform apply tfplan으로 정확히 그대로 적용하세요.

• 운영 환경에서는 절대 -auto-approve를 사용하지 마세요. 항상 변경 사항을 리뷰하세요.
• terraform fmt와 terraform validate를 Git pre-commit 훅으로 설정하면 코드 품질을 유지할 수 있습니다.

---

6. 첫 번째 리소스 생성

드디어 실전입니다. 김개발 씨는 첫 번째 EC2 인스턴스를 만들기로 했습니다.

간단한 웹 서버를 띄워보는 것이 목표입니다. VS Code를 열고 새로운 프로젝트 폴더를 만들었습니다.

첫 번째 Terraform 프로젝트는 간단한 EC2 인스턴스 생성으로 시작하는 것이 좋습니다. provider 블록으로 AWS를 설정하고, resource 블록으로 인스턴스를 정의합니다.

코드를 작성한 후 init, plan, apply 순서로 실행하면 실제 인스턴스가 생성됩니다. 생성된 인스턴스는 AWS 콘솔에서 확인할 수 있습니다.

다음 코드를 살펴봅시다.

# main.tf - 첫 번째 Terraform 프로젝트
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
  }
}

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

# EC2 인스턴스 생성
resource "aws_instance" "my_first_server" {
  ami           = "ami-0c9c942bd7bf113a2"  # Amazon Linux 2
  instance_type = "t2.micro"  # 프리티어

  tags = {
    Name = "MyFirstTerraformServer"
    CreatedBy = "Terraform"
  }
}

# 인스턴스의 퍼블릭 IP 출력
output "instance_public_ip" {
  value = aws_instance.my_first_server.public_ip
  description = "The public IP of the EC2 instance"
}

김개발 씨는 my-first-terraform이라는 폴더를 만들었습니다. 그리고 main.tf라는 파일을 생성했습니다.

Terraform 프로젝트의 시작은 항상 비슷합니다. 먼저 필요한 프로바이더를 선언합니다.

위의 코드에서 terraform 블록이 그 역할을 합니다. AWS 프로바이더 버전 4.x를 사용하겠다고 명시했습니다.

다음은 provider 블록입니다. 이것은 AWS 프로바이더의 실제 설정을 담고 있습니다.

region은 어느 리전에 리소스를 만들지 지정합니다. ap-northeast-2는 서울 리전의 코드입니다.

한국 사용자를 위한 서비스라면 서울 리전을 사용하는 것이 일반적입니다. 인증 정보는 어떻게 전달될까요?

코드에 명시하지 않았다는 것을 눈치챘나요? Terraform은 여러 방법으로 AWS 인증 정보를 찾습니다.

환경 변수(AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)를 확인하고, AWS CLI의 설정 파일(~/.aws/credentials)을 확인합니다. 대부분의 경우 AWS CLI로 인증 정보를 설정해두면 자동으로 동작합니다.

이제 핵심인 resource 블록입니다. **resource "aws_instance" "my_first_server"**는 두 부분으로 나뉩니다.

aws_instance는 리소스 타입입니다. EC2 인스턴스를 만들겠다는 뜻입니다.

my_first_server는 우리가 붙인 이름입니다. 코드 내에서 이 리소스를 참조할 때 사용합니다.

ami 속성은 매우 중요합니다. AMI는 Amazon Machine Image의 약자로, 운영체제 이미지를 의미합니다.

여기서는 Amazon Linux 2를 사용했습니다. 주의할 점은 AMI ID가 리전마다 다르다는 것입니다.

서울 리전의 AMI ID와 버지니아 리전의 AMI ID가 다릅니다. instance_type은 서버의 크기를 나타냅니다.

t2.micro는 가장 작은 인스턴스 타입 중 하나로, AWS 프리티어에 포함되어 있습니다. 학습용으로는 충분합니다.

실제 서비스라면 트래픽과 요구사항에 맞는 타입을 선택해야 합니다. tags는 리소스에 메타데이터를 붙이는 방법입니다.

AWS 콘솔에서 리소스를 볼 때 이 태그가 표시됩니다. Name 태그는 특별합니다.

AWS 콘솔에서 리소스 이름으로 표시되기 때문입니다. 여러 리소스를 관리할 때 태그는 필수입니다.

마지막으로 output 블록입니다. 이것은 Terraform이 작업을 완료한 후 특정 값을 출력하도록 합니다.

여기서는 생성된 인스턴스의 퍼블릭 IP를 출력합니다. apply가 끝나면 터미널에 이 IP가 표시됩니다.

이제 실제로 실행해봅시다. 터미널을 열고 프로젝트 폴더로 이동합니다.

첫 번째 명령어는 terraform init입니다. 실행하면 AWS 프로바이더를 다운로드하는 메시지가 보입니다.

"Terraform has been successfully initialized!"라는 메시지가 나오면 성공입니다. 다음은 terraform plan입니다.

실행하면 무엇이 만들어질지 자세히 보여줍니다. "Plan: 1 to add, 0 to change, 0 to destroy"라는 메시지를 확인하세요.

1개의 리소스가 추가될 것입니다. 마지막으로 terraform apply를 실행합니다.

변경 사항을 다시 한 번 보여주고, "Do you want to perform these actions?"라고 물어봅니다. yes를 입력합니다.

AWS API를 호출하는 과정이 시작됩니다. 진행 상황이 실시간으로 표시됩니다.

30초에서 1분 정도 걸립니다. "Apply complete!"라는 메시지와 함께 퍼블릭 IP가 출력됩니다.

예를 들어, "instance_public_ip = 3.35.123.45" 같은 형태입니다. 이제 AWS 콘솔로 가봅시다.

EC2 대시보드를 열면 방금 만든 인스턴스가 보입니다. 이름은 "MyFirstTerraformServer"입니다.

상태는 "running"일 것입니다. 태그도 제대로 붙어 있습니다.

김개발 씨는 감격했습니다. "와, 정말 만들어졌어요!" 클릭 클릭 클릭 하던 시절과는 다릅니다.

코드 몇 줄로 서버를 만들었습니다. 박시니어 씨가 말했습니다.

"이제 이 코드를 Git에 커밋하세요. 다른 팀원도 같은 환경을 만들 수 있어요." 정리할 때는 terraform destroy를 실행하면 됩니다.

모든 리소스가 깔끔하게 삭제됩니다. AWS 비용을 절약할 수 있습니다.

실전 팁

💡 - AMI ID는 AWS 콘솔의 EC2 런치 마법사에서 확인할 수 있습니다. 또는 aws ec2 describe-images 명령으로 검색할 수 있습니다.

• 프리티어를 사용 중이라면 t2.micro를 사용하세요. 다른 타입은 비용이 발생합니다.
• 실습 후에는 반드시 destroy를 실행해서 리소스를 정리하세요. 그렇지 않으면 계속 비용이 청구됩니다.
• terraform.tfstate 파일은 절대 Git에 커밋하지 마세요. 민감한 정보가 포함되어 있습니다. .gitignore에 추가하세요.

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!