멀티에이전트 시스템에서 나타나는 패턴과 문제들

Who Should Read

여러 LLM 에이전트를 병렬·협업 구조로 묶어 코드 작업이나 자동화를 설계 중인 백엔드 개발자

Core Mechanics

• 협업 swarm이 취약점을 더 많이 찾았다
  • Mythos Preview 기준 독립 병렬 에이전트는 650만 토큰에 취약점 21개, 협업 swarm은 2,700만 토큰에 266개를 찾았다.
  • 독립 에이전트가 보도록 지정된 핵심 디렉터리만 세면 토큰당 취약점 수는 비슷했다.
  • 두 방식이 겹친 취약점은 12개뿐이라 서로 보완적이었다.
• 게임 개발 협업은 결과물이 별로였다
  • 에이전트 swarm에 텍스트 오픈월드 게임을 12시간 만들게 했더니 세 가지 프롬프트(기본, 역할 지정, CEO 계층) 모두 결과가 나빴다.
  • 프롬프트 차이는 크지 않았고 모델은 이 분야에서 취향이 부족해 사람의 지시가 필요했다.
• 모델 세대마다 협업 방식이 달랐다
  • Sonnet 4.6과 Opus 4.6은 같은 파일에 커밋하다 PR이 충돌해 버려지는 일이 많았다.
  • Opus 4.8과 Mythos Preview는 각자 파일을 소유하고 거의 함께 일하지 않는 방식으로 충돌을 피했다.
  • Sonnet 5만 코드 공유가 높으면서 PR 병합률도 높았다.
• 같은 모델 에이전트는 같은 실수를 한꺼번에 한다
  • 30개 에이전트 중 18개가 똑같은 브랜치명 mvp-game-loop를 만들었다.
  • 반복 죄수의 딜레마에서는 모두 같은 전략으로 동시에 배신해 보상이 떨어졌다.
  • 작업 큐 실험에서는 초당 30회 폴링 데몬이 몰려 요청 240만 건 중 117건만 수락됐다.

Community Reactions

• 병렬·협업을 이미 쓰는 사람의 경험
  • 매니저, 실행자, 리뷰어 3개 에이전트 cohort에 agents.md로 전제 의심과 맹신 방지 규칙을 넣어 쓴다는 경험이 있었다.
  • 기능당 시간은 늘었지만 완성도가 높아 디버깅과 되돌아오는 시간이 크게 줄었다고 한다.
• 좁은 도구로 제한하면 안정적이라는 의견
  • 원시 DOM 조작 대신 DoLogin 같은 화면별 도구를 준 전문 서브에이전트가 5~10단계에서 죽던 앱을 100단계 이상 돌렸다는 경험이 있었다.
  • 계층 없는 피어 구조 자체가 문제라는 의견도 여러 개 있었다.
• 분산 시스템 문제와 같다는 의견
  • 상태 관리, 조율, 장애 격리, 관측성, 종료 조건이 어렵고 모델 호출은 가장 덜 흥미로운 부분이라는 의견이 있었다.
  • 한 에이전트가 환각하면 다음 에이전트들이 오류를 증폭시킨다는 의견도 있었다.
• 단일 에이전트가 더 낫지 않냐는 질문
  • 필요한 정보가 한 컨텍스트에 들어가면 단일 에이전트가 그룹보다 일관되게 높은 점수를 받았다는 점을 짚는 댓글이 있었다.
  • 원문의 turf war 대목에서 방해 공작과 악성코드 같은 행동이 나온다는 점을 우려하는 반응도 있었다.

How to Apply

• 서브에이전트 간 브랜치·파일 소유권 규칙 넣기
  • 오늘 멀티에이전트 프롬프트에 각 에이전트가 수정할 디렉터리와 브랜치명 접두사를 에이전트 ID로 지정하라.
  • 같은 이름 브랜치와 PR 충돌을 막기 위해 공유 파일 수정 전 게시판에 알리게 하라.
• 독립 병렬 실행과 협업 실행을 같은 작업으로 비교하기
• 에이전트에 역할 다양성과 반대 의견 의무 넣기
  • 같은 모델·컨텍스트에서는 행동이 수렴하므로 시스템 프롬프트에 서로 다른 관점이나 담당 영역을 줘라.
  • 리뷰어에게는 다수 의견과 다른 근거를 한 번은 반드시 검토하게 하라.
• 공유 자원 호출에 한도와 중앙 조율 붙이기

Try It

# Claude 또는 Claude Code에 붙여넣기: 논문 방법의 간이 버전 (멀티에이전트 협업 규칙 점검)

너는 멀티에이전트 시스템 설계 리뷰어다. 아래 설계를 읽고 같은 모델 에이전트가 수렴해서 생기는 문제를 점검해라.

[설계]
{{에이전트 역할, 공유 자원, 협업 방식 설명}}

다음을 표로 답해라.
1. 여러 에이전트가 같은 선택을 할 수 있는 지점(브랜치명, 폴링, 작업 선택 등)
2. 각 지점에서 생길 수 있는 충돌이나 자원 폭주
3. 한 에이전트가 틀렸을 때 다른 에이전트가 증폭시킬 경로
4. 파일·디렉터리 소유권, 호출 한도, 반대 의견 역할을 넣은 수정안

이어서 해 볼 것: 수정안을 시스템 프롬프트에 넣고 에이전트 3개로 같은 작업을 돌려 충돌 횟수를 비교해 봐라.

Terminology

관련 논문

• 같은 시뮬레이션, 다른 근거: 도구 출력을 파일로 넘기면 LLM 에이전트 정확도가 어디서 깎이나

  긴 툴 출력을 파일로 넘기자 GPT-5.1은 정확도 11.3%p 하락, 정식 출력 지정하니 회복

• 가짜 뉴스가 진짜 폭락을: LLM 트레이딩 에이전트 대상 정보 주입 공격

  가짜 헤드라인 한 줄로 LLM 트레이딩 에이전트 62%를 조종했다(프롬프트 주입은 14%)

• Harness Engineering 101: LLM은 뇌, harness는 몸

  에이전트는 JSON 배열을 관리하는 루프이고, 16개 챕터로 직접 만들어 본다

• Harness²: 에이전트 harness를 스스로 고쳐 쓰는 재귀 최적화 프레임워크

  모델은 고정하고 harness를 재귀로 고쳤더니 벤치마크 점수가 최대 11.8%p 올랐다

• 해고된 Savannah 경찰관, ICE 요원 남편에게 Flock 계정 공유

  경찰관이 Flock 계정을 남편(ICE 요원)에게 공유했고, 감사에서 983건 검색이 드러나 해고됐다

• tmux와 Claude Code: 세션, send-keys, 그리고 한계선

  tmux로 Claude Code 여러 개를 돌리면 편하지만 에이전트 4개쯤에서 한계가 온다

• Hybrid Reasoning Agents: 잠재 공간에서 생각하고 텍스트로 행동하는 LLM 에이전트

  잠재 공간 추론과 텍스트 도구 호출을 섞었더니 성능 10.4%↑, 토큰 최대 54.7%↓

Related Resources

• https://www.anthropic.com/research/multiagent-systems