오케스트레이터-워커 2편: 멀티에이전트는 왜 실패하나

Show Notes

오케스트레이터-워커 2부작 2편. MAST 실패 분류의 3범주와 주요 실패 유형, 같은 모델로 설계만 바꾼 개입 실험을 살펴보고, Cognition의 "나누지 마라" 반론과 Anthropic 멀티에이전트 리서치 결과를 읽기 중심과 쓰기 중심 작업으로 정리합니다. 단일 에이전트와 멀티에이전트를 고르는 판단 기준으로 마무리합니다.

전체 대본 보기

참고 자료

• Cemri et al., Why Do Multi-Agent LLM Systems Fail? (arXiv 2503.13657v3, NeurIPS 2025 Datasets and Benchmarks)
• Walden Yan (Cognition), Don't Build Multi-Agents (2025-06-12)
• Anthropic, How we built our multi-agent research system (2025-06-13)
• Kim et al., Towards a Science of Scaling Agent Systems (arXiv 2512.08296v3)
• shalomeir, 멀티 에이전트 오케스트레이션은 왜 잘 안 되는가? (2026-04-07)

이 에피소드의 음성은 TTS로 합성되었습니다.

What is kalee's 공부방?

kalee 가 공부하고자 하는 내용들을 두서없이 업로드하는 팟캐스트

진행자: 안녕하세요. 오케스트레이터-워커 2부작의 두 번째 시간입니다. 지난 1편에서는 "오케스트레이터-워커를 굴리는 다섯 가지 규칙"을 다뤘죠. 비싼 모델을 어디에 두고, 언제 멈추고, 누가 검증하고, 상태를 어디에 두고, 언제 사람을 부를지요.

진행자: 오늘은 그 반대편 얘기를 해 보려고 합니다. 규칙을 세워도 멀티에이전트는 자주 실패해요. 왜 실패하는지, 그리고 애초에 나눠야 하는 일과 나누면 안 되는 일을 어떻게 가르는지요.

전문가: 네. 오늘 질문은 두 개로 정리할 수 있어요. 실패 원인이 모델 성능이냐 설계냐. 그리고 작업을 나눠도 되는 경우와 안 되는 경우를 무엇으로 구분하느냐.

진행자: 재료는 뭘로 하나요?

전문가: 크게 네 가지예요. 첫째는 UC Berkeley 연구진이 낸 MAST라는 실패 분류 논문이에요. 둘째는 Cognition이 쓴 "Don't Build Multi-Agents", 멀티에이전트를 만들지 말라는 글이고요. 셋째는 Anthropic이 자기네 리서치 기능을 멀티에이전트로 만든 경험을 정리한 글, 넷째는 Google Research와 MIT 연구진이 에이전트 구조를 비교한 논문이에요.

전문가: 여기에 한국 실무자 한 분의 경험담도 곁들일 건데, 그건 일화로 들어 주시면 됩니다.

진행자: 먼저 MAST부터요. 이게 뭐의 약자예요?

전문가: Multi-Agent System Failure Taxonomy, 멀티에이전트 시스템 실패 분류예요. 여러 에이전트가 같이 일하는 시스템이 어떤 식으로 망가지는지를 열네 가지 유형, 세 가지 범주로 나눈 거죠.

진행자: 데이터는 어디서 왔어요?

전문가: ChatDev, MetaGPT, AG2, Magentic-One 같은 오픈소스 프레임워크 7개를 돌린 실행 기록이에요. 분류를 처음 만들 때는 기록 150여 건을 전문가 여섯 명이 직접 읽었어요. 기록 하나가 평균 1만 5천 줄이 넘는다고 하니까 꽤 고된 작업이었죠.

전문가: 그렇게 만든 분류로 세 명이 따로 주석을 달았을 때 일치도가 카파 0.88이었어요.

진행자: 카파는 주석자끼리 얼마나 일치하는지 보는 지표죠?

전문가: 네, 코헨 카파요. 우연히 맞을 몫을 빼고 얼마나 일치했는지 보는 지표인데, 0.88이면 높은 편이에요. 같은 실패를 보고 사람마다 다른 유형을 붙이지 않았다는 뜻이죠.

전문가: 최종 데이터셋은 실행 기록 1,642건인데, 이건 사람이 다 읽은 게 아니라 LLM-as-a-Judge 방식으로 주석을 달았어요.

진행자: LLM-as-a-Judge는 LLM을 심사관으로 쓴다는 거죠.

전문가: 맞아요. o1 모델에게 분류 정의와 예시를 주고 기록을 판정하게 했어요. 사람 판정과 비교하면 정확도 94%, 카파 0.77이 나왔고요.

진행자: 하나 짚고 가면, 대상 모델이 좀 지난 세대죠?

전문가: 네. GPT-4 계열, Claude 3.7 Sonnet, Qwen2.5-Coder, CodeLlama 같은 모델이고, 운영 환경이 아니라 오픈소스 프레임워크에서 나온 기록이에요.

전문가: 그래서 저는 숫자 하나하나보다는 실패가 어떤 모양인지를 보는 데 쓰는 게 맞다고 생각해요.

전문가: 참고로 실패율 자체는 시스템마다 41%에서 86.7%까지 퍼져 있었어요. 다만 시스템마다 벤치마크가 달라서 서로 비교하면 안 된다고 논문이 직접 밝혀요.

진행자: 그럼 본론으로 가 보죠. 열네 가지를 한 번에 들으면 머리에 안 남을 것 같은데, 큰 묶음부터 알려 주세요.

전문가: 세 묶음이에요. 시스템 설계 문제가 44.2%, 에이전트 간 불일치가 32.3%, 작업 검증 실패가 23.5%예요. 논문 첫 그림에 실린, 1,642건 기준 수치예요.

전문가: 하나 조심할 게 있어요. 41.8, 36.9, 21.3% 같은 숫자를 인용하는 글도 있는데, 같은 논문 안에서 시스템별로 첫 30건씩, 210건만 그린 다른 그림의 숫자예요. 오늘은 전체 1,642건 기준만 씁니다.

진행자: 설계 문제가 거의 절반이네요. 설계 문제 안에는 뭐가 있어요?

전문가: 다섯 가지예요. 제일 큰 게 단계 반복, 15.7%로 열네 가지 중 1위예요. 이미 끝낸 단계를 또 하는 거죠. 그다음이 종료 조건 모름 12.4%, 작업 명세 위반 11.8%예요. 대화 이력 손실 2.8%, 역할 명세 위반 1.5%는 작고요.

진행자: 종료 조건 모름은 1편에서도 나왔죠. 노력 예산 얘기할 때요.

전문가: 네, 같은 얘기예요. 언제 끝내야 하는지 모르면 돌고 또 돌아요. 제 눈에는 단계 반복이랑 한 쌍처럼 보여요.

진행자: 그런데 작업 명세 위반은 모델이 지시를 안 따른 거 아니에요? 그건 모델 문제 같은데요.

전문가: 논문도 그 질문을 정면으로 다뤄요. ChatDev에 Wordle 게임을 만들라고 했더니 고정된 단어 목록을 썼어요. 그래서 "고정 단어장 없이 매일 새 단어를 골라라"라고 더 분명히 써 줬는데도 또 고정 목록을 쓰고, 새 오류까지 생겼어요.

전문가: 논문은 이걸 지시를 해석하는 시스템 설계 쪽 문제로 봐요. 원인을 셋으로 나누는데, 에이전트 역할과 흐름 설계의 결함, 사용자 프롬프트의 모호함, 그리고 모델 자체의 한계예요. 모델 한계도 원인 중 하나라고 인정은 하는 거죠.

진행자: 두 번째 묶음, 에이전트 간 불일치는요?

전문가: 여섯 가지예요. 제일 큰 게 추론과 행동의 불일치, 13.2%예요. 생각은 A라고 해 놓고 행동은 B를 하는 거죠. 그다음 작업 이탈 7.4%, 모르는 걸 되묻지 않고 잘못된 가정으로 밀고 가는 게 6.8%예요. 대화 리셋과 다른 에이전트 입력 무시는 2% 안팎이고, 정보 숨김은 1%가 안 돼요.

진행자: 정보 숨김이 1%도 안 되면 굳이 얘기할 필요가 있나요?

전문가: 비율은 작은데, 논문이 대표 예로 그림까지 그린 게 이거예요. 전화 앱 담당 에이전트가 "사용자 이름은 전화번호여야 한다"는 API 요구 사항을 위에 전하지 않았어요. 감독 에이전트는 감독 에이전트대로 되묻지 않았고요. 결국 로그인만 계속 실패했죠.

전문가: 겉으로는 똑같이 정보가 빠진 걸로 보여도, 숨긴 건지, 받은 걸 무시한 건지, 문맥을 잃은 건지 원인이 다를 수 있다는 게 논문의 지적이에요. 그래서 유형을 잘게 나눴다는 거고요.

진행자: 이건 메시지 형식을 표준화하면 해결되는 거 아니에요?

전문가: 논문은 그걸로는 부족하다고 봐요. 같은 프레임워크 안에서 자연어로 대화해도 이 실패가 났거든요. 다른 에이전트가 무슨 정보를 필요로 하는지 헤아리지 못하는 문제라서, 논문은 이걸 마음 이론의 붕괴라고 불러요.

진행자: 세 번째 묶음이 검증이죠.

전문가: 세 가지예요. 잘못된 검증 9.1%, 검증을 안 하거나 덜 한 게 8.2%, 조기 종료가 6.2%예요.

전문가: 예가 인상적인데요. ChatDev가 만든 체스 프로그램이 컴파일 같은 표면 검사는 통과했어요. 그런데 실제 체스 규칙대로 동작하는지는 확인하지 않아서 실행하면 버그가 났어요. 리뷰 단계가 있었는데도요.

전문가: 논문이 기록을 읽어 보니, 검증 에이전트 상당수가 철저히 검증하라는 지시를 받고도 컴파일되는지, TODO 주석이 남았는지 정도만 봤대요.

진행자: 그래도 검증자를 두면 낫긴 하죠?

전문가: 명시적인 검증 단계가 있는 MetaGPT와 ChatDev가 전체 실패가 대체로 적긴 했어요. 그런데 검증자가 있어도 전체 성공률은 여전히 낮을 수 있었어요. 논문 표현으로는 만병통치약이 아니라는 거죠.

진행자: 이제 첫 번째 질문으로 돌아가 볼게요. 모델 탓이냐, 설계 탓이냐.

전문가: 논문이 이걸 실험으로 확인한 게 있어요. 모델은 GPT-4o 그대로 두고 ChatDev의 설계만 바꿨어요. 과제는 연구진이 직접 만든 프로그램 작성 과제 32개였고요.

전문가: 바꾸기 전 성공률이 25%였어요.

진행자: 넷 중 하나만 성공한 거네요.

전문가: 네. 첫 번째 개입은 역할 명세를 다듬은 거예요. CPO 에이전트가 CEO 에이전트와 합의도 없이 대화를 끝내 버리는 일이 있었는데, 상위 에이전트만 대화를 끝낼 수 있게 했어요. 검증 역할에는 과제별 경계 사례를 보라고 명시했고요. 그랬더니 34.4%, 9.4%포인트 올랐어요.

전문가: 두 번째 개입은 구조를 바꾼 거예요. 원래는 단계가 한 방향으로만 흐르는 구조였는데, 되돌아갈 수 있는 순환 구조로 바꿨어요. 그리고 CTO 에이전트가 모든 리뷰가 충족됐다고 확인해야만 끝나게 했죠. 논문은 이걸 상위 목표를 검증하는 단계를 넣은 거라고 설명해요. 결과는 40.6%, 처음보다 15.6%포인트 올랐어요.

진행자: 15.6%포인트면 꽤 큰데요. 모델은 그대로인데.

전문가: 그게 논문의 핵심 주장이에요. 같은 모델이라도 설계를 잘하면 성능이 오른다. 그런데 반대쪽도 같이 봐야 해요. 제일 좋아진 게 40.6%예요. 열 번 중 여섯 번은 여전히 실패해요.

전문가: 논문도 스스로, 개입이 효과는 있었지만 큰 개선은 아니고 모든 실패 유형이 사라지지도 않았다고 써요. 다른 실험에서는 같은 개입이 모델에 따라 효과가 달랐어요. 수학 문제 과제에서 구조를 바꾼 게 GPT-4에서는 통계적으로 유의하지 않았고, GPT-4o에서는 유의했거든요.

진행자: 그럼 답은 뭐예요? 모델이냐 설계냐.

전문가: 논문의 답은 설계 쪽에 무게를 둬요. 모델이 좋아지는 것만으로는 이 실패들을 다 없애지 못할 거라고 추정하고, 똑똑한 개인들이 모인 조직도 구조가 잘못되면 크게 실패한다는 조직 이론을 근거로 들어요. 동시에 모델 한계에서 오는 실패도 있다고 인정하고요.

전문가: 다만 그건 어디까지나 추정이고, 2025년 초 세대 모델 기준이라는 점은 감안해서 들어야 해요. 제 정리는 이래요. 설계를 바꾸면 분명히 오른다. 하지만 설계 몇 줄 고쳐서 믿고 맡길 수준까지 가지는 않는다.

진행자: 그럼 아예 나누지 말자는 쪽 얘기를 들어 보죠. Cognition 글이요.

전문가: 2025년 6월에 Cognition의 Walden Yan이 쓴 글이에요. 원칙이 두 개예요. 첫째, 개별 메시지가 아니라 에이전트의 전체 실행 기록, 트레이스를 공유하라. 둘째, 행동에는 암묵적 결정이 담기고, 충돌하는 결정은 나쁜 결과를 낳는다.

진행자: 암묵적 결정이라는 게 구체적으로 뭐예요?

전문가: 글에 나오는 예가 Flappy Bird 복제예요. 배경과 파이프 담당, 새 담당으로 서브에이전트 둘에게 나눠 줬더니, 한쪽은 슈퍼마리오 같은 배경을 만들고 다른 쪽은 Flappy Bird답지 않은 새를 만들었어요.

전문가: 원래 과제를 같이 줘도 부족했대요. 문맥을 공유한 버전에서도 두 결과물의 그림 스타일이 어긋났어요. 서로 볼 수 없는 가정 위에서 각자 결정을 내렸으니까요.

진행자: 그림체를 정하는 게 암묵적 결정이었던 거네요.

전문가: 그렇죠. 제 식으로 풀면, 코드를 한 줄 쓸 때마다 이름 짓는 방식, 에러 처리 방식, 스타일 같은 결정이 같이 들어가요. 그걸 다른 에이전트가 모르면 충돌하는 거죠.

전문가: 그래서 이 글의 결론은 기본값으로 단일 스레드 선형 에이전트를 쓰라는 거예요. 아주 긴 작업이면 지난 이력을 핵심 결정 위주로 압축하는 별도 모델을 두라고 하는데, 그건 제대로 만들기 어렵다고 스스로 말해요.

진행자: 이 글에 실험 수치가 있나요?

전문가: 없어요. 벤치마크도 측정 결과도 없고, 예시와 관찰로 펼친 주장이에요. 자사 제품의 설계 방향을 설명하는 글이기도 하고요. 그러니까 증거라기보다는 논증으로 받아들이는 게 맞아요.

진행자: 반대편에는 Anthropic 결과가 있죠.

전문가: 네, Cognition 글 바로 다음 날인 2025년 6월 13일에 나온 글이에요. 리드 에이전트로 Claude Opus 4, 서브에이전트로 Claude Sonnet 4를 쓴 구성이, Claude Opus 4 하나만 쓴 것보다 내부 리서치 평가에서 90.2% 높았어요.

전문가: 이것도 감안할 게 있어요. 자사 제품이고, 결과가 회사 내부 평가에서 나온 수치예요. 그리고 같은 글에서 BrowseComp라는 웹 탐색 평가를 분석했더니, 성능 편차의 80%를 토큰 사용량 하나로 설명할 수 있었다고 해요. 토큰을 많이 쓴 효과도 섞여 있다는 얘기죠.

진행자: 두 회사가 정반대 말을 하는 것 같은데요.

전문가: 저는 정반대라기보다 서로 다른 일을 보고 있다고 봐요. Anthropic 글을 잘 읽으면 멀티에이전트가 안 맞는 영역을 스스로 적어 놨어요. 모든 에이전트가 같은 문맥을 공유해야 하거나 에이전트끼리 의존성이 많은 일이요. 그리고 대부분의 코딩 작업은 조사보다 진짜로 병렬화할 수 있는 부분이 적다고요.

전문가: Cognition이 든 예는 게임을 만드는 일, 즉 무언가를 쓰는 일이에요. Anthropic이 성공한 건 조사, 즉 읽는 일이고요.

진행자: 읽기와 쓰기로 나뉘는군요.

전문가: 네. 이 구분은 두 글이 직접 쓴 표현은 아니고, 둘을 나란히 놓고 제가 정리한 틀이에요. 읽기 중심 작업은 하위 작업끼리 독립적이에요. 각자 찾아 와서 합치면 되죠. 쓰기 중심 작업은 앞의 결정이 뒤의 행동을 묶어요. 나누는 순간 암묵적 결정이 갈라지고요.

진행자: 그 틀을 수치로 확인한 연구는 없어요?

전문가: 비슷한 걸 본 게 Google Research, Google DeepMind, MIT 연구진의 논문이에요. 단일 에이전트와 네 가지 멀티에이전트 구조를 같은 도구, 같은 프롬프트, 같은 연산 예산으로 맞추고, 벤치마크 6개에서 260개 구성을 비교했어요.

전문가: 금융 분석 과제에서는 중앙 조율형 멀티에이전트가 단일 에이전트보다 80.8% 높았어요. 매출, 비용, 시장 요인을 각자 따로 분석할 수 있는, 자연스럽게 나뉘는 일이었죠.

전문가: 반대로 게임 속 아이템 제작을 순서대로 계획하는 과제에서는 멀티에이전트 구조 네 가지가 전부 나빠졌어요. 적게는 약 39%, 많게는 70%까지 떨어졌어요.

진행자: 왜 그렇게까지 떨어져요?

전문가: 논문이 실행 기록을 보여 주는데요. 단일 에이전트는 레시피를 찾고, 재료를 옮기고, 만들면 세 번 만에 끝나요. 그런데 중앙형은 레시피 조사, 인벤토리 확인, 제작을 각각 다른 에이전트에 나눠 줘요. 정말 필요한 건 마지막 하나뿐인데요. 추론에 써야 할 토큰을 조율 메시지에 써 버린 거죠.

전문가: 이 논문에 수치가 두 개 더 있어요. 하나는, 단일 에이전트가 이미 45% 정도를 넘는 과제에서는 에이전트를 더해도 오히려 손해였다는 것. 다른 하나는 오류 증폭인데, 중간 검증 없이 각자 돌리는 독립형은 오류를 17.2배로 키웠고, 중앙에서 조율하는 구조는 4.4배로 억눌렀대요.

진행자: 4.4배도 적은 건 아니네요.

전문가: 맞아요. 검증 병목을 두면 덜 퍼진다는 거지, 안 퍼진다는 게 아니에요. 논문 결론은 한 줄이에요. 에이전트 수가 아니라 아키텍처와 작업 구조가 맞느냐가 협업의 성패를 가른다.

진행자: 현장 얘기도 하나 듣고 싶어요. 한국 실무자 경험담이 있다고 하셨죠.

전문가: 네. shalomeir라는 분이 2026년 4월에 쓴 글인데, 먼저 말씀드리면 이건 개인 경험담이에요. 통제된 실험이 아니니까 일화로 들어 주세요.

전문가: 이분이 멀티에이전트 오케스트레이션 도구 두 개를 직접 써 보면서 API 토큰 비용으로 5천 달러 정도를 썼대요. 토큰은 단일 에이전트 대비 체감상 적게는 다섯 배, 많게는 열 배 가까이 들었다고 하고요.

전문가: 겪은 실패가 MAST 분류와 많이 겹쳐요. 한 에이전트가 완료 처리를 했는데 다음 에이전트를 깨우는 트리거가 끊겨서 위임된 일이 계속 대기했대요. 상위 작업은 닫혔는데 하위 작업은 미완료로 방치되기도 했고요. 각자 git worktree에서 일하다 머지 충돌이 났는데, 완료로 처리됐지만 결과물은 없는 경우도 있었대요.

진행자: 마지막 건 MAST로 치면 검증 실패네요.

전문가: 네, 이분도 비슷하게 진단해요. LLM은 그럴듯한 응답이면 스스로 완료로 처리한다, 자기가 쓴 답안을 자기가 채점하는 구조라서. 그래서 해결 방향으로, 완료 보고에는 실제 결과물이나 검증 결과를 증거로 붙이게 강제하라고 제안해요.

전문가: 이분 결론도 오늘 흐름과 비슷해요. 멀티에이전트가 도움이 된 건 한 문맥 창을 넘는 작업, 병렬 작업, 교차 검증이었고, 리서치가 첫 성공 사례가 된 건 오류 비용이 낮고 검증이 쉽고 각 에이전트가 독립적으로 일할 수 있어서라고 봐요.

진행자: 이제 두 번째 질문이요. 나눌지 말지, 실제로는 어떻게 판단하면 될까요?

전문가: 오늘 자료를 합쳐서 질문 네 개로 정리해 볼게요. 이건 제 정리고, 각 질문이 어느 근거에서 왔는지 같이 말씀드릴게요.

전문가: 첫째, 하위 작업이 서로의 결과를 몰라도 되는가. 각자 찾아 와서 합치기만 하면 되는 읽기 중심 일이면 나눌 만해요. 금융 분석 과제나 Anthropic의 리서치가 여기에 해당하죠.

전문가: 둘째, 하위 작업이 결정을 내리는가. 코드를 쓰거나 계획을 세우는 일처럼 앞의 결정이 뒤를 묶는다면 나누지 마세요. Cognition의 논증, 순차 계획 과제의 하락, Anthropic이 코딩을 잘 안 맞는 영역으로 꼽은 게 같은 방향을 가리켜요.

전문가: 셋째, 단일 에이전트가 이미 잘하는가. 이미 꽤 잘하는 과제라면 에이전트를 더해도 조율 비용만 늘 수 있어요.

전문가: 넷째, 나눈다면 검증을 구조에 넣었는가. 프롬프트에 검증하라고 한 줄 추가하는 게 아니라, 목표를 확인해야만 끝나는 흐름, 결과를 합치기 전에 걸러 내는 중앙 검증, 증거가 있어야 인정되는 완료 보고 같은 거요.

진행자: 결국 기본값은 단일 에이전트고, 나누려면 이유가 있어야 한다는 거네요.

전문가: 저는 그렇게 봐요. 그리고 나눴다면 실패를 유형별로 세어 보세요. 단계 반복인지, 되묻지 않은 건지, 검증이 겉만 본 건지요. 같은 성공률이라도 어디서 깨지는지 알아야 고칠 곳이 보이니까요.

전문가: MAST 논문도 개입 전후로 실패 유형 분포를 비교해서, 어떤 실패가 줄었고 어떤 게 남았는지 확인했어요.

진행자: 정리해 볼게요. 첫째, MAST 기준으로 멀티에이전트 실패의 절반 가까이는 설계 문제였고, 같은 모델로 설계만 바꿔도 성공률이 올랐어요. 하지만 그래도 성공률은 낮았죠.

진행자: 둘째, Cognition의 "나누지 마라"와 Anthropic의 90.2%는 서로 다른 일을 보고 있어요. 읽기 중심의 병렬 작업은 나눌 만하고, 결정을 내리는 쓰기 중심의 순차 작업은 나누면 암묵적 결정이 충돌해요.

진행자: 셋째, 나눈다면 검증을 구조에 넣어야 해요. 겉만 보는 검증은 실패의 큰 덩어리였으니까요.

전문가: 하나만 덧붙이면, 오늘 숫자 대부분이 2025년 전후 세대 모델, 오픈소스 프레임워크, 또는 자사 평가에서 나왔어요. 방향은 참고하되, 내 작업에서는 직접 세어 보시길 권해요.

진행자: 1편의 다섯 규칙과 오늘의 실패 유형을 같이 보시면, 루프를 어디서 나누고 어디서 묶을지 판단하는 데 도움이 될 거예요. 오늘 다룬 논문과 글은 설명란에 모두 링크해 두었습니다. 들어 주셔서 감사합니다.