본문으로 건너뛰기

© 2026 Molayo

Dev.to헤드라인2026. 06. 25. 02:18

GPT-4o와 저렴한 모델로 받은 편지함 분류 테스트를 진행했습니다. GPT-4o가 패배했습니다.

요약

이메일 분류 작업에서 Gemini 2.5 Flash가 GPT-4o와 같은 고비용 모델보다 더 높은 정확도와 재현율을 기록했습니다. 복잡한 추론이 필요 없는 반복적 작업에서는 모델의 지능보다 일관성이 중요함을 보여주는 사례입니다.

핵심 포인트

  • 이메일 분류 작업에서 저렴한 Flash 모델이 GPT-4o를 능가함
  • 단순 분류 작업에는 높은 추론 능력보다 일관성이 더 중요함
  • LLM을 결정권자가 아닌 특징 점수 산출자(feature-scorer)로 활용
  • 과도한 모델 지능은 오히려 불필요한 변동성을 초래할 수 있음

여기에 점수판을 공유합니다. 동일하게 50개의 이메일, 동일한 프롬프트, 그리고 동일한 4단계 작업이 적용되었습니다:

ModelAccuracyNote
google/gemini-2.5-flash88%긴급 메일은 100% 회수(recall) — 놓친 것이 없었습니다
...

저렴한 모델이 비싼 모델들과 대등하게 겨루지 못했습니다. 이 모델은 그들을 6점 차이로 앞질렀으며, 저를 깨워야 할 이메일은 단 하나도 놓치지 않았습니다. 본능적으로 선택했을 두 가지 모델 — 명백히 더 똑똑하고 토큰당 비용이 몇 배나 비쌌던 모델들 — 모두 2위를 차지했습니다.

사실 저는 이 비교 테스트 자체를 거의 진행하지 않을 뻔했습니다. 그 부분이 여러분의 시간을 들일 가치가 있는 부분입니다.

작업 내용

저는 이메일 방화벽을 구축하고 있습니다. 수신되는 모든 메시지는 정확히 네 가지 등급 중 하나를 받습니다:

  • SILENT — 기록만 되고 표시되지 않음 (마케팅, 영수증, 참고용(FYI))
  • QUEUE — 제가 확인하기로 선택할 때만 보이며 알림이 오지 않음
  • PUSH — 실제로 저에게 방해를 줌(알림)
  • AUTO — 되돌릴 수 있고, 신경 쓸 필요가 없음 (현재는 분류용으로만 사용)

이것이 전체 출력 범위입니다. 제안 카드도 없고,

제가 실제로 고민하던 모델들을 대상으로 테스트를 진행했습니다. Flash가 승리했습니다. 단순히 "비용 면에서 이기고 품질은 비겼다"는 뜻이 아닙니다. 품질 면에서 이겼고, 마침 그 모델이 저렴한 것이었습니다. 저는 운영 환경(production)을 해당 모델로 고정했고, 미래의 제가 예산 때문에 비싼 모델을 희생했다고 몰래 변명하지 못하도록 커밋 메시지에 결과를 기록해 두었습니다:

flash는 타협안이 아닙니다. PUSH recall(재현율) 점수에서 88%/100%를 기록하며 gemini-2.5-pro와 gpt-4o(둘 다 82%)를 앞질렀습니다.

왜 "여기서" 저렴한 모델이 승리하는가

프런티어 모델(frontier model)은 추론의 깊이(reasoning depth)를 판매합니다. 긴 연쇄 추론(long chains), 어려운 문제, 혹은 여러 가지를 동시에 머릿속에 담아두어야 하는 문제들을 해결하죠. 하지만 이메일 분류(email triage)는 그런 것들이 전혀 아닙니다. 짧고, 반복적이며, 네 가지 신호(signals)를 읽고 일관성을 유지하면 되는 문제입니다. 이 작업의 지표를 움직이는 능력을 위해 비용을 지불하는 것이 아닙니다. 사용하지도 않을 능력을 위해 비용을 지불하는 셈이며, 더 큰 모델의 추가적인 "사고(thinking)"는 대부분 30단어짜리 이메일을 과하게 생각(overthink)할 확률만 높일 뿐입니다.

아키텍처 측면의 이유도 있으며, 이것이 핵심적인 이유입니다. LLM은 결코 등급(tier)을 결정하지 않습니다. 모델은 이메일당 네 가지 특징(feature) — 신뢰도(confidence), 발신자 신뢰도(sender trust), 되돌릴 수 있음(reversibility), 긴급도(urgency) — 을 점수화하며, 약 20줄의 결정론적 규칙(deterministic rule)이 이 네 가지 숫자를 PUSH/QUEUE/SILENT/AUTO로 매핑합니다. 모델은 결정권자가 아니라 특징 점수 산출자(feature-scorer)입니다. 따라서 저는 이메일 정책에 대해 훌륭하게 추론하는 모델이 필요한 것이 아닙니다. 매번 네 가지 신호를 동일한 방식으로 읽어내는 모델이 필요합니다. 천재성이 아니라 일관성(consistency)이 필요합니다. 이것이 바로 저렴하고 빠른 모델이 잘하는 일이며, 더 큰 모델의 영리함이 원치 않는 변동성(variance)으로 변질되는 지점이기도 합니다.

또한 이는 모델이 개입하지 않고도 정책을 감사(auditable)할 수 있음을 의미합니다. 저는 규칙을 읽을 수 있고, 테스트할 수도 있습니다. 만약 모델이 다운되더라도, 키워드 폴백(keyword fallback)이 동일한 네 가지 특징을 생성하므로 긴급한 메일은 여전히 전달될 수 있습니다. LLM이 답을 자유롭게 작성(free-hand)하도록 내버려 둔다면 이 중 어느 것도 작동하지 않을 것입니다.

반박하기 전에 (@ me)

이것은 50개의 이메일입니다. 의도적으로 작게 구성했습니다. 이것은 벤치마크 (benchmark)가 아니라 한 개인의 멘탈 모델 (mental model)을 기록한 것이며, 이를 벤치마크인 것처럼 꾸미지 않을 것입니다. 이 데이터셋은 합성 (synthetic) 데이터이므로, 모델이 실제 세상을 읽을 수 있는지 여부가 아니라 _나의 정책 (my policy)_을 일관되게 적용하는지를 테스트합니다. 소유자가 다른 다른 편지함이라면 분류 기준이 달라질 것이고, 모델의 순위 또한 다르게 매겨질 수 있습니다.

또한 저는 제가 측정한 것만을 주장합니다. Flash 모델은 PUSH 항목에서 100%의 재현율 (recall)을 기록했습니다. 즉, 긴급한 이메일을 조용한 단계 (quiet tier)로 보낸 적이 단 한 번도 없습니다. 저는 패배한 모델들에 대해 단계별 수치를 임의로 만들어내지 않을 것입니다. 저는 그들의 헤드라인 정확도 (headline accuracy)만을 가지고 있으며, 그것이 제가 이름을 걸고 내놓는 결과입니다.

제가 번복하지 않을 부분은 다음과 같습니다: 제가 실제로 중요하게 생각하는 단 하나의 작업에서, 여러분이 열어볼 수 있도록 공개 리포지토리 (public repo)에 올려둔 데이터셋을 기준으로 했을 때, 비싼 모델들이 패배했습니다. 그 결과는 실제 서비스 (production)에 배팅할 수 있을 만큼 충분히 안정적이었습니다.

교훈은 짜증 날 정도로 저렴합니다

우리 대부분은 이런 비교를 결코 수행하지 않습니다. "가장 좋은 모델을 사용하라"가 기본값이고, 가장 좋은 모델은 비싼 모델이며, 리더보드 (leaderboard)도 이에 동의하므로, 왜 뻔한 사실을 증명하는 데 오후 시간을 낭비하겠습니까?

그 이유는 리더보드가 당신의 작업을 본 적이 없기 때문입니다. MMLU는 당신이 말하는 "긴급함"이 무엇을 의미하는지 모릅니다. 당신의 문제에 대해 모델의 순위를 매기는 유일한 평가 (eval)는 당신이 직접 작성한 것입니다. 그리고 당신이 평가를 작성할 때, 순위가 가격표와 일치하지 않는 경우가 놀라울 정도로 자주 발생합니다. 프런티어 모델 (frontier model)이 당신의 업무에 더 똑똑한 것은 아닙니다. 그것은 단지 보도 자료에 나오는 업무들에 더 똑똑할 뿐입니다.

작은 규모의 평가 (eval)를 작성하세요. 비싼 모델을 찾기 전에 저렴한 모델로 먼저 테스트해 보세요. 최악의 경우 뻔한 사실을 확인하게 될 뿐입니다. 최선의 경우 비용을 절감하면서도 정확도는 _상승_하게 됩니다. 저 역시 예상치 못한 문장이군요.

판단자(judge), 평가 세트(eval set), 그리고 결정론적 규칙(deterministic rule)은 모두 공개되어 있습니다 — AGPLv3 라이선스이며, OpenAI 호환 방식입니다. Ollama나 vLLM을 연결하여 여러분의 메일을 직접 관리하세요: github.com/k08200/klorn. 평가 세트는 packages/api/eval/judge-eval-set.json에 있습니다. 파일을 열어 여러분만의 방식으로 라벨링(labeling)하고, 어떤 모델이 여러분의 편지함에서 실제로 승리하는지 확인해 보세요.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0