프롬프트를 줄여 55% 빨라졌는데, 정작 중요한 게 사라졌다

−55%를 만든 압축이 정작 도메인의 핵심을 버리고 있었다. 안 재던 지표가 무너진 이야기

하려던 것

닷새 전에 gemma-4-26B-A4B용 요약 프롬프트를 277자에서 108자로 줄여 프로덕션에 넣었다. 처리 시간 −55%, JSON 파싱 100%, Opus 라벨 일치 73%. 지표가 다 좋았다.

오늘은 그냥 결과물을 눈으로 훑어보려던 참이었다.

어디서 막혔나

훑다가 이상한 걸 발견했다.

“공시 분석 모델을 바꿨잖아. 그런데 이게 너무 요약을 해 버려서 내용이 거의 다 비슷하게 분석돼. 주식 수량이나 임원 이름 같은 건 언급도 안 하고 더 큼지막하게 요약해 버려. 그래서 공시 이름이랑 내용이 별로 차이가 없어.”

공시 제목만 봐도 알 수 있는 내용이 요약에 그대로 적혀 있었다. 요약을 붙이는 의미가 없어진 거다.

어떻게 풀었나

원인은 내가 넣은 그 프롬프트였다. 압축본에 이런 제약이 들어 있다.

"summary": "<1문장 50자 이내>"

50자에 공시 하나를 밀어 넣으라고 하면 모델이 뭘 먼저 버릴까. 고유명사와 수치다. “누가”와 “얼마”를 빼면 문장이 확 짧아지고 “무엇을 했다”라는 뼈대만 남는다. 그리고 그 뼈대는 공시 제목과 거의 같다.

압축률을 올리면 제일 먼저 사라지는 게 고유명사인데, 공시 분석에서 제일 중요한 게 고유명사와 수치다. 속도를 위해 줄인 제약이 정확히 그 도메인의 핵심을 겨냥하고 있었다.

더 나쁜 건 이게 모든 공시에 골고루 나쁜 게 아니라는 점이다. 짧고 단순한 공시는 50자로도 충분히 담긴다. 문제는 임원 변동이나 지분 취득처럼 이름과 숫자가 본질인 공시다. 그런 건 요약이 전부 “임원이 변경되었다” 같은 문장으로 수렴한다. 정작 요약이 제일 필요한 종류가 제일 망가진 셈이다.

관련 지표가 하나 더 있었다. 같은 검증에서 **부정 감성 recall이 53%**였다. 절반은 놓친다. 이 숫자는 그때도 표에 있었는데 그냥 넘어갔다. 부정적인 공시일수록 “누가 얼마를”이 중요한데 그걸 버리는 프롬프트를 쓰고 있었으니, 지금 보면 연결되는 얘기다.

파는 과정에서 에이전트가 엉뚱한 걸 확인해 오기도 했다. 요약이 50자로 제한돼 있다길래 잘못 본 것 같다고, 다른 서비스 프롬프트랑 헷갈린 것 아니냐고 되물었다. 결과적으로 50자가 맞았다. 의심은 맞았지만 지적한 지점은 틀렸다. 그런데 그 의심 덕에 양쪽 프롬프트를 다시 열어 보게 됐고 거기서 진짜 원인이 나왔다.

정리하면

108자 프롬프트
처리 시간12.84s → 5.73s
JSON 파싱100%
Opus 라벨 일치73.0%
고유명사·수치 보존나빠짐
부정 감성 recall53%

내가 잰 세 지표는 다 좋아졌다. 그리고 제대로 안 본 두 개가 나빠졌다.

무서운 건 안 재는 지표는 나빠져도 표에 안 나온다는 거다. 나는 −55%를 보고 성공이라 판단했고 닷새 동안 그렇게 믿었다. 발견한 건 지표가 아니라 눈으로 훑다가였다.

Opus 라벨 일치 73%도 다시 보면 다르게 읽힌다. 안 맞는 27%가 랜덤하게 흩어진 게 아니라 수치와 이름이 중요한 공시에 몰려 있었을 가능성이 크다. 총점만 보면 안 보이는 종류의 실패다.

바꿔 말하면 나는 평균으로 성공을 판정하고 분포로 실패하고 있었다. 200건을 재면서 정작 어떤 200건인지, 틀린 54건이 어떤 유형인지는 안 봤다. 표를 만든 사람이 표를 안 읽은 셈이다.

배운 점