AI 벤치마크 읽는 법: LLM 점수표에서 5분 안에 확인할 것

LLM의 성능을 평가하는 AI 벤치마크는 다음에 무엇을 테스트할지 판단하는 데 도움을 줘야 합니다. SWE-bench Verified는 선별한 소프트웨어 이슈 500개를 얼마나 잘 해결하는지 측정합니다. 점수가 높다고 해서 에이전트가 회사의 환불 정책까지 잘 따르는지는 알 수 없습니다. 가장 높은 점수부터 보기 전에 과제, 평가 환경, 채점 기준부터 확인해야 합니다.

2026년 10월 15일에 벤치마크 제작자의 공식 페이지와 Google 모델 카드를 대조해 확인했습니다. 아래의 벤치마크 설명은 각 시험이 무엇을 평가하는지 다루며, 해설에 사용한 점수는 Google이 공개한 결과입니다. 결과에 대한 해석과 평가 체크리스트는 필자가 작성했습니다.

코딩 어시스턴트를 고른다면 저장소나 터미널 과제부터 살펴봅니다. 고객 서비스 에이전트라면 대화 중 툴 사용과 정책 준수를, 문서 어시스턴트라면 긴 컨텍스트에서의 추론을 먼저 봅니다. 폭넓은 지식을 평가하는 점수는 판단을 보조할 수 있지만, 그 자체로 결정을 내려주지는 못합니다.

AI 벤치마크는 무엇을 측정하나요?

LLM 벤치마크(LLM benchmark)는 정해진 규칙에 따라 특정 과제 집합에서의 성능을 측정합니다. 지능 인증서보다는 스포츠 종목에 가깝습니다. 단거리 달리기 기록은 유용한 정보지만, 그 기록만으로 산악 구조에 누구를 보낼지 정할 수는 없습니다.

데이터셋에는 질문이나 과제가 담겨 있습니다. 평가 프로토콜은 모델에 무엇을 제공하고, 어떤 도움을 허용하며, 결과를 어떻게 채점할지 정합니다. 스캐폴드라고도 부르는 하네스는 모델을 둘러싼 소프트웨어로, 프롬프트와 툴, 실행 루프를 포함합니다.

신규 모델 발표에서 코딩 능력을 강조할 때 이 구분이 중요합니다. 짧은 프롬프트를 보고 함수를 작성하는 모델과, 저장소를 탐색하고 파일을 수정하며 테스트를 실행한 뒤 오류에서 복구하는 에이전트는 서로 다른 일을 합니다. 후자의 점수는 하네스를 포함해 실제로 작동한 시스템 전체의 성적입니다.

SWE-bench 리더보드는 공통 mini-SWE-agent 환경을 비롯해 평가 설정을 구분해서 보여줍니다. 실제 사용하는 코딩 제품은 툴이나 지침, 제약 조건이 다를 수 있습니다. 점수를 업무에 적용하기 전에 모델 주변에서 어떤 소프트웨어가 함께 실행됐는지 확인해야 합니다.

모델 출시 발표에 등장하는 벤치마크 이름들

점수를 비교하기 전에 벤치마크가 평가하는 과제와 실제 업무가 맞는지 확인합니다. 아래는 2026년 범용 모델, 코딩 모델, 음성 모델의 출시 발표에서 알아둘 벤치마크 계열과, 그 주장을 해석하는 데 필요한 컨텍스트 평가입니다. 각 벤치마크 이름에는 제작자의 공식 페이지나 저장소를 연결했습니다.

벤치마크 이름에는 버전을 항상 함께 적어야 합니다. HLE-Diamond는 정제한 문제 1,000개로 구성되며, 최종 확정된 원본 HLE는 2,500개입니다. Terminal-Bench 4.0은 자원과 과제를 변경했습니다. 현재 tau 저장소에는 새로운 모달리티와 채점 수정 사항이 함께 기록돼 있습니다. 이전 점수 옆에 놓인 최신 점수는 모델이 개선된 결과가 아니라 시험이 바뀐 결과일 수 있습니다.

우리 업무에는 어떤 점수가 중요한가요?

방지하려는 실패와 가장 가까운 벤치마크 계열을 선택합니다. AI 기능을 고르는 창업자, 에이전트 도입을 승인하는 CTO, 지원 티켓을 처리하는 운영 담당자가 출시 발표 표의 모든 행에 같은 비중을 둘 필요는 없습니다.

코딩 에이전트 벤치마크

기존 제품을 유지보수하는 개발자라면 저장소 수정과 터미널 작업부터 살펴봐야 합니다. SWE-bench는 이슈 해결 능력을, Terminal-Bench는 셸에서 작업을 수행하는 능력을 판단하는 데 유용한 근거입니다. LiveCodeBench와 HumanEval은 더 좁은 범위의 프로그래밍 능력을 파악하는 데 도움이 됩니다. 어느 하나만으로는 패치가 해당 코드베이스에서 유지보수하기 좋은지 알 수 없습니다.

혼자 제품을 만드는 개발자가 에이전트에게 계정 삭제 기능을 바꾸라고 요청한다고 가정해 봅니다. 올바른 보조 함수를 작성하는 것은 작업의 일부입니다. 에이전트는 영향을 받는 모든 호출 지점을 찾고, 권한 체계를 유지하며, 테스트를 갱신하고, 고객 레코드의 일관성이 깨지지 않도록 해야 합니다. 평가에도 이 변경 작업 전체를 포함하고, 실제로 제공할 저장소 접근 권한과 툴을 그대로 사용해야 합니다.

판단 기준: 여러 파일과 실행 단계를 거치는 업무라면 후보를 추리기 전에 에이전트 과제에서의 성능 근거를 요구합니다. 함수 단위 점수는 보조 자료로 활용합니다. 자체 사례에서 검토 범위를 줄여도 된다는 근거가 나오기 전까지는 코드 리뷰를 승인 절차에 유지합니다.

LLM 추론 벤치마크

GPQA, HLE, MMLU-Pro, AIME, ARC-AGI는 서로 다른 종류의 추론을 살펴봅니다. 특히 어려운 과학·수학 문제를 풀어야 하는 업무에서 무엇을 더 검토할지 알려주는 유용한 신호입니다. 하지만 회사의 운영 규칙을 잘 따르는지 보여주는 직접적인 근거를 대신하기에는 부족합니다.

GPQA Diamond의 198개 문제는 의도적으로 선별한 과학 문제 집합입니다. 내부 연구 어시스턴트를 검토하는 CTO라면 이 점수를 바탕으로 후보를 추린 뒤, 회사 내부 자료를 알아야 답할 수 있는 질문으로 테스트할 수 있습니다. 고객 지원 책임자라면 정책을 지키는 툴 사용과 상위 담당자 이관에 더 큰 비중을 둬야 합니다.

Humanity's Last Exam은 이름이 내세우는 포부와 실제 측정 대상을 구분해서 봐야 합니다. 제작자도 정답이 정해진 학술 문제의 성적과 자율 연구 능력을 명확히 구별합니다. 알려진 해답이 있는 어려운 문제에 답했다고 해서, 가치 있는 연구 문제를 선택하고 신뢰할 만한 근거를 모으며 자신의 오류를 알아차릴 수 있다는 뜻은 아닙니다.

긴 컨텍스트와 음성은 별도의 근거가 필요합니다

컨텍스트 윈도는 시스템이 얼마나 많은 입력을 받을 수 있는지를 나타내는 용량입니다. 긴 컨텍스트 평가는 그 입력으로 무엇을 할 수 있는지 묻습니다. 검색 평가는 정보를 찾아내는지 확인하고, 추론 평가는 정보를 연결하도록 요구합니다. RULER 제작자는 숨겨진 사실을 찾는 데 성공했다는 이유만으로 전반적인 긴 컨텍스트 성능을 판단해서는 안 되는 이유를 보여줍니다.

계약서를 검토하는 담당자에게 유용한 테스트는 부록의 예외 사항을 본문의 조항과 연결하고 둘 다 정확히 인용하는지 확인하는 것입니다. 답이 없거나, 이전 내용이 새 내용으로 대체됐거나, 서로 모순되는 문서도 포함해야 합니다. 양립할 수 없는 버전들을 자신 있게 합쳐 답하는 시스템은 각 구절을 제대로 검색했더라도 실패한 것입니다.

음성에서는 듣기, 추론, 말하기, 대화 제어를 분리해서 봅니다. FLEURS는 전사 평가에 참고할 수 있고, Big Bench Audio는 음성 질문을 바탕으로 한 추론을 다루며, VoiceBench는 여러 음성 지시 과제를 포괄합니다. 현재 tau 계열도 음성 상호작용을 평가합니다. 각각 측정하는 대상이 다릅니다.

전화 상담 파일럿에는 배경 소음, 이름, 끼어들기, 정정, 상담원 연결을 포함해야 합니다. 실제 대화를 듣고 마지막에 수행된 작업까지 확인합니다. 전사문은 올바르게 보여도 음성 대화는 답답하게 느껴질 수 있고, 엉뚱한 계정이 수정됐을 수도 있습니다.

LLM 성능 비교에서 따져야 할 것

도입을 판단할 때는 성능을 '업무 흐름의 제약 안에서 승인 기준을 충족한 작업'으로 정의합니다. 답변 품질, 완료의 신뢰성, 응답 시간은 별개의 요구 사항입니다. 많은 추론 자원을 쓴 벤치마크 실행은 밤새 진행하는 조사에는 적합한 근거가 될 수 있지만 실시간 고객 상담과는 잘 맞지 않을 수 있습니다.

구매 담당자는 필요한 세부 과제와 실제 제품 구성에서의 결과를 요구해야 합니다. 운영 담당자는 실패와 복구 과정을 살펴봐야 합니다. 개발자는 설정을 재현할 수 있어야 합니다. 판매자가 어떤 구성으로 평가했는지 밝힐 수 없다면, 그 점수는 운영 환경 도입을 결정하기에 충분한 근거가 아닙니다.

출시 발표의 점수표를 5분 안에 읽는 법

다음 5분 점검으로 새 모델을 더 깊이 평가할 가치가 있는지 판단합니다. 이는 점수표를 읽는 절차입니다. 이 시간만으로 모델이 해당 애플리케이션에서 안전하거나 유용하다고 검증할 수는 없습니다.

1. 1

   1분째: 필요한 작업을 정합니다

   저장소 이슈 해결, 고객 지원 요청 처리, 문서 기반 답변, 음성 통화 대응 등 필요한 결과를 적습니다. 그 작업과 닮은 행에 표시합니다. 관련 없는 분야의 우수한 성적은 도입 판단에서 제외합니다.

2. 2

   2분째: 정확히 어떤 시험인지 확인합니다

   벤치마크 버전, 하위 집합, 언어, 문제의 대상 기간을 기록합니다. Diamond, Verified, 오프라인, 텍스트 전용, 툴 사용 같은 조건을 찾습니다. 표기가 불완전하다면 해당 벤치마크의 공식 페이지를 확인합니다.

3. 3

   3분째: 실행 설정을 읽습니다

   하네스, 툴, 추론 설정, 허용 시간, 시도 횟수 정책을 찾습니다. 실제 제품에서도 같은 조건을 사용할지 따져봅니다. 검색 접근 권한, 코드 실행, 더 많은 재시도 허용 여부에 따라 점수의 의미가 달라질 수 있습니다.

4. 4

   4분째: 평가 지표를 해석합니다

   정확도는 정답으로 채점된 비율입니다. F1은 반환한 항목 중 올바른 항목의 비율과, 찾아야 할 항목 중 실제로 찾은 항목의 비율을 함께 고려합니다. 부분 점수는 과제를 완료하지 못해도 진척도에 점수를 줄 수 있습니다. 오류율은 낮을수록 좋습니다. 백분율을 업무 완료율로 받아들이기 전에 지표의 정의를 읽어야 합니다.

5. 5

   5분째: 누가 평가했는지 추적합니다

   모델 제작사, 벤치마크 운영자, 다른 평가자 중 누가 테스트를 실행했는지 확인합니다. 표 전체가 하나의 절차를 따랐다고 가정하지 말고 각 행의 각주를 읽습니다. 출처와 설정을 저장한 뒤 자체 테스트에 올릴 후보를 선택합니다.

이 절차를 마치면 짧은 판단 메모가 남아야 합니다. “관련 과제 계열이며, 현재 버전을 사용했고, 설정을 이해했으므로 자체 사례로 테스트할 가치가 있습니다.” 이 내용을 채울 수 없다면 잘 작동하는 시스템을 바꾸기 전에 빠진 정보를 기록합니다.

실제 사례: Google의 Gemini 4 Argon 점수표

Google의 범용 AI 모델인 Gemini 4 Argon은 여러 과제 계열과 채점 기준이 한 표에 섞여 있어 해석 연습에 좋은 사례입니다. 아래 행은 Google의 10월 모델 카드에 실린 결과를 옮긴 것으로, 2026년 10월 15일에 확인했습니다. 출처를 명시해 인용한 결과이며, 이 글을 위해 직접 측정한 값은 아닙니다.

각 값은 행 이름과 주석을 함께 읽어야 합니다. 이 백분율들은 분모도, 의미도 같지 않습니다.

BFS는 너비 우선 탐색으로, 깊이 순서대로 그래프의 연결을 따라가는 방식입니다. 토큰은 모델의 컨텍스트를 측정하는 단위이며, 단어와는 다릅니다.

결론을 내리기 전에 각주부터 읽습니다

Google의 평가 방법론에 따르면 Argon은 대체로 가장 높은 사고 설정과 pass@1을 사용하지만 예외도 있습니다. DeepSWE 결과에는 mini-swe 하네스를 사용했습니다. Terminal-Bench의 Argon 결과는 Google이 자체 산출했고, 비교 대상의 결과는 공식 리더보드에서 가져왔습니다. GraphWalks 결과는 모든 모델에 대해 자체 산출했습니다. OSWorld는 세 번 실행한 결과의 최댓값을 사용하며, 오프라인 부분 점수를 보고합니다.

여러 평가 방식이 섞여 있는 것이지, 모든 셀이 하나의 통제된 실험에서 나왔다는 근거가 아닙니다. 개발자라면 코딩 하네스가 도입하려는 에이전트와 닮았는지 확인해야 합니다. 구매 담당자라면 제안받은 애플리케이션 구성이 평가 근거와 일치하는지, 운영 담당자라면 해당 지표가 실제 완료된 결과에 점수를 주는지 살펴봐야 합니다.

필자의 계산: 공개된 GraphWalks F1 결과에서 99.7에서 84.2를 빼면 차이는 15.5%포인트입니다. 두 행은 길이가 다른 하위 집합을 사용했으므로, 이 뺄셈으로 동일한 질문에서 길이만 달라졌을 때의 인과 효과를 분리할 수는 없습니다. 다만 긴 문서 업무를 검토하면서 짧은 컨텍스트 행만 인용하면 관련 근거를 빠뜨리게 된다는 점은 보여줍니다.

컴퓨터 조작 점수도 구체적으로 해석해야 합니다. 부분 점수를 “에이전트가 우리 데스크톱 업무를 그 비율만큼 완료한다”는 뜻으로 바꾸어 읽으면 안 됩니다. 사람에게 작업을 넘겨주는 어시스턴트라면 부분적인 진척도 가치가 있을 수 있습니다. 반면 사람이 지켜보지 않는 프로세스에는 완전하고 정확한 결과에 대한 근거가 필요합니다.

모델별 도입 맥락은 Gemini 4 Argon 해설과 별도의 Gemini 4 Argon과 Opus 5.5 비교를 참고합니다.

높은 점수가 판단을 그르칠 수 있는 이유

높은 점수가 유효하더라도 정작 업무에서 묻는 질문에는 답하지 못할 수 있습니다. 먼저 한계를 짚고, 어떤 근거가 있어야 그 한계를 해소할 수 있는지 판단하는 것이 유용합니다.

데이터 오염과 특정 시험에 맞춘 최적화

데이터 오염은 평가 질문이나 정답이 학습 자료에 들어가는 현상입니다. 이 경우 모델은 처음 보는 문제를 푸는 대신 이전에 접한 내용을 활용해 이득을 얻을 수 있습니다. 공개된 시험 자체가 최적화 목표가 되기도 합니다. 같은 과제를 대상으로 프롬프트나 스캐폴드를 반복 조정하면, 새로운 검증 수단으로서 시험이 갖는 가치가 줄어듭니다.

LiveCodeBench는 공개 날짜가 있는 문제를 사용하므로 평가자가 학습 데이터 기준 시점 이후에 나온 과제를 선택할 수 있습니다. 이는 유용한 설계상의 장점입니다. 그렇다고 이름에 “Live”가 들어간 결과라면 무엇이든 오염되지 않았다고 가정해서는 안 됩니다. 실제로 어떤 기간의 문제를 사용했는지 확인해야 합니다. 의심스러울 만큼 큰 점수 상승은 부정행위의 증거로 단정할 일이 아니라, 평가 프로토콜을 살펴볼 계기로 삼아야 합니다.

자체 평가에서는 프롬프트 조정에 쓰지 않는 홀드아웃 세트를 유지합니다. 실패 사례를 개발용 예제로 활용하게 됐다면 홀드아웃에 새로운 사례를 추가합니다. 그렇지 않으면 시스템이 익숙한 예제에서는 뛰어나지만 다른 상황에서는 여전히 취약할 수 있습니다.

스캐폴딩이 달라지면 비교하는 시스템도 달라집니다

실행 환경은 중요합니다. 검색, 파일 툴, 재시도, 세심하게 작성한 지침을 갖춘 모델은 같은 모델이 단일 프롬프트에 답할 때와는 다른 운영 시스템입니다. 스캐폴딩 개선은 가치 있는 엔지니어링 성과일 수 있습니다. 잘못은 그 결과 전체를 기반 모델만의 성과로 돌리는 데 있습니다.

모델 변경의 효과만 분리해 보려면 공통 하네스를 사용합니다. 완성된 제품끼리 선택하려면 제품 전체를 평가합니다. 서로 다른 질문이므로 다른 결론이 나와도 타당합니다.

제조사 자체 평가도 유용하지만 독립 재현과는 구분해야 합니다

제작사의 결과는 방법이 명확할 때 유용하고, 벤치마크 운영자의 결과는 평가 구성이 비교 목적에 맞을 때 유용합니다. 어느 쪽이든 누가 평가했다는 사실만으로 프로토콜을 읽는 일을 대신할 수는 없습니다. 리더보드에 제출된 결과와, 공통 조건에서 독립적으로 다시 실행한 결과를 구분해야 합니다.

프롬프트, 모델 식별자, 하네스, 채점 방식, 제외 항목, 불확실성을 확인합니다. 변동성에 관한 정보가 충분하지 않다면 작은 점수 차이로 전환을 결정해서는 안 됩니다. 결과가 빠져 있다면 근거가 없는 것이지, 자동으로 0점이라는 뜻은 아닙니다.

집계 방식도 살펴봅니다. 전체 평균에는 평가자가 선택한 과제와 가중치가 반영됩니다. 실제 고객 지원 대기열에는 평균에 거의 영향을 주지 않는 예외 사례가 많을 수 있습니다. 서로 관련 없는 벤치마크의 백분율을 평균 내어 자체적인 지능 점수로 만들지 않아야 합니다.

채점이 정확해도 엉뚱한 결과를 측정할 수 있습니다

단위 테스트, 정답표, 모델 평가자, 사람의 선호는 각각 다른 대상에 점수를 줍니다. 테스트 범위가 결함을 놓칠 수 있고, 정답표에 오류가 있을 수 있으며, 모델 평가자가 올바른 행동보다 유창한 설명을 선호할 수 있습니다. 선호도 평가의 승리는 해당 절차에서 응답자들이 무엇을 선호했는지를 측정한 결과입니다.

현재 tau 저장소에는 과제와 채점의 수정 내역이 기록돼 있습니다. 이러한 수정은 평가를 개선하는 동시에 버전 추적을 필수로 만듭니다. 시험은 계속 관리해야 하는 측정 시스템이며, 의심할 수 없는 진실의 출처는 아닙니다.

자체 LLM 평가는 언제 필요한가요?

의사결정이 회사의 데이터, 정책, 툴, 사용자, 실패 허용 수준에 달려 있다면 자체 평가를 실행해야 합니다. 공개 점수는 가능성 있는 후보를 찾는 데는 충분합니다. 하지만 고객 레코드를 수정하거나 비공개 문서에 근거해 답하는 에이전트를 승인하기에는 부족합니다.

관련 벤치마크의 개선이 현재 시스템에서 이미 알려진 실패를 해결할 가능성을 보여준다면 지금 평가에 착수합니다. 해당 실패 유형을 대상으로 조건을 통제해 비교합니다. 개선된 부분이 업무와 무관하거나 공개 평가의 설정을 실제 제품에서 사용할 수 없다면 전환을 보류합니다. 현재 시스템이 이미 승인 기준을 충족하고 새 후보가 관련 성능의 개선을 보여주지 못했다면 현재 시스템을 유지합니다.

중견기업 고객 지원팀이라면 실용적인 초기 파일럿을 50개 사례로 구성할 수 있습니다. 일반 요청 20개, 정책 예외 10개, 누락되거나 모순된 입력 10개, 권한 또는 상위 담당자 이관 사례 10개입니다. 이는 설계를 위한 권장 구성일 뿐, 이 표본이 배포 판단에 통계적으로 충분하다는 주장은 아닙니다. 탐지해야 할 실패율과 차이에 맞춰 최종 규모를 정합니다.

후보를 실행하기 전에 성공 조건부터 정의합니다. 환불 사례라면 대상 여부를 올바르게 판단하고, 계정과 금액이 정확하며, 승인되지 않은 행동을 하지 않고, 명확히 설명해야 한다는 조건을 둘 수 있습니다. 이관 사례는 에이전트가 요청을 직접 해결하지 못했더라도 올바르게 담당자에게 넘겼다면 통과해야 합니다.

실제 사용할 프롬프트, 검색, 툴, 권한으로 각 후보를 실행합니다. 마지막 메시지만 보지 말고 최종 레코드와 행동 기록을 확인합니다. 결과가 불안정한 사례는 반복 실행하고, 지연 시간은 별도로 추적하며, 평가가 엇갈리는 사례를 검토한 뒤 개선 여부를 판단합니다. 최종 결정을 위한 홀드아웃 세트를 유지합니다.

Promptfoo는 테스트 사례와 검증 조건을 기준으로 프롬프트, 모델, 애플리케이션을 비교하는 평가 툴입니다. 공식 문서에서는 실행 방식을 설명합니다. Promptfoo 리뷰에서는 어떤 상황에 적합하며 사용자가 여전히 책임져야 할 부분은 무엇인지 다룹니다.

선택한 계정이나 금지된 행동의 실행 여부처럼 직접 확인할 수 있는 사실에는 결정론적 검사를 사용합니다. 설명이 충분하고 근거가 있는지처럼 판단이 필요한 품질에는 평가 기준표를 사용하고, 사람이 부여한 라벨에 맞춰 보정합니다. LLM-as-a-judge 가이드는 이러한 채점 과정과 실패 유형을 다룹니다.

월요일에 바로 할 일: 업무 흐름 하나를 선택하고, 승인 기준을 적고, 최근 사례를 모은 뒤, 같은 조건에서 현재 시스템과 후보 하나를 비교합니다. 사용자에게 중요한 결과와 실패를 기준으로 배포 여부를 결정합니다.

벤치마크 점수표에 관해 자주 묻는 질문

대표적인 LLM 벤치마크에는 무엇이 있나요?

먼저 계열을 구분합니다. 코딩 에이전트에는 SWE-bench와 Terminal-Bench, 학술 질문에는 GPQA와 Humanity's Last Exam, 대화 중 툴 사용에는 tau 계열이 있습니다. 긴 컨텍스트와 음성에는 별도의 시험이 있습니다. 점수마다 버전과 설정을 함께 기록해야 합니다.

코딩 평가에 가장 적합한 LLM 벤치마크는 무엇인가요?

실제 과제와 가장 가까운 벤치마크를 사용합니다. SWE-bench는 저장소 이슈 해결, Terminal-Bench는 터미널 작업, HumanEval은 함수 생성을 다룹니다. LiveCodeBench에는 공개 시점이 명시된 경진대회 과제가 포함됩니다. 그 근거를 실제 업무에 적용할 수 있는지는 자체 저장소의 변경 작업으로 판단합니다.

LLM 벤치마크 데이터셋이란 무엇인가요?

데이터셋은 질문이나 과제를 제공합니다. 서로 비교할 수 있는 벤치마크 결과를 얻으려면 프롬프트, 툴, 제한 조건, 시도 횟수, 채점 방식 등 평가 프로토콜도 필요합니다. 데이터셋 이름이 같다는 사실만으로 두 결과가 비교 가능하다고 볼 수는 없습니다.

AI 평가와 도입에 관한 실무 가이드를 받아보려면 뉴스레터를 구독하세요.