iceberggymnast Session Audit — 세션 전수 분석
로그에서 나오는 것은 진단이 아니라 가설이다. 이 스킬의 절반은 분석 절차고, 나머지 절반은 가설을 행동으로 옮기기 전에 걸러내는 절차다. 4단계(검증)와 5단계(3관문 필터)를 빼면 남는 것은 그럴듯한 제안 목록이며, 그건 그대로 새 워크스트림이 된다.
산출물 형식은 references/report-skeleton.md, B안 프롬프트 원문은 references/blank-prompt.md.
출력 모드
두 가지다. 데이터 준비(0·1)와 백지 프롬프트(2)는 같고, 어디서 멈추는지가 다르다.
| 전수 분석 (기본) | 쓴맛 보고 | |
|---|---|---|
| 도는 단계 | 0 → 6 전부 | 0 → 1 → 2 → 4(축소) → 출력 |
| A안 분류 틀 | 있음 | 없음 |
| 검증 | 4단계 전부 | 부재 주장만 |
| C안 · 3관문 필터 | 있음 | 없음 |
| 출력 | 노트 파일, 절 번호 고정 | 대화에 그대로. 파일을 만들지 않는다 |
쓴맛 보고를 고르는 신호 — "내 로그 좀 까줘", "냉정하게 봐줘", "쓴소리 좀 해줘". 산출물 계획이 아니라 지적 자체를 원하는 요청이다. 애매하면 어느 쪽인지 묻는다.
쓴맛 보고에서 하지 않는 것
- A안 — 만들 것 목록을 내는 순간 쓴맛이 아니라 기획서가 된다
- 7·8단계 — 교차표, 실행 계획, 작동 확인 방법 열
- 노트 배치·커밋·절 번호 — 파일로 남기고 싶어지면 그건 전수 분석 쪽이다
쓴맛 보고에서도 반드시 하는 것
- 0단계. 데이터 창을 확인하지 않으면 "요즘 한 달밖에 안 썼네" 같은 지적이 자동 정리의 흔적을 두고 나온다. 가장 값싸고 가장 창피한 오진이다
- 부재 주장 판정. "
한 적이 없다", "를 안 쓴다" 형태만 골라 파일 유무·크기·최종 수정 시각으로 판정한다. 3분이면 끝난다. 틀린 것은 버리지 말고 틀렸다고 표시해 함께 낸다 — 백지 분석이 어디서 헛짚는지가 다음 실행의 재료다 - 못 보는 축 한 줄. Claude Code 로그만 본 결과라는 것
- 마지막에 가장 냉정한 한 줄
검증을 통과한 지적만 날이 선다. 확인하지 않은 지적은 사용자가 한 건을 반박하는 순간 나머지까지 같이 힘을 잃는다.
0. 데이터 창부터 확인한다 — 분석 시작 전에
~/.claude/settings.json의 cleanupPeriodDays가 미설정이면 30일치만 남기고 조용히 지워진다. 이 확인을 건너뛰면 잔존 로그의 범위를 사용 기간으로 읽어 결론 전체가 틀어진다.
cleanupPeriodDays값을 읽는다.- 사용자에게 Claude Code를 실제로 언제부터 썼는지 묻는다. 로그로는 알 수 없다.
- 1단계 추출 후 월별 분포와 대조한다. 최근 한 달에만 몰려 있으면 사용 패턴이 아니라 자동 정리의 흔적이다.
보존 기간을 늘리려면 "cleanupPeriodDays": 365. 이건 앞으로를 위한 조치고 이미 지워진 건 돌아오지 않으므로, 그 사실을 안 채로 분석에 들어간다.
데이터가 한 달치뿐이어도 진행할 만하다. 지적 대부분은 반복 패턴에서 나오므로 한 달이면 드러난다. 다만 결론에 "최근 N개월 기록 기준"을 못박고 시작한다.
1. 추출
python scripts/scrape_prompts.py <출력경로>
~/.claude/projects/*/*.jsonl에서 type:user & isSidechain:false만 남기고 도구 결과·시스템 알림을 뺀다. 출력은 임시 폴더에 쓴다.
- 프롬프트 1건 상한 1200자. 붙여넣은 로그·문서 전문이 파일을 삼키는 것을 막는다.
- 자동 프롬프트 접기 조건에
len(prompts) == 1이 붙어 있는 것을 지우지 마라. 첫 문장이 같다는 이유로 세션 전체가 접히면, 재개를 "이어서 진행" 한 줄로 시작하는 세션의 본문이 전부 사라진다. 원작성자 실측에서 이 조건 전후가 416KB와 671KB로 갈렸고, 리밋 후 재시작 패턴은 그 분석에서 가장 큰 발견이었다. - 계정 폴더를 여럿 쓴다면 스캔 전에 실체가 몇 벌인지 확인한다. 한쪽이 다른 쪽을 가리키는 링크(Junction·심볼릭 링크)면 둘 다 스캔했을 때 같은 세션이 두 번 잡힌다.
추출 파일에는 사용자가 친 모든 문장이 들어간다 — 거래처, 계약, 개인 사정, 붙여넣은 문서 조각까지. 자기 머신 안에서 도는 동안은 문제가 없지만, 외부 서비스에 올리는 경로가 생기면 그전에 사용자에게 알린다.
2. B안을 먼저 띄운다
A안 결론이 B안에 새는 것을 막고, 대기 시간도 줄인다.
references/blank-prompt.md의 블록을 치환만 해서 서브에이전트에 넘긴다. 문구를 다듬지 않는다 — 그 파일의 "손대면 안 되는 부분" 표가 이유다.- 백지에서 구조를 잡는 작업이므로 그 계열에 강한 모델을 붙이고, 백그라운드로 띄운다.
- 이 세션에서 이미 세운 가설을 프롬프트에 섞지 않는다.
3. A안 — B안이 도는 동안
분류 틀을 가지고 같은 추출 파일을 읽는다. 네 칸으로 나눈다.
| 칸 | 넣는 것 |
|---|---|
| 스킬 | 절차가 고정된 반복 작업 |
| 플러그인 | 스킬 3개를 넘을 때 묶는 포장. 그 전에는 만들지 않는다 |
| 에이전트 | 시행착오가 길어 격리 컨텍스트가 필요한 것 |
| CLAUDE.md | 절차가 아니라 프로젝트 사실 |
각 항목에 반복 횟수와 근거 세션을 붙인다. 스킬에는 절차를, CLAUDE.md에는 프로젝트 사실을 넣는다 — 이 경계가 흐려지면 같은 규칙이 두 곳에 중복된다.
4. 검증 — 건너뛸 수 없다
B안 결과를 받은 직후, 보고서에 옮겨 적기 전에 한다. 원작성자 실행에서 백지 분석 주장 2건이 사실과 달랐고, 파일을 직접 열어보고서야 정정됐다. 둘 다 "그 산출물을 한 달간 활용한 흔적이 없다", "그 스킬을 한 번도 안 쓴다" 형태였는데, 실제로는 산출물이 정상 누적 중이었고 스킬은 한 번 쓰고 방치된 상태였다.
- "
한 적이 없다", "를 안 쓴다" 형태는 전부 판정 대상이다. 파일 유무·크기·최종 수정 시각·커밋 로그로 3분이면 끝난다. - 관측되지 않은 것과 없는 것은 다르다. 사용자 발화가 없는 세션(스케줄 루틴 등)은 작업이 없는 세션이 아니다. 산출물 diff와 커밋으로 측정해야 하며, 이걸 노이즈로 걸렀다가 "3주째 방치 중"이라는 진단이 나온 적이 있다.
- 판정 결과는 §6에 표로 남긴다. §6이 비어 있으면 검증을 안 한 것이다.
이 분석이 못 보는 축도 여기서 선언한다 — 다른 AI 도구 로그, 채팅에서 내린 결정, 각 레포 커밋 로그.
서브에이전트 안에서 한 작업도 이 축에 들어간다. 호출은 메인 레인에 tool_use 한 줄로 남지만 그 안쪽 대화는 ~/.claude/projects의 세션 파일에 기록되지 않는다 — 1단계의 isSidechain 필터가 걸러내서가 아니다(원작성자 머신 실측: isSidechain=true 레코드 0건, 즉 그 조건은 한 번도 실행되지 않는다). 필터는 형식이 바뀔 때를 대비해 두되, 그게 서브에이전트 작업을 처리해 주고 있다고 읽으면 안 된다. 원작성자 실행에서 나온 정정 네 건이 전부 이 유형이었다. 축을 나눴으면 각 축이 못 보는 것을 다른 축이 확인해주는 절차까지 있어야 한다.
5. C안 — 합치되 더하지 않는다
A안과 B안을 그냥 더하면 A안이 낸 산출물 목록이 그대로 살아남는다. B안 진단을 A안에 대한 필터로 쓴다. 원작성자 실행에서는 이 기준으로 14개가 5개로 줄었다.
- 매주 반복되는가
- 잔여 수명이 긴가
- 작동·소비 여부를 확인할 방법이 있는가
3번을 통과 못 하면 만들지 않는다.
격하도 결과에 넣는다 — 스킬로 제안된 것이 규약 한 줄로 끝나거나, 상설 에이전트가 일회성 스프린트로 내려앉는 경우가 많다. 뺀 항목은 이유와 함께 §8.2에 남긴다. 목록에서 지워버리면 다음 분석에서 같은 항목이 다시 올라온다.
§8.4 단계 표의 작동 확인 방법 열은 비워두지 않는다. 채울 수 없는 항목은 3번 관문을 통과하지 못한 것이다.
6. 배치 · 커밋
파일명은 세션전수분석_YYYY-MM-DD.md. 배치 경로는 첫 실행 때 사용자에게 묻고, 이후 이 절에 적어 고정한다 — 매번 물으면 노트가 흩어진다. 커밋 메시지는 사용자 규약을 따르고, push는 하지 않는다.
재실행할 때
이전 분석 노트가 있으면 먼저 읽는다.
- §8.4 항목들이 실제로 적용됐는지 작동 확인 방법 열에 적힌 방식으로 판정한다. 여기서 나온 결과가 이번 분석의 가장 단단한 근거다.
- 앞선 결론이 뒤집히면 원문을 고쳐 쓰지 말고 새 절을 붙여 정정 표를 만든다. 절 번호가 정정 이력을 잇는 유일한 끈이다.
- 지난번에 "미확인"으로 남긴 항목부터 본다. 대체로 확인 가능한 것들이 그대로 남아 있다.
하지 않는 것
- 개별 세션 요약. 이 스킬은 여러 달치를 한꺼번에 볼 때만 값을 한다.
- 추출 파일을 외부 서비스에 올리는 것. 필요하면 사용자에게 먼저 알리고 승인받는다.
- B안 프롬프트를 상황에 맞게 "개선"하는 것. 고칠 수 있는 곳은
blank-prompt.md의 마지막 절에 적힌 세 가지뿐이다.
성공 기준 · 존재 의의
같은 폴더의 RATIONALE.md에 있다. 여기 옮겨 적지 않는다 — 두 벌이 되면 갈라진다.
RATIONALE.md는 원작성자의 관측 기록이라 배포에 포함되지 않는다. 이 스킬을 새로 받았다면 자기 관측 기록으로 직접 만든다. 그때 ## 재는 것에는 아래 셋을 그대로 옮긴다 — 메커니즘에 딸린 것이라 사람이 바뀌어도 같다:
- §6(사실과 다른 것) 표가 채워져 있는가. 비어 있으면 검증을 건너뛴 것이고 그 실행은 실패다. 백지 분석이 완벽했을 가능성보다 검증을 안 했을 가능성이 훨씬 크다
- §8.4 산출물 개수가 A안 원안보다 줄었는가. 안 줄었으면 3관문 필터가 작동하지 않았다
- 직전 분석의 §8.4 항목 중 작동 확인이 실제로 가능했던 비율 — 재실행 때 판정된다. 낮으면 문제는 분석이 아니라 "작동 확인 방법" 열을 성의 없이 채운 것이다
쓴맛 보고 모드는 첫째 기준만 형태를 바꿔 적용된다 — 표 대신 "부재 주장을 골라 판정했는가"다. 둘째·셋째는 산출물 목록과 실행 계획을 내지 않는 모드이므로 해당 없음이다. 두 모드의 실행을 한 분모에 섞어 세지 않는다.
이 스킬이 프롬프트가 아니라 절차인 이유가 여기 있다. 프롬프트만 복사해 가면 앞의 데이터 창 확인(0단계)과 뒤의 검증·필터(4·5단계)가 같이 가지 않고, 그러면 남는 것은 근거가 안 붙은 제안 목록이다.
사용자가 "이 스킬 의도대로 작동해?" 라고 물으면 그 파일을 읽고 이번 실행과 대조한다.