Leaf 라우팅 가이드 — 어떤 일을 어느 모델에 내리나

이 문서의 용어

① 관점 지정 리뷰 sonnet

언제 쓰는 유형인가

• 병합 직전의 게이트 리뷰(대표) — 원 프로젝트에서는 기능 하나가 끝날 때마다 "이 diff를 프라이버시/성능/테스트 실효성 관점으로 검토하라"는 병합 전 적대 리뷰가 관행이었다. 측정 표본도 전부 이 패턴.
• 보안·프라이버시가 걸린 변경의 지정 관점 검토.
• 계획·문서를 완료조건 목록과 대조하는 검증.
• 체크리스트는 위임하는 메인 세션이 병합 직전에 작성해 부여한다:
  • "어디가 위험한지 짚는" 일 자체는 발굴형 판단(⑧)이라, 상위 모델 몫으로 남기는 게 이 벤치의 다른 측정과 정합한다.
  • 단 체크리스트 작성 능력은 이번에 직접 측정하지 않았다 — 측정이 아니라 추론임을 밝혀둔다.

측정에 쓴 실제 태스크

• 작업 내용: 노트를 공개용 웹 URL로 배포하는 기능을 만드는 과정에서, 그 페이지에 "하위 항목 수를 표시하는 배지"를 추가하는 코드가 들어왔다. 이 코드의 정합성을 병합 전에 리뷰하는 작업이다.
• 관점 지정: 프라이버시 누설, 정확성·성능, 테스트 실효성 — 세 관점의 체크리스트를 부여받았다.
• 정답지가 존재: 이 코드에는 병합 차단급 결함이 숨어 있다 — 정체는 아래 "정답지의 정체"에. 배지 숫자를 세는 코드가 항목마다 하위 트리를 처음부터 다시 세어 연산량이 항목 수의 제곱으로 폭발하고, 이 페이지는 로그인 없이 누구나 접근할 수 있어 서비스 마비 공격의 통로가 된다.
• 채점 기준: 이 결함을 스스로 찾아내는가.

정답지의 정체

• 무엇: 병합 차단급 결함 1건 — 연산 폭발로 인한 서비스 마비 통로 — 의 확정 목록.
• 만든 모델: 당시 opus 단독 실행의 리뷰가 발견.
• 거친 과정: 그 발견이 실제 수리 커밋으로 이어져 결함의 실재가 증명됨 — 누군가의 의견이 아니라 확정 사실.
• 비교 시 주의: 발견 여부만 정답이 있고, 보고서 품질에는 정답이 없어 블라인드 심사로 별도 판정.

테스트 방식

• 같은 리뷰 지시문을 opus와 sonnet에 각 2회씩, 총 4회 위임.
• 각 실행은 1회 위임이다 — 중간 개입 없이 지시문 하나로 완주. 다만 지시문이 관점당 1라운드씩 3라운드를 규정하고 "라운드마다 diff·소스 재독, 관점당 발견 소진까지"를 요구하므로, 내부적으로는 다회 라운드 리뷰다. 4회 실행 모두 3라운드 완주를 보고서에 명시했다.
• 채점은 2층이다. 1층은 정답 결함을 포착했는가 — 정답지와 대조하는 기계적 판정. 2층은 리뷰 보고서 자체의 품질 — 모델명을 가린 블라인드 패널이 보고서에서 오탐·부정확 서술·과장 같은 흠을 찾는다.
• 네 실행 모두 결함 주장을 말로만 하지 않고 스스로 실증했다: 전체 테스트 스위트 실행, 성능 벤치마크, 그리고 뮤테이션 테스트 — 프라이버시 필터를 제거하는 식으로 코드에 일부러 결함을 심고, 기존 테스트가 FAIL로 바뀌는지 확인하는 기법. 안 바뀌면 그 테스트는 장식이다. 이걸로 "diff에 딸린 테스트가 공허하지 않음"을 증명.

^*패널 지적 = 블라인드 심사가 리뷰 보고서 자체에서 찾은 흠의 수(존재하지 않는 결함 주장, 부정확한 파일·수치 인용, 과장 등 — 전부 minor급, 치명 0).

인사이트

• 관점 지정 리뷰는 sonnet으로 충분하다. 4회 실행 전부 정답을 잡았고 실증 밀도도 대등 — "어디를 볼지"가 체크리스트로 상류에서 끝나 있으면 남는 일은 지정된 곳을 끝까지 파는 실행이고, 여기서 두 모델은 구분되지 않았다.
• 좋은 모델 1회보다 리뷰 2회가 낫다. 가장 깨끗한 보고서와 가장 지저분한 보고서가 같은 모델(opus)에서 나왔다 — 같은 모델의 실행 간 편차가 모델 간 차보다 크다.
• sonnet이 금액 관점에서 저렴하지도 않다. 이 태스크 2회 합계 opus $5.23 vs sonnet $5.97 — 강등의 실익은 금액이 아니라 상위 모델 사용량 한도 절약이다(§2).
• 체크리스트 작성은 계속 상위 모델 몫. 리뷰 실행은 내려도, "어디가 위험한지 짚는" 상류 판단은 발굴형 능력이라 아끼면 안 된다.

주의

체크리스트가 없는 열린 심층 리뷰는 ⑨ 적대 리뷰 게이트로 취급 — "어디를 팔지 스스로 발명"하는 전혀 다른 능력이고, 거기선 상위 모델 격차가 실재했다.

② 방법 지정 수리·리팩터링 sonnet

언제 쓰는 유형인가

• 원인과 수리 방법이 이미 합의된 버그의 실행 위임 — 진단은 끝났고 고치는 일만 남은 경우.
• 동작을 보존해야 하는 리팩터링 — 구조 전환, 모듈 분리, 성능 개선처럼 "겉보기 결과는 그대로"가 요구되는 작업.
• 오라클 동봉이 이 유형의 성립 조건이다. 테스트·출력 대조 같은 판정 수단 없이 "알아서 고쳐"가 되는 순간 ⑦ 순수 진단·수리로 격상되고, 권장 모델과 안전장치가 달라진다.

측정에 쓴 실제 태스크

• 작업 내용: 노트를 공개용 웹 URL로 배포하는 발행 기능의 서버 코드에는, 페이지를 그리는 두 함수가 서로를 재귀 호출하는 구조가 있었다. 항목이 1,900단 넘게 중첩된 문서를 만나면 호출이 너무 깊어져 서버 전체가 죽는다 — 로그인 없이 접근되는 URL이라 요청 한 번으로 서버를 죽일 수 있는 문제다.
• 방법 지정: 수리 방법이 지시문에 이미 있다 — 재귀를 반복문 구조로 바꿔라. 단, 페이지의 렌더 결과가 바이트 하나까지 이전과 동일해야 한다. 동작 변경이 아니라 구조만 바꾸는 리팩터링이기 때문이다.
• 채점 기준: 깊은 문서에서 크래시가 사라졌는가, 그리고 출력이 완전히 동일한가.

정답지의 정체

• 왜 "수리 전 코드의 출력"이 정답인가: 언뜻 역설 같다 — 버그가 있는 코드의 출력이 어떻게 정답인가? 이 작업의 요구가 "크래시만 없애고, 페이지가 그려지는 결과는 이전과 완전히 같게"이기 때문이다. 수리 전 코드의 결함은 아주 깊게 중첩된 문서에서 죽는다는 것 하나뿐이고, 보통 문서는 올바르게 그린다. 그래서 보통 문서에서 뽑은 출력은 그대로 정답이 되고, 수리 후 코드가 같은 문서에서 글자 하나까지 같은 결과를 내면 합격이다.
• 무엇: 그렇게 뽑은 문서 3종 — 공유 항목이 있는 문서, 1,800단 문서, 서식 있는 문서 — 의 출력. 여기에 별도 기준 하나: 수리 전 코드가 죽던 3,000단 문서에서 수리 후엔 죽지 않아야 한다.
• 만든 모델: 없음 — 코드가 만든 출력 그 자체라 모델 편향이 개입할 자리가 없다. 이 벤치에서 가장 객관적인 정답지.
• 거친 과정: 채점자가 별도 환경에서 직접 생성했고, 수리 전 코드가 3,000단 문서에서 실제로 죽는 것까지 먼저 재현해 정답지가 유효함을 확인했다.
• 참고 — 원 세션에서는 누가 수리했나: 이 수리를 실제 수행한 것은 당시 fable 실행이었다(모델 지정 없는 기본 디스패치). 그 산출물은 채점 기준이 아니라 참고 대조본이다 — 정답은 위의 코드 출력이 대신한다.

테스트 방식

• 같은 지시문을 opus와 sonnet에 각 2회씩, 총 4회 위임.
• 채점은 후보의 주장을 믿지 않는 독립 하네스로 했다. 채점자가 별도 환경에서 수리 전 코드로 정답 출력 3종 — 특정 모델의 산출이 아니라 코드 자체가 기준이라 출처 편향이 없다 — — 공유 항목이 있는 문서, 1,800단 문서, 서식 있는 문서 — 을 만들어 두고, 후보 코드의 출력과 바이트 단위로 대조했다. 3,000단 문서에서 수리 전 코드가 실제로 크래시한다는 것도 먼저 재현해 오라클 자체의 유효성을 확인했다.
• 여기에 기존 테스트 132개 재실행과, 모델명을 가린 블라인드 패널의 품질 심사를 더했다.

^*패널 지적의 내용이 흥미롭다 — opus의 흠 4건은 전부 코드가 아니라 보고서와 산출물의 어긋남이었다: 스스로 주장한 검증 도구가 커밋에 없거나, 기존 테스트 커버리지의 빈틈을 과장하거나, 새로 만든 오라클이 한 방향만 검증. 코드 자체는 4회 실행 모두 무결.

인사이트

• 방법과 오라클이 함께 주어진 수리는 sonnet으로 충분하다. 4회 실행 전부 오라클 만점이고, 패널 흠 0건은 오히려 sonnet 쪽이다.
• "바이트 하나까지 동일" 같은 어려운 제약도, 판정 수단이 함께 오면 실행의 문제가 된다. 제약이 어렵다고 상위 모델이 필요한 게 아니라, 제약을 검증할 오라클이 있느냐가 관건이다.
• 보고서 주장과 산출물의 대조는 이 유형에서도 유효한 게이트다. "500개 무작위 케이스로 검증했다"는 주장이 커밋에 없는 사례가 실제로 나왔다 — 코드가 완벽해도 보고는 부풀 수 있다.
• 금액은 대등하다 — 2회 합계 opus $17.53 vs sonnet $16.15. 강등의 실익은 쿼터다.

주의

오라클은 병합·확정된 기준에서 파생된 것이어야 한다. 수리하는 쪽이 스스로 만든 테스트를 오라클로 쓰면 자기 사각을 공유한다 — ⑥ 창발 구현에서 이 함정이 실물로 확인됐다.

③ 닫힌 계획 문서 작성 sonnet + 검토 강도는 파급이 정한다 — 본문 결정 절차 참조

언제 쓰는 유형인가

• 구조 변경·마이그레이션처럼 구현 전에 단계와 리스크를 정리해야 하는 작업의 닫힌 계획 문서 작성.
• 코드 수정은 금지되고, 조사한 근거와 단계 분해·완료 판정 기준·열린 결정 목록을 담은 문서 하나가 산출물.
• 이름이 "초안"인 이유: 이 leaf의 산출물은 언제나 확정 계획이 아니라 검토 전 초안이다. 파급이 크면 아래 기준대로 독립검토를 거쳐 확정되고, 국소적이면 초안이 그대로 채택될 수 있다 — 확정 여부는 이름이 아니라 게이트가 정한다.

결정 절차 — 이 계획, 누가 쓰고 누가 검증하나

• 계획 작성 — 누가 쓰나
  • 닫힌 계획(목표가 정해진 계획) — 현재 상태를 근거로 단계·리스크·완료 기준을 상세화 → sonnet — 파급이 커도 마찬가지다. 근거는 실측이다: 아래 측정 태스크가 바로 파급 큰 계획이었는데 sonnet이 밀리지 않았다.
  • 열린 계획(목표를 찾아야 하는 계획) — 무엇을 할지 넓게 찾거나 새 설계를 고안하는 것이 본체 → opus 이상. 이 카드의 측정 밖이라 ⑥ 창발 구현의 증거를 유추한 보수적 선택이다.
• 검토 — 누가 검증하나
  • 파급이 국소적 — 단일 화면의 개편 순서 정리 수준 → 검토 생략 가능.
  • 파급이 큼 → opus 독립검토. "파급이 크다"는 다음 중 하나면 성립:
    • 많은 후속 작업이 이 계획을 딛고 서는가
    • 되돌리기 어려운 것 — 마이그레이션 등 — 을 움직이는가
    • 해석 차이가 사용자가 보는 동작을 가르는가
    검토자 근거는 실측 1건: 이번 측정의 치명적 결함을 잡은 심사자가 opus였다. 볼 관점을 지정해 주면 ①의 결과대로 sonnet까지 내릴 여지.
  • 최상위 위험 — 제품 방향을 가르는 결정, 비가역 데이터 이동 → fable 열린 심층 검토. 미측정 — ⑨의 증거를 유추한 보수적 선택.

크기가 바꾸는 것은 "계획을 누가 쓰나"가 아니라 "검토를 얼마나 세게 하나"다 — 이것이 이 카드의 측정이 준 답이다.

측정에 쓴 실제 태스크

• 작업 내용: 초기 검증 단계라 같은 종류의 데이터가 여러 저장처에 쪼개져 있었다 — 목록·트리는 임시 저장처에, 본문은 실제 저장처에 — 그래서 화면마다 다른 출처를 읽었다. 한쪽 화면에는 보이는 항목이 다른 화면에는 없는 모순이 실제로 발생했다. 이 분열을 단일 데이터 모델로 통일하는 마이그레이션 계획을 문서로 작성하는 작업이다.
• 이 계획은 위의 "파급이 큰 계획" 기준에 해당한다 — 많은 후속 작업이 이 계획을 딛고 서고, 마이그레이션이 걸려 있어 잘못되면 되돌리기 어렵다.
• 채점 방식이 독특하다 — hindsight 채점: 이 계획은 원 프로젝트에서 실제로 구현까지 갔고 — 구현 실행은 당시 fable — 그 과정에서 밟은 함정 4개가 기록으로 남아 있다. 그 함정을 역산해 "계획이 미리 경고했는가"를 본다 — 계획의 품질을 취향이 아니라 사후에 확정된 사실로 채점하는 방식이다.
• 함정 4개:
  • 깊은 트리 조회에서 같은 항목을 중복으로 세는 폭발 문제
  • 페이지 이동의 예외 케이스 처리
  • 마이그레이션을 두 번 실행해도 안전한가, 실패하면 되돌릴 수 있는가
  • 데이터 구조만이 아니라 사용자가 조작할 화면까지 계획에 포함했는가

정답지의 정체

• 무엇: 계획이 예견했어야 할 함정 4개의 목록.
• 만든 모델: 특정 모델의 산출물이 아니다 — 이후 실제 구현(당시 fable 실행)과 독립 검토가 실제로 밟거나 잡아낸 사건 기록에서 역산했다.
• 거친 과정: 전부 커밋·검토 기록으로 확정된 사후 사실.
• 비교 시 주의: 원 세션의 채택 계획 문서는 독립 검토 26회를 반영한 개선본이라 비교에 쓰지 않았다 — 검토본과 1회 실행의 직접 비교는 불공정하기 때문.

테스트 방식

• 같은 지시문을 opus와 sonnet에 각 2회씩, 총 4회 위임.
• 채점은 함정 4개의 예견 여부를 문서 인용 근거와 함께 판정하고, 별도로 블라인드 패널이 계획 자체의 결함 — 실현 불가한 단계, 자기모순, 잘못된 귀속 — 을 찾았다.
• 원 세션의 채택본과의 직접 비교는 하지 않았다. 채택본은 독립 검토 26회를 거친 개선본이라, 검토 없는 1회 산출과 비교하면 불공정하기 때문이다.

인사이트

• 닫힌 계획 문서는 sonnet으로 충분하다 — 정확히는 "sonnet이 밀리지 않는다". 치명적 결함을 낸 쪽은 오히려 opus였다. 다만 실행 2회씩의 결과이므로 "sonnet이 더 안전하다"까지는 말할 수 없다.
• 최고 단일 산출도 opus, 유일한 치명적 결함도 opus. 같은 모델의 실행 간 편차가 모델 간 차보다 크다는 패턴이 계획에서도 반복됐다.
• 계획의 안전장치는 모델 상향이 아니라 독립검토다. 치명적 결함을 낸 쪽이 상위 모델이었다는 사실이 이를 뒷받침한다 — 누가 어떤 검토를 하는지는 위 결정표에.

주의

계획 문서가 "무엇을 조사해서 어떻게 찾을지"의 전략서라면 이 유형이 아니다 — 전략을 미리 써서 실행자에게 주입하는 구성 자체가 ⑩에서 기각됐다.

④ 커버리지형 조사 sonnet

언제 쓰는 유형인가

• 경쟁 제품·표준·문서의 전수 수집과 현행 대조 — "빠짐없이 모아라"가 가치의 본체인 조사.
• 수집 결과를 우리 코드·문서와 대조해 분류표를 만드는 작업이 전형.

측정에 쓴 실제 태스크

• 작업 내용: 경쟁 노트 제품의 키보드 단축키를 공식 문서 한국어판·영어판과 커뮤니티 정리 글에서 전수 수집하고, 우리 앱의 코드를 직접 읽어 각 단축키를 "이미 지원 / 다른 동작과 충돌 / 미구현"으로 분류하는 호환성 매트릭스를 만드는 작업이다.
• 정답지: 확정 매트릭스 49항목 — 정체와 편향은 아래 "정답지의 정체"에. "최고가 47/49로 2개 모자람"은 성능 부족이 아니라 1회 실행 vs 검토 반영본의 격차로 읽어야 한다.
• 분류가 맞는지도 별도 검증: 채점 패널이 각 실행의 분류 중 최소 8개를 골라 코드를 직접 열어 재검증했다.

정답지의 정체

• 무엇: 확정 호환성 매트릭스 49항목.
• 만든 모델: opus로 시작해 도중에 fable로 이어진 실행이 초안을 작성.
• 거친 과정: 독립 검토 2회에서 발견 11건을 반영한 확정본 — 즉 검토를 거친 개선본.
• 비교 시 주의: 1회 실행과의 커버리지 비교에는 정답지 쪽에 유리한 기울기가 있다. 게다가 이번 채점에서 정답지 자체의 오류 3건이 드러났고, 후보들이 정답지에 없는 유효 항목도 찾았다 — 정답지는 절대 기준이 아니라 대조 기준.

테스트 방식

• 같은 지시문을 opus와 sonnet에 각 2회씩 위임.
• 패널에는 "정답지도 의심하라"를 지시했다 — 실제로 정답지 자체의 오류 3건이 이 과정에서 발굴됐다(공식 단축키 누락 등). 원 세션 산출물도 무결이 아니다.

인사이트

• 커버리지형 조사는 sonnet으로 충분하다. 커버리지 최고 기록이 sonnet이고, 분류 오류는 양쪽 다 전부 사소한 국소 오분류였다 — 정확도는 opus가 소폭 우위(25개 중 24 vs 29개 중 24)지만 치명적 결함은 양쪽 0.
• 수집 범위가 정의되면 성실한 순회의 문제가 된다. "어디를 찾을지"가 열려 있는 발굴형 조사는 전혀 다른 결과를 냈다 — ⑧.
• 정답지도 의심하게 하라. 채점 기준 자체의 오류 3건이 후보 실행들에 의해 드러났다 — 기준과 다르다고 무조건 감점하면 더 나은 답을 벌준다.

⑤ 디자인 시안·HTML 제작 sonnet + 렌더 화면 자동 캡처 검토 명시

언제 쓰는 유형인가

• 새 화면·컴포넌트를 구현하기 전에 변형 여러 종을 나란히 비교하는 시안 HTML을 만들어 사람이 고르는 라운드.
• 선택 수집 장치 — 라디오·복사 버튼 — 까지 포함한 자체완결 페이지가 산출물.

측정에 쓴 실제 태스크 (2건)

• 태스크 A: 에디터의 명령 메뉴가 "글자가 너무 커" 피드백을 받았다. 글자 크기와 밀도를 축으로 변형 4~6종을 설계해 비교 페이지로 만드는 작업.
• 태스크 B: 아직 만들어진 적 없는 휴지통 화면과 상단 메뉴 패널의 첫 시안 라운드 — 구조 변형 3종씩, 상태별 화면 포함.
• "원 세션 채택본"이란: 원 프로젝트에서 이 시안 라운드가 실제로 실행됐을 때 산출돼, 사용자가 보고 변형을 골랐던 바로 그 비교 페이지 — 정체는 아래 "비교 기준의 정체"에. 원본은 지금도 프로젝트 저장소에 있어 직접 열어 대조할 수 있다.
• 비교 설계: 태스크마다 opus 2회·sonnet 2회에 채택본을 더해 5개를 익명으로 섞고, 어느 것이 채택본인지도 가린 채 사람이 최고와 탈락을 골랐다.

비교 기준의 정체 — 시각 선호에는 정답이 없어 "정답지" 대신 채택본을 쓴다

• 무엇: 원 라운드에서 사용자가 보고 변형을 골랐던 그 비교 페이지 2건.
• 만든 모델: 두 건 모두 당시 opus 실행의 산출물.
• 거친 과정: 산출 후 수정 없이 그대로 채택 — 저장소 이력상 도입 커밋 이후 변경 0회, 블라인드 사본과 해시 일치 확인.
• 비교 시 주의: 사람 선택을 한 번 통과한 판이지만, 이번 블라인드에선 1승 1탈락 — 채택 이력이 품질 보증이 아니다.

테스트 방식

• 사람 블라인드 선택이 1차 판정 — 시각 품질에는 자동 채점이 없기 때문. 채점자의 어감 기준: 탈락 = 채택 불가 수준의 결함, "고만고만" = 눈에 차지 않는 수준.
• 별도로 패널이 검증 가능한 항목만 심사했다: 요구된 변형 수·상태 화면·수치 주석의 정확성·다크 모드·자체완결성.

인사이트

• 시안은 1회 생성으로 되는 일이 아니다. 신규 8건 중 사람 눈높이를 만족한 것은 2~3건 — 절반 이상이 별로 이하였다. 이 유형의 올바른 운용은 후보를 여러 개 생성해 사람이 고르는 구조이고, 시안 라운드가 원래 그 구조다.
• 모델 방향은 없다. 최고 1회는 sonnet, 좋음 1회는 opus, 별로와 탈락엔 양쪽이 다 있다 — sonnet 강등 시 잃는 것이 관측되지 않았고, 실행 단가가 지배 요인도 아니다. 그래서 sonnet에 후보 수를 늘리는 쪽이 합리적.
• 채택본이 항상 이기지도 않는다. 채택본 — 당시 opus 산출 — 이 한 태스크에선 최고였지만 다른 태스크에선 채택 불가 판정을 받았고, 실전에서 아무도 못 잡았던 내용 결함까지 블라인드 재검에서 드러났다. 익명 비교는 산출물만이 아니라 과거의 선택도 검증한다.
• 필수 조건: 지시문에 "렌더 화면을 자동 캡처해 스스로 검토하라"를 명시하라. 화면 없는 자동 브라우저로 페이지를 열어 스크린샷을 찍는 검증인데, 스타일 선언만 하고 연결하지 않는 부류의 버그는 소스만 봐선 안 잡히고 렌더된 화면을 봐야 잡힌다 — 실제로 탈락한 실행이 이 함정을 밟았다.

⑥ 창발 구현 opus 또는 fable + 병합 전 독립 적대 리뷰 의무

언제 쓰는 유형인가

• 알고리즘·프로토콜 수준의 설계 판단이 남아 있는 구현 — 참고 방향은 있지만 정답 설계가 없는 작업.
• 동기화·동시성·데이터 무결성처럼 실수의 대가가 큰 영역이 전형.

측정에 쓴 실제 태스크

• 작업 내용: 두 사람이 같은 줄을 동시에 편집하면 한쪽의 입력이 지워지는 결함이 있었다. 원격에서 온 변경을 아직 확정되지 않은 내 편집 위에 위치를 변환해 병합하는 알고리즘을 만들어야 하는데, 지시문은 원인 계열과 방향만 주고 "설계는 현재 코드를 직접 확인한 뒤 네가 판단하라"고 했다. 재전송·재접속·서버 동기화 규칙과 충돌 없이 공존해야 한다는 제약이 겹친다.
• 원 세션에서는 어땠나: 이 태스크의 원 구현은 fable 실행이었다. 그 fable조차 1차 구현에 치명적 결함 1건을 내장했고, 병합 전 적대 리뷰가 잡아낸 뒤 수리를 거쳐서야 병합됐다 — 즉 "1회 구현을 믿을 수 없다"는 이 카드의 결론은 fable을 포함한 세 모델 공통이다.

정답지의 정체

• 무엇: 사전에 정답 목록이 없다 — 확정 결함 수가 사후에 만들어지는 정답지다.
• 만든 모델: 교차 심사단(opus·fable 각각)이 결함을 발견하고, 중대 주장은 별도 반증 검증을 통과한 것만 확정.
• 비교 시 주의: 원 세션 구현(당시 fable, 1차에 치명적 결함 1건 후 리뷰로 수리)은 참고용 대조본이지 채점 기준이 아니다.

테스트 방식

• fable·opus·sonnet에 각 2회씩, 총 6회 위임. 자동 채점은 빌드와 기존 테스트 전체 재실행 — 전원 통과였다.
• 품질층은 교차 심사: 같은 산출물 6개를 opus 심사단과 fable 심사단이 각각 블라인드로 심사하고, 중대 주장은 반증 검증을 통과한 것만 인정했다. 이 교차 설계가 뜻밖의 수확 — 심사단 간 격차 — 을 낳았다.

검증 깊이의 비대칭 각주: 심사자는 검증 도구를 스스로 만들 수 있고 어디까지 팔지는 재량이라, 모든 후보가 7만 회급 무작위 검증을 받은 것은 아니다 — 결함이 나온 세 후보는 그 결함이 재생기로 확정됐고(양성 증거), fable 두 후보는 공격적 재생에도 무결(음성 증거)이지만, opus 1회차의 무결은 같은 강도의 공격을 받은 기록이 없다. "fable 2/2 > opus 1/2" 사다리를 읽을 때 이 점을 감안하라.

fable은 언제, 얼마나 좋았나 — 검증 국면의 실측

• 구현 국면의 fable은 위 표대로 2/2 무결이다. 그와 별개로 fable의 실력이 가장 극적으로 드러난 곳은 검증 국면이다.
• 원 실험의 후보 4개를 심사한 두 심사단의 행동이 갈렸다. opus 심사단: 코드를 정독하고 기존 테스트를 확인하는 수준 — 확정 결함 0건 발견.
• fable 심사단: 코드 정독에서 멈추지 않고, 두 클라이언트의 편집 순서를 무작위로 뒤섞어 재생하는 검증 하네스를 즉석에서 만들어 실행했다. 30,000가지 순서를 돌려 불일치 291건을 재현하고, 의심 지점 한 줄을 고치자 0건이 되는 것까지 확인해 원인을 확정했다. 이 방식으로 확정 결함 3건 전부를 발견.
• 즉 fable의 우위는 "코드를 더 잘 읽는다"가 아니라 "어떤 검증 수단이 필요한지 스스로 발명한다"에 있었다 — ⑧ 발굴과 같은 기전이고, 창발 구현의 병합 게이트를 fable에 맡기는(⑨) 직접 근거다.

인사이트

• 6회 중 3회가 자기 테스트를 전부 통과한 채 병합 차단급 결함을 내장했다. 스스로 만든 테스트는 스스로의 사각을 공유한다 — 창발 구현의 완료 조건에 "자체 테스트 통과"를 쓰면 안 되는 실물 증거.
• 모델 사다리가 실측됐다: fable 무결 2/2 > opus 1/2 > sonnet 0/2. 이 벤치의 결정 규칙(치명 0)을 통과한 모델은 fable뿐이다. 단 원 세션의 fable 1차는 치명이 있었으므로(실행 6회 표본) fable도 항상 무결은 아니다 — 게이트 의무는 모델 불문 유지.
• 선택지는 둘이다: 품질 최우선이면 fable + 게이트(1회 $43~51 — opus의 약 3배), 한도를 아끼려면 opus + 게이트(치명은 게이트가 잡는다는 전제). sonnet 강등은 무결 0/2라 여전히 비권장.
• 가장 비싼 유형이다 — 1회 $12~22. 그런데도 게이트 없이는 그 돈으로 결함을 사는 셈이다.

⑦ 순수 진단·수리 opus, 중요하면 fable + 동일 게이트 의무

언제 쓰는 유형인가

• 재현은 되는데 원인이 미상인 버그의 진단＋수리 통짜 위임.
• ②와의 경계: 수리 방법이 지시문에 있으면 ②, 없으면 여기.

측정에 쓴 실제 태스크

• 작업 내용: 새 페이지를 만들면 그 페이지로 이동해야 하는데 홈 화면으로 튕기는 버그가 있었다. 지시문은 "화면 갱신 타이밍이 얽힌 경합이 의심된다"는 가설만 주고, 그 가설조차 "리뷰 시점의 추정이니 코드로 재검증하라"고 못박았다.
• 층위가 있는 정답지: 원 세션에서 이 버그는 두 번에 걸쳐 고쳐졌다. 첫 수리 — fable 실행 — 는 문제가 난 경로 하나만 막은 수준이었고, 독립 리뷰 — opus 실행 — 가 "다른 경로로 재발한다"고 지적한 뒤에야 fable의 재수리가 어느 경로로도 재발하지 않는 봉쇄에 도달했다. 그래서 채점 척도가 3층이다:
  • 경로 수리 — 문제가 난 경로 하나만 막음. 원 세션 첫 수리 수준.
  • 제3의 유효한 원천 수리 — 정답과 다른 방법이지만 현재 도달 가능한 경로를 전부 차단.
  • 원천 봉쇄 — 어느 경로로도 재발하지 않는 구조적 수리.

정답지의 정체

• 무엇: 수리 층위 3층 척도 — 경로 수리 / 제3의 유효 수리 / 원천 봉쇄.
• 만든 모델: 특정 모델의 단일 산출이 아니라 원 세션의 사건 이력에서 역산 — 1차 수리는 fable, "다른 경로로 재발한다"는 지적은 opus 리뷰, 원천 봉쇄 재수리는 다시 fable.
• 비교 시 주의: 기계적 diff 대조가 아니라 "이 수리가 다른 경로까지 실제로 막는가"를 심사단이 코드 추적으로 판정 — 정답과 다른 제3의 유효 수리도 인정된다.

테스트 방식

• fable·opus·sonnet에 각 2회씩, 총 6회 위임. opus 심사단과 fable 심사단이 각 산출물의 진단 수준 — 표면 경합까지인가, 재발 구조의 뿌리까지인가 — 과 수리 층위를 코드 추적으로 판정했다. 기계적 diff 대조가 아니라 "이 수리가 다른 경로까지 실제로 막는가"를 경로별로 확인.

흥미로운 사실 — 신선한 1회 실행의 fable 2회가 모두, 원 세션에서 fable 자신이 냈던 1차 수리(경로 수리 수준)를 넘어섰다. 원 세션 1차가 얕았던 것은 모델 한계라기보다 그날의 편차였을 가능성이 크다.

인사이트

• opus·sonnet 4회만 놓고 보면 최고도 sonnet, 유일한 치명적 결함도 sonnet. 최고 실행은 원 세션의 첫 수리보다 깊이 갔고, 최악 실행은 원 세션이 기각한 접근을 밟았다 — 진단 유형에서도 편차가 모델 차를 지배한다.
• 권장은 opus, 중요하면 fable이다. 이 벤치의 결정 규칙 — 치명적 결함이 하나라도 나오면 강등 불가 — 을 sonnet이 통과하지 못했다. opus는 두 실행 다 무결한 중간이었고, fable은 2/2가 근본 진단＋제3의 유효 수리 이상 — 층위·무결 모두 우위였다.
• 4회 전부 가설을 맹신하지 않고 실측으로 재검증했다 — 계측을 직접 심어 3단계 화면 전이를 관측하는 수준까지. 진단의 성실성은 모델 무관하게 높았다.
• 중요한 진단이라면 "상위 모델 1회"보다 "같은 모델 2회 + 게이트 선별"이 실측상 합리적일 수 있다 — 편차가 크기 때문이다.

⑧ 발굴형 조사 opus 이상

언제 쓰는 유형인가

• 공식 문서에 없는 기능·제약·우회로를 커뮤니티와 실험에서 캐내는 조사.
• ④ 커버리지형과 같은 태스크 안에 섞여 있는 경우가 많다 — 지시문을 쓸 때 두 축을 구분해서 생각하라. 어느 축이 본체냐에 따라 권장 모델이 갈린다.

측정에 쓴 실제 태스크

• 별도 실행이 아니다 — ④의 단축키 조사 4회 실행 그대로를 다른 자로 잰 것이다. 그 지시문에는 "공식 문서에 없는데 커뮤니티가 보고하는 숨은 단축키를 찾아 별도 표시하라"는 발굴 축이 명시돼 있었다.

정답지의 정체

• 무엇: 사전 정답 목록이 없다 — 각 실행이 찾아낸 숨은 단축키 중 출처가 실제로 확인되는 것의 개수가 사후에 점수가 된다.
• 만든 모델: 채점 기준 자체는 특정 모델 산출물이 아니다(사전 정답 목록 없이 발견별 출처 실물을 검증하는 사후 검증형). 단 원 세션에서 이 발굴을 실제 수행한 실행은 ④와 같은 실행 — 당시 opus로 시작해 fable로 이어졌고, 교차 확인에 쓴 ④ 확정 매트릭스의 숨은 단축키 3건도 그 산출물(독립 검토 2회 반영)이다.
• 비교 시 주의: 참고로 ④의 확정 매트릭스에도 숨은 단축키 3건이 실려 있어 교차 확인에 썼다. 그리고 이 유형에 fable은 실측되지 않았다 — fable 보완 실행은 ⑥(구현 대상 A)·⑦(진단 대상 A)에만 있었고 이 조사 태스크는 opus·sonnet만 비교됐다.

테스트 방식

• 모델명을 가린 패널이 실행별 발굴 주장을 출처 실물 — 공식 발표, 커뮤니티 문서 — 로 검증해 유효 건수만 셌다.

비용은 ④와 같은 실행이므로 ④의 표를 보라. 두 실행 모두에서 벌어진, 이 벤치 전체에서 가장 뚜렷하고 일관된 모델 격차다.

인사이트

• 지정된 곳을 파는 능력은 동률이지만, 어디를 파볼지 스스로 넓히는 능력은 상위 모델이 일관되게 우위였다.
• 이 격차는 게이트로 보정할 수 없다. 틀린 것은 리뷰가 잡아주지만, 하지 않은 발견은 리뷰가 만들어주지 못한다 — 그래서 발굴이 본체인 일은 모델을 아끼면 안 된다.

주의

측정 태스크가 1종이므로 방향 신호로 읽어야 한다 — 다만 ⑨의 심사단 격차가 같은 기전이라 서로를 보강한다.

⑨ 적대 리뷰 게이트 fable 유지

언제 쓰는 유형인가

• 창발 구현·진단 수리의 병합 전 마지막 관문. 이 문서의 모든 "sonnet 가능" 판정이 게이트의 존재를 전제하므로, 게이트 자체의 품질이 전체 체계의 바닥이다.
• ①과의 경계: 체크리스트가 주어지면 ①이고 sonnet으로 충분하다. 여기는 어디를 팔지 스스로 정해야 하는 리뷰다.

측정에 쓴 실제 태스크

• 설계된 리플레이가 아니라 벤치의 심사 과정 자체가 만든 자연 실험이다 — ⑥의 구현 산출물 4건과 ⑦의 진단 산출물 4건을, opus 심사단과 fable 심사단이 각각 독립적으로 블라인드 심사했다. 같은 대상을 두 심사단이 봤으므로 심사 능력의 직접 비교가 된다.

정답지의 정체

• 무엇: 사전 정답이 없다 — 두 심사단의 발견을 합쳐 반증 검증을 통과한 확정 결함의 집합이 사후 기준이 되고, 각 심사단이 그중 몇 개를 찾았는지가 점수다.
• 만든 모델: 없음 — 교차 발견 + 반증 검증으로 사후 확정.
• 비교 시 주의: 심사단 자신들의 발견이 기준이 되는 구조라, 두 심사단이 모두 놓친 결함은 측정 밖이다 — 격차의 하한만 잰다.

테스트 방식

• 동일 후보 4건씩을 두 심사단이 모델명을 가린 채 심사하고, 병합 차단급 주장은 별도 반증 검증을 통과한 것만 인정.

인사이트

• 열린 심층 리뷰의 격차는 발굴의 격차다 — ⑧과 같은 기전. 어디를 의심할지, 어떤 검증 도구를 만들어 돌릴지를 스스로 정하는 능력에서 심사단이 갈렸다.
• 게이트에서 아끼면 전체가 무너진다. sonnet 강등 행들의 안전 근거가 전부 "게이트가 잡는다"이므로, 게이트 모델을 내리는 순간 그 전제가 사라진다.

주의

구현 심사 1태스크 + 진단 심사의 방향 일치가 근거의 전부인 보수적 현상 유지다 — "opus로 내리면 안 된다"의 확정이 아니라 "내릴 근거가 없다"가 정확한 진술. 체크리스트형 리뷰(①)는 반대 방향 증거.

⑩ 전략/실행 2단 분리 금지

언제 이 패턴에 끌리나

• "비싼 모델은 머리만 쓰고, 싼 모델이 손을 쓰면 되지 않나"라는 직관 — 쿼터를 아끼려는 합리적 동기에서 나온다. 그럴듯해 보이지만 실측에서 기각됐다.

측정에 쓴 실제 태스크

• ④의 단축키 조사 태스크로 세 구성을 각 2회씩 비교했다: opus 단독, sonnet 단독, 그리고 분리 구성 — opus가 전략 문서를 쓰고 sonnet이 이어받아 실행.

정답지의 정체

• ④와 동일 — 확정 매트릭스 49항목(검토 반영본) 대비 커버리지와, 분류의 코드 재검증, 그리고 ⑧의 숨은 발견 수.

테스트 방식

• 단독 구성 4회는 ④·⑧과 같은 실행이고, 분리 구성 2회만 새로 돌렸다 — 전략 단계와 실행 단계의 비용을 합산해 비교.

왜 실패하나

• 전략 문서가 탐색의 상한이 된다. 두 실행 모두 숨은 발견이 0건 — 실행자는 전략이 가리킨 곳만 팠고, 전략 밖의 뜻밖의 발견이 사라졌다.
• 전략의 구멍이 그대로 결과의 구멍이 된다. 최악 실행의 원인을 추적하니, 전략이 훑으라고 지정한 파일 목록에 핵심 파일 하나가 빠져 있었고 실행자는 그 파일을 끝내 열지 않았다 — 오분류 4~5건이 여기서 연쇄됐다. 단독 실행이라면 스스로 찾아 들어갔을 파일이다.
• 비용도 더 비싸다. 두 모델을 부르니 합산 비용이 단독보다 높다.

인사이트

• 핵심 기전: 조사 범위는 조사 결과에 따라 동적으로 갱신되어야 하는데, 분리 구성은 그것을 막는다 — 그래서 성능이 떨어진다. 위 두 실패가 전부 이 하나의 기전이다: 실행 중의 발견이 "다음엔 저기도 봐야겠다"를 만들어내야 하는데(숨은 발견), 범위가 전략 문서에 고정돼 있으면 그 갱신이 일어나지 않고(발견 0건), 전략에 빠진 곳은 영영 방문되지 않는다(핵심 파일 미방문 → 오분류 연쇄).
• 대안은 잘 쓴 지시문 하나다. 배경과 완료조건을 담되 "세부는 현재 상태를 직접 확인한 뒤 네 판단"을 남기는 단일 위임이, 2단 파이프라인보다 성능·비용 모두에서 나았다 — 이 문서의 모든 측정이 그 형식 위에서 이루어졌다.

번외 — 메인 세션은 무슨 모델로? fable 유지 (미측정 — 인접 실측 유추)

• 이 문서의 측정은 전부 leaf 층이다 — 메인 세션의 직무(분해·지시문 작성·오케스트레이션·게이트 운영)를 모델별로 직접 비교한 실험은 없다. 아래는 인접 실측으로부터의 유추다.
• 메인 세션의 직무가 곧 상위 모델 격차가 실측된 능력들의 집합이다: 열린 심층 심사(⑨ — fable 3건 vs opus 0건), 발굴(⑧), 조사 범위의 동적 갱신(⑩의 핵심 기전 — 메인 세션이 상시 수행하는 바로 그 판단), 체크리스트 작성(①의 상류)과 파급 판정(③).
• 한도 구조와도 정합: 한도 절약의 본체는 leaf를 fable 밖으로 내리는 것(§2)이고, 그렇게 아낀 Fable 한도의 용처가 메인 세션이다. leaf를 내려놓고 메인까지 낮추면 아낀 한도를 쓸 곳이 없다.
• 경고 신호: "opus 메인 세션"의 가장 가까운 대리 실측이 ⑨의 opus 심사단인데, 확정 결함 4건 중 0건을 잡았다. Fable 한도가 부족하면 메인을 낮추기보다 leaf 라우팅을 더 철저히 하라.