Claude Code에서 /compact를 실행했을 때 살아남는 것: root CLAUDE.md가 8번 중 8번 돌아왔습니다. 호출된 스킬은

세 번의 /compact 작업이 제가 이전에 세션에서 호출했던 스킬의 본문(body)을 누락시켰습니다. 비록 Claude Code 문서에서는 호출된 스킬 본문이 재주입된다고 명시하고 있음에도 불구하고 말입니다: 두 경우 모두 claude -p --resume을 통해 /compact가 전송되었지만, 단일 프로세스 내에서 실행된 6개의 /compact 작업은 매번 해당 스킬을 다시 연결했습니다. 8개 모두는 root CLAUDE.md와 그 @import를 디스크에 있던 것과 정확히 동일하게 되돌렸고, 채팅창에 입력된 암호 구문(passphrase)만 요약본 안에 유지했으며, Claude Code가 압축 후 다시 읽어들이는 파일들 사이에 있을 때 새로운 '읽기 전용' 상태 없이 중첩된 CLAUDE.md를 되찾아 왔습니다.

이 계정은 지난 7월에 Claude Code에서 컴팩션 시 살아남는 것과 규칙을 유지하는 방법이라는 글을 게시했습니다. 이 글은 지침들을 컴팩션 시 살아남는 것과 사라지는 것으로 분류하고, 나머지 부분에 대해서는 matcher: compact를 가진 SessionStart 훅(hook)을 권장했습니다. 당시에는 측정 결과가 제시되지 않았고, 스킬에 무슨 일이 일어나는지에 대해서도 언급하지 않았습니다. 다만 마지막에 조언 하나를 남겼는데, 세션 중간에 수동으로 /compact를 실행하여 에이전트가 여전히 규칙을 가지고 있는지 확인하라는 것이었습니다. 그 이후로 Claude Code 문서에는 컴팩션 후 무엇이 일어나는지를 메커니즘별로 나열한 표가 생겨났습니다. 이 글은 바로 그 수동 점검이며, 지난 7월의 게시물과 문서 속 표를 나란히 비교하여 테스트합니다.

이 방법은 Six CLAUDE.md files, six codewords에서 가져온 것으로, 각 CLAUDE.md가 처음 로드되는 시점을 측정했습니다. 이번에는 /compact 실행 후 무엇이 남는지에 대한 질문입니다. 저는 다섯 군데에 마커 문자열을 넣었습니다: 루트 CLAUDE.md, @로 임포트된 파일, 서브디렉터리의 CLAUDE.md (컴팩팅 전에 Read를 통해 로드됨), 컴팩팅 전에 호출된 스킬의 본문, 그리고 채팅창에 입력된 비밀 문구입니다. 컴팩팅 후, 저는 모델에게 여전히 볼 수 있는 마커가 무엇인지 질문했고, 그 답변을 ~/.claude/projects/ 아래 세션 기록과 비교했습니다. 이 경로는 Claude Code가 보내는 모든 첨부 파일과 모든 요청의 토큰 사용량을 기록합니다. 나중에 실행에서는 범위 지정되지 않은 규칙(unscoped rule), 경로 지정 규칙(path-scoped rule), 그리고 컴팩트 훅(compact hook)이 추가되었습니다.

모든 것은 2026-09-30에 Claude Code 2.1.285 (claude --version)와 claude-opus-5-5를 사용하여 임시 디렉터리에서 실행되었으며, 총 18개의 claude -p 프로세스, 8번의 컴팩팅, 12번의 프로브가 있었습니다.

claude -p가 /compact를 아예 실행할 수 있을까?

headless page에는 -p 모드에서 명령 지원이 어떻게 다른지 나열되어 있습니다: 사용자 호출 스킬과 사용자 정의 명령은 작동하지만,

두 가지 방식 모두 CLI(Command Line Interface)에서 작동합니다. claude -p "/compact" --resume <session-id> --output-format json 명령어는 약 20초 후에 "result": ""와 num_turns: 0을 반환했으며, 트랜스크립트에는 compact_boundary 기록(구성: "trigger": "manual", "preTokens": 23412, "postTokens": 1740)이 추가되었고 로컬 명령어 출력물인 Compacted (ctrl+o to see full summary)가 표시되었습니다. --input-format stream-json을 사용하여 시작된 단일 프로세스는 /compact를 세 번째 사용자 메시지로 사용했습니다. 이 프로세스의 출력 스트림은 compacting 상태 이벤트, compact_boundary 이벤트, 그리고 빈 문자열의 결과를 보여주었습니다. 실험실에서는 두 가지 방식 모두를 사용했으며, 그 차이점이 주요 발견점으로 밝혀졌습니다.

실험실 (The lab)

기본 레이아웃은 다섯 개의 파일과 하나의 채팅 메시지로 구성됩니다:

CLAUDE.md                          루트 코드워드: MK-ROOT-4417, 이후 @notes/imported.md
notes/imported.md                  임포트 코드워드: MK-IMPORT-2290
sub/CLAUDE.md                      하위 디렉토리 코드워드: MK-SUB-6621
...

네 개의 명령어 파일은 아무것도 요청하지 않는 채우기 줄(filler lines)로 패딩되어 있습니다. 세션은 네 가지 메시지를 전송합니다: /lab-skill; 다음으로 "남은 세션 동안, 암호는 MK-PASS-8053입니다. 이제 sub/data.txt에서 Read 도구를 한 번 사용하고 그 파일의 첫 번째 줄만 답하세요." (이 Read 명령이 sub/CLAUDE.md를 로드합니다); 다음으로 /compact; 그리고 프로브(probe) 메시지입니다.

암호 메시지와 /compact 사이에, 스크립트는 루트 CLAUDE.md, 임포트 파일, 중첩된 CLAUDE.md, 그리고 SKILL.md 파일을 새로운 번호(MK-ROOT-7093, MK-IMPORT-6158, MK-SUB-3846, MK-SKILL-5702)로 재작성합니다. 이 수정 작업이 답변을 읽기 가능하게 만듭니다. 압축(compaction) 후에는 이전 번호가 대화 기록(요약 또는 Claude Code가 보관한 사본)에서만 왔을 수 있습니다. 반면, 새로운 번호는 오직 디스크에서만 올 수 있습니다. 암호는 절대 수정되지 않으며, 디스크에 사본도 전혀 없습니다.

프롬프트(probe)는 다음과 같았습니다: “도구는 사용하지 마십시오. 현재 컨텍스트에 이미 있는 것 중에서 MK-로 시작하는 모든 문자열을 한 줄에 하나씩 나열하십시오. 각 문자열 다음에는 그것이 나타난 위치를 몇 단어로 추가하십시오. 볼 수 없는 문자열은 추측하지 마십시오.” 저는 모델에게 전송된 트랜스크립트 기록에서 MK- 문자열을 모두 수집했습니다. 12개의 모든 프롬프트에서 모델의 목록과 트랜스크립트의 목록이 동일했으므로, 아래에 트랜스크립트를 제시하고 답변은 주석으로 작성하겠습니다.

다섯 가지 형태가 각각 두 번씩 실행되었습니다:

• A, 재개(resumed): 다섯 개의 claude -p 프로세스가 단계별로 실행되었으며, 각 단계는 첫 번째 단계에서 --resume 옵션으로 시작했습니다. 이 단계들은 스킬 호출, 암호 구문 메시지, --fork-session을 사용한 프롬프트 (원본 세션을 건드리지 않는 제어용), /compact, 그리고 프롬프트를 포함합니다.
• B, 단일 프로세스: 편집 내용을 사이에 두고 하나의 claude -p --input-format stream-json 프로세스를 통해 동일한 네 가지 메시지를 처리했습니다.
• BC: /compact가 없는 B의 버전으로, 제어용입니다.
• C: .claude/rules/always-on.md에 범위 지정되지 않은 규칙(unscoped rule)을 추가하고, `paths: [

Project-root CLAUDE.md는 compaction을 거쳐도 살아남습니다: /compact 실행 후, Claude는 이를 디스크에서 다시 읽어 세션에 재주입(re-inject)합니다. 하위 디렉터리에 있는 중첩된 CLAUDE.md 파일과 paths: 프런트매터가 적용된 규칙들은 Claude가 해당 파일을 읽을 때 다시 로드됩니다.

context window page에는 "What survives compaction"이라는 제목 아래 표가 있습니다. 여기서 중요한 행은 다음과 같습니다:

또 다른 문장이 편집이 공정한 테스트인 이유를 설명해 줍니다. prompt caching page에 따르면: "사용자의 project-root 및 user-level CLAUDE.md 파일은 세션 시작 시 한 번 읽혀 메모리에 유지됩니다. 세션 중간에 편집하더라도 캐시가 무효화되지는 않지만, 해당 편집 내용도 적용되지 않습니다." 새로운 콘텐츠는 다음 /clear, /compact 또는 재시작(restart) 시 로드됩니다.

저는 2026-09-30에 trafilatura를 사용하여 모든 페이지를 전체 텍스트로 가져왔습니다. Trafilatura가 표와 시작 보기 텍스트를 누락했기 때문에, 저는 이 두 가지 내용을 해당 페이지의 markdown 버전에서 가져와 HTML과 비교해 보았고, 문구가 일치했습니다.

무엇이 돌아왔는가

그리고 같은 세션이 --resume을 통해 압축된 경우, A1:

루트 파일이 디스크에서, 이전 모습 옆에 복구되다

모든 8번의 실행에서, 압축 후 첫 번째 턴은 instructions 첨부물과 함께 루트 CLAUDE.md 및 notes/imported.md를 그 순간 디스크에 있던 상태로 가지고 있었습니다. 편집이 있었던 6개 실행에서는 각각 7093과 6158을 의미했습니다. 압축 없는 제어군(control) BC는 프롬프트 캐싱 페이지를 확인했으며: 같은 편집 후에도 모델은 여전히 4417과 2290만 보았습니다. 재개(Resuming)는 해당 페이지의 문장에서 재시작으로 간주됩니다. 압축이 없는 신선한 프로세스인 A의 포크 프로브(fork probe)는

요약본이 핵심입니다. 모든 8개의 요약본은 이전의 모든 마커를 나열했기 때문에, 6번의 편집 실행에서 모델은 압축(compaction) 후 두 개의 루트 코드워드를 유지했습니다: 요약본에는 4417, 파일에는 7093입니다. 새로운 파일을 담은 첨부 파일은 재개(resume) 사례와 달리 어떤 것도 대체한다는 내용이 없었습니다. 6번의 모든 편집 실행에서 이를 인지했습니다. A2는 "파일이 변경되었거나, 요약본이 틀린 것입니다. 여기서는 어느 쪽인지 알 수 없습니다."라고 말했습니다. B1과 B2도 이 점을 명확히 하지 않았습니다. C1은 파일 편("위의 파일 내용은 신뢰해야 하는 내용입니다.")을 들었고, C2 역시 "요약본이 아마 그 다섯 가지 값을 잘못 기록했을 것입니다"라며 격차를 설명했습니다. 하지만 그렇지 않았습니다. 요약본은 이미 변경된 파일에 대한 정확한 기록이었습니다. A1은 불일치를 보고하며 실제로 자신에게는 새로운 숫자들만 표시되었다고 지적했습니다.

CLAUDE.md 파일을 긴 세션 동안 편집한 후 압축(compacting)하면 정확히 이러한 상태가 만들어집니다: 컨텍스트에는 새 텍스트가, 요약본에는 이전 텍스트가 재진술되고, 이전 내용을 폐기하는 것은 아무것도 없습니다.

스킬 본문(skill body): 하나의 프로세스로 재첨부되지만, --resume 후에는 누락됨