Foundations - 06. IaC 철학

서버 한 대를 설정하는 데 1시간이면, 100대에는 며칠이 걸린다 — IaC 철학

2012년 8월 1일, Knight Capital의 주문 거래 시스템이 뉴욕 증권시장에서 폭주하기 시작했다. 45분 만에 회사가 4억 4천만 달러를 잃었고, 그해 말 파산했다. 나중에 밝혀진 원인은 단순했다 — 8개 서버 중 1대에만 이전 배포의 죽은 코드(DEAD code)가 남아 있었다. 7대에는 새 코드가 정상적으로 배포됐지만, 8번째 서버(RSM-4)는 수동 배포 과정에서 누락됐다. 그 서버가 살아 있던 구 코드가 새로운 거래 플래그를 해석하지 못하고, 시장에 무한히 주문을 쏟아낸 것이다. 이 사건은 자동화된 배포가 없는 인프라가 얼마나 위험한지를 보여주는 잔혹한 사례다. 한 대의 서버 설정이 어긋난 게 전 회사를 무너뜨렸다.

이 사건이 보여주는 것은 "수동으로는 몇 대까지 가능하다"는 통념의 붕괴다. 서버 한 대를 설정하는 데 1시간이 걸린다면, 100대에는 며칠이 걸린다. 그 며칠 동안 누군가는 지치고, 어딘가에 오타가 들어가고, 어느 순간부터 서버마다 미세하게 다른 상태가 된다 — "눈송이 서버(snowflake server)"라 부르는 상태. 눈송이 서버가 생기면 장애가 났을 때 원인을 찾기 어렵고, 새 서버를 똑같이 만들 방법이 없다. 이 문제를 푸는 패러다임이 Infrastructure as Code(IaC)다. 인프라를 손으로 만지는 대신 코드로 정의하고, 코드를 실행해 인프라를 만드는 방식. foundations의 마지막 주제로 다루는 이유는 — 앞의 모든 글(품질 속성·fault domain·redundancy·build-vs-buy)에서 내린 결정을 재현 가능하게 만드는 게 IaC이기 때문이다.

IaC의 본질 — "인프라를 코드처럼"

IaC(Infrastructure as Code)의 정의는 단순하다. 인프라의 설정·배치·구성을 코드로 정의하고, 그 코드를 실행해 인프라를 프로비저닝(provisioning)하고 관리하는 방식. 코드는 버전 관리(Git)되고, 코드 리뷰를 거치고, CI/CD 파이프라인으로 배포된다. 인프라가 "코드처럼" 취급된다는 건 — 애플리케이션 코드가 누리는 혜택(버전 관리·변경 이력 추적·자동화·재현 가능성)을 인프라도 누린다는 뜻이다.

IaC 이전의 인프라는 명령적·수동이었다. 관리자가 서버에 SSH로 접속해 패키지를 설치하고, 설정 파일을 편집하고, 서비스를 재시작했다. 한 번에 한 서버씩. 이 방식의 문제는 세 가지다. 첫째, 재현 불가 — 똑같은 설정을 한 서버에서 다른 서버로 옮기는 게 거의 불가능하다. 사람마다 다르게 하고, 시점마다 다르게 한다. 둘째, 추적 불가 — "이 서버가 왜 이렇게 설정됐는지"를 아무도 모른다. 퇴사한 관리자의 머릿속에만 있다. 셋째, 확장 불가 — 서버 10대까지는 버틴다. 100대부터는 한계, 1,000대부터는 불가능. Knight Capital의 사건은 이 한계가 단순한 비효율이 아니라 치명적 장애로 이어지는 걸 보여준다.

IaC는 이 세 가지를 동시에 해결한다. 코드를 실행하면 항상 같은 결과가 나온다(재현 가능). 코드의 Git 히스토리가 변경 이력이다(추적 가능). 코드 한 번 실행으로 서버 1대든 1만 대든 같은 방식으로 설정된다(확장 가능).

flowchart LR
    CODE["IaC 코드<br/>(Terraform/Pulumi)"] --> GIT[Git 저장소]
    GIT --> CI[CI/CD 파이프라인]
    CI --> APPLY[코드 실행]
    APPLY --> INFRA["프로덕션 인프라<br/>(재현 가능)"]
    APPLY --> DR["DR 환경<br/>(동일 코드로 복제)"]

이 다이어그램의 핵심은 코드가 단일 진실의 원천(single source of truth)이라는 점이다. 프로덕션과 DR 환경이 같은 코드로 만들어지면, 둘은 정확히 같다. 프로덕션에 장애가 나도 DR이 같은 코드로 만들어졌으니 같은 동작을 보장한다. 04에서 본 "Pilot Light"나 "Warm Standby" DR 패턴이 IaC 없이는 비현실적인 이유가 여기에 있다.

선언적(declarative) vs 명령적(imperative) — 두 패러다임

IaC의 핵심 설계 선택은 선언적이냐 명령적이냐다. 이 차이는 인프라 관리의 철학을 갈라놓는다.

명령적(imperative) 은 "어떻게 할 것인가"를 기술한다. "이 패키지를 설치하고, 이 설정 파일을 작성하고, 이 서비스를 시작하라." 명령의 순서가 중요하고, 한 번 실행하면 끝. Ansible·Chef·Puppet·Shell 스크립트가 전통적으로 이 방식이다. 장점은 직관적이고 유연하다는 것 — 시스템의 현재 상태와 무관하게 원하는 동작을 순서대로 실행할 수 있다. 단점은 멱등성(idempotency) 을 보장하기 어렵다는 것 — 같은 스크립트를 두 번 실행하면 결과가 달라질 수 있다(예: 사용자를 두 번 만들려 하거나, 패키지를 두 번 설치하려 함).

선언적(declarative) 은 "무엇이 되어야 하는가"를 기술한다. "이 서버는 3개 존재해야 하고, 이 보안 그룹은 443 포트가 열려 있어야 한다." 현재 상태와 목표 상태를 비교해 차이를 맞춘다. Terraform·CloudFormation·Pulumi·Kubernetes manifest가 이 방식이다. 장점은 멱등성이 자동 보장된다는 것 — 같은 코드를 열 번 실행해도 결과는 같다. 시스템이 이미 목표 상태면 아무것도 안 하고, 차이가 있으면 그 차이만 맞춘다. 단점은 복잡한 조건 로직을 표현하기 어렵다는 것 — "만약 월요일이면 이 설정, 아니면 저 설정" 같은 분기를 선언적 코드로 표현하려면 도구 자체의 한계에 부딪힌다.

특성	선언적 (Terraform, CloudFormation, K8s)	명령적 (Ansible, Chef, Shell)
기술 단위	목표 상태 (what)	절차 (how)
멱등성	자동 보장	직접 구현해야
상태 추적	state 파일로 추적	실행 로그로 추적
리소스 삭제	코드에서 지우면 실제로 지움	명시적 삭제 명령 필요
복잡한 로직	어려움	자유로움
학습 곡선	가파름	완만함
현재 상태 파악	코드를 보면 됨	서버에 접속해 봐야

현대 IaC의 주류(majorstream)는 선언적이다. 이유는 — 인프라 규모가 커지고 클라우드 API가 표준화되면서 "목표 상태를 선언하면 도구가 차이를 맞추는" 모델이 훨씬 잘 맞기 때문이다. 다만 Ansible 같은 명령적 도구는 여전히 설정 관리(config management) 영역에서 강력하다 — 03-compute-platforms에서 다룰 systemd 설정·패키지 설치 같은 영역이다. 두 패러다임은 경쟁보다 보완 관계로 쓰인다 — 인프라 프로비저닝은 Terraform(선언적), 세부 설정은 Ansible(명령적).

mutable vs immutable — 눈송이를 어떻게 없앨 것인가

IaC의 또 다른 축이 mutable(가변) vs immutable(불변) 인프라다. 서버를 설정 변경할 때, 기존 서버를 고치느냐(mutable), 새 서버를 만들어 교체하느냐(imutable)의 차이다.

Mutable infrastructure — 서버를 만든 뒤에도 계속 고친다. SSH로 접속해 패키지를 업데이트하고, 설정을 바꾸고, 서비스를 재시작한다. 시간이 지나면 서버마다 미세하게 다른 상태가 된다 — 눈송이 서버(snowflake server). 장점은 변경이 빠르다는 것 — 서버를 새로 만들 필요 없이 그 자리에서 고친다. 단점은 — 눈송이가 생기면 재현이 불가능하고, 설정 변경이 누적되면 어느 순간 "이 서버가 왜 이렇게 됐는지"를 아무도 모르는 상태가 된다.

Immutable infrastructure — 서버를 한 번 만들면 고치지 않는다. 변경이 필요하면 새 이미지(golden image·AMI)를 만들고, 새 서버를 띄운 뒤, 기존 서버를 버린다. 서버는 눈송이가 아니라 소모품(disposable)이다. 장점은 재현 가능성 — 같은 이미지로 만든 서버는 항상 같다. 장애가 나도 새 서버로 교체하면 된다. 단점은 — 이미지 빌드·서버 교체에 시간이 걸린다는 것. 또한 인프라 전체가 immutable하려면 상태(데이터)를 서버 밖으로 빼야 한다 — 서버가 소모품이려면 서버가 데이터를 들고 있으면 안 된다.

flowchart TD
    CHANGE["변경 필요"] --> Q{"인프라 스타일?"}
    Q -->|Mutable| SSH["기존 서버에 SSH<br/>패키지 업데이트, 설정 변경"]
    SSH --> SNOW["눈송이 서버 발생<br/>(재현 불가)"]
    Q -->|Immutable| BUILD["새 이미지 빌드"]
    BUILD --> REPLACE["새 서버 배포, 기존 서버 폐기"]
    REPLACE --> CLEAN["모든 서버 동일<br/>(재현 가능)"]

immutable의 핵심 도구가 이미지 빌드(image building) 다. Packer(HashiCorp)가 대표적 — 코드로 서버 이미지를 빌드한다. 이미지 안에 OS·패키지·설정·애플리케이션 코드를 다 넣고, 그 이미지를 클라우드(AMI·GCE image)에 올린다. 배포는 새 이미지로 인스턴스를 띄우고 로드 밸런서가 트래픽을 옮기는 것. Kubernetes의 컨테이너 이미지(Docker·OCI)가 같은 철학의 최신 형태다.

immutable은 foundations 04의 DR 전략과도 직결된다. "새 서버를 만들어 교체한다"는 건 — DR 환경에서도 같은 이미지로 서버를 띄우면 된다는 뜻이다. Pilot Light나 Warm Standby DR이 IaC와 immutable 없이 비현실적인 이유가 여기에 있다.

멱등성과 상태 관리 — 선언적 IaC의 기둥

선언적 IaC가 작동하려면 두 개념이 필수다.

멱등성(idempotency) — 같은 코드를 여러 번 실행해도 결과가 같은 성질. Terraform 코드에 "nginx 서버 3개"라고 쓰면, 한 번 실행해도 3개, 열 번 실행해도 3개. 이미 3개가 있으면 아무것도 안 하고, 2개만 있으면 1개를 추가하고, 5개가 있으면 2개를 지운다. 멱등성이 없으면 — "nginx 3개" 코드를 두 번 실행하면 6개가 되고, 세 번이면 9개가 되는 혼란이 생긴다.

상태 관리(state management) — Terraform은 "현재 인프라가 어떤 상태인지"를 state 파일(terraform.tfstate)에 기록한다. 이 state 파일이 실제 인프라와 코드 사이의 다리다. 코드를 실행하면 — state를 읽어 현재 상태를 파악하고, 코드(목표 상태)와 비교해 차이를 계산하고, 그 차이를 클라우드 API에 반영한다.

state 파일이 왜 중요한가. state를 잃어버리면 Terraform은 "현재 인프라가 어떤 상태인지"를 모른다. 코드에 "nginx 3개"라고 돼 있어도, 실제로 5개가 떠 있는지 3개가 떠 있는지 알 수 없다. state 없이 코드를 실행하면 — Terraform이 "3개를 새로 만들어야겠다"고 판단해, 이미 있는 5개와 별개로 3개를 더 만드는 참사가 일어난다. 그래서 state 파일은 가장 중요한 백업 대상이다. 보통 원격 백엔드(S3 + DynamoDB locking, Terraform Cloud, GitLab managed Terraform state)에 두고, 팀이 공유한다.

state의 또 다른 문제가 drift(상태 드리프트) 다. 누군가가 콘솔에서 직접 인스턴스를 지우거나, 설정을 바꾸면, 실제 인프라와 state 파일이 어긋난다. 이걸 drift라 부른다. drift는 — "코드가 단일 진실의 원천이어야 한다"는 IaC의 철학을 깬다. 그래서 정기적으로 terraform plan -refresh-only로 drift를 감지하고, 코드 또는 인프라 둘 중 하나로 맞추는 작업이 필요하다.

GitOps — 단일 진실의 원천을 Git으로

IaC의 최신 발전 형태가 GitOps다. 2017년 Weaveworks의 Alexis Richardson이 만든 용어로, 정의는 — Git 저장소가 인프라 상태의 단일 진실의 원천(single source of truth)이고, 자동화된 프로세스가 Git의 상태를 프로덕션에 동기화하는 운영 모델.

전통적 IaC(Terraform CLI)는 — 개발자가 로컬에서 terraform apply를 실행해 인프라를 변경한다. 이 모델의 문제는 — 누가 언제 무엇을 적용했는지 추적이 어렵고, 권한 관리가 느슨하다. GitOps는 — 변경을 Git에 커밋(PR)으로 제안하고, 리뷰를 거쳐 머지되면 자동으로 프로덕션에 적용된다. 모든 변경이 Git 히스토리에 남고, 권한은 Git의 PR 리뷰로 통제된다.

flowchart LR
    DEV[개발자] -->|코드 수정| PR[Pull Request]
    PR --> REV[코드 리뷰]
    REV -->|머지| MAIN[main 브랜치]
    MAIN --> OP[Operator/Controller]
    OP -->|자동 동기화| PROD[프로덕션 인프라]
    PROD -. 드리프트 감지 .-> OP

GitOps를 실천하는 도구가 Flux·ArgoCD(Kubernetes용), Terraform Enterprise·Atlantis(Terraform용)다. 이들은 Git 저장소를 주시하다가, 변경이 머지되면 자동으로 클러스터/인프라에 적용한다. 또한 실제 인프라가 Git과 어긋나면(drift) 다시 Git 상태로 되돌린다 — 단일 진실의 원천을 강제하는 메커니즘.

GitOps가 중요한 이유는 — 인프라 변경이 애플리케이션 배포와 같은 수준의 통제·감사 가능성을 갖게 한다는 것. 코드 리뷰, CI 테스트, 변경 승인, 감사 추적을 인프라에도 적용한다. Knight Capital 사건이 안 일어나게 하는 제도적 장치다. 누군가가 서버 한 대를 잘못 설정하려 해도 — 그 변경이 PR로 들어가고, CI가 검증하고, 리뷰어가 확인하기 전에는 머지되지 않는다.

Conway's Law — 인프라 버전

Conway's Law는 1968년 Melvin Conway가 제안한 법칙이다 — "시스템을 설계하는 조직은 그 조직의 의사소통 구조를 복사한 시스템을 만든다." 소프트웨어 아키텍처에서 자주 인용되지만, 인프라에도 그대로 적용된다.

IaC의 구조는 조직 구조를 반영한다. 한 팀이 전 인프라를 관리하면 — 하나의 거대한 Terraform 저장소가 된다. 각 서비스 팀이 자기 인프라를 관리하면 — 서비스마다 별도의 Terraform 모듈·저장소가 생긴다. DevOps 팀과 SRE 팀이 분리돼 있으면 — IaC 코드도 두 레이어(인프라 프로비저닝 + 서비스 배포)로 나뉜다. "인프라 구조가 조직 구조를 따른다"는 건 피할 수 없는 현상이고, 오히려 의식적으로 활용해야 한다 — 조직이 협력하길 원하는 방식으로 IaC를 나누면, 그 구조가 조직의 협업을 유도한다(inverse Conway maneuver).

이건 단순한 이론이 아니다. 모노리틱 Terraform 저장소를 서비스별로 쪼개는 건 — 동시에 조직을 서비스 팀 중심으로 재편하는 작업이다. 둘은 같이 일어나야 성공하고, 하나만 하면 실패한다. 03에서 본 "장애 도메인을 쪼갠다"는 것도 결국 조직이 분산돼 있어야 가능한 일이다. IaC는 조직 구조를 코드로 드러내는 거울이다.

IaC 도구 생태계 — 각자의 자리

주요 IaC 도구들의 자리를 정리한다.

• Terraform(HashiCorp, 2014) — 선언적, 멀티 클라우드, 현재 사실상 표준. HCL(HashiCorp Configuration Language)로 쓴다. 2023년 라이선스가 BUSL로 바뀌면서 OpenTofu 포크가 생김(리눅스 재단).
• OpenTofu(2023) — Terraform의 오픈소스 포크. 문법·기능 호환. 라이선스 우려가 있는 조직의 대안.
• AWS CloudFormation(2011) — AWS 전용, JSON/YAML. AWS 공식 도구지만 HCL보다 장황하고 멀티 클라우드 불가.
• Pulumi(2018) — 선언적이지만 프로그래밍 언어(JavaScript·Python·Go·C#)로 쓴다. HCL 대신 익숙한 언어를 쓸 수 있어 개발자 친화적.
• CDK(AWS CDK, GCP CDK) — 클라우드 벤더 공식 프로그래밍 언어 IaC. AWS CDK가 대표적. 내부적으론 CloudFormation으로 컴파일.
• Ansible(2012, Red Hat 인수) — 명령적, YAML playbook. 설정 관리(config management)의 표준. 멱등성을 직접 설계해야 하지만 잘 쓰면 강력.
• Chef(2009)·Puppet(2005) — 1세대 설정 관리 도구. Ruby DSL. 현재는 상대적으로 인기 하락.
• Packer(HashiCorp) — 이미지 빌드 도구. immutable infrastructure의 핵심.
• Kubernetes manifest(YAML) — 컨테이너 오케스트레이션의 선언적 인터페이스. Helm·Kustomize가 패키징 계층.

이 도구들은 경쟁보다 역할 분담이다. 인프라 프로비저닝(VPC·EC2·RDS)은 Terraform/Pulumi, 서버 설정(패키지·systemd)은 Ansible, 컨테이너는 K8s manifest, 이미지는 Packer. 한 조직이 전부 쓰는 게 드물지 않다.

클라우드가 IaC를 가능케 했다

IaC는 클라우드 시대와 함께 폭발적으로 성장했다. 그 이유는 — 클라우드 API 때문이다. 온프레미스는 물리적 제약이 크다. 서버를 추가하려면 누군가 랙에 꽂아야 하고, 전원·네트워크 연결이 필요하다. "코드로 서버 100대를 추가하라"는 명령이 실행되려면 — 물리적 작업이 동반돼야 한다. 온프레미스 IaC(OpenStack·Metal3·Ironic)가 있지만 여전히 물리적 한계에 부딪힌다.

클라우드는 — "인스턴스 100개 만들어라"는 API 호출이 몇 초 만에 실행된다. IaC 코드가 클라우드 API를 부르고, 클라우드가 가상 자원을 만들어 준다. 인프라가 "소프트웨어처럼" 다뤄지는 물리적 기반이 이 API 추상화다. 05에서 본 build vs buy에서 "클라우드가 인프라를 API로 노출한다"는 점이 IaC의 전제 조건이다.

이게 하이브리드 클라우드의 도전이기도 하다. 온프레미스는 IaC가 물리적 한계에 부딪히고, 클라우드는 IaC가 잘 작동한다. 두 환경을 같은 코드로 관리하려면 — 온프레미스 쪽을 클라우드 API처럼 추상화하는 레이어(OpenStack·Metal3·Anthos·Arc)가 필요하다. 그 추상화가 완벽하지 않기 때문에 하이브리드는 여전히 어렵다.

실습 — IaC 상태 직접 확인하기

1. Terraform plan 실행 (변경 시뮬레이션)

# 실제 적용 없이 무엇이 바뀔지 미리 본다. 코드와 state를 비교해 diff를 출력.
terraform plan

확인할 것: +(추가), ~(수정), -(삭제) 기호. 코드가 state와 다르면 diff가 나온다. diff가 없으면 "No changes" — 이미 목표 상태라는 뜻. 멱등성 확인의 기본.

# 예상 출력 (plan이 변경을 감지한 경우)
Terraform used the selected providers to generate the following execution plan.
Resource actions are indicated with the following symbols:
  + create
  ~ update in-place

Terraform will perform the following actions:

  # aws_instance.web will be created
  + resource "aws_instance" "web" {
      + ami           = "ami-0abcdef1234567890"
      + instance_type = "t3.micro"
      ...
    }

Plan: 1 to add, 0 to change, 0 to destroy.

2. state 파일 위치 확인

# state가 어디 저장되는지 본다. 로컬이면 위험, 원격이면 안전.
grep -A 5 'backend' *.tf 2>/dev/null
ls -la terraform.tfstate* 2>/dev/null

확인할 것: backend "s3" 같은 설정이 있으면 원격 백엔드(안전). terraform.tfstate 파일이 로컬에만 있으면 위험 — Git에 커밋하면 안 됨(비밀 포함 가능).

3. drift 감지

# state를 refresh해 실제 인프라와 비교. drift가 있는지 본다.
terraform plan -refresh-only

확인할 것: "No changes"면 drift 없음. diff가 나오면 누군가 콘솔에서 수동 변경했다는 뜻 — IaC 원칙 위반. 코드로 다시 맞추거나, 수동 변경을 코드로 반영해야.

4. Ansible playbook 멱등성 점검

# 같은 playbook을 두 번 실행. 두 번째에 changed=0이면 멱등.
ansible-playbook -i inventory site.yml
ansible-playbook -i inventory site.yml  # 두 번째 실행

확인할 것: changed=N 값. 첫 실행은 변경 사항이 있어 N>0, 두 번째 실행은 N=0이어야 멱등. N이 두 번 다 0이 아니면 playbook에 멱등성 버그.

# 예상 출력 (멱등 playbook의 두 번째 실행)
PLAY RECAP *********************************************************************
server1.example.com : ok=5  changed=0  unreachable=0  failed=0

미검증: 위 명령은 Terraform·Ansible이 설치된 환경에서 동작. state 파일은 자격증명을 포함할 수 있어 Git에 올리면 안 됨. .gitignore에 *.tfstate 포함 필수.

IaC 도입 체크리스트

• 인프라 정의가 코드(Terraform·Pulumi·K8s manifest)로 돼 있는가, 아니면 콘솔 클릭으로 만들어졌는가?
• 코드가 Git에 버전 관리되고 있는가?
• 변경이 PR 리뷰를 거치는가(GitOps)?
• state 파일이 원격 백엔드(S3 + locking 등)에 있는가, 로컬에 방치돼 있진 않은가?
• state 파일이 Git에 커밋되진 않았는가(보안 위험)?
• 정기적으로 terraform plan -refresh-only로 drift를 감지하는가?
• 인프라 변경이 애플리케이션 배포와 같은 통제(CI/CD·리뷰·감사)를 받는가?
• 서버가 mutable(SSH로 고침)인가 immutable(이미지 교체)인가? 혼재돼 있다면 명확한 분기가 있는가?
• IaC 코드 구조가 조직 구조(서비스 팀)를 반영하는가?
• Knight Capital 사건 같은 "수동 배포 한 대 누락"이 가능한 구조가 아닌가?

foundations를 마치며 — 인프라를 "공학"으로 다룬다는 것

이 글이 foundations의 마지막이다. 여섯 편에 걸쳐 인프라를 "공학"의 대상으로 다루는 기본 어휘를 세워뒀다. 첫 글에서 "왜 인프라가 공학인가"를 물었고, 둘째에서 품질 속성을 숫자로, 셋째에서 장애 도메인과 폭발 반경을, 넷째에서 중복과 고가용성 패턴을, 다섯째에서 build vs buy의 전략적 의사결정을, 그리고 이 글에서는 그 모든 결정을 재현 가능하게 만드는 IaC를 다뤘다. 한 줄로 요약하면 — 인프라를 공학으로 다룬다는 건, 결정을 의식적으로 내리고, 그 결정을 숫자로 검증하고, 장애에 대비하고, 전략적으로 비용을 계산하고, 코드로 재현 가능하게 만드는 일이다.

이 어휘를 들고 다음 영역으로 간다. compute platforms는 베어메탈에서 컨테이너까지 "컴퓨팅 자원을 어떻게 추상화했나"를 다룬다 — 서버 하드웨어·부팅·가상화·HCI·컨테이너 런타임. network fundamentals는 "패킷이 어떻게 흐르는가"를 OSI 7계층부터 BGP·TLS까지. datacenter and cloud는 물리 시설에서 클라우드 네이티브까지. reliability sre는 신뢰성을 공학으로. infra security는 방어의 축. 각 영역은 이 foundations에서 세운 어휘(품질 속성·fault domain·redundancy·TCO·IaC)를 전제로 한다. 같은 질문이 다른 층면에서 반복될 것이다 — "이 추상화 계층에서, 이 품질 속성을 위해, 이 비용을 치를 가치가 있는가." foundations는 그 질문의 문법을 가르친 곳이고, 이제 그 문법으로 구체적인 세계를 읽어본다.

---

참고

• U.S. SEC, "In the Matter of Knight Capital Americas LLC", Release No. 70694, 2013-10-16 — Knight Capital 2012-08-01 사건 공식 보고서. 접근 2026-07-21
• HashiCorp, "Terraform: Up & Running", Yevgeniy Brikman, O'Reilly, 2nd ed 2019 — Terraform 실천과 IaC 철학. 접근 2026-07-21
• Richardson, A. "GitOps: Operation by Pull Request", Weaveworks, 2017 — GitOps 개념 원전. 접근 2026-07-21. URL: https://www.weave.works/blog/gitops-operations-by-pull-request
• GitOps Working Group, "GitOps Principles", OpenGitOps, 2022 — GitOps 공식 원칙. 접근 2026-07-21. URL: https://opengitops.dev/
• Conway, M. E. "How Do Committees Invent?", Datamation, 1968 — Conway's Law 원논문. 접근 2026-07-21
• Morris, K. , O'Reilly, 2nd ed 2020 — IaC 철학·실천 정론. 접근 2026-07-21
• Skelton, M., Pais, M. , IT Revolution, 2019 — inverse Conway maneuver, 팀 구조와 시스템 구조. 접근 2026-07-21
• Beyer, B., Jones, C., Petoff, J., Murphy, N. R. (eds.) , O'Reilly, 2016, Ch.1·Ch.8 — IaC와 SRE의 관계. 접근 2026-07-21
• OpenTofu, Linux Foundation, 2023 — Terraform BUSL 이전 후 포크. 접근 2026-07-21. URL: https://opentofu.org/