Terraform부터 Kubernetes까지: 현대 인프라 구축의 전체 로드맵 마스터 가이드

클라우드 환경에 발을 들인 개발자나 주니어 DevOps 엔지니어라면, 아마도 'Terraform으로 인프라를 만들고', 'Kubernetes로 애플리케이션을 배포한다'는 두 가지 키워드를 수없이 접했을 겁니다. 이 두 기술은 현대 인프라의 양대 산맥이라 불릴 만큼 중요합니다.

하지만 문제는 무엇일까요? 이 두 기술을 개별적으로 학습하다 보면, 마치 멋진 레고 블록들을 잔뜩 모아놓고 '이걸 어떻게 연결해서 멋진 성을 만들지?'라는 질문 앞에서 막막함을 느끼기 쉽습니다.

이 글은 단순한 기술 나열이 아닙니다. 클라우드 리소스 프로비저닝부터 애플리케이션의 배포, 그리고 이 모든 과정을 자동화하는 CI/CD 파이프라인까지, 현대적인 엔터프라이즈급 인프라를 처음부터 끝까지 구축하고 운영하는 전체적인 원리와 흐름을 한눈에 정리한 최종 마스터 가이드입니다.

🧱 인프라의 기반 다지기: IaC(Infrastructure as Code)의 역할과 Terraform

우리가 건물을 짓는다고 가정해 봅시다. 건물을 짓기 전에 땅을 다지고, 전기와 수도 배관을 깔고, 건물의 뼈대(골조)를 세워야 합니다. 이 '땅 다지기'와 '뼈대 세우기' 과정이 바로 인프라(Infrastructure)를 구축하는 일이며, 이 과정을 코드로 관리하는 것이 IaC입니다.

Terraform은 이 IaC의 대표 주자입니다. Terraform의 핵심은 **'상태 관리(State Management)'**와 **'선언적(Declarative) 방식'**입니다.

• 선언적 방식: "나는 이런 구조의 VPC가 필요해"라고 원하는 최종 상태만 선언하면, Terraform이 현재 상태와 비교하여 차이점만 계산해 필요한 변경(Plan)을 실행합니다.
• 상태 파일: Terraform은 terraform.tfstate 파일을 통해 "현재 내가 만든 인프라의 실제 모습"을 기록합니다. 이 상태 파일 덕분에, 수백 개의 리소스 중 어떤 것이 이미 존재하고 어떤 것이 누락되었는지 정확히 파악할 수 있습니다.

💡 실무 팁: Terraform을 사용할 때, 클라우드 제공사(AWS, Azure 등)의 리소스에 접근하기 위해 Provider를 설정해야 합니다. 이 Provider가 마치 '클라우드 API 통역사' 역할을 한다고 이해하시면 쉽습니다.

🚀 애플리케이션 배포의 표준: 컨테이너 오케스트레이션과 Kubernetes

인프라가 준비되었다면, 이제 그 위에 실제 서비스를 올려야 합니다. 여기서 컨테이너가 등장합니다. 컨테이너는 애플리케이션과 그 실행에 필요한 모든 종속성을 하나의 패키지로 묶어주어, "내 노트북에서는 잘 됐는데 서버에서는 안 돼요"라는 문제를 원천적으로 차단합니다.

하지만 컨테이너는 그 자체로 '단일 컨테이너'에 불과합니다. 실제 서비스는 수십, 수백 개의 컨테이너로 구성되며, 이들을 안정적으로 띄우고, 장애가 나면 자동으로 재시작하며, 트래픽이 몰리면 자동으로 늘려주는 '관리 시스템'이 필요합니다. 이것이 바로 컨테이너 오케스트레이션이며, 그 표준이 바로 **Kubernetes(K8s)**입니다.

Kubernetes는 다음과 같은 역할을 수행합니다.

1. 자동 스케일링: 트래픽에 따라 파드(Pod) 수를 자동으로 조절합니다.
2. 자가 복구(Self-Healing): 컨테이너 하나가 죽으면, 즉시 새 컨테이너로 대체합니다.
3. 서비스 디스커버리: 컨테이너들이 서로를 찾을 수 있도록 네트워크 주소를 관리합니다.

IaC와 K8s, 무엇이 다른가? (역할 분리 비교)

두 기술은 서로 다른 계층의 문제를 해결합니다. 이 차이를 명확히 아는 것이 가장 중요합니다.

🔗 두 기술의 완벽한 결합: GitOps 기반 CI/CD 파이프라인 구축 전략

개별 기술의 이해를 넘어, 이들을 연결하는 '자동화 워크플로우'가 바로 진정한 DevOps 역량입니다. 여기서 핵심 개념이 GitOps입니다.

GitOps는 "애플리케이션과 인프라의 모든 상태를 Git 저장소(Source of Truth)에 코드로 선언하고, 이 Git의 상태를 클러스터가 스스로 동기화하여 유지하는 방식"입니다.

전체 아키텍처 흐름도 (Conceptual Flow):

graph TD
    A[개발자 코드 커밋] --> B{Git Repository};
    B --> C[CI Pipeline (Jenkins/GitHub Actions)];
    C --> D{Artifact 생성 (Docker Image)};
    D --> E[IaC 실행 (Terraform Plan/Apply)];
    E --> F[클라우드 리소스 준비 (VPC, EKS Cluster)];
    F --> G[K8s Manifest 업데이트 (Helm Chart/YAML)];
    G --> H[CD Pipeline (ArgoCD/Flux)];
    H --> I[K8s Cluster에 배포 및 동기화];

실제 워크플로우 예시:

1. 인프라 준비 (Terraform): 먼저, EKS 클러스터 자체를 Terraform으로 배포합니다.
   Bash복사

   # 1. 필요한 리소스 정의 및 계획 수립
   terraform init
   terraform plan -out=tfplan
   
   # 2. 계획에 따라 실제 클라우드 리소스 생성/수정
   terraform apply tfplan

2. 애플리케이션 배포 (K8s/GitOps): 클러스터가 준비되면, 애플리케이션의 배포 정의(Deployment YAML)를 Git에 커밋합니다. ArgoCD 같은 툴이 이 커밋을 감지하고, 클러스터의 실제 상태를 Git의 상태와 일치시키도록 kubectl apply와 유사한 작업을 수행합니다.

📚 핵심 개념 정리 및 학습 로드맵

이 가이드를 통해 접한 몇 가지 핵심 용어들을 정리해 보겠습니다.

✅ 핵심 용어 5가지 정의

1. Idempotency (멱등성): 같은 작업을 여러 번 수행해도 결과가 항상 동일함을 의미합니다. IaC가 이 원칙을 따르기 때문에, 같은 코드를 여러 번 실행해도 인프라가 꼬이지 않습니다.
2. Declarative (선언적): "어떻게(How)"가 아닌, "무엇을(What)" 원하는지만 명시하는 방식입니다. (예: "웹서버가 3대 필요해" $\rightarrow$ K8s가 알아서 3대를 유지함)
3. Provider: Terraform이 특정 클라우드(AWS, GCP 등)와 통신하기 위해 사용하는 플러그인입니다.
4. GitOps: Git을 인프라와 애플리케이션의 '단일 진실 공급원(Single Source of Truth)'으로 삼고, Git의 변경 사항을 기반으로 시스템을 자동 동기화하는 운영 패러다임입니다.
5. State File: Terraform이 현재 관리하고 있는 인프라의 스냅샷입니다. 이 파일이 손상되면 인프라 관리에 큰 문제가 생길 수 있습니다.

✍️ 실무자의 경험적 조언: 초기 학습 단계에서 많은 분들이 'Terraform으로 K8s를 만들고, K8s로 애플리케이션을 배포'하는 순서에 집착합니다. 하지만 실제로는 'Terraform으로 클라우드 기반의 K8s 클러스터(EKS/AKS)를 먼저 띄운다' $\rightarrow$ **'그 위에 GitOps 툴(ArgoCD)을 설치하여 K8s를 관리한다'**는 순서가 가장 안정적입니다. 인프라와 오케스트레이션 툴 자체도 코드로 관리해야 합니다.

🗺️ 당신의 DevOps 로드맵 완성하기

이 가이드가 제시하는 최종 목표는 '개별 기술 숙련'이 아닌, **'자동화된 전체 흐름 구축'**입니다. 다음의 순서로 학습 목표를 재설정해 보세요.

1. Level 1 (기반): Terraform을 이용해 최소한의 클라우드 리소스(VPC, Subnet)를 코드로 배포하는 연습.
2. Level 2 (실행): K8s의 기본 개념(Pod, Deployment, Service)을 이해하고, kubectl로 수동 배포를 성공시키는 연습.
3. Level 3 (연결): Terraform으로 K8s 클러스터 자체를 배포하고, GitOps 툴(ArgoCD 등)을 설치하여 Git 커밋만으로 애플리케이션이 배포되도록 자동화하는 전체 파이프라인을 구축하는 것을 목표로 삼아야 합니다.

이 로드맵을 따라가신다면, 단순한 '사용자'가 아닌, '시스템 설계자'로서의 역량을 갖추게 될 것입니다.

자주 묻는 질문 (FAQ)

Q. Terraform과 Kubernetes 중 무엇부터 깊게 파는 것이 좋을까요? A. 클라우드 환경에 대한 이해가 부족하다면 Terraform으로 기반(VPC, IAM)을 잡는 것부터 시작하는 것이 좋습니다. K8s는 그 기반 위에서 동작하는 애플리케이션 레이어이기 때문입니다.

Q. GitOps를 사용하면 CI/CD 툴(Jenkins 등)이 필요 없나요? A. 완전히 대체하는 것은 아닙니다. CI 툴은 '빌드'와 '아티팩트 생성(Docker Image)'을 담당하고, GitOps 툴(ArgoCD 등)은 '배포 및 동기화'를 담당하는 역할 분담이 가장 이상적입니다.

Q. IaC와 K8s Manifest를 같은 곳에 관리하는 것이 좋은가요? A. 네, 강력히 권장됩니다. 모든 인프라 정의와 애플리케이션 정의를 하나의 Git 저장소(Monorepo)에 두는 것이 GitOps의 철학이며, 관리 용이성 측면에서 가장 효율적입니다.