Heal은 코딩 에이전트가 코드를 검증할 도구를 만든다

힐(Heal)의 피에르 우시프(Pierre Oucif)는 코딩 에이전트가 작성한 코드를 직접 실행하고 확인하도록 돕는 ‘검증 하네스’를 소개했다. 하네스는 테스트 도구와 사용 맥락, 에이전트가 통제하거나 우회할 수 없는 평가 규칙으로 구성된다. 힐은 자사 에이전트가 저장소마다 필요한 하네스를 자동으로 만들게 하고 있다.

애디 오스마니(Addy Osmani)는 Agentic Verification에서 “조금 더 나은 모델보다 훨씬 나은 피드백 루프를 언제나 선호하겠다”고 썼다. 코드를 읽기만 하는 코딩 에이전트는 추측할 수밖에 없다. 반면 제품을 실행하고 인터페이스와 API를 사용할 수 있으면 결과를 확인하고 반복해서 수정할 수 있다. 검증 하네스는 지속적 통합(CI) 파이프라인과 비슷하지만 에이전트 세션 안에서 더 짧은 주기로 실행된다.

힐의 하네스는 처음부터 제품으로 시작한 것이 아니다. 엔지니어들이 대부분의 Claude Code 세션에서 Claude에 “코드를 테스트하려면 무엇이 필요한가?”라고 묻는 데서 출발했다. 5주 동안 받은 답변은 백엔드의 Docker 모드, 에이전트의 재생 모드, 두 기능을 결합한 통합 테스트 명세, 실제 Vercel 샌드박스를 구동하는 벤치마크로 이어졌다. 이 글은 하네스의 구성과 설계, 하네스가 발견한 문제, 같은 모델이 하네스 유무에 따라 보인 차이, 힐이 코드베이스마다 하네스를 자동으로 만드는 이유를 다룬다.

검증 하네스는 코딩 에이전트가 코드를 확인하도록 제공하는 세 가지 요소로 이뤄진다.

• 검증 도구: 린터, 테스트가 포함된 테스트 프레임워크, 실시간 브라우저, 테스트용 데이터를 채운 실행 앱, 각 외부 서비스의 대체 수단.
• 맥락: 도구가 무엇이고 어떻게 사용하는지, 무엇을 어떤 방식으로 이미 검증했는지, 어디를 살펴볼지 정하는 경험적 기준.
• 규칙: 에이전트가 통제하거나 속일 수 없는 평가기. 종단 간 테스트, 통합 테스트, 스크립트 기반 검사로 구성된다.

AI로 코드를 만드는 비용이 낮아진 지금은 검증 하네스를 만드는 일도 저렴해졌다. 힐은 시간 부족이나 관련 전문성 부족 때문에 대부분의 엔지니어가 하네스를 충분히 깊이 있게 만들지 못한다고 본다. 대부분의 저장소에는 하네스가 없기 때문에 힐은 하네스를 만드는 에이전트를 개발했다. Heal Sandbox는 그 구현 방식 가운데 하나다. 궁극적으로는 각 코드베이스에 맞춘 하네스를 먼저 로컬 작업 흐름에 두고, 편의성과 확장성을 위해 힐의 클라우드에서도 실행하는 것이 목표다.

하네스를 만든 과정과 구조

힐의 에이전트는 대규모 언어 모델(LLM)을 이용해 장시간 작업을 수행하고 백엔드에 결과를 보고한다. 그래서 많은 버그가 스테이징이나 프로덕션에서야 드러났다. 기존 스택에는 폭넓은 테스트가 있었지만 충분하지 않았다. 엔지니어들은 5주 동안 Claude Code에 코드 테스트에 필요한 것을 묻거나 로컬 테스트 방법을 알려 달라고 요청하고, 그 답변을 토대로 초기 하네스를 만들었다.

그림 1은 하네스 도입 전 힐의 스택을 보여준다. 백엔드와 에이전트에는 실제 저장소를 대상으로 하는 유닛 테스트와 통합 테스트가 수천 개 있었지만 프런트엔드에는 테스트가 없었다. 그런데도 90일 동안 버그 29건이 테스트를 빠져나갔다. 이 때문에 같은 질문을 계속 던졌다.

그림 2는 9월 28일부터 10월 23일까지 15번 요청한 내용 중 10건과 각 요청으로 만들어진 기능을 보여준다. 재생 모드, Docker 환경, 첫 녹화 기능은 요청한 당일 아침에 만들어져 병합됐다.

하네스는 가능한 한 프로덕션 코드와 분리했다. 다만 힐의 경우 두 부분은 완전히 분리하기 어려웠다. Anthropic 호출은 도구 정의와 캐시 등이 포함된 복잡한 HTTP 응답 때문에 모킹하기 어렵다. 힐은 이 부분이 Claude SDK 설정이 제대로 됐는지를 확인하는 데 그치므로 가치가 낮다고 판단했다. 에이전트 동작을 모킹하기 위해 다양한 호출 옵션을 대규모로 재생하려면 호출을 기록하고 재생하는 메커니즘도 필요하다. 예를 들어 모의 서버로 기록하는 방식이 이에 해당한다.

힐은 이 부분을 처리하기 위해 의존성 주입과 포트·어댑터 패턴을 사용했다. 앱을 Claude SDK에 연결하는 지점에서는 SDK를 프로덕션에서 기록한 정적 로컬 재생으로 대체하고, 프로덕션 샌드박스 런타임은 Docker 컨테이너로 바꿨다. 환경 변수로 이를 제어하므로 프로덕션과 테스트에서 같은 바이너리를 사용할 수 있고, 코드 분기본을 따로 만들지 않아도 검증 하네스가 프로덕션 코드에 연결된다. 로컬에서는 대체 구성요소와 실제 의존성 사이를 전환할 수도 있다. 그림 3은 환경 변수로 호출 대상을 바꾸는 힐의 포트·어댑터 구조를 보여준다.

하네스가 병합 전에 잡은 버그

힐은 하네스가 병합 전에 잡아낸 사례 여섯 가지를 소개했다. 이전에는 스테이징이나 프로덕션까지 도달했던 문제들이다.

• 수정 후 후속 실행에서 나온 판정이 고객 대시보드에 표시되지 않았다. 실제 백엔드에 기록된 실행을 재생하는 테스트의 첫 실행에서 발견했다. 버그 수정으로 어떤 문제가 해결됐는지 고객에게 알리지 못해 사람이 몇 시간씩 다시 확인해야 했다.
• 분석이 끝난 뒤에도 클라우드 머신이 계속 실행되는 문제가 22일 동안 발견되지 않았다. 120초 동안 실행한 뒤 종료하는 재생 테스트에서 잡았고, 수정 후 실행 시간은 9.5초였다. 매 실행마다 불필요한 컴퓨팅 비용이 발생하고 결과 전달도 늦어졌다.
• 첫 실행 기록에 날짜가 빠져 있어 수정 후 후속 실행을 시작할 수 없었다. 메인 브랜치에서는 실패하고 해당 브랜치에서는 통과하는 재생 테스트가 이를 찾았다. 이 문제로 모든 고객의 수정·재검증 절차가 중단됐다.
• 에이전트가 같은 샌드박스 새로 고침을 연속 87회 요청했다. 모델을 호출하지 않는 기록 실행의 모의 재생에서 발견했다. 후속 실행마다 모델 호출과 비용이 들고 결과도 늦어졌다.
• 메시지가 문자 중간에서 잘리거나 100KB를 넘으면 진행 상황 보고가 거부됐다. 실제 PostgreSQL을 대상으로 한 통합 테스트가 커밋 전에 잡았다. 진행 상황과 발견 사항이 고객 대시보드로 전달되는 과정에서 사라졌다.
• 한 실행 모드에서 프로덕션 안전 검사가 건너뛰어졌다. 변경을 작성한 세션에서 실행한 유닛 테스트로 발견했다. 재생 실행이 실제 실행처럼 통과해 고객에게 잘못된 발견 사항을 보여줄 수 있었다.

그림 4의 설명에 따르면 이 문제들은 에이전트와 백엔드 사이에서 발생했기 때문에 유닛 테스트로 잡히지 않았다.

벤치마크와 힐의 자동화 방식

공개 버그 수정 벤치마크는 에이전트가 제품을 실행할 수 있게 하고 수정할 버그를 알려주면 성능이 크게 개선된다고 제시한다. 힐은 더 복잡한 하네스에서도 자체 평가 결과가 같은 방향을 가리켰다고 밝혔다.

힐은 공개 벤치마크 결과를 두고, 제품을 실행하고 버그를 특정하면 성능이 크게 향상된다고 설명한다. 자체 평가에서는 복잡한 제품을 대상으로 샌드박스를 사용해 같은 경향을 재현했다고 밝혔다. 소스만 주어진 경우 최신 모델도 실제 버그의 10분의 1 미만을 수정하며, 제품이 실행되면 그보다 몇 배 많은 버그를 해결하고, 버그 설명까지 주어지면 거의 모두 해결한다는 것이 힐의 해석이다. 힐은 검증 하네스가 에이전트를 이 단계로 끌어올리며, 시스템 복잡도와 관계없이 하네스를 자동으로 만드는 접근을 취한다고 설명한다.

대부분의 저장소에는 검증 하네스가 없다. 힐의 에이전트는 저장소를 처음 접하더라도 누락된 요소를 하나씩 만들 수 있다면, 하네스 전체를 만든 뒤 이를 활용하는 일도 맡길 수 있다는 구상에서 출발했다. 그림 5는 힐 에이전트가 실행되면서 검증 하네스를 만드는 과정을 보여준다.

힐에 따르면 자사 에이전트는 수백 개 제품의 검증 하네스를 만들고 영향이 큰 결함 수만 건을 보고했다. 힐은 그중 21개 제품의 작은 표본을 분석해 하네스를 만들 때 에이전트가 자주 추가하는 요소를 살펴봤다. 그림 6은 가장 흔한 추가 항목을 보여준다.

코드베이스별 하네스

힐은 버그와 취약점을 찾기 위해 하네스를 자동으로 만드는 에이전트를 사용한다. 새 저장소를 받으면 기존 요소가 요구사항을 얼마나 충족하는지 평가한 뒤 빠진 부분을 만든다. 핵심 요소 중 하나는 앱을 프로덕션과 비슷한 방식으로 실행하는 Heal 애플리케이션 샌드박스다. 이 샌드박스는 버그와 취약점을 찾도록 설계됐지만 코딩 에이전트도 사용할 수 있다.

목표는 모든 저장소에 같은 샌드박스 형태를 적용하는 것이 아니다. 각 코드베이스의 테스트, 코드가 이미 제공하는 포트, 호출하는 외부 서비스, 부팅 방식에 맞는 하네스를 만드는 것이다. 먼저 변경 사항을 작성한 에이전트가 푸시 전에 로컬에서 하네스를 실행하고, 팀이 모든 커밋마다 검사기와 심판 역할을 원하면 같은 하네스를 힐의 클라우드에서 실행하는 구상을 제시했다. 저장소에서 사용해 보기 또는 코드 리뷰 봇과 비교한 벤치마크를 확인할 수 있다.