한국어 LLM 벤치마크
한국어 LLM을 같은 조건에서 비교하는 벤치마크.
한국어 LLM 벤치마크는?
한국어 LLM 성능을 객관적으로 평가·비교하는 웹 벤치마크 플랫폼이다. 여러 LLM(OpenAI GPT · 네이버 HyperCLOVA X · Google Gemini)을 4가지 평가 방식으로 돌려 정답률·품질을 시각화해 한 화면에서 비교한다.
회사에서 한국어 업무에 어떤 LLM을 채택할지 판단하려고 만든 내부 도구다. 납품물이나 출시작이 아니라, "모델 선정의 객관적 근거"를 확보하기 위한 실무 도구를 혼자 프론트 대시보드부터 백엔드 평가 엔진·모델 추론까지 만들었다.
회사 내부 도구다. 조직·라이선스명, 평가에 쓴 특정 지자체 공공정책 데이터는 익명화했다.
왜 만들었나
"한국어 업무엔 어떤 LLM이 제일 나은가?"에 답하려면 감이 아니라 숫자가 필요했다. 그런데 벤치마크는 여기저기 흩어져 있고, 한국어 특화 모델(HyperCLOVA)과 범용 모델(GPT)을 같은 조건으로 비교한 자료도 마땅치 않았다. 그래서 모델 × 평가방식을 한 매트릭스에서 동일 데이터로 돌려 비교하는 도구를 직접 만들었다.
전체 구조
4가지 평가 방식
같은 모델도 무엇을 묻느냐에 따라 실력이 다르다. 그래서 축을 넷으로 나눠 다각도로 봤다.
K-MMLU
회계·건강 같은 한국어 전문지식 4지선다로 정답률을 잰다. "학술 표준 벤치에서 이 모델이 얼마나 아는가".
도메인 특화, 공공정책
학술 데이터가 아닌 실제 도메인에서의 전문성을 본다. 특정 지자체(익명)의 공공정책 데이터(고시공고·정책·복지·채용 등)로 객관식을 만들어, 실무 영역에서 모델이 얼마나 정확한지 측정했다. 범용 벤치에선 안 드러나는 실전 격차를 보려는 축.
다국어 번역, LLM-as-judge의 씨앗
영·일·중·베트남어를 한국어로 번역시키고 품질을 판정한다. 번역은 정답이 하나가 아니라서 정답지 매칭만으로는 안 된다. 그래서 키워드 매칭(40%) + 의미 유사도(60%)로 보고, 의미 유사도는 GPT가 채점하게 했다. 정답지로 안 되는 자유 텍스트를 LLM 심판으로 평가하는 방식을, 여기서 이미 부분적으로 쓴 셈이다. 이게 나중에 새김 Eval로 이어지는 씨앗이 됐다.
KLUE-NLI
전제-가설의 관계(일치/중립/모순)를 분류시켜 추론 능력을 본다.
기술 스택
- 프론트: React · Vite · Tailwind · Framer Motion · Recharts · lucide-react
- 백엔드: Node.js · Express (REST)
- 모델: OpenAI GPT · HyperCLOVA X (Python + LangChain) · Google Gemini
- 데이터: Hugging Face Datasets(K-MMLU·KLUE-NLI) + 로컬 JSON(도메인·번역)
왜 이 스택
- React · Recharts: 결과가 의사결정용(모델 선정 근거)이라, 모델 × 평가방식을 한눈에 비교할 차트 시각화가 핵심이었다.
- Node/Express + Python: 프론트·API는 Node로 빠르게, 실제 모델 추론은 Python으로 분리했다.
- LangChain: 여러 한국어 LLM(GPT·HyperCLOVA X·Gemini)을 같은 인터페이스로 호출해야 공정한 비교가 된다. 여기서 LLM 의미 채점을 처음 써봤고, 그게 새김 Eval의 reference-free로 이어졌다.
- Hugging Face Datasets: K-MMLU·KLUE-NLI 같은 표준 벤치를 직접 만들지 않고 검증된 셋으로 가져와 학술 벤치의 신뢰성을 확보했다.
Decision Log
평가를 모델 × 방식 매트릭스로 한 화면에 모아, 같은 조건으로 비교해 모델 선정 근거를 만든다.
HyperCLOVA(한국어 특화)와 GPT(범용)를 한국어 도메인에서 같은 조건으로 붙여, 실효성을 실측으로 검증한다.
정답지 매칭만으론 못 잡는 자유 텍스트 품질을 GPT 의미 유사도로 보완했다. reference-free 평가의 맹아다.
의사결정자(비개발자)가 읽을 수 있도록 차트로 시각화. 도구의 목적이 "판단"이니까.
회고: 정답지의 한계, 그리고 다음
한국어 LLM 벤치마크는 토이가 아니라 실무 필요에서 나온 내부 도구이자, "LLM을 어떻게 평가할 것인가"라는 문제의식의 출발점이다.
만들면서 한계를 봤다. 이 도구는 정답지가 있는 데이터셋(K-MMLU·KLUE·번역쌍)에서만 작동한다. 그런데 실제 AI 서비스의 자유 출력엔 정답지가 없다. 이 한계가 다음 프로젝트 새김 Eval로 이어졌다. 정답지 없이도 믿을 수 있는 점수를 내는 reference-free 평가로.