역할 구분 — 누가 할 것인가

Supervisor–Worker 워크플로우에서 가장 되돌리기 비싼 분기다. 여기서 잘못 가르면
결과물을 아무리 고쳐도 안 된다 — [[work-review]]의 "NO 재설계"가 되돌아오는 지점이
바로 여기다.

판단 기준 — 한 줄

결과물이 프로젝트의 구현 코드 자산인가.

그렇다면 Codex. 아니라면 관리자. 애매하면 위임한다(관리자가 코드를 붙들고 있는 쪽이
더 자주 사고가 난다).

배분표

관리자(Claude)가 직접	Codex에게 위임
아키텍처·설계, 계획 수립	정밀 코드 생성, 모듈 고속 구현
작업지시서 작성([[task-brief]])	학습·평가 스크립트, 파이프라인
맥락 종합·조율·우선순위	반복 확장(뼈대가 잡힌 뒤의 N건)
결과 검수([[work-review]])	대규모 실행·벤치마크
전략 문서·진행상황([[progress-log]])	코드 레벨 문서(README·주석)
외부 게시(구글독스 등)	적대적 검증·테스트 작성

예외 — 문서 변환용 소규모 스크립트, 분석을 위한 즉석 조회는 관리자가 직접 해도 된다.
프로젝트에 남는 자산이 아니기 때문이다.

가르기 전에 확인할 것

1. 결정이 남아 있지 않은가. 아키텍처·데이터셋·모델·범위 중 미정인 것이 있으면
   가르지 말고 사용자에게 먼저 올린다. 미정 상태로 넘기면 실행자가 대신 정해버린다
   ([[task-brief]] §0).
2. 뼈대와 확장이 섞여 있지 않은가. 판단이 많이 섞인 뼈대는 관리자가 잡고,
   반복 확장만 넘긴다. 통째로 넘기면 되돌리는 비용이 직접 짜는 비용보다 크다.
3. 되돌릴 수 없는 일이 포함돼 있지 않은가. 삭제·배포·외부 전송은 넘기지 않거나
   --sandbox로 막는다.
4. 한 덩어리로 넘길 수 있는 크기인가. 완료 기준을 검증 가능한 형태로 쓸 수 없다면
   아직 너무 크다. 쪼갠다.

재설계로 돌아왔을 때

검토에서 NO 재설계가 나왔다면 결과물이 아니라 이 배분이 틀렸다는 뜻이다.
같은 배분으로 다시 넘기지 않는다. 다음을 의심한다.

• 관리자가 잡았어야 할 뼈대를 통째로 넘겼다 → 뼈대를 직접 잡고 확장만 재위임
• 결정이 안 된 채로 넘겨서 실행자가 대신 정했다 → 사용자에게 올려 결정부터
• 범위가 너무 커서 완료 기준이 모호했다 → 쪼개서 재위임
• 애초에 위임할 일이 아니었다 → 관리자가 직접

연계

• 가른 뒤 Codex 몫은 [[task-brief]]로 지시서를 쓰고 [[codex-delegate]]로 넘긴다
• 돌아온 결과는 [[work-review]]로 검토한다

이력 (필수 기록)

• 생성일: 2026-08-27
• 업데이트 횟수: 0
• 사용 이력:
  • 2026-08-27 — 확정된 워크플로우 정의(docs/workflows/supervisor-worker.md)를 스킬과 대조하다
    C(역할 구분) 노드에만 담당 스킬이 없는 것이 확인되어 신설. 판단 기준 자체는
    codex-delegate §권한경계에 산문으로 묻혀 있었는데, 역할을 가르려는 시점에
    그 스킬을 열 이유가 없어 실질적으로 사문화돼 있었다.