개념
멀티에이전트(multi-agent)는 하나의 에이전트가 모든 일을 처리하는 대신, 역할이 다른 여러 에이전트를 두고 이들이 결과를 주고받으며 목표를 달성하게 하는 구성이다. 각 에이전트는 자기 몫의 지시와 도구, 그리고 자신만의 대화 기록을 갖는다.
이 구조를 쓰는 이유는 크게 두 가지다. 하나는 관심사의 분리다. 하나의 프롬프트에 조사·작성·검토 지침을 모두 욱여넣으면 지시끼리 충돌하고 모델의 주의가 흩어지지만, 역할별로 나누면 각 에이전트의 지시가 짧고 명확해진다. 다른 하나는 문맥의 분리다. 조사 과정에서 쌓인 방대한 중간 산출물을 최종 작성 에이전트가 전부 볼 필요는 없고, 요약된 결과만 넘기면 컨텍스트 윈도우를 아낄 수 있다.
에이전트를 엮는 방식은 대체로 두 갈래다. 하나는 총괄 에이전트가 하위 에이전트에게 작업을 배분하고 결과를 취합하는 위계형이고, 다른 하나는 정해진 순서대로 결과를 넘기며 처리하는 파이프라인형이다. 후자는 사실상 프롬프트 체이닝에 가깝고, 각 단계가 독립된 도구와 판단 권한을 가질 때 멀티에이전트라 부른다.
이 구조가 잘 맞는 작업에는 공통점이 있다. 하위 작업들이 서로 독립적이어서 동시에 진행할 수 있고, 각 결과를 합치는 방법이 분명해야 한다. 반대로 앞 단계의 판단이 뒤 단계를 계속 바꾸는 작업은 나눠 봐야 대기와 재작업만 늘어난다. 병렬로 쪼갤 수 있는가가 도입 여부를 가르는 첫 번째 기준이다.
쓰임새
리서치가 대표적이다. 여러 하위 에이전트가 서로 다른 출처를 동시에 조사하고, 총괄 에이전트가 그 결과를 모아 보고서를 쓴다. 각자 조사한 내용을 전문 그대로 넘기는 대신 요약해서 올리기 때문에, 총괄 에이전트는 훨씬 넓은 범위를 다루면서도 자기 컨텍스트 윈도우를 지킬 수 있다. 소프트웨어 개발에서는 코드를 작성하는 에이전트와 리뷰하는 에이전트를 분리해 한쪽이 놓친 문제를 다른 쪽이 잡게 하는 구성이 널리 쓰인다.
각 에이전트가 서로 다른 도구에 접근해야 하므로 MCP 같은 표준 도구 연결 규약과 함께 설계되는 경우가 많다. 에이전트 사이에 무엇을 주고받을지, 어느 시점에 사람의 승인을 받을지를 미리 정해 두는 것이 실무 설계의 핵심이다.
운영에서 가장 까다로운 부분은 관찰과 통제다. 여러 에이전트가 동시에 움직이면 어디서 잘못됐는지 추적하기 어렵고, 한 에이전트가 루프에 빠져 호출을 반복해도 눈에 띄지 않는다. 전체 호출 횟수와 시간에 상한을 두고, 각 에이전트가 주고받은 내용을 기록으로 남기는 장치가 함께 필요하다.
자주 하는 오해
에이전트를 늘리면 결과가 좋아지지 않나?
에이전트가 늘수록 호출 비용과 지연이 곱으로 늘고, 전달 과정에서 정보가 유실될 지점도 함께 늘어난다. 단일 에이전트로 안 되는 이유를 먼저 확인하지 않으면 비용만 커진다.
에이전트끼리 서로 검증하면 오류가 걸러지지 않나?
같은 모델을 쓰는 에이전트들은 같은 착각을 공유하기 쉽다. 검토 에이전트가 잘못된 결과를 그대로 통과시키는 일이 드물지 않아, 외부 도구로 사실을 확인하는 단계가 함께 필요하다.
역할만 나누면 각자 알아서 협업하지 않나?
무엇을 어떤 형식으로 주고받을지 명시하지 않으면 결과가 어긋난다. 에이전트 사이의 인터페이스를 구조화 출력으로 고정해 두는 편이 안정적이며, 각 에이전트가 무엇을 받고 무엇을 돌려줘야 하는지를 먼저 정한 뒤 프롬프트를 쓰는 순서가 낫다.