무엇인가
이슈 번호를 넘기고 시작할 때 한 번만 답하면,
그다음에는 머지까지 끝났다는 최종 보고만 받는다.
계획 리뷰, 결과 검수, 워커 지휘를
Claude Code 스킬 셋으로 묶어 만든 흐름이다.
개정은 실제 런에서 부딪힌 문제를 스킬에 되먹이는 방식으로 이어졌다
(이 내용은 커밋 본문에 적힌 이유를 모아 읽고 정리한 것이다).
이 스킬 셋의 이름은 검수·지휘 스킬이고 세 스킬은 각각 호출하는 시점이 다르다.
워커는 이슈마다 따로 만든 작업 사본(워크트리)에서
일하는 Claude Code 세션이고
코디네이터는 워커를 띄우고 검수하는 세션이다.
| 스킬 | 부르는 때 | 하는 일 |
|---|---|---|
| plan-review | 스펙과 티켓을 쓴 직후 | 판정(PASS / CONCERNS / FAIL)과 보고서만 낸다 |
| super-auto | 이슈 번호나 대화 맥락을 넘길 때 | 워커를 띄워 검수, PR(풀 리퀘스트), 머지, 정리까지 돈다 |
| final-review | 워커가 변경을 만든 뒤 | Spec 대조, 버그, 보안 리뷰를 거쳐 확정된 결함만 고친다 |
워커를 띄우는 도구는 Orca다.
Orca는 워크트리와 터미널을 orca CLI로 다루는 앱이고
super-auto는 이 CLI로 이슈별 워크트리를 만들고
워커가 보내는 완료·질문 메시지를 받는다.
왜 만들었나
스킬을 만들기 전에도 같은 일을 손으로 하고 있었다.
이전 PC의 Claude Code 입력 기록 9,696행을 보면
2월 19일부터 4월 26일 사이에 /smartplan 으로 시작한 입력이 75행,
/sp 16행, /smartreview 30행, /review 5행이다.
9월 초에는 이슈 단위로 워커에게 일을 나눠 맡기는 Orca 런을
스킬 없이 돌렸다. 그 런의 목적 문구 끝에는 "팀장 없음"이라고 적혀 있다.
문제는 리뷰 스킬들이 서로 따로 실행됐다는 점이다.
9월 23일에 나는 이렇게 물었다.
"스킬이 산발적으로 돌아가는데, 스킬체이닝을 하나의스킬로 묶을수있나?"
같은 세션에서 리뷰는 맥락 없는 서브에이전트에게 맡기고 싶다고 했고
스킬 생성 계획을 Opus 5.5에게 리뷰시키면서 이렇게 덧붙였다.
"하이쿠가 스폰되지않도록 조심해. 클린컨텍스트."
그날 저녁 final-review가 첫 커밋으로 들어왔다.
지휘 방식은 사흘 뒤 smartthink 작업에서 자리를 잡았다.
코디네이터 역할을 맡은 세션에 나는 이렇게 직접 입력했다.
"나한테 물어볼거없이 잘 판단해서 진행시키고 최종 완료보고만 나한테"
그 런에서 검증한 흐름이 다음 날 super-orchestration으로 커밋됐고,
10월 8일에 super-auto로 이름을 바꾸면서
대화 맥락이나 플랜 파일을 이슈로 확정하는 intake 단계를 넣었다.
어떻게 동작하나
내가 맡는 일은 시작 직후 한 번 답하는 것과 최종 보고를 읽는 것이다.
그때 받는 질문은 final-review를 돌릴지 여부 하나다.
나머지는 이 순서로 돈다.
- 스펙을 쓰면 plan-review가 섬세 모드로 본다.
- 티켓으로 쪼개면
--set가벼운 모드로, 쪼개는 과정에서 생기는 결함만 본다. - super-auto가 이슈마다 워크트리 워커를 띄운다.
- 워커가 끝나면 코디네이터 검수와 /final-review를 거친다.
- 판정을 통과하면 PR, 머지, 정리를 마치고 최종 보고를 쓴다.
이 루프는 Claude Code의 /loop로 끝까지 돈다.
이슈가 네 개 이상이면 새로 띄운 코디네이터 워커가 루프를 맡고
스킬을 실행한 세션은 시작 질문, 이슈화, 감시, 최종 전달만 맡는다.
판정은 계획을 쓴 쪽이 내리지 않는다.
plan-review에서는 새 컨텍스트의 Opus 리뷰어와 Codex(gpt-6.1-sol)가
서로의 결과를 모르는 채로 같은 기준에 따라 검토하고
판정은 Opus가 확인한 지적만을 근거로 스크립트가 낸다.
계획을 쓴 세션이 판정까지 하면 작성자 편향이 생긴다고 커밋에 적었다.
리뷰어 구성을 바꿔 가며 측정한 결과는 별도의 글로 썼다.
리뷰어를 늘려도 판정은 그대로였다
final-review도 같은 원칙을 따른다.
세 리뷰를 맥락 없는 서브에이전트가 차례로 수행하고
부모 세션은 확정(CONFIRMED)된 결함만 고친다.
리뷰어는 opus를 명시해 띄우고
리뷰가 끝난 뒤에는 세션 기록의 모델 필드를 보고 정말 Opus였는지 확인한다.
Codex 교차 리뷰의 지적은 Opus verifier를 거쳐야 채택되며
이 단계를 붙인 계기는 GitHub 자동 코드 리뷰였다.
보지도 않은 리뷰가 주간 사용량 19%를 썼다
워커 모델은 Sonnet high에서 시작해 막히면
Opus medium, Opus max 순으로 올리고
그래도 해결되지 않으면 BLOCKED로 둔다.
10월 11일에는 이렇게 목표를 못 박았다.
"웬만하면 전자동으로 머지까지 수행하는게 목표야. 에이전틱플로우."
그래서 이슈 번호를 넘긴 것 자체가 곧 승인이고
BLOCKED는 런 안에서 기술적으로 처리할 수 없는 일에만 쓴다.
스킬 폴더를 건드린 커밋 55개(머지 커밋 제외, 옛 이름 폴더 포함)에는
전부 Co-Authored-By 줄이 붙어 있다.
Opus 5.5가 47개, Sonnet 5.5가 8개다. 내가 맡은 몫은 설계와 판정 기준이다.
써 보니
한 달이 채 안 되어 이 흐름이 내 기본 작업 경로가 됐다.
9월 25일부터 10월 18일까지 맥의 Claude Code 세션 원문에서
사용자 입력 칸에 /final-review가 들어간 횟수는 140회(세션 124개)다.
이 값은 코디네이터가 워커 터미널에 입력한 명령까지 포함해 센 것이다.
Orca 런 원장에는 9월 23일부터 10월 18일 17시(UTC)까지
만든 런이 53개 있고,
그중 40개의 목적 문구에
super-orchestration이나 super-auto가 적혀 있다.
40개 가운데 27개는 내 다른 프로젝트인 Hindsight-Crew의 런이다.
9월 23일부터 10월 18일 15시(UTC) 전까지 머지된 PR 145개 가운데
제목이나 본문에 "final-review"라는 낱말이 든 것은 119개다.
이 값은 낱말이 든 PR을 센 것이고 실제로 돌렸는지는 세지 않았다.
10월 7일부터 10월 18일까지 리포 작업 폴더에 남은
plan-review 판정 파일은 50개이고
FAIL 36개, CONCERNS 14개, PASS는 0개다
(git이 추적하지 않는 로컬 산출물이라 지워진 실행은 세지 못했다).
스킬 자신도 이 흐름을 거쳤다.
plan-review와 super-auto의 체이닝을 고친 PR은
스펙 리뷰 FAIL에서 시작했고,
final-review 버그 후보 10건 중 CONFIRMED 5건은 전부,
PLAUSIBLE 5건 중에서는 1건을 채택했다고 PR 본문에 적었다.
실패와 고친 것
무인으로 돌리자, 사람이 있었다면 그냥 넘어갔을 일이 런을 멈춰 세웠다.
9월 30일에는 재도전 워커가 맥락을 보지 못했다.
--task --retry-of 로 띄운 Opus 워커가
뒤이어 send로 보낸 재도전 맥락을 보지 못하고
Sonnet이 했던 질문을 그대로 반복했다.
그래서 재도전 맥락을 새 태스크 스펙에 담아 주입하는 방식으로 바꿨다.
10월 1일에는 확인 창이 검수를 멈췄다.
final-review 스냅샷 단계에서는 임시 index 파일을
변수 경로로 지우는 rm -f 를 실행했는데,
Claude Code가 이 명령을 "비어 있을 수 있는 변수 경로"로 판단하고
바이패스 모드에서도 확인 프롬프트를 띄웠다.
무인 실행에서는 약 2분 뒤 자동으로 거부되어 스냅샷이 실패했다.
경로를 리터럴 절대경로로 바꿔서 이 문제를 막았다.
10월 15일에는 이슈를 늘리는 규칙이 문제였다.
범위 밖 결함은 무조건 새 이슈로 빼는 규칙 때문에,
Hindsight-Crew 런에서 대상 이슈 3개를 처리하는 동안
관찰 이슈 5개가 생겼다.
그날 새벽 나는 이렇게 물었다.
"이슈로 올릴만한 것들이아닌데 왜 이슈로 올리는 유난을 떤거지?"
얼마 뒤 다른 세션에서는 고칠 방향도 적었다.
"워커가 범위밖 이슈를 발견할경우 코디네이터에게 올려."
그날 바로 코디네이터가 판정하도록 고쳤고 새 이슈는 런당 2개로 묶었다.
10월 18일에는 판정 등급을 기록만, 하, 중, 상, 후보로 다시 나눴다.
하와 중은 발견한 워커에게 되돌려 같은 PR에서 고치고
상만 관찰 이슈로 발행한다(상한 2).
나머지 세 건은 Orca의 동작과 충돌해 생긴 문제다.
| 시기 | 깨진 것 | 고친 것 |
|---|---|---|
| 10월 1일 | Orca 1.4.217이 worker-start --worktree new-top-level 을 selector_not_found로 거부 | 워크트리를 먼저 만들고 id로 워커를 붙이는 두 단계 |
| 10월 8일 | 코디네이터 heartbeat 5분 주기로 오케스트레이터가 계속 깨어남 | 필터 없이 대기하고 heartbeat는 대기 스크립트가 ack |
| 10월 14일 | Orca 1.4.224의 keepalive 줄 때문에 대기 출력 파싱 실패 | 대기 스크립트가 keepalive 줄을 거름 |
지금 상태
운영 중이고 쓰는 사람은 나 하나다.
본체는 비공개 리포 vault에 있고 내 Claude Code 스킬 폴더에 연결돼 있다.
10월 19일 확인 기준으로 스킬 체이닝을 다듬는 핸드오프 이슈 두 개가 열려 있고
10월 18일 뒤로 세 스킬을 건드린 커밋은 없다.
다섯 건 모두 다음 런이 첫 실행이다.