AI 가 만든 결과는 전부 읽지 않고 검증 레이어로 신뢰한다

AI 가 코드와 문서를 만드는 속도는 사람이 읽는 속도를 넘어섰다. 모든 산출물을 한 줄씩 읽으며 이해하려 하면 검토가 병목이 되고, 결국 결론만 보고 검토를 포기하게 된다. 이 글은 사람이 직접 볼 것과 검증 레이어에 맡길 것을 나누는 기준을 정리한다. 검증을 이진 검사, 정량 지표, 정성 루브릭으로 나누고, 만드는 시점과 운영 시점에 각각 무엇이 필요한지 설명한다.

이 글은 하용호의 발표 「AI시대 나의 전문성을 재설계하는 법」(2026-06-11, 인프런 강의와 밋업 발표자료, 강의 링크)의 검증 레이어 부분을 정리하고, 하네스 설계 관점에서 덧붙인 것이다.

왜 읽는 대신 검증하는가

발표는 AI 도입 과정에서 쌓이는 부채를 세 가지로 나눈다.

이 가운데 인지부채는 검토 방식과 직접 연결된다. 사람의 주된 일이 생산에서 검증으로 옮겨 가므로, 중간 산출물을 전부 이해하려는 대신 결과물을 검증할 레이어를 만드는 데 시간을 써야 한다는 것이 발표의 주장이다. 중요한 결과물은 사람이 철저히 보고, 중간 산출물은 통과 기준으로 간접적으로 신뢰한다.

검증의 세 종류

이진 검사는 같은 입력에 항상 같은 판정을 낸다. 정량 지표는 기준값을 정해 두면 회귀를 잡을 수 있다. 정성 루브릭은 숫자로 바꾸기 어려운 기준이다. 판정에 LLM judge 를 쓸 수 있지만, 무엇을 좋은 결과로 볼지의 기준은 도메인을 이해하는 사람이 정해야 한다. 발표도 좋은 검증 레이어는 도메인 이해가 있는 전문가가 만든다고 말한다.

가능하면 정성 기준을 이진 검사나 정량 지표로 바꿔서 결정적으로 판정할 수 있는 부분을 늘리고, 정말 남는 부분만 루브릭으로 둔다. 이 순서를 코드 컨벤션에 적용한 사례는 AI 코딩 에이전트의 코드 컨벤션은 규칙 문서와 결정적 검사로 지킨다에 있다.

만드는 시점과 운영 시점

발표는 검증 레이어가 build-time 과 run-time 모두에 필요하다고 말한다.

• build-time 검증: 산출물을 만드는 과정의 검증이다. 테스트, 정적 분석, 리뷰가 여기에 속한다.
• run-time 검증: 운영 중인 시스템의 검증이다. 제품 자체가 AI 에이전트라면 같은 입력에도 결과가 달라질 수 있으므로, 배포 전에 한 번 통과한 것으로는 부족하고 실행 중에도 결과를 계속 점검하는 구조가 필요하다.

AI 에이전트를 제품으로 운영하는 경우의 지연, 비용, 도구 실패, 폴백 설계는 AI 제품 백엔드 안정성과 LLM 평가 프레임워크에서 다룬다.

검증하는 쪽을 만든 쪽과 분리한다

검증을 작업한 세션이 그대로 맡으면 자기 결과를 옹호하기 쉽다. 독립된 평가자를 두는 구조와 그 근거는 하네스 엔지니어링의 「자기 평가 편향」 절에 이미 정리돼 있어 여기서는 다시 쓰지 않는다.

정리

• 사람의 일은 생산에서 검증으로 옮겨 간다.
• 모든 중간 산출물을 읽는 대신, 무엇을 직접 볼지와 무엇을 검증 레이어에 맡길지를 나눈다.
• 검증은 이진 검사, 정량 지표, 정성 루브릭으로 나누고, 결정적으로 판정할 수 있는 부분부터 늘린다.
• 만드는 시점의 검증으로 끝내지 않고, 결과가 비결정적인 제품이라면 운영 중 검증도 설계한다.