앞 장에서는 모델을 고르는 기준을 살펴봤습니다. 이번에는 한 걸음 더 들어가, 그 모델을 어떻게 평가하고 신뢰할 수 있을지에 대해 이야기 해보겠습니다.

벤치마크, 환각, 그리고 검증

최근 GPT-6 Astra가 발표되며 이런 보도가 나왔습니다.

“OSWorld 2.0에서 GPT-6 Astra는 72.6%, GPT-5.6 Sol은 65.7%, Claude Opus 5는 70.2%를 기록했다.”

— TechRadar, 2026년 9월 4일

OpenAI는 이 점수가 OSWorld 전체가 아니라 일부 문제에서 나온 결과이며, 모델이 가장 오래 깊게 추론하도록 설정했을 때의 수치라고 설명했습니다. 즉 일반 사용자가 ChatGPT에서 같은 작업을 할 때 비슷한 성능이 나온다고 보기는 힘듭니다. OpenAI의 Astra 발표

여기에서 나온 72.6%라는 숫자는 Astra가 컴퓨터 사용 능력에서 크게 발전했다는 의미입니다. 그러나 이 보도에 뒤이어 또 다른 “최고 성능” 발표가 이어졌습니다. Claude Opus 5.5는 터미널 작업, Gemini 4 Argon은 장기 소프트웨어 엔지니어링 작업에서 높은 점수를 얻었다는 것을 얘기하고있고, GPT-6.1 Sol은 Astra에 가까운 성능을 더 낮은 비용으로 제공 가능하다는 점을 내세우고 있습니다. Anthropic의 Opus 5.5 발표, Google의 Gemini 4 Argon 발표, OpenAI의 GPT-6.1 Sol 문서

문제는 이런 수많은 성능에 대한 이야기들이 같은 능력을 측정한게 아니라는 점입니다. OSWorld는 화면을 보고 프로그램을 조작하는 시험이고, Terminal-Bench는 터미널 환경의 과업, DeepSWE는 긴 소프트웨어 개발 과업을 봅니다. 게다가 Argon은 신뢰된 보안 테스트 그룹부터 단계적으로 배포되는 중이라 아직 많은 사람들이 접해보지 못하고 있습니다. 즉 평가 방법 뿐 만이 아니라 시험 환경, 비용, 그리고 실제 사용 가능성까지 모두 다른 셈이죠.

자, 뭔가 속은 것 같죠? 그래서 AI 성능 평가를 제대로 이해하려면 관련된 사전 지식이 필요합니다.

뉴스 속 점수는 어떻게 만들어지나?

모델 발표 자료의 숫자는 크게 네 가지 방식으로 나옵니다.

1. 정답형 시험: 답을 맞혔는가?

AIME나 GPQA처럼 정답이 정해진 문제를 풀게 한 뒤, 최종 답이 정답과 일치하는지 확인하는 시험입니다. 수학, 과학, 지식 문제처럼 정답을 비교적 분명하게 정할 수 있는 분야에서 쓰기 좋습니다.

하지만 한 번의 답만 채점했는지, 여러 번 시도해 가장 좋은 답을 골랐는지, 검색이나 계산 도구를 썼는지에 따라 같은 점수라도 의미가 달라질 수 있습니다.

2. 과업 완수형 평가: 실제 일을 끝냈는가?

SWE-bench는 실제 소프트웨어 저장소의 버그 보고서를 주고, AI가 코드를 고친 뒤 테스트를 통과하는지 봅니다. OSWorld는 화면을 보고 프로그램을 조작해 파일 편집, 예약, 설정 변경 같은 일을 끝내는지 측정합니다.

여기서 점수는 문장을 잘 썼는가가 아니라, 마지막 상태가 과업의 요구 조건을 만족하는가에 가깝습니다. 대신 어떤 도구를 쓸 수 있었는지, 재시도를 몇 번 허용했는지가 결과에 크게 영향을 줍니다.

3. 사람 선호형 평가: 어느 답이 더 나았는가?

Chatbot Arena처럼 두 모델의 답을 익명으로 보여 주고 사람이 더 좋은 답을 고르게 하는 테스트도 있습니다. 이런 비교 결과를 바탕으로 모델 간 상대적 선호도를 계산한 것이 Elo 계열 점수입니다.

Elo는 체스 실력 평가 방식을 만든 물리학자 아르파드 엘로(Arpad Elo)의 이름에서 온 점수입니다. Elo가 높다는 것은 그 답변이 사람들에게 더 자주 선택됐다는 뜻입니다.

하지만 사실과 다른 답변이라도 더 친절하고 매끄러운 표현이 선택될 가능성이 있으므로, 정확도 점수와는 거리가 있습니다.

4. 종합 지수형

그래서 이런 여러 시험 결과를 하나의 숫자로 합친 종합 지수를 보는 방식도 있죠. 다만 이 방식은 어떤 능력에 비중을 더 두었느냐에 따라 점수가 달라집니다.

따라서 "90% 정확도", "Elo 점수", "종합 지수" 등은 같이 비교하면 안 되는 숫자입니다. 예를 들어 수학 점수가 높다고 해서 코딩, 고객 상담, 글쓰기, 문서 처리까지 잘한다고 볼 수 없는 것과 마찬가지입니다.

특히 실제 업무에 사용할 에이전트를 평가하려면 모델 하나만 봐서는 안 되죠.

에이전트의 실제 성능은 이렇게 구성되거든요.

모델 + 추론 강도 + 시스템 프롬프트 + 제공 데이터 + 도구 + 재시도 + 검증 절차

검색 능력이 얼마나 되는지, 문제 해결을 위해 Python스크립트를 만들어 실행시키는지, 브라우저를 허용했는지, 몇 번까지 재시도했는지, 추론 강도를 어디까지 쓸 수 있는지, 어떤 도구를 붙였는지에 따라 같은 모델을 써도 점수가 달라질 수 있죠.

“최고 성능” 기사를 읽을 때 필요한 다섯 가지 질문

그래서 "최고 성능" 모델이 발표되었다는 기사를 읽을 때, 다음 사항들을 먼저 확인할 필요가 있습니다.

벤치마크의 유용성과 한계

정리하면 벤치마크는 여러 모델을 같은 조건에서 비교하는 표준 시험입니다. 모델을 선택할 때 후보를 좁히는 데는 매우 유용합니다. 다만 다음과 같은 한계가 있습니다.

• 시험 범위의 한계: 공개 시험은 우리 회사의 문서 양식, 승인 규칙, 고객 유형까지 측정하지 못한다.

• 데이터 오염: 공개된 문제와 정답이 학습 데이터에 섞이면 새 문제 해결 능력을 측정하는 것인지 이미 기억하고 있는 내용을 측정하는 것인지 알 수 없다. (학교에서 기말고사 족보가 돌면 평균 점수가 달라지는 것과 비슷합니다.)

• 평균의 함정: 95% 정확도라도 나머지 5%가 단순 오탈자인지, 잘못된 금액 안내인지에 따라 위험은 다르다.

• 시험의 노화: 모델이 발전하면 시험이 너무 쉬워지거나 문제와 채점 기준의 결함이 드러날 수 있다.

그래서 벤치마크는 지도일 뿐 목적지는 아니다! 라는 점을 꼭 참고 하면 좋겠습니다.

환각은 왜 생길까?

AI의 대표적 실패는 환각(Hallucination)입니다. 존재하지 않는 사실, 출처, 인물을 그럴듯하게 말하거나, 입력 자료와 다른 내용을 자신 있게 답하는 현상입니다.

AI가 일부러 거짓말을 하는 것은 아닙니다. 앞에서도 얘기했듯이 언어모델은 데이터베이스에서 정답을 꺼내는게 아니고, 현재 문맥에 이어질 가능성이 가장 높은 표현을 생성합니다. 그래서 자연스럽고 자신 있게 말한다고 해서 그 내용이 사실이라는 보장은 없습니다

검색과 RAG는 최신 근거를 제공해 환각을 줄입니다. 그러나 잘못된 자료를 찾거나, 자료에 없는 결론을 만들거나, 오래된 정보를 최신 정보처럼 쓸 수 있습니다.

또한 참조 링크가 있다는 사실과 답변이 그 링크에 의해 뒷받침된다는 사실은 다릅니다. (이 부분은 나중에 GEO에 대한 글을 쓴다면 다시 언급할 기회가 있겠네요.)

그리고 AI의 말투도 정확도의 증거가 아닙니다. “확실합니다”는 검증 결과가 아니라 생성된 표현일 뿐이라는 것도 잊으면 안됩니다.

정리

처음에 본 Astra의 OSWorld 점수는 AI가 특정 컴퓨터 사용 과업에서 얼마나 발전했는지를 보여 주는 유용한 신호입니다. 하지만 그 숫자 하나만으로 모든 업무에서 가장 뛰어난 모델인지, 더 나아가 AGI인지까지 판단할 수는 없습니다.

AI 평가 결과를 읽을 때는 세 가지만 확인하면 됩니다.

1. 무엇을 시험했는가?

2. 어떤 조건에서 나온 점수인가?

3. 그 시험이 보여 주지 못하는 실패는 무엇인가?

벤치마크는 분명 유용합니다. 그런데 모델의 모든 능력을 보여주는 성적표는 아니죠. 점수 하나만 보고 “이 모델이 제일 좋다”라고 결론 내리기보다는, 이 점수가 어떤 시험에서 어떤 조건으로 나왔는지부터 보는 게 맞습니다.

결국 AI를 신뢰한다는 건 높은 점수가 아니라 이 모델이 뭘 잘하고, 어디에서 틀릴 수 있는지 알고 쓰는 거라고 할 수 있겠습니다.

이어서

자 여기까지가 4장의 마지막 입니다. 

제가 그동안 이런 순서로 글을 써왔는데요..

• 1~3장 : LLM을 이루는 3가지 기본원리

• 4장 : LLM 모델에 관련된 여러가지 이야기

5장 부터는 실제 비지니스 현장에서의 AI활용에 대한 이야기를 다뤄 볼까 합니다.

예를 들어 요즘 마케팅 담당자들이 머리싸매고 고민하는 GEO, 하네스엔지니어링/루프엔지니어링등 각종 XX엔지니어링, 개발용 AI는 토큰을 어떻게 사용하는가?, Agentic AI의 여러가지 형태.... 이런것들이 있을 것 같구요.. 

"개발자가 만드는 코드와 LLM이 만드는 코드는 어떻게 다르고 전통적인 소프트웨어 개발방법론은 LLM시대에 어떻게 바뀌어야 하나?" 같은 숙고가 필요한 논쟁적인 내용들도 다룰 수 있을것 같습니다.