저도 CLAUDE.md에 지침을 꽤 열심히 쌓아뒀어요. “코딩 전에 생각하라, 단순하게 짜라, 필요한 것만 고쳐라.” 거기에 TDD도 강제해봤고, 토큰 절약 스킬 파일도 설치해봤습니다. 그런데 어느 순간부터 SDD나 TDD 같은 프로세스 강제는 점점 내려놓고, context engineering과 린터·테스트·자동 검증 같은 결정론적 도구를 다듬는 데 시간을 쓰고 있더라고요. 뚜렷한 근거가 있어서라기보다 손에 남는 결과가 그쪽이 나았거든요. 최근 몇 달 사이 나온 실험들을 읽고 나서야 그 감이 숫자로 확인됐습니다. 좋다더라 방식들을 실제로 측정해봤더니, 수치가 통념과 많이 달랐어요.
TDD를 강제하면 코드 품질이 올라갈까요?
Birgitta Böckeler가 martinfowler.com에 올린 실험(2026년 8월)은 에이전트가 직접 red-green-refactor 사이클을 도는 “fully agentic TDD”를 시도했어요. 소·중·대 크기 3개 greenfield 과제에서 non-TDD와 TDD를 각각 2회씩 돌려 Opus로 블라인드 평가했는데, 결과가 예상과 달랐습니다. TDD에서 품질 우위가 관찰되지 않았고, 오히려 non-TDD가 상위권을 더 많이 차지했어요. 토큰은 TDD가 3배에서 8.5배까지 더 썼는데도요.
왜 이런 결과가 나왔을까요? Böckeler의 설명이 설득력 있었어요. TDD의 핵심 이점, 즉 불안 관리, 설계 강제, red 상태 확인은 인간 개발자를 위한 거라는 거예요. 에이전트는 테스트와 구현을 동시에 작성하기 때문에 red 단계가 “실행은 됐다”만 증명하게 됩니다. 더 흥미로운 관찰도 있었는데, 테스트가 구현과 동일한 로직으로 기대값을 다시 계산하는 tautological test가 나왔다는 거예요. 테스트가 구현의 답안을 그대로 베껴 쓰는 셈이죠.
비슷한 시기에 kunchenguid의 ProgramBench 실험(2026년 6월)도 같은 방향을 가리켰어요. gpt-5.5로 CLI 리버스엔지니어링 과제 192쌍을 matched pair로 비교했는데, TDD를 강제했더니 pass-rate가 52.4%에서 48.8%로 3.6%p 떨어졌어요(p<0.0001). 비용은 $1.12에서 $1.73으로 55% 늘었고, 턴 수도 40에서 67로 증가했습니다.
비용 증가의 구조가 흥미로워요. output 토큰은 26%만 늘었는데, input이 112%, reasoning turn이 248% 증가했거든요. red-green 마이크로사이클마다 전체 컨텍스트를 다시 불러오는 구조였던 거예요. 저자가 딱 맞는 말을 했습니다. “The money buys process, not product.”
숨은 스펙을 모르니 자가 테스트가 불충분했고, “테스트를 통과하는 최소 코드”가 불완전한 제품으로 끝나는 패턴도 나왔어요. TUI 도구 과제에서 터미널 인터랙션 루프를 통째로 빠뜨린 케이스가 그 예입니다.
다만, 두 실험 모두 한계를 명시했어요. 소표본이거나 one-shot 숨은 스펙 세팅이라, 인간 TDD 일반론의 반증으로 읽어선 안 됩니다. TDD가 원래 빛나는 조건, 즉 알려진 스펙과 오래 사는 코드베이스에서의 payoff는 이 실험에서 재현되지 않았을 뿐이에요. Böckeler는 대안으로 mutation testing이나 구조 리뷰 같은 결과 중심 통제를 권고했는데, 이쪽이 더 납득이 갔어요.
CLAUDE.md 행동 지침도 마찬가지
kunchenguid는 같은 세팅에서 AGENTS.md 실험도 했어요. “Think Before Coding, Simplicity First, Surgical Changes, Goal-Driven Execution” 4원칙을 주입했더니 pass-rate가 53.7%에서 51.5%로 2.2%p 하락했고(p=0.005), 79승 111패 2무였습니다. 비용 증가는 5% 남짓이었으니 토큰 낭비는 크지 않았어요.
메커니즘이 재미있었는데, 지침이 코드 줄 수를 줄인 게 아니라 구현 범위를 좁혔어요. SQLite 같은 내장 엔진에 위임하는 대신 제한적인 자체 구현을 선택하는 방향으로 작동한 거예요. “Simplicity First”가 숨은 엣지케이스 탈락으로 이어진 셈입니다. 저자 표현대로 “It reasons itself out of completeness.”
저도 비슷한 지침을 오랫동안 써왔는데, 이 결과를 보고 한 번 빼고 돌려봐야겠다는 생각이 들었어요.
토큰 절약 스킬 3종 실측
JetBrains AI 블로그에서 Denis Shiryaev가 2026년 7월에 3부작 실험을 발표했어요. 흔히 쓰는 토큰 절약 스킬 세 가지를 실제로 측정했는데, 결과가 광고와 꽤 달랐습니다.
Caveman(원시인처럼 짧게 말하기): 65% 절감을 광고하지만 실측은 output -8.5%였어요. 코드·diff·tool call 같은 기술 출력은 압축이 안 되고 narration만 짧아지기 때문입니다. 품질 저하는 검출되지 않았어요. 다만 절감 수치 자체가 측정 횟수에 따라 출렁였는데, 10개 과제를 1회(k=1)만 측정하면 -29.5%처럼 보이다가 3회 반복에서 -6.7%로 내려앉았거든요. “Never trust k=1.”
RTK(shell 출력 압축 hook): 자체 대시보드가 “96.2M 토큰 절약”을 표시했지만, 실제 청구액은 low effort 설정에서 오히려 +7.6% 높아졌어요(p=.004). 내장 Read/Grep이 hook을 우회해서 Bash 호출의 33%만 hook에 도달했고, 이론상 최대 절감은 총 input의 3%에 불과했습니다. 도구가 아낀 토큰을 스스로 집계하는 구조인데, 저자가 딱 잘라 말했어요. “The scoreboard is grading its own homework.” 절감 주장은 당신 청구서가 아니라, 그 도구가 설정한 counterfactual에 대한 주장입니다.
Ponytail(최소 코드 지침): 셋 중 유일하게 신호가 있었어요. median 비용 -10.3%(p=.004), 코드 -15.4%였습니다(광고는 54%). 절감은 over-build 여지가 큰 과제에 집중됐고, 이미 lean한 과제는 효과가 0에 수렴했어요. 함정이 있었는데, 스킬 파일만 설치하면 10세션 중 자체 활성화가 0회였고 플러그인 주입이 따로 필요했습니다.
측정 결과에는 유통기한이 있어요
이 실험들은 전부 특정 모델의 스냅샷입니다. Böckeler는 Sonnet 4.6과 Opus 4.8을, ProgramBench는 gpt-5.5를, JetBrains 실험은 claude-sonnet-5를 썼어요. 저자들 스스로 “다른 모델에 일반화되지 않을 수 있다”고 한계를 명시했습니다.
이 프랙티스들 대부분은 모델의 약점을 보완하려는 스캐폴딩이에요. 성능이 좋아질수록 어제의 베스트 프랙티스가 오늘의 세금이 됩니다. 단계별로 손잡아주는 프롬프팅이 최근 모델에서 덜 필요해진 것과 같은 흐름이에요.
실험 안에서도 근거를 찾을 수 있어요. Böckeler 글에 인용된 Ivett Ördög의 가설이 하나입니다. 학습 데이터에는 요구사항에서 완성 함수로 가는 매핑은 많고, 진짜 단계별 TDD 과정 기록은 드물어요. 강제 TDD는 에이전트가 학습한 작업 방식과 어긋나는 워크플로를 강요하는 셈입니다. RTK 실험도 같은 방향인데, low effort는 비용이 +7.6%였지만 high effort에서는 +0.1%로 차이가 사라졌어요. 추론 여력이 클수록 압축된 출력에 덜 흔들리는 거예요. 같은 도구의 효과가 모델 설정에 따라 뒤집힙니다.
결정적인 근거는 Anthropic이 직접 내놨어요. 2026년 7월 공식 블로그에 올라온 context engineering 글은, Claude 5 세대(Opus 5, Fable 5)로 넘어오면서 Claude Code 시스템 프롬프트의 80% 이상을 제거했는데도 코딩 평가에서 측정 가능한 성능 저하가 없었다고 보고합니다. 예전 모델에 필요했던 행동 규칙과 반복 지시, 워크드 예시가 새 세대에서는 불필요하거나 판단을 제약하는 짐이 된다는 거예요. 그래서 나온 원칙이 “Let Claude use judgement.” CLAUDE.md도 프로젝트의 목적과 특이한 구현 세부사항만 남기고 가볍게 유지하라고 권고해요.
Claude Code를 만든 Boris Cherny의 조언은 한 발 더 나갑니다. YC 인터뷰(2026년 7월)에서 이렇게 말했어요. “Every six months, delete your CLAUDE.md, delete your skills, delete your hooks.” 지우고 나서 모델이 스캐폴딩 없이 무엇을 해내는지 보고, 구체적인 실패를 관찰했을 때만 지침을 다시 추가하라는 접근입니다.
측정 결과에는 유통기한이 있습니다. 모델이 바뀌면 다시 재야 해요. 지금 도움이 되는 스캐폴딩도 다음 세대에서는 짐이 되기도 합니다.
믿음 말고 측정
실험들을 읽으면서 반복해서 보이는 패턴이 있었어요.
첫째, 소표본과 1회 측정은 배신합니다. k=1에서 -29.5%였던 수치가 3회 반복에서 -6.7%로 내려앉은 걸 기억하세요.
둘째, 도구의 자체 리포트를 그대로 믿으면 안 돼요. “96.2M 토큰 절약” 대시보드와 실제 청구서가 반대 방향이었습니다.
셋째, 인간에게 좋았던 프랙티스가 에이전트에게 자동으로 이전되지 않아요. TDD도, CLAUDE.md 지침도 이 패턴에서 벗어나지 못했습니다.
넷째, paired run으로 내 워크로드에서 직접 재야 해요. kunchenguid의 결론이 그래서 설득력 있습니다. “Measure before you adopt a vibe.”
그래서 저는 요즘 지침을 늘리는 대신 두 곳에 투자해요. 모델이 필요한 맥락을 제때 보게 하는 context engineering, 그리고 모델의 판단에 기대지 않는 결정론적 도구요. 프롬프트 속 “테스트를 잘 짜라”에는 유통기한이 있지만, 실제로 도는 테스트와 린터는 모델이 바뀌어도 그대로 남으니까요.
CLAUDE.md에 쌓아둔 지침들, 한 번쯤 빼고 돌려보셨나요?
참고 자료
- Birgitta Böckeler, TDD in the agent loop (martinfowler.com, 2026년 8월)
- kunchenguid, Does test-driven development help a coding agent? (2026년 6월)
- kunchenguid, Do “reduce LLM coding mistakes” guidelines help a coding agent? (2026년 6월)
- Denis Shiryaev, Does Speaking to Agents Like Cavemen Really Save 65% of Tokens? (JetBrains AI 블로그, 2026년 7월)
- Denis Shiryaev, Does ‘rtk’ reduce Claude Code token usage? (JetBrains AI 블로그, 2026년 7월)
- Denis Shiryaev, Ponytail Skill for Claude Code (JetBrains AI 블로그, 2026년 7월)
- Thariq Shihipar, The new rules of context engineering for Claude 5 generation models (Anthropic, 2026년 7월)
- Boris Cherny, Building Claude Code (YC Root Access, 2026년 7월) · 인터뷰 영상: We Cut 80% of Claude Code’s Prompt