9. LLM 평가(Evaluation) - 벤치마크·리더보드 정리부터 9개 모델 Python -> C++ 포팅 실험까지

 

목차 

1. 주요 벤치마크와 벤치마크의 한계점 
2. 주요 리더보드 사이트
3. 프론티어 모델별 코드 생성능력 (Python to C++ 포팅 성능 비교)
4. 오픈소스 모델 포함 생성능력 비교 ( Python to C++ 포팅 성능 비교, w/ Gradio UI)
5. 생성형 AI 솔루션 성능 평가를 어떻게 할 것인가? 
 

---

이번 글은 모델 평가(Evaluation) 관련 챕터를 공부했던 글로 
1) 주요 벤치마크들과 리더보드 사이트에 대해 공부해 본 내용 
2) 실제로 다양한 closed 모델, open source 모델들의 성능을 코드 생성능력 task를 직접 시켜보며 비교해 본 내용 
을 작성해보고자 한다. 

1. 주요 벤치마크와 벤치마크의 한계점 

1) 주요 벤치마크

주요 6개 벤치마크

1)- 1. 6개 벤치마크 등장 배경 

• MMLU, GSM8K, HumanEval 같은 기존 벤치마크
  → GPT-4급 모델들이 거의 만점
• 그래서:
  • “모델이 진짜 똑똑해진 건지”
  • “문제를 외운 건지” 구분이 어려워짐

=> 그에따라 더 어렵고, 더 인간 상위권 수준의 벤치마크 지표가 개발됨
이런 벤치마크를 맹신해서는 안되지만 특정 작업에 맞는 모델을 고르는 데 있어 starting point로 적절
 

1)- 2. 6개 벤치마크별 상세 설명 

	1) 평가항목	어떤 벤치마크?	해석 포인트
1. GPQA (google proof q&A) -> PhD급 과학 전문성	PhD Science Expertise	생물·화학·물리 등 박사급 과학 질문 448개 구글링 가능해도: 비전공 인간 평균 정답률: 34% 65%가 박사급 gpt 4o 가 39% 정도 단순 검색 ❌ 전문 지식 + 개념 연결 능력 필요	GPQA 점수 높다 = 👉 “이 모델은 전문가 역할을 어느 정도 대체 가능”
2. MMLU-PRO -> 언어 이해력	Language Understanding	기존 MMLU와의 차이  4지선다-> 10지 선다 노이즈 많음 -> 정제된 문제 패턴 추측 가능 -> 추측 불가	단순 “영어 잘함” ❌ 의미 기반 이해 / 문맥 유지 능력 측정 챗봇, 문서 요약, 정책 분석 등 → 언어 정확도가 중요한 서비스용 모델 평가에 적합
3. AIME -> 상위 1% 수학 사고력	Math (Reasoning 중심)	미국 AIME 수학 경시대회 초엘리트 고등학생 대상 계산 ❌ 수학적 사고 + 증명 아이디어 공식 대입 불가 중간 추론이 길고 복잡	기존 주요 벤치마크였던 GSM8K는 “초중등 수학” AIME는 “수학적 사고력 그 자체” 금융 모델링 알고리즘 설계 고난도 의사결정 지원 등 서비스 측정에 적합
4. LiveCodeBench -> 코딩 실력	Coding (실전형)	LeetCode / AtCoder / Codeforces 문제 기반 단순 함수 구현 ❌ 시간 복잡도, 엣지 케이스 고려 HumanEval은 “toy problem” LiveCodeBench는 대회급 문제	코드 생성 AI의: 실무 투입 가능성 자동 코딩 에이전트 성능 판단
5. MuSR -> 추론 성능	Multi-Step Reasoning	장기 문맥 유지 정보 통합 논리적 배제 추론 필요 예시문제  1,000단어짜리 추리소설 질문: “누가 수단(means), 동기(motive), 기회(opportunity)를 가졌는가?”	Chain-of-Thought의 질적 수준 평가 단순 reasoning 흉내 ❌
6. HLE -> 초인적 지능 평가	Super-human Intelligence	2,500문제 멀티모달 (텍스트+이미지 등) 출제 의도: “AI를 위한 마지막 학술 시험” 인간 상위권도 거의 못 품 정답보다 사고 과정 자체가 관건	이건 실무용보다는: AGI 근접성 연구용 벤치마크 -> “이 모델이 인간 지능을 넘었는가?”를 묻는 실험장 -> 2024에는 모델들이 2~3%

 
 

2) 벤치마크의 한계점 

1. Training data contamination (훈련데이터 오염)

• 벤치마크 완전 비밀로 하기 힘듬
• 훈련데이터에 이런 벤치마크 테스트에 대한 정보 포함되기도
• 계속 지표 바꾸고, 업데이트하는 식으로 대응하기도 해 벤치마크 사들은

2. Not consistently applied

• 모델이 어떤 하드웨어에서 돌아가는가 에 따라서도 성능 다를 수 있음

3. Too narrow in scope

• 벤치마크가 너무 세부적인 영역(ex. 화학) 집중하는 케이스도 있음

4. Hard to measure nuanced reasoning

• 대부분 객관식 답안이거나, 고정된 구조
• 뉘앙스 테스트 어렵

5. Satuartion (포화도) 

• 이미 99점 이상 맞는 벤치마크도 많음

6. Overfitting  

• 특정 메트릭 해결하도록 과도하게 맞춰진 모델 있을 수 있음

7. (증명 안됨) frontier llm은 그들이 평가되고 있다는 걸 인지해서 답변을 왜곡할 수도 있음 

 

3) 느낀 점

실제로 ai 트렌드 관련한 기사들을 보다 보면 새로 나온 이 모델의 벤치마크 성능이 어떻네?라는 식의 내용들을 많이 접하게 된다. 
요새는 모델들의 벤치마크 성능이 워낙 상향 평준화 됐기도 하고, 단순 모델 성능보다 에이전트를 위한 하네스를 어떻게 설계하냐 그로 인한 에이전트 쪽 실행능력이 얼마나 뛰어나냐가 더 중요해지고 있긴 하다.
(실제로 관련된 벤치마크들도 계속 새로 나오기도 하고)
 
그래도 일반적인 모델 성능을 측정할 때 주로 쓰는 벤치마크들에 대해 한번 정리해 볼 수 있는 지점이었다. 
 
 

2. 주요 리더보드 사이트 

위에서 소개한 벤치마크들을 포함해서 다양한 지표로 모델들을 비교하는 
주요 리더보드 사이트 5곳에 대해서 알아봤다. 
 

1) 주요 리더 보드 사이트 

1)-1. Artificial Analysis

기사에 자주 등장하고, 최근에 독파모 사업 관련해서도 "특정회사의 모델이 Artificial Analysis 순위 몇 등에 들었다" 식으로 기사에 많이 보도되기도 한다. 
https://artificialanalysis.ai/

AI Model & API Providers Analysis | Artificial Analysis

 
 
아래의 10개의 벤치마크 지표를 기준으로 최근엔 순위가 매겨진다. 
몇 달 전까지만 해도 10개의 벤치마크 지표에 위에서 서술한 MMLU-Pro, Live code bench, AIME 등도 포함되어 있었으나
해당 지표들도 이미 너무 상향 평준화가 되었는지 해당 지표들이 빠지고 다른 지표들로 대체가 되었다. 
 
- 10 evaluations:
GDPval-AA, 𝜏²-Bench Telecom, Terminal-Bench Hard, SciCode, AA-LCR, AA-Omniscience, IFBench, Humanity's Last Exam, GPQA Diamond, CritPt

2026.04.12 기준 순위

 
 
순위 외에 Artificial intelligence index를 돌리기 위해 각 모델별로 필요한 cost와 각 모델별 점수를 비교해 놓은 그래프도 볼 수 있다.

(2026.04.12 기준) Artificial intelligence index 를 돌리기 위해 각 모델별로 필요한 cost와 각 모델별 점수를 비교해놓은 그래프

1)-2. Vellum

Vellum의 경우 AA와 유사하게 리더보드를 볼 수 있고 모델별 비교를 하기 좋은 사이트이다.
https://www.vellum.ai/llm-leaderboard?utm_source=google&utm_medium=organic

LLM Leaderboard 2025

 
아래 이미지와 같이 모델 2개 간 벤치마크를 서로 비교해 볼 수 있고,

(2026.04.12 기준) 클로드 모델간 비교

 
특히나 모델별 context window와 비용을 표로 바로 비교해볼 수 있어 어떤 모델을 쓸지 선택하는 데 있어 참고하기 유용하다
(물론 openrouter나, Groq 등의 플랫폼을 써서 모델을 사용하는 경우에도 이를 바로 볼 수 있겠지만 
특정 모델사에서 바로 API를 써야 할 땐 이 표를 보고 참고하는 것도 괜찮을 듯하다)

(2026.04.12 기준) 모델별 Context window와 cost

1)-3. Seal

다양한 전문 분야에 대해 구체적으로 테스트 가능 
매우 전문적인 작업하는 경우 자신에게 해당하는 Seal 리더보드 있는지 확인할 때 유용
 
https://labs.scale.com/leaderboard

AI Model Leaderboards & Benchmarks

 
HLE 벤치마크에 대한 자세한 정보를 볼 수도 있고 

HLE 벤치마크에 대한 자세한 정보

아래처럼 특수 TASK별 지표를 볼 수도 있다.

• MCP ATLAS: mcp 활용한 툴 호출 성능
• Fortress: 보안 관련 지표 
• MASK: 모델이 거짓말하는지를 측정하는 지표 
• TutorBench: 잘 가르치는 AI인지 평가

 

MCP atlas, fortress

 
 

mask, tutorbench

1)-4. LiveBench

데이터셋 유출 문제가 발생하지 않도록 장치를 해둔 사이트인 
LiveBench 도 있다.
https://livebench.ai/#/?highunseenbias=true

LiveBench

 

1)-5. LM Arena

마지막으로 LM Arena는 blind human test 즉 blind 상태로 2개의 모델과 채팅해 볼 수 있는 사이트이다.
https://arena.ai/

Arena | Benchmark & Compare the Best AI Models

 

2) 느낀 점

벤치마크와 마찬가지로 기사에서 많이 봤던 리더보드 사이트들이 실제로 어떻게 생겼고, 각 사이트별로 어떤 기능들을 담고 있는지를 볼 수 있던 게 의미가 있던 거 같다. 특히나 각 세부지표별로 최근엔 어떤 모델들이 강점을 가지고 있나 지켜보는 것도 의미가 있던 거 같다. 
 
 

3. 프론티어 모델별 코드 생성능력 (Python to C++ 포팅 성능 비교)

Python 코드를 LLM에게 C++로 변환시킨 뒤, 실제로 컴파일·실행해서
3개 모델 (GPT-5, Claude-Sonnet 4.5, gemini 2.5 pro) 중 어떤 모델이 가장 빠른 C++을 생성하는지 비교하는 실험 진행
 

1) 실행과정 

1) -1. 시스템 정보 수집

현재 컴퓨터의 OS, CPU, 컴파일러 정보를 자동으로 수집

현재 컴퓨터 OS, CPU, 컴파일러 정보 수집

 
GPT 5에게 컴파일 방법 질문
: 내 시스템에서 C++를 어떻게 컴파일하면 되냐"라고 물어봄

 
GPT 응답 참고해 컴파일 명령어 설정한 뒤 프롬프트 구성 
 

 
1) 생성된 c++ 코드를 main.cpp 파일로 저장하는 코드와 
2) port 함수 정의 (LLM에 c++ 변환요청 -> 응답 텍스트 추출 -> 마크다운 코드블록 제거 -> main.cpp 로 저장)

 
 

1) -2. 테스트용 파이썬 코드 준비 

라이프니츠 급수를 활용한 원주율(π) 계산 코드를 사용. 2억 번 반복하는 연산 집약적인 코드
python 기준으로 10초 정도가 걸렸음

 

1) -3. LLM 에 C++ 변환 요청 & 컴파일 & 실행

-  GPT-5, Claude Sonnet 4.5, Grok, Gemini 2.5 Pro 각각에게 동일한 Python 코드를 넘기고 "가장 빠른 C++로 변환해 달라"라고 요청
-  OpenAI는 직접 API를 사용하고, 나머지 2개 모델은 OpenRouter를 통해 하나의 API 키로 통합 호출
 

 
GPT 5 기준 3번 돌렸을 때 중앙값 기준으로 50배 정도 빨라짐

 

1) -4. 결과 비교 

Python 실행 시간 대비 C++ 실행 시간의 속도 향상 배수(speedup)를 모델별로 비교 
Gemini 2.5 pro> claude sonnet 4.5 > GPT-5 순으로 *성능이 좋은 것을 확인할 수 있었다. 
(*실행할 때마다의 환경에 따라서도 속도가 달라졌기 때문에 절대적인 순위에 대한 맹신은 x)

 

 

4. 오픈소스 모델 포함 코드 생성능력 비교 ( Python to C++ 포팅 성능 비교, w/ Gradio UI)

1) 실행과정 

이번엔 위에서 언급한 3개의 프론티어 모델 외에도 오픈소스 모델 몇 개를 추가하여
총 9개의 모델을 가지고 동일한 python코드에 대한 c++ 포팅 시 성능을 비교해 봤다. 
아래 이미지처럼 Gradion UI를 통해 실제 변환된 C++ 코드도 바로 볼 수 있게 진행되었다. 
 
 
실험해 본 9개 모델 리스트는 아래와 같다. 
오픈소스 모델인 qwen 2.5 coder, deepseek coder, gpt oss 20b 등은 ollama를 통해 로컬에서 돌렸고 
오픈소스 모델이지만 규모가 큰 gpt oss 120 b는 openrouter를 통해 돌렸다. 
LGAI의 K EXAONE은 friendli AI를 통해 돌렸다. 
 
grok4는 openrouter로, gpt 5, claude sonnet 4.5, gemini 2.5 pro는 각각의 api로 돌렸다.

models = ["gpt-5", "claude-sonnet-4-5-20250929", "x-ai/grok-4", "gemini-2.5-pro", "qwen2.5-coder", "deepseek-coder-v2", "gpt-oss:20b", "qwen/qwen3-coder-30b-a3b-instruct", "openai/gpt-oss-120b", "LGAI-EXAONE/K-EXAONE-236B-A23B"]

clients = {"gpt-5": openai, "claude-sonnet-4-5-20250929": anthropic, "x-ai/grok-4": openrouter, "gemini-2.5-pro": gemini, "openai/gpt-oss-120b":  openrouter, "qwen2.5-coder": ollama, "deepseek-coder-v2": ollama, "gpt-oss:20b": ollama, "qwen/qwen3-coder-30b-a3b-instruct": openrouter, "LGAI-EXAONE/K-EXAONE-236B-A23B": friendli}

 

c++ 포팅을 실행해볼 수 있는 Gradio UI 구성함

 
실제 실행결과 gemini 2.5 pro가 압도적으로 성능이 좋게 나와버렸는데, 이전에 프론티어 모델끼리 테스트했을 때에 비해서도 
성능이 확 좋게 나온 건 이번엔 openrouter로 gemini를 돌린 게 아니라 직접 gemini api를 써서인가 싶다. 
아쉽게도 exaone과 , deepseek coder v2, qwen 2.5 coder가 변환한 c++코드는 내가 돌렸을 땐 코드에서 에러가 발생하며 fail로 실패한걸 볼수 있었다.
 

그래프 하단 3개 모델은 c++ 코드 실행과정에서 에러가 발생했다.

아래는 유데미 강사가 돌렸던 결과(아마도 작년 11~12월쯤?)인데 큰 경향성은 유사한 걸 볼 수 있다. 
(뭔가 이 task는 제미나이가 잘하는듯하다)
하지만 실제 내가 돌렸을 땐 fail 인 것도 때로는 성공하는 걸 보면 그때그때의 상황+ 각자의 하드웨어에 따라서도 결과가 조금씩 다르게 나오는 듯하다. 

강사가 진행했던 결과

 

2) 느낀 점 

벤치마크 성능이 더 좋은 모델이라 하더라도, 실제 특정 task에서 해당 모델이 잘 먹히냐 안 먹히냐는 결국 돌려봐야 안다는 것을 좀 몸소 느꼈던 거 같다. 또한 때로는 특정 task에선 비싸게 프론티어 모델 쓰는 것보다 오픈소스 모델 잘 가져다 쓰는 게 괜찮을 수도 있겠다는 걸 
위 테스트에서 오픈소스 모델들의 선전을 통해 볼 수 있었던 거 같다. 
 
 

5. 생성형 AI 솔루션 성능 평가를 어떻게 할 것인가? 

1) 느낀 점

모델 센트릭과, 비즈니스 센트릭 지표

 
강사는 모델 평가 관련된 마지막으로 모델 센트릭한 지표와, 비즈니스 센트릭한 지표를 예로 들어주며
모델 centric 지표만 좋다고 되는 게 아니라 결국엔 비즈니스 지표적으로 좋은 게 생성형 AI 서비스에선 중요하단걸 마지막으로 언급했다. 
 
굉장히 많이 공감을 했던 내용으로 개발적으로 나오는 기술적 수치와 또 실제 엔드유저가 느끼는 체감은 클 수밖에 없다. 
그렇기 때문에 위 강사의 말처럼 기본적으로 모델 centric 지표는 어떠한 최소 기준을 통과시키는 용도로 사용하고, 
비즈니스 지표를 그 후에 보며 실제 성공/실패 여부를 판단하는 게 필요하지 않을까 라는 생각을 하게 됐다. 
 

---

이번 글은 강의의 모델 evaluation 관련 전체 챕터를 한 글에 담아보았다. 
기사에서 많이 봤던 벤치마크나 리더보드에 대한 공부도 해볼 수 있었고 
실제 코드 생성 능력을 프론티어모델부터 오픈 소스 모델까지 직접 써보며 수치를 가지고 비교해 볼 수 있던 부분이 인상적이었던 거 같다. 
 
다음 챕터는 RAG로 아마 한편에 다 쓰긴 어려울 거 같고, 
조금 나눠서 글을 쓸 생각이다. 
 
(꾸준히 공부하고, 적을 테니 많은 관심 부탁드립니다.)
 
Profile:
Linkedin