3줄 요약
- 지침 문서를 압축하는 과정에서 21건의 규칙이 유실됐고, 그중 6건은 같은 패턴이었다.
- 원문이 "예방 + 대응" 또는 "권고 + 경고" 쌍으로 쓴 규칙을 한쪽만 남기면, 규칙의 방향 자체가 뒤집힌다.
- 압축에서 항상 살아남는 쪽은 짧은 쪽(금지·경고)이므로 요약할 때는 긴 쪽(권고·예방)이 남았는지부터 확인해야 하고, 근본 대책은 규칙의 권위를 대화가 아니라 디스크에 두는 것이다.

이 글대로 하면 무엇이 달라지는가 — 지침이나 문서를 요약할 때 규칙이 조용히 반대 방향으로 굳는 자리를 편집 직후에 잡아내고, 폐기된 수치가 되살아나 판단에 다시 쓰이는 일을 막을 수 있다.

지침 문서를 압축하는 과정에서 규칙이 얼마나 유실됐는가?

전역 지침 파일 한 벌을 원문과 전수 대조한 결과 21건이 압축 과정에서 사라진 것으로 확인됐다. 유실이라고 해서 전부 완전히 없어진 것은 아니었다. 규칙의 흔적은 남아 있어도 그 규칙이 원래 담고 있던 조건이나 절차가 빠지면서 의미가 달라진 경우가 상당수였다. 이 유형이 더 위험하다. 사라진 규칙은 없다는 것이 눈에 띄지만, 뜻이 바뀐 규칙은 계속 지켜지는 것처럼 보인다.

유실 21건 중 6건이 같은 패턴이었다는 것은 무엇을 뜻하는가?

유실이 무작위가 아니라 압축이라는 작업 자체에서 나오는 구조적 편향이라는 뜻이다. 21건을 분류해 보니 6건이 하나의 공통 패턴을 갖고 있었다. 원문이 애초에 쌍으로 쓰여 있었다는 점이다. "이렇게 하라(권고)"와 "이런 위험이 있다(경고)"가 함께 있거나, "미리 이렇게 예방하라(예방)"와 "문제가 생기면 이렇게 대응하라(대응)"가 함께 있는 형태였다. 압축 과정에서 이 쌍 중 한쪽만 남았고, 남은 것은 여섯 건 모두에서 짧은 쪽이었다. 사라진 쪽은 길게 서술된 권고·예방이었고, 남은 쪽은 짧게 쓰인 금지·경고였다.

그래서 지침 맨 앞에 분리 규약 세 줄을 새로 박았다. 이 세 줄이 이 글의 결론이기도 하다.

1. 쌍으로 쓴 규칙은 쌍으로 요약한다. 원문이 "예방 + 대응" 또는 "권고 + 경고"로 쓴 것을
   한쪽만 남기면 규칙의 방향이 뒤집힌다. 압축 과정에서 살아남는 쪽은 항상
   짧은 쪽 = 금지·경고다. 그러니 요약할 때 긴 쪽(권고·예방)이 남았는지를 먼저 확인한다.
2. 금지선만 옮기고 대응 절차를 빼지 않는다. "…금지"를 적었으면
   "발견 시 무엇을 하는가"도 적는다.
3. 본문과 상세가 어긋나면 본문이 최신이다. 본문을 고쳤으면 상세도 같은 턴에 고친다.

3번이 나중에 붙은 조항이다. 지침을 얇게 유지하려고 세부를 별도 문서로 분리하면서 "분리본은 원문 그대로일 것"이라고 가정했는데, 그 가정은 이미 깨져 있었다. 본문만 고치고 상세 문서를 그대로 두면, 다음에 그 상세 문서를 읽는 순간 폐기된 규칙을 다시 집어 든다.

압축에서 항상 짧은 쪽만 살아남는다는 것은 왜 위험한가?

권고 없이 경고만 남으면 그 규칙은 금지로 읽히기 때문이다. 압축은 본질적으로 분량을 줄이는 작업이고, 분량을 줄일 때는 짧은 문장이 긴 문장보다 살아남기 쉽다. 그런데 쌍으로 쓰인 규칙에서 두 문장은 하나의 완결된 지침이다. 원래는 "이걸 해라, 다만 이 위험은 주의해라"였는데 남은 것이 위험 쪽뿐이면 "이걸 하지 마라"가 된다.

그래서 요약본을 검토할 때 던지는 질문을 바꿔야 한다. "짧은 쪽이 남았는가"가 아니라 "긴 쪽(권고·예방)이 남았는가" 를 먼저 확인한다. 이 확인 절차를 넣지 않으면 압축을 거듭할수록 규칙이 조용히 반대 방향으로 굳어간다.

뒤집힌 규칙의 실제 사례는 무엇이었는가?

가장 분명한 사례는 서브에이전트 위임 규칙이었다.

원문의 취지는 "큰 조사는 에이전트에 맡기되, 보고 형식은 결론 위주로 짧게 받으라"였다. 그런데 경고 문장만 남자 정반대로 "에이전트 자체를 피하라"는 규칙처럼 보이게 됐다.

이 사례가 특히 위험한 이유는 남은 문장만 보면 아무 문제가 없어 보인다는 데 있다. "보고서는 부모 컨텍스트에 영구 잔류한다"는 문장 자체는 사실이고 경고로서도 유효하다. 문제는 이 문장이 원래 짝이었던 권고 문장 없이 혼자 남으면서, 읽는 쪽이 "그러니 쓰지 마라"로 확장 해석하게 된다는 점이다. 규칙이 틀린 문장으로 바뀐 게 아니라 맥락이 빠진 채로 남아 스스로 방향을 바꾼 것이다. 그러니 유실을 잡아내는 절차도 "틀린 문장을 찾는다"가 아니라 "쌍으로 쓰인 자리에 한쪽만 남아 있는가"를 찾는 방식이어야 한다.

요약은 규칙만이 아니라 수치도 어떻게 망가뜨렸는가?

같은 문서에서 수치도 세 가지 방식으로 망가졌고, 셋 다 문장이 짧아지는 과정에서 일어났다.

첫째, 조건이 떨어져 나간 판별식이다. 원문의 판별식은 "컨텍스트가 갑자기 내려간 것이 곧 압축은 아니다"였다. 우리 환경에서 쓰는 기준은 재기록량(cache_write)이 약 50k 이상이면 진짜 압축이고, 약 10k 이하이면 압축이 아니라 다른 왕복이라는 것이다. 여기에는 "비율로 판별하면 안 된다"는 조건이 붙어 있었다. 진짜 압축에서도 그 비율이 0.58에서 1.00까지 흔들리기 때문이다. 이 조건 문장이 빠지면 남는 것은 "비율을 보면 된다"는 잘못된 판별식이다. 조건을 붙여 하강 22건을 전수로 다시 세니 진짜 압축 12건, 다른 왕복 3건, 세션 재개 아티팩트 7건으로 갈렸다. 조건 없이 셌다면 22건 전부를 압축으로 보고 대책을 세웠을 것이다.

둘째, 측정 방법이 떨어져 나간 수치다. 오진 사슬이 그대로 남아 있다. 처음 진단은 "사고(thinking) 비중이 세 프로젝트에서 각각 36.1%, 29.9%, 90.7%"였다. 이 진단이 틀린 이유는 세는 대상이 잘못됐기 때문이다. 전사에 남은 사고 블록은 본문이 빈 문자열이고 서명만 붙어 있어서, 블록 바이트를 세면 사고량이 아니라 서명 바이트를 세게 된다. 세 프로젝트 수치는 전부 철회했다. 진짜 측정법은 인접 응답 쌍의 컨텍스트 증가분에서 눈에 보이는 바이트를 빼고 쌍별 중앙값으로 판정하는 것이었고, 다시 재니 컨텍스트 증가분에서 사고가 차지하는 비중은 46.8%, 57.3%, 70.2%로 나왔다. 여기에도 조건이 붙는다. 바이트를 토큰으로 바꾸는 환산 계수를 4.5로 고정했을 때의 값이고, 계수를 3.5로 두면 같은 데이터가 0.670에서 0.902로 흔들린다. 그래서 구성비를 말할 때는 계수를 함께 적는다는 규칙이 붙었다. 이 규칙이 요약에서 빠지면 숫자만 남고, 숫자만 남으면 다음 사람이 그 값을 절대값처럼 쓴다.

셋째, 모형의 출력이 관측으로 읽힌 경우다. 캡 설정별 비용을 비교한 세 줄짜리 표가 문서에 있었는데, 그 값들은 측정한 것이 아니라 산식에 값을 넣어 계산한 결과였다. 표만 보면 실측처럼 읽혔다. 그래서 표를 지우고 산식만 남기면서 "이 산식을 쓰려면 바닥·압축비용·턴당 증가분을 자기 프로젝트에서 재야 한다"는 문장을 붙였다. 요약할 때 계산값과 측정값을 같은 표에 넣으면, 요약이 한 번 더 일어나는 순간 둘의 구분이 사라진다.

같은 이유로 폐기한 값은 지우지 않고 폐기 표시와 이유를 함께 남긴다. 폐기된 임계값이 다시 살아나는 것을 막는 방법은 그 값을 문서에서 없애는 것이 아니라 "이 값은 왜 틀렸는지"를 옆에 적어 두는 것이다. 값만 지우면 다음에 같은 계산을 해서 같은 값을 다시 만든다. 실측에서 수치를 셀 때 요청 단위 중복 제거를 하지 않으면 사용량이 1.9배로 부풀어 보인다는 사실도 같은 자리에 적어 두었다.

유실을 잡아내는 절차는 어떻게 되는가?

절차는 여섯 단계이고, 전제 조건은 원문 스냅샷을 남기는 것이다.

1. 압축·정리 전에 원문을 백업 파일로 남긴다. 날짜를 파일명에 넣는다. 원문이 없으면 무엇이 사라졌는지 셀 수 없다.
2. 금지·경고 문장을 뽑는다. 이 목록이 검사 대상이다.

# 요약본에서 금지·경고 성격의 줄을 전부 뽑는다
grep -n "금지\|하지 마라\|안 된다\|주의" CLAUDE.md

3. 원문과 요약본에서 같은 패턴의 줄 수를 비교한다. 금지 줄 수는 그대로인데 권고 줄 수만 줄었다면 그 자리가 의심 구간이다.

grep -c "금지\|하지 마라\|안 된다" CLAUDE.md CLAUDE.md.bak_20260808
grep -c "한다\|권장\|먼저\|우선" CLAUDE.md CLAUDE.md.bak_20260808

4. 2번 목록을 한 줄씩 열어 대응 절차가 함께 있는지 본다. "금지"만 있고 "발견 시 무엇을 하는가"가 없으면 유실이다.
5. 복원하거나, 복원이 어려우면 표시를 남긴다. 최소한 "이 문장은 원래 다른 문장과 짝이었다"는 한 줄이라도 남긴다.
6. 본문을 고쳤으면 분리된 상세 문서도 같은 턴에 고친다. 뒤로 미루면 다음 세션이 낡은 상세를 권위로 삼는다.

편집 직후에 돌릴 체크리스트는 다음과 같다. 그대로 복사해 쓰면 된다.

[ ] 이번 편집에서 지운 문장 중 다른 문장과 짝이었던 것이 있는가
[ ] "금지"라고 적은 자리마다 대응 절차가 함께 있는가
[ ] 길게 쓰인 권고·예방 문장이 짧은 경고로 대체되지 않았는가
[ ] 남긴 수치마다 측정일·측정 방법·환산 계수가 붙어 있는가
[ ] 계산으로 얻은 값과 측정한 값이 같은 표에 섞여 있지 않은가
[ ] 폐기한 값은 지우지 않고 폐기 표시와 이유를 남겼는가
[ ] 본문을 고쳤다면 분리된 상세 문서도 이번 턴에 고쳤는가

압축이 애초에 손대지 못하는 자리는 어디인가?

자동 압축은 문서의 종류를 가려서 버린다. 우리 환경에서 압축이 버리는 것은 문서 상단의 적용 범위 지정(frontmatter) 규칙, 하위 디렉터리에 둔 지침 파일, 그리고 스킬 본문이었다. 반대로 프로젝트 루트의 지침 파일과 메모리 파일은 디스크에서 다시 주입된다. 그래서 살아남아야 할 규칙은 루트 지침 파일에 둔다는 배치 규칙이 따로 생겼다. 규칙의 내용을 잘 쓰는 것과 규칙을 어디에 두는가는 별개의 문제다.

압축이 반복될 때 생기는 두 번째 손실은 세대 열화다. 요약의 요약이 되면서 수치와 이유가 마모된다. 대책은 요약을 잘하는 것이 아니라 다시 요약하지 않는 것이다. 직전 요약에서 이어받은 항목, 곧 결정·수치·경로·실패 사유는 다시 요약하지 말고 원문 그대로 옮기고, 새로 생긴 내용만 요약한다. 그리고 근본 대책은 하나다. 압축이 두려운 사실이 있다면 그것이 파일에 없다는 신호다. 결정과 수치가 대화에만 있으면 압축이 곧 손실이지만, 문서에 적혀 있으면 압축이 반복돼도 원문을 다시 대조할 수 있다. 우리 환경에서는 압축을 네 번 거치는 것보다 대화를 비우고 인계문 한 장을 쓰는 편이 정보 보존과 비용 양쪽에서 나았다.

이 절차의 한계와 통하지 않는 조건은 무엇인가?

원문 스냅샷이 없으면 이 절차는 작동하지 않는다. 1번 단계가 전제이기 때문이다. 이미 여러 세대의 요약을 거친 문서에서는 무엇이 짝이었는지 복원할 방법이 없고, 남은 문장이 원래 그렇게 쓰인 것인지 잘려서 그렇게 보이는 것인지도 구분되지 않는다. 그런 경우 우리가 한 것은 복원이 아니라 재작성이었다.

3번의 줄 수 비교도 문자열 검사라서 표현이 바뀐 유실은 놓친다. 이 검사가 잡는 것은 "패턴이 통째로 사라진 자리"이고, 문장이 남되 조건절 하나가 빠진 유실은 사람이 읽어야 잡힌다. 21건이라는 수도 지침 문서 한 벌을 전수 대조해 나온 값이라, 문서 종류가 다르면 비율도 다르게 나온다. 이 글이 제안하는 것은 그 비율이 아니라 확인 순서다.

이 대조 자체도 자기가 쓴 요약을 자기가 다시 읽는 방식으로는 잡히지 않았다. 신선한 컨텍스트로 원문과 압축본을 나란히 놓고 대조하는 절차를 거쳤기 때문에 21건이 나왔다. 같은 방식으로 콘텐츠를 감사한 결과는 AI 두 기에게 발행글 12편을 감사시킨 결과에 정리했고, 결정과 수치를 파일에 남기지 않았을 때 무엇을 잃는지는 압축이 두려운 사실이 있다면 그것이 파일에 없다는 신호다에서 이어서 다룬다.

자주 묻는 질문

Q. "쌍으로 쓴 규칙"이란 무엇인가?
A. 하나의 지침이 권고와 경고, 또는 예방과 대응처럼 두 문장이 짝을 이뤄 완결되는 형태로 쓰인 규칙을 말한다. 한쪽만 남으면 문장은 사실이어도 규칙의 방향이 바뀐다.

Q. 왜 항상 짧은 쪽(금지·경고)만 남는가?
A. 압축은 분량을 줄이는 작업이고, 같은 정보량이면 짧은 문장이 요약 과정에서 우선적으로 살아남기 때문이다. 유실 21건 중 6건이 이 패턴이었고 여섯 건 모두 사라진 쪽이 긴 쪽이었다.

Q. 유실을 어떻게 21건까지 셀 수 있었나?
A. 압축 전 원문 스냅샷과 압축 후 지침을 신선한 컨텍스트로 나란히 대조해, 의미가 달라지거나 빠진 항목을 전수 확인했다. 원문 백업이 없으면 이 계수 자체가 불가능하다.

Q. 압축 자체를 하지 않는 것이 답인가?
A. 아니다. 압축은 불가피하다. 대신 요약할 때 긴 쪽이 남았는지 확인하는 절차를 넣고, 살아남아야 할 규칙은 디스크에서 다시 주입되는 자리(프로젝트 루트 지침 파일)에 두며, 근본적으로는 결정과 수치의 권위를 대화가 아니라 문서에 둔다.

Q. 이 문제는 AI 지침에만 해당하는가?
A. 우리가 겪은 것은 AI 지침 문서 압축이지만, 쌍으로 쓴 규칙을 요약하다 한쪽만 남기는 문제는 문서 요약 작업 일반에 적용될 수 있는 패턴이라고 본다. 확인 순서는 그대로 쓸 수 있고, 21건이라는 비율은 문서마다 다르다.