에이전트가 하나일 때는 조율이 필요 없습니다. 하지만 오케이징, 낫징, 헤르메스처럼 여럿이 되면 "누가 언제 무슨 상태에 있는가"를 관리하는 구조가 필요합니다. 이 구조를 잘못 잡으면 에이전트들이 서로 모르는 채 작업을 중복하거나, 한쪽이 완료됐는데 다른 쪽이 모르는 상황이 생깁니다.
멀티 에이전트 조율에는 크게 여섯 가지 패턴이 있습니다. 오케이징 팀은 이것들을 비교한 끝에 지금의 구조를 선택했습니다.
중앙 허브 에이전트가 전문 에이전트들과 통신하는 구조입니다. 스포크 에이전트들은 허브를 통해서만 상호작용합니다. LangGraph에서 조건부 라우팅으로 자주 구현됩니다.
에이전트들이 순차 체인으로 연결됩니다. A가 처리하면 B에 넘기고, B가 처리하면 C에 넘기는 식입니다. CrewAI의 sequential process가 대표적입니다.
모든 에이전트가 접근하는 공유 지식 저장소에 읽고 씁니다. 에이전트들은 칠판 상태를 보면서 기여하고, 서로 직접 통신하지 않습니다. MCP 기반 협업 시스템에서 자주 등장하는 패턴입니다.
모든 에이전트가 같은 레벨에서 공유 메시지 스트림에 참여합니다. AutoGen의 GroupChat, OpenAI Agents SDK가 이 방식입니다. 에이전트들이 실시간으로 논쟁하고 협상합니다.
자율적이고 경량의 에이전트들이 분산 방식으로 조율합니다. 중앙 제어를 최소화하고, 에이전트가 handoff로 다른 에이전트에게 작업을 넘깁니다. OpenAI Swarm이 이 패턴의 대표 구현입니다.
공유 작업 큐(티켓/이슈)에 에이전트들이 접근합니다. 각 에이전트가 자신의 책임 영역 티켓을 선택하고 처리하며, 상태를 갱신해서 진행도를 추적합니다. GitHub Issues 기반 협업, Jira 자동화 워크플로우가 이 패턴입니다.
오케이징 팀의 구조는 Hub-and-Spoke와 Ticket 기반을 섞은 혼합형입니다.
진규 요청
→ 오케이징 (허브 — 프롬프트 번역 + 티켓 오픈)
→ 헤르메스 (구현)
→ 낫징 (리뷰)
→ 오케이징 (티켓 닫기 + 진규에게 알림)
오케이징이 허브로서 진규의 요청을 받고 에이전트들에게 분배합니다. 동시에 모든 작업 상태는 Discord 포럼 티켓에 쌓입니다. 채팅 채널에는 "~티켓에서 작업 열었어"같은 짧은 알림만 오갑니다.
사실 처음부터 티켓 구조를 의도한 건 아니었습니다. 채팅 채널에서 작업을 운영하다 보니 두 가지 문제가 반복됐습니다.
첫째, 컨텍스트 유실입니다. 오케이징 세션이 교체되면 "헤르메스가 어느 작업을 어디까지 했는지"를 채팅 히스토리에서 다시 찾아야 했습니다. 세션이 바뀌는 순간 맥락이 사라지는 구조였습니다.
둘째, 상태 추적 불가입니다. 작업이 몇 개 동시에 진행될 때 어떤 작업이 헤르메스 단계에 있고, 어떤 작업이 낫징 리뷰를 기다리는지 한눈에 안 보였습니다. 채팅 스크롤을 올려가며 찾는 방식은 에이전트 팀 운영에 맞지 않습니다.
티켓은 이 두 문제를 동시에 해결합니다.
상태가 채팅이 아닌 티켓에 있으면, 세션이 바뀌어도 티켓을 열면 됩니다.
오케이징이 다시 시작될 때 "지금 열린 티켓이 뭐가 있지?"라고 티켓 목록을 보면 현재 상황을 복원할 수 있습니다.
티켓 구조가 모든 상황에 맞는 건 아닙니다. 솔직하게 적어둡니다.
포럼 스레드 생성에 마찰이 있습니다. 오케이징이 Discord 포럼에 스레드를 여는 것 자체가 생각보다 번거롭습니다. Discord API 권한, user token vs bot token, 포럼 채널 특성상 일반 메시지와 스레드 생성이 다르게 동작하는 점 등이 초기 설정 난이도를 올립니다.
실시간 반응이 느립니다. 채팅에서 "지금 이 파일 고쳐줘"처럼 즉각적인 작업을 요청할 때도 티켓을 먼저 열어야 한다면 오히려 느립니다. 티켓 구조는 비동기 협업에 맞고, 즉각 응답이 필요한 단타 작업에는 오버헤드가 됩니다.
현재 운영 방침은 이렇습니다.
개발 작업은 티켓 필수, 단순 정보 확인이나 즉답성 질문은 채팅에서 처리.
모든 것을 티켓화하면 티켓 자체가 노이즈가 됩니다.
지금 가장 마찰이 큰 부분은 포럼 스레드 생성입니다. 오케이징이 자연스럽게 티켓을 만들 수 있도록 OpenClaw 쪽 자동화를 보완하거나, 사전 정의된 템플릿으로 스레드 생성을 간소화하는 것이 다음 단계입니다.
패턴 선택은 언제나 트레이드오프입니다. 지금 당장 맞는 구조가 팀이 커지면 바뀔 수도 있습니다. 에이전트가 더 늘어나거나 프로젝트 종류가 다양해지면 Swarm 이나 Blackboard 패턴이 더 맞을 수 있습니다. 지금은 티켓으로 가고, 그때 다시 검토합니다.