Anthropic의 Applied AI 팀은 너무 많은 엔터프라이즈 에이전트 설계가 조직도를 그대로 복제한다고 지적합니다. 그들의 해결책은 평가(eval)를 우선하고 서브 에이전트를 하나씩 통합하는 것입니다. 여러분은 무엇 때문에 서브 에이전트를 유지하셨나요?
Anthropic's own Applied AI team says too many enterprise agent designs just copy the org chart. Their fix is an eval first, then folding subagents in one at a time. What made you keep yours?
핵심 요약
조직도를 따라 설계된 멀티 에이전트 구조의 문제점과 이를 해결하기 위한 평가 기반의 통합 전략에 대한 논의입니다.
- 조직도 기반 설계 — 문제 유형별로 서브 에이전트를 나누면 컨텍스트 손실과 복잡성 증가가 발생함
- 평가 우선 통합 — 10개의 골든 예제로 평가를 먼저 구축하고 서브 에이전트를 하나씩 메인 루프로 통합함
- 통합의 기준 — 권한 분리, 컨텍스트 과부하 방지, 혹은 특정 모델의 효율성이 필요한 경우에만 서브 에이전트 유지
- 평가 데이터의 함정 — 기존 평가 세트에 없는 엣지 케이스를 놓치지 않도록 로그를 활용한 데이터 보강이 필수적임
Anthropic의 Applied AI 팀이 10월 22일에 올린 가이드는 그동안 수많은 멀티 에이전트 빌드 삽질을 정리한 사후 분석 보고서 같더라. 얘네 관찰 결과가 뭐냐면, 팀마다 혹은 문제 유형마다 무지성으로 서브 에이전트를 하나씩 붙이다 보니 결국 에이전트 구조가 조직도랑 똑같이 복제된다는 거야(콘웨이의 법칙을 인용하더라고).
얘네가 나열한 실패 사례들은 큰 조직에서 일해본 놈들이라면 다들 공감할 거다. 업무 넘길 때마다 컨텍스트 다 날아가고, 주인 없는 서브 에이전트 수백 개가 굴러다니는 꼴이지. 팀마다 시스템 프롬프트에 문장 하나씩 추가하다 보니 나중엔 규칙끼리 서로 충돌하는 '프랑켄프롬프트(Frankenprompt)'가 돼버려. 팀별로 자기네 하위 작업에만 맞춘 평가 지표를 짜니까 전체 시스템 품질을 책임지는 놈은 아무도 없는 상황인 거지. 게다가 레이어가 늘어나면 지연 시간도 늘어나. Anthropic이 특정 고객사 이름을 밝히진 않았지만, 단일 루프로 바꿨더니 런타임이 대략 2배 빨라졌다는 사례도 있더라.
얘네가 제안하는 규칙은 문제 유형이 아니라 '컨텍스트' 단위로 쪼개라는 거야. 서브 에이전트는 시스템의 다른 부분과 의존성이 거의 없는 작업을 맡아서 깔끔한 결과물만 딱 던져줘야 한다는 거지. 문제 유형별로 쪼개면 넘길 때마다 정보가 왜곡되는데, 이걸 '전화 게임(telephone game)'이라고 표현하더라고.
이 글에서 내가 훔쳐오고 싶은 건 마이그레이션 방법이야. 일단 작은 규모의 엔드 투 엔드 평가(eval)부터 만들고(골든 샘플 10개만 있어도 시작하기 충분하대), 서브 에이전트 하나씩 프롬프트를 '스킬'로, API 호출을 '도구'로 바꿔서 시스템에 통합해 보는 거야. 그렇게 합쳤을 때 성능이 더 떨어질 때만 서브 에이전트로 남겨두라는 거지. 그리고 작업마다 여러 번 돌려보라고 하더라. 자기네 서브 에이전트 테스트에서도 두 번 중 한 번만 회귀 오류가 나타난 적이 있었거든.
이 비교 데이터는 Anthropic이 기업용 배포 환경에서 직접 뽑은 거라 원본 데이터는 공개 안 됐어. 그래도 병렬 작업이 필요하거나, 컨텍스트가 너무 비대해지거나, 도구 선택이 꼬이는 경우에는 여전히 서브 에이전트를 쓰는 게 낫다고 하네.
너네 멀티 에이전트 환경 돌리고 있으면, 서브 에이전트를 통합하려다 결국 남겨둬야 했던 이유가 뭐야? 아니면 통합하다가 뭐가 박살 났어? 그리고 평가(eval)는 한 팀이 전담해, 아니면 팀마다 각자 짜?
