1. 서론

생성형 AI의 새로운 모델이 발표될 때마다 다양한 벤치마크 결과가 공개된다.

"대학 입학 공통 테스트에서 만점을 받았다"

"TOEIC에서 만점에 상당하는 점수를 기록했다"

"수학 벤치마크에서 기존 모델을 상회했다"

"코딩 벤치마크에서 최고 점수를 경신했다"

이러한 숫자들은 이해하기 쉽다. 모델들을 하나의 표에 나열할 수 있고, 어느 쪽이 더 우수한지를 짧은 말로 설명할 수 있다. 그렇기 때문에 생성형 AI를 이용하는 IT 엔지니어 중에서도 벤치마크 순위를 강하게 신경 쓰는 사람이 적지 않다. 물론 벤치마크가 무의미한 것은 아니다. 모델의 대략적인 능력 차이를 알거나, 어느 분야가 진보하고 있는지를 관찰하는 데에는 도움이 된다. 하지만 여기서 주의해야 할 점이 있다.

같은 모델이라 하더라도 입력의 표현, 지시, 주어진 정보, 이용 가능한 도구, 시도 횟수, 채점 방법에 따라 점수는 변화한다. 최근의 연구에서도 벤치마크의 프롬프트 민감도(Prompt Sensitivity), 문제 형식, 데이터 누출(Data Leakage), 평가 하네스(Evaluation Harness), 실행 환경, 채점 모델, 측정 오차 등이 명확하게 문제 제기되고 있다.

본고에서는 생성형 AI의 벤치마크가 무엇을 하고 있는지를 수리적으로 정리하고, IT 엔지니어가 그 점수를 어떻게 읽어야 하는지를 생각한다.

2. 애초에 벤치마크는 무엇을 하고 있는가

전형적인 벤치마크에서는 문제와 정답의 쌍을 모은 데이터셋을 준비한다.

여기서,

$D = ext{{(q_i, a_i)}}_{i=1}^N$

이다.

모델 $M$이 문제 $q_i$에 대해 생성한 답변을 채점 함수 $f$가 채점한다.

예를 들어 정답이면 1, 오답이면 0이라고 한다면, 벤치마크 점수는 다음과 같이 된다.

$S(M) = \frac{1}{N} \sum_{i=1}^N f(M(q_i), a_i)$

언뜻 보면 이 식은 모델 $M$의 고유한 능력만을 나타내는 것처럼 보인다. 하지만 문제의 전후에는 시스템 프롬프트(System Prompt)나 지시문이 부가되며, 출력 형식이 지정된다. 경우에 따라서는 검색, 코드 실행, 테스트, 파일 조작 등의 도구도 주어진다. 나아가 temperature(생성 랜덤성을 제어하는 온도 파라미터), 추론 토큰 수, 재시도 횟수, 에이전트의 제어 방법도 결과에 영향을 미친다.

따라서 실제 답변은 다음과 같이 쓰는 것이 더 정확하다.

$y_i = M(q_i, P, T, ext{tools}, ext{etc.})$

여기서,

$P$는 프롬프트(Prompt) 등을 의미한다.

채점 방법에도 조건이 있다.

$c = f(y_i, a_i, ext{criteria})$

여기서 $c$는 채점 기준을 나타낸다.

즉,

$S(M) = \frac{1}{N} \sum_{i=1}^N f(M(q_i, P, T, ext{tools}, ext{etc.}), a_i, c)$

이다.

3. 벤치마크 점수는 「능력」이 아니라 「조건부 관측값」이다

모델의 능력을 직접 관측할 수 있는 것은 아니다. 우리가 관측할 수 있는 것은 특정 조건을 주었을 때 생성된 출력과 그 출력에 대한 채점 결과뿐이다. 이는 물리학에서 대상 그 자체와 측정 결과를 구별하는 것과 비슷하다. 측정 결과에는 대상의 성질뿐만 아니라 다음과 같은 요소가 포함된다.

• 측정 장치
• 측정 방법
• 초기 조건
• 외부 환경
• 측정 오차

생성형 AI의 벤치마크도 마찬가지다.

모델을 $M$, 환경(조건)을 $C$라고 하면, 우리가 얻는 점수는 $S(M, C)$이다.

따라서 어떤 모델이 벤치마크에서 80점을 받았다고 하더라도, 그것은 $S(M, C) = 80$임을 의미할 뿐, 모델 $M$의 절대적인 능력치가 80이라는 뜻은 아니다.

이 부분을 생략해 버리면 벤치마크 점수가 모델에 내재된 고정적인 능력치인 것처럼 보이게 된다.

4. 모델의 능력은 하나의 숫자가 아니다

애초에 생성형 AI의 능력을 하나의 스칼라(Scalar)로 나타낼 수 있을까? 실제로는 모델의 능력이 다차원이라고 생각하는 것이 자연스럽다.

여기서는 설명을 위해 모델의 능력을 여러 잠재적인 능력 성분으로 구성된 벡터로 나타낸다. 이는 실제 능력이 이 8개 항목으로 일의적으로 분해될 수 있음을 의미하는 것은 아니다. 모델의 능력 $V_M$을 다음과 같이 정의하자.

$V_M = [v_1, v_2, ext{..., } v_8]^ op$

각 성분은 다음과 같은 능력을 나타낼 수 있다.

• 언어 이해
• 지식
• 추론
• 코딩
• 장문맥 유지 (Long Context Retention)
• 도구 이용
• 입력 변동에 대한 강건성 (Robustness)
• 지적 후 수정 능력

벤치마크 점수 $S$는 모델의 능력 벡터 $V_M$과 벤치마크의 특성을 나타내는 가중치 벡터 $W$의 내적으로 표현할 수 있다.

$S = V_M \cdot W$

여기서 $W$는 각 능력 성분에 대한 중요도를 나타낸다.

TOEIC형 시험이라면 언어 이해나 어휘, 독해에 큰 가중치가 붙는다.

반면, 기존 업무 시스템을 개수하는 능력에서는 다음과 같은 항목에 가중치가 붙는다.

• 리포지토리 이해
• 의존 관계 파악
• 업무 제약 사항 유지
• 여러 파일 간의 정합성
• 테스트 실행
• 에러 수정
• 의미 불일치 억제

일반적으로, 특정 벤치마크의 가중치 벡터 $W$는 특정 방향을 향한다.

따라서, "$S_{\text{TOEIC}}(M)$이 높다"는 사실로부터 "$S_{\text{SWE}}(M)$도 높다"라고 말할 수는 없다. TOEIC 만점이나 대학 입학 공통 테스트 만점은 해당 시험이 측정하고 있는 방향으로의 능력이 높다는 것을 나타낸다. 하지만 그것이 생성형 AI가 업무 시스템 개발에 적합하다는 증거는 아니다.

5. 같은 의미라도 질문 방식을 바꾸면 점수가 변한다

2025년의 연구에서는 LLM이 프롬프트의 미세한 표현 차이에 민감하다는 점이 다시 한번 밝혀지고 있다.

2025년의 Benchmarking Prompt Sensitivity in Large Language Models [1] 연구는 TriviaQA와 HotpotQA를 바탕으로, 원래의 정보 요구 사항을 유지하면서 프롬프트 표현을 변화시킨 PromptSET을 구축했다. 해당 연구에서는 미세한 표현 변경만으로도 정답 여부가 달라지며, 어떤 표현에서 올바르게 답변할 수 있는지를 사전에 예측하는 것 자체도 어렵다고 보고하고 있다.

또한, On Robustness and Reliability of Benchmark-Based Evaluation of LLMs [2]는 6종류의 일반적인 벤치마크에 대해 모든 문제를 바꾸어 표현(paraphrasing)하여 34개의 모델을 평가했다.

그 결과, 모델 간의 상대적인 순위는 비교적 안정적이었던 반면, 절대적인 점수는 유의미하게 하락했다. 고정된 문제문에서 얻은 고득점이 현실의 언어적 변동에 대한 강건성(Robustness)을 충분히 나타내지 못할 가능성이 지적되고 있다.

동일한 의미를 유지하는 프롬프트 템플릿의 집합을 $\mathcal{P}$라고 하자. 각 문제 $x \in \mathcal{D}$에 대하여,

(수식 생략)

이하에서는 프롬프트 이외의 평가 조건은 고정되어 있다고 가정한다. 더 정확하게는, 각 프롬프트에서의 기대 점수를 $E(x, p)$라고 정의했을 때, 의미가 같다면

$p_1, p_2 \in \mathcal{P} \implies E(x, p_1) = E(x, p_2)$

가 되는 것이 바람직하다. 하지만 실제로는 프롬프트의 미세한 차이에 의해 큰 차이가 발생할 수 있다.

따라서 단일 프롬프트에서의 점수뿐만 아니라, 데이터셋 전체에서 의미를 보존한 프롬프트 변종들에 대한 평균 성능을 고려해야 한다.

나아가 프롬프트에 의한 불안정성을 분산(Variance)으로 나타낸다.

예를 들어 두 모델의 평균 점수와 표준 편차가 다음과 같다고 가정하자.

모델 A: $\mu_A = 80, \sigma_A = 2$
모델 B: $\mu_B = 75, \sigma_B = 10$

평균 점수만 본다면 모델 A가 더 높다. 하지만 실무에서 입력 표현이 일정하지 않다는 점을 고려하면, 모델 B가 더 안정적으로 사용될 가능성이 있다. 기존의 리더보드(Leaderboard)에서는 평균 점수나 단일 조건에서의 점수만 강조되어, 이러한 분산은 거의 보이지 않는다.

6. 문제 형식을 바꾸면 측정하는 능력도 바뀐다

객관식(Multiple-choice)은 채점이 용이하다. 정답 선택지와 모델의 답변을 비교하기만 하면 되므로 대규모 자동 평가에 적합하다. 하지만 객관식으로 정답을 맞히는 것과 선택지 없이 답변을 생성하는 것은 동일하지 않다.

2025년의 Answer Matching Outperforms Multiple Choice for Language Model Evaluation [3]는 MMLU-Pro와 GPQA-Diamond을 사용하여 객관식 평가와 자유 응답식(Free-response) 평가를 비교했다.

해당 연구에서는 일부 객관식 문제가 문제문을 보지 않고도 선택지의 특징만으로 답변할 수 있는 가능성을 보여주었으며, 자유 응답을 참조 답변과 대조하는 Answer Matching 방식으로 변경했을 때 여러 모델의 순위가 크게 변화했다고 보고했다.

객관식에서는 $P(y \in \text{Choices} | x)$가 된다.

자유 응답에서는 $P(y = \text{Ground Truth} | x)$이다.

전자는 정답 후보가 이미 입력에 포함되어 있다. 후자는 모델 스스로 답변을 구성해야 한다. 따라서 두 방식이 요구하는 능력은 다르다.

대학 입시나 자격시험에서 고득점을 받았다는 사례를 볼 때도 다음과 같은 사항을 확인할 필요가 있다.

• 선택지가 주어졌는가
• 자유 기술 방식이었는가
• 외부 도구를 이용했는가
• 재시도가 허용되었는가
• 최종 답변만을 평가했는가
• 추론 과정도 평가했는가

7. 기술 벤치마크에는 데이터 누출(Data Leakage) 문제가 있다

생성형 AI는 방대한 양의 공개 데이터를 학습한다. 따라서 공개된 코드 문제, GitHub 리포지토리, LeetCode 등으로 작성된 벤치마크는 학습 데이터에 포함되어 있을 가능성이 있다.

2025년의 LessLeak-Bench [4]는 83종류의 소프트웨어 공학 벤치마크를 대상으로 데이터 누출을 조사했다. 전체 평균 누출률은 비교적 낮았으나, QuixBugs에서는 100%, BigCloneBench에서는 55.7%라는 높은 누출률이 보고되었으며, 누출이 모델 평가에 큰 영향을 미친다는 점도 확인되었다. 연구에서는 벤치마크 데이터가 학습 데이터에 직접 포함되거나, LeetCode와 같은 코딩 플랫폼에서 문제를 구축하는 것이 주요 원인으로 꼽혔다.

단순화하여 벤치마크 데이터를 처음 보는 문제 집합 $\mathcal{D}_{test}$라고 하자.

관측된 점수는 $E[f(x) | x \in \mathcal{D}_{test}]$라고 생각할 수 있다. 여기서 이 점수가 다음 중 무엇인지 판별하기 어려워진다.

• 미지의 문제를 일반화하여 풀었는가
• 학습된 해법 패턴을 재현했는가
• 문제나 답변 그 자체를 기억하고 있었는가

이는 '모델이 답을 맞혔다'는 사실 자체를 부정하는 것은 아니다. 하지만 '미지의 기술적 과제에도 동일하게 대응할 수 있다'는 일반화 능력의 증명은 될 수 없다.

8. 합성 문제를 풀 수 있다고 해서, 실제 코드를 작성할 수 있는 것은 아니다

코딩 벤치마크(Coding Benchmark)에는 짧은 함수를 구현하게 하는 형식이 많다. 이러한 문제는 채점하기 쉽다. 입력값과 기대 출력값을 준비하고, 단위 테스트(Unit Test)를 통과하는지 확인하면 되기 때문이다. 하지만 실제 소프트웨어 개발은 짧은 함수를 생성하는 것만이 아니다. 기존 프로젝트에서는 다음과 같은 요소들을 고려해야 한다.

• 클래스 간의 의존성 (Dependency)
• 타입 (Type)
• 프레임워크의 규약 (Framework Convention)
• 데이터베이스 구조 (Database Structure)
• 기존 코드의 설계 의도 (Design Intent)
• 암묵적인 업무 규칙 (Implicit Business Rules)
• 다른 기능에 미치는 부작용 (Side Effect)

2025년의 Beyond Synthetic Benchmarks [5]는 기존의 합성 벤치마크와, 실제 오픈 소스 프로젝트에서 작성한 클래스 단위의 과제를 비교했다.

평가 대상 모델은 기존 합성 벤치마크에서는 8489%의 정답률을 보였던 반면, 실제 프로젝트 유래의 클래스 구현에서는 약 2534%로 하락했다. 실제 코드에서는 AttributeError나 TypeError 등, 의존 관계, 속성, 타입과 관련된 실패가 전면에 나타났으며, 합성 문제와는 다른 실패 구조가 관찰되었다. 이는 단순히 벤치마크가 어렵거나 쉽다는 차원의 문제가 아니다.

벤치마크의 문제 분포를

실무상의 기대 손실은,

이며, 일반적으로,

이고, 채점 기준 또한,

이다. 따라서, " 로부터, " R_U(M) 도 작지 않다.

양자의 손실을 비교 가능한 동일 척도로 정규화했을 때, 이 차이를 $\Delta$라고 두면, 벤치마크와 실운용 사이의 괴리를 나타내는 하나의 사고방식이 된다. 이 값이 양수이며 클수록, 벤치마크에서 추정된 성능보다 실운용상의 손실이 더 크다는 것을 의미한다.

9. 코딩 능력은 「모델 + 하네스(Harness)」의 능력이다

현재의 코딩 AI는 단순히 모델에 문제문을 입력하고 코드를 한 번 생성하게 하는 것이 아니다. 대부분의 경우, 코딩 에이전트(Coding Agent)는 다음과 같은 일련의 처리를 수행한다.

• 리포지토리(Repository)를 검색한다
• 관련 파일을 선택한다
• 기존 코드와 의존 관계를 읽어 들인다
• 수정할 부분을 추정한다
• 코드를 다시 쓴다
• 테스트나 빌드(Build)를 실행한다
• 에러 내용을 읽는다
• 수정을 반복한다
• 최종적인 패치(Patch)를 제출한다

이때 성능을 결정하는 것은 기반 모델(Foundation Model)뿐만이 아니다. 모델이 아무리 고성능이라 하더라도, 필요한 정보에 도달할 수 없다면 적절한 수정을 할 수 없다. 반대로 모델 단독으로는 능력이 다소 낮더라도, 탐색(Search), 컨텍스트 구축(Context Construction), 도구 실행(Tool Execution), 에러 복구(Error Recovery)가 적절히 설계되어 있다면 에이전트 전체로서 높은 성능을 보이기도 한다. 구체적으로는 다음과 같은 하네스(Harness) 설계가 결과에 영향을 미친다.

• 어떤 파일을 검색 대상으로 할 것인가
• 검색 결과를 어떻게 순위 매길 것인가
• 몇 개의 파일을 컨텍스트에 포함할 것인가
• 긴 코드나 실행 이력을 어떻게 압축할 것인가
• 도구의 실행 결과를 어떤 형식으로 모델에게 돌려줄 것인가
• 모델이 인식하는 작업 상태와 실제 파일 상태를 어떻게 일치시킬 것인가
• 테스트 실패 시 몇 회까지 재시도할 것인가
• 어느 시점에서 수정 방침을 재검토할 것인가
• 모델에게 어떤 권한을 부여할 것인가
• 최종 결과물을 어떻게 검증할 것인가

여기서 말하는 하네스란 단순히 모델을 호출하기 위한 얇은 래퍼(Wrapper)가 아니다. 모델과 리포지토리, 검색 기구, 컨텍스트 관리, 코드 편집, 테스트 실행, 상태 관리, 재시도 제어, 결과물 검증을 연결하여 모델의 출력을 실제 개발 작업으로서 성립시키기 위한 시스템 전체를 의미한다.

2026년의 Harness-Bench [8]는 현실적인 에이전트 작업을 대상으로, 여러 모델과 여러 하네스의 조합을 비교했다. 106건의 태스크와 5,194건의 실행 궤적(Trajectory)을 분석한 결과, 완료율뿐만 아니라 작업 과정, 효율, 실패 방식 또한 모델과 하네스의 조합에 따라 크게 변화했다. 해당 연구는 에이전트 능력을 기반 모델에만 귀속시키지 말고, model–harness configuration, 즉 모델과 하네스의 구성 단위로 보고해야 한다고 제안한다.

여기서 중요한 점은 하네스가 모델 능력을 보조하는 부수적인 구현이 아니라는 것이다. 코딩 에이전트에서는 하네스의 차이에 따른 성능 차이가 기반 모델의 차이에 따른 성능 차이에 필적하는 경우가 있다. 즉, 더 새롭고 고성능인 모델로 교체하는 것만이 에이전트 전체의 성능을 향상시키는 방법은 아니다.

같은 모델을 사용하더라도,

• 필요한 파일에 도달할 수 있는지
• 관련 없는 정보를 컨텍스트에서 제외할 수 있는지
• 툴 실행 결과를 다음 추론에 올바르게 반영할 수 있는지
• 작업 중인 상태와 모델의 인식이 일치하는지
• 테스트 실패 원인을 다음 수정에 연결할 수 있는지
• 실패한 방침에 고집하지 않고 탐색을 다시 시작할 수 있는지
• 최종 결과물을 검증 가능한 형태로 추출할 수 있는지

이러한 요소들에 따라 결과는 크게 달라진다. 이 의미에서, 코딩 에이전트의 성능은 단순한 모델의 함수가 아니라,

로 표현하는 것이 더 자연스럽다. 여기서,

이다.

이 공식이 나타내는 것은, 코딩 에이전트의 벤치마크가 단순히 모델의 코드 생성 능력만을 측정하고 있는 것이 아니라는 점이다.

평가되고 있는 것은, 모델을 실제 개발 작업에 연결하여 탐색(exploration), 이해(understanding), 편집(editing), 실행(execution), 검증(verification), 수정(correction)을 성립시키는 시스템 설계 전체이다.

코딩 에이전트의 벤치마크 결과를 보고,

더 나아가, 모델과 하네스 사이에는 상호작용이 있다. 이하에서는 이 상호작용에 주목하기 위해 컨텍스트, 툴 구성, 추론 예산(inference budget), 채점 방식 등 다른 평가 조건을 고정하고 시스템 전체의 성능을 단순화하여,

두 개의 모델

이었다고 하더라도, 다른 하네스

일 필요는 없다. 더욱이 말하자면,

처럼, 하네스를 변경하면 모델의 순위 자체가 역전되는 것도 생각할 수 있다. 이는 특정 모델에 적합한 탐색 방법, 컨텍스트 구축, 툴 제시 형식, 재시도 제어가 다른 모델에도 똑같이 적합하다고 할 수 없기 때문이다. 모델에 따라,

• 긴 컨텍스트를 폭넓게 제공하는 것이 좋은지
• 필요한 정보만 엄선하는 것이 좋은지
• 세밀한 절차를 지시하는 것이 좋은지
• 자율적으로 탐색하게 하는 것이 좋은지
• 오류를 그대로 반환하는 것이 좋은지
• 구조화하여 요약하는 것이 좋은지

와 같은 차이가 있다.

따라서, 리더보드를 볼 때는, 거기서 비교되고 있는 것이,

• 기반 모델(Foundation Model)끼리인지
• 에이전트 제품끼리인지
• 모델과 하네스의 조합인지
• 컨텍스트 관리나 툴 구성을 포함하는 시스템끼리인지
• 추론 예산이나 재시도 횟수까지 포함하는 운용 구성끼리인지

를 확인해야 한다.

코딩 에이전트의 점수는 모델에서 직접 도출된 능력치가 아니다. 모델을 개발 작업에 연결하는 여러 처리를 거쳐, 시스템 전체가 만들어낸 결과로서 관측된다. 이 관점에 서면, 코딩 AI의 성능 향상은 단순히 '더 똑똑한 모델을 선택한다'는 문제가 아니게 된다. 그것은,

• 어떤 정보를 제공할지
• 어떤 툴을 이용하게 할지
• 어떤 상태를 유지할지
• 어떤 실패를 감지할지
• 어디서 재시도하게 할지
• 어떤 결과물을 인간이 검증할지

를 설계하는, 시스템 설계상의 문제이기도 하다.

따라서, 코딩 에이전트의 벤치마크는, 모델의 우열을 보여주는 순위표일 뿐만 아니라, 모델을 둘러싼 시스템 설계가 어느 정도 기능하고 있는지를 관측하는 평가로서 읽어야 한다.

10. 한 번 성공한 것과, 안정적으로 쓸 수 있는 것은 다르다

많은 벤치마크에서는, 한 번의 시도에 성공했는지 여부를 평가한다. 그러나 실무에서 중요한 것은 한 번 성공하는 것이 아니다.

• 반복 실행해도 성공하는지
• 입력 표현을 조금 바꿔도 성공하는지
• API 장애가 발생해도 회복할 수 있는지
• 긴 대화에서도 제약을 유지할 수 있는지
• 수정 요구를 추가해도 기존 기능을 망가뜨리지 않는지

와 같은 신뢰성이 필요하다.

2026년의 ReliabilityBench [6]는, 툴을 이용하는 LLM 에이전트에 대해, 반복 실행, 의미를 보존한 입력 변동(input perturbation), 툴 장애를 결합한 신뢰성 평가를 제안했다.

해당 연구에서는, 통상 조건에서

단발의 성공 확률을

로 한다. 예를 들어,

실무에서는 평균 점수뿐만 아니라,

• 최악 시 성능(worst-case performance)
• 분산(variance)
• 재시도 횟수
• 실패로부터의 회복
• 실패 감지율(failure detection rate)

도 평가해야 한다.

11. 벤치마크에는 보이지 않는 측정 오차가 있다

벤치마크 점수에는 다양한 변동 요인이 포함된다. 평가 조건을 독립적인 랜덤 효과로 근사하고, 각 조건에 대해 균형 잡힌 반복 평가를 수행한다고 가정하면, 점수 추정량의 분산은 개념적으로 다음과 같이 분해될 수 있다.

여기서,

이다. 실제로는 각 요인이 독립적이지 않으며, 모델과 프롬프트, 모델과 하네스 등의 상호작용이나 공분산도 존재한다. 이 공식은, 점수의 불확실성이 문제 수만으로는 결정되지 않는다는 것을 보여주기 위한 개념적인 분해이다.

일반적인 통계적 신뢰 구간 (Confidence Interval)은 주로 문제 항목의 샘플링 오차 (Sampling Error)를 다룬다. 하지만 프롬프트 (Prompt)를 하나로 고정하고, 채점 모델을 하나로 고정하며, temperature를 하나로 고정하고 있는 경우, 그 선택에 따른 불확실성은 신뢰 구간에 포함되지 않을 수 있다.

2026년의 Decomposing and Reducing Hidden Measurement Error in LLM Evaluation Pipelines [7]는 프롬프트의 재진술 (Paraphrasing), 채점 모델의 변경, temperature의 변경에 의해 순위나 연구상의 결론이 역전될 수 있다고 지적한다.

또한, 일반적인 신뢰 구간은 이러한 파이프라인 유래의 분산 (Variance)을 포착하지 못하며, 문제 수를 늘려도 해소되지 않는 측정 오차가 남는다고 논한다. 해당 연구에서는 MMLU에서 평가 예산의 배분을 변경함으로써, 동일 비용의 단일 프롬프트 평가보다 추정 오차를 절반으로 줄였다고 보고하고 있다.

문제 수

즉, 문제 수가 많다고 해서 그 평가가 반드시 신뢰할 수 있는 것은 아니다.

12. 벤치마크에서의 「의미 불일치」

벤치마크에는 또 하나의 중요한 문제가 있다. 그것은 벤치마크가 측정하고 있는 능력과 사용자가 알고 싶어 하는 능력이 일치하지 않을 가능성이다.

예를 들어, IT 엔지니어가 알고 싶은 것은 이 모델이 실제 개발 현장에서 도움이 되는가 하는 것이다. 하지만 벤치마크가 측정하고 있는 것이 객관식 프로그래밍 문제에 정답을 맞힐 수 있는가뿐이라면, 양자의 의미는 일치하지 않는다.

이 문제를 제4장에서 도입한 능력 공간 (Capability Space)의 벡터를 사용하여 정리해 본다. 벤치마크 점수에 각 능력이 어느 정도 반영되는지를 나타내는 비음수 가중치 벡터를

또한, 이 정합도는 가중치의 방향만을 비교하는 것이며, 실무에서 요구하는 능력 수준의 높음 그 자체를 나타내는 것은 아니다.

TOEIC형 시험과 기존 업무 시스템의 개수는 능력 공간상의 가중치 설정이 크게 다르다. 따라서 TOEIC형 시험에서의 고득점을 통해 기존 업무 시스템 개수에서의 유용성을 직접 추론할 수는 없다.

이 상태에서 고득점을 얻더라도 사용자가 원하는 능력이 높다는 것을 의미하지는 않는다. 이는 단순한 정밀도의 문제가 아니다.

예를 들어 체온계가 매우 정확하더라도 혈압을 알고 싶은 사람에게는 도움이 되지 않는다. 마찬가지로 TOEIC형 문제로 언어 능력을 정확하게 측정하더라도, 복잡한 기존 시스템의 개수 능력을 알고 싶은 IT 엔지니어에게는 그것만으로는 불충분하다.

13. 그럼에도 벤치마크는 무엇에 도움이 되는가

여기까지 읽으면 벤치마크가 의미가 없는 것처럼 보일지도 모른다. 하지만 그렇지 않다. 벤치마크는 올바르게 사용한다면 충분히 도움이 된다.

13.1 모델 선택의 첫 번째 필터

기초 능력이 명백히 부족한 모델을 후보에서 제외하기 위해 사용할 수 있다. 모델을 하나씩 상세히 검증하기 전에 대략적인 능력 수준을 확인할 수 있다.

13.2 장점과 단점의 지도

여러 벤치마크를 비교함으로써,

• 수학에 강함
• 코드 생성에 강함
• 긴 문장 이해에 강함
• 다국어에 강함
• 도구 사용에 약함

과 같은 경향을 파악할 수 있다.

13.3 진화의 방향을 관찰하기

동일한 평가 조건을 지속적으로 사용하면 모델이 어느 방향으로 진보하고 있는지를 관찰할 수 있다. 절대적인 지능의 측정이 아니라, 시계열 비교를 위한 관측 장치로 사용할 수 있다.

13.4 자신의 인상을 교정하기

개인적인 사용감만으로는 우연히 잘 된 사례나 실패한 사례에 휘둘리기 쉽다. 벤치마크는 주관적인 인상을 보정하는 외부 참고 정보가 된다.

요컨대, 벤치마크는,

14. IT 엔지니어는 무엇을 평가해야 하는가

어느 수준을 넘어선 생성형 AI에 대해서는 벤치마크 순위의 몇 포인트보다 자신의 용도에 따른 평가가 더 중요해진다. 실무상의 유용성을 단순화하여 다음과 같이 나타내 본다.

여기서,

이다. 각 항은 0에서 1의 범위로 정규화(Normalization)되어 있다고 가정한다. 이 곱은 엄밀한 평가식은 아니며, 기초 능력이 높더라도 용도 적합성이나 의미 보존, 안정성 중 어느 하나가 현저히 낮으면 실무 가치도 저하된다는 것을 나타내는 설명 모델이다.

벤치마크가 주로 측정하고 있는 것은 이 중 기초 능력의 일부이다. 실제 개발에서 평가해야 할 것은 예를 들어 다음과 같은 항목일 것이다.

• 모호한 요구사항을 적절히 정리할 수 있는가
• 업무 고유의 용어를 임의로 일반화하지 않는가
• 여러 파일에 걸친 제약 사항을 유지할 수 있는가
• 기존 코드의 설계 의도를 읽어낼 수 있는가
• 수정으로 인한 부작용을 억제할 수 있는가
• 테스트 실패로부터 원인을 분리해낼 수 있는가
• 지적을 받고 국소적으로 수정할 수 있는가
• 동일한 요구사항을 표현을 바꿔도 안정적으로 처리할 수 있는가
• 틀렸을 때 검증 가능한 출력을 반환하는가

이러한 것들은 TOEIC나 대학 입시 점수로는 거의 알 수 없다.

15. 실무에서 수행하는 최소한의 모델 평가

대규모 사내 벤치마크를 처음부터 구축할 필요는 없다. 우선은 실제 업무에서 10~30건 정도의 대표적인 과제를 선정하는 것만으로도 충분하다. 동일한 과제에 대해,

• 지시 표현을 여러 개 준비한다
• 몇 번씩 실행한다
• 의미나 제약 사항이 보존되었는지 확인한다
• 성공뿐만 아니라 실패의 종류를 기록한다
• 수정 지시에 적절히 대응할 수 있는지 확인한다
• 비용과 처리 시간도 기록한다

라는 평가를 수행한다. 전 장의 '곱'이 병목 현상을 설명하는 개념 모델이었다면, 모델

각 점수와 비용은 비교 가능한 공통 척도로 정규화하고, 계수 우리에게 필요한 능력에는 우리 스스로 가중치를 부여해야 한다.

16. 요약

생성형 AI 벤치마크는 모델의 능력 그 자체를 직접 관측하는 것이 아니다. 특정 평가 조건 하에서 얻어진 출력으로부터 능력의 일면을 간접적으로 추정하는 측정 체계이다. 벤치마크 점수는,

이며, 모델만으로 결정되는 것이 아니다. 2025~2026년의 연구에서는 다음과 같은 문제들이 명확히 지적되고 있다.

• 같은 의미라도 프롬프트 (Prompt) 표현에 따라 점수가 달라진다
• 객관식과 자유 응답에서는 순위까지 바뀐다
• 기술 벤치마크에는 학습 데이터 누출 (Data Leakage)이 있을 수 있다
• 합성 코드 문제와 실제 프로젝트에서는 성능이 크게 다르다
• 에이전트 (Agent) 성능은 모델과 하네스 (Harness)의 조합으로 결정된다
• 단발성 성공률로는 실무상의 신뢰성을 측정할 수 없다
• 프롬프트, 채점기, temperature 등의 측정 오차가 순위를 역전시킬 수 있다

따라서 벤치마크 점수를 이 모델의 지능은 90점이다라는 고정적인 능력치로 읽어서는 안 된다. 정확하게는 이 모델을 이 평가 조건에서 구동했을 때, 이 점수가 관측되었다라고 읽어야 한다.

어느 수준을 넘어선 모델들끼리라면, 종합 벤치마크의 몇 점 차이를 계속 쫓기보다 각각의 특징과 편향을 이해하고 자신의 용도에 맞는 사용법을 설계하는 것이 실무적이다.

결국 IT 엔지니어가 알고 싶은 것은 어떤 모델이 가장 높은 점수인가가 아니다. 정말로 알고 싶은 것은 이 모델이 우리 문제의 의미를 정확히 파악하고, 제약을 유지한 채로 안정적이고 검증 가능한 결과물을 만들어낼 수 있는가가 아닐까.

벤치마크는 그 질문에 대한 답 그 자체는 아니다. 하지만 질문을 시작하기 위한 거친 지도라면 충분히 이용 가치가 있다.

참고 문헌

[1] Razavi et al., Benchmarking Prompt Sensitivity in Large Language Models, arXiv:2502.06065, 2025.

[2] Lunardi et al., On Robustness and Reliability of Benchmark-Based Evaluation of LLMs, arXiv:2509.04013, 2025.

[3] Chandak et al., Answer Matching Outperforms Multiple Choice for Language Model Evaluation, arXiv:2507.02856, 2025.

[4] Zhou et al., LessLeak-Bench: A First Investigation of Data Leakage in LLMs Across 83 Software Engineering Benchmarks, arXiv:2502.06215, 2025.

[5] Rahman et al., Beyond Synthetic Benchmarks: Evaluating LLM Performance on Real-World Class-Level Code Generation, arXiv:2510.26130, 2025.

[6] Gupta, ReliabilityBench: Evaluating LLM Agent Reliability Under Production-Like Stress Conditions, arXiv:2601.06112, 2026.

[7] Messing, Decomposing and Reducing Hidden Measurement Error in LLM Evaluation Pipelines, arXiv:2604.11581, 2026.

[8] Yao et al., Harness-Bench: Measuring Harness Effects across Models in Realistic Agent Workflows, arXiv:2605.27922, 2026.

보충

본고에서 다룬 2025~2026년 연구에는 arXiv에 공개된 피어 리뷰(Peer Review) 전의 프리프린트(Preprint)가 포함되어 있다. 개별 수치는 확정적인 결론으로서가 아니라, 현재의 LLM 평가 연구에서 어떠한 문제들이 제기되고 있는지를 보여주는 지표로서 참조되었다.

토론 (Discussion)