코딩 에이전트가 컴포넌트를 수정하고 빌드를 돌린 뒤 "UI가 픽셀 퍼펙트하게 완성됐습니다"라고 리포트한다. 그런데 에이전트는 단 한 번도 브라우저를 열지 않았다. 그건 완성이 아니라 추측이다.
이 불편한 사실을 정면으로 건드린 도구가 있다. dev.to에 공개된 hwatu는 코딩 에이전트의 검증 루프를 위해 설계된 경량 브라우저다. 핵심은 단순하다. 에이전트가 편집을 마칠 때마다 실제로 브라우저를 열고, 스크린샷을 찍고, 베이스라인 이미지와 픽셀 단위로 비교한 뒤 "97.49% 일치" 같은 측정값을 숫자로 돌려준다. '잘 됐다'는 주관적 보고가 아니라, 재현 가능한 수치로 UI 상태를 증명하는 구조다.
기술 설계 선택도 눈여겨볼 만하다. hwatu는 Chromium 대신 WebKitGTK를 사용해 170MB에 달하는 다운로드를 단일 Rust 바이너리로 대체했고, 전체 검증 루프—브라우저 오픈 → 로드 대기 → DOM 쿼리 → 스크린샷 → 픽셀 비교—를 약 87ms에 완료한다. 에이전트가 매 편집마다 검증을 돌려도 부담이 없는 속도다. MCP 서버, CLI, JSON 소켓 세 가지 프로토콜을 지원해 Claude Code, Cursor 등 주요 에이전트 환경에 곧바로 붙을 수 있다.
이 맥락에서 함께 읽어야 할 사례가 있다. 역시 dev.to에 올라온 ShipNano 개발자의 경험담은, Claude Code를 "페어 프로그래머"로 삼아 주말마다 Chrome 확장 세 개를 출시한 여정을 담고 있다. 흥미로운 지점은 이 개발자가 AI를 단순 코드 생산 도구로 쓰지 않았다는 것이다. JWT 보안 분석, MV3 퍼미션 거절 대응, 로컬 번들링 제약 해결처럼 판단과 검증이 필요한 순간마다 AI와 함께 루프를 돌렸다. 속도는 AI가 가져가되, 검증의 책임은 워크플로우 설계 안에 구조적으로 내재돼 있었다.
두 사례가 교차하는 지점에서 하나의 패턴이 보인다. AI 코딩 에이전트를 진짜 신뢰할 수 있으려면, 에이전트의 '자기 보고'를 그대로 믿는 것이 아니라 측정 가능한 검증 루프를 워크플로우 안에 심어야 한다는 것이다. hwatu가 "픽셀 퍼펙트를 숫자로 증명하라"고 요구하는 방식, ShipNano 개발자가 Chrome 심사 거절 이후 피드백 루프를 체계적으로 돌린 방식—둘 다 AI를 빠른 코드 생성기가 아닌, 검증 사이클의 파트너로 재정의하고 있다.
기존의 AI 코딩 담론은 '얼마나 빠르게 만드는가'에 집중했다. 그러나 속도가 당연해지는 순간, 진짜 경쟁력은 '얼마나 신뢰할 수 있는 결과물을 만드는가'로 이동한다. Storybook이 컴포넌트를 격리해 검증하고, 픽셀 diff가 UI 변화를 수치화하고, CI가 에이전트 출력을 자동 감시하는 것—이 모든 장치가 결국 같은 질문에 답한다. AI가 만들었다는 사실이 아니라, 그것이 실제로 의도대로 작동한다는 증거를 어디서 얻을 것인가.
앞으로 AI 코딩 에이전트 생태계에서 '검증 인프라'는 선택이 아닌 필수 레이어가 될 것이다. hwatu처럼 에이전트 루프에 직접 물리는 경량 검증 도구들이 늘어나고, MCP 프로토콜을 통해 에이전트가 스스로 검증 결과를 피드백 루프에 반영하는 구조가 표준화될 가능성이 높다. 개발자의 역할은 코드를 검토하는 것에서, 검증 루프 자체를 설계하는 것으로 한 단계 더 이동하고 있다.