Claude Code 자가 진단 후속 — 처방이 들었는지 transcript 로 다시 재봤습니다

지난번에 저는 Claude Code 가 로컬에 쌓아두는 transcript 를 직접 파싱해서 제 사용 패턴을 진단해본 적이 있습니다. 그 글에서 진단 결과를 보고 처방 세 가지를 적어두었는데, 솔직히 말하면 거기서 끝이었습니다. 메모만 남기고 효과가 있었는지는 확인하지 않았습니다. 한동안 그 메모를 잊고 지내다, 문득 그때 적어둔 처방이 실제로 듣기는 했는지 궁금해졌습니다. 그래서 같은 도구를 다시 돌려봤고, 이 글은 그 재측정에 대한 회고입니다.

지난 글(「Claude Code 사용 패턴, transcript jsonl 로 직접 진단해봤습니다」)에서 transcript 가 별도 설정 없이 로컬에 자동으로 쌓인다는 것, 거기서 뽑을 수 있는 여섯 가지 시그널, 그리고 general-purpose 비중이 일정 임계를 넘으면 위임 ROI 가 떨어진다는 개념을 다뤘습니다. dormant 스킬을 함부로 단정하면 안 된다는 점, OS 환경 차이 같은 주의사항도 그때 정리했습니다. 그 내용은 다시 풀지 않겠습니다. 이번 글은 그 다음 이야기, 즉 적어둔 처방이 데이터로 확인되었는지와, 그때는 보지 못했던 또 하나의 축에 대한 것입니다.

처방의 루프를 닫다 — 범용 서브에이전트 비중 재측정

지난번 메모의 핵심은 이랬습니다. 막연하게 범용 에이전트(general-purpose)에 일을 던지는 비율이 너무 높으면, 도메인 맥락이 흩어지고 토큰만 새어 나간다. 그러니 작업 영역에 맞는 전문 에이전트로 명시해서 위임하자. 임계는 대략 30% 정도로 잡아두었습니다. 다만 그때는 그 처방을 적는 것까지가 전부였고, 실제로 행동이 바뀌었는지는 재보지 않았습니다.

이번에 Claude Code 의 같은 자가 진단을 다시 돌려보니, 범용 에이전트로 위임된 비율은 전체 호출의 11%(16/145)였습니다. 지난번 우려했던 임계보다 한참 아래였습니다. 그 사이에 라우팅 규칙을 손봤고, 호출 직전에 작업 영역을 한 번 분류하는 습관을 들인 것이 영향을 준 것으로 보입니다.

여기서 제가 새삼 느낀 것은 숫자 자체보다 그 숫자가 가진 의미였습니다. 처방을 적는 것과 처방이 듣는 것은 전혀 다른 일입니다. 자가 진단 도구의 진짜 가치는 한 번 측정해서 현황을 아는 데 있지 않았습니다. 처방을 적고, 일정 기간을 두고, 다시 재서 before/after 로 말할 수 있을 때 비로소 의미가 생긴다는 생각이 들었습니다. 측정 가능한 도구가 손에 있으면, "그 사이에 좀 나아진 것 같다" 같은 직관 대신 "11% 였다"고 말할 수 있습니다. 그 차이는 생각보다 큽니다.

묵묵히 일하는 스킬 — 오케스트레이터의 sidechain 위임

지난 글에서 저는 가설 하나를 던져두기만 했습니다. 내가 슬래시로 의식해서 부르는 스킬과, 실제로 가장 많은 sub-agent 를 spawn 하면서 일을 하는 스킬은 다를 수 있다는 것이었습니다. 그때는 attribution 데이터로 그럴 가능성이 있다는 정도만 짚었습니다.

이번 실측에서 그 가설은 꽤 분명하게 확인되었습니다. sidechain 에서 오간 메시지의 97%가 오케스트레이터 단 2종에서 발생하고 있었습니다. 정작 제가 손으로 슬래시를 쳐서 직접 부르는 비율은 미미했습니다. 사실상 한 스킬을 가끔 수동으로 부르는 정도였습니다. 제가 의식적으로 부르는 스킬과, 실제로 가장 많이 일을 시키는 스킬이 거의 겹치지 않았습니다.

곰곰이 생각해보니 당연한 결과였습니다. 자동 연쇄 — 이를테면 PR 리뷰가 끝나면 UI 평가가 돌고, 통과하면 머지되고, 다시 배포로 이어지는 흐름 — 가 한 번 트리거되면 그 안에서 수십에서 수백 개의 메시지가 조용히 돕니다. 제가 명령어를 친 횟수만 세면 이 일꾼들은 통계에 거의 잡히지 않습니다. 체감 사용량과 실제 위임량 사이에는 큰 간극이 있었습니다. 슬래시 카운트만 보고 "이 스킬은 별로 안 쓰네"라고 했다면, 가장 바쁘게 일하던 자산을 못 보고 지나쳤을 것입니다.

자주 쓰는가와 잘 만들어졌는가는 다른 질문

이번에 한 가지를 추가로 봤습니다. transcript 가 알려주는 것은 어디까지나 동적인 정보입니다. 무엇이 얼마나 자주 쓰였는가. 그런데 그것과 별개로, 파일 자체가 잘 만들어졌는가라는 정적인 질문이 있습니다. description 의 트리거가 명확한지, 스킬 간 scope 가 중복되지 않는지, 도구 권한이 과하지 않은지, 안티패턴 위생은 깨끗한지 같은 것들입니다.

이 두 축을 일부러 하나의 점수로 합산하지 않았습니다. 의미가 다른 두 질문을 한 숫자로 뭉개면, 점수가 좋아도 나빠도 무엇 때문인지 해석이 되지 않습니다. 그래서 사람이 두 축을 교차해서 보도록 두었습니다. 그 결정이 옳았다는 것을 보여준 발견이 두 가지 있었습니다.

많이 쓰는 자산은 지우는 게 아니라 쪼갠다

가장 자주 쓰는 스킬 하나가 본문 1,257줄까지 비대해져 있었습니다. 만약 이게 거의 안 쓰는 dormant 자산이었다면 답은 간단했을 겁니다. 지우면 됩니다. 그런데 이건 최다 사용 자산이라 지울 수가 없었습니다. 그렇다고 그대로 두면 매번 그 큰 본문이 컨텍스트에 통째로 올라옵니다. 결국 핵심 진입점만 남기고 나머지는 보조 파일로 분리하는, 이른바 progressive disclosure 가 가장 ROI 높은 선택이었습니다. 여기서 단순한 결정 매트릭스 하나가 정리되었습니다.

자산 상태	판단	조치
거의 안 쓰임 (dormant)	비용만 발생	삭제
자주 쓰이는데 비대 (hot)	가치 있으나 무거움	핵심만 남기고 분리

같은 "비대함"이라도 사용 빈도에 따라 처방이 정반대였습니다. 동적 데이터 없이 파일 크기만 봤다면 둘을 똑같이 취급했을 것입니다.

쌍둥이 description 은 위임 실패의 씨앗이다

두 리포터 에이전트의 description 이 사실상 똑같았습니다. 트리거가 걸렸을 때 둘 중 어디로 위임해야 할지 시스템이 구분할 수 없는 상태였고, 이건 가장 높은 심각도(P0)로 분류했습니다. 흥미로웠던 것은, 같은 진단에서 안티패턴 위생 점수는 평균 24.7/25 로 매우 깨끗했다는 점입니다. 위생만 보면 흠잡을 데가 없었습니다. 그런데 scope 중복이라는 치명적인 문제는 그 점수와 전혀 다른 축에서만 잡혔습니다. 만약 모든 것을 하나의 종합 점수로 뭉갰다면, 24.7 이라는 높은 숫자에 가려 이 P0 가 보이지 않았을 것입니다. 두 축을 섞지 않은 것이 다행이었습니다.

측정 윈도우가 결론을 만든다 — transcript 3일과 7일

한 가지 솔직하게 덧붙일 것이 있습니다. 이번 재측정은 3일치 데이터만 돌렸습니다. dormant 후보가 17개나 떴는데, 3일이라는 베이스라인은 그렇게 단정하기에는 너무 짧습니다. 주말이 끼었거나 특정 작업에 며칠 집중했을 뿐인 자산이 "안 쓰는 것"으로 잘못 잡혔을 가능성이 큽니다. 이 도구의 기본 측정 기간이 7일인 데에는 이유가 있었습니다.

그래서 자가 진단 결과를 인용할 때는 반드시 측정 기간을 함께 말해야 한다는 생각이 들었습니다. 같은 도구, 같은 자산이라도 윈도우가 결론을 바꿉니다. "이건 안 쓰는 것 같다"는 판단은 3일 창에서는 거짓일 수 있습니다. 이번에 나온 dormant 17개는 결론이 아니라, 7일로 다시 봐야 할 후보 목록으로만 받아두었습니다.

닫으며

같은 Claude Code 자가 진단 도구를 두고, 이전 글이 "한번 측정해보자"였다면 이번 글의 결론은 조금 다릅니다. 측정은 한 번으로 끝나지 않습니다. 처방을 적고, 시간을 두고, 다시 재서 루프를 닫아야 비로소 그 측정에 의미가 생긴다는 것을 이번에 확인했습니다. 11% 라는 숫자는 그 자체로는 별것 아니지만, 지난번 메모와 짝을 이룰 때 비로소 "처방이 들었다"는 문장이 됩니다.

그리고 한 가지 더. "자주 쓰이는가"와 "잘 만들어졌는가"는 다른 질문이었습니다. 이 둘을 한 점수로 섞으면 둘 다 보이지 않게 됩니다. 편하게 하나의 종합 점수를 만들고 싶은 유혹이 있었지만, 섞지 않길 잘했다는 생각이 듭니다. 다음에는 7일 창으로 다시 재서, 이번에 미뤄둔 dormant 후보들을 제대로 확인해볼 생각입니다.