블로그
devops
3遺??뚯슂

클릭 대신 코드로 고정하라: IaC로 인프라를 반복 가능하게 만드는 법

IaC는 인프라를 수동 설정이 아니라 코드로 고정해 변경 추적과 재현성을 만든다. 선언적/명령형 접근을 구분하고, 리뷰·상태 관리·드리프트 통제를 함께 설계하면 운영이 단단해진다.

클릭 대신 코드로 고정하라: IaC로 인프라를 반복 가능하게 만드는 법
🧱
한 문장 결론

인프라는 “한 번 잘 세팅”하는 대상이 아니라, 코드로 고정해 반복 가능한 변경으로 다루는 편이 운영에 강합니다.

이 글이 다루는 문제

수동 프로비저닝은 빠르게 시작하기 좋지만, 시간이 지나면 같은 문제로 되돌아옵니다.

  • 반복 작업이 늘어나고, 담당자가 바뀌면 작업 방식도 달라집니다.
  • 설정이 조금씩 어긋나 “같은 환경”이 깨집니다.
  • 변경 이력이 흩어져, 무엇이 언제 바뀌었는지 추적이 어렵습니다.

여기서 중요한 건 “지금 되느냐”가 아니라, 다음 변경도 안전하게 할 수 있느냐입니다.


핵심 개념: IaC는 변경을 “기록 가능한 흐름”으로 만든다

Infrastructure as Code(IaC)는 인프라를 코드로 정의하고 실행해 프로비저닝과 변경을 관리하는 방식입니다.

다이어그램 불러오는 중...

기대 결과

  • 변경이 “누군가의 손”이 아니라 리포지토리 기록으로 남습니다.
  • 리뷰와 검증 단계를 통과한 변경만 반영돼 휴먼 에러가 줄어듭니다.
  • 수동 변경(드리프트)은 감지와 수정 대상으로 분리돼 일관성이 유지됩니다.

해결 접근

1) 선언적(Declarative) 방식

  • 왜 하는지: 최종 상태만 정의하고, 적용 과정은 도구에 맡겨 변경 폭을 관리하기 위해서입니다.
  • 어떻게
    • 사용자는 “원하는 상태”를 기술합니다.
    • 도구가 현재 상태와 비교해 필요한 변경을 수행합니다.
  • 대표 도구: Terraform, AWS CloudFormation
  • 기대 결과: “어떻게 만들지”보다 “무엇이 되어야 하는지”에 집중해, 인프라 변경을 표준화할 수 있습니다.

2) 명령형(Imperative) 방식

  • 왜 하는지: 구성 단계를 코드로 명시해 실행 흐름을 더 직접적으로 통제하기 위해서입니다.
  • 어떻게
    • 사용자가 설정 단계를 코드로 정의합니다.
    • 명령어 기반으로 실행됩니다.
  • 대표 도구: Ansible, AWS CDK
  • 기대 결과: 단계가 분명해져, 복잡한 구성이나 순서 제어가 필요한 작업에서 예측 가능성이 올라갑니다.

구현(코드): 운영 흐름으로 고정하기

IaC를 “운영 흐름”에 붙이려면, 최소한 아래 3가지를 분리해두는 편이 안전합니다.

  1. 변경 전 검증 (Plan / Validate)
  2. 실제 적용 (Apply)
  3. 적용 결과 확인 (Verify)
bash
# (일반적인 흐름 예시)
# 1) 변경 계획 확인
terraform plan

# 2) 변경 적용
terraform apply

기대 결과

  • 적용 전에 변경 범위를 확인해, 의도치 않은 교체나 삭제를 줄일 수 있습니다.
  • 실행 절차가 표준으로 고정돼, 개인별 운영 편차가 줄어듭니다.
도구나 정책에 따라 명령과 흐름은 달라질 수 있습니다. 핵심은 “검증 → 적용 → 확인”을 분리해 반복 가능하게 만드는 것입니다.

검증 방법(체크리스트)

인프라 변경이 Git 이력으로 추적된다.
적용 전에 변경 범위를 확인하는 단계가 있다.
리뷰와 승인 후에만 적용되도록 흐름이 고정돼 있다.
수동 변경이 발생해도 감지와 복구 흐름이 있다.
동일한 코드로 환경을 다시 만들 수 있다.

흔한 실수 / FAQ

Q1. 수동으로 한 번 고치고 끝내면 안 되나?

수동 변경은 즉시 해결처럼 보이지만, 다음 변경 시점에 “어디가 다른지”가 문제를 만듭니다. IaC의 목적은 변경을 코드로 고정해 재현성을 유지하는 데 있습니다.

Q2. 선언적/명령형 중 무엇을 선택해야 하나?

필요한 통제 수준과 팀의 운영 방식에 따라 달라집니다.

  • 최종 상태 중심으로 표준화하고 싶으면 선언적 접근이
  • 단계와 순서 통제가 중요하면 명령형 접근이 유리합니다.

Q3. 상태(State) 관리가 왜 어렵다고 하나?

IaC는 “코드”와 “실제 리소스” 사이의 일관성이 핵심입니다. 상태를 어디에 저장하고, 어떻게 공유하고, 어떻게 잠글지가 팀 운영 정책을 크게 좌우합니다.


요약(3~5줄)

IaC는 인프라를 수동 설정이 아니라 코드로 관리해 변경 이력과 재현성을 만듭니다.

선언적/명령형 접근은 “원하는 상태 vs 실행 단계”라는 관점 차이입니다.

운영에서는 검증 → 적용 → 확인 흐름을 고정하고, 수동 변경(드리프트)을 분리해 다루는 편이 안정적입니다.


결론

IaC의 핵심은 도구 선택보다 변경을 코드로 고정해 운영 가능한 흐름을 만드는 데 있습니다.

리뷰와 검증, 그리고 재현 가능한 실행 절차를 함께 묶으면 인프라는 더 예측 가능해집니다.


참고 링크

관련 게시물