ponytail

간판 수치는 무너졌고, 채택은 한 줄입니다. 이 레포의 얼굴인 “코드량 −54%“는 보고서 자신이 선언한 정의로 다시 계산하면 −35.4%이고, 애초에 정답 판정 게이트가 없습니다 — 「코드를 한 줄이라도 썼는가」가 정답 여부입니다. 후보 네 줄 중 근거가 버틴 건 “모든 호출부를 grep하라” 하나뿐이었고, 그마저 전역이 아니라 에이전트 하나에만 넣었습니다. 그리고 이 조사가 실제로 찾아낸 건 남의 룰셋이 아니라 제 룰셋의 자기모순 세 건이었습니다.

무엇을 파는 물건인가

에이전트에게 「일단 만들지 마라」를 상주 주입하는 프롬프트 룰셋이다. 코드를 검사하거나 고치는 도구가 아니다 — 제품의 실체는 위 사다리를 포함한 120줄짜리 텍스트 한 장이고, 레포의 나머지는 그 텍스트를 스무 종의 에이전트 호스트에 꽂고 최신으로 유지하는 배관이다.

별 92,133개, 포크 5,069개, npm 주간 9,166 다운로드. 개설 7주.

사다리에 붙은 조건이 둘 있는데 이게 이 룰셋을 단순한 “적게 만들기”와 가른다.

• 사다리는 문제를 이해한 뒤에 돈다 — 순서를 바꾸면 그냥 대충 하는 것이 된다
• 게으름은 해답을 줄이는 것이지 읽기를 줄이는 게 아니다 — 버그 수정은 “증상 아닌 근본원인, 모든 호출부 grep”으로 못 박혀 있다

잘라내기 금지 목록도 있다. 신뢰 경계 입력검증, 데이터 손실 에러핸들링, 보안, 접근성, 하드웨어 캘리브레이션 노브. 미니멀리즘이 위험해지는 자리를 스스로 표시해 둔 것이다.

뜯어보니 달랐던 것 둘

룰 텍스트가 한 곳이 아니다. 정본이라 부르는 파일 말고도 별도 규약 파일(스무 종 호스트 중 절반 이상이 이걸 읽는다), JS 폴백본, 보조 스킬 다섯 종에 룰이 흩어져 있다. 세 군데에서 네 군데다. 특정 호스트로 한정하면 정본이 맞지만, 레포 전체로 보면 “한 장짜리 제품”이라는 인상과 다르다.

강도 레벨은 실질 차이가 거의 없다. lite / full / ultra 세 단계를 파는데, 실제 주입 텍스트가 5,202자 · 5,229자 · 5,267자다 — 차이가 65자, 1.2%. 내용 차이가 아니라 수사(修辭) 차이다. full과 ultra의 실행 diff를 뜨면 100줄 중 3줄이고 그 3줄에 엣지케이스 처리를 줄일 문장은 없다.

간판 수치가 정의를 바꿔치기했다

“코드량 −54%”가 이 레포의 얼굴이다. 보고서와 README 둘 다 그 수치를 “태스크 단위 평균”이라고 선언한다.

공개된 12태스크 표로 직접 계산하면 태스크 평균은 −35.4%다. −54%는 기준선 코드량으로 가중한 총합 비율이다. 선언한 정의와 실제 계산이 다르다.

그리고 그 −54% 중 17.7포인트가 날짜·색상 선택기 두 태스크에서 나온다. 그 둘을 빼면 −36.5%, 백엔드 여섯 태스크만 보면 −22.2%다.

그런데 더 근본적인 문제가 따로 있다. 정확성 게이트가 없다.

sc = {"correct": 1 if stats.get("total_loc", 0) > 0 else 0, "safe": 1, "reason": "git-diff"}

correct는 “코드를 한 줄이라도 썼는가”이고 safe는 하드코딩된 상수 1이다. 23줄짜리 날짜 선택기가 티켓을 실제로 충족했다는 증거가 이 벤치마크 어디에도 없다.

저자는 이 구멍을 안다. 별도 스크립트를 만들어 놓고 주석에 *“가장 신빙성 있는 공격은 「덜 만들었으니 덜 썼다」이다”*라고 적어 뒀다. 그리고 한 번도 보고하지 않았다.

계측기에도 결함이 있다. 코드량을 셀 때 테스트를 소스에서 빼야 하는데, 판별 함수가 파이썬 관례와 특정 폴더명만 인식한다. 그래서 프론트엔드의 *.test.tsx가 소스로 계산된다. 하네스 스스로 *“테스트는 따로 세며 결코 군더더기로 치지 않는다”*고 선언해 놓고 한쪽 언어에서만 안 지켜지는데, 하필 대승 여섯 태스크가 전부 그 언어다.

정직성은 진짜인데, 기울어진 방향이 전부 같다

이 레포를 깎아내리기 쉬운데 그러면 틀린다. 이 저자는 오염 버그를 자진 발견해 공개하고 이전 결과를 통째로 폐기 처리했고, 불리한 데이터를 실었다 — 백엔드에서 효과가 수렴한다는 것, 어떤 모델에서는 오히려 느리다는 것, 다른 모델에서는 비용이 38.7% 늘었다는 것. 계측기 자체가 자가 검증에 실패하면 API 지출을 아예 거부하는 게이트까지 만들어 뒀다. 이 분야 평균을 크게 웃돈다.

그러니 무너지는 건 정직성이 아니다. 무너지는 건 집계 방식·계측기 선택·태스크 선정·미보고 항목 넷이 전부 같은 방향으로 기울어 있다는 사실이다. 하나였으면 실수고, 넷이 같은 쪽이면 그건 결과가 나오는 구조다.

태스크 선정이 특히 그렇다. 사다리 4칸에 네이티브 날짜 입력이 문자 그대로 예시로 적혀 있고, 헤드라인 1위 태스크가 “날짜 선택기를 추가하라”다. 측정되고 있는 건 일반적인 미니멀리즘이 아니라 그 한 문장의 리콜률이다. 그리고 12태스크 중 미니멀리즘이 손해를 보는 축(접근성 요구, 하드웨어 캘리브레이션 같은 것)이 0개다.

안전 항목도 마찬가지다. README는 안전 태스크가 일곱 개라 하고 재현 명령도 일곱 개를 나열하는데, 보고서는 여섯 개만 싣는다. 빠진 하나가 하필 저자가 비판자에게 답하려고 만든 그 태스크다.

원자료는 공개돼 있지 않다. 보고서가 광고하는 재채점 재현 경로가 제3자에게는 실행 불가능하다.

⇒ 방어 가능한 형태로 남는 주장은 이 정도다. 특정 소형 모델에서, 네이티브 HTML 입력으로 대체 가능한 프론트엔드 티켓에 한해, 검증되지 않은 코드 산출량이 크게 준다.

남은 한 줄 — 그리고 그게 왜 살아남았나

채택한 건 “모든 호출부를 grep하라” 한 줄이다.

레포 자체 벤치에 이런 태스크가 있다. 두 함수가 같은 내부 출금 함수를 공유하는데 버그 리포트는 한쪽만 지목하고, 채점기는 리포트에 이름조차 없는 다른 쪽의 초과 출금을 검사한다. 즉 “리포트에 적힌 것만 고치면 실패한다.”

대조군이 결정적이다. 뜻이 같은 평문 산문 — “흐름을 끝까지 추적하라” — 은 세 번 중 영이었다. 작업지시형 문장만 여섯 번 중 여섯으로 옮겼다.

이게 왜 이 페이지에서 유일하게 살아남았나. 앞에서 무너뜨린 건 전부 코드량 축의 집계 문제인데, 이 항목은 품질 축이라 그 문제가 적용되지 않는다. 그리고 찬반 두 방향의 리뷰가 정반대 결론을 내면서 이 항목 하나에서만 독립적으로 수렴했다.

한계도 같이 적는다. 레포 자체 벤치이고, 표본 6, 태스크 하나, 원자료 미공개. 소형 모델에는 전이되지 않는다(기준선도 실패하는 천장 구간이다).

나머지 셋을 왜 뺐나

• 사다리 2칸(이미 있나) — 레포 자체 벤치가 행동 가치를 입증하지 못했다. 기준선과 ponytail 둘 다 헬퍼를 재사용했고, 중복 실패가 재현되지 않았다
• 사다리 4칸(플랫폼 네이티브) — 효과가 HTML 폼 컨트롤 치환에 집중돼 있다. 제 작업은 게임 엔진 C#·파이썬 테스트·파이프라인 JS 위주라 해당 사항이 없다
• 원라이너 반사 — 제 규칙이 이미 덮고 있다(“200줄이 50줄 되면 다시 써라”)

조사가 찾아낸 건 남의 룰셋이 아니라 제 룰셋이었다

통짜 도입을 검토하면서 제 규칙과 부딪히는 지점을 세었다. 세 건이 나왔다. 그런데 더 큰 게 나왔다 — 제 룰셋이 ponytail 없이도 이미 자기모순 세 건을 안고 있었다.

축	한쪽	다른 쪽
설정성	요청 안 한 설정성 금지	튜닝 노브는 코드 기본값과 같아도 config 키로 뺀다
에러 처리	불가능한 시나리오에 에러 처리 금지	항상 포괄적으로, 모든 레벨에서
투기성	투기적인 것 금지	유닛·통합·E2E 전부 필수, 커버리지 80%

셋 다 상시 로드되고, 어느 쪽이 이기는지가 어디에도 정의돼 있지 않다. 그러니 매 턴 모델이 임의로 정한다.

조항을 더 얹기 전에 이 셋을 재정하는 게 순서다. 그리고 아직 안 했다 — 이 조사가 만든 숙제가 이 조사가 가져온 한 줄보다 크다.

그래서 전역이 아니라 에이전트 하나에만

“전역에 넣으면 어디까지 걸리나”를 추측하지 않고 쟀다. 결과가 나빴다 — 시스템 프롬프트를 통째로 교체하는 자식 프로세스에도 전역 지침은 살아서 넘어간다. 전역에 넣으면 테스트 케이스 생성과 QA 자동화까지 예외 없이 걸리고, 끄는 수단이 없다.

그쪽에서는 “덜 만들기”가 곧 커버리지 구멍이다. 특히 “답을 기본값으로 낼 수 있는 일에 절대 멈추지 마라”는 줄이, 기획서에 근거가 없으면 멈추고 「확인 필요」로 표기하라는 제 규칙을 정면으로 뒤집는다.

그래서 3단으로 좁혔다. 전역 ❌ → 프로젝트 ❌ → 게임 코드를 쓰는 에이전트 하나에만 ✅. 프로젝트 단위도 기각인 이유는 격리가 안 되기 때문이다 — 같은 프로젝트의 QA 에이전트들이 함께 걸린다. 콘텐츠를 만드는 에이전트도 제외했다. 거기서는 양이 곧 값이고, 검증 쪽은 하네스와 픽스처가 자산이다.

그 하나에도 두 줄은 빼고 넣었다. “가능한 한 적은 파일”은 파일을 잘게 쪼개라는 제 규칙과 정면으로 부딪히고, “절대 멈추지 마라”는 불명확하면 멈추라는 첫 번째 규칙과 부딪힌다. 표적을 좁혀도 남는 충돌은 표적을 좁혀서 해결되지 않는다.

⚠ 측정하면서 한 번 틀렸다. 전파 범위 프로브의 1차 결과는 “전역 규칙이 자식에 전달 안 됨”이었는데, 한 번에 두 가지를 물어서 생긴 오탐이었다. 같은 질문으로 대조해 정정했다. 프로브는 한 번에 하나만 묻는다.