2023년 말, 한 개발자가 MMLU 86점짜리 오픈소스 모델을 내려받았다. 리더보드 상위 10위 안에 들었고, 커뮤니티 평도 좋았다. 기대를 안고 코드 리뷰를 시켰다. 결과는? 함수 파라미터 순서를 반대로 알려줬고, SQL 인젝션 취약점을 놓쳤다. 벤치마크 점수만 보고 모델을 고르면 실패한다. 이 글은 LLM 선택의 함정들 — 벤치마크, sLLM 런타임, 그리고 알쏭달쏭한 기술 용어들 — 을 하나씩 뜯어본다.

벤치마크 점수, 믿을 만한가?

HuggingFace Open LLM Leaderboard. 이곳의 MMLU(Massive Multitask Language Understanding) 점수는 57개 과목에 대한 다지선다 정답률이다. 직관적이고 비교하기 쉽다. 문제는 이 점수가 실제 사용 경험과 심각하게 괴리된다는 데 있다.

NAACL 2025에서 발표된 "Are We Done with MMLU?" 논문에 따르면, Virology 과목 문항의 57%에서 정답 오류가 발견됐다. 이 논문이 제안한 MMLU-Redux(5,700문항 재검수)로 측정하자 주요 모델 점수가 3~8%p 일제히 하락했다. Microsoft의 MMLU-CF 실험에서도 40여 개 모델 전원이 성능 하락과 순위 변동을 겪었다.

더 근본적인 문제는 포맷 민감도다. GPT-4는 정답 위치를 고정했을 때 점수가 ±30%p까지 출렁였다. Llama-30B는 선택지 기호를 바꾸자 27%의 성능 차이를 보였다. 벤치마크 순위의 통계적 신뢰도를 나타내는 켄달 타우(Kendall's τ)는 셔플·기호 변경만으로도 0.56~0.73까지 떨어진다. 1.0에 가까워야 신뢰할 수 있는 순위라는 뜻인데, 절반 수준이다.

그렇다면 벤치마크를 아예 무시해야 하나? 그건 아니다. 다만 보는 법을 바꿔야 한다. MMLU 같은 다지선다식 지표보다 실제 작업과 유사한 생성형 벤치마크를 봐야 한다. 코드라면 HumanEval, 수학이면 GSM8K, 함수 호출이면 BFCL. 그리고 궁극적으로는 자신의 워크로드에서 직접 A/B 테스트하는 것보다 정확한 지표는 없다.

sLLM, 정말 필요한가?

Ollama. LM Studio. llama.cpp. KoboldCpp. 2026년 현재 소형 언어모델을 로컬에서 돌리는 도구는 넘쳐난다. 이 중 어떤 걸 골라야 할까?

흥미롭게도, 이 도구들의 엔진은 모두 llama.cpp다. C++로 작성된 GGUF 추론 엔진을 각자 다른 인터페이스로 감쌌을 뿐이다. 단일 사용자 기준 토큰 생성 속도는 Q4_K_M 양자화 기준 62~65 tok/s로 큰 차이가 없다. 차이는 운영 편의성과 생태계에 있다.

Ollama는 CLI와 API, Modelfile을 제공해 개발자와 백엔드 연동에 강하다. GitHub 174k 스타(2026년 중반)로 생태계가 가장 크다. LM Studio는 GUI 기반에 모델 브라우저와 하드웨어 자동 추천 기능이 있어 초보자에게 적합하다. KoboldCpp는 World Info, Author's Note, Memory 등 창작·롤플레잉 특화 기능으로 픽션 작가들 사이에서 표준처럼 쓰인다.

그런데 진짜 프로덕션을 생각한다면 vLLM을 봐야 한다. PagedAttention과 연속 배칭(continuous batching) 덕분에 단일 사용자 처리량은 Ollama 대비 1.1배지만, 100명이 동시에 요청하면 15~20배 차이가 난다. devcheolu 팀의 실측 벤치마크에 따르면, Ollama는 동시 사용자 5명만 넘어도 P99 레이턴시가 673ms까지 치솟는다. vLLM은 같은 조건에서 80ms. 혼자 쓰는 토이 프로젝트라면 Ollama, 팀 단위로 쓰는 도구라면 vLLM이다.

VRAM도 현실을 직시해야 한다. 7B 모델 Q4 양자화는 약 5~6GB, 70B Q4는 약 40GB를 잡아먹는다. RTX 3060 12GB로는 7B Q4가 쾌적한 마지노선이다. 13B Q4는 버겁고, 32B는 아예 불가능하다. RTX 4090 24GB로도 70B Q4는 구동 불가능 — 70B Q8은 48GB VRAM이 필요하다. Mac M4 Max 128GB 정도는 돼야 70B Q4가 원활하게 돌아간다.

많은 사람들이 놓치는 지점이 있다. "하드웨어 → 모델 크기 → 런타임" 순서로 결정해야 한다는 것이다. GPU부터 정해놓고, 그 위에서 돌아가는 모델을 고르고, 그 모델을 가장 효율적으로 서빙할 런타임을 선택하는 순서. 모델부터 고르는 건 벤치마크부터 고르는 것만큼 위험하다.

추론·컨텍스트·MoE… 이 단어들, 알고 보면 별거 아니다

"이 모델은 MoE 아키텍처에 128K 컨텍스트 윈도우를 지원하고 체인오브소트 추론이 가능합니다." 기술 스펙 시트에나 나올 법한 이 문장, 실제로 무슨 의미일까? 하나씩 까보자.

MoE(Mixture-of-Experts)는 모델의 전체 파라미터 중 일부만 활성화해서 연산량(FLOPs)을 아끼는 구조다. DeepSeek-V3는 총 671B 파라미터지만 실제 추론 시 활성화되는 건 37B뿐이다. MoE가 무조건 좋은 건 아니다. NAACL 2025 "Mixture of Parrots" 논문에 따르면, 전문가 수를 늘리면(활성 파라미터는 고정) 암기·지식 성능은 올라가지만 추론·수학·그래프 성능은 정체된다. Active FLOPs가 추론 성능을 결정한다는 게 이 논문의 결론이다.

컨텍스트 윈도우는 모델이 한 번에 "기억"할 수 있는 텍스트의 양이다. RoPE 스케일링(YaRN, LongRoPE) 기술 덕분에 128K, 심지어 1M 토큰까지 확장 가능해졌다. 하지만 윈도우가 크다고 다 좋은 건 아니다. Needle-in-Haystack 테스트(긴 텍스트 속에 숨겨진 정보를 찾아내는 벤치마크)로 검증해보면, 윈도우 끝부분의 정보는 잘 찾지만 중간 구간은 성능이 급락하는 경우가 흔하다. 숫자만 믿지 말고 실제 자기 워크로드에서 테스트해야 하는 이유다.

추론 모델(Reasoning Model)은 DeepSeek-R1이나 OpenAI o1 계열처럼 내부적으로 Chain-of-Thought 토큰을 생성해 정확도를 높이는 방식이다. 수학 문제를 풀 때 "중간 계산 과정"을 종이에 쓰는 것과 비슷하다. 당연히 출력 토큰이 3~5배 많아지고, 지연 시간과 비용도 비례해서 늘어난다. 모든 작업에 추론 모델이 필요한 건 아니다. 코드 자동완성이나 이메일 요약에는 Flash 계열이면 충분하고, 수학 증명이나 복잡한 디버깅에만 Pro/Reasoning 계열을 쓰는 게 실용적이다.

결국, 내게 맞는 모델을 찾는 법

벤치마크 순위는 참고만 한다. 실제 워크로드에서 직접 돌려보는 것보다 정확한 지표는 없다. 7B~13B 로컬 모델로 코드 완성·요약·간단한 추론을 커버하고, 복잡한 추론·장문맥·고정밀 작업만 API로 호출하는 하이브리드 전략이 2026년 현재 가장 합리적이다.

DeepSeek V4 Flash는 출력 100만 토큰당 $0.28로 GPT-4o 대비 97% 저렴하다. 캐시 히트 시 $0.0028까지 떨어진다. 로컬에 RTX 4090을 박고 전기세와 쿨링 소음을 감내할 이유가 점점 사라지고 있다. 단, 데이터 레지던시가 법적 요구사항이거나, 레이턴시 50ms 이하가 강제되는 실시간 서비스라면 자체호스팅이 답이다.

핵심은 이것이다. "이 모델이 몇 점이야?"가 아니라 "내 작업에 무슨 모델이 필요하지?"를 먼저 묻는 것. 그 질문 하나가 3개월의 방황을 3일로 줄인다.