스탠퍼드 HAI의 2026 AI Index 소개에서 눈에 들어온 것은 수학 대회와 아날로그 시계의 대비였다. 공식 소개는 Gemini Deep Think의 국제수학올림피아드 금메달 수준 성과를 언급하면서, 시계 읽기에서는 가장 좋은 모델도 정확도가 50.1%였다고 설명한다. 어려워 보이는 일을 잘한다고 쉬워 보이는 일까지 잘하는 것은 아니라는 사례다. 2026 AI Index
다만 제목만 보고 같은 Gemini 모델이 같은 설정에서 두 과제를 치렀다고 받아들이면 안 된다. 평가 대상, 입력 형식, 허용 시간, 도구와 시도 횟수를 각각 확인해야 한다. 이 대비를 모든 AI의 고정된 한계라고 읽는 것도 성급하다. 보고서에 담긴 관찰과 다음 모델의 능력은 구분해야 한다.
리서치 업무에 가져가고 싶은 질문은 더 작다. 공개 점수가 높은 모델을 골랐는데 우리 보고서에서는 표의 분모를 놓친다면, 무엇을 다시 측정해야 할까. 아래 평가표는 실제 회사 파일럿 성과가 아니라 내가 적용할 수 있도록 만든 실험 설계다. 초안의 내부 테스트 사례와 일률적인 15% 차이 규칙은 근거가 확인된 결과처럼 사용하지 않는다.
두 점수의 차이를 계산하기 전에 같은 일을 재는지 묻는다
코딩 벤치마크 정답률 90%와 문서 요약 평가 75%를 놓고 성능이 15% 떨어졌다고 말할 수는 없다. 분모가 다른 데다 정답의 정의도 다를 수 있다. 전자는 테스트를 통과한 문제의 비율이고 후자는 사람이 여러 항목을 채점한 평균일 수도 있다. 숫자 모양이 비슷하다고 같은 척도가 되지는 않는다.
공개 평가를 읽을 때는 우선 측정 단위를 적는다. 문제 하나를 풀었는지, 여러 번 시도해서 한 번이라도 맞혔는지, 도구가 있는 에이전트 전체를 평가했는지 구분한다. 같은 모델 이름도 추론 설정이나 제공 버전이 다르면 그대로 재현되지 않을 수 있다. 게시 날짜와 시험 날짜가 다를 때도 있으니 둘 다 확인한다.
그다음 내 과제와 겹치는 능력을 적는다. 한국어 보고서 요약이라면 긴 문맥 처리, 표와 각주의 연결, 출처 보존, 모르는 내용의 유보가 중요하다. 코드 작성 점수는 일부 추론 능력의 참고가 될 수 있지만 이 네 가지를 직접 보증하지 않는다. 벤치마크가 쓸모없다는 결론이 아니라 그 숫자가 답해 줄 수 있는 질문을 좁히자는 뜻이다.
공식 기술 성능 장은 여러 평가를 모아 발전과 남은 약점을 보여 준다. 그 목록을 구매 순위표로 복사하기보다 우리 작업에서 확인할 항목의 후보로 읽는 편이 낫다. 보고서 전체를 직접 재검증했다는 의미는 아니며, 여기서는 공식 웹 소개와 기술 성능 장을 출발 자료로 사용했다. 기술 성능 장
문서 요약 과제를 입력과 허용된 답으로 좁힌다
“보고서를 잘 요약한다”는 목표로는 모델 둘을 비교하기 어렵다. 예시 과제를 다음처럼 고정한다. 입력은 권한이 확보된 한국어 설문 보고서 한 편이고, 출력은 의사결정자에게 보낼 600자 이내 요약이다. 핵심 결과 세 개와 해석의 한계 한 개를 포함하고, 각 수치 옆에는 페이지나 표 번호를 붙인다. 원문에 없는 원인 설명은 쓰지 않는다.
여기서 600자나 핵심 결과 세 개는 보편적인 최적값이 아니다. 비교하려는 작업의 계약을 고정하기 위한 예시다. 실제 독자가 긴 메모를 필요로 한다면 길이를 바꿔야 한다. 문서를 통째로 넣을 수 없는 환경이라면 전처리나 검색 방식도 평가 대상에 포함된다.
정답 기준은 모델 출력 전에 작성한다. 중요한 결과가 무엇인지 사람도 합의하지 못한 상태라면 점수 차이가 평가자 취향을 반영할 수 있다. 숫자와 대상 집단은 확인 가능한 답으로 고정하고, 문체처럼 여러 답이 가능한 항목은 따로 평가한다. 특정 문장과 완전히 같아야만 정답이라는 방식은 요약의 다양한 표현을 부당하게 벌점 처리할 수 있다.
출처가 빠진 요약은 단지 형식 점수를 조금 잃은 답이 아닐 수 있다. 나중에 숫자를 확인할 수 없으면 업무상 사용이 불가능할 수 있다. 실제 승인 조건에 필요한 항목은 평균에 섞지 않고 별도의 통과 조건으로 둔다.
스무 개로 시작하더라도 표본의 종류를 먼저 나눈다
작은 평가를 시작하기 위해 문서 스무 개를 골라 볼 수 있다. 하지만 스무 개는 통계적으로 충분함을 보장하는 숫자가 아니다. 시간과 예산 안에서 실패 유형을 발견하려는 출발점이다. 회사 전체 문서에서 무작위로 고르는 것과, 문제가 생길 법한 문서를 의도적으로 넣는 것은 목적이 다르므로 구분해서 기록해야 한다.
가상의 구성은 일반 본문 여섯 개, 표와 각주가 많은 문서 여섯 개, 서로 다른 조사 차수를 비교하는 문서 네 개, 정보가 부족하거나 일부 페이지가 누락된 문서 네 개다. 마지막 유형에서 좋은 답은 자신 있는 완성 요약이 아니라 누락 사실과 답할 수 없는 항목을 밝히는 것이다.
이 구성의 점수를 실제 전체 업무의 예상 정확도라고 그대로 발표하면 안 된다. 어렵고 드문 문서를 과하게 넣었다면 현장 빈도와 다르기 때문이다. 실패를 찾는 도전 세트와 실제 사용 빈도를 반영한 세트를 나누면 목적이 더 분명해진다. 둘을 합친 평균만 보는 대신 유형별 결과를 남긴다.
프롬프트를 고치는 데 쓸 개발용 문서와 마지막 확인용 문서도 분리한다. 같은 스무 개를 보며 열 번 수정하고 마지막 점수를 새 과제의 실력이라고 부르면, 그 자료에만 맞춘 효과가 섞인다. 자료가 적으면 규모를 늘릴 때까지 결론을 제한하고 새 문서가 생길 때 재확인한다.
채점표에는 숫자 오류와 빠진 한계를 따로 둔다
아래는 문서 요약을 평가하는 제안이다. 특정 연구에서 검증한 척도가 아니라, 검토자 사이의 기준을 맞추기 위한 작업표다.
| 항목 | 확인할 증거 | 실패 예시 |
|---|---|---|
| 수치 정확성 | 원문 수치, 단위, 분모, 시점 | 30%를 30%p로 바꾸거나 전체와 하위 집단을 혼동 |
| 핵심 결과 보존 | 미리 정한 중요 결과 목록 | 제목에 잘 맞는 결과만 남기고 반대 결과 누락 |
| 불확실성 표현 | 표본 한계와 누락 정보 | 상관관계를 원인으로 단정 |
| 출처 추적 | 페이지·표 번호와 원문 위치 | 존재하지 않는 표 번호를 생성 |
| 사용 가능성 | 길이·대상 독자·형식 | 내용은 맞지만 승인 문서로 쓸 수 없는 형식 |
수치와 출처를 틀렸다면 문장이 자연스럽다는 이유로 평균 점수에 묻히지 않게 한다. 반면 문체 차이는 같은 위험도로 다루지 않는다. 가중치를 붙이려면 누가 그 결과를 어떤 결정에 쓰는지 먼저 물어야 한다. 고객에게 공개되는 숫자와 개인 독서 메모의 표현 오류는 영향이 다르다.
가능하면 모델 이름을 가리고 같은 기준으로 평가한다. 평가자가 둘이라면 일부 문서를 함께 채점해 해석 차이를 기록한다. 둘이 다르게 본 항목을 무조건 평균 내기보다 기준이 모호한지, 원문이 모호한지 확인한다. 모델을 심판으로 보조 사용할 때도 수치와 원문 대조를 모두 맡겼다는 이유로 독립 검증이 끝났다고 생각하지 않는다.
응답 시간보다 검토가 끝나는 시간을 기록한다
빠르게 나온 답을 사람이 오래 수정해야 할 수 있다. 그래서 실행 비용과 함께 읽기, 출처 확인, 수정, 재실행 시간을 나눠 적는다. 예를 들어 모델 A가 20초, 모델 B가 50초에 답했더라도 A의 수치 오류를 고치는 데 더 오래 걸리면 전체 업무 시간은 역전될 수 있다. 이 숫자는 실제 측정값이 아닌 계산 관점을 설명하는 예다.
비용도 호출 한 번의 가격만으로 비교하지 않는다. 입력 전처리, 검색, 반복 호출, 외부 도구가 있다면 같은 완료 기준까지 발생한 비용을 묶는다. 최신 가격은 구매 시점의 공식 요금표로 다시 확인해야 하므로 여기서는 특정 모델의 현재 단가를 적지 않는다.
실패 비용은 시간과 별도로 남긴다. 원문과 다른 고객 수치가 외부로 전달된 사고를 단순 수정 몇 분으로 환산하면 중요한 위험을 놓친다. 낮은 위험의 문서는 자동 초안으로 쓰고 높은 위험의 문서는 사람 승인을 유지하는 식으로 사용 범위를 나눌 수 있다. NIST AI RMF도 사용 맥락과 위험에 맞춰 측정과 관리를 연결하는 틀을 제공한다. AI 위험 관리 프레임워크
모델이 바뀌었을 때 재시험할 수 있는 기록을 남긴다
평가 결과에 이름과 점수만 있으면 다음 달에 같은 조건으로 비교하기 어렵다. 최소 기록에는 실행 날짜, 제공자와 모델 식별자, 설정, 프롬프트 버전, 입력 자료 버전, 사용 도구, 답변 원문, 판정 이유를 넣는다. 원자료가 민감하다면 공개 기록에 문서 내용이나 식별 가능한 고객 정보를 포함하지 않는다.
한 번 통과한 모델도 제공 버전, 검색 방식, 문서 형식이 바뀌면 다시 확인한다. 이전 실패 사례를 회귀 시험에 넣되 새 문서도 보탠다. 오래된 시험만 반복하면 익숙한 오류에 강해진 것을 새로운 업무에 대한 보장으로 오해할 수 있다.
이 과정을 모두 끝내기 전에는 “우리 업무에서 우수하다” 대신 “이 조건의 작은 표본에서 이 유형의 오류가 적었다”라고 적는 편이 정확하다. 나는 우선 블로그와 공개 문서의 요약처럼 손실을 제한할 수 있는 과제에 이 평가표를 적용해 보고 싶다. 실제 결과가 나오면 후보 이름보다 먼저 어떤 문서에서 실패했는지 남길 생각이다.
참고자료
- Stanford HAI, The 2026 AI Index Report: 수학 성과와 시계 읽기 사례를 포함한 공식 소개.
- 2026 AI Index, Technical Performance: 모델 성능과 평가 영역의 공식 장 안내.
- NIST AI Risk Management Framework: 사용 맥락에 따른 위험의 측정과 관리 기준.