— 멀티 에이전트에서 State와 메시지 버스로 상태를 관리하며 겪은 혼란
멀티 에이전트를 설계하기 시작하면
자연스럽게 이런 생각이 든다.
“각자 역할을 나눠서 서로 이야기하게 하면 되지 않을까?”
사람 팀처럼 말이다.
내가 만들던 멀티 에이전트 구조도 그랬다.
Planner가 계획을 세우고,
Executor가 코드를 실행하고,
Reviewer가 결과를 검토한다.
겉으로 보면 꽤 그럴듯한 협업 구조다.
단일 Agent보다 더 똑똑해 보이기도 하고
실제로 역할 분담도 명확해 보였다.
문제는, 이 에이전트들이 ‘대화’를 시작하면서부터였다.
멀티 에이전트를 만들면 왜 ‘대화’부터 떠올리게 될까
멀티 에이전트 구조를 처음 설계할 때
나는 자연스럽게 양방향 통신을 떠올렸다.
Planner는 Executor에게 지시하고,
Executor는 결과를 Reviewer에게 넘기고,
Reviewer는 다시 Planner에게 피드백을 준다.
특히 이 구조에서는
Executor가 실제로 코드를 실행하는 에이전트였기 때문에
에러가 발생했을 때 단순한 텍스트 응답으로 끝나지 않았다.
- 다시 실행해야 할지
- 파라미터를 바꿔야 할지
- 아니면 설계 자체를 수정해야 할지
Reviewer가 판단해서
다시 Planner에게 “상태”를 돌려보내야 했다.
이 과정에서 자연스럽게
순환 구조가 만들어졌다.
Planner–Executor–Reviewer 구조에서 상태 문제가 시작된 순간
실행 → 리뷰 → 재계획 → 재실행.
이 사이클이 한 번으로 끝나면 괜찮다.
문제는 이 흐름이 여러 번 반복될 때였다.
내가 개발하던 멀티 에이전트는
서로가 서로에게 피드백을 주며 수정하는 루프가 있는 로직이였고
서로 간 소통이 중요하다고 생각했다.
개발하다보니 어느 순간부터 이런 질문이 생겼다.
“지금 이 시스템은
도대체 어디까지 진행된 상태지?”
에이전트들은 각자 열심히 일하고 있었지만
전체 시스템의 상태는 점점 불분명해졌다.
처음엔 State로 충분하다고 생각했다
처음 선택한 해법은 State였다.
공통 State를 하나 두고:
- 현재 단계
- 마지막 실행 결과
- 에러 여부
같은 정보를 기록했다.
Planner는 State를 보고 다음 계획을 세우고,
Executor는 실행 결과를 State에 반영하고,
Reviewer는 결과를 해석해 다시 State를 업데이트했다.
초반에는 잘 돌아갔다.
하지만 구조가 복잡해질수록 문제가 드러났다.
- 누가 State를 마지막으로 수정했는지 애매해지고
- 실행 중간에 State가 바뀌어 버리고
- 같은 에러인데 매번 다른 흐름으로 빠졌다
State를 쓰고 있는데도
상태가 점점 불안정해지는 느낌이었다.
그래서 메시지 버스로 옮겨갔다
“상태를 직접 공유하지 말고,
이벤트 기반으로 소통하면 더 깔끔하지 않을까?”
그래서 메시지 버스를 도입했다.
- 실행 완료 메시지
- 에러 발생 이벤트
- 리뷰 결과 알림
각 Agent는 메시지를 구독하고 반응했다.
겉보기에는 훨씬 구조적인 시스템 같았다.
서로 상태를 직접 건드리지도 않았고
결합도도 낮아 보였다.
하지만 곧 다른 문제가 생겼다.
메시지는 많은데 시스템이 보이지 않았다
메시지는 계속 오가는데
지금 전체 시스템이 어떤 상태인지 알 수 없었다.
- 이 메시지는 최신 실행 결과인가?
- 이미 처리된 이벤트는 아닌가?
- 지금 이 판단은 어떤 상태를 기준으로 한 건가?
로그는 있었지만 맥락이 없었다.
디버깅은 오히려 더 어려워졌다.
그때 깨달았다.
메시지는 ‘사건’을 전달할 뿐
시스템의 ‘사실’을 보장하지는 않는다는 걸.
State와 Message Bus를 헷갈렸던 이유
돌이켜보면 혼란의 원인은 단순했다.
State와 Message Bus의 역할을 섞어 쓰고 있었던 것이다.
내가 이해한 State의 역할
State는
Agent들이 공통으로 합의하는 현재 상황이다.
- 지금 어떤 단계에 있는지
- 무엇이 이미 끝났는지
- 다음 판단을 위해 필요한 사실은 무엇인지
State는 의견이 아니다.
사실에 가깝다.
그래서 State는 보통:
- 단일 source of truth
- 명확한 스키마
- 제한된 수정 경로
를 가져야 한다.
나중에 깨달았지만
State는 “기억”이 아니라
시스템이 스스로에게 쓰는 기록에 가깝다.
Message Bus의 실제 역할
반면 Message Bus는
“무슨 일이 일어났는지”를 전달한다.
- 실행이 끝났다는 신호
- 에러가 발생했다는 이벤트
- 리뷰가 완료됐다는 알림
메시지는 상태를 설명하지 않는다.
사건만 전달한다.
그래서 메시지는:
- 순서가 중요할 수도 있고
- 중복될 수도 있고
- 처리 시점에 따라 의미가 달라질 수도 있다
이 차이를 명확히 구분하지 않으면
멀티 에이전트 구조는 빠르게 혼란스러워진다.
다시 State로 돌아오며 정리한 최소 원칙
결국 다시 State 중심 구조로 돌아왔다.
하지만 이전과는 기준이 달라졌다.
지금 내가 정리한 최소 원칙은 이렇다.
- State는 반드시 하나의 source of truth여야 한다
- 상태 변경은 한 곳에서만 일어난다
- Agent는 상태를 소유하지 않는다
- Message는 상태를 바꾸지 않는다
메시지는 “사건”을 알리고,
State는 “사실”을 담는다.
이렇게 역할을 나누고 나서야
멀티 에이전트 구조가 다시 통제 가능해졌다.
마무리하며
멀티 에이전트에서 어려운 건
Agent들이 서로 말을 못 해서가 아니다.
지금 우리가 어디에 있는지에 대해
모두가 같은 답을 갖지 못하기 때문에 어렵다.
다음 글에서는
이 State를 누가 관리해야 하는지,
Orchestrator와 Agent의 경계를 중심으로
조금 더 구체적으로 정리해보려 한다.
