diagnosing-bugs (Matt Pocock)

리뷰

Codex CLI 0.166 (gpt-6-astra, low reasoning)을 Mac 테스트 머신에서 실행했고, 실행마다 새 임시 프로젝트와 임시 HOME/TMPDIR/캐시를 사용했습니다. 스킬 설치(스킬 사용군), 미설치(대조군), 미설치 상태에서 스킬의 핵심 요구사항만 한 문장으로 압축해 프롬프트에 덧붙인 경우(한 문장 프롬프트군)로 나눴으며, 과제·그룹당 2회씩 실행했습니다. 네트워크는 끄고 /tmp 쓰기는 차단했습니다. 프롬프트에는 스킬 이름을 언급하지 않았습니다. 채점은 자동화된 프로그램으로 수행했습니다(숨은 테스트 / 심어 둔 문제 탐지율 / 제약 조건 검사 / 해당되는 경우 렌더링+OCR). 실행당 0–5점이며, 어떤 점수도 LLM 심사자가 결정하지 않았습니다.

3개 그룹 비교

Codex CLI에서 18회 실행해 측정했고, LLM 심사 없이 규칙 기반 검사로 채점했습니다. 총점 22.9 / 30, 판정 상황에 따라.

판정: 상황에 따라 (22.9 / 30). 출처: mattpocock/skills, skills/engineering/diagnosing-bugs, 커밋 4ae2317에 고정. 설치: npx skills@latest add mattpocock/skills --skill diagnosing-bugs. 라이선스: MIT(저장소 LICENSE).

무엇인가

Matt Pocock의 스킬 저장소(engineering)에 있는 diagnosing-bugs 스킬입니다. 어려운 버그를 다루는 훈련법으로, 1단계는 '촘촘한 통과/실패 피드백 루프 만들기'입니다(실패하는 테스트, curl 스크립트, CLI diff, 헤드리스 브라우저, 재생한 트레이스). 그다음 순위를 매긴 가설을 하나씩 검증하고, 계측을 추가하고, 회귀 테스트를 작성하고, 정리합니다. 약 1,000단어의 Markdown, hitl-loop.template.sh 도우미 템플릿 하나, 출력을 보여주기 전에 비밀을 가리라는 규칙이 들어 있습니다. 'diagnose', 'debug this', 'something is broken/failing'에 반응해 실행됩니다.

테스트 방법

Codex CLI 0.166(gpt-6-astra, 낮은 추론)을 Mac 테스트 머신에서 실행했고, 실행마다 새 임시 프로젝트와 임시 HOME/TMPDIR/캐시를 사용했습니다. 스킬을 설치한 스킬 사용군, 스킬이 없는 대조군, 스킬 없이 핵심 요구사항을 한 문장으로 압축해 프롬프트 끝에 붙인 한 문장 프롬프트군으로 나눴으며, 작업·군당 2회 실행, 네트워크 차단, /tmp 쓰기 차단 조건이었습니다. 프롬프트에는 스킬 이름을 전혀 언급하지 않았습니다.

1. 작은 함수의 off-by-one — movavg.py의 moving_average가 잘못된 숫자를 반환합니다. moving_average([2, 4, 6, 8, 10], 3)은 [2, 3, 4, 6, 8]이어야 하는데 뒤쪽 값이 잘못 나옵니다. 원인을 찾아 수정하세요. 테스트: python3 -m unittest.
2. 파일 간 날짜 버그 — 주간 보고서 헤더가 연말연시에 잘못된 날짜를 표시합니다. 예를 들어 header('2026-W01')은 'Week 2026-W01: Dec 29 - Jan 04, 2026'이어야 합니다. 원인을 찾아 수정하세요.
3. 실행 순서에 따른 테스트 실패 — tests/test_settings.py의 테스트는 개별 실행하면 통과하지만 파일 전체를 실행하면 test_b가 실패하고, 설정이 이전 호출의 태그를 물고 오는 것처럼 보입니다. 진단하고 수정하세요.

채점은 프로그램 방식(숨은 테스트/심어 둔 문제 탐지/제약 조건 검사/해당되는 경우 렌더링+OCR)으로 진행하며 실행당 0~5점입니다. 어떤 점수도 LLM 심사자가 결정하지 않았습니다.

결과

세 번째 군에 제공한 한 문장 프롬프트: "먼저 이 정확한 버그에서 빨간불이 되는 빠르고 결정적인 통과/실패 피드백 루프를 만드세요(실패하는 테스트가 가장 좋습니다). 그다음 순위를 매긴 가설을 세우고, 수정 전에 증거와 함께 하나씩 검증하세요. 마지막으로 루프를 다시 실행해 수정을 확인하세요."

평균 점수: 스킬 없음 4.31 vs 스킬 사용 4.58(델타 +0.28). 실행당 토큰: 77k vs 133k(1.71배), 시간 38초 vs 51초. 한 문장 프롬프트군: 4.72(한 문장 프롬프트 대비 스킬의 이득: -0.14, 스킬 없음 대비 한 문장 프롬프트의 이득: +0.42). 한 문장 프롬프트는 실행당 126k 토큰이므로 스킬 비용은 한 문장 프롬프트의 1.05배입니다.

무슨 일이 있었나

• 최종 정확성은 세 군 모두 같았습니다. 숨은 테스트가 18/18 실행에서 통과했고 모든 diff가 소규모 diff 한도 안에 머물렀습니다. 심어 둔 세 버그(off-by-one, 파일 간 날짜 로직, 실행 순서에 따른 테스트 오염)는 일반 Codex로도 고칠 만큼 쉬웠습니다.
• 달라진 것은 '코드를 수정하기 전에 테스트를 실행했는가', 즉 먼저 재현했는가라는 과정 검사뿐입니다. 스킬 없이는 1/6 실행이 그렇게 했고, 스킬의 첫 규칙을 한 문장으로 옮긴 경우 4/6, 스킬을 설치한 경우 4/6이었습니다. 즉 그 한 문장이 효과 전체를 재현했습니다.
• 스킬은 어떤 프롬프트에서도 언급되지 않았지만 스킬 사용군 6/6 실행에서 읽혔습니다('debug this'에 반응). 에이전트를 더 많이 움직이게 했습니다. 실행당 명령이 18개로, 스킬 없음 8개, 한 문장 13개보다 많았습니다.
• 비용: 실행당 스킬 133k 토큰으로 스킬 없음 77k(1.71배), 한 문장 126k(1.05배)였습니다. 한 문장 군 자체도 대조군의 1.64배 비용이었는데, 에이전트에게 먼저 루프를 만들라고 하면 단계를 더 실행하기 때문입니다.
• 스킬 사용 실행 하나(공유 상태 작업)는 버그를 고치고 숨은 테스트를 통과했지만, 답변이 저희 근본 원인 검사(원인을 명시하는지 봄)와 맞지 않았습니다. 어느 군에서든 이 검사를 놓친 유일한 실행입니다.

항목별 점수

이 테스트의 한계

• 코드를 읽으면 찾을 수 있는 작은 단일 파일 Python 버그 세 개입니다. 이 스킬은 어려운 버그(간헐적 버그, 성능 회귀, 하네스가 필요한 버그)를 위해 만들어졌지만 그런 것은 테스트하지 않았습니다.
• 스킬의 다른 도구(HTTP/브라우저 루프, 트레이스 재생, 이분 탐색, 계측 태그)는 구동할 앱이 없는 네트워크 차단 샌드박스에서 실행할 수 없습니다.
• '수정 전 테스트 실행' 검사는 이벤트 로그에서 첫 테스트 명령과 첫 쓰기의 순서를 비교할 뿐, 재현의 품질을 판단하지 않습니다.
• 작업·군당 n=2: 약 1점 미만의 차이는 노이즈입니다.
• 규칙 기반 채점은 검사가 볼 수 있는 것만 측정하며, 취향이나 결과가 최선인지는 판단하지 못합니다.

보안

security.md를 참고하세요. 스캔: CRITICAL 0 / HIGH 0 / MEDIUM 0. 판정: 실행해도 안전(네트워크 차단 샌드박스). 깨끗한 스캔 결과가 스킬의 안전성을 증명하지는 않습니다.

결론

이 스킬의 핵심 아이디어는 좋은 습관이고 Codex는 말해 주면 이를 따릅니다. 그러나 그 한 문장만으로도 거의 같은 비용에 같은 '먼저 재현' 행동과 같은 통과율을 얻었고, 쉬운 버그는 어느 쪽이든 에이전트가 고칩니다. 어렵고 간헐적인 버그를 디버깅하며 전체 훈련법을 원한다면 설치해 두세요. 작은 버그라면 첫 규칙을 프롬프트에 넣는 것만으로 이득을 볼 수 있습니다.