클릭 몇 번 하다가 밤새던 내가 테라폼(Terraform)알고 칼퇴

마우스 클릭으로 서버 만들던 시절과 작별하기

몇 년 전, 새로 들어간 프로젝트에서 급하게 테스트 환경을 구축해 달라는 요청을 받았습니다. 평소 하던 대로 AWS 콘솔에 로그인해서 신나게 마우스를 클릭했죠. VPC를 만들고, 서브넷을 쪼개고, EC2 인스턴스를 올린 뒤 보안 그룹까지 꼼꼼하게 설정했습니다. 제 눈에는 완벽해 보였습니다.

하지만 진짜 문제는 그다음 날 터졌습니다. “개발팀용, 검증팀용으로 똑같은 환경 2개만 더 만들어 주세요”라는 메일을 받은 것입니다. 다시 콘솔을 열고 어제 내가 뭘 클릭했는지 기억을 더듬어가며 작업했지만, 귀신같이 보안 그룹 설정 하나가 누락되어 통신 에러가 발생했습니다. 원인을 찾느라 결국 새벽까지 모니터를 붙잡고 있어야 했죠.

이처럼 사람이 손으로 직접 인프라를 만들다 보면 반드시 실수가 나옵니다. 규모가 커져서 관리해야 할 서버가 수십, 수백 대가 되면 클릭 몇 번으로 감당할 수 없는 수준이 되죠. 이런 끔찍한 삽질을 막기 위해 등장한 구원투수가 바로 IaC(Infrastructure as Code), 즉 ‘코드로 관리하는 인프라’입니다.

왜 수많은 도구 중 하필 ‘테라폼’일까?

인프라를 자동화해 주는 도구는 생각보다 많습니다. AWS의 CloudFormation도 있고, 설정 관리에 강한 Ansible도 있죠. 하지만 현업에서 일하는 엔지니어들에게 “요즘 뭐 써요?”라고 물어보면 십중팔구 테라폼(Terraform)이라는 답이 돌아옵니다. 왜 이렇게 인기가 많을까요? 실제로 제가 굴러보며 느낀 장점은 크게 세 가지입니다.

1. 클라우드를 가리지 않는 유연함

AWS만 쓰다가 갑자기 회사의 방향이 바뀌어 Azure나 GCP, 심지어 오라클 클라우드(OCI)까지 섞어 써야 하는 상황이 올 수 있습니다. 이때 테라폼은 빛을 발합니다. 특정 클라우드 벤더에 종속되지 않기 때문에, 테라폼 문법 하나만 잘 익혀두면 어떤 클라우드 환경이든 부드럽게 넘나들며 인프라를 짤 수 있습니다.

2. “과정은 몰라, 결과만 맞춰줘” 선언적 언어의 매력

Ansible 같은 도구는 “A를 하고, 그다음에 B를 한 뒤, C를 해라”라는 식으로 순서를 일일이 알려줘야 합니다. 반면 테라폼은 “내가 원하는 최종 상태는 EC2 인스턴스 3대야”라고 결과만 적어두면 끝입니다. 만약 기존에 1대가 켜져 있었다면, 테라폼이 알아서 계산해서 부족한 2대만 추가로 만들어 줍니다. 엔지니어가 머리 싸매고 순서를 계산할 필요가 없어서 실수가 확 줄어듭니다.

3. 고쳐 쓰지 않고 새로 만드는 ‘불변의 인프라’

기존 서버에 들어가서 설정을 이리저리 수정하다 보면, 나중에 이 서버가 왜 작동하는지 아무도 모르는 ‘마법의 서버’가 되곤 합니다. 테라폼은 기존 것을 고치는 게 아니라, 새로운 설정을 가진 깨끗한 서버를 새로 띄우고 예전 서버를 지우는 방식(Immutable Infrastructure)을 지향합니다. 덕분에 인프라 꼬임 현상에서 해방될 수 있습니다.

테라폼을 움직이는 뼈대 구조 훑어보기

테라폼을 내 손으로 직접 다루기 전에, 이 녀석이 어떤 구조로 돌아가는지 핵심 개념 5가지만 아주 쉽게 짚고 넘어가겠습니다.

• HCL (HashiCorp Configuration Language): 테라폼 전용 언어입니다. 코딩의 ‘ㅋ’자만 알아도 한눈에 읽힐 정도로 직관적이고 가독성이 좋습니다.
• Provider (프로바이더): 테라폼이 클라우드 API와 대화할 수 있게 도와주는 통역사입니다. AWS용, Azure용 프로바이더가 각각 존재합니다.
• State File (terraform.tfstate): 현재 내 실제 클라우드 인프라가 어떤 상태인지 적어둔 ‘비밀 장부’입니다. JSON 형태로 되어 있으며, 테라폼 운영에서 가장 중요한 파일입니다.
• Backend (백엔드): 위에서 말한 비밀 장부(State File)를 어디에 안전하게 보관할지 지정하는 저장소입니다. 보통 AWS S3 같은 원격 저장소를 씁니다.
• Module (모듈): 자주 쓰는 인프라 코드 묶음을 부품처럼 만들어 둔 것입니다. 레고 블록처럼 가져다 쓸 수 있어 재사용성이 극대화됩니다.

4단계로 요약하는 테라폼의 생애 주기

실무에서 테라폼으로 인프라를 만들고 지울 때는 딱 4가지만 기억하면 됩니다. 이 루틴은 엔지니어의 하루 일과이기도 합니다.

1. Init (초기화): “자, 이제 시작해 볼까?” 하고 필요한 플러그인을 다운로드하는 단계입니다.
2. Plan (계획 확인): (가장 중요!) 코드를 실행했을 때 내 클라우드에 어떤 변화가 생길지 미리 미리보기(Dry-run)하는 단계입니다. 어떤 리소스가 생성되고 지워지는지 여기서 꼼꼼히 안 보면 대형 장애로 이어집니다.
3. Apply (실행): “좋아, 계획대로 진행시켜!” 하고 실제로 클라우드에 인프라를 생성하는 단계입니다. 완료되면 비밀 장부(State File)에 기록됩니다.
4. Destroy (삭제): 만들어진 모든 리소스를 흔적도 없이 지우는 단계입니다. 테스트 환경을 정리할 때 주로 쓰며, 운영 환경에서는 절대 함부로 치면 안 되는 명령어입니다.

맛보기 코드로 짜보는 AWS 네트워크와 서버

말로만 들으면 감이 안 오니, AWS에 아주 기본적인 VPC 네트워크와 EC2 인스턴스 하나를 올리는 코드가 어떻게 생겼는지 가볍게 구경해 봅시다.

Terraform

# 1. 어떤 클라우드를 쓸지 통역사를 지정합니다.
provider "aws" {
  region = "ap-northeast-2" # 서울 리전
}

# 2. 내 가상 네트워크망(VPC)을 만듭니다.
resource "aws_vpc" "main_vpc" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true

  tags = {
    Name = "My-First-VPC"
  }
}

# 3. 그 네트워크 안에 웹 서버 하나를 띄웁니다.
resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0" # 우분투 이미지 ID (리전별 확인 필요)
  instance_type = "t3.medium"

  tags = {
    Name = "Hello-Terraform-Server"
  }
}

여기서 주의할 점이 하나 있습니다. 아무 인터넷 블로그에 있는 ami-xxxx 코드를 그대로 긁어서 복사하면 100% 에러가 납니다. 클라우드 벤더사나 리전마다, 그리고 시기마다 사용할 수 있는 이미지 ID와 인스턴스 타입이 조금씩 다르기 때문입니다. 코드를 실행하기 전에 내 환경에서 지원하는 스펙인지 확인하는 버릇을 들이는 것이 좋습니다.

굴러보며 깨달은 시니어의 테라폼 실무 팁

⚠️ 비밀 장부(State 파일)를 절대 로컬에 두지 마세요

처음 테라폼을 배우면 내 컴퓨터 바탕화면에 terraform.tfstate 파일이 생깁니다. 혼자 연습할 땐 상관없지만, 팀원들과 같이 일할 때 이 파일을 각자 로컬에 두고 쓰면 인프라가 완전히 꼬여버립니다. 동료가 서버를 지웠는데 내 장부에는 살아있는 상태가 되는 거죠. 반드시 AWS S3 같은 원격 백엔드에 저장하고, DynamoDB를 연동해 한 사람이 수정 중일 땐 다른 사람이 못 건드리게 락(Locking)을 걸어두세요.

⚠️ 하드코딩은 미래의 나를 치는 부메랑입니다

코드 안에 IP 주소나 인스턴스 크기를 무턱대고 적어두지 마세요. 나중에 사양을 변경하거나 개발 환경에서 운영 환경으로 코드를 복사할 때 골치가 아파집니다. 변수 파일(variables.tf)을 따로 만들어서 값들을 빼놓는 습관을 들이면, 나중에 코드 재사용하기가 훨씬 편해집니다.

⚠️ 처음부터 거대하게 짜지 마세요

네트워크, 데이터베이스, 웹 서버 코드를 파일 하나에 전부 몰아넣으면 나중에 코드가 수천 줄로 늘어나 손대기 무서워집니다. 처음에는 작게 시작하더라도 네트워크 모듈, 서버 모듈처럼 기능을 쪼개서 관리하는 ‘모듈화’를 고민해 보세요. 그래야 인프라 규모가 커져도 길을 잃지 않습니다.

마치며: 인프라 자동화는 선택이 아닌 필수

예전에는 서버실에서 땀 흘리며 무거운 장비를 랙에 꽂고 케이블을 연결해야만 ‘인프라를 한다’고 했습니다. 하지만 지금은 모니터 앞에 앉아 코드를 정교하게 짜고 아키텍처를 설계하는 능력이 엔지니어의 진짜 경쟁력이 되었습니다.

테라폼은 여러분의 퇴근 시간을 앞당겨줄 가장 강력한 무기입니다. 처음에는 콘솔 클릭이 더 빠르다고 느껴질 수 있습니다. 하지만 한 번 잘 짜여진 코드는 두고두고 여러분의 든든한 자산이 될 것입니다. 오늘 당장 프로젝트의 작은 리소스 하나부터 코드로 직접 만들어 보는 건 어떨까요?

전문가의 인사이트 : 함께 읽어 보세요.

[성능 Monitoring 체계 구축: OS와 DB 레벨에서 반드시 확인해야 할 핵심 지표]

참조 및 출처 URL:

https://developer.hashicorp.com/terraform/docs