Claude Code /compact 후 살아남는 것과 덜 잃는 법

발행 2026.10.19출처 DEV · J. Gravelle

클로드 코드레퍼런스준전문가

Claude Code는 압축할 때 무작위로 뭔가를 잊지 않습니다. 실제로 문서에는 정확히 무엇이 남는지 표로 명시되어 있습니다.

나머지는 당신의 오후 몇 시간 분량의 토큰을 몇 백 개 수준의 요약으로 억지로 눌러 넣으려는 모델에 맡겨집니다. 40분이나 들여 찾아낸 그 예외 상황까지 포함해서요.

이와 관련해 해볼 만한 일은 두 가지입니다. 중요한 것은 Claude가 다시 찾을 수 있는 곳에 두는 것, 그리고 압축이 덜 자주 일어나게 하는 것입니다.

그 40분짜리 예시는 제가 지어낸 이야기가 아닙니다. 이번 주말 r/ClaudeCode의 한 게시물에는 “/compact가 그것을 요약으로 ‘고쳐’ 주는데, 그러면 Claude가 40분이나 들인 예외 상황을 잊어버린다”라고 적혀 있었습니다( https://www.reddit.com/r/ClaudeCode/comments/1x9aivo/ ). 다음 날 아침에는 X의 한 창업자가 몇 번만 압축하고 나면 “어느 정도 쓸모없어지는” 오케스트레이터에 대해 묻고 있었습니다.

압축 후 무엇이 돌아오는가

Claude Code 문서의 “What survives compaction” 표에는 다음과 같이 나와 있습니다( code.claude.com/docs/en/context-window, 2026-10-19에 열람):

프로젝트 루트의 CLAUDE.md와 범위가 지정되지 않은 규칙: 디스크에서 다시 주입됩니다.

자동 메모리: 디스크에서 다시 주입됩니다.

plan 모드에서 Claude가 작성한 계획: 디스크에서 다시 주입됩니다.

Claude가 읽거나 수정한 파일: 최대 다섯 개가 다시 돌아오며, 가장 최근에 수정된 것부터 먼저입니다. 5,000 토큰을 넘는 파일은 내용 없이 경로만 돌아옵니다.

Skill 본문: 다시 주입되며, Skill당 최대 5,000 토큰, 전체 합계 최대 25,000 토큰으로 제한됩니다.

compact 매처가 있는 SessionStart 훅: 다시 실행되며, 그 출력이 추가됩니다.

대화 내용과 이전 훅이 추가한 컨텍스트를 포함한 나머지 전부: 요약됩니다.

디스크에 있는 것은 돌아옵니다. 대화에서 나눈 것은 요약됩니다. 그런데 그 40분 동안 예외 상황을 파악하느라 썼던 것은 어디에 있었을까요? 당연히 대화 안이죠.

작업하면서 결정 사항을 디스크에 적어 두기

Claude가 중요한 것을 확정할 때마다 업데이트하는 짧은 메모 파일을 두는 것을 권합니다. 발견한 예외 상황, 거절한 접근법과 그 이유, 버그를 재현하는 테스트 같은 것들입니다.

그다음에는 컴팩션이 끝날 때마다 Claude가 그 파일을 다시 읽게 하세요. 바로 그 용도의 훅이 있습니다. 프로젝트 루트의 .claude/settings.json에 아래 내용을 넣으세요:

코드

123456789101112{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "compact",
        "hooks": [
          { "type": "command", "command": "cat .claude/session-notes.md" }
        ]
      }
    ]
  }
}

한 가지 주의할 점이 있습니다. 그 파일은 짧게 유지하세요. 훅이 출력한 모든 것은 압축 후 다시 컨텍스트로 들어가고 그 뒤의 모든 턴에 따라붙습니다. 메모를 3,000줄짜리 자서전으로 만들어 버리면, 토큰을 낭비하는 또 다른 방법을 발명한 셈입니다.

같은 문서 페이지에서 알아둘 또 하나의 세부 사항이 있습니다. 중첩된 CLAUDE.md 파일과 paths: frontmatter가 있는 규칙은 필요할 때만 다시 로드됩니다. 그렇지 않으면 나머지와 함께 요약되어 사라집니다. 어떤 규칙이 반드시 살아남아야 한다면, 그것이 있어야 할 곳은 루트 CLAUDE.md입니다.

요약기에게 무엇이 중요한지 알려 주기

/compact에 무엇을 보존하고 싶은지도 알려 줄 수 있습니다:

코드

/compact Keep the retry edge case in payments/charge.py and the test that reproduces it

또는 CLAUDE.md 안의 # Compact instructions 제목 아래에 상시 지침을 넣어 두면, 매번 같은 내용을 입력해야 한다는 걸 기억하지 않아도 됩니다. 설정 비용은 들지 않습니다.

벼랑 끝이 아니라, 일정에 맞춰 압축하기

/autocompact 300k는 Claude Code가 스스로 압축하기 전에 컨텍스트 창을 어느 정도까지 채울 수 있는지 알려 줍니다. 100K부터 1M까지 설정할 수 있습니다.

언제 압축하느냐도 비용에 영향을 줍니다. 문서에 따르면 /compact는 요약 중인 대화 전체를 읽습니다. 프롬프트 캐시가 따뜻한 상태라면 그 비용은 비교적 저렴합니다. 구독에서는 1시간, API 키에서는 기본값으로 5분인 캐시 수명을 넘겨 휴식을 취하면, 같은 기록도 캐시되지 않은 입력으로 처리됩니다.

그러니 점심 먹으러 갈 예정이라면, 떠나기 전에 압축하세요. 돌아온 뒤가 아니라요.

그리고 대화가 끝났고 연속성이 전혀 필요 없다면 /clear는 비용이 들지 않습니다.

압축이 덜 자주 일어나게 하기

압축은 컨텍스트 창이 가득 차기 때문에 발생합니다. 코딩 세션에서는 그것을 채우는 것의 상당 부분이 소스 코드입니다.

Claude는 함수 하나가 필요합니다. 그 함수가 들어 있는 파일을 엽니다. 그러면 파일 전체가 컨텍스트로 끌려 들어와 다음 압축 전까지 그 자리에 머뭅니다. 함수가 그 안에서 차지하는 비중은 아주 작더라도요.

다음은 FastAPI 0.115.0의 fastapi/routing.py에서, tiktoken의 cl100k_base로 센 실제 측정값입니다:

코드

whole file:          32,397 tokens
get_request_handler:  1,137 tokens

자신의 코드와 비교해 보려면 아래 스크립트를 사용하면 됩니다(pip install tiktoken을 먼저 하세요):

코드

123456789import ast, sys, tiktoken
path, name = sys.argv[1], sys.argv[2]
src = open(path, encoding="utf-8").read()
enc = tiktoken.get_encoding("cl100k_base")
for node in ast.walk(ast.parse(src)):
    if isinstance(node, (ast.FunctionDef, ast.AsyncFunctionDef, ast.ClassDef)) and node.name == name:
        print(f"whole file: {len(enc.encode(src)):,} tokens")
        print(f"{name}: {len(enc.encode(ast.get_source_segment(src, node))):,} tokens")
        break

python fn_vs_file.py fastapi/routing.py get_request_handler

에이전트가 찾아온 것보다 소스가 대략 28배나 많습니다.

그리고 압축 표의 그 5,000 토큰 줄은요? 이 파일은 그 기준을 훨씬 넘습니다. 그래서 압축 후 Claude는 경로는 다시 얻지만 소스는 얻지 못합니다. 그 함수가 또 필요해지면, 파일 전체를 다시 읽게 될 수도 있습니다.

코딩 세션 중 한 번 /context를 실행해서 무엇이 창을 차지하고 있는지 확인해 보세요. 파일 읽기가 원인이라면 선택지가 있습니다. Claude에게 전체 파일 대신 줄 범위를 읽게 요청하세요. Anthropic의 자체 비용 문서도 타입이 있는 언어에는 코드 인텔리전스 플러그인을 권장합니다. 심볼 인덱스도 또 다른 방법입니다.

솔직히 말하면, 저는 이 싸움에 이해관계가 있습니다. jCodeMunch는 여러분의 저장소를 tree-sitter로 파싱하고 개별 심볼을 인덱싱하는 제 MCP 서버입니다. 에이전트가 함수, 클래스, 메서드가 필요하면 이름으로 요청하고, 파일 전체가 아니라 바이트 오프셋으로 추출된 해당 심볼만 받습니다.

제가 공개한 벤치마크에서는, grep에 이어 상위 3개 파일 전체를 읽는 방식보다 조회당 토큰을 96.6% 줄였고(29.2배), express, fastapi, gin에 걸친 15번의 작업 실행에서 cl100k_base로 측정했습니다. 방법과 하네스는 공개되어 있습니다(github.com/jgravelle/jcodemunch-mcp/tree/main/benchmarks). 제가 놓친 점이 있다면 듣고 싶습니다.

저장소가 클수록 더 큰 도움이 됩니다. 작은 저장소에서는 기본 검색만으로도 이미 비용이 적습니다.

코드

uv tool install jcodemunch-mcp
jcodemunch-mcp init

압축 이야기로 돌아가 보겠습니다. 컨텍스트로 끌려 들어오는 전체 파일이 적을수록 창은 더 천천히 차게 됩니다. 그러면 압축 횟수도 줄고, 오후 내내 공들여 알아낸 내용을 요약기가 놓쳐 버릴 가능성도 줄어듭니다.

같은 버그를 Claude에게 세 번씩 설명하는 것보다는 낫죠...

자주 묻는 질문

/compact는 토큰 비용이 드나요?

네. 전체 대화를 요약하기 위해 전송합니다. 캐시가 따뜻한 상태라면 그 대부분은 비용이 적게 드는 캐시 읽기입니다. 충분히 오래 쉬었다면 기록을 캐시 없이 처리하는 비용을 지불하게 됩니다. /clear는 비용이 들지 않습니다.

압축해도 CLAUDE.md는 유지되나요?

프로젝트 루트의 파일은 유지됩니다. Claude가 디스크에서 다시 읽기 때문입니다. 중첩된 CLAUDE.md 파일과 경로 범위 규칙은 Claude가 그것들을 트리거하는 무언가에 닿을 때까지는 다시 돌아오지 않습니다.

1M 컨텍스트 창이면 이 문제가 해결되지 않나요?

한계선을 더 멀리 옮겨 줄 뿐입니다. 문서에 따르면 더 큰 창에서도 압축은 같은 방식으로 동작하고, 그 창 안의 모든 내용은 여전히 매 턴마다 캐시 요율로 함께 따라옵니다. 더 큰 창은 유용합니다. 더 이상 필요 없는 소스 파일들로 그 창을 채우는 건 좋은 활용법이 아닙니다.

이런 것들에 MCP 서버가 꼭 필요한가요?

아닙니다. notes 파일, SessionStart 훅, compact 지침, /autocompact는 모두 Claude Code에 내장되어 있습니다. 심볼 인덱스는 다른 문제를 해결합니다. 즉, 압축하기 전에 애초에 필요 없는 소스가 컨텍스트에 들어오지 않게 하는 것입니다.