멀티에이전트가 무조건 정답은 아니다 — AI에게 직접 물어봤다

2026-07-05 · Ascendy Engineering

TL;DR

멀티에이전트를 더 붙일수록 좋아질 것 같지만, 무조건 정답은 아니다. 적합/부적합은 결국 한 질문으로 갈린다 — 병렬로 쪼갠 조각들이 서로의 암묵적 결정을 몰라도 되는가?
몰라도 되면(넓게 읽고 탐색하는 일) 멀티가 이긴다. 알아야 하면(하나로 일관되게 써내는 일) 오히려 독이 된다. 회의론(Cognition)과 옹호론(Anthropic)은 사실 같은 축의 양 끝이다.
그래서 “크로스-모델 검증”은 모순이 아니다 — 쓸 때는 컨텍스트를 모으고(single writer), 판단할 때는 떼어낸다(independent check). 정반대 성질을 이용하는 별개의 일이다.
늘릴수록 나빠지는 건 세 가지 세금 때문이다: 조율·컨텍스트 파편화·오류 복리. 어느 임계를 넘으면 8명 회의처럼 느려지고 틀린다.

이 글에 대하여. 이 글은 내가 AI에게 직접 묻고 AI가 답한 문답을 정리한 것이다(평소와 반대 방향의 인터뷰). 그래서 AI가 답에서 던진 현재-사실 주장(누가 뭘 냈다, 수치)은 발행 전에 web으로 검증해 링크를 달았고, 추론은 추론이라고 밝혀 둔다. 다루는 범위는 소프트웨어(LLM) 에이전트다. 같은 결의 loop engineering의 핵심은 검증, 설계한 게 아니라 위임했다와 이어진다.

한 질문으로 갈린다

멀티에이전트 얘기가 요즘 뜨겁다. 에이전트를 여럿 붙여 병렬로 돌리면 당연히 더 빠르고 똑똑해질 것 같다. 그래서 궁금했다 — 정말 늘 그런가? 그걸 AI와 한참 문답했고, 그 대화에서 건진 걸 정리한다.

첫 답부터 명쾌했다. 정답이냐 아니냐는 결국 한 질문으로 갈린다:

작업을 병렬 조각으로 쪼갰을 때, 그 조각들이 서로가 내린 판단을 몰라도 결과가 어긋나지 않는가?

몰라도 된다 → 멀티에이전트가 유리하다
알아야 한다 → 멀티에이전트가 오히려 독이다

이 한 줄이 이 글 전체의 척추다. 실제로 이 주제에서 유명한 두 입장 — 회의론 쪽 Cognition의 “Don’t Build Multi-Agents”와 옹호론 쪽 Anthropic의 멀티에이전트 리서치 시스템 — 은 정면으로 갈리는 것처럼 보이지만, 사실 같은 축의 양 끝이다.

적합한 조건과 아닌 조건

멀티가 이기는 쪽 — 넓게 읽는 일

Anthropic의 리서치 시스템이 딱 이 케이스다. 리드 에이전트가 3~5개 서브에이전트를 병렬로 띄워 각자 다른 각도로 검색하고, 압축 요약만 반환한다. 각 서브는 자기만의 컨텍스트 창을 갖고, 서로의 중간 상태를 알 필요가 없다. 넓게 읽고 훑는 일(breadth-first)이라 조각이 충돌하지 않기 때문이다.

성능은 실제로 나온다 — 그들 내부 평가에서 단일 Claude Opus 4 대비 90.2% 우위. 단, 대가가 있다. 토큰이 약 15배다. 그래서 Anthropic도 못박는다: 이 배수를 감당할 수 있는 건 법률 실사·경쟁정보·문헌 리뷰처럼 고부가가치 작업뿐이고, 일상 Q&A는 이 비용을 흡수하지 못한다.

정리하면 멀티가 유리한 세 조건은:

읽기 중심·탐색형. 넓게 훑어 정보를 모으는 일.
깔끔하게 분해되고, 조각이 서로 충돌하지 않을 때.
그 15배 비용을 흡수할 만큼 고부가가치일 때.

멀티가 지는 쪽 — 하나로 써내는 일

반대쪽 대표가 코드 작성이다. Cognition의 유명한 Flappy Bird 예시 — 한 서브에이전트는 마리오풍 배경을 만들고, 다른 서브는 게임 에셋과 안 맞는 새를 만든다. 둘 다 상대가 내린 암묵적 디자인 결정을 공유받지 못했기 때문이다. 합치면 프랑켄슈타인이 된다.

하나의 일관된 산출물을 만들어야 하거나, 앞 결정이 뒤에 영향을 주는 순차 작업이라면 — 컨텍스트를 잘게 쪼개는 순간 정보가 샌다. Cognition은 이걸 “context is fragile”이라 부르며, 단일 스레드 + (필요하면) 압축 전용 LLM을 권한다.

그래서 실전의 수렴점

재미있는 건, 회의론(Cognition)과 옹호론(Anthropic)이 실제 배포 형태에서는 오히려 한 모양으로 만난다는 점이다. 순진한 대칭형이 아니다:

지휘자(orchestrator) 하나가 전체 컨텍스트를 쥐고, 일회성 고립 서브에이전트를 정찰병처럼 띄워 압축 요약만 돌려받는다.

즉 여러 에이전트가 peer로 자유롭게 병렬 작업하는 순진한 멀티에이전트는 대체로 실패하고, 살아남은 건 “지휘자 1 + 소모성 정찰병 N”이다. 이건 싱글 에이전트의 확장이지, 대칭적 멀티에이전트가 아니다.

”크로스-모델 검증”은 모순 아닌가

여기서 반문이 나온다. 우리가 만든 오픈소스 redteam은 다른 계열의 모델이 결과를 교차 검증하는 구조를 쓴다. 그것도 에이전트가 하나 이상이니 — 멀티에이전트를 비판하면서 멀티에이전트를 쓰는 모순 아닌가?

전혀 아니다. 오히려 이 지점이 핵심인데, “멀티에이전트”라는 한 단어가 정반대 두 가지를 가리키기 때문이다.

	병렬 노동 (분업)	독립 검증 (교차)
무엇	쓰기를 쪼갬	결과를 다른 눈이 판정
공유 컨텍스트	필요 (없으면 깨짐)	없어야 함 (있으면 무의미)
실패 모드	Flappy Bird	자기 검토 = 고무도장

분업이 깨지는 지점은 쓰기 쪽이었다 — 병렬 작성자들이 서로의 암묵적 결정을 몰라서 프랑켄슈타인이 되는 것. 실패 원인은 컨텍스트 공유의 부재다.

그런데 크로스-모델 검증은 판단 쪽이고, 여기선 부호가 뒤집힌다 — 컨텍스트를 공유하지 않는 게 버그가 아니라 바로 그게 기능이다. 코드를 쓴 모델은 자기 코드에 고무도장을 찍는다. 자기가 내린 판단을 자기가 다시 봐도 같은 결론이 나오니까. 다른 계열의 모델은 그 판단에 동의할 이유가 없다. 검증의 값은 개수가 아니라 독립성에서 나온다.

그리고 redteam은 사실 Cognition이 옳다고 한 쪽에 서 있다. 파이프라인이 계획 → 구현 → 리뷰로 이어지는 순차 단계고, 한 태스크의 코드를 쓰는 건 한 명의 작성자다. 병렬 작성자로 쪼개지 않는다. Cognition이 권한 단일 스레드 선형 에이전트(single-threaded linear agent) — 한 작성자가 컨텍스트를 끝까지 쥐는 방식 — 그대로, 거기에 다른 모델의 독립 리뷰어를 얹었을 뿐이다.

그래서 규칙은 한 줄로 압축된다:

쓸 때는 컨텍스트를 모으고(single writer), 판단할 때는 떼어낸다(independent check).

“멀티에이전트 쓰냐 마냐”는 틀린 질문이다. 맞는 질문은 “지금 이 단계가 쓰기냐 판단이냐”고, 단계마다 답이 다르다.

늘리면 왜 어느 순간 오히려 나빠지나

그럼 왜 무작정 늘리면 안 되나. 에이전트를 늘릴 때 붙는 세 가지 세금이 있다. 처음엔 추가 에이전트의 이득이 세금보다 크지만, 어느 지점을 넘으면 세금이 이득을 잡아먹는다.

조율 세금. 에이전트가 늘수록 서로 맞춰야 할 접점이 늘어난다 — 순진하게 peer로 다 연결하면 소통 경로가 대략 n²로 폭증한다. 앞의 “지휘자 1 + 정찰병 N” 별 모양 구조는 정확히 이 n²를 n으로 낮추려는 설계다.
컨텍스트 파편화 세금. 각 서브에이전트는 자기 창만 본다. 전체를 끝까지 보는 존재가 아무도 없다. 정보는 압축 요약으로만 오가는데, 압축은 곧 손실이다. Flappy Bird가 바로 이 세금이 터진 사례다.
오류 복리 세금. 한 서브의 틀린 전제가 다른 서브 결과와 합쳐지며 증폭된다. 게다가 Anthropic이 관찰했듯, 에이전트가 단순 작업에 수십 개 서브를 띄우거나 끝없이 웹을 뒤지는 식으로 폭주하면, 그 15배 토큰 위에 낭비가 더 쌓인다. 비용도 오류도 복리로 터진다.

그래서 임계점은 이렇게 정의된다: 추가 에이전트가 주는 한계 이득이, 그가 주입하는 조율 + 파편화 + 오류 세금보다 작아지는 순간. 이 부등호가 뒤집히면 “느려지고 틀리기 시작한다.” 넓게 읽는 일은 그 임계가 높고(정찰병 5명까지 남는 장사), 하나로 써내는 일은 임계가 아주 낮다(2명만 돼도 이미 손해).

직관은 회의에 사람 더 넣기와 같다. 2명 회의보다 8명 회의가 항상 더 나은 결정을 내리지 못하는 이유 — 추가된 두뇌의 이득을 소통 오버헤드가 먹어버리기 때문이다. (비유다. 소프트웨어 인력의 Brooks’s Law와 같은 결이지만 엄밀한 인용은 아니고, 직관용이다.)

덤: “멀티에이전트”라는 단어의 함정

얼마 전 한 독자가 물었다 — “공장이나 설계처럼 생산 자동화가 기대되는 분야에선 아직 멀티에이전트를 고려하지 않는 것 같은데 어떤가요?” 나는 그 분야를 실제로 다뤄본 적이 없어 섣불리 답하지 않았지만, 이 질문 자체가 한 가지를 선명하게 드러낸다.

“멀티에이전트”는 완전히 다른 두 세계를 가리키는 단어다. 하나는 이 글이 다룬 LLM 멀티에이전트고, 다른 하나는 로봇 군집·분산 제어 같은 산업 제어의 Multi-Agent System(MAS) — 수십 년 된 별개 분야다. 같은 단어인데 성숙도가 정반대라, 같은 문장도 어느 세계를 뜻하느냐에 따라 답이 뒤집힌다.

그래서 이런 질문을 받으면, 답을 지어내기 전에 어느 쪽 멀티에이전트를 말하는지부터 확인하는 게 맞다. 모르는 분야를 아는 척하지 않는 것 — 그 자체가 이 시리즈가 지키려는 태도다.

가져갈 것

무조건 정답은 아니다. 적합/부적합은 “조각들이 서로의 암묵적 결정을 몰라도 되는가”로 갈린다. 읽기·탐색이면 멀티, 하나로 써내는 일이면 싱글(+긴 컨텍스트).
실전의 멀티는 대칭형이 아니다. “지휘자 1 + 소모성 정찰병 N” — 싱글의 확장이지 peer들의 자유 병렬이 아니다.
크로스-모델 검증은 모순이 아니다. 쓸 땐 컨텍스트를 모으고, 판단할 땐 떼어낸다. 검증의 값은 개수가 아니라 독립성이다.
늘릴수록 나빠지는 임계가 있다. 조율·파편화·오류 복리라는 세 세금이 추가 이득을 넘어서는 순간부터. 8명 회의를 떠올리면 된다.

솔직히 이 글의 대부분은 내가 아니라 AI가 답한 것이다. 다만 그 답을 검증하고, 어디까지가 사실이고 어디부터가 추론인지 가르는 것 — 그건 여전히 사람의 몫이었다. 어쩌면 그게 이 글이 던지는 가장 작은 실천 예시일지도 모른다.

저작·인용: 이 글은 Ascendy Engineering이 작성했으며 출처 표기 시 재인용 가능합니다. 잘못된 정보를 발견하면 GitHub 이슈로 알려주세요.

Tags: ai, agents, multi-agent, architecture, opinion, loop-engineering