안녕하세요! 현대 클라우드 환경에서 인프라 관리는 개발 못지않게 중요해지고 있습니다. 특히 AWS와 같은 클라우드 서비스는 다양한 자원을 제공하며, 이들을 효율적으로 관리하는 것이 핵심 역량이 되었죠. 오늘은 수많은 인프라 관리 도구 중에서도 가장 강력하고 널리 사용되는 Terraform을 사용하여 AWS 인프라를 코드로 관리(Infrastructure as Code, IaC)하는 방법에 대해 자세히 알아보겠습니다.
이 튜토리얼을 통해 Terraform의 기본 개념부터 AWS 환경에서 실제 인프라를 배포하고 관리하는 실전적인 방법까지 익힐 수 있을 것입니다. 복잡하고 반복적인 수동 작업을 줄이고, 더욱 안정적이고 효율적인 인프라 관리의 세계로 함께 떠나볼까요?
Image by onkelglocke on Pixabay
1. 왜 Terraform과 IaC인가?
과거에는 서버나 네트워크 장비를 수동으로 설정하고 관리하는 것이 일반적이었습니다. 하지만 클라우드 환경이 보편화되고 인프라 규모가 커지면서 이러한 방식은 여러 문제점을 야기했습니다. 바로 이 지점에서 IaC (Infrastructure as Code)의 필요성이 대두됩니다.
IaC는 인프라를 코드로 정의하고 관리하는 접근 방식입니다. 코드를 통해 인프라를 프로비저닝하고, 업데이트하며, 삭제할 수 있게 해줍니다.
그렇다면 왜 수많은 IaC 도구 중에서 Terraform이 각광받을까요? Terraform은 HashiCorp에서 개발한 오픈소스 IaC 도구로, 여러 클라우드 제공업체(AWS, Azure, GCP 등) 및 온프레미스 환경까지 지원하는 클라우드 agnostic 특징을 가지고 있습니다. 즉, 한 번 배운 Terraform 문법으로 다양한 환경의 인프라를 관리할 수 있다는 큰 장점이 있습니다.
IaC와 Terraform을 사용하는 주요 이점은 다음과 같습니다.
- 일관성 및 반복 가능성: 코드로 정의된 인프라는 항상 동일하게 배포될 수 있어, 환경 간 불일치를 줄이고 반복 가능한 배포를 가능하게 합니다.
- 버전 관리: 인프라 코드를 Git과 같은 버전 관리 시스템으로 관리하여 변경 이력을 추적하고, 필요한 경우 이전 버전으로 쉽게 롤백할 수 있습니다.
- 자동화: 수동 작업을 자동화하여 시간과 노력을 절약하고, 인적 오류의 가능성을 줄입니다.
- 협업 증진: 팀원들이 인프라 변경 사항을 쉽게 공유하고 검토할 수 있어 협업 효율성을 높입니다.
- 문서화: 코 자체가 인프라의 현재 상태와 설정을 명확하게 문서화하는 역할을 합니다.
전통적인 수동 방식과 Terraform (IaC) 방식의 차이를 표로 비교해 볼까요?
| 특징 | 수동 관리 (AWS 콘솔) | Terraform (IaC) |
|---|---|---|
| 배포 속도 | 느림, 반복 작업에 취약 | 빠름, 자동화된 반복 배포 가능 |
| 일관성 | 낮음, 휴먼 에러 가능성 높음 | 높음, 코드 기반으로 항상 동일 |
| 버전 관리 | 어려움, 변경 이력 추적 불가 | 쉬움, Git 등으로 변경 이력 관리 |
| 협업 | 어려움, 변경 사항 공유 복잡 | 쉬움, 코드 리뷰 및 공동 작업 용이 |
| 비용 효율성 | 불필요한 자원 프로비저닝 가능성 | 자원 최적화 및 비용 예측 용이 |
2. Terraform 기본 개념 이해
Terraform을 본격적으로 사용하기 전에 몇 가지 핵심 개념을 이해하는 것이 중요합니다.
- Provider: Terraform이 특정 클라우드 서비스(AWS, Azure 등) 또는 인프라 플랫폼과 상호작용할 수 있도록 해주는 플러그인입니다. 각 Provider는 해당 플랫폼의 자원을 생성, 관리, 업데이트하는 방법을 알고 있습니다.
- Resource: 클라우드 환경에서 생성하고 관리할 수 있는 가장 기본적인 인프라 구성 요소입니다. 예를 들어, AWS S3 버킷, EC2 인스턴스, VPC 등이 모두 Resource에 해당합니다. Terraform 코드에서는
resource "type" "name" {}형태로 정의됩니다. - Data Source: Terraform 외부(이미 존재하는 클라우드 자원 등)에서 정보를 가져오는 데 사용됩니다. 예를 들어, 이미 생성된 VPC의 ID를 가져오거나, 최신 AMI ID를 조회하는 데 사용될 수 있습니다.
data "type" "name" {}형태로 정의됩니다. - Variables: 인프라 코드에 유연성을 제공하기 위해 사용되는 입력값입니다. 환경별로 달라지는 값(예: 리전, 인스턴스 타입)을 변수로 정의하여 코드를 재사용할 수 있습니다.
- Outputs: Terraform이 인프라를 배포한 후 결과로 출력하는 값입니다. 예를 들어, 생성된 EC2 인스턴스의 퍼블릭 IP 주소나 S3 버킷의 ARN 등을 외부에서 쉽게 참조할 수 있도록 출력합니다.
- State File (.tfstate): Terraform이 관리하는 인프라의 실제 상태를 기록하는 파일입니다. 이 파일은 Terraform이 현재 클라우드에 어떤 자원이 배포되어 있는지, 그리고 각 자원의 속성은 무엇인지 파악하는 데 사용됩니다. 매우 중요한 파일이므로 안전하게 관리(보통 S3와 같은 원격 백엔드 사용)해야 합니다.
3. AWS 환경 설정 및 Terraform 설치
3.1. AWS CLI 및 자격 증명 설정
Terraform이 AWS 리소스에 접근하고 관리하려면 AWS 자격 증명이 필요합니다. 가장 일반적인 방법은 AWS CLI를 설치하고 자격 증명을 구성하는 것입니다. Terraform은 기본적으로 AWS CLI가 사용하는 자격 증명 파일을 자동으로 찾아서 사용합니다.
- AWS CLI 설치: AWS CLI 공식 문서를 참조하여 설치합니다.
- AWS 자격 증명 설정: 터미널에서 다음 명령어를 실행하고, AWS Access Key ID, Secret Access Key, 기본 리전, 출력 형식을 입력합니다.
이 정보는aws configure~/.aws/credentials(Access Key ID, Secret Access Key)와~/.aws/config(리전, 출력 형식) 파일에 저장됩니다.
보안 경고: 운영 환경에서는 IAM 사용자 대신 IAM Role을 사용하여 권한을 관리하는 것이 훨씬 안전합니다. EC2 인스턴스에서 Terraform을 실행하거나 CI/CD 파이프라인에서 사용하는 경우, 해당 인스턴스나 파이프라인에 적절한 IAM Role을 부여하는 것을 권장합니다.
3.2. Terraform 설치
Terraform 설치는 운영체제에 따라 다릅니다. Terraform 공식 다운로드 페이지에서 최신 버전을 확인하고 설치할 수 있습니다. 여기서는 macOS와 Linux 환경에서 일반적으로 사용되는 방법을 안내합니다.
- macOS (Homebrew 사용):
brew tap hashicorp/tap brew install hashicorp/tap/terraform - Linux (apt 또는 yum 사용):
# Debian/Ubuntu sudo apt update && sudo apt install -y gnupg software-properties-common wget -O- https://apt.releases.hashicorp.com/gpg | \ gpg --dearmor | \ sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg gpg --no-default-keyring \ --keyring /usr/share/keyrings/hashicorp-archive-keyring.gpg \ --fingerprint 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 # RHEL/CentOS sudo yum install -y yum-utils sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo sudo yum install terraform
설치 후 다음 명령어로 Terraform이 제대로 설치되었는지 확인합니다.
terraform -v
Image by onkelglocke on Pixabay
4. 첫 번째 Terraform 프로젝트: S3 버킷 생성
이제 Terraform을 사용하여 AWS S3 버킷을 생성하는 간단한 프로젝트를 진행해 보겠습니다.
4.1. 프로젝트 디렉토리 생성 및 파일 작성
새로운 디렉토리를 만들고 그 안에 main.tf 파일을 생성합니다.
mkdir terraform-s3-example
cd terraform-s3-example
touch main.tf
main.tf 파일에 다음 내용을 작성합니다.
# AWS Provider 설정
provider "aws" {
region = "ap-northeast-2" # 원하는 AWS 리전으로 변경하세요 (예: us-east-1)
}
# S3 버킷 리소스 정의
resource "aws_s3_bucket" "my_first_bucket" {
bucket = "my-unique-first-terraform-bucket-12345" # 전역적으로 고유한 이름으로 변경하세요!
acl = "private" # 접근 제어 목록 (private, public-read, public-read-write 등)
tags = {
Name = "MyFirstTerraformBucket"
Environment = "Dev"
}
}
# S3 버킷의 ARN을 출력 (Output)
output "bucket_arn" {
description = "The ARN of the S3 bucket"
value = aws_s3_bucket.my_first_bucket.arn
}
# S3 버킷의 ID를 출력 (Output)
output "bucket_id" {
description = "The ID of the S3 bucket"
value = aws_s3_bucket.my_first_bucket.id
}
주의: S3 버킷 이름은 AWS 내에서 전역적으로 고유해야 합니다. my-unique-first-terraform-bucket-12345 부분을 본인만의 고유한 이름으로 변경해야 합니다.
4.2. Terraform 초기화
Terraform 프로젝트를 시작하려면 먼저 초기화해야 합니다. 이 과정에서 Provider 플러그인과 모듈이 다운로드됩니다.
terraform init
성공적으로 초기화되면 Terraform has been successfully initialized! 메시지를 볼 수 있습니다.
4.3. 실행 계획 확인
Terraform이 어떤 작업을 수행할지 미리 확인하는 단계입니다. 이 명령은 실제 리소스를 생성하거나 변경하지 않고, 계획(plan)만 보여줍니다.
terraform plan
출력 결과를 통해 Terraform이 aws_s3_bucket.my_first_bucket 리소스를 생성(+ create)할 것임을 확인할 수 있습니다.
4.4. 인프라 배포
계획이 마음에 든다면, 이제 실제로 인프라를 배포할 차례입니다. apply 명령은 plan에서 확인한 작업을 실행합니다.
terraform apply
Terraform은 다시 한 번 계획을 보여준 후, Do you want to perform these actions? 메시지와 함께 yes를 입력하도록 요청합니다. yes를 입력하면 S3 버킷이 생성됩니다. 배포가 완료되면 Apply complete! Resources: 1 added, 0 changed, 0 destroyed. 메시지와 함께 output으로 정의했던 버킷의 ARN과 ID가 출력될 것입니다.
이제 AWS 콘솔에 로그인하여 S3 서비스에서 my-unique-first-terraform-bucket-12345 (본인이 설정한 이름) 버킷이 생성되었는지 확인해 보세요.
4.5. 인프라 삭제
생성된 리소스를 더 이상 사용하지 않을 경우, Terraform을 사용하여 쉽게 삭제할 수 있습니다. 이는 테스트 환경을 깔끔하게 유지하는 데 매우 유용합니다.
terraform destroy
마찬가지로 삭제 계획을 보여준 후, yes를 입력하여 버킷을 삭제합니다. Destroy complete! Resources: 1 destroyed. 메시지가 출력되면 성공적으로 삭제된 것입니다.
5. 더 나아가기: EC2 인스턴스 배포 및 상태 관리
S3 버킷은 간단한 예시였지만, 실제 인프라는 훨씬 복잡합니다. 이번에는 EC2 인스턴스와 같은 컴퓨팅 자원을 배포하고, Terraform 상태 관리의 중요성에 대해 알아보겠습니다.
5.1. EC2 인스턴스 배포
main.tf 파일을 다음과 같이 수정하여 EC2 인스턴스를 추가해 보겠습니다.
# AWS Provider 설정
provider "aws" {
region = "ap-northeast-2"
}
# EC2 인스턴스 리소스 정의
resource "aws_instance" "web_server" {
ami = "ami-0c9c73335759163c4" # 서울 리전(ap-northeast-2)의 Amazon Linux 2 AMI
instance_type = "t2.micro"
key_name = "my-ssh-key" # 미리 생성된 EC2 키페어 이름 (본인의 키페어로 변경)
tags = {
Name = "WebServerInstance"
Environment = "Dev"
}
}
# EC2 인스턴스의 퍼블릭 IP를 출력
output "instance_public_ip" {
description = "The public IP address of the EC2 instance"
value = aws_instance.web_server.public_ip
}
주의:
ami값은 사용하려는 리전과 OS에 따라 달라집니다. 위 예시는 서울 리전의 Amazon Linux 2 AMI입니다. 다른 AMI를 사용하려면 AWS EC2 콘솔에서 "AMI" 메뉴를 통해 검색하거나, Terraform data source를 활용하여 동적으로 가져올 수 있습니다.key_name은 AWS에 미리 등록된 EC2 키페어 이름이어야 합니다. SSH 접속을 위해 필요하므로, 본인의 키페어 이름으로 변경하거나 새로운 키페어를 생성해야 합니다.
이 파일을 저장한 후, 다시 다음 명령어를 실행하여 EC2 인스턴스를 배포합니다.
terraform init # (Provider가 변경되지 않았다면 생략 가능)
terraform plan
terraform apply
terraform apply 후 yes를 입력하면 EC2 인스턴스가 생성되고, 인스턴스의 퍼블릭 IP 주소가 출력됩니다.
5.2. Terraform 상태 파일 (.tfstate) 관리의 중요성
Terraform은 .tfstate 파일에 현재 관리하는 인프라의 상태를 기록합니다. 이 파일은 다음과 같은 이유로 매우 중요합니다.
- 인프라와 코드의 동기화: Terraform은
.tfstate파일과 현재 코드를 비교하여 어떤 변경 사항이 필요한지 파악합니다. - 의존성 관리: 리소스 간의 의존성을 추적하여 올바른 순서로 리소스를 생성하거나 파괴합니다.
- 원격 상태 (Remote State): 여러 개발자가 협업하거나 CI/CD 파이프라인에서 Terraform을 사용하는 경우,
.tfstate파일을 로컬에 두는 것은 문제가 발생할 수 있습니다. 예를 들어, 두 명이 동시에terraform apply를 실행하면 상태 파일이 덮어쓰여지거나 충돌할 수 있습니다.이러한 문제를 해결하기 위해 원격 상태(Remote State)를 사용하는 것이 강력히 권장됩니다. AWS 환경에서는 S3 버킷을 사용하여 상태 파일을 저장하고, DynamoDB를 사용하여 상태 파일 잠금(Locking)을 구현하여 동시성 문제를 방지할 수 있습니다.
원격 상태를 설정하는 예시 (main.tf 파일 상단에 추가):
terraform {
backend "s3" {
bucket = "my-terraform-state-bucket-unique-12345" # 고유한 S3 버킷 이름
key = "terraform.tfstate"
region = "ap-northeast-2"
encrypt = true
dynamodb_table = "terraform-lock-table" # 미리 생성된 DynamoDB 테이블 이름
}
}
원격 상태를 설정한 후에는 다시 terraform init을 실행하여 로컬 상태 파일을 S3 버킷으로 마이그레이션해야 합니다.
Image by ramboldheiner on Pixabay
6. Terraform 모범 사례 및 팁
Terraform을 효과적으로 사용하기 위한 몇 가지 모범 사례와 팁입니다.
- 모듈화 (Modulization): 재사용 가능한 인프라 구성 요소를 모듈로 만들어 관리하면 코드의 가독성과 유지보수성이 향상됩니다. 예를 들어, VPC, EC2 인스턴스 그룹, RDS 데이터베이스 등을 각각의 모듈로 분리할 수 있습니다.
- 워크스페이스 (Workspaces): 개발, 스테이징, 프로덕션과 같이 여러 환경에 동일한 코드를 배포해야 할 때 워크스페이스를 활용할 수 있습니다. 각 워크스페이스는 독립적인 상태 파일을 가집니다. (
terraform workspace new dev,terraform workspace select dev) - 변수 (Variables) 활용: 환경별로 달라지는 값이나 민감한 정보는 변수로 분리하여 관리합니다.
variables.tf파일에 변수를 정의하고,terraform.tfvars파일이나 환경 변수를 통해 값을 주입할 수 있습니다. - 민감한 정보 관리: 데이터베이스 비밀번호, API 키와 같은 민감한 정보는 절대로 코드에 하드코딩하지 않습니다. AWS Secrets Manager, HashiCorp Vault, 또는 환경 변수를 통해 안전하게 관리해야 합니다.
- 정기적인
terraform plan: 변경 사항을 적용하기 전에 항상terraform plan을 실행하여 예상되는 변경 사항을 검토합니다. CI/CD 파이프라인에 포함하여 자동화하는 것도 좋습니다. .terraformignore사용: Git과 마찬가지로,.terraform디렉토리나.tfstate파일 등 버전 관리에서 제외할 파일을.terraformignore에 명시합니다.
7. 결론 및 다음 단계
오늘은 Terraform을 사용하여 AWS 인프라를 코드로 관리하는 방법에 대해 알아보았습니다. Terraform의 기본 개념부터 AWS 환경 설정, S3 버킷 및 EC2 인스턴스 배포, 그리고 중요한 상태 관리와 모범 사례까지 다루었습니다.
IaC는 현대 클라우드 환경에서 인프라를 효율적이고 안정적으로 관리하기 위한 필수적인 기술입니다. Terraform은 그 중심에서 강력한 역할을 수행하며, 여러분의 클라우드 여정을 더욱 순조롭게 만들어 줄 것입니다. 처음에는 다소 복잡하게 느껴질 수 있지만, 꾸준히 실습하고 익숙해지면 인프라 관리의 패러다임을 바꿀 수 있는 강력한 도구가 될 것입니다.
다음 단계로 다음과 같은 주제들을 탐구해 보시는 것을 추천합니다.
- Terraform 모듈 생성 및 사용: 재사용 가능한 인프라 컴포넌트를 직접 만들어 보세요.
- 다른 AWS 리소스 관리: VPC, RDS, Lambda 등 다양한 AWS 리소스를 Terraform으로 배포해 보세요.
- CI/CD 파이프라인 통합: Jenkins, GitHub Actions, GitLab CI/CD 등과 연동하여 Terraform 배포를 자동화해 보세요.
- Terraform Cloud/Enterprise: 협업 및 상태 관리를 위한 HashiCorp의 솔루션을 알아보세요.
이 튜토리얼이 여러분의 클라우드 인프라 관리 여정에 좋은 시작점이 되었기를 바랍니다. Terraform을 활용하여 더 효율적이고 안정적인 인프라를 구축하시길 응원합니다!
혹시 Terraform을 사용하면서 궁금한 점이나 공유하고 싶은 팁이 있으시다면, 언제든지 댓글로 남겨주세요. 함께 성장해나가는 커뮤니티가 되었으면 좋겠습니다!
'튜토리얼' 카테고리의 다른 글
| 2024년 최신 eBPF 실무 활용법: 실시간 컨테이너 네트워크 성능 모니터링 시스템 완벽 구축 가이드 (0) | 2026.03.14 |
|---|---|
| 2026년 최신 GitOps 기반 Kubernetes 자동 배포 시스템 구축 완벽 가이드: Argo CD 실무 활용법 (0) | 2026.03.13 |
| Git hooks로 코드 품질 자동 관리하기 (0) | 2026.03.12 |
| PostgreSQL 성능 튜닝 실전 가이드 (0) | 2026.03.12 |
| 리눅스 서버 초기 세팅 체크리스트: 안전하고 효율적인 시작을 위한 가이드 (0) | 2026.03.12 |