Fail Fast, Fail Free: 내 멀티 에이전트 게임에 부족했던 설계 원칙

이 글은 "프로덕션 환경에서의 멀티 에이전트 시스템: 당신이 듣지 못하는 이야기(Multi-Agent Systems in Production: What They Don't Tell You)" 시리즈의 서론입니다. 이 시리즈는 AI Engineer Week, Conf42 LLM, AgentCon Bengaluru, 그리고 R/pharma GenAI 컨퍼런스 발표를 위해 제가 제작한 게임을 바탕으로 한 4부작 시리즈입니다. 이 도입부 포스트는 이후 이어질 모든 내용의 근간이 되는 통합 원칙을 정의합니다.

내가 배포한 가장 비싼 버그

버그는 내 코드에 있었던 것이 아닙니다. 로직은 정확했습니다. 프롬프트(Prompts)도 좋았습니다. 모델(Model) 또한 최첨단(state-of-the-art)이었습니다.

버그는 내 시스템이 실패하는 _지점(where)_에 있었습니다.

나는 두 명의 AI 에이전트(Harry와 Voldemort)가 관객 앞에서 실시간으로 전투를 벌이는 "Horcrux Hunt"라는 멀티 에이전트 인터랙티브 게임을 만들었습니다. Harry(Amazon Bedrock 상의 Claude, Strands SDK 사용)는 15개 위치에 숨겨진 호크룩스(Horcruxes)를 추적합니다. Voldemort(LLM 폴백(fallback) 기능이 있는 휴리스틱 우선 적대자)는 그것들의 위치를 옮기고, 미끼를 설치하며, Harry의 신념을 타락시킵니다. 관객들은 Streamlit 대시보드를 통해 추격전이 실시간으로 전개되는 것을 지켜봅니다.

그리고 우리는 그것을 실행했습니다. 어느 주말 이벤트였습니다. AWS 비용으로 1,847달러가 청구되었습니다. 턴당 12초의 지연 시간(latency). 기다리는 관객들. Harry의 패배율 77%.

실패 원인을 분석했을 때, 나는 모든 곳에서 동일한 패턴을 발견했습니다:

Harry의 차례 동안, LLM은 약 90개의 가능한 행동(actions)에 대해 추론했습니다. 그 중 86개는 무효였습니다. 0.2ms의 제약 조건 확인(constraint check)만으로 무료로 알 수 있었던 사실을 알아내기 위해, 3초의 시간과 2,000개의 토큰(tokens)을 소비했습니다.
Harry 에이전트는 결정을 내리기 위해 5,000토큰의 히스토리를 검색했습니다. 55토큰의 확률 점수(probability score)에 동일한 정보가 포함되어 있었습니다. 하지만 우리는 전체 컨텍스트(context)를 먼저 로드한 뒤 나중에 압축했습니다. 즉, 확인하기 전에 비용을 먼저 지불한 것입니다.
잘못된 파라미터(parameters)를 가진 도구 호출(tool call)이 API에 전달되어 400 에러를 발생시켰고, 두 번의 재시도(retry)를 거쳤습니다. 클라이언트 측 검증(Client-side validation)을 했다면, 어떤 호출이나 게임 액션이 낭비되기 전인 1ms 미만의 시간에 이를 잡아냈을 것입니다.
Harry를 돕기 위해 Hermione, Ron, Dumbledore 에이전트들을 추가했습니다. 이 세 에이전트는 독립적으로 동일한 가이드라인을 조회했고, 서로 충돌하는 전략을 생성했으며, 결과적으로 Harry의 승률은 61%에서 34%로 하락했습니다. 실행 전 단 한 번의 우선순위 확인(priority check)만 있었어도 무료로 이를 잡아낼 수 있었습니다.

모든 값비싼 실패는 동일한 형태를 띠고 있었습니다: 시스템은 실패할 것임을 알고 있었지만, 너무 늦게 이를 발견했습니다. 토큰이 소비되고, 지연 시간(latency)이 소모되며, 연산(compute)이 사용되고, 턴(turns)이 낭비된 이후였습니다.

나는 이 패턴을 **"느리게 실패하고, 값비싸게 실패하기 (failing slow, failing expensive)"**라고 부르기 시작했습니다. 그리고 그 반대가 나의 설계 원칙이 되었습니다:

Fail Fast, Fail Free (빨리 실패하고, 비용 없이 실패하라).

만약 어떤 결정이 실패할 예정이라면, 아무런 비용도 들기 전에 실패하게 만드세요.

그게 전부입니다. 이것이 원칙입니다.

Fail fast (빨리 실패하기) = 가능한 가장 이른 체크포인트(checkpoint)에서 잡아내는 것
Fail free (비용 없이 실패하기) = 값비싼 미터기(meter)가 돌아가기 전에 잡아내는 것

Horcrux 사냥 게임에서 "미터기"는 문맥(context)에 따라 다릅니다:

비용(cost) 측면: 실패 1회당 발생하는 LLM 호출 비용($0.008~0.015) vs 유효하지 않은 액션을 해결하는 제약 조건 확인 시 $0
지연 시간(latency) 측면: 게임이 어차피 거부할 액션에 대한 3초 추론 호출 vs 0.2ms 검증
게임 플레이 측면: 재사용 대기 시간이 있는 위치에서 턴을 낭비하는 해리 vs 즉시 이용 불가함을 아는 것
협업(coordination) 측면: 에이전트 네 명이 9초 동안 논쟁하는 것 vs 엔트로피가 낮을 때 해리가 혼자 결정하는 것
신뢰성(reliability) 측면: 토큰을 소모시키는 재시도 루프 vs 사전 검증된 깨끗한 호출

이 원칙은 시스템의 모든 실패에 대해 하나의 질문을 던집니다: '이것을 더 일찍, 더 저렴하게, 혹은 둘 다로 잡을 수 있었을까?'

거의 항상 대답은 '그렇다'입니다.

무료 실패(Free Failure)의 해부학적 구조

'무료 실패'가 실제로 어떤 모습인지 궁금한가요? 게임에 적용할 패턴은 다음과 같습니다:

# 비싼 실패 (전통적인 방식):
# 1. 전체 게임 기록 로드 및 전체 컨텍스트 구축 (500ms, 2000 토큰)
# 2. 의사 결정을 위해 LLM 호출 (3000ms, $0.008)
...

핵심 통찰: 검증은 거의 무료입니다. 추론(Inference)이 비쌉니다. 체크포인트를 상류(upstream)로 이동시키세요.

이는 전통적인 소프트웨어 엔지니어링의 '입력 유효성 검사'를 넘어서는 개념입니다. 멀티 에이전트 프로덕션 시스템에서는 실패가 비용이 발생하기 전에 잡을 수 있는 여러 계층이 존재합니다:

Layer 1: 제약 조건 확인 (Constraint check) → '이 액션 자체가 유효한가?' → 0.2ms, $0
Layer 2: 엔트로피 확인 (Entropy check) → 'LLM 추론이 필요한가?' → 0.5ms, $0
Layer 3: 스키마 검증 (Schema validation) → '이 파라미터들이 올바른가?' → 0.3ms, $0
...

레이어 1~~5는 무료입니다. 레이어 6~~8은 비쌉니다. 레이어 1~~5에서 잡히는 모든 실패는 레이어 6~~8에 도달하지 못하는 실패입니다. 이것이 바로 'fail fast, fail free'입니다.

이 점이 특히 멀티 에이전트 시스템에 중요한 이유

단일 에이전트 시스템에서는 실패가 LLM 호출 비용 하나를 발생시킵니다. 짜증나지만 감당할 만합니다.

멀티 에이전트 시스템에서는 실패가 **복합적으로 증가(compound)**합니다:

1개 에이전트 실패 = 1회 재시도(retry) × 1회 추론 비용(inference cost)
3개 에이전트 실패 = 재시도(retries) × 컨텍스트 재생(context replay) × 조정 오버헤드(coordination overhead) × 연쇄 지연(cascading delays)

Harry가 잘못된 출력을 생성하면, Voldemort가 이를 전달받아 추론하고(토큰 비용 발생), 그 쓰레기 데이터를 기반으로 자신의 출력을 생성하며, Executor Agent가 '그것'을 전달받게 됩니다... 실패를 감지했을 때쯤이면 이미 세 번의 추론 호출 비용을 지불했고, 공유 상태(shared state)는 오염되었으며, 모든 것을 되돌려야(rewind) 하는 상황에 처하게 됩니다.

멀티 에이전트 시스템에서 조기에 포착되지 않은 실패는 배가되는 실패가 됩니다. 이것이 바로 "fail fast, fail free(빨리 실패하고, 실패로부터 자유로워지기)"가 단순한 권장 최적화가 아니라, 아키텍처 측면에서 매우 결정적인 이유입니다.

멀티 에이전트 시스템에서 지연된 감지의 비용:

실패가 포착되는 지점	단일 에이전트 비용	3개 에이전트 시스템 비용
LLM 호출 전 (Layer 1-5)	$0	$0
...

이러한 곱셈 계수(multiplication factor) 때문에 "fail fast, fail free"는 단순한 코딩 모범 사례를 넘어, 저의 멀티 에이전트 게임 및 기타 프로덕션 AI 시스템을 위한 아키텍처 원칙이 됩니다.

Fail Fast, Fail Free의 네 가지 모습

이 원칙은 직면한 실패 모드에 따라 다르게 나타납니다. 본 시리즈의 네 가지 파트에서 이 원칙이 어떻게 구현되는지 미리 살펴보겠습니다:

🔥 비용(Cost): 추론 전 가지치기 (Part 1)

LLM은 유효하지 않은 옵션에 대해 추론할 필요가 없습니다.

# Fail fast: LLM 실행 '전'에 제약 조건 해결사(constraint solver) 실행
valid_actions = constraint_solver(game_state)  # 0.2ms, $0
# 90개 옵션 → 4개의 유효한 액션
...

만약 Harry가 할 수 있는 90개의 가능한 액션 중 86개가 유효하지 않다면(위치 소진, 능력 소진 등), 이를 LLM이 직접 발견하게 만드는 것은 추론 예산(reasoning budget)의 95%를 낭비하는 것입니다. 제약 조건 해결사(constraint solver)를 사용하면 그 86개의 실패는 비용이 들지 않으며, 측정 단계(meter)에 도달조차 하지 않습니다.

모토 (The mantra): 당신이 이미 답을 알고 있는 것에 대해 LLM이 고민하게 만들지 마세요.

🧠 메모리 (Memory): 검색 전 게이트 설치 (Part 2)

모든 결정이 전체 컨텍스트 검색 (context retrieval)을 필요로 하는 것은 아닙니다. 제 경우에는 Harry의 다음 동작을 위해 5,000 토큰 전체를 히스토리로 가져올 필요가 없는 경우가 있었습니다.

# Fail fast: 검색(retrieval) 전 엔트로피(entropy) 체크
entropy = calculate_entropy(belief_map)
if entropy < 1.0:
...

엔트로피가 낮을 때 (에이전트가 베이지안 신념 지도 (bayesian belief map)를 사용하여 이미 특정 동작에 대해 확신하고 있을 때), LLM에 50턴 분량의 컨텍스트를 보내는 것은 낭비입니다. 엔트로피 체크는 'Fail-fast' 게이트 역할을 합니다: "이 결정을 위해 토큰을 소비할 필요가 있는가?"라고 묻는 것이죠. 60%의 경우, 답은 '아니오'입니다. 이러한 결정들은 비용이 들지 않게 됩니다.

모토 (The mantra): 생각을 시작하기 전에, 생각할 필요가 있는지부터 확인하세요.

🔌 통합 (Integration): 호출 전 검증 (Part 3)

클라이언트 측 스키마 검증 (schema validation)은 잘못된 파라미터(parameter)를 비용 없이 잡아냅니다.

# Fail fast: API 호출 전 JSON 스키마 검증
errors = jsonschema.validate(params, tool_schema)  # <1ms, $0
if errors:
...

제 게임 검증의 전형적인 예시입니다:

# Fail fast: 게임 액션 실행 전 스키마 검증
errors = validate_tool_call("search_location", {"location": "hogwarts"})
if game_state.cooldown["hogwarts"] > 0:
...

Harry가 쿨다운(cooldown) 상태인 위치를 검색하려고 할 때 (게임 이론 (Game Theory)에서 유래한, 즉각적인 보복이나 반복적인 행동을 제한하는 메커니즘), 이를 검증 단계(무료, <1ms)에서 잡아내는 것은 LLM 추론 (inference) + 게임 실행 + 실패 + 재시도(retry) 과정을 거친 후에 잡아내는 것보다 무한히 낫습니다. 그렇다면 여기서 MCP를 사용하는 것보다 더 나은 방법이 있을까요? MCP의 핵심 기능은 프로토콜 그 자체라기보다, 서버와 클라이언트 사이의 스키마 계약 (schema contracts)이 _무료 검증_을 가능하게 한다는 점입니다. 1ms 미만에 잡아낸 모든 파라미터 오류는 발생하지 않은 재시도입니다. 요청당 평균 2.3회의 재시도(MCP 도입 전 기준점)를 고려할 때, 이는 엄청난 차이를 만듭니다. 실패 체크포인트를 상류(upstream)로 옮기는 것만으로 재시도를 91% 감소시켰습니다.

모토 (The mantra): 가장 저렴한 API 호출은 아예 호출하지 않는 호출입니다.

🏥 조정 (Coordination): 실행 전 거부 (Veto Before Executing) (Part 4)

규제된 시스템 (Regulated systems)에서는 안전하지 않은 응답이 실행 단계가 아닌 검토 단계에서 실패해야 합니다. 예를 들어, 저의 호크룩스 게임에서 헤르미온느 (Hermione)와 덤블도어 (Dumbledore)의 의견이 일치하지 않을 때, 해리 (Harry)가 행동하기 전에 이를 해결해야 합니다.

# Fail fast: 팀이 실행하기 전 우선순위 해결
if hermione.recommends("attack_azkaban") and dumbledore.warns("trap_detected"):
    # 우선순위: 덤블도어의 안전 평가가 헤르미온느의 분석을 무시(OVERRIDES)함
...

안전 분석 (Safety analysis)이 안전하지 않은 행동을 거부(veto)할 때, 그 "실패"는 비용이 들지 않으며 2ms 미만의 활동입니다. 그 대안(토큰과 여러 번의 재시도를 사용하여 안전하지 않은 행동을 전달하는 것)은 무한히 비쌉니다. 따라서 "Fail fast, fail free"는 "조기에 검증하고, 결코 해를 끼치지 말 것 (validate early, harm never)"이 됩니다.

모토 (The mantra): 가장 안전한 실패는 실행자(executor)에게 도달하지 않는 실패입니다.

최적화 사다리 (The Optimization Ladder) (재구성)

여기서 저는 의사결정을 비용이 많이 드는 계층에서 저렴한 계층으로 밀어내기 위한 프레임워크인 "최적화 사다리 (Optimization Ladder)"를 소개하겠습니다.

"Fail Fast, Fail Free"를 통해 재구성하면, 이는 실패 체크포인트 사다리가 됩니다:

가장 저렴함 (먼저 시도):
├── 규칙 및 제약 조건 (Rules & Constraints)     → 비용 없이 이를 제외할 수 있는가?
├── 휴리스틱 (Heuristics)              → 답이 명확한가?
...

각 계층은 체크포인트입니다. 각 체크포인트는 실패가 아래 계층으로 전이(cascade)되기 전에 이를 포착합니다. 시스템은 위의 모든 무료 체크포인트를 통과한 결정에 대해서만 추론 (inference) 비용을 지불하며, 이는 전체 턴의 약 20-40%에 해당합니다.

나머지 60-80%는요? 무료입니다. 제 게임에서 해리는 제약 조건 (constraints), 엔트로피 게이트 (entropy gates), 휴리스틱 (heuristics), 그리고 수학 (math)에 따라 행동합니다. 이 모든 것은 토큰 비용이 전혀 들지 않습니다. 그리고 직관과는 반대로, 노이즈가 적을수록 더 나은 결정이 내려지기 때문에 그의 승률은 향상되었습니다.

내일부터 적용하는 방법

시스템을 완전히 재설계할 필요는 없습니다. 단 하나의 질문으로 시작하세요:

"내 파이프라인의 어느 지점에서 무언가 잘못되었다는 것을 처음 발견하는가?"

그다음 질문하세요: "그 사실을 한 단계 더 일찍 발견할 수는 없었을까?"

답변이 "아니오"이거나 "실패 체크포인트(failure checkpoint)가 이미 자유로운(free) 상태"가 될 때까지 이 과정을 반복하세요.

실질적인 시작점:

모든 LLM 호출 전에 입력 검증(input validation)을 추가하세요. 당신의 프롬프트 중 답변을 미리 결정지어 버리는 정보를 포함하고 있는 비율은 얼마나 됩니까? 에이전트의 추론(reasoning) 중 유효하지 않은 행동(invalid actions)으로 이어지는 비율은 얼마나 됩니까? 그것이 바로 당신의 "자유로운 실패(free failure)" 기회입니다.
검색(retrieval) 전에 엔트로피/신뢰도(entropy/confidence) 체크를 추가하세요. 에이전트가 필요하지 않은 컨텍스트(context)를 검색하는 빈도는 얼마나 됩니까? 그것은 토큰 낭비입니다.
모든 도구 호출(tool call) 전에 스키마 검증(schema validation)을 추가하세요. 재시도(retry) 비율은 어느 정도입니까? 각 재시도는 전체 토큰 비용과 같습니다. 이를 평균 토큰 비용과 곱해 보세요. 그것이 바로 자유로운 검증(free validation)이 당신을 위해 절약해 주는 비용입니다.
모든 멀티 에이전트 출력(multi-agent output) 전에 안전/우선순위(safety/priority) 체크를 추가하세요. 에이전트들이 서로 의견이 불일치하는 빈도는 얼마나 됩니까? 오케스트레이션(orchestration) 단계에서 포착된 각 불일치는 사용자에게 도달하지 않는 모순(contradiction)이 됩니다.

시리즈 로드맵

이 블로그는 원칙을 정의합니다. 이어지는 네 개의 글은 Horcrux Hunt를 구축하고, 망가뜨리고, 고치는 관점을 통해 그 원칙이 실제로 어떻게 작동하는지 보여줍니다.