Claude Code의 스킬이 매일 자동으로 개선되는 메커니즘을 만들었다

이 기사는 Claude on SonicGarden의 기사입니다. SonicGarden의 프로그래머가 Claude Code의 활용에 대해 쓰고 있습니다. #claude_on_sonicgarden

최근에는 dev-workflow라는 스킬로 워크플로우화된 개발을 하고 있습니다만, 개발이 일단락될 때마다 "이번 dev-workflow의 이 부분이 미묘했네"라고 느끼는 부분을 수정하고 다음 태스크로 넘어가는 흐름을 매번 반복하고 있다는 사실을 깨달았습니다.

그러던 차에 Claude Code의 Routines가 발표되었고, 이것을 사용하면 dev-workflow의 개선을 어느 정도 자동화할 수 있지 않을까?라고 생각하여 다음과 같은 자기 성찰(Self-reflection) 메커니즘을 만들었습니다.

dev-workflow에서의 개발 완료 시 해당 세션의 대화 이력으로부터 자기 성찰 실시 - 자기 성찰에서 검출된 과제를 GitHub Issues에 등록

Routines로 매일 Issues에 등록된 과제를 수정

대략 3주 동안 40건 이상의 auto-triage 커밋이 PR을 통해 main에 반영된 상태입니다. 현재는 사람이 리뷰하고 머지(Merge)하는 운용 방식이라 완전 자동은 아니지만, 성찰부터 PR 생성까지가 자동으로 진행되는 것만으로도 상당히 편해졌습니다.

게다가, 스스로 "이번에는 잘 풀렸네"라고 생각했을 때라도, 사실 뒤에서는 서브 에이전트(Sub-agent)와의 상호작용에서 발생한 문제를 자기 성찰이 잡아내 줍니다. 스스로는 깨닫지 못했던 부분까지 개선되어 가는 것은 흥미로운 발견이었습니다.

단계	스킬	장소	할 일
1. 발견	dev-workflow의 자기 성찰	로컬	자신의 대화 jsonl로부터 "잘 되지 않았던 시그널(signal)"을 추출하여 Issue 기표
2. 판정+적용	dev-workflow-triage	Claude Code on the Web	Issue를 읽고 accept/reject, accept라면 SKILL.md를 수정하여 PR 생성
3. 무인 운전	Routines	Claude Code on the Web	2를 하루에 1번 실행

마지막에 사람이 PR을 리뷰하고 머지하므로, main에 커밋이 쌓이는 것은 사람이 OK를 낸 만큼뿐입니다.

dev-workflow의 자기 성찰에서 수행하고 있는 일입니다.

최신 ~/.claude/projects/<encoded-cwd>/<session-id>.jsonl을 서브 에이전트에게 통째로 맡겨서, 다음과 같은 "잘 되지 않았던 시그널"을 찾아내게 하고 있습니다.

• 사용자로부터의 수정 지시 ("틀렸어", "stop doing X")
• 동일한 지시의 반복 (스킬이 내면화되지 않았다는 시그널)
• 진행되지 않는 단계가 몇 번이고 반복되는 루프
• 리뷰 스킬이 SKILL.md 문구를 근본 원인(root cause)으로 지목한 부분

jsonl은 크기가 꽤 크기 때문에, 생대화(Raw conversation)를 메인 컨텍스트에 올리지 않고 서브 에이전트 측에서 처리하도록 구성했습니다.

dev-workflow-triage라는 스킬을 별도로 만들어 Routines에 등록했습니다.

dev-workflow는 사용자와의 대화를 전제로 한 스킬이기 때문에, Routines로 무인 운전하기에는 적합하지 않습니다. 그래서 dev-workflow의 개발 품질은 유지하면서, 무인으로 돌릴 수 있는 triage 전용 로컬 스킬을 별도로 만들었습니다.

최종적으로는 완전 자동 스킬 개선을 목표로 하고 있기 때문에 품질 게이트(Quality gate)를 확실히 마련해 두었습니다.

게이트	무엇을 보는가	내부 루프 상한
verify-diff	Edit가 Finding의 의도를 달성했는가 (empirical 검증)	3
skill-review	SKILL.md의 best practices (구조, 기술 스타일, 중복성)	3
publicity-review	공개 리포지토리로의 유출 (leak) (절대 경로, 내부 hostname, credential, 사용자 식별자)	2

각 게이트(gate)는 각각 내부에서 루프를 돌지만, 그 3단계 전체를 하나의 유닛으로 하여 외부에서 다시 최대 3회 루프를 돌립니다. skill-review가 SKILL.md를 수정하면 verify-diff의 의도 달성 체크나 publicity-review의 leak 체크 결과가 달라질 수 있기 때문에, 3단계를 직렬로 1회만 실행하고 끝내면 정합성(consistency)을 맞출 수 없기 때문입니다. 외부 루프는 "어떤 게이트도 단 한 건의 edit을 넣지 않은 iter(iteration)가 있다면 convergence(수렴)", "fatal한 verdict(판정)가 나오면 break" 조건으로 종료됩니다.

verify-diff는 empirical-prompt-tuning의 발상을 참고했습니다.

워크플로우를 중간에 멈추지 않고 끝까지 실행하는 것이 생각보다 힘들었습니다.

서브 스킬(sub-skill)에서 돌아온 직후에 대기하기 시작함: 서두에 "멈추지 마세요"라고 써두어도 멈춥니다. 판단 포인트 직전에도 다시 게시함으로써 대응했습니다.
서브 스킬의 출력이 긴 문장일 경우 거기서 완결된 것으로 간주됨: 문장을 반환하면 에이전트(agent)가 이를 "사용자에 대한 완성된 응답"으로 해석하여 다음 단계로 진행하지 않습니다. 끝부분을 {"status": ..., "suggested_edits": [...]}와 같은 짧은 JSON으로 닫으면 "파싱(parse)하여 다음으로 넘어가는 것"으로 인식해 주었습니다.
비대화형(non-interactive) 환경에서는 쓰려고 하는 시점에 허가 다이얼로그가 뜸: staging 파일은 .claude/ 하위에 작업 파일을 두면 멈춥니다. .triage/ 등 외부 디렉토리에 두고 .gitignore로 관리하는 것이 좋아 보입니다.
allowed-tools 누락이 있으면 중간에 멈춤: TodoWrite 등 놓치기 쉬운 도구는 서브 스킬을 통해 호출되는 순간 permission dialog가 뜹니다. 서브 스킬이 사용하는 도구를 망라하고 있는지 체크하는 메커니즘을 넣어두면 안심할 수 있습니다.
Web의 기본 Stop hook이 중간 상태에서 오작동함: Web 환경에는 stop-hook-git-check.sh라는 기본 Stop hook이 들어있어, 커밋되지 않았거나 푸시되지 않은 변경 사항이 있으면 exit 2로 에러를 반환합니다. 중간에 미커밋 상태가 발생하는 워크플로우에서는 서브 에이전트 호출 시마다 오작동합니다. 오케스트레이터(orchestrator)와 각 서브 스킬 양측에 상황 설명을 배치하여 대응했습니다.

수치로는:

• 자동 triage 커밋: 13일 동안 40건 이상
• 자기 성찰(self-reflection) Issue: 21건 생성 / 21건 종료 / 0건 오픈
• Issue 1건당 Finding 수: 1 ~ 4

이것은 저 혼자서만 자기 성찰을 활성화하고 있는 시험 운영 단계의 수치입니다. 조금 더 안정되면 팀으로 확대할 예정입니다.

솔직히 "그렇게 개선할 부분이 있을까?"라고 생각하기도 하지만, 현재까지 명확하게 스킬이 악화된 케이스는 없으며, 반대로 "오, 제대로 좋아지고 있네"라는 경우는 있어서 어느 정도는 잘 작동하고 있는 것 같습니다.

대화 이력에서 개선의 씨앗을 찾아내고, 별도의 세션에서 판정하여 PR(Pull Request)까지 내는 3단계 구성의 자기 개선 루프를 소개했습니다.

최종 머지는 사람이 PR 리뷰를 한 뒤에 진행하므로 완전히 기계에 맡긴 것은 아니지만, 성찰부터 PR 제출까지가 자동으로 진행되는 것만으로도 같은 수정을 반복하고 있다는 느낌이 상당히 줄었습니다. 비슷한 자동화 스킬을 만들 예정인 분들에게 참고가 되길 바랍니다.

이번에 소개한 dev-workflow / dev-workflow-triage 스킬은 다음 리포지토리에 있습니다.

hiroro-work/claude-plugins

이 기사는 Zenn/Qiita에 크로스 포스트하고 있습니다.