# Session Audit

> 로컬 Claude Code 세션 로그(~/.claude/projects)를 전수 파싱해 사용자 프롬프트 원본을 복원하고, 틀을 가진 분석(A안)과 틀 없는 백지 분석(B안)을 독립 수행한 뒤, 검증을 거쳐 실행 계획(C안)으로 합쳐 노트로 남긴다. 사용자가 "세션 전수 분석", "내 프롬프트 로그 분석해줘", "백지 분석 돌려줘", "내 작업 방식 분석해줘", "지난 한 달 내가 뭘 했는지 분석", "세션 회고", "자동화 후보 뽑아줘"라고 하거나, 반복 작업을 스킬·에이전트로 만들 근거를 로그에서 찾으려 할 때 사용한다. 개별 세션 요약이 아니라 여러 달치 로그를 한꺼번에 보는 작업에만 해당한다. 출력은 두 모드다 — 노트 파일로 남기는 전수 분석(기본)과, 지적만 대화에 내는 쓴맛 보고("내 로그 좀 까줘", "냉정하게 봐줘", "쓴소리 좀 해줘"). 또한 "이 스킬 의도대로 작동해?", "이 스킬 잘 되고 있어?"처럼 스킬 자체의 효과를 점검해 달라는 요청에도 발동하며, 그때는 같은 폴더의 `RATIONALE.md`를 읽고 이번 세션·기존 기록과 대조한다.

- Skill: `iceberggymnast/session-audit` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add iceberggymnast/session-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/iceberggymnast/session-audit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: iceberggymnast (https://skillmd.com/u/iceberggymnast)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/iceberggymnast/session-audit

---


# 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일치만 남기고 조용히 지워진다. 이 확인을 건너뛰면 **잔존 로그의 범위를 사용 기간으로 읽어** 결론 전체가 틀어진다.

1. `cleanupPeriodDays` 값을 읽는다.
2. 사용자에게 **Claude Code를 실제로 언제부터 썼는지** 묻는다. 로그로는 알 수 없다.
3. 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개로 줄었다.

1. 매주 반복되는가
2. 잔여 수명이 긴가
3. 작동·소비 여부를 확인할 방법이 있는가

**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단계)가 같이 가지 않고, 그러면 남는 것은 근거가 안 붙은 제안 목록이다.

사용자가 *"이 스킬 의도대로 작동해?"* 라고 물으면 그 파일을 읽고 이번 실행과 대조한다.