171. 멱등성 (Idempotency in IaC)

핵심 인사이트 (3줄 요약)

본질: 멱등성 (Idempotency)은 Infrastructure as Code (IaC)를 몇 번 실행했는지가 아니라, 원하는 인프라 상태가 항상 같은 모습으로 수렴하는 성질이다.

가치: 이 성질이 있어야 재시도, 부분 실패 복구, GitOps 동기화가 "중복 생성"이 아니라 "안전한 수렴"으로 동작한다.

판단 포인트: Terraform이 기본적으로 멱등 지향적이어도 State 잠금, 외부 변경, 비결정적 값, 부작용 스크립트를 통제하지 않으면 실제 운영 멱등성은 쉽게 무너진다.

Ⅰ. 개요 및 필요성

멱등성은 같은 요청을 여러 번 보내도 최종 결과가 달라지지 않는 성질이다. 클라우드 인프라에서는 서버, 네트워크, 권한 정책을 사람이 손으로 맞추지 않고 반복 배포해야 하므로, "한 번만 성공하면 된다"보다 "몇 번 다시 실행해도 같은 상태가 나온다"가 훨씬 중요하다. 이 기준이 없으면 파이프라인 재실행 자체가 공포가 되고, 장애 복구 때마다 중복 리소스나 충돌 오류가 쌓인다.

특히 Infrastructure as Code 환경은 실패를 전제로 설계해야 한다. 네트워크 타임아웃, Provider API (Application Programming Interface) 지연, 중간 단계 실패는 현실적으로 자주 발생한다. 멱등성이 보장되면 운영자는 "실패한 지점부터 수동 보수"가 아니라 "같은 선언을 다시 적용해 원하는 상태로 수렴"하는 방식을 택할 수 있다.

아래 그림은 같은 요구사항이라도 명령 중심 스크립트와 상태 중심 IaC가 어떻게 다르게 행동하는지 보여준다.

┌──────────────────────────────────────────────────────────────┐
│       같은 "web-sg가 있어야 함" 요청도 방식에 따라 결과가 다르다 │
├───────────────────────────┬──────────────────────────────────┤
│ 비멱등 명령               │ 멱등 선언                         │
├───────────────────────────┼──────────────────────────────────┤
│ create-security-group     │ resource "web-sg" must exist     │
│ 1회 실행: 생성            │ 1회 실행: 생성                    │
│ 2회 실행: AlreadyExists   │ 2회 실행: 변화 없음               │
│ 3회 실행: 예외 처리 필요  │ 3회 실행: 변화 없음               │
└───────────────────────────┴──────────────────────────────────┘

핵심은 "명령을 반복한다"가 아니라 "상태를 보장한다"는 발상 전환이다. 운영자가 원하는 것은 create 명령의 성공 횟수가 아니라, 최종적으로 보안 그룹이 정확한 규칙으로 존재하는 사실이기 때문이다.

📢 섹션 요약 비유: 멱등성은 방에 의자를 "한 개 놓아라"라고 지시하는 것과 같다. 같은 말을 다섯 번 들어도 의자가 다섯 개 늘어나면 안 되고, 항상 한 개만 정확히 놓여 있어야 한다.

Ⅱ. 아키텍처 및 핵심 원리

Terraform의 멱등성은 선언형 구성, 상태 추적, 실제 인프라 조회, 차이 계산, 직렬화된 적용이라는 다섯 축으로 만들어진다. 여기서 중요한 점은 terraform.tfstate만 보고 판단하는 것이 아니라, 계획 수립 시점에 Provider가 실제 클라우드 상태를 다시 읽어 와서 구성과 비교한다는 점이다. 즉 멱등성은 "코드 vs 상태 파일"의 단순 비교가 아니라, 원하는 상태와 실제 상태 사이의 차이를 지속적으로 줄이는 수렴 루프다.

┌────────────────────────────────────────────────────────────────────┐
│        Terraform Convergence Loop: 선언 → 조회 → 차이만 적용       │
├────────────────────────────────────────────────────────────────────┤
│ .tf Desired State                                                 │
│      │                                                            │
│      ▼                                                            │
│ State Backend (resource address, dependency, lock)                │
│      │                                                            │
│      ▼                                                            │
│ Provider Read / Refresh (actual cloud state)                      │
│      │                                                            │
│      ▼                                                            │
│ Plan Engine                                                       │
│  ├─ No-op    : 이미 일치                                          │
│  ├─ Create   : 없는 리소스 생성                                   │
│  ├─ Update   : 속성 차이 수정                                     │
│  └─ Replace  : 인플레이스 불가 시 교체                            │
│      │                                                            │
│      ▼                                                            │
│ Apply → 새 상태 기록 → 다음 실행에서는 같은 상태면 다시 No-op    │
└────────────────────────────────────────────────────────────────────┘

구성 요소	역할	멱등성과의 관계
Desired State	`.tf` 코드에 적힌 목표 구조	"무엇이 되어야 하는가"를 고정한다
State Backend	리소스 주소, ID, 의존성 추적	이미 관리 중인 대상을 식별해 중복 생성을 막는다
Refresh	실제 클라우드 자원 재조회	수동 변경이나 Drift를 감지한다
Plan Engine	차이를 계산해 액션 결정	변경이 필요한 대상만 선택한다
State Lock	동시 적용 차단	두 파이프라인이 같은 자원을 동시에 바꾸는 사고를 막는다

다만 멱등성은 "무조건 아무 일도 없다"는 뜻이 아니다. Desired State가 바뀌면 재실행 시 Update나 Replace가 정상적으로 일어나야 한다. 멱등성의 본질은 같은 선언에는 같은 결과, 다른 선언에는 예측 가능한 변경이 나온다는 점이다. 그래서 Terraform 설계에서는 timestamp()처럼 매번 값이 달라지는 표현이나, null_resource + local-exec처럼 외부 부작용을 일으키는 구문이 멱등성을 약하게 만드는 대표 사례다.

📢 섹션 요약 비유: Terraform은 내비게이션과 같다. 목적지가 이미 같으면 더 움직이지 않고, 길을 벗어났을 때만 다시 경로를 잡아 준다. 중요한 것은 버튼을 몇 번 눌렀는지가 아니라 목적지에 도달했는지다.

Ⅲ. 비교 및 연결

멱등성은 도구마다 구현 방식이 다르다. Terraform은 상태 기반 수렴 엔진이고, Ansible은 모듈 단위 조건 검사에 가깝고, Shell Script는 기본적으로 비멱등이다. Kubernetes도 컨트롤러가 선언된 Desired State를 지속적으로 맞추는 점에서 Terraform과 같은 철학을 공유하지만, 적용 범위는 클러스터 내부 오브젝트에 더 가깝다.

구분	Terraform	Ansible	Shell Script	Kubernetes Controller
기본 모델	선언형 리소스	태스크 실행형	명령 순차 실행	선언형 오브젝트
멱등성 방식	State + Diff + Apply	모듈이 현재 상태 확인	직접 조건문 작성 필요	Reconciliation Loop
강점	인프라 전체 수렴에 강함	서버 설정에 유연함	빠른 임시 작업	지속적 자동 복구
약점	외부 부작용 리소스에 약함	`shell` 태스크는 비멱등 가능	재실행 안전성 낮음	클러스터 밖 자원은 범위 제한

중요한 경계도 있다. Terraform 리소스 블록은 멱등적으로 설계되지만, 그 안에서 외부 스크립트를 호출하면 멱등 책임이 다시 사용자에게 돌아온다. 예를 들어 데이터베이스 계정 생성, 스키마 마이그레이션, 원타임 토큰 발급 같은 작업은 "이미 수행되었는가"를 직접 확인하지 않으면 재실행 시 중복 반영될 수 있다. 즉 도구가 선언형이어도 작업 내용이 부작용 중심이면 멱등성은 자동으로 생기지 않는다.

이 개념은 다음 문서인 선언형 (Declarative) vs 명령형 (Imperative)과도 자연스럽게 연결된다. 선언형은 상태 목표를 적고, 멱등성은 그 목표를 반복 적용해도 안전하게 수렴하게 만든다. 다시 말해 선언형이 "어디로 갈지"를 정한다면, 멱등성은 "몇 번 다시 시도해도 같은 곳에 도착하는가"를 보장한다.

📢 섹션 요약 비유: Terraform은 "집을 이 설계도로 맞춰라"라고 말하는 감독이고, Shell Script는 "망치질 세 번, 못 박기 두 번"을 일일이 시키는 작업 지시서와 같다. 감독형은 결과를 맞추고, 지시서형은 중간에 꼬이면 사람이 다시 수습해야 한다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서 멱등성은 이론보다 운영 습관에서 깨지는 경우가 많다. 가장 대표적인 원인은 병렬 apply, 수동 콘솔 변경, 브라운필드 자원을 import 없이 다시 생성하려는 시도, 그리고 랜덤 값이나 시간 값을 steady-state 경로에 넣는 설계다. 따라서 "Terraform을 쓴다"보다 "멱등성을 유지하는 운영 규칙을 지킨다"가 더 중요하다.

상황	권장 판단	이유
팀 단위 협업	원격 Backend + Lock 필수	동시 적용 충돌을 막아야 한다
기존 자원 편입	먼저 `terraform import` 또는 선언 정합화	동일 자원을 새로 만들려는 사고를 방지한다
원타임 작업 필요	IaC 본 경로와 분리해 별도 단계로 설계	멱등 수렴 루프에 부작용을 섞지 않는다
Drift 잦은 환경	`plan`을 정기 실행해 수동 변경 탐지	"코드와 실제가 다름"을 조기에 발견한다
랜덤 이름 필요	최초 생성용 랜덤은 고정 저장, 매 실행 재생성 금지	매번 교체가 발생하면 No-op이 불가능해진다

실무 체크리스트

State 파일은 로컬 개인 PC보다 원격 저장소에 두고 잠금 기능을 활성화한다.
apply 전에 plan을 자동화해 예상 변경이 의도한 것인지 검토한다.
null_resource, local-exec, 시간 함수, 외부 스크립트는 "정말 필요한 예외"로만 사용한다.
수동 콘솔 수정이 발생했다면 원인을 분석하고, 다시 코드에 환원해 다음 실행에서 표준 상태로 복구되게 한다.
"멱등적"이라는 이유로 파괴적 변경까지 안전하다고 오해하지 않는다. 같은 Replace라도 다운타임과 데이터 손실 위험은 별도 검토해야 한다.

안티패턴

같은 Workspace에 여러 파이프라인이 동시에 apply
매 실행마다 바뀌는 태그, 이름, 트리거 값 사용
이미 존재하는 자원을 import하지 않고 신규 생성 선언
수동 핫픽스를 해 놓고 코드에는 반영하지 않는 운영

기술사 답안에서는 State 관리, Drift 감지, 동시성 통제, 외부 부작용 분리를 함께 언급해야 실무성이 살아난다. 멱등성은 단순한 정의 문제가 아니라, 반복 배포와 재시도 전략을 가능하게 만드는 신뢰성 설계 요소다.

📢 섹션 요약 비유: 멱등성을 지키는 운영은 출석부를 한 사람이 들고 질서 있게 체크하는 것과 같다. 여러 사람이 동시에 같은 줄에 표시하거나, 몰래 이름을 지웠다 다시 쓰면 금세 엉망이 된다.

Ⅴ. 기대효과 및 결론

멱등성이 잘 설계된 IaC는 재시도를 두려워하지 않게 만든다. 같은 선언을 다시 적용해도 인프라가 중복 생성되지 않으므로, 운영자는 장애 복구와 배포 자동화에서 훨씬 높은 자신감을 가질 수 있다. 그 결과 CI/CD (Continuous Integration / Continuous Delivery) 파이프라인 안정성, 감사 가능성, Drift 복구 속도가 함께 좋아진다.

한계도 분명하다. 클라우드 Provider의 eventual consistency, 외부 시스템의 부작용, 데이터 마이그레이션 같은 작업은 순수한 리소스 선언보다 훨씬 어렵다. 또한 멱등성은 "재실행 안전"을 뜻할 뿐 "항상 무해함"을 뜻하지는 않는다. 예를 들어 인스턴스 교체가 필요한 변경은 멱등적이어도 서비스 영향이 있을 수 있다.

결국 멱등성은 IaC의 편의 기능이 아니라 자동화가 인간보다 더 믿을 만하게 반복되도록 만드는 안전장치로 기억해야 한다. 좋은 IaC는 한 번 멋지게 성공하는 코드가 아니라, 실패 후에도 같은 선언으로 다시 일어설 수 있는 코드다.

📢 섹션 요약 비유: 멱등성은 엘리베이터 호출 버튼과 같다. 한 번 누르든 세 번 누르든 엘리베이터는 한 번만 와야 하고, 버튼을 더 누른다고 층이 중복 생성되면 안 된다.

📌 관련 개념 맵

개념	연결 포인트
Desired State	IaC가 보장하려는 목표 인프라 상태
State Backend	관리 대상과 이전 적용 결과를 추적하는 기준점
Drift	코드와 실제 인프라가 어긋난 상태, 멱등 재적용의 직접 대상
State Lock	병렬 적용으로 멱등성이 깨지는 것을 막는 동시성 제어
Declarative Model	"무엇을 원하나"를 적는 방식, 멱등성과 궁합이 좋다
Reconciliation	차이를 계산해 목표 상태로 수렴시키는 핵심 루프

📈 관련 키워드 및 발전 흐름도

수동 클릭 · 명령형 스크립트
    │
    ├─ 문제: 재실행 충돌 · 중복 생성 · 수동 복구
    ▼
선언형 IaC (Desired State)
    │
    ├─ State Backend
    ├─ Refresh / Diff
    └─ Locking
    ▼
멱등적 Apply
    │
    ▼
Drift Detection · Safe Retry · GitOps Reconciliation

이 흐름은 인프라 운영이 "한 번 실행되는 작업"에서 "반복 적용해도 같은 상태로 수렴하는 관리 체계"로 발전하는 과정을 보여준다.

👶 어린이를 위한 3줄 비유 설명

멱등성은 장난감 상자에 "자동차 한 대만 넣어"라고 여러 번 말해도 자동차가 딱 한 대만 있게 하는 규칙이에요.
이미 자동차가 있으면 더 넣지 않고, 없을 때만 한 대를 넣어요.
그래서 컴퓨터가 같은 명령을 다시 해도 방이 엉망이 되지 않아요.