멀티에이전트 시스템 정리: 언제 쓰고 언제 쓰지 말아야 하나, 네 가지 구조 비교

핵심 메시지

• 토큰을 더 많이 쓸수록 성능이 오르지만 컨텍스트가 차오르면 성능이 떨어지는 모순을 푸는 한 가지 방법이 멀티에이전트다.
• 순차적으로 이어지는 작업은 단일 에이전트가, 병렬로 쪼갤 수 있는 작업은 멀티에이전트가 유리하다.
• 구글 연구진의 기준에 따르면 단일 에이전트가 45%보다 자주 성공한다면 조율 비용을 감당할 이유가 없다.
• 에이전트를 5개로 늘리면 비용은 5배가 아니라 그 이상 늘어난다. 서로 대화하는 데도 연산이 들기 때문이다.
• 구조보다 어려운 것은 하네스, 즉 에이전트를 둘러싼 테스트·공유 컨텍스트·작업 목록 같은 소프트웨어를 짜는 일이다.

쉽게 이해하기

쇼 탈레비는 2025년을 단일 AI 에이전트가 쓸 만해진 해로 규정하며 이야기를 시작한다. 그 배경에는 토큰을 더 많이 생성할수록 성능이 좋아진다는 테스트타임 컴퓨트 스케일링 원리가 있다. 오래 생각하고 도구를 더 많이 호출할수록 작업을 잘 해내니, 업계의 관심은 모델을 키우는 쪽에서 모델이 더 많이 생성하게 하는 쪽으로 옮겨 갔다.

문제는 컨텍스트 창이 유한하다는 점이다. 100만 토큰이 넘는 창을 갖더라도 창이 차오를수록 성능이 떨어지는 이른바 컨텍스트 로트 현상이 나타난다. 그는 크로마DB 연구진이 프런티어 모델들에게 단어를 그대로 반복하는 단순한 과제를 시켰을 때조차 창이 찰수록 성능이 뚜렷이 떨어졌다는 결과를 근거로 든다. 토큰을 늘려야 하는데 늘리면 나빠지는 이 긴장을 여러 에이전트에게 일을 나눠 푸는 것이 멀티에이전트의 출발점이다.

그렇다고 만능은 아니다. 판단 기준으로 그는 세 가지를 제시한다. 첫째, 작업이 순차적인가 분해 가능한가다. 문서를 찾아보고, 그걸로 계획을 세우고, 계획대로 코딩하는 일은 순서를 건너뛸 수 없으니 단일 에이전트가 낫다. 반대로 여러 RAG 라이브러리를 각각 조사하는 리서치는 나눠서 동시에 시키고 나중에 합치면 된다. 둘째, 구글 연구진의 결과를 인용해 단일 에이전트 성공률이 45%를 넘으면 조율 비용을 정당화할 만큼의 성능 향상이 없다고 말한다. 셋째, 비용이 가장 중요한 제약이라면 단일 에이전트가 답이다.

이어 그는 네 가지 구조를 비교한다. 독립형은 같은 요청을 여러 인스턴스에 던지고 투표하거나 가장 나은 결과를 고르는 방식이다. 구현이 단순하지만 서로 대화하지 않아 오류를 바로잡을 기회가 없고, 같은 구글 논문에서는 단일 에이전트 대비 오류가 17배로 늘었다고 한다. 분산형은 위계 없이 서로 대화하는 무리다. 앤트로픽 쪽 사례로 16개 에이전트가 2주 동안 돌며 러스트로 약 10만 줄짜리 C 컴파일러를 만든 이야기를 소개하는데, API 비용은 2만 달러가 들었고 벤치마크 정확도는 99%였으며 둠(Doom)도 돌렸다고 한다.

중앙집중형은 리드 에이전트가 하위 에이전트에게 일을 나눠 주는 구조다. 하위 에이전트의 실수가 곧바로 전파되지 않고 리드가 검증하기 때문에 오류 증폭이 가장 적었다. 마지막 하이브리드는 리드가 감독하되 하위 에이전트끼리도 대화할 수 있게 한 절충안으로, 그는 클로드 코드가 새로 내놓은 에이전트 팀 기능이 정확히 이 구조라고 설명한다. 가장 복잡하고 조율 비용도 가장 크다는 대가가 따른다.

주요 인사이트

• 멀티에이전트는 단일 에이전트의 상위 호환이 아니다. 탈레비의 표현대로 파레토 개선이 아니어서, 작업이 분해 가능할 때만 값어치를 한다.
• 에이전트를 늘릴 때 비용은 선형이 아니라 초선형으로 증가한다. 에이전트끼리 대화하는 데 드는 연산이 따로 붙기 때문이다.
• 구조 선택은 작업의 성격을 따라간다. 폭넓은 탐색이 필요한 일에는 분산형이, 하나의 목표를 일관되게 밀고 가야 하는 일에는 중앙집중형이 맞았다.
• 지금 통용되는 경험칙들은 모델 세대가 바뀌면 낡을 수 있다. 45%나 17배 같은 수치는 현 세대 모델을 기준으로 관측된 값이다.
• 먼저 단일 에이전트로 만들어 성능을 측정해 보라는 것이 그의 권고다. 기준선이 있어야 멀티에이전트로 넘어갈지 판단할 수 있다.

자주 묻는 질문

관련 AI 소식