AI 클론으로 사무실을 차린다고요? 멀티에이전트가 관료제까지 복제하는 순간

요즘 AI 에이전트 판에서 제일 자주 보이는 그림이 있습니다. 매니저 에이전트 하나가 맨 위에 앉고 그 아래로 리서처, 코더, 리뷰어, QA 에이전트가 줄줄이 붙어 있는 조직도 말이죠. 이름도 그럴싸합니다. “당신의 AI 클론으로 사무실을 운영하세요.” 그런데 이 그림을 볼 때마다 걸리는 게 하나 있습니다. 우리가 지금 복제하는 게 생산성일까요, 아니면 회의(會議)일까요.

미리 밝혀둘 게 있습니다. 이번 주제는 커뮤니티 데이터가 충분히 잡히지 않았습니다. 최근 30일 기준으로 확인된 관련 스레드가 사실상 없었습니다. 그래서 이 글은 특정 프로젝트를 두고 나온 반응 정리라기보다, 지난 1년간 멀티에이전트를 둘러싸고 반복돼 온 논쟁 구조를 짚는 쪽에 가깝습니다. 그 점은 감안하고 읽어주세요.

‘사무실 은유’가 매력적인 이유

멀티에이전트 하네스가 사람을 끌어당기는 건 은유가 너무 직관적이라서입니다. 회사는 원래 한 명이 다 못 하는 일을 나눠서 합니다. 그러니 AI도 나눠서 시키면 되겠지. 이 추론은 자연스럽습니다.

기술적인 근거도 있습니다. 컨텍스트 윈도우는 유한하고 긴 작업에서 모델은 중간 정보를 흘립니다. 서브에이전트를 쓰면 각자 컨텍스트를 따로 쓰고 부모 에이전트에게는 결론만 올려보냅니다. 파일 100개를 뒤지는 지저분한 과정이 메인 대화로 쏟아지지 않습니다. 이게 서브에이전트의 진짜 효용이고 실제로 잘 작동합니다.

병렬로 돌리는 것도 그렇습니다. 서로 의존하지 않는 다섯 개 작업이 있으면 다섯 명을 동시에 돌리는 게 당연히 빠릅니다. 여기까지는 딱히 논쟁거리가 없습니다.

그런데 왜 회의론이 사라지지 않을까

문제는 사무실 은유를 끝까지 밀어붙일 때 생깁니다. 회사가 한 명보다 나은 이유는 분업 때문만이 아닙니다. 사람은 맥락을 공유하고 애매하면 옆자리에 물어봅니다. 어제 뭘 정했는지도 기억합니다. 에이전트 조직도에는 이 인프라가 없습니다.

대신 있는 건 텍스트뿐입니다. 매니저가 워커에게 프롬프트를 던지면 워커가 요약을 돌려주고, 매니저는 그걸 다시 요약해 다음 워커에게 넘깁니다. 단계마다 정보가 깎입니다. 사람 조직에서 부장이 팀장한테 전달하고 팀장이 사원한테 전달하다 원래 요구사항이 뭐였는지 아무도 모르게 되는 그 현상. 그게 토큰 단위로 재현됩니다.

비용도 정직하게 따져야 합니다. 매니저 하나에 워커 다섯이면 대화가 여섯 개 굴러가고 각자 시스템 프롬프트와 도구 정의를 들고 있습니다. 같은 파일을 세 에이전트가 각각 읽으면 그 토큰은 세 번 청구됩니다. 체감상 단일 에이전트보다 몇 배가 나와도 이상한 일이 아닙니다.

진짜 갈림길은 “합칠 수 있는 일인가”

겪어보면 멀티에이전트가 이기는 조건은 꽤 좁습니다. 질문은 하나입니다. 각자가 낸 결과를 기계적으로 합칠 수 있는가.

합쳐지는 일은 이렇습니다. 파일 200개에서 특정 패턴 찾기. 서로 다른 관점으로 코드 리뷰하고 발견 목록 합치기. 같은 설계 문제에 독립적인 안 세 개를 내고 비교하기. 여기서는 병렬이 곧 이득입니다. 각 에이전트가 서로를 몰라도 되니까요.

안 합쳐지는 일도 있습니다. 기능 하나를 여러 에이전트가 나눠서 구현하는 경우죠. 인터페이스 하나만 어긋나도 통합 단계에서 다 무너집니다. 그럼 누가 고치냐. 결국 매니저가 전부 읽어야 합니다. 처음부터 혼자 했으면 안 겪었을 일입니다.

그래서 실무에서는 이런 감각이 생겼습니다. 탐색은 나눠서, 결정은 모아서. 넓게 훑는 건 병렬로 던지고 실제로 코드를 고치는 건 컨텍스트를 온전히 쥔 하나가 맡습니다.

오케스트레이션이 어려운 게 아니라, 검증이 어렵다

멀티에이전트 프레임워크를 쓰다 보면 알게 되는 게 있습니다. 에이전트를 띄우는 건 쉽습니다. 어려운 건 결과를 믿을 수 있느냐입니다.

에이전트 다섯이 각각 “완료했습니다"라고 보고했다고 칩시다. 그중 둘은 사실 아무것도 안 했을 수 있습니다. 그럴듯한 요약만 올린 거죠. 사람 조직이라면 신뢰와 평판으로 거릅니다. 에이전트에게는 그런 게 없습니다. 그래서 잘 만든 하네스일수록 검증 장치가 두껍습니다. 구조화된 출력을 강제하고 발견한 내용은 다른 에이전트가 반박해보게 합니다. 다수결로 살아남은 것만 채택합니다.

여기까지 오면 사무실 은유가 좀 다르게 보입니다. 우리가 만드는 건 스스로 판단하는 동료 팀이 아니라 검증 파이프라인에 가깝습니다. 파이프라인은 조직도보다 훨씬 덜 낭만적이지만 훨씬 잘 돌아갑니다.

그래서 값비싼 농담일까요

절반은요. “AI 클론으로 사무실 운영"이라는 프레이밍 자체는 마케팅에 가깝습니다. 조직도를 흉내 내는 순간 조직의 비효율까지 딸려 옵니다. 회의가 생기고 전달하다 내용이 새고 책임은 흩어집니다. 인간 관료제가 비효율적인 건 인간이 느려서가 아니라 조정 비용이 커서인데, 에이전트에게도 조정 비용은 그대로 붙습니다.

나머지 절반은 진지합니다. 컨텍스트 격리와 병렬 탐색에는 실제 효용이 있습니다. 이건 은유가 아니라 공학입니다. 다만 그 효용을 얻는 데 필요한 건 조직도가 아니라 결정론적 제어 흐름입니다. 누가 무엇을 하고 결과를 어떻게 합치고 어디서 검증하는지를 코드로 못 박아야 합니다. 모델에게 “알아서 팀을 꾸려봐"라고 맡기는 게 아니라요.

멀티에이전트를 붙이기 전에 스스로에게 물어볼 건 이겁니다. 나는 지금 병렬로 나눌 수 있는 일이 있어서 여러 명을 쓰는 걸까, 아니면 여러 명을 쓰는 그림이 멋있어서 일을 억지로 나누고 있는 걸까. 여기에 바로 답이 안 나온다면, 아직은 잘 만든 에이전트 한 명이 더 빠릅니다.