메인으로
지유 · 최고기술책임자(CTO) · 오늘의 기술 칼럼

조건을 적지 않은 점수는 비교가 아니다

같은 모델의 같은 벤치마크 점수도 추론 연산량과 평가 방식에 따라 달라집니다. 학회 논문 2천여 편을 주장 단위로 다시 돌려 본 실험을 따라, 법률 AI 의 검증 결과를 어떤 단위와 조건으로 남겨야 하는지 다룹니다.

초록 AI 평가의 점수는 숫자 하나로 돌아다니지만, 그 숫자를 만든 조건은 대개 함께 다니지 않습니다. 영국 AI Security Institute(AISI)는 EvalEval 연합의 공유 스키마와 평가 카드로 평가 결과를 설정 정보와 함께 공개하기 시작했고, 벤치마크 성능이 추론 시점 연산량과 평가 프로토콜에 따라 달라진다는 연구를 곁들였습니다. 같은 여름 Hugging Face 는 커뮤니티와 함께 ICML 2026 논문 2,226편을 코딩 에이전트로 주장 하나하나씩 재현했고, 짧게 끝난 확인이 틀린 정리를 '검증됨'으로 판정한 사례와, 재현하는 쪽의 단위 착오가 만든 '거짓 반증'을 함께 보고했습니다. 이 칼럼은 두 발표를 법률 AI 의 검증 기록으로 옮깁니다. 인용 하나, 결론 하나를 검증했다고 적을 때 그 판정이 어떤 원문 판본과 어떤 조회 조건에서 나왔는지가 함께 남아야, 다른 사람이 다시 돌려 보고 동의하거나 반박할 수 있습니다.

두 모델의 점수가 같은 표에 나란히 있으면 우리는 자연스럽게 높은 쪽이 낫다고 읽습니다. 그런데 한쪽은 답을 여러 번 시도하게 두었고 다른 쪽은 한 번만 시도하게 했다면, 그 표는 모델을 비교한 것이 아니라 조건을 비교한 것입니다. AISI 와 EvalEval 이 공개한 자료가 보여 주는 것이 바로 이 점입니다. 같은 모델, 같은 벤치마크라도 추론에 쓰는 연산량과 평가 방식이 바뀌면 점수가 움직입니다. 법률 AI 에서도 사정은 같습니다. '이 답변의 인용은 검증을 통과했다'는 문장은 그 자체로는 무엇을 말하는지 알 수 없습니다. 어느 시점의 법령 원문과 대조했는지, 원문을 실제로 읽었는지 아니면 읽지 못해 판정을 건너뛰었는지, 조문 번호만 맞춰 봤는지 내용까지 맞춰 봤는지에 따라 같은 '통과'가 전혀 다른 뜻이 됩니다. 조건을 적지 않은 검증 결과는 비교할 수도, 반박할 수도 없는 숫자로 남습니다.

핵심 기술 개념

평가 카드(Evaluation Card)

평가 결과와 그 결과를 해석하는 데 필요한 정보, 곧 벤치마크 정보·실행 설정·모델 정보를 하나의 기록으로 묶은 것입니다. EvalEval 연합은 공유 스키마(Every Eval Ever)로 이 기록의 형식을 맞춰, 비슷해 보이는 점수가 실제로는 다른 조건에서 나왔는지 알아볼 수 있게 합니다.

주장 단위 재현(Claim-level Reproduction)

논문이나 보고서 전체를 통째로 맞다·틀리다 판정하지 않고, 그 안의 개별 주장마다 검증·반증·축소 규모 증거·판정 불가를 따로 매기는 방식입니다. ICML 2026 재현 챌린지는 35,908개 주장을 이렇게 판정했습니다.

짧은 확인의 거짓 검증(Finite-horizon False Verification)

문제가 드러나기 전에 확인을 멈춰, 틀린 주장이 검증된 것처럼 보이는 현상입니다. 재현 챌린지에서는 어떤 정리의 반례가 224단계 뒤에야 나타나, 그보다 짧게 돌린 확인들이 그 정리를 '검증됨'으로 판정했습니다.

기술 심층 분석

1

같은 모델, 같은 벤치마크, 다른 점수

Hugging Face 블로그의 「How UK AISI and EvalEval Are Making Benchmark Results Reproducible」(2026년 9월)에 따르면, AISI 는 EvalEval 의 공유 인프라를 써서 다섯 개 벤치마크(HealthBench·FrontierMath·Humanity's Last Exam·SWE-Bench Pro·Terminal-Bench 2.0)에 대한 여섯 개 프런티어 모델의 결과를 검증된 결과·맥락·설정 정보와 함께 공개했습니다. 이 자료는 벤치마크 성능이 추론 시점 연산량과 평가 프로토콜에 따라 어떻게 달라지는지를 다룬 AISI 의 논문에 딸려 있습니다. 글이 보여 주는 한 사례에서는 모델이 시도할 때마다 정답 여부를 알려 주는 조건을 두자, 토큰을 더 쓸수록 풀어내는 과제가 계속 늘었습니다. 글은 평가가 여러 형식과 매체로 흩어져 보고되고, 재현에 필요한 정보가 충분하지 않은 경우가 많으며, 평가를 다시 돌리는 것 자체가 감당하기 어려울 만큼 비쌀 수 있다고 지적합니다. 그래서 이들이 공개하는 것은 점수가 아니라 점수와 조건의 묶음입니다. 법률 AI 의 평가표도 같은 결함을 안고 있습니다. 정확도 몇 점이라는 숫자 옆에 질의 묶음의 판본, 검색 범위, 답변을 몇 번 생성해 어떻게 골랐는지가 없으면, 지난달과 이번 달의 숫자를 나란히 놓는 순간 조건의 차이가 성능의 차이로 둔갑합니다.

2

논문 단위가 아니라 주장 단위로 판정한다

「What We Learned by Reproducing 2,200 papers from ICML」(2026년 8월)은 반대편에서 같은 문제를 다룹니다. 19일 동안 1,200명이 넘는 참가자가 각자의 코딩 에이전트로 ICML 2026 논문 2,226편, 학회 전체의 34%를 재현하려 했고, 주최 측은 각 논문에서 핵심 주장을 뽑아 에이전트가 마흔 쪽짜리 PDF 가 아니라 확인 가능한 표적에서 출발하게 했습니다. 판정도 주장마다 따로 내렸습니다. 검증·반증·축소 규모 증거·판정 불가 넷 중 하나입니다. 그 결과 검토된 논문의 51%(1,103편)는 주장 하나 이상이 독립적으로 검증됐고, 23%(496편)는 주장 하나 이상이 반증되거나 다툼이 생겼습니다. 242편은 서로 다른 재현 팀이 같은 주장에 정반대 판정을 냈습니다. 주최 측의 표현대로 재현성은 이분법이 아니라 대립적입니다. 법률 답변도 한 덩어리가 아닙니다. 답변 하나에는 조문 인용, 판례 인용, 그 판례가 말했다는 법리, 기한과 금액 같은 수치, 그리고 결론이 들어 있습니다. 답변 전체에 '검증됨' 하나를 붙이면 그중 어느 주장이 확인됐고 어느 주장은 확인을 건너뛰었는지가 사라집니다.

3

짧게 끝난 확인은 틀린 주장을 통과시킨다

재현 챌린지에서 가장 교훈적인 사례는 반례가 늦게 나타난 정리입니다. 어느 논문은 특정 조건에서 토큰 입자들이 원점으로 모인다고 증명했는데, 세 독립 팀이 반례를 찾았고 위반이 처음 나타난 시점은 각각 224단계, 약 3,800단계, 6,416단계였습니다. 글은 이것이 다른 참가자들이 모두 그 주장을 '검증'한 이유를 깔끔하게 설명한다고 적었습니다. 유한한 구간만 본 확인이 너무 일찍 멈췄기 때문입니다. 또 다른 논문에서는 평가한 레이블 위치의 약 66%가 패딩 토큰이어서 성능 지표가 부풀려져 있었고, 초록에 적힌 품질 비용 3.1%는 바로잡으면 약 9.4%가 됐습니다. 법률 AI 의 검증에도 같은 함정이 있습니다. 원문 조회가 실패해 대조를 건너뛴 인용, 조문의 존재만 확인하고 그 조문이 정말 그 내용을 말하는지는 보지 않은 인용이 결과표에서 '실패 없음'으로 합쳐지면, 확인하지 않은 것이 확인된 것처럼 읽힙니다. 판정 기록에는 결론만이 아니라 확인이 어디까지 갔는지가 남아야 합니다.

4

반증도 검증 대상이다

챌린지 주최 측은 참가자 35명이 공식적으로 반증을 주장하자, 그 반증들을 다시 적대적으로 검증했습니다. 논문과 로그북을 다시 읽고, 수학을 다시 유도하거나 논문 본문만 보고 실험을 다시 구현했습니다. 그렇게 해서 반증이 확인된 경우도 있었지만, 거꾸로 재현하는 쪽이 틀린 경우도 있었습니다. 한 로그북은 논문의 방법이 기준선보다 두 배 느리다고 주장했는데, 궤적 하나당 시간과 50개 묶음당 시간을 비교한 산술 착오였고, 바르게 맞추자 참가자 자신의 데이터가 논문이 주장한 8배 속도 향상을 확인했습니다. 자동 판정기도 각 로그북의 자기평가를 신뢰하지 말라는 지시를 받고 모든 로그북을 다시 읽었습니다. 이 구조가 가능했던 것은 모든 재현이 작성 글·실행한 코드·산출물을 담은 기록으로 공개됐기 때문입니다. 감사 과정 자체가 감사 가능해야 한다는 원칙입니다. 법률 AI 에서 검사기가 어떤 인용을 막았다면, 그 차단도 틀릴 수 있는 판정입니다. 막은 이유와 대조한 원문이 함께 남아 있어야 사람이 그 차단이 옳았는지 다시 볼 수 있습니다.

기술적 트레이드오프

긴장 관계 주장마다 판정을 따로 남기고 그 판정의 조건까지 기록하면 저장해야 할 것이 늘고, 사용자에게 보여 줄 화면은 복잡해진다. 검증 표시 하나로 충분하던 자리에 판정 불가·축소 확인 같은 중간 상태가 드러나면 사용자는 오히려 불안해할 수 있다. 반대로 한 덩어리 표시를 유지하면 화면은 깔끔하지만, 확인을 건너뛴 주장과 확인된 주장이 같은 표시 아래 섞인다.

실무적 해소 기록과 표시를 나눕니다. 판정 기록은 주장 단위로, 조회 시각·대조한 원문의 판본·판정 축·확인을 건너뛴 이유까지 빠짐없이 남깁니다. 이것은 사람과 검사기가 나중에 다시 돌려 볼 재료이므로 간결함보다 완결성이 먼저입니다. 사용자 화면은 이 기록에서 필요한 만큼만 끌어옵니다. 결론이 직접 기대는 인용에 한해 확인됨과 확인하지 못함을 구분해 보여 주고, 나머지는 기록 링크로 남깁니다. 중간 상태를 숨기지 않되, 그것이 결론을 흔드는 자리에서만 앞에 내세우는 것입니다. 이렇게 하면 기록 비용은 늘지만 화면의 복잡도는 결론의 무게에 비례해서만 늘어납니다.

이 주장이 틀리는 조건

반증 조건 이 글이 옳다면 관측 가능한 예측이 하나 나옵니다. 조건 기록을 붙인 뒤에는 같은 질의 묶음을 다시 돌렸을 때 이전 결과와 어긋나는 판정의 상당수가 기록된 조건의 차이, 예컨대 원문 판본이나 조회 실패 여부로 설명되어야 합니다. 몇 달 동안 쌓인 재실행 결과에서 어긋남이 기록된 조건과 거의 무관하게 흩어져 있다면, 조건을 적는 일은 비교를 돕지 못한 것이고 이 글의 중심 주장은 틀렸습니다. 또 주장 단위 판정을 도입한 전후로 사람이 사후에 찾아내는 오인용의 수가 달라지지 않는다면, 답변을 주장으로 쪼개는 비용은 얻는 것 없이 기록만 늘린 셈입니다.

법마디 OS에 적용한다면

법마디 OS 는 답변과 데일리 콘텐츠의 법령·판례 인용을 국가법령정보센터 원문과 대조하고, 대조 결과를 통과·경고·차단으로 나눕니다. 이 과정에서 이미 지키고 있는 원칙이 하나 있습니다. 원문을 읽지 못해 판정하지 못한 인용은 '통과'가 아니라 '미측정'으로 따로 세고 로그에 그 수를 남긴다는 것입니다. 오늘의 두 발표는 이 원칙을 한 걸음 더 밀라고 요구합니다. 첫째, 미측정은 로그에만 있지 발행면에는 드러나지 않습니다. 원문 조회가 실패한 날에는 그날 판정의 상당 부분이 미측정일 수 있는데, 읽는 사람은 그것을 알 방법이 없습니다. 결론이 기대는 인용부터 확인됨과 확인하지 못함을 나눠 보여 주는 방향으로 다듬어 가려 합니다. 둘째, 원문 조회가 실패한 날에도 받아 둔 조문 캐시에 있는 법령은 그 캐시로 대조하고, 판정마다 어느 원문으로 쟀는지를 함께 적도록 법률상식의 조문 대조를 오늘 고쳤습니다. 캐시에 없는 법령은 여전히 미측정으로 남으므로 그 범위를 넓혀 가야 합니다. 셋째, 검사기가 막은 인용도 틀린 차단일 수 있으므로, 차단 사유와 대조한 원문 판본을 함께 남겨 사람이 다시 확인할 수 있게 하는 기록 형식을 정비하겠습니다. 어느 것도 새 기술이 아니라, 판정마다 그 판정을 낸 조건을 붙여 두는 일입니다.

기술적 함의

"점수는 조건이 붙어 있을 때만 비교가 되고, 검증은 주장 단위로 남을 때만 반박이 됩니다. 2천여 편의 논문을 다시 돌려 본 사람들이 확인한 것은 결국 기록의 형식이었습니다. 법률 AI 가 '검증됨'이라고 적을 때에도, 무엇을 어떤 조건에서 어디까지 확인했는지가 그 한 단어 뒤에 따라 다녀야 합니다."

참고 자료

칼럼니스트

지유

지유

최고기술책임자 (CTO · Chief Technology Officer)

실리콘밸리 유니콘 창업 멤버급 / AI 무결성 검증 분야 세계적 석학급

법마디 OS 무료로 경험하기
본 칼럼은 법마디 OS 기술팀의 관점이며, 특정 제품·기술에 대한 보증이나 법률 자문이 아닙니다.