LLM 프로덕션을 위한 카오스 엔지니어링(Chaos Engineering for LLM Production)

2026년의 LLM 카오스 엔지니어링(Chaos Engineering)은 그 자체로 하나의 분야(discipline)로 자리 잡았습니다. 운영 환경(production)에서 실험을 돌리기 전에 반드시 갖춰야 할 선행 조건은 정의된 SLI/SLO, 트레이스(trace)와 메트릭(metric)과 로그(log)를 아우르는 관측성(observability), 자동 롤백(automated rollback), 런북(runbook), 그리고 온콜(on-call) 체계입니다. 아키텍처는 네 개의 평면(plane)으로 구성됩니다. 실험 스케줄러를 두는 제어 평면(control plane), 서비스·인프라·데이터 저장소가 놓이는 대상 평면(target plane), 가드와 중단(abort)과 트래픽 필터를 둔 안전 평면(safety plane), 메트릭과 트레이스와 로그를 모으는 관측 평면(observability plane), 그리고 SLO 조정으로 이어지는 피드백 루프(feedback loop)입니다. 가드레일(guardrail)은 선택이 아니라 필수입니다. 번 레이트 알람(burn-rate alert)은 일일 오류 예산(error budget) 소진이 기대치의 2배를 넘으면 실험을 일시 중단(pause)합니다. 억제 윈도우(suppression window)와 트레이스 ID 상관관계(trace-ID correlation)는 알람 잡음을 중복 제거(dedupe)합니다. 주기(cadence)는 매주 작은 카나리(canary) 실험과 SLO 리뷰, 매월 게임 데이(game day)와 사후 분석(postmortem), 매 분기 부서 간 회복력 감사(resilience audit)와 의존성 매핑(dependency mapping)으로 구성합니다. LLM에 특화된 실험으로는 메모리 과부하(memory overload), 네트워크 장애(network failure), 공급자(provider) 장애, 비정상 프롬프트(malformed prompt), KV 캐시 축출 폭풍(KV cache eviction storm)이 있습니다. 도구로는 LLM 기반 추천과 폭발 반경(blast-radius) 축소, MCP 도구 통합을 제공하는 Harness Chaos Engineering, CNCF의 LitmusChaos, 쿠버네티스(Kubernetes) 네이티브인 Chaos Mesh를 활용합니다.

유형: Learn 언어: Python (stdlib, 학습용 카오스 실험 러너) 선수 지식: Phase 17 · 23 (SRE for AI), Phase 17 · 13 (Observability) 예상 시간: 약 60분

학습 목표

• 카오스 엔지니어링의 다섯 가지 선행 조건(SLI/SLO, 관측성(observability), 롤백(rollback), 런북(runbook), 온콜(on-call))을 말하고, 그중 하나라도 빠지면 왜 실천 자체가 무너지는지 설명합니다.
• 네 개의 평면(제어(control), 대상(target), 안전(safety), 관측(observability))과 SLO로 돌아가는 피드백 루프(feedback loop)를 도식으로 그립니다.
• LLM에 특화된 다섯 가지 실험(메모리 과부하(memory overload), 네트워크 장애(network fail), 공급자 장애(provider outage), 비정상 프롬프트(malformed prompt), KV 축출 폭풍(KV eviction storm))을 열거합니다.
• 주어진 스택(stack)에 맞춰 Harness, LitmusChaos, Chaos Mesh 가운데 알맞은 도구를 고릅니다.

문제

전통적인 스택(stack)에서 카오스 테스트(chaos testing)는 이미 정착한 관행입니다. 그러나 LLM 스택은 기존에 없던 새로운 장애 모드(failure mode)를 추가합니다. 가령 독성 문자(poison character)가 들어 있는 4K 토큰(token) 프롬프트 하나가 토크나이저(tokenizer)를 12초간 멈추게 만듭니다. 상류 공급자(upstream provider)가 429를 반환하면 게이트웨이가 재시도(retry)하고, 그 결과 재시도로 증폭된 동시 요청 때문에 서비스에서 OOM(out-of-memory)이 발생합니다. 폭발적인 부하 아래에서는 KV 캐시 축출 폭풍이 일어나 재(再) 프리필(re-prefill) 캐스케이드를 만들어 컴퓨트(compute)를 포화시킵니다.

이 같은 문제들은 단위 테스트(unit test)에 잡히지 않습니다. 카오스 엔지니어링은 사용자가 먼저 겪기 전에 우리가 먼저 이런 장애를 발견해 두는 방법입니다.

개념

선행 조건(Prerequisites)

운영 환경에서 카오스를 실행하기 전에는 다음이 반드시 갖춰져 있어야 합니다.

1. SLI/SLO — 서비스 수준 지표(service-level indicator)와 목표(objective)가 정의되어 있어야 합니다.
2. 관측성(Observability) — 트레이스, 메트릭, 로그가 대시보드(dashboard)에 연결되어 있어야 합니다.
3. 자동 롤백(Automated rollback) — Phase 17 · 20에서 다룬 정책 플래그(policy-flag) 기반 롤백을 갖춥니다.
4. 런북(Runbook) — 구조화된 형태로 정리되어 있어야 합니다(Phase 17 · 23).
5. 온콜(On-call) — 즉시 대응할 수 있는 사람이 있어야 합니다.

이 가운데 하나라도 빠진 상태에서 카오스를 돌리면, 그것은 더 이상 실험이 아니라 실제 사고(incident)가 됩니다.

네 개의 평면(plane)과 피드백 루프

제어 평면(Control plane) — 실험 스케줄러(experiment scheduler)를 둡니다. 예: Litmus 워크플로(workflow), Chaos Mesh 스케줄(schedule), Harness UI.

대상 평면(Target plane) — 실험이 작용하는 대상입니다. 서비스, 파드(pod), 노드(node), 로드 밸런서(load balancer), 데이터 저장소(data store)가 여기에 포함됩니다.

안전 평면(Safety plane) — 킬 스위치(kill switch), 억제 윈도우(suppression window), 폭발 반경(blast radius) 제한, 오류 예산 게이트(error-budget gate)로 실험의 위험을 통제합니다.

관측 평면(Observability plane) — 평상시 메트릭에 트레이스 ID 상관관계를 더해, 카오스가 유발한 장애와 자연 발생 장애를 구분할 수 있게 합니다.

피드백 루프(Feedback loop) — 실험에서 발견된 사실은 SLO 조정, 런북 갱신, 코드 수정으로 되돌아갑니다.

가드레일은 필수입니다

• 번 레이트 알람(Burn-rate alert): 일일 오류 예산 소진이 기대치의 2배를 넘으면 실험을 일시 중단(pause)합니다.
• 억제 윈도우(Suppression window): 실험이 진행되는 동안 폭발 반경 안쪽의 비(非)실험 알람은 잠시 잠재웁니다.
• 트레이스 ID 상관관계(Trace-ID correlation): 실험으로 유발된 모든 오류에는 태그를 붙여 두어, 온콜이 알람을 중복 제거(dedupe)할 수 있게 합니다.

LLM에 특화된 다섯 가지 실험

1. 메모리 과부하(Memory overload) — 높은 동시 요청과 긴 컨텍스트(long-context) 요청을 함께 보내 KV 캐시 선점 폭풍(preemption storm)을 강제로 만들어 봅니다. 관찰 포인트: 서비스가 우아하게 부하를 떨궈내는가(graceful shedding), 아니면 그대로 crash 하는가?

2. 네트워크 장애(Network failure) — 추론 게이트웨이(inference gateway)와 공급자 사이의 연결을 끊습니다. 관찰 포인트: 폴백(fallback)이 SLA 안에서 동작하는가? (Phase 17 · 19)

3. 공급자 장애 시뮬레이션(Provider outage simulation) — OpenAI에서 100% 429를 반환하게 만듭니다. 관찰 포인트: 라우팅이 Anthropic으로 페일오버(failover)되는가? (Phase 17 · 16, 19)

4. 비정상 프롬프트(Malformed prompt) — 토크나이저를 멈추게 만드는 입력을 주입(inject)합니다. 예: 깊게 중첩된 유니코드(unicode), 거대한 UTF-8 코드포인트(codepoint). 관찰 포인트: 단 하나의 요청이 워커(worker) 하나를 통째로 잠그는가?

5. KV 축출 폭풍(KV eviction storm) — vLLM의 블록 예산(block budget)을 포화시켜 축출(eviction)을 강제합니다. 관찰 포인트: LMCache가 복구되는가, 아니면 서비스가 그대로 성능 저하(degrade)에 빠지는가?

주기(Cadence)

• 매주(Weekly) — 스테이징(staging)에서 작은 카나리(canary) 실험을 돌립니다. 안정이 확인되면 운영 환경의 5% 정도까지 확장합니다.
• 매월(Monthly) — 특정 시나리오를 정해 일정에 따라 게임 데이(game day)를 엽니다. 부서 간 함께 참석하고 사후 분석(postmortem)으로 마무리합니다.
• 매 분기(Quarterly) — 부서 간 회복력 감사(resilience audit)를 진행하고 의존성 맵(dependency map)을 갱신합니다.

도구(Tooling)

• Harness Chaos Engineering — 상용(commercial) 도구입니다. AI 기반 실험 추천, 폭발 반경 축소(blast-radius downscaling), MCP 도구 통합을 제공합니다.
• LitmusChaos — CNCF 졸업(graduated) 프로젝트이며 쿠버네티스 워크플로 기반(workflow-based)입니다.
• Chaos Mesh — CNCF 샌드박스(sandbox) 프로젝트이며 쿠버네티스 네이티브 CRD 스타일을 따릅니다.
• Gremlin — 상용 도구이며 폭넓은 환경을 지원합니다.
• AWS FIS / Azure Chaos Studio — 관리형 클라우드(managed cloud) 서비스 형태로 제공됩니다.

작게 시작하기

첫 번째 실험으로는 평상시 트래픽 아래에서 디코드 레플리카(decode replica) 하나를 강제 종료(pod-kill)하는 것이 적당합니다. 트래픽이 다시 라우팅(rerouting)되어 복구되는 과정을 관찰합니다. 이 단계가 무사히 지나가고 안전하다고 판단되면 네트워크 카오스(network chaos)로 넘어갑니다.

LLM에 특화된 첫 실험으로는 5분 동안 공급자 429를 하나만 주입해 보는 것을 권장합니다. 폴백(fallback)이 실제로 동작하는지 관찰합니다. 대부분의 팀은 이 실험에서 자신들의 폴백이 끝까지 검증된 적이 없었다는 사실을 발견하곤 합니다.

기억해 둘 숫자

• 네 평면: 제어(control), 대상(target), 안전(safety), 관측(observability).
• 번 레이트 일시 중단 기준: 기대 일일 예산 소진의 2배.
• 주기: 매주 카나리, 매월 게임 데이, 매 분기 감사.
• LLM 다섯 실험: 메모리, 네트워크, 공급자, 비정상 프롬프트, KV 폭풍.

사용해보기

code/main.py는 안전 평면 게이트(safety plane gate)가 적용된 세 가지 카오스 실험을 시뮬레이션합니다. 각 실험 가운데 어떤 것이 번 레이트 중단(burn-rate abort) 조건에 걸리는지 보고합니다.

산출물 만들기

이 레슨에서는 outputs/skill-chaos-plan.md를 만듭니다. 스택과 성숙도(maturity) 정보가 주어졌을 때, 처음 시도할 세 가지 실험과 사용할 도구를 골라 줍니다.

연습문제

1. 쉬움: code/main.py를 실행합니다. 어떤 실험이 번 레이트 게이트에 걸리며, 그 이유는 무엇입니까?
2. 중간: vLLM 기반 RAG 서비스를 위한 첫 다섯 가지 카오스 실험을 설계합니다. 각각의 성공 기준(success criteria)을 포함합니다.
3. 중간: 번 레이트 알람이 실험을 일시 중단했습니다. 근본 원인(root cause)이 카오스 실험 때문인지, 자연 발생 장애 때문인지 어떻게 판별하시겠습니까?
4. 어려움: 카오스를 운영 환경에서 돌려야 하는지 스테이징에서만 돌려야 하는지를 논합니다. 운영 환경에서 돌리는 것이 정답이 되는 상황은 어떤 경우입니까?
5. 어려움: 일반적인 네트워크 카오스(network chaos)로는 재현할 수 없는 LLM 특유의 장애 모드 세 가지를 말합니다.

핵심 용어

더 읽을거리

• DevSecOps School — Chaos Engineering 2026 Guide
• Ankush Sharma — Observability for LLMs (book)
• LitmusChaos (CNCF)
• Chaos Mesh (CNCF)
• Harness Chaos Engineering
• AWS FIS