마흔 번 기각했고, 사유는 대개 대상 밖에 있었다

남의 도구 마흔 건을 뜯어 실제로 들인 것은 하나다. 그런데 값이 나가는 건 1/40 이라는 비율이 아니라 기각 사유 쪽이었다.

남의 도구 마흔 건을 뜯었고 실제로 들어온 도구는 하나다. 그런데 이 원장에서 값이 나가는 건 1/40 이라는 비율이 아니라 기각 사유 쪽이다. 마흔 편의 사유를 보면 최빈값은 「대상이 나쁘다」가 아니라 「내 쪽에 걸 자리가 없다」였다. 이미지 생성 스킬을 기각한 사유는 품질이 아니라 이 PC에 이미지 생성 도구가 0개라 설치해도 부를 곳이 없다는 것이었고, 어떤 표식 스캐너를 기각한 사유는 성능이 아니라 내 발행 코퍼스 6.1MB 를 훑어 검출이 0건이라 표적이 존재하지 않는다는 것이었다. 판정의 주어가 대상이 아니라 내 환경이라는 뜻이고, 그래서 채택·보류·기각 세 칸으로는 이 사유가 기록되지 않는다. 네 번째 칸 — 적용 불가 — 이 없으면 「끼울 자리가 없다」가 「별로다」로 잘못 적히고, 반년 뒤에 같은 조사를 다시 하게 된다. 실제로 같은 질문을 세 번째로 연 편이 있다. 두 번째 결론은 이것이다. 간판 수치는 실측 앞에서 거의 버티지 못했는데, 무너뜨린 근거는 남의 비판 글이 아니라 대상 자신의 자료였다. 세 번째, 1차에 적은 수확은 거의 항상 부풀려져 있었다 — 발행본의 kpi 줄에 「N → M」으로 남은 열 편을 더하면 58에서 5.5다. 이 글은 그 마흔 건의 원장에서 역산한 판정 절차다.

판정 절차의 뼈대. 집계는 2026-08-23 기준 발행본 마흔 편 전수이고, 재개 조건과 재제안 금지는 본문 정규식 grep 으로 셌다.

기각 사유의 최빈값은 「대상이 나쁘다」가 아니라 「내 쪽에 걸 자리가 없다」였다

마흔 편의 기각 사유를 모아 보면 가장 자주 나오는 것은 대상의 품질 문제가 아니다. 설치해도 부를 곳이 없거나, 고칠 대상이 내 쪽에 없거나, 이미 같은 일을 하는 것이 돌고 있다 — 셋 다 대상이 버전을 올리거나 별이 늘어도 안 바뀌는 사유다.

기각 사유	그 사유가 본문에 문장으로 적힌 편
마운트 지점 부재 — 설치해도 호출할 곳이 없다	ip-as-logo · DSH better-sidebar · dsh-anchored-standard · ASIDE
표적 부재 — 고칠 대상이 내 쪽에 없다	watermarks-remover · Headroom · 토스 네뷸라 · 그래프 엔지니어링
이미 갖고 있음 — 순증이 0이다	obra/superpowers · ECC · 세컨드 브레인 강의 · 당근 SEED
대상 자신의 수치가 안 맞음	OmniRoute · ponytail · Odysseus · 플러그인 4종 추천

이 표는 마흔 편의 분할이 아니다. 네 줄은 서로 배타적이지 않고 한 편이 두 줄에 동시에 들어간다 — dsh-anchored-standard 는 마운트 지점이 없는 동시에 2단계 카탈로그를 이미 갖고 있었다. 그래서 축마다 숫자를 먼저 쓰지 않고 편 이름을 나열했다. 나열의 길이가 그 축의 크기다.

구체적으로 보면 이렇다. 이미지 마스코트 생성 스킬은 파일 5개에 실행 코드 0인 지시문 한 장이었는데, 기각 사유는 지시문의 품질이 아니라 이 PC에 이미지 생성 도구가 0개라는 것이었다. 표식 스캐너는 별 16,619개짜리였지만 내 발행 코퍼스 6.1MB — 문서 196편 + 정적 HTML 238장 + 원고 7편 — 을 그 스캐너로 훑으니 검출이 0건이었고, 청소 함수를 라운드트립으로 돌려도 196편이 196/196 바이트 동일이라 순수 no-op 이었다. 어떤 디바이스 팜의 UI 덤프는 2,350ms 라는 실측이 정확히 맞았는데, 내 파이프라인에 그 호출이 0건이었다. 내 화면 구조에서는 그 덤프가 애초에 빈 껍데기로 온다 — 10배 빨라질 대상 자체가 없었고, 그 사실은 내 프로젝트 문서에 이미 적혀 있었다. 컨텍스트 압축 계층은 간판이 「60~~95% 압축」이었지만 내 캐시 재사용률이 이미 92.5~96.3% 였고 캐시를 안 타는 입력이 호출당 1.8~~2.0 토큰이라 줄여 줄 대상이 존재하지 않았다. 영상 하나가 「그래프의 핵심」이라 부른 되돌림 엣지는 내 런 52개에서 발동 조건이 한 번 나왔다.

다섯 건에 공통점이 있다. 어느 것도 대상을 더 깊게 읽어서 나온 판정이 아니다. 전부 내 쪽을 한 번 재서 나왔고, 재는 데 걸린 시간은 대상을 읽는 데 걸린 시간의 몇십 분의 일이다. 그런데 순서를 반대로 하면 — 대상을 먼저 오래 읽으면 — 그 시간이 판정에 섞여 들어온다.

여기서 값을 치른 교훈은 사유의 유효기간이다. 「별로다」는 대상이 안 바뀌는 한 유효하지만 「끼울 자리가 없다」는 내 환경이 바뀌는 순간 뒤집히는 판정이다. 둘을 같은 칸에 적으면 유효기간이 통째로 사라지고, 반년 뒤에 같은 조사를 다시 하게 된다.

재고 확인의 단위는 목록이 아니라 마지막으로 켠 날짜다

「이미 갖고 있다」는 세 층에서 각각 다른 답을 낸다. 앞의 두 층 — 보유(설치돼 있나)와 작동(눌러 보면 결과가 나오나) — 은 기준선 편이 이미 다뤘다. 이 절이 새로 세우는 것은 세 번째 층 하나뿐이다. 마지막으로 켠 날짜. 세 층 전체와 그것을 어떻게 세는지는 마지막으로 켠 날짜가 없으면 갖고 있는 게 아니다가 따로 다룬다.

세 층 중 위의 두 층은 다른 글이 소유한다. 이 절이 세우는 것은 3층 하나이고, 그 층에서만 도입과 실행이 갈린다.

실측 세 건이 전부 3층에서 나왔다. 컨텍스트 예산을 재려고 들여놓은 측정 스킬은 07-29 설치 후 08-22 까지 24일간 실행이 0회였고, 그것을 받쳐 줄 슬래시 커맨드는 커맨드 37개를 전수 확인해도 애초에 만들어지지 않았다. 더 나쁜 것은 그 스킬의 산식이 스킬 오버헤드를 37.6배 과대계상한다는 것이다 — 스킬 문서 전체 890,428자를 세는데 실제 상시 노출은 설명 프론트매터 23,671자뿐이다. 다른 하네스에서 기법 다섯을 수확하려다 셋이 죽었을 때, 셋을 죽인 스킬 두 개도 둘 다 실행 이력이 0이었다. 한쪽은 도입 메모 한 줄 말고 흔적이 없고, 다른 쪽은 자기가 만들라고 지시한 로그 파일과 휴지통 폴더가 둘 다 존재하지 않았다. 내가 직접 만든 쪽도 같았다 — 세션을 자동 관찰해 패턴을 증류하는 파이프라인에 관찰이 127파일 20.6MB 쌓이는 동안 증류기는 한 번도 돌지 않았고 산출된 본능은 0개였다.

셋 다 「없어서」가 아니라 「있는 걸 안 돌려서」 생긴 공백이다. 그리고 셋 다 1층에서 판정했으면 정반대 결론이 나온다 — 목록에 이름이 있으니 「이미 있음, 도입 불필요」다. 실제로 그렇게 적은 적이 있다. 남이 만든 4단계 사다리에 내 운영을 맞추면서 「동등」이라고 네 칸을 적었는데, 근거가 전부 「설치돼 있다」였다. 마지막 칸을 실제로 눌러 보니 쌓인 항목 0, 파일 0, 관측기 훅 0이었다.

여기서 값을 치른 교훈은 재고표의 방향이다. 도구를 모으는 일과 재는 일은 다른 일이고, 전자가 후자를 계속 뒤로 민다. 재고표에 「보유」 칸만 있으면 그 표는 도입을 막는 게 아니라 도입을 정당화한다 — 목록이 길수록 「우리는 이미 잘 갖췄다」로 읽히기 때문이다. 「마지막으로 켠 날짜」 칸 하나가 그 방향을 뒤집는다. 날짜가 비어 있으면 그건 자산이 아니라 미결 항목이다.

도입 판정은 긴 검토가 아니라 측정 세 줄로 끝났다

기능 대조표를 오래 그려서 판정이 난 편은 거의 없다. 실제로 판정을 가른 것은 명령 몇 줄이었다.

npm 플러그인 하나는 별 2,575개에 커밋 250건짜리였는데, 판정은 세 줄에서 끝났다. where dsh 결과 없음, ~/.dsh 없음, 전역 npm 패키지 9종에 그 생태계 0건. peer 의존 18종 중 15종이 그 생태계인 플러그인이라 설치 경로 자체가 존재하지 않았다. 「지금은 안 맞는다」가 아니라 「호스트가 없다」다. 이미지 마스코트 스킬은 스킬 99종의 문서 전문을 이미지 생성 낱말로 훑어 히트 8건이 나왔는데 전부 오탐이었다 — dall 이 ReadAll·findAll 안에 걸린 것이었다. 로컬 생성 스택 0, 세션 도구 로스터에 생성 도구 0. 어떤 데스크톱 에이전트는 요구 사양이 macOS 15 이상인데 내 PC는 두 대 다 Windows 11 이었고, 명령줄 도구 쪽은 설치 스크립트가 macOS 가 아니면 즉시 종료하도록 확정적으로 막혀 있었다.

측정이 세 줄로 안 끝난 경우도 판정은 결국 명령 출력이 냈다. 별 181,214개짜리 하네스는 README 첫 줄의 설치 명령을 격리 폴더에서 300초 제한으로 돌렸더니 로그 0바이트로 침묵하다 타임아웃(EXIT=124) 했다. 같은 명령에 --legacy-peer-deps 만 붙이면 30초에 끝나므로 원인은 네트워크가 아니라 peer 의존 그래프였고, 그렇게 깔면 430패키지 260MB 가 들어오는데 첫 실행이 ERR_MODULE_NOT_FOUND 로 죽는다. 부팅에 반드시 필요한 아홉 개가 전부 peerDependencies 로 선언돼 있는데 그 플래그가 정확히 peer 를 안 깔기 때문이다. 빠진 의존을 손으로 채워 넣자 884ms · EXIT=0 으로 떴다 — 문서 어디에도 없는 경로다. 설치를 세 번 재는 데 든 시간이, 기능 대조표를 그렸다면 걸렸을 시간보다 훨씬 짧다.

여기서 값을 치른 교훈은 매몰비용이다. 검토를 오래 하면 도입하고 싶어진다 — 들인 시간이 판정에 섞이기 때문이다. 측정을 먼저 하면 그 시간이 쌓일 틈이 없고, 기각이 취향이 아니라 명령 출력으로 남는다. 「얼마나 개선되나」보다 「개선할 게 있나」를 먼저 묻는 순서 자체의 근거는 기준선 편에 있다.

적대 검증은 남의 비판 글이 아니라 대상 자신의 자료로 한다

간판 수치를 무너뜨린 결정적 증거는 거의 매번 대상 자신의 자료 안에 있었다. 외부 비판을 찾으러 갈 필요가 없었고, 오히려 외부 비판 쪽이 두 번 틀렸다.

어떤 플러그인의 README 첫 줄은 「기동 시 ~325KB 코어」였는데, npm tarball 다섯 버전을 직접 열어 재니 405 · 424 · 459 · 482 · 585KB 였다. 발행된 다섯 중 간판 값이었던 것은 하나도 없다. 같은 저장소의 청크 로더 주석은 세 번째 숫자(~1MB)를 내놓는다.
게이트웨이 하나가 내건 「평균 89.2% 토큰 절감」은 1 − (1−0.80) × (1−0.46) 이라는 곱셈 한 줄이었다. 두 압축기가 서로 다른 잉여를 먹는다는 가정 위에서만 참인데, 레포에 그 독립성을 잰 데이터가 없다.
같은 레포의 「기여자 500+」는 전수 페이징으로 368명이었다. API 상한이 500이라 상한에 막힌 것도 아니다. 커밋 6,225건 중 3,822건(61%)이 한 사람이다.
같은 레포의 「291 프로바이더 · 테스트 25,000+」에서 왕복 검증에 해당하는 것은 e2e 42 · integration 124 뿐이었다.
어떤 보고서의 간판 「코드량 −54%」를 보고서 자신이 선언한 정의(태스크 단위 평균)로 재계산하면 −35.4% 다. 그중 17.7포인트가 태스크 두 개에서 나오고, 백엔드 여섯 태스크만 보면 −22.2% 다.
별 84,277개짜리 프로젝트를 소개한 2차 출처 여럿이 라이선스를 MIT라고 적었는데 실제로는 AGPL-3.0 이었고, 포크를 10,000개라고 적었는데 실제로는 187개였다. 도입 판단을 통째로 뒤집는 오보다.
어떤 도구의 홍보 표 안에 반례가 그대로 남아 있었다 — 코드량은 80%로 줄었는데 토큰은 107% 다. 짧게 쓰게 했는데 총량이 늘었다는 뜻이고, 그 표를 만든 것은 도구를 파는 쪽이다.
대상이 자기 문서에 써 둔 검증 방법을 대상 자신에게 돌리자 내 1순위 채택이 붕괴했다. 「무가이던스 대조군을 반드시 넣어라」가 그 문서의 규칙이었고, 대조군을 실제로 만들자 내 코퍼스가 오히려 덜 편중돼 있었다.

숫자만 그런 게 아니다. 대상이 자기 규칙을 자기한테 안 돌린 흔적도 대상의 저장소 안에 그대로 있었다. 어떤 린터 플러그인은 자기 소스에 자기 플러그인을 한 번도 돌린 적이 없었고, 어떤 하네스는 게이트 39종 중 일부가 어떤 CI 에도 배선돼 있지 않았으며 그 미배선분이 기본 브랜치에서 빨간불이었다. 39는 「돈다」가 아니라 「있다」는 뜻이었다. 어떤 채팅 스택은 벤치마크 워크플로가 disabled_manually 에 실행 이력 0건이었다 — 결과 디렉터리가 「아직 안 만든 것」이 아니라 그걸 만드는 유일한 잡이 꺼져 있는 것이었다.

여기서 값을 치른 교훈은 검증 순서다. 남의 비판 글은 출처와 시점이 불명이라 그것을 검증하는 데 원 조사만큼 시간이 든다. 대상 자신의 자료는 반박 불가능한 1차 증거라 공짜다. 그래서 순서를 「대상이 자기 입으로 한 말들끼리 맞는지」부터로 고정했다 — 이 순서를 지키면 적대 검증의 대부분이 읽기만으로 끝난다.

별과 도입 사이에는 상관이 없었다 — 표본을 내가 안 골라서 확인했다

마흔 편 중 본문에 별 수를 명시한 편은 열하나다. 그 열하나를 자릿수 밴드에 떨어뜨리면 별과 도입 사이에 아무 관계도 안 보인다. 가장 별이 많은 181,214개짜리는 기각됐고, 유일하게 실제로 들어온 도구는 5,894개로 한가운데에 있다.

2026-08 측정. 정확값은 각 편의 본문에 있다 — 181,214 · 84,277 · 41,856 · 16,619 · 5,894 · 3,481 · 3,313 · 2,858 · 2,575 · 1,023 · 481.

별이 왜 근거가 못 되는지는 별 181,214개짜리 하네스가 스스로 보여 줬다. 내 수집기가 08-20 07:11 에 잡은 값이 170,925, 뜯기 시작한 08-22 아침이 181,170, 표를 채운 시점이 181,214, 그 문단을 쓰는 시점이 181,723 이었다. 이틀에 +10,798, 글 쓰는 몇 시간에 +553. 별을 근거로 쓰려면 측정 시각을 같이 적어야 하는데, 시각을 적는 순간 그 값이 몇 시간 단위로 움직인다는 게 드러난다. 별 84,277개에 포크 187개라는 450 대 1 비율도 같은 방향이다 — 정상적인 오픈소스는 대개 5~20 대 1 이고, 450 대 1 은 스타는 눌렀지만 코드는 안 만진다는 뜻이다.

여기까지는 내가 고른 표본이니 확증 편향일 수 있다. 그래서 고르는 주체를 기계로 바꿔 봤다. 수집기가 긁어 온 피드에서 순서대로 다섯 편을 전수로 뜯었다 — 무엇을 뜯을지 내가 정하지 않았다는 뜻이다. 다섯의 별을 다 더하면 19만이 넘는데, 판정은 오히려 더 짰다 — 채택 0, 보류 1, 기각 4. 유일한 보류였던 공개 5일차 별 2,858개짜리는 중재 장치 자체는 볼 값이 있었지만, 대상이 스스로 방어선이라 내건 셋(CI 가드·벤치마크 재현·배포 채널)이 실측에서 전부 깨졌다.

한 가지는 분명히 해 둔다. 기법 수확은 도구 도입과 별개 축이다. 도구가 0이어도 기법이 한둘 넘어온 편은 있고, 이 절이 「도입 0」이라고 말할 때 그것은 설치된 물건의 수를 말하는 것이지 그 조사에서 아무것도 안 남았다는 뜻이 아니다.

별이 못 하는 일이 하나 더 있다. 그 별이 어느 저장소의 것인지도 보증하지 않는다. 별 16,619개짜리 표식 스캐너를 뜯을 때 내 후보 목록에는 같은 이름의 다른 계정 저장소가 올라와 있었다. 피드에 실린 것과 후보로 뜬 것이 다른 물건이었고, 별 수만 보고 있었으면 그 차이를 못 봤을 것이다.

여기서 값을 치른 교훈은 별의 용도다. 이 원장에서 별은 판정 입력이 아니라 「이 조사가 언제 것인가」를 표시하는 스탬프로만 쓴다. 스탬프로 쓰면 값이 움직이는 게 문제가 아니라 오히려 기능이 된다 — 반년 뒤에 이 글을 읽는 사람이 「이 수치는 그때 것」이라고 바로 알아본다. 버전 문서가 왜 늘 낡는지는 버전 문서 편에 따로 적었다.

1차 수확은 거의 항상 부풀려져 있었다 — 58에서 5.5로 줄었다

발행본 kpi 줄에 「N → M」이 남은 편이 열 개 있다. 왼쪽이 1차 검토에서 세운 도입 후보 수, 오른쪽이 확정 수확이다. 합치면 58에서 5.5, 감축률 90.5% 다.

수치는 각 편의 발행본 kpi 줄에서 그대로 가져왔다. 제외한 두 편은 1 → 43(늘어난 쪽)과 워크플로 200 → 0(수확 축이 아닌 쪽)이다.

깬 것은 남의 비판이 아니라 내 실측이다. 어떤 디자인 시스템 레포에서 기법 일곱을 수확이라 적어 놓고 각각에 「내가 이미 겪은 사고」까지 붙여 뒀는데, 나흘 뒤 내 환경을 실측하고 다섯을 지웠다. 이미 갖고 있거나 인과가 헛다리였다. 특히 한 건이 나빴다 — 과거에 겪은 사고와 그 레포의 기법을 그럴듯하게 짝지어 놨는데 그 사고의 원인은 그 기법이 막는 것이 아니었다. 이 오류는 대상 쪽 자료를 아무리 정독해도 안 잡힌다. 내 설정 파일을 열어야만 잡힌다. 「내 쪽 원인이 무엇이었나」는 대상의 문서 어디에도 없기 때문이다. 살아남은 둘은 둘 다 훅 하나짜리였고, 그마저 차단하지 않고 경고만 하는 모드로 먼저 돌렸다.

정정은 수확 쪽에만 붙은 게 아니다 — 어떤 린터 플러그인 편에서는 오탐을 2건이라 셌는데 실제로는 3건이었다. 한 파일을 빠뜨려 놓고 「전수」라고 적었다. 같은 편에서 동기화 게이트가 「사본이 낡는 걸 못 잡는다」고 적어 뒀는데, 실측하니 낡은 사본이 0건이었다. 조립 단계가 매번 전량 재복사를 해서 그 실패 모드가 이미 없어져 있었다. 그대로 켰으면 첫 실행에 허위경보 열 건이 떴을 것이다. 이런 정정을 최종본에서 지우지 않고 남기는 이유는 증거 등급 편에 적힌 것과 같다. 그쪽에서는 남의 레포를 README만 읽고 요약했다가 두 군데가 서로 반대 방향으로 틀렸고, README 는 거짓말을 안 했다 — 6등급 증거를 1등급으로 읽은 것이 나였다.

이 열 편이 어떻게 뽑혔는지도 적어 둔다. 발행본 kpi 줄에 「N → M」이 남은 전량이고, 같은 모양인데 뺀 것이 둘 있다. 하나는 규칙 1개가 43곳으로 늘어난 편이라 방향이 반대이고, 하나는 워크플로 200 → 0 이라 세는 대상이 수확이 아니다. 뺐다는 사실을 여기 적는 이유는, 안 적으면 다음 사람이 「N → M」을 grep 해서 열둘을 얻고 합계가 안 맞는다고 생각하기 때문이다.

여기서 값을 치른 교훈은 1차 판정을 지우지 않는 것이다. 1차를 지우고 최종본만 남기면 감축률이라는 지표 자체가 사라진다. 그러면 다음 조사에서도 1차 수확 일곱을 그대로 믿게 되고, 「일곱을 적었으니 일곱만큼 값이 있다」가 착수 근거로 재사용된다. 90.5% 라는 숫자가 하는 일이 정확히 그거다 — 1차 수확 목록을 착수 근거로 쓸 수 없게 만드는 것.

판정 칸은 셋이 아니라 넷이다 — 적용 불가가 따로 있어야 한다

채택 / 보류 / 기각 세 칸으로는 「내 쪽에 걸 자리가 없다」가 기록되지 않는다. 실제 판정표를 보면 이 부족이 눈에 보인다. 어떤 프리셋 묶음의 판정표에는 「마운트 지점 부재」와 「이미 있음, 이득 0」이 다른 사유로 나란히 적혀 있다. 둘을 같은 「기각」으로 압축하면 재개 조건이 정반대인데 그 구분이 사라진다 — 앞은 내 하네스에 훅이 생기면 열리고, 뒤는 내 하네스가 그 기능을 잃어야 열린다.

칸이 늘어난 표도 있다. 어떤 데스크톱 에이전트의 판정표는 다섯 칸이 실제로 다 쓰였다 — 기각(플랫폼) / 점검 후 결정 / 보류 / 이미 보유 / ⚠금지(자가 채점 벤치마크는 인용 불가). 마흔 편 중 재제안 금지를 따로 적어 둔 편은 두 편이다(재제안 정규식 전수 grep). 그 둘은 「별이 붙거나 모드가 늘어도 설치 불가라는 사실은 안 바뀐다」처럼, 무엇이 바뀌어도 판정이 안 바뀌는 이유를 같이 적어 뒀다.

칸이 부족하면 무슨 일이 나는지도 실제로 봤다. 「내가 이미 갖고 있다」가 「대상이 별로다」로 압축돼 남았고, 그 결과 같은 공백을 다른 레포로 메우겠다는 조사가 다시 착수됐다. 압축의 방향이 나쁘다 — 「내 쪽 사정」은 다음 사람(반년 뒤의 나)이 복원할 수 없고, 「대상이 별로다」는 복원할 필요가 없는 것처럼 보인다. 그래서 네 번째 칸의 값어치는 판정 그 자체가 아니라 사유의 보존에 있다.

한 가지는 구분해 둔다 — 이 네 칸은 테스트 결과의 판정 다섯 종과 다른 축이다. 도입 판정은 「이 물건을 내 환경에 들일 것인가」를 정하고, 테스트 판정은 「이 실행 결과를 무엇으로 부를 것인가」를 정한다. 후자는 판정 임계 편이 다룬다. 두 축을 한 표에 섞으면 칸 이름이 겹쳐 보여서 둘 다 못 쓰게 된다.

여기서 값을 치른 교훈은 칸의 가격이다. 판정 칸이 부족하면 사유가 아니라 결론만 남는다. 결론만 남은 기각은 반년 뒤의 나에게 아무 정보도 주지 않고, 정보가 없으면 조사는 반복된다. 칸을 하나 늘리는 비용이 조사를 한 번 더 하는 비용보다 훨씬 싸다.

조건을 적어도 반복됐다 — 그 조건이 대상의 변화로 쓰여 있었기 때문이다

마흔 편 중 재개 조건을 적어 둔 편을 세어 봤다. 「재개 조건」이라는 말 그대로 쓴 편이 16, 「다시 여는 조건」·「여는 조건」까지 넣으면 21 이다(정규식 재개 ?조건|(다시 )?여는 조건, 2026-08-23 전수). 표현이 통일돼 있지 않아 좁은 쪽 정규식 하나로는 다섯 편을 놓친다. 이건 사소한 표기 문제가 아니다 — 조건은 적어 놓고 찾을 수 없으면 안 적은 것과 같다. 반년 뒤에 재개 조건을 훑어보려는 사람은 정규식을 한 번밖에 안 돌린다.

그런데 문제는 개수가 아니었다. 조건을 적어 둔 편에서도 같은 질문이 다시 열렸다. 「남의 프리셋 묶음을 통째로 도입할까」에 세 번째로 같은 답을 낸 편이 있는데, 앞선 라운드의 판정표에는 재개 조건이 명시돼 있었다. 조건이 없어서 반복된 게 아니다. 조건이 대상의 변화로 쓰여 있어서 반복됐다 — 「모드가 늘면」·「별이 붙으면」 같은 문장은 매일 조금씩 참이 되지만 아무것도 발동시키지 않는다.

내 환경의 변화로 쓴 조건은 모양이 다르다. 같은 편이 적어 둔 재개 조건 셋이 그 예인데, 셋 다 주어가 내 쪽이다 — 내 하네스에 없던 훅이 생길 때, 내가 통계적으로 유의한 비교를 할 수 있게 될 때, 내가 대조군을 만들 수 있게 될 때. 대상이 무엇을 하든 하나도 안 열리고, 내 쪽이 바뀌어야만 열린다. 한 걸음 더 나간 편도 있다 — 어떤 macOS 전용 도구에는 재개 조건 다섯에 추적 지점까지 붙였다. 설치 스크립트의 분기가 늘어나는지, 다운로드 페이지에 버튼이 생기는지. 체인지로그를 전량 읽으니 Windows 가 세 번 등장했고, 판정은 그대로 기각이지만 조건의 성격이 「언젠가」에서 「도래 가능」으로 바뀌었다.

여기서 값을 치른 교훈은 조건의 주어다. 재개 조건은 대상이 아니라 내 환경의 변화로 쓴다. 「별이 더 붙으면」이나 「버전이 오르면」은 조건이 아니라 기한 없는 유예이고, 그 문장은 반년 뒤에 아무것도 발동시키지 않는다. 판별법은 간단하다 — 그 문장을 읽고 「무엇을 확인하면 되는지」가 바로 떠오르지 않으면 조건이 아니다. 「조립 단계에 컨텍스트를 빼는 훅이 열릴 때」는 내 하네스 설정 한 곳을 보면 되고, 「모드가 늘면」은 볼 곳이 없다.

수확 0의 조사가 값이 제일 컸다

가져올 게 하나도 없던 조사가 일곱 편 있다. 그리고 그 일곱이 서로 모르는 채로 같은 결론에 도달했다 — 대조표를 끝까지 채우면 대상이 아니라 내 쪽의 빈칸이 드러난다는 것이다. 개별 사례가 새로운 게 아니라, 독립적으로 일곱 번 같은 자리에 도착했다는 집계가 새롭다.

기법 0종 — 그 시스템의 원칙 하나를 자로 삼아 내 코드를 재니 관문이 두 벌이었고, 게이트웨이를 우회해 명령을 직접 부르는 곳이 7개 파일 14건이었다.
수확 0 — 남의 자가채점 6항목을 내 스킬 99개에 전수 적용하니 description 이 없어 자동 호출이 안 되던 스킬 1건과 500줄을 넘긴 16종이 나왔다.
설치 0 — 그 레포의 교리 문서를 자로 삼아 내 스킬 96개를 재니 호출 축이 걸린 건 1개였고, 나머지 95개의 설명 20,672자가 매 턴 상시 로드되고 있었다.
수확 1종 — 그런데 실제 산출은 내 다른 파이프라인 두 곳에 인수 게이트를 붙인 것이었다. 실패 케이스 10건 전부 잡고 정상 12건 전부 통과, 오탐 0. 게이트를 왜 그렇게 설계했는지는 무인 회귀 편에 있다.
스킬 285개 중 도입 1 — 유일하게 못 가진 축을 채울 도구였는데, 그 도구가 내 환경에서 안 돌았다.
영상이 「핵심」이라 부른 기능은 내 런 52개에서 발동이 1회였고, 실제 이득은 지나가듯 언급된 병렬 실행 쪽이었다 — 런당 중앙값 9.9분 절감.
별 16,619개짜리 스캐너를 뜯어 남은 것은 내 규칙 문서 한 줄을 내 배포 스크립트 한 줄이 어기고 있더라는 자기 대조 1건이었다.

일곱 편의 공통 구조는 이렇다. 대상에서 가져올 것은 없는데 잴 자가 하나 나온다. 그 자를 내 코드에 대면 대상을 볼 때는 안 보이던 것이 보인다. 남의 원칙으로 내 물건을 보면 내 원칙으로 볼 때 생기는 사각이 없기 때문이다. 그 자가 안 돌 때조차 값이 났다 — 스킬 285개짜리 레포에서 유일하게 못 가진 축을 채울 도구를 골랐는데 그것이 내 환경에서 안 돌았고, 안 돈 이유의 유력 가설이 그 레포 자신이 표로 정리해 둔 붕괴 모드였다.

여기서 값을 치른 교훈은 원장의 칸이다. 배울 게 없는 자료일수록 대조표를 끝까지 채우게 되고 빈칸은 거기서 드러난다. 그래서 원장에 「안 만들어도 되게 된 것」 칸을 따로 뒀다 — 그 칸이 없으면 최대 성과였던 일곱 편이 전부 「수확 0」으로만 기록되고, 다음번에 비슷한 자료를 만나면 「저번에도 0이었으니 열지 말자」가 착수 판단이 된다.

못 한 것

도입률 1/40 은 도구들의 성적표가 아니다. 표본이 내 환경 하나이고, 마흔 편 전부에서 판정을 가른 것이 대상이 아니라 내 쪽이었다는 게 이 글의 주장이다. 같은 마흔 건을 다른 환경에서 재면 목록이 달라지는 것이 정상이고, 이 글은 「이 도구들이 안 좋다」의 증거로 인용될 수 없다.
재개 조건 스물한 개를 적어 놓고, 조건이 실제로 발동해 재조사에 들어간 적은 0회다. 조건이 잘 그어졌는지 — 너무 빡빡해서 영영 안 열리는지, 너무 헐거워서 아무 때나 열리는지 — 아직 모른다. 지금 받쳐지는 것은 「조건을 대상의 변화로 쓰면 발동하지 않는다」까지이고, 「내 환경의 변화로 쓰면 발동한다」는 아직 안 받쳐졌다.
마흔 편을 전부 내가 뜯고 내가 채점했다. 생산자와 채점자가 같다. 58 → 5.5 라는 감축률도 내가 셌고 「1차 수확」의 정의도 내가 사후에 정했다. 독립 재검증은 없고, 이 원장에서 6등급 증거(자가 보고)에 해당하는 자리가 바로 여기다.
기각 사유 분류에는 산식이 없다. 이 글의 첫 표는 네 축에 편 이름을 나열하지만, 그 축을 어떻게 나눴는지는 내 판단이다. 편마다 「이 편은 어느 축인가」를 다시 물으면 다른 사람은 다르게 넣을 것이고, 그래서 축마다 숫자를 먼저 쓰지 않고 이름을 나열했다. 나열은 검증 가능하고 분류는 아니다.
기각한 서른아홉 건이 실제로 값이 없었는지는 못 잰다. 기회비용을 재려면 기각한 것 중 일부를 무처리로 도입해 보는 홀드아웃이 필요한데, 그런 대조군을 만든 적이 없다. 「도입했으면 손해였다」가 아니라 「도입할 근거를 못 찾았다」까지가 전부다.
별 수치는 2026-08 스냅샷이다. 「별은 도입을 예측하지 못한다」는 명제는 스냅샷과 무관하게 성립하지만, 각주의 개별 숫자는 읽는 시점에 이미 틀려 있다. 그래서 도판을 자릿수 밴드로 그렸다.
절차를 지켰는데도 틀린 경우를 아직 못 세고 있다. 이 글은 「측정을 먼저 하면 판정이 정확해진다」를 마흔 건으로 받치는데, 측정을 먼저 하고도 판정이 뒤집힌 편이 몇인지는 안 세어 봤다. 그 숫자가 0이 아니면 이 절차에도 구멍이 있다.