AI 코딩 에이전트는 테스트 기법을 제대로 못 쓴다 — 대너 루의 실험

코딩 에이전트가 좋은 테스트 기법을 쓰도록 만들면 소프트웨어 품질을 특정 수준까지 끌어올리기가 그 어느 때보다 쉬워졌다는 기대가 있다. 그러나 실제로는 소프트웨어 품질이 오히려 나빠지는 것처럼 보인다. 이는 개발자들이 쓰는 기본 설정이 잘 작동하지 않는다는 신호다. 대너 루(Dan Luu)는 이 지점을 파고들어, 테스트에 대한 전문성이 없는 사람이 "이런 기법을 써야 한다더라" 정도의 감으로 에이전트에게 특정 기법이나 라이브러리를 지시했을 때 구현 정확도가 실제로 좋아지는지를 실험했다.

실험은 앞선 프로그래밍 언어 비교에서 쓰였던 Zstd 구현 평가를 재활용했다. Zstd를 구현하라는 동일한 프롬프트에 "테스트 주도 개발(TDD)을 사용하라", "Lean 4를 사용하라", "QuickCheck를 사용하라", "속성 기반 테스트(property-based testing)를 사용하라" 같은 문구를 덧붙여 조건을 나눴다. 모든 구현은 Rust로 이뤄졌고, ACL2·Alloy·Creusot·Kani·Verus·TLA+·Spin 같은 정형 기법부터 퍼징, 차등 테스트, 변이(mutation) 테스트, 메타모픽 테스트, Proptest·rstest·Insta 등 라이브러리까지 총 26개 프롬프트 조건이 비교됐다. 여기에 스킬 4종(공식 Hegel 스킬, 깃허브 스타 25만·포크 3.8만의 ECC Rust 테스트 스킬, Trail of Bits 속성 테스트 스킬, 저자가 직접 쓴 스킬)도 포함됐다. 평가는 codex(GPT-5.6 Sol)로 medium과 xhigh 두 노력 수준에서, 조건별 평균 80회 실행으로 진행됐다.

무엇도 압도하지 못했다

결과를 담은 그래프는 x축에 비용, y축에 숨겨진 테스트를 100% 통과한 실행 비율을 놓았다. 핵심은 어느 조건도 다른 조건을 크게 압도하지 못했다는 점이다. 오히려 아무 추가 지시가 없는 Default 조건이 평균을 훌쩍 웃돌았다. xhigh에서는 퍼징과 속성 기반 테스트 계열이 정형 기법보다 평균적으로 약간 나았지만, medium에서는 훨씬 뒤섞인 양상이었다. codex가 추천한 테스트 스킬들은 오히려 부진했고, 저자가 급조한 커스텀 스킬은 그럭저럭했다. 차이는 명확했다. 다른 스킬들이 튜토리얼에 가까운 반면, 저자의 스킬은 에이전트의 비생산적 기본 습관에서 벗어나도록 밀어붙이게 설계됐기 때문이다. 예상대로 TDD는 좋은 성적을 내지 못했고, 에이전트에게 TDD를 시키던 스킬 역시 그 지시를 따를 때 부진했다.

이름만 주면 겉핥기로 흉내 낸다

에이전트가 실제로 한 일을 들여다보면 문제가 뚜렷해진다. 이들은 도구나 기법을 제대로 다룰 줄 모른다. 게리 번하트(Gary Bernhardt)의 표현처럼, 에이전트의 테스트 방식은 15년 전 목(mock)을 실제로 써보지도 않고 비판하던 이가 상상한 병리적 사례를 테스트 전략의 근간으로 삼는 것과 비슷하다. 특정 기법을 지정해도 이 습성은 별로 바뀌지 않는다. 에이전트는 평소에 쓰던 테스트를 그저 다른 기법의 프레임워크 안에 집어넣거나, 기법을 피상적으로만 걸치고 정작 그 가치를 뽑아내는 핵심은 건드리지 않는다. 정형 기법에서는 무관한 속성들을 증명하고, 속성 기반 테스트에서는 완전 무작위 입력에 기대 대부분 유효하지 않은 입력만 걸러내거나, 사소한 속성 하나를 잡아 저가치 무작위 케이스만 돌리는 식이었다. IMAP RFC(조건별 40회 실행)나 다른 RFC에서도 결과는 다르지 않았다. 문제 유형과 무관하게, 에이전트는 정형 기법이든 테스트 라이브러리든 효과적으로 쓰지 못했다.

xhigh에서는 자신이 짠 테스트를 통과시키긴 했으나, 그 테스트 자체가 부실했다. 예컨대 네 개의 비트스트림을 쓰는 기능을 검증하면서 동일한 비트스트림 네 개를 넣어, 스트림 순서를 뒤바꿨을 때 생기는 버그를 아예 잡지 못하는 식이다. 노력 수준을 낮춰 단순 루프로 돌리면 이런 경향이 더 심해지고 정확도도 더 떨어졌다.

Verus 사례가 보여주는 것

Verus는 SMT 솔버와 여러 추론을 동원해 코드가 명세와 일치함을 증명하는 도구다. 그런데 에이전트는 실제 코드를 검증하는 대신 Zstd에 관한 추상적 속성만 증명했다. 증명한 속성은 수도 적고 내용도 시시했다. "유효한 커서/인덱스/거리가 주어지면 연산 결과가 범위 안에 머문다" 같은 것으로, 나쁘진 않지만 버그의 근원은 아니었다. 심지어 A ⇒ A 형태의 공허한 증명을 쓰기도 했다. 버그가 날 만한 부분, 이를테면 인코딩과 디코딩에서 비트스트림 순서를 뒤집는 처리는 증명을 피했고, 회문(palindrome)형 테스트로는 이런 결함을 잡을 수 없었다. 네 스트림 점프 테이블 기능의 경우 Verus 조건은 160회 중 89회 테스트를 작성했는데, 공교롭게 Default와 정확히 같은 횟수였지만 잘못된 결과를 테스트에 박아 넣거나 공간을 못 덮는 쉬운 테스트를 만들 확률이 더 높았다. Verus 자체가 나쁜 테스트를 강요하는 것이 아니라, 실패는 이렇게 특유하고 우발적이었다.

한국의 실무자 입장에서 이 실험이 주는 함의는 분명하다. 에이전트에게 라이브러리나 기법의 이름만 던져주는 것으로는 정확성이 오르지 않으며, 오히려 아무것도 지시하지 않은 기본값보다 나을 것이 없다는 것이다. 효과를 본 것은 튜토리얼식 안내가 아니라 에이전트의 생산성 낮은 기본 습관에서 벗어나게 구체적으로 유도한 프롬프트였다. 도구 선택 논쟁보다, 무엇이 버그를 낳는 부분인지 짚고 그 지점을 겨냥한 테스트를 강제하도록 지시를 설계하는 편이 실질적이다. 저자는 소프트웨어가 제대로 동작하는 것이 에이전트 도입에 중요한데도 AI 연구소들이 테스트를 잘하도록 학습시키는 강화학습 환경을 왜 아직 만들지 않았는지 의문을 던진다. 다만 이 결과는 2026년 9월 시점의 공개 에이전트에 대한 것이며, 표본과 조건 순위에서 강한 결론을 끌어내는 것은 저자 스스로도 경계한다는 점은 함께 기억해둘 만하다.