이 글은 PyCon Korea 2025에서 진행된 <고등학생이 만들어 본 LLM-as-a-judge 번역 벤치마크 리더보드: AI가 평가하는 번역, KorT> 세션을 정리한 내용입니다. 구글의 TPU 지원과 엔트로픽(Anthropic)의 API 크레딧을 받아, 한국어 번역 벤치마크, KorT를 구축한 발표자의 개발기를 공유합니다. 발표 자료는 PyCon Korea 2025 공식 홈페이지에서 확인할 수 있으며, 추후 파이콘 한국 유튜브 채널을 통해 영상으로도 만나보실 수 있습니다. (따로 출처가 명시되지 않은 모든 이미지의 출처는 발표자에게 있습니다.)

고등학생이 만들어 본 LLM-as-a-judge 번역 벤치마크 리더보드: AI가 평가하는 번역, KorT
심기현

안녕하세요. 저는 세상의 변화, 특히 기술이 어떻게 세상을 바꾸는지에 호기심이 많은 고등학생 개발자 심기현입니다. 현재 일반고 2학년에 재학 중이며, 학교 공부만큼이나 NLP(자연어 처리)와 LLM(거대 언어 모델) 분야를 정말 좋아합니다.

혹시 ‘나만의 AI 서비스를 만들고 싶은데 GPU가 없어서 못 해’라고 포기하신 적이 있나요? 혹은 ‘내가 파인튜닝한 모델이 실제로 얼마나 똑똑해졌는지 어떻게 알지?’라는 의문을 품어본 적 있으신가요? 이 글은 바로 그런 고민을 가진 분들을 위해 쓰였습니다.

오늘 저는 좋은 GPU 하나 없는 평범한 고등학생이 구글의 TPU 지원과 엔트로픽(Anthropic)의 API 크레딧을 받아, 맨땅에서 한국어 번역 벤치마크, KorT를 구축한 좌충우돌 개발기를 공유하려 합니다. 단순히 모델을 가져다 쓰는 것을 넘어, 직접 만든 모델을 평가하기 위해 AI 심판관을 채용하고, 리버스 엔지니어링으로 데이터를 수집하며, 파이썬으로 견고한 파이프라인을 구축한 과정을 상세히 담았습니다. NLP 엔지니어, LLM 평가 방법론을 고민하는 연구자, 그리고 제한된 환경 속에서도 무언가 만들어보고 싶은 모든 메이커분들에게 작은 영감이 되기를 바랍니다.

0.015%의 한국어 데이터, 그리고 리소스의 갈증

챗GPT의 등장과 한국어의 소외

시간을 거슬러 2022년 겨울, 챗GPT(ChatGPT)가 처음 세상에 나왔을 때를 기억하시나요? 전 세계가 떠들썩했지만, 한국 사용자로서 저는 약간의 아쉬움을 느꼈습니다. 당시 GPT-3의 학습 데이터 통계를 봤더니 영어가 92%를 차지하는 동안 한국어 데이터는 전체의 고작 0.015%에 불과했거든요.

“0.015%만 썼는데도 한국말을 이 정도 하는데, 한국어만 전문적으로 가르치면 얼마나 더 잘할까?”
“그렇다면 한국어 성능이 뛰어난 모델을 직접 만들어볼 수는 없을까?”

이 당찬 호기심은 곧바로 현실의 벽에 부딪혔습니다. 아시다시피 LLM을 직접 학습시키거나 파인튜닝(Fine-tuning) 하려면 수천만 원을 호가하는 고성능 GPU가 필수적입니다. 용돈을 모아 그래픽 카드를 사는 수준으로는 어림도 없는 일이었죠. 학생인 저에게 고성능 컴퓨팅 파워는 꿈같은 이야기였습니다.

구글의 선물, TRC(TPU Research Cloud)와 시행착오

그때 한 줄기 빛처럼 발견한 것이 바로 구글의 TRC(TPU Research Cloud) 프로그램이었습니다. 연구 목적으로 신청하면 구글의 자체 AI 가속기인 TPU(Tensor Processing Unit)를 무료로 빌려준다는 것이었죠. 운 좋게 기회를 얻었지만, 기쁨도 잠시였습니다. TPU는 엔비디아(NVIDIA) GPU와 아키텍처가 완전히 다르기도 하고, 멀티호스트(Multi-hosts) 멀티디바이스(Multi-devices) 환경이 매우 복잡했기 때문이었습니다.

저는 llama-tpu나 KorQuAD-TPU 같은 프로젝트를 해보며 TPU 환경에 적응해 나갔습니다. 특히 구글이 공개한 오픈 모델 젬마(Gemma)의 한국어 성능이 준수하다는 점에 착안했습니다. Beomi님의 Gemma-EasyLM 코드를 참고하여 TPU v4-64 장비에서 분산 학습 환경을 구축했고, 마침내 영-한 번역에 특화된 파인튜닝 모델 'Gemago'를 탄생시킬 수 있었습니다.

하지만 정작 결과물이 나왔을 때, 이 모델의 성능을 증명할 방법이 없었습니다.

“그래서, 내가 만든 이 모델이 진짜 번역을 잘하는 건가? 도대체 '좋은 번역'의 기준이 뭐지?”

“내 모델이 파파고보다 나은가? 구글 번역기보다는? 도대체 ‘좋은 번역’을 어떻게 증명하지?”

기존에 파파고나 구글 번역기가 있지만, 내 모델이 그들보다 나은지, 혹은 어떤 점이 부족한지 객관적으로 알 길이 없었습니다. 기존의 BLEU Score 같은 정량적 지표는 문맥의 뉘앙스를 잡아내지 못합니다. 그래서 결심했습니다. 제대로 된 한국어 번역 평가 벤치마크를 직접 만들어보기로요.

AI 심판관을 채용하자, LLM-as-a-judge 설계

벤치마크를 만들려면 수천 개의 번역 문장을 채점할 공정한 심판이 필요합니다. 사람이 일일이 채점할 수는 없으니, 최근 주목받는 LLM-as-a-judge 방법론을 도입하기로 했습니다. 즉, AI가 한 번역을 더 똑똑한 AI가 평가하게 하자는 것이죠.

학생의 신분을 적극 활용, Claude for Student Builders

심판 역할을 할 모델은 기본적으로 번역기들보다 훨씬 뛰어난 추론 능력을 갖춰야 합니다. 문제는 고성능 모델일수록 API 비용이 비싸다는 점입니다. 여기서 또 한 번 외부의 도움을 받았습니다. 앤트로픽(Anthropic)에서 학생 개발자에게 API 크레딧을 지원해 주는 Claude For Student Builders 프로그램이었습니다. (현재는 없어진 것으로 보입니다.)

덕분에 50달러 상당의 크레딧을 지원받아, 당시 최고 수준의 추론(Reasoning) 능력을 갖춘 Claude 3.7 Sonnet 모델을 메인 심판관으로 고용할 수 있었습니다. 비용 걱정 없이 최고의 모델을 심판으로 쓸 수 있게 됐습니다.

번역기를 괴롭히는 매운맛 데이터셋 설계

Hello를 안녕으로 번역하는 건 누구나 합니다. 변별력 있는 벤치마크를 만들려면 번역기의 멘탈을 흔들 수 있는 까다로운 문장들이 필요했습니다. 저는 나무위키의 번역할 수 없는 표현 문서에서 영감을 얻어, 단순 직역으로는 해결되지 않는 5가지 고난도 카테고리를 설계했습니다.

속담 및 관용어(Idioms/Proverbs): 직역하면 뜻이 산으로 가는 문장들
말장난(Wordplay): 언어유희와 라임(Rhyme)을 살려야 하는 문장들
문화적 표현(Cultural References): 한국 고유의 정서나 특정 밈(Meme)이 포함된 문장들
속어 및 신조어(Slang): 사전에는 없지만 실생활에서 쓰이는 최신 밈이나 줄임말들
문학적 표현(Literature): 시적인 은유와 함축적 의미가 담긴 문장들

데이터셋을 만드는 과정에서도 클로드(Claude)의 도움을 받았습니다. “당신은 언어학 전문가입니다. 도착 언어에 딱 맞아떨어지는 단어가 없는 문화적 개념을 포함한 문장을 만들어주세요”라고 페르소나(Persona)를 부여하여 200여 개의 고난도 문장을 생성했고, 제가 직접 검수하여 최종 49개를 선별했습니다.

편파 판정을 막기 위한 프롬프트 엔지니어링

LLM 심판의 가장 큰 약점은 ‘기분파’라는 것입니다. 프롬프트가 조금만 바뀌어도 점수가 들쑥날쑥하거나, 특정 말투를 선호하는 편향(Bias)이 생길 수 있습니다. 이를 통제하기 위해 저는 아주 엄격하고 구조화된 평가 프롬프트를 설계했습니다.

페르소나(Persona) 부여: "당신은 전문 번역 평가관입니다."라고 역할을 명시합니다.
레퍼런스(Reference) 제공: 원문과 번역문 외에 '모범 답안(Professional Translation)'을 함께 제공하여 채점 기준을 잡아주었습니다.
5가지 평가 기준: 뭉뚱그려 점수를 주는 것을 막기 위해 정확성, 유창성, 용어 사용, 스타일, 문화적 각색이라는 5가지 항목을 제시했습니다.
생각의 사슬(Chain of Thought): <translation_evaluation> 태그 안에서 먼저 각 항목별로 분석을 수행한 뒤, 마지막에 점수를 출력하도록 유도했습니다. 이는 모델의 논리적 사고를 강제하여 채점 일관성을 높여줍니다.
출력 형식 고정: 파이썬 스크립트가 파싱하기 쉽도록 최종 점수는 반드시 <score> 태그 안에 숫자만 출력하게 했습니다.

Python으로 만드는 KorT CLI Tool

벤치마크 설계가 끝났으니 이제 구현할 차례입니다. 저는 단순히 스크립트 하나 돌리고 마는 것이 아니라, 새로운 모델을 계속 추가하고 확장할 수 있는 KorT CLI Tool을 파이썬으로 개발했습니다.

API가 없다면? 개발자 도구로 뜯어보자 (feat. 리버스 엔지니어링)

벤치마크에는 파파고, 카카오 번역, 구글 번역 같은 상용 서비스도 반드시 포함되어야 했습니다. 하지만 파파고처럼 공식 API가 유료이거나 제한적인 경우도 있었죠. 여기서 개발자의 집요함이 발휘되었습니다. (※본 프로젝트는 비상업적 학술 연구 목적으로 진행되었으며, 서버에 과도한 부하를 주지 않도록 주의했습니다.)

예를 들면, 브라우저 개발자 도구를 이용해 파파고의 요청 헤더에서 특정 키와 타임스탬프를 조합해 HMAC-MD5로 암호화한 뒤, 이를 Base64로 인코딩하여 인증 토큰을 생성하는 로직을 찾을 수 있습니다. 이 로직을 파이썬으로 포팅(Porting)하여 Wrapper 클래스를 만들었고, 덕분에 자동화된 번역 요청 시스템을 구축할 수 있었습니다. DeepL과 카카오 번역 역시 유사한 방식으로 API가 없는 상황을 돌파했습니다.

성능과 안정성을 모두 잡은 코드 아키텍처

KorT 툴은 다양한 모델(Claude, Gemini, GPT, Hugging Face 모델 등)을 지원해야 했기에 모듈화가 생명이었습니다.

_LazyModule 도입: Hugging Face의 transformers 라이브러리 구조를 참고하여, 사용자가 특정 모델을 호출할 때만 해당 라이브러리를 임포트하도록 _LazyModule을 구현했습니다. 덕분에 CLI 도구의 초기 구동 속도를 획기적으로 줄일 수 있었습니다.
타입 안정성 확보: pydantic과 dataclasses를 적극 활용하여 데이터의 입출력 구조를 명확히 정의했습니다.
코드 품질 관리: ruff와 ty 같은 최신 린터(Linter)와 타입 체커를 적용하여, 수천 라인의 코드에서 발생할 수 있는 버그를 사전에 차단했습니다. "Error 0"를 달성했을 때의 쾌감은 개발자만 알 수 있죠.

대망의 결과, 누가 번역의 왕인가?

Gradio를 이용해 웹 리더보드를 구축하고, 총 17종의 번역기(상용 서비스 + LLM)를 링 위에 올렸습니다. 과연 제 ‘Gemago’ 모델과 상용 번역기들의 승부는 어떻게 되었을까요?

LLM의 압승, 그리고 Gemini의 1등

예상대로 대부분의 LLM이 기존의 상용 번역기보다 높은 점수를 기록했습니다. 트랜스포머(Transformer) 아키텍처가 원래 기계 번역을 위해 탄생했다는 점을 생각하면 자연스러운 결과일지도 모릅니다. 흥미로운 건 구글 번역기보다 파파고의 순위가 높았고, 제가 만든 ‘Gemago’ 모델이 파파고와 비슷한 수준까지 올라왔다는 점이었습니다.

DeepL vs 파파고, “소 잃고 외양간 고치기”

상용 번역기 리그에서는 DeepL이 파파고보다 전반적으로 높은 점수를 받았습니다. 하지만 '속담과 관용어' 카테고리에서는 파파고가 DeepL을 눌렀습니다.

예를 들어, “소 잃고 외양간 고치지 말고…” 라는 문장을 번역할 때

DeepL: “Don't lose and fix…” (잃어버리지도 말고 고치지도 마라?)
Papago: “Don't fix after losing…” (잃어버린 뒤에 고치지 마라. 정확한 선후 관계!)

역시 한국 고유의 속담이나 문화적 뉘앙스는 한국 데이터를 집중적으로 학습한 ‘토종’ 파파고가 한 수 위였습니다. 이는 번역기를 선택할 때, 문맥에 따라 다른 도구를 써야 함을 보여줍니다.

카카오의 굴욕? 햄릿의 비극

카카오 i 번역은 DeepL 다음으로 준수한 성적을 거뒀지만, 문학적 표현에서 여러 실수를 범했습니다. 셰익스피어 햄릿의 유명한 대사 ‘To be or not to be’를 ‘되든 안 되든 그것이 문제다’라고 번역해 버린 것이죠.

아마도 실용문 위주의 정제된 데이터로 학습하다 보니, 고전 문학의 은유를 ‘성공과 실패’의 맥락으로 잘못 해석한 것으로 보입니다. 이런 발견이 바로 벤치마크를 만드는 재미가 아닐까요?

마치며: 계속되는 도전

이번 프로젝트는 “리소스가 없어서 못 해”라는 핑계를 “어떻게든 해보자”는 도전으로 바꾸는 과정이었습니다. GPU가 없으면 TPU를 빌리고, API 비용이 없으면 학생 지원 프로그램을 찾고, API가 없으면 뜯어보면서 길을 만들었습니다.

물론 KorT에도 한계는 있습니다. 문장이 짧아 긴 호흡의 맥락(Context)을 평가하기 어렵고, 심판관인 LLM 자체의 편향성 문제도 완벽히 해결하진 못했습니다. 향후에는 소설 같은 긴 글을 평가하는 Multi-turn 번역 평가, 여러 모델이 서로를 평가하여 순위를 매기는 Elo Rating 시스템 등을 도입해 더 정교한 벤치마크로 발전시킬 계획입니다.

제 모든 코드와 데이터셋은 깃허브에 오픈소스로 공개되어 있습니다. 혹시 여러분도 자신만의 모델, 혹은 자신만의 심판관을 만들어보고 싶지 않으신가요? 제 작은 시도가 여러분의 도전에 조금이나마 도움이 되었으면 좋겠습니다. 감사합니다.

<참고 링크>