실패 모드(Failure Modes) — MAST, Groupthink, Monoculture, Cascading Errors

2026년의 기준 분류 체계(reference taxonomy)는 MAST입니다(Cemri et al., NeurIPS 2025, arXiv:2503.13657). 이 분류는 7개의 최신(state-of-the-art) 오픈소스 멀티 에이전트 시스템(Multi-Agent System; MAS)에서 수집한 1,642건의 실행 추적(execution traces)에서 도출되었고, 41–86.7%에 이르는 실패율(failure rate)을 보였습니다. 세 개의 최상위(root) 범주는 다음과 같습니다. 사양 문제(Specification Problems)(41.77%) — 역할 모호성(role ambiguity), 불명확한 과제 정의(unclear task definitions). 조정 실패(Coordination Failures)(36.94%) — 통신 단절(communication breakdowns), 상태 불일치(state desync). 검증 공백(Verification Gaps)(21.30%) — 검증 누락(missing validation), 품질 점검의 부재(absent quality checks). 집단사고(Groupthink) 계열(arXiv:2508.05687)은 여기에 다섯 가지를 더합니다. 같은 기반 모델(base model)을 공유해 오류가 함께 일어나는 단일 문화 붕괴(monoculture collapse), 에이전트끼리 서로의 오류를 강화하는 동조 편향(conformity bias), 마음 이론(theory of mind; ToM)의 결핍(deficient ToM), 혼합 동기 역학(mixed-motive dynamics), 그리고 연쇄적 신뢰성 실패(cascading reliability failures)입니다. 연쇄 실패의 예로는 재시도 폭풍(retry storm)이 있습니다. 결제(payment) 실패가 주문 재시도(order retries)를 부르고, 그것이 다시 재고(inventory) 재시도를 부르며, 재고 서비스가 몇 초 안에 평소의 10배 부하(10x load)에 짓눌립니다. 이를 막으려면 회로 차단기(circuit breaker)가 필요합니다. 메모리 오염(memory poisoning)은 한 에이전트의 환각(hallucination)이 공유 메모리(shared memory)에 기록되어 하류(downstream) 에이전트가 그것을 사실로 받아들이는 현상입니다. 정확도가 서서히 감소(decay)하기 때문에 근본 원인 진단(root-cause diagnosis)이 매우 까다롭습니다. STRATUS(NeurIPS 2025)는 탐지(detection), 진단(diagnosis), 검증(validation)을 맡는 특화된 에이전트를 도입하면 완화 성공률(mitigation-success)이 1.5배 개선된다고 보고합니다. 이 강의는 실패 모드를 일급(first-class) 엔지니어링 대상으로 다룹니다.

유형: Learn 언어: Python (stdlib) 선수 지식: Phase 16 · 13 (공유 메모리), Phase 16 · 14 (에이전트를 위한 합의와 Byzantine Fault Tolerance), Phase 16 · 15 (투표, Self-Consistency와 토론 토폴로지) 예상 시간: 약 75분

문제

멀티 에이전트 시스템은 실제 과제(real task)에서 41–86.7%에 달하는 비율로 실패합니다(Cemri et al. 2025가 7개의 오픈소스 MAS에서 측정한 수치입니다). 이는 "에이전트를 더 붙이자"만으로 디버깅(debugging)할 수 있는 종류의 문제가 아닙니다. 실패에는 구조적인 원인(structural cause)이 있고, MAST 분류 체계는 그 원인을 묶는 범주를 제공합니다. 이 강의는 각 범주를 구체적인 탐지·진단·완화 패턴(detection, diagnosis, mitigation pattern)에 연결해, 위 숫자가 더 이상 임의로 보이지 않도록 정리합니다.

2026년 운영(production) 현장의 관행은 실패 모드를 아키텍처의 설계 입력(design input)으로 다루는 것입니다. 각 MAST 범주를 짚으며 "이 범주에 대해 우리는 어떤 완화책을 배치했다"고 말할 수 있을 때까지 아키텍처는 아직 "충분히 좋다(good enough)"고 보지 않습니다.

개념

MAST 범주

사양 문제(Specification Problems, 전체 실패의 41.77%). 에이전트의 과제(task)가 충분히 엄밀하게 정의되지 않은 경우입니다. 예를 들면 다음과 같습니다.

• 역할 모호성(role ambiguity): 두 에이전트가 모두 자신이 검토자(reviewer)라고 생각합니다.
• 과제 과소 명세(task underspecified): 사용자는 특정한 관점의 요약을 원했는데 프롬프트(prompt)는 단지 "summarize this"뿐입니다.
• 암묵적 성공 기준(success criteria implicit): 에이전트가 자신이 성공했는지 스스로 판단할 수 없습니다.

완화책(mitigations):

• 명시적인 역할 계약(role contract)을 작성합니다. 각 에이전트의 프롬프트에는 그 에이전트가 무엇을 하는지와 무엇을 하지 않는지를 함께 적습니다.
• 과제마다 인수 시험(acceptance test)을 둡니다. 에이전트가 작업을 시작하기 전에 "완료된 모습은 X와 같다(done looks like X)"를 정의합니다.
• 사전 점검(pre-flight spec check)을 둡니다. 별도의 에이전트가 작업을 디스패치(dispatch)하기 전에 과제 정의를 검토합니다.

조정 실패(Coordination Failures, 36.94%). 통신 또는 상태에서 일어나는 단절(breakdown)입니다.

예시:

• 두 에이전트가 동기화(synchronization) 없이 공유 상태(shared state)를 갱신합니다.
• 에이전트 사이의 메시지가 유실됩니다(큐 실패, 타임아웃).
• 상태 이탈(state drift): 에이전트 A는 과제가 끝났다고 보지만 에이전트 B는 아직 실행 중입니다.

완화책:

• 낙관적 동시성 제어(optimistic concurrency)를 적용한 버전 관리된 공유 상태(versioned shared state).
• 중요한 메시지에는 명시적 수신 확인(explicit acknowledgment)을 요구합니다(확인을 받을 때까지 재전송).
• 주기적인 상태 동기화 체크포인트(state-sync checkpoint)를 두어 이탈을 조기에 감지합니다.

검증 공백(Verification Gaps, 21.30%). 출력에 대한 독립적인 점검(independent check)이 없는 경우입니다.

예시:

• 한 에이전트가 성공을 주장하지만 아무도 그것을 검증하지 않습니다.
• 에이전트 체인(chain)이 매 단계마다 직전 단계의 출력을 그냥 신뢰합니다.
• 에이전트들이 결합되어 나타나는 발현적 행위(emergent composed behavior)에 대한 시험 커버리지(test coverage)가 없습니다.

완화책:

• 독립 검증자 에이전트(independent verifier agent, Lesson 13). 읽기 전용(read-only)이고, 독립적인 원본 정보 접근(independent source access) 권한을 가집니다.
• 명시적 인계 계약(handoff contract): "A의 출력은 검사기 C를 통과해야만 B가 시작한다."
• 사후 분석(post-hoc analysis)을 위한 결과 기록(outcome logging).

집단사고 계열 (Groupthink family, arXiv:2508.05687)

에이전트들이 동질화(homogenize)되거나 서로를 모방할 때 나타나는, 서로 관련된 다섯 가지 실패입니다.

단일 문화 붕괴(Monoculture collapse). 같은 기반 모델 또는 같은 훈련 데이터(training data)를 공유하면 오류가 상관(correlated)됩니다. 세 에이전트가 같은 LLM을 공유하면 환각(hallucination)도 공유합니다.

동조 편향(Conformity bias). 에이전트가 가장 목소리가 크거나 가장 자신감 있는 동료의 의견에 끌려가며, 그 답이 틀렸을 때도 마찬가지입니다.

마음 이론의 결핍(Deficient ToM). 에이전트가 서로의 믿음(belief)을 모델링하지 못해 조정(coordination)이 무너집니다(Lesson 18).

혼합 동기 역학(Mixed-motive dynamics). 부분적으로만 정렬된 유인(partially-aligned incentive)을 가진 에이전트들이, 누구도 만족시키지 못하는 어중간한 타협(compromise-middle)으로 흘러갑니다.

연쇄적 신뢰성 실패(Cascading reliability failures). 한 구성요소(component)의 오류 패턴이 그것에 의존하는 다른 구성요소의 오류 패턴을 촉발합니다.

연쇄 실패 예시 — 재시도 폭풍(retry storm)

2026년에 흔히 보이는 전형적인 사고(incident) 패턴입니다.

payment service fails 10% of requests
   ↓
order agent retries payment (exponential backoff but naive)
   ↓
each retry is a new order-inventory check
   ↓
inventory service sees 2x normal load
   ↓
inventory service starts timing out
   ↓
every order retries inventory check
   ↓
inventory service sees 10x normal load
   ↓
cluster goes down

해결책은 고전적입니다. 바로 회로 차단기(circuit breaker)입니다. 하류 오류율(downstream error rate)이 임계값(threshold)을 넘으면, 캐시된(cached) 결과나 기본값(default)으로 호출을 단락(short-circuit)시킵니다. 또한 요청별로 상한이 정해진 재시도 예산(capped retry budget)을 함께 둡니다.

회로 차단기는 거의 수정 없이 분산 시스템(distributed systems)에서 그대로 가져다 쓸 수 있는, 몇 안 되는 멀티 에이전트 실패 완화책 중 하나입니다.

메모리 오염(Memory poisoning) 다시 보기

Lesson 13에서 이미 다룬 내용입니다. 한 에이전트의 환각이 공유 메모리의 사실(fact)이 되고, 하류 에이전트가 그 오염된 사실 위에서 추론(reasoning)을 이어갑니다. MAST 용어로 보면 이는 공유 메모리 계층에서 일어나는 검증 공백입니다.

증상(symptom)은 점진적인 정확도 감소입니다. 시스템이 크게 멈추는 것이 아니라, 천천히 정확도가 표류(drift)하기 때문에 근본 원인을 추적하기가 어렵습니다.

완화책은 추가 전용 로그(append-only log), 출처 정보(provenance), 쓰기 불가능한 검증자(unwritable verifier)입니다. Lesson 13에서 이미 다뤘습니다.

STRATUS — 실패 탐지를 위한 특화 에이전트

STRATUS(NeurIPS 2025)는 다음 세 에이전트를 배치하면 완화 성공률이 1.5배 개선된다고 보고합니다.

• 탐지 에이전트(Detection agent). 증상 패턴(높은 의견 불일치, 재시도 급증, 정확도 표류 등)을 관찰합니다.
• 진단 에이전트(Diagnosis agent). 증상이 주어지면 MAST 분류 체계에서 가능성 있는 근본 원인을 추론(infer)합니다.
• 검증 에이전트(Validation agent). 완화책이 적용된 뒤 증상이 실제로 사라졌는지 확인합니다.

이는 SRE(Site Reliability Engineering) 방식의 사고 대응(incident response)을 에이전트 시스템에 적용한 것입니다. 세 역할 모두 특화된 프롬프트를 가진 LLM 에이전트로 구현할 수 있습니다.

실패 모드 감사(failure-mode audit)

2026년의 모범 사례(best practice)는 연 1회 또는 메이저 릴리스(major release)마다 실패 모드 감사를 수행하는 것입니다.

1. 추적 표본(Trace sample). 실제 실행 추적 약 1,000건을 수집합니다.
2. 분류(Categorize). 각 추적의 실패를 MAST와 집단사고 계열의 범주로 매핑합니다.
3. 범주별 실패율 계산(Compute failure-by-category rate). 어느 범주가 우리 시스템을 지배하고 있는지 확인합니다.
4. 완화책 순위 매기기(Rank mitigations). 어떤 수정이 가장 많은 실패를 제거할 수 있는지 따져 봅니다.
5. 2–3개 완화책 선정(Pick 2–3 mitigations). 구현한 뒤 다음 분기(quarter)에 다시 감사를 수행합니다.

구체적인 선택보다 이러한 규율(discipline) 자체가 더 중요합니다. 감사가 없으면 실패는 잡음(noise)에 묻혀버려, 결코 체계적으로 다루어지지 않습니다.

시스템이 조용히 실패할 때

가장 위험한 실패 범주는 조용한 정확성 실패(silent correctness failure)입니다. 시끄럽게 실패하는 시스템(crash, exception, alert)은 모니터링이 가능하지만, 그럴듯하지만 틀린(plausible-but-wrong) 출력을 내놓는 시스템은 예외 로그(exception log)만으로는 잡아낼 수 없습니다. 검증 공백이 건수 기준으로는 21.30%에 불과한데도 한 건당 비용은 가장 비싼 범주가 되는 이유가 바로 이것입니다.

다음에 투자해야 합니다.

• 표본 기반의 사람 검토(sample-based human review).
• 골든 데이터셋(golden-dataset)을 활용한 회귀 시험(regression test).
• 중요한 출력에 대한 에이전트 간 교차 점검(cross-agent cross-checking).

빠른 실패와 느린 실패(Failure vs slow failure)

실패에는 즉시 드러나는 즉각적 실패(immediate failure)와 서서히 드러나는 느린 실패(slow failure)가 있습니다. 즉각적 실패(timeout, schema mismatch, auth error)는 감지 비용이 낮습니다. 반면 느린 실패(메모리 오염, 단일 문화 표류, 역할 모호성)는 감지하고 예방하는 비용이 큽니다.

2026년 엔지니어링이 권하는 방향은 느린 실패의 대리 지표(slow-failure proxy)를 계측(instrument)해, 그것이 눈에 보이는 오류로 자라기 전에 표류를 잡아내는 것입니다. 의견 일치율(agreement rate), 재시도율(retry rate), 출력 길이 분포(output-length distribution), 연속된 에이전트 버전 간의 편집 거리(edit distance) 모두가 유용한 대리 지표입니다.

직접 만들기

code/main.py는 다음을 구현합니다.

• FailureTaxonomy — 모의(simulated) 사고를 MAST와 집단사고 계열의 범주로 분류합니다.
• CircuitBreaker — 고전적인 패턴입니다. 오류율이 임계값을 넘으면 열림(open) 상태로 전이합니다.
• RetryStormSimulator — 연쇄 실패를 시연합니다. 회로 차단기의 켜짐/꺼짐(on/off)을 전환해 비교할 수 있습니다.
• DetectionAgent — STRATUS 방식의 증상 매처(symptom matcher)를 스크립트(scripted)로 구현한 버전입니다.

실행 방법은 다음과 같습니다.

python3 code/main.py

예상 출력:

• 회로 차단기가 없는 경우의 재시도 폭풍: 재고 서비스 쪽 오류가 모의 환경에서 폭증합니다.
• 회로 차단기가 있는 경우: 임계값에서 호출이 제한되고, 성능 저하 모드(degraded-mode) 응답이 반환됩니다.
• 탐지 에이전트가 패턴을 표시하고(flag), 어떤 MAST 범주인지 이름을 붙입니다.

사용해보기

outputs/skill-mast-auditor.md는 멀티 에이전트 시스템에 MAST 방식의 실패 모드 감사를 실행합니다. 추적 수집 → 범주화 → 완화책 순위 매기기 순서입니다.

배포 전 확인

운영 환경에서의 실패 모드 규율:

• 분기별 MAST 감사(MAST audit per quarter). 연 1회로 충분하지 않습니다. 시스템이 자라면 범주의 분포도 함께 바뀝니다.
• 모든 곳에 회로 차단기(Circuit breakers everywhere). 의존하는 서비스로 나가는 모든 외부 호출(outbound call)에 둡니다. 기본 개방 임계값(open threshold)은 오류율 5–10%로 시작합니다.
• 골든 데이터셋(Golden datasets). 작고 품질이 높으며 사람이 손으로 감사한(hand-audited) 데이터셋입니다. 매주 회귀 시험을 돌립니다.
• STRATUS 3종(STRATUS trio). 탐지 + 진단 + 검증 에이전트가 운영 환경을 함께 감시합니다. 처음에는 탐지 에이전트만 운영하다가, 증상이 잡음 섞인 형태로 늘어나면 진단 에이전트를 추가합니다.
• 실패 예산(Failure budget). 범주별 실패율에 대해 명시적인 서비스 수준 목표(Service Level Objective; SLO)를 둡니다. 예산을 초과하면 출시 중단(stop-shipping) 논의를 시작합니다.

연습문제

1. (쉬움) code/main.py를 실행합니다. 회로 차단기가 재시도 폭풍을 제한하는지 확인합니다. 실패 임계값을 바꿔보며 절충점(trade-off)을 관찰합니다.
2. (중간) 느린 실패 대리 지표(slow-failure proxy)를 구현합니다. 병렬로 동작하는 세 에이전트의 의견 일치율을 측정하고, 그 값이 급격히 떨어지면 경보(alert)를 띄웁니다. 에이전트의 출력이 점점 더 비슷해지도록 조작해 단일 문화 표류를 모의 실험합니다.
3. (중간) Cemri et al.(arXiv:2503.13657)을 읽습니다. 논문이 다룬 7개의 MAS 중 하나를 골라, 그 시스템의 상위 3개 실패 범주를 매핑합니다. 그 결과는 MAST가 예측하는 분포와 어떻게 다릅니까?
4. (어려움) 집단사고 논문(arXiv:2508.05687)을 읽습니다. 다섯 가지 패턴 중 운영 환경에서 감지하기 가장 어려운 것은 무엇입니까? 그 패턴을 추적할 대리 지표(proxy metric)를 제안하십시오.
5. (어려움) 자신이 알고 있는 특정 멀티 에이전트 시스템 하나를 골라, STRATUS 방식의 탐지-진단-검증 3종 구성을 설계하십시오. 탐지 에이전트는 어떤 증상을 감시합니까? 진단 에이전트는 어떤 완화책을 권합니까? 검증 에이전트는 그 완화책이 효과를 냈다고 어떻게 확인합니까?

핵심 용어

더 읽을거리

• Cemri et al. — Why Do Multi-Agent LLM Systems Fail? — MAST 분류 체계를 제안한 NeurIPS 2025 논문입니다.
• Groupthink failures in multi-agent LLMs — 단일 문화, 동조 편향을 포함한 다섯 계열 분류를 다룹니다.
• STRATUS — specialized agents for MAS incident response — NeurIPS 2025 프로시딩(proceedings) 항목으로, 탐지·진단·검증 구성을 다룹니다.
• Release It! — stability patterns (Nygard) — 회로 차단기 패턴의 정전(canonical) 참고서입니다.
• Anthropic — Multi-agent research system — 운영 환경에서 관찰된 실패 모드 노트입니다.