무엇인가
이슈 번호를 넘기고 시작할 때 한 번만 답하면,
그다음에는 최종 보고만 받는다.
계획 리뷰, 결과 검수, 워커 지휘를
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이 첫 커밋으로 들어왔다. 커밋 본문은
코디네이터 1명과 이슈별 Orca 워크트리 워커로 머지까지 끝내는 절차를 고정한 것이라고
적었고,
10월 8일에 super-auto로 이름을 바꾸면서
대화 맥락이나 플랜 파일을 이슈로 확정하는 intake 단계를 넣었다.
어떻게 동작하나
내가 맡는 일은 시작 직후 한 번 답하는 것과 최종 보고를 읽는 것이다.
super-orchestration을 처음 커밋했을
때 그 한 번의 질문은 final-review를 돌릴지 여부였다.
나머지는 이 순서로 돈다.
- 스펙을 쓰면 plan-review가 섬세 모드로 본다.
- 스펙 리뷰 기록이 있는 티켓 묶음은
--set가벼운 모드로, 쪼갤 때 생기는 결함만 본다. - super-auto가 이슈마다 워크트리 워커를 띄운다.
- 워커가 끝나면 코디네이터 검수와 /final-review를 거친다.
- 판정을 통과하면 PR, 머지, 정리를 마치고 최종 보고를 쓴다.
이 루프는 Claude Code의 /loop로 끝까지 돈다.
이슈가 네 개 이상이거나 런이 몇 시간 걸릴 것 같으면 새로 띄운 코디네이터 워커가 루프를 맡고,
스킬을 실행한 세션은 시작 질문, 이슈화, 감시, 최종 전달만 한다.
plan-review의 섬세 모드에서는 새 컨텍스트의 Opus 리뷰어와 Codex(gpt-6.1-sol)가
서로의 결과를 모르는 채로 같은 기준에 따라 검토하고
판정은 Opus가 확인한 지적만을 근거로 스크립트가 낸다.
계획을 쓴 세션이 판정까지 하면 작성자 편향이 생긴다고 커밋에 적었다.
리뷰어 구성을 바꿔 가며 측정한 결과는 별도의 글로 썼다.
리뷰어를 늘려도 판정은 그대로였다
final-review는 리뷰를 서브에이전트에게 맡긴다.
Spec 대조 리뷰어를 먼저 띄우고,
누락이 없으면 코디네이터 서브에이전트 하나가 버그 리뷰와 보안 리뷰를 이어 돈다.
부모 세션은 확정(CONFIRMED)된 결함만 고친다.
리뷰어는 opus를 명시해 띄우고
리뷰가 끝난 뒤에는 세션 기록의 모델 필드를 보고 정말 Opus였는지 확인한다.
10월 2일 커밋 당시 Codex 교차 리뷰의 지적은 Opus verifier를 거쳐야 채택됐고,
이 단계를 붙인 계기는 GitHub 자동 코드 리뷰였다.
보지도 않은 리뷰가 주간 사용량 19%를 썼다
워커 모델은 9월 30일 커밋 기준으로 Sonnet high에서 시작해 막히면
Opus medium, Opus max 순으로 올리고
그래도 해결되지 않으면 BLOCKED로 둔다.
10월 11일에는 이렇게 목표를 못 박았다.
"웬만하면 전자동으로 머지까지 수행하는게 목표야. 에이전틱플로우."
같은 날 커밋은 이슈 번호를 넘긴 것 자체를 곧 승인으로 보고,
BLOCKED는 런 안에서 기술적으로 못 하는 일에만 쓰게 했다.
써 보니
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) 전까지 내 리포 여섯 곳(Hindsight-Crew, vault,
smartthink, collection-resilience-lab, bkan-dev,
bkan-blog)에서 머지된 PR 145개 가운데
제목이나 본문에 "final-review"라는 낱말이 든 것은 119개다.
이 값은 낱말이 든 PR을 센 것이고 실제로 돌렸는지는 세지 않았다.
10월 7일부터 10월 18일까지 리포 작업 폴더에 남은
plan-review 판정 파일은 50개이고
FAIL 36개, CONCERNS 14개, PASS는 0개다
(git이 추적하지 않는 로컬 산출물이라 지워진 실행은
세지 못했다).
체이닝 PR 본문에는 티켓 묶음 리뷰의 묶음 판정이 PASS였다고 적혀 있다.
스킬 자신도 이 흐름을 거쳤다.
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 작업을 이어 하던 세션에서 나는 이렇게 물었다.
"이슈로 올릴만한 것들이아닌데 왜 이슈로 올리는 유난을 떤거지?"
얼마 뒤 다른 세션에서는 고칠 방향도 적었다.
"워커가 범위밖 이슈를 발견할경우 코디네이터에게 올려."
그날 커밋 본문은 범위 밖 결함은 무조건 새 이슈로 빼는 규칙 때문에,
Hindsight-Crew 런에서 대상 이슈 3개를 처리하는 동안
관찰 이슈 5개가 생겼다고 적었다.
그 커밋으로 코디네이터가 판정하도록 고쳤고 새 이슈는 3조건과 런당 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 줄을 거름 |
지금 상태
운영 중이고(10월 19일 확인 기준), 쓰는 사람은 나 하나다.
본체는 10월 19일 확인 기준으로 비공개 리포 vault에 있고
내 Claude Code 스킬 폴더에 연결돼 있다.
10월 19일 확인 기준으로 스킬 체이닝을 다듬는 핸드오프 이슈 둘이 열려 있고,
세 스킬을 건드린 가장 최근 커밋은 10월 18일의 super-auto 변경이다.
스킬 폴더를 건드린 커밋 55개(머지 커밋 제외, 옛 이름 폴더 포함)에는
전부 Co-Authored-By 줄이 붙어 있다.
Opus 5.5가 47개, Sonnet 5.5가 8개다. 내가 맡은 몫은 설계와 판정 기준이다.