27B 모델을 분류에 쓰던 걸 9B 스코어링 모델로 갈아끼우기

메일을 실시간으로 분류하는 작업에, 27B급 일반 생성 모델을 프롬프트와 JSON 출력 규칙으로 이끌어 흉내 내던 구조를 쓰고 있었습니다. 그런데 이걸 토큰을 한 글자도 뱉지 않고 확률 하나만 내놓는 9B 스코어링 분류 모델로 갈아끼웠더니, 더 빨라지고 더 정확해졌습니다. 분류처럼 고정된 라벨 집합에 하나만 매기면 되는 정해진 일에는, 큰 모델보다 작업에 특화된 작은 모델이 오히려 유리하다는 결론이 나왔습니다. 라이선스와 하드웨어 함정까지 실제로 부딪혀 가며 비교한 이야기를 풀어보겠습니다.

왜 거대한 생성 모델로 분류를 흉내 냈을까

"일반 LLM에 프롬프트와 JSON 출력을 시키면 뭐든 된다"는 패턴은, 로컬 LLM을 만지는 사람이라면 한 번쯤 지나친 길입니다. 물으면 글로 대답하는 모델이니까, 분류도 "1, 2, 3 중에 하나 골라서 이렇게 적어줘"라고 요청하면 되는 것처럼 보입니다. 문제는 이 모델이 분류를 글을 쓰는 방식으로 한다는 데 있습니다.

한 문장을 쓸 때 모델은 토큰을 한 글자씩 뽑아냅니다. 라벨 하나를 정하려고 그렇게 글을 써 내려가면, 답이 나오기까지 시간이 길어지고, 그 사이 출력 규칙에 어긋나면 JSON 파싱부터 어긋나서 오류가 되돌아옵니다. 우편함 몇 개에 편지를 나눠 넣는 일을 두고, 서랍 한 칸에 놓여야 할 옷가지들을 전부 꺼내 설명부터 늘어놓는 격입니다. 정해진 일을 굳이 창작처럼 대하는 셈이지요.

후보 비교 — 27B 어댑터 vs 경량 분류 모델

그래서 분류를 정직하게 "라벨을 고르는 작업"으로 다루는 모델들을 후보로 올려, 정확도·속도·하드웨어·라이선스를 나란히 놓고 비교했습니다. 기존에 돌리던 27B 어댑터와, 신규로 올린 경량 분류 모델들입니다.

후보	정확도(니치)	라이선스 / 크기	비고
기존 27B 어댑터	84.88%	—	프롬프트+JSON 파싱
Nimble 9B	90.12%	Apache 2.0, ~9.5GB(Q8)	num_ctx 8,192
Tev1 4B	미정	라이선스 미정	공개·상용 시 주의
Tev1 0.8B	63.5%	—	실전 불가

표만 봐도 결론이 바로 나옵니다. Nimble 9B가 기존 27B보다 니치 정확도에서 높게 나왔고, Apache 2.0이라 라이선스 걱정도 덜 합니다. 다만 이 90.12%라는 수치는 제조사가 내놓은 값이지 제가 랩 라벨셋으로 직접 잰 값이 아닙니다. 그래서 지금은 "골치 아픈 걸 하나 줄여주는 유력 후보" 정도로 놓고, 나중에 직접 벤치해 볼 생각입니다. Tev1 4B는 라이선스가 미정이라 아예 결정에서 미뤄뒀고, 0.8B는 63.5%로 실사용이 어렵다는 판단에 탈락했습니다.

왜 빠른가 — 토큰 디코딩 없는 스코어링

가장 큰 차이는 동작 방식에 있습니다. 일반 생성 모델은 토큰을 뱉어 글을 완성하고, 그 글에서 라벨을 굳이 파싱해 냅니다. 반면 스코어링 분류 모델은 토큰 디코딩을 하지 않고, 후보 라벨들에 대한 확률 하나만 내놓습니다. 레터 하나에 확률 하나, 그 결론을 그대로 쓰는 구조입니다. 글을 쓰고 읽는 단계가 통째로 사라지니, 기존 JSON 파싱 오버헤드와 그게 만들어내던 병목이 사라집니다. 실제로 100문항을 돌리는 데 70초씩 걸리던 병목이 이 교체로 사라졌습니다.

작은 컨텍스트의 한계도 이 작업에서는 거의 무력화됩니다. 메일 분류는 상태가 짧아서, num_ctx 8,192(실측으론 약 2,050)라는 작은 컨텍스트 한계가 실전 성능에 거의 아무 영향이 없었습니다. 넓은 컨텍스트가 필요한 장르에선 이 모델이 쓸모없겠지만, 분류처럼 상태가 짧은 결정 작업에서는 오히려 그 한계가 부담이 되지 않습니다.

함정 — 완벽한 성공담은 아닙니다

다만 이게 "그냥 바꾸면 만능"이라는 뜻은 아닙니다. 실제로 부딪힌 함정들이 있었습니다.

첫째는 교정(calibration) 부재입니다. 스코어링 모델들이 내놓는 확률은 신뢰도가 꽤 낮아서, 확실하지 않은데도 높은 확률을 뱉는 경우가 생깁니다. 그래서 자동화 임계값, 이를테면 오토 게이트 같은 걸 걸 땐 확률을 그대로 쓰면 안 되고 재교정을 반드시 거쳐야 합니다.

둘째는 하드웨어 호환성입니다. 일부 리모트 서버 노드는 AVX 명령어를 지원하지 않는 QEMU 가상머신이라, 최적화된 바이너리를 실행하면 SIGILL로 바로 죽어버렸습니다. 그래서 로컬 배포는 GB10 듀얼이나 워크스테이션 쪽으로 정리했습니다. 같은 바이너리라도 돌 수 있는 땅과 없는 땅이 갈린다는 걸, 이번에 뼈저리게 보여줬습니다.

셋째는 라이선스입니다. Tev1 4B는 아직 라이선스가 정리되지 않아, 공개 배포나 상용화 때 주의가 필요한 상태입니다. Apache 2.0인 Nimble 9B가 이 점에서 여유가 있는 편이었습니다.

아직은 비교 분석 단계

이 시점에서 분명해진 건, "큰 모델이 무조건 낫다"가 아니라 작업 특성에 맞는 모델을 고르는 게 답이라는 점입니다. 단발성 결정 작업에서는 빠른 스코어링이 압도적으로 유리합니다. 그런데 솔직히 말하면, 지금 결과는 아직 비교 분석 단계에 있습니다.

실제 랩 라벨셋으로 Nimble 9B를 벤치하고, 기존 파이프라인의 백엔드를 교체하고, 오토 게이트 임계값을 재교정하는 작업이 남아 있습니다. 지금의 90.12%라는 수치는 정확히 검증되기 전까지는 참고용이고, 검증되지 않은 수치는 이 글에서도 조심스럽게 다뤘습니다. 후속으로 랩 라벨셋 벤치, 백엔드 교체, 임계값 재교정을 진행해 결과를 또 정리해 보겠습니다.

이번에 배운 건, 커다란 모델이 무조건 우수한 게 아니라는 교훈보다는 "일의 성격을 먼저 보자"는 태도였습니다. 분류라는 정해진 직무에는, 작지만 딱 맞는 도구가 있었다는 이야기였습니다.