포스트

Codex와 Claude Code 헤비 유저들 워크플로 보고 system-agents를 되돌아본다

Codex와 Claude Code 헤비 유저들 워크플로 보고 system-agents를 되돌아본다

앞 글에서 Codex 결제 결정을 위해 후기를 한 바퀴 돌았다. 돌다 보니 Codex와 Claude Code를 같이 쓰는 사람들이 대부분 멀티 에이전트 헤비 유저였다는 게 눈에 들어왔다. 운영 중인 오픈소스 두 개(system-agents-template, system-agents-plugins)를 그 흐름과 비교해두면 차용할 점이 보일 것 같아서 메모로 남긴다.

지금 시스템 위치

네 축에서 정리.

  • 병렬: 에이전트당 git worktree 격리
  • 외부 메모리: 작업 보드(봇이 채팅 메시지 파싱해서 자동 업데이트)
  • 오케스트레이션: 봇이 중재하는 턴제
  • 비동기 입력: 디스코드 listen 스크립트 상시 가동(사람의 메시지를 실시간으로 받아 처리)

이걸 기준으로 후기에서 본 풀이들과 비교해본다.

병렬

후기들의 표준은 에이전트당 git worktree 한 개씩이다. 같은 레포에 두 에이전트를 동시에 띄우면 8분 안에 git index가 깨졌다는 보고가 있고, oh-my-codex는 이 패턴을 worker 단위로 정형화해 30개 역할 특화 에이전트를 굴린다. system-agents-template는 이미 worktree 격리를 쓰고 있어 같은 자리. 차용보다는 worker 풀 크기와 역할 분화를 어디까지 가져갈지가 다음 질문이 된다.

tmux 차용 여부는 미정. 후기들에서 tmux는 사람이 한 화면에서 여러 에이전트 셸을 보는 UX를 푼다. 작업 보드 + 디스코드 채널로 푸는 영역과 어디서 겹치고 어디서 안 겹치는지 더 봐야 한다. 에이전트 셸 출력을 실시간으로 봐야 하거나 수동 개입 빈도가 높으면 도입이 의미 있을 텐데, 지금 그 빈도는 낮다.

외부 메모리

후기에서 보이는 패턴은 셋이다.

  • 각 에이전트 컨텍스트 안에 묻어두기(가장 흔하지만 토큰 비효율)
  • 셸 히스토리/세션 파일에 의존(workmux 같은 도구가 pane별로 가짐)
  • 잡 ID와 result 메타데이터에 보관(codex-plugin-cc의 /codex:status, /codex:result)

Anthropic Agent Teams는 한 세션이 팀 리드, 나머지는 독립 컨텍스트로 격리한다. 메모리는 리드의 컨텍스트와 서브에이전트 결과 메타로 분산.

system-agents-template는 작업 보드를 외부 메모리로 명시적으로 분리해두는 쪽인데, 잡 ID 기반 결과 추적은 약하다. codex-plugin-cc의 잡 ID + result 조회 패턴은 작업 보드 위에 결과 메타데이터 layer로 흡수해볼 만하다. 백그라운드 잡이 길게 도는 걸 띄워두고도 진행 상황과 결과를 시간 축으로 추적할 수 있게.

오케스트레이션

후기 도구들은 대체로 셋 중 하나로 푼다.

  • 비동기 큐: 워커가 큐에서 잡을 받아 처리. 처리량 우선
  • pane 자동 분할: workmux. 사람이 한 화면에서 여러 에이전트를 직접 보면서 결정
  • 팀 리드 위임: Anthropic Agent Teams. 한 세션이 다음 차례를 결정

system-agents-template는 봇이 중재하는 턴제로 다르게 푼다. 충돌이 안 생기지만 처리량이 낮다는 트레이드오프가 있다. 그리고 비동기 입력은 별도로 푼다. system-agents-plugins의 디스코드 플러그인이 listen 스크립트로 사람의 메시지를 상시 받아 처리하는 방식.

다음 진화 방향으로 고민하는 건, 사람의 디스코드 메시지를 받는 그 자리에 에이전트끼리도 자동으로 비동기 대화하게 만들어야 하나다. 그러면 턴제의 처리량 한계를 풀면서 작업 보드의 명시 기록은 유지할 수 있을 것 같은데, 토큰 비용과 충돌 해소가 따라온다.

에이전트 간 자동 비동기 대화 - 다른 사람들은 어떻게 푸나

토큰 효율 관점에서 자료 위치를 정리.

AutoGen GroupChat (Microsoft). 다중 에이전트가 한 채팅방에서 메시지를 주고받는 패턴. 라운드 로빈, 자동 선택, manager 모드 등 라우팅 옵션 제공. 토큰 비용으로 유명한 함정이 있다. 매 턴 전체 대화 히스토리를 모든 참여 에이전트가 받기 때문에 라운드가 길어질수록 비용이 제곱으로 늘어난다. 최근 버전은 summary memory로 압축해서 보내는 옵션을 더했지만 여전히 비싼 편.

CrewAI. 에이전트마다 역할과 목표를 정해두고 task를 위임. 위임 시 다른 에이전트의 출력만 컨텍스트에 넣는다(전체 히스토리가 아님). 토큰 효율은 AutoGen보다 좋지만 자유 대화는 거의 없고 task 위임 위주라 RPC에 더 가깝다.

LangGraph. 에이전트 간 통신을 그래프 노드 간 엣지로 모델링. 어떤 메시지가 어디로 가는지 명시적이고, 각 노드가 받는 컨텍스트를 개발자가 정확히 통제. 토큰 효율 가장 좋은 편. 자유 대화가 아니라 워크플로 정의에 가까워서 “자동 대화” 결은 약하다.

OpenAI Swarm 발상. 한 에이전트가 다른 에이전트에 handoff하면 컨텍스트 일부만 같이 넘김. 한 번에 한 에이전트만 활성. 모두가 모든 메시지를 보지 않는다. 토큰 효율 좋고, system-agents-template의 턴제와 발상이 비슷. 차이는 봇 중재가 아니라 에이전트 자체가 다음 턴을 결정한다는 점.

이 네 가지를 종합하면, 토큰 낭비를 줄이려는 시도들에서 공통 원칙이 보인다.

  1. 모든 에이전트에게 모든 메시지를 보여주지 않기 (AutoGen이 비싸진 이유)
  2. 컨텍스트 압축이나 요약을 봇이 처리해 다음 턴에 넘기기
  3. 명시적 handoff와 라우팅으로 결정 비용 줄이기
  4. 외부 메모리에 결과를 두고 컨텍스트에서는 빼기

system-agents-plugins의 디스코드 플러그인 입장에서 보면, 채널이 사람과 에이전트가 공유하는 메시지 버스라 1번 함정에 빠질 위험이 있다. 모두가 모든 메시지를 본다는 구조에 잘못 들어가면 토큰이 빠르게 빠진다. 4번(작업 보드 활용)은 이미 잘 풀고 있는 자리.

차용 가설

위 비교에서 system-agents에 흡수해볼 만한 발상 셋.

멘션 기반 명시 라우팅. CrewAI/LangGraph 식. 에이전트가 디스코드에 메시지를 던질 때 @강현명님 같은 멘션을 봇이 라우팅 신호로 받는다. 멘션된 에이전트만 새 메시지 컨텍스트로 받고, 다른 에이전트는 작업 보드 업데이트만 받는 식. 디스코드 채널은 사람용 가시성으로, 진짜 컨텍스트 전달은 보드와 라우팅으로 분리.

컨텍스트 압축은 봇이. 봇이 다음 에이전트에게 채널 히스토리를 그대로 주지 않고 작업 보드 요약 + 직전 멘션 메시지만 넘기는 식. 이미 작업 보드를 갖고 있어서 비교적 자연스럽게 도입 가능.

Swarm 식 handoff. 봇 턴제 결정에 더해 에이전트가 명시적으로 “다음은 X에이전트가 받아주세요”라고 선언하면 봇이 그대로 라우팅. 봇의 결정 부담을 줄이고 비동기성을 일부 허용.

핵심은 사람용 채널과 에이전트용 컨텍스트를 분리하는 발상이 들어가야 한다는 것. 디스코드는 사람이 보는 자리고, 에이전트가 다음 턴에 받는 정보는 그것의 부분집합이어야 토큰이 안 빠진다.

갈림길

이 비교를 정리하다 보면 한 갈래 갈림길이 보인다.

  • system-agents-template를 멀티 에이전트 오케스트레이션 전용으로 역할을 좁히고, 외부 메모리/RAG는 새 오픈소스로 분리할지
  • 한 레포 안에 어댑터 layer를 더해 흡수할지

오케스트레이션과 메모리가 한 시스템 안에 묶여 있어야 봇 라우팅이 작업 보드를 그대로 활용할 수 있고, 그러면 후자가 자연스럽다. 다만 외부 메모리/RAG 영역이 커지면 결국 분리해야 하는 시점이 온다. 이 결정은 차용 후보를 실제로 한두 개 도입해보고 정한다.

정확도 라벨

위 네 도구(AutoGen, CrewAI, LangGraph, Swarm) 비교는 후기와 공식 문서를 종합한 1차 정리다. 직접 써보고 검증한 건 아니다. 특히 AutoGen GroupChat의 “라운드 길어지면 비용 제곱” 같은 토큰 비용 주장은 후기 종합이라 실제 차용 전에 직접 측정해봐야 한다. 본격 차용 전에 각 도구의 라우팅과 컨텍스트 관리 코드를 한 번 더 읽어볼 생각이다.

참고 자료

system-agents

병렬과 worktree

오케스트레이션과 멀티 에이전트 프레임워크

codex-plugin-cc 잡 관리 패턴

이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.