프로덕션 환경을 위한 5-에이전트 AI 팀 구축 방식 (30일간의 기록, 실제 비용, 발생한 문제점)

대부분의 "AI 에이전트 팀 (AI agent team)" 튜토리얼은 데모 단계에서 멈춥니다. 에이전트 하나가 다른 에이전트를 호출하고, 서로 대화하며, 노트북에 만족스러운 답변이 출력되면 모두가 박수를 칩니다. 하지만 이를 실제 업무에 한 달 동안 투입해 보면, 첫날 선택한 구조가 당신의 수면 여부를 결정하게 됩니다.

우리는 5-에이전트 팀을 30일 동안 프로덕션 (production) 환경에서 운영했습니다. 이것은 살아남은 조직도와 살아남지 못한 조직도, 실제 달러 비용, 그리고 아무도 경고해주지 않는 실패 사례들에 대한 기록입니다.

우리가 시작했던 팀 (그리고 왜 무너졌는가)

우리의 첫 번째 본능은 아주 당연한 것이었습니다. 모든 작업을 수신하고 4명의 "작업자 (workers)"에게 위임하는 하나의 "매니저 (manager)" 에이전트를 두는 것이었습니다. 화이트보드 위에서는 깔끔해 보였지만, 실제로는 재앙이었습니다.

매니저는 단일 장애점 (single point of failure)이자 단일 비용 발생 지점 (single point of cost)이 되었습니다. 모든 작업은 계획을 위해 한 번, 검토를 위해 한 번, 총 두 번 매니저를 거쳐 왕복해야 했기에, 매니저는 자신이 직접 수행하지 않는 작업에도 토큰 (tokens)을 소모했습니다. 매니저가 작업을 잘못 읽으면 4명의 작업자 모두가 그 실수를 물려받았습니다. 또한 모든 것이 하나의 컨텍스트 윈도우 (context window)로 집중되었기 때문에, 그 윈도우가 가득 차면서 매니저는 긴 작업의 앞부분을 잊어버리기 시작했습니다.

교훈 1: 중앙 집중형 매니저 에이전트는 조직도가 아니라 병목 현상 (bottleneck)이다. 이는 비용, 실패, 그리고 컨텍스트 제한을 당신이 가장 감당하기 어려운 단 한 곳에 집중시킵니다.

하나의 매니저 에이전트 = 비용, 실패, 컨텍스트 오버플로 (context overflow)의 단일 지점.

살아남은 구조

우리는 구조를 평탄화(flattened)했습니다. 매니저가 모든 것을 라우팅(routing)하는 대신, 각 에이전트에게 **좁은 권한 범위 (narrow charter)**를 부여하고, LLM이 아닌 일반 코드인 **결정론적 라우터 (deterministic router)**를 사용하여 작업 유형에 따라 어떤 에이전트가 작업을 받을지 결정하도록 했습니다.

다섯 가지 역할은 다음과 같습니다:

1. Intake — 들어오는 요청을 구조화된 JSON 작업으로 정규화 (normalize) 합니다. 추론(reasoning)은 하지 않으며, 오직 형태(shape)만 잡습니다.
2. Planner — 작업을 순서가 있는 단계별 목록으로 변환합니다. 다단계 작업(multi-step work)에 대해서만 실행되며, 단일 단계 작업은 이 단계를 완전히 건너뜁니다.
3. Executor — 실제 도구 호출 (tool calls)을 수행합니다. 외부 시스템에 접근할 수 있는 유일한 에이전트입니다.
4. Verifier — Executor의 출력물을 작업 내용과 대조하여 검증하며, Executor와는 독립적으로 작동합니다. 이 에이전트가 제 역할을 톡톡히 해냈습니다 (자세한 내용은 아래 참조).
5. Scribe — 최종 구조화된 결과물과 사람이 읽을 수 있는 요약본을 작성합니다.

라우터(router)는 의도적으로 단순하게 설계되었습니다. 단일 단계 작업은 Intake → Executor → Verifier → Scribe 순으로 진행되며 Planner를 절대 깨우지 않습니다. 이러한 "단순함" 덕분에 매니저(manager) 설계 방식에 비해 토큰 비용을 약 3분의 1 정도 절감할 수 있었습니다. 실행할 필요가 없는 에이전트는 실행되지 않기 때문입니다.

교훈 2: 매니저 LLM을 결정론적 라우터(deterministic router)로 교체하세요. 라우팅은 if 문과 같은 문제이지, 추론(reasoning)의 문제가 아닙니다. "어떤 에이전트"를 사용할지 결정하기 위해 모델 토큰을 소비하는 것은, switch 문이 무료로 처리할 수 있는 작업에 프리미엄 가격을 지불하는 것과 같습니다.

좁은 역할 범위, 결정론적 라우터, 그리고 실행할 필요가 없는 에이전트는 실행하지 않습니다.

아무도 경고해주지 않는 실패: 확신에 찬 오답

가장 위험한 에이전트는 시스템을 충돌시키는 에이전트가 아닙니다. 작업을 완료하고 성공했다고 보고하지만, 실제로는 틀린 답을 내놓는 에이전트입니다.

첫 주에 두 번, 우리의 Executor가 작업을 잘못 완료하고 완료(done)로 표시했습니다. 오류도, 예외(exception)도 없었습니다. 그저 초록색 체크 표시와 함께 잘못된 결과가 나왔을 뿐입니다. 만약 우리가 그 체크 표시를 믿었다면, 그 쓰레기 같은 데이터는 그대로 다음 단계로 흘러갔을 것입니다.

해결책은 검증기 (Verifier)이며, 이를 작동하게 만드는 규칙은 다음과 같습니다: 검증기는 실행기 (Executor)로부터 독립적이어야 합니다. 서로 다른 프롬프트를 사용하고, 가능하다면 제2의 의견 (second opinion) 대신 결정론적 체크 (deterministic check)를 수행해야 합니다. 예를 들어, 샘플 정답 (ground truth)과 비교하거나, 일반 코드로 계산을 다시 실행하거나, JSON 스키마 (JSON schema)에 따라 출력을 검증하는 방식입니다. 자신이 푼 숙제를 스스로 채점하는 에이전트는 아무것도 잡아낼 수 없습니다.

교훈 3: 모든 에이전트 작업에는 자신이 생성하지 않은 별도의 검증 단계가 필요합니다. 자유 형식의 "괜찮아 보이네요"는 검증이 아닙니다. 구조화된 출력 (Structured output)과 독립적인 체크가 결합되어야 비로소 검증입니다.

자신의 숙제를 스스로 채점하는 에이전트는 아무것도 잡아낼 수 없습니다. 독립적으로 검증하세요.

실제 비용

여기가 튜토리얼들이 생략하는 부분입니다.

• 첫 달 청구액이 예상치의 약 4배에 달했습니다 — 모델 비용이 비싸서가 아니었습니다. 바로 재시도 루프 (retry loops) 때문이었습니다. 에이전트가 일시적인 오류 (transient failure)를 겪으면 재시도하고, 또 실패하면 다시 재시도하며 상한선 없이 반복됩니다. 각 재시도는 모두 비용이 발생하는 추론 (inference)입니다. 하나의 멈춰버린 작업이 밤사이 조용히 수백 번의 호출을 발생시켰습니다.
• 해결책은 두 줄의 정책이었습니다: 지수 백오프 (exponential backoff)와 엄격한 최대 재시도 횟수 (hard max-retry count) 설정입니다. 이는 기본 중의 기본이며, 우리는 비싼 대가를 치르고 이를 배웠습니다.
• 우리는 또한 **작업당 엄격한 토큰 예산 (hard token budget per task)**을 설정했습니다. 각 에이전트에게 상한선을 부여하여, 상한선에 도달하면 무한히 돌아가는 대신 작업이 명확하게 실패하도록 했습니다. 실패한 작업은 비용이 적게 들지만, 통제 불능 상태로 돌아가는 작업은 그렇지 않습니다.

교훈 4: 비용 제어는 나중에 확인하는 대시보드가 아니라, 설계 요구 사항입니다. 재시도 제한과 작업당 토큰 예산은 무서운 청구서를 받은 후가 아니라, 출시 전에 포함되어야 합니다.

첫 번째 달은 재시도 루프(retry loops)에 상한선이 없어 비용이 4배나 더 나왔습니다. 해결책: 첫날부터 제한(caps)을 설정하는 것입니다.

우리가 다시는 하지 않을 일들

• 매니저 에이전트 (Manager agent). 위에서 언급했습니다. 구조를 평탄화(Flatten)하세요.
• 에이전트 간의 자유 형식 텍스트 (Free-form text). 초기에는 에이전트들이 서로에게 산문(prose)을 전달했고, 다음 에이전트는 이를 다시 파싱(parse)해야 했습니다. 모든 인계(handoff) 과정이 오독의 가능성이었습니다. 우리는 모든 에이전트 간 메시지에 JSON 스키마 (JSON schemas)를 도입했습니다. 구조화되지 않으면 출시하지 마세요.
• 초록색 체크 표시를 신뢰하는 것. 성공을 보고하는 에이전트는 주장을 하는 것이지, 사실을 말하는 것이 아닙니다. 독립적으로 검증(Verify)하세요.
• 단계별 추적 (Step-level traces) 없이 출시하는 것. 무언가 고장 났을 때, "팀이 실패했다"는 말은 우리에게 아무런 정보도 주지 못했습니다. 단계별 실행 추적(execution traces)은 3시간 걸리던 디버깅(debugging) 세션을 3분으로 단축해 주었습니다. 필요할 때가 아니라, 필요하기 전에 미리 추가하세요. 왜냐하면 새벽 2시에 반드시 필요하게 될 것이기 때문입니다.

효과적인 구조

모든 것을 걷어내고 살아남은 구조는 단순합니다:

살아남은 구조: 좁은 범위의 에이전트, 코드 라우터 (code router), 독립적 검증, 비용 상한선.

• 하나의 만능 에이전트(god-agent)가 아닌, 좁은 범위의 에이전트 (Narrow agents). 모든 것을 수행하는 하나의 LLM보다 전문화된 역할이 더 안정적으로 작동합니다.
• 매니저 LLM이 아닌, 결정론적 라우터 (Deterministic router). 라우팅(Routing)은 코드로 구현해야 합니다.
• 모든 작업에 대한 독립적 검증 (Independent verification). 모델은 하나의 구성 요소일 뿐입니다. 모델을 둘러싼 하네스(harness) — 즉 검증, 예산, 추적, 구조화된 출력(structured output) — 가 시스템의 나머지 전부입니다.
• 첫날부터 설정된 비용 상한선 (Cost ceilings). 출시 전 재시도 제한(Retry caps)과 토큰 예산(token budgets)을 설정하세요.

우리는 매 프로젝트마다 이 하네스(harness)를 다시 구축하는 것에 지쳤고, 그래서 라우터(router), 검증 루프(verification loop), 작업별 예산(per-task budgets), 트레이스(traces)를 one-team이라는 하나의 패키지로 묶었습니다. 만약 여러분이 멀티 에이전트 팀(multi-agent team)을 구성하고 있으며, 저희가 겪었던 방식대로 레슨 4(Lesson 4)를 다시 학습하고 싶지 않다면, 바로 이를 위해 만들어진 것입니다.

모델은 결코 어려운 부분이 아니었습니다. 조직도(org chart)가 문제였습니다.

프로덕션 환경에서 에이전트 팀을 운영해 보셨나요? 1일 차와 비교했을 때 30일 차의 구조는 어떠했나요? 다른 분들은 어떤 결론에 도달했는지 궁금합니다.