GDPx 최고 점수 12%, 모델과 하네스를 함께 평가해야 하는 이유

SemiAnalysis가 전문 분야의 고난도 과제로 AI 에이전트를 평가하는 벤치마크 GDPx를 발표했다. 11개 도메인, 14개 파트너가 제공한 206개 과제로 구성된다. 2026년 11월 2일 13:47 KST 확인 기준 공식 리더보드의 표시된 비교표에서 Claude Opus 5.5의 종합 점수가 12.0%로 가장 높았다. 개발자와 IT 실무자에게 중요한 것은 낮은 숫자 자체보다, 어떤 실행 조건과 채점 방식에서 나온 결과인지다.[1][2]

이 결과만으로 모델을 바꾸면 업무 문제가 해결된다고 판단할 수는 없다. GDPx는 가능한 경우 모델별 네이티브 하네스를 사용하므로, 관측된 성적에는 모델뿐 아니라 도구를 호출하고 작업을 이어가는 실행 환경도 조건으로 포함된다. 따라서 도구를 고를 때는 모델 이름뿐 아니라 하네스·워크플로까지 비교해야 한다. [2]

GDPx는 어떤 일을 얼마나 오래 시키는가?

높은 투자 대비 효과를 기대하는 전문 분야에서, 에이전트가 긴 작업을 수행하도록 만든 벤치마크다. 소프트웨어 엔지니어링뿐 아니라 칩 설계, 생물학, 재료과학, 금융, 법률 등 11개 도메인을 다룬다. 기본 실행 시간은 8시간이며 일부 과제는 더 짧다. 짧은 문답의 정답률과 같은 의미로 읽기 어려운 이유다.[2]

범위가 넓다고 전체 직업을 대표하는 것은 아니다. 원문은 경제 전반의 직업 비중을 그대로 재현하기보다, AI 활용의 수익성이 높을 것으로 보는 영역을 선별했다고 설명한다. 따라서 이 점수를 고객 문의 분류, 사내 문서 검색, 반복적인 코드 수정 같은 개별 업무의 예상 성공률로 옮겨 쓸 근거는 없다. 업무가 얼마나 비슷한지부터 확인해야 한다.[2]

긴 시간 제한 역시 결과 해석의 조건이다. 이 벤치에서 얻은 종합 성적만으로 짧은 응답 시간 안에 처리해야 하는 사내 서비스의 품질을 판정할 수는 없다. 평가하려는 업무가 장시간 탐색을 허용하는지, 중간에 사람이 확인하는지에 따라 별도의 시험 조건을 정해야 한다.

상위 모델의 12%는 무엇을 뜻하는가?

도메인별 채점 결과를 정해진 가중 방식으로 합친 GDPx 종합 점수다. 아래는 확인 시점에 모델 선택이 13 of 20으로 표시된 공식 비교표의 상위 네 모델이다. 화면에 표시되지 않은 나머지 모델의 결과까지 확장한 표는 아니다.[1]

GDPx는 도메인을 균등하게 가중하고, 각 도메인 안의 파트너도 균등하게 가중한다. 과제에 따라 이진 채점과 부분 채점을 함께 사용한다. 그러므로 12.0%를 206개 과제 가운데 정확히 12%를 완수했다는 뜻으로 풀어 쓰면 틀린다. 일반 업무의 88%에 실패한다는 설명도 성립하지 않는다.[1][2]

시도 횟수도 구분해야 한다. 보고하는 것은 세 번의 시도 결과를 평균한 pass@1이지, 세 번 중 한 번만 성공해도 해당 과제를 통과 처리하는 pass@3가 아니다. 재시도 기회를 몇 번 주었는지와, 그 결과를 어떤 지표로 합쳤는지는 다른 문제다. 도입 시험에서도 가장 잘된 결과만 골라 비교하지 않도록 평가 규칙을 먼저 고정해야 한다.[2]

부분 점수와 완전 통과를 왜 나눠 봐야 하는가?

일부 요구를 충족한 결과와 과제를 끝까지 통과한 결과는 같은 산출물이 아니기 때문이다. 원문은 금융의 이진 평가에서 모든 모델이 0%였고, 법률도 이진 평가로는 너무 어려워 부분 점수를 보고한다고 설명한다. 부분 점수가 있다는 이유로 그 도메인의 업무를 완수했다고 바꿔 읽어서는 안 된다.[2]

실무 평가에서도 초안 작성, 검증 완료, 최종 승인에 서로 다른 기준을 두면 유용하다. 예를 들어 코드가 생성됐다는 사실만으로 테스트 통과나 배포 가능 상태를 인정하지 않고, 문서가 채워졌다는 이유만으로 근거 확인까지 끝났다고 처리하지 않는 것이다. 단계별 진척과 최종 수용 여부를 따로 기록하면 부분적인 도움을 과대평가하지 않으면서 활용할 수 있다.

하네스가 포함되면 모델 순위를 믿을 수 없는가?

순위는 해당 실행 조건에서의 결과로 읽을 수 있지만, 모델 자체의 효과만 분리한 비교는 아니다. 원문에 따르면 Opus 5.5는 Claude Code, GPT-6 Astra는 Codex, Gemini 4 Carbon은 Antigravity를 사용한다. 네이티브 하네스가 없는 모델에는 OpenCode를 사용한다.[2]

하네스는 모델의 응답을 실제 작업으로 연결하는 실행 환경으로 이해하면 된다. 개념은 Claude Code와 하네스의 관계를 정리한 글에서 이어 볼 수 있다. GDPx에서는 이 실행 환경이 모델마다 같지 않다는 사실을 비교 조건에 포함해 읽어야 한다.[2]

다만 서로 다른 모델과 서로 다른 하네스의 결과를 나란히 놓았다고 하네스의 기여도를 계산할 수는 없다. 동일 모델에서 다른 조건을 통제하고 하네스만 교체한 인과실험이 아니기 때문이다. 특정 조합의 점수가 높다는 관측과, 그 조합에서 하네스가 점수를 높였다는 설명 사이에는 추가 검증이 필요하다.[2]

따라서 모델만 바꾸면 해결된다는 결론도, 하네스만 개선하면 해결된다는 결론도 이 자료로는 뒷받침되지 않는다. 조직의 선택 단위를 모델 이름 하나가 아니라 모델·도구·작업 절차의 조합으로 두자는 것이 이 글의 실무 제안이다.

안전 분류기가 낮춘 점수는 태업의 증거인가?

아니다. 원문의 sandbagged라는 표현은 Opus와 Astra의 점수가 안전 분류기의 영향을 받아 낮아지는 맥락으로 제시된다. 이를 모델이 의도적으로 기만하거나 태업했다는 증거로 사용할 수 없다. 사이버·생물학·얼라인먼트 영역을 제외하면 순위도 달라지므로, 종합 순위만으로 모든 용도의 우열을 고정하기 어렵다.[2]

업무 평가에서는 거절된 요청과 실행했지만 요구를 충족하지 못한 요청을 나누어 기록하는 편이 좋다. 둘을 합쳐 실패로만 집계하면 개선 대상을 구분하기 어렵다. 그렇다고 점수를 높이기 위해 안전장치를 약화하자는 뜻은 아니다. 허용된 업무 범위와 데이터 접근 권한 안에서 어떤 요청을 처리할 수 있는지 확인하는 평가가 필요하다.

실무에서는 무엇부터 평가해야 하는가?

실제 업무의 완료 기준과 실행 조건을 먼저 고정해야 한다. 아래 체크리스트는 GDPx가 검증한 생산성 향상 절차가 아니라, 벤치마크의 결과를 조직의 도입 판단으로 옮길 때 사용할 평가안이다.

• 평가할 업무를 구체화한다. 코드 수정, 테스트 보완, 문서 정리처럼 산출물과 최종 승인 조건을 함께 적는다.
• 모델과 하네스의 버전, 사용 도구, 접근 가능한 파일과 권한을 기록한다. 모델 이름만 남기지 않는다.
• 시간·비용·재시도 예산을 정한다. 가장 좋은 한 번의 결과와 반복 시도의 평균을 섞어 보고하지 않는다.
• 완전 통과, 부분 진척, 실행 오류, 정책상 거절을 구분한다. 사람이 추가로 검토하거나 수정한 범위도 남긴다.
• 모델 교체와 하네스 변경을 구분해 시험한다. 여러 조건을 동시에 바꿨다면 조합의 결과로만 보고한다.
• 전체 평균과 업무 유형별 결과를 함께 본다. 한 영역의 장점이 다른 영역의 수용 기준까지 충족하는지 따로 확인한다.

결과 기록은 성공 여부에서 멈추지 않는 편이 낫다. 어느 단계에서 막혔는지, 도구 실행 오류인지, 결과 검증에서 탈락했는지까지 남기면 다음 시험의 변경 대상을 정하기 쉽다.

이 결과로 어디까지 결론 내릴 수 있는가?

선별된 고난도 과제에서 현재 표시된 상위 모델도 낮은 종합 점수를 받았다는 범위까지다. 12%를 현실 업무 성능의 천장으로 삼거나, 모든 조직의 자동화 한계로 선언할 수는 없다. 이 글의 근거는 공식 리더보드와 원문 방법론이며, 외부 독립 재현 여부는 확인되지 않았다.[1][2]

도입 판단에서 가져갈 것은 숫자 하나가 아니라 비교의 단위다. 모델의 능력, 실행 환경, 업무별 완료 기준을 분리해 기록하고 실제 사용할 조합을 시험해야 한다. 종합 순위는 후보를 좁히는 출발점이고, 도입 여부는 팀의 산출물 검수 결과로 결정해야 한다.

출처