"프로덕션에서의 멀티 에이전트 시스템(Multi-Agent Systems): 당신이 듣지 못하는 이야기" 시리즈의 제1부 — 비싼 대가를 치르며 프로덕션 AI에 대해 모든 것을 가르쳐준 멀티 에이전트 해리 포터 게임, Horcrux Hunt의 대서사시를 따라가는 4부작 시리즈입니다.

내 게임 비용이 월세보다 더 많이 나왔던 주말

나는 두 명의 AI 에이전트가 관객 앞에서 실시간으로 전투를 벌이는 인터랙티브 해리 포터 테마 게임인 Horcrux Hunt를 만들었습니다. Harry(주인공, Strands SDK를 통해 Amazon Bedrock의 Claude로 구동됨)는 15개 위치에 숨겨진 Horcruxes를 찾아다닙니다. Voldemort(적대자)는 그것들을 옮기고, 미끼를 설치하며, Harry의 신념을 타락시킵니다.

이것을 두 LLM(Large Language Models) 사이의 적대적 숨바꼭질이라고 생각하면 됩니다. 관객들은 실시간으로 Streamlit 대시보드에서 Harry의 탐색 과정이 펼쳐지는 것을 지켜보며 투표합니다.

재미있는 주말 데모가 될 예정이었습니다. 관객들은 좋아했습니다. 하지만 CloudWatch 지표는 그렇지 않았습니다.

청구서: 주말 동안 1,847달러.

내 월세보다 더 많았습니다.

게다가 성능은 끔찍했습니다:

• 턴당 12초의 지연 시간 (latency) (관객들이 말 그대로 기다려야 함)
• Harry의 승률 23% (거의 이기지 못함)
• 18%의 타임아웃(timeout) 비율 (생각하는 도중에 Lambda 함수가 종료됨)
• **비용의 67%**가 Bedrock LLM 호출에서만 발생

관객 피드백에는 "게임이 느리다", "Harry가 거의 이기지 못한다"와 같은 내용이 있었습니다. 그들은 이것이 저를 파산시키고 있다는 사실은 몰랐습니다.

멀티 에이전트 시스템이 생각보다 비용이 많이 드는 이유

우리는 멀티 에이전트 시스템을 구축합니다. 모든 작업에 에이전트를 계속 추가합니다. 하지만 우리는 결코 묻지 않습니다 - "에이전트가 몇 개나 되어야 너무 많은 것인가"? 멀티 에이전트 아키텍처를 제안할 때 아무도 보여주지 않는 공식이 여기 있습니다:

비용(Cost) = 토큰(tokens) × 에이전트(agents) × 턴(turns) × 재시도(retries) × 컨텍스트 재생(context_replay)

각 항은 서로를 곱합니다. 이는 가산적인 것이 아니라 승수적인 것입니다. Horcrux Hunt를 해부학적 사례로 사용하여 그 이유를 설명하겠습니다.

기하급수적으로 증가하는 컨텍스트 윈도우 (Context Windows)

Horcrux Hunt의 매 턴마다, 게임은 모든 검색, 모든 신호, 사용된 모든 아군 능력을 포함한 전체 대화 기록을 Harry에게 제공합니다. 50번째 턴에 이르면, 그것은 엄청난 양이 됩니다:

매 턴마다 LLM (Large Language Model)은 전체 대화 기록을 다시 읽습니다. 이는 Harry가 결정을 내릴 때마다 자신의 미션 일지 전체를 첫 페이지부터 다시 읽는 것과 같습니다. 50번째 턴에 이르면, 1번째 턴 비용의 7.5배를 지불하게 되며, 이는 단 하나의 에이전트(agent)에 불과한 비용입니다.

두 명의 에이전트(Harry와 Voldemort)가 있다면, 토큰 곡선(token curve)은 2배가 됩니다. 각 에이전트가 스스로 팽창하는 컨텍스트 (context)를 유지하기 때문입니다.

출력 토큰(Output Tokens)은 숨겨진 살인마입니다

대부분의 사람들은 입력 토큰 (input tokens)에 집중합니다. 하지만 대부분의 모델에서 출력 토큰은 입력 토큰보다 5배 더 많은 비용이 듭니다 (Claude 3 Sonnet 기준: 입력 1K당 $0.003 vs 출력 1K당 $0.015). 또한 출력 토큰은 순차적으로 생성되어 토큰당 12ms가 소요되며, 병렬화 (parallelization)가 불가능합니다.

Harry의 응답은 턴당 평균 150-200개의 출력 토큰을 생성했습니다. Voldemort는 평균 100-150개였습니다. 50턴 × 2명의 에이전트를 기준으로 했을 때, 출력 토큰은 전체 실행 시간 (wall-clock time)의 39%를 차지했습니다. 관객들은 모델이 '생각'하는 것이 아니라, *토큰 생성 (token generation)*을 기다리고 있었던 것입니다.

한 턴은 실제로는 12번의 연산입니다

제가 상상했던 한 턴의 모습은 다음과 같았습니다:

1. Harry가 생각한다 → 2. Harry가 행동한다 → 3. Voldemort가 응답한다

실제로 한 턴에 필요한 작업은 다음과 같습니다:

1. DynamoDB에서 게임 상태 (game state) 로드
2. 유효한 행동 (valid actions) 계산 (어느 위치가 재사용 대기 시간 (cooldown) 중인가?)
3. Harry의 컨텍스트 (context) 구축 (게임 이력 압축)
4. Harry의 결정을 위해 Bedrock 호출
5. Harry의 응답 검증 (행동 형식이 올바른가? 합법적인 이동인가?)
6. Harry의 행동 실행 (게임 보드 업데이트, 신호 (signals) 해결)
7. Voldemort의 컨텍스트 계산
8. Voldemort의 결정을 위해 Bedrock 호출 (또는 휴리스틱 (heuristic) 사용)
9. Voldemort의 응답 검증
10. Voldemort의 행동 실행 (호크룩스 (Horcrux) 이동? 미끼 설치?)
11. 공유 게임 상태 업데이트 (위치, 신호, 점수)
12. DynamoDB에 저장 + CloudWatch 메트릭 (metrics) 발행

50 턴 × 12개 작업 = 게임당 600개 작업. 순차적인 특성이 진정한 병목 현상 (bottleneck)입니다. Voldemort의 행동은 Harry가 방금 무엇을 했는지에 달려 있기 때문에 Harry와 Voldemort를 병렬화 (parallelize)할 수 없습니다.

느리게 실패하고, 비싸게 실패하기

재시도율 (retry rate)을 분석했을 때 발견한 점은 다음과 같습니다: LLM 응답의 15%가 검증에 실패했습니다. Harry가 잘못된 행동 형식을 생성하거나, 재사용 대기 시간 (cooldown) 중인 위치를 탐색하려 하거나, 이미 사용한 아군 능력을 사용하려고 시도했습니다.

각 실패 시: 3초간의 추론 (reasoning) → 거부됨 → 전체 컨텍스트 (full context) 재재생 → 재시도. 각 재시도는 전체 토큰 비용이 발생했습니다.

시스템은 돈을 쓴 이후에 실패를 발견하고 있었습니다. 느리게 실패하고 (추론 시작 3초 후). 비싸게 실패했습니다 (실패당 전체 토큰 비용 발생). 저는 나중에 이 패턴의 반대되는 이름을 붙였습니다.

나를 겁먹게 만든 비용 계산

• 게임당: ~$1.95 (단순한 접근 방식)
• 일일 1,000 게임: 하루 $1,950
• 월간: ~$49,000
• 연간: ~$588,000

단 하나의 게임을 위해 말이죠. Harry가 호크룩스를 쫓는 2인 에이전트 게임을 위해서 말입니다.

비용 세부 내역:

• Bedrock (LLM 호출): 67% — 게임당 $1.31
• Lambda (연산): 26% — 게임당 $0.51
• DynamoDB (상태): 7% — 게임당 $0.13

이제 이것을 항상 켜져 있는(always-on) 인터랙티브 경험으로 배포한다고 상상해 보세요. 1,000개의 게임이 동시에 실행되는 상황으로 확장한다고 상상해 보세요. 숫자는 매우 빠르게 공포스러운 수준으로 치솟습니다.

네 가지 해결책: 최적화 사다리 (An Optimization Ladder)

저에게 필요했던 것은 더 적은 수의 에이전트가 아니었습니다. 제가 필요했던 것은 더 적은 수의 *비싼 결정(expensive decisions)*이었습니다. 여기 비용이 많이 드는 LLM 레이어에서 더 저렴한 대안으로 결정을 아래로 밀어내는 최적화 사다리가 있습니다.

해결책 1: 문제의 범위 제한 (제약 조건 가지치기, Constraint Pruning)

이전: Harry는 턴당 90개의 가능한 행동(15개 위치 × 6개 행동 유형: 수색, 공격, 아군 활용, 조사, 요새화, 후퇴)을 보았고, LLM은 어떤 행동이 유효한지 추론해야 했습니다.

이후: 제약 조건 해결사(constraint solver)가 Harry의 LLM이 확인하기 전에 유효하지 않은 행동을 가지치기합니다:

def get_valid_actions(game_state, agent="harry"):
    actions = []
    for loc in game_state.locations:
...

결과: 90개의 옵션 → 2~4개의 유효한 옵션. Harry의 LLM은 쿨타임 중인 위치나 이미 사용한 능력에 대해 추론하며 토큰을 낭비하지 않습니다. 유효하지 않은 추론 토큰 80% 감소.

이 지점에서 저는 다음과 같은 원칙을 만들었습니다: "Fail Fast, Fail Free (빨리 실패하고, 비용 없이 실패하라)."

제약 조건 해결사는 잘못된 결정이 LLM에 닿기 전에 잡아냅니다. 0.2ms의 Python 함수에 의해 거부된 유효하지 않은 행동은 비용이 전혀 들지 않습니다. 반면 Claude가 3초 동안 동일한 유효하지 않은 행동에 대해 추론하면 토큰과 지연 시간(latency)이 발생하며, 추론 후 검증(post-inference validation)에 실패할 경우 재시도(retry) 비용까지 발생하곤 합니다.

Fail fast = 조기에 잡아내는 것. Fail free = 계량기가 돌아가기 전에 잡아내는 것.

해결책 2: 토큰을 수학으로 대체 (베이지안 추론, Bayesian Inference)

이전: Harry는 "호크룩스가 아마 어디에 위치해 있을까?"를 알아내기 위해 50턴 분량의 서사적 기록(5,000 토큰)을 다시 읽었습니다.

1턴: Harry가 Hogwarts를 탐색함 → 부정적 신호 (negative signal)
2턴: Harry가 Diagon Alley를 탐색함 → 긍정적 신호 (positive signal)
3턴: Harry가 Diagon Alley를 공격함 → 미끼 (decoy!)
...

이후: 베이지안 신념 지도 (Bayesian belief map)가 LLM
_외부_에서 확률을 계산합니다:

class HorcruxBeliefMap:
    def __init__(self, locations):
        n = len(locations)
...

Harry의 LLM이 실제로 보는 것: "top_target: Hogwarts (p=0.34), Azkaban (p=0.22)" = 15 토큰, 5,000 토큰이 아닙니다.

결과: 97%의 컨텍스트 (context) 감소. 신념 계산을 위한 비용이 $0.015에서 사실상 $0로 떨어집니다. 그리고 Harry는 확률이 서사적 직관보다 더 정밀하기 때문에
더 나은 결정을 내립니다.

"Fail Fast, Fail Free"의 또 다른 측면은, 만약 수학적 계산($0)으로 답을 구할 수 있다면, 왜 서사 텍스트로부터 이를 추론하기 위해 LLM($0.015)에 비용을 지불하겠느냐는 것입니다.

해결책 3: LLM 호출 건너뛰기 (휴리스틱 결정 트리 (Heuristic Decision Trees))

모든 Voldemort의 결정에 2,000억 개의 파라미터를 가진 모델이 필요하지는 않습니다. 어떤 게임 상황들은 명백한 최적의 움직임을 가지고 있습니다:

def voldemort_decide(game_state):
    # 만약 Harry가 실제 호크룩스에 한 수 차이로 접근했다면 → 위치 이동 (명백함)
    if game_state.harry_adjacent_to_horcrux():
...

결과: Voldemort 결정의 60%가 LLM 비용 없이 처리됩니다. 여러 유효한 전략이 경쟁하는 진정으로 전략적인 순간에만 추론 호출을 정당화합니다.

해결책 4: 비용이 많이 드는 레이어 격리 (아키텍처 (Architecture))

가장 영향력 있는 변화는 구조적인 것이었습니다. 저는 Horcrux Hunt를 재설계하여 8개 모듈 중 2개만 LLM에 접근하도록 만들었습니다:

무료 모듈 (6개):
├── Game Engine         (규칙, 턴 관리)
├── Constraint Solver   (유효한 행동 계산)
...

인터페이스 경계 (Interface Boundary)는 무료 모듈과 비용이 발생하는 모듈 사이의 경계에서 컨텍스트를 압축합니다:

• LLM 입력: 2,000개 이상의 원시 게임 상태 토큰 → 55개의 AgentContext 토큰으로 압축
• LLM 출력: 즉시 검증되며, 유효하지 않을 경우 무료로 거부됨

이것은 아키텍처로서의 "Fail Fast, Fail Free(빠르게 실패하고, 비용 없이 실패하라)"입니다. 즉, 명확한 비용 경계가 존재합니다. 검증은 무료 영역(free zone)에서 이루어집니다. 무언가 실패해야 한다면, 6개의 무료 모듈 중 하나에서 실패할 뿐, 비용이 많이 드는 2개의 모듈에서는 절대 실패하지 않습니다.

결과 (The Results)

동일한 게임. 동일한 Harry. 동일한 Voldemort. 동일한 Claude Sonnet 모델. 하지만 근본적으로 다른 아키텍처입니다:

Harry가 더 많이 승리하는 이유는 모델이 더 똑똑해졌기 때문이 아니라, 6,000개의 노이즈 토큰에 빠져 허우적거리는 대신 집중되고 관련 있는 정보에 기반하여 추론(reasoning)하기 때문입니다. 시청자들은 12초의 대기 시간 대신 3초의 턴을 보게 됩니다. 이제 게임은 실제로 관람하는 "재미"가 생겼습니다.

교훈 (The Lesson)

"에이전트가 몇 명이면 너무 많은가?"라는 질문에 대한 답은 숫자가 아닙니다. 그것은 질문입니다:

"이 결정이 LLM 호출을 할 만큼 가치가 있는가?"

Voldemort의 결정 대부분은 그렇지 않았습니다. Harry의 확률 계산 대부분도 그렇지 않았습니다. 검증 로직(validation logic) 대부분도 마찬가지였습니다. 제가 이미 알고 있는 것을 발견하기 위해 LLM에 비용을 지불하는 것을 멈추자, 비용이 낭떠러지 아래로 떨어지듯 급감했습니다.

최적화 사다리 (The Optimization Ladder):

1. **규칙 (rule)**이 이를 처리할 수 있는가? (무료 — 제약 조건, 쿨다운, 예산)
2. **휴리스틱 (heuristic)**이 이를 처리할 수 있는가? (거의 무료 — if/then 게임 로직)
3. **수학 (math)**이 이를 처리할 수 있는가? (저렴함 — 베이지안 업데이트 (Bayesian updates), 엔트로피 (entropy))
4. 이것이 진정으로 LLM을 필요로 하는가? (비쌈 — 하지만 진정한 불확실성(uncertainty)을 위해서는 정당함)

모든 결정을 가능한 한 이 사다리의 아래쪽으로 밀어내세요. 모든 계층에서 빠르게 실패하고, 비용 없이 실패(Fail fast, fail free) 하십시오.

🚀 다음 단계 (What's Next)

청구서는 통제 범위 안에 들어왔습니다. 하지만 Harry는 여전히 지고 있습니다.

그는 같은 위치를 두 번 검색합니다. 3턴 전의 신호를 잊어버립니다. 자신의 신념 지도(belief map)와 모순되는 행동을 합니다. 문제는 더 이상 비용이 아니라, 추론 실패로 위장한 메모리(memory) 문제입니다.

→ Part 0: Fail Fast, Fail Free

이 원칙에 대해 더 자세히 알고 싶다면 이 블로그를 읽어보세요.