82%. 이 숫자가 맞다면, 업계가 익숙하게 보는 LLM 리더보드는 성능의 큰 부분을 놓치고 있을 수 있다. arXiv에 공개된 The Capability Frontier: Benchmarks Miss 82% of Model Performance는 단일 모델·단일 실행 정확도로 대표되던 평가 방식이 실제 활용 가능한 성능을 과소평가할 수 있다고 주장한다. 핵심은 간단하다. 어떤 문제는 모델 A가 잘 풀고, 다른 문제는 모델 B가 잘 푼다. 같은 모델도 한 번 더 생성하면 더 나은 답을 낼 수 있다.

세 줄 요약

• 이 글의 핵심 쟁점은 LLM 성능을 “모델 하나, 한 번 실행한 점수”로 재는 기존 벤치마크가 실제 활용 가능한 능력을 충분히 담지 못할 수 있다는 점이다.
• 이 문제가 중요한 이유는 평가 방식이 제품 설계와 비용 집행에 이어지기 때문이다. 논문 초록 기준으로는 단일 모델 선택만 보정해도 오류율이 54% 줄고, 단일 실행 제약까지 보정하면 82% 개선되며, 같은 최고 성능을 85% 낮은 비용으로 맞출 수 있다고 한다.
• 독자는 자사 평가판에 단일 점수 대신 “모델 조합 + 반복 실행 + 비용” 축을 추가할 필요가 있다. 한 모델의 평균 점수보다 어떤 문제에서 함께 틀리는지부터 확인하는 편이 실무 판단에 가깝다.

현황

이 논문은 21개 LLM을 16개 널리 쓰이는 벤치마크에서 비교했다고 밝힌다. 범위도 넓다. 초록과 조사 결과 기준으로 코딩, 추론, 의료, 사실성, 지시이행, 에이전트 작업을 함께 다룬다. 여기서 저자들이 제안한 개념이 ‘Capability Frontier’다. 성능을 하나의 점수가 아니라, 비용과 샘플 수, 모델 선택을 함께 놓고 보는 파레토 프런티어로 다루자는 접근이다.

다만 여기에는 단서가 있다. 조사 결과 기준으로, 이 수치가 실제 서비스 로그와 운영 데이터셋을 직접 대조해 나온 값인지는 확인되지 않았다. 즉 “프로덕션 워크로드”라는 표현은 초록상 비용 제약 아래에서 다중 모델 선택과 다회 생성·선별을 반영한 활용 시나리오에 가깝다. 실서비스의 지연시간, 장애 처리, 검수 비용까지 포함한 운영 성능으로 바로 읽으면 범위를 넓혀 해석하는 셈이다.

이 문제의식은 다른 연구 흐름과도 맞닿아 있다. 별도 연구는 반복 제출이 전반적으로 도움이 되지만, 더 큰 토큰 예산이나 외부 피드백, 병렬 시도의 효용은 벤치마크마다 다르다고 짚었다. 또 다른 연구는 다중 모델 시스템의 상한을 “모든 모델이 동시에 틀리는 비율”, 즉 co-failure 관점에서 봐야 한다고 말한다. 쉽게 말해 모델을 여러 개 붙였다고 성능이 자동으로 오르지는 않는다. 서로 다른 방식으로 틀릴 때 조합의 가치가 생긴다.

분석

이 논문이 건드리는 것은 단순한 평가 기법만이 아니다. 리더보드의 기준 자체다. 지금까지 공개 벤치마크는 대체로 “어떤 모델이 1등인가”를 묻는 구조였다. Capability Frontier는 질문을 바꾼다. “같은 예산이면 어떤 조합이 가장 낫나”, “같은 성능이면 비용을 얼마나 줄일 수 있나”, “한 번 더 생성할 가치가 있는 작업인가”를 묻는다. 제품 팀 관점에서는 이런 질문이 더 실무적이다. 사용자는 모델 이름보다 답의 품질, 지연시간, 비용을 함께 경험하기 때문이다.

오해하면 안 되는 지점도 있다. 이 접근이 곧바로 모든 팀에 유리한 것은 아니다. 다회 샘플링은 추론 비용과 지연시간을 늘린다. 선택 전략도 비용이 든다. 사람이 고를지, 검증기를 붙일지, 규칙 기반 필터를 둘지에 따라 운영 복잡도가 커진다. 게다가 작업 유형별로 최적의 샘플 수나 선택 규칙이 어떻게 다른지는 이번 조사 결과만으로 넓게 결론내리기 어렵다. 리더보드를 프런티어 형태로 바꾸자는 제안은 설득력이 있지만, 어떤 축을 표준으로 삼을지는 아직 정리되지 않았다.

실전 적용

실무에서는 이 논문을 “벤치마크를 버리라”는 메시지로 읽으면 안 된다. 더 정확한 해석은 이렇다. 단일 점수는 출발점일 뿐이다. 배포 판단은 그 위에 한 겹 더 쌓아야 한다. 예를 들어 고객지원 자동화와 코드 생성은 같은 평가법으로 다루기 어렵다. 고객지원은 일관성과 안전한 거절이 중요하다. 코드 생성은 반복 시도 후 테스트 통과본을 고르는 전략이 더 잘 맞을 수 있다.

예: 사내 문서 검색 도우미를 운영한다면, 한 모델의 최고 평균 점수만 볼 것이 아니라 질문 유형을 나눠 어떤 모델이 어디서 함께 틀리는지 먼저 본다. 그다음 비용이 허용하는 범위에서 한 번 더 생성할 때 품질이 얼마나 오르는지 측정한다. 여기서 상승폭이 작으면 반복 실행을 줄인다. 상승폭이 크면 특정 질문군에만 best-of-n류 전략을 제한적으로 붙이는 식으로 설계할 수 있다.

오늘 바로 할 일

• 현재 평가표에 “단일 실행 점수” 옆으로 “반복 실행 허용 시 점수”와 “추가 비용” 열을 붙여라.
• 상위 후보 모델들을 평균 정확도 순서만 보지 말고, 같은 문제에서 동시에 실패하는 비율을 따로 기록해라.
• 작업 유형을 코딩·추론·사실성처럼 쪼개서, 반복 실행이 이득인 구간과 낭비인 구간을 분리해라.

FAQ

Q. 이 논문은 기존 벤치마크가 쓸모없다고 말하나요?
아닙니다. 기존 벤치마크는 여전히 출발점으로 유용합니다. 다만 단일 모델·단일 실행 점수만으로 실제 활용 성능을 대표하면 중요한 차이를 놓칠 수 있다는 문제 제기입니다.

Q. 다회 샘플링을 쓰면 항상 성능이 오르나요?
그렇지는 않습니다. 조사 결과에 따르면 반복 제출은 도움이 되는 경우가 있지만, 더 큰 토큰 예산이나 외부 피드백, 병렬 시도의 효용은 벤치마크별로 다릅니다. 즉 작업 유형에 따라 이득이 달라집니다.

Q. 제품 팀은 무엇부터 바꿔야 하나요?
평가 대시보드부터 바꾸는 편이 좋습니다. 모델 하나의 점수 대신 비용, 반복 실행, 모델 조합, 동시 실패 비율을 함께 보셔야 배포 판단이 현실에 가까워집니다.

결론

Capability Frontier가 던지는 메시지는 분명하다. LLM 성능은 더 이상 “누가 한 번에 제일 잘 푸나”만으로 설명하기 어렵다. 앞으로는 단일 점수보다 프런티어 관점이 더 중요해질 수 있다. 같은 예산에서 무엇을 더 얻고, 같은 성능을 위해 무엇을 덜 쓸 수 있는지가 다음 평가 기준으로 다뤄질 가능성이 있다.

다음으로 읽기

• AI 자료 모음 (24h) - 2026-06-28
• 에이전트 설정의 숨은 위험
• 금융 추천, 연결보다 설명
• 클러터 작업대 모션 선별
• LLM 갈등 완화 안전성

참고 자료

• When Does Combining Language Models Help? A Co-Failure Ceiling on Routing, Voting, and Mixture-of-Agents Across 67 Frontier Models - huggingface.co
• State of What Art? A Call for Multi-Prompt LLM Evaluation - huggingface.co
• arxiv.org - arxiv.org
• How Inference Compute Shapes Frontier LLM Evaluation - arxiv.org