한 줄 정의
LiveCodeBench는 언어 모델이 코드를 얼마나 잘 쓰고 고치는지 보려고 만든 benchmark야. 핵심은 새 문제를 계속 모은다는 점이야. LeetCode, AtCoder, Codeforces에서 공개된 문제에 날짜를 붙여 두고, 모델의 학습 시점 이후에 나온 문제만 골라 볼 수 있게 해.
그래서 이 이름이 보이면 먼저 “코딩 능력 점수”라고 읽되, 곧바로 “어느 리리즈(release) 버전, 즉 어떤 문제 묶음의 점수인가”와 “어느 기간, 어느 평가 작업의 점수인가”를 같이 물어봐야 해. 일반 지식 시험도 아니고, 실제 회사 저장소를 고치는 SWE-bench Verified도 아니야. 경쟁 프로그래밍 문제와 코드 관련 작업을 정해진 채점기로 반복 평가하는 벤치마크야.
어떻게 작동하나
이 벤치마크는 문제마다 공개 날짜를 들고 있어. 이게 오염 방지의 중심이야. 어떤 모델의 학습 cutoff가 2024년 8월이라면, 그 이후에 나온 문제만 골라 평가하는 식으로 “이미 학습 데이터에 들어갔을 가능성”을 줄여. 공식 설명은 이 구조를 코드 생성(code generation)뿐 아니라 스스로 고치기(self-repair), 코드 실행(code execution), 테스트 출력 예측(test output prediction) 같은 작업까지 넓혀 둬.
GitHub README 기준으로 데이터는 버전(version), 즉 서로 다른 문제 묶음으로 나뉘어. release_v1은 2023년 5월부터 2024년 3월까지의 400개 문제였고, release_v6는 2023년 5월부터 2025년 4월까지의 1055개 문제로 커졌어. 그래서 LiveCodeBench 80%라는 말만 있으면 부족해. release_v6인지, 특정 기간만 잘라 본 것인지, 코드 생성 평가인지까지 붙어야 같은 숫자로 비교할 수 있어.
대표 지표로는 pass@1을 자주 봐. 모델이 낸 첫 번째 답이 테스트를 통과한 비율로 읽으면 돼. 다만 실행 시간 제한, timeout, 샘플링 온도, 프롬프트 형식, 평가용 release가 바뀌면 같은 모델도 다르게 보일 수 있어.
왜 중요한가
코딩 모델은 예전 HumanEval이나 MBPP에서 높은 점수를 받는다고 실제 새 문제를 잘 푼다고 단정하기 어려웠어. 문제 수가 작거나 널리 퍼져 있으면, 모델이 문제를 이미 본 것처럼 행동할 수 있기 때문이야. 이 벤치마크는 새 문제와 날짜 필터로 그 약점을 줄이려고 만들어졌어.
모델 카드에서도 이 숫자가 점점 자주 나와. 예를 들어 Gemma-4-26B-A4B-NVFP4의 NVIDIA Hugging Face 카드에는 LCB pass@1이 BF16 baseline 80.50%, NVFP4 79.80%로 적혀 있어. 여기서 읽을 수 있는 건 “이 quantized checkpoint가 해당 모델 카드의 조건에서 코드 문제 정확도를 크게 잃지 않았다”는 정도야. 이 숫자만 보고 로컬 서버에서 같은 속도나 같은 제품 품질이 나온다고 보면 안 돼.
실무에서는 모델 후보를 거를 때 첫 번째 신호로 쓸 만해. 코딩 agent를 만들거나 사내 API 자동화에 붙일 모델을 고를 때, 이 점수가 낮으면 복잡한 코드 생성 루프에서 시작점이 약할 가능성이 있어. 그래도 마지막 판단은 사내 저장소, 사내 테스트, 실제 도구 호출 실패율로 다시 봐야 해.
주의해서 볼 점
LiveCodeBench는 계속 갱신되는 벤치마크라서 오래된 점수와 최신 점수를 한 줄에 놓으면 헷갈려. release_latest 같은 표현은 편하지만, 시간이 지나면 같은 명령이 다른 문제 묶음을 가리킬 수 있어. 발표 자료에서 release 버전이 빠져 있으면 숫자를 그대로 믿기보다 재현 조건을 먼저 찾아야 해.
또 하나는 벤치마크 종류를 섞어 읽는 문제야. LCB pass@1은 정해진 코드 문제를 얼마나 풀었는지 보는 값이고, AI Muninn 글의 52 tok/s 같은 숫자는 DGX Spark에서 vLLM으로 얼마나 빠르게 decode했는지 보는 처리량 값이야. 하나는 정답률이고 하나는 속도야. 같은 모델 이름 옆에 붙어 있어도 서로 대체하지 않아.
SWE-bench Verified와도 용도가 달라. SWE-bench Verified는 실제 GitHub 이슈를 고치고 패치를 통과시키는지를 보고, LiveCodeBench는 새 코딩 문제와 코드 관련 시나리오를 정해진 채점기로 평가해. 모델 발표를 읽을 때는 LiveCodeBench, SWE-bench, Terminal-Bench 같은 이름이 각각 어떤 작업을 묻는지 먼저 나눠 놓는 게 맞아.
실무 사용
- 모델 카드 해석: LCB 숫자를 보면
pass@1, release 버전, 평가 시나리오, 샘플링 조건을 같이 기록해. - 후보 압축: 여러 모델을 볼 때는 같은 release와 같은 프롬프트 조건의 점수만 비교해.
- 사내 검증: 외부 점수가 높아도 사내 코드베이스의 테스트, lint, 권한 있는 도구 호출, 긴 컨텍스트 입력을 따로 평가 절차(eval)로 만들어.
- 속도 비교 분리: LCB 점수와
tok/s, VRAM, KV cache 숫자는 표를 나눠 읽어. - 에이전트 도입 판단: 코드 생성 능력은 외부 코딩 벤치마크로 보고, 실제 작업 완결률은 SWE-bench류 또는 사내 이슈 해결 eval로 다시 봐.