STRONG_RE = re.compile(
r"(続きから|つづきから|前回|前のセッション|さっきのセッション|再開|申し送り|"
r"引き継|この前|昨日|一昨日|先ほどのセッション|resume|pick up where)")
...

def is_young(payload: dict) -> bool:
tp = payload.get(

범위를 넓게 잡으면 툴 로그(tool log)를 대량으로 수집하게 되어 다이제스트(digest)가 지저분해집니다. **의도적으로 좁게 설정해 두었습니다.**

노이즈 제거를 위해 한 종류가 더 필요했습니다. 대화 로그의 끝부분은 저장 명령의 전개로 채워지기 때문에, 이를 제거하지 않으면 **최근의 실제 지시 사항이 밀려나게 됩니다**.

실제로 주입되는 것은 다음과 같은 골격이 됩니다 (내용은 숨겼습니다).

서두의 지시문이 중요했습니다. 다이제스트만 전달하면 "아마 이 내용의 다음 단계겠지"라며 시작해 버립니다. **"한 문장으로 말할 수 없다면 거슬러 올라가라", "추측으로 시작하지 마라"를 주입문 자체에 심어 두었습니다.** `--rank 1`, `--rank 2`와 같이 한 단계씩 이전으로 거슬러 올라갈 수 있으며, 상한은 5개로 정해 두었습니다.

### 왜 매 세션마다 전부 넣지 않는가

훅(hook)의 주석에 그대로 적혀 있습니다.

매 세션마다 무조건 다이제스트를 주입하면, 이력과 무관한 단발성 작업에서도 수천 토큰을 상시 과금하게 됩니다. 재개 의사가 확인되었을 때만 비용을 지불하는 것이 옳습니다.

`SessionStart` 측에는 "이력이 N건 있음"이라는 두 줄의 이정표만 남겨 둡니다.

## 망가지는 방식 1 —— 결론은 남지만, 증거는 남지 않는다

여기서부터가 본론입니다.

인계가 작동하기 시작한 후부터, 기록 속에 자기 수정이 쌓여갔습니다. 오늘 측정한 출현 횟수입니다.

| 용어 | 프로젝트 `CLAUDE.md` | 인계 파일 |
|---|---|---|
| 정정 | 32 | 9 |
| 오류 | 28 | 15 |
| 철회 | 13 | 8 |
| 오독 | 4 | — |
| 오판정 | 5 | — |

나아가, **이전 세션의 기술을 직접 지목하며 "오류", "철회"라고 명시한 행이 15행** 있습니다 (`grep "前セッション"` 결과 중 `오류|철회|정정|오독|위음성|사용하지 말 것`으로 필터링한 건수, 2026-08-03).

가장 비용이 많이 발생한 사례를 들어보겠습니다.

**공개한 툴의 이름을 바꿨더니 검색 순위가 사라졌다**는 관측이 있었습니다. 인계 파일에는 다음과 같이 남았습니다 —— "**이름 변경은 검색 인덱스를 파괴한다**". 다음 세션은 이를 전제로 하여, 이름 변경이라는 수단을 선택지에서 제외했습니다.

다음 날 다시 측정해 보니, **파괴된 것은 인덱스가 아니라 측정 코드**였습니다. 순위 취득에 사용하던 행 셀렉터(row selector)가 1페이지 24건 중 **6건밖에 가져오지 못하고 있었던 것**입니다. 스크롤을 해도 늘어나지 않았습니다. "범위 외"는 실재하지 않았고, 단지 이쪽에서 보이지 않았을 뿐이었습니다.

문제는 오측정 그 자체가 아닙니다. **오측정은 반드시 일어납니다.** 문제는 인계 파일에 남은 것이 "이름 변경은 인덱스를 파괴한다"라는 **결론뿐**이었고, "행 셀렉터로 DOM에서 계산함 · n=42 · 1회만 수행"이라는 **측정 방법이 남지 않았다**는 점입니다. 측정 방법이 적혀 있었다면, 다음 세션에서 "n=42는 1페이지의 건수와 맞지 않는 것 아닌가"라고 의심할 수 있었을 것입니다.

동일한 구조의 철회가 다른 곳에도 여러 개 남아 있습니다.

- "A 그룹의 중앙값은 B 그룹의 **36배**" → 모집단을 깊게 다시 추출했더니 **2.5배**로 줄어듦 (앞부분만 읽으면 상층부 데이터만 모집단으로 오인함)
- "기존 코드가 더 위험함" → 300번의 요청을 실행했더니 **발생 0건**으로 확인되어 철회
- "상한은 1시간마다 1개씩 생김" → 에러 본문 내용대로 **롤링 24시간 기준 5개**라는 오독이었음

이 모두 **작성된 시점에는 정직한 보고**였습니다. 거짓말을 한 것이 아닙니다. 단정적인 형태로 작성되었고, 증거가 덧붙여지지 않았을 뿐입니다.

## 망가지는 방식 2 —— 가변적인 상태를 단정적으로 적어버린다

이 글을 쓰기 위해, 인계 파일에 적혀 있던 "정정 23 · 오류 20 · 철회 9"라는 숫자를 다시 측정했습니다. 실제로는 **32 · 28 · 13**이었습니다.

인계 파일이 거짓말을 한 것은 아닙니다. **작성된 8/2 시점에는 정확했습니다.** 다만, 그것이 오늘의 값은 아니었을 뿐입니다.

「현재 N개 공개 중」「순위 3위」「남은 수 M건」——**이러한 종류의 가변적인 상태를 인계 사항에 단정적인 문장으로 쓰면, 다음 세션은 그것을 현재 값으로 읽어들입니다.**

대책은 간단했습니다. **기계가 읽을 수 있는 사실은 단정적으로 쓰지 말고 명령어로 만든다.**

실제로 만든 정점 관측 (Fixed-point observation) 스크립트의 서두 주석에는 다음과 같이 적혀 있습니다.

한 줄의 명령어는 100줄의 정확한 인계 사항보다 열등하지 않습니다.

## 고장 나는 방식 3 —— 망가진 로그가 다음 세션으로 전염된다

이것은 인계(Handover) 특유의 사고입니다.

긴 세션에서는 도구 호출(Tool call)이 `malformed` 상태가 되어 망가지는 경우가 있습니다. 망가진 호출이 컨텍스트(Context)에 남으면, 그것이 **본보기(Example)**가 되어 다음 호출도 망가집니다.

인계를 구현하면, 이 망가진 어구가 **저장 → 다음 세션에서 읽기** 경로를 통해 넘어옵니다. 한 세션의 사고가 프로젝트 전체의 사고가 됩니다.

대처 방법은 두 가지였습니다.

- **저장 시에 결정론적인 (Deterministic) 스크립트로 새니타이즈(Sanitize)한다** (LLM에게 청소를 시키지 않는다. 청소 담당자까지 침식되기 때문)
- **대화 로그 본체를** (컨텍스트를 잡아먹을 뿐만 아니라, 파손된 어구의 전염원이 되므로) 읽을 때는 반드시 다이제스트(Digest)를 경유하며, `Read`로 직접 여는 것을 금지한다.

## 대책으로 정한 3가지 규칙

고장 나는 방식들이 모두 정리되었으므로, 규약을 3가지 추가했습니다.

**① 사실에는 「측정 방법·n·날짜」를 반드시 첨부한다**

3가지 점을 적을 수 없는 것은 사실로서 적지 않고, `(미검증)`, `(추정)`, `(n=1)`을 명시합니다.

**② 출처 없는 단정 위에 중요한 판단을 쌓기 전에 1회 다시 측정한다**

「중요한 판단」은 되돌릴 수 없는 작업(이름 변경 · 삭제 · 공개 · 전송), 여러 시간을 투입하는 작업, 방침 전환으로 한정했습니다. 전부 다시 측정하고 있다면 일을 할 수 없습니다. 재측정 비용이 판단 비용을 상회한다면, **그 단정을 근거로 사용하지 않고 판단을 보류한다**고 정했습니다.

**③ 기계가 읽을 수 있는 사실은 단정이 아니라 스크립트로 만든다**

위에서 언급한 바와 같습니다.

예외도 정했습니다. **사용자의 결정·선호는 재측정할 수 없으므로** 인계 사항이 유일한 기록이 됩니다. 공식 문서의 문구나 API 사양과 같은 불변의 1차 정보도 인계해도 됩니다 (단, URL을 병기할 것). 「했다 / 하지 않았다」의 작업 기록은 git 히스토리로 추적할 수 있습니다.

## Windows에서 빠진 2가지 함정

훅(Hook) 구현 측의 이야기입니다. 일본어 환경이라면 반드시 겪게 될 것이라 생각합니다.

**① sys.stdin이 cp932로 열린다**

Windows의 Python은 표준 입력을 cp932로 엽니다. 훅으로 들어오는 입력은 UTF-8이므로, 텍스트 계층을 경유하면 **일본어 프롬프트가 깨져서 탐지 패턴과 일치하지 않게 됩니다.**

까다로운 점은, **예외가 발생하지 않고 조용히 일치하지 않게 된다**는 것입니다. 「이어서」가 깨지면 훅은 아무 일도 하지 않은 채 침묵합니다. 작동하지 않고 있다는 사실을 알아차릴 수 없습니다.

**새로운 훅은 반드시 일본어가 포함된 페이로드(Payload)로 테스트하십시오.** 실제로 이 문제로 2건의 실질적인 피해를 입었습니다.

**② 훅은 사용자의 프롬프트를 절대로 망가뜨려서는 안 된다**

`UserPromptSubmit`은 입력 경로에 개입합니다. 여기서 예외를 던지면 사용자의 입력 자체가 통과되지 않게 됩니다. 모든 예외를 무시(Catch-all)하는 방침으로 정했습니다.

```python
if __name__ == "__main__":
    try:
        sys.exit(main())
...