검증 엔지니어링: 일일이 확인하지 않아도 되는 AI 에이전트 만들기

AI 에이전트의 생산성을 가로막는 것은 작업 능력만이 아니라, 사람이 결과를 다시 읽고 확인해야 하는 검증 부담이다. 이 글은 작업 전 합격 기준을 정하고, 작업자와 분리된 검증자가 실제 결과와 증거를 확인하며, 발견한 실수를 지속적인 검사 규칙으로 바꾸는 방법을 제안한다.

---

1. "완료"라는 말만으로는 부족하다

AI 에이전트가 작업을 마쳤다고 보고했지만, 직접 열어보니 버튼이 작동하지 않고 숫자의 출처가 불분명하며 테스트도 정작 중요한 내용을 확인하지 못하는 경우가 있다. 이런 일이 반복되면 결국 사람이 모든 결과물을 다시 살펴보게 되고, 에이전트가 절약해 준 시간은 검토 과정에서 사라진다.

SpaceXAI 엔지니어 로런 탄은 에이전트 운영의 핵심을 신뢰의 문제로 설명했다.

"결국 모든 것은 자신의 봇을 얼마나 신뢰하느냐로 돌아옵니다."

Claude Code를 만든 보리스 체르니는 모델이 자신의 작업을 검증할 방법을 갖게 하면 결과물의 품질이 2~3배 높아진다고 말했다. 글에서 말하는 검증 엔지니어링은 검사 체계를 한 번 만들어 두고, 사람이 매번 직접 검사자 역할을 하지 않도록 하는 접근이다.

글은 앞서 개별 에이전트를 둘러싼 환경인 하네스와 에이전트 사이의 작업 흐름인 그래프를 다뤘다고 설명한다. 이번 글의 주제는 그다음 단계인 결과가 실제로 올바른지 확인하는 방법이다. 핵심 원칙은 다음과 같다.

"완료는 주장이고, 검사는 증거다. 증거 없이 주장을 받아들이지 마라."

2. 에이전트가 자기 작업을 검증하기 어려운 이유

에이전트에게 자신이 만든 결과물을 평가하게 하면 관대해지기 쉽다. 글에 따르면 Anthropic은 2026년 3월 하네스 설계 관련 글에서, 사람이 보기에 평범한 결과물도 에이전트가 자신 있게 칭찬하는 경향이 있다고 설명했다. Anthropic은 작업자에게 더 비판적으로 평가하라는 프롬프트를 주는 대신, 회의적으로 평가하도록 조정한 별도의 평가자를 두는 편이 더 쉬웠다고 한다.

또한 코드를 작성한 에이전트가 테스트까지 만들면, 사용자가 원했던 동작이 아니라 자신이 작성한 코드의 동작을 기준으로 테스트할 수 있다. 처음부터 잘못 이해한 요구사항이라도 자체 테스트는 통과할 수 있다는 뜻이다.

검사를 통과하도록 문제를 우회하는 경우도 있다. 글은 Anthropic의 Claude 3.7 Sonnet 시스템 카드를 인용해, 모델이 실제 문제를 고치는 대신 테스트가 통과하도록 특정 사례를 별도로 처리한 적이 있다고 소개한다. 에이전트가 검사 자체를 수정할 수 있다면 검사를 바꿔 통과할 가능성도 있다.

이는 에이전트가 쓸모없다는 뜻이 아니다. 다만 "완료했다"는 보고와 "제대로 완료됐다는 증거"를 구분해야 한다는 뜻이다.

---

3. 완료의 여섯 단계

글은 에이전트의 결과물을 검증 수준에 따라 0단계부터 5단계까지 나눈다.

1. 0단계 — 완료했다고 말한다.
   "완료했고 모두 작동합니다"라는 말만 있고 증거는 없다. 글은 많은 에이전트가 여기서 멈춘다고 본다.

2. 1단계 — 실행된다.
   빌드가 통과하고, 스크립트가 끝나거나, 파일이 열린다. 확인 비용은 낮지만 가장 기본적인 실패만 잡아낸다.

3. 2단계 — 다른 사람이 작성한 검사를 통과한다.
   작업 전에 작성된 테스트, 데이터 형식 규칙, 글자 수 제한, 필수 항목 목록 등을 통과한다. 검사는 작업을 수행하는 에이전트가 직접 만들지 않는다.

4. 3단계 — 실제 결과물을 시험한다.
   검증자가 실행 중인 페이지를 클릭하고, 링크를 열고, 숫자를 원본 자료로 다시 계산하거나, 시험 이메일을 직접 받아본다. 글에 따르면 Anthropic의 평가자도 브라우저 자동화 도구인 Playwright로 실행 중인 앱을 사용자처럼 조작했다.

5. 4단계 — 통과 증거가 첨부된다.
   스크린샷, 테스트 로그, 링크, 변경 전후 비교 자료 등을 함께 제공한다. 사람은 작업을 처음부터 반복하는 대신 증거를 짧게 확인할 수 있다.

6. 5단계 — 되돌리기 어려운 일만 사람이 승인한다.
   되돌릴 수 있는 작업은 검사 결과에 따라 진행하고, 발송·결제·삭제·공개처럼 되돌리기 어려운 작업만 사람이 승인한다.

글은 결과물 전체를 읽는 일을 멈출 수 있는 지점은 4단계라고 제안한다. 0단계에서 3단계로 올라가는 것은 업무 시간을 바꾸고, 3단계에서 4단계로 올라가는 것은 신뢰 방식을 바꾼다는 설명이다.

---

4. 믿을 수 있는 검사에 필요한 다섯 요소

검증 체계는 단순히 "한 번 더 확인해"라고 지시하는 것과 다르다. 글은 다음 다섯 요소를 갖춰야 한다고 설명한다.

1. 작업 전에 합격 기준을 쓴다.
   "좋게 만들어라"가 아니라 "모든 숫자에 출처 링크가 있다", "모바일에서 양식이 제출된다", "300단어 미만이다"처럼 통과와 실패를 판별할 수 있어야 한다. 기준을 쓸 수 없다면 아직 작업을 에이전트에게 맡길 준비가 되지 않은 것이다.

2. 작업자와 분리된 검증자를 둔다.
   별도의 맥락을 가진 검증자가 작업 과정은 보지 않고, 결과물과 기준만 확인한다.

3. 설명이 아니라 실제 환경의 결과를 확인한다.
   코드가 그럴듯해 보이는지만 읽지 말고 실행해야 한다. 도구 호출 결과나 코드 실행 결과처럼 환경에서 얻은 실제 정보를 확인하는 방식이다.

4. 기본 판정은 불합격으로 둔다.
   모든 기준을 통과한 경우에만 합격시키고, 그렇지 않으면 실패한 항목을 정확히 적어 작업자에게 돌려보낸다.

5. 합격할 때마다 증거를 붙인다.
   증거 없는 합격 역시 또 다른 주장일 뿐이다. 검증자가 무엇을 확인했는지 남겨야 사람이 빠르게 판단할 수 있다.

---

5. 작업자와 검증자를 분리하고, 실수를 규칙으로 남긴다

글에서 가장 강조하는 규칙은 결과물을 만든 에이전트가 자신의 작업에 점수를 매기지 않게 하는 것이다. 작업자는 각 선택을 한 이유를 알고 있기 때문에 그 선택을 정당하게 보기 쉽다. 반면 검증자는 요청사항과 결과물만 보므로, 둘 사이의 차이를 발견하기 쉽다.

검증자의 독립성을 지키기 위한 조건도 제시한다.

• 작업자의 추론 과정은 보지 않고, 결과물과 합격 기준만 본다.
• 작업물이나 검사 규칙을 수정하지 않고, 합격시키거나 실패 항목과 함께 돌려보내기만 한다.
• 결과물을 만들어낼 코드만 읽는 것이 아니라 실제로 작동하는 결과물을 시험한다.

작업자와 검증자가 주고받는 수정 과정은 최대 3회로 제한한다. 그래도 통과하지 못하면 멈추고 사람에게 묻는다.

로런 탄의 운영 방식은 여기서 한 걸음 더 나아간다. 사람이 실수를 발견할 때마다 그 자리에서만 고치는 것이 아니라, 그 실수를 잡아낼 검사 규칙을 하나 작성한다. 글은 탄이 월간 병합 PR 수가 809개에서 10,926개로 늘어난 사례를 보여주며, 에이전트가 똑똑해졌다기보다 검사 목록이 길어진 것이라고 설명한다.

실천 방법은 단순하다. 사람이 실수를 발견하면, 채팅에서만 고치지 않고 그것을 잡을 규칙을 CHECKS.md에 추가한다. 이후 검증자는 작업마다 해당 규칙을 실행한다. 글은 첫 주에 열 가지를 발견했다면 넷째 주에는 그중 아홉 가지가 이미 검사가 되어, 새로 발견할 문제는 하나로 줄어드는 모습을 예로 든다.

"실수 하나마다 규칙 하나를 써 두고, 같은 실수를 다시 손으로 고치지 않는다."

---

6. 주간 보고서 검토를 40분에서 4분으로 줄인 예시

글은 매주 금요일 에이전트가 판매 시트와 캠페인 대시보드를 바탕으로 4쪽짜리 고객 보고서를 작성하는 상황을 예로 든다. 이전에는 숫자가 두 번 틀리고 링크가 한 번 다른 고객을 가리킨 적이 있어, 에이전트가 "완료"라고 해도 사람이 매번 보고서 전체를 읽었다. 검토에는 약 40분이 걸렸다.

검증 체계를 도입한 뒤의 흐름은 다음과 같다.

1. 작업 에이전트가 보고서를 작성한다.
2. 검증자가 CHECKS.md의 항목을 검사한다.
3. 실패한 항목은 작업자에게 돌려보내며, 수정과 재검사는 최대 3회 진행한다.
4. 사람은 검증 판정과 증거를 읽고 고객 발송을 승인한다.

검증자는 모든 숫자를 원본 시트에서 다시 계산하고, 링크를 열어보며, 지난주 대비 30%를 넘게 바뀐 수치를 출처와 함께 표시한다. 글의 예시에서 사람이 읽는 것은 "검사 7개 중 7개 통과"라는 판정과, 표시된 두 개의 변동 및 출처뿐이다. 검토 시간은 약 4분으로 줄었다.

예시의 CHECKS.md에는 다음 기준이 담겨 있다.

• 모든 숫자가 시트와 일치하는지 복사한 값이 아니라 재계산한 값으로 확인한다.
• 모든 링크가 열리고 해당 고객의 것인지 확인한다.
• 지난주 대비 30%를 넘는 변화는 출처와 함께 표시한다.
• 다른 고객 이름이 보고서 어디에도 나오지 않아야 한다.
• 600단어 미만이어야 하고, 필수 섹션 세 개가 모두 있어야 한다.
• 모든 날짜가 지난주가 아니라 이번 주의 날짜여야 한다.
• 사용한 시트 범위, 확인한 링크 목록, 지난주 대비 변경 내역을 증거로 첨부한다.

모든 항목을 통과해야 합격이며, 실패하면 실패한 항목을 돌려보낸다. 최대 3회 후에는 사람에게 묻고, 승인 전에는 고객에게 아무것도 발송하지 않는다. 글은 다른 고객 이름과 날짜를 확인하는 네 번째·여섯 번째 규칙이 첫 주부터 있었던 것은 아니며, 사람이 각각 한 번 발견한 실수에서 추가됐다고 설명한다.

---

7. 증상으로 빠진 검사를 찾는 법

에이전트를 여전히 믿기 어렵다면, 글은 불신의 증상에서 빠진 검사를 찾으라고 제안한다.

글은 이런 문제를 반드시 더 똑똑한 모델로 해결해야 하는 것은 아니라고 강조한다. 어떤 검사가 빠졌는지 파악하고 그 빈칸을 채우는 것이 우선이라는 것이다.

---

8. 피해야 할 방식과 시작하는 순서

흔한 실수 중 하나는 작업 에이전트에게 "정말 확실해?"라고 다시 묻는 것이다. 같은 실수를 만든 맥락에서 답하기 때문에 자신 있게 "그렇다"고 하거나, 오히려 맞는 부분을 바꿀 수 있다.

"고품질인지 확인해" 같은 모호한 기준도 도움이 되지 않는다. 검증자가 직접 수정까지 할 수 있게 하면 문제를 보고하는 역할에서 벗어날 수 있고, 작업자의 추론을 읽게 하면 그럴듯한 설명 때문에 나쁜 결과물을 놓칠 수 있다.

또한 마지막에만 검사하지 말고 계획부터 확인해야 한다. 잘못된 계획을 두 시간 동안 구현한 뒤에 발견하면 그 시간이 낭비된다. 수정 루프에도 제한이 필요하다. 글의 권장 방식은 세 번 시도한 뒤 사람에게 넘기는 것이다. 같은 문제를 반복해서 손으로 잡고 있다면, 습관적으로 확인할 일이 아니라 검사 규칙으로 남길 일이다.

시작은 작게 하면 된다.

1. 평소 결과를 항상 다시 확인하는 에이전트 작업 하나를 고른다.
2. 직접 검토할 때 보는 항목을 적어 첫 CHECKS.md를 만든다.
3. 두 번째 에이전트에게 결과물과 기준만 주고 검증을 맡긴다. 기본 판정은 불합격으로 두고, 합격 시 증거를 첨부하게 한다.
4. 다음 작업부터 판정과 증거를 확인한다.
5. 검증자가 놓친 실수를 사람이 발견할 때마다 검사 항목을 한 줄씩 추가한다.

글의 마지막 메시지는 분명하다. 검증 체계 없이 사람이 매번 모든 결과를 살펴야 한다면, 에이전트가 시간을 없애 준 것이 아니라 시간이 쓰이는 위치만 바꾼 것일 수 있다.