측정하지 않으면 압축이 아니다 — 출력 압축 도구의 효과를 재는 법 (Scrooge 1편)

AI 엔지니어링

측정하지 않으면 압축이 아니다 — 출력 압축 도구의 효과를 재는 법 (Scrooge 1편)

Kir93 2026. 6. 12. 15:53

728x90

1. 도입부 — "더 압축하자"가 위험한 이유

압축 도구를 며칠 굴리다 보면 자연스러운 다음 생각이 떠오른다. *"영문 출력을 좀 더 깎을 수 있지 않을까?"* 규칙을 한두 줄 더 공격적으로 쓰면 토큰이 더 줄 것 같다.

이 충동은 합리적으로 보이지만, 실은 방향을 모르는 최적화다. 더 깎았을 때 토큰이 정말 줄어드는지, 줄어든다면 얼마나 줄어드는지, 그 대가로 무엇이 깨지는지 — 이걸 모르는 채로 규칙만 더 공격적으로 쓰는 건 도박이다. 압축 도구에서 "규칙을 더 공격적으로"는 곧 출력의 명료성(auto-clarity)과 안전 register를 깎는 쪽으로 압력을 주는 일이기 때문이다. 이득은 불확실한데 위험은 확실하다.

그래서 scrooge 개발 중 "더 압축하자"는 plan을 의도적으로 보류했다. 먼저 한 일은 압축이 아니라 측정이었다. 이 글에서 당신이 얻어갈 것은, 프롬프트·출력처럼 "정확한 수치를 매기기 애매한" 대상의 효과를 어떻게 재현 가능한 벤치마크로 환원하는가에 대한 구체적 방법이다.

2. 핵심 개념 — 프롬프트형 도구는 왜 측정이 어려운가

일반 코드 최적화와 다른 점

함수 하나를 최적화했다면 측정은 명확하다. 같은 입력에 실행 시간을 재서 before/after를 비교하면 된다. 결정론적이고, 단위가 분명하다.

LLM 출력 압축은 그렇지 않다. 두 가지가 측정을 흐린다.

비결정성: 같은 프롬프트라도 출력이 매번 다르다. 한 번 재서 "30% 줄었다"라고 말하면 그건 그날 그 샘플의 우연일 수 있다.
단위의 모호함: "압축됐다"를 무엇으로 잴 것인가? 글자 수? 토큰 수? 토큰이 곧 비용이므로 토큰 수가 정답이지만, 그러려면 baseline이 명확히 정의돼 있어야 한다.

핵심 통찰: baseline 없는 % 는 의미가 없다

"50% 절감"이라는 말이 성립하려면 무엇 대비 50%인지가 고정돼야 한다. scrooge가 택한 baseline은 압축을 전혀 걸지 않은 normal(일반) 출력이다. 그리고 그 사이에 약하게 압축한 terse를 두고, 본 제품인 scrooge× {언어} × {강도} 출력들을 같은 입력에 대해 나란히 생성한다.

용어 1줄 정의 — 코퍼스(corpus): 여기서는 "같은 입력 프롬프트 묶음 + 그걸 각 모드로 돌린 출력 묶음"을 뜻한다. 측정의 기준 표본 집합이다.

이렇게 하면 "scrooge ko full이 normal 대비 얼마나 줄었나"가 같은 입력 위에서 계산되는, 비교 가능한 수치가 된다.

3. 동작 원리 — 코퍼스로 ground truth 만들기

측정의 뼈대는 단순하다. 하나의 입력을 여러 출력 모드로 돌리고, 토큰 수를 집계해 baseline과 비교한다.

세 가지 설계 포인트가 이 측정을 "그럴듯한 숫자"가 아니라 "재현 가능한 ground truth"로 만든다.

① 입력에 verbose-prone edge를 일부러 넣는다.
압축 도구의 진짜 실력은 "원래 짧은 답"이 아니라 "가만 두면 장황해지는 답"에서 드러난다. 그래서 코퍼스 입력에 장황해지기 쉬운 엣지 프롬프트를 의도적으로 포함한다. 평균적인 입력만 재면 도구가 가장 일하는 구간을 놓친다.

② baseline·terse·scrooge를 한 표본 위에 나란히 둔다.
normal / terse / scrooge× {ko, en} × {lite, full} 조합을 같은 입력으로 생성한다. normal은 절감의 기준점(0%), terse는 "단순 간결 지시"만으로 얼마나 줄어드는지의 대조군, scrooge 계열은 본 제품의 실측치다. terse라는 중간 대조군이 중요한 이유는, "규칙 묶음 없이 그냥 짧게 써"만 해도 얻는 절감과 scrooge 규칙이 추가로 사주는 절감을 분리해 보여주기 때문이다. 이게 없으면 scrooge의 공을 과대평가하게 된다.

③ 측정 결과는 커밋하지 않는다(gitignore).
코퍼스 입력과 리포트 도구는 저장소에 두되, 산출된 절감 수치 자체는 gitignore 했다. 이유는 정직성이다. 절감률은 모델·시점·샘플링에 따라 달라지는 값이라, 한 번 잰 숫자를 저장소에 박아두면 "고정된 사실"처럼 오해된다. 대신 도구를 저장소에 두고 재현은 "다시 측정"으로 하게 만든다. README가 절감 %를 단정하지 않고 "추정(estimated)"으로 표기하는 태도와 같은 결의 결정이다.

4. 실무 적용 — 측정 파이프라인 만들기

이 시리즈에서 "코드 예제" 자리는 설정·구조·측정 코퍼스가 채운다. 1화의 예시는 절감률 측정 파이프라인의 골격이다.

✅ Good Practice — baseline을 고정하고 재현 가능하게 측정

# 1) 코퍼스: 입력 + 모드 매트릭스 (장황해지기 쉬운 입력 포함)
inputs = load("benchmark/inputs/")        # verbose-prone edge 포함
modes  = ["normal", "terse",
          "scrooge:ko:lite", "scrooge:ko:full",
          "scrooge:en:lite", "scrooge:en:full"]

# 2) 같은 입력을 모든 모드로 생성하고 토큰 수 집계
for inp in inputs:
    for m in modes:
        out = generate(inp, mode=m)
        record(inp.id, m, count_tokens(out))   # 글자수 아님 — 토큰수

# 3) baseline(normal) 대비 절감률 산출
#    절감률 = (normal_tokens - mode_tokens) / normal_tokens
report = reduction_vs_baseline(baseline="normal")

# 4) 산출된 수치는 gitignore — 도구만 저장소에, 재현은 "다시 측정"으로

핵심은 (a) baseline이 코드에 명시돼 있고, (b) 토큰 수로 재며, (c) 같은 입력 위에서 모드를 비교하고, (d) 결과를 박제하지 않는다는 네 가지다.

❌ Anti-Pattern — 인상으로 절감률을 말하기

# 흔한 실수
# - 출력 두어 개 눈으로 보고 "한 절반 줄었네" → 표본 1~2개, 비결정성 무시
# - 글자 수로 비교 → 비용 단위(토큰)와 어긋남
# - baseline 없이 "scrooge는 60% 절감" → 무엇 대비 60%인지 불명
# - 측정해보지도 않고 규칙부터 더 공격적으로 → auto-clarity·안전 register만 깎임

왜 문제인가. 이렇게 나온 "60%"는 반증 불가능한 마케팅 문구다. 누가 "정말?"이라고 물으면 재현할 방법이 없다. 그리고 측정 없이 규칙부터 공격적으로 바꾸면, 줄어든 토큰의 이득보다 깨진 명료성·안전성의 손해가 클 수 있는데 그걸 알 길조차 없다.

🔍 실행 결과 — 측정이 사주는 것

측정 파이프라인을 갖추면 두 가지가 생긴다. 첫째, "scrooge ko full은 normal 대비 약 N% 절감(추정, 이 코퍼스·이 모델 기준)"처럼 조건이 붙은 정직한 수치를 말할 수 있다. 둘째 — 그리고 이게 더 중요한데 — "여기를 더 압축하면 토큰은 X만큼 더 줄지만 명료성 체크가 깨진다"는 트레이드오프가 눈에 보인다. 측정은 자랑할 숫자를 주는 게 아니라, 어디를 건드리면 안 되는지를 알려주는 지도를 준다.

5. 장단점 및 고려사항

장점	단점·비용
✓ 절감 주장이 재현 가능한 근거를 갖는다	✗ 코퍼스·리포트 도구를 먼저 만드는 선투자가 필요
✓ "더 압축" 결정의 트레이드오프가 가시화된다	✗ 비결정성 탓에 표본을 충분히 모아야 신뢰구간이 좁아짐
✓ terse 대조군이 도구의 순효과를 분리해준다	✗ 모델·시점이 바뀌면 수치도 바뀌어 재측정이 필요

실무 팁 — 측정 도입 체크리스트

baseline을 코드에 명시한다. "무엇 대비"가 함수 시그니처에 드러나야 한다.
글자 수가 아니라 토큰 수로 잰다. 비용 단위와 측정 단위를 일치시킨다.
장황해지기 쉬운 입력을 코퍼스에 일부러 넣는다. 평균 입력만으로는 도구의 일하는 구간을 못 본다.
순효과 대조군(terse)을 둔다. "그냥 짧게 써"와 도구의 차이를 분리한다.
수치를 박제하지 않는다. 도구를 커밋하고 결과는 gitignore. 발표할 땐 "추정 + 측정 조건"을 함께 적는다.

핵심 3줄 요약

프롬프트·출력 도구의 효과는 비결정성과 단위 모호함 때문에 측정이 어렵지만, 같은 입력 + 고정 baseline + 토큰 수 집계로 재현 가능하게 만들 수 있다.
terse 같은 중간 대조군이 도구의 순효과를 분리하고, 산출 수치는 gitignore + "추정" 표기로 정직하게 다룬다.
측정의 진짜 가치는 자랑할 숫자가 아니라, "더 압축해도 되는 곳과 건드리면 안 되는 곳"의 지도다.

저작자표시 (새창열림)