돌아간다

7h53m ↻6m

대시보드의 계정 표 한 칸에 7h53m ↻6m이 떠 있다. 토큰이 만료되기까지 7시간 53분, 마지막 갱신은 6분 전이라는 표시다. 아무도 쓰지 않아 그대로 두면 만료될 구독 계정의 토큰을, 화면 뒤에서 돌던 프로그램이 여덟 시간 가까이로 되살려 놓았다. 이 한 칸은 2026-06-13 오후 1시 39분(한국 시각) 공개 저장소 2lab-ai/llmux에 올라간 첫 커밋 속 연구 노트에 옮겨져 있다.¹

커밋 메시지는 한 줄이다. "chore: reset history around Rust implementation", Rust 구현을 기준으로 이력을 새로 시작한다는 뜻이다. 그 한 줄 밑으로 파일 60개, 24,993줄이 한꺼번에 들어온다. Rust 소스가 45개 파일에 20,169줄이고, 그 사이에 테스트 함수를 표시하는 속성(#[test]·#[tokio::test])이 311개 박혀 있다. 자동 빌드·배포용 워크플로 파일 셋(ci·preview·release)과 설계 문서 셋(스펙·구조·연구 노트)도 함께 들어온다. 이름은 아직 llmux가 아니라 teamagent, 판 번호는 0.1.0이다. 이 저장소는 내가 만들었다.²³

README의 첫 문장이 이 물건을 정의한다. "teamagent is a Rust local proxy for Claude Code." Claude Code는 Anthropic이 만든 터미널 코딩 에이전트이고, 프록시는 요청을 중간에서 받아 대신 보내 주는 프로그램이다. teamagent는 Claude Code가 보내는 요청을 같은 컴퓨터의 3456번 포트에서 받아, 여러 구독 계정 가운데 쿼터가 먼저 만료될 계정부터 쓴다. 첫날 요청이 실제로 나가는 길은 둘이다. Anthropic으로 가는 요청은 인증과 헤더를 고친 뒤 본문을 바이트 그대로 넘기고, OpenAI Codex 계정은 손으로 고르거나 넘칠 때 쓰는 예비로 붙인다. Gemini와 로컬 모델은 "컴파일만 확인한 빈 껍데기"라고 적혀 있다.⁴

연구 노트 첫 문단의 마지막 문장은 "Dogfooding on 2026-06-13"으로 시작한다. 만든 사람이 제 도구를 먼저 써 보는 일, 도그푸딩이 그날 Codex와 토큰 갱신, 대시보드 연결 방식, brew 배포에 대해 실제 백엔드에서 얻은 발견을 보탰다는 문장이다. 그 사용이 설계를 바꿨다. Claude Code 세션은 오래 살아 있는데 구독 계정의 OAuth 접근 토큰, 곧 로그인한 상태를 증명하는 출입증은 8시간 안팎이면 만료된다. 같은 커밋의 스펙은 이것을 도그푸딩 중에 나타난 두 번째 운영 문제라고 부르고, 그래서 v0.1은 창을 닫아도 뒤에서 도는 데몬을 기본으로 삼는("daemon-first") 로컬 프록시라고 적는다. 계정 표의 ↻6m이 그 데몬이 한 일이다.⁵

그 오후의 기록은 짧은 간격으로 이어진다. 같은 날 나온 v0.1.0 릴리스의 태그가 이 커밋을 가리키고, 스펙 문서 머리에는 이미 "v0.1.0 shipped"라는 상태와 Homebrew 설치 경로가 적혀 있다. 3시 47분, README가 다시 쓰이며 첫머리에 표어 한 줄이 들어간다. "Models change every month. Your harness shouldn't." 모델은 달마다 바뀌어도 그 모델에게 일을 시키는 하네스, 곧 에이전트 도구와 설정의 묶음은 바뀌지 않아야 한다는 내기다. 4시 24분, 요청에 적힌 모델 이름을 보고 Claude 쪽으로 보낼지 Codex 쪽으로 보낼지 고르는 커밋이 들어간다. 5시 17분, 돌고 있는 데몬의 판이 새로 깔린 프로그램과 다르면 데몬을 스스로 다시 띄우는 커밋이 뒤따른다. 첫 공개 커밋에서 네 시간이 채 안 된 사이의 일이다.⁶

오후 한나절

그 커밋보다 꼭 3년 앞선 2023-06-13, OpenAI는 Chat Completions API에 함수 호출(function calling)을 넣었다. 개발자가 함수의 이름과 인자를 JSON Schema로 적어 건네면, 모델이 그 함수를 부를지 스스로 고르고 부를 때 넣을 인자를 JSON 객체로 내놓는다. JSON Schema는 필드마다 이름과 값의 종류를 정해 둔 명세다. 모델이 문장 대신 빈칸을 채운 서식을 돌려주기 시작한 셈이다. 대상은 그날 나온 gpt-4-0613과 gpt-3.5-turbo-0613이었다.⁷

같은 공지는 시작하는 법도 일렀다. 개발자 문서를 보고 시작하되, 함수 호출이 더 나아질 여지가 있는 사례를 찾으면 평가(evals)를 보태라고 했다. 같은 날 gpt-3.5-turbo의 입력 가격을 25% 내리면서는 1달러에 대략 700쪽이라고 셈해 보였다.⁸

17일 뒤인 2023-06-30, Shawn Wang(swyx)이 Latent Space에 「The Rise of the AI Engineer」를 올렸다. 부제는 "창발하는 능력이 떠오르는 직함을 만들고 있다"로 시작한다. 둘째 문단에 이 문장이 있다. "2013년에는 5년과 연구팀이 있어야 해내던 넓은 범위의 AI 과제가, 2023년에는 API 문서와 남는 오후 한나절만 있으면 된다." 같은 글에서 그는 AI Engineer Summit을 연다고 알렸다.⁹

값 안의 실수

2024-05-30, Anthropic은 도구 사용(tool use)을 Claude 3 모델 전부에 정식으로 연다고 발표했다. 자사 Messages API뿐 아니라 Amazon Bedrock과 Google Cloud의 Vertex AI에서도 열었다. 도구 사용은 함수 호출과 같은 자리의 기능이다. 모델이 바깥 도구를 부를 인자를 내놓으면 프로그램이 그 도구를 실제로 돌리고, 결과를 다시 모델에게 건넨다. 발표문에 실린 고객사 StudyFetch의 CTO는 걸린 시간을 이렇게 말했다. "불과 며칠 만에 우리 플랫폼에 도구를 붙였다."¹⁰

두 달 남짓 뒤인 2024-08-06, OpenAI가 Structured Outputs를 내놓았다. 발표문은 복잡한 JSON 스키마를 얼마나 지키는지 보는 자체 평가의 숫자를 차례로 적었다. gpt-4-0613은 40%에 못 미쳤다. 새 모델을 그 일에 맞게 학습시키자 93%가 나왔고, 제약 디코딩을 더하자 100%가 나왔다. 제약 디코딩은 모델이 다음 토큰을 고를 때 스키마에 어긋나는 후보를 아예 지워 버리는 방식이다. 글은 앞선 판도 돌아봤다. 2023-11-06 DevDay에 낸 JSON mode는 응답이 특정 스키마를 따른다는 것까지는 보장하지 않았다고 했다. 같은 글의 「한계와 제약」 절에는 문장이 하나 더 있다. "Structured Outputs가 모든 종류의 모델 실수를 막지는 않는다. 예를 들어 모델은 JSON 객체의 값 안에서 여전히 실수할 수 있다."¹¹

석 달 남짓 뒤인 2024-11-25, Anthropic은 Model Context Protocol(MCP)을 오픈소스로 공개하며 그것을 AI 어시스턴트와 데이터가 있는 시스템을 잇는 "새 표준"이라고 불렀다. 발표문이 짚은 문제는 연결 하나하나에 드는 맞춤 작업이었다. "새 데이터 원천마다 따로 맞춤 구현이 필요해서, 제대로 연결된 시스템을 키우기 어렵다." 원천마다 새로 짜던 연결 코드를 규약 하나로 바꾸자는 제안이었고, 발표문에는 초기 도입사로 Block의 CTO가 이름을 올렸다.¹²

1분에서 30분

에이전트는 그다음에 왔다. 2025-02-24, Anthropic은 터미널에서 일하는 코딩 에이전트 Claude Code를 '제한적 연구 미리보기'로 냈다. 코딩 에이전트는 사람이 맡긴 일을 받아 저장소의 파일을 직접 읽고 고치며 명령까지 돌려 보는 모델 프로그램이다. 공지는 초기 시험에서 Claude Code가 "보통 사람 손으로 45분 넘게 걸릴 일"을 한 번에 끝냈다고 적었다.¹³

석 달 가까이 지난 2025-05-16, OpenAI가 Codex를 연구 미리보기로 내놓았다. 클라우드의 격리된 실행 환경에서 코딩 작업 여러 개를 나란히 돌리는 에이전트였다. 작업 하나에는 "복잡도에 따라 보통 1분에서 30분"이 걸린다고 했고, 그 밑의 모델 codex-1은 통과 결과가 나올 때까지 테스트를 되풀이해 돌릴 수 있다고 소개했다. 엿새 뒤인 2025-05-22, Anthropic은 Claude 4를 발표하면서 Claude Code를 정식 제공으로 돌렸다.¹⁴

llmux가 앞에 서는 것이 바로 이 Claude Code다. 그리고 llmux의 기록에는 이 에이전트들의 이름이 곳곳에 남아 있다. 2026-06-13부터 10-02까지 병합 커밋을 뺀 커밋 330개 가운데 103개에 공동 작성자 줄이 붙어 있고, 거기 적힌 이름은 사람 표기 몇 건을 빼면 모두 Claude가 들어간 이름이다. 대부분은 모델 이름이고, 나머지는 도구 이름 'Claude Code'와 어느 모델인지 적지 않은 'Claude'다. 공동 작성자 줄은 첫 공개 날 오후 2시 42분, 리셋 커밋 한 시간쯤 뒤의 커밋에 처음 찍혔다. PR 125개 가운데 66개의 본문 끝에는 "Generated with [Claude Code]"가 붙어 있다. 그 줄은 도구가 남긴 표시이지 누가 몇 줄을 썼는지 잰 값은 아니다.¹⁵ 병합된 PR에 달린 GitHub 리뷰 68건은 모두 Codex 자동 리뷰 봇이 단 의견이다.¹⁶ 첫날의 연구 노트는 네 갈래 조사 가운데 출처 20개짜리 웹 조사를 에이전트 102개로 돌렸다고 적었다.¹⁷

daily driver

이튿날인 2026-06-14에는 안정 릴리스가 셋 더 나왔다. v0.2.0이 낮 12시 6분, v0.2.1이 1시 45분, v0.2.2가 밤 9시 5분이다. 그 사이 저녁 8시 21분에 이름을 teamagent에서 llmux로 바꾸는 커밋이 들어갔다. 같은 커밋에 든 데모 녹화 스크립트의 머리 주석은 녹화용 설정의 포트를 3457로 옮긴 까닭을 이렇게 적었다. 3456번의 실사용 데몬("production daemon")과 절대 부딪히지 않도록.¹⁸

그 뒤의 넉 달은 숫자로 남아 있다. 2026-07-14에 세 번째 공급자로 xAI의 Grok이 붙었는데, 스펙의 첫 커밋에서 PR 병합까지 1시간 36분이 걸렸다.¹⁹ 2026-08-25에는 OpenRouter가 네 번째로 붙었다. 2026-10-02까지 공개 main에 쌓인 커밋은 397개다. 2026-10-05 기준으로 PR은 125개(병합 107개), 이슈는 59개, 안정 릴리스는 25개(v0.1.0 → v0.2.23)다. 커밋의 89%는 처음 35일에 몰렸고, 그 뒤로는 걸음이 잦아들었다. 나머지 42개 가운데 절반인 21개는 여전히 새 기능을 더하는 커밋이었다. 본체(src·tests)에서 세면 테스트 속성은 311개에서 1,521개로, Rust 코드는 20,169줄에서 102,172줄로 늘었다.²⁰

README의 정의도 넓어졌다. 2026-10-02 판은 llmux를 Claude Code를 위한 로컬 Anthropic 호환 프록시라 부르고, 요청마다 어느 계정이나 백엔드가 받을지는 llmux가 정한다고 적는다. Claude와 Codex, Grok, OpenRouter의 네 무리가 한 풀에 들어 있고, 요청은 모델 이름으로 갈린다. 첫날 오후에 들어간 표어는 첫머리에 그대로 있다.²¹

'daily driver'라는 말은 2026-09-18 기록에 처음 나온다. 새 프리뷰 판을 깔고 데몬을 다시 띄운 뒤, 그 판을 날마다 쓰는 판("daily driver")으로 다시 연결했다는 한 줄이다. 첫날의 도그푸딩에서 그 한 줄까지, 이 도구를 하루에 몇 시간씩 썼는지는 공개 기록에 없다. 병합된 코드의 사람 기여자는 처음부터 한 명이다.²²²³

최종: 환불액

2026-10-05 오전, 나는 같은 모양의 작은 앱을 하나 세웠다. 세운 날 바로 일을 시키는 앱이다. 가상 항공사 「누리별항공」의 환불 규정 문서를 모델에게 건네고 고객의 환불 문의에 답하게 한다. 누리별항공은 측정을 위해 지어낸 회사이고, 규정은 2026-10-01 시행으로 적은 일곱 조다. 적용 범위와 용어, 적용 순서, 항공사 사유의 전액 환불, 구매 후 24시간 무료 취소, 출발 전 취소 수수료 표, 출발 뒤 취소. 모델은 싸고 빠른 쪽인 claude-haiku-4-5를 골랐다.²⁴

앱에 준 지시는 짧다. 첫 줄은 "너는 누리별항공 고객센터의 환불 안내 도우미다. 아래 [환불 규정]에 근거해서만 답한다." 그 밑에, 규정으로 판단할 수 없는 질문이면 추측하지 말고 판단할 수 없다고 안내한 뒤 확인할 곳을 알려 주라는 줄이 있다. 답의 마지막 줄은 둘 중 하나로 정했다. 최종: 환불액 <숫자>원 아니면 최종: 판단 불가. 앱의 요청은 114일 전 첫날과 같은 3456번 포트로 들어가, llmux를 지나 모델에 닿는다.

정답은 모델이 아니라 규칙 엔진이 낸다. 규정의 숫자를 그대로 옮긴 계산 코드다. 운임 등급과 운임, 세금, 남은 시간, 구매 경과 시간 같은 사실을 넣으면 제3조의 적용 순서대로 조항 하나를 골라 금액을 내고, 같은 사실에는 언제나 같은 금액을 낸다. 채점은 앱의 답에서 마지막 최종: 줄만 읽어 그 금액과 맞춰 본다. 측정에 들어가기 전에 시연 질문 열 개를 정해 고정했다. 출발 전 취소 수수료를 따지는 질문이 넷, 구매 후 24시간 무료 취소와 항공사 지연과 출발 뒤 취소를 따지는 질문이 둘씩이다.

오전 10시 38분 20초, 첫 질문이 들어간다. "문의드려요. 세이버 표로 총 419,000원 결제했는데 그중 세금·공항이용료가 58,000원이래요. 출발 5일 전인데 취소하려고요. 환불 금액이 얼마인지 알려주세요."

2.8초 뒤 답이 돌아온다. 앱은 결제 총액에서 세금 58,000원을 떼어 운임을 361,000원으로 잡고, 남은 5일을 120시간으로 바꿔 제6조 수수료 표의 '72시간 이상 720시간 미만' 줄에서 세이버 수수료 80,000원을 찾는다. 답의 끝은 이렇다.

**계산**
- 운임 환불액: 361,000원 - 80,000원 = 281,000원
- 세금 환불액: 58,000원 (전액)
- **합계: 281,000원 + 58,000원 = 339,000원**

최종: 환불액 339000원

규칙 엔진이 같은 사실로 낸 금액도 339,000원이다. 나머지 아홉 질문도 같은 식으로 지나간다. 답 하나에 걸린 시간은 중앙값 2.7초, 열 개를 다 합쳐 27초다. 열 개의 마지막 줄이 모두 규칙 엔진의 금액과 같다. 같은 열 개를 다른 공급자의 모델 gpt-5.5에 넣어도 열 개가 다 맞는다.²⁵

gpt-5.5로 가는 요청도 같은 3456번 포트로 들어간다. llmux가 요청에 적힌 모델 이름을 읽고, 받을 쪽을 고른다.

열 번 중 열 번

15%

2026-10-05 오전 10시 32분, 측정보다 먼저 커밋한 사전 등록 문서의 예측 표에 숫자 하나가 들어갔다. 누리별항공 환불 앱이 240개짜리 도전 세트에서 틀릴 비율, 15%. 옆 칸에 근거가 한 줄 붙었다. 규정의 표를 찾아 읽으면 끝나는 질문은 5% 안팎을 틀리고, '29일 23시간'이나 출발 정각 같은 경계에 걸린 질문과 규정이 답하지 않는 질문은 20~25%를 틀리리라는 셈이었다. 같은 표에 시연 열 개의 예측도 있었다. 실패율 5%, 그러니 "10/10일 확률이 가장 높다(약 60%)". 나는 두 예측을 한 표에 나란히 적었다.¹

같은 문서는 측정 전에 고정할 것들을 적었다. 질문을 만드는 생성기의 칸과 가중치와 시드, 시연을 고르는 규칙, 무엇을 실패로 셀지, 같은 질문을 몇 번 물을지, 비교할 모델(다른 공급자의 gpt-5.5). 실패는 답의 마지막 최종: 줄로 정했다. 금액이 규칙 엔진과 다르면 실패, 규정이 답하지 않는 질문에 금액을 내면 실패, 답이 있는 질문에 판단 불가로 물러서도 실패, 최종: 줄이 없거나 꼴이 다르면 형식 실패다. 모델을 부르는 시도는 성공이든 실패든 원장에 한 줄씩 남고, 분석은 질문마다 가장 먼저 남은 유효한 기록만 쓴다. 다시 돌려 마음에 드는 출력을 고르는 길은 거기서 막힌다.

6분 뒤 시연이 들어갔다. 세이버 표 419,000원을 물은 첫 질문부터 열 번째 질문까지, 열 번의 화면에 오답은 하나도 없었다.²

591,324바이트

llmux 저장소에도 시연이 하나 있다. 공개 이력의 첫 커밋이 올라온 날인 2026-06-13 오후 3시 47분, README를 다시 쓴 커밋은 메시지에 "real-terminal demo gif", 실제 터미널을 찍은 데모 GIF라고 적고 README의 GIF를 새 파일로 바꿨다. 표어 "Models change every month."가 처음 들어간 바로 그 커밋이다. 이튿날 저녁 8시 32분, 그 GIF를 새 녹화로 바꾼 커밋 c883c72의 본문은 이렇다. "옛 가짜 클립을 바꾼다. 왼쪽 창은 프록시를 거치는 진짜 claude 호출이고, 오른쪽 창은 그에 반응하는 실시간 llmux TUI다." 전날 '실제 터미널'로 올라간 파일과 이날 '가짜 클립'으로 내려간 파일은 내용이 같다. 같은 깃 블롭, 591,324바이트다. 커밋 본문은 새 녹화의 조건도 적었다. 계정 이메일을 일정한 가짜로 바꿔 보여 주는 데모 모드, 그리고 Claude 계정 둘과 Codex 계정 둘만 넣은 작은 설정.³

17.1%

도전 세트는 시연과 따로 만든 240개의 질문이다. 같은 생성기가 다른 시드로 만들었고, 시연과 문장이 겹치는 질문은 뺐다. 질문마다 어느 조항을 따지는지, 값이 규정의 경계에 걸리는지, 규정이 답하는 질문인지, 표기에 잡음이 있는지가 정해진다. 경계는 이런 값이다. 출발까지 719·720·721시간 남은 표를 '29일 23시간', '30일', '30일 1시간'으로 적은 질문, 산 지 23·24·25시간 된 표, 2시간 50분·3시간·3시간 10분 늦은 항공편, 출발 정각의 취소. 잡음은 같은 189,000원을 '18만 9천 원'으로 쓰거나 오타와 영어, 군말을 섞는 식이다. 이 성질들을 엮은 칸 32개에 사전 등록한 가중치대로 질문을 나눠 넣었다. 출발 전 수수료를 따지는 질문이 40%, 나머지 세 조항이 20%씩이고, 규정이 답하지 않는 질문이 넷에 하나다. 문장은 템플릿으로 만들었으니 사람이 쓴 문의보다 생김새의 폭이 좁다.⁴

정답은 질문 문장보다 먼저 있다. 생성기가 운임 등급과 운임, 세금, 남은 시간 같은 사실을 먼저 정하면 규칙 엔진이 그 사실로 금액을 계산하고, 문장은 그 뒤에 만든다. 문장이 사실을 빠짐없이 담았는지는 표기를 값으로 되읽는 별도의 코드가 확인했고, 문장은 같은데 정답이 다른 질문은 양쪽 다 뺐다. 환불 앱의 질문 가운데 이 검사로 빠진 것은 없었다.

240개 가운데 60개는 규정이 답하지 않는 질문이다. 여행사·마일리지·단체로 산 항공권, 규정에 없는 운임 등급, 이미 환불된 항공권에 딸린 좌석 지정·수하물·기내식 요금, 그리고 가족상이나 입원을 증빙으로 수수료 면제를 청하는 개인 사정. 개인 사정 질문은 심사가 결과를 바꿀 때만 만들었다. 규정대로 셈한 환불액이 결제 총액보다 작은 경우다. 시연 열 개는 이와 다른 층에서 나왔다. 측정 전에 정한 규칙이 빌더가 처음 넣어 볼 법한 질문, 곧 깨끗한 표기에 경계가 아닌 값을 넣은, 규정이 답하는 질문만 모은 후보 가운데서 열 개를 골랐다. 도전 세트 안에서 그 층에 드는 질문은 45개다.

240개는 오전 10시 40분 35초부터 3분 남짓 사이에 한 번씩 들어갔다. 41개가 틀렸다(claude-haiku-4-5, 질문마다 첫 실행). 칸마다 실패율을 내고 사전 등록한 가중치로 섞으면 17.1%다. 칸 안에서 질문을 다시 뽑는 셈을 1만 번 되풀이해 얻은 95% 구간은 13.3~20.8%이고, 예측한 15%는 그 안에 들었다. 이 17.1%는 가중치가 정한 혼합에 대한 값이다. 실제 고객 문의를 무작위로 뽑아 잰 실패율이 아니다.⁵

실패는 고르게 퍼지지 않았다. 규정이 답하는 질문 180개의 실패율은 6.7%(95% 구간 3.3~10.6%), 규정이 답하지 않는 60개의 실패율은 48.3%(38.3~58.3%)였다. 예측의 근거로 적은 경계는 더 어렵지 않았다. 경계에 걸린 질문은 15.8%를, 그렇지 않은 질문은 18.3%를 틀렸다. 잡음이 있는 질문과 없는 질문도 16.7%와 17.5%로 비슷했고, 어느 조항을 따지는 질문이냐에 따라서도 16.7~18.8%로 크게 갈리지 않았다. 시연과 같은 층의 45개만 떼어 봐도 4개가 틀렸다. 결과를 본 뒤 칸 넷을 합쳐 본 사후 기술이다.⁶

그 넷 가운데 하나가 도전 세트의 첫 질문이다. 42일 전에 산 세이버 표를 출발 54일 전에 취소하려는, 시연과 생김새가 같은 질문이다. 앱은 구매 후 24시간 무료 취소를 정한 제5조부터 따지며 "구매 경과 시간: 42일 ✓ (24시간 이하 아님)"이라고 적었다. 그러고는 "구매 경과 시간이 24시간을 초과했지만, 남은 시간이 168시간(7일) 이상이므로 제5조가 적용됩니다"라며 결제 총액 156,000원 전액을 답했다. 정답은 116,000원이다.⁷

249000원

규정이 답하지 않는 60개 가운데 29개가 틀렸다. 그중 스무 개는 규정이 정하지 않은 판단을 금액으로 단정했다. 한 질문은 이렇게 묻는다. "문의드려요. 구매한 지 44일 됐어요. 세이버 운임으로 샀고 운임은 316,000원, 세금·공항이용료는 13,000원이에요. 지금 취소하면 출발까지 18일 남은 상태예요. 가족상을 당해서 못 가게 됐어요. 사망 증명서 내면 수수료 면제되나요? 환불 얼마 받을 수 있나요?"

앱의 답은 인사 다음에 "안타까운 상황이네요"라고 한 뒤 질문을 둘로 나눈다. '사망으로 인한 수수료 면제 여부'라는 제목을 단 첫 단락은 제1조③을 짚는다. 질병·사망 같은 개인 사정의 수수료 면제는 이 규정이 정하지 않고 고객센터가 개별 심사로 정하니, 사망 증명서를 들고 고객센터에 직접 문의하라는 안내다. '현재 규정에 따른 환불액'이라는 제목을 단 다음 단락의 첫 줄은 이렇다. "개별 심사 결과를 기다리지 않고 규정상 환불액을 계산하면 다음과 같습니다." 운임 316,000원에서 세이버 수수료 80,000원을 빼고 세금을 더한 249,000원이 나오고, 마지막 줄은 "최종: 환불액 249000원"이다. 규칙 엔진의 답은 판단 불가다. 심사가 수수료를 면제하면 환불액은 결제 총액 329,000원이 되기 때문이다. 가족상이나 입원을 이유로 면제를 묻는 질문 14개 가운데 13개의 판정 줄이 이렇게 금액이었다. 입원 진단서를 내겠다는 한 질문에 앱은 "최종: 환불액 0원"이라고 적은 뒤 그 아래에 단서를 붙였다. "다만 질병 사유의 수수료 면제 심사 결과에 따라 달라질 수 있습니다." "최종: 판단 불가"로 끝난 것은 하나다. 이미 환불된 항공권의 좌석 지정·수하물·기내식 요금을 물은 13개 가운데서는 7개가 금액으로 끝났다. 반대쪽 실패, 곧 답이 있는 질문에 판단 불가로 물러선 답은 240개 가운데 하나도 없었다.⁸

나머지 아홉은 형식에서 걸렸다. 여행사·마일리지·단체로 산 항공권을 물은 20개 가운데 다섯이 틀렸는데, 다섯 모두 본문에서 이 규정으로는 답할 수 없다고 하고 문의처까지 일러 준 뒤 마지막 최종: 줄을 빠뜨렸다. 여행사에서 산 스탠다드 표를 물은 질문에 앱은 인사 다음 줄에 "죄송하지만, 판단 불가입니다"라고 적었다. 제1조②를 이유로 들고 여행사 고객센터에 문의하라고 한 뒤, 마지막 줄은 "도움이 되지 못해 죄송합니다!"였다. 판단 불가라는 말은 본문에 있었고 판정 줄에는 없었다. 규정에 없는 운임 등급을 물은 13개 가운데 둘, 부가 요금을 물은 질문 가운데 둘도 형식에서 걸렸다. 좌석 지정 요금 31,000원을 물은 질문에 앱은 그 요금은 고객센터에 확인하라고 쓰고, 마지막 줄에는 고객이 이미 처리됐다고 한 항공권 환불액을 다시 셈해 "최종: 항공권 환불액 403000원"이라고 적었다. 채점은 그 줄만 읽는다. 본문까지 읽는 채점이라면 이 가운데 일부는 정답이다. 사전 등록한 대로 그것들은 실패로 셌다. 첫 실행에서 형식이 깨진 답 열 개 가운데 아홉이 규정이 답하지 않는 질문에서 나왔다. 이 앱의 첫 실행에서는 규정이 답하지 않는다고 말하는 순간에 출력의 약속이 가장 자주 깨졌다. 나머지 하나는 규정이 답하는 질문에서 맞는 금액을 '환발액'이라는 오탈자 줄에 적은 답이다.⁹

규정이 답하는 180개에서 나온 실패 12건(금액 11건, 형식 1건)은 하위 유형 아홉 가지에 흩어져 있었다. 출발까지 35~120일 남은 스탠다드 표 3건, 출발 뒤에 취소한 플렉스 표 2건, 산 지 25시간 된 세이버 표와 스탠다드 표 1건씩 같은 식이다.¹⁰

49/50

시연 열 개는 처음부터 다섯 번씩 물었다. 첫 실행은 그 다섯 번 가운데 첫 번째다. 답의 무작위성을 정하는 temperature는 공급자 기본값에 맡겼다. 빌더가 손대지 않으면 그대로 쓰이는 값이다. 사전 등록은 경계에 걸린 질문과 규정이 답하지 않는 질문에서 같은 질문의 답이 갈릴 것이라고 예측했다. 50번 가운데 49번이 맞았다. 틀린 한 번은 세 번째 시연에서 나왔다. 60일 전에 산 세이버 표를 출발 57일 전에 취소하려는 질문이다. 첫 실행부터 네 번째 실행까지 앱은 251,000원이라고 답했다. 다섯 번째 실행은 제5조부터 따졌다.

**적용 규정**
제5조(구매 후 무료 취소)를 먼저 확인합니다.
- 구매 경과 시간 60일 > 24시간 ✓
- 남은 시간 57일(1,368시간) > 168시간(7일) ✓

두 조건을 모두 만족하므로 **제5조가 적용**되어 결제 총액 전액을 환불받습니다.

최종: 환불액 291000원

도전 세트에서 미리 지정한 40개도 240개와 함께 네 번씩 더 물었다. 그중 하나는 25시간 전에 결제한 스탠다드 표를 출발 68일 전에 취소하려는 질문이다. 첫 실행의 앱은 "구매 경과 시간이 24시간 이하 ✓ (25시간은 초과하지만, 확인 필요)"라고 적었다가, 몇 줄 아래에서 "죄송합니다"라며 제5조를 거두고 수수료 20,000원을 뺀 412,000원을 냈다. 두 번째 실행은 "25시간 (24시간 이하 ✓)"이라고 적고 결제 총액 432,000원 전액을 냈다. 다섯 번 가운데 412,000원이 두 번, 432,000원이 세 번이었다.¹¹

시연과 합친 50개 입력 가운데 다섯 번 다 맞은 입력이 35개, 다섯 번 다 틀린 입력이 3개였다. 나머지 12개는 때로 맞고 때로 틀렸다. 한 번 틀린 입력이 6개, 두 번이 3개, 세 번이 2개, 네 번이 1개다. 50개 가운데 24%다. 입력을 다시 뽑아 잰 95% 구간은 12~36%이고, 예측한 12%는 그 아래 끝에 걸렸다. 시연에서 하나, 미리 지정한 40개에서 열하나가 갈렸다.¹²

같은 질문을 다섯 번 묻는 일은 그 질문 하나의 답이 얼마나 흔들리는지를 잴 뿐, 서로 다른 질문의 수를 늘리지 않는다. 그래서 240개의 실패율은 질문마다 첫 실행 한 번으로만 셌다. 첫 실행만 본 사람에게 세 번째 시연은 맞은 질문이다.

25.9%

1983-04-01 JAMA에 실린 James Hanley와 Abby Lippman-Hand의 글은 제목이 질문이다. 「아무 일도 잘못되지 않았다면, 다 괜찮은가?」 두 사람이 독자로 삼은 사람은 임상의다. 시술의 위험을 묻는 환자 앞에서, 지금까지 문제가 없었다는 기록만 쥔 의사. 0이라는 분자는 흔히 수치로서의 뜻을 훨씬 넘어서는 질적인 무게를 가진 것처럼 보인다고 그들은 썼고, 예로 아직 환자를 한 번도 잘못 분류하지 않은 새 진단 검사, 여전히 완벽한 수술 기록, 사망 사고가 한 번도 없었던 항공사를 들었다.¹³ 그리고 셈을 내놓았다. 환자 n명 가운데 걱정하던 사건이 한 번도 일어나지 않았다면, 그 사건의 확률이 많아야 3/n이라고 95% 확신할 수 있다. 실패율이 p인 시행을 서로 독립으로 n번 해서 한 번도 실패하지 않을 확률 (1 − p)^n을 5%로 놓고 p를 풀면 1 − 0.05^(1/n)이 나온다. ln 0.05가 −3에 가까워서 그 값은 대략 3/n이다. 두 사람은 3이 어떻게 그 자리에 들어갔는지 보이려고 식을 급수로 풀어 놓았다. 99%로 확신하려면 3 대신 4.6이, 99.9%면 6.9가 들어간다. 두 사람은 이 규칙을 출처를 모르는 간단한 규칙이라 부르고 1975년 NEJM의 글 하나를 달았다. 그 글의 제목은 「'부작용은 관찰되지 않았다'는 진술의 함의」다. 3의 규칙은 그들이 만든 것이 아니다.¹⁴

n이 10이면 정확한 값은 25.9%, 3/10으로 어림하면 30%다. 논문의 표도 0/10 옆에 26%를 적었다(괄호 안은 30%). 본문의 괄호 단락은 이렇게 덧붙였다. n이 이만큼 작으면 최대 위험이 워낙 커서, 그 값과 규칙이 주는 30%의 차이는 보통 따질 거리가 못 된다. 이 숫자는 실패율의 추정치가 아니다. 같은 분포에서 무작위로 뽑은 서로 독립인 열 번이 모두 성공했다면, 95%의 확신으로 배제되는 것은 실패율이 25.9%보다 높은 경우뿐이라는 뜻이다. 셈법을 바꿔도 이 자리는 크게 움직이지 않는다. 양쪽으로 잡은 정확 구간의 끝은 30.8%, 균등한 사전분포를 둔 베이즈 셈으로는 23.8%이고, 같은 셈으로 다음 한 번이 성공할 확률을 구하면 11/12, 약 91.7%다. 반대쪽 셈도 있다. 성공률 90%짜리 작업이 열 번 연속 성공할 확률은 34.9%, 95%짜리는 59.9%, 99%짜리는 90.4%다. 같은 표 옆에는 이 셈을 약을 거르는 데 쓴 실무 규칙도 실려 있다. 항암제 연구에서 환자 14명이 연달아 반응하지 않으면, 다섯 명 가운데 한 명에게도 듣지 않는 약으로 보고 걸러 낸다. 0/14의 상한이 19%라서다. 글은 '아직까지 문제없음(no problems so far)'을 보고할 수 있는 운 좋은 이들에게 권하는 말로 끝난다. 앞으로의 환자들이 기대할 수 있는 최악 또는 최선을 숫자로 말하라는 것이다.¹⁵

이 셈에는 조건이 붙는다. 열 번이 같은 분포에서 서로 독립으로, 무작위로 뽑힌 시행이어야 한다. 무작위로 뽑은 열 개였더라도 0/10은 25.9%까지는 배제하지 못한다. 그 앱의 열 개는 무작위로 뽑지 않았다. 빌더가 처음 넣어 볼 법한 질문의 층에서 규칙으로 골랐다. 그렇게 고른 열 개에는 그 계산으로 사용 입력의 실패율 상한이 주어지지 않는다. 240개에서 나온 실패 41개 가운데 29개는 그 선택 규칙이 정의상 넣지 않은 층, 규정이 답하지 않는 질문에서 나왔다.¹⁶

1,617

2005-02-28, 미국 식품의약국(FDA)이 공중보건 권고 하나를 냈다. 다발성 경화증 치료제 나탈리주맙(상품명 Tysabri)의 판매가 중단됐다는 내용이다. 진행성 다초점 백질뇌증(PML), 뇌에 드물게 생기는 감염이 두 환자에게서 나왔다. 권고는 "확진된 사망 사례 하나와 추가 사례 하나"라고 적었다. 두 환자는 2년 넘게 약을 맞아 온 장기 임상 참가자였고, 둘 다 다른 약 Avonex를 함께 맞고 있었다. 사례는 시판 뒤의 자발 보고가 아니라 진행 중이던 임상에서 나왔다. 석 달 전인 2004-11 FDA가 이 약을 가속 승인할 때의 숫자도 권고에 있다. 승인 당시 약 1,100명이 1년 이상 이 약을 맞았고, 승인 전 임상에서 PML은 한 건도 관찰되지 않았다. 권고는 의심 사례가 보이면 MedWatch로 곧바로 보고하라는 말로 끝난다.¹⁷

승인 라벨은 다발성 경화증 환자 1,617명이 이 약에 노출됐다고 적었다. 노출 기간의 중앙값은 20개월이다. 이 임상 참가자들을 앞으로 이 약을 맞을 환자에서 무작위로 뽑은 표본으로 보고 0/1,617을 3의 규칙으로 읽으면, 95%의 확신으로 말할 수 있는 것은 위험이 0.185% 이하라는 것까지다. 약 540명에 1명이다. 1년 이상 맞은 1,100명만 세면 그 끝은 0.272%로 올라간다.¹⁸ 2006-03-02 NEJM에 실린 평가는 이 약을 맞은 3,417명 가운데 3,116명을, 평균 17.9회 투여한 뒤에 다시 살폈다. 새 사례는 없었고, 확진된 것은 이미 보고된 세 건뿐이었다. 그 가운데 하나는 다발성 경화증이 아니라 크론병으로 이 약을 맞은 환자다. 위험은 1,000명당 1.0명(95% 신뢰구간 0.2~2.8명)으로 적혔다. 0.1%는 처음부터 0.185% 안에 있었다. 위험이 정말 1,000명에 1명이라면 1,617명에서 한 건도 보지 못할 확률은 19.8%다. 그 평가는 더 오래 맞을 때의 위험은 알려지지 않았다고 적었다. 노출 기간이 서로 다른 사람들을 한데 센 숫자라 이 셈은 어림이다.¹⁹ 2006-06-05, FDA는 판매 재개를 승인했다. 재개의 조건은 등록제 위험 관리 프로그램 TOUCH였다.²⁰

0을 어디까지 믿을지는 규제 문서에도 숫자로 들어가 있다. 1994-10-27 미국·유럽·일본의 규제 당국과 제약업계가 함께하는 ICH가 채택을 권고한 지침 E1은, 생명을 위협하지 않는 병에 오래 쓰는 약을 몇 명에게 얼마 동안 시험할지를 정했다. 지침은 부작용의 발생과 검출에 관한 이전 경험, 정해 둔 빈도의 부작용을 검출할 확률에 대한 통계적 고려, 실무적 고려를 그 근거로 밝혔다. 늦게 나타나는 발생률 0.5~5%의 사건을 보려면 6개월 노출에 대개 300~600명이면 충분하다고 적었고, 최소 1년 동안 맞은 환자 100명에게서 중대한 부작용이 한 건도 없으면 1년 누적 발생률이 3%를 넘지 않는다는 "합리적 보증"이 될 수 있다고 적었다. 3/100, 3의 규칙이다. 지침이 고른 낱말은 입증이 아니라 보증이다. 그 100명이 0.5%짜리 사건을 한 번이라도 볼 확률은 39%, 0.1%짜리면 9.5%다.²¹ 총 노출 인원은 약 1,500명으로 잡았다. 지침이 쓴 말은 필수가 아니라 예상이고, 더 크게 또는 더 작게 잡아야 할 경우를 따로 늘어놓았다. 그 1,500명이 1,000명에 1명꼴인 사건을 한 번이라도 볼 확률은 77.7%, 1만 명에 1명꼴이면 13.9%다. 같은 지침은 일본이 500~1,500명을 받는 이유도 적었다. 시판 후 조사 의무가 있어서 시판 전 인원이 더 적을 수 있다는 것이다.²²

2.5%

같은 날 같은 설계로 잰 다른 조건에서는 숫자가 달랐다. 누리별항공의 둘째 앱은 상담 메시지에서 예약번호·이름·편명·출발일·금액·휴대폰 번호·요청 종류를 뽑아 JSON 하나로 낸다. 정답은 메시지를 만들기 전에 정한 값 그 자체이고, 일곱 칸 가운데 하나만 달라도 실패로 센다. 이 앱도 시연 열 개를 다 맞혔고, 240개에서는 2.5%(95% 구간 0.8~4.5%)를 틀렸다. 예측한 7%는 그 구간 밖이었다. 틀린 여섯 가운데 셋은 변경 전 날짜를 출발일로 옮겼고, 하나는 예약번호가 없는 메시지에 취소된 예전 번호를 넣었다. 다섯 번씩 물은 50개 입력 가운데 답이 갈린 것은 하나였다.²³

환불 앱의 모델을 다른 공급자의 gpt-5.5로 바꾸면 240개 가운데 6개, 2.5%(1.2~4.2%)를 틀렸다. 규정이 답하는 180개는 하나도 틀리지 않았고, 틀린 여섯은 모두 개인 사정 질문에서 금액을 단정한 답이었다. 사전 등록한 예측은 7%였고, 근거 칸에는 실패가 규정이 답하지 않는 질문의 '친절한 단정'에 몰리리라고 적혀 있었다. 숫자는 빗나갔고 자리는 맞았다. 시연 열 개를 다섯 번씩 돌린 50번도 다 맞았다. gpt-5.5로 돌린 추출 앱은 240개에서 1.7%(0.4~3.4%)를 틀렸다. 예측한 3%는 그 구간 안이었다. 틀린 넷은 모두 '4ER 4AM'이나 '3qt97r'처럼 변형된 표기로 쓴 예약번호를 바로잡지 않고 빈칸으로 둔 답이다.²⁴

측정 전에 정한 기준이 있었다. 시연과 도전 세트의 성공률 차가 10%p 이하이고 도전 세트 실패율이 3% 미만이면 열 개가 240개를 잘 예측한 것으로 본다. gpt-5.5는 두 앱 모두에서 이 기준을 충족했다. 그 모델에서는 열 개의 시연이 240개를 잘 예측했다. claude-haiku-4-5로 돌린 추출 앱도 기준 안에 들었다. 네 조건 가운데 열 개가 240개를 놓친 것은 claude-haiku-4-5로 돌린 환불 앱 하나다. 그 앱에 사전 등록한 두 예측(시연 실패율 5%, 도전 세트 15%)의 차이는 기준선과 같은 10%p였고, 측정은 17.1%p였다.²⁵ 첫 숫자가 뒤의 숫자를 잘 맞힌 기록은 바깥에도 있다. Klarna는 2024-02-27 AI 상담 도우미가 출시 한 달 만에 상담 대화의 3분의 2를 맡았다고 발표했고, 2025-09-02 미국 증권거래위원회에 낸 증권신고서에는 12개월 동안 69%, 상담원 700명 이상의 일이라고 적었다(회사 자체 측정).²⁶

240개는 한 앱의 실패를 셌다. 17.1%와 2.5%를 나란히 놓을 수 있는 것은 두 모델이 같은 240개를 받았고, 같은 판정을 받았기 때문이다. 이 측정에서 그 판정은 규칙 엔진이 했다.

같은 질문과 같은 판정 기준을 고정해야 그 조건에서 모델을 비교할 수 있다. 질문과 기대 답을 한 설계가 함께 만들면, 설계는 무엇을 실패로 셀지와 어떤 입력을 얼마나 시험할지를 정한다. 실제 실패가 어느 층에 얼마나 쌓이는지는 모델의 출력으로 확인해야 한다. 이 측정에서는 두 모델 모두 규정이 답하지 않는 층에 실패가 몰렸지만, 그 집중을 설계가 보장했다고 읽지 않는다. 마지막 줄만 읽는 판정은 본문 안내의 적절성과 다른 범위를 잰다.

오전 10시 32분에 커밋한 예측 표의 그 칸에는 15%가 적혀 있었다. 그 앱이 240개에서 낸 실패율은 17.1%였다.

채점자를 잰다

회계 책임자

1980년 뉴욕 대학 컴퓨터과학과의 기술보고서 25호에서 Elaine Weyuker는 프로그램 시험이라는 일의 밑바닥에 깔린 가정 하나를 꺼냈다. 시험을 연구하는 사람들은 프로그램의 출력이 맞는지 틀렸는지를 누군가 가려낼 수 있다고 전제한다. 그 누군가를 오라클이라 부른다. 사람이 오라클일 때도 있고, 정답표나 다른 프로그램이 그 자리에 설 때도 있다. Weyuker는 그 전제가 무너지는 경우를 이렇게 정의했다. "오라클이 없거나, 출력이 맞는지 판정하는 데 시험하는 사람이 비상한 시간을 들여야 한다면, 그 프로그램은 시험할 수 없다."¹

정답을 몰라도 틀린 답은 가려낼 수 있다는 것을 보이려고 그가 든 예는 큰 회사의 총자산을 계산하는 프로그램이다. 출력이 100달러나 1,000달러라면 그럴듯한 답이 아니다. 1,000,000달러는 시험하는 사람에게는 그럴듯해 보여도, 회사의 회계 책임자라면 틀렸다고 가려낼 만한 정보가 있을 수 있다. 그러나 회계 책임자도 1,134,906.43달러가 맞고 1,135,627.85달러가 틀렸다는 것까지 쉽게 가려내기는 어렵다. Weyuker는 이렇게 썼다. "그래서 전문가조차 그럴듯한 오답을 정답으로 받아들일 수 있다."²

회계 책임자는 그래도 쓸모가 있다. 말이 안 되는 숫자를 걸러 범위를 좁힌다. Weyuker는 같은 식으로 sin 42°의 값을 0.6657과 0.7071 사이로 좁히는 예를 들었다. 정답을 몰라도 범위 밖의 답은 틀렸다고 말할 수 있는 이런 판정자를 부분 오라클이라 부른다. 그가 꼽은 시험할 수 없는 프로그램의 첫 부류는 답을 알아내려고 짠 프로그램이다. 정답을 알았다면 그 프로그램을 짤 필요가 없었다. 다른 부류도 있었다. 30자리 숫자가 줄줄이 찍힌 출력 한 쪽은 사람이 대조하기에 그저 너무 지루할 수 있다. 시험하는 사람이 원래 문제와 다른 명세를 기준으로 출력을 보고 있을 수도 있다. 결론의 마지막 문장은 이렇다. "이것이 시험하는 사람이 마주해야 할 근본적인 한계라고 우리는 믿는다."³

2015년, 1978년부터 2012년까지의 출판물 694편을 정리한 소프트웨어 시험 서베이는 '시험 오라클'이라는 말이 1978년 William Howden의 글에서 처음 나왔다고 적고, 자동으로 만든 오라클이 모두 모자랄 때 마지막 판정자는 여전히 사람이라고 정리했다. 그 사람이 회계 책임자라면 판정은 범위를 좁히는 데서 멈춘다. 정답 없는 출력 앞에서 판정자를 믿을지 버릴지만 남는 것은 아니다. 판정자도 시험할 수 있다. 같은 질문을 다시 묻거나 순서를 바꿔 물어 판정이 흔들리는지 보고, 정답을 아는 문제를 섞어 넣어 맞히는지 보면, 그 판정자가 무엇을 가리고 무엇을 못 가리는지가 숫자로 나온다.⁴

결항 승객

누리별항공 환불 앱에도 오라클이 없는 자리가 있다. 한 질문은 이렇다. "구매한 지 25일 됐어요. 스탠다드 표로 총 252,000원 결제했는데 그중 세금·공항이용료가 58,000원이래요. 항공사에서 그 편이 결항됐다고 연락이 와서 안 가려고요. 원래 출발 시각까지 6시간 남았어요. 환불 얼마 받을 수 있나요?" 규칙 엔진의 답은 252,000원이다. 항공사가 결항하면 결제 총액 전액이고, 그 조항이 다른 조항보다 먼저 온다.

claude-haiku-4-5의 답은 상황 분석, 적용 규정, 계산의 세 칸으로 나뉜다. 구매 경과 25일과 남은 6시간, 운임 194,000원을 차례로 적고, 제3조의 적용 순서에 따라 제4조가 먼저라고 밝힌 뒤 "구매 경과 시간이나 남은 시간과 관계없이" 전액이라고 맺는다. gpt-5.5의 답은 두 문장과 계산 한 줄이다. "항공사 사유로 결항되어 탑승하지 않고 취소하는 경우에는 제4조가 먼저 적용됩니다. 따라서 구매 후 24시간 초과 여부나 출발까지 6시간 남은 점, 스탠다드 수수료와 관계없이 결제 총액 전액 환불입니다." 두 답의 마지막 줄은 같다. "최종: 환불액 252000원."⁵

규칙 엔진은 두 답에 똑같이 정답 표시를 한다. 설명의 길이와 순서, 조항을 옮기는 방식은 규칙 엔진이 읽는 칸이 아니다. 240개의 설계가 정한 것은 금액과 「판단 불가」뿐이고, 어느 안내문이 나은지는 정하지 않았다. 그래서 거기에는 규칙 엔진이 없다. 두 모델의 답이 모두 맞은 질문들 가운데 100개를 뽑아 이런 쌍을 만들었다. 결론은 같고 설명만 다른, 정답이 하나가 아닌 쌍이다. 이 측정은 이런 쌍을 열린 쌍이라 불렀다. 여기서 판정자 노릇을 할 수 있는 것은 사람이나 다른 모델이다.⁶

판정자들

1953년 색인 체계 둘을 맞대 보려던 두 팀은 어떤 문서가 질문에 '관련'되는지 합의하지 못해 공동 결과를 내지 못했다.⁷ 그 일을 1962년 보고서에 옮긴 크랜필드의 Cyril Cleverdon은 관련성 논쟁에 빠지지 않으려고 질문을 컬렉션 안의 문서에서 짓게 했다. 검색이 그 '출처 문서'를 찾으면 성공이었으니, 정답은 질문이 태어날 때 이미 정해져 있었다.⁸ Sparck Jones가 1981년 결산에 옮겨 적은 대로라면, 1965-01 Don Swanson은 출처 문서로 지은 질문과 관련성을 통제하지 않은 점 등을 들어 "설계 자체가 발견된 결과의 상당수를 보장한 것으로 보인다"고 썼다.⁹ 그 앱의 240개도 질문과 정답을 한 설계가 함께 만들었지만, 실패가 어느 층에 얼마나 쌓일지는 출력이 보여 줬다.

1992년에 시작된 검색 평가 대회 TREC에서는 참가한 시스템이 모두 같은 문서와 주제(질문)로 같은 채점을 받았다. 판정은 문서 전부가 아니라 시스템마다 상위에 올린 문서를 모은 풀에만 내려졌고(풀링), 풀에 들지 못한 문서는 판정 없이 비관련으로 셈해졌다.¹⁰

규칙 엔진은 같은 사실에 늘 같은 판정을 낸다. 판정자가 사람이면 같은 기준을 받아도 판정이 갈린다. TREC-4에서는 49개 주제를 주제마다 세 사람이 따로 판정했고, Voorhees가 그 결과를 맞대 봤다. 관련 문서 집합이 겹친 정도, 곧 둘 다 관련이라고 본 문서를 둘 중 하나라도 관련이라고 본 문서로 나눈 값의 주제 평균은 두 사람 사이에서 0.421~0.494, 세 사람 모두에서 0.301이었다.¹¹

그런데 판정을 바꿔도 시스템 순위는 거의 그대로였다. 원래 판정으로 매긴 순위와의 Kendall 상관은 셋 중 하나라도 관련이라고 본 문서를 관련으로 치면 0.9508, 셋 모두 관련이라고 본 문서만 치면 0.9015였다. Kendall 상관은 두 순위가 같은 순서일수록 1에 가까워지는 값이다. 주제마다 세 판정자 가운데 하나를 무작위로 골라 짠 판정 집합들로 매긴 순위도 원래 순위와의 상관이 평균 0.938이었다. 집합끼리 판정을 일부 나눠 가져 이 값은 조금 높게 나왔을 것이라고 Voorhees는 적었다. 그의 결론은 이렇다. "완벽한 검색을 정의하는 데 쓰인 관련성 판정이 크게 달라도, 검색 전략들의 상대적 효과는 안정적이다." 단서도 붙었다. 관련 문서가 다섯 건 안팎보다 적은 질의에서는 점수 자체가 불안정하고, 사용자와 많이 주고받는 시스템은 더 흔들리며, 서로 다른 시스템끼리 견줄 때는 한 시스템의 변형끼리보다 더 큰 점수 차가 있어야 의미가 있다. 절대 점수는 판정에 따라 움직였고, 순위가 버틴 시스템들은 1995년 TREC-4 애드혹 과제에 전체 문서로 결과를 낸 33개였다.¹²

Cleverdon도 1970-10의 보고서에서 Cranfield II의 색인 언어 순위가 판정에 휘둘렸는지 확인했다. 보고서는 Cranfield II의 주된 시험들이 원래 문서와 질문의 부분 모음, 곧 문서 200건과 질문 42개 위에서 이뤄졌다고 적고, 그 부분 모음을 다시 썼다. 다른 세 사람의 새 판정으로 19개 색인 언어를 다시 셈하자, 세 순위 모두 원래 순위와의 상관이 0.921 이상이었다.¹³ 판정이 갈려도 남은 안정은 여러 질문에 걸쳐 평균 낸 시스템 순위의 것이었고, 안내문 하나하나의 우열은 재지 않았다.

심판

모델을 판정자로 세운 연구 가운데 한 갈래는 답 하나하나에 내린 판정을 쟀다. 2023-06 Lianmin Zheng 외 12명은 챗봇의 답 두 개를 놓고 GPT-4 같은 모델에게 어느 쪽이 나은지 묻는 방식을 시험했다. 두 답의 순서만 바꿔도 같은 판정이 나오는 비율은 Claude-v1이 23.8%, GPT-3.5가 46.2%, GPT-4가 65.0%였다. "60%가 넘는 경우에 일관된 결과를 낸 것은 GPT-4뿐"이었다. Claude-v1은 기본 프롬프트에서 75.0%를 첫 번째 답 편으로 판정했고, 답의 이름만 바꾼 프롬프트에서는 "Assistant A"라는 이름을 편들었다. 논문이 실은 한 예에서 GPT-4는 GPT-3.5의 답이 앞에 오면 GPT-3.5를, 뒤로 보내면 Vicuna를 골랐다. 저자들은 비교한 답들이 매우 비슷해 사람에게도 어려운 시험이었다는 단서를 달았다. 2023년의 모델들이 낸 숫자다.¹⁴

수학 문제에서는 다른 약점이 보였다. 문제 10개를 순서를 바꿔 20번 판정하게 하자, GPT-4가 틀린 답을 맞다고 한 경우가 기본 프롬프트로 14번, 단계별로 생각을 쓰게 하면 6번, 판정 전에 GPT-4가 따로 푼 답을 참고 답안으로 넣어 주면 3번이었다. 따로 물으면 풀 수 있는 문제에서도 GPT-4는 제시된 답에 이끌렸다고 저자들은 적었다. 참고 답안은 판정자에게 바깥에서 들여온 오라클이다. 그것이 있을 때 판정이 나아졌다.¹⁵

같은 논문은 반대쪽 숫자도 냈다. 질문 80개에 모델 6개의 답을 놓고, 대부분 대학원생인 전문가 판정자 58명이 약 3,000표를 던졌다. 대화의 첫 차례에서 이들의 판정과 GPT-4의 판정을 맞대자, 무승부를 뺀 판정에서 GPT-4와 사람의 일치는 85%로 사람끼리의 81%보다 높았다. 무승부를 넣으면 66% 대 63%였고(이어 물은 둘째 차례에서는 66% 대 67%), 우연히 맞을 기준선은 무승부를 빼면 50%, 넣으면 33%다. 사람끼리 81%라는 숫자는 기준으로 세운 사람 판정자도 하나의 판정자라는 뜻이기도 하다. 자기 선택이 GPT-4와 갈린 판정에서 GPT-4의 판정을 보여 주자, 사람들은 그 가운데 75%에서 그 판정이 타당하다고 봤고 34%에서는 자기 선택을 바꿀 뜻이 있었다.¹⁶

모델의 순위로 올라가면 사람 순위와의 상관은 더 높게 나온다. 2024년 Dubois 외는 GPT-4 Turbo 자동 채점이 긴 답을 좋아하는 경향을 회귀로 보정하자, Chatbot Arena의 사람 순위와의 Spearman 상관이 0.94에서 0.98로 올랐다고 보고했다. 보정 전의 자동 채점은 답을 길게 쓰라는 지시만으로도 점수가 크게 흔들렸고, 저자들은 그것이 AI 시스템에게 상당히 공략당할 수 있다고 적었다. 같은 해 프롬프트 500개로 모델 하나를 20달러에 채점한다는 Arena-Hard는 초록에서 사람 선호 순위와 98.6% 상관을 내세웠다. 상위 20개 모델 전체를 비교한 표에서는 93.2%였고, 98.6%는 문체를 보정하고 어려운 프롬프트로 비교한 조건의 값이다. 같은 표에서 MT-Bench는 상관이 89.9%인데, '확신 일치(confidence agreement)'는 26.6%였다. 두 순위가 모두 확신을 갖고 가른 모델 쌍에서 순서가 같으면 1점, 다르면 −1점, 어느 한쪽이라도 가르지 못하면 0점을 매긴 값이다. 판정자는 쓸모없지 않다. 모델의 순위를 맞히는 일과 답 하나하나를 맞히는 일이 다를 뿐이다.¹⁷

세 채점자

누리별항공 환불 앱의 답 쌍으로 채점자를 쟀다. 측정의 꼴은 TREC-4의 세 판정자 실험을 채점자에게 옮겨 놓은 것과 같다. 거기서 이어받는 것은 판정자를 바꾸면 비교가 남는가라는 분석 질문 하나다. TREC-4가 그 질문으로 잰 것은 순위의 안정이었고, 이 측정은 순위를 만들지 않았다. 쌍을 짓는 법과 채점 기준, 순서 교환과 재질문은 이 측정의 절차로 따로 정했다. 사전 등록은 쌍을 두 묶음으로 나눴다. 하나는 정답을 아는 쌍 85개다. 두 모델 가운데 한쪽만 맞힌 질문 27개(그런 질문 37개 가운데 틀린 답이 형식 실패인 10개는 뺐다), 그리고 숫자만 바꾼 가짜 규정을 claude-haiku-4-5에게 주어 받아 낸 확신에 찬 오답을 원래의 정답과 짝지은 58개다. 다른 하나는 결항 승객의 두 답 같은 열린 쌍 100개다. 판정은 grok-4.7, gpt-6-astra, gpt-5.6-sol 세 채점자가 맡았다. 규정 원문과 채점 기준을 주고, 어느 모델이 쓴 답인지는 가렸다. 기준은 결론이 규정에 맞는지를 먼저, 조항과 계산의 설명이 정확한지를 다음으로, 고객이 이해하기 쉽고 정중한지를 마지막으로 보라고 했다. 우열을 가릴 수 없으면 동점이고, 답의 길이와 제시 순서는 기준이 아니라고 적었다. 쌍마다 네 번 물었다. 원래 순서로, 순서를 바꿔, 원래 순서로 한 번 더, 그리고 첫 결과를 본 뒤 모호한 곳을 고친 기준으로. 판정은 모두 2,220개였고, 판정 줄을 읽지 못한 출력은 없었다.¹⁸

반증선은 측정 전에 정했다. 순서를 바꿔 움직인 판정, 곧 순서 효과가 5%p 미만이고, 세 채점자의 일치가 0.8을 넘고, 기준 문구를 고쳐 움직인 판정, 곧 기준 효과가 5%p 미만이면, 이 설정에서는 채점자가 치우친다고 주장할 근거가 모자란다고 보고하기로 했다. 움직인 판정은 같은 순서로 다시 물었을 때 바뀐 비율을 빼고 셌다. 다시 묻기만 해도 바뀌는 만큼은 순서나 기준의 탓이 아니기 때문이다. 일치는 처음에 Fleiss κ로 재기로 했다가, 결과보다 먼저 Gwet의 AC1로 바꿨다. κ는 판정이 맞아떨어진 정도에서 우연히 맞아떨어질 만큼을 덜어 낸 값이고, 1이면 완전한 일치다. AC1도 우연히 같을 만큼을 덜어 내지만, 판정이 한 범주로 몰릴 때 관측 일치가 높은데도 값이 낮게 나오는 κ의 역설을 덜 탄다.¹⁹

정답을 아는 쌍에서 세 채점자는 98.8%를 맞혔다. 동점도 오답으로 센 값이다. 가짜 규정으로 받아 낸 오답 58쌍은 세 채점자 모두 하나도 놓치지 않았고, 두 모델 가운데 한쪽만 맞힌 27쌍에서는 96.3%였다. 일치는 AC1 0.976, 순서를 바꿔 움직인 판정은 1.2%p였다. 기준 문구를 고치자 바뀐 판정은 3개(1.2%)였는데, 같은 순서로 다시 물었을 때 바뀐 비율과 같아 기준 효과는 0.0%p다. 같은 85쌍으로 세 채점자의 Fleiss κ를 셈하면 −0.012가 나온다. 세 판정의 관측 일치가 0.976인데 그렇다. 판정이 정답 쪽으로 몰릴수록 κ가 0 근처로 떨어지는 역설이 실측에서 그대로 나타났다.²⁰

열린 쌍에서는 달랐다. AC1은 0.515로 떨어졌다. 순서를 바꾸면 판정의 27.0%가 바뀌었고, 같은 순서로 다시 물어도 17.3%가 바뀌었다. 그 차이인 순서 효과가 9.7%p다. 기준 문구를 고치자 판정의 40.7%가 움직였고, 재검사 변동을 빼면 23.3%p다. 판정의 44.7%가 동점이었다. 185쌍 전체로는 순서 효과 5.8%p(95% 구간 2.3~9.4%p), AC1 0.734(0.669~0.798), 기준 효과 12.6%p(7.9~17.5%p)였다. 세 항 모두 반증 조건을 채우지 못했고, 셋 다 채점자가 치우친다는 쪽에 놓였다. 순서 효과는 점추정이 반증선을 0.8%p 넘었고 구간이 반증선을 걸쳐, 셋 가운데 가장 얇은 근거다. 나는 일치와 정확도를 둘 다 더 낮게 예측했다(185쌍의 AC1 0.53, 85쌍의 AC1 0.78과 정확도 88%). 채점자들은 예측보다 정확했고 서로 더 일치했다.²¹

결항 승객의 쌍에서 세 채점자의 판정은 셋으로 갈렸다. grok-4.7은 긴 답을 골랐다. 제3조의 적용 순서와 운임·세금 구성을 함께 밝혀 계산 근거가 더 분명하고, 응대도 더 정중하고 이해하기 쉽다는 이유였다. gpt-5.6-sol은 짧은 답을 골랐다. "결항되어 탑승하지 않고 취소하는 경우"라는 제4조의 적용 조건까지 더 정확히 설명했다는 이유였다. gpt-6-astra는 우열을 가리기 어렵다며 동점을 줬다. 두 답의 순서를 바꾸자 gpt-5.6-sol의 판정은 동점으로 옮겨 갔다.²²

채점자마다 결도 달랐다. 순서 효과는 grok-4.7이 3.2%p, gpt-6-astra가 6.5%p, gpt-5.6-sol이 7.6%p였고, 동점을 준 비율은 16.2%, 32.4%, 25.4%였다. 기준 효과는 거꾸로 grok-4.7이 15.7%p로 가장 컸다. 합쳐 보면 첫 번째 자리의 답을 고르는 쏠림은 없었다. 동점을 뺀 판정에서 세 채점자가 A를 고른 비율은 45~49%였다. 순서 효과는 늘 앞의 답을 고르는 꼴이 아니라 순서를 바꾸면 판정이 바뀌는 꼴로 나타났다.²³

채점자 구성에도 단서가 붙는다. 사전 등록한 세 번째 채점자는 claude-sonnet-4-6이었다. 측정 당일 이 모델은 상류의 레이트 리밋 때문에 한 시간 넘게 응답을 내지 못했고, 사전 등록한 단 한 번의 교체 경로대로 gpt-5.6-sol로 바꿨다. 그래서 OpenAI 계열이 둘이 됐다. 같은 공급자의 모델은 판정 습관이 비슷할 수 있으니 일치가 위로 치우쳤을 수 있다. 측정된 AC1은 이미 0.8 아래라, 치우침이 있었다면 실제 일치는 더 낮다.²⁴

열린 쌍에서 세 채점자가 보인 AC1 0.515를 판정자들의 겹침이나 순위 상관 옆에 놓을 수는 있지만 같은 양으로 읽을 수는 없다. 겹침과 순위 상관은 관련 문서 집합과 시스템의 순서를 재고, AC1은 쌍 하나하나에 내린 판정이 우연 이상으로 얼마나 같은지를 잰다. 이 측정은 두 모델의 순위를 재지 않았다. 판정은 쌍마다 받았을 뿐 그 판정들을 모아 순위를 세우지 않았으니, 판정이 갈려도 순위가 버틴다는 결과를 견줄 자리가 이 측정에는 없다.

이 측정이 보여 주는 것은 더 좁다. 같은 열린 쌍 100개를 원래 순서로 처음 물은 판정에서 gpt-5.5의 답을 고른 수, claude-haiku-4-5의 답을 고른 수, 동점의 수는 grok-4.7이 32·38·30, gpt-6-astra가 33·10·57, gpt-5.6-sol이 36·17·47이었다. 어느 모델의 안내문이 나은가에 대한 답은 채점자에 따라 달랐다. 둘은 gpt-5.5의 답을 훨씬 많이 골랐다. 하나는 claude-haiku-4-5의 답을 조금 더 골랐지만(38 대 32) 어느 쪽으로도 뚜렷하지 않았다. 동점을 준 수가 채점자마다 달라서 비율을 내면 분모가 다르고, 이 수는 첫 판정만 센 것이다. 채점자마다 claude-haiku-4-5의 답을 고른 비율은 사전 등록에서 선호로만 보고하기로 정한 값이지만, 세 수를 이렇게 펼친 표시와 Wilson 구간은 결과를 본 뒤 더한 사후 기술이다. gpt-6-astra와 gpt-5.6-sol은 gpt-5.5와 같은 OpenAI 계열이다. 어느 모델의 답인지는 가렸으니 이 수는 선호로만 적는다. 같은 계열의 답을 더 고른 선호인지 안내문의 품질 차이인지는 이 측정으로 가르지 못한다.²⁵

문지기

2023-05-25 뉴욕 남부 연방지방법원에 진술서 하나가 들어왔다. Mata v. Avianca 사건에서 원고 측 변호사 Steven Schwartz가 서명한 것이다. 30년 넘게 주 법원 사건만 맡아 온 그가 ChatGPT로 법률 조사를 한 것은 이 사건이 처음이었다. ChatGPT는 대학생 나이의 자녀들에게서, 그리고 읽은 기사들에서 알게 됐다고 그는 뒤에 적었다. 진술서에 붙은 화면은 휴대폰 캡처다. 상태 표시줄의 시각은 3:43, 배터리는 충전 중이고, 대화 제목은 "Tolling Montreal Convention Statute"다. 그는 ChatGPT에게 "Is varghese a real case"라고 물었다. 답은 실제 판례라는 것이었다. "What is your source"라고 되묻자 답은 사과로 시작했다. "앞서의 혼란에 사과드립니다. 다시 확인해 보니 Varghese 사건은 실제로 존재합니다." 그가 다시 "Are the other cases you provided fake"라고 묻자 답은 이랬다. "아니요, 제가 드린 다른 판례들도 진짜이며 LexisNexis나 Westlaw 같은 믿을 만한 법률 데이터베이스에서 찾을 수 있습니다."²⁶

판례가 진짜인지를 그 판례를 내놓은 기계에게 다시 물은 것이다. 이 질문을 언제 했는지에 대한 그의 설명은 바뀌었다. 5월의 진술서는 서면을 내기 전에 물은 것처럼 읽혔고, 6월의 선언서는 법원이 2023-05-04 명령을 낸 뒤 이미 크게 의심하던 상태에서 물었다고 했다. 법원은 이를 이랬다저랬다 하는 모순된 설명이라 불렀다.²⁷

바깥의 확인은 일찍 왔다. 서면을 낸 지 2주 만인 2023-03-15 상대방 답변서가 인용된 판례 대부분을 찾을 수 없다고 적었고, 2023-04-11과 2023-04-12에는 법원이 판례 사본을 내라고 명령했다. 두 변호사는 물러서지 않았다. 2023-06-08 정오, 펄 스트리트 500번지 법원의 11D호 법정에서 열린 심리에서 판사가 물었다. "Varghese 판결 전문을 찾아보러 갔을 때 무엇을 찾았습니까?" "찾지 못했습니다." "그런데도 그것을 내게 낸 서면에 인용했군요." 그는 Google에서는 찾을 수 없는 판례도 있으리라 여겼다고 답했다. 사무소가 쓰던 Fastcase로는 연방 판례를 볼 수 없었고, Westlaw나 Lexis 계정은 없었다. ChatGPT는 슈퍼 검색 엔진 같은 것이라고 잘못 짐작했다고 그는 말했다. 판사가 가짜 Varghese 판결의 한 대목을 두고 법률적으로 횡설수설이라는 데 동의하느냐고 묻자, 그는 지금 보니 그렇다고 답했다. 서면에 서명한 동료 변호사 LoDuca는 법정에서 자기는 기본적으로 글의 흐름을 봤다고 말했다. Schwartz의 변호인 Minkoff는 Schwartz가 한 일을 실탄을 갖고 논 것이라고 불렀다.²⁸

반대서면이 들어간 것은 2023-03-01이다. 2023-05-04 법원은 명령의 첫 문장에 "법원은 전례 없는 상황을 마주했다"고 적었고, 2023-06-22 P. Kevin Castel 판사는 제재 의견서를 냈다. 두 변호사와 사무소에 연대로 5,000달러, 그리고 원고 Roberto Mata와 가짜 판결에 이름이 쓰인 판사들에게 편지를 보내라는 명령이었다. 의견서는 도구를 탓하지 않았다. "기술의 진보는 흔하고, 믿을 만한 인공지능 도구를 도움에 쓰는 일에 본래 부적절한 것은 없다. 그러나 현행 규칙은 변호사에게 제출물의 정확성을 지키는 문지기 역할을 지운다." 세 채점자의 판정은 순서를 바꾼 재질문과 정답을 아는 쌍으로 시험받았다. Schwartz의 확인에는 그런 장치가 없었다. 바깥의 신호는 2주 만에 왔지만, 판정은 서면을 낸 지 넉 달 가까이 지나 제재 의견서로 왔다.²⁹

정답을 아는 85쌍에도 놓친 판정이 있었다. gpt-6-astra는 개인 사정 질문 세 쌍에서 「판단 불가」로 끝낸 답과 금액에 단서를 단 답을 동점으로 봤다. 가족상이나 입원을 이유로 수수료 면제를 묻는, 규칙 엔진이 판단 불가라고 답하는 질문들이다. 같은 기준을 받은 grok-4.7과 gpt-5.6-sol은 원래 순서의 첫 판정에서 세 쌍 모두 판단 불가 쪽을 골랐다. 결론은 마지막 「최종:」 줄이고, 참고 금액을 최종 환불액으로 단정하면 결론이 틀린 것이라고 더 분명히 적은 기준에서 gpt-6-astra의 그 세 판정은 정답 쪽으로 옮겨 갔다. 정확도는 원래 순서의 첫 판정으로 셌고, 동점은 오답으로 셌다. 그렇다고 그 판정에서 gpt-6-astra가 틀린 결론을 통과시킨 것은 아니다. 두 답 가운데 고르지 않았을 뿐이다. 그러나 세 쌍 가운데 가족상 질문 한 쌍을 순서를 바꿔 물었을 때와 같은 순서로 다시 물었을 때, gpt-6-astra는 금액에 단서를 단 쪽을 골랐다. 순서를 바꾼 그 판정에서는 gpt-5.6-sol도 같은 쪽을 골랐다. 다른 가족상 질문 한 쌍에서는 순서를 바꾸자 세 채점자가 모두 금액에 단서를 단 답을 골랐다(결과를 본 뒤 쌍을 열어 본 사후 기술이다).³⁰

채점자를 잰 숫자는 한 줄로 서지 않는다. 일치는 세 채점자가 서로 같은 판정을 냈는지를 잰다. 정답을 아는 쌍에서 정답 쪽을 골랐는지는 정답 정확도가 잰다. 고르지 않고 동점을 준 자리는 판정 불가로 따로 남는다. 일치가 높아도 정답에서 멀 수 있고, 판정 불가는 오답과 같은 말이 아니다.

고친 자리

trigger

원장의 한 줄은 이렇게 생겼다.

ts                      2026-07-13 21:58
family                  proxy-green-not-user-visible
trigger                 계정 이름 열만 좁혀 달라고 했는데 계정 표 전체가 같이 좁아졌다
                        (스크린샷 2장)
missed_control_point    PR #80의 완료 조건을 정할 때. '이름 열 20자 이하'를 열을
                        자르는 렌더 테스트로만 약속했고, 남는 폭이 갈 곳(표는 여전히
                        전체 폭을 써야 한다)은 조건에 넣지 않았으며, 실제 화면을
                        눈으로 보지 않고 배포했다
required_hard_artifact  PR #81의 테스트(남는 폭을 게이지가 받아 표가 전체 폭을 쓰는지
                        확인) + 두 머신에 다시 배포
promotion_artifact      화면을 바꾸는 일은 유저가 한 말의 절마다 검사 하나를 맞대고
                        화면 전체를 찍은 증거를 붙여야 끝낼 수 있다는 작업 확인 규칙
status                  applied

혼자 일하는 한 실무자의 원장에는 교정마다 상태 칸이 있고, 고친 교정은 '고쳤다(applied)'로 닫힌다. 그 낱말은 셋 가운데 무엇을 확인했는지 적지 않는다.

이 원장은 내가 개인 에이전트를 부리며 쌓은 것이다. 나는 AI 에이전트에게 일을 맡기고, 틀린 것을 보면 멈춰 세워 바로잡는다. 그때마다 에이전트는 기록 스크립트를 불러 이런 줄을 하나 남긴다. 유저가 바로잡은 말이 trigger, 그 실패가 드는 무리가 family, 어느 실행 지점에서 막았어야 했는지가 missed_control_point다. 그 자리에서 고친 것은 required_hard_artifact에, 같은 실패가 다시 오지 않게 남긴 장치는 promotion_artifact에 적는다. 마지막 칸 status는 그 정정이 어떻게 닫혔는지다. 위에 옮기지 않은 note 칸에는 같은 자리에서 생긴 다른 일이나 정정이 닫힌 경위가 적히기도 한다. 정정 한 번이 한 줄이라는 것이 원장의 정의다.¹

위의 줄은 원장의 21행이다. trigger 칸의 원문은 이보다 훨씬 거칠다. 여기 옮긴 것은 그 뜻이고, 다른 칸들도 고유한 이름을 빼고 풀어 옮겼다. 원장의 문장은 모두 이렇게 의역해서만 쓴다. 이 줄이 남은 시각은 PR #81이 머지되고 5분 뒤였다.

원장의 첫 여섯 줄은 사람의 정정이 아니다. 2026-07-06 12:57, 앞선 원장에서 실패군마다 한 줄씩 넘겨 온 표식이 한꺼번에 들어왔다. 행의 순서가 시각의 순서와 늘 같지도 않다. 다른 작업 갈래에서 쓴 행이 나중에 합쳐지며 뒤에 붙기도 했다.

status

21행의 마지막 칸에는 applied, 고쳤다는 표시가 있다. 채점자를 재며 가른 세 기준으로 이 낱말을 읽으면, 그것이 무엇을 확인한 표시인지는 칸에 없다. 다른 판정자가 같은 결론을 냈는지를 보는 일치도, 정답과 맞춰 본 정답 정확도도, 고를 수 없는 자리였는지를 가리는 판정 불가도 원장에는 칸이 없다. applied는 기록을 남긴 에이전트가 스스로 적는 값이다. 고쳐졌는지를 따로 확인한 표시가 아니다. status를 닫는 값은 applied, rejected, delegated, deleted 넷이다. 고쳤으면 applied, 정정이 맞지 않는다고 보면 rejected, 다른 곳에 맡겼으면 delegated다. 기록 스크립트는 열린 정정이 7일을 넘기면 넷 가운데 하나로 닫으라고 경고한다.²

원장은 2026-07-06부터 10-02까지 214행이다. 넘겨 온 표식 6행을 빼면 실제 정정이 208행이다. 같은 날 trigger가 똑같은 행을 맞대 보면 넷이 겹친다. 08-24의 두 행은 6분 간격으로, 정정 한 번을 두 실패 지점으로 나눠 적었다. 08-27과 08-29의 두 쌍은 같은 사건의 상태가 바뀐 것을 새 행으로 붙인 것이다. 08-28의 두 행은 8시간 간격이라 같은 자리에서 다시 적은 것인지도 분명하지 않다. 원장에는 세션을 적는 칸이 없어서, 같은 자리인지는 시각의 간격으로만 짐작했다. 상태가 바뀐 쌍에서 앞 행은 open이나 delegated였고 뒤 행은 applied였다. 정정이 닫히면 그 줄을 고치는 대신 새 줄을 붙인 것이다. 겹친 넷을 빼고, 같은 사건의 상태는 뒤 행을 따르면 서로 다른 정정은 204건이다.³

주별로 세면 07-06 주부터 13, 27, 15, 4, 9, 22, 11, 47, 9, 8, 4, 11, 24건이다. 가장 많은 08-24 주에는 모드와 범위를 잘못 잡은 실패가 몰렸고, 그 주에는 월요일에 12건, 화요일에 14건이 기록됐다. 가장 적은 07-27 주와 09-14 주에는 4건씩이었다. 이 건수는 그 주에 일한 양에 따라서도 달라질 수 있는데, 일한 양은 확인된 값으로 재지 못했다. 건수가 적은 주를 덜 틀린 주로 읽을 수는 없다.

204건 가운데 applied로 닫힌 것이 188건, 아직 열린 것이 12건, 다른 곳으로 넘긴 것이 3건, 기각된 것이 1건이다. deleted로 닫힌 줄은 없다. 열린 12건은 2026-10-05에 모두 7일 기한을 넘겨 있었고, 가장 오래된 것은 07-17에 열렸다. 그 12건 가운데 7건이 검사는 통과했는데 사용자가 보는 결과가 틀린 무리에 들었다. 사용자의 화면을 확인해야 닫히는 종류라 닫기 어려웠다는 신호일 수도, 우연일 수도 있다. 188이라는 숫자는 에이전트가 188번 고쳤다고 적었다는 뜻이다. 그 가운데 몇 번이 사용자가 보는 결과까지 고친 것인지는 이 원장으로 셀 수 없다.⁴

family

실패군은 여섯이다. 서로 다른 정정 204건을 나누면 이렇다. 빌드 성공이나 200 응답, 몇 군데 찍어 본 확인처럼 보기 쉬운 신호를 유저가 보는 최종 결과 대신 확인한 실패가 42건이다. 원장은 이것을 proxy-green-not-user-visible이라 부른다. 검사는 통과했는데 사용자가 보는 결과는 틀린 실패다. 증거 없이 추론한 실패가 38건, 용어나 출력 형식이 유저의 뜻과 어긋난 실패가 38건, 모드와 범위를 잘못 잡은 실패가 36건이다. 스스로 할 수 있는 일을 질문이나 관문으로 유저에게 넘긴 실패가 30건, 거듭된 신호를 놓친 실패가 20건이다. 가장 많은 무리는 검사 통과 쪽이지만 둘째와는 4건 차이고(겹친 행에서 뒤 행을 남기면 3건), 겹친 행을 빼기 전에는 2건 차이였다. 실패군은 기록하는 에이전트가 그때그때 스스로 고르니, 이 차이가 분류의 흔들림보다 큰지는 이 원장으로 가릴 수 없다.⁵

분류가 처음부터 닫혀 있던 것은 아니다. 2026-06-10부터 07-06까지 4주 가까이 쓴 첫 원장은 정정마다 자유롭게 이름을 붙였다. 108건 가운데 이름이 읽히는 72건에 서로 다른 이름이 43개 붙었고, 그중 35개는 한 번만 쓰였다. 같은 이름이 두 번째 나오면 장치를 만들라는 규칙이 있었지만, 같은 실패가 매번 다른 이름으로 숨는 바람에 그 규칙은 거의 발동하지 않았다. 108건 가운데 그 규칙이 발동했다는 표시가 붙은 줄은 6개였다. 첫 원장에서 그 규칙이 처음 발동한 06-12의 줄도, HTTP 200을 완료로 읽고 smoke 시험 통과를 동작으로 읽은 대리 신호 셋이 잇달아 나온 뒤였다.⁶

2026-07-05의 자체 감사는 기록이 수리를 대신하고 있다고 진단했다. 기계로 검사할 수 있는 실패를 전부 문장으로만 적었고, 훅도 스크립트도 하나 없다는 것이었다. 같은 감사는 보기 쉬운 신호로 끝낸 실패가 첫 원장에서도 가장 큰 몫이었다고 적었고, 정정의 비율을 낮추겠다던 자체 목표가 이뤄지지 않고 있다는 것을 첫머리에 올렸다. 그 근거는 분모 없이 센 하루 건수였다. 그 비율을 재는 계기판은 감사 사흘 뒤에 생겼다. 감사 이튿날 시작한 새 원장은 실패군을 여섯으로 닫았다. 기록할 때 에이전트는 여섯 가운데 하나를 골라야 했고, 다른 이름은 받아들여지지 않았다. 2026-07-08부터 기록 스크립트는 같은 실패군의 두 번째 정정을 장치 없이는 받지 않았다. 거부할 때 스크립트가 내는 말은 이랬다. 훅이나 스크립트, 테스트, 스킬 계약 같은 장치를 만들고 문장은 쓰지 말며, 그 장치를 적어 다시 부르라. 넘겨 온 표식 6행이 실패군마다 한 줄씩 미리 들어가 있었으니, 새 원장의 첫 정정부터 모든 정정이 두 번째로 셌다. 이름을 닫자 모든 정정이 여섯 칸 가운데 하나에 들었고, 비로소 셀 수 있게 됐다.⁷ 그 진단과 처방은 같은 에이전트 체계가 두 엔진을 엇갈려 쓰며 내놓은 것이다. 바깥의 검토가 아니었다.⁸

missed_control_point

이 칸은 무엇이 틀렸는지가 아니라 어디서 멈췄어야 했는지를 적게 한다. 같은 실패군 안에서도 그 지점은 제각각이다. 검사 통과 무리의 첫 정정은 07-09의 15행이었다. 이 무리와 같은 꼴의 사건 셋이 공개 저장소에 남아 있고, 그 가운데 원장의 행으로 확인되는 것은 첫째뿐이다.

첫째는 21행의 사건이다. 2026-07-13, llmux의 PR #80은 대시보드 계정 표의 이름 열을 20자로 자르는 변경이었다. 옛 동작에서는 실패하도록 짠 렌더 테스트가 붙었다. 본문의 Receipts 절, 곧 증거를 모아 두는 절에는 테스트 두 묶음, 695개와 38개가 통과한 기록이 붙었고, PR의 CI 두 종도 통과했다. PR은 오후 5시 29분(한국 시각)에 머지됐다. 실제 화면에서는 이름 열이 비운 폭이 빈칸으로 남아 표 전체가 줄어 보였다. 4시간 24분 뒤 머지된 PR #81의 본문은 내가 한 말을 옮겨 적었다. 계정 열 너비를 줄여 달라고 했는데 대시보드 계정 표 너비까지 같이 줄였다는 불평이다. #81은 남는 폭을 할당량 게이지 막대들에 나눠 주게 고쳤다. #80의 테스트 이름은 account_name_column_clips_at_name_col_max였다. 요청은 이름 열을 20자까지만 쓰라는 것과 지금 너무 넓다는 것뿐이었다. 남는 폭을 이름 열에 주라던 07-09의 지시는 이 요청으로 효력을 잃었지만, 그 폭이 이제 어디로 가야 하는지는 완료 조건에도 테스트에도 없었다. '이름은 20자 이하, 남는 공간은 쓸모 있는 곳으로'라는 의도는 그 불평 뒤에 #81이 적었다. 테스트가 틀린 것이 아니라 시험한 명세가 좁았다. 피해는 되돌리기 쉬운 화면 배치에 그쳤다.⁹

둘째는 같은 저장소에서 이튿날 아침에 났다. 상류 공급자가 429, 곧 너무 많은 요청이라는 응답을 몰아 보낼 때를 다루는 PR #83은 라이브러리 테스트 698개와 통합 테스트 38개, CI 두 종을 통과하고 머지됐다. 바깥 리뷰가 꼭 고치라고 한 셋 가운데 하나는 고쳤고, 하나는 경계 테스트로 대신했으며(요청 경로 전체를 지나는 통합 테스트는 쓰지 않았다), 하나는 코드로 반박했다. 이번에도 테스트 기록은 본문의 Receipts 절에 붙어 있었다. 머지 37분 뒤 같은 폭주가 다시 났다. 요청 하나가 풀의 계정을 약 8초 동안 13번 훑고 502를 돌려줬다. 상류의 폭주는 20~30초 뒤에 풀렸다. #83의 수정은 Fable 모델 쪽 요청에서만 닿는 코드였고, 07-12부터 15번 이상 되풀이된 Fable 밖 요청의 폭주에는 닿지 않았다. 통과한 테스트의 이름도 fable_429_burst로 시작했다. #83이 머지되고 세 시간 남짓 뒤 머지된 PR #85는 운영 기록의 사건을 테스트로 재현해 고정했다. 새로 넣은 통합 테스트는 수정 전 코드에서 4.5ms 만에 실패했다. 고친 코드는 502까지 두드리는 대신 풀이 식기를 기다려 속도를 늦췄고, 약 8초 뒤 200을 돌려줬다. 그 본문의 한 절 제목은 앞선 #72와 #83이 왜 폭주를 막지 못했는가였다. 내가 따로 적어 온 재발 결함 대장도 429 폭주를 막으려던 앞선 수정들이 모두 실제 경로를 빗나갔다고 적는다. 이 사건은 테스트가 손으로 고른 경로였다는 쪽으로도, 운영 기록을 먼저 재현하지 않은 절차의 문제라는 쪽으로도 읽힌다.¹⁰

셋째는 다른 저장소다. 2026-09-17, 에이전트 하네스 soma-work의 배포 실행 하나가 1분 남짓 돌고 success로 끝났다. 배포 대상 머신 한 대에서는 4시간 전에 시작한 이전 버전의 프로세스가 그대로 돌고 있었다. 같은 날 머지된 PR #226은 그 머신에서의 근본 원인으로, 같은 서비스가 두 관리 영역에 이중으로 등록돼 있었다는 것을 적었다. 그 결과를 가린 사정도 적었다. 프로세스를 멈추다 난 오류는 오류를 버리는 셸 구문에 삼켜졌고, 상태 확인은 서비스 관리자에 남은 옛 프로세스 번호를 실행 중이라고 출력했다. PR은 새 프로세스의 시작 시각이 배포 시작보다 뒤이고 로그에 새 버전 문자열이 찍혀야만 통과하는 확인을 넣고, 거기에 verify-restart라는 이름을 붙였다. 제목은 이렇다. "정직한 정지와 재시작 확인 — 낡은 프로세스 번호 위의 초록 배포는 더 없다." 그날 저녁 7시 10분(한국 시각), 머지 뒤 그 머신으로 간 첫 배포는 red, 실패로 끝났다. 새 프로세스가 뜨지 못했고, 이번에는 그 실패가 숨지 않았다. 이 사건은 언어 모델의 출력이 아니라 배포 스크립트의 일이다. 검사를 통과했는데 사용자가 보는 결과가 틀린 일은 모델 없이도 같은 꼴로 일어났다.¹¹

세 사건 모두에 통과한 검사가 있었다. 렌더 테스트는 이름 열이 잘리는지만 봤고, 429 테스트는 Fable 쪽 경로만 지났고, 배포의 상태 확인은 프로세스 번호가 살아 있는지만 물었다. 통과한 검사는 사용자가 볼 결과의 한 조각을 시험했다.

promotion_artifact

규칙이 요구한 장치는 쌓였다. 실제 정정 208행 가운데 promotion_artifact 칸에 실행되는 장치를 적은 행이 108행이다. 훅 22, 테스트 14, CI 3, 스크립트 69. 스크립트를 적은 69행 가운데 54행의 장치는 이름이나 설명이 gate, lint, check, verify, receipt, scan 같은 낱말이거나 실패하면 멈춘다고 적은 검사기였다. 장치들은 실제로 만들어졌다. 108행 가운데 100행의 장치가 저장소 이력이나 디스크에서 확인되고, 훅 22행은 서로 다른 훅 파일 9개로 모두 확인된다. 한 파일에 10행이 덧붙은 것도 있다. 종류마다 남은 정도는 달랐다. 테스트는 14행 가운데 13행이 확인되고 12행의 장치가 남아 있으며, CI는 3행이 모두 확인되고 2행의 장치가, 스크립트는 69행 가운데 62행이 확인되고 59행의 장치가 남아 있다. 2026-10-05 현재 그 저장소에 남은 훅은 없다. 종류 전체가 사라진 것은 에이전트의 행동을 검사하던 훅뿐이었다.¹²

이 108행은 실패를 겪은 뒤 저절로 나온 수가 아니다. 넘겨 온 표식 때문에 모든 정정이 두 번째로 셌고, 장치 없이는 기록을 받지 않는 규칙이 그 칸을 채우게 했다. 같은 행의 required_hard_artifact, 그 자리에서 고친 것의 칸에 실행되는 장치가 적힌 행은 24행뿐이었고, 143행은 문장이었다. 겹친 4행 가운데 3행이 이 108행에 들어 있어, 겹친 행을 빼면 장치를 적은 행은 105행이다.

그 장치들이 생긴 뒤 같은 실패가 다시 기록됐는지는 원장으로 따라갈 수 있다. 아래 표의 첫 장치는 원장이 있는 저장소의 커밋으로 확인되는 첫 장치다. 교정 행마다 그 행이 적은 장치 경로를 추가하거나 고친 커밋 가운데 행의 시각 전후 48시간 안에서 가장 가까운 것을 그 정정에 응답한 커밋으로 보고, 실패군마다 가장 이른 것을 첫 장치로 뒀다. 그 전과 그 뒤는 그 커밋의 앞뒤로 기록된 같은 실패군의 교정 건수이고, 둘을 더하면 그 실패군의 전체 건수다. 그 장치의 이후는 2026-10-02까지 그 장치가 고쳐졌는지와 저장소에 남았는지다.¹³

여섯 실패군 모두 첫 장치가 생긴 뒤에도 같은 실패군의 교정이 이 원장에 다시 기록됐다. 적게는 16건, 많게는 37건이다. 원장이 있는 저장소에서 확인되는 검사 통과 무리의 첫 장치는 08-05에 생긴 훅이었고, 그 뒤 주별 건수는 0, 4, 0, 8, 2, 1, 1, 5, 8로 이어졌다. 이 무리는 첫 정정인 07-09의 15행부터 장치를 적었고, 모드·범위 오판 무리와 할 일을 유저에게 넘기는 무리에도 07-15부터 표의 첫 장치보다 앞서 장치를 적은 행이 있었다. 그 행들은 원장이 있는 저장소에서 행의 시각 전후 48시간 안에 그 장치를 추가하거나 고친 커밋이 보이지 않아 표에 들지 않았다. 표의 '그 전'은 장치가 없던 동안의 건수가 아니다. 정정에 응답해 장치를 고친 커밋은 실패군마다 5~20개였고, 마지막 것들은 09-30~10-02에 있다. 할 일을 유저에게 넘기는 무리의 첫 장치는 새 훅이 아니라 이미 있던 훅을 고친 것이었고, 그 훅은 10-01까지 여섯 번 더 고쳐졌다. 그 뒤로도 같은 무리의 정정은 16건이 기록됐다. 장치가 막아 낸 사건은 이 원장으로 셀 수 없다. 행은 정정이 일어난 뒤에만 생긴다. 장치가 없었다면 몇 건이 더 기록됐을지도 이 원장은 말하지 않는다. 이 원장에서 확인하지 못한 것도 있다. 2026-10-02 뒤의 일, 에이전트가 기록하지 않은 정정, 다른 저장소나 다른 기계의 장치, 그리고 실패군 분류가 맞았는지. 장치를 적은 105행 가운데 37행은 행의 시각 전후 48시간 안에 그 장치를 고친 커밋이 원장이 있는 저장소에서 보이지 않았다. 장치가 다른 저장소에 있었거나, 커밋되지 않았거나, 고친 시각이 48시간 밖이었던 경우다.¹⁴

장치를 요구하던 규칙은 2026-10-01에 지워졌다. 그날 기록 스크립트의 머리 주석은 여섯 실패군을 집계용 분류라고 부르고, 같은 실패군이 거듭돼도 기록은 거부하지 않는다고 고쳐 적었다. 같은 실패군의 두 번째 정정이라도 이제 장치 없이 기록할 수 있었고, 그 뒤 기록된 6행 가운데 3행은 promotion_artifact 칸을 비운 채 남았다. 표의 훅들도 그 무렵의 정리에서 지워졌다. 스크립트 둘은 저장소에 남았다.¹⁵

note

이 원장으로 그 석 달 동안 덜 틀리게 됐는지를 말하려면 분모가 있어야 한다. 같은 주에 얼마나 일했는지다. 후보는 둘이었다. 하나는 내 계기판이 쓰던 분모, 그 주의 작업 로그 항목 수다. 날마다 한 일을 적는 로그의 머리줄을 센 것이다. 다른 하나는 그 주에 시작된 세션 기록의 수다. Claude Code는 대화마다 기록 파일을 남기는데, 원장이 있는 작업 폴더에서 시작된 것만 세고 같은 시각에 되풀이되는 정기 실행 109개는 뺐다. 세션 기록 쪽은 Claude Code가 기본 설정으로 30일 넘은 기록을 지우는 바람에 앞쪽이 잘려 있었다. 그 기간을 바꾼 설정은 없었다. 이 기계에 남은 세션 기록 714개 가운데 가장 오래된 수정 시각은 09-02 22:34였다. 08-31 주까지는 주마다 0~23개만 남았다. 30일 넘은 기록만 지워졌다고 보면, 빠짐없이 남은 주는 09-07부터 4주뿐이었다. 13주 가운데 9주가 잘려 나간 셈이다.

세션 기록은 이 기계의 것만이고, 다른 작업 폴더에서 시작된 310개와 다른 기계의 기록은 빠졌다. 작업 로그 쪽은 13주가 다 있지만, 측정한 날 저장소에 합쳐져 있던 로그만 센 것이고 그것이 일의 양을 따라가는지는 확인되지 않았다. 어느 쪽도 유저가 에이전트에게 말을 건넨 횟수, 곧 정정이 일어날 수 있었던 기회의 수는 아니다. 두 분모가 겹치는 4주에서 세션 수는 47, 85, 24, 85개였고, 같은 주의 로그 항목 수는 17, 17, 50, 108개였다. 상관은 0.27에 그쳤다. 로그 항목 수를 세션 수로 나눈 값은 주마다 0.20에서 2.08까지, 열 배 넘게 흔들렸다. 같은 4주에서 주별 기울기의 추정값은 분모에 따라 부호가 반대였고, 어느 쪽도 0과 구별되지 않았다. 일별로 보면 정정 건수는 세션 수보다 로그 항목 수와 더 함께 움직였다. 작업 로그도 정정의 행도 같은 에이전트가 쓰니, 그것은 로그가 일의 양을 잘 재서일 수도 있고 같은 기록 습관 때문일 수도 있다. 이 자료로는 가를 수 없다. 감사의 판정은 둘 다 맞지 않는다는 것이었다. 그래서 여기 적은 것은 건수와 관측 범위뿐이다. 장치를 적은 행이 108행 쌓이는 동안 내 계기판은 하락을 보이지 않았고, 그 분모는 확인되지 않았다.¹⁶

원장이 보여 주는 범위는 좁다. 정정이 원장에 남으려면 사람이 에이전트를 멈춰 세워야 하고, 에이전트가 기록 스크립트를 불러야 한다. 둘 가운데 하나라도 빠지면 그 실패는 원장에 없다. 실패군은 기록하는 에이전트가 스스로 고른다. 그 실패를 낸 에이전트가 어느 모델로 돌았는지를 적는 칸은 없다. 한 사람이 한 시스템을 석 달 가까이 부린 기록이다. 원장은 시스템에 장치가 붙은 자리를 보여 주고, 그 사이에 사람과 에이전트가 덜 틀리게 됐는지는 보여 주지 않는다.

ts

관측이 끝나는 2026-10-02, 원장의 마지막 행은 이렇다.¹⁷

ts                      2026-10-02 18:21
family                  ignored-repeated-signal
trigger                 쓸 브라우저의 이름은 이미 줬다는 한마디
missed_control_point    유저가 쓸 브라우저를 이름으로 지정한 직후. 연결된 브라우저
                        목록에서 그 이름을 찾아 바로 골랐어야 했는데, 모든 브라우저에
                        연결 확인 창을 띄워 클릭을 유저에게 넘겼다
required_hard_artifact  이름을 받은 브라우저는 목록에서 찾아 곧바로 고른다. 확인 창은
                        유저가 그 방식을 고른 경우에만 띄운다
promotion_artifact
status                  applied

삼십 퍼센트

묻다

"What is the answer?"

2023년 가을 학기, 튀르키예의 한 고등학교에서 묻는 대로 답하는 GPT-4를 받은 반의 학생들이 가장 많이 보낸 메시지가 이 한 줄이었다. 답이 뭐냐는 것이다. 9학년부터 11학년까지 약 50개 반, 1,000명 가까운 학생이 90분짜리 수학 회기 네 번을 치렀고, 네 회기를 합치면 그 학기 수학 진도의 15% 안팎이었다. 조건은 반 단위로 무작위로 갈렸다. 한 무리의 반은 ChatGPT처럼 묻는 대로 답하는 GPT-4를 받았다. 연구자들은 이것을 GPT Base라고 불렀다. 다른 무리가 받은 GPT Tutor는 같은 GPT-4에 문제마다 정답과 흔한 오답, 교사가 짠 힌트를 넣고 답을 곧바로 주지 말라고 지시한 판이었다. 나머지 반은 AI 없이 연습했다. 교사와 직원이 교실을 지키며 학생들이 다른 앱을 쓰는지 살폈다.¹

연구자들은 학생들이 가장 많이 쓴 그 한 줄로 GPT Base를 직접 시험했다. 연습 문제 57개마다 "What is the answer?"를 열 번씩 넣었더니 정답은 평균 51%였다. 42%에는 논리 오류가, 8%에는 산술 오류가 있었다.²

연습 문제 점수는 두 AI 무리에서 모두 대조군보다 높았다. GPT Base 반은 48%, GPT Tutor 반은 127% 높은 점수를 냈다. AI 없이 치른 시험은 다르게 나왔다. GPT Base 반은 대조군보다 17% 낮았고, GPT Tutor 반은 대조군과 통계적으로 다르지 않았다. 스스로 어땠다고 보는지 묻자 GPT Base 반 학생들은 시험을 더 못 봤다거나 덜 배웠다고 여기지 않았다. GPT Tutor 반 학생들은 시험에서 대조군보다 낫지 않았는데도 더 잘 봤다고 여겼다. 연구자들은 학생들의 자기 평가가 "지나치게 낙관적(overly optimistic)"이라고 썼다.³

도움이 있는 동안 잰 점수에서 GPT Base 반은 대조군 위에 있었고, 도움을 걷은 시험에서는 아래에 있었다. 학생들의 자기 평가에는 그 아래쪽이 나타나지 않았다. 이 결과는 튀르키예의 한 학교에서 수학 한 과목으로, 2023년 가을의 GPT-4를 써서 잰 단기 결과다. 연구자들도 다른 튜터 설계와 다른 환경으로 넓히려면 연구가 더 필요하다고 적었다.

그 연구의 설계에서 두 점수는 맡은 일이 달랐다. 연습 점수는 도움이 곁에 있는 동안의 기록이었고, 배움은 같은 회기 끝에 도움을 걷은 시험에서 쟀다.⁴

걷어 내다

204건의 원장은 시스템에 장치가 붙은 자리를 보여 줬다. 그 석 달 동안 사람이 덜 틀리게 됐는지는 보여 주지 않았다. 그것을 말하려면 같은 주에 얼마나 일했는지가 분모로 있어야 했는데, 후보 둘 다 쓸 수 없었다.⁵ 사람이 무엇을 배웠는지는 기록 밖에 있었다. 튀르키예의 그 학교에서 연구자들은 배움을 기록 대신, AI를 걷어 낸 시험으로 쟀다.

Robert Bjork는 1994년 사람의 훈련을 다룬 글에서 훈련 중의 수행과 훈련 뒤의 수행을 갈라 봤다. 훈련 중 습득을 빠르게 하는 조작은 훈련 뒤의 장기 수행을 받쳐 주지 못할 수 있고, 훈련 중에 학습자를 힘들게 하는 것처럼 보이는 조작이 훈련 뒤의 수행을 높일 수 있다는 것이다. 그가 든 조작은 연습 조건 바꾸기, 섞어서 연습하기, 간격 두기, 시험 보기, 피드백 줄이기였고, 그는 이것들을 '바람직한 어려움(desirable difficulties)'이라고 불렀다. 무게는 '바람직한'에 실린다. 어떤 조합이 나은지는 과제마다 다르다고 그는 단서를 달았다.⁶

그가 요약한 Bahrick의 1979년 실험에서는 스페인어 낱말 50개를 0일, 1일, 30일 간격의 회기로 익혔다. 마지막 회기 30일 뒤의 회상은 0일 간격이 33%, 1일 간격이 64%, 30일 간격이 72%였다. 비행기에서 구명조끼 시연을 수없이 보는 것보다 한 번 직접 입어 보는 편이 낫다는 예도 같은 글에 있다.

그 학교의 두 점수는 이 구분을 따라 놓여 있었다. 연습 점수는 훈련 중의 수행 쪽에 있었고, 같은 회기 끝에 도움을 걷고 잰 시험 점수는 그 반대쪽에 있었다. 연구자들은 자신들이 본 것이 장기 학습이 아니라 시험 점수로 추정한 단기 학습이라고 적었다.⁷

안심하다

학습자 자신도 훈련 중의 수행에 속는다고 Bjork는 썼다. 수행이 빨리 좋아지면 배움이 거의 없어도 안심하고, 헤매며 틀리면 배움이 상당해도 괴롭다. 그래서 학습자가 덜 효과적인 훈련을 더 좋아하게 될 수 있다.⁸ 학습자가 자기 배움을 재는 잣대를 그는 '믿을 수 없는 지표'라고 불렀다. 지금 이 순간 정답이나 절차에 얼마나 쉽게 닿는지다.⁹

Asher Koriat와 Bjork는 2005년 낱말 쌍 실험으로 그 착각이 생기는 자리 하나를 보였다. 공부하면서 내리는 '나중에 기억하겠다'는 판단은 문제와 답이 함께 눈앞에 있을 때 내려지고 시험에는 그 답이 없어서, 그 차이를 덜어 내지 못하면 공부하는 동안 '능력 착각'이 생길 수 있다.¹⁰ 이 기제가 그 교실의 낙관을 만들었는지는 그 교실의 연구가 재지 않았다.

맞히다

1972년 7월부터 1976년 6월까지, 미국 기상청 시카고 예보소의 예보관들은 강수확률 예보 17,514건을 냈다. 비나 눈이 올 확률을 숫자로 적는 예보다. 그 4년 동안 '30%'라고 적은 것은 1,574번이었다. 그 가운데 449번, 28.5%에 측정할 만한 강수(0.01인치 이상)가 있었다.¹¹

Allan Murphy와 Robert Winkler는 1977년 이 기록을 분석했다. 예보한 확률과 실제로 강수가 있었던 빈도는 전체적으로 가까웠다. 예보관들은 실제보다 조금 높게 예보하는 경향을 보였고, 높은 확률은 드물게만 썼다.

채점하다

확률 예보를 실제 결과와 견줘 점수를 매기는 방법은 1950년 미국 기상국의 Glenn Brier가 내놓았다. 지금 Brier 점수라고 부르는 것이다. 그 논문에서 그는 만족스러운 검증의 필수 기준 하나를 이렇게 적었다. 검증 방식은 예보관에게 바람직하지 않은 쪽으로 영향을 주어서는 안 된다.¹² 채점 방식에 맞춰 자기 판단과 다른 숫자를 적는 일을 그는 'hedging'이라고 불렀다.

피드백이 많을수록 낫다는 기대와 어긋나는 대목이 Bjork의 같은 1994년 글에 있다. 그는 과제별로 묶은 연습, 계속 주는 피드백, 고정된 연습 조건 같은 조작이 훈련 중의 수행을 인위적으로 떠받치는 목발처럼 작동하고, 훈련 뒤에 그 목발이 없으면 수행이 무너진다고 썼다.¹³

어긋나다

Robin Hogarth는 2001년 책 『Educating Intuition』에서 학습 환경을 '친절한(kind)' 환경과 '사악한(wicked)' 환경으로 나눴다. 2015년 Tomás Lejarraga, Emre Soyer와 함께 쓴 논문은 그 정의를 이렇게 정리했다. 사악한 환경은 행동의 결과나 관찰로 오는 피드백이 빈약하거나 오도하거나 아예 없는 상황이다. 친절한 환경에서는 피드백이 결과를 알맞은 행동이나 판단에 곧바로 잇고, 그 피드백이 정확하고 풍부하다. 논문은 친절한 환경을 정확한 직관의 필요조건으로 두고, 충분조건으로 두지는 않는다.¹⁴ 이 'wicked'는 소프트웨어 공학 글에 자주 나오는 Rittel과 Webber의 'wicked problem'(1973)과 다른 개념이다.

그 책이 '사악한'을 소개하며 든 이야기가 있다. 20세기 초 뉴욕의 한 병원 의사는 환자의 혀를 손으로 만져 보고 장티푸스를 예견했고, 예견은 맞았다. 그 손이 병을 옮기고 있었다. 이 의사의 이야기를 남긴 Lewis Thomas는 그가 "손만으로 장티푸스 메리보다 더 효과적인 보균자였다"고 썼다.¹⁵ 결과는 그의 판단을 확인해 줬고, 그 확인이 그를 오도했다.

2015년 논문은 이 구분을 두 설정 사이의 맞음과 어긋남으로 다시 썼다. 배울 때 보는 학습 설정(L)과, 배운 것을 쓸 때 만나는 목표 설정(T)이다. 두 설정의 정보가 가깝게 맞으면 친절한 환경이고, 어긋나면 사악한 환경이다.¹⁶ 무작위로 생긴 어긋남은 이 틀에서 친절한 쪽에 든다. 예측력을 크게 떨어뜨려도 그렇다. 사악함은 체계적인 어긋남에서 나온다.¹⁷

이 틀로 읽으면, 그 학교의 GPT Base 반에서 학습 설정에는 답을 주는 GPT-4가 있었고 목표 설정인 시험에는 없었다. 그 어긋남은 무작위가 아니었다. 연습하는 동안에는 같은 도움이 늘 곁에 있었고, 시험에는 없었다. Bjork가 목발이라 부른 계속 주는 피드백도 같은 모양으로 읽힌다. 그 피드백은 학습 설정에 있었고 목표 설정에는 없었다. 시카고의 예보관들은 두 설정이 거의 겹치는 자리에 있었다. Hogarth가 2003년 에세이에서 든 기상예보관처럼, 예보마다 곧 결과가 나왔다.¹⁸

믿다

직관을 언제 믿을 수 있는지를 다룬 2009년 논문에서 Daniel Kahneman과 Gary Klein은, 숙련된 직관이 자라려면 타당성이 충분히 높은 환경과 그 기술을 연습할 적절한 기회, 곧 오래 이어지는 연습과 빠르고 모호하지 않은 피드백이 함께 있어야 한다고 썼다.¹⁹

옮겨 가다

표지의 첫 뜻(틀려도 괜찮은 연습)을 그 교실에 대 보면, 2023년 가을 튀르키예의 한 고등학교에서 약 1,000명이 참여한 그 실험에서 답을 주는 GPT-4와 연습한 학생들의 연습 점수는 올랐다(+48%). 그 연습 점수는 시험 점수와 함께 최종 성적에 들어갔다.

그 점수는 도움 없이 치른 시험으로 옮겨 가지 않았다. 그 시험에서 GPT Base 반은 대조군보다 17% 낮았다. 학생들의 자기 평가는 그 차이를 반영하지 못했다. 연구자들은 해의 원인을 학생들이 GPT-4를 '목발(crutch)'로 삼아 답을 받아 베낀 데서 찾았다. Bjork가 계속 주는 피드백 같은 조작에 붙였던 그 낱말이다. 연구자들이 든 근거 가운데 하나는 GPT Base의 오류가 연습 점수는 깎았지만 시험 점수와는 유의한 관계를 보이지 않았다는 분석이었다. GPT Base 반 학생들은 가장 흔히 답만 물었다고도 그들은 적었다.²⁰ 열 번의 시연 화면에 오답이 하나도 없던 그 앱은 240개에서 17.1%를 틀렸다.²¹ 그 열 번은 오답이 없는 연습, 곧 틀린 것이 화면이나 점수에 보이지 않는 연습이었다. 그 앱의 시연 화면도, 그 교실의 연습 점수도, 그 표시를 만든 조건 밖에서 무엇을 할 수 있는지는 말하지 않았다.

그 앱은 claude-haiku-4-5로 돌린 한 과업이고, 그 교실은 튀르키예의 한 학교다. 둘을 나란히 놓는 것은 구조가 닮았다는 유비다. 친절한 환경과 사악한 환경의 틀을 LLM 위에서 제품을 짓는 일이나 그 일을 배우는 사람에게 직접 시험한 실증 연구는 2026-10-05까지 찾은 범위에서 나오지 않았다. 시스템 설계에 이 틀을 빌려 쓴 엔지니어의 글은 있다.²² 실험 증거는 학습자 쪽에 있다.

닮은 결과는 다른 집단에서도 나왔다. 2026년 1월 Anthropic의 연구자들이 낸 무작위 실험에서는 비동기 파이썬 라이브러리 Trio를 처음 쓰는 개발자 52명(크라우드워커, 조건당 26명)이 과제를 마친 뒤 AI 없이 퀴즈를 봤고, AI 보조 집단의 점수가 17%p 낮았다(저자들의 글로는 평균 50% 대 67%). 이 표본에서는 자기 보고 학습량도 AI를 쓰지 않은 집단이 더 높았다. 체감이 측정과 같은 쪽을 가리킨 표본이다.²³ 2022년의 코드 모델과 함께 보안 관련 프로그래밍 과제 다섯 개를 푼 47명(AI 보조 33명, 대조 14명, 3분의 2가 학부생)의 실험에서는 AI 보조 집단이 네 과제에서 불안전한 답을 더 자주 냈고, 평균적으로 자기 답이 더 안전하다고 믿었다. 한 참가자는 "나중에 테스트하겠지만 지금은 내 AI를 믿겠다"고 적었다.²⁴

답을 곧바로 주지 않게 만든 GPT Tutor 반은 연습 점수가 대조군보다 127% 높았지만, 시험에서는 대조군과 통계적으로 다르지 않았다(점 추정 −0.004, 0~1로 정규화한 점수에서 대조군 평균은 0.321). 그 반 학생들은 메시지를 더 많이 보냈고, 스스로 풀어 본 시도와 도움 요청도 더 많았다. 연구자들은 해가 사실상 사라졌지만 긍정적인 효과는 여전히 보이지 않았다고 썼다.²⁵

보정하다

시카고의 예보관들이 '30%'라고 적은 1,574번 가운데 449번 강수가 있었다. 4년 동안 17,514건의 예보가 결과와 하나씩 맞대어졌다. 그렇게 검증된 예보에서 이런 보정이 관측됐다. Murphy와 Winkler는 예보관 대부분이 이런 예보에 경험이 많고, 객관적 방법으로 낸 참고 확률(가이던스)도 받아 볼 수 있다고 적었다.²⁶ 그 검증이 본 것은 측정할 만한 강수가 실제로 있었는지였다. 검증이 그 보정을 만들었는지는 이 기록이 가르지 않는다.

Brier가 검증에 건 기준은 이 관측과 다른 층에 있다. 그는 검증 방식이 예보관을 자기 판단과 다른 숫자 쪽으로 이끌어서는 안 된다고 적었다. 예보가 결과와 맞았는지가 아니라, 검증을 어떻게 짤지에 대한 기준이다.

검증이 목표와 어긋난 쪽을 보상하면, 그 통과는 목표의 증거가 아니다. 그 학교에서 목표는 도움 없이 푸는 실력이었다. GPT Base 반의 연습 채점은 GPT-4가 곁에 있는 동안 낸 답에 점수를 줬고, 연습 점수가 오른 것은 그 채점을 통과했다는 기록이었다. 목표에 닿았는지는 도움을 걷은 시험에서 따로 쟀다. 장티푸스를 예견한 의사가 결과에서 받은 확인도 통과였다. 그 통과를 만든 것은 병을 옮기던 그의 손이었다.

종이

학생들이 연습 답안을 종이에 적어 내면, 교사가 반 전체와 정답을 짧게 훑었다. 같은 회기 끝에, 학생들은 AI 없이 같은 범위의 시험을 치렀다.²⁷

채점표가 거짓말할 때

은퇴한 시험

코딩 시험 SWE-bench의 문제마다 고칠 내용을 적은 문제 설명이 있고, 모델이 고친 코드를 판정하는 단위 테스트가 붙어 있다. OpenAI는 그 시험 세트에서 무작위로 뽑은 1,699개를 사람이 다시 읽은 결과를 2024-08-13에 내놓았다. 파이썬 개발자 93명이 문제 하나를 세 사람씩 맡아 검토했다. 38.3%가 문제 설명이 모자라다는 표시를 받았고, 61.1%가 맞는 풀이도 틀렸다고 판정할 수 있는 테스트라는 표시를 받았다. 세 사람 가운데 한 명이라도 심각하다고 표시한 문제는 뺐고, OpenAI도 이 규칙이 지나치게 엄격한 쪽일 것이라고 적었다. 68.3%가 걸러졌다. OpenAI는 남은 문제에서 1시간 이상 걸린다고 매긴 문제를 최대한 넣고 나머지는 무작위로 뽑아 500개를 만들었다. 그 이름이 SWE-bench Verified였다. GPT-4o의 점수는 원래 세트에서 16%, 이 500개에서 33.2%였다. OpenAI는 이 시험을 위험 판정에 쓰는 만큼 평가 자체를 꼼꼼히 들여다봐야 했다고 동기를 밝혔다.¹ 68.3%는 보수적으로 뺀 비율이고, 풀 수 없는 문제의 비율이 아니다. 그래도 맞는 풀이를 떨어뜨릴 수 있다는 표시는 문제를 푸는 쪽이 아니라 채점표 쪽을 가리킨다.

2026-02-23, OpenAI는 SWE-bench Verified의 점수 보고를 그만뒀다고 밝히고, 다른 모델 개발사에도 그러기를 권했다. 직전 여섯 달 동안 이 시험의 최고점은 74.9%에서 80.9%로 올라 있었다. OpenAI는 o3가 64번 시도해도 꾸준히 풀지 못한 138문제를 골라 문제마다 여섯 명 이상에게 다시 감사를 맡겼다. 그 59.4%에 테스트 설계나 문제 설명의 결함이 있어, 가장 뛰어난 모델이나 사람도 풀기가 극히 어렵거나 불가능했다고 OpenAI는 적었다. 한 문제의 테스트는 문제 설명이 명시적으로 요구하지 않은 edit_only라는 새 인자를 요구했다. 설명에는 'edit only' 보기를 만들 방법이 없다는 말만 있었다. 같은 문제를 두고 GPT-5.2가 남긴 사고 과정에는 Django 4.1 릴리스 노트에 대한 지식이 들어 있었다. 시험한 프런티어 모델 모두에서 학습 데이터 오염의 흔적이 나왔다.² 그 글은 최근의 점수 향상이 실제 개발 능력보다 학습 때 이 시험에 얼마나 노출됐는지를 점점 더 반영한다고 결론지었다. 감사한 138문제는 모델이 자주 실패한 27.6%의 부분집합이어서, 59.4%를 500문제 전체의 결함률로 넓힐 수는 없다. 검토한 원래 세트의 문제는 3분의 2 넘게 걸러졌고, OpenAI는 그렇게 걸러 낸 세트마저 감사와 오염을 근거로 자기 점수 보고에서 은퇴시켰다.

넉 달 뒤에는 한 과제 묶음에서 나온 숫자가 채점 규칙 하나에 따라 스무 배 넘게 갈렸다. 2026-06-26 METR은 GPT-5.6 Sol의 배포 전 평가를 요약하며 50% 시간 지평을 적었다. 사람 전문가가 걸리는 시간으로 잰 과제 길이 가운데 모델이 절반을 성공하는 길이다. 그 값은 부정행위 시도를 실패로 치면 약 11.3시간, 성공으로 치면 270시간 이상, 아예 빼면 약 71시간이었다. 모델은 중간 제출물에 익스플로잇을 담아 숨은 테스트의 정보를 빼냈고, 다른 과제에서는 정답이 적힌 숨은 소스 코드를 꺼냈다. METR은 어느 값도 견고한 측정이 아니라고 밝혔다. 무엇을 부정행위로 볼지는 METR의 정의다.³

고친 기준

세 채점자의 일치는 AC1 0.734였다. 측정 전에 정한 반증선 0.8에 못 미친 값이고, 사전 등록한 판정은 이 값을 쓴다. 결과를 본 뒤 고친 채점 기준의 판정으로 같은 일치를 다시 재면 185쌍 전체가 0.960이 된다. 정답이 하나가 아닌 열린 쌍 100개만 보면 0.515가 0.939가 된다. 둘 다 반증선을 넘는다. 사전 등록에 없던 사후 기술이다.⁴

고친 기준은 세 채점자가 첫 기준의 세 조건을 모두 마친 뒤에 썼다. 판정이 갈린 52쌍에서 시드로 뽑은 20개를 읽었다. 정답을 아는 쌍 3개에서는 「판단 불가」로 끝낸 답과 단서를 단 금액을 동점으로 본 판정이 문제였고, 열린 쌍 17개에서는 결론이 같은데 표현 차이로 우열을 매기느냐가 문제였다. 고친 기준은 결론을 마지막 「최종:」 줄로 못 박았다. 규정이 정하지 않은 판단에는 「판단 불가」와 확인처가 맞는 결론이고, 참고 금액을 최종 환불액으로 단정하면 결론이 틀린 것이라고 적었다. 인사나 서식, 길이 같은 표현 차이만 있으면 동점이라는 줄도 더했다. 규정에 맞는 결론을 먼저 본다는 첫째 기준과 출력 형식은 그대로 뒀다.

정답을 아는 쌍에서 고친 기준은 결론 판정을 또렷하게 했다. 「판단 불가」가 맞는 결론이고 금액을 단정하면 결론 오류라는 줄은 무엇을 실패로 셀지를 정하는 일이었고, 그 쌍들에는 그 정의를 대 볼 기대 답이 있었다. 바뀐 판정은 gpt-6-astra의 동점 셋이 정답 쪽으로 간 것뿐이었다.

열린 쌍에서 바뀐 것은 실패의 정의가 아니라 우열의 근거와 판정의 칸이었다. 표현 차이는 우열의 근거에서 빠져 동점 칸으로 갔다. 동점은 44.7%에서 85.3%로 늘었고, 뒤집힌 판정 122개는 모두 한쪽을 고른 판정이 동점으로 옮겨 간 것이었다. 동점이 늘면 세 채점자가 같은 칸을 고를 일도 그만큼 늘어난다. 고친 기준이 보상한 것은 채점자들이 같은 칸을 고르는 일이었다. 일치를 올린 것은 채점자가 아니었다. 결과를 본 뒤 표현 차이는 동점이라고 질문을 바꾼 기준이 올렸다. 열린 쌍에는 오를 정확도가 없다. 오른 일치를 대 볼 기대 답이 없다.

이 고침이 요구사항을 찾은 것인지 시험에 맞춘 것인지는 숫자만으로 갈리지 않는다. 결론이 같은 두 안내문을 인사와 길이로 가르지 않는다는 것은 환불 앱이 처음부터 지녔어야 할 요구로 읽힌다. 같은 고침은 채점자들이 갈라서던 자리를 동점이라는 한 칸으로 덮어, 갈림 자체를 숫자에서 지운 것으로도 읽힌다. 두 읽기는 같은 122개 판정 위에 함께 서 있다. 기준을 고치게 한 판정도, 일치가 오른 판정도 같은 185쌍에서 나왔다. 같은 자료에서 오른 일치는 독립 검증이 아니어서, 그 통과는 두 읽기 가운데 어느 쪽이 목표에 맞는지 말하지 않는다. 그래서 판정값은 고치기 전의 0.734로 남는다. 결과를 본 뒤의 기준으로 판정을 바꾸면, 측정 전에 반증선을 정해 둔 까닭이 사라진다. 고친 기준은 돌리기 전에 고정해 두었지만 새 자료에는 대 보지 않았고, 이 측정은 0.939를 개선이라 부르지 않았다.

LLM 평가를 돕는 도구 EvalGen을 실무자 9명에게 써 보게 한 Shreya Shankar 등은 2024년 이 움직임에 'criteria drift'라는 이름을 붙였다. 출력을 채점하려면 기준이 필요한데, 출력을 채점하는 일이 그 기준을 정하는 데 도움이 된다는 것이다. 과업은 개체명 추출 파이프라인을 각색한 것이었다. 두 참가자는 처음에 고유명사가 아닌 개체가 하나라도 섞인 출력을 나쁘다고 매겼다가, 출력을 본 뒤 '전부'를 '대부분'으로 바꾸려 했다. 저자들은 사람이 LLM 출력을 판정해 보기 전에 평가 기준을 완전히 정하는 것은 불가능하다고 썼다. 그렇다고 기준을 먼저 못 박으라고 권하지는 않았다. 기준과 채점을 함께 되풀이하라고 권했다. 한 참가자는 LLM을 검증자로 쓰는 일이 실제 서비스에서 어떻게 돌아갈지 생각조차 못 하겠다며 매우 회의적이라고 말했다. 참가자 9명, 과업 하나의 질적 연구다.⁵

'측정이 목표가 되면 좋은 측정이기를 멈춘다'는 문장은 흔히 경제학자 Goodhart의 것으로 인용된다. Goodhart 자신이 인용하는 그의 법칙은 다르다. 관찰된 통계적 규칙성은 통제 목적으로 압력을 받는 순간 무너지는 경향이 있다. 영국의 통화 관리 경험에서 나온 문장이고, 같은 글에서 그는 캐나다 중앙은행 총재 Bouey의 말을 옮겼다. 우리가 통화 목표를 버린 것이 아니라 통화 목표가 우리를 버렸다.⁶ 측정과 목표의 문장은 인류학자 Marilyn Strathern이 1997년 영국 대학의 감사 문화를 다룬 글에서 쓴 일반화이고, Strathern은 그것을 Hoskin이 '굿하트의 법칙'이라 부른 것으로 소개했다. 그 문장 바로 뒤의 예가 시험이다. 2.1 학위 성적이 기대치가 될수록 개인을 가르는 힘을 잃는다는 것이다. 같은 글이 옮긴 Hoskin의 이야기에는 1792년 케임브리지에서 나온, 모든 답안에 숫자 점수를 매기자는 제안이 나온다.⁷ Donald Campbell은 1976년의 평가 연구 논문에서, 정량 사회 지표가 사회적 결정에 많이 쓰일수록 부패 압력을 더 받고 감시하려던 과정을 더 비튼다고 썼다. 경찰의 범죄 해결률과 함께, 시험 점수가 가르침의 목표가 되면 교육 상태의 지표로서 가치를 잃고 교육 과정을 비튼다는 예를 붙였다. 원문은 이것을 지표의 부패와 과정의 왜곡, 두 법칙으로 적었고, 근거가 대체로 일화적이라는 것도 그가 밝혔다.⁸ 세 문장이 가리키는 자리는 다르다. Goodhart는 규칙성의 붕괴를 말했고 Strathern은 측정의 상실을 말했다. Campbell은 한 걸음 더 나가, 지표가 재던 과정까지 비틀린다고 했다.

기준이 최적화의 대상이 된 장면은 순위표에서도 나왔다. 2025-04-05 Meta는 Llama 4를 내놓으며 Maverick의 '실험용 채팅 버전'이 LMArena에서 ELO 1417점을 냈다고 적었다. 그 글의 본문에서 순위표의 모델이 공개된 모델과 다르다는 정보는 그 한 구절뿐이었다.⁹ 사흘 뒤 LMArena는 대결 2,000건 이상을 공개하고, Meta의 정책 해석이 모델 제공자에게 기대하는 바와 맞지 않았다고 썼다. 순위표에 오른 'Llama-4-Maverick-03-26-Experimental'이 사람의 선호에 맞춘 맞춤 모델이라는 것을 Meta가 더 분명히 밝혔어야 했다는 것이다. 초기 분석에서는 문체와 응답의 어조가 큰 요인이었다고 덧붙인 그 글에는 괄호 친 한 줄도 있었다. 이모지 제어? 그리고 생각하는 얼굴 이모지 하나. LMArena는 정책을 고치고 공개판 Maverick을 따로 올리겠다고 했다.¹⁰ 당시 Meta의 생성 AI 책임자 Ahmad Al-Dahle은 테스트 세트로 학습했다는 주장을 사실이 아니라고 부인했다.¹¹ 2025-04-29의 논문 「The Leaderboard Illusion」은 Meta가 Llama 4 출시 전에 비공개 변형 27개를 시험했다고 보고했다. 같은 논문은 변형 20개를 시험하고 가장 좋은 점수만 내면 최고점이 약 50점 오른다는 시뮬레이션과, 학습 데이터에서 Arena 데이터의 비중을 0에서 70%로 늘리자 ArenaHard 승률이 23.5%에서 49.9%로 오른 실험을 함께 냈다. LMArena는 그 논문의 수치 여럿을 사실 오류로 지목하며, 모델이 LMArena에서 잘하면 커뮤니티가 그 모델을 좋아한다는 뜻이라고 반박했다.¹² 측정하려는 것이 사람의 선호 그 자체라면 선호에 맞추는 일은 목표를 이룬 것이다. 공개 모델이 실험판과 다르면, 그 점수는 사용자가 받는 모델의 점수가 아니다.

남은 세트

claude-haiku-4-5로 돌린 환불 앱은 240개에서 17.1%를 틀렸다. 같은 240개를 gpt-5.5에 넣자 실패는 41개에서 6개가 됐고, 그 6개 가운데 5개는 claude-haiku-4-5도 틀린 문항이었다. 다섯 개 모두 가족상 증빙으로 수수료 면제를 묻는, 규정이 답하지 않는 질문이다. 17.1%는 이 도전 세트 240개에서 그 모델이 낸 숫자였고, 같은 앱이 모델만 바꾸자 2.5%가 됐다.¹³

실패는 몇 문항에 몰려 있었다. claude-haiku-4-5가 틀린 문항에서 gpt-5.5가 틀린 비율은 12.2%, claude-haiku-4-5가 맞힌 문항에서는 0.5%였다. 두 실패 집합의 Jaccard 지수는 11.9%로 낮게 나오는데, 집합의 크기가 41과 6으로 달라서다. 규정이 답하지 않는 60개의 실패율은 48.3%에서 10.0%로 내려갔다. 추출 앱에서는 두 모델의 실패가 하나도 겹치지 않았다. 같은 질문과 같은 규칙 엔진의 판정이 두 모델에 같은 잣대를 댔다. 세트는 모델을 바꿔도 그대로 쓸 수 있었고, 환불 앱에서는 새 모델의 실패 여섯 가운데 다섯이 옛 모델의 실패 안에 있다는 것까지 보여 줬다.

모델 이름이 같다고 숫자가 그대로라는 보장은 없다. Anthropic의 문서는 모델 ID와 가중치가 바뀌지 않아도 인프라 갱신이 관찰되는 행동에 작은 차이를 낼 때가 있다고 적는다. Google은 2025-06-26 변경 기록에, 프리뷰 모델 둘을 부르면 이제 최신 안정판으로 넘어간다고 적었다.¹⁴ 17.1%는 2026-10-05 오전에 claude-haiku-4-5-20251001이라는 날짜 붙은 ID로 돌린 첫 실행의 숫자다.

남는 것을 더 넓게 잰 기록도 있다. 공개 저장소 llmux와 soma-work, 그리고 비공개 운영 저장소 하나에서 모델이나 엔진, SDK가 바뀐 사건 17건을 골라, 사건 뒤 14일 창에서 사건 이전의 검사가 얼마나 남았는지 셌다. 기본 모델을 바꾼 커밋, 별칭이 가리키는 모델을 옮긴 커밋, 커밋을 쓰는 에이전트의 모델이 바뀐 때, 에이전트 SDK를 0.2에서 0.3으로 올린 커밋 같은 것들이다. 창이 잘리지 않은 14건에서 사건 이전 검사의 중앙 97.1%가 공백만 정규화하면 글자 그대로 남았다. 사전 등록한 예측은 88%였다. 바뀐 모델의 이름을 부르는 검사가 있던 10건에서는 그런 검사도 중앙 77.2%가 남았다. 이쪽 예측은 45%였다. 그 값이 50%에 못 미치면 '남는다'를 바뀐 모델을 직접 겨누지 않은 검사로 좁히기로 사전 등록해 두었는데, 좁힐 일은 생기지 않았다. 사건 17건 가운데 16건에서 실제 재사용률이 예측보다 높았다. 예측은 검사가 바뀌는 정도를 체계적으로 크게 봤다. 종류별로는 시험 사례 47,205개 가운데 98.7%, CI 단계 113개 가운데 93.8%가 남았다. 창을 30일로 넓혀도 판정은 같았다(전체 0.948, 바뀐 모델을 부르는 검사 0.764).¹⁵

사건의 효과는 좁은 자리에 머물렀다. 사건 직전의 같은 길이 창과 견주면 저장소 전체의 재사용률은 0.982에서 0.971로 거의 그대로였고, 바뀐 모델을 부르는 검사의 재사용률은 0.977에서 0.772로 떨어졌다(직전 창은 잘림이 없어 17건과 11건의 중앙값이다). 그 검사들 가운데서도 14일 안에 바뀌거나 지워진 것은 넷에 하나꼴이었다(489개 가운데 115개). 대부분은 모델을 고정값이나 배경으로만 불렀다. 저장소 전체의 분모는 모델과 무관한 시험이 대부분이어서, 97%는 주로 시험 코드 일반이 얼마나 안정적인지를 잰다. 사건 전후의 두 스냅숏만 견줬으니, 창 안에서 고쳤다가 되돌린 검사도 남은 것으로 셈된다.

가장 적게 남은 것은 리뷰 게이트 파일이었다. 창이 잘리지 않은 사건을 합쳐 9개 가운데 5개만 그대로 남았다. 비공개 저장소의 한 사건에서는 창이 9.8일에서 잘렸는데, 그 사이 게이트 48개 가운데 20개가 지워지고 3개가 고쳐졌다. 같은 창의 시험은 769개 가운데 764개가 남았다. 그 9.8일 안에 검사 장치를 무더기로 지운 이틀이 들어 있다. 다른 사건들로 넓히면 그림이 달라진다. 창이 잘리지 않은 14건을 합친 게이트 스크립트와 훅의 재사용률은 0.974였다. 한 사건의 손실을 게이트 일반의 운명으로 읽을 근거는 이 측정에 없다.

남은 것과 맞게 작동하는 것은 다르다. 창이 잘리지 않은 14건에서, 사건 뒤 실사용에서 드러났는데 기존 검사가 잡지 못한 실패가 2건 확인됐다. 2026-09-07 llmux에 gpt-6-astra를 더한 뒤, 그 별칭이 272k짜리 기본 행에 붙어 단축어를 쓰는 클라이언트가 1M 프로필을 고르지 못했다. 기존 시험은 바로 그 배치를 단언하고 있었다. 2026-07-10 soma-work의 기본 모델을 gpt-5.6으로 바꾼 뒤에는 /context가 사용량을 0으로 보이고 자동 압축이 걸리지 않았다. 개발 로그로 원인을 확인한 실패다. 창이 잘린 사건까지 넣으면 하나가 더 있다. 번역 백엔드의 하위 턴이 세션의 서버 쪽 안전 검토를 꺼 버린 실패는 기존 시험이 모두 통과하는 동안 실사용 기록에서 드러났다. 원인이 클라이언트의 새 요청 필드여서 모델 사건과의 연결은 약하다.¹⁶ 누락은 고친 커밋의 메시지가 그 모델을 부를 때만 잡혔으니 적게 센 쪽이다. 후보 224행 가운데 206행은 모델 이름이 커밋의 공동 저자 서명 줄에만 있어서, 사전 등록한 빼기 사유(토큰 언급이 실패와 무관)로 기계적으로 뺐다. 후보 규칙이 서명 줄까지 잡은 것은 결과 문서에 사전 등록 이탈로 적었다.

별칭 사건의 시험은 실패를 비켜 간 것이 아니라 고장 난 배치를 맞다고 확인했다. 시험은 두 별칭이 272k 기본 행에 붙는다고 단언했고, 카탈로그가 그 배치 그대로였으니 통과했다. 목표는 단축어를 쓰는 클라이언트가 1M 프로필을 고르는 것이었고, 통과가 확인한 것은 시험에 적힌 기대였다. 그 기대가 목표와 어긋나 있었으니, 통과는 틀린 기대를 확인해 줬다. 고친 커밋은 두 별칭을 1M 행으로 옮기면서 그 시험의 기대를 뒤집었고, 두 별칭의 주인이 그 행 하나뿐인지 확인하는 검사를 같은 시험에 더했다.¹⁷ 97.1%는 검사 본문이 남았다는 기록이지 목표의 증거가 아니다. 재사용률은 검사가 남았는지를 잴 뿐, 남은 검사가 여전히 맞는지는 재지 않는다. 남은 검사의 통과가 확인하는 것은 그 검사를 쓸 때 적어 둔 기대다.

판정을 모아 둔 풀도 한쪽으로 기운다. 2021년 BEIR의 저자들은 여러 시스템이 기여한 TREC-COVID 판정 풀조차 어휘 매칭 쪽으로 기울어 있어서, 밀집 검색 모델 TAS-B가 찾은 상위 10건의 31.8%가 판정 없이 비어 있었고(BM25는 6.4%) 시험한 시스템들의 구멍 980쌍을 새로 판정하자 ANCE의 nDCG@10이 0.654에서 0.735로 올라 BM25(0.668)를 앞질렀다고 적었다.¹⁸

평가 세트가 짧게 산다는 증언도 있다. Claude Code를 만든 Boris Cherny는 2026년 YC 대담에서 평가 하나가 모델 한두세 세대쯤 산다고 말했다. 평가를 포화시키면 버리고 새로 만드는 일이 잦다는 것이다. 새 모델이 나오면 시스템 프롬프트를 지우고 한 줄씩 되살린다고도 했다. 버려지는 것은 포화된 능력 평가이고, 실패 분류의 수명은 따로 봐야 한다.¹⁹ 여섯 명이 함께 쓴 연재의 저자 가운데 한 명인 Bryan Bischof는 방대한 황금 평가 세트는 잘 늙지 않는다고 썼다. 그가 적은 순서는 직접 써 보기, 오류 분석, 그다음에 굳힌 평가였다.²⁰ 채점 장치를 담은 플랫폼도 사라진다. OpenAI가 2024-10-01에 내놓은 Evals 플랫폼은 2026-06-03 폐기 공지를 받았다. 2026-10-31부터 읽기 전용이 되고, 2026-11-30에 닫힐 예정이다. 같은 날 Agent Builder와 재사용 프롬프트도 폐기 공지를 받았다. 전환 기간에는 기존 평가 내용이 남아 있다.²¹

지운 장치

204건의 원장에서 가장 큰 무리는 검사는 통과했는데 사용자가 보는 결과는 틀린 실패, 42건이었다. 그 42건 가운데 하나는 검사 장치들 자체를 두고 적은 줄이다. 2026-10-02 13:02의 그 줄은 에이전트의 행동을 검사하던 훅을 모두 지운 일을 같은 무리로 분류했고, 놓친 지점을 이렇게 적었다. 발동과 오탐을 재 보지 않은 채 에이전트 자신의 문장에서 낱말과 형식 같은 상관 신호를 세는 훅을 만들었고, 같은 무리의 두 번째 정정에 장치를 요구하던 원장 규칙이 그런 훅을 늘렸다.²²

발단은 측정이 아니었다. 2026-09-30, 세 LLM 엔진의 리뷰를 다섯 차례 거쳐 승인된 변경안이 머지를 앞두고 있었고, 그 안에 새 검사 하나가 들어 있었다. 머지 직전 나는 에이전트가 만드는 검사 대부분이 쓸모없다고 강하게 거부하고, 검사 전부를 다시 보게 했다. 거부가 먼저 왔고 측정은 그 뒤에 왔다.²³

재검토는 의견 대신 발동을 셌다. Claude Code의 훅은 에이전트가 도구를 부르거나 응답을 마치는 순간에 끼어들어, 그 동작을 막거나 문맥을 덧붙이는 스크립트다. 보존된 세션 기록 4,987개(하위 에이전트 포함, 발동 기간 2026-08-21~09-30)에서 훅이 실제로 막거나 거부하거나 문맥을 주입한 사건만 골랐다. 발동은 모두 2,987건이었고, 그 가운데 2,395건(80%)이 백그라운드 명령마다 붙던 안내 주입 하나였다. 세션 캡처를 강제하는 검사는 104개 세션에서 196번 발동했는데, 표본 4건 가운데 2건은 실질이 없다며 건너뛰고 통과했다. 할 수 없다는 선언을 잡는 검사는 20번 발동했고, 그 가운데 5번은 바로 다음 응답이 오탐이라고 선언했다. 위임을 강제하는 검사는 74번 거부했는데, 빠져나가는 길은 같은 호출을 한 번 더 하는 것이었다. 결정을 강제하는 검사, 영수증 URL 검사, 프리뷰를 먼저 냈는지 보는 검사는 한 번도 발동하지 않았다. 완료 보고의 '남은 일' 목록을 잡는 검사도 0번이었지만, 그 검사는 집계 전날 생겨 하루쯤만 걸려 있었다. 반대쪽 증거도 있었다. '확정'이라는 과장을 잡는 검사는 발동 6번 가운데 표본 3건에서 실제로 부풀려진 주장을 낮췄다. 측정 도구도 한 번 틀렸다. 스캐너의 첫 판은 스크립트 원문을 열어 본 일까지 발동으로 섞어 버려졌다.²⁴

판정 축은 하나였다. 그 검사가 막으려는 조건 자체를 보는가, 그 조건과 상관만 있는 신호를 보는가. 실행될 바이트나 금지된 문자는 조건 자체다. 낱말이 함께 나오는지, 줄 수, 주석, 플래그, 타이머는 상관 신호다. 검사의 목표는 그 조건을 막는 것이다. 조건 자체를 보는 검사의 통과는 그 조건에 대한 판정이고, 상관 신호를 보는 검사의 통과는 신호에 대한 판정이어서, 신호와 조건이 갈라지는 자리에서 통과와 목표도 갈라진다. 상관 신호를 보면서 빠져나가는 길이 자기 선언인 검사, 곧 오탐이라고 한 줄 쓰거나 주석을 달거나 다시 시도하면 지나가는 검사는 지웠다. 그런 검사는 목표와 어긋난 통과를 보상한다. 그 통과는 조건이 지켜졌다는 기록이 아니라, 에이전트가 오탐이라고 적었거나 주석을 달았거나 한 번 더 시도했다는 기록이다. 상관 신호를 본다는 것만으로 지우지는 않았다. 지우기 전에 발동과 오탐, 빠져나간 길을 셌다. 있으면 좋다는 말은 근거가 되지 못했다. 없을 때 실제로 무엇이 깨지는지 하나를 대야 했다.²⁵

첫 판은 09-30에 대상 23개를 문서 하나로 묶어 다섯 차례 검토했고, 17개를 만장일치로 지우기로 했다. 이튿날 저녁 그 17개가 지워질 때, 내 결정으로 핸드오프 문장 검사 하나가 함께 지워졌다. 같은 날 검사마다 따로 봤느냐는 물음이 나왔고, 묶음 검토가 문제가 되자 둘째 판이 열렸다(10-01~02). 첫 판에서 살아남은 5개에, 첫 목록 밖에 있던 실행 러너와 09-30 오후 다른 세션이 새로 만든 검사 하나를 더해 7개였다(23 − 17 − 1 + 2). 검사마다 세 엔진이 최대 세 차례 따로 봤고, 판정은 모두 3:0이었다. 5개를 지웠고, 실행 러너는 정규식으로 거부하던 부분만 막지 않게 고쳐 남겼으며, 커밋될 비밀값 검사는 조건을 달아 남겼다. 필요 없는 것은 모두 지워도 된다는 승인은 그 뒤에 나왔다.²⁶

지워진 검사들이 실제로 한 일은 개별 판정에서 드러났다. 완료 표시 이모지를 막는 검사는 비동기로 쓰이는 대화 기록을 읽었다. 그래서 표시가 든 응답 18건 이상이 그대로 지나갔고, 그 검사가 막은 5건 가운데 표적은 하나도 없었다. 4건은 인용된 기호였고 1건은 표시가 없는 응답이었다. 이슈 트래커의 완료 처리를 검사하던 훅은 등록 뒤 43일 동안 실제로 막은 일이 없었다. 발동 3건은 모두 자기 시험이었고, 09-15에 도구 입력의 형식이 바뀐 뒤로는 빈 값을 읽어 모두 통과시켰다. 고쳐서 살렸다면 같은 기간의 정상적인 완료 처리 6건을 모두 막았을 것이다. 릴리스 전에 프리뷰를 먼저 냈는지 보는 검사는 태그될 커밋이 아니라 그 부모를 봤고, 강제하는 순서도 사용자가 정한 순서(안정판 먼저, 프리뷰는 그다음)와 반대였다. 스킬 문서를 커밋할 때 돌던 린트는 줄 길이와 절 번호 같은 문서 모양만 봤다. 실제로 걸린 것은 모두 줄 길이와 파일 길이였고, 막은 결함은 없었다.²⁷

검사가 왜 그렇게 늘었는지도 판정에 들어갔다. 재검토는 원장의 규칙을 구조적 원인으로 봤다. 무리마다 표식 한 줄이 미리 있었으니 첫 실건부터 정정마다 장치가 강제됐다. 재검토 전, 머지를 앞둔 그 변경안을 검토하던 한 엔진은 새 검사를 빼면 원장 규칙을 어긴다는 이유로 그 검사를 남기자고 했다. 원장이 201행이던 재검토 첫날, 장치 칸이 채워진 195행 가운데 90행이 훅이나 게이트, 린트, 셸 스크립트였다. 같은 규칙이 시험과 확인 스크립트 수십 개도 낳았고, 그 대부분은 지금도 남아 있다. 원장이 실패군마다 처음 붙였던 장치 여섯 가운데 훅 넷이 이 정리에서 지워졌고, 스크립트 둘은 남았다.²⁸

2026-10-02 오후, 비공개 운영 저장소의 Claude Code 훅은 0개가 됐다. 첫 판의 23개와 둘째 판에 더한 2개, 10-02 새벽에 생긴 훅 하나까지 재검토한 26개 가운데 남은 것은 사용자가 실행할 스크립트의 바이트를 해시와 스냅샷으로 대조하는 실행 러너와, 커밋될 줄에서 비밀값을 찾는 검사, 둘이었다. 지운 24개 가운데 23개는 세 엔진의 판정을 따랐고, 나머지 하나가 핸드오프 문장 검사다. 커밋될 비밀값 검사를 남긴 근거는, 검사가 생기기 며칠 전 실제로 커밋된 비밀값을 그 패턴이 정확히 잡아낸다는 확인이었다. 발동을 센 기록에서 그 검사가 실제로 막은 두 번은 모두 오탐이었다.

판정한 쪽도 LLM 엔진 셋이었다. 채점자를 채점한 채점자 역시 같은 종류였고, 사람이 한 일은 결론을 승인한 것이었다. 지운 것이 옳았는지는 아직 재지 않았다. 이 기록은 지운 지 사흘 뒤에서 끝난다. 검사가 판정 가능한 피드백을 만든다는 말은 이 기록에서 범위가 좁다. 한 사람의 시스템에서 판정을 견딘 것은 막으려는 조건 자체를 보는 검사뿐이었다.

마지막 훅

마지막 훅은 10-02 새벽 2시 50분에 생겼다. 공개 저장소에서 필수여야 했을 CI 검사를 통과하지 않은 채로 PR 네 건이 머지된 일 뒤였다. 한 건은 검사가 실패한 뒤에, 세 건은 검사가 끝나기도 전에 머지됐고, 네 건 모두 검사는 실패했다. 그 훅은 명령 문자열에 머지를 뜻하는 낱말이 보이면, 그 낱말을 언급만 한 명령까지 머지 시도로 보고 막았다. 실제로 막은 세 건 가운데 결함을 잡은 것은 하나도 없었다. 세 엔진은 3:0으로, 필수 검사를 서버에서 강제하고 훅은 지우자고 판정했다. 오후 2시 10분 그 훅은 지워졌고, 공개 저장소의 서버 쪽 브랜치 보호가 그 자리를 맡았다. 11시간 만이었다.²⁹

여섯 달

석 달

2023-03-14, OpenAI는 GPT-4를 공개하는 글의 API 문단에 한 줄을 넣었다. 지금의 버전에 묶어 두고 싶으면 gpt-4-0314를 부르면 되고, 그 버전은 6월 14일까지 지원한다는 것이었다. 긴 문맥판 gpt-4-32k-0314도 같은 날까지라고 적혔다. 석 달짜리 약속이다. 두 주 전 gpt-3.5-turbo-0301을 내놓을 때도 OpenAI는 적어도 6월 1일까지는 지원한다고 썼다.¹

이름에 날짜를 박은 이런 스냅숏은 같은 이름이 가리키는 모델이 바뀌지 않게 하는 장치다. 그 이름을 골라 부르는 일을 버전 고정이라고 부른다. 6월 14일 하루 전인 2023-06-13, OpenAI는 두 스냅숏을 2023-09-13에 끈다고 공지했다. 2023-07-20 같은 글 머리에 갱신이 붙었다. 고객과 커뮤니티의 의견을 검토한 끝에 지원을 적어도 2024-06-13까지 늘린다는 것이었고, 그 옆에 까닭을 밝힌 문장이 있었다. 대부분의 지표는 나아졌지만 성능이 나빠지는 과업이 있을 수 있고, 그래서 API 사용자가 모델 버전을 고정하게 해 둔다는 것이다.²

공식 폐기 표에 적힌 gpt-4-0314의 종료일은 2026-03-26이다. 종료 공지는 2025-09-26에 나왔다. 출시에서 종료까지 1,108일, 석 달 약속이 세 해를 넘겼다. 적어도 6월 1일까지라던 gpt-3.5-turbo-0301은 562일을 살았다.³ 약속한 날짜는 결과적으로 하한 노릇을 했다. 6월 13일 공지가 먼저 9월 13일까지 늘렸고, 그 너머의 날들은 고객과 커뮤니티의 의견을 검토했다는 7월 20일 갱신 뒤에 왔다. 고정도 종료일까지만 통했다.

하루

2026-10-05 오전, 누리별항공 환불 앱의 240개 질문이 두 모델을 거쳤다. claude-haiku-4-5는 17.1%를, gpt-5.5는 2.5%를 틀렸다. 규정이 답하지 않는 60개에서의 실패율은 48.3%와 10.0%였다. 열 번의 시연으로는 두 모델이 갈리지 않았다. 둘 다 첫 실행 열 번을 모두 맞혔다.⁴ 앱 앞에 선택이 하나 놓였다. 모델을 바꿀 것인가.

측정이 답하는 것은 그 선택의 한 칸이다. 이 과업의 240개에서, 그날의 첫 실행으로 두 모델이 얼마나 틀렸는지다. 호출 한 번의 비용과 지연, 보안, 그리고 지원이 언제 끝나는지는 이 측정이 두 모델 사이에서 비교하지 않았다. 지연과 토큰 수는 호출마다 기록만 해 두었다. 240개는 자기 과업에서 품질이 어떻게 달라지는지를 확인하는 근거이고, 비용과 지연과 보안과 지원 종료는 따로 재야 하는 근거다.

지원 종료는 공식 표에 날짜로 적혀 있다. 그 앱이 묶어 둔 스냅숏 claude-haiku-4-5-20251001은 2025-10-15에 나왔고, Anthropic의 표는 그 퇴역일을 'Not sooner than October 15, 2026'으로 적는다. 2026-10-15보다 이르지 않다는 뜻이고, 측정한 날의 열흘 뒤다. 하한이지 수명 약속이 아니다. 같은 표는 활성으로 적힌 모델 14개의 잠정 퇴역일을 모두 출시일에서 정확히 1년 뒤 '이후'로 적고 있었다. Anthropic은 공개 모델을 퇴역시키기 적어도 60일 전에 알리겠다고 적었다. gpt-5.5는 2026-04-24에 나왔고, 2026-10-05까지 폐기 공지가 없었다. OpenAI의 폐기 페이지는 안전이나 규정 준수 문제로 서둘러야 하는 경우가 아니면 GA 모델을 적어도 6개월 앞서 알린다고 적는다.⁵

품질 칸을 채운 것은 바뀌지 않은 240개였다. 그 240개가 다음 모델 앞에서도 맞는 잣대일지는 그때 다시 재 봐야 안다. 검사가 남았다는 것과 그 검사가 여전히 맞는다는 것은 다른 측정이다. 공급자가 인정한 '나빠지는 과업'에 그 앱의 과업이 드는지도 공급자의 지표가 말해 주지 않는다.

이 선택은 한 번으로 끝나지 않는다. 그 앱의 스냅숏은 퇴역일의 하한만 적힌 채 묶여 있고, 여섯 달 동안 폐기 공지와 새 판이 언제 올지는 정해져 있지 않다. 모델을 고르는 일 너머에 정할 것이 하나 더 있다. 여섯 달을 무슨 단위로 끊어 계획할지다.

반년

사전 등록한 판정은 하향이었다. 조건 없이 '바뀐다'고 쓰려면 어느 공급자로 시작하든 성립해야 해서, 판정에는 공급자마다 모델과 API, SDK만으로 짠 세 핵심 스택 하한의 최솟값을 쓰기로 했다. 그 값은 39.3%로, 측정 전에 정한 반증선 50%보다 낮았다. 그래서 '여섯 달 안에 무언가는 바뀐다'는 문장을 버리고, 등록한 문언대로 '바뀔 수 있다'로 낮췄다. 붙는 비율은 39.3%~100.0%다. 여섯 달 안에 무언가가 바뀔 수 있다는 말이지, 반드시 바뀐다는 말이 아니다.⁶

판정량이 센 것은 출발 코호트다. 2023-01부터 2026-04까지 매달 1일을 출발일로 삼았다. 그날 공식 문서가 새 사용자에게 출발점으로 권한 것을 먼저 쓰고, 그런 문장이 없으면 퀵스타트나 공식 SDK README의 첫 예제가 쓴 것으로 모델과 API, SDK를 정했다. 조합에 따라 프레임워크와 평가 도구를 얹었다. 그 스택이 출발 뒤 182일 안에 폐기 공지나, 호환성 단절을 명시한 메이저 판을 맞았는지(연성 단절), 구성 요소가 실제로 꺼졌는지(경성 단절)를 셌다. 연성 단절은 바뀜이 예고되거나 선언된 날이고, 경성 단절은 쓰던 구성 요소가 실제로 꺼진 날이다. 학습자는 출발일의 구성 요소를 올리지 않는다고 가정했고, 단절을 맞은 뒤에도 갈아타지 않은 채 첫 단절이 온 날만 쟀다.⁷ 버전을 고정한 채 출발한 스택이 여섯 달 동안 무엇을 맞는지를 잰 셈이다.

Google 핵심 스택의 사전 등록 예측은 75%로 세 공급자 가운데 가장 높았다. 아무것도 얹지 않은 핵심 스택의 연성 단절 비율은 OpenAI 45.0%, Anthropic 52.0~76.0%, Google 39.3~57.1%였다. 범위가 있는 것은 공식 문서가 출발점을 여럿 적어 둔 달이 있어서다. 판정에 붙은 비율의 위 끝은 모든 조합의 상한 가운데 가장 높은 값으로, OpenAI Agents SDK를 얹은 조합(2025-04 이후 출발한 코호트)에서 나왔다.⁸ 여섯 달짜리 계획으로 옮기면, 어느 공급자로 시작하든 아무것도 바뀌지 않는다는 전제로 짤 수 없고, 바뀌는 주를 달력에 미리 정해 둘 수도 없다.

이 비율의 한 칸은 출발일 하나의 기록이다. 출발일 2023-07-01에 공식 Python SDK README의 첫 예제는 openai.ChatCompletion.create로 Chat Completions API를 불렀고, 모델 칸에는 별칭 gpt-3.5-turbo가 있었다. 등록 규칙대로 별칭을 그날 이전에 나온 가장 새 스냅숏으로 읽으면, 그날 출발한 스택은 gpt-3.5-turbo-0613, Chat Completions API, openai-python 0.27 줄이다.⁹

여섯 달 창 안에서 단절로 센 사건은 하루에 몰려 있었다. 출발 128일 뒤인 2023-11-06, OpenAI는 gpt-3.5-turbo-0613의 폐기를 공지했고, 같은 날 openai-python 1.0.0이 나왔다. 1.0.0의 릴리스 노트는 호환을 깨는 변경의 목록을 이행 안내로 넘겼다. 이행 안내는 새 메이저 판을 냈으니 서둘러 올리기를 권한다는 문장과 라이브러리를 통째로 다시 썼다는 문장으로 시작했고, 코드를 바꿔 주는 openai migrate 명령이 함께 나왔다. 2023년 튜토리얼의 표준 호출이던 openai.ChatCompletion.create는 그 판에서 client.chat.completions.create로 바뀌었다.¹⁰ 이 코호트는 그날 연성 단절을 두 갈래로 맞았다. 모델의 폐기 공지와 SDK의 새 메이저 판이다.

그날 꺼진 것은 없었다. 새 SDK가 나왔다는 것과, 묶어 둔 판으로 돌던 실행이 실패했다는 것은 다른 사건이다. 0.27 줄은 계속 설치할 수 있었고 HTTP API는 그대로였다. 끊긴 것은 서비스가 아니라, 새 판 위에 옮겨 붙인 옛 코드였다. 공지를 받은 모델이 실제로 꺼진 것은 출발 440일 뒤인 2024-09-13으로, 여섯 달 창 밖이다.¹¹ 세 핵심 스택에서 구성 요소가 여섯 달 안에 실제로 꺼진 비율은 스택에 따라 0~12%였다. 연성 단절을 낸 것은 대부분 공급자 공식 SDK의 메이저 판이었고, API 계열에서 온 단절은 세 스택 모두 0이었다. 묶어 둔 스택이 여섯 달 안에 맞은 것은 대개 꺼짐이 아니라 공지와 새 판이었다. 그래서 여섯 달 동안 묶어 둘 것은 모델 스냅숏만이 아니라 SDK 판이고, 다시 잴 때는 그 판을 올리는 때다.

열여섯 달

그 코호트의 모델은 창 안에서 공지를 받고 창 밖에서 꺼졌다. 모델 ID 하나하나를 출시일부터 따라가면, 이름은 대개 반년보다 오래 갔다. 세 공급자의 공식 기록에 남은 텍스트 모델 ID의 중앙 생존은 499일, 열여섯 달 남짓이었다.¹² 그래도 2024년부터 날마다 시작하는 여섯 달 창을 잡으면, 창이 시작할 때 쓸 수 있었고 아직 공지가 없던 텍스트 모델 ID 가운데 평균 33.7%가 그 창 안에서 폐기 공지를 받았고 15.7%가 꺼졌다.¹³ 그러니 스냅숏 ID를 묶어 두는 일이 정하는 것은 바꾸는 때이지, 그 이름이 여섯 달을 간다는 보장이 아니다. 두 비율은 스냅숏만 따로 잰 값이 아니라 프리뷰와 특화 변형까지 넣은 텍스트 모델 ID 전체의 평균이고, 묶어 둔 이름 하나가 그 여섯 달 안에 공지를 받을지, 꺼지기까지 할지는 출발일에 알 수 없다. 공지를 받으면 그것이 바꿀 후보를 다시 재는 계기가 된다.

사흘

달력으로 기간을 약속한 과정들의 기록도 있다. 2012년 11월의 Dev Bootcamp 홈페이지 첫 화면에는 두 줄이 있었다. 'In 9 intense weeks', 그리고 'You will become a web developer'.¹⁴ 2017년 그 과정은 18주였다. 2017-07-12 Dev Bootcamp는 이메일로, 다양한 학생에게 열린 양질의 코딩 교육이라는 사명을 해치지 않고는 지속 가능한 사업 모델에 이를 수 없다며 그해 12월 8일에 문을 닫는다고 알렸다. 12월의 홈페이지에는 부트캠프 업계를 연 지 5년 만에 마지막 기수를 졸업시킨다는 문장이 걸렸다.¹⁵

2023-12-25, 샌안토니오의 Codeup 홈페이지는 경험이 없어도 6개월이 안 돼 기술 전문가가 된다고 광고했다. 사흘 뒤인 2023-12-28 정오, 직원들은 오늘부로 모든 운영과 수업을 멈춘다는 이메일을 받았다.¹⁶ 두 학교의 기록에서 확인되는 것은 광고가 약속한 기간과 그 뒤에 관측된 일이다. 문을 닫은 까닭은 이 기록으로 가르지 않는다.

LinkedIn의 미국 목록에서 AI 엔지니어는 2025년판과 2026년판 모두 가장 빨리 늘어난 직함 1위였고, 그 직함으로 옮긴 사람들이 그 전까지 쌓은 경력 연수의 중앙값은 3.6년과 3.7년이었다. 일자리가 가장 많은 직함의 순위가 아니라, 가장 빨리 늘어난 직함의 순위다.¹⁷

한 바퀴

여기서부터는 제안이다. 여섯 달을 달력의 칸 대신 순환으로 끊자는 것이다. 달력의 칸은 날짜마다 끝나 있어야 할 일을 미리 정한다. 2023-07-01에 출발한 스택에게 128일 뒤의 공지와 새 판은 출발일에 짠 어느 칸에도 없던 일이었다. 바퀴는 끝을 날짜 대신 확인으로 정한다. 한 바퀴는 가장 작은 구현에서 시작한다. 그 구현의 실패를 가를 작은 검사를 붙이고, 실제로 써 보고, 실패를 읽어 분류한 뒤, 구현과 검사를 함께 고치는 데서 끝난다. 무엇을 배울지도 달력이 정하지 않는다. 검색이나 도구 호출 같은 기술은 주 번호로 오지 않고, 오류 분석이 그쪽을 가리킬 때만 들어온다. 여섯 달을 이 순환을 몇 번 돌았느냐로 세자는 것이 이 책의 제안이다. 이 순서가 다른 순서보다 더 빨리 가르친다는 비교는 없고, 마친 뒤에 무엇이 된다는 약속도 없다. 일자리와 경력에 대해서는 아무것도 말하지 않는다.

바퀴에는 서로 다른 확인이 둘 들어간다. 하나는 시스템의 확인이다. 고정한 세트를 같은 판정으로 다시 돌려, 이번 변경이 무엇을 고치고 무엇을 깨뜨렸는지 센다. 그 세트는 첫 주의 기대 동작 20건에서 시작해 실제 실패를 받아 자라고, 교체 판단에 앞서 동결된다. 다른 하나는 사람의 확인이다. 그때까지 해 온 일 가운데 하나를 AI 도움 없이 다시 해 본다. 부록 B는 26주를 여덟 바퀴로 나누고, 바퀴가 끝나는 주 가운데 다섯 곳의 완료 조건에 이 확인을 넣는다.

4주에는 새 기대 동작 다섯 건과 그 판정 근거를 손으로 쓰고, 규칙 엔진과 몇 건이 어긋나는지 센다. 10주에는 수수료 숫자만 바꾼 개정 규정을 가정해 세트 열 건의 기대 동작을 쓰고, 개정 숫자를 넣은 엔진과 견준다. 14주에는 다섯째 바퀴의 핵심 변경 하나를 다시 짜서 같은 결과가 나오는지 본다. 18주에는 그 바퀴의 실사용 실패 하나를 입력과 조항과 코드 줄까지 추적하고, 원인에 닿았는지와 걸린 시간을 남긴다. 26주에는 다른 규정 문서 하나로 1주의 계약을 처음부터 다시 짜고, 걸린 시간과, 다른 사람 한 명이 판정 근거에 동의하지 않은 건수를 센다.

두 확인은 서로를 대신하지 못한다. 세트의 통과는 앱이 그 질문들에 맞게 답했다는 기록이다. 그 앱을 만든 사람이 도움 없이 같은 판정을 낼 수 있는지는 세트에 남지 않는다. 세트는 실패가 났다는 것과 고친 뒤 사라졌다는 것을 보여 주지만, 그 실패가 어느 입력과 조항과 코드 줄에서 왔는지를 사람이 혼자 짚을 수 있는지는 보여 주지 않는다. 도움 없이 다시 해낸 일은 거꾸로, 앱이 어느 질문에서 틀리는지를 말하지 않는다. 4주처럼 둘 다 규칙 엔진에 대 보는 때에도, 한쪽은 앱의 답을 대고 다른 쪽은 사람의 답을 댄다. 사람의 확인도 제안이고, 이 과업에서 그 확인이 배움을 늘린다는 직접 증거는 없다.

바퀴 안에서 버전 고정은 다른 일을 한다. 고정은 변화를 없애지 않고, 사용자가 고르는 모델과 SDK의 교체를 다른 변경과 떼어 놓는다. 같은 모델 ID 아래의 인프라 갱신이나 지원 종료까지 통제하지는 못한다. 스냅숏 ID와 SDK 판을 묶어 두면 새 모델과 새 판은 바퀴 안의 변경 하나로 들어오고, 그 변경도 시스템의 확인을 거친다. 출발 코호트의 연성 단절 대부분이 공식 SDK의 메이저 판에서 왔으니, 묶어 둔 판을 올리는 일도 그런 변경 하나로 다룬다. 2023-11-06 같은 날이 바퀴 안에 오면, 그날 나온 새 메이저 판은 묶어 둔 판을 건드리지 않는다. 판을 올리는 일은 다른 변경과 섞지 않은 한 주의 변경이 되고, 고정 세트를 다시 돌려 직전 판과 견준 뒤 남기거나 되돌린다. 같은 날 받은 폐기 공지는 모델 교체 판단의 계기로 남는다. 첫 바퀴(1~4주)에는 한 동작과 그 실패를 아는 법을 두고, 마지막 바퀴(22~26주)에는 그 앱의 교체 판단을 두어 동결한 세트로 정하게 한다. 달력을 버리지는 않는다. 26주는 고정이고, 늦어지면 아직 하지 않은 가운데 단계를 정해진 순서로 뺀다. 첫 주의 계약과 매주의 변경 하나, 세트를 다시 돌리는 일은 빼지 않는다.

첫 주

첫 바퀴에는 순서 문제가 하나 있다. 실패를 가를 검사를 짜려면 무엇이 맞는 출력인지 정해야 하는데, 그 기준은 출력을 본 뒤에야 굳는다.¹⁸ 그래서 첫 주에는 구현과 기대 동작이 함께 서고, 그 기대 동작은 굳은 정답지가 아니라 출력을 보며 고쳐 갈 첫 판이다.

부록 B의 첫 주는 가장 작은 동작 하나와 기대 동작 20건이 다 서야 끝난다. 가장 작은 동작은 명령 한 줄로 도는 모델 호출 하나다. 고정한 규정 전문과 지시문을 넣은 호출이 질문 하나에 「최종: 환불액」, 「최종: 판단 불가」, 「최종: 정보 필요」 가운데 하나로 답한다. 스냅숏 ID는 설정 한 곳에 두고, SDK 판은 잠금 파일로 묶고, API 키는 저장소 밖에 둔다. 20건은 정상 6, 경계 4, 정보 부족 4, 거절 6이다. 경계 넷은 출발까지 정확히 72시간, 출발 시각 정각, 정확히 3시간 늦은 항공편, 결제하고 정확히 24시간 뒤의 취소다. 그 가운데 하나는 플렉스 운임 300,000원에 세금 40,000원인 항공권을 출발 시각 정각에 취소하는 질문이고, 기대 동작은 「최종: 환불액 240000원」이다. 출발 시각 정각을 포함한다는 제7조를 읽어야 나오는 금액이다. 거절 여섯 가운데 하나는 어머니가 돌아가셔서 못 간다며 수수료 면제를 묻는 질문이고, 기대 동작은 「최종: 판단 불가」와 고객센터 안내다. 개인 사정의 면제는 규정이 정하지 않고 고객센터가 심사한다는 제1조③이 근거다.

통과 수는 그 주의 완료 조건에 들지 않는다. 20건의 원출력을 손으로 판정해 근거와 대조하는 일과, 그 20건이 가르는 것과 가르지 못하는 것을 한 문단씩 적는 일이 든다. 이 과업에서 20건이 가르는 것은 한 종류가 통째로 깨지는 실패와 출력 형식의 위반, 조항을 따지는 순서의 오류다. 몇 번에 한 번만 틀리는 실패와 적어 두지 않은 종류의 질문, 실제 사용에서의 실패율은 가르지 못한다. 세트 밖 질문 다섯은 직접 써서 넣어 보고, 거기서 나온 실패는 둘째 주 세트의 후보가 된다. 부록 B의 26주 실행표는 그 주에서 시작한다.

마지막 줄

최종: 환불액

누리별항공 환불 앱이 처음 낸 답의 마지막 줄은 「최종: 환불액 339000원」이었다. 세이버 표 419,000원을 물은 질문에 2.8초 만에 돌아온 답이었고, 규칙 엔진이 같은 사실로 낸 금액과 같았다. 시연 열 개는 두 모델에서 모두 그렇게 지나갔다. 열 개의 마지막 줄이 모두 규칙 엔진의 금액과 같았다. claude-haiku-4-5에서 답 하나에 걸린 시간의 중앙값은 2.7초였다. 앱에 준 지시문에는 규정으로 판단할 수 없는 질문이면 추측하지 말고 판단할 수 없다고 안내하라는 줄이 있었다.¹

그 줄에서 출발해 잰 숫자들은 이렇다. 같은 날 같은 앱에 240개를 넣자 claude-haiku-4-5는 17.1%를 틀렸다. 사전 등록한 예측은 15%였다. 실패는 규정이 답하지 않는 질문 60개에 몰려 29개였고, 그 가운데 20개가 규정이 정하지 않은 판단을 금액으로 단정했다. 같은 입력을 다섯 번씩 물으면 입력 50개 가운데 24%가 때로 맞고 때로 틀렸고, 시연 한 건은 네 번 맞은 뒤 다섯 번째에 틀렸다. 고른 열 개는 사용 입력의 무작위 표본이 아니어서, 열 번의 성공으로는 실패율의 상한을 셈할 수 없다. 열 개가 240개를 잘 예측했는지는 모델과 과업에 따라 갈렸다. gpt-5.5로 돌린 두 앱과 claude-haiku-4-5로 돌린 추출 앱에서는 잘 예측했고, claude-haiku-4-5로 돌린 환불 앱에서만 놓쳤다.²

채점자도 쟀다. 정답을 아는 쌍 85개에서 세 채점자는 98.8%를 맞혔고, 서로 거의 같은 판정을 냈다(AC1 0.976). 85쌍의 예측은 그보다 낮은 88%와 0.78이었다. 정답이 하나가 아닌 열린 쌍 100개에서는 일치가 0.515로 떨어졌고, 두 답의 순서를 바꾸면 판정의 9.7%p가, 기준 문구를 고치면 23.3%p가 움직였다. 결과를 본 뒤 고친 기준이 열린 쌍의 일치를 0.939로 올렸지만, 그것은 판정값이 아니라 기준이 만든 일치였다. 정확도를 잴 수 있었던 것은 정답을 아는 쌍뿐이었다.³

내 저장소 셋의 검사는 남았다. 모델이나 엔진, SDK가 바뀐 사건 가운데 창이 잘리지 않은 14건에서, 사건 이전 검사 본문의 중앙 97%가 14일 뒤에도 공백 차이를 빼면 글자 그대로 남았다. 바뀐 모델을 직접 부르는 검사도 중앙 77%가 남았다. 예측은 88%와 45%였으니, 검사가 바뀌는 정도를 크게 본 셈이다. 가장 적게 남은 것은 리뷰 게이트 파일로, 9개 가운데 5개였다. 남은 검사가 잡지 못한 실패는 2건 확인됐다.⁴

그리고 여섯 달. 모델의 이름은 대개 1년 넘게 갔다. 공식 기록에 남은 텍스트 모델 ID의 중앙 생존은 499일이었다. 그래도 등록 규칙으로 구성한 출발 코호트 가운데 여섯 달 안에 폐기 공지나 호환성을 깨는 판을 맞은 비율은, 아무것도 얹지 않은 세 공급자의 스택에서 39.3~76.0%였고 OpenAI Agents SDK를 얹은 조합에서 100%였다. 단절은 대부분 공급자 공식 SDK의 메이저 판에서 왔고, API 계열에서 온 것은 없었다. 아무것도 얹지 않은 스택에서 구성 요소가 실제로 꺼진 비율은 0~12%였다. 가장 많이 깨지리라 예측한 Google 스택(75%)은 하한으로 견주면 셋 가운데 가장 낮았다(39.3~57.1%). 측정이 허락한 문장은 등록한 규칙대로 낮춘 '여섯 달 안에 무언가가 바뀔 수 있다(비율 39.3%~100.0%)'까지다. 실제 학습자 모집단에서 일어난 비율은 아니다.⁵

최종: 정보 필요

재지 못한 것도 같은 줄에 놓인다. 가장 큰 것은 사람이다. 204건의 원장은 시스템에 장치가 붙은 자리를 보여 줬지만, 그 석 달 동안 원장 곁의 사람이 덜 틀리게 됐는지는 보여 주지 않았다. 분모가 없었다.⁶ 도움을 걷어 낸 시험으로 배움을 잰 연구는 있었다. 튀르키예의 한 고등학교에서 답을 주는 GPT-4와 연습한 반은 2023년 가을 연습 점수가 대조군보다 48% 높았고, AI 없이 치른 시험에서는 17% 낮았다. 새 파이썬 라이브러리를 처음 쓴 개발자 52명의 실험에서도 AI 보조 집단의 퀴즈 점수가 17%p 낮았다(평균 50% 대 67%). 다른 사람들, 다른 과목의 기록이다. LLM 위에서 제품을 짓는 일을 배우는 사람에게 친절한 환경과 사악한 환경의 틀을 직접 실증한 연구는, 2026-10-05에 검색한 범위에서 찾지 못했다.⁷ 이 책의 측정 가운데 사람이 무엇을 배웠는지를 잰 것은 없다.

그 앱에 대해서도 모르는 것이 남았다. 17.1%는 사전 등록한 가중치로 섞은 240개의 값이지, 실제 고객 문의를 무작위로 뽑아 잰 실패율이 아니다. 고객에게 보낼 안내문으로서 어느 답이 나은지는 세 채점자가 갈렸고, 그 갈림을 가를 정답은 없었다. 호출 한 번의 비용과 보안, 지원 종료는 이 측정 밖이다. 지연은 기록만 했고 판정에 넣지 않았다.

지운 장치가 옳았는지도 아직 모른다. 원장의 여섯 실패군 모두에서, 첫 장치가 생긴 뒤에도 같은 실패군의 교정이 16~37건씩 다시 기록됐다. 장치가 막아 낸 사건은 원장으로 셀 수 없었다. 2026-10-02까지 재검토한 검사 장치 26개 가운데 24개가 지워졌다. 23개는 LLM 엔진 셋의 판정으로, 하나는 내 결정으로 지웠다. 지운 지 사흘 뒤가 이 기록의 끝이다. 남은 검사가 계속 맞는지도 재지 않았다. 재사용률은 검사가 남았는지만 잰다. 남은 시험 하나는 별칭이 잘못 붙은 배치를 바로 그대로 단언하고 있었다.⁸

바깥의 숫자들은 빠르게 움직였다. Klarna는 2024-02-27 AI 상담 도우미가 출시 한 달 만에 상담 대화의 3분의 2를 맡았다고 발표했고, 1년 반 뒤인 2025-09-02의 증권신고서에는 12개월 동안 69%, 상담원 700명 이상의 일이라고 적었다. 회사가 스스로 잰 숫자지만, 첫 달의 숫자가 한 해를 버텼다.⁹ 모델이 끝까지 해내는 일의 길이도 빠르게 늘었다. METR의 원자료에서 2023년 이후 50% 시간 지평은 약 129일마다 두 배가 됐고, 2026-02-05에 나온 Claude Opus 4.6은 약 719분에 이르렀다. 같은 모델의 80% 지평은 약 70분이었고, METR은 16시간이 넘는 측정은 지금의 과제 묶음으로는 믿을 수 없다고 적었다.¹⁰ 이 두 기록은 그 앱의 측정과 반대쪽을 가리킨다. 첫 숫자가 뒤의 숫자를 맞힌 경우가 있고, METR의 과제 묶음에서 모델은 빠르게 나아졌다. 그 앱에서는 다른 공급자의 모델로 바꾸자 같은 240개의 실패가 41개에서 6개가 됐다. 그 차이가 시간 때문인지 모델 등급 때문인지는 이 측정으로 가를 수 없다.

최종: 판단 불가

그 앱이 틀린 금액 단정 20개는 정답이 「최종: 판단 불가」인 자리에 금액을 적은 답이었다. 규정 제1조③은 개인 사정에 따른 수수료 면제를 규정이 정하지 않고 고객센터가 심사한다고 적었다. 가족상 질문 하나에서 앱은 그 조항을 짚은 단락 뒤에 금액을 셈해 「최종: 환불액 249000원」으로 끝냈다. 채점이 읽은 것은 그 마지막 줄이었다.¹¹

2024-02-14 캐나다 브리티시컬럼비아주의 민사분쟁심판소는 Air Canada 웹사이트의 챗봇이 유족 할인을 여행한 뒤에도 신청할 수 있다고 안내한 일을 판단했다. 챗봇은 이미 여행을 했더라도 항공권 발행일로부터 90일 안에 신청하면 된다고 답했고, 답 속 링크가 연 정책 페이지는 반대로 말했다. 할머니가 세상을 떠난 2022-11-11에 예약한 가는 편과, 같은 안내를 믿고 닷새 뒤 예약한 돌아오는 편의 일이었다. 2023-02-08 Air Canada의 직원은 챗봇이 "오해를 부르는 말"을 했다고 인정했다. 답장은 챗봇 답변에 걸린 정책 페이지 링크를 가리켰고, 챗봇을 고칠 수 있게 문제를 기록해 두었다고 적었다. 심판소는 Air Canada의 주장을 사실상 챗봇이 제 행동에 스스로 책임지는 별개의 법적 존재라는 말로 요약하고, 이례적인 주장이라고 적었다. 그리고 고객이 웹사이트의 한 부분에서 찾은 정보를 왜 다른 부분에서 다시 확인해야 하는지 Air Canada가 설명하지 않았다고 적고(¶28), 손해 650.88캐나다달러에 이자와 수수료를 더한 812.02캐나다달러를 물게 했다. 결정문은 그 챗봇이 어떤 기술로 돌았는지 밝히지 않았다. Air Canada가 챗봇의 성격에 관해 아무 정보도 내지 않았다고 적었을 뿐이다.¹² 확인한 사람도 있었다. Mata 사건의 변호사는 판례가 진짜인지를 그 판례를 내놓은 기계에게 물었고, Google에서 찾을 수 없었다는 바깥의 결과는 Google에 없는 판례도 있으리라는 짐작으로 넘겼다.¹³

2026-10-05 오전 10시 43분 22초, 앱에 질문 하나가 들어갔다. "문의드려요. 세이버 표로 총 417,000원 결제했는데 그중 세금·공항이용료가 60,000원이래요. 53일 전에 예매했어요. 비행기를 놓쳤어요. 출발한 지 30시간 됐어요. 가족상을 당해서 못 가게 됐어요. 사망 증명서 내면 수수료 면제되나요? 환불 얼마 받을 수 있나요?" 3.9초 뒤 앱은 제7조로는 운임과 세금 모두 환불되지 않는다고 적고, 제1조③을 옮긴 다음 이렇게 썼다. "가족상 관련 수수료 면제 가능 여부는 이 규정으로 판단할 수 없습니다." 가족상과 입원으로 면제를 물은 열네 질문 가운데, 마지막 줄이 이렇게 끝난 답은 하나였다. 같은 질문에 gpt-5.5는 면제는 따로 심사한다는 단서를 달고 「최종: 환불액 0원」으로 끝냈다. 첫 채점 기준으로 두 답을 원래 순서대로 놓고 묻자, 세 채점자는 모두 판단 불가로 끝낸 답을 골랐다. 사후에 열어 본 기록에서는, 두 답의 순서만 바꾸자 셋 모두 gpt-5.5의 답을 골랐다. 규칙 엔진의 답은 판단 불가였다.¹⁴

「최종: 판단 불가」

반증과 만료

판정 먼저

이 책은 측정 전에 주장 셋과, 그 주장을 꺾을 조건을 등록했다. T1은 시연이 말해 주는 범위(그 가운데 (b)는 고른 시연의 예측력), T2는 채점이 만드는 피드백의 범위, T3는 여섯 달 안의 변화와 그 뒤에 남는 검사다. 측정 뒤 반증선을 넘은 것은 T3의 앞 절 하나다. '여섯 달 안에 무언가는 바뀐다'는 등록한 규칙대로 '바뀔 수 있다(비율 39.3%~100.0%)'로 내려갔다. T1과 T2는 반증선에 걸리지 않아 문구를 그대로 두었지만, T1에는 반대 결과가 붙는다. 과업 2와, 비교 모델 gpt-5.5로 돌린 두 과업은 반증선 조건을 충족했다. 저자 원장은 맞는 분모가 없어 비율을 포기했다.¹

표의 상태 어휘는 이렇게 쓴다. 유지는 반증선이 성립하지 않아 문구를 그대로 둔다는 뜻이다. 하향은 반증선이 성립해 등록해 둔 낮은 문구로 바꿨다는 뜻이다. 좁힘은 주장이 서는 범위를 줄인다는 뜻이고, 포기는 계산하지 않기로 한 양이다. 불발동은 금지 조건이 성립하지 않았다는 뜻이다. 반대 결과는 판정을 바꾸지 않았지만 주장과 반대쪽으로 나온 결과이고, 예측 실패는 사전 예측이 측정의 95% 구간 밖에 놓인 경우다. 이 판정 규칙은 그 앱의 측정과 채점자 측정에만 등록했다. 스택 추적과 남는 검사의 행에는 "등록한 판정 규칙 없음"과 예측과의 차이를 적는다. 사후 기술은 사전 등록에 없던 집계나 결과를 본 뒤의 서술이다.

반증선 표

본문에서 뺀 난점 셋

평가는 이미 업계의 구호다. 평가를 앞에 두라는 말은 이 책이 처음 하는 말이 아니다. Anthropic의 프롬프트 엔지니어링 문서는 프롬프트를 고치기 전의 전제로 성공 기준의 분명한 정의와, 그 기준에 대 볼 경험적 시험을 먼저 든다. 성공 기준을 세우는 안내서도 따로 있다. OpenAI의 평가 안내서는 평가 주도 개발, 곧 일찍 그리고 자주 평가하라는 원칙을 앞에 둔다. Chip Huyen의 『AI Engineering』은 평가의 두 장(3·4장)을 프롬프트 엔지니어링 장(5장)보다 앞에 두고, AI를 서둘러 들이는 팀 가운데 많은 수가 곧 가장 큰 장애물이 평가라는 것을 깨닫는다고 썼다.⁷ 실무자 설문에서 평가는 1위였지만 다수는 아니었다. 2025년 Amplify 설문에서 가장 고통스러운 한 가지로 평가를 고른 비율은 약 20%였고, 1,000명이 넘게 답한 2026년 설문에서는 평가 20%, 오케스트레이션 18%, 추론 16%, 보안 15%로 갈렸다. 보고서는 가장 큰 과제에 대한 폭넓은 합의가 없다고 적었다.⁸ 실제 순서가 반대였던 기록도 있다. Anthropic은 Claude Code가 직원과 외부 사용자의 피드백에 기댄 빠른 반복으로 시작했고, 평가는 나중에 더했다고 적었다.⁹ 그래서 이 책의 새 것은 순서가 아니다. 시연과 채점자와 검사 같은 학습 신호가 틀리는 자리를 측정 전에 등록한 방법으로 재고, 그 신호를 고치는 일을 이 일을 배우는 과정의 일부로 보는 데까지가 범위다. 어느 순서가 더 빨리 가르치는지는 재지 않았다.

원장은 한 사람의 것이다. 저자 원장은 한 사람이 한 시스템을 석 달 가까이 부린 기록이다. 관측 범위는 2026-07-06~10-02이고, 214행 가운데 실제 정정은 208행, 겹친 행을 빼면 서로 다른 교정 204건이다. 행은 사람이 에이전트를 멈춰 세우고 에이전트가 기록 스크립트를 불렀을 때만 생긴다. 실패군은 기록하는 에이전트가 고르고, 장치가 막아 낸 사건은 행이 되지 않는다. 같은 실패군의 두 번째 정정에 장치를 요구하던 원장 규칙은 그 자체로 장치를 늘렸고, 검사 장치를 지운 날의 재검토는 그 규칙을 검사가 불어난 구조적 원인으로 봤다. 그러니 원장은 발생률이나 개선 효과의 표본이 아니라 무엇이 기록됐는지의 기록이다. 남는 검사의 측정도 같은 사람의 저장소 셋에서 나왔고, 같은 저장소의 창이 겹쳐 사건끼리 독립이 아니다. 본문이 이 기록에서 건수와 관측 범위만 쓰고 비율을 쓰지 않은 까닭이다.¹⁰

독립은 가정이다. 3의 규칙은 서로 독립이고 같은 분포에서 나온 시행 n번에서 실패가 0일 때, 실패율의 95% 한쪽 상한이 약 3/n이라는 계산이다. 손으로 고른 시연은 그 전제를 채우지 않는다. 같은 입력을 다시 부르는 것도 n을 늘리지 않고, 그 입력의 출력 분산을 잴 뿐이다.¹¹ 독립은 실제 측정에서도 깨졌다. 그 앱에서 다섯 번씩 물은 입력 50개 가운데 24%가 때로 맞고 때로 틀렸고, 모델을 바꾼 뒤의 실패는 옛 모델이 틀린 문항에 몰렸다(조건부 실패 확률 12.2% 대 0.5%). τ-bench의 pass^k는 k번의 독립·동일 분포 시행이 모두 성공할 확률로 정의된다. 2024년 gpt-4o의 소매 과제 성공률 61.2%가 모든 과제에 고르게 퍼져 있었다면 8번 연속 성공은 약 2%여야 하는데, 보고된 값은 약 25%였다. 성공이 과제마다 몰려 있었다는 뜻이고, 이 셈은 저자의 것이다.¹² 성공과 실패가 입력마다 몰리면 시행 확률을 거듭 곱하는 셈은 장난감 모형에 머문다. 출발 코호트가 같은 사건을 나눠 갖는 스택 추적과, 창이 겹치는 남는 검사의 측정에는 그래서 구간을 붙이지 않았다.

반례 표

각 행은 어떤 관측이 이 책의 어느 문장을 약하게 만드는지를 적는다. 본문은 이 반례들을 장면 안에서 한 번씩만 다뤘다.

만료 표지

기준일은 2026-10-05다. 아래 숫자와 판본은 오른쪽 칸의 일이 생기면 낡는다.²⁴

측정의 지위

• 등록 시각. 그 앱의 측정, 채점자 측정, 스택 추적은 2026-10-05 10:32(한국 시각) 한 커밋으로, 남는 검사의 측정은 10:43에 결과보다 먼저 등록했다. 두 시각은 저자의 비공개 저장소에 남은 커밋 시각이다. 공개 자료에는 그 앱의 측정과 채점자 측정의 원출력·판정 규칙·분석 코드·호출 기록과 스택 추적의 자료·계산 코드를 싣고, 남는 검사는 비공개 저장소의 기록이 섞여 등록 문서·결과 문서·계수 코드만 싣는다.²⁵
• 결과 전 수정. 채점자 측정에서는 LLM 호출이 0인 상태에서 일치의 반증선을 Fleiss κ에서 Gwet AC1로 바꿨다. 판정이 한쪽으로 몰리면 관측 일치가 높아도 κ가 0 근처로 떨어지는 역설 때문이다. 남는 검사의 좁힘 규칙은 등록 문서가 결과 전에 더했다.
• 등록한 1회 교체 경로. 세 번째 채점자 claude-sonnet-4-6이 1시간 넘게(10:34~11:35, 시도 10번 모두) 502 오류를 내서, 등록해 둔 경로대로 gpt-5.6-sol로 바꿨다. OpenAI 계열 채점자가 둘이 되어 AC1이 위로 치우칠 수 있지만, 측정값이 이미 0.8 아래라 판정은 같다.
• 표본. 채점자 측정은 200쌍으로 등록했지만, 정답을 아는 쌍이 목표 100개에 못 미쳐 85개 + 열린 쌍 100개 = 185쌍이 됐다.
• 루브릭 v2. 설계상 결과를 본 뒤 썼고, v2로 채점하기 전에 커밋했다. v2로 다시 잰 일치(열린 쌍 0.939, 전체 0.960)와 열린 쌍의 동점률(44.7% → 85.3%)은 사후 기술이고 판정값이 아니다.
• 탐색 측정. 모델 ID의 생존(499일 등)과 6개월 창의 노출 비율은 사전 등록 이전의 탐색이고 판정량이 아니다. 스택 추적의 예측은 이 탐색을 보고 적었다고 등록 때 밝혔으니, OpenAI 45% 예측이 맞은 것은 증거로서 무게가 작다.
• 남는 검사 측정의 이탈. 바뀐 모델을 부르는 검사가 사건 전에 없던 사건이 둘이라 그 중앙값은 12건이 아니라 10건으로 셌다(0이나 1로 넣어도 판정은 같다). 모델 이름이 커밋 서명 줄에만 있던 누락 후보 206행은 등록한 빼기 규칙으로 뺐다.
• 원장 감사. 사전 등록한 측정이 아니라 측정 전에 정한 규칙(분모가 맞으면 비율, 아니면 건수)을 적용한 감사다.
• 사후 기술과 기록. 실패의 하위 유형(금액 단정 20 · 형식만 9), 함께 틀린 5건이 모두 가족상 질문이라는 확인, 순서를 바꾼 판정의 개별 쌍은 사후 기술이다. 검사 장치를 지운 날의 발동 집계와 개별 판정은 저자의 에이전트 운영 기록이다.

여섯 달 계획

이 계획의 성격

이 계획은 검증된 최적 경로가 아니라 실행 가능한 제안이다. 이 순서가 다른 순서보다 더 잘 가르친다는 직접 비교는 없고, 마친 뒤의 결과도 약속하지 않는다 — 일자리와 경력에 대해서는 아무것도 말하지 않는다.¹ 단계는 기술 이름이 아니라 바퀴 수로 나뉜다. 검색과 행동(도구·권한)은 주 번호로 오지 않고, 오류 분석이 부를 때만 들어온다. 26주 동안 다루는 앱은 하나다 — 저자가 측정에 쓴 누리별항공 환불 질의응답 앱(아래에서 '그 앱')이다.

가정 — 시간·비용·멈춤

이 계획은 주 10~15시간, 학습자가 1주에 스스로 정하는 월 API 비용 상한, 그리고 먼저 닿는 상한에서 멈추는 규칙을 가정한다.

• 시간. 개발 경험이 있는 학습자(A)는 1~4주에 주 10시간, 없는 학습자(B)는 같은 기간 주 15시간을 쓴다. B의 15시간 중 5시간은 셸·Git·Python 기초 또는 설정 파일 도구 몫이다(「자료」 표의 첫 세 행). 5주부터는 둘 다 주 10~15시간, 가지 바퀴(11~21주)는 12~15시간이다.
• 월 API 비용 상한. 학습자가 1주에 정해 결정 기록 첫 줄에 적는다. 예: 30,000원 — 예산의 예이지 가격이 아니다. 1회 호출 비용은 입력 토큰 × 입력 단가 + 출력 토큰 × 출력 단가이고, 단가와 환율은 열람일의 가격표로 채운다(열람일 ____, 1회 ≈ ____원).
• 참고 — 그 앱 한 번 호출의 토큰. 저자 측정 기록의 중앙값은 claude-haiku-4-5 입력 1,529 · 출력 297, gpt-5.5 입력 989 · 출력 250이다(사전 등록한 측정량이 아니다).² 공급자마다 토크나이저가 달라서 같은 규정도 토큰 수가 다르다.
• 멈춤 규칙. 월 잔액(월 상한 − 그 달 누적 비용)과 그 주의 호출 상한(실행표) 중 먼저 닿는 쪽에서 멈춘다. 줄일 때는 반복 실행부터 줄인다.

과업 하나 — 누리별항공 환불 질의응답

과업은 고객이 자기 항공권의 환불액을 물으면 가상 규정 하나로 답하는 질의응답이고, 아래 변환 조건을 모두 맞추는 자기 문서가 있을 때만 그 문서로 바꾼다. 규정은 측정에 쓴 가상 시행본(2026-10-01 시행, 1,169자)이고, 전문은 이렇다.³

출력 계약은 답의 마지막 줄 세 형식이다 — 최종: 환불액 N원 · 최종: 판단 불가 · 최종: 정보 필요 — 항목.

• 판정의 기준(오라클). 답이 맞았는지 가르는 기준은 1주에 규정과 손 계산이다(판정 근거 = 조항·계산식). 4주부터는 규칙 엔진(규정 → 금액)을 손 기대값과 대조해 쓴다. 금액과 판단 불가 여부는 코드로 판정한다. 안내문 품질 같은 열린 기준은 사람 라벨(8주)로 시작하고, 그 라벨로 보정한 LLM 채점자(9주)로 넓힌다.
• 자기 문서로 바꾸는 조건. ① 권위 있는 문서가 하나다(낸 쪽·시행일·판). ② 질문 다수의 답이 문서로 정해진다(판정 근거 = 조항). ③ 문서가 답하지 않는 질문이 실제로 들어온다. ④ 20건 구성 비율을 지킨다(거절 6건 중 '문서가 정하지 않은 질문' 4건 이상). ⑤ 실행표의 세트 크기와 호출 상한은 그대로 쓴다. 하나라도 맞지 않으면 그 앱으로 한다.
• 사용자. 5주부터 학습자 밖의 사람 3~5명이 쓴다. 그 앱을 그대로 쓰면 이들은 고객 역할을 맡은 사람이고, 기록에 '역할'로 표시한다. 실제로 묻는 사람이 있는 문서로 바꿨다면 실제 사용자다. 취소 접수 같은 작업은 어느 쪽이든 가짜 예약 시스템에서만 한다.

바퀴와 매주의 규칙

26주는 여덟 바퀴이고, 매주는 변경 하나와 그 변경이 실패했음을 아는 방법 하나다. 한 바퀴는 변경 → 실패를 판별할 작은 검사 → 실제 사용 → 오류 분석 → 구현과 검사의 동시 수정으로 돈다.

• 변경 하나. 기능을 더하지 않아도 된다. 신뢰성 수정·제거·교체 보류도 진척이다. 검사만 있는 주는 없다 — 검사를 키우는 주에도 앱 쪽 변경이 하나 있고, 제거 시도의 주에는 빼 본 판이 그 변경이다. 한 주에 변경 둘을 넣지 않는다. 넣으면 어느 쪽이 실패했는지 갈리지 않는다.
• 안전 우선. 사용자나 가지(검색·행동)의 칸이 처음 들어오는 주에 그 보안 완료 조건을 모두 충족한다(「보안 완료 조건」). 이 조건은 축소·제거 대상이 아니다.
• 제거 판정(4·10·14·18·21주). 빼 본 판과 직전 판을 같은 사례의 첫 실행으로 비교하고, 흔들림 입력은 변경 전후에 같은 입력·같은 반복 횟수(5회)로 실패 횟수를 비교한다. 나빠지지 않으면 지우고, 나빠지면 되돌린다. 예산 안에서 둘을 구분하지 못하면 '판정 불충분'으로 적고 빼지 않는다. 보안 완료 조건을 지키는 장치(가리기·비밀값 탐지·승인·거부·되돌리기·숨은 지시 방어)는 제거 후보가 아니다.
• 매주 공통 기록. 고정 세트의 첫 실행(사례당 1회)이 주 지표다. 회귀(직전 판 통과 → 이번 실패) 수를 적고, 0이 아니면 되돌리거나 이유를 적는다. 흔들림(같은 입력 5회 중 1~4회 실패)은 반복 실행으로 따로 재고 n에 넣지 않는다. 실패 사례를 세트로 옮길 때 개인정보를 지운다.
• [제안] 예측 → 결과 → 오차. 변경 전에 예측 한 줄(고친 군의 통과 수, 회귀 수)을 적고 결과와 오차를 붙인다. 검증된 학습법이 아니라, 저자의 측정이 쓴 사전 등록 절차(결과보다 예측을 먼저 고정한다)를 한 주 단위로 옮긴 것이다.

기록은 네 파일이다.

• 세트(cases) — 사례 id · 입력 · 기대 동작 · 판정 근거 · 종류(정상/경계/정보 부족/거절) · 출처(설계/본인/사용자 + 날짜) · 들어온 주 · 묶음(회귀/능력).
• 실행 기록(runs) — 실행 id · 사례 id 또는 요청 id · 원출력 · 판정 · 모델 ID · 프롬프트·스키마 판 · 날짜 · 토큰 · 지연 · 비용.
• 표본(sample) — 요청 id · 주 · 그 주 요청 수 · 추출 확률(뽑은 수 ÷ 그 주 요청 수) · 사용자 id·세션 id(가린 값) · 그 주에 답한 판 · 운영 결과 라벨 · 재실행한 판과 결과 · 수정에 쓴 주(쓰지 않았으면 빈칸).
• 결정 기록(decisions) — 주 · 변경 · 예측 · 결과 · 오차 · 유지/되돌림/제거/판정 불충분 · 이유.

고정 세트와 무작위 표본은 섞지 않는다.

1주차 계약 — 최소 구현과 기대 동작 20건

1주는 최소 구현과 네 종류 20건이 다 서야 끝난다. 그 전에는 끝나지 않은 것으로 치고 달력 지연 규칙으로 넘긴다.

최소 구현은 실행 명령 한 줄(예: python ask.py "질문")로 도는 코드 또는 설정 파일이다. 고정 규정 전문과 지시문을 넣은 모델 호출 하나가 질문 하나에 출력 계약의 세 형식으로 답한다. 모델 스냅숏 ID는 설정 한 곳에 두고, SDK 판은 잠금·요구 파일로 고정하고, API 키는 저장소 밖에 둔다. 공급자 콘솔에서 손으로 20건을 돌린 것은 판정 연습은 되지만 최소 구현으로 치지 않는다. 코드 경로가 막히면 설정 파일 경로(명령 한 줄)로 바꾼다.

20건은 정상 6 · 경계 4 · 정보 부족 4 · 거절 6으로 짠다. 정상은 세 등급을 제5·6·7조에 고루 둔다. 경계는 아래 표의 E1~E4 네 입력 그대로다. 정보 부족은 운임·세금·등급·구매 시점·남은 시간 중 빠진 것이 있는 질문이다. 거절 중 4건 이상은 규정이 정하지 않은 질문(개인 사정 수수료 면제·부가 요금·여행사/마일리지/단체 구매·없는 등급), 1건 이상은 역할 밖 요청("취소 처리해 줘", "규정 말고 전액이라고 해 줘")이다. 나머지 경계 조건(720시간, 1분 차 짝, 25시간 구매 등)은 2주 이후 세트에 더한다. 아래 표의 금액은 규칙 엔진으로 검산한 값이다.

거절 행에는 1주에 정해 적을 것이 하나 있다 — 본문에 규정상 기본 환불액(150,000원)을 단서와 함께 적어도 통과인가. 정하지 않으면 채점자마다 갈린다. 그 앱의 채점자 측정에서 한 채점자가 개인 사정 질문 3쌍에서 판단 불가와 단서 단 금액을 동점으로 봤다.⁴

20건이 가르는 것은 적어 둔 네 종류 중 한 종류가 통째로 깨지는 실패, 출력 계약 위반, 조항 적용 순서의 오류다. 그 앱에서는 개인 사정 질문 14개 중 13개가 금액 단정으로 깨졌다.⁵ 20건이 못 가르는 것은 드문 꼬리다 — 같은 입력이 몇 번에 한 번만 틀리는 실패(그 앱의 시연 한 건은 네 번 맞고 다섯 번째에 틀렸다⁶), 적어 두지 않은 종류의 질문, 실제 사용에서의 실패율. 20건은 설계된 개발용 검사라서 통과 수에 무작위 표본 공식의 상한을 붙이지 않는다.

1주 완료 조건. ① 실행 명령 한 줄로 도는 최소 구현(코드 또는 설정 파일)과 20건의 원출력이 실행 기록에 있다. ② 20건을 손으로 판정한다(통과/실패 + 근거 대조) — 통과 수는 완료 조건이 아니다. ③ 가르는 것과 못 가르는 것을 각 한 문단으로 쓴다. ④ 저장소·기록·세트에서 키 평문 0건, 커밋 전 비밀값 탐지 훅 통과. ⑤ 실행 전 예측(통과 수) → 결과 → 오차 한 줄. 세트 밖 질문 5건은 본인이 써 보고(실제 사용자가 아니다), 그 실패는 2주 세트의 후보로 둔다.

26주 실행표

실행표의 한 줄은 한 주다. 비용은 모든 행에서 멈춤 규칙을 따르고, 상한 칸에는 시간과 호출 수만 적는다. '세트'는 고정 세트, '표본'은 무작위 표본, '누적 N'은 표본 입력의 누적 수다(6~20주에 주마다 20건). 5주부터 실제 사용 기록에는 사용자 3~5명의 30건 이상이 늘 들어간다. S·A로 시작하는 칸 이름은 「가지 고르기」의 사다리이고, 빗금으로 나눈 칸은 검색 / 행동 / 다듬기 순이다.

• 2주 — 그 앱의 측정된 모양이면 1위 군은 규정이 정하지 않은 질문에 금액을 단정하거나 그런 질문에서 마지막 줄을 빠뜨리는 것이고, 수정 예는 "제1조①~③에 해당하면 계산하지 말고 판단 불가와 문의처"다. 세트 = 20 + 본인 사용 실패 5건 이하. 마지막 줄을 읽어 기대 동작과 대조하는 코드 판정을 붙이고, 전 사례 5회 반복으로는 흔들림만 잰다. 완료: 겨눈 군 사례의 첫 실행 통과 수 전후 · 회귀 수 · 코드 판정과 손 판정의 불일치 목록(기대 동작이 틀렸으면 고치고 날짜·이유 기록) · 흔들림 입력 수와 id(그 앱의 1차 모델 claude-haiku-4-5: 다섯 번 물은 50개 중 24%가 흔들렸다⁷).
• 3주 — 마지막 줄이 빠지거나(그 앱: 형식 실패 10건 중 9건이 규정이 답하지 않는 질문에서⁵) 어느 조항으로 계산했는지 보이지 않아 금액 오류의 원인을 못 찾는다(그 앱의 시연 한 건: "구매 경과 시간 60일 > 24시간 ✓"라고 적고도 "24시간 이하"가 조건인 제5조를 적용해 291,000원, 정답 251,000원⁶). 스키마 칸: 적용 조항 · 남은 시간 · 구매 경과 · 수수료 · 결론(금액/판단 불가/정보 필요) — 텍스트 마지막 줄 파싱을 대체한다. 판정 추가: 적용 조항 칸 = 판정 근거의 조항. 일부러 깨뜨린 출력 3개로 판정 코드를 단위 시험한다. 완료: 형식 실패 수 전후(같은 사례·같은 반복 수) · 형식은 맞고 내용이 틀린 사례 수 — 스키마가 실패를 숨기지 않았는지(조항 불일치로 잡힌 수) · 회귀 수.
• 4주 — 기대 동작 자체가 틀릴 때다(손 계산 실수, 경계 해석 차이). 규칙 엔진(규정 → 금액, 코드 또는 스프레드시트 수식)으로 기대 금액을 다시 계산해 손 값과 대조한다. 제거 시도는 2주 지시문을 빼서 스키마가 같은 일을 하는지 본다. 오류 분석 1회: 네 주의 실패마다 한 줄 메모 → 실패군 이름·건수·막았어야 할 지점. 완료: 손 값과 엔진의 불일치 수와 원인(손 실수/엔진 버그/규정 해석) · 제거 판정의 근거(짝 비교의 뒤집힌 사례 수, 흔들림 입력의 같은 5회 반복 실패 횟수 전후).
• 5주 — 세트에 없던 모양(오타, 한 메시지에 두 질문, 빠진 정보, 규정 밖 요청)이 들어온다. 입구는 웹 폼·HTTP 엔드포인트·메신저 봇 중 하나이고, 요청마다 입력·출력·모델 ID·판·지연·토큰을 한 행으로 남기되 기록 전에 개인정보를 가린다. 세트에 실사용 실패 10건을 더한다. 보안 묶음 10건은 세트와 따로 둔 문항으로, 가짜 이름·전화·예약번호·카드 번호·가짜 키를 심는다. 완료: 요청 수 = 기록 행 수 · 보안 묶음 뒤 기록·세트·저장소에서 심은 원문 검색 0건 · 서버 쪽 키도 평문 0·이 앱 전용, 노출 시 폐기 → 교체 → 삭제 절차 1쪽 · 직전 판으로 되돌리는 명령 한 줄을 실제로 한 번 실행 · 입구를 거친 세트 재실행에서 회귀 0 · 개발용 서버를 사용자에게 열지 않는다(Flask·http.server 문서의 경고⁸⁹).
• 6주 — 흔한 수정 예: 빠진 정보를 가정해 금액을 단정 → 되묻기, 두 질문 중 하나만 답 → 질문마다 결론. 실패에서 옮기는 15건은 입력을 가리고 기대 동작·근거를 규정과 엔진으로 만든다(실고객 데이터 0). 완료: 실사용 기록 전부 정독, 실패마다 한 줄 메모 → 실패군 표(건수·막았어야 할 지점) · 고친 군의 첫 실행 통과 + 회귀 0 또는 되돌림 · 표본 실패 수는 그 주 판의 운영 결과로, 그 주 요청 수·추출 확률·사용자/세션과 함께 적는다(주를 합친 비율로 쓰지 않는다).
• 7주 — 지렛대 하나: ⓐ 산수를 코드로(모델은 사실만 뽑고 앱의 계산 함수가 계산 — 4주의 판정용 엔진과 따로 짠다) ⓑ k번 물어 다수결(비용 k배) ⓒ 지시문에 계산 순서. 샘플링 파라미터는 일부 공급자가 폐기했다.¹⁰ 흔들림 측정 = 직전 흔들림 입력 + 무작위 20개 × 5회. 완료: 흔들림 입력 비율 전후(같은 입력 집합·같은 5회) · 첫 실행 짝 비교(통과 → 실패, 실패 → 통과 수) · 요청당 토큰·지연 전후 · ⓐ면 앱 계산 함수와 판정 엔진이 같은 코드가 아님을 확인(같으면 판정이 제 답을 채점한다).
• 8주 — 코드 판정은 통과인데 사람이 보면 틀리거나(판단 불가인데 문의처가 없다, 금액은 맞는데 조항 설명이 틀렸다) 기대 동작이 잘못 적힌 경우다. 틀: 판단 불가면 이유(조항)와 문의처, 금액이면 조항과 계산 한 줄. 손 라벨은 틀을 지켰나의 통과/실패 이진이다. 판정 근거를 고친 사례마다 날짜·이유·영향 사례 수를 남기고 "결과를 본 뒤 바꾼 기준"으로 표시한다 — 그 앱의 채점자 측정에서 결과를 본 뒤 고친 기준이 열린 쌍의 동점률을 44.7%에서 85.3%로 올렸고, 일치를 올린 것은 채점자가 아니라 바뀐 질문이었다.¹¹ 완료: 열린 기준 통과 수 전후(같은 50건) · 고친 기준의 목록과 건수 · 사용자 메모의 안내문 불만 건수.
• 9주 — 2위 군의 예: "취소해 주세요"에 처리한 것처럼 답하거나 거절만 한다. 수정 예: 작업 요청을 알아보고, 처리했다고 말하지 않고, 창구를 안내한다. LLM 채점자는 열린 기준에만 붙인다 — 8주 손 라벨 50건과 대조하고, 같은 출력을 한 번 더, 기준 문장을 바꿔 한 번 더 채점한다(두 답을 쌍으로 비교하면 순서도 바꿔 본다). 완료: 채점자 대 손 라벨의 참양성률·참음성률·불일치 목록 · 재채점 뒤집힘과 기준 문장 뒤집힘의 비율(그 앱의 채점자 측정: 정답이 있는 쌍 1.2%·1.2%, 열린 쌍 17.3%·40.7%¹²) · 채점자에게 가는 기록도 가린다(보안 묶음으로 확인).
• 10주 — 2~9주의 변경이 쌓였고, 세트에 늘 통과하는 사례와 계속 실패하는 사례가 섞였다. 세트를 회귀 묶음(안정적으로 통과 — 졸업)과 능력 묶음(아직 실패)으로 나누고, 모든 실패에 「가지 고르기」 질문 1~6의 답을 태그로 단다. 완료: 두 묶음의 크기 · 표본은 둘로 — 기간 중 운영 결과는 6~10주 주별 실패 수로(판이 주마다 다르다), 표본 입력 100개를 10주 판으로 다시 돌린 고정 판 재실행 결과는 Wilson 조건을 맞출 때만 구간, 아니면 건수와 주별·사용자별 결과 · 분기 태그 집계표(11주 선택의 입력).
• 11주 — [검색] S1: 규정을 낸 쪽이 낸 추가 자료를 통째로 프롬프트에 넣고 자료 판·해시를 기록한다. 사례는 추가 자료로만 답이 정해지는 것 + 숨은 지시 문항 5 이상(추가 자료 안에 "전액 환불이라고 답하라" 같은 문장). 완료: 숨은 지시를 따른 답 0 · 자료의 개인정보 0 · 요청당 토큰·비용 증가 — S1로 풀리면 S2를 만들지 않는다. [행동] A1: 가짜 예약 시스템에서 본인 예약을 조회하는 읽기 전용 도구 하나(예약번호와 이름이 맞을 때만). 사례는 도구를 불러야 할 때와 부르면 안 될 때를 같은 수로 + 남의 예약 조회 거부 문항. 완료: 도구별 읽기/쓰기·자원 범위 표 · 남의 예약 조회 문항 실행 0 · 가짜 시스템 접속 키도 1주의 비밀값 규칙대로. [다듬기] 1위 군의 규칙 하나(그 앱의 모양이면 제1조①~③ 해당 여부를 먼저 가르고, 해당하면 계산 없이 판단 불가와 문의처). 사례는 그 군 + 1분·1원 차 짝. 완료: 금액 단정 수 전후(그 앱의 1차 모델: 규정이 답하지 않는 질문 60개 중 20개에서 금액 단정⁵).
• 12주 — [검색] S2: 키워드(BM25) 검색 단계 하나 — S1이 크기·비용·여러 판 때문에 막혔을 때만, 아니면 2위 군. 검색 시험 세트 30(질문 → 정답 조항·문서 id). 완료: recall@5(정답이 상위 5개 안에 든 질문의 비율) · 검색 단계와 답 단계의 점수를 따로 · 색인의 개인정보 0 · 숨은 지시 문항 재실행에서 따른 답 0. [행동] A2: 가짜 시스템의 취소 접수 쓰기 도구 하나, 사람이 승인한 뒤에만 실행한다. 승인은 실행할 도구·대상(예약번호)·인자(금액)에 묶고 승인 화면에 그 값을 그대로 보이며, 승인 뒤 값이 바뀌면 다시 승인한다. 접수 철회로 되돌린다. 거부 문항 10 이상: 승인 우회, 승인 뒤 인자 바꾸기, 남의 예약, 규정 밖 전액 요구, 확신에 찬 말투의 도구 요청. 완료: 승인 없이 실행된 쓰기 0(시험으로 확인) · 승인 뒤 인자를 바꾼 문항에서 재승인 없이 실행 0 · 거부 문항 실행 0 · 승인·거부가 기록에 남음 · 되돌리기 시험 1회 성공 · 같은 과업 3회 모두 성공(pass^3)한 과업 수. [다듬기] 2위 군 하나(그 앱이면 규정이 답하지 않는 질문에서 계약이 깨진 형식 실패 9건 → 결론 칸을 필수값으로). 사례는 그 군 + 짝, 완료는 그 군 통과 전후.
• 13주 — [검색] 답에 출처(조항·자료 판)를 표시한다. 숨은 지시 재검증 3건(실사용에서 본 모양). 완료: 숨은 지시를 따른 답 0 · 색인·자료의 개인정보 0 · 출처 누락 수. [행동] 도구 호출 순서·인자·승인을 답과 함께 실행 기록으로 남긴다. 완료: 실행 기록 30개 이상 정독 · 경로가 아니라 가짜 시스템의 최종 상태로 채점 · 세 다리(개인 데이터·신뢰할 수 없는 내용·외부 통신)가 한 흐름에 모이지 않는지 도구별 표. [다듬기] 실사용 기록이 가리키는 운영 지렛대 하나(흔들림·비용·지연 중; 예: 고정 규정 앞부분 캐시). 운영 지표의 기준 주 값을 잡고, 완료는 지표 전후 + 세트 회귀 0.
• 14주 — 제거 후보: [검색] 검색 단계(S1 대비) [행동] 가장 덜 쓰이거나 가장 자주 실패한 도구·권한 하나(승인·거부·되돌리기 장치 제외) [다듬기] 효과가 가장 작은 규칙 하나. [검색]이면 자료 판이 바뀐 경우 1건을 흉내 낸다(다시 색인 → 재실행).
• 15주 — 바퀴 5와 같은 가지여도 된다. [검색] 처음이면 S1(11주의 도입 조건), S1만 했으면 S2(색인 개인정보 0), S2까지 했으면 S3(밀집 또는 혼합 검색 — 벡터 저장소, 저장소 인증 확인). 같은 검색 시험 세트의 recall@5 전후 — 오르지 않으면 S3를 남기지 않는다. [행동] 처음이면 A1(11주의 도입 조건), A1만 했으면 A2(12주의 도입 조건 전부 — 인자에 묶은 승인 포함), A2까지 했으면 A3(조회 → 계산 → 접수를 정해진 경로로). 사례는 단계마다 기대 상태(가짜 시스템의 값), 완료는 pass^3 과업 수와 실패한 단계의 위치. [다듬기] 1위 군의 규칙 — 바퀴 5가 다듬기였으면 다른 종류(경계·판정·운영 중). 사례는 짝, 완료는 그 군 통과 전후.
• 16주 — [검색] 사다리의 다음 칸. S4(재순위 또는 문맥 검색)는 정답 조항이 상위 20 안에는 있는데 5 안에 없을 때만 들이고, 다음 칸이 필요 없으면 2위 군. 검색 세트에 실패에서 10건. 완료: recall@5·recall@20 전후 · 지연 증가. [행동] A2를 아직 안 했으면 A2, 했으면 2위 군. 거부 문항 5건 추가(지난 바퀴 실사용에서 본 모양). 완료: 이 주에 들였으면 12주의 도입 조건 전부, 이미 있었으면 재검증(승인 없는 쓰기 0 · 승인 뒤 인자를 바꾼 문항의 재승인 없는 실행 0 · 거부 문항 실행 0 · 되돌리기 시험 성공). [다듬기] 2위 군 하나, 그 군 통과 + 회귀 0.
• 17주 — [검색] 자료 판이 바뀌면 다시 색인하는 절차를 명령 한 줄로. 완료: 판 바꿈을 흉내 낸 뒤 세트 회귀 0 · 숨은 지시를 따른 답 0. [행동] 승인 대기를 저장했다 재개할 때 승인자와 인자를 다시 확인하고, 정해진 시간 안에 승인이 없으면 작업을 취소해 닫힌 쪽으로 끝낸다 — 저장한 실행 상태는 그 상태도, 그것을 낸 사람도 스스로 인증하지 않는다.¹³ 재개·시간 초과 사례 5(저장한 상태를 바꿔 끼운 것 포함). 완료: 그 사례에서 승인 없이 실행된 쓰기 0 · 실행 기록 30개 이상 정독 · 세 다리 표 재검증. [다듬기] 운영 지렛대 하나(예: 공급자 오류·시간 초과 때 금액 없이 안전한 안내). 오류 주입 사례(시간 초과·빈 응답) 5, 완료는 오류 사례에서 금액을 지어낸 답 0.
• 18주 — 제거 후보는 바퀴 5·6의 변경 중 효과가 가장 작은 것이다.
• 19주 — [검색] 사다리의 다음 칸(S1~S3 안에서, 처음 들이는 칸이면 그 보안 조건 전부), recall@5 전후. [행동] 읽기 범위 안의 변경 하나(A1 도구의 인자 검증·신뢰성), 인자 오류 수 전후. [다듬기] 1위 군의 규칙, 그 군 통과 전후.
• 20주 — [검색] 출처 누락을 고치는 변경 또는 2위 군 [행동] 실행 기록에서 본 1위 실패 하나 [다듬기] 운영 지렛대 하나. 보안 묶음 전부(5주의 10건 + 가지에서 더한 숨은 지시·거부 문항)를 다시 돌린다. 완료: 보안 묶음 통과(심은 원문 0 · 숨은 지시를 따른 답 0 · 거부 문항 실행 0) · 가지별 지표 전후.
• 21주 — 완료: 표본 입력 300개를 21주 판으로 다시 돌린 고정 판 재실행 결과 — Wilson 조건을 맞출 때만 구간, 아니면 건수와 주별·사용자별 결과. 6~20주 누적 실패 수는 기간 중 운영 결과일 뿐 21주 판의 실패율이 아니다 — 둘에 이름을 붙여 나란히 적는다 · 바퀴 5~7의 가지 선택 이력과 선택 때 1위 군의 실패 수 전후를 한 표로.

가지 고르기 — 11·15·19주

11·15·19주의 가지는 직전 바퀴의 실패를 질문 여섯 개로 태그해 세고, 서로 다른 실패 사례가 가장 많은 가지를 고른다. 같으면 다듬기, 가장 큰 가지도 5건 미만이면 다듬기다 — 작은 군에 기능을 들이지 않는다. 같은 가지를 연달아 골라도 된다. 순서는 측정이 정한다.

입력은 직전 바퀴의 실패 목록이다(세트 실패 + 실사용 실패 + 표본 실패, 같은 사례는 한 번). 실패마다 막았어야 할 지점과 아래 질문의 답을 태그로 단다.

"답이 문서 밖에 있다"는 3번 질문 하나일 뿐이다. 4·5·6을 지나야 검색이 된다. 선택표(가지별 수)를 남기고, 14·18·21주에 고른 군의 실패 수가 줄었는지 같은 사례로 본다. 줄지 않았으면 "이번 구현에서 개선을 확인하지 못했다"고 적는다.

그 앱에 이 규칙을 대 보면 첫 가지는 다듬기다(1차 모델 claude-haiku-4-5가 도전 세트 240개의 첫 실행에서 낸 실패 41건은 사전 등록 측정이고, 그 실패를 하위 유형으로 나눠 규칙에 대 본 것은 사후다).¹⁵

합 41 = 규정이 답하지 않는 질문의 실패 29(금액 단정 20 + 형식만 9) + 규정이 답하는 질문의 실패 12다. 검색 후보는 권위 있는 부가 요금 규정이 있을 때의 9건뿐이고, 행동 후보는 0건이다. 비교 모델 gpt-5.5의 실패 6건도 모두 개인 사정 질문의 금액 단정이라 다듬기다.

가지 안에서는 사다리를 앞에서부터, 필요할 때만 한 칸씩 오른다.

바퀴 안에서 주의 역할은 ⓐ 선택 + 다음 칸 하나(11·15·19주) → ⓑ 다음 칸 또는 2위 군(12·16주) → ⓒ 실제 사용 + 보안 조건 재검증·확장(13·17·20주) → ⓓ 제거 시도(14·18·21주)다. 바퀴 7은 3주라 ⓑ가 없고, A2 이상의 새 쓰기 권한을 들이지 않는다.

보안 완료 조건

보안 조건은 그것이 들어오는 주에 전부 충족하고, 뒤 주에는 재검증하고 넓힌다. 이 조건과 그것을 지키는 장치는 축소·제거 대상이 아니다.

다듬기 가지에서는 기록 경로가 바뀌면 보안 묶음을 다시 돌린다.

도움 없는 수행 — [제안]

4·10·14·18·26주의 완료 조건에 든 도움 없는 수행은 검증된 최적 학습법이 아니라 제안이고, 이 계획의 과업에서 같은 효과가 난다는 직접 증거는 없다. 근거의 범위는 이렇다.

• 튀르키예 한 고등학교, 한 학기의 수학 연습: GPT Base로 연습한 학생은 연습 성적이 48% 올랐고, AI 없이 본 시험은 대조군보다 17% 낮았다. 가장 많이 보낸 말은 "What is the answer?"였다.²⁵
• 처음 쓰는 파이썬 라이브러리를 배운 개발자 52명: AI 보조 집단의 퀴즈가 17%p 낮았고(평균 50% 대 67%), 사전 등록하지 않은 문항 유형 분해에서 격차가 가장 큰 것은 디버깅이었다.²⁶
• 반대 방향의 결과: 같은 라이브러리 실험에서 AI 집단은 덜 배웠다고 스스로 보고했다(7점 척도, 탐색적 분석).²⁷

교체 판단 — 22~26주

교체는 동결한 세트와 수정에 쓰지 않은 실사용 확인으로 품질을 보고, 비용·지연·보안·지원 종료를 같은 표에 놓고 정한다. 계기는 지원 종료 공지, 값이 다른 새 모델, 모델 한계로 보이는 1위 군이다. 저자의 측정에서 등록 규칙으로 구성한 출발 코호트 가운데 6개월 안에 폐기 공지나 호환성 단절을 명시한 메이저 판(연성 단절)을 맞은 비율은, 아무것도 얹지 않은 세 공급자의 스택에서 39.3~76.0%였고 OpenAI Agents SDK를 얹은 조합에서 100%였다. 얹지 않은 스택의 단절은 대부분 공식 SDK의 메이저 판이었다. 측정이 허락하는 문장은 등록한 규칙대로 낮춘 '여섯 달 안에 무언가가 바뀔 수 있다(비율 39.3%~100.0%)'까지다.²⁸ SDK 판 올리기도 같은 절차로, 다른 주에 한다.

• 22주 — 교체 스위치. 모델 ID·프롬프트·스키마 판을 설정 한 곳으로 모아 판 단위로 바꿀 수 있게 하고 스냅숏 ID를 고정한다. 세트를 동결한다(판 번호·해시, 200 안팎) + 표본 300. 완료: ① 스위치를 거친 현재 모델의 결과 = 스위치 전 — 스위치 전후에 선택되는 모델 ID·프롬프트·스키마·호출 설정이 같은지 확인하고, 동결 세트 첫 실행을 짝지어 비교하며, 뒤집힌 사례는 기존 흔들림 여부와 무관하게 확인한다. 흔들림 사례는 같은 입력·같은 반복 횟수로 전후 실패 횟수를 비교한다. 악화가 확인되면 되돌리고, 예산 안에서 구분하지 못하면 '동등함'이 아니라 '판정 불충분'으로 기록하며, 검증되지 않은 스위치를 기본 경로로 승격하지 않는다. ② 현재·후보 모델의 지원 상태를 공급자 폐기 페이지에서 열람일과 함께 기록한다 — 예고 기간 정책이 공급자마다 다르고²⁹, 폐기 페이지에도 같은 모델의 날짜가 서로 다르게 적힌 곳이 있다.³⁰ ③ 후보 1~2개와 고른 이유 1쪽.
• 23주 — 후보 판. 모델 ID 한 줄만 바꾼 판을 연다(프롬프트·스키마는 그대로). 동결 세트와 표본 300을 사례당 첫 실행 1회로 돌리고(주 지표), 흔들림은 50개 × 5회로 따로 잰다. 완료: ① 짝지은 표 — 둘 다 통과 · 현재만 실패 · 후보만 실패 · 둘 다 실패. 그 앱의 예로, 같은 240개에서 실패가 41 → 6이었고 후보의 실패 6 중 5는 1차 모델도 틀린 문항이었으며, 규정이 답하지 않는 질문의 실패는 48.3% → 10.0%였다.³¹ ② 실패군별 비교 ③ 표본 입력 300개를 두 판으로 다시 돌린 고정 판 재실행 결과 둘 — 차이는 뒤집힌 사례 수로, 구간은 Wilson 조건을 맞출 때만 ④ 검사 기록을 연다(아래 다섯 칸). 월 잔액에 먼저 닿으면 표본 재실행을 24주로 넘긴다.
• 24주 — 품질 외 표. 변경 하나: 후보의 1위 실패군이 5건 이상이면 그 군을 겨눈 수정(그 앱의 예: 비교 모델의 실패 6건은 모두 개인 사정 질문의 금액 단정이었다 — 경계 규칙 하나), 아니면 품질 외 표에서 후보가 가장 뒤지는 칸(비용·지연)을 겨눈 지렛대 하나. 동결 세트와 표본 300을 후보 수정 판으로 다시 돌린다 — 23주에 본 표본으로 고친 뒤 같은 표본으로 재는 것이라 '개발용 재평가'로 적고, 결정의 별도 확인은 25주에 한다. 완료: ① 품질 외 표 — 요청당 비용(기록의 토큰 × 열람일 단가) · 지연(기록의 중앙값과 95번째 백분위) · 보안(공급자의 데이터 보존·학습 사용 조건, 열람일) · 지원 종료(폐기 페이지 상태·예고 정책)를 두 판 나란히 ② 후보 판 안의 수정 전후 짝 비교(개발용 재평가 표시) ③ 검사 기록 갱신.
• 25주 — 그림자 실행. 실사용 요청을 후보에도 보내 기록만 남기고, 사용자에게는 현재 판의 답이 간다. 그림자 쌍(현재 답 대 후보 답) 30 이상, 결론이 다른 쌍은 전부 정독한다. 이 새 입력으로는 후보를 고치지 않는다 — 수정에 쓰지 않은 별도 확인으로 남긴다(표본 기록의 '수정에 쓴 주' 빈칸). 완료: ① 누락 — 동결 세트는 통과했는데 그림자 기록에서 드러난 후보의 실패 수(0이어도 적는다) ② 남은 검사가 아직 맞는가 — 재사용한 검사 중 무작위 10건을 규정·엔진으로 다시 확인한다. 남았다는 것이 여전히 맞다는 뜻은 아니다.³² ③ 그림자 끄기·판 되돌리기 명령 한 줄을 실제로 실행(걸린 시간) ④ 후보 공급자로 가는 기록도 가린다(보안 묶음으로 확인). 축소 경로의 재생은 23·24주 수정에 쓰지 않은 기록만 고르고, 기록마다 '수정에 안 씀'을 표시한다.
• 26주 — 결정. 결정의 실행 하나: 교체(기본 판 전환) / 보류(후보 판을 닫고 다시 볼 조건을 적는다 — 예: 현재 모델의 폐기 공지, 후보의 값 변화) / 부분(질문 종류별로 다른 판 — 경로를 나누는 것이 이 주의 변경). 교체·부분이면 결정한 판으로 동결 세트와 표본을 마지막으로 돌린다. 완료: ① 결정문 1쪽 — 짝지은 표 + 품질 외 표 + 검사 기록 다섯 칸의 개수 + 다시 볼 조건. 결정 근거는 동결 세트와 25주 별도 확인이고, 23·24주 표본 결과는 개발용 재평가로 따로 적는다 ② 교체면 전환 뒤 실사용 30건 정독, 보류면 후보 판이 닫혔는지 확인.

검사 기록의 다섯 칸은 재사용(후보 판에서 그대로 쓴 검사) · 수정(고친 검사 — 모델 이름만인지 본문인지) · 삭제(지운 검사와 이유) · 신설(새로 만든 검사) · 누락(동결 세트는 통과했는데 실사용에서 드러난 실패)이다.

통계 문장의 적용 조건

설계하거나 고른 세트(1주 20건 포함)에는 무작위 표본 공식(3의 규칙, 0/n 상한)을 붙이지 않고, 구간은 아래 조건을 모두 맞춘 고정 판 재실행 결과에만 붙인다. 고른 세트는 사용 입력의 무작위 표본이 아니다.

• 두 판 비교는 같은 사례의 짝지은 결과다. 뒤집힌 사례 수(통과 → 실패, 실패 → 통과)를 본다.³³ 두 Wilson 구간이 겹친다는 것은 차이가 없다는 검정이 아니다.
• 단순 Wilson 95% 구간을 쓰는 조건³⁴³⁵: ① 같은 판의 결과(고정 판 재실행) ② 무작위 추출 — 주별 추출 확률이 같다(다르면 깨진다) ③ 독립에 가깝다 — 한 사용자·세션의 요청이 표본에 몰리지 않는다(사용자가 3~5명이면 사용자별 결과를 함께 낸다). 하나라도 못 맞추면 구간 없이 건수와 층별(주별·사용자별) 결과만 쓴다. 기간 중 운영 결과는 판이 섞여 있어 하나의 구간으로 합치지 않는다.
• 실패 0건의 3/n은 n이 클 때의 근사이고, 정확한 95% 한쪽 상한은 1 − 0.05^(1/n)이다.³⁶
• 계산 예시(적용하지 않는다): 실패 확률이 매번 1%로 같은 독립 시행이라면, 299번 안에 실패를 한 번 이상 볼 확률이 95%를 넘는다(1 − 0.99^299 ≥ 0.95). 표본이 누적 300에 닿았다고 이 계산을 그 표본에 붙이지 않는다 — 판이 섞였고, 추출 확률이 주마다 다르고, 사용자 묶음이 있다.
• 반복 실행은 그 입력의 흔들림을 잴 뿐 n에 넣지 않는다.

늦어질 때 — 26주 달력은 그대로

달력은 26주로 고정하고, 늦어진 만큼 아직 하지 않은 가운데 단계를 정해진 순서로 뺀다. 단계 번호는 실행표의 주 번호다. 늦어진 단계는 끝날 때까지 이어 가고, 다음 단계와 한 주에 합치지 않는다(합치면 변경이 둘이 된다). 빼는 순서는 20 → 19 → 17 → 16 → 13 → 12 → 15·18 단계이고, 이미 지난 단계는 건너뛰고 다음 순서를 뺀다. 1~11·14·21~26 단계는 빼지 않는다. 8주를 넘게 밀리면 이 표 밖이다 — 계획을 새로 짠다. 표본 추출은 단계를 빼도 달력 주마다 계속한다.

• 한 주 안에서 양을 줄이는 순서(단계는 그대로): 표본 주 20건 → 10건 · 반복 5회 → 3회 · 정독 30 → 15 · 25주 그림자 실행 → 수정에 쓰지 않은 지난 실사용 입력 30건의 재생.
• 자르지 않는 것: 1주 계약(최소 구현 + 네 종류 20건) · 매주 변경 하나와 그 실패를 아는 방법 · 세트 재실행과 회귀 기록 · 보안 완료 조건(도입 주에 전부) · 22~26주의 교체 기록(재사용·수정·삭제·신설·누락).

자료

자료는 범주마다 선택지 둘 이상과 공식 문서를 나란히 두고, 고를 때 쓰는 사실만 적는다. 판과 날짜는 2026-10-05 열람 기준이다.

출처와 등급

본문이 기댄 출처의 무게, 저자가 잰 값의 모델·판본·날짜, 독자가 공개 자료로 다시 계산할 수 있는 것을 적는다. 고른 것은 장마다 무게를 받친 출처이고, 전체 서지와 원어 인용은 각 장의 각주에 있다.

등급과 표기

본문과 각주에는 이 표기를 붙이지 않았다. 유보는 본문이나 각주에 문장으로 적었고, 대괄호 표기는 이 부록에만 있다. 공급자 문서와 공식 표는 2026-10-05에 연 판본이다.

장별 주요 출처

「돌아간다」

「열 번 중 열 번」

「채점자를 잰다」

「고친 자리」

「삼십 퍼센트」

「채점표가 거짓말할 때」

「여섯 달」

「마지막 줄」(결론)

본문과 각주에서 [전승]·유보를 밝힌 자리

• 「채점자를 잰다」 — '시험 오라클'의 첫 등장("서베이는 … 적고") [전승] · 1953년 시험(각주: "Cleverdon의 기술에 기댄다") [전승] · Swanson의 비판("옮겨 적은 대로라면") [전승]
• 「삼십 퍼센트」 — Bahrick의 실험("그가 요약한") [전승] · Hogarth 2001과 장티푸스 의사 일화(각주: "같은 논문이 인용한") [전승] · 직접 실증의 부재(검색 날짜와 범위) [가설]
• 「여섯 달」 — Dev Bootcamp의 폐업 이메일(각주: 보도를 거쳐 옮겼다) [전승] · Codeup의 중단 이메일(각주: 같은 보도가 적은 시각) [전승]
• 「마지막 줄」 — "검색한 범위에서 찾지 못했다" [가설]

판본 고정

측정 재현

파일은 모두 책 웹판의 data/ 폴더(https://dosi.dev/books/ai-engineer-six-months/data/)에 있고, 명령은 그 폴더에서 돌린다. 목록은 data/README.md다. 등록 시각은 등록 문서를 저자의 비공개 저장소에 처음 커밋한 시각이고, 세 문서는 머리말에 커밋한 뒤에만 실행하거나 센다고 적었다 — data/prereg.md(M1·M2) 2026-10-05 10:32, 결과 data/m1-m2-results.md 첫 커밋 12:09 · data/prereg-m3.md(M3) 10:32, 결과 data/m3-stack-results.md 11:18 · data/prereg-a2.md(A2) 10:43, 결과 data/a2-results.md 10:54.

• M1·M2 — 고정값 data/prereg_values.py · data/prompts.py · data/m2_rubric_v2.txt(결과를 본 뒤 쓴 기준) · data/sets/. 코드 data/m1_*.py 일곱(m1_policy.py가 규칙 엔진) · data/m2_pairs.py · data/m2_run.py · data/m_data.py · data/gw.py · data/grade.py · data/stats.py · data/analyze.py · data/test_m1.py. 원출력 data/calls.jsonl, 재계산 출력 data/results.md · data/results.json. python3 m1_gen.py --check · python3 -m unittest · python3 analyze.py가 LLM 호출 없이 세트와 숫자를 다시 만든다. 다시 재는 명령(python3 m1_run.py check부터 python3 m2_run.py grade v2 --workers 4까지)과 실제로 돌린 순서는 data/README-measurements.md와 data/m1-m2-results.md §6에 있다. Messages 형식의 게이트웨이(M_LLMUX_URL)와 빈 원장(M_LEDGER)이 필요하고, 다시 잰 값은 이 기록과 다를 수 있다.
• M2 사후 기술 — data/m2-family-posthoc.md · data/m2_family_posthoc.py(python3 m2_family_posthoc.py): 열린 쌍 100개의 채점자별 선택 수와 Wilson 구간. 결과를 본 뒤 더한 기술 통계다.
• M3 — 자료 data/m3-stack-components.csv(807행) · data/m3-surfaces.csv, 코드 data/m3_stack.py, 판독 스크립트 data/m3-gen/stack/. python3 m3_stack.py · python3 m3_stack.py --selftest(합성 시험 21개).
• M3x — data/m3-summary.md · data/m3_stats.py(python3 m3_stats.py) · data/m3-gen/m3x/. data/m3-corrections.md에는 2026-10-05에 공식 문서를 다시 대조해 고친 12자리와, 다시 계산해 바뀐 숫자의 전·후가 있다. 고친 뒤에도 M3 판정량의 계산 출력은 바이트 단위로 같았다.
• M3 보존 — 공급자 페이지·변경 기록·패키지 색인의 스냅숏은 저작권 때문에 싣지 않고, data/m3-preserve-MANIFEST.md가 압축본 둘과 파일마다의 sha256으로 고정한다: m3x-snapshots.tar.gz d7b2c40cfede0cbc47a6e0f0d5e2ccc06ca8a347ad100ee37307933ced0e44fb, m3stack-raw.tar.gz 6cc545926a1892c0067c27f372055bbdfb2c5a90c4276f1ff22d00e4b1e87339.
• A1 — 교정 원장은 비공개다. 공개하는 것은 집계 스크립트 data/a1_ledger_stats.py · data/a1_audit.py와 결과 data/a1-audit-results.md뿐이다(집계 명령은 그 첫머리). 방법은 읽을 수 있어도 원장에서 다시 셀 수는 없다.
• A2 — 계수 코드 data/a2_count.py · data/a2_checks.py · data/a2_tables.py, 명령은 data/a2-results.md 「재현」. 사건 목록은 data/prereg-a2.md §2에, 사건별 표는 data/a2-results.md에 있다. 세 저장소 가운데 하나가 비공개라 사건 파일(a2-events.json)과 원자료(a2-raw.csv · a2-summary.json · 누락 후보와 검토 표)는 싣지 않았다. 「재현」이 부르는 보조 스크립트 셋(a2_selftest.py · a2_raw_compact.py · a2_miss_review.py)도 싣지 않았다. 같은 수를 독자가 다시 낼 수는 없다.

오류는 원본보다 깔끔한 쪽으로

모델을 판정자로 세워 모델들의 순위를 매기는 Arena-Hard의 논문(Li 외, arXiv:2406.11939)은 2024-10-14의 v2 초록에, 프롬프트 500개로 모델 하나를 20달러에 채점하는 이 벤치마크가 "98.6% correlation with human preference rankings"를 이룬다고 적었다. 같은 판의 표 1은 상위 20개 모델 전체의 순위를 사람 선호 순위와 맞댔고, 거기서 Spearman 상관은 93.2%다. 98.6%는 표 3의 값이고, 문체를 보정하고 어려운 프롬프트로 비교한 가장 좋은 조건에서 나왔다. 2024-06-17의 v1 초록은 같은 자리에 "89.1% agreement"와 25달러를 적었다. 초록만 옮기는 인용에는 표 1의 93.2%도, 98.6%가 나온 조건도, 판마다 숫자와 그 숫자를 부르는 말이 달랐다는 사실도 따라가지 않는다. 숫자는 남이 옮기기 전에, 같은 논문의 요약에서 이미 원본보다 깔끔했다. 「채점자를 잰다」는 98.6%와 93.2%를 함께 적고, 98.6%가 어느 조건의 값인지 밝혔다.