📄 코딩 에이전트 테스트, 자기가 지으면 안 되는 이유
코딩 AI에게 버그 수정을 맡기면 대개 이런 흐름이 된다. 문제를 읽고, 코드를 고치고, 그 수정이 맞는지 확인할 테스트를 직접 짜서 돌려본다. 테스트가 통과하면 "됐습니다"라고 보고한다. 그럴듯하다. 그런데 여기에 구멍이 있다. 시험 문제를 낸 사람과 답안을 쓴 사람이 동일인이라는 것이다.
2026년 9월 8일 arXiv에 공개된 ExecCritic 연구는 정확히 이 지점을 겨냥한다.
같은 궁지가 둘 다 쓰면 오류도 같이 틀린다
실행 피드백, 즉 "테스트를 돌려보고 결과를 보고 고친다"는 방식은 코딩 에이전트를 올바른 수정으로 이끄는 강력한 도구다. 단, 조건이 있다. 그 테스트가 원래 이슈에서 요구한 동작을 제대로 담고 있어야 한다.
문제는 하나의 에이전트의 실행 궤적(trajectory)이 패치와 테스트를 모두 작성할 때 생긴다. 에이전트가 요구사항을 잘못 이해했다면, 코드도 그 오해대로 짜이고 테스트도 그 오해대로 짜인다. 둘의 오류가 서로 일치하니 테스트는 당연히 통과한다. 논문은 이것을 '거짓 확신(false confidence)'이라 부른다. 초록 불이 켜졌지만 실제로는 아무것도 검증되지 않은 상태다.
역할을 나누는 것이 전부다
ExecCritic의 구조는 단순하다. 테스트 작성과 소스 수정을 서로 다른 에이전트에게 맡기고, 그 사이에 하네스를 둔다.
- 테스트 에이전트가 저장소 관습에 맞는 테스트를 독립적으로 생성한다.
- 하네스가 그 테스트를 검증하고 고정한다. 이후 수정될 수 없다.
- 수정 에이전트는 테스트를 건드리지 못한 채, 실행 결과만 보고 소스 코드를 고친다. 두 역할 모두 Qwen-3.5-35B-A3B를 백본으로 쓰되 따로 학습된다. 테스트 에이전트는 '올바른 패치와 잘못된 패치를 구분해내는 테스트'를 만드는 법을, 수정 에이전트는 '직접 해결'과 '피드백을 보고 고치기'를 함께 배운다.
숫자가 말하는 것
SWE-bench Verified에서의 결과가 흥미롭다. 수정 에이전트를 고정해두고 테스트만 바꿔가며 붙여본 실험이다.
| 조건 | 해결률 |
|---|---|
| 테스트 없는 기준선 | 61.2% |
| 기본 테스트 에이전트의 테스트 | 57.3% |
| 더 강한 모델(GPT-5.6-sol)의 테스트 | 65.3% |
주목할 것은 가운데 줄이다. 테스트를 붙였더니 성능이 떨어졌다. 품질이 낮은 테스트는 도움이 안 되는 정도가 아니라 적극적으로 해를 끼친다는 뜻이다.
역할별 사후 학습을 거치자 Qwen 테스트 에이전트의 성공률이 22.2%에서 62.2%로 올랐고, 학습된 두 에이전트를 결합했을 때 최종 해결률은 72.6%에 도달했다. 기준선 대비 11.4포인트 개선이며, 평가 시점에 더 강한 모델이나 정답 정보를 빌려오지 않고 얻은 수치다.
그래서 진짜 의미하는 것
이 논문의 교훈은 모델을 더 키우라는 게 아니다. 같은 백본으로도 역할을 분리하고 검증 절차를 고정하는 것만으로 10포인트 넘는 차이가 난다는 것이다. 아키텍처가 아니라 워크플로의 문제라는 이야기다.
여기서 오해하기 쉬운 지점을 짚어두자. "AI에게 테스트를 짜게 하지 말라"는 결론이 아니다. 오히려 테스트 에이전트를 제대로 학습시켰을 때 가장 큰 이득이 나왔다. 핵심은 테스트를 누가 짜느냐가 아니라, 테스트를 짠 주체와 코드를 고치는 주체가 분리돼 있고 테스트가 사후에 수정될 수 없느냐다.
사실 이건 사람의 소프트웨어 개발에서 오래전에 합의된 원칙이기도 하다. 자기 코드를 자기가 리뷰하지 않고, 테스트를 통과시키려고 테스트를 고치지 않는다. AI 에이전트에게도 같은 규율이 필요하다는 것이 이 연구의 실무적 결론이다.
한계도 있다. SWE-bench Verified는 파이썬 저장소 중심의 벤치마크라 다른 언어나 사내 코드베이스로 그대로 옮겨간다는 보장은 없다. 또 하네스가 테스트를 '검증'하는 단계 자체가 완벽할 수는 없다. 다만 방향 자체는 지금 코딩 에이전트를 도입하려는 팀이 곧바로 참고할 만하다.
마무리
사내에서 코딩 에이전트를 쓰고 있다면 확인해볼 것이 하나 있다. 그 에이전트가 만든 테스트를, 그 에이전트가 나중에 고칠 수 있는가. 답이 "그렇다"라면 통과 표시는 생각보다 적은 것을 보증한다. 코드는 공개돼 있다.
출처
Leitian Tao, Baolin Peng, Haorui Wang 외 7명, "ExecCritic: Learn to Test, Test to Improve for Coding Agents", arXiv:2609.09133 (2026년 9월 8일)