일이 복잡해지면 Agent를 역할별로 나누고 싶어집니다. 검색 담당, 글쓰기 담당, 검토 담당처럼 팀을 꾸리는 그림이 그럴듯해 보이기 때문입니다. 그런데 Agent가 늘면 모델을 부르는 횟수와 토큰(token, 모델이 읽고 쓰는 글자 조각의 단위)도 함께 늘어 비용이 불어납니다.
Anthropic은 Agent가 챗보다 약 4배, 여러 Agent가 함께 일하는 Multi-Agent 시스템은 챗보다 약 15배 토큰을 쓴다고 밝혔습니다. 일을 하나 골라 어느 쪽이 맞는지 보세요.
막대 높이는 Anthropic이 공개한 토큰 사용량 비율(챗 1배, Agent 약 4배, Multi-Agent 약 15배)입니다. 일마다 어느 막대가 맞는지는 이 글이 정리한 판단입니다.
모델은 한 번에 읽을 수 있는 양이 정해져 있고 그 범위를 컨텍스트 창(context window)이라고 부릅니다. 한 Agent가 도구 서른 개의 설명을 모두 들고 있으면 창이 복잡해지고 알맞은 도구를 고르기도 어려워집니다.
LangChain은 Multi-Agent를 고려할 이유로 한 창에 다 담기 어려운 전문 지식, 도구가 너무 많아 잘못 고르는 문제, 하위 작업을 동시에 돌릴 수 있는 경우, 팀별 독립 개발, 조건이 맞아야 열리는 기능을 듭니다. 나눈 Agent는 자기 일에 필요한 것만 들고 있다가 결과 요약만 위로 올립니다.
LangChain은 Multi-Agent 방식을 Subagents, Handoffs, Skills, Router, Custom workflow 다섯 가지로 정리합니다. 이름은 달라도 모두 같은 질문에 답합니다. 누가 제어권을 쥐고 있고 사용자와는 누가 말하느냐입니다.
하나씩 눌러 모양과 잘하는 일, 약한 일을 보세요. 약한 점은 공식 문서에 적힌 것만 옮겼습니다.
LangChain은 같은 일을 네 방식으로 돌려 모델 호출 수를 비교한 표를 공개합니다. 한 번만 시킬 때는 Handoffs와 Skills와 Router가 3번으로 적게 들고 Subagents는 4번입니다. 같은 사용자가 이어서 두 번 요청하면 상태를 기억하는 Handoffs와 Skills가 5번으로 가장 적습니다.
여러 분야를 한꺼번에 묻는 경우에는 Subagents와 Router가 약 9천 토큰으로 가장 적고 Skills는 약 1만 5천 토큰입니다. 일의 모양에 따라 순위가 바뀝니다. 상황을 눌러 보세요.
우선 하나로 충분한지 따져 봅니다. LangChain은 도구와 프롬프트를 잘 갖춘 Agent 하나가 비슷한 결과를 내는 경우가 많다고 말합니다. Anthropic은 모든 Agent가 같은 맥락을 나눠 써야 하거나 서로 의존이 많은 일은 지금의 Multi-Agent에 잘 맞지 않는다고 말합니다.
그래도 나눠야 한다면 일의 모양으로 고릅니다. 해당하는 것을 켜 보세요. 공식 문서가 적은 강점과 약점을 겹쳐 본 것이라 참고용입니다.
다음 글에서는 가장 널리 쓰는 두 방식, 일을 맡기는 Subagents와 제어권을 넘기는 Handoffs를 직접 구현해 보겠습니다.