3줄 요약
- 압축으로 잃는 것은 요약 품질이 아니라 디스크에 적히지 않은 결정이다. 어떤 사실이 압축된다고 생각할 때 불안하다면, 그 사실이 대화에만 있다는 신호다.
- 압축은 두 단계로 진행된다. 오래된 도구 출력을 먼저 버리고, 그래도 모자라면 대화를 요약한다. 두 단계 모두 파일에 적힌 내용은 건드리지 못한다.
- 판별은 감이 아니라 검색으로 한다. 방금 확정한 결정을 한 줄로 적어 저장소에서 찾아보고 0건이면 대화에만 있는 것이다.

이 글대로 하면 무엇이 달라지는가 — 세션이 끊기거나 압축되어도 다시 물어봐야 하는 항목이 줄고, 이미 끝낸 일을 모르고 다시 하는 중복 작업을 저장점 문서 한 줄로 막을 수 있다.

압축이 두려운 사실이 있다는 것은 무엇을 뜻하는가?

그 사실의 권위가 대화에만 있다는 뜻이다. 압축은 대화를 요약하는 동작이고, 파일은 읽어 오는 대상이라 요약 대상이 아니다. 그러므로 압축을 앞두고 잃을까 걱정되는 항목이 있다면, 그 항목이 아직 파일이 되지 못했다는 것이 문제의 정확한 위치다.

이 관점을 놓치면 대책이 엉뚱한 곳으로 간다. 처음 진단은 "요약을 더 정교하게 시키면 된다"였다. 압축 지침을 길게 쓰고 무엇을 보존할지 목록으로 지정하는 방식이다. 이 진단이 틀린 이유는 압축이 한 번으로 끝나지 않기 때문이다. 2세대부터는 요약의 요약이 되고, 수치와 이유가 세대마다 마모된다. 요약기의 성능이 아무리 좋아도 앞 세대에서 이미 사라진 원문을 복원하지는 못한다.

진짜 원인은 요약의 품질이 아니라 권위의 위치였다. 그래서 대책도 바뀐다. 요약을 잘 시키는 대신, 요약당해도 무해한 상태를 만든다. 결정과 수치와 미완 항목이 저장소 파일에 적혀 있으면 대화가 얼마나 줄어들든 다음 세션이 파일을 다시 읽는다. 압축이 언제 발동하는지, 그것이 누적이 아니라 한 턴에 좌우된다는 측정은 압축은 누적이 아니라 한 턴이 부른다에 따로 정리했다.

자동 압축은 무엇을 버리고 무엇을 남기는가?

두 단계로 진행된다. 오래된 도구 출력을 먼저 폐기하고, 그래도 여유가 모자라면 대화를 요약한다. 이 순서가 중요한 이유는 1단계가 우리가 가장 많이 흘리는 것을 먼저 가져가기 때문이다. 파일 전체를 읽은 결과나 긴 로그처럼 크기가 큰 도구 출력이 여기에 해당한다.

2단계인 대화 요약에서 무엇을 남기고 무엇을 버릴지는 지침으로 정할 수 있다. 지침 파일에 적어 둔 목록은 다음과 같다.

여기에 세대 열화를 늦추는 규칙을 하나 덧붙였다. 직전 요약에서 이어받은 항목은 다시 요약하지 말고 원문 그대로 옮기고, 새로 생긴 내용만 요약한다. 이 규칙은 마모 속도를 늦추지만 마모 자체를 없애지는 못한다. 규칙을 줄여 옮기는 과정에서 방향이 뒤집히는 현상은 규칙을 요약하면 방향이 뒤집힌다에 따로 다뤘다. 지침 문서를 압축하며 유실된 21건 중 6건이 같은 패턴이었고, 살아남는 쪽은 늘 짧은 쪽인 금지와 경고였다.

압축 직전에 자동으로 도는 보조 장치도 하나 둔다. 압축 시작 시점에 전사 원문을 별도 폴더에 저장하고, 사실 목록 파일을 프로젝트의 .claude/sessions/_auto/ 아래에 남기며, 압축 지침을 다시 주입하는 훅이다. LLM을 부르지 않는 스크립트라 비용이 들지 않는다. 다만 이것은 안전망이지 대책이 아니다. 전사가 남아 있어도 다음 세션이 그것을 다시 읽지는 않기 때문이다.

어떤 사실이 대화에만 있는지 어떻게 판별하는가?

검색해서 0건이면 대화에만 있는 것이다. 판별을 감각에 맡기지 않는 이유는 방금 정한 것일수록 기억이 생생해서 이미 적었다고 착각하기 쉬워서다. 절차는 세 단계다.

1. 방금 확정한 것을 한 줄로 적는다. 결정, 수치, 실패한 경로 중 하나여야 한다. "이번 배치는 6모가 아니라 7모로 돌린다"처럼 뒤에 검색할 수 있는 고유한 낱말이 들어가게 쓴다.

2. 저장소에서 그 낱말을 찾는다. 저장점 문서, 백로그, 세션 로그를 함께 본다.

grep -rn "ok=5/5" HISTORY.md docs/BACKLOG.md .claude/sessions/ | head -20

3. 0건이면 그 자리에서 적는다. 다음 턴으로 미루지 않는다. 미루면 그 다음 턴에 압축이 들어올 수 있고, 압축된 뒤에는 무엇을 적어야 했는지조차 흐려진다.

판별 기준을 표로 정리하면 다음과 같다. 왼쪽이 참이면 기록 대상이다.

두 번째 줄이 실제로 값을 한 번 했다. 백로그에 미해결로 남아 있던 항목이 사실은 이미 해결된 상태였고, 저장점을 갱신하면서 낡은 기록이라고 교정했다. 같은 세션에서 다른 항목도 걸렸다. 어떤 배치가 이미 이틀 전에 실행돼 로그에 ok=5/5로 남아 있었고, 그 기록을 확인한 덕분에 같은 배치를 다시 돌리는 대신 다음 회차 대상으로 옮겼다. 기록의 값어치는 기억을 돕는 데 있지 않고 중복 작업을 막는 데 있다.

저장점 문서에는 무엇을 적는가?

다섯 항목이다. 시간순 일지가 아니라 다음 세션이 이어받을 수 있는 형태로 쓴다.

실패한 접근은 별도로 남긴다. 성공한 경로만 적으면 다음 세션이 이미 막힌 길을 다시 간다. 가설 단위로 결과를 붙여 두면 재시도 여부가 한눈에 갈린다. 검증, 기각, 반증, 미검증 네 가지면 충분하고, 미검증에는 몇 번 시도하고 왜 멈췄는지를 붙인다. 예를 들어 어떤 자료를 특정 경로에서 찾는 시도는 5회 실패 후 시간 상한으로 중단했다고 적었고, 다른 가설은 조사 항목 자체에 필요한 값이 없다는 것이 확인되어 경로 폐기로 닫았다. 앞의 것은 다시 시도할 수 있고 뒤의 것은 다시 시도하면 안 되는 항목이라, 둘을 같은 "실패"로 뭉뜨리면 정보가 사라진다.

세션을 끝내기 전 확인 목록은 이렇게 쓴다.

[ ] 이번 세션의 결정과 그 이유가 저장점 문서에 있는가
[ ] 확정된 수치에 측정일과 측정 방법이 붙어 있는가
[ ] 실패한 접근이 재시도 가능 여부와 함께 적혀 있는가
[ ] 미완 항목에 시작점 경로와 재현 명령이 붙어 있는가
[ ] 대기 중인 외부 응답이나 승인이 적혀 있는가
[ ] 낡아진 기존 기록을 교정했는가

파일에 적었는데도 사라지는 것은 무엇인가?

위치가 잘못된 규칙이다. 여기서 두 번째 오진이 나온다. "파일에 적었으니 안전하다"는 판단은 절반만 맞는다. 압축은 대화를 요약하지만, 대화에 실려 있던 참조 자료도 함께 줄인다. 하위 디렉터리에 둔 지침 파일, 문서 머리말에 적은 적용 범위 규칙, 스킬 본문 같은 것이 그렇게 사라진다. 반면 프로젝트 루트의 지침 파일과 메모리 파일은 디스크에서 다시 주입되므로 압축 뒤에도 남는다.

그래서 규칙의 위치 자체가 설계 대상이 된다. 압축을 넘겨야 하는 규칙은 루트 지침 파일에 두고, 세부는 별도 문서로 두되 언제 그 문서를 읽어야 하는지를 루트에 트리거로 적는다. 이 구조에는 유지 부담이 하나 따라온다. 루트의 요약과 상세 문서가 어긋나면 트리거를 탄 순간 폐기된 규칙을 다시 집어 들게 된다. 그래서 루트를 고쳤으면 상세도 같은 턴에 고친다는 규칙을 함께 둔다.

실패 조건과 대응을 정리하면 다음과 같다.

압축과 새 세션 중 무엇을 고르는가?

기록이 끝난 뒤라면 압축을 반복하는 것보다 인계문을 한 번 쓰고 새 세션을 여는 편이 낫다. 정보 보존과 비용 양쪽에서 그렇다. 압축은 매번 요약 산출 비용에 더해 남은 컨텍스트를 다시 기록하는 비용을 치르고, 그러면서 세대마다 내용이 마모된다. 인계문은 한 번 쓰면 파일로 남아 마모되지 않는다.

인계문은 저장점 문서와 다르다. 저장점은 프로젝트의 누적 기록이고, 인계문은 지금 하던 작업을 다음 세션이 그대로 이어받게 하는 짧은 글이다. 다음 형태면 충분하다.

- 지금 하던 것: <작업 한 줄>
- 이미 끝난 것: <산출물 경로 목록>
- 다음 한 수: <바로 실행할 명령 또는 편집할 파일>
- 건드리면 안 되는 것: <범위 밖 항목>
- 대기 중: <사용자 결정, 외부 응답>

선택 기준은 단순하다. 주제가 바뀌었으면 새 세션이고, 같은 작업을 이어가는 중인데 여유가 모자라면 압축이다. 다만 압축을 고르기 전에 확인할 것이 하나 있다. 지금 잃으면 곤란한 항목이 파일에 있는지다. 없다면 압축보다 기록이 먼저다.

이 방식이 통하지 않는 경우는 언제인가?

기록 자체가 비용이라는 점이 첫 번째 한계다. 모든 판단을 파일로 옮기면 파일이 늘어나고, 읽어야 할 문서가 늘면 매 세션의 시작 비용이 올라간다. 그래서 대상을 좁힌다. 결정과 그 이유, 확정 수치, 실패한 경로, 미완 항목만 적고 과정은 적지 않는다. 무엇을 검토했는지는 대화가 사라지면서 함께 사라져도 대체로 무해하다.

두 번째 한계는 기록의 신선도다. 파일은 압축에 안전하지만 낡는 데는 취약하다. 저장점이 실제와 어긋나면 압축으로 잃는 것보다 나쁘다. 잃은 정보는 다시 물어보게 만들지만 틀린 정보는 틀린 전제 위에서 작업하게 만들기 때문이다. 그래서 저장점 문서에 확정된 사실 절을 따로 두고, 그 안에 교정 기록을 남기는 형식을 쓴다.

세 번째 한계는 이 글의 수치와 동작이 특정 도구와 설정에 묶여 있다는 점이다. 압축이 두 단계로 도는 것, 루트 지침 파일이 다시 주입되는 것은 우리 환경에서 확인한 동작이라 다른 도구에는 그대로 적용되지 않는다. 옮겨 갈 수 있는 것은 판별 질문 하나다. 이 사실이 지금 어디에 있는가. 대화에만 있다면 도구가 무엇이든 그것은 사라질 수 있는 상태다. 같은 원칙으로 검사 규칙을 코드에 박아 둔 사례는 AI가 만든 통계를 잡아내는 법에, 규칙을 문서가 아니라 변환기 동작으로 굳힌 사례는 스타일 블록 하나가 페이지 문서 전체를 오염시킨 이유에 있다.

자주 묻는 질문

Q. 압축이 두렵다는 감각은 무엇을 뜻하는가?
A. 그 사실의 권위가 대화에만 있고 디스크에 없다는 신호다. 파일에 적힌 것은 요약 대상이 아니므로, 잃을까 걱정되는 항목이 있다면 그 항목이 아직 파일이 되지 못한 것이다.

Q. 압축 지침을 정교하게 쓰면 해결되지 않는가?
A. 마모를 늦출 뿐이다. 압축이 반복되면 2세대부터는 요약의 요약이 되어 앞 세대에서 사라진 원문을 복원할 수 없다. 이어받은 항목을 다시 요약하지 않고 원문 그대로 옮기는 규칙이 도움은 되지만 근본 대책은 기록이다.

Q. 어떤 사실이 대화에만 있는지 어떻게 확인하는가?
A. 방금 확정한 것을 검색 가능한 한 줄로 적고 저장점 문서, 백로그, 세션 로그에서 찾는다. 0건이면 대화에만 있는 것이므로 그 자리에서 파일에 옮긴다.

Q. 파일에 적었는데도 압축 후 규칙이 지켜지지 않는 이유는 무엇인가?
A. 위치 때문이다. 하위 디렉터리 지침 파일이나 문서 머리말의 적용 범위 규칙은 압축이 가져가고, 프로젝트 루트의 지침 파일과 메모리 파일은 디스크에서 다시 주입된다. 넘겨야 할 규칙은 루트에 둔다.

Q. 압축과 새 세션 중 무엇을 골라야 하는가?
A. 주제가 바뀌었으면 새 세션이고, 같은 작업을 이어가는 중이면 압축이다. 기록이 끝난 상태라면 압축을 여러 번 반복하는 것보다 인계문을 한 번 쓰고 새로 시작하는 편이 정보 보존과 비용 양쪽에서 낫다.