AI 에이전트가 작성한 코드를 사람이 줄마다 살펴보는 대신, 에이전트가 스스로 결과를 확인하고 수정할 수 있는 빠르고 안정적인 검증 절차를 마련해야 한다는 제안이다. 애디 오스마니(Addy Osmani)는 테스트를 에이전트가 작업의 성공 여부를 판단하는 기준으로 삼고, 사람이 코드 차이만 보는 대신 검증 근거를 살펴야 한다고 말한다.
오스마니는 실제 사용자 흐름을 재현하는 엔드투엔드(E2E) 테스트를 중요한 검증 수단으로 꼽는다. 회원 가입부터 장바구니에 상품을 담고 결제한 뒤 확인 메시지를 보는 식으로, 내부 코드가 아니라 사용자가 경험하는 결과를 검사한다. 다만 E2E 테스트는 기존 단위 테스트보다 느리고 불안정할 수 있으므로, 모든 경로를 다루기보다 가치가 높은 사용자 흐름을 소수로 선정하라고 권한다. 실패한 단계와 화면, 추적 정보를 에이전트가 확인할 수 있게 하면 무엇이 잘못됐는지 파악하는 데도 도움이 된다.
속성 기반 테스트는 지켜야 할 규칙을 정하고 도구가 수백 또는 수천 개의 입력을 만들어 규칙을 깨는 사례를 찾는 방식이다. 예를 들어 인코딩 후 디코딩한 값이 원래 값과 같아야 한다거나, 정렬 뒤에도 원소 수와 내용이 유지돼야 한다는 조건을 검사할 수 있다. fast-check는 JS/TS, Hypothesis는 Python, proptest는 Rust용 도구로 소개됐다. 실패를 일으킨 입력은 최소 사례로 줄여 회귀 테스트에 저장할 수 있다.
시스템을 교체하거나 재작성할 때는 기존 시스템과 새 시스템에 같은 입력을 넣고 결과를 비교하는 차등 테스트도 제안한다. 입력은 무작위로 만들거나 실제 트래픽 일부를 재생할 수 있다. 의미가 없는 차이는 비교 전에 정규화하고, 의도적으로 허용한 변경은 이유와 함께 목록으로 관리해야 한다. 그래야 새 시스템이 기존의 문서화되지 않은 동작과 달라진 부분을 구분할 수 있다.
테스트가 느리거나 불안정하면 에이전트가 실패 원인을 고치기보다 재실행을 택하거나, 테스트를 덜 자주 실행할 수 있다고 오스마니는 경고한다. 핵심 검증은 각 작업 주기에서 돌릴 만큼 빠르게 만들고, 결과가 반복해서 같도록 난수 시드와 시계, 네트워크, 상태를 통제하라고 제안한다. 불안정한 테스트는 주 테스트 묶음에서 분리하고, 첫 검증은 가볍게 한 뒤 무거운 E2E 테스트와 차등 테스트를 통합 전에 실행하는 방식도 언급한다.
오스마니는 작업을 맡기기 전에 성공 기준을 먼저 정하고, 코드 예시뿐 아니라 발생하면 안 되는 조건도 검증해야 한다고 강조한다. 테스트 자체도 그럴듯하지만 틀린 구현을 실제로 구별하는지 살펴볼 필요가 있다. 사람은 배포할 결과에 대한 책임을 유지하되, 코드 변경분만이 아니라 에이전트가 통과한 검증 결과를 판단의 근거로 삼는다는 구상이다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요