멀티 에이전트 AI 시스템이 정말 더 나을까, 아니면 대부분의 실무에는 단일 에이전트로 충분할까?

프롬프트 외부에서 경계를 강제하지 않으면 흐릿해지기 마련임. 분리는 권한, 로그, 아티팩트에서 확실히 드러나야 함. 플래너가 글을 쓸 수 있고, 리뷰어가 행동할 수 있고, 워커가 몰래 스코프를 변경할 수 있다면, 결국 레이턴시만 늘어난 하나의 거대한 에이전트로 전락하게 됨. 더 깔끔한 패턴은 핸드오프할 때마다 작은 영수증을 남기는 거임: 의도된 행동, 허용된 툴, 사용된 증거, 건너뛴 가정, 승인 필요 여부 같은 것들. 그렇게 하면 기능이 추가될 때...

업무 인계 시 컨텍스트가 줄어든다는 점에 대해서는 약간 반대 의견입니다. 탄탄한 메모리가 있어도 단일 에이전트가 긴 세션 동안 작업을 수행하다 보면 초기 추론 내용이 압축되면서 컨텍스트 드리프트가 발생합니다. 메모리는 회상에는 도움을 주지만, 결정을 내리게 된 분기점을 보존하는 데는 항상 효과적이지는 않죠. 그 부분이 조용히 썩어 들어가는 경향이 있습니다.

기본적으로는 단일 에이전트로 시작할 겁니다.

강력한 도구, 좋은 로깅, 권한 관리, 재시도 로직, 깔끔한 커넥터 계층을 갖춘 잘 설계된 단일 에이전트는 보통 멀티 에이전트 설정보다 디버깅하기 쉽고, 저렴하며, 더 안정적입니다.

멀티 에이전트는 역할이 진정으로 다를 때(플래너, 실행자, 검증자, 연구자, 모니터 등)만 의미가 있다고 봅니다. 모든 에이전트가 같은 모델과 같은 컨텍스트를 감싼 껍데기에 불과하다면, 실질적인 이점 없이 오케스트레이션 복잡성만 더하는 경우가 많습니다.

대부분의 경우 단일 에이전트 + 지식 저장소/커스텀 도구 카탈로그로 해결할 수 있습니다. 컨텍스트 비대화를 막기 위해 도구를 에이전트별로 전문화해야 할 때만 멀티 에이전트가 필요하죠.

위임 기능이 있는 멀티 에이전트는 npcpy / npcsh를, 많은 도구를 가진 단일 에이전트는 incognide를 참고해 보세요.

업무 인계 경계를 명확히 정의할 수 없다면 단일 에이전트로 시작할 겁니다. 멀티 에이전트는 역할별로 서로 다른 권한, 컨텍스트, 검증 경로가 필요할 때 제값을 합니다. 모든 에이전트가 같은 대화 기록을 보고 같은 도구를 사용한다면, 보통은 더 복잡한 장애 모드와 함께 지연 시간만 늘어날 뿐입니다.

병렬 처리를 목적으로 하는 멀티 에이전트는 좋은 패턴입니다.

반면 역할극(role-playing) 용도로 멀티 에이전트를 쓰는 건 좀 멍청한 짓이죠.

좋은 도구를 갖춘 단일 에이전트는 병렬 작업 흐름이 서로를 차단하지 않고 독립적으로 실행되어야 하는 작업에 도달하기 전까지는 대부분 깔끔하게 처리합니다. 보통 그 지점이 진짜 임계점이죠. 하지만 멀티 에이전트의 복잡성 비용은 실재합니다. 디버깅이 빠르게 고통스러워지고, 대부분의 장애 모드는 개별 에이전트 내부가 아니라 조정 계층에서 나타나거든요.

정말 필요한 경우가 아니라면 멀티 에이전트 시스템을 만드는 수고는 절대 안 할 겁니다. 하려는 작업이 병렬이나 순차적으로 협력하는 여러 에이전트를 진정으로 필요로 한다면 어쩔 수 없겠지만요. 지금 저는 moclaw 에이전트와 claude 에이전트를 가지고 있지만, 둘은 완전히 다른 일을 하고 있고 서로 협력하지 않습니다(하나는 개인 콘텐츠 작성용, 다른 하나는 팀용).

멀티 에이전트 워크플로우가 필요했던 적은 없습니다.

다들 노동 분업에 대한 질문에 잘 답변하고 있네요. 명확한 인계 경계가 생길 때까지는 단일 에이전트로 가다가, 그 이후에 권한과 책임에 따라 분리하라는 거죠. 하지만 모델을 여러 개 실행해야 하는 이유는 두 가지인데, 이 스레드에서는 그걸 같은 단어로 뭉뚱그리고 있습니다.

첫 번째 이유는 노동 분업입니다. 플래너, 작업자, 검토자, 서로 다른 도구와 컨텍스트 등이죠. 이 스레드의 대부분이 이 내용이고, '단일로 시작하라'는 조언이 맞습니다.

두 번째 이유는 다양성입니다.