AI 코딩 에이전트 검증 장치, 언제 효과적일까?

AI 코딩 도구에 같은 개발 과제를 맡길 때, 처음부터 촘촘한 테스트 환경을 붙이는 편이 좋을까요? 테스트는 결과를 확인하는 데 도움이 되지만, 실행 시간과 비용도 늘립니다. 개발자 나레시 자인이 2026년 10월 마틴 파울러 사이트에 발표한 실험은 이 선택이 모델과 작업 조건에 따라 달라질 수 있음을 보여줍니다. 아래 수치는 연구자가 보고한 결과이며, 파크골프맵이 직접 모델을 시험한 값은 아닙니다.

여기서 말하는 ‘하네스’는 무엇일까

하네스는 AI가 코드를 작성하는 동안 지켜야 할 규칙을 알려주고, 실제 결과를 검사해 다시 피드백하는 장치입니다. 이번 실험에서는 API 명세와 요청·응답 예시가 길잡이 역할을 했습니다. 계약 검사, 가짜 외부 서비스, 자동화된 동작 검사는 코드가 요구 사항을 따르는지 알려주는 센서 역할을 했습니다.

예를 들어 온라인 상품 검색 서비스를 만든다면 “검색 결과를 보여준다”는 설명만으로는 부족합니다. 주문 서비스가 늦게 응답할 때 어떤 상태 코드를 돌려줄지, 검색한 상품 중 무엇을 메시지로 보낼지, 전송 실패를 어떻게 처리할지까지 맞아야 합니다. 하네스는 이런 세부 조건을 실행 가능한 검사로 바꿔 AI에게 알려줍니다.

같은 과제에서 결과가 어떻게 달랐나

연구자는 코딩 에이전트에게 상세한 설명을 주고, 새 자바 API 서비스를 여러 번 만들게 했습니다. GPT-6 Sol과 GPT-6 Luna 각각에 대해 하네스가 있는 경우와 없는 경우를 10회씩 비교했습니다. 완성된 서비스는 개발 중 사용한 검사와 별도로 마련한 178개 자동 수용 검사에 통과해야 ‘성공’으로 셌습니다.

• GPT-6 Sol, 하네스 없음: 10회 중 10회 통과. 평균 약 6분 51초, 추정 모델 비용 0.406달러.
• GPT-6 Sol, 하네스 있음: 10회 중 10회 통과. 평균 약 19분 53초, 추정 모델 비용 2.679달러.
• GPT-6 Luna, 하네스 없음: 10회 중 3회 통과. 평균 약 15분 56초, 추정 모델 비용 0.086달러.
• GPT-6 Luna, 하네스 있음: 10회 중 10회 통과. 평균 약 35분, 추정 모델 비용 0.273달러.

이 과제에서는 Sol이 하네스 없이도 매번 통과했습니다. 따라서 개발 과정 내내 하네스를 돌리는 비용만 늘고 관찰된 성공 횟수는 같았습니다. 반면 Luna는 하네스를 붙였을 때 통과 횟수가 3회에서 10회로 늘었습니다. 하네스를 붙인 Luna의 한 번 실행 비용 추정치는 하네스 없는 Sol보다 약 33% 낮았지만, 실행 시간은 훨씬 길었습니다.

실패는 코드 문법보다 ‘경계 조건’에서 나왔다

Luna의 하네스 없는 실행은 대부분의 검사를 통과했습니다. 문제는 예외 처리와 외부 서비스 사이의 약속에서 나타났습니다. 상품 생성 요청이 시간 초과되면 우선 ‘접수됨’을 뜻하는 202 응답과 진행 상태를 확인할 링크를 줘야 했지만, 일부 실행은 503·400·429를 돌려줬습니다. 그러면 이용자는 이후 결과를 확인할 주소도 받지 못합니다.

메시지를 카프카에 보내는 과정도 마찬가지였습니다. 실제 메시지가 도착해도 예상치 못한 헤더가 붙거나, 배열이어야 할 값이 비어 있는 값으로 전송되면 약속한 형식에 어긋납니다. 겉으로는 서비스가 작동하는 것처럼 보여도 다른 시스템과 연결할 때 문제가 생길 수 있다는 뜻입니다.

여기서 중요한 점은 검사 기준의 출처입니다. AI가 자기 해석대로 코드와 정답 테스트를 모두 만들면 같은 오해가 양쪽에 들어갈 수 있습니다. 이번 실험은 사람이 제공한 명세와 예시를 기준으로 삼고, 개발 완료 후 별도의 검사 환경에서 다시 확인했습니다.

‘더 저렴하다’는 숫자를 읽는 방법

0.273달러와 0.406달러는 실제 청구서가 아니라 기록한 토큰 사용량과 모델 가격을 바탕으로 계산한 API 비용 추정치입니다. 명세 작성, 테스트 구축·유지, 실패 분석, 사람의 검토, 배포 비용은 들어 있지 않습니다. 따라서 이 숫자만으로 전체 개발비가 33% 줄었다고 말할 수는 없습니다.

또한 성공 10회는 이 실험의 10회에서 실패가 없었다는 뜻입니다. 앞으로의 모든 작업에서 성공률이 100%라는 증거는 아닙니다. 비교한 과제도 요구 사항이 매우 자세히 적힌 새 자바 서비스 하나였습니다. 기존 코드 수정이나 다른 언어, 간단한 작업에서도 같은 결과가 나온다고 단정할 수 없습니다.

실무에서는 검사를 언제 돌릴지 정하자

작업을 맡기기 전에 먼저 ‘완료’를 판단할 수 있는 조건을 적어 보세요. 정상 동작뿐 아니라 시간 초과, 잘못된 입력, 외부 서비스 장애처럼 놓치기 쉬운 경우도 포함합니다. 그다음 AI가 임의로 바꿀 수 없는 별도의 기준으로 최종 결과를 확인하는 편이 좋습니다.

한 번에 통과하는 경우가 많은 작업이라면 개발 중 모든 단계에서 무거운 검사를 반복하기보다 마지막에 독립적인 검사를 하는 방식을 검토할 수 있습니다. 반대로 같은 종류의 실수가 반복된다면 개발 도중 검사 결과를 바로 되돌려주는 환경이 도움이 될 수 있습니다. 다만 ‘최종 검사만 하는 방식’의 비용과 효과는 원문 실험에서 직접 비교하지 않았으므로, 실제 프로젝트에서 작은 규모로 시험한 뒤 결정해야 합니다.

AI가 완료했다고 보고한 뒤 사람이 무엇을 확인해야 하는지 궁금하다면 AI 코딩 도구 결과를 확인하는 5가지 방법도 함께 참고할 수 있습니다.

이 실험에서 가져갈 한 가지

하네스는 무조건 많이 붙이는 것이 목표가 아닙니다. 독립적인 검증 기준은 유지하면서, 작업의 난도와 모델의 실제 실패 양상에 맞춰 피드백을 주는 시점을 정하는 것이 핵심입니다. 검사에 드는 시간과 돈, 실패를 고치는 비용까지 함께 기록해야 우리 팀에 맞는 선택을 할 수 있습니다.

참고 자료

• Naresh Jain, “Are Harnesses Worth the Cost?”, Martin Fowler, 2026년 10월 13일 — 실험 설계, 결과 및 한계의 원문

자료 확인일: 2026년 10월 16일. 가격과 모델 특성은 바뀔 수 있으며, 본문 수치는 원문 실험 당시의 추정치입니다.