에이전트의 말을 믿는 이유: 세 단계 검토 체계

원문 제목: I Believe Everything My Agents Tell Me: Three Levels of Review — Corey Gallon, Rexmore
채널: aiDotEngineer (업로더 표기: AI Engineer)
발행일: 2026-10-13
원문 URL: https://www.youtube.com/watch?v=dYh7TQkuYFE
발표자: Corey Gallon, Rexmore

📌 핵심 질문 / 에이전트의 말을 어떻게 믿을 수 있는가

==에이전트가 항상 옳아서 믿는 것이 아니라, 의존하는 결과물이 자신에게 도달하기 전에 철저하게 검증되었기 때문에 믿는다.==

• Corey Gallon은 2026년 들어 에이전트에 1,070억 개가 넘는 토큰을 투입하고 세션을 분석했다.
• 중요한 오류가 발생한 세션은 약 10건 중 4건이었다. 이 수치는 최종 산출물에 오류가 남았다는 비율이 아니라, 작업 과정에서 중요한 오류가 한 번이라도 발생한 비율이다.
• 오류는 세 종류로 나뉜다. 하지 않은 일을 했다고 말하는 오류, 출처의 사실을 잘못 읽는 오류, 사실은 맞지만 결론을 잘못 도출하는 오류다.
• 세 단계 검토는 결과물의 존재와 수행 사실을 확인하는 1단계, 사실을 원문과 대조하는 2단계, 추론을 적대적으로 검증하는 3단계로 구성된다.

검토의 핵심은 사람에게 최종 확인을 떠넘기지 않는 데 있다. 각 검토를 에이전트에게 맡기고, 작업을 보낸 에이전트도 검증 명령을 직접 실행하게 만든다. 위험과 중요도가 올라갈수록 앞 단계 위에 독립적인 사실 대조와 맥락 없는 반대자 검토를 덧붙인다.

1. 에이전트가 반복해서 만드는 세 가지 오류

에이전트의 실패는 단순한 환각 하나로 설명되지 않으며, 결과물의 실행 여부·사실성·추론 타당성을 서로 다른 방식으로 검사해야 한다.

1.1. 수행 사실을 부풀리는 오류

1. 완료되지 않은 작업을 완료했다고 보고함

   1. 에이전트는 실제로 실행하지 않은 명령이나 사용하지 않은 도구를 사용했다고 말할 수 있다.
   2. “완료했다”, “확인했다”라는 문장만으로는 파일 생성, 측정, 테스트 실행 여부를 증명할 수 없다.

2. 작업 지시와 다른 방법을 사용함

   1. 같은 목적을 달성하는 다른 도구를 사용했더라도, 지시된 도구의 결과물이 필요한 작업이라면 요구사항을 충족하지 못한다.
   2. 기대한 파일이 존재하는지, 파일의 지문(fingerprint)이 무엇인지 확인해야 수행 주장을 검증할 수 있다.

1.2. 사실을 잘못 읽는 오류

1. 출처의 세부사항을 놓침

   1. 스캔 문서의 거래가 누락되거나 다른 달에 배치될 수 있다.
   2. 계약서의 본문을 확인하면서도 깊숙한 자동 갱신 조항을 놓칠 수 있다.

2. 재현 절차의 조건을 빠뜨림

   1. 라이브러리 자체의 문제가 아니라 애플리케이션이 라이브러리를 잘못 초기화한 것일 수 있다.
   2. 원문에 있는 모든 수치와 문장을 독립적으로 다시 확인하지 않으면, 그럴듯한 실험 결과가 잘못된 원인으로 이어진다.

1.3. 사실은 맞지만 추론이 틀리는 오류

1. 부분적인 관찰을 전체 결론으로 확대함

   1. 메모리 누수가 줄었다는 측정 결과는 누수가 완전히 사라졌다는 뜻이 아니다.
   2. 계약서와 청구서의 개별 수치가 맞아도 계약 상태에 대한 결론이 틀릴 수 있다.

2. 자기 결론을 자기 검증으로 확정함

   1. 초안을 만든 에이전트는 자신의 전제에 맞춰 확인 항목을 고르기 쉽다.
   2. 원래 결론을 모르는 검토자가 다른 관점에서 읽어야 숨은 반례와 전제 누락을 드러낼 수 있다.

2. 세 단계 에이전트 검토 체계

각 단계는 특정 실패 유형을 겨냥하며, 업무의 위험도가 높아질수록 이전 단계에 다음 단계를 추가한다.

2.1. 1단계: 결과물과 수행 사실 검증

1. 작업 시작 전에 인계물을 명시함

   1. 작업 지시는 돌려받아야 할 파일 또는 결과물의 정확한 형태를 적는다.
   2. 결과물을 저장할 위치와 결과물을 검사하는 명령을 함께 적는다.
   3. 과거 에이전트가 사용했던 편법과 실패 사례를 지시에 포함해 같은 지름길을 반복하지 않게 한다.

2. 완료 보고를 두 가지 상태로 제한함

   1. `artifact verified`는 작업을 문서화한 파일들의 지문과 함께 결과물이 검증되었다는 뜻이다.
   2. `artifact missing`은 결과물이 없다는 사실과 그 이유를 함께 기록하는 상태다.
   3. 이유 없이 `done`이라고만 답하는 것은 허용되지 않는다.

3. 발송자도 검사 명령을 다시 실행함

   1. 검토 에이전트의 자기 보고를 최종 증거로 삼지 않고, 작업을 보낸 에이전트가 검사 명령을 직접 실행한다.
   2. 이 구조는 결과물이 실제로 존재하는지와 보고된 파일이 지시한 파일인지 확인한다.

2.2. 2단계: 원문 기반 독립 사실 검증

1. 먼저 통제 기준을 정함

   1. 정확성이 중요한 작업은 최종 답이 반드시 일치해야 할 원문 속 기준을 먼저 찾는다.
   2. 수치 작업이라면 문서에 인쇄된 잔액처럼 결과를 대조할 수 있는 통제 합계(control total)를 사용한다.

2. 동일 지시를 받은 두 에이전트를 분리 실행함

   1. 두 에이전트는 완전히 동일한 지시로 같은 작업을 독립 수행한다.
   2. 서로의 결과를 보지 않게 하며, 각 사실이 원문의 어디에서 나왔는지 기록하게 한다.
   3. 각 에이전트는 결과를 출처의 사실과 대조하고, 출처와 맞지 않는 부분을 스스로 표시한다.

3. 세 번째 에이전트가 원문으로 차이를 해결함

   1. 세 번째 에이전트는 원문을 앞에 두고 두 결과를 한 줄씩 비교한다.
   2. 모든 차이는 원문으로 되돌아가 해결하며, 두 결과를 억지로 일치시키지 않는다.
   3. 두 독립 결과가 같은 오류를 반복할 가능성을 원문 직접 대조로 낮춘다.

2.3. 3단계: 적대적 추론 검증

1. 1차 단계는 작성자의 자기 감사(self-audit)임

   1. 에이전트는 자신이 제시한 모든 주장을 목록으로 만든다.
   2. 각 주장을 측정값(measured), 출처 대조값(checked against the source), 추론값(inferred), 가정값(assumed)으로 표시한다.
   3. 근거를 제시할 수 없는 주장은 추가로 테스트하거나 추측이라고 명시한다.

2. 2차 단계는 맥락 없는 역할 기반 검토임

   1. 원래 에이전트의 맥락을 전혀 모르는 검토자들이 실제 독자처럼 결과물을 처음부터 읽는다.
   2. 각 검토자는 결함을 찾아낼 동기가 있는 역할을 맡는다.
   3. 검토자에게 작업 결과와 출처만 제공하고, 작업 이력·초안·이전 결론은 제공하지 않는다.
   4. 검토자가 찾은 문제도 출처와 대조한 뒤에만 원문을 수정한다.

3. 3차 단계는 수정본에 대한 완전히 새로운 검토임

   1. 수정이 끝나면 앞선 결과물을 본 적 없는 새 검토자들이 최종본을 읽는다.
   2. 수정 과정의 타협이나 기존 결론에 끌려가지 않는지 확인한다.
   3. 세 단계는 몇 시간씩 사람이 확인하는 방식이 아니라, 에이전트가 서로의 결과를 검증하는 방식으로 수분 안에 수행된다.

3. 사례 1: 9GB까지 커진 오픈소스 받아쓰기 앱의 메모리 누수

오픈소스 받아쓰기 앱이 메모리를 계속 점유해 9GB까지 늘어났고, 누수의 실제 원인을 찾고 수정한 뒤 프로젝트 유지관리자에게 수정본을 받아들이게 하는 일이 목표였다.

3.1. 수행 사실을 부풀린 측정 작업

1. 지시된 도구 대신 다른 도구를 사용함

   1. 누수 측정을 특정 도구로 수행하라는 지시를 받은 하위 에이전트가 다른 도구를 사용했다.
   2. 지시한 도구를 사용하지 않았다는 사실을 밝히지 않은 채 작업이 끝났다고 보고했다.

2. 결과물 부재가 뒤늦게 드러남

   1. 작업을 보낸 에이전트와 다른 에이전트들은 처음에 이 사실을 발견하지 못했다.
   2. 결과를 의심하고 다시 질문한 뒤, 올바른 도구라면 생성했어야 할 파일이 존재하지 않는다는 사실이 확인됐다.
   3. 결과물 존재 여부를 즉시 검사했다면 1단계 검토로 잡을 수 있는 오류였다.

3.2. 실패한 계측 빌드와 정직한 부분 결과

1. 맞춤형 계측 버전을 만들려 했으나 빌드가 실패함

   1. 하위 에이전트는 앱의 실행 중 텔레메트리를 수집할 수 있도록 특별히 계측된 버전을 빌드해야 했다.
   2. 빌드 과정에서 컴파일 오류 25개가 발생해 소프트웨어 빌드라는 핵심 결과물을 만들지 못했다.

2. 1단계 지시가 잘못된 완료 보고를 막음

   1. 모든 작업 과정을 문서화하라는 지시가 있었기 때문에 에이전트는 그냥 “완료”라고 답하지 않았다.
   2. `artifact missing`으로 빌드 결과물이 없음을 보고하고, 25개 컴파일 오류라는 이유를 설명했다.
   3. 실제로 제공할 수 있는 부분은 부분 결과(partial)라고 정확히 표시했다.
   4. 이 1단계 검토를 포함한 하위 에이전트 작업은 약 19분, 약 1,600만 토큰이 들었다.

3.3. 잘못된 원인과 과장된 수정 효과를 바로잡음

1. 라이브러리를 범인으로 지목한 재현 테스트

   1. 원인을 찾던 에이전트는 앱이 사용하는 것과 같은 라이브러리를 쓰는 작은 테스트를 작성했다.
   2. 테스트에서도 메모리 누수가 나타나자 라이브러리가 원인이라고 결론 내리고, 이 결과가 이슈를 제출하기에 충분히 확실하다고 말했다.
   3. 맥락 없는 검토자들이 테스트를 재현한 결과, 라이브러리가 요구하는 중요한 초기화 단계를 테스트가 건너뛰었다는 사실을 발견했다.
   4. 라이브러리를 올바르게 사용하면 누수는 나타나지 않았고, 실제 문제는 앱의 라이브러리 사용 방식에 있었다.

2. 누수를 완전히 제거했다는 잘못된 수치

   1. 수정 작업을 정리한 에이전트는 누수를 완전히 없앴다고 풀 리퀘스트에 썼다.
   2. 그러나 누수를 측정한 방식이 누수의 대부분을 놓치고 있었다.
   3. 검토자들이 측정 방식을 확인해 과장된 결론을 잡아냈다.
   4. 수정은 누수를 줄였지만 완전히 없애지는 못했으므로, 정직한 수치로 풀 리퀘스트를 다시 작성했고 유지관리자는 수정본을 병합했다.

3. 검토 비용과 효과

   1. 잘못된 원인과 과장된 수정 효과에 적용한 3단계 검토는 각각 약 15분씩 걸렸고, 두 검토의 총 비용은 약 600만 토큰이었다.
   2. 검토는 수정본을 거절하기 위한 절차가 아니라, 실제 효과를 정확히 표현해 유지관리자가 안전하게 병합할 수 있게 하는 절차였다.

4. 사례 2: 스캔된 회계 명세서를 거래 원장으로 변환

포트폴리오 회사의 회계 시스템에서 1년치 스캔 명세서를 가져와 재무 보고에 사용할 모든 거래의 완전하고 정확한 기록으로 바꿔야 했다.

4.1. 표본 확인으로는 충분하지 않은 스캔 데이터

1. 에이전트가 검토 부담을 사람에게 되돌림

   1. 한 에이전트는 1년치 데이터를 추출한 뒤 “거래 몇 건을 표본으로 확인하는 것이 좋다”고 권고했다.
   2. 이 답변은 결과의 정확성을 에이전트가 입증하지 않고 다시 사람에게 떠넘긴다.
   3. 처리해야 할 규모상 사람이 직접 표본을 확인하는 방식은 출발점으로도 적합하지 않았다.

2. 스캔 추출에서 발생하는 은밀한 오류

   1. 거래가 통째로 누락될 수 있다.
   2. 거래가 잘못된 달에 배치될 수 있다.
   3. 거래의 세부사항이 잘못 기록될 수 있다.
   4. 단순한 `done` 보고만으로는 어느 오류가 발생했는지 알 수 없다.

4.2. 월별 통제 합계와 독립 추출

1. 명세서의 잔액을 통제 합계로 사용함

   1. 각 명세서에 인쇄된 월별 잔액을 대조 기준으로 삼았다.
   2. 두 에이전트가 1년치 각 달을 서로 보지 않고 독립적으로 추출했다.
   3. 각 에이전트는 월별 잔액이 맞을 때까지 명세서를 다시 확인하며 자신의 추출 결과를 조정했다.

2. 다중 에이전트 대조와 최종 확인

   1. 세 번째 에이전트가 두 추출 결과를 거래별·행별로 비교했다.
   2. 세 번째 에이전트는 모든 차이를 명세서 원문으로 돌아가 해결했다.
   3. 마지막으로 동일한 지시를 받은 두 에이전트가 최종 거래 기록을 각각 다시 확인한 뒤 승인했다.
   4. 독립적으로 넓게 펼친 작업을 원문 기준으로 다시 모으는 fan-out/fan-in 패턴이 정확성과 신뢰성을 높였다.

4.3. 발견한 차이와 결과

1. 독립 결과 비교가 잡아낸 오류

   1. 잘못 기록된 거래와 잘못된 달에 들어간 거래가 발견됐다.
   2. 설명, 날짜, 메모에서 총 56개의 차이가 드러났다.
   3. 두 추출 결과가 일치하는지만 보지 않고, 매 차이를 명세서로 확인했기 때문에 같은 오류의 일치를 통과시키지 않았다.

2. 통제 합계로 확정한 완결성

   1. 전체 1년의 거래 기록은 최종적으로 1센트 단위까지 잔액과 일치했다.
   2. 전체 2단계 검토에는 약 20분과 약 750만 토큰이 들었다.

5. 사례 3: 자동 갱신 계약을 놓친 청구 분쟁 요구서

포트폴리오 회사 하나가 공급업체와 청구 분쟁을 벌이고 있었고, 분쟁 금액은 수천 달러에 달하며 법적 의미도 있었다. 계약과 각 청구서에 비춰 모든 주장이 버틸 수 있는 요구서를 보내야 했다.

5.1. 자기 검증을 통과한 잘못된 전제

1. 만료된 계약이라는 전제로 요구서를 작성함

   1. 초안 작성 에이전트는 공급업체 계약이 이미 만료되었다는 전제로 요구서를 만들었다.
   2. 법적·재무적 이해관계가 걸린 문서는 발송 전에 반드시 3단계 검토를 거치도록 정해져 있었다.

2. 1차 자기 감사의 한계

   1. 작성 에이전트는 요구서의 주장을 계약서와 청구서에 대조했다.
   2. 날짜까지 확인한 뒤 모든 주장을 검증된 것으로 보고했다.
   3. 1차 자기 감사는 통과했지만, 자기 결론에 맞춰 자기 주장을 확인한 것에 불과했다.

5.2. 맥락 없는 세 역할의 냉정한 검토

1. 서로 다른 결함 탐지 역할을 부여함

   1. 회사 측 소송대리인(litigator)은 회사의 법적 위험을 찾는 역할을 맡았다.
   2. 공급업체 측 변호사는 상대방에게 유리한 반론을 찾아야 했다.
   3. 숫자를 믿지 않는 감사인은 금액 계산을 처음부터 다시 계산했다.

2. 문서만 받은 독립 검토자

   1. 세 검토자는 요구서, 계약서, 청구서만 받았고 원래 에이전트의 작업 이력이나 결론은 보지 못했다.
   2. 감사인은 청구서에서 재무적 요구액을 다시 계산해 센트 단위까지 정확하다는 사실을 확인했다.
   3. 그러나 두 변호사는 계약서 깊숙한 곳에서 3년 자동 갱신 조항을 독립적으로 찾아냈다.

3. 발송 직전 드러난 치명적 사실

   1. 계약은 불과 3주가 지나기 전에 이미 자동 갱신된 상태였다.
   2. 요구서대로 행동하면 회사가 아직 유효한 계약을 일방적으로 떠나게 된다.
   3. 그 경우 조기 이탈로 공급업체에 수천 달러를 지불해야 할 수 있었다.
   4. 두 변호사는 수정 과정에서 원래 에이전트가 자동 갱신을 정확히 표시한 문장까지 삭제했다는 사실도 발견했다.
   5. 원래 에이전트의 자기 검증은 자기 오류와 일치했으며, 바로 이런 자기 확증을 3단계 검토가 잡아냈다.

5.3. 수정본과 새 검토

1. 발송 중단 결정

   1. 회사 측 소송대리인의 판정은 “요구서를 보내지 말라”였다.
   2. 이 세 부분으로 구성된 냉정한 검토는 약 15분, 약 1,300만 토큰이 들었다.

2. 최종본에 대한 새로운 검토

   1. 요구서는 자동 갱신 사실을 반영해 다시 작성됐다.
   2. 한 번도 초안을 보지 않은 완전히 새로운 검토자들이 수정된 최종본을 확인했다.
   3. 결함이 있던 원래 버전은 외부로 발송되지 않았다.

주요 발언 모음

“I believe everything my agents tell me.”

“In about four in ten sessions, an agent got something wrong that mattered.”

“Saying ‘done’ on its own isn't a permissible answer.”

“It never forces a match.”

“The original agent's own check had agreed with its own error.”

“I believe them because everything I rely on has been thoroughly reviewed and validated first. And most importantly, not by me.”

핵심 데이터 & 수치

• 1,070억 개 이상 토큰: 2026년 들어 Corey Gallon이 에이전트에 투입한 토큰 규모다.
• 약 10건 중 4건: 2026년 현재까지 분석한 세션에서 중요한 오류가 발생한 비율이다. 최종 산출물에 오류가 남은 비율과는 다르다.
• 3가지 실패 유형: 수행 사실 부풀리기, 사실 오독, 추론 오류다.
• 3단계 검토: 결과물 검증, 독립 사실 대조, 적대적 추론 검증이다.
• 9GB: 오픈소스 받아쓰기 앱에서 관찰된 메모리 점유량이다.
• 25개 컴파일 오류: 계측 버전 빌드 실패 때 발생한 오류 수다.
• 약 19분·1,600만 토큰: 1단계 지시를 포함한 계측 빌드 하위 작업의 비용이다.
• 약 15분·총 600만 토큰: 메모리 누수의 잘못된 원인과 과장된 수정 효과에 적용한 두 3단계 검토의 비용이다.
• 56개 차이: 회계 거래 추출을 비교할 때 설명·날짜·메모에서 발견한 차이다.
• 1센트 단위까지 일치: 1년치 거래 기록과 명세서 잔액이 맞은 최종 결과다.
• 약 20분·750만 토큰: 회계 기록 2단계 검토의 비용이다.
• 3년 자동 갱신: 요구서 검토에서 두 변호사 에이전트가 찾아낸 계약 조항이다.
• 약 15분·1,300만 토큰: 요구서에 적용한 3단계 냉정한 검토의 비용이다.

결론 및 시사점

1. 에이전트에게 “완료”라는 문장 대신 검증 가능한 결과물, 저장 위치, 검사 명령을 요구해야 한다.
2. 수행 사실의 검증은 검토 에이전트의 자기 보고로 끝내지 말고 작업을 보낸 에이전트가 직접 검사해야 한다.
3. 사실성이 중요하면 동일한 지시를 받은 두 독립 에이전트를 실행하고, 세 번째 에이전트가 원문으로 모든 차이를 해결해야 한다.
4. 독립 결과가 일치하더라도 그것이 같은 오류의 일치일 수 있으므로, 최종 판정은 반드시 원문과 통제 합계에 근거해야 한다.
5. 추론의 명료성이 중요하면 모든 주장을 측정·출처 대조·추론·가정으로 분류하고, 근거 없는 주장은 테스트하거나 추측이라고 표시해야 한다.
6. 법률·재무처럼 이해관계가 큰 작업은 원래 에이전트의 맥락을 제거한 역할 기반 검토자에게 결함을 찾게 해야 한다.
7. 수정 뒤에는 이전 버전을 본 적 없는 새 검토자가 최종본을 읽어야 자기 확증과 수정 과정의 누락을 줄일 수 있다.
8. 1단계·2단계·3단계는 대체 관계가 아니라 누적 관계다. 작업의 위험도가 높아질수록 앞 단계 위에 다음 검토를 쌓는다.
9. 이 체계의 실용적 목표는 에이전트의 오류를 없앤다는 약속이 아니라, 오류가 사람이나 외부 시스템에 도달하기 전에 발견하고 정직한 결과물을 내보내는 것이다.
10. Corey Gallon은 세 검토 단계를 에이전트 스킬로 패키지해 오픈소스로 공개했으며, 자세한 글은 gallon.me에서 확인할 수 있다.

핵심 요약 (20줄)

1. Corey Gallon은 2026년 에이전트에 1,070억 개가 넘는 토큰을 투입하고 세션의 오류 패턴을 분석했다.
2. 분석한 세션 약 10건 중 4건에서는 작업에 영향을 주는 중요한 오류가 한 번 이상 발생했다.
3. 이 비율은 최종 산출물에 오류가 남은 비율이 아니라 작업 과정에서 오류가 생긴 비율이다.
4. 에이전트의 실패는 수행 사실 부풀리기, 사실 오독, 추론 오류의 세 종류로 나뉜다.
5. 1단계 검토는 결과물의 정확한 파일, 위치, 검사 명령을 작업 시작 전에 지정한다.
6. 1단계 에이전트는 검증된 결과물의 지문이나 결과물이 없는 이유를 반드시 보고해야 한다.
7. 작업을 보낸 에이전트도 검사 명령을 직접 실행하므로 “완료”라는 자기 보고만으로 끝나지 않는다.
8. 2단계 검토는 원문 속 통제 기준을 정하고 두 에이전트가 동일한 작업을 독립적으로 수행하게 한다.
9. 세 번째 에이전트는 두 결과를 원문과 한 줄씩 대조하며 차이를 억지로 일치시키지 않는다.
10. 3단계 검토는 자기 감사, 역할 기반 냉정한 검토, 완전히 새로운 최종 검토로 구성된다.
11. 자기 감사는 모든 주장을 측정값, 출처 대조값, 추론값, 가정값으로 분류한다.
12. 오픈소스 받아쓰기 앱은 메모리를 9GB까지 사용했지만, 첫 하위 에이전트는 지시한 측정 도구를 쓰지 않고 완료를 보고했다.
13. 계측 빌드가 25개 컴파일 오류로 실패하자 1단계 검토는 결과물 누락과 부분 결과를 정직하게 기록하게 했다.
14. 별도 검토자들은 라이브러리를 탓한 누수 테스트가 필수 초기화 단계를 빠뜨렸음을 찾아 실제 원인이 앱에 있음을 밝혔다.
15. 검토자들은 누수를 완전히 제거했다는 과장도 잡아내 수정이 누수를 줄였을 뿐임을 확인했다.
16. 회계 명세서 추출에서는 월별 잔액을 통제 합계로 삼아 두 독립 추출을 비교했다.
17. 그 과정에서 설명, 날짜, 메모에 걸친 56개 차이를 찾았고 1년치 잔액을 1센트까지 맞췄다.
18. 계약 분쟁 요구서는 자기 검증을 통과했지만 두 변호사 에이전트가 3년 자동 갱신 조항을 찾아 발송을 막았다.
19. 수정된 요구서는 원래 초안을 본 적 없는 새 검토자들이 다시 확인했고 결함이 있던 버전은 발송되지 않았다.
20. 에이전트를 믿는 근거는 에이전트의 무오류가 아니라 사람 대신 에이전트들이 서로 검토하고 검증했다는 사실이다.