# IaC (Infrastructure as Code, 코드형 인프라)

## 1. 개요
**IaC(Infrastructure as Code, 코드형 인프라)**란 서버, 네트워크, 스토리지 등 IT 인프라의 설정과 관리를 수동 작업이 아닌 기계가 읽을 수 있는 정의 파일(코드)을 통해 자동화하는 소프트웨어 공학적 접근 방식이다.

과거의 **수동 인프라 설정(Manual Configuration)** 방식은 관리자가 클라우드 콘솔에 접속하여 클릭하거나 서버에 직접 접속해 명령어를 입력하는 방식으로 이루어졌다. 이러한 방식은 설정 과정에서 인적 오류(Human Error)가 발생할 가능성이 높고, 인프라 규모가 커질수록 동일한 환경을 복제하는 데 막대한 시간이 소요된다는 단점이 있다. IaC는 이러한 문제를 해결하여 인프라 구축의 속도, 정확성, 그리고 재현성을 보장하기 위해 도입되었다.

## 2. IaC의 핵심 원리와 작동 방식
IaC는 인프라를 정의하는 방식에 따라 크게 **선언적 방식**과 **명령형 방식**으로 나뉜다.

### 2.1 선언적(Declarative) vs 명령형(Imperative) 방식
*   **선언적 방식:** "최종적으로 어떤 상태가 되어야 하는가"를 정의한다. 사용자가 원하는 최종 상태(Desired State)를 기술하면, 도구가 현재 상태를 분석하여 그 차이를 메우는 작업을 자동으로 수행한다.
*   **명령형 방식:** "어떤 순서로 작업을 수행해야 하는가"를 정의한다. 특정 리소스를 생성하고, 설정을 변경하는 일련의 단계(Step-by-step)를 명시적으로 기술한다.

| 구분 | 선언적 방식 (Declarative) | 명령형 방식 (Imperative) |
| :--- | :--- | :--- |
| **핵심 관점** | 최종 상태 (What) | 수행 절차 (How) |
| **특징** | 결과 중심, 멱등성 확보 용이 | 과정 중심, 세밀한 제어 가능 |
| **장점** | 코드 가독성이 높고 관리가 쉬움 | 복잡한 로직이나 순차적 작업에 유리 |
| **대표 도구** | Terraform, Kubernetes Manifest | Ansible, Bash Script, AWS CLI |

> **※ 멱등성(Idempotency)이란?**
> 연산을 여러 번 적용하더라도 결과가 변하지 않는 성질을 의미한다. IaC에서 멱등성이 보장되면, 동일한 코드를 여러 번 실행해도 인프라의 최종 상태는 항상 동일하게 유지되며 중복 리소스가 생성되지 않는다.

### 2.2 상태 관리 (State Management)
IaC 도구는 실제 배포된 인프라의 현재 상태를 기록하는 **상태 파일(State File)**을 관리한다. 이를 통해 도구는 코드로 정의된 '희망 상태'와 실제 환경의 '현재 상태'를 비교하여, 변경이 필요한 부분만 업데이트하는 효율적인 리소스 관리를 수행한다.

## 3. IaC의 주요 장점 및 기대 효과
1.  **자동화 및 속도 향상:** 반복적인 인프라 구축 작업을 코드로 실행하여 배포 시간을 획기적으로 단축한다.
2.  **버전 관리 및 이력 추적:** Git과 같은 버전 관리 시스템을 사용하여 인프라 변경 사항을 기록하고, 문제 발생 시 이전 버전으로 신속하게 롤백(Rollback)할 수 있다.
3.  **환경 일관성 유지 및 드리프트(Drift) 방지:** 개발, 테스트, 운영 환경을 동일한 코드로 생성하여 환경 불일치 문제를 해결한다. 또한, 수동 변경으로 인해 코드와 실제 환경이 달라지는 **구성 드리프트(Configuration Drift)** 현상을 감지하고 수정할 수 있다.
4.  **문서화 대체:** 코드 자체가 인프라의 설계도 역할을 하므로, 별도의 최신 문서 유지 보수 부담이 줄어든다.

### 불변 인프라(Immutable Infrastructure) 전략
IaC는 **불변 인프라** 개념을 가능하게 한다. 기존 서버에 접속해 설정을 수정하는 '가변 인프라(Mutable)' 방식과 달리, 불변 인프라는 변경 사항이 생기면 기존 서버를 수정하지 않고 새로운 이미지로 서버를 완전히 교체한다. 이는 설정 오염을 방지하고 배포의 예측 가능성을 극대화하여 클라우드 네이티브 환경의 핵심 전략으로 활용된다.

## 4. 주요 도구 및 생태계
IaC 도구는 목적에 따라 **인프라 프로비저닝 도구**와 **구성 관리 도구**로 분류된다.

*   **프로비저닝 도구:** 가상 머신, 네트워크, DB 등 하드웨어 수준의 리소스를 생성하고 배치하는 데 집중한다.
*   **구성 관리 도구:** 생성된 서버 내부에 소프트웨어를 설치하고 설정을 변경하는 등 OS 레벨의 관리에 집중한다.

### 주요 도구 비교표
| 도구 | 분류 | 특징 | 주요 용도 |
| :--- | :--- | :--- | :--- |
| **Terraform** | 프로비저닝 | 클라우드 불가지론(Multi-cloud), HCL 언어 사용 | 멀티 클라우드 인프라 구축 |
| **Ansible** | 구성 관리 | Agentless(에이전트 설치 불필요), YAML 기반 | 서버 설정 및 애플리케이션 배포 |
| **CloudFormation** | 프로비저닝 | AWS 전용 서비스, 강력한 AWS 통합 | AWS 전용 인프라 자동화 |
| **Pulumi** | 프로비저닝 | 범용 프로그래밍 언어(Python, TS 등) 사용 | 개발자 친화적 인프라 정의 |

### 도구 선택 가이드 및 학습 곡선
인프라 환경과 팀의 역량에 따라 적절한 도구를 선택해야 한다.

**학습 곡선 (낮음 $\rightarrow$ 높음):**
`Ansible` $\rightarrow$ `CloudFormation` $\rightarrow$ `Terraform` $\rightarrow$ `Pulumi`

**선택 기준 가이드:**
1.  **단일 클라우드(AWS)만 사용하는가?** $\rightarrow$ **CloudFormation** (관리 부담 최소화)
2.  **멀티 클라우드 혹은 하이브리드 환경인가?** $\rightarrow$ **Terraform** (업계 표준, 광범위한 지원)
3.  **서버 내부 설정 및 패키지 관리가 주 목적인가?** $\rightarrow$ **Ansible** (에이전트리스의 편의성)
4.  **인프라 정의에 복잡한 로직(루프, 조건문)이 많이 필요한가?** $\rightarrow$ **Pulumi** (범용 언어 활용 가능)

## 5. IaC 도입 및 구현 프로세스
일반적인 IaC 워크플로우는 다음과 같은 단계로 진행된다.

```mermaid
graph LR
    A[코드 작성] --> B[코드 검증<br/>Lint/Plan]
    B --> C[승인 및 리뷰]
    C --> D[배포<br/>Apply]
    D --> E[모니터링]
```

### 코드 예시 (Terraform)
아래는 AWS에 간단한 EC2 인스턴스 하나를 생성하는 Terraform 코드 예시이다.

```hcl
# AWS 프로바이더 설정
provider "aws" {
  region = "ap-northeast-2"
}

# EC2 인스턴스 리소스 정의
resource "aws_instance" "web_server" {
  # AMI ID는 리전마다 다르므로 실제 사용 시 확인 필요
  ami           = "ami-0c55b159cbfafe1f0" # Amazon Linux 2 AMI ID
  instance_type = "t2.micro"

  tags = {
    Name = "Wiki-Demo-Server"
  }
}
```

## 6. 모범 사례 및 주의사항
*   **모듈화(Modularization):** 반복되는 리소스 묶음을 모듈로 만들어 재사용성을 높이고 코드 중복을 제거해야 한다.
*   **민감 정보 관리:** API 키, 패스워드 등의 Secret 정보를 코드에 직접 하드코딩하는 것은 보안상 매우 위험하다. 이를 방지하기 위해 HashiCorp Vault, AWS Secrets Manager, Azure Key Vault와 같은 전용 비밀 관리 도구를 사용하거나, 환경 변수 및 암호화된 변수 파일을 통해 주입해야 한다.
*   **CI/CD 파이프라인 통합:** 인프라 변경 사항을 자동으로 테스트하고 배포하는 파이프라인을 구축하여 휴먼 에러를 최소화한다.

## 7. IaC의 한계와 극복 방안
### 한계점
*   **학습 곡선:** 도구별 전용 언어(HCL 등)나 복잡한 상태 관리 개념을 익히는 데 시간이 소요된다.
*   **상태 파일 오염:** 상태 파일이 손상되거나 동기화되지 않을 경우 실제 인프라와 괴리가 발생하여 예기치 못한 리소스 삭제가 일어날 수 있다.

### 극복 방안
*   **원격 상태 저장소(Remote Backend):** 상태 파일을 로컬이 아닌 S3, Terraform Cloud 등 공유 저장소에 보관하고 상태 잠금(State Locking) 기능을 사용하여 동시 수정 충돌을 방지한다.
*   **점진적 도입:** 모든 인프라를 한 번에 코드로 전환하기보다, 정적인 리소스부터 단계적으로 적용한다.

## 8. GitOps와의 관계 및 차이점
**GitOps**는 IaC의 개념을 확장하여, Git 저장소를 인프라와 애플리케이션의 **단일 진실 공급원(Single Source of Truth)**으로 사용하는 운영 모델이다.

*   **관계:** IaC가 "인프라를 코드로 정의하는 기술"이라는 수단이라면, GitOps는 "그 코드를 Git을 통해 어떻게 운영하고 동기화할 것인가"에 대한 방법론이다. 즉, GitOps는 IaC를 기반으로 한 현대적인 CD(지속적 배포) 방식이다.
*   **차이점:**
    *   **IaC (주로 Push 기반):** 사용자가 로컬이나 CI 서버에서 명령어를 실행하여 인프라에 변경 사항을 밀어 넣는다.
    *   **GitOps (주로 Pull 기반):** 클러스터 내의 에이전트(예: ArgoCD, Flux)가 Git 저장소의 상태를 지속적으로 감시하다가, 실제 상태와 다를 경우 자동으로 동기화(Reconciliation)하여 일치시킨다.