비교 가능성의 조건: 추론 프로토콜과 누출 없는 평가
같은 점수라도 어떤 추론 절차로 얻었는지 밝히지 않으면 비교할 수 없습니다. 8월 초 공개된 세 편의 논문이 평가의 최소 조건을 다시 정의합니다.
초록 모델 성능 발표는 대개 하나의 숫자로 요약됩니다. 그러나 그 숫자를 만든 추론 절차와 평가 데이터의 구성을 밝히지 않으면 서로 다른 시스템을 같은 자로 잰 것이 아닙니다. 2026년 8월 초 arXiv에 공개된 세 연구는 이 문제를 각각 다른 각도에서 다룹니다. 하나는 테스트타임 스케일링을 단일 예산 변수로 뭉뚱그리면 비교가 불가능해진다는 점을, 다른 하나는 법률 검색 데이터셋의 누출과 축소가 성능을 부풀린다는 점을, 마지막 하나는 답이 아직 존재하지 않는 시점에 묻는 방식으로 누출을 원천 차단한 설계를 보고합니다. 이 글은 세 연구를 관통하는 비교 가능성의 조건을 정리하고, 검증을 출력 앞에 두는 우리 구조에 무엇을 적용해야 하는지를 다룹니다.
성능 비교표를 볼 때 우리가 실제로 확인하는 것은 무엇일까요. 대개는 모델 이름과 점수뿐입니다. 그런데 Hariri 등이 8월 4일 공개한 'Test-Time Scaling in Reasoning LLMs'는 그 두 가지만으로는 아무것도 비교할 수 없다고 말합니다. 저자들은 테스트타임 스케일링이라는 말이 지금은 서로 구조가 다른 여러 알고리즘을 한꺼번에 가리킨다고 지적합니다. 하나의 추론 경로를 길게 늘이는 방식, 완성된 후보를 여럿 뽑아 투표나 검증으로 합치는 방식, 아직 완성되지 않은 중간 상태를 탐색하는 방식은 통계적 구조도 연산 계산법도 실패 양상도 다릅니다. 그런데도 이들을 하나의 예산 값으로 뭉뚱그리거나, 점수를 낸 추론 프로토콜을 빼고 정확도만 보고하면 연구 사이의 비교가 어려워진다는 것입니다. 이 지적은 실무에서 훨씬 날카롭게 작동합니다. 어떤 모델이 우리 업무에 더 맞는지를 벤더가 제시한 표로 판단해야 하는 쪽에게, 프로토콜이 빠진 점수는 판단 근거가 아니라 마케팅 자료에 가깝기 때문입니다.
핵심 기술 개념
테스트타임 스케일링
학습이 끝난 모델에 추론 시점의 연산을 더 써서 더 어려운 문제를 풀게 하는 기법군입니다. 논문은 이를 단일 경로 순차 확장, 완성 후보를 모아 줄이는 리프 단위 확장, 접두 상태를 탐색하는 접두 단위 확장의 세 구조로 구분합니다.
프로토콜 정합 보고
점수를 낼 때 사용한 추론 절차와 소비한 연산, 불확실성을 함께 적어 같은 조건에서 비교할 수 있게 하는 보고 방식입니다. 논문은 평가 대상을 모델이 아니라 추론 시스템 전체로 보아야 한다고 제안합니다.
핀사이트
판결문 전체가 아니라 특정 문단을 지목해 인용하는 실무 방식입니다. LegalPincite는 기존 공개 법률 검색 데이터셋 대부분이 이 문단 단위 인용 주석을 갖고 있지 않다는 점을 문제로 삼습니다.
데이터 누출
평가 질의 안에 정답 단서가 남아 있거나 정답이 이미 공개되어 모델이 기억으로 맞힐 수 있는 상태입니다. 누출이 있으면 검색 능력이 아니라 기억력을 재게 되어 성능이 부풀려집니다.
기술 심층 분석
하나의 예산 값으로 뭉뚱그린 순간 비교는 끝난다
Test-Time Scaling 논문의 첫 기여는 개념 정리입니다. 저자들은 테스트타임 스케일링을 자기회귀 모델이 암묵적으로 갖는 접두 트리 위에서의 예산 제약 추론으로 형식화하고, 구조적으로 세 가지 체제를 구분합니다. 하나의 궤적을 따라 사고를 길게 잇는 단일 궤적 순차 확장, 완성된 후보들을 만들어 마지막에 하나로 줄이는 리프 단위 확장, 완성되지 않은 부분 상태를 탐색하는 접두 단위 확장입니다. 이 셋은 같은 연산량을 써도 통계적 성질이 다릅니다. 후보를 여럿 뽑아 다수결로 줄이는 방식은 오류가 서로 독립일 때만 이득을 보고, 단일 궤적을 늘이는 방식은 초반 판단이 틀리면 그 위에 계속 쌓습니다. 그래서 저자들은 이들을 교환 가능한 것으로 취급하거나 하나의 스칼라 예산으로 표현하면 연구 간 결과 비교가 어려워진다고 못 박습니다. 실무 번역은 간단합니다. 우리가 어떤 모델의 점수를 다른 모델과 나란히 놓으려면, 두 숫자가 같은 체제에서 나왔는지를 먼저 확인해야 합니다. 확인할 수 없다면 그 표는 순위표가 아니라 각자의 자기 보고를 모아 둔 목록일 뿐입니다.
평가 대상은 모델이 아니라 추론 시스템 전체다
두 번째 기여는 평가의 단위를 옮긴 것입니다. 논문은 평가되는 객체를 추론 시스템 전체로 보고, 종단 성능과 후보 뱅크 진단을 분리하는 평가 원칙을 제시합니다. 즉 '이 모델이 얼마나 똑똑한가'와 '이 절차가 후보를 얼마나 잘 만들고 잘 고르는가'는 다른 질문이며, 섞으면 원인을 못 찾는다는 것입니다. 저자들은 반복 샘플링에서 흔히 쓰는 지표들을 복원하거나 상한을 줄 수 있는 좌표계로서 평가 프로파일을 도입하고, 연산량과 불확실성을 프로토콜에 맞추어 보고할 것을 규정합니다. 이 구분은 법률 시스템 설계에 그대로 옮겨 옵니다. 우리 파이프라인에서 최종 품질은 생성기 하나가 아니라 검색, 그라운딩, 생성, 검증 게이트가 합쳐진 결과입니다. 어느 한 단계를 바꾸고 종단 점수만 보면 개선인지 상쇄인지 알 수 없습니다. 실제로 우리는 검증 게이트가 살아 있을 때 근거를 더 많이 다는 변경이 오히려 미검증 인용을 늘려 점수를 떨어뜨리는 경우를 겪었습니다. 종단 점수와 단계별 진단을 함께 보지 않으면 그 인과를 짚어낼 수 없습니다.
재현 가능성에는 두 종류가 있다
세 번째 기여는 재현 가능성의 정의를 쪼갠 것입니다. 논문은 추론 프로토콜에 대한 재현 요건을 규정하면서 정확한 재생과 분포적 재현을 구분하고, 각각을 뒷받침하는 데 필요한 산출물이 무엇인지 정리합니다. 정확한 재생은 같은 입력에 같은 출력이 나오도록 난수 시드와 실행 조건까지 고정하는 것이고, 분포적 재현은 개별 출력은 달라도 성능 분포가 통계적으로 같음을 보이는 것입니다. 두 요구는 필요한 기록이 다릅니다. 앞의 것은 실행 흔적 전체를, 뒤의 것은 충분한 반복 횟수와 분산 정보를 요구합니다. 법률 영역에서 이 구분이 중요한 이유는 감사 때문입니다. 어떤 답변이 왜 그렇게 나왔는지를 사후에 설명해야 할 때, 우리에게 필요한 것은 대체로 정확한 재생 쪽입니다. 그러려면 모델 이름과 온도 값만이 아니라 어떤 근거가 어떤 순서로 주입됐고 어떤 검증 결과가 어느 문장을 지웠는지가 함께 남아 있어야 합니다. 재현 가능성은 연구 윤리의 문제가 아니라 설명 책임의 하부 구조입니다.
법률 검색 데이터셋의 누출과 축소가 성능을 부풀린다
Rampisela 등이 같은 날 공개한 LegalPincite는 평가의 다른 쪽 끝을 짚습니다. 법률 정보 검색의 흔한 과제는 판례 모음에서 관련 있는 자료를 찾는 것인데, 실무는 특정 문단을 지목하는 핀사이트를 요구하는 반면 공개 데이터셋 대부분은 문단 수준 인용 주석을 갖고 있지 않습니다. 더 큰 문제는 그런 주석을 가진 소수의 공개 데이터셋에도 질의 텍스트에 인용 정보가 남아 있는 누출이 있고, 인용하지도 인용되지도 않은 문단은 코퍼스에서 아예 빼 버린다는 점입니다. 저자들은 이 조합이 비현실적이고 지나치게 단순화된 검색 환경을 만들어 성능을 부풀릴 수 있다고 지적합니다. 이에 대응해 이들은 유럽연합사법재판소 판결문으로 데이터셋을 구축하면서 인용 정보를 지운 마스킹 질의, 모든 문단을 포함한 코퍼스, 판례 및 문단 수준의 정답 인용을 함께 제공하고 일부는 전문가 검증을 거쳤습니다. 판례 대 판례, 문단 대 판례, 문단 대 문단의 여러 수준에서 평가할 수 있게 한 점이 핵심입니다. 우리에게 이는 남 얘기가 아닙니다. 검색 대상에서 노이즈 문단을 걷어 내면 내부 지표는 좋아지지만 실제 사용자가 마주하는 난이도는 그대로이기 때문입니다.
누출은 걸러 내는 것이 아니라 설계로 막는 것이다
Wang 등의 WorldCup Arena는 누출 문제를 정반대 방향에서 해결합니다. 예측 능력을 재는 벤치마크는 거의 언제나 회고적이라 사건은 이미 일어났고 답은 웹 어딘가에 있으며, 그래서 평가는 암기로부터 자신을 방어해야 합니다. 저자들은 반대 설계를 택했습니다. 2026년 월드컵 39일 동안 여섯 개 프런티어 모델에게 매 경기 킥오프 전에 예측 카드를 채우게 했습니다. 질문을 던지는 시점에 답이 존재하지 않았으므로 이 평가는 걸러 내기가 아니라 구성상 누출이 없습니다. 결과에서 우리 설계에 직접 닿는 관찰이 하나 있습니다. 여섯 시스템은 서로 맞을 때보다 서로 의견이 일치할 때가 훨씬 잦았고, 그래서 다수결이 아무런 이득을 주지 않았다는 것입니다. 앞의 논문이 리프 단위 확장의 전제로 지목한 오류 독립성이 실제로는 잘 성립하지 않는다는 실증인 셈입니다. 모델을 여러 개 세워 투표시키는 방식으로 환각을 줄이겠다는 설계는 이 지점에서 무너집니다. 서로 같은 방향으로 틀리기 때문입니다. 우리가 검증을 모델의 합의가 아니라 외부 권위 대조에 맡기는 이유가 여기에 있습니다.
기술적 트레이드오프
긴장 관계 프로토콜을 남기고 누출 없는 평가를 구성하려면 기록과 운영 비용이 늘어난다. 반대로 가볍게 가면 내부 지표는 빨리 얻지만 그 지표가 실제 사용자 경험과 어긋나기 시작한다. 특히 문단 단위 정답과 전 문단 코퍼스를 유지하는 일은 검색 난이도와 지연을 함께 끌어올린다.
실무적 해소 두 축을 분리해 비용을 다르게 매기는 것이 답입니다. 상시 운영 경로에서는 종단 지표와 검증 통과율만 가볍게 남기고, 변경을 판단할 때만 프로토콜을 고정한 비교 실행을 별도로 돌립니다. 데이터셋 쪽도 마찬가지여서, 노이즈 문단을 걷어 낸 축소 코퍼스는 회귀 감지용 으로만 쓰고 배포 판단은 전 문단 코퍼스에서 내립니다. 즉 빠른 지표는 변화를 감지하는 데 쓰고, 비싼 지표는 결정을 내리는 데만 씁니다. 모든 실행에 같은 엄밀성을 요구하면 결국 아무 실행도 하지 않게 됩니다.
법마디 OS에 적용한다면
우리 구조에 옮기면 세 가지 작업이 나옵니다. 첫째, 품질 측정의 단위를 모델이 아니라 파이프라인 전체로 고정합니다. 생성기를 교체하는 변경이든 검색 단계를 손보는 변경이든 종단 점수와 함께 단계별 진단을 남겨, 근거를 더 많이 다는 변경이 검증 통과율을 떨어뜨리는 상쇄를 즉시 볼 수 있게 합니다. 둘째, 재현 기록의 범위를 넓힙니다. 지금도 어떤 인용이 검증을 통과했고 어떤 문장이 제거됐는지는 남지만, 어떤 근거가 어떤 순서로 주입됐는지까지 함께 남겨야 정확한 재생이 가능해집니다. 이는 설명 책임의 요구이기도 합니다. 셋째, 평가 데이터의 난이도를 실제와 맞춥니다. LegalPincite가 지적한 축소와 누출은 우리 내부 지표에서도 똑같이 일어날 수 있으므로, 회귀 감지용 코퍼스와 배포 판단용 코퍼스를 분리해 운영합니다. 그리고 이 세 작업의 방향은 모두 같은 곳을 가리킵니다. 모델을 바꿔도 남는 계층에 품질의 책임을 두는 것입니다. 다수결이 이득을 주지 못한다는 관찰은 이 원칙을 다시 확인해 줍니다. 여러 모델을 세우는 것보다 하나의 검증 계층을 튼튼히 하는 편이 낫습니다.
기술적 함의
- 성능 주장을 받을 때 점수보다 프로토콜을 먼저 묻는다. 추론 체제, 소비 연산, 반복 횟수, 제3자 검증 여부가 빠진 표는 순위표가 아니라 자기 보고 목록으로 취급한다.
- 내부 평가 코퍼스에서 인용되지 않은 문단을 빼지 않는다. 축소된 코퍼스의 점수는 회귀 감지용으로만 쓰고, 배포 판단은 실제 사용자가 마주하는 전체 코퍼스에서 낸다.
- 환각 통제를 모델 간 다수결에 맡기지 않는다. 시스템들은 맞을 때보다 서로 같을 때가 잦으므로, 판정은 합의가 아니라 외부 권위 대조와 출력 단계 차단에 둔다.
"점수는 주장이고 프로토콜은 근거입니다. 근거를 요구하는 습관이 결국 우리가 만드는 시스템의 바닥을 결정합니다."
