Executive Summary

주요 수치

출처: Xiao & Cai, Follow the Policy, Fail the Benchmark, arXiv:2611.07042(2026) · BAR 저장소

아래 네 숫자는 분모가 다 다르다. 앞의 둘은 LegalBench 세금 문항 96개, 셋째는 RuleArena 세금 과제 300개, 넷째는 ConditionalQA 285개가 분모다. 같은 논문 안에서도 과제마다 다른 잣대로 재고 있으니 수치끼리 직접 더하거나 비교할 수는 없다.

LegalBench는 법률 추론을 재는 공개 벤치마크이고, 그 안의 SARA numeric 과제는 세금 사례를 주고 내야 할 세액이 얼마인지 묻는다. 정답은 금액 하나이고, 과제 설명은 답을 먼저 적으라고만 요구한다. 센트 단위를 적지 말라는 말은 어디에도 없다. 채점은 참조값의 10퍼센트 안에 들면 인정하는 것으로 설명돼 있다.

문제는 그 10퍼센트 비교에 들어가기 전에 답을 숫자로 바꾸는 단계에 있었다. LegalBench의 채점 함수를 저자들이 직접 읽어 적은 바로는, 원래 파서는 쉼표와 마침표를 지운 뒤 첫 숫자 덩어리를 음이 아닌 정수로 읽는다. 쉼표를 지우는 것은 천 단위 구분 기호를 떼어내는 정상 동작이다. 사고는 같은 줄에서 마침표까지 함께 지우는 데서 난다. 센트 두 자리가 정수부에 그대로 붙어, 모델이 적은 금액이 백 배로 부풀어 비교에 들어간다.

이 버그가 양방향으로 작동한다는 점이 고약하다. 저자들은 같은 문항에 답안 문자열을 손으로 지어 넣어 원래 채점기가 무엇을 인정하는지 확인했다. 참조값이 $259,487인 문항에 259487이라고 적으면 인정된다. 같은 금액을 $259,487.00으로 적으면 25948700이 되어 거부된다. 그런데 100배 작은 $2,594.87은 259487로 읽혀 인정된다. 센트까지 적은 정확한 답은 떨어지고, 자릿수를 한참 틀린 답이 붙는다. 채점기가 능력을 재기는커녕 답을 적는 습관을 재고 있었던 셈이다.

한 가지 더 있다. 원래 채점식은 모델이 적은 값 p와 참조값 r을 두고 |p/(r+0.1) − 1| < 0.1이 성립할 때 답을 인정한다. 참조값이 0인 문항에 이 식을 대 보면 p가 0.09에서 0.11 사이여야 통과한다. 낼 세금이 없어 0이라고 정확히 적은 답은 구조적으로 인정될 수 없다. 저자들은 이 결함을 파싱 문제와 따로 떼어 잰다. 96개 시험 문항 중 참조값이 0인 것은 넷이다.

두 결함이 겹치면 채점기의 천장이 어디까지 내려오는지도 저자들이 재 봤다. 96문항의 참조값을 그대로 답으로 적어 넣어 보니 원래 채점기는 92점을 줬다. 정답을 그대로 베껴 써도 만점이 나오지 않는다는 뜻이다. 떨어진 넷이 참조값 0인 문항이다. 저자들은 이 92를 모델 성적이 아니라 채점기 진단값이라고 못 박는다.

저자들은 Haiku 5.5, GPT6 Luna, Gemma 4 31B 세 모델에 문항마다 응답을 한 번씩 받아 두고, 그 응답을 그대로 보관한 채 채점 코드만 갈아 끼웠다. SARA는 벤치마크 저자가 제공한 입력 틀을 손대지 않고 썼고, TRAIN 행 넷을 뺀 TEST 96행 전부를 썼다. 저장된 응답은 네 과제를 합쳐 2,664건이다. 세금 과제 900건, SARA 288건, ConditionalQA 855건, OpenExempt 621건이다.

수정은 두 단계로 나뉘고, 단계마다 따로 쟀다. 1단계는 소수점을 살린 파서만 넣고 원래 공식을 그대로 둔 것이고, 2단계는 거기에 참조값이 0일 때 정확히 0으로 읽힌 답만 인정하는 규칙을 더한 것이다. 세 모델의 결과는 이렇다.

LegalBench SARA numeric 96문항 중 인정된 답의 수. 논문 표 1 오른쪽 블록. 새로 떨어진 답은 세 모델 모두 0건이다.

대부분의 상승은 1단계에서 나왔다. 소수점을 살리는 것만으로 Haiku가 8개에서 87개로 갔다. 2단계는 세 모델에 정확히 4개씩을 더했다. 앞서 본 참조값 0 문항 넷에 걸린 몫이고, 나머지 92개 판정은 2단계에서 하나도 바뀌지 않았다. 초록은 이 변화를 세 모델 각각 80퍼센트포인트 넘는 인정률 상승이라고 적는다.

왜 거의 전부가 걸렸는지는 응답을 세어 보면 나온다. 고친 파서가 응답에서 가장 먼저 찾아낸 금액이 소수였던 경우가 Haiku 82건, Luna 76건, Gemma 78건이다. 세 모델 모두 96문항 가운데 여든 안팎에서 센트를 적었고, 과제 설명이 금지하지 않은 그 습관이 원래 채점기에서는 그대로 오답이 됐다. 금액을 읽어 내지 못한 응답은 한 건도 없었다. 판정이 바뀐 241건을 갈라 보면 229건이 파싱에서, 나머지 12건이 0 처리에서 나왔다.

점수 자체보다 더 날카로운 것은 순서다. 원래 채점에서는 GPT6 Luna가 9개로 혼자 앞서 있었고 나머지 둘이 8개로 묶여 있었다. 채점을 고치자 Haiku 91개, Gemma 88개, Luna 87개가 되면서 맨 앞이던 모델이 맨 뒤로 내려갔다. 8과 9의 차이는 사실상 잡음이었는데, 그 잡음이 서열처럼 보였던 것이다.

같은 논문이 다른 벤치마크에서 찾아낸 결함은 채점기가 아니라 정답 쪽에 있었다. RuleArena는 세금, 항공, 농구 리그 규정 같은 실제 규칙 문서를 주고 사례에 적용하게 하는 벤치마크다. 그중 세금 과제의 정답은 사람이 적은 숫자가 아니라 참조 프로그램이 계산해서 내놓는다.

미국 세금 서식에는 어떤 줄의 계산 결과가 0보다 작아지면 음수를 그대로 쓰지 않고 0으로 적으라는 지시가 붙는다. 저자들이 바닥 규칙이라 부르는 것이고, 서식이 요구하는 계산 규칙의 일부다. 모델에게 주어진 과제 자료에도 적혀 있다. 논문이 사례로 든 문항의 22번 줄은 "18번 줄에서 21번 줄을 뺀다. 0 이하이면 -0-을 적는다"로 돼 있다. 그런데 RuleArena 세금 과제의 참조 프로그램에는 바로 그 바닥 규칙이 빠져 있었다. 음수가 그대로 남아 아래 줄의 계산을 끌고 내려가고, 그렇게 어긋난 최종 금액이 정답으로 등록된다.

그 문항에서 Haiku 5.5는 703달러라고 답했다. 서식이 시킨 대로 바닥 규칙을 적용한 값이다. 원래 정답표는 이 답을 틀렸다고 했고, 빠진 규칙을 되살린 정답표는 맞다고 했다. 모델의 답은 한 글자도 바뀌지 않았다. 흥미로운 대목은 같은 벤치마크 안에서 규칙을 읽는 두 부품이 서로 달랐다는 점이다. 규칙 단위로 분석하는 쪽은 바닥 규칙을 적용하는데, 최종 금액을 내놓는 프로그램만 그것을 건너뛰고 있었다.

바닥 규칙만 복원하고 그 아래 금액을 다시 계산하자 참조값 300개 중 27개가 바뀌었다. 채점 쪽은 손대지 않았다. 세금 과제의 인정 기준은 상대 오차 10만분의 1 수준이라 사실상 정확히 맞아야 하는데, 그 기준도 그대로 뒀다. 300개 문항 전부가 분모에 남아 있고, 판정이 달라진 사례는 전부 그 27개 안에서 나왔다.

어느 27개인지는 모델에게 응답을 받기 전에 참조 프로그램만 다시 돌려 정해 뒀다. 어떤 모델이 어디서 점수를 얻을지가 선정에 끼어들 자리가 없었다는 뜻이다. 문항의 무게가 모두 같으니 이 수정이 고정된 응답 집합의 성적을 움직일 수 있는 폭도 미리 정해진다. 위아래로 최대 9퍼센트포인트다. 그 좁은 폭 안에서 모델 사이의 거리가 어떻게 달라지는지가 다음 표에 있다.

RuleArena 세금 과제 300문항 중 참조값과 일치한 답의 수. 논문 표 1 왼쪽 블록.

여기서 드러난 것은 모델 간 격차의 왜곡이다. Haiku와 Gemma의 정답 수 차이가 원래 채점에서는 14문항이었는데 고친 뒤에는 4문항으로 줄었다. 두 모델의 실력 차이가 세 배 넘게 부풀려져 있었다는 뜻이다. 세 모델의 서열 자체는 바뀌지 않았지만, 서열 사이의 거리는 상당 부분 정답표의 결함이 만든 것이었다.

저자들은 그 61건의 새 인정을 그냥 넘기지 않았다. 응답 본문을 그대로 읽어 둘로 갈랐다. 48건은 모델이 바닥 규칙을 적용한다고 응답에 명시했고, 13건은 그 말 없이 소계가 0이라는 결과만 보여 줬다. Haiku에서 하나 생긴 탈락도 후자에 속한다. 소계를 0으로 두긴 했는데 다른 계산의 오차가 서로 상쇄되는 바람에 최종 금액이 원래의 틀린 정답과 우연히 맞아떨어진 경우다. 저자들은 그 한 건을 바닥 규칙을 못 지킨 사례로 세지 않는다고 따로 적어 둔다.

감사 대상은 아홉 항목이다. RuleArena, OpenExempt, LegalBench SARA, DeonticBench, ConditionalQA, ShARC, PolicyGuardBench, WorkArena++, TheAgentCompany. 고른 기준은 하나다. 주어진 규칙 문서를 사례에 적용하는 과제이면서, 입력이나 코드나 채점기를 외부에서 들여다볼 수 있는 것. 방법은 셋을 섞었다. 출처 추적, 프로그램 실행, 통제 검사다.

논문은 찾아낸 결함을 네 갈래로 정리한다. 앞의 세 절에서 본 것은 그중 둘뿐이고, 나머지 둘은 성격이 다르다.

• 참조 답이 과제가 요구한 조건을 어긴다. 3절의 RuleArena 세금이 여기 들어간다. 파산 면제 과제 OpenExempt도 같은 갈래인데, 어긋난 참조값이 뒤 단계의 입력으로 넘어간다는 점이 하나 더 붙는다. 5절에서 따로 본다.
• 결함이 있는 참조 프로그램이 검증을 통과한다. DeonticBench의 한 세금 사례에서 참조 프로그램은 부양가족을 두 번 세고 납세자 본인 공제는 빠뜨린다. 두 오류가 서로 상쇄돼 공제 합계 4,000달러가 그대로 맞고, 저자들의 채점기는 그 답을 인정한다. 결과만 보면 프로그램이 옳아 보인다.
• 채점이 틀리거나 검사가 빠진다. 1절의 LegalBench가 여기다. TheAgentCompany의 예산 과제는 더 노골적이다. 담당자에게 장비 총액과 예산이 충분한지를 함께 알려야 하는 과제인데, 지어 넣은 답변으로 공식 채점 사슬을 돌려 보니 예산 판단을 빼거나 거꾸로 뒤집어도 총액 문자열만 맞으면 만점이 나왔다. WorkArena++의 한 일정 과제는 요청 사이 간격을 한 시간 이내로 요구하면서 검증기는 24시간 기준으로 통과시킨다.
• 모델이 볼 수 있는 입력만으로는 도달할 수 없는 목표값이 정답으로 걸려 있다. PolicyGuardBench에는 보이는 입력이 완전히 똑같은데 이진 정답이 서로 엇갈리는 묶음이 279개, 레코드로 780건 있다. 중복을 걷어낸 엄격판에도 시험 분할에만 60개 묶음 143건이 남는다. 입력만 보고 결정하는 어떤 방식도 최소 61건은 틀리게 돼 있다. 저자들은 이것이 정답 61개가 틀렸다는 판정이 아니라 일관성의 하한이라고 선을 긋는다.

아홉 항목이 모두 같은 처분을 받지는 않았다. 수정 코드가 함께 나온 것은 다섯 과제에 걸친 일곱 개 부품이다. RuleArena 세금과 항공과 농구, LegalBench SARA numeric, ConditionalQA가 여기 들어가고, 항공은 정책 전사 오류와 금액 채점과 빠진 최소 비용 목표를 따로 손봐야 해서 혼자 세 부품이다. 나머지 항목은 수정 없이 감사 증거로만 공개했다. 농구 과제는 216개 기록 중 두 개 필드만 고쳤고 이진 판정은 하나도 바뀌지 않았다. 결함이 있어도 점수가 움직이지 않는 경우를 통제 사례로 남긴 것이다.

반대 방향 사례가 ConditionalQA에 있다. 이 과제의 원래 집계는 모델이 답을 제출하지 않은 문항을 분모에서 빼고 제출된 것만 가지고 점수를 냈다. 보관된 응답에서 그런 결측이 77건 나왔다. Luna 24건, Gemma 53건이다. 제출이 없으면 0점으로 치고 285개 문항 전부를 분모에 두는 방식으로 바꾸자 두 모델의 점수가 내려갔다. Luna의 정확 일치율은 52.34%에서 47.93%로, Gemma는 58.02%에서 47.23%로 떨어졌다. 결측이 하나도 없던 Haiku는 58.63%에서 한 치도 움직이지 않았다.

이 대목에는 단서가 하나 붙는다. 저 결측은 저자들이 쓴 JSON 응답 형식을 모델이 지키지 못해 생긴 것이지 벤치마크의 정답이 틀려서가 아니다. 그러니 내려간 점수가 재는 것은 결함의 크기가 아니라 집계 방식의 선택이다. 저자들도 그것을 확인하려고 모든 문항에 답이 들어 있는 외부 제출 파일 여덟 개를 두 채점기에 똑같이 넣어 봤고, 네 지표와 범주별 분모가 전부 일치했다. 결측이 없으면 두 채점기는 아예 구별되지 않는다.

여기까지는 점수 이야기였다. 채점을 고치면 숫자가 달라지고, 때로는 서열도 달라진다. 그런데 벤치마크의 결함이 성적표 밖으로 걸어 나가는 자리가 있다. 긴 계산을 단계로 쪼개 놓고, 앞 단계의 답을 미리 풀어서 모델에게 쥐여 준 다음 뒷 단계를 묻는 과제다. 그 쥐여 준 답이 틀려 있으면 어떻게 되는가.

OpenExempt가 그런 과제다. 파산 신청자가 채권자에게서 지킬 수 있는 재산을 면제 조항별로 계산하게 한다. 중간 단계에서 자산마다 조항마다 보호 가능한 최대 금액을 구해 두고, 그 값을 뒤 단계의 입력으로 넘긴다. 그런데 이 중간 계산은 한 조항을 한 번만 적용한다. 같은 8,200달러짜리 차량에 같은 조항을 걸었을 때 중간 답은 4,450달러를 최대라고 적는데, 최종 배분은 같은 조항을 한 번 더 써서 8,200달러를 전부 지킨다. 최대라고 적어 둔 값을 최종 답이 넘어선다. 이렇게 어긋나는 항목이 이 단계 기록 100건 중 33건에 걸쳐 38개 있다. 저자들은 이것이 두 참조 자료가 서로 어긋난다는 뜻일 뿐이라고 적는다. 둘 중 어느 금액이 법적으로 옳은지는 가리지 않았다.

저자들은 이 중간 답이 실제 모델 결정을 움직이는지 실험으로 갈라 봤다. 전제를 분명히 박아 과제를 고쳐 썼다. 부부가 함께 신고하고, 둘 다 연방 면제를 쓰고, 모든 자산을 절반씩 소유하고, 그 자산에 걸린 담보는 없다. 그 위에서 연방 면제를 적용한 뒤에도 끝내 보호받지 못하는 최소 총액을 묻는다. 69개 기록에 세 조건을 돌렸다. 공개된 중간 답을 그대로 건네는 조건, 전제에 맞게 다시 계산한 중간 답을 건네는 조건, 중간 답을 아예 주지 않는 조건이다. 정책도 질문도 사건 사실도 세 조건에서 같다.

조건마다 응답을 새로 받아 채점했다. 전제를 보강한 OpenExempt 최소 비보호액 과제, 69문항 기준. 논문 표 3. 인정받으려면 지정한 JSON 형식을 지키고 목표값과 0.005달러 안에 들어야 한다.

가장 눈에 띄는 칸은 맨 오른쪽이다. 중간 답을 하나도 주지 않자 세 모델 모두 69문항을 다 맞혔다. 공개된 중간 답을 건넸을 때 Haiku는 50개로 내려앉는다. 도와주려고 쥐여 준 값이 열아홉 번 발목을 잡은 것이다. 저자들은 응답을 받기 전에, 건네준 금액을 상한으로 받아들이면 최종 답이 달라지는 문항 19개를 따로 추려 뒀다. Haiku가 떨어뜨린 19건 중 16건이 그 안에 들어 있다. 모델이 건네받은 값을 믿고 자기 계산의 천장으로 썼다는 뜻이다.

모든 모델이 같은 방향으로 움직이지는 않았다. 중간 답을 고쳐 주자 Haiku는 50에서 68로 올랐지만 Gemma는 65에서 64로 오히려 하나 내려갔다. Luna의 새 탈락 한 건은 금액을 맞게 적고도 JSON 형식을 어긴 경우이고, Gemma의 세 건은 형식은 지켰는데 금액이 틀렸다. 범위도 좁혀 읽어야 한다. 이것은 저자들이 전제를 얹어 고쳐 쓴 과제이지 OpenExempt 원본 과제가 아니고, 문항과 조건마다 응답을 한 번씩만 받았으며 도구는 쓰지 않았다. 논문도 응답 변화 하나하나를 원본 벤치마크의 확정된 결함 탓으로 돌릴 수는 없다고 적는다.

학습 데이터의 품질은 누구나 의심한다. 라벨이 맞는지, 출처가 깨끗한지, 분포가 치우치지 않았는지를 묻는 절차는 어느 조직에나 조금씩은 있다. 그런데 그 데이터로 만든 모델을 평가하는 코드의 품질을 같은 강도로 의심하는 팀은 드물다. 채점기는 대개 한 사람이 며칠 만에 쓰고, 한번 돌아가기 시작하면 다시 열리지 않는다. 그리고 의사결정은 그 코드가 뱉은 숫자를 보고 내려진다.

이번 감사가 보여 준 것은 결함의 크기가 아니라 결함이 숨는 방식이다. LegalBench의 버그는 코드 한 줄짜리이고, 두 달 전 이미 공개 이슈로 보고돼 있었다. 그런데도 그 채점기로 나온 숫자는 계속 인용된다. 잘못된 점수는 이상하게 보이지 않기 때문이다. 8점은 그냥 낮은 점수처럼 보이고, 낮은 점수에는 설명이 쉽게 붙는다. 모델이 세법을 모른다거나, 긴 계산에 약하다거나 하는 식이다. 실제로는 센트를 적었다는 이유로 떨어진 답이 대부분이었다.

이 블로그에서 이웃한 자리를 다룬 글이 몇 편 있다. 정답지 오류로 AI 에이전트 실력을 낮게 매긴 벤치마크는 정답표 자체가 틀린 경우였고, 이번 LegalBench 사례는 정답표가 멀쩡한데 그것을 읽는 코드가 틀린 경우다. 풀지 않고도 만점을 받는 벤치마크 여덟 개는 누군가 의도적으로 허점을 파고드는 이야기였지만, 여기서는 아무도 공격하지 않았는데 점수가 틀렸다. 악의 없는 버그 하나가 공격보다 더 넓게 퍼진다.

평가 체계를 가진 조직이라면 이 논문에서 가져갈 절차가 넷 있다.

• 답을 숫자나 범주로 바꾸는 단계를 따로 시험하는가. 정답과 똑같은 답, 소수점이 붙은 답, 0인 답, 빈 답을 일부러 넣어 채점기가 무엇을 인정하는지 먼저 확인한다. 저자들이 한 일도 그것이다.
• 모델 응답을 원문 그대로 보관하는가. 응답이 남아 있어야 채점을 고쳤을 때 모델을 다시 부르지 않고 옛 점수와 새 점수를 나란히 놓을 수 있다. 응답을 버리고 점수만 남기면 채점 결함이 발견돼도 과거를 되짚을 방법이 없다.
• 저장된 점수를 계산의 입력으로 쓰는가, 검증용 단언으로 쓰는가. BAR의 재현 도구는 보관된 응답을 매번 처음부터 다시 채점하고 그 결과를 옛 점수와 대조해, 하나라도 어긋나면 실패로 끝낸다. 점수를 믿고 넘어가는 대신 매번 다시 증명하는 구조다.
• 모델에게 중간 계산을 풀어서 건네는 자리가 있는가. 그 값이 틀리면 점수만 틀리는 것이 아니라 모델의 결론이 틀린다. 5절의 실험에서는 아무것도 건네지 않은 조건이 가장 정확했다. 건네줄 중간값은 최종 정답표와 같은 강도로 검증하거나, 그럴 수 없다면 건네지 않는 쪽이 안전하다.

1차 출처

• 1.Xiao, Y. & Cai, Y. (2026). "Follow the Policy, Fail the Benchmark: Auditing and Revising Policy-Based Decision Benchmarks." arXiv:2611.07042 [cs.CL], 2026년 11월 4일 제출. 본문 전체의 수치·인용·분류 틀이 이 논문에서 나왔다.
• 2.Xiao, Y. & Cai, Y. BAR — Benchmark Audit and Revision 저장소(MIT License, v0.2.0). github.com/SugarRuy/BAR-Policy-Decision. 감사 증거와 수정 코드, 재현용 응답 아카이브(2,664건)를 공개한다. README와 docs/REPRODUCING.md에서 2절·3절·5절의 표 수치를 직접 확인했다.

페블러스 블로그 인접 글

• 3.정답지 오류로 AI 에이전트 실력을 낮게 매긴 벤치마크(6절) · 풀지 않고도 만점을 받는 벤치마크 여덟 개(6절)