[리눅스 기초 #56] 명령어로 창조하는 클라우드 세상: 테라폼(Terraform)으로 코드형 인프라(IaC) 시작하기

 

리눅스 기초 시리즈의 56번째 시간입니다! 지난 시간에는 Redis를 활용해 웹 서비스의 혈액순환을 돕는 캐싱 전략을 배웠습니다. 이제 우리는 서버 한 대의 성능을 극한으로 끌어올릴 줄 아는 고수가 되었습니다. 하지만 서비스가 대박이 나서 똑같은 설정의 서버 100대를 한꺼번에 만들어야 한다면 어떨까요? 다시 1번부터 55번 포스팅을 보며 마우스를 클릭하실 건가요?

현대적인 인프라 운영의 핵심은 '사람의 손'을 타지 않는 것입니다. 오늘은 마우스 클릭 대신 코드로 서버와 네트워크를 설계하고 생성하는 테라폼(Terraform)의 세계로 여러분을 안내합니다. 코드형 인프라(IaC)를 통해 리눅스 서버를 '창조'하는 과정을 저의 생생한 경험담과 함께 정리해 보겠습니다.

---

1. 나의 경험담: "클라우드 콘솔의 미로에서 탈출하다"

 

최근 제 프로젝트 규모가 커지면서 AWS(Amazon Web Services) 위에 여러 대의 리눅스 인스턴스를 띄워야 했습니다. 처음에는 콘솔 화면에서 열심히 클릭하며 VPC를 만들고, 서브넷을 쪼개고, 보안 그룹을 설정했죠. 그런데 테스트 환경과 운영 환경을 똑같이 맞추는 과정에서 사소한 설정 하나를 빼먹는 바람에 원인 모를 네트워크 에러로 주말을 통째로 반납해야 했습니다.

"이걸 사람이 할 짓이 아니구나"라는 깨달음과 함께 도입한 것이 바로 테라폼이었습니다. 복잡한 네트워크 구성을 .tf 파일에 한 번 적어두니, 명령어 한 줄로 똑같은 환경이 5분 만에 뚝딱 만들어지더군요. 이제 저는 더 이상 콘솔의 복잡한 버튼들을 외우지 않습니다. 모든 인프라는 제 Git 저장소 안에 '코드'로 살아있기 때문입니다.

---

2. Before: "불확실성과 휴먼 에러의 연속"

IaC를 쓰기 전에는 인프라의 현재 상태를 알기 위해 관리 콘솔을 일일이 뒤져야 했습니다. "이 보안 그룹은 왜 열려 있지?", "이 서버는 누가 만든 거지?"라는 질문에 누구도 명확히 답할 수 없는 '인프라의 암흑기'였죠.

수동 관리의 고질병:

AWS Console (Legacy)

 

# 1단계: EC2 생성 버튼 클릭

2단계: OS 선택 (Ubuntu 22.04였나 24.04였나..?)
3단계: 인스턴스 타입 선택 (t3.micro 맞겠지?)
4단계: 키 페어 분실... "아, 새로 만들어야겠다"

(▲ Before: 재현 불가능한 '예술 작품' 같은 서버를 만들던 시절입니다. 똑같이 다시 만들라고 하면 절대 못 하죠.)

---

3. Action: 테라폼으로 리눅스 서버 선언하기

 

테라폼의 핵심은 '선언적 언어(HCL)'입니다. "어떻게 만들어라"가 아니라 "이런 상태가 되어야 한다"라고 적는 것이죠. AWS에 리눅스 인스턴스 한 대를 띄우는 코드를 작성해 보겠습니다.

테라폼 정의 코드 (main.tf):

HCL (HashiCorp Configuration Language)

 

# 1. 공급자(Cloud Provider) 설정
provider "aws" {
region = "ap-northeast-2" # 서울 리전
}

2. 리소스 정의 (EC2 인스턴스)
resource "aws_instance" "my_linux_server" {
ami           = "ami-0c9c942bd7bf113a2" # Ubuntu 22.04 AMI ID
instance_type = "t3.micro"

tags = {
Name = "Linux-Basics-56-Server"
}
}

실행 명령어:

Terminal

 

# 초기화 (플러그인 설치)
terraform init

실행 계획 확인 (뭐가 만들어질지 미리 보기)
terraform plan

인프라 생성 (실제 배포!)
terraform apply

(▲ Action: terraform apply를 치는 순간, AWS 위에서 리눅스 서버가 조립되기 시작합니다. 더 이상 클릭은 필요 없습니다.)

---

4. After: "관리되는 인프라, 신뢰의 시스템"

테라폼을 도입한 뒤 제 개발 라이프스타일은 '건축가'의 그것과 닮아갔습니다. 모든 인프라는 도면(코드)대로 지어지고, 관리됩니다.

달라진 점들:

• 환경의 일관성: 개발, 테스트, 운영 서버가 100% 동일한 스펙을 유지합니다.
• 버전 관리: 인프라 변경 이력을 Git에서 확인할 수 있어 "누가 VPC를 건드렸나?"라는 범인 찾기가 끝났습니다.
• 빠른 복구: 서버가 날아가도 코드만 있으면 5분 만에 완벽히 복구됩니다.

---

5. 실험 요약 및 팁

용어	역할	비유
IaC	인프라를 코드로 정의하는 방식	설명서가 있는 레고 블록
Provider	클라우드 서비스 공급자 (AWS, Azure 등)	거래할 대형 마트
State File	현재 인프라 상태를 기록한 지도	집 평면도
Resource	실제 생성될 개체 (서버, DB, VPC)	가구 하나하나

---

6. 마치며: 당신의 서버에 '설계도'를 부여하세요.

리눅스 기초 56단계를 거치며 우리는 이제 한 대의 서버 운영을 넘어, 거대한 인프라를 설계하는 영역까지 발을 들였습니다. 엔진(커널)과 보안, 자동화가 갖춰졌다면 이제는 그 환경을 '박제'하고 '복제'할 능력이 필요합니다. 테라폼은 여러분을 단순한 관리자에서 '인프라 아키텍트'로 끌어올려 줄 최고의 날개입니다.

오늘의 인사이트: "가장 훌륭한 문서는 설명 글이 아니라, 실행 가능한 코드 그 자체다."

---

56번째 이야기를 마칩니다. 이제 우리만의 '코드형 서버'가 탄생했습니다. 다음 시간에는 이렇게 만들어진 수많은 서버를 하나의 거대한 유기체로 묶어주는 끝판왕 기술, '쿠버네티스(Kubernetes) 찍먹하기: 컨테이너 오케스트레이션의 첫걸음'에 대해 다뤄보겠습니다.

이 글이 여러분의 클라우드 운영에 한 줄기 빛이 되었나요? 혹시 테라폼 코드를 실행하다가 'Access Denied' 에러를 만나셨나요?

로컬 환경에서 AWS 자격 증명(Credential)을 안전하게 관리하는 법을 다음 포스팅 부록으로 준비해 드릴까요?