모델을 바꾸기 전에 재는 법

01 · 발단

남의 저울로 내 결정을 내리고 있었다

이 시스템은 하루에 수십 개의 하위 작업을 LLM에 위임한다. 한국어 금액 문자열 파싱, 코드 리뷰에서 심어 둔 버그 찾기, 깨진 기획 문서 복원 같은 것들이다. 작업마다 모델이 배정되어 있고, 배정은 곧 돈이다. 문제는 새 모델이 몇 주 간격으로 나온다는 것. 나올 때마다 같은 질문이 돌아온다. 바꿔야 하나, 말아야 하나.

처음에는 벤더 벤치마크와 리더보드를 봤다. 곧 두 가지가 걸렸다. 첫째, 그 점수는 남의 과제 분포 위의 점수다. 리더보드 상위 모델이 내 한국어 파서에서도 최선이라는 보장은 어디에도 없다. 둘째, 공개 벤치마크 자체가 흔들리고 있었다. OpenAI 는 2026년 7월 감사에서 한 유명 코딩 벤치마크의 공개 과제 중 약 30%가 결함이라고 판정하고 사용 권고를 철회했다. 결함의 최다 두 종류는 과잉 엄격 테스트 (프롬프트에 없는 구현 세부를 검사)와 과소 명세 프롬프트였다. 남의 저울은 내 작업을 모르고, 심지어 저울 자체가 고장나 있을 수 있다.

그래서 저울을 직접 만들었다. 거창한 것이 아니다. 내 실제 작업에서 파생한 과제 네 종, 결정론 게이트, 결과가 쌓이는 원장 하나. 대신 규칙을 계약으로 박았다. 이 글은 그 계약이 넉 주 동안 실제 배정 결정 세 건을 어떻게 통과시켰고, 그 과정에서 저울 자신이 두 번 의심받고 한 번 은퇴 판정을 받은 기록이다.

02 · 계약

저울의 네 가지 규칙

측정 도구는 규칙이 없으면 원하는 답을 돌려주는 기계가 된다. 넉 주를 버틴 것은 측정 코드가 아니라 다음 네 계약이었다.

규칙 1. 능력과 신뢰도를 분리한다. 같은 과제를 세 번 돌렸을 때 셀 평균 통과율(pass@1)은 능력을 말하고, 세 번 전원 통과(pass^3)는 신뢰도를 말한다. 배정 결정이 물어야 하는 것은 후자다. "이 모델이 이걸 할 수 있는가"가 아니라 "매번 되는가". 반복 수가 부족한 지표는 아예 보고하지 않는다.

규칙 2. 스크리닝은 N=1, 인용은 N=3. 한 번 돌린 숫자는 후보를 거르는 데만 쓰고, 결정 근거로 문서에 적는 숫자는 반드시 세 번 반복 측정한 것만 쓴다. 이 규칙이 왜 필요한지는 §04에서 숫자로 보인다. 만들 때는 절약 장치라고 생각했는데, 실제로는 오판 방지 장치였다.

규칙 3. 품질이 동률일 때만 비용을 판정한다. 게이트 통과가 같은 모델들 사이에서만 토큰·시간·비용으로 승자를 가린다. 품질을 비용으로 사는 트레이드오프는 이 저울의 판정 대상이 아니다. 그리고 비용 숫자에는 캐비엇이 붙는다. 단가표 × 토큰의 추정치이고, 캐시 토큰 클래스를 분리하지 못하므로 서열 비교 전용이며, 청구액이 아니다.

규칙 4. 저울과 개선기를 분리한다. 측정 저장소는 설정 저장소를 직접 수정할 수 없다. 레이스가 끝나면 원장 집계로 제안 문서 초안만 자동 생성되고, 제안 작성과 승인과 반영은 사람이 한다. 개선하는 쪽이 자기 채점표를 소유하는 순간 점수는 오르고 역량은 제자리인 루프가 시작되기 때문이다. 이 원칙 때문에 두 저장소는 물리적으로 분리되어 있고, 측정 쪽에서 설정 쪽으로 가는 자동 경로는 만들지 않았다.

저울 구성 (2026-07 기준)
과제      : 변별 4종 — 한국어 금액 파싱 · 구간 겹침 계산 · 리뷰 버그 적중 · 기획 복원
게이트    : 결정론 (보이는 테스트 + 채점 시 주입되는 holdout 테스트 + 형식 검사)
원장      : append-only JSONL — 같은 원장에서 같은 리포트가 재생성된다
판정 LLM  : 없음 — pass/fail 은 전부 결정론 게이트, LLM 심판은 원장에 섞지 않는다

마지막 줄은 EV-003 과 이어진다. LLM 심판의 판정이 배치 순서만 바꿔도 흔들린다는 것을 별도 측정으로 확인했기 때문에, 이 저울의 pass/fail 원장에는 LLM 의 의견이 들어가지 않는다. 심판 점수를 쓰게 되더라도 별도 원장에 참고 전용으로 두기로 사전 규율을 등록해 두었다.

03 · 저울 검증

첫 실패 셀은 모델이 아니라 저울의 결함이었다

변별 과제를 처음 돌린 날(7월 3일), 두 모델이 같은 지점에서 나란히 실패했다. 구간 겹침 과제의 holdout 테스트 중 "역순 기간 거부" 항목. 순진하게 읽으면 "두 모델이 엣지 케이스에 약하다"는 발견이다. 그렇게 적을 뻔했다.

포렌식을 하니 다른 그림이 나왔다. 과제 스펙의 규칙 3(역순 기간이면 예외를 던져라)과 규칙 4(기간이 1개면 0을 반환하라)가 역순 기간 1개짜리 입력에서 서로 충돌하고 있었다. 동반 실패한 두 모델 중 포렌식으로 확인한 쪽(opus)은 검증 로직을 제대로 갖고 있었고, 규칙을 한쪽으로 해석했을 뿐이다. 테스트를 무모호화하고 실패했던 원 구현을 그대로 다시 돌리자 11/11 통과. 모델 결함이 아니라 저울이 만든 거짓 변별이었다.

앞의 OpenAI 감사가 말한 것과 정확히 같은 병이다. 그 감사에서 결함 최다 두 종류는 과잉 엄격 테스트와 과소 명세 프롬프트였는데, 목적 제작한 내 과제도 첫 런에 같은 함정을 밟았다. 규모의 문제가 아니라 구조의 문제라는 뜻이다. 그래서 두 가지를 계약에 추가했다.

이 사건이 준 교훈은 역설적이다. 저울의 최대 리스크는 난이도 부족이 아니라 저울 자신의 모호성이고, 따라서 측정 시스템에는 측정 대상을 의심하는 절차만큼 자기 자신을 의심하는 절차가 필요하다. 이후의 모든 판정 리포트에는 실패 분포 표가 포렌식 진입점으로 들어간다.

04 · 측정 1

N=1이 순위를 뒤집은 날

7월 초의 결정은 이것이었다. 빌드·QA 성격의 하위 작업을 대형 모델(당시 opus)에 계속 맡길 것인가, 더 싼 모델로 내릴 것인가. 후보는 같은 벤더의 소형 모델(haiku)과 타 벤더 모델(gpt-5.5). 7월 3일의 N=1 스크리닝(세 모델 모두 기본 effort)에서는 haiku 가 시간 합 최속이었다. 세 과제 합산 193s, opus 196s, gpt-5.5 240s. 여기서 멈췄다면 "속도는 haiku"라고 적었을 것이다.

규칙 2가 있어서 멈추지 못한다. 인용하려면 N=3이 필요하다. 7월 5일, 같은 과제 세 종을 모델당 아홉 셀씩 반복했다(run 20260705T190809). 결과는 순위 자체가 뒤집혔다.

N=3 합산에서 gpt-5.5-low 는 1,215k 토큰, 553s. haiku 는 2,875k 토큰, 1,129s. opus 는 3,202k 토큰, 2,189s. 세 모델 전원이 게이트를 통과했으므로(규칙 3의 동률 조건 성립) 효율이 판정 기준이 되고, 승자는 gpt-5.5-low 다. opus 대비 토큰 −62%, 시간 −75%. 그런데 이 결론보다 중요한 것이 있었다. 왜 N=1은 haiku 를 최속이라고 말했는가.

답은 분산이었다. haiku 는 금액 파싱 과제에서 셀당 361k ~ 671k 토큰, 같은 조건 세 번이 1.9배 폭으로 흔들렸다. N=1 스크리닝은 이 분포에서 한 번 뽑은 값이고, 그날은 운 좋게 아래쪽이 뽑혔을 뿐이다. 이후 넉 주 동안 같은 패턴을 세 번 더 측정했다.

네 번의 실측이 그리는 패턴은 일관된다. N=1은 방향은 자주 맞히지만 크기를 부풀리고, 가끔은 순위째 뒤집는다. 그래서 이 저울에서 한 번 돌린 숫자는 문서에 적히지 못한다. 이 규칙 하나가 시간 축의 N=1 숫자("haiku 최속")가 결정 근거로 인용되는 것을 막았다.

7월 5일 런의 판정은 제안 문서가 되어 설정 저장소의 이슈로 올라갔고, 사람 승인을 거쳐 반영됐다. 빌드·QA 위임 작업의 기본 모델을 gpt-5.5-low 로. 단, 조건부다. 타 벤더 CLI 를 호출할 수 있는 자리에 한정하고, 차기 모델 세대가 나오면 같은 축을 재측정한다는 트리거가 승인 조건으로 함께 박혔다. 이 트리거가 §05와 §06을 만든다.

05 · 측정 2

비용 −97%의 해부

7월 20일, 트리거가 발동했다. 5.6 세대 모델이 나왔고, 현직(gpt-5.5-low)보다 싼 후보가 셋이었다. N=1 스크리닝 16셀로 후보를 거르고(여기서 sonnet-5 는 현직보다 싸면서도 나머지 두 후보에 토큰·시간·비용 전 축에서 밀려 탈락했는데, 이 탈락은 빌드·QA 슬롯 한정이고 신형 토크나이저의 토큰 산정 불리 캐비엇이 붙어 있다), 남은 후보로 N=3 36셀을 돌렸다(run 20260720T204027). 36셀 전원 통과, 재시도 0. 게이트가 완전 동률이므로 규칙 3에 따라 비용이 판정한다.

판정문은 이렇게 적었다. 게이트 동률(3모델 전원 pass^3, 재현 12/12) 조건에서 비용 −83%는 "큰 격차" 인용 기준을 충족한다. 반면 토큰 −16%와 시간 −23%는 이 규모(4과제, N=3)로는 오차막대를 못 세우는 동률 밴드 안이라 참고로만 적었다. 근소 우위를 인용하지 않는 같은 취지의 규율은 EV-003 의 순서 실증 이후 심판 레인에도 등록되어 있다. 공정하게 반대 증거도 적는다. luna 는 리뷰 과제 한 종에서 유일한 약세(467k, terra 312k·현직 353k)를 보였고, 이를 무겁게 보면 terra 가 균형형 대안이라고 리포트에 병기했다. 배정은 luna-low 로 교체됐고, 이번에도 승인은 사람이 했다.

여기까지가 측정이다. 그런데 열흘 뒤인 7월 30일, 벤더가 luna 단가를 공식 인하했다. 입력·출력 동률로 정확히 ×0.2. 재측정이 필요했을까. 아니다. 비용은 단가 × 실측 토큰의 곱이고 토큰 실측은 이미 N=3으로 있으므로, 새 단가는 선형 배율로 재계산하면 끝난다. $1.77 이 ~$0.35 가 되고, 현직 대비 −83%는 −97%가 된다.

이 분해를 굳이 적는 이유가 있다. −97%라는 숫자에서 내 측정의 기여는 −83%까지다. 나머지는 벤더가 가격을 내린 것이고, 그건 누구에게나 일어난 일이다. 측정 시스템의 성과 보고가 부풀려지는 가장 흔한 경로가 이 두 층의 뭉개기라서, 리포트에도 측정 불필요·선형 배율이라고 명시해 두었다. 정확히 말하면 측정의 기여는 따로 있다. 인하 공지가 떴을 때 재측정 없이 하루 만에 판정을 갱신할 수 있었던 것, 그것이 N=3 토큰 실측을 보유한 대가다.

06 · 측정 3

세대 교체와 정직한 문장

8월 1일, 두 번째 트리거가 발동했다. 대형 모델의 새 세대(opus-5)가 GA 됐다. 구세대와 단가가 같으므로 이번 판정축은 비용이 아니라 행동이다. 변별 4종 × N=3 (run 20260801T152438), 구세대와 신세대 각 12셀 전원 통과, 재시도 0. 동가·동통과이므로 다시 효율이 가른다.

합계만 보면 신세대의 우세다. 그런데 과제별로 열면 혼재다. 기획 복원에서는 구세대보다 느리고, 리뷰 과제에서는 토큰을 더 쓴다. 합계 우위는 사실상 금액 파싱 한 과제의 시간 개선이 견인했다. 그래서 판정 리포트의 문장은 이렇게 적혔다. "합계 우세 + 과제별 혼재". "전 축 우세"라고 적지 않는 것, 이 문장 선택이 이 저울에서 가장 공들이는 부분이다. 합계는 요약이고 요약은 언제나 유리한 쪽으로 미끄러지려 하기 때문이다. 교체 제안도 같은 이유로 범위를 잘랐다. 이 4과제가 커버하는 자리(빌드·QA·경량 기획)에 한정하고, 측정하지 않은 심층 기획 축의 배정은 별도 측정 전까지 교체를 유보했다. 4과제 합계를 전 역할로 외삽하지 않는다.

같은 런에는 실패 처리의 사례도 하나 있다. 함께 돌린 luna 의 기획 복원 셀에서 error 가 7건 나왔다. 순진하게 집계하면 "luna 는 복원 과제에서 불안정"이다. 원장을 열면 다른 그림이다. 7건 전부 0토큰, 그리고 보존해 둔 stderr 7건 전부에 같은 계열의 문구가 있다. 인증 토큰 무효화, HTTP 401. 요청이 모델에 도달하기 전에 내 쪽 인증 인프라가 죽은 것이다.

통과한 10셀 기준 luna 의 비용은 ~$0.26. 신세대 대형 모델(~$17.85)의 약 1/70 규모다. 이 격차가 §05의 배정을 유지시킨다. 다만 이 문장도 규율 안에서만 성립한다. 게이트가 동률일 때의 이야기이고, 이 4과제 범위의 이야기다.

07 · 저울의 수명

모든 모델이 만점을 받으면 저울이 은퇴한다

넉 주의 기록에는 불편한 사실이 하나 관통한다. 변별 과제에서 pass 로 갈린 모델이 없다. 7월 20일 런에서 양 벤더 5개 모델이 전원 통과했고, 8월 1일 런에서도 전원 통과였다(무효 처리된 인프라 에러 제외). 확정 기준에 도달한 것은 4종 중 인프라 에러가 없었던 3종이다. 과제가 쉬워서가 아니라 이 티어의 모델들이 이 난이도를 넘어섰기 때문이다. 통과율의 변별력이 0이면 판정은 전부 효율 축으로 넘어가는데, 효율만 남은 저울은 반쪽이다.

이 상태에도 규칙을 미리 박아 두었다. 전 모델 동반 실패는 과제 결함 의심(§03의 포렌식 대상)이고, 전 모델 전원 통과는 포화 후보다. 포화의 은퇴·상향 확정 기준은 두 개 이상 벤더가 섞인 로스터에서 전원 pass 가 N=3 이상으로 연속 관측될 것. 단일 벤더의 포화는 벤더 특성일 수 있어서 확정 근거로 부족하다. 7월 20일 관측으로 "근접", 8월 1일 관측으로 기준 도달. 그래서 현재 이 저울의 최우선 과제는 새 측정이 아니라 과제 난이도 상향이다. 공개 벤치마크들이 전 모델이 맞히는 문항을 걸러내고 하드셋만 남기는 것과 같은 생애주기 관리를, 개인 저울도 해야 한다.

측정 인프라 쪽의 사건도 하나 기록해 둔다. 8월 1일 첫 웨이브에서 한 벤더의 모델 전 셀이 15분 타임아웃으로 죽었다. 원인은 모델이 아니라 API 호출이 경유하던 로컬 프록시의 행업이었고, 해당 웨이브는 통째로 무효 처리했다. 이후 측정 런은 프록시를 우회한 직접 API 가 표준이 됐다. 프록시에는 한도 초과 시 다른 모델로 자동 전환하는 기능이 있는데, 편의 기능이 측정에서는 셀에 붙은 모델 라벨과 실제 응답한 모델이 달라질 수 있는 오염 경로가 되기 때문이다. 운영에 좋은 것과 측정에 좋은 것은 자주 다르다.

08 · 이식

남의 저울을 믿지 않는 법, 다섯 줄

이 시스템의 코드는 내 작업에 묶여 있지만, 넉 주를 버티게 한 구조는 어떤 팀이든 하루면 옮길 수 있다.

다섯 줄의 공통 형태는 하나다. 숫자를 만드는 쪽과 숫자로 결정하는 쪽 사이에 마찰을 일부러 남겨 두는 것. N=3 반복은 시간의 마찰이고, 사람 승인은 권한의 마찰이고, 포렌식은 해석의 마찰이다. 마찰을 없애면 빨라지는 게 아니라, 틀린 결정이 빨라진다.

09 · 한계

이 기록이 주장하지 않는 것

이 글의 숫자에는 경계가 있고, 경계 밖으로 확장해 읽으면 이 글의 취지와 반대가 된다.

규모. 과제 4종, N=3, 셀 수십 개. 오차막대와 동률 밴드의 통계적 뒷받침이 없는 규모라서 이 저울이 변별하는 것은 큰 격차뿐이다. −83% 같은 격차는 인용했고 −16% 같은 격차는 참고로 강등한 이유다. 토큰·비용. 토큰 산정 방식이 런타임마다 달라 교차 벤더 비교는 근사이고, 비용은 단가표 × 토큰의 추정치로 캐시 클래스를 분리하지 못한다. 서열 비교 전용, 청구액 아님. 일반화. 여기서의 판정은 내 과제 분포 위의 판정이다. 같은 방법을 권하는 것이지 같은 결론(예: luna 가 항상 최선)을 권하는 것이 아니다. 측정 범위 밖 역할로의 외삽은 리포트 자체가 금지한다.

N=1 축소 시리즈의 지위. §04의 4회 실측은 통제 실험이 아니라 운영 중 관측의 누적이다. 대상 모델도 축도 제각각이고, 7월 3일 스크리닝과 7월 5일 인용 런은 일자와 effort 설정 라벨이 다르다. 스크리닝은 세 모델 모두 기본 effort, 인용 런은 haiku-low·gpt-5.5-low·opus(xhigh)다. haiku 쪽 뒤집힘은 낮춘 설정으로 재쟀는데도 더 무거워진 것이라 방향이 보수적으로 성립하지만, gpt-5.5 쪽 개선에는 effort 하향이 섞여 있어 도표 1의 두 패널은 순위 외의 어떤 비교도 지지하지 않는다. 다만 같은 날 동일 설정 N=1 쌍(haiku-low 170s vs gpt-5.5-low 175s, run 20260703T114222)에서도 haiku 가 앞섰고 N=3에서 뒤집혔으므로, 뒤집힘 관찰 자체는 라벨 교란 없이도 성립한다. fable 행의 시간 축은 날짜가 다른 크로스런이라 스로틀 교란 가능성을 리포트가 명시했다(참고용). 외부 인용. §01·§03의 벤치마크 감사는 발행사의 공개 리포트가 원문 접근 차단 상태라 복수의 독립 보도와 감사 요약으로 교차 확인했다. 세부 수치가 아닌 결함 규모와 상위 결함 유형만 인용한 이유다.

마지막으로 이 글 자체의 이해관계. 이 저울과 배정 시스템은 내가 만들었다. 측정이 성공적이었다고 말할 유인이 있는 사람이 쓴 글이라는 뜻이고, 그래서 원장과 리포트 원문이 남아 있는 사실만 적고 판정 문장은 리포트의 표현을 그대로 옮겼다.

10 · 재현 조건

같은 것을 만들려면

구성 요소 (전부 수백 줄 수준의 스크립트 + JSON)
과제      : 실제 업무에서 파생·익명화한 태스크 4종 (스펙 + 보이는 테스트 + holdout 테스트)
게이트    : 결정론 — 채점 시 holdout 주입, LLM 판정 무개입
원장      : append-only JSONL (셀 단위: 모델·rep·게이트·토큰·시간·rc)
리포트    : 같은 원장에서 재생성 — 같은 입력이면 같은 문서
반영      : 원장 집계 → 제안 초안 자동 생성 → 이슈 등록·승인·반영은 사람

이 글의 판정 런
run 20260705T190809  : 3과제 × 3모델 × N=3 — gpt-5.5-low 배정 (§04)
run 20260720T204027  : 4과제 × 3모델 × N=3, 36셀 전원 pass — luna-low 배정, −83% (§05)
run 20260801T152438  : 4과제 × 3모델 × N=3 — 세대 비교 (§06)
−97% 재계산        : 신단가 × 7/20 원장 토큰 실측 — 새 측정 아님 (§05)

사전 규율 (측정 전 등록)
스크리닝 N=1 · 인용 N=3 / 게이트 동률에서만 효율 판정 / 반복 n<k 지표 보고 금지
실패 셀 포렌식 전 인용 금지 / 무출력 error 다발 = 스로틀 신호, 웨이브 무효
포화 은퇴 기준: 교차 벤더 전원 pass N≥3 연속

측정 저장소는 업무 파생 과제가 들어 있어 비공개다. 위 run ID 와 구성은 원장과 리포트 파일에서 그대로 재생성되며, 구조 자체는 어느 스택에서든 재구현 가능한 수준이다. 질문이 들어오면 익명화 가능한 범위에서 스펙을 공개할 생각이 있다.