#다중 Agent를 "역할 나눠 대화"로 조율하면 왜 무너지는가 — 중앙조정기·전역상태머신·분층기억풀

← 전체 목차 · 이전: 멀티 Agent Handoff: 왜 완전한 이력을 전부 넘기면 안 되는가 · 다음: 여러 Agent가 동시에 뛸 때, 중복 실행과 기억 뒤섞임은 어떻게 막는가

"기획자·실행자·검증자로 역할 Prompt를 나누고, 대화 이력으로 정보를 주고받으며 순서대로 발언시킨다"는 답은 데모에서는 통과하지만 병렬 실행, 노드 오류, 갱신 비동기화 세 조건이 겹치는 순간 전부 깨진다. 진짜 쟁점은 "역할을 나눌 줄 아는가"가 아니라 같은 복잡 작업을 몇 번을 다시 실행해도 일관된 결과로 수렴시킬 수 있는가다 — 환절 누락 없음, 중복 실행 없음, 오류 추적 가능.

#"대화로 조율"이 실패하는 5가지 지점

대화 이력을 상태의 저장소로 쓰는 방식은 암묵적, 희석 가능, 잠금 불가능하다. 이 다섯 가지를 한 번에 막으려면 조율을 자연어 밖으로 꺼내 명시적 상태로 옮겨야 한다.

#기준선: 중앙조정기 + 전역상태머신 + 분층기억풀

조정기(Orchestrator)      — 작업 분해·단계 배정·진행 관리를 전담. Agent 자체 협상 금지
전역상태머신(State Machine) — 유일한 진실 소스. Agent는 상태 회신만, Agent 간 직접 통신 금지
분층기억풀(Memory Pool)    — 전역 풀: 공용 상태·마일스톤 결과 / 로컬 풀: 개별 Agent 실행 디테일
역할계약(Role Contract)    — 책임 경계·입출력 규격·능력 범위를 자연어 대신 스키마로 고정

• 통신 위상이 바뀐다: Agent끼리 그물망(O(n²))으로 떠들던 것이, 전부 상태머신에만 회신하는 별 모양(O(n))으로 줄어든다. 동기화 지점이 하나면 장애 지점도 하나다.
• 작업 분해는 하달 전에 검증한다: 완전성 검증(전체 흐름을 덮는가) + 상호배제 검증(겹치는 환절이 없는가)을 통과한 뒤에만 실행에 내려보낸다. 누락과 중복은 실행 단계가 아니라 분해 단계의 결함이다.
• 컨텍스트는 밀어 넣지 않고 필요에 따라 꺼내 쓴다: 조정기가 전역 풀/로컬 풀 중 무엇을 누구에게 줄지 결정한다. "요약 Agent를 추가해 압축한다"는 폭발 이후의 뺄셈이고, 분층 + 온디맨드 푸시는 애초에 팽창시키지 않는 방식이다.

#동시성·장애·하류 시스템 3종 방어

병렬 충돌
  노드 실행 전 현재 단계 상태를 "선점"
  → 선점 실패 → 대기 또는 스킵 → 중복 실행 원천 차단

단일 노드 오류
  실행과 상태 기록을 하나의 원자적 트랜잭션으로 묶음
  → 실패 시 마지막 안정 상태로 자동 롤백
  → 임계치 초과 시 해당 노드 회로 차단 → 대체 Agent 전환 또는 사람 처리로 강등

하류 시스템 개조 불가
  "프로토콜 어댑터 레이어"를 새로 추가해 상태 매핑·포맷 변환만 담당
  → 기존 업무 인터페이스는 무변경, 협업 로직은 전부 어댑터 위쪽에서 처리

조정기 자체 장애
  전체 시스템을 "단일 Agent 직렬 실행 모드"로 강등
  → 핵심 흐름은 중단시키지 않고, 병렬 최적화와 결과 재검증은 사후에 보완

중앙화 아키텍처는 스스로 단일 장애점이 될 수 있다는 것을 전제로 설계해야 한다 — 조정기가 죽었을 때 조정기 없이도 굴러가는 대체 경로(직렬 강등)가 항상 실행 가능한 상태로 검증돼 있어야 한다.

#관측 지표

작업 완료율(누락 탐지) · 노드 롤백 횟수(단일 노드 불안정) · 상태 불법 전이 횟수(동시성/로직 결함) · 컨텍스트 길이 임계치(팽창) — 이 네 지표는 위 5가지 실패 지점과 정확히 대응한다.

#핵심 통찰

1. 다중 Agent의 목표는 "사람처럼 토론하는 것"이 아니라 "일관된 폐루프 결과"다 — 판정 기준을 환절 무누락·실행 무중복·오류 추적 가능 세 개로 못 박으면, "역할 Prompt + 순번 발언" 방식이 그중 어느 것도 보장하지 않는다는 게 바로 드러난다.
2. 협업을 자연어에서 꺼내 명시적 상태로 옮기는 것이 전체 설계의 토대다 — 대화 이력은 희석되고 잠글 수 없는 암묵적 매체이고, 전역 상태머신은 유일하고 검증 가능한 명시적 매체다. "일관성은 상태머신이 동시성 제어를 맡는다"는 이 설계 전체의 지반이다.
3. 유일 진실 소스 + 별 모양 통신이 Agent 간 그물망 잡담을 대체한다 — Agent는 상태머신에만 회신하고 서로 직접 통신하지 않는다. 통신 경로가 O(n²)에서 O(n)으로 줄면 검증할 동기화 지점도 하나, 장애 시 봐야 할 진실도 하나가 된다.
4. 작업 분해는 하달 전에 검증돼야지, 실행 후 발견되면 안 된다 — 완전성 검증은 누락을, 상호배제 검증은 중복을 막는다. 이 두 단어가 "작업 분해"를 모델의 한 번뿐인 자유 발휘에서 인수 조건이 있는 하나의 스텝으로 바꾼다. 누락과 중복을 분해 단계가 아니라 실행 단계에서 발견하면 비용이 한 자릿수 이상 뛴다.
5. 컨텍스트는 많을수록 좋은 게 아니라 "필요에 따라 미는 것"이 좋다 — 전역 풀엔 공용 상태와 마일스톤, 로컬 풀엔 개별 실행 디테일을 두고 조정기가 무엇을 누구에게 밀지 결정한다. "요약 Agent 추가"는 폭발 후의 뺄셈이고, 분층 + 온디맨드는 애초에 근원에서 팽창을 막는 방식이다.
6. "실행 + 상태 기록"은 반드시 하나의 원자적 트랜잭션이어야 한다 — 그렇지 않으면 "일은 했는데 상태는 안 써졌다" 혹은 "상태는 써졌는데 일은 안 됐다"는 중간 상태가 생기고, 이 중간 상태가 병렬 시스템에서 눈덩이 오류의 시작점이 된다. 마지막 안정 상태로 롤백할 수 있으려면 모든 안정 상태가 온전히 기록돼 있어야 한다는 게 전제다.
7. 개조 불가능한 하류는 어댑터로 격리하지, 하류에 맞춰 협업 로직을 굽히지 않는다 — 프로토콜 어댑터 레이어가 상태 매핑·포맷 변환을 전담하고 기존 업무 인터페이스는 무변경으로 둔다. "바꿀 수 없는 것"을 경계로 격리하는 범용 아키텍처 해법이다.
8. 중앙화 방안은 반드시 스스로의 강등 경로를 갖춰야 한다. 그렇지 않으면 조정기가 새로운 단일 장애점이 될 뿐이다 — 조정기 장애 시 단일 Agent 직렬 실행으로 강등해 핵심 흐름을 지키고, 병렬 최적화와 결과 복기는 사후에 보완한다. 자기 설계의 실패 모드와 대책을 먼저 말할 수 있는 것이 이 주제에서 가장 격차를 벌리는 지점이다.

#엔지니어링 실전 Tips

• "누가 누구를 부를 수 있는가"를 문서가 아니라 아키텍처에 새길 것. 모든 하위 Agent는 조정기와만 통신하고 노드 간 직접 호출을 금지 — 규범으로 막을 수 있는 게 아니라 호출 권한으로만 막을 수 있다.
• 노드 실행 전 "선점"을 전치 조건으로 만들 것. "이 단계를 할지 말지"를 Agent의 자유 판단이 아니라 상태머신의 결정론적 응답으로 바꾸는 것이 중복 실행을 막는 가장 저비용 수단이다.
• 상태 기록은 트랜잭션에 묶고 "기억해서 갱신하라"는 약속에 맡기지 말 것. 실패 경로에서는 반드시 누락된다.
• 회로 차단은 임계치뿐 아니라 반드시 다음 행선지를 지정할 것. 대체 Agent 전환 또는 사람 처리로 강등 — 차단만 하고 갈 곳을 안 정하면 작업이 그대로 목매달린다.
• 분층 기억의 경계선은 "공용이냐 사설이냐"다. 공용 상태·마일스톤은 전역 풀, 개별 실행 디테일은 로컬 풀 — 경계를 정확히 그어야 조정기가 누구에게 무엇을 밀어줄지 안다.
• 강등 경로는 문서에만 적어두지 말고 미리 연습할 것. 조정기 장애 시 단일 Agent 직렬 모드가 항상 실행 가능해야 하며, 한 번도 검증 안 된 가정 경로여서는 안 된다.
• 모니터링 4지표를 실패 지점과 1:1로 매핑해 둘 것. 작업 완료율=누락, 노드 롤백 횟수=단일 노드 불안정, 상태 불법 전이=동시성 결함, 컨텍스트 길이=팽창. 지표 하나가 튀면 바로 원인 후보가 좁혀진다.