이제 "에이전트 기술 (agent skills)"라는 거대한 생태계가 존재합니다. 이는 Claude Code (또는 Cursor, Copilot)에 넣어 모델이 더 깔끔한 코드를 작성하고, 더 주의 깊게 디버깅하며, 토큰을 더 적게 사용하도록 만드는 재사용 가능한 지침 파일 (instruction files)들입니다. 이러한 저장소(repos) 중 일부는 수만 개의 GitHub 스타를 보유하고 있습니다. 하지만 그중 그 기술이 실제로 효과가 있는지 알려주는 단 하나의 수치라도 제공하는 곳은 거의 없습니다.

이 점이 저를 괴롭혔습니다. 왜냐하면 "그럴듯하게 들리는 지침을 추가하는 것"과 "실제로 작동하는 지침을 추가하는 것"은 측정하기 전까지는 완전히 동일해 보이기 때문입니다. 그래서 저는 실행하기 전에 단 하나의 규칙을 담은 벤치마크를 구축하고 이를 확정했습니다:

어떤 기술도 사전 등록된 대상 지표(target metric)에서 지침이 없는 베이스라인(no-instruction baseline)과 플라세보 프롬프트(placebo prompt)를 모두 이기지 못하면 병합(merge)될 수 없다. 이 측정은 정확도가 떨어지지 않는 조건 하에 숨겨진 홀드아웃 테스트(hold-out tests)로 수행된다. 실패한 기술들도 수치와 함께 그대로 공개된다.

플라세보 그룹(placebo arm)은 거의 아무도 실행하지 않는 부분이며, 결과적으로 가장 중요한 부분이 되었습니다.

왜 플라세보인가

무언가를 측정하는 대부분의 "검증된(battle-tested)" 기술 컬렉션들은 기술이 있을 때(skill-on)와 없을 때(skill-off)를 비교합니다. 문제는 이 비교가 "이 기술이 작동한다"는 사실과 "그저 자신감 있게 들리는 텍스트를 추가하는 것만으로도 모델의 행동이 변한다"는 사실을 구분할 수 없다는 점입니다. LLM은 암시를 받기 쉽습니다(suggestible). 당신의 기술이 무언가를 해냈다고 주장하고 싶다면, 실제 메커니즘은 없고 오직 분위기(vibes)만 담긴 동일한 길이의 지침보다 더 뛰어나다는 것을 보여주어야 합니다.

따라서 여기서의 모든 결과는 세 가지 방식의 비교 — off / placebo / on — 로 이루어집니다. 각 그룹당 작업별로 K=5~8회씩 격리된 git 워크스페이스에서 실행되었으며, 에이전트가 결코 보지 못한 홀드아웃 수락 테스트(hold-out acceptance tests)로 채점되었습니다. 모든 원시 실행 로그는 저장소에 커밋되었으며, CI를 통해 해당 로그로부터 README가 재생성되었습니다. 총 516회의 실행이 이루어졌으며, 모두 claude-opus-4-8에서 수행되었습니다.

발견 1: 플라세보는 종종 코드를 더 크게 만들었습니다

나의 과잉 엔지니어링 방지 기술 (underkill, ~20 lines)은 동일한 정확도(60/60 hold-out passes)에서 베이스라인 대비 소스 LOC(Lines of Code)를 -23.8% 감소시켰습니다. 좋습니다. 하지만 흥미로운 지점은 플라세보(placebo) 열입니다. 동일한 길이의 "깨끗하고, 최소한이며, 전문적인 코드를 작성하라"는 지침은 코드를 전혀 줄이지 못했습니다. 오히려 12개 작업 중 8개에서 코드가 증가했습니다 (중앙값 ~+19%).

다시 한번 읽어보세요: 모델에게 깨끗한 코드를 작성하라고 말했더니 코드를 더 많이 작성했습니다. 일반적인 권고는 토큰만 추가했을 뿐 아무런 도움이 되지 않았고, 모델은 그 분위기에 맞추기 위해 코드를 채워 넣었습니다(padding). 만약 제가 지침의 유무(on-vs-off)만 비교했다면 underkill은 좋아 보였을 것입니다. 하지만 플라세보와 비교했을 때, 이는 단순히 지침의 존재 여부 때문이 아니라는 효과를 증명할 수 있습니다.

발견 2: 196k 스타의 기술이 "지침 없음"을 간신히 이겼습니다

현재 생태계에서 가장 많은 스타를 받은 행동 기술은 "Karpathy Guidelines" (~196k stars)입니다. 이는 Andrej Karpathy가 LLM 코딩의 함정에 대해 관찰한 내용을 바탕으로 도출된 네 가지 규칙이며, 그중 하나는 "단순함 우선(Simplicity First): 만약 200줄을 작성했는데 50줄로 줄일 수 있다면, 다시 작성하라"입니다. 이는 underkill이 목표로 하는 정확한 지표에 대한 직접적이고 검증 가능한 주장(falsifiable claim)이므로, 동일한 12개 작업에 대해 비교군으로 실행했습니다.

이 유명한 기술은 플라세보를 명확히 이겼습니다 (-23%). 따라서 그 메커니즘은 단순히 프롬프트의 존재 때문이 아니라 실제적인 것입니다. 하지만 지침이 없는 베이스라인과 비교하면 **-4.8%**로 간신히 앞섭니다. 작은 작업의 경우 Opus는 이미 최소한의 코드에 가깝기 때문입니다. 그리고 나의 집중된 20줄 기술은 동일한 정확도와 약간 더 낮은 비용으로 196k 스타 기술보다 20% 적은 코드를 작성합니다.

이것은 Karpathy 기술을 비하하려는 것이 아닙니다. 그 기술은 네 가지 서로 다른 실패 모드(failure modes)를 다루며, 그중 하나만이 이 축(axis)에 해당합니다. 핵심은 더 좁고 유용한 것입니다: 하나의 특정 실패 모드를 겨냥한 규칙이, 그것을 단순히 언급만 하는 광범위하고 일반적인 규칙 세트보다 낫다는 것입니다. 지침의 _존재(presence)_는 저렴합니다; 지침의 _메커니즘(mechanism)_이 진짜 가치를 만들어냅니다.

결과 3: 나의 4가지 기술 중 2가지가 관문을 통과하지 못함

성공한 사례만 발표한다면 이 실험 전체가 무의미해질 것이기에, 탈락한 기술들과 그 번호를 공개합니다:

• tests-that-bite (테스트 작성 규율 기술): 한계에 부딪혔습니다. 베이스라인인 Opus가 이미 4개 작업 중 3개에서 나의 변이 테스트 (mutation-testing) 변이체(mutants)를 100% 제거했습니다. 나의 변이체들이 차이를 구별하기에는 너무 거칠었습니다 (too coarse). 탈락.
• thrift (토큰 소비 기술): 턴(turn) 수를 14% 줄였으나, 실행당 중앙값 비용(median cost per run)이 베이스라인보다 0.005달러 더 높게 나타났습니다. "비용 및 턴 수"를 공동 주요 기준으로 삼는다면, 이는 반올림 오차가 아니라 탈락 사유입니다.

thrift 실험은 프로젝트 전체에서 가장 직관에 어긋나는 결과를 보여주었습니다. 비교군으로 92k 스타를 보유한 "caveman"식의 간결한 모드 규칙 세트 (terse-mode ruleset)를 실행해 보았는데, 모든 비용 관련 작업에서 지침이 아예 없을 때보다 실행당 비용이 더 높게 측정되었습니다. 에이전트의 비용은 입력값 (읽어들인 파일, 도구 결과, 반복되는 컨텍스트)에 의해 결정되므로, 모델의 출력 (output)을 압축하는 지침은 매 턴 자신의 프롬프트가 추가하는 입력 토큰 (input tokens)을 상쇄할 수 없습니다. 채팅 응답에는 유효한 출력 압축 조언이 에이전트 실행에서는 역효과를 낼 수 있습니다.

이것이 증명하지 못하는 것

작업 단위가 작고 독립적입니다 (350줄 규모의 솔루션). 이는 특정 기술을 검증하기에는 충분하지만, 대규모 코드베이스로 일반화하기에는 부족합니다. K=58의 표본은 증거를 제공할 뿐, 확정적 증명은 아닙니다. 여기서 사전 등록 (Pre-registration)은 내가 제어하는 리포지토리 (repo) 내의 커밋 순서이며, 자기 증명 (self-attested) 방식입니다. 또한 홀드아웃 데이터 (hold-out material)는 동일한 리포지토리에 존재하므로 원칙적으로 접근 가능합니다. 나는 모든 커밋된 실행 로그를 스캔하여 작업 자료에 대한 참조가 있는지 확인하는 CI 체크를 실행합니다 (516/516 통과). 이 모든 내용은 리포지토리의 "알려진 한계 (Known Limitations)"에 기록되어 있습니다. 좋은 소식만 담긴 결과 로그는 신뢰할 가치가 없기 때문입니다.

시도해 보기 / 망가뜨려 보기

두 가지 기술이 관문을 통과했습니다 (underkill, repro-first). 이들은 Claude Code 플러그인으로 설치하거나 npx skills add sjh9714/skill-receipts를 통해 설치할 수 있으며, 설치된 스니펫 (snippet)은 벤치마크에서 측정한 것과 바이트 단위로 동일합니다 (CI가 이를 강제합니다).

만약 당신이 효과가 있다고 생각하는 기술이 있다면 — 당신의 것이든, 혹은 감사를 받고 싶은 유명한 기술이든 — 모두에게 열려 있는 문은 동일합니다: 이슈(issue)를 생성하세요. 저는 이 중 몇몇 결과에 대해 진심으로 제가 틀렸다는 것을 증명받고 싶습니다.

Repo + 모든 원본 로그 (all raw logs): https://github.com/sjh9714/skill-receipts