AGENT / 62번째 글

에이전트를 여럿으로 나눌 때와 나누지 말아야 할 때

에이전트를 여럿 세우면 그럴듯해 보이지만 대부분은 하나로 두는 편이 낫습니다. 나누는 방식 네 가지의 모양과 값, 나눌 이유가 있는지 판단하는 세 질문, 그리고 나눈 뒤에 생기는 새로운 실패를 정리합니다.

PALDYN Team2026.08.2212 MIN READ

지난 글까지는 에이전트 하나가 무엇을 어떻게 하는지를 봤다. 이 글은 그 위의 질문이다 — 에이전트를 여럿 세우는 것이 언제 이득인가.

먼저 결론부터 적어 두는 편이 낫겠다. 대부분의 경우 하나로 두는 것이 낫다. 도구 여섯 개를 든 에이전트 하나가 잘 도는 자리를, 「기획 에이전트·조사 에이전트·작성 에이전트·검토 에이전트」로 나누면 토큰은 세 배가 되고 지연은 두 배가 되며 고장 날 수 있는 자리가 넷으로 는다. 그렇게 해서 결과가 나아지는 경우가 생각보다 드물다.

그렇다고 언제나 하나가 옳은 것도 아니다. 나누면 확실히 이기는 자리가 있고, 그 자리를 알아보는 것이 이 글의 목적이다.

모양은 넷뿐이다

프레임워크마다 이름이 다르고 그림이 화려하지만, 실제 배치는 넷 중 하나이거나 그 조합이다.

나누는 방식은 넷뿐이다

모양	무엇이 좋은가	무엇을 대가로 내는가
① 하나로 둔다	문맥이 하나라 아는 것이 새지 않는다. 가장 싸고 빠르다	도구가 너무 많아지면 고르기를 틀린다
② 관리자와 일꾼	일꾼마다 도구가 적어 정확해지고, 동시에 돌릴 수 있다	관리자가 일을 잘 쪼개야 하고, 쪼갠 만큼 문맥이 갈린다
③ 줄지어 넘긴다	단계마다 다른 모델·다른 설정을 쓸 수 있다	앞 단계의 실수가 뒤로 그대로 흘러간다
④ 서로 검토한다	혼자서는 못 보는 실수를 잡는다	값이 몇 배로 뛴다. 그리고 서로 동의만 하고 끝나기도 한다

①이 기본값이라는 점을 다시 짚어 둔다. 「멀티 에이전트」라는 말이 붙은 구조를 만들기 전에, 지금 하나로 안 되는 이유를 한 문장으로 적을 수 있어야 한다.

②는 실무에서 가장 자주 이득을 보는 모양이다. 특히 동시에 돌릴 수 있는 일이 있을 때 그렇다 — 세 회사의 최근 실적을 각각 조사하는 일은 서로 기다릴 이유가 없으므로, 셋을 동시에 던지면 지연이 3분의 1이 된다. 병렬 함수 호출에서 도구 하나짜리로 다룬 것을 에이전트 단위로 키운 셈이다.

③은 순서가 이미 정해져 있을 때 쓴다. 그런데 순서가 정해져 있다면 그것을 굳이 에이전트로 둘 이유도 없는 경우가 많다. 정해진 순서로 흐르는 것은 파이프라인이지 에이전트가 아니다 — 모델을 부르는 함수 셋을 순서대로 부르면 된다. 에이전트라는 이름을 붙이면 그 단계마다 「무엇을 할지 고르는」 판단이 끼어들고, 이미 순서를 아는 자리에서 그 판단은 비용이기만 하다.

④는 값이 가장 비싸고 효과가 가장 들쭉날쭉하다. 잘 쓰이는 자리는 틀렸을 때 비싼 일이다 — 계약서 검토, 마이그레이션 계획, 보안 설정 변경처럼 한 번 틀리면 되돌리기 어려운 것. 반대로 「글을 더 잘 써 줘」류의 일에서는 두 에이전트가 서로 칭찬만 하고 끝나기 쉽다. 에이전트 자기 검토에서 다룬 문제가 여럿으로 늘어난 형태다.

나눌 이유가 있는지 묻는 세 질문

구조를 고르기 전에 나눌 이유부터 확인한다.

나눌 이유가 있는가

첫째, 도구가 너무 많은가. 도구 목록이 스물을 넘어가면 모델이 비슷한 것 사이에서 헷갈리기 시작한다. 「주문 조회」와 「배송 조회」와 「결제 조회」가 나란히 있으면 셋 중 아무거나 부른다. 이때 나누는 것은 진짜 이득이다 — 각 일꾼이 서너 개만 들면 고르기가 쉬워진다. 다만 순서를 지키자면, 도구 스키마를 정리하는 것이 먼저다. 도구 스키마 설계로 해결되는 혼동을 구조 변경으로 푸는 것은 비싸다.

둘째, 서로 기다리지 않아도 되는 일이 여럿인가. 이건 가장 정직한 이유다. 병렬로 돌 수 있는 일을 병렬로 돌리면 지연이 실제로 줄고, 줄어드는 양을 미리 계산할 수도 있다. 논쟁의 여지가 없는 이득이다.

셋째, 다른 눈으로 다시 봐야 하는가. 검토를 따로 세우는 것은 비용을 내고 정확도를 사는 거래다. 그 거래가 남는지는 틀렸을 때의 값이 정한다. 틀려도 사람이 금방 알아채고 고치면 되는 일이면 안 남고, 틀린 채로 나가면 큰일 나는 일이면 남는다.

셋 다 「아니오」인데 나눈 구조라면, 얻는 것 없이 비용과 실패 지점만 늘린 것이다.

나누면 새로 생기는 문제

나누기로 정했다면, 하나였을 때는 없던 문제 셋이 따라온다.

문맥이 갈린다. 하나였을 때는 앞에서 알아낸 것이 그냥 문맥에 남아 있었다. 나누면 일꾼 B는 일꾼 A가 무엇을 알아냈는지 모른다. 그래서 넘겨줄 것을 골라 정리해 넘겨야 하고, 여기서 새는 것이 결과 품질을 그대로 깎는다. 다음 글에서 이 주제를 따로 다룬다.

비용이 문맥 복사만큼 는다. 일꾼 셋에게 각각 배경을 설명하면 그 배경이 세 번 입력 토큰이 된다. 일꾼이 늘수록 곱해진다. 프롬프트 캐싱으로 공통 앞부분을 재사용하면 이 곱셈을 상당히 눌러 둘 수 있다 — 여러 일꾼이 같은 시스템 프롬프트로 시작하는 구조라면 특히 그렇다.

어디서 틀렸는지 찾기 어려워진다. 하나짜리는 대화 기록 하나만 보면 됐다. 넷이면 네 갈래를 맞춰 봐야 하고, 「관리자가 일을 잘못 쪼갠 것」과 「일꾼이 잘못한 것」을 구분하는 데 시간이 든다. 나누기로 했다면 각 호출에 같은 작업 아이디를 붙여 한 줄로 따라갈 수 있게 해 두는 일이 선택이 아니라 필수가 된다. LLM 운영 관측 쪽 이야기다.

관리자를 세울 때의 실무

②를 고른 경우에 가장 자주 어긋나는 자리를 적어 둔다.

일꾼에게 목표가 아니라 일감을 준다. 「이 주제를 알아봐 줘」가 아니라 「이 회사의 2025년 매출과 영업이익을 사업보고서에서 찾아 숫자와 출처를 함께 돌려줘」. 목표를 주면 일꾼이 다시 계획을 세우고 그만큼 흔들린다
돌려받을 모양을 정해 둔다. 일꾼의 출력이 자유 서술이면 관리자가 그것을 다시 해석해야 한다. 구조화 출력으로 모양을 고정해 두면 합치는 쪽이 훨씬 조용해진다
일꾼은 상태를 갖지 않게 한다. 한 번 부르고 결과를 받고 끝나는 형태가 다루기 쉽다. 일꾼이 여러 턴을 살면 관리자가 그 상태까지 관리해야 한다
일꾼 수에 상한을 둔다. 관리자가 일감을 스스로 쪼개게 두면 열두 개를 만들어 내는 날이 온다. 상한을 코드로 걸고, 넘으면 관리자에게 다시 추리게 한다
실패를 관리자가 알게 한다. 일꾼 하나가 못 찾았을 때 그것을 「없음」으로 조용히 처리하면 관리자는 다 찾은 줄 안다. 못 찾은 것은 못 찾았다고 돌려받는다