Fable 5.2로 스킬 5개 토큰 45% 절감하기

요약: 이슈 개발 흐름을 묶은 스킬 5개(dev-issue·start-issue·finish-issue·end-issue·prune-branch)를 Fable 5.2에게 토큰 낭비 관점으로 점검시켰다. 줄일 곳은 본문 길이보다 스킬끼리 같은 말을 반복하는 부분과 헛도는 명령 호출이었고, 앞 4개 합계가 16,978 → 9,340 bytes(약 45% 감소)가 됐다. 점검 과정에서 설명이 사실과 다른 곳과, 미병합 브랜치를 지울 뻔한 판정 버그도 같이 나왔다.

왜 스킬을 줄이나

스킬은 SKILL.md 본문만 비용이 아니다. description은 호출하지 않아도 모든 세션의 스킬 목록에 실린다. 본문은 호출될 때마다 컨텍스트에 들어가 이후 모든 턴에서 다시 읽힌다. 그래서 스킬이 길고 서로 같은 말을 반복하면 비용이 누적된다.

내 이슈 흐름은 스킬 여러 개를 조합한다. dev-issue가 start-issue로 착수하고, 구현한 뒤 finish-issue로 PR·머지·이슈 종료까지 간다. 조합하다 보니 같은 내용이 여러 파일에 복사되어 있었다. 이번 작업은 Fable 5.2에게 "토큰을 절약할 부분이 있는지 체크해줘"라고 시킨 뒤, 결과를 보고 "적용해줘"만 반복한 세션이다.

점검 방식: 점검 → 승인 → 적용

한 번에 고치지 않고 스킬 묶음마다 두 단계로 나눴다.

1. 점검만 시킨다. 항목을 번호로 받고, 안전과 토큰이 충돌하는 항목은 "판단 필요"로 따로 받는다.
2. 내용을 보고 "적용해줘"라고 한다.

dev-issue → start-issue·finish-issue → end-issue·prune-branch 순서로 세 번 돌렸다. 아래부터는 점검에서 나온 것을 유형별로 정리한다.

발견 1. 본문 줄이기보다 실행 중복이 컸다

dev-issue는 6,853 bytes였다. 본문을 정리하면 절반쯤 줄지만, 점검 결과에서 더 큰 낭비는 실행할 때 일어나는 중복이었다.

• 탐색이 2번 실행됨. start-issue가 메인 컨텍스트에서 Grep/Glob으로 탐색하고, 이어서 dev-issue가 서브에이전트로 같은 파일을 다시 탐색했다. 서브에이전트 1회로 통일하고, dev-issue에서 start-issue를 부를 때는 탐색·착수 요약 단계를 건너뛰게 했다.
• **composer ci 로그 전체가 컨텍스트로 들어옴.** CS Fixer, PHPStan, PHPUnit 출력이 통째로 남았다. 성공하면 마지막 요약만 필요하므로 끝부분만 보게 했다.

composer ci 2>&1 | tail -n 40

• 존재하지 않을 수 있는 에이전트 이름 고정. ci4-explorer를 이름으로 고정해 부르고 있었는데 전역 에이전트 폴더에는 없었다. 저장소 전용 에이전트가 있으면 그것을, 없으면 Explore를 쓰도록 바꿨다.

본문 쪽은 finish-issue와 거의 같은 7·8단계(PR, squash, 브랜치 정리, 이슈 종료)를 "finish-issue 호출" 한 줄로 바꾼 것이 가장 컸다. 약 1,300 bytes다. Closes #NN 함정 설명이 네 군데에 있던 것도 finish-issue 한 곳만 남겼다.

발견 2. 설명이 사실과 달랐다

토큰과 상관없이 점검하다 나온 오류들이다. 줄이다 보면 "이 줄이 맞나"를 확인하게 되어서 걸렸다.

• finish-issue에는 "--delete-branch는 원격 브랜치만 지운다"고 적혀 있었다. 설치된 gh 2.96.0의 도움말은 "Delete the local and remote branch after merge"였다. 로컬도 지워지므로 뒤에 있던 git branch -d와 git checkout dev는 대개 헛도는 호출이었다. "브랜치가 남아 있을 때만 삭제"로 바꾸고 단계를 합쳤다. 워크트리 안에서는 로컬 삭제가 실패할 수 있어서 그 경우만 수동 정리로 남겼다.
• PR 본문 템플릿에 "Closes #NN은 dev 머지로는 자동으로 닫히지 않는다"는 문구가 들어 있었다. 이 문구가 실제 PR 본문에 그대로 올라간다. Refs #NN으로 교체했다.
• end-issue의 description에는 "그리고 커밋"이 있는데 본문에는 커밋 단계가 없었다. 실행마다 해석이 갈려 의도하지 않은 커밋이 나올 수 있다. 커밋은 하지 않는다고 본문에 명시했다.
• 여러 스킬이 아직 "종료는 end-issue 담당"이라고 적고 있었다. 실제 상위 흐름은 finish-issue다.

발견 3. description이 제일 비쌌다

finish-issue의 description이 약 600 bytes, start-issue가 약 400 bytes였다. description은 호출 여부와 무관하게 모든 세션에 상시 로드된다. 본문을 몇백 bytes 줄이는 것보다 누적 효과가 크다. 트리거 문구 + 한 줄 설명만 남기고 배경 설명은 본문으로 옮기거나 지웠다.

발견 4. 호출 수 줄이기

• gh auth status 선행 호출을 삭제했다. 권한이 없으면 다음 gh 명령이 어차피 실패한다. 매번 도구 호출 1회가 낭비였다.
• end-issue는 코멘트와 종료를 하나로 합쳤다. 이미 758 bytes로 작아서 본문을 줄일 여지는 없었고 호출만 3회에서 1회가 됐다.

gh issue close <이슈번호> --comment "<작업내역 요약>"

• 이슈번호 추정 폴백이 5단계였다. dev-issue에서 오면 첫 단계에서 항상 끝난다. "세션 컨텍스트 → 브랜치명·커밋 로그의 #숫자 → 없으면 질문" 두 줄로 줄였다. 키워드로 열린 이슈를 검색하는 폴백은 호출이 늘고 엉뚱한 이슈를 닫을 위험이 있어 지웠다.

prune-branch: 줄이다 버그를 찾았다

prune-branch는 병합이 끝난 로컬·원격 브랜치를 정리하는 스킬이다. 점검에서 두 가지가 나왔다.

출력 낭비. gh pr list --state merged --limit 100 결과를 통째로 읽었다. 대부분은 이미 지워진 브랜치의 PR이다. 이걸 candidates.sh 스크립트로 분리했다. fetch, PR 조회, 보호 브랜치(main·dev·현재 브랜치) 제외, 판정까지 호출 1회로 끝나고, 남아 있는 브랜치마다 한 줄만 출력한다.

판정 버그. 기존 스킬은 브랜치 이름이 병합된 PR의 브랜치명과 같으면 "병합됨"으로 봤다. 병합된 PR과 같은 이름을 재사용해 새 커밋을 쌓은 브랜치도 -D 삭제 대상이 되어 미병합 작업이 유실될 수 있다. 판정 기준을 이름 일치에서 **병합 PR의 끝 커밋(headRefOid)과 브랜치 끝 커밋 일치**로 바꿨다. 이름만 같고 커밋이 다르면 삭제 금지로 남긴다.

# 같은 이름의 병합 PR 중 끝 커밋까지 일치(또는 브랜치가 그 조상)해야 병합으로 본다
if [ "$sha" = "$oid" ] || git merge-base --is-ancestor "$sha" "$oid" 2>/dev/null; then
  status="병합 $num"
fi

한 저장소에서 읽기 전용으로 시험하니 브랜치 40개가 판정됐다. 그중 하나가 병합 PR과 이름만 같고 끝 커밋이 다른 브랜치였고 "이름만 일치, 삭제 금지"로 나왔다. 이전 스킬이었다면 -D 대상이 됐을 브랜치다. 시험 중 병합 PR 조회 한도 300에 정확히 걸린 것도 발견해 1000으로 올렸다.

결과

합계가 약 45% 줄었다. prune-branch는 이전 크기를 재지 않아서 비교에서 뺐다. 현재는 SKILL.md 1,894 bytes + candidates.sh 1,983 bytes다.

배운 점

• 줄일 곳은 스킬 사이의 경계다. 개별 파일은 다 말이 됐다. 조합해서 쓸 때 같은 설명이 반복되고, 같은 동작이 두 번 일어나는 게 문제였다. 조합 스킬은 하위 스킬을 "호출"하고 내용을 복사하지 않는 쪽이 맞다.
• 전역 규칙과 겹치는 문구는 지운다. 브랜치 생성, --squash --delete-branch, 이슈 코멘트 형식은 항상 로드되는 전역 Git 규칙에 이미 있었다.
• 줄이는 점검은 사실 검증을 겸한다. 줄일 문장을 하나씩 읽다가 --delete-branch가 원격만 지운다는 오래된 설명과 이름 기반 병합 판정 버그가 나왔다.
• 안전 장치는 토큰과 바꾸지 않는다. 승인 4회(push, PR, 머지, 이슈 종료)를 한 번에 묶으면 왕복 3턴을 아낄 수 있지만, 단계별로 멈출 기회가 사라진다. 이번엔 현행 유지를 선택했다.
• LLM이 쓴 점검 결과도 시험한다. 스크립트는 문법 검사와 실제 저장소 읽기 전용 실행으로 돌려봤다. 다만 "병합 #N" 판정 경로는 사례가 없어 실측하지 못했고, 삭제 동작도 시험하지 않았다. 다음 실제 정리 때 첫 결과를 확인해야 한다.

남은 확인

• 정리한 스킬들을 실제 이슈 하나로 끝까지 돌려 보지 않았다. dev-issue가 start-issue의 탐색 단계를 실제로 건너뛰는지 다음 실행에서 확인할 예정이다.
• 스킬 폴더가 git 저장소가 아니라 이전 버전 백업이 없다. 수정 전 원문은 대화 기록에만 남아 있다. 스킬 폴더를 git으로 관리하면 이런 정리가 훨씬 안전해진다.
• prune-branch는 스크립트를 절대 경로로 호출한다. 다른 기기로 옮기면 경로를 맞춰야 한다.