report HAN-376 asurada draft 2026-05-27

[HAN-376] 멀티 에이전트 작업 배정/완료 모니터링 채널 파일럿

TL;DR

---

1. 배경

HAN-376은 사용자의 다음 문제의식에서 출발:

> "현재 Slack 기반 업무 배정/AI 파이프라인이 안정적으로 이어지지 않아, 우선순위 높은 작업이 실제 담당자/페르소나에게 배정되고 완료까지 추적되는 루프가 약함."

(트리거 thread: hangmansplayground.slack.com/archives/C0B5KLB7DHR/p1779866314152439)

목표: 새 Slack 채널 파일럿으로 완수가 매니저 역할을 수행, 페르소나별 배정/상태/완료를 관리하는 운영안을 만들고 Claude Code로 즉시 구현 착수 가능한 수준까지 정리한다.

---

2. 현재 파이프라인 진단

2.1 내부 코드 조사 결과 (단정 사실)

항목위치현재 상태
완수 페르소나 정의`pantheon/personas/wansu.md`, `bridge.py:354`v1 **read-only 검토** 페르소나. "Codex-backed engineering lead for northstar strategy, execution planning, implementation risk, tickets, PRs, and verification loops" — 검토자 정체성
완수 자동 응답 채널`WANSU_AUTO_CHANNELS` (`bridge.py:140-141`)`#northstar`(`C0B5KLB7DHR`)가 기본. 트리거: untagged northstar-style prompt 또는 `!wansu` prefix
Spec Gate (승인 파이프라인)`spec_gate.py:1-100`, `bridge.py:117`Linear auto-discovery → `AGENT_APPROVALS_CHANNEL_ID` 브리핑 → 👍 반응 → `approved` 라벨까지 자동. **승인 이후는 사용자 사람-루프**
Jarvis 작업 인수`personas/jarvis.md:81-86`Linear fetch → state 변경 + 댓글 "[Jarvis] 작업 인수". 인수 후 진행/완료는 자유 텍스트
위임 마커`pantheon/README.md:17``[DELEGATE: CONTEXT: ]` — **free-form text**, 컨텍스트 4-field 강제 없음
Nano 구현`bridge.py:352` (prompt만)"parallel task orchestration, batch processing" 정의는 있으나 **실제 orchestration 코드 미존재**
완료 추적—**찾지 못함**. 페르소나 완료 후 상태 회수·표시 로직 없음
모니터 채널`MONITOR_CHANNEL_ID` (`bridge.py:615,661,711`)선택적 채널, 자동 정기 알림 없음 — 수동 사용

2.2 6가지 갭

내부 fact를 외부 1차 출처(다음 섹션)와 대조하면 다음 갭이 보임:

1. 승인-실행 단절

Spec Gate가 approved 라벨까지만 만들고 다음 책임자가 자동 지정되지 않는다. 사용자가 사람-루프에서 매번 "이거 누가 한다"를 결정.

2. 위임 컨텍스트 비표준

[DELEGATE] 마커는 자유 문구. Anthropic Lead Researcher가 명시한 4-field 강제(objective / output_format / tools-sources / boundaries) 부재. Anthropic이 실제로 겪은 실패 패턴("research the semiconductor shortage" 식 모호 지시 = subagent 간 중복 작업)에 정면 노출.

3. 상태 비가시

진행/완료/blocked 상태가 채널에서 보이지 않음. Devin Slack 통합이 이모지 마커로 in-place 노출하는 패턴이 부재. 사용자가 매번 polling.

4. 완료 판정 부재

페르소나가 "끝났다" 자유 문장 한 줄을 남기는 수준. SWE-agent의 표준 종료 사유 5종(submit / context-exceeded / cost-exceeded / max-retries / timeout) 같은 enum이 없어 사용자가 다음 결정(승인/재시도/escalation)을 자동화할 신호가 없음.

5. 권한 boundary 미정의

Factory Droid의 autonomy tier(low/medium/high)가 부재. Nano/Raphael/Jarvis/완수가 어떤 액션까지 자율적으로 할 수 있는지 명문화 안 됨 → 사용자가 매번 권한 가드.

6. 매니저 역할 공백

완수는 검토자 정체성, Jarvis는 자기 작업 인수자, Spec Gate는 데몬 — 누가 "다음 작업을 누구에게 줄 것인가"를 결정하는 주체가 사람(사용자) 1인.

---

3. 외부 패턴 1차 출처 종합

3.1 매니저 패턴

패턴핵심 1차 출처 인용
AutoGen `GroupChatManager``speaker_selection_method`(auto/manual/random/round_robin) + `max_round`. 상태는 별도 enum 없이 message log = 상태
Anthropic Lead Researcher**위임 4-field 강제** (objective / output / tools / boundaries) + **External Memory 분리** + "현재 lead가 subagent를 **synchronous로 기다린다**" (한계 정면 인정)
LangGraph supervisor`create_handoff_tool` — 위임을 명시적 tool call로. `output_mode` (full_history vs last_message)
OpenAI Swarm handoffAgent function이 다른 Agent return → control 이전, history 유지

3.2 AI 코딩 에이전트 작업 큐

제품핵심 1차 출처 인용
Cognition Devin**Interactive Planning** = plan-as-checkpoint. Slack 통합에서 **이모지로 run 완료/실패 마킹**. 2025 perf review: "작업 시작 후 mid-task 변경 = 성능 저하" → scope-up-front
SWE-agent5종 표준 종료: `submit / ContextWindowExceeded / CostLimitExceeded / max_requeries / max_consecutive_execution_timeouts`
Copilot WorkspaceTask → Spec → Plan → Implementation 4단계, **파일 단위 queued→in-progress→completed** 우측 패널
Factory Droid `droid exec``--auto low\medium\high` autonomy tier. exit code 0/non-zero. 권한 초과 시 즉시 halt

3.3 합성된 5개 원칙

1. 위임 패킷 표준화 — 4-field 강제 (Anthropic)

2. Plan-as-checkpoint — execution 전 사용자 ack 차단 (Devin, Copilot Workspace)

3. 이모지/in-place 상태 마커 — 채널이 곧 큐 뷰 (Devin Slack, Copilot Workspace queued→in-progress→done)

4. 표준 종료 사유 enum — 다음 액션 자동화 신호 (SWE-agent)

5. Autonomy tier per persona — 권한 boundary 사전 정의 (Factory)

---

4. 대안 비교

대안 A: 완수 v2 — 매니저 풀스택 페르소나로 확장

대안 B: 새 매니저 페르소나 "PM" 도입, 완수는 검토 유지

대안 C: 매니저를 페르소나가 아닌 백그라운드 데몬으로 (spec_gate v2)

비교 표

축A: 완수 v2B: 신규 PMC: spec_gate 데몬
Slack 앱 한도 부담없음**큼**없음
페르소나 정체성 정합**높음**중간(신규 학습)낮음
사용자 비전 정합 (팀 운영)**높음**높음낮음
구현 복잡도중간큼작음
실패 격리중간**높음**높음
매니저와 대화 가능성가능가능약함

---

5. 추천안: 대안 A (완수 v2 매니저 모드)

5.1 결정 근거

1. 사용자 비전과의 정합: user_multi_llm_vision 메모리 — "LLM을 팀처럼 운영, 페르소나/역할 배정". 매니저는 페르소나여야 자연.

2. 인프라 재사용: Slack 앱 한도 임박 상태(project_slack_integration_limit)에서 신규 앱 추가는 비용. 완수는 이미 토큰·핸들러·Codex 권한 보유.

3. 완수 정체성 자연 확장: 현 정의가 "engineering lead for execution planning" — execution coordination은 정체성 확장이지 변경이 아님.

4. 실패 격리 책임 분리: Spec Gate(enqueue) ↔ 완수(dispatch/추적/회수) 책임을 코드 차원에서 분리. spec_gate.py는 그대로, 완수에 새 핸들러 추가.

5.2 책임 분리 도식

```

[Linear auto-discovery]

↓

[Spec Gate 데몬] ─── 라벨 변환 + 채널 브리핑 + 👍 처리 ───┐

↓ │

[approved 라벨] │

↓ │

[완수 매니저] ── (1) 작업 카드 생성: #pantheon-ops 채널 │

│ (2) 4-field 위임 패킷 생성 │

│ (3) DELEGATE 마커로 worker 호출 │

│ (4) in-thread parent message in-place edit │

│ (5) 표준 종료 enum 수신·회수 │

↓ │

[Worker: Jarvis/Raphael/Nano] ── 실행 + 상태 이모지 + 종료 enum

↓

[완수] ── (6) 사용자 escalation 또는 다음 작업 dispatch

```

5.3 위임 4-field 표준 패킷

```

[DELEGATE: ISSUE: TIER:

OBJECTIVE: <한 줄 결과 기술>

OUTPUT: <산출물 형식 — 예: PR / Linear 코멘트 / Notion 페이지>

TOOLS: <허용 도구 — 예: gh, Linear MCP, WebSearch>

BOUNDARIES: <스코프 외 — 예: DB 마이그레이션 금지, prod 배포 금지>

RETURN_BY: <표준 종료 enum 중 하나로 응답>

]

```

기존 자유 문구 [DELEGATE: target CONTEXT: text] 마커는 v1 호환으로 유지하되, 매니저 모드에서 발송되는 패킷은 4-field 표준 강제.

5.4 표준 종료 사유 enum (SWE-agent 차용)

코드의미다음 액션 (완수 자동)
`submit`산출물 완성, PR/코멘트 첨부parent message ✅ 마킹 + 사용자 승인 대기
`blocked-need-input`사용자 입력 필요parent message 🚫 + 사용자 멘션 + 작업 대기 큐
`cost-exceeded`토큰/시간 임계 초과parent message ❌ + 종료 사유 첨부 + retry 옵션 제시
`max-retries`자체 재시도 한계parent message ❌ + trajectory 요약 + 사용자 escalation
`scope-violation`위임 boundary 초과parent message ❌ + 위반 액션 첨부 + 사용자 escalation

---

6. Slack 채널 운영 절차

6.1 새 채널 `#pantheon-ops`

- #pantheon-alerts (C0B5VDF3JTS): 에러·CRITICAL 로그 모니터링 — 유지

- #northstar (C0B5KLB7DHR): 완수 검토·전략 대화 — 유지 (v1 정체성 보존)

- #pantheon-ops (신규): 작업 dispatch·진행·완료 — 본 파일럿 채널

6.2 작업 카드 생애주기

1. enqueue (Spec Gate → 완수)

approved 라벨이 붙은 Linear 이슈 → 완수가 #pantheon-ops에 parent message로 작업 카드 포스팅:

```

📋 [LIN-XXX] <이슈 제목>

상태: queued

담당: (미배정)

우선순위:

추정:

```

2. dispatch (완수 → worker)

완수가 worker를 결정하고 in-thread에 4-field 위임 패킷 발송. parent message in-place edit:

```

📋 [LIN-XXX] <이슈 제목>

상태: in-progress ⏳

담당: @raphael

...

```

3. progress (worker → 채널)

Worker가 in-thread에 진행 메시지 + 이모지 (⏳, 🚫 blocked, 🔍 investigating). 30분 이상 idle 시 완수가 status check 멘션.

4. complete (worker → 완수 → 채널)

Worker가 in-thread에 표준 종료 enum + 산출물 링크. 완수가 parent message in-place edit:

```

📋 [LIN-XXX] <이슈 제목>

상태: ✅ submit

담당: @raphael

PR: github.com/.../pull/XXX

완료: 2026-MM-DD HH:MM

```

5. escalation (필요 시)

blocked-need-input / max-retries / scope-violation 시 완수가 사용자 멘션 + 트레이스 요약 첨부.

6.3 채널 노이즈 제어

---

7. 페르소나별 작업 배정·상태·완료 기준

7.1 Autonomy tier 정의 (Factory droid 차용)

페르소나Tier허용 액션금지 액션
Nano**low** (read-only)조사·요약·분석, Linear 코멘트 read, WebSearch코드 수정, commit, PR, 상태 변경
Raphael**medium** (write)코드 수정, commit, 브랜치 push, Linear 코멘트 writePR merge, prod 배포, secrets 변경
Jarvis**high** (merge)PR 생성·merge, 자동 배포 trigger, Linear status 변경secrets 변경, DB 마이그레이션 (사용자 ack 필요)
완수 (매니저 모드)**meta** (coordination)작업 dispatch·재배정·escalation, parent message edit직접 코드 작업 (worker에 위임)
완수 (검토 모드, `#northstar`)**low**검토·전략 자문코드 작업

7.2 작업 → 페르소나 배정 룰 (완수 dispatch 의사결정)

7.3 상태 필드 정의 (완수 매니저가 추적)

필드타입출처
`card_id`Slack message_ts완수 생성 시
`linear_id`string (HAN-XXX)enqueue
`assignee`persona enumdispatch
`state``queued`/`in-progress`/`blocked`/`complete`/`failed`worker 신호 + 완수 갱신
`tier_used``low/medium/high`dispatch
`exit_code`표준 종료 enumworker 회수
`artifact_url`URL (PR/코멘트/문서)worker 회수
`escalations`int완수 카운트

영속 저장소: 우선 in-memory dict (페르소나 프로세스 메모리) + Linear 코멘트로 백업. 파일럿 안정화 후 SQLite 또는 별도 JSON 영속화 검토 (spec_gate_pending.json 패턴 참고).

7.4 완료 기준 (Definition of Done)

조건검증
Worker가 `submit` enum으로 회수exit_code = submit
산출물 링크 첨부artifact_url != null
Linear 이슈 상태가 `In Review` 또는 `Done`Linear API 조회
완수가 parent message ✅ in-place editSlack message 검증
사용자 명시 ack 또는 30분 무반응 (자동 close)reaction 또는 timeout

5개 모두 true일 때 카드 close. 하나라도 fail이면 매니저가 자동 재dispatch 또는 사용자 escalation.

---

8. 리스크와 중단 조건

8.1 식별된 리스크

리스크영향완화
완수 prompt 비대 (v1 검토 + v2 매니저)응답 품질 저하매니저 모드는 `#pantheon-ops`에서만, system prompt 채널별 분기
Anthropic synchronous 한계 (완수가 worker 대기로 병목)dispatch 처리량 저하완수는 polling 아닌 **이벤트 트리거** (worker 메시지 reaction/marker로 깨어남)
In-place edit 누락 (state 표시 불일치)사용자 신뢰 손실`chat.update` 실패 시 새 메시지 + 이전 메시지 strikethrough fallback
Worker가 종료 enum 무시 (free-form 회수)매니저 자동화 신호 손실worker system prompt에 enum 강제 + 미인입 시 완수가 한 번 재질의
Dispatch hallucinate (없는 Linear ID에 위임)작업 손실enqueue 시 Linear API 사전 검증 + linear_id로 사후 조회 검증
페르소나 권한 boundary 초과scope 위반autonomy tier prompt 강제 + 완수가 `scope-violation` 인입

8.2 중단 트리거 (파일럿 2주 평가)

다음 중 하나라도 발생 시 파일럿 중단 + 회고:

1. In-place edit 실패율 > 5% (Slack chat.update 응답 카운트)

2. 종료 enum 미인입 비율 > 20% (worker 응답 중 free-form 회수 비율)

3. 매니저 hallucinate dispatch 발생 (Linear에 없는 이슈 ID로 위임)

4. 사용자 명시 피드백: "오히려 더 번거롭다" 또는 동등 의사

5. 비용 임계 초과: 완수 매니저 모드 일일 토큰이 v1 검토 모드 대비 5x 초과

평가 채널: #pantheon-ops thread + Linear HAN-376에 회고 코멘트.

8.3 롤백 절차

1. 완수 WANSU_MANAGER_MODE=false 환경변수로 v1 검토 모드 단독 동작 복귀

2. #pantheon-ops 채널 archive (메시지 보존)

3. 매니저 dispatch 핸들러 bridge.py import 해제 (코드는 보존, 환경변수로 dormant)

4. Linear HAN-376에 회고 + 잠재 대안 C(데몬화) 재검토 트리거

---

9. Claude Code 구현 지시문

> 본 섹션은 /spec HAN-XXX 또는 /implement 직행으로 변환 가능한 수준의 작업 분해. 각 작업은 독립 PR 가능.

9.1 작업 분해

#### W1: 채널 셋업 (Infra)

- [ ] 채널 ID가 .env + bridge.py config에 반영

- [ ] 4개 bot이 멤버

- [ ] WANSU_AUTO_CHANNELS에 채널 ID 추가

#### W2: 완수 매니저 모드 prompt 분기

- [ ] #pantheon-ops 채널에서 완수가 매니저 모드 prompt를 로드

- [ ] 4-field 위임 패킷 발송 규칙이 prompt에 포함

- [ ] 표준 종료 enum 5종이 prompt에 명시

- [ ] #northstar에서는 기존 v1 검토 prompt 그대로

#### W3: 작업 카드 생애주기 핸들러

- [ ] spec_gate.py의 approved 라벨 인입 → 완수가 작업 카드 parent message 포스팅

- [ ] Worker의 종료 enum 인입 → 완수가 parent message in-place edit

- [ ] in-thread Worker 진행 이모지 / blocked 신호 인식

- [ ] in-place edit 실패 시 fallback (새 메시지 + strikethrough)

#### W4: 위임 4-field 패킷 발송기

- [ ] 4-field(objective/output/tools/boundaries) 모두 채워진 경우만 발송

- [ ] 누락 시 완수가 사용자에 멘션해 보강 요청

- [ ] Worker 페르소나 system prompt에서 4-field 패킷 인식 룰 추가

- [ ] 기존 [DELEGATE: target CONTEXT: text] v1 마커는 호환 유지

#### W5: 표준 종료 enum 회수기

- [ ] 5종 enum (submit/blocked-need-input/cost-exceeded/max-retries/scope-violation) 정규식 파싱

- [ ] enum별 자동 액션 (✅ 마킹 / 🚫 사용자 멘션 / ❌ 트레이스 요약)

- [ ] enum 누락 시 한 번 재질의, 그래도 누락이면 free-form으로 처리하되 메트릭 카운트

#### W6: Autonomy tier 가드

- [ ] Nano = low / Raphael = medium / Jarvis = high / 완수 = meta 정의

- [ ] Worker가 tier 초과 액션 시도 시 자체 scope-violation enum으로 종료

- [ ] 완수가 dispatch 시 작업 tier ≤ 페르소나 tier 검증

#### W7: 상태 영속화 (in-memory + Linear 코멘트 백업)

- [ ] 8개 필드 (card_id/linear_id/assignee/state/tier_used/exit_code/artifact_url/escalations) 관리

- [ ] 페르소나 프로세스 재시작 시 Linear 코멘트에서 복원

- [ ] 30분 idle worker 자동 status check

#### W8: 메트릭·중단 트리거 모니터링

- [ ] 4개 메트릭 카운터 + 임계 비교

- [ ] 임계 초과 시 #pantheon-alerts에 CRITICAL 알림

- [ ] 일일 요약 (자동 daily brief)

9.2 작업 순서·의존

```

W1 (채널 셋업) ─┐

├─→ W2 (prompt 분기) ─→ W3 (생애주기 핸들러) ─→ W4 (위임 패킷)

│ │

W6 (autonomy) ──┴─→ W5 (종료 enum) ──────────────────────────────┤

│

W7 (영속화) ─────────────┤

↓

W8 (메트릭) ─────────→ 파일럿 운영

```

W1→W2→W3가 critical path. W4·W5·W6은 W3 진입 후 병렬 가능. W7·W8은 W5 완료 후 진입.

9.3 SDD 진입 권장

9.4 파일럿 운영 시작 조건

W1·W2·W3·W5만 완료되어도 최소 운영 가능. W4·W6·W7·W8은 운영 중 점진 추가 OK. 단 W3 in-place edit fallback 없이는 시작 금지 (사용자 신뢰 손실 리스크).

---

10. 참고 자료

1차 출처

내부 참조

관련 메모리

트리거 thread