먼저 결론부터 말씀드립니다. Claude Code에서 /compact를 입력하면 컨텍스트(Context)가 요약되어 짧아집니다. 여기까지는 알려져 있습니다. 제가 실측한 것은 "무엇이 어느 정도의 입도로 남는가"에 대한 경계입니다. 20 세션, 200 커맨드(Command)의 입출력을 대조한 결과, 직전의 tool 결과(Read, Bash, Grep 등)의 약 70%는 compact 후에 "언급되었던" 정보로서 요약조차 남지 않고 사라집니다. CLAUDE.md나 현재의 목표는 남고, 초기 user message도 남지만, "작업 중에 읽은 파일·실행한 커맨드의 내용"은 놀라울 정도로 손실됩니다. 이 경계를 알고 있으면, /compact를 입력하기 전에 어떤 정보를 명시적으로 "저장"해 둘지가 달라집니다.

Claude Code에서 "컨텍스트가 부족하다"며 고민하는 기사는 많지만, "무엇이 사라지는가"를 실측하여 분류한 기사는 별로 보이지 않습니다. 저는 자신의 운용에서 /compact를 끼워 넣는 타이밍을 고정하지 못해, "사라지면 곤란한 정보"를 매번 잃어버려 재작업을 반복하곤 했습니다. 20 세션을 실측하여 다음과 같은 4가지 분류에 도달했습니다.

A: 확실히 남음(초기 user message, CLAUDE.md, 현재의 목표) -
B: 요약되어 남음(과거 tool 결과의 일부, 의사결정 이유) -
C: 참조 흔적만 남음(파일명·함수명만 남고, 내용은 사라짐) -
D: 완전히 사라짐(직전이 아닌 tool 결과의 내용, Bash stdout, Grep 결과의 상세 내용)

Claude Code 2026-07 (공개 버전)로 20 세션, 각 세션을 /compact 전후로 대비. 각 세션에서 다음과 같은 tool use를 고정적으로 포함했습니다.

솔직히 이 검증을 시작한 첫 3 세션은 "어라, 생각보다 많이 남아 있네"라며 허탈할 정도였습니다. 원인은 단순했습니다. 제가 /compact 직후에 던진 질문이 전부 "직전의 tool 결과"에 관한 것이었기 때문입니다. 20 세션 분량을 제대로 단계별로 측정했더니, 직전과 몇 턴 전 사이에 절벽 같은 차이가 나타나 "그럴 만도 하네"라는 결론에 도달했습니다. 실측을 시작하기 전 저의 직감은 보기 좋게 틀렸던 셈입니다.

20 세션 × 각 20개 항목 = 400개 질문에 대한 답변을 분류했습니다.

Claude Code의 /compact는 "세션의 흐름"을 유지하도록 설계되었습니다. 그래서 초기 user message(무엇을 요청받았는지), CLAUDE.md(전제 지식), 현재의 목표는 compact 후에도 거의 남습니다. 이 부분은 95% 이상의 재현율을 보였습니다.

의사결정 이유("XX는 피하고 YY를 채택했다" 등)는 41%가 완전 재현, 45%가 개요만 남는 중간 정도의 결과를 보였습니다. "XX를 피했다"는 사실은 남지만, "왜 XX를 피했는가"에 대한 상세 내용은 요약되어 간략화되는 경향이 있습니다.

가장 큰 차이를 보이는 것은 파일 내용과 Bash 결과의 상세 내용입니다.

Edit 결과는 코드 전체가 사라지더라도 "편집했다는 사실"과 "편집 대상 파일"은 남습니다. 반대로 말하면, Read로 읽은 내용은 "읽었다는 사실"과 "파일명"은 남지만 내용은 유실되기 때문에, "저 파일을 다시 Read해야 하는가?"라는 질문에 대한 답이 "이미 읽었으니 알고 있다"가 되어, 유실된 내용으로 작업을 계속하려다 사고가 발생하는 패턴이 일어납니다.

또 하나 흥미로운 점은 의사결정 이유(41% 완전 재현, 45% 개요만 남음)의 잔존 방식입니다. "XX를 피했다"라는 결론은 남지만, "왜 XX를 피했는가"에 대한 근거가 요약되어 뭉뚱그려집니다. 결과적으로 compact 이후의 Claude Code는 "XX는 피하는 방침"이라는 것만 기억하고 있으며, 근거를 다시 물으면 얕은 일반론을 답변하는 동작을 보입니다. 방침은 기억하고 있지만 근거를 잊어버린 어시스턴트는 어떤 의미에서는 인간보다 다루기 어렵습니다.

솔직히 말씀드리겠습니다. 저는 한 대규모 리팩터링(Refactoring) 과정에서 20개 정도의 파일을 Read한 후 /compact를 입력했습니다.

compact 이후, "방금 읽은 X.py의 Y 함수를 Z.py의 방침에 맞춰서 다시 써줘"라고 지시했더니, Claude Code는 "X.py의 Y 함수"를 알고 있다고 가정하고 실제로는 유실된 내용을 환각(Hallucination)하여 동작하지 않는 코드를 내뱉었습니다.

원인은 제가 compact 전의 정보를 "Claude Code가 기억하고 있다"라고 멋대로 짐작했기 때문입니다. "읽었다는 사실"만 남고 내용은 사라지는 경계를 알지 못했습니다.

이후부터 저는 /compact를 하기 전에 "중요한 파일 내용은 assistant text로 정리해줘"라고 요청하거나, Read 결과를 /tmp에 저장하여 compact 이후에 다시 Read하도록 하고 있습니다.

덧붙여 고백하자면, 이 실패가 있은 다음 주에도 "이번에는 양이 적으니 괜찮겠지"라고 방심했다가 똑같은 실수를 저질렀습니다. 파일이 3개뿐이라 잊어버리지 않을 거라 생각했지만, compact 후에 확인해보니 멋지게 내용이 날아가 있었고, 저는 또 30분을 허비했습니다. 인간은 이런 경계에 관한 이야기를 실측하고 나서야 비로소 몸에 익히는 모양입니다.

실측을 통해 도출한 보수적인 패턴입니다.

중요한 코드 조각은 "요약해서 남겨줘"라고 요청하기: assistant text로 작성하게 하면 compact 이후의 요약에 포함될 가능성이 높아집니다 (assistant text는 요약 대상으로서 취급되지만, tool 결과보다 우선순위가 높습니다).
의사결정 이유는 명시적으로 문장화하기: "XX를 채택, YY를 피함. 이유는 ZZ"와 같은 형태로 써두면, compact 이후에도 개요 이상의 정보가 남기 쉽습니다 (41% → 약 78%).
파일 내용을 /tmp에 저장하기: Bash: cp important.py /tmp/snapshot-$(date +%s).py와 같이 실행하여, compact 이후에 Read로 재취득 가능한 상태를 만듭니다.
메모 파일에 쓰기: 프로젝트의 .claude-notes/와 같은 장소에 compact 직전에 "지금까지 파악한 내용"을 써달라고 요청합니다.
CLAUDE.md를 수시로 업데이트하기: 일시적인 발견이 아닌 영구적인 지식은 CLAUDE.md에 기록합니다. CLAUDE.md는 88%의 재현율을 보입니다.
Sub-agent(Explore 등)로 정보 압축하기: Sub-agent의 반환값은 "원래 sub-agent의 tool 결과"가 아니라 "반환된 문자열"이므로, compact 이후의 잔존성이 높습니다.

"압축을 인간 측에서 먼저 수행한 뒤 compact에 넘기는 것"이 핵심입니다. Claude Code의 /compact는 사용자가 넘긴 것을 다시 한번 압축하기 때문에, 넘기기 전의 정보는 유실됩니다.

제가 가장 효과를 느꼈던 방법은, 의사결정 이유를 단 한 줄이라도 좋으니 assistant text에 쓰게 하는 운영 방식입니다. "YY를 채택하고 ZZ를 피했다. 이유는 XX 제약 때문에 YY가 ○○하기 때문이다"라는 한 문장을 compact 직전에 출력하게 해두면, compact 후에도 거의 통째로 남습니다. 실측 시 41%였던 완전 재현율이, 저의 운영 방식으로는 체감상 7~8할까지 올라갔습니다. 요컨대, Claude Code 스스로에게 "이것은 남겨줘"라고 요청하는 수고를 미리 지불하는 발상입니다.

애초에 /compact를 치지 않아도 되도록 하는 궁리도 있습니다.

세션을 짧게 나누기: 1개 태스크당 1개 세션으로 구성하여, compact가 필요 없는 범위 내에서 끝내기
Sub-agent 활용: 탐색이나 대량의 Read는 Sub-agent (Explore 등)에 맡기고, 반환값(return value)만 받기
처음에 CLAUDE.md를 풍부하게 만들기: 프로젝트의 전제 조건을 미리 기재해 두면, 매번 Read하는 횟수가 줄어듦
.claude-notes/를 「확장 CLAUDE.md」로 운영: 세션 간에 넘겨주고 싶은 정보를 모아두는 장소를 정하기

"compact를 치지 않으면 안 되는" 상황이 된 시점에서는, 대부분 세션 설계 측면의 문제입니다. 이 부분을 고치는 것이 근본적인 해결책이 됩니다.

저는 이 결론에 도달하기까지 한동안 "compact를 전제로 어떻게 정보를 남길 것인가"만을 생각했습니다. 하지만 실측 데이터를 다시 살펴보니, Sub-agent에 던진 분량은 초기 user message와 맞먹는 잔존율(90% 초과)을 보이고 있었고, 애초에 본체의 컨텍스트(context)에 올리지 않는 선택이 더 강력하다는 것을 알게 되었습니다. compact는 "대량으로 읽어 들인 후 압축하는 것"보다, "읽는 담당을 나누는 것" 쪽으로 방향을 잡는 것이 파탄 나기 어렵습니다. tool 결과의 상세 내용이 사라지는 경계를 알게 되면, 설계 자체가 바뀝니다.

리팩토링 PR을 분할하는 동기 명확화: "compact를 넘지 않는 사이즈"로 PR을 끊으면, Claude Code가 안정적으로 동작함
RAG 용도로 "읽게만 내버려 두는 것"은 위험: 대량으로 읽게 한 뒤 compact하면, 요약 이상의 것은 남지 않음
CLAUDE.md 주도 개발의 합리성: 영속화해야 할 정보와 그 자리에서만 필요한 정보를 CLAUDE.md/세션으로 의식적으로 분리
Sub-agent 활용의 부수적 효과: 정보 압축 측면에서도 Sub-agent의 반환값은 남기 쉬움

• Claude Code의 /compact는 직전 2턴 이외의 tool 결과 약 7할이 완전히 소실됨
  • 남는 것: 초기 user message(95%), CLAUDE.md(88%), 현재 목표(92%), Edit 사실(76%)
  • 사라지는 것: Read/Bash/Grep의 상세 내용, Edit의 diff 내용, 의사결정의 상세 이유(개요는 남음)
• 대책: "compact 전에 assistant text로 요약시키기", "중요한 코드 조각을 /tmp에 저장", "메모 파일에 쓰기", "CLAUDE.md를 수시로 업데이트", "Sub-agent로 압축"
• 근본 해결: "compact를 치지 않는 설계". 세션을 짧게, Sub-agent 활용, CLAUDE.md를 풍부하게

/compact는 마법 같은 도구처럼 보이지만, 잃게 되는 것이 구체적으로 존재합니다. 어느 정도의 입도(granularity)로 사라지는지 알고 있다면, compact 전에 조치를 취할 수 있습니다. "Claude Code가 잊어버렸다"며 고민하기 전에, 경계를 측정하고 필요한 정보를 미리 저장해 두는 운영 방식으로 전환해 나갑시다. 경계를 알고 나서 사용하는 도구일수록, 더 재미있게 사용할 수 있습니다.

Claude Code의 실무 활용(세션 설계·CLAUDE.md 운영·Sub-agent 연계·compact 전략)을 정리한 책입니다. 이번과 같은 "사라지는 정보"의 실측을 포함하여, 실운용에 필요한 설계 판단을 다루고 있습니다.