안 깎는 것이 실력이다 — 압축 도구가 거부해야 할 출력 (Scrooge 2편)

1. 도입부 — 압축 도구의 진짜 위험은 "덜 압축"이 아니다

압축 도구를 만들 때 본능적으로 좇는 목표는 "최대한 깎기"다. 그런데 출력 압축에는 일반적인 성능 최적화에 없는 위험이 하나 있다. 너무 잘 깎으면 사람이 다친다.

예를 들어 LLM이 이런 출력을 내야 하는 상황을 생각해 보자. "이 명령은 데이터베이스를 복구 불가능하게 삭제합니다. 실행 전 백업을 확인하세요." 압축 규칙이 이걸 "DB 삭제 주의"로 깎았다고 하자. 토큰은 줄었다. 하지만 복구 불가능이라는 사실과 백업 확인이라는 행동 지시가 사라졌다. 사용자가 이 경고를 가볍게 보고 명령을 실행하면, 줄인 토큰 몇 개가 데이터 전체와 맞바꿔진다.

그래서 잘 만든 압축 도구의 핵심 설계는 "어떻게 더 깎을까"가 아니라 "무엇을 절대 깎지 않을까"다. 이 글에서 당신이 얻어갈 것은, 출력 도구에 "거부 영역"을 계약처럼 박는 방법과 그 경계를 어디에 긋는지에 대한 구체적 기준이다.

---

2. 핵심 개념 — register, 그리고 "압축하지 않는다"는 약속

용어 1줄 정의 — register: 언어학에서 상황에 맞는 말투·격식 수준을 뜻한다. 여기서는 "출력이 띠어야 할 표현 양식" 정도로 읽으면 된다. 압축된 register, 격식 있는 register, 안전을 위한 normal prose register 등.

scrooge에는 safety register라는 컨벤션이 있다(CLAUDE.md에 명문화). 골자는 한 줄이다.

특정 종류의 출력은, 압축 강도(dial)가 아무리 공격적이어도 normal prose로 유지한다.

즉 압축 도구이면서도 "여기는 압축 안 함"을 규칙으로 선언해 둔 것이다. 이건 도구의 약점이 아니라, 도구가 신뢰받을 수 있는 근거다.

"안전성 계약"이라는 프레임

여기서 이 글의 핵심 프레임이 나온다. 무엇을 압축하지 않을지를 정하는 일은 단순한 예외 처리가 아니라 계약(contract)이다. 사용자는 scrooge를 켤 때 암묵적으로 이렇게 믿는다. *"토큰은 아껴주되, 내가 다칠 수 있는 정보는 온전히 보여주겠지."* 안전 register는 그 믿음을 코드와 규칙으로 보증하는 명문 조항이다. 계약이 깨지면 — 즉 압축이 안전 정보를 깎으면 — 도구는 "토큰 아끼는 도구"가 아니라 "위험한 도구"가 된다.

---

3. 동작 원리 — 경계를 어디에 긋는가

핵심은 압축 대상과 안전 register를 명확히 분리하는 것이다. dial이 올라가면 전자는 점점 더 깎이지만, 후자는 어느 강도에서도 normal prose를 유지한다.

압축 강도가 올라가도 안전 register

안전 register에 들어가는 것 (압축 제외)

세 부류가 명시적으로 "안 깎는" 영역이다.

• 보안 경고: credential 노출 위험, 위험한 명령, 권한 상승 같은 경고. 압축돼 흐려지면 사용자가 위험을 과소평가한다.
• 되돌릴 수 없는 동작: 삭제·덮어쓰기·배포처럼 한 번 하면 못 무르는 행위에 대한 안내. 복구 불가능성과 선행 확인 절차가 압축으로 증발하면 안 된다.
• 모호하면 위험한 다단계 절차: 순서가 틀리면 사고가 나는 절차. 압축이 단계를 뭉치거나 생략하면 명료성(auto-clarity)이 깨진다.

관통하는 기준은 하나다. "압축이 명료성을 깎았을 때, 사람이 잘못 행동할 수 있는 출력인가?" 그렇다면 안전 register다. 여기서 auto-clarity가 압축률보다 항상 우선한다는 우선순위가 register 레벨에 박힌다.

한자 가드 — "압축 규칙"이 아니라 "정합성 가드"

scrooge에는 한국어 출력에서 한자(漢字)가 새어 나오는 것을 막는 규칙이 있다. 흥미로운 분류 결정은 이걸 압축 규칙이 아니라 정합성(correctness) 가드로 처리한 점이다.

왜 이 구분이 중요한가. 한자 leakage 가드를 "압축 규칙"으로 분류하면, 압축 강도를 낮추면 가드도 느슨해질 수 있다는 잘못된 함의가 생긴다. 하지만 한글 출력에 한자가 섞이는 건 압축 강도와 무관하게 틀린 출력이다. 그래서 이건 압축 다이얼에 종속되는 규칙이 아니라, 모든 dial에서 똑같이 지켜야 할 정합성 조건으로 박았다.

그리고 여기서 의도적이고 명시적인 비대칭이 하나 있다. 한자 가드는 ko의 every dial(lite·full 모두)에 적용하되, en에는 의도적으로 넣지 않았다(이 결정을 정리한 세션에서 en은 N/A로 명시). 한자 leakage는 CJK(한·중·일) 토크나이저를 공유하는 환경에서 한국어 같은 언어에 나타나는 CJK 한정 실패 모드라, 영어 출력에는 해당하지 않기 때문이다. 중요한 건 이 예외를 "그냥 안 넣음"으로 흘리지 않고 — bilingual parity(두 언어 동등 대우)의 예외임을 명시적으로 플래그 했다는 점이다. parity는 기본 원칙이되, 깨야 할 땐 왜 깨는지를 기록으로 남긴다.

---

4. 실무 적용 — 거부 영역을 규칙으로 박기

이 시리즈에서 "코드 예제" 자리는 register 정책과 가드 규칙이 채운다.

✅ Good Practice — 안전 register를 dial과 분리해 선언

# rules/ko/full.md (발췌, 개념적 표현)

## 압축 정책 (dial: full — 공격적)
- 인사·맥락 복창·완곡어법 제거
- 부연은 핵심만, 산문은 압축 표현으로

## 안전 register (압축 제외 — 모든 dial 공통)
다음은 압축 강도와 무관하게 normal prose로 유지한다:
- 보안 경고(credential·위험 명령·권한)
- 되돌릴 수 없는 동작(삭제/덮어쓰기/배포)의 위험성과 선행 확인
- 순서가 틀리면 위험한 다단계 절차

## 정합성 가드 (압축 규칙 아님 — 모든 dial 공통)
- 한국어 출력은 한글 전용. 한자(漢字) leakage 금지.
#   ※ 이 가드는 ko 전용. en은 CJK 한정 실패라 N/A (parity 예외, 의도적).

핵심은 "안전 register"와 "정합성 가드"가 압축 정책과 다른 섹션에, 모든 dial 공통으로 적혀 있다는 점이다. dial을 바꿔도 이 두 섹션은 그대로다 — 그게 계약이라는 증거다.

❌ Anti-Pattern — 안전 정보를 압축 대상에 섞기

# 잘못된 규칙
## 압축 정책 (dial: full)
- 모든 출력을 최대한 짧게. 경고·주의도 한 줄로 요약.   # ← 위험
- 절차는 단계 합쳐서 압축.                              # ← 모호해지면 사고
- 한자 써도 됨 (토큰 효율 좋음).                         # ← 정합성 위반

왜 문제인가. 안전 정보를 압축 대상에 함께 두면, 압축 강도를 올릴 때마다 안전성이 함께 깎인다. "경고도 한 줄로"는 복구 불가능 같은 결정적 단어를 날리고, "단계 합쳐서"는 순서 의존 절차를 망가뜨린다. "한자 써도 됨"은 토큰은 줄지만 한국어 독자에게 읽기 비용을 떠넘긴다(0화의 접근성 프레임과 정면충돌). 셋 다 토큰 몇 개와 사용자의 안전·이해를 맞바꾸는 거래다.

🔍 실행 결과 — 계약이 있을 때의 동작

안전 register가 박혀 있으면, dial을 full로 올려도 보안 경고는 온전한 문장으로 나온다. 사용자는 "압축 모드인데도 위험 정보는 또렷하다"는 일관성을 경험하고, 그게 도구를 신뢰하는 근거가 된다. 반대로 정합성 가드 덕에 한국어 출력에 한자가 새지 않으므로, ko 사용자는 압축의 이득을 읽기 비용 증가 없이 온전히 가져간다.

---

5. 장단점 및 고려사항

장점	단점·비용
✓ 압축 강도와 무관하게 안전성이 보장됨 (신뢰의 근거)	✗ 절감률 수치는 안전 register만큼 낮아짐 (덜 화려한 숫자)
✓ 정합성/안전과 압축을 분리해 규칙이 명료해짐	✗ "무엇이 안전 register인가"의 경계 판단에 지속적 노력 필요
✓ parity 예외를 기록으로 남겨 결정이 추적 가능	✗ 예외(en N/A 등)가 늘면 규칙 일관성 관리 부담

 

실무 팁 — 거부 영역 설계 체크리스트

• "압축이 명료성을 깎으면 사람이 잘못 행동하나?"를 단일 기준으로 삼는다. 그렇다면 안전 register.
• 안전 register는 압축 정책과 다른 섹션에 둔다. 같은 섹션에 두면 dial을 따라 함께 깎일 위험이 구조적으로 생긴다.
• "틀린 출력"과 "덜 압축된 출력"을 구분한다. 한자 leakage처럼 틀림에 해당하는 건 압축 규칙이 아니라 정합성 가드로 분류해 모든 dial에 건다.
• parity를 깰 땐 이유를 기록한다. "그냥 안 넣음"이 아니라 "CJK 한정 실패라 en은 N/A"처럼 명시적 플래그를 남긴다.

---

핵심 3줄 요약

1. 압축 도구의 진짜 설계 난제는 "어떻게 더 깎을까"가 아니라 "무엇을 절대 안 깎을까"이며, 이건 사용자와의 안전성 계약이다.
2. 보안 경고·되돌릴 수 없는 동작·모호한 다단계 절차는 모든 dial에서 normal prose로 유지하고, auto-clarity를 압축률보다 우선한다.
3. 한자 leakage처럼 틀림에 해당하는 건 압축 규칙이 아니라 정합성 가드로 분류하며, parity를 깰 땐 그 예외를 기록으로 명시한다.