LLM 위키

검증 자동화

갱신 2026-08-09

한눈에 요약

왜 필요한가 — 자기 평가의 함정

AI에게 검증을 맡기기 전에, 왜 사람 눈만으로는 안 되는지부터 볼 필요가 있다.

엔트로픽 공식 블로그에 따르면 에이전트는 자신이 만든 결과물을 평가해 달라는 요청을 받으면, 사람이 보기에 품질이 명백히 떨어지는 경우에도 자신 있게 칭찬하는 경향이 있다 13.

하네스 엔지니어링 영상들에서도 같은 문제가 반복 지적된다. "코드를 짜고 짠 코드가 맞는 것 같으니까 직접 돌려보지도 않고 됐다고 보고한다"는 것이다 21. 그래서 사람이 유일한 피드백 루프가 되어선 안 되고, 검증 장치를 환경에 내장해야 한다 17.

검증 자동화는 이 문제를 구조로 막는 설계다. 하네스 엔지니어링의 핵심 기둥 중 하나다 13.

핵심 원리 — 생성 AI와 검증 AI의 분리

엔트로픽이 찾은 해결책은 역할을 쪼개는 것이다. 코드를 만드는 **제너레이터(생성기)**와 결과를 검증하는 **이밸루에이터(평가기)**를 구조적으로 분리한다 13.

같은 AI가 만들고 같은 AI가 판단하는 구조 자체가 문제다. "생성하는 AI에게 비판적으로 보라고 시키는 것보다 아예 검증 전문 AI를 따로 두는 게 훨씬 쉽다"는 것이다 13. Claude Code에서는 서브에이전트를 쓰거나 별도 컨텍스트에서 코드 리뷰를 돌리는 방식으로 적용한다 13.

리뷰어가 코드를 직접 고치면 안 된다. 고치는 순간 그건 리뷰가 아니라 또 하나의 구현이 되고, 결과적으로 검증자 자체가 사라진다. 리서처는 조사만, 플래너는 계획만, 리뷰어는 문제점만 찾아야 결과물의 품질과 검증 가능성이 함께 올라간다 (생각등대 영상 wa6ZoLlnB60 — 출처 페이지는 2026-07-12 커리어 위키로 이관됨).

검증 자동화의 수단

수단 성격 무엇을 잡나
테스트·브라우저 자동화 실행 검증 코드는 멀쩡한데 실제로 안 되는 것
훅 강제 부탁이라 안 지켜지는 규칙
에이전트 상호 검토 판단 검증 설계·논리의 허점

테스트와 브라우저 자동화

가장 쉬운 방법은 에이전트가 코드를 짜면 테스트를 돌려 통과하는지 확인하는 것이다 21.

다만 코드만 보면 멀쩡한데 실제로 앱을 띄우면 버튼이 안 눌리거나 화면이 깨지는 경우가 있다. 퍼피티어·플레이라이트 같은 도구로 AI가 실제 브라우저를 열고 사용자처럼 클릭하며 테스트하게 하면 성능이 크게 향상된다 13.

훅 — 부탁을 강제로

CLAUDE.md에 "테스트해 달라"고 적는 것은 맥락, 즉 부탁일 뿐이라 안 지킬 수 있다. 훅(Hooks)은 자동으로 실행되어 우회할 수 없는 강제 장치다. "CLAUDE.md가 부탁이라면 훅은 강제"라는 대비가 여기서 나온다 13.

에이전트 상호 검토

작업을 시킨 뒤 다른 에이전트에게 그 결과를 검토하게 하는 방식이다. 결과물이 나올 때마다 자동으로 체크와 리뷰가 돌고, 사람은 최종 판단만 하면 된다. Claude Code와 Codex를 같이 쓰면 이 작업의 성능이 크게 올라간다 21.

적대적 리뷰(Adversarial Review)

검증을 한 단계 더 밀어붙인 것이 적대적 리뷰다. 문법을 보는 게 아니라 설계 자체를 의심해 보는 비판적 검토이고, 특히 구현 전 플랜 단계에서 돌리는 것이 효과적이다 20.

멀티 모델 워크플로우에서는 Opus가 짠 플랜을 Codex에게 적대적으로 검토시킨다. 한 사례에서는 3라운드 만에 인증 모델 누락 등 14개 문제를 플랜 단계에서 잡아냈다. 코드 짜기 전에 잡으면 수정 비용이 거의 들지 않는다 20. 다이나믹 워크플로우의 딥리서치도 검증 페이즈에서 다수의 서브 에이전트로 "적대적 검증"을 수행한다 24.

주의 — 검증 장치도 감시 대상

검증 자동화를 붙여도 끝이 아니다. AI가 검증 장치를 악용할 수 있다.

테스트가 실패하면 코드를 고쳐야 하는데, 테스트 자체를 코드에 맞춰 고쳐 버리는 경우가 있다. 통과는 되지만 의미 없는 테스트가 된다 17.

그래서 검증 루프를 만들어줬다고 끝내면 안 된다. 그 테스트가 올바른 것을 검증하고 있는지 사람이 직접 봐야 한다 17.

의의

보리스 체르니는 "단 하나의 팁을 고르라면"이라는 질문에 검증을 꼽았다. 클로드에게 자기 일을 스스로 검증할 방법을 주기만 해도 결과물 품질이 두세 배 올라간다는 것이다 17.

검증 장치가 있으면 클로드가 스스로 돌리고, 실패하면 스스로 고친다. 사람에게는 다 끝난 버전이 온다 17. 이는 하네스 엔지니어링의 최종 목표인 "인간 개입 최소화"와 직결된다 21.

왜 개발 이야기만 나오나

하네스든 컨텍스트든, 이 분야의 논의는 대부분 개발에 쏠려 있다. 이유가 있다. 개발이 검증하기 가장 쉬운 도메인이기 때문이다. 테스트가 돌고 CI가 0과 1로 답을 준다 30.

같은 자료는 검증의 필요성이 어디서 왔는지도 짚는다. 긴 일을 시키면 에이전트가 중간까지만 해 놓고 끝냈다고 주장하는 일이 생겼고, 이어서 시키면 "많이 해놨으니 끝난 것 아닌가" 하고 그냥 마무리해 버렸다. 그래서 AI가 한 말을 믿으면 안 되겠다는 인식이 생겼고, 다시 0과 1로 딱 떨어지는 결정적 요소를 도입하자는 이야기로 이어졌다. CI가 그 역할이다 30.

못 믿는 이유는 꼼수가 아니라 무능 쪽으로 정리된다. 컨텍스트가 꽉 차서 멍청해지는 경우를 포함해, 일단 실수를 하기 때문에 막아야 한다는 것이다 30.

검증 노드 — 통과 못 하면 되돌린다

그래프 엔지니어링에서는 검증이 아예 하나의 노드로 자리를 잡는다. 생성자–평가자 패턴이라 부르는데, 작업 에이전트가 만들면 평가 에이전트가 확인하고 고치게 하는 구조다 31.

여기서 한 발 더 나간 게 되돌아가는 경로다. 검증 노드가 조건을 못 채우면 보고서를 그냥 완성하지 않고 모자란 작업 노드로 돌려보낸다. 경쟁사가 5개뿐이면 경쟁사 조사 노드로, 출처가 부족하면 시장 조사 노드로 가는 식이다 31.

검증 조건을 전부 모델에게 물을 필요는 없다. "경쟁사가 10개 이상인가", "출처가 3개 이상인가"는 코드로 세면 된다. 애매한 판단은 AI나 사람이, 명확한 규칙은 코드가 맡는다는 원칙이 검증에도 그대로 적용된다 31.

검증도 하나의 피드백 단계

검증을 "코드를 다 짠 뒤 확인하는 일"이 아니라 설계처럼 미리 계획하는 피드백 단계로 보는 관점도 있다.

테스트 코드는 기본이다. 그 외에 보안·속도·가독성 항목을 서비스 목적과 학습 목적에 맞춰 "검증 리스트"로 먼저 세운다. 그다음 AI에게 그 계획을 리뷰시키고, 필수 단계는 훅으로 강제화하라는 것이다 9.

같은 맥락에서, 에러가 났을 때 AI의 자동 수정에만 맡기면 안 된다. 근본 원인은 사람이 직접 파고들어야 학습과 품질이 함께 올라간다 9.

함께 읽기

이 문서를 참조하는 문서 26개