들어가며 — "프로덕션 서버를 일부러 죽인다고요?"

Chaos Engineering을 처음 듣는 사람은 보통 이렇게 반응한다.

> "장애가 나도 문제인데, 왜 일부러 만듭니까?"

답: **장애는 어차피 일어난다. 통제된 환경에서 먼저 겪는 게 덜 아프다.** 2010년 Netflix가 AWS로 이전하며 이 역설적 진리를 깨달았고, 세상에 **Chaos Monkey**를 풀어놓았다.

이 글에서는:

- **왜 Netflix가 서버를 죽이기 시작했나** — 탄생 배경

- **Chaos Engineering 4원칙** — 공식 principles

- **Simian Army** — Chaos Monkey부터 Chaos Kong까지

- **LitmusChaos / Chaos Mesh** — Kubernetes 카오스 툴링

- **AWS Fault Injection Simulator**

- **Game Day** 설계와 실행

- 관측성과 카오스의 결합

- **비난 없는 포스트모템** — 조직 문화의 기둥

- 카오스 실험 실제 레시피 10개

- 성숙도 모델 — 우리 조직은 어디에?

> 이전 글 [CDN과 엣지 컴퓨팅 완전 해부](/blog/culture/2026-04-15-cdn-edge-computing-anycast-cache-invalidation-ddos-lambda-workers-compute-deep-dive-guide-2025)에서 전 세계에 배포된 인프라를 봤다. 이렇게 복잡한 시스템이 정상 동작한다는 건 어떻게 **증명**하나? 답은 **부숴서 증명**하는 것이다.

1. 탄생 배경 — 2010년 Netflix의 선택

문제: 모놀리스에서 클라우드로

Netflix는 2008년 데이터센터 장애로 3일간 DVD 배송 시스템 다운. 결정: **"우리는 이걸 자체 DC로 해결 못 함. 클라우드로 간다."** AWS로 이전하면서 깨달음:

- 클라우드는 **개별 인스턴스 신뢰도가 낮음** (싸구려 VM)

- 네트워크는 **언제든 단절** (AZ, 리전 간)

- 의존 서비스는 **항상 실패 중**

해법 둘 중 하나:

1. 완벽한 코드를 만든다 (불가능)

2. **실패를 전제로 설계한다** (현실적)

Chaos Monkey 탄생 (2010)

Netflix 엔지니어가 만든 간단한 도구: **AWS에서 무작위로 EC2 인스턴스 종료**. 처음엔 내부 반발 심함. "미쳤다." 하지만 엔지니어들이 자신의 서비스가 **한 인스턴스 죽어도 살아남게** 설계하기 시작. 영향:

- 재시작에도 살아남는 아키텍처

- 배포 시 점진 교체 정상화

- 장애가 뉴스거리가 아닌 일상

2012년 Chaos Monkey 오픈소스화. Chaos Engineering이라는 **이름이 세상에 등장**.

2. Chaos Engineering의 4가지 원칙

Netflix, Google SRE 등이 공식화한 **principlesofchaos.org** 선언:

1. "Steady State"를 정의하라

시스템이 **정상일 때의 측정 가능한 지표**가 있어야 한다. 예:

- 초당 요청 수

- P99 지연

- 에러 비율

- 비즈니스 지표 (결제 성공률)

"정상"이 모호하면 카오스 실험이 성공인지 실패인지 모른다. **비즈니스 지표**가 특히 강력 — Netflix의 "초당 재생 시작 횟수(SPS)"가 대표적.

2. 실세계 이벤트를 다양화하라

실제로 일어날 수 있는 사건을 주입:

- 인스턴스 다운

- 네트워크 지연/단절

- DNS 실패

- 의존 서비스 timeout

- 리전 장애

- 디스크 full

- 시계 왜곡

"코드 버그"보단 **환경 이벤트**에 집중.

3. 프로덕션에서 실험하라

"스테이징에서만 하면 안 되나?" 스테이징은 프로덕션이 아니다:

- 트래픽 패턴 다름

- 데이터 크기 다름

- 서드파티 의존 다름

**점진적으로** 프로덕션에 도입. 10% 트래픽부터. 그러나 **궁극적으론 프로덕션에서**.

4. 자동화하고 지속하라

한 번 테스트하고 끝이면 의미 없다. **지속적 실험**만이 회귀를 잡는다. CI/CD처럼 **카오스도 파이프라인**.

3. Simian Army — Netflix의 전체 구성

Chaos Monkey는 시작일 뿐. Netflix는 **Simian Army**로 확장:

Chaos Monkey (2010)

- 무작위 EC2 인스턴스 종료

- 업무 시간 내만 실행 (엔지니어가 대응 가능할 때)

Latency Monkey (2012)

- 서비스 간 통신에 **지연 주입**

- 외부 API가 느릴 때의 대응 검증

Conformity Monkey

- "우리 표준"에 맞지 않는 인스턴스 찾아 종료

- 구식 AMI, 잘못된 태그 등

Doctor Monkey

- 비정상 인스턴스 (CPU 100%, 응답 없음) 발견 후 조치

Janitor Monkey

- 사용 안 되는 리소스 (orphan EBS, 미사용 IP) 정리

- 비용 관리 겸용

Security Monkey

- 잘못된 IAM/보안 그룹 설정 자동 탐지

**Chaos Gorilla** (2011)

- **AZ 하나 전체를 시뮬레이션 장애**

- 훨씬 큰 영향, 훨씬 큰 배움

**Chaos Kong** (2013)

- **AWS 리전 하나 전체를 다운**

- Netflix는 **리전 장애에도 견딜 수 있게** 설계. 2016년 실제 AWS 리전 장애 때도 서비스 유지

**FIT (Failure Injection Testing)**

- 특정 서비스, 특정 사용자, 특정 요청에만 장애 주입

- 세분화된 카오스

대부분은 오픈소스로 공개됐지만, 많은 것들이 후계 도구들로 대체됐다.

4. Kubernetes 시대의 카오스 — LitmusChaos vs Chaos Mesh

LitmusChaos (CNCF Graduated 2024)

**특징**:

- CNCF 졸업 프로젝트 (인큐베이션 → 졸업)

- Kubernetes 네이티브 (CRD 기반)

- **ChaosHub** — 수십 개의 사전 제작 실험

- GitOps 친화적

**실험 예**:

apiVersion: litmuschaos.io/v1alpha1

kind: ChaosEngine

metadata:

name: pod-delete-chaos

spec:

appinfo:

appns: default

applabel: app=nginx

experiments:

- name: pod-delete

spec:

components:

env:

- name: TOTAL_CHAOS_DURATION

value: "30"

- name: CHAOS_INTERVAL

value: "10"

**실험 유형** (ChaosHub):

- Pod delete, container kill

- Network loss/latency/corruption

- CPU/memory/IO stress

- Node drain, cordon

- AWS/Azure/GCP 리소스 조작

Chaos Mesh (CNCF Incubating)

**특징**:

- PingCAP(TiDB 회사)가 만듦

- 훌륭한 UI 대시보드

- **Scheduling** 강력 — cron 기반 반복 실험

- **워크플로우** 지원 — 여러 실험을 단계별로

**실험 YAML 예**:

apiVersion: chaos-mesh.org/v1alpha1

kind: NetworkChaos

metadata:

name: delay-example

spec:

action: delay

mode: one

selector:

namespaces:

- default

labelSelectors:

app: nginx

delay:

latency: "100ms"

correlation: "25"

jitter: "10ms"

duration: "5m"

비교

| 측면 | LitmusChaos | Chaos Mesh |

|---|---|---|

| 성숙도 | CNCF Graduated | CNCF Incubating |

| UI | 좋음 | 우수 |

| 실험 수 | ChaosHub 50+ | 내장 30+ |

| GitOps | 강함 | 중간 |

| 스케줄링 | 기본 cron | 고급 워크플로우 |

| 학습 곡선 | 중간 | 낮음 |

선택 팁:

- 온보딩 빨리 하고 싶다 → **Chaos Mesh**

- 엔터프라이즈 정책과 GitOps 통합 → **LitmusChaos**

5. AWS Fault Injection Simulator (FIS)

AWS 공식 카오스 서비스 (2021 GA).

주요 기능

- EC2 인스턴스 stop/terminate

- EBS volume detach

- 네트워크 혼란 (latency, packet loss)

- RDS 페일오버 트리거

- **사용자 정의 CloudWatch 알람**으로 자동 중지

- **IAM 기반 안전장치**

전체 리전 셧다운 실험 (조심)

FIS Template

├── Action: aws:network:disrupt-connectivity

├── Target: us-east-1의 특정 서브넷

├── Stop Condition: CloudWatch 알람 '비즈니스 지표 이하'

└── IAM Role: 제한된 권한

Netflix의 Chaos Kong을 **AWS가 공식 제공**하는 셈.

Azure Chaos Studio / GCP 실험

- Azure Chaos Studio — 2021년 출시, Kubernetes/AKS 통합

- GCP: 공식 제품 없음, Chaos Mesh 권장

6. Game Day — 조직적 재난 훈련

왜 Game Day인가

자동화된 카오스가 '기술 검증'이라면, **Game Day**는 '조직 검증'. 다음을 테스트:

- 누가 대응하나? (온콜 로테이션)

- 어떤 Runbook이 실제로 쓸만한가?

- Slack/PagerDuty 알림이 제대로 오나?

- 커뮤니케이션이 지연되는 지점은?

- 에스컬레이션 체인이 작동하나?

Game Day 설계 템플릿

**1. 목표 설정**

- 예: "us-east-1 리전 셧다운 시 15분 이내에 us-west-2로 복구"

**2. 참여자 선정**

- SRE, 백엔드, DBA, 프론트엔드, PM

- 사전 일정 공유 (재난 모의 날짜)

**3. 시나리오 작성**

- "오전 10:00에 RDS 프라이머리 페일오버"

- "오전 10:05에 쓰기 트래픽 10% 증가"

- "오전 10:10에 캐시 노드 절반 재시작"

**4. 실행**

- **관찰자**와 **실행자** 분리

- 진행 시 실시간 기록 (타임라인, Slack 스크립트)

**5. 복기 (가장 중요)**

- 무엇이 잘 됐나

- 무엇이 놀라웠나

- 어떤 Runbook을 갱신해야 하나

- 어떤 자동화가 필요한가

실전 팁

- **첫 Game Day는 고위험 피하기** — 평일 오후, 트래픽 낮은 시간

- **Chat Channel을 열어둔다** — 모든 결정이 로그에 남도록

- **Time-boxing** — "1시간 해보고 복구 안 되면 중단"

- **Blast Radius 제어** — 전체의 1~5%만 먼저

7. 관측성과 카오스의 결합

Chaos without Observability = Guessing

카오스 실험 중 **무엇을 봐야 하는가?**

- 스테디 상태 지표 (steady state)

- 의존 서비스의 에러 전파

- 캐스케이드 실패 징후

관측성 3기둥 (이전 글 [OpenTelemetry 완전 해부](/blog/culture/2026-04-15-opentelemetry-observability-traces-metrics-logs-profiles-otlp-collector-sampling-deep-dive-guide-2025) 참고):

- **메트릭** — 지속적 수치 모니터링

- **로그** — 이상 이벤트

- **Trace** — 장애가 어느 서비스로 전파됐나

"Canary + Chaos" 패턴

- 배포 후 10% 트래픽 카나리

- 동시에 **카나리 인스턴스에만** 카오스 주입

- 정상 페일 라인에 잘 대응하는지 검증

- 통과하면 전체 배포

자동 중단 (Auto-Abort)

카오스 실행 중 **비즈니스 지표 이하로 떨어지면 자동 중단**. 예:

stopConditions:

- source: cloudwatch

alarm: checkout-success-rate-below-95

실수로 큰 장애 만드는 것 방지.

8. 비난 없는 포스트모템 — 카오스 문화의 기둥

왜 "비난 없는"인가

개인을 비난하면:

- 사람들이 장애 숨김

- 학습 멈춤

- 심리적 안전 파괴

"누가 잘못했나"가 아닌 **"어떻게 시스템이 실패를 허용했나"**에 집중.

포스트모템 템플릿

1. **영향** — 몇 명에게 얼마나? 금전적 영향?

2. **타임라인** — 분 단위 사건 기록

3. **근본 원인** — "왜?"를 5번

4. **잘 된 점** — 탐지 속도, 팀워크 등

5. **안 된 점** — 알림 누락, Runbook 부족 등

6. **액션 아이템** — 담당자 + 마감일 명확히

5 Whys 예시

**문제**: 결제가 15분간 실패

1. 왜? → 결제 서비스가 응답 없음

2. 왜? → DB 커넥션 풀 고갈

3. 왜? → 쿼리 하나가 인덱스 없이 스캔 중

4. 왜? → 최근 배포에서 쿼리 추가, 인덱스 빼먹음

5. 왜? → PR 리뷰 체크리스트에 "인덱스 확인" 없음

→ 액션: PR 템플릿에 인덱스 확인 체크박스 추가.

근본 원인이 "개발자 실수"가 아닌 **"프로세스 누락"**으로 귀결.

"Just Culture"

단, 비난 없음 ≠ 책임 없음. **고의적 무시, 지속적 부주의**엔 조치. John Allspaw (Etsy)의 **"Just Culture"** 프레임워크 참조 권장.

9. 실전 카오스 레시피 10개

레시피 1: Pod 무작위 삭제

ChaosMesh

apiVersion: chaos-mesh.org/v1alpha1

kind: PodChaos

spec:

action: pod-kill

mode: random-max-percent

value: "25"

selector:

namespaces: [production]

labelSelectors: { tier: backend }

scheduler:

cron: "0 */6 * * *" # 6시간마다

**검증**: readinessProbe 설정, graceful termination, PodDisruptionBudget.

레시피 2: CPU 스트레스

**검증**: HPA가 스케일 아웃하나? Throttling 대응은?

레시피 3: 네트워크 지연

networkChaos:

action: delay

delay: { latency: "500ms" }

**검증**: 타임아웃 설정, 서킷 브레이커 작동.

레시피 4: DNS 실패

대부분 장애의 절반이 DNS ([이전 글](/blog/culture/2026-04-15-dns-internals-recursive-authoritative-edns-dnssec-doh-coredns-happy-eyeballs-deep-dive-guide-2025) 참고).

**검증**: DNS 캐시 정책, 복구 후 재연결.

레시피 5: Disk Full

dd if=/dev/zero of=/tmp/fill bs=1M count=10000

**검증**: 로그 로테이션, 디스크 알람.

레시피 6: 의존 서비스 5xx 응답

Envoy의 fault injection 필터:

fault:

abort:

percentage: 50

httpStatus: 503

**검증**: 재시도 정책, 폴백 구현.

레시피 7: DB 페일오버

**검증**: 연결 풀 재연결, 클라이언트 측 retry.

레시피 8: Region/AZ 셧다운

AWS FIS로 서브넷 네트워크 단절.

**검증**: 멀티-AZ 배포, 자동 페일오버.

레시피 9: Clock Skew

NTP 동기화 끊고 시간 조작.

**검증**: JWT 검증, 이벤트 타임스탬프, TLS 인증서.

레시피 10: Traffic Surge

부하 테스트 도구(k6, Locust)로 예상 3배 트래픽.

**검증**: Rate limiting, HPA, CDN hit ratio.

10. 카오스 성숙도 모델

Level 1 — Chaos-curious

- 관심 있지만 도구 안 씀

- 장애 대응은 사후 대응 중심

- 포스트모템은 비난 섞임

Level 2 — Staging Chaos

- 스테이징에서 가끔 실험

- Runbook 존재

- 온콜 로테이션 있음

Level 3 — Production Chaos

- 프로덕션에서 통제된 실험

- 비즈니스 지표 steady state 정의됨

- Game Day 분기별

Level 4 — Continuous Chaos

- CI/CD에 통합된 카오스 테스트

- Blast radius 자동 확장

- 자동 중단 + 관측성 결합

Level 5 — Engineering Culture

- 모든 PR이 "이 변경의 카오스 시나리오는?"을 고려

- 비난 없는 포스트모템이 자연스러움

- 조직이 "실패는 학습 기회"로 인식

Netflix, Google, Amazon이 Level 5. 대부분 회사가 Level 1~2. 목표는 차근차근 올라가기.

11. 카오스가 드러내는 아키텍처 안티패턴

안티패턴 1: Hidden Dependency

"그 서비스가 죽을 수 있나?" → "안 죽어요." 실험하면 죽는다. 그러면 드러나는 의존성.

안티패턴 2: Cascading Failures

서비스 A가 B에 의존, B가 다운되면 A가 retry 폭발 → C까지 다운. 카오스로 발견.

안티패턴 3: Single Point of Failure

DB 프라이머리 하나, Load Balancer 하나, DNS 하나. 카오스로 실제 SPOF 탐지.

안티패턴 4: Inadequate Timeouts

타임아웃 30초 = 클라이언트 대기 30초. 카오스로 "사용자 경험"에 얼마나 아픈지 보여줌.

안티패턴 5: Incomplete Retries

재시도는 있는데 backoff 없음 → 부하 증폭. 카오스로 발견.

12. 금융·의료·정부 등 엄격 규제 환경

"우리는 규제가 엄격해서 프로덕션 카오스 못 함."

접근 1: Regulatory Sandboxing

많은 규제(GDPR, PCI-DSS, HIPAA)가 **프로덕션 미러 환경**에서의 테스트를 허용. 실데이터 마스킹 후 카오스 적용.

접근 2: 최소 Blast Radius

0.1%부터. 특정 내부 사용자 트래픽에만. 감사 로그 철저히.

접근 3: Game Day만 프로덕션에서

연 1~2회 공식 훈련. 사전 승인 얻고 후속 보고.

접근 4: 실제 장애를 카오스처럼 기록

매 장애마다 **구조화된 학습**. 이미 카오스 중인 셈.

13. 실전 체크리스트 12가지

1. **Steady State 먼저 정의** — 비즈니스 지표 기반

2. **Staging부터 시작** — 그다음 프로덕션 10%

3. **Blast Radius 명시** — 영향 범위 투명화

4. **자동 중단 조건 항상 설정** — "이 지표 이하면 중단"

5. **관측성 먼저** — 측정 없으면 실험 무의미

6. **Runbook과 함께** — 카오스는 Runbook의 테스트

7. **PDB / preStop hooks** — Kubernetes 기본 안전장치

8. **온콜이 알고 있어야** — 모의 실험을 진짜 알람으로 착각하면 낭비

9. **결과 문서화** — 블로그, 내부 위키

10. **비난 없는 포스트모템 문화** — 프로세스부터 정착

11. **Game Day 정기화** — 분기 1회 이상

12. **경영진 후원** — 카오스는 투자가 필요한 문화 변화

다음 글 예고 — Feature Flag와 Progressive Delivery

"카오스"가 프로덕션에서 장애를 탐색한다면, **Feature Flag**는 프로덕션에서 **신기능을 탐색**한다. 다음 글에서는:

- **Feature Flag의 역사** — Facebook "Dark Launch"에서 LaunchDarkly까지

- 플래그 타입 분류 — release, experiment, ops, permission

- **Progressive Delivery** — Canary → Rolling → Blue/Green

- **A/B Testing**과 플래그의 차이

- **Trunk-based Development** — 브랜치 지옥 끝내는 법

- 플래그 부채 관리 (오래된 플래그의 문제)

- Unleash, LaunchDarkly, GrowthBook, Flagsmith 비교

- **Open Feature** 표준화 움직임

- 실전 롤아웃 전략 (사용자 버킷, 지리적, 시간대)

Feature Flag는 이제 "혁신적 도구"가 아닌 **현대 배포의 기본기**. 다음 글에서 전모를 보자.

> **"배포와 릴리스를 분리하라. 코드는 이미 거기에 있지만, 기능은 아직 켜지지 않았다 — 이것이 현대 소프트웨어의 기본 태도다."**