“AGI가 오면”으로 시작하는 문장에는 공통점이 하나 있습니다. 조건절의 참거짓을 누가 어떻게 판정하는지가 비어 있다는 것입니다. 그 뒤에 붙는 결론은 대체로 구체적입니다. 무엇을 지금 만들지 말아야 하는지, 어떤 검증 단계를 지워도 되는지 같은 것들입니다. 결론은 실무 문장인데 전제는 판정 절차가 없습니다.

이 글은 그 단어에 정의를 하나 더 보태려는 글이 아닙니다. 정의가 여럿이라는 관찰은 이미 논문으로 정리돼 있고, 거기서 멈추면 그냥 정리글이 됩니다. 대신 확인 가능한 것부터 봅니다. 그 단어가 실제로 판정된 적이 있는가, 그리고 판정하지 않기로 한 쪽은 그 자리를 무엇으로 대신했는가.

가장 진지한 조작화 시도와, 그 단어에 검증 절차를 붙였던 발표문부터 봅니다. 판정하는 대신 지운 단어를 확인하고 나면 남는 질문은 하나입니다. “이 산출물이 틀렸다는 걸 무엇이 알려주는가.” 그 질문의 답은 담론에 없고 기록에 있어서, 이 저장소와 제가 쓰는 하네스 플러그인에서 실제로 틀렸던 자리를 열어 봐야 합니다. 그럴듯하게 틀린 자리들은 틀린 방식이 일정했고, 그것들을 뒤집은 물건도 매번 같은 종류였습니다. 그 물건이 무엇인지 따라가면 모델이 좋아져도 안 옮겨지는 자리가 어디인지도 드러납니다.

이 글에서 인용하는 코드와 문서는 전부 공개된 것입니다. 이 블로그 저장소, 그리고 제가 공개 배포하는 하네스 플러그인(sr-harness, sr-blog-harness, flowcast)이라 원문 그대로 옮기고 파일 경로와 줄번호를 답니다. 외부 자료는 각주로 서지를 답니다.

판정하는 대신 지운 단어

정의가 여럿이라는 사실은 논문 한 편이 정리해 뒀습니다. Morris 등의 “Levels of AGI for Operationalizing Progress on the Path to AGI”¹는 기존 AGI 정의를 아홉 개의 사례 연구로 나열하고 하나씩 비평합니다. 다만 아홉이라는 숫자는 이 글에 별 쓸모가 없습니다. 쓸모 있는 건 그 논문이 나열을 끝낸 뒤 스스로 세운 원리 쪽입니다.

논문은 초록에서 이렇게 적습니다.

“To develop our framework, we analyze existing definitions of AGI, and distill six principles that a useful ontology for AGI should satisfy.”

여섯 원리 중 네 번째의 이름이 "Focus on Potential, not Deployment"이고, 원리 진술문은 다음과 같습니다.

“Demonstrating that a system can perform a requisite set of tasks at a given level of performance should be sufficient for declaring the system to be an AGI; deployment of such a system in the open world should not be inherent in the definition of AGI.”

실무자가 그 단어를 두고 묻는 질문은 전부 세미콜론 뒤쪽에 있습니다. 내 파이프라인에서 이게 돌아가는가, 틀리면 무엇이 알려주는가, 사람이 어디서 멈춰 서야 하는가. 그런데 정의를 가장 성실하게 조작화하려 한 쪽이 배포를 정의에서 의도적으로 밀어냈습니다. 그러니까 이 단어가 실무 질문에 답하지 않는 것은 단어가 부실해서가 아닙니다. 설계상 그렇게 그어져 있습니다.

같은 논문이 자기 바깥에 무엇이 남는지도 알고 있습니다. 4절에는 이런 문장이 있습니다.

“While theoretically an ‘Expert’ level system, in practice the system may only be ‘Competent,’ because prompting interfaces are too complex for most end-users to elicit optimal performance.”

이론상 Expert인데 실제로는 Competent일 수 있다는 진술입니다. 능력과 배포 사이의 간극을 논문이 먼저 인정하고 정의 밖에 둔 것입니다. 5절은 측정 쪽 한계도 한 문장으로 적어 둡니다.

“It is impossible to enumerate the full set of tasks achievable by a sufficiently general intelligence.”

능력을 전부 세는 것은 불가능하고, 셀 수 있는 것에서도 배포는 빠져 있습니다. 여기까지가 판정을 시도한 쪽의 결론입니다. 판정을 시도하지 않은 쪽은 어떻게 했을까요.

발표문에서 그 단어가 하는 일이 바뀐 순서

Charter에서 흔히 인용되는 문장은 "highly autonomous systems that outperform humans at most economically valuable work"입니다. 그런데 원문을 열어 보면 이것은 독립된 정의 조항이 아닙니다.

“OpenAI’s mission is to ensure that artificial general intelligence (AGI)—by which we mean highly autonomous systems that outperform humans at most economically valuable work—benefits all of humanity.”

by which we mean 뒤에 붙은 동격절이 그 단어가 받은 규정의 전부입니다. Morris 등이 사례 연구 6번에서 이 대목을 축자 인용하는데, 발췌로는 정확하지만 원문에서 이게 정의 조항의 모양을 하고 있지는 않습니다. 게시일만은 원문에 표기가 없어서 2018-04는 2차 출처 기준으로 둡니다.

2025-10-28 발표문은 그 단어에 절차를 붙였습니다.

“Once AGI is declared by OpenAI, that declaration will now be verified by an independent expert panel.”

같은 문서는 그 절차에 기한도 걸어 뒀습니다.

“Microsoft’s IP rights to research, defined as the confidential methods used in the development of models and systems, will remain until either the expert panel verifies AGI or through 2030, whichever is first.”

매출 배분 조건도 같은 검증에 걸려 있었습니다.

“The revenue share agreement remains until the expert panel verifies AGI, though payments will be made over a longer period of time.”

읽어 보면 판정 장치의 모양을 하고 있습니다. 선언하는 쪽이 있고, 검증하는 패널이 있고, 그 검증에 걸린 권리와 마감일이 있습니다. 그리고 여섯 달 뒤 발표문에서 이 장치가 통째로 사라집니다. 2026-04-27에 Microsoft와 OpenAI가 각각 낸 발표문 어느 쪽에도 AGI와 expert panel이 나오지 않습니다. 두 문서의 매출 배분 항목은 문구까지 같습니다.

“Revenue share payments from OpenAI to Microsoft continue through 2030, independent of OpenAI’s technology progress, at the same percentage but subject to a total cap.”

independent of OpenAI's technology progress. 여섯 달 전 expert panel의 AGI 검증에 걸려 있던 바로 그 항목입니다. 판정 대상이던 것이 무관하다고 명시된 항목으로 바뀌고, 그 자리를 날짜가 대신했습니다.

여기서 제가 확인한 것의 범위를 분명히 해 둡니다. 저는 세 발표문의 본문만 봤습니다. 계약 원문은 공개돼 있지 않아 보지 못했습니다. 그러니 “계약에서 AGI 조항이 빠졌다”라고 쓸 수 없고, 쓸 수 있는 것은 “2026-04-27 양측 발표문 어디에도 AGI와 expert panel 언급이 없다”까지입니다. 한 칸 넓히면 발표문을 근거로 계약을 말하는 셈이 되고, 확인 가능한 것만 말하라는 이 글의 결론을 첫 절에서 어깁니다.

같은 이유로 그 무렵 보도된 이익 기준 수치나 상한 금액도 넣지 않았습니다. 2차 출처만 있고, 이 절의 논지에 필요하지도 않습니다.⁶

범위를 그렇게 좁혀도 관찰은 남습니다. 판정 절차가 붙었다가, 판정되지 않은 채, 무관하다는 진술로 대체됐습니다. 도달했다도 아니고 도달하지 못했다도 아닙니다. 판정할 수 없는 조건을 문서에서 빼고 날짜로 바꾸는 것, 이건 스펙 작업에서 늘 하는 일이에요. 릴리스 기준에 “충분히 안정적일 때”가 들어가면 그걸 판정하는 대신 지우고 날짜나 에러율 임계값을 넣습니다.

그렇다면 걷어내도 잃는 게 없습니다. 애초에 그 자리에 실무 답이 없었으니까요. 남는 질문은 배포 쪽에 있습니다. 이 산출물이 틀렸다는 걸 무엇이 알려주는가. 그리고 그 답은 조회인가 판단인가.

그럴듯하게 틀린 자리

두 번째 질문이 왜 필요한지는 틀린 기록을 열어 봐야 보입니다. 이 저장소에는 그런 기록이 이슈 번호를 달고 남아 있습니다. 다시 읽어 보니 틀린 방식이 서로 닮아 있었습니다.

정확한 수치를 달고 틀린 검토

2026-07-17에 이 블로그의 접근성 이슈를 열었습니다(#26). 발단은 다른 모델(Fable)에게 사이트 검토를 맡긴 결과였습니다. 검토는 이렇게 적었습니다.

rouge 주석색 #999988 대비 ≈2.8:1(AA 미달) … 링크색 teal(#008080)은 ≈4.8:1로 AA 통과

읽으면 신뢰가 갑니다. 색 코드가 있고, 대비 수치가 있고, 통과와 미달 판정이 갈려 있습니다. 그런데 이슈 본문에 제가 적은 반박은 이렇습니다.

링크는 teal이 아니다. 빌드된 CSS에서 teal은 rouge 문법 강조 클래스(.na·.no·.nv — Name.Attribute/Constant/Variable)의 색이고, 링크는 a{color:#1ABC9C}다.

반박에 쓴 것은 더 나은 검토가 아니라 빌드 산출물에 건 명령 두 줄이었습니다.

$ grep -oE "[^{};]{0,40}\{[^}]*#1ABC9C[^}]*\}" _site/assets/css/main.css
a{color:#1ABC9C;text-decoration:none}
.button-link:hover,a.button:hover{background:#1ABC9C;...;color:#fff}
.call-out{...background-color:#1ABC9C;...color:#FFF}

$ grep -oE "[^{};]{0,40}\{[^}]*teal[^}]*\}" _site/assets/css/main.css
.na{color:teal}  .no{color:teal}  .nv{color:teal}

이슈의 결론은 이렇습니다.

즉 검토가 “통과”라고 넘긴 링크가 자기가 지적한 주석색보다 더 나쁘고, 본문 전체에 걸려 영향도 훨씬 크다.

실제 값은 링크색 #1ABC9C가 2.41:1이고, 교체한 #117964가 5.33:1입니다. 검토가 4.8:1로 통과 판정한 대상이 실제로는 AA에 크게 미달했습니다.

여기서 중요한 건 틀렸다는 사실이 아니라 틀린 모양입니다. 검토는 모호하게 틀리지 않았습니다. 구체적인 수치를 달고 틀렸습니다. 그리고 그것을 뒤집은 것은 판단이 아니었습니다. “어느 CSS 규칙이 그 색을 갖는가”는 의견이 갈릴 수 있는 질문이 아니라 파일에 답이 적혀 있는 조회입니다.

의미는 그대로인데 문자가 틀린 인용

같은 날 연 다른 이슈(#30)는 이 블로그의 첫 포스트가 계약 테스트를 인용한 대목을 다룹니다. 이슈 본문의 대조표는 이렇습니다.

이슈에 적은 판단은 이렇습니다.

정규식 안에 없는 "를 넣었고 괄호를 뺐다. 의미는 같지만, 하필 이 글의 결론이 "’왜’를 기록할 때 그 안에 섞인 ‘검증 가능한 사실’은 그 자리에서 검증하라” 다. 인용은 원문 그대로가 맞다.

그리고 이건 나중에 코드가 바뀐 게 아니었습니다.

발행 시점 파일과 대조해 확인했으므로 “나중에 바뀐 것”이 아니라 처음부터 잘못 옮긴 것이다.

정규식의 의미는 보존됐습니다. 그래서 문장을 읽고 코드를 읽고 “맞는 말이네” 하고 넘어가면 끝까지 안 걸립니다. 잡는 방법은 하나뿐입니다. 발행 시점 파일을 꺼내서 문자 단위로 대조하는 것.

이유가 그럴듯해서 엿새를 살아남은 오기

세 번째는 코드가 아니라 결정의 이유가 틀린 사례입니다. 이 블로그는 초기에 테마를 Chirpy에서 Type Theme로 바꿨는데, CLAUDE.md의 변경 이력에 그 사유를 이렇게 적어 뒀습니다.

Chirpy 저장소는 archived 상태라 유지보수 대신 교체 선택

엿새 뒤 커밋 29bf70f가 이 줄을 고칩니다. 여러 작업을 묶어 머지한 커밋이라 정정은 메시지 본문의 한 줄로 들어가 있습니다. 그 줄 원문은 * docs: CLAUDE.md 이력 정정 — 'Chirpy archived' 오기 바로잡음 (실제로는 Type Theme가 archived)입니다. 확인 방법은 GitHub API 한 번이었습니다.

주목할 것은 고친 방식입니다. 틀린 문장을 지우고 맞는 문장으로 바꾸지 않았습니다.

⚠️ 당시 사유로 적은 “Chirpy가 archived”는 오기 — 2026-07-13 GitHub API 확인 시 Chirpy는 활성(v7.6.0)·오히려 Type Theme가 archived(2025-07-26)였음. 실제 교체 근거는 디자인/컨셉 적합성

틀린 기록을 남기고 옆에 정정을 붙였습니다. 이렇게 하면 이력을 읽는 사람이 “왜 이 결정을 내렸는가”뿐 아니라 “그때 무엇을 근거로 삼았고 그게 어떻게 틀렸는가”까지 봅니다. 지워 버리면 두 번째가 사라지고, 사라진 자리에는 처음부터 옳았던 것처럼 보이는 기록만 남습니다. 이 글의 관심사에서 보면 이건 정정 방식의 문제라기보다 틀림의 형태를 보존하는 문제입니다. 형태가 남아야 다음번에 같은 형태를 알아봅니다.

archived 저장소를 떠난다는 건 흔하고 그럴듯한 이유입니다. 그래서 엿새 동안 아무도 의심하지 않았고, 의심했다면 확인에 걸릴 시간은 몇 초였습니다.

다섯 번 검증했는데 마지막이 더 잡았다

앞의 셋은 각각 한 건짜리 사건입니다. “그럼 검토를 한 번 더 돌리면 되지 않나”에 대한 답은 되지 못합니다. 그 질문에는 이 저장소에 실측이 하나 있습니다.

하네스 책 리뷰 포스트 한 편의 리서치 노트(_drafts/harness-engineering-book-overview.research.md, 869줄)에는 검증 라운드가 다섯 번 기록돼 있습니다. 라운드별 결과 요약줄을 그대로 옮기면 이렇습니다.

7 → 6 → 2 → 1 → 3. 마지막 라운드가 직전보다 많이 잡았습니다.

이 수치의 한계를 먼저 적어 둡니다. 라운드마다 검증 대상 초안이 같지 않았습니다. 노트의 각 라운드 헤더가 그걸 밝히고 있어요. 2차는 발행본을 “writer가 노트의 미사용 소재로 보강한 판”이고, 3차는 사용자 피드백을 반영해 “구조만 재작성한 판”, 4차는 절 순서와 서두를 다시 쓴 판입니다. 5차 헤더만 이렇게 적혀 있습니다.

검증 대상: _drafts/harness-engineering-book-overview.md (4차 절 순서·서두 재작성본 = 4차 라운드와 동일한 초안).

그러니 “같은 것을 다시 봤는데 더 나왔다”가 엄밀하게 성립하는 구간은 4차에서 5차로 넘어가는 한 구간뿐입니다. 앞 구간은 초안이 바뀌었으니 애초에 단조 감소를 기대할 이유가 약합니다. 이 구분을 흐리면 다섯 라운드 전체가 수렴 실패의 증거인 것처럼 읽히는데, 그건 과장입니다.

그런데 이 글에 필요한 건 그 한 구간뿐입니다. 같은 초안을 같은 방식으로 다시 봤고, 1건에서 3건으로 늘었습니다. 그리고 늘어난 것 중 하나는 4차가 명시적으로 “정확하다”고 판정했던 항목입니다. 5차 기록이 그 판정을 이렇게 뒤집습니다.

4차 검증 기록 64번은 이 문자열을 “원문의 연속된 부분문자열이라 인용으로서 정확하다”고 판정하고 “유지가 옳은 것 1건”으로 명시했다. 오판이다 — 내부 따옴표 2개를 지워야만 연속이 된다.

같은 노트에 앞선 뒤집기도 남아 있습니다.

주의: 1차 검증 기록 14번은 이 문장을 “결론 문장 축자 대조 → 정확”으로 판정했으나 괄호 누락을 놓친 오판이다. 재사용 금지.

5차 라운드는 자기가 왜 4차 기록을 재사용하지 않고 처음부터 다시 봤는지도 적어 뒀습니다.

이 방침을 택한 이유는 이 노트 자체가 앞서 두 번 “이전 라운드의 판정이 오판이었다”를 기록했기 때문이다(3차 50번이 1차 14번을 뒤집고, 검증 기록 7번이 근거 D·인사이트 7을 뒤집음). 실제로 이번에도 4차 판정 1건이 뒤집혔다(70번).

라운드를 더 도는 것으로 “이제 됐다”에 도달하지 못했다는 기록입니다. 그리고 회차를 쌓는 대신 무엇이 실제로 문제를 잡았는지는 그 70번 항목에 적혀 있습니다.

네 라운드를 통과한 인용을 무너뜨린 것

70번의 확인 방법 원문은 이렇습니다.

초안이 인용부호로 묶은 문자열 전체를 grep -c -F "스스로 고쳐서 통과 처리하는 문제를 구조적으로 차단" chapter_13_레거시_마이그레이션_팀.md → 히트 0건. 이어서 sed -n '283p' | tr '.' '\n'로 해당 문장을 분리 출력해 책의 인용부호가 “통과 처리”에서 닫히는 것을 실물 확인.

무엇이 틀렸는지는 이렇게 적혀 있습니다.

책은 "스스로 고쳐서 통과 처리"까지만 인용부호로 묶고 하는 문제를 구조적으로 차단하기 위함입니다는 저자의 산문이다. 발행본과 4차본은 그 내부 닫는 따옴표를 삭제해 뒤 산문까지 인용 안으로 끌어왔고, 그 결과 원문에 존재하지 않는 문자열이 축자 인용의 외형을 갖게 됐다.

원문에 없는 문자열이 축자 인용의 외형을 갖는 것. #30과 정확히 같은 형태입니다. 읽으면 자연스럽고 의미도 어긋나지 않아서 네 라운드가 통과시켰습니다. 그걸 무너뜨린 건 grep -c -F의 반환값 0이었어요.

주목할 것은 그다음에 한 일입니다. 같은 라운드의 74번 항목이 이렇게 적혀 있습니다.

확인 방법: 블록인용 행을 제외한 본문에서 정규식 "([^"\n]{6,})"로 인용부호 문자열 50건을 추출해 전역 grep -rF로 1건씩 대조. 70번을 적발한 방법을 표본이 아니라 전수로 확대한 것이다.

개선책이 “다음엔 더 꼼꼼히 읽자”가 아니었습니다. 한 번 통한 조회를 표본에서 전수로 넓힌 것이었습니다.

같은 노트에 부수 발견도 하나 붙어 있는데, 이 글의 주제에 정확히 걸립니다.

1차 검증 기록에 “본문의 외부 인용 전량 대조”라 적힌 것은 각주가 붙은 외부 URL 인용에 한정된 진술이었다.

보고서에는 “전량 대조”라고 적혀 있었고, 실제 범위는 그보다 훨씬 좁았습니다. 보고의 단어와 실제로 한 일이 갈리는 전형입니다. 그리고 이 갈림은 보고를 아무리 정독해도 안 보입니다. 보고 바깥의 산출물을 봐야 보입니다.

체감은 방향까지 틀릴 수 있다

보고를 믿을 것인가 측정을 믿을 것인가. 이 질문에는 외부 실험이 하나 있습니다. METR의 무작위 대조 실험⁷은 초록에서 이렇게 요약합니다.

“Before starting tasks, developers forecast that allowing AI will reduce completion time by 24%. After completing the study, developers estimate that allowing AI reduced completion time by 20%. Surprisingly, we find that allowing AI actually increases completion time by 19%–AI tooling slowed developers down.”

이 결과를 “AI가 개발자를 느리게 만든다”는 주장으로 확장하면 근거를 넘습니다. 조건이 좁습니다. 개발자 16명, 2025년 초 프론티어 모델, 평균 5년 경력의 성숙한 자기 저장소입니다. 초록의 조건 문장을 그대로 옮기면 이렇습니다.

“16 developers with moderate AI experience complete 246 tasks in mature projects on which they have an average of 5 years of prior experience.”

저자들 스스로도 실험 설계의 영향을 배제하지 못한다고 적어 뒀습니다.

“Although the influence of experimental artifacts cannot be entirely ruled out, the robustness of the slowdown effect across our analyses suggests it is unlikely to primarily be a function of our experimental design.”

이 글에 필요한 건 그중 한 조각입니다. 일을 끝낸 당사자가 사후에 20% 빨라졌다고 답한 조건에서, 측정은 19% 느려짐이었습니다. 크기가 아니라 방향이 반대였습니다. “직접 써 보니 좋더라”가 근거로 통하는 자리에서 이 한 건이 방향까지 뒤집혔다는 사실은 남습니다.

규칙을 적는 것과 규칙이 돌아가는 것

마지막 하나는 사실 오류가 아니라 운영의 실패입니다. 2026-07-17에 이슈 #16을 열었는데, 발행본이 DOI까지 달아 인용한 논문을 리서치 노트는 “확정하지 못함”으로 남겨 둔 상태였습니다. 이슈 본문의 진단은 이렇습니다.

verifier가 검증해 확정했지만 그 흔적을 어디에도 남기지 않았다.

그리고 같은 이슈가 성격을 못 박습니다.

사실 오류는 아니다 — 추적성 문제다

이 이슈는 규칙을 만들었습니다. 본문의 외부 인용은 리서치 노트에 반드시 존재해야 하고, 검증 결과는 노트에 남긴다. 그런데 일곱 주 남짓 뒤인 2026-09-08, 커밋 8cdfc8f가 이렇게 시작합니다.

발행본 7편 중 이 한 편만 리서치 노트가 저장소에 없었다. 각주 14개로 외부 자료를 인용하는데 근거를 되짚을 수 없는 상태였다. CLAUDE.md가 #16으로 못박은 계약이 여기서만 끊겨 있었다.

규칙은 적혀 있었고, 한 편에서만 조용히 안 지켜졌고, 그 사실이 일곱 주 남짓 아무에게도 걸리지 않았습니다. 규칙을 적는 것과 규칙이 돌아가는 것은 다른 일입니다. 그리고 이 건도 정독으로 발견된 게 아니라 발행본과 노트 목록을 대조하다 걸렸습니다.

여기까지의 사례를 나란히 놓으면 공통점이 하나로 모입니다. 4.8:1이라는 수치, 의미가 보존된 정규식, 그럴듯한 교체 사유, 네 라운드를 통과한 인용, “전량 대조”라는 보고, 20% 빨라졌다는 체감. 전부 읽어서는 걸리지 않는 형태로 틀렸습니다. 그리고 전부 무언가를 열어서 세는 동작에 걸렸습니다.

모델이 좋아져도 안 옮겨지는 자리

앞 절에서 틀린 것을 뒤집은 물건만 모으면 목록이 짧습니다. grep -oE가 어떤 CSS 규칙이 그 색을 갖는지 답했고, grep -c -F가 히트 0으로 인용을 무너뜨렸고, GitHub API 한 번이 어느 저장소가 archived인지 답했고, 발행본과 노트 목록의 대조가 끊긴 사슬을 찾았습니다. 넷 다 판단이 아니라 조회입니다. 그리고 조회는 모델 성능과 무관하게 같은 답을 냅니다.

그렇다면 게이트를 어디에 두어야 하는지도 따라 나옵니다. 제가 쓰는 하네스 플러그인들을 이 기준으로 다시 읽어 보니, 게이트가 놓인 자리가 두 종류였습니다.

보고를 읽지 않고 산출물을 세는 쪽

flowcast 플러그인에는 렌더 결과를 검사하는 스크립트가 있습니다(scripts/validate_rendered_pairs.py). 상단 docstring이 자기가 왜 존재하는지 적어 뒀습니다. 아래 docstring의 #88 · #94는 이 블로그 저장소가 아니라 flowcast 저장소의 이슈 번호입니다.

"""렌더 산출물을 manifest 와 대조하는 **dispatch 후 전용** 검증기.

`validate_manifest.py` 는 drawer 팬아웃 **전** 게이트라 선언값만 본다(pair 당
sequence 1 + topology 1, `segment_numbers` 동일성). 그런데 그 번호가 실제로
그려졌는지, `source_ref` 가 렌더 JSON `source` 로 전사됐는지는 아무도 확인하지
않았다(#88 · #94 핸드오프). 이 스크립트가 그 두 실측 대조를 맡는다:

무엇이 구멍이었는지는 같은 docstring이 한 문장으로 설명합니다.

drawer 가 구간을 쪼개(1..4 → 1..6) 그려도 반환 에코는 그대로라 preflight 게이트가 형식적으로만 통과하던 구멍을 닫는다.

서브에이전트가 거짓말을 한 게 아닙니다. 시킨 대로 1..4를 에코해서 반환했고, 게이트는 그 반환값을 읽고 통과시켰습니다. 실제로 그려진 것만 1..6이었죠. 게이트가 본 것은 일을 한 쪽이 자기 일에 대해 한 말이었습니다.

이 스크립트는 말을 읽지 않습니다. 렌더된 JSON 파일을 열어서 steps[].n과 segments[].n을 셉니다. 다르면 무엇을 하는지가 이 글의 관점에서 중요합니다.

불일치는 자동 수정하지 않는다 — 양쪽 값을 나란히 보고하고 사람이 원문·번호를 확인한다(#88 전반의 “자동 재번호 금지” 원칙).

같은 저장소의 다른 스크립트도 형태가 같습니다. scripts/scan-sensitive.sh:5-6은 이렇게 적혀 있습니다.

# push / 공개 / CI 에서 이 스크립트가 0건(exit 0)일 때만 통과한다.
# 한 건이라도 매치되면 exit 1 로 파이프라인을 세운다.

확률적인 판단을 exit 코드 하나로 귀결시킨 것입니다. 그리고 블로그 하네스에도 같은 계열의 스크립트가 있는데, 이건 아예 자기가 판정자가 아니라고 자기 안에 적어 뒀습니다. scripts/cohesion_check.py의 docstring :4-6입니다.

판정하지 않는다. 주제열(각 문장의 첫 어절)과 문단 크기, 나열 위치, 예고 사슬을 사람이 볼 수 있게 펼쳐 놓을 뿐이다. 한국어 문장 분리와 어절 추출은 근사치이므로 플래그가 붙었다고 문제인 것도, 안 붙었다고 통과인 것도 아니다.

셋의 공통 성질은 이렇습니다. 자기가 답할 수 있는 질문에만 답하고, 답할 수 없는 것은 사람 앞에 펼쳐 놓고 멈춥니다. 게이트의 절반이 이런 물건입니다.

사람이 남는 쪽, 그런데 능력 때문이 아닌

나머지 절반은 사람입니다. 그런데 그 자리를 정하는 기준이 흥미롭습니다. sr-harness 플러그인의 CLAUDE.md:20-32에 이렇게 적혀 있습니다.

## 모델 자동 호출 차단 기준

다음 넷 중 하나에 해당하는 스킬은 frontmatter에 `disable-model-invocation: true`를 단다.
현재 대상: `ralph`, `goal`, `release`, `finish`, `abort`, `meta`.

| 기준 | 예 |
|------|-----|
| 세션 전체를 자율 루프로 바꾼다 | `ralph`, `goal` (Stop hook 설치) |
| 저장소 밖으로 나간다 | `release` (태그 push, GitHub Release) |
| 되돌리는 데 별도 작업이 필요하다 | `finish` (머지, 브랜치 삭제), `abort` (브랜치 삭제) |
| 하네스 자신을 고친다 | `meta` |

되돌리기 쉽고 워크플로우 체인의 핵심인 스킬(`submit`, `issue`)에는 달지 않는다.

문서가 선언한 것과 실물이 맞는지는 셀 수 있습니다. grep -l "disable-model-invocation" */SKILL.md를 스킬 디렉터리에서 돌리면 abort goal meta finish release ralph 여섯 개가 나오고, 전체 스킬은 25개입니다(플러그인 0.26.0 기준). 문서의 목록과 실물이 일치합니다.

여기서 눈여겨볼 것은 목록이 아니라 네 기준에 없는 것입니다. “모델이 이건 잘 못한다”가 하나도 없습니다. 네 기준은 전부 결과의 성질을 말합니다.

이 차이가 이 절의 제목입니다. 능력을 기준으로 그은 선은 능력이 올라가면 옮겨야 합니다. 그런데 머지는 모델이 아무리 좋아져도 여전히 되돌리는 데 별도 작업이 필요합니다. 태그를 push하면 그대로 저장소 밖으로 나갑니다. 이 선은 애초에 모델 성능 축 위에 놓여 있지 않아서, 그 축이 움직여도 따라 움직이지 않습니다.

같은 파일이 이 플래그의 강도도 적어 뒀습니다.

이 플래그는 다른 스킬 본문이 호출을 지시하는 경로까지 막는다. 체인이 그 앞에서 멈추는 자리에서는 슬래시 커맨드를 안내하고 대기하도록 해당 스킬 문구를 함께 고친다 (submit, pause, start).

지시로 막는 게 아니라 호출 경로를 막습니다. 그리고 막힌 자리에서 체인이 어색하게 끊기지 않도록 그 앞 스킬의 문구까지 함께 고쳤다고 적어 뒀습니다. 게이트를 세우는 비용에는 게이트 자체뿐 아니라 그 앞뒤를 다시 쓰는 일도 들어갑니다.

블로그 하네스도 같은 기준을 씁니다. README.md:19입니다.

발행은 Issue → feature 브랜치 → PR(Closes #N)까지만 자동화한다. main 직접 push·자동 merge는 하지 않는다 — merge는 사용자가 한다.

그리고 발행 에이전트에는 미해소 상태를 그대로 내보내지 못하게 하는 조항이 있습니다(agents/blog-publisher.md:12).

본문에 눈에 보이는 미해소 마커 (확인 필요)가 남아 있으면 이동·발행하지 말고 중단해 사용자에게 보고한다

이건 검증이 끝났는지를 모델이 판단하는 게 아니라, 미해소 마커라는 문자열이 남아 있는지를 조회하는 것입니다. 앞 절의 형태가 여기서도 반복됩니다.

자기 자신을 재지 않게 하는 규칙

게이트가 필요한 자리는 하나 더 있습니다. 개선 여부를 스스로 판정하는 루프입니다. sr-harness의 evals/rubric.md는 왜 자기가 필요한지를 먼저 적습니다.

meta는 매 iteration마다 후보 3개를 강제로 만듭니다. “이미 최적”이라는 조기 종료가 금지돼 있으니, 루프는 구조적으로 바꿀 게 없어도 바꾸는 쪽으로 편향됩니다. 판정 기준이 없으면 그 편향이 그대로 채택됩니다.

그래서 채점 가중치를 이렇게 배분했다고 적혀 있습니다.

루브릭의 가중치는 그 편향을 상쇄하도록 배분했습니다. 진화 루프가 팔고 싶어하는 것(새 메커니즘)에는 점수를 주지 않고, 진화 루프가 깨뜨리기 쉬운 것(워크플로우 계약, 안전성)에 절반 이상을 몰아줍니다.

측정 근거가 없을 때의 처리가 이 글의 논지와 정확히 만납니다(:66, :73).

그런 근거가 하나도 없으면 채점하지 않고 후보를 미검증으로 표시합니다.

근거 없이 “개선으로 보인다”고 채택하는 것이 이 루브릭이 막으려는 정확한 실패입니다.

측정 조건에 대한 경고도 한 줄 있습니다(:47).

가장 틀리기 쉬운 지점입니다. 격리하지 않고 재면 스킬을 자기 자신과 비교하게 됩니다.

벤치마크 숫자가 실무에서 힘을 잃는 지점이 여기입니다. 격리하지 않은 조건에서 나온 개선폭은 조건을 잰 게 아니라 자기 자신을 잰 값입니다. 그리고 “개선으로 보인다”는 근거로 치지 않겠다는 문장이 규칙에 명시돼 있습니다.

자동으로 반복하는 구간에는 반대 방향의 규칙이 붙어 있습니다. skills/ownership-principles/SKILL.md:15입니다.

• 사람 개입 없이 반복하는 구간(ralph·goal)일수록 outer loop 체크포인트를 매 반복 명시적으로 남긴다 — 자동 반복이 outer loop 자체를 지워버리면 안 된다

자동화가 늘어난 구간일수록 체크포인트를 줄이는 게 아니라 더 명시적으로 남기라는 것입니다.

단계를 쪼갠 이유도 능력이 아니었다

이 기준으로 보면 파이프라인이 왜 여러 단계로 갈려 있는지도 다시 읽힙니다. 이 글을 만든 블로그 파이프라인은 근거 수집, 초안, 사실 검증, 윤문, 발행의 다섯 단계로 갈려 있습니다. 그런데 다섯 단계를 도는 것은 같은 모델입니다. 한 모델이 다 못 해서 나눈 게 아니에요.

나눈 실체는 각 에이전트 정의에 적힌 금지 조항 쪽에 있습니다. 검증 담당은 이렇게 제한됩니다(agents/blog-verifier.md:37).

• 문체·구조·표현은 건드리지 않는다. 문장을 짧게 나누거나 번역투를 고치는 것은 editor의 일이다. verifier는 사실이 걸린 지점만 만진다

윤문 담당은 반대쪽이 막혀 있습니다(agents/blog-editor.md:17).

• 내용을 추가·삭제·왜곡하지 않는다. 기술적 주장, 숫자, 코드 결과를 임의로 바꾸지 않는다. 애매하면 원문을 유지한다 — 윤문은 문장 표현의 문제이지 사실관계의 문제가 아니다

그리고 윤문 담당이 사실 오류를 발견했을 때 무엇을 해야 하는지까지 적혀 있습니다(agents/blog-editor.md:86).

• 기술적으로 틀린 것 같은 문장을 발견해도 임의로 고치지 않는다. 파일 하단에 <!-- 편집자 노트: ... --> 형태로 의심되는 부분을 남긴다

고칠 능력이 없어서가 아닙니다. 고치면 안 되기 때문입니다. 윤문 단계에서 사실이 바뀌면 검증 기록 없이 바뀌는 것이고, 검증 단계에서 문장을 다듬으면 무엇이 사실 교정이었는지 나중에 구분되지 않습니다. 분할의 기준은 능력이 아니라 권한이고, 권한을 나누는 이유는 한 판단이 다른 판단을 조용히 덮어쓰는 것을 막기 위해서입니다.

코드 쪽 하네스에는 같은 사상이 더 짧게 적혀 있습니다. skills/analyze/SKILL.md:8은 이렇게 시작합니다.

“빌드가 되는가”가 아니라 “계획한 것을 만들었는가”를 검증한다.

바로 아래 역할 분리 표가 두 질문을 갈라 놓습니다.

그리고 analyze가 무엇을 하지 않는지가 명시돼 있습니다(:18).

analyze는 코드를 실행하지 않는다. Issue(계획)와 diff(구현)를 텍스트로 대조한다.

테스트 통과는 의도 정합성을 증명하지 않습니다. 두 질문을 한 스킬에 넣으면 초록불 하나가 두 질문에 동시에 답한 것처럼 읽히는데, 실제로는 한쪽만 답한 것입니다. 앞 절의 #26이 정확히 이 모양이었습니다. 검토 보고서 하나가 “색 대비를 봤다”와 “어느 색이 링크인지 확인했다”에 동시에 답한 것처럼 읽혔지만, 두 번째는 아무도 하지 않았습니다.

남는 것과, 이 글이 답하지 못하는 것

하네스 책 리뷰를 쓰면서 닫지 못한 질문이 하나 있었습니다. 하네스의 구성요소에는 유효기간이 있고 모델이 좋아지면 지워야 하는데, 그때가 언제이고 무엇이 남는지는 알 수 없다는 것이었습니다. 이 글은 그중 앞쪽에는 여전히 답하지 못합니다. 다만 뒤쪽, 무엇이 남는가에 대해서는 관찰 하나를 보탤 수 있습니다.

지금 이 저장소와 하네스에서 게이트가 그어진 자리는 두 종류였습니다. 하나는 보고 대신 산출물을 여는 조회이고, 다른 하나는 결과가 되돌리기 어렵거나 저장소 밖으로 나가는 지점에 놓인 사람의 승인입니다. 둘 다 모델 능력을 기준으로 그어져 있지 않습니다. 조회는 모델이 좋아져도 같은 답을 내고, 되돌리기 어려움은 모델이 좋아져도 그대로 어렵습니다. 이건 전망이 아니라 이미 그어져 있는 선의 성질에 대한 관찰입니다.

정직하게 남겨 둘 것도 있습니다. 게이트를 늘리면 비용이 듭니다. 앞에서 인용한 다섯 라운드 검증은 포스트 한 편에 869줄짜리 노트를 남겼고, 그게 적정한지는 이 저장소 데이터로 판정되지 않습니다. 게이트 자체가 사각지대를 갖는다는 것도 남는 문제인데, 그건 테스트 기준 3편에서 검사기 세 개가 같은 것을 세고 다른 답을 낸 기록으로 이미 다뤘습니다. 이 글이 그 위에 더하는 것은 비용도 사각지대도 아니고 위치뿐입니다.

그래서 “AGI가 오면”이라는 조건절을 만났을 때 할 일은 그 단어를 정의하는 게 아닙니다. 정의를 가장 성실하게 시도한 쪽이 배포를 정의 밖으로 밀어냈고, 그 단어에 검증 절차를 붙였던 발표문은 여섯 달 뒤 그 절차째로 그 단어를 지웠습니다. 그 단어를 걷어낸 자리에 놓을 질문은 이미 정해져 있습니다. 이 산출물이 틀렸다는 걸 무엇이 알려주는가. 그 답은 조회인가 판단인가. 그리고 그게 틀렸을 때 되돌리는 데 무엇이 필요한가.

세 질문 모두 오늘 이 저장소에서 답할 수 있습니다. 판정된 적 없는 단어와 이 질문들의 차이가 거기에 있습니다.