AI 모델 비교표를 보다 보면 숫자가 너무 깔끔해서 오히려 판단이 쉬워 보입니다. 58점, 53점, 48점. 가장 높은 숫자를 고르면 끝일까요?

실제 업무에서는 그렇지 않습니다. 벤치마크 점수는 특정 시험 묶음에서, 특정 설정으로, 특정 방식으로 측정된 결과입니다. 모델을 고를 때는 숫자보다 먼저 “무엇을 재고 있는 숫자인가?”를 봐야 합니다.

2026년 벤치마크는 단순 퀴즈 시험이 아닙니다

Artificial Analysis의 Intelligence Index v4.3.2는 현재 10개 평가를 묶어 사용합니다. 여기에는 장기 지식 작업을 보는 AA-Briefcase, 실제 업무형 GDPval-AA, SaaS 자동화를 보는 AutomationBench-AA, 터미널 작업을 보는 Terminal-Bench 4.0, 코딩을 보는 SciCode, 긴 문맥을 보는 AA-LCR 등이 함께 들어갑니다.

즉 Intelligence Index 50은 “수학 50점”처럼 단일 능력을 뜻하지 않습니다.

  • 문서와 지식을 다루는 능력
  • 여러 단계를 이어가는 능력
  • 도구를 사용하는 능력
  • 코드를 작성하고 환경을 조작하는 능력
  • 긴 문맥을 유지하는 능력

같은 서로 다른 능력을 하나의 종합 점수로 압축한 값에 가깝습니다.

그래서 종합 점수만 보면 놓치는 것이 생깁니다.

같은 모델도 effort가 다르면 다른 모델처럼 보입니다

최근 reasoning 모델은 low, medium, high, xhigh, max처럼 추론 강도를 나눠 제공하는 경우가 많습니다.

예를 들어 GPT-6 Sol은 Artificial Analysis 기준으로 effort가 올라갈수록 Intelligence Index가 높아지지만, 동시에 한 작업에 사용하는 reasoning token과 시간도 크게 늘어납니다. high에서 충분히 해결되는 일을 max로 돌리면 성능 차이는 작고 비용과 대기 시간만 커질 수 있습니다.

따라서 비교할 때는 최소한 다음처럼 써야 합니다.

모델 이름만 비교      X
GPT-6 Sol vs Opus     X

모델 + effort 비교    O
GPT-6 Sol (high)
Claude Opus 5.5 (medium)

코딩에서는 harness까지 같이 봐야 합니다

AI 코딩 성능은 모델만의 성능이 아닙니다.

코딩 에이전트는 보통 다음을 함께 사용합니다.

Model
  ↓
Context / Instructions
  ↓
Tools
  ↓
Terminal / Browser / Files
  ↓
Test / Verify / Retry

이 전체 구조를 하네스(harness)라고 볼 수 있습니다.

같은 모델이라도 어떤 agent가 파일을 어떻게 읽고, 테스트를 언제 실행하고, 실패 후 어떻게 다시 시도하는지에 따라 결과가 달라집니다. 그래서 Coding Agent Index 같은 지표를 볼 때는 모델명만 확인하지 말고 어떤 harness에서 측정됐는지도 같이 보는 것이 좋습니다.

점수를 볼 때 최소 5가지를 같이 보세요

확인할 것 왜 중요한가
Benchmark version 평가 문제가 바뀌면 과거 점수와 직접 비교하기 어렵습니다
Reasoning effort 같은 모델도 비용·시간·성능이 크게 달라집니다
Harness 코딩·에이전트 작업은 실행 환경이 결과에 영향을 줍니다
Cost per Task 토큰 단가가 싸도 많이 쓰면 실제 작업 비용은 커집니다
세부 benchmark 종합점수가 비슷해도 강한 작업이 다를 수 있습니다

특히 버전은 중요합니다. 2026년 9월 Artificial Analysis는 Terminal-Bench를 4.0으로 교체하고 AutomationBench-AA를 추가했습니다. 벤치마크 구성이 바뀌면 예전 점수와 최신 점수를 단순히 한 줄에 놓고 비교하면 안 됩니다.

CodeBridge Mini Lab: 내 업무에 맞는 모델 비교표 만들기

뉴스에 나온 점수를 그대로 받아들이기보다 작은 비교표를 직접 만들어보세요.

먼저 내가 자주 하는 작업 3개를 고릅니다.

Task A: 2,000줄 코드에서 버그 원인 찾기
Task B: 긴 PDF 3개 비교 요약하기
Task C: 작은 기능을 구현하고 테스트 통과시키기

그다음 같은 입력으로 후보 모델을 3회씩 실행합니다.

model, task, success, time_sec, cost_usd, retries
model_a, A, 1, 82, 0.18, 0
model_a, A, 1, 91, 0.21, 1
model_b, A, 0, 43, 0.05, 2

여기서 중요한 것은 “더 그럴듯한 답”이 아니라 내가 정의한 성공 조건입니다.

예를 들어 코딩이라면:

- 테스트 통과 여부
- 기존 기능 회귀 여부
- 수정 파일 수
- 불필요한 변경 여부

를 성공 조건으로 잡을 수 있습니다.

이 실험은 모델 순위를 만들기 위한 것이 아닙니다. 내 업무에서 어떤 설정이 충분한지 찾기 위한 실험입니다.

벤더 점수와 독립 평가를 구분하세요

모델 출시 글에 나오는 점수는 모델을 만든 회사가 측정한 결과일 수 있습니다. 반대로 Artificial Analysis, SWE-bench, METR 같은 외부 평가에는 별도의 환경과 방법론이 있습니다.

둘 중 하나만 믿어야 한다는 뜻은 아닙니다. 중요한 것은 출처를 섞지 않는 것입니다.

공식 발표
→ 모델이 무엇을 목표로 설계됐는지 확인

독립 평가
→ 동일 조건에서 다른 모델과 비교

직접 실험
→ 내 작업에서 실제로 맞는지 확인

이 세 층을 나누면 모델 선택이 훨씬 덜 흔들립니다.

결론: 최고 점수보다 내 작업에서의 충분한 점수가 중요합니다

새 모델이 나올 때마다 “현재 1위는 누구인가?”를 따라가면 선택 기준이 계속 바뀝니다.

더 실용적인 질문은 이것입니다.

내 작업을 안정적으로 끝내는 가장 저렴하고 빠른 조합은 무엇인가?

종합 벤치마크는 좋은 출발점입니다. 하지만 최종 선택은 세부 벤치마크 + effort + harness + 비용 + 직접 실험까지 내려와야 합니다.

함께 읽으면 좋은 글

참고 자료