예를 들어, 금요일 밤입니다. 실제 운영 환경에서 느린 API를 분할하기 위해 여러 개의 에이전트를 병렬로 실행합니다. 로그 담당, 메트릭스 담당, 최근 배포된 변경 사항 담당 등 각각 별도의 스레드에서 작동합니다.
아이(에이전트)들은 꽤 빠르게 움직입니다. 그런데 전체 과정이 느려집니다. 이유는 간단합니다. 모든 결과가 부모 스레드로 돌아오고, 부모가 다음 지시를 내릴 때까지 아이들이 멈춰 있기 때문입니다.
'에이전트를 늘렸는데 빨라지지 않는다'는 것은 모델의 지능만의 문제가 아닙니다. 데이터를 모으는 방식(집계 방법)의 문제이기도 합니다. Carnegie Mellon University의 Xuecheng Liu 씨와 Daman Arora 씨 등의 팀은 이 집계 병목 현상(aggregation bottleneck)을 해결하는 프레임워크로 **Message Passing Language Models (MPLMs)**를 제안했습니다. 논문은 Message Passing Enables Efficient Reasoning이며, 프로젝트 페이지는 MPLM: Message Passing Language Models, 구현체는 Zanette-Labs/mplm에 공개되어 있습니다.
본고에서는 연구의 세부 사항을 따라가기보다는, 병렬 에이전트 하네스(harness)에서 무엇이 어떻게 달라지는지를 현장의 언어로 설명합니다.
테스트 시 계산량을 늘려 추론을 강화하는 흐름은 이미 일반적입니다. 하나의 긴 Chain-of-Thought(사고의 연쇄)로 진행하는 방식과, 태스크를 분할하여 병렬로 진행하는 방식이 있습니다.
후자의 대표적인 예가 fork-join입니다. 부모가 자식 스레드를 시작하고, 자식이 완료되는 대로 부모가 결과를 모아 다음 단계를 결정합니다. 레이턴시는 줄어듭니다. 하지만 또 다른 제약이 남아있습니다.
자식들끼리는 기본적으로 직접 대화할 수 없습니다. 정보는 반드시 부모를 거쳐야 합니다. 자식들의 컨텍스트(context)는 수명이 짧고, 한 번 반환되면 사라지도록 설계되는 경우가 많습니다. 부모는 결과 취합/재프롬프트/도구 호출 등으로 바빠지고, 그 결과 **암묵적인 직렬화(implicit serialization)**가 발생합니다.
모델 외의 제어 계층을 '하네스'라고 정리하는 개념은 '하네스 엔지니어링이란 무엇인가? — AI 에이전트를
저자들은 구조가 명확한 문제에서 효율성 차이를 측정했습니다. 훈련 데이터는 Python으로 시뮬레이션된 트레이스입니다. 이를 사용하여 Qwen3-0.6B-Base를 지도 학습 미세 조정(SFT) 했습니다. 비교 대상은 단일 Serial CoT와, 부모가 취합하는 Fork-Join (FJ) 방식입니다.
각 칸에 1개의 스레드를 할당합니다. 각 칸은 같은 행/열/상자 이웃으로부터 숫자를 받아 후보를 줄여나갑니다. 후보가 하나로 결정되면(소위 naked singles), 부모와 이웃에게 숫자를 보내고 자신은 멈춥니다. 모든 것이 멈추면 부모가 판을 정리합니다.
논문 Table 1에서는 예를 들어 9×9의 경우 MPLM이 약 **14.9초, 정답률 100%**인 반면, FJ는 약 **59.6초, 93%**입니다. 16×16이나 25×25의 경우, FJ와 Serial은 저자들이 설정한 컨텍스트/계산 제약 때문에 훈련 자체가 성립하지 않았고, MPLM은 25×25에서 **72%**까지 풀 수 있었습니다. 도구(tool)가 없는 일부 프론티어 추론 모델에서도 큰 판에서는 어려움을 겪는다는 비교도 제시되었습니다.
핵심은 '작은 모델이 강하다'라는 것만이 아닙니다. 이웃과만 대화하도록 설계한 결과, 스레드당 컨텍스트 증가가 억제되었다는 구조적인 이야기입니다.
부울식이 만족되는지 탐색하는 문제에서는, 한 가지 가지(branch)가 해답을 찾은 순간 다른 가지를 계속할 필요가 없어집니다. MPLM의 경우, 해답을 찾은 자식(child)이 부모에게 보내면 부모가 다른 가지를 멈출 수 있습니다. FJ의 경우, 부모는 자식이 완성될 때까지 기다리기 쉬워서 나무 구조가 치우치면 '마지막 잎'까지 레이턴시가 끌리게 됩니다.
정확도는 FJ와 비슷합니다(변수별 표에서는 대략 90% 전후). 평균 레이턴시는 MPLM이 빠르다는 결과입니다. 치우친 나무 구조에서는 요약에서 언급된 것처럼 몇 배 빠른 예도 나옵니다.
병렬화로 인해 호출이 늘어나면 경제성이 무너지기 쉬운 점은 AI 에이전트가 바꿀 비즈니스의 미래: 에이전트 워크플로우의 실천 가이드(AIエージェントが変えるビジネスの未来：エージェント・ワークフローの実践ガイド)에서도 다루고 있습니다. MPLM이 보여주는 것은, '호출을 늘릴 거라면, 쓸모없는 가지를 빨리 잘라내라'라는 상쇄적인 설계입니다.
Sudoku와 SAT는 전용 트레이스로 학습한 이야기입니다. 반면, LongBench-v2에서는 태스크에 대한 추가 학습 없이 큰 모델에게 MPLM의 절차를 프롬프트 지시했습니다. 비교 대상은 fork-join 성향의 RLM(Recursive Language Models)입니다.
논문 Table 2의 평균을 보면 다음과 같습니다.
Qwen3-30B-A3B: 정답률 29.7% → 37.8%, 평균 레이턴시 105.7초 → 61.3초 (약 1.7배 빠름) -
Qwen3.6-35B-A3B: 정답률은 거의 동일(46.7% 대 46.5%), 평균 레이턴시 223.5초 → 102.2초 (약 2.2배 빠름)
작동 방식의 골격은 이렇습니다. 긴 컨텍스트를 청크로 나누고, 각 워커가 요약을 부모에게 보냅니다. 부모는 요약을 보고 필요하다면 특정 워커에게만 추가 질문을 합니다. 워커는 상태를 유지하므로, 같은 구간을 다시 읽어올 비용을 줄이기 쉽다는 설명입니다.
긴 컨텍스트를 한 번에 넣지 않고 분할하여 다루는 발상은 긴 채팅일수록 답변이 흐트러지는—Context Rot을 방지하는 Memory・Projects・Skills의 사용 구분(Context Rotを防ぐMemory・Projects・Skillsの使い分け)과도 연결됩니다. MPLM은 그 분할을 '부모에게 일괄 반납'이 아니라, '필요하다면 같은 워커에게 다시 묻는' 형태로 하고 있습니다.
연구를 그대로 실전에 적용할 필요는 없습니다. 설계 검토에서는 다음 3가지를 체크하면 사용하기 좋습니다.
Sudoku의 '행・열・상자', 장문의 '청크 ID', 마이크로서비스의 '의존하는 API 경계'처럼, 누가 누구의 결과를 필요로 하는지를 먼저 쓸 수 있는 작업일수록 점대점(point-to-point)으로 효과적입니다. 오픈 엔드 조사나 도중에 의존 관계가 바뀌는 작업에서는 부모가 모아주는 것이 더 안전할 때도 많습니다. 저자 자신도 오픈 엔드의 경우 프롬프트나 추가 학습이 필요하다는 한계를 언급했습니다.
부모가 '전체 로그를 읽고 재추론하는' 역할을 맡게 되면, fork-join의 약점이 재발합니다. 부모는 라우팅과 최종 보고만 하고, 국소적인 세부 사항은 워커들 사이에서 역할 분담을 하는 발상이 가깝습니다.
탐색이나 여러 가설 비교에서는 '하나가 발견되면 나머지를 멈추기', '모순이 나오면 가지를 버리기'가 가능한지가 중요합니다. 멈출 수 없는 병렬 처리는 비용만 늘립니다.
작은 설계 메모로, 자 팀의 워크플로우를 다음 표에 대입해 보는 것도 유효합니다.
검토용 체크리스트 (개념). 실제 오케스트레이터는 아닙니다.
workflows = [
{
...
]
실행 조건은 Python 3의 로컬 실행으로 충분합니다. 출력은 설계 메모의 초안일 뿐, 채택 판단 그 자체가 아닙니다.
그렇지 않습니다. 통신 패턴이 불분명한 작업에서는 부모가 상황을 보고 재조정하는 것이 실패할 확률이 적습니다. MPLM의 강점은 알려진 희소 의존성과 **조기 종료(early termination)**를 동시에 원하는 경우입니다.
저자는 Sudoku를 naked singles (제거만으로 진행되는 판)로 한정하고 있습니다. 추측과 검증을 깊이 넘나드는 테크닉은 이 실험에서는 요구하지 않습니다. 일반화의 증거는 LongBench-v2 쪽이 더 가깝지만, 여기 역시 프롬프트 설계에 의존합니다.
Sudoku/SAT는 0.6B의 학습 결과이고, LongBench는 수십 B급의 프롬프트 결과입니다. 숫자가 의미하는 레이어가 다릅니다. 저희 회사에서는 같은 작업을 '부모 집중(parent aggregation)'과 '인접 알림 + 조기 정지'의 두 하네스에서 정확도・레이턴시・토큰 합계를 나열하는 것이 실무적입니다.
MPLM이 보여주는 것은 새로운 모델 이름이라기보다, 에이전트 병렬 통신 설계입니다. 스레드를 늘리기 전에, '누가 누구에게 무엇을 전달할지', '부모가 얼마나 모을지', '언제 멈출지'를 그림으로 그리면 병목 지점의 위치를 파악하기 쉽습니다.
금요일 조사에서도, 월요일 설계 검토에서도 첫걸음은 같습니다. 기존 오케스트레이션 다이어그램에 화살표가 전부 부모를 향하고 있지 않은지 한번 재검토하는 것입니다. 화살표 일부를 워커(worker) 간으로 옮길 수 있다면, 메시지 패싱(message passing)의 발상을 사용할 수 있습니다. 옮길 수 없다면, 부모 집중을 유지하되 부모의 작업을 줄이는 것이 먼저입니다.
만능의 하네스는 없습니다. 그럼에도 불구하고, '늘렸는데 기다리게 되는' 이질감의 정체를 모델 외적인 계층에서 설명할 수 있게 되는 것만으로도 다음 시제품 제작은 진행하기 쉬워집니다.
작성일: 2026-09-25
