"TDD로 해줘"는 효과가 없었다
26개 프롬프트 조건을 조건당 80회 돌린 실험에서 기법 이름을 대는 지시는 효과가 없었고, 아무 지시 없는 기본 조건이 평균 이상이었다. 효과가 있었던 건 전제를 반박시키는 것과 위험 지점을 특정한 짧은 스킬이다.
결론부터. 코딩 에이전트에게 기법 이름을 알려주는 것은 거의 효과가 없다. "TDD로 해줘", "속성 기반 테스트 써줘", "형식 검증해줘" 같은 지시 말이다. 아무 지시도 하지 않은 기본 조건이 평균 이상이었다.
실험 규모부터
danluu가 Rust로 Zstd를 구현시키는 과제에 26가지 프롬프트 조건과 4가지 스킬을 붙여 비교했다. Codex의 GPT-5.6 Sol을 medium·xhigh 추론 강도에서 조건당 80회씩 돌리고, 숨겨진 테스트를 100% 통과한 실행의 비율을 셌다. 예측을 사전 등록해두고 시작했다.
조건 목록에 TDD, 속성 기반 테스트, 퍼징, 변이 테스트, 메타모픽 테스트, TLA+, Alloy, Lean 4, Kani, Verus, Creusot, SMT 솔버(Z3·cvc5·Yices)까지 들어 있다. 도구는 실제로 설치해 쓸 수 있게 해뒀다.
압도적으로 우수한 조건은 없었고 Default는 평균 이상이었다. 기존 테스트 스킬은 대체로 부진한 반면, 기본 행동을 더 생산적인 쪽으로 유도한 맞춤형 스킬은 좋은 점수를 얻었다.
(원문)
확인된 것 몇 가지 더
- "실수하지 마라"는 점수상 Default보다 조금 높았지만, 관찰된 행동과 결과가 기본 조건의 무작위 변동과 구별되지 않았다.
- 형식 검증을 시켰더니 버그가 잦은 부분이 아니라 자명한 명제를 증명했다. 전제와 결론이 사실상 같은
A => A증명이 많았다. - 속성 기반 테스트를 시켰더니 완전 무작위 입력으로 거부 경로만 반복했다.
- 네 개의 비트스트림을 처리하는 기능에 동일한 스트림 4개를 넣어, 순서를 바꾸는 버그를 잡을 수 없는 테스트를 만들었다.
- 잘못된 기대값을 테스트에 넣어 잘못된 동작을 오히려 고정시키기도 했다.
인기도는 지표가 되지 못했다. 부진했던 기존 스킬 중 하나는 스타 25만·포크 3.8만 규모 저장소의 것이다.
왜 안 되는가
원문의 진단이 정확하다. 기법 이름을 알려줘도 비효율적인 테스트 습관이 그 기법 안으로 옮겨간다. 일반 단위 테스트를 다른 프레임워크 안에 감싸 넣는 식이다. 도구는 바뀌고 사고는 안 바뀐다.
여기서부터는 내 판단이다.
이건 사람에게도 똑같이 일어나는 일이다. "TDD 도입했다"고 테스트가 좋아지지 않는 걸 다들 봤다. 차이는 속도다. 에이전트는 그 잘못된 습관을 지치지 않고 80배 빠르게 반복한다. 나쁜 검증은 검증이 없는 것보다 나쁘다. 통과한 테스트가 안전하다는 착각을 주기 때문이다.
반대편에서 온 사례
같은 날 올라온 개인 기록 하나가 정확히 반대쪽을 보여준다. 혼자 커뮤니티 서비스를 만들던 사람이 "별의 이름을 바꾸면 태그도 같이 바뀌어야 하지 않나" 싶었다고 한다. 구현을 바로 시키지 않고 "구조부터 확인하고 결과만 보고 멈춰" 라고 시켰더니 전제가 뒤집혔다. 이름과 태그는 독립된 구조였고, 자동으로 묶으면 검색 유입이 조용히 끊기는 함정이었다.
AI로 개발할 때 진짜 위험은 못 만드는 게 아니라, 내가 잘못 생각한 걸 너무 잘 만들어주는 것 같습니다.
(원문)
두 글이 같은 곳을 가리킨다. 기법 이름을 대는 것은 효과가 없고, 전제를 반박시키는 것과 이 코드베이스의 위험 지점을 특정해주는 것은 효과가 있다. danluu 실험에서 최고 점수를 받은 것도 범용 튜토리얼 스킬이 아니라 "위험 영역과 의미 있는 입력을 겨냥한 짧은 맞춤형 스킬"이었다.
프롬프트를 이렇게 바꾼다
- ~~"TDD로 구현해줘"~~ → "구현 전에 스키마와 호출부를 읽고 내 전제가 틀린 지점을 말해. 코드는 아직 쓰지 마."
- ~~"속성 기반 테스트 붙여줘"~~ → "이 모듈에서 순서·경계·인코딩이 어긋나면 조용히 깨지는 입력을 먼저 나열해."
- ~~"꼼꼼히 검증해줘"~~ → "네가 쓴 테스트에 일부러 버그를 넣어서 실제로 실패하는지 확인해."
마지막이 특히 중요하다. 원문은 독립적인 재검증 지시가 거의 지켜지지 않았다고 적었다. 시켜놓고 됐다고 믿으면 안 되고, 실행 여부를 눈으로 확인해야 한다.
모르는 것: 이 실험의 과제는 Zstd와 IMAP RFC처럼 사양이 명확한 구현이다. 사양이 흐릿한 제품 코드에서도 같은 순위가 나올지는 원문도 답하지 않았고 나도 모른다. "기법 이름보다 구조를 먼저 잡아라"는 결론은 사양이 흐릴수록 더 맞을 것 같지만, 그건 내 추측이지 실험 결과가 아니다.
댓글
불러오는 중...