코딩 에이전트에 TDD를 시켰더니…테스트 두 배, 정확도는 제자리

코딩 에이전트에게 TDD, fuzzing, QuickCheck, Lean 4 같은 이름을 알려 주면 구현이 더 정확해질까. Dan Luu가 공개한 실험의 답은 대체로 ‘아니다’에 가깝다. 테스트 수는 늘었지만 위험한 경로를 겨냥하는 능력은 따라오지 않았고, 아무 추가 지시를 주지 않은 기본 조건이 평균보다 좋은 결과를 냈다.

실험은 Rust로 Zstd를 구현하는 평가를 재사용했다. 기본 설정을 포함해 26개 프롬프트 조건을 만들고, GPT-5.6 Sol의 medium과 xhigh 추론 수준에서 조건별·수준별 평균 80회를 돌렸다. TDD, 차등 테스트, 변이 테스트, property-based testing뿐 아니라 Verus, Alloy, Lean 4, TLA+ 같은 형식 기법도 포함했다. 별도의 테스트 스킬 네 종류도 비교했다.

문제는 도구를 ‘사용했다’는 기록과 실제 검증 가치가 달랐다는 데 있다. 형식 기법을 받은 에이전트는 실제 Zstd 코드의 오류 가능성이 큰 부분보다 자명하거나 무관한 속성을 증명하는 경우가 많았다. property-based testing에서는 무작위 입력이 거부 경로만 반복하게 두거나, 너무 단순한 속성을 검사했다. 차등 테스트도 독립 구현 두 개를 만들기보다 같은 논리를 두 번 써 같은 버그를 복제했다.

TDD 조건은 행동을 눈에 띄게 바꿨다. 에이전트가 작성한 테스트 수가 두 배로 늘었고, 테스트와 구현을 더 자주 오갔다. 그러나 어려운 입력을 놓치거나 잘못된 출력을 정답으로 굳히는 테스트도 늘었다. 작성한 테스트를 모두 통과하는 것과 숨겨진 테스트를 통과하는 것은 달랐다. 코드가 무엇을 어렵게 만드는지 알기 전에 고정 입출력을 먼저 만들면 취약 구간을 비껴갈 수 있다는 해석도 붙었다.

결과를 모든 코딩 작업에 일반화할 수는 없다. 중심 과제는 Rust의 Zstd 구현이고, 저자도 조건 간 세부 순위를 강하게 해석하지 말라고 경고한다. 다만 IMAP RFC와 다른 소규모 평가에서도 도구 이름만 건넸을 때 비슷한 경향이 나왔다. 특정 라이브러리나 방법론을 프롬프트에 추가하는 것만으로 전문적인 테스트 설계가 생기지는 않는다는 신호다.

실무에서 읽을 대목은 간단하다. ‘테스트해’보다 실패 비용이 큰 동작, 비교할 독립 구현, 생성해야 할 경계 입력, 숨겨야 할 평가 기준을 구체화해야 한다. 더 많은 테스트보다 어떤 버그를 놓치면 안 되는지 알려 주는 편이 낫다. 전체 조건과 사례는 실험 원문에 공개돼 있다.