에이전트는 테스트·검증 기법을 얼마나 잘 쓸까?

TL;DR Highlight

기법 이름만 알려주면 에이전트는 겉핥기만 해서 기본값보다 나아지지 않았다

Who Should Read

코딩 에이전트에 "TDD 써", "fuzzing 써"처럼 테스트 기법을 지시하며 품질을 올리려는 백엔드 개발자

Core Mechanics

기법 이름만 던지면 별 효과 없다
- 26개 프롬프트 조건 중 크게 앞선 조건은 없었다.
- 추가 지시 없는 Default가 평균보다 꽤 높게 나왔다.
에이전트는 기법을 겉핥기로 쓴다
- 평소 쓰던 테스트를 다른 프레임워크 안에 넣어 쓰거나 기법을 형식적으로만 썼다.
- property-based testing(입력을 무작위로 만들어 성질을 검사하는 테스트)에서는 무효 입력만 잔뜩 때리거나 사소한 성질만 검사했다.
형식 검증 도구는 쓸모없는 증명만 만들었다
- Verus 에이전트는 실제 코드가 아니라 추상적인 성질만 증명했고, A => A 같은 빈 증명도 썼다.
- Alloy는 정답률 2위 최하위였고, 대부분 Rust 기본 #[test]에 의존했다.
Differential testing도 독립 구현을 못 했다
- 160회 중 135회가 비슷한 걸 시도했지만 대부분 사소했다.
- 같은 코드를 두 번 써서 같은 버그를 양쪽에 넣었다.
TDD와 기존 skill은 성적이 나빴다
- TDD는 사전 예측대로 부진했다.
- Codex가 추천한 skill들은 부진했고, 기본 행동을 바로잡도록 설계한 저자의 skill은 괜찮았다.

Community Reactions

프롬프트·재현성이 부족하다는 지적
- 정확한 프롬프트와 테스트 설정을 모르면 실험 가치가 거의 없다는 의견이 있었다.
- 재현용 저장소 링크가 있는지 묻는 댓글도 있었다.
Audit와 교차 리뷰가 효과 있었다는 경험
- 서로 다른 계열의 LLM으로 코드를 감사시키니 잘 됐다는 경험이 여럿 나왔다.
- 새 컨텍스트에서 적대적 리뷰를 돌리는 방식이 좋았다는 경험도 있었다.
TDD·Hypothesis가 얕게 쓰인다는 경험
- Superpowers skill로 TDD를 시켰더니 버튼 존재 여부 같은 저가치 테스트만 쌓였다는 경험이 있었다.
- Hypothesis를 써 봤더니 비즈니스 규칙과 코드 연결에 애를 먹고 부동소수점 엣지케이스에 집착했다는 경험이 있었다.
Verus는 스펙이 잡히면 쓸 만했다는 경험
- 에이전트에게 맡기면 기존 구현을 그대로 옮긴 스펙이 나왔다는 경험이 있었다.
- 스펙을 공들여 다듬은 뒤에는 Claude가 증명을 잘 해냈고 버그도 몇 개 찾았다고 했다.
mutation testing을 자동화하라는 의견
- 에이전트는 빌드 실패는 무시할 수 없으니 mutation 프레임워크로 빌드를 실패시키라는 의견이 있었다.
- 테스트 용이한 아키텍처(DI, hexagonal)를 강제하는 쪽이 낫다는 의견도 있었다.

How to Apply

에이전트 테스트 결과에 mutation 점검 붙이기
- 오늘 한 모듈에 cargo-mutants나 사용 언어의 mutation 도구를 돌려 살아남은 mutant 수를 확인하라.
- 에이전트가 쓴 테스트가 코드 변경을 잡는지 숫자로 확인하라.
기법 이름 대신 하지 말아야 할 행동을 지시하기
- "fuzzing 써" 대신 "같은 입력 반복 금지, 무효 입력만 쓰지 말 것"처럼 기본 행동을 바로잡는 지시를 넣어라.
- 원문에서 성적이 괜찮았던 저자 skill의 설계 방식과 같다.
구현과 리뷰를 컨텍스트 분리해 감사시키기
- 구현 후 새 컨텍스트의 다른 모델에 감사를 시켜 버그 목록을 받아라.
- 그 목록으로 수정 작업을 돌려라.
긴 튜토리얼형 skill은 컨텍스트에 넣지 않기
- 20k 토큰 넘는 skill은 먼저 짧게 줄여 Default와 비교 실행하라.
- 정답률이 안 오르면 제거하라.

Try It

복사해서 바로 해보기

# Claude Code나 Codex에 붙여넣기 (원문 결과를 바탕으로 만든 테스트 감사 프롬프트, 간이 버전)

지금 작성된 {{모듈}}의 테스트를 감사해라.
- 같은 값을 여러 입력에 반복해 넣는 테스트(예: 모든 스트림이 동일)를 찾아라.
- 대칭/팰린드롬 입력이라 순서·뒤바뀜 버그를 못 잡는 테스트를 찾아라.
- 항상 참인 단언(A => A 형태)이나 무효 입력만 때리는 property 테스트를 찾아라.

각 문제 테스트를 고쳐 쓰고, 일부러 버그를 심어 테스트가 실패하는지 확인한 뒤 원복해라.

이어서 해 볼 것: 이 작업을 구현한 세션과 다른 새 세션에서 돌려 보고 결과를 비교해라.

Terminology

Property-based testing예시 입력 대신 "항상 성립해야 할 성질"을 정하고 무작위 입력으로 깨지는지 보는 테스트. 규칙을 정해 두고 아무 손님이나 들여보내 보는 검문이다.

Differential testing같은 입력을 여러 구현에 넣어 결과가 다른지 비교하는 테스트. 두 계산기에 같은 식을 쳐서 답을 맞춰 보는 것과 같다.

Mutation testing코드를 일부러 조금 망가뜨려 테스트가 실패하는지 보는 기법. 테스트가 진짜 감시하는지 확인하는 함정 수사다.

Formal methods코드가 명세를 만족함을 수학적으로 증명하는 방법. Verus, Lean 4, Alloy 등이 해당한다.

RL environment에이전트가 시도하고 보상을 받으며 배우는 훈련용 환경. 연습 문제집과 자동 채점기를 합친 것이다.