Tec-Blog Technology & DevOps

AI Kim, DongKi

Kanban으로 멀티에이전트 업무 분해하기

TL;DR

  • 멀티에이전트에서 제일 자주 깨지는 건 모델 성능이 아니라 누가 무엇을 끝까지 가져가는지다.
  • Kanban을 상태 머신 + 의존성 그래프로 쓰면, 오케스트레이터는 “쪼개고 넘기고”, 워커는 “실행만” 하면 된다.
  • 핵심 키는 세 개다. 상태(status), 담당(assignee/profile), 부모→자식(parents).
  • 코딩 에이전트 함대(Orca)나 Hermes 프로필을 여러 개 돌릴 때, 보드 없이 채팅만으로 분해하면 금방 꼬인다.

들어가며

에이전트를 둘 이상 켜면 대화가 늘고, 맥락이 갈라지고, “누가 이 PR을 끝까지 가져가지?”가 사라진다.
나는 이 문제를 LLM 프롬프트로만 풀려다 실패했고, 일을 카드로 만들고 상태를 강제하는 쪽으로 넘어갔다.

이 글은 특정 제품 이름이 아니라, Kanban으로 멀티에이전트 업무를 분해하는 일반 패턴만 정리한다.
앞선 Orca ADE 함대 운영, Hermes 소개 글의 “실행 UI / 게이트웨이” 다음에 오는 업무 라우팅 편이라고 보면 된다.

1. 보드를 상태 머신으로 보기

에이전트용 보드는 “포스트잇 느낌”보다 상태 전이가 중요하다. 내가 쓰는 최소 상태는 대략 이렇다.

  • todo — 생겼지만 아직 준비 안 됨 (부모 미완료, 스펙 부족)
  • ready — 지금 집어가도 됨
  • running — 워커가 실행 중
  • blocked — 사람 입력 / 권한 / 외부 의존으로 멈춤
  • review — 결과 검수 대기 (코딩이면 diff·테스트 확인)
  • done — 핸드오프 완료

중요한 건 에이전트가 마음대로 done을 찍지 못하게 하는 규칙이다.
예: 코드 변경은 review를 거치거나, 오케스트레이터만 complete를 허용하는 식.
상태 이름이 달라도 괜찮다. 다만 ready → running → (blocked|review) → done 흐름이 없으면 병렬 워커가 서로를 밟는다.

2. 분해는 오케스트레이터, 실행은 워커

멀티에이전트에서 역할을 안 나누면 모두가 “조금 짜고 조금 계획”한다.
나는 역할을 이렇게 고정한다.

  • 오케스트레이터(분석/라우팅 프로필)
    • 큰 목표를 읽고 카드로 쪼갠다
    • assignee를 워커 프로필에 붙인다
    • 의존성(parents)을 건다
    • 본인은 파일 수정·커밋을 하지 않는다
  • 워커(코딩/실행 프로필)
    • 자기 카드 하나만 본다
    • 워크스페이스 안에서 구현·검증한다
    • 막히면 blocked + 이유, 끝나면 요약·산출물 경로를 남긴다

채팅 한 줄에 “이거 분석하고 코드도 짜고 PR도 열어”를 넣으면, 모델이 잘해도 핸드오프가 없다.
보드에 올리는 순간부터 “다음 에이전트가 읽을 계약”이 생긴다.

3. parents로 파이프라인 만들기

단순 나열(카드 A, B, C)은 병렬로 터진다.
실제로 필요한 건 의존 그래프다.

[스펙 정리] ──┐
              ├──► [구현] ──► [리뷰]
[테스트 픽스처]┘

표현은 도구마다 다르지만 개념은 같다. 자식은 부모가 전부 done일 때만 ready.
그러면 구현 워커가 스펙 없이 추측 코딩을 덜 하고, 리뷰 카드는 구현이 끝나기 전에 뜨지 않는다.

실무에서 자주 쓰는 fan-out / fan-in 패턴:

  1. 조사 카드 2~3장을 서로 다른 assignee에
  2. 조사들이 끝나면 합성(synth) 카드 1장
  3. 합성이 끝나면 구현 카드

오케스트레이터의 일은 “똑똑한 한 방 답”이 아니라 이 그래프를 맞게 그리는 것이다.

4. assignee = 프로필(실행기)

카드의 assignee는 사람 이름이 아니라 실행 런타임에 가깝다.

  • 분석·분해만 하는 프로필
  • Cursor ACP / Claude Code처럼 코딩에 강한 프로필
  • (선택) 하드한 리팩터만 맡는 전용 코더 프로필

라우팅 휴리스틱은 단순할수록 덜 망한다.

  • 파일 대량 수정·테스트·PR → 코더 프로필
  • 조사·문서·분해·검수 지시 → 오케스트레이터 / 제너럴리스트

여기서 한 가지 운영 팁.
디스패처(스케줄러)는 오케 프로필 게이트웨이 한곳만 돌리고, 워커 프로필은 “spawn만” 받게 두면 이중 스윕이 줄어든다.
여러 게이트웨이가 같은 보드를 동시에 쓸어가면, 같은 카드가 두 번 running으로 들어가기 쉽다.

5. 카드 바디에 넣을 것 / 빼 것

워커는 대화 히스토리를 모른다. 카드가 곧 스펙이다.

넣으면 좋은 것:

  • 목표 한 줄 + 완료 조건(Acceptance)
  • 건드릴 경로 / 건드리면 안 되는 경로
  • 검증 방법 (build, 스모크 URL, 체크리스트)
  • 산출물 위치 (리포트 경로, PR 링크 자리)

빼야 하는 것:

  • 장황한 대화 복붙
  • 시크릿·토큰
  • “알아서 잘” 같은 열린 지시만 있는 본문

막히면 워커는 추측으로 밀지 말고 blocked 이유 한두 문장을 남긴다.
사람(또는 오케)이 답을 카드에 달아주면 다시 ready로 올린다. 이게 채팅 멘션 루프보다 훨씬 싸다.

6. 최소 운영 루프

내가 반복하는 하루 루프는 이렇다.

  1. 큰 요청이 오면 오케가 보드에 부모 카드 + 자식 카드를 만든다
  2. 디스패처가 ready + assignee 맞는 워커만 깨운다
  3. 워커는 running → (작업) → done 또는 blocked
  4. 부모가 모두 done이면 다음 자식이 ready
  5. 사람/오케가 review 카드를 보고 병합·후속 카드를 만든다

Discord 같은 채널은 알림면, 보드는 진실의 원천으로 둔다.
알림만 보고 채팅에서 일을 이어가면 다시 맥락이 증발한다.

마치며

멀티에이전트는 “모델 여러 개”가 아니라 역할·상태·의존성을 강제하는 운영 문제에 가깝다.
Kanban을 그 강제 장치로 쓰면, 오케스트레이터는 분해에 집중하고 워커는 실행에 집중한다.

다음에 이을 글감으로는 실제 시드 학습 루프(Q-LoRA)나, LoRA/Q-LoRA 차이처럼 한 카드 안에서 끝나는 기술 주제도 있지만,
에이전트를 둘 이상 굴린다면 먼저 이 보드 규약을 맞추는 편이 이득이다.

관련 글: Orca ADE 함대 운영 · Hermes cron 자동화 · SOUL.md로 행동 규칙 강제

Comments