단일 에이전트가 확장성 문제로 실패하는 이유와 이를 해결하는 3가지 역할 아키텍처

LLM (Large Language Models)으로 시스템을 구축할 때 흔히 하는 순진한 가정은 더 똑똑한 단일 에이전트가 더 많은 문제를 해결할 것이라는 점입니다. 더 나은 도구를 제공하고, 더 긴 컨텍스트 윈도우 (Context Window)를 부여하며, 더 강력한 모델을 사용하면 확장될 것이라고 믿습니다.

하지만 그렇지 않습니다. 모델의 능력이 부족해서가 아니라, 아키텍처 (Architecture)가 잘못되었기 때문입니다.

인간의 주의력 (Attention)은 병목 현상의 원인이 됩니다. 30일간의 엔지니어링 작업을 수행하는 단일 에이전트는 모든 단계에서 감독될 수 없으며, 감독될 수 없다면 실패는 운영 환경에서 무언가 고장 날 때까지 조용히 누적됩니다.

여기에 작업의 복잡성까지 더해지면 단일 에이전트 시스템은 빠르게 한계에 부딪힙니다. 환각 (Hallucination)을 일으키거나, 컨텍스트 (Context)를 놓치거나, 지속적인 인간의 수정이 필요한 일관성 없는 출력을 생성하게 됩니다.

해결책은 더 나은 모델이 아닙니다. 다른 아키텍처입니다. 실제로 작동하는 아키텍처를 소개합니다.

첫째: 멀티 에이전트 (Multi-agent)가 실제로 무엇을 의미하는지 이해하기

[

]

'멀티 에이전트'라는 용어는 두 개의 LLM이 서로 대화하는 것부터 50개의 에이전트로 구성된 분산 시스템까지 모든 것을 설명하는 데 사용됩니다. 분류 체계 (Taxonomy)는 매우 중요한데, 선택한 디자인 패턴 (Design Pattern)이 시스템이 실패하는 방식을 결정하기 때문입니다.

각기 다른 문제를 해결하는 다섯 가지 패턴이 있습니다:

[

]

대부분의 운영 시스템은 이들을 조합하여 사용합니다. 제가 복잡한 엔지니어링 작업에 가장 신뢰할 수 있다고 판단한 아키텍처는 위임 (Delegation)을 중추로 삼고, 모든 출력 경계에 생성자-검증자 (Creator-Verifier) 구조를 내장하는 방식입니다.

3가지 역할 아키텍처: 오케스트레이터 (Orchestrator), 워커 (Workers), 검증자 (Validators)
모든 미션에는 세 가지 역할이 있습니다. 이들은 서로 대체될 수 없으며, 컨텍스트 프롬프트 (Context Prompts)를 공유해서도 안 됩니다.

오케스트레이터 (The Orchestrator)

오케스트레이터 (The Orchestrator)는 코드를 작성하지 않습니다. 기능을 구현하지도 않습니다. 이들의 역할은 세 가지입니다: 전략적 계획 (Strategic planning), 마일스톤 정의 (Milestone definition), 그리고 검증 계약 (Validation contracts) 생성입니다.

검증 계약 (Validation contract)이란, 어떤 작업자 (Worker)가 시작하기 전에 각 마일스톤에 대해 '완료'가 무엇을 의미하는지 미리 합의된 사양 (Specification)입니다. 이것은 오케스트레이터가 생성하는 가장 중요한 산출물 (Artifact)입니다. 이것이 없다면 검증은 주관적이게 되며, 작업자들은 잘못된 결과물을 위해 최적화하게 됩니다.

오케스트레이터의 출력물은 계획과 일련의 계약입니다. 만약 오케스트레이터가 구현 (Implementation)을 작성하고 있다면, 당신의 아키텍처 (Architecture)에 문제가 있는 것입니다.

작업자 (Workers)

작업자들은 구현을 담당합니다. 각 작업자는 이전 마일스톤으로부터 축적된 부담이 없는, 백지 상태의 컨텍스트 (Clean-slate context)를 부여받습니다. 이는 의도적인 설계입니다. 작업 초기 단계에서의 컨텍스트 유출 (Context bleed)은 디버깅하기 어려운 방식으로 새로운 작업을 오염시키기 때문입니다.

작업자가 생성하는 세 가지는 기능 구현 (Feature implementation), 구조화된 git 커밋 (Structured git commits), 그리고 그 외에는 아무것도 없습니다. 구조화된 커밋 형식이 중요한 이유는, 이것이 오케스트레이터가 마일스톤 진행 상황을 추적하는 방식이자 검증자 (Validators)가 무엇을 테스트해야 할지 아는 방법이기 때문입니다.

작업자들은 다른 작업자에 대해 알지 못합니다. 전체 계획도 알지 못합니다. 그들은 자신의 마일스톤, 자신의 검증 계약, 그리고 자신의 도구 (Tools)만을 알고 있습니다.

검증자 (Validators)

검증자는 설계 단계부터 적대적 (Adversarial)입니다. 이들의 역할은 작업자의 출력물이 검증 계약을 통과하지 못하는 이유를 찾아내는 것이지, 도움을 주거나, 개선 사항을 제안하거나, 부분 점수를 주는 것이 아닙니다.

두 가지 유형의 검증: 적대적 검증 (Adversarial verification, 구현체가 실제로 계약과 일치하는가?) 및 엔드 투 엔드 동작 확인 (End-to-end behavior checks, 실제 사용자가 마주하는 방식대로 시스템이 올바르게 작동하는가?).

검증자 (Validator)는 작업자 (Worker)의 컨텍스트 (Context)를 절대 보지 않습니다. 검증자는 오직 계약 (Contract)과 출력물 (Output)만을 봅니다. 만약 검증자가 출력물을 평가하기 위해 작업자의 추론 (Reasoning) 과정을 읽어야 한다면, 그 출력물은 충분히 완전하지 않은 것입니다.

하나가 아닌 세 명의 검증자

단 한 번의 검증 과정은 놓치는 부분이 생기기 마련입니다. 이 아키텍처는 서로 다른 계층에서 세 개의 별도 검증자를 사용합니다.

세 가지를 모두 실행하는 것은 선택 사항이 아닙니다. 검증 계약 검증자 (Validation Contract Validator)는 잘못된 사양 (Spec)이 작업자의 실행 시간을 낭비하기 전에 잡아냅니다. 정밀 검증자 (Scrutiny Validator)는 구현 드리프트 (Implementation drift)를 잡아냅니다. 사용자 테스트 검증자 (User Testing Validator)는 '기술적으로는 정확함'과 '실제로 작동함' 사이의 간극을 잡아내는데, 바로 이 지점이 프로덕션 (Production) 환경에서 대부분의 버그가 발생하는 곳입니다.

실행 전략: 기본적으로 직렬 (Serial) 방식, 안전한 경우에만 병렬 (Parallel) 방식 사용
모든 것을 병렬화하려는 본능이 있습니다. 더 많은 에이전트 (Agent)가 동시에 실행되면 = 더 빠른 출력물이 나옵니다. 하지만 실제로 제약 없는 병렬화는 절약한 시간보다 디버깅하기 더 어려운 일관성 (Consistency) 문제를 야기합니다.

효과적인 실행 전략:

일관성을 위한 직렬 실행 (Serial execution)

마일스톤 (Milestone)은 기본적으로 순차적으로 실행됩니다. 다음 마일스톤이 시작되기 전에 각 마일스톤의 출력물이 검증됩니다. 이를 통해 두 개의 병렬 작업자가 공유 상태 (Shared state)에 대해 서로 충돌하는 가정을 하는 부류의 버그를 제거합니다.

읽기 전용 작업을 위한 내부 병렬화 (Internal parallelization)

마일스톤 내에서 상태를 쓰지 않는 작업들은 병렬로 실행될 수 있습니다. 조사 (Research), 분석 (Analysis), 컨텍스트 수집 (Context gathering) 등은 안전합니다. 공유 상태를 수정하는 모든 것은 직렬로 실행됩니다.

컨텍스트 유지를 위한 구조화된 핸드오프 (Structured handoffs)

Worker가 Validator에게 핸드오프(handoff)를 수행할 때, 핸드오프에는 무엇이 구축되었는지, 계약(contract)에서 요구한 사항은 무엇인지, 그리고 어떤 테스트가 실행되었는지가 포함됩니다. 전체 컨텍스트 윈도우(context window)를 전달하는 것이 아니라 구조화된 요약(structured summary)을 전달하는 것입니다. Validator는 해당 요약만으로도 평가를 수행할 수 있어야 합니다.

자가 치유 마일스톤 경계 (Self-healing milestone boundaries)

마일스톤(milestone)이 검증(validation)에 실패했을 때, 시스템은 처음부터 다시 시작하지 않습니다. 실패 정보를 포함하는 업데이트된 계약과 새로운 Worker 컨텍스트를 사용하여 해당 특정 마일스톤을 재시도합니다. Orchestrator가 재시도 로직을 소유합니다. Worker는 자신이 재시도하고 있다는 사실을 알지 못합니다.

Droid whispering: 역할에 맞는 모델 매칭 (matching models to roles)

모든 역할에 동일한 모델이 필요하지는 않습니다. 이 아키텍처는 설계 단계부터 모델 불가지론적(model-agnostic)이며, 이는 단순히 회피책이 아니라 비용과 역량을 고려한 의도적인 결정입니다.

Orchestrator는 긴 컨텍스트(long context)에 대해 전략적 추론(strategic reasoning)을 수행합니다. 따라서 사용 가능한 가장 강력한 모델로부터 이점을 얻습니다.

Worker는 좁은 범위 내에서 집중적인 구현(focused implementation)을 수행합니다. 작업 범위가 제한적이고 컨텍스트가 깨끗하기 때문에, 여기서는 더 작고 빠르며 저렴한 모델이 종종 대등하거나 더 나은 성능을 발휘합니다.

Validator는 특정 계약을 바탕으로 적대적 검사(adversarial checking)를 수행합니다. 마찬가지로, 모호한 지시를 받는 범용 대형 모델보다 잘 구조화된 프롬프트(prompt)를 가진 집중형 모델이 더 뛰어난 성능을 보입니다.

프롬프트 기반의 오케스트레이션(orchestration) 레이어는 약 700줄에 달합니다. 이는 과잉 엔지니어링(over-engineering)의 징후가 아니라, 아키텍처를 모델 불가지론적으로 만드는 핵심 요소입니다. 더 나은 모델이 출시되면 아키텍처가 아닌 모델 문자열만 교체하면 됩니다.

모델 업데이트에 대한 탄력성(resilience)은 사후 고려 사항이 아니라 설계 요구 사항입니다. 특정 모델의 동작을 가정하는 모든 아키텍처는 해당 모델이 변경될 때 무너집니다. 명시적인 계약을 가진 프롬프트 기반 오케스트레이션은 모델의 동작이 변할 때 시스템이 재앙적으로 붕괴하는 대신 우아하게 성능이 저하(degrade gracefully)되도록 합니다.

이것이 실제로 만들어내는 결과

16~30일간의 미션 동안 실제 엔지니어링 작업에 이 아키텍처를 적용한 결과:

1. 90% 코드 커버리지 (code coverage)

2. 매 마일스톤(milestone)마다 활성 실행(active runs)에 대한 비동기적 '미션 컨트롤 (Mission Control)' 뷰 제공 — 모든 검증기(validator)와 재시도(retry) 내역 확인 가능

3. 데모 환경이 아닌 실제 프로덕션 작업(production tasks)을 수행하는 엔지니어 팀의 실질적인 생산성 향상

4. 검증 계약(validation contracts)을 통해 시스템이 완료 시점을 스스로 인지하므로, 별도의 모니터링(babysitting)이 필요 없는 실행

90% 커버리지라는 수치가 중요한 이유는 이것이 목표가 아니라 부산물이기 때문입니다. 검증기(Validators)가 적대적(adversarial)이고 계약(contracts)이 명시적일 때, 커버리지는 마지막에 테스트 코드를 작성하여 강제하는 것이 아니라 아키텍처로부터 자연스럽게 따라옵니다.

이것으로부터 얻어야 할 교훈

인간의 주의력 병목 현상(attention bottleneck)은 실재합니다. 수 주간 지속되는 에이전트 실행(agentic run)의 모든 단계를 감독할 수는 없습니다. 아키텍처는 단순히 스스로 실행(self-executing)되는 것을 넘어, 스스로 검증(self-validating)할 수 있어야 합니다.

이것을 작동하게 만드는 세 가지 요소: 구현 시작 전 작성된 검증 계약(validation contracts), 출력값만을 확인하는 적대적 검증기(adversarial validators), 그리고 타겟팅된 내부 병렬화(internal parallelization)를 동반한 직렬 실행(serial execution)입니다.

거의 항상 생략되는 부분은 바로 '검증 계약 검증기(Validation Contract Validator)'입니다. 팀들은 곧바로 구축 단계로 뛰어들었다가, 실행 중간에 성공 기준이 모호했다는 사실을 깨닫게 됩니다. 그것은 모델의 문제가 아니라, 사양(spec)의 문제입니다.

멀티 에이전트 시스템(multi-agent systems)을 운영하면서 겪었던 가장 큰 실패 모드(failure mode)는 무엇이었나요? 그리고 그것은 아키텍처의 문제였나요, 아니면 모델의 문제였나요?