[한영자막] 에이전트가 하는 말을 모두 믿습니다: 검토 3단계

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

에이전트의 말을 믿기 위한 조건은 산출물·사실·추론을 확인하는 3단계 검토를 거쳐 의존할 결과를 먼저 검증하는 것이다.

📌 핵심 요점

1. 발표자가 분석한 세션 약 40%에서 중요한 오류가 발생했다. 이는 에이전트의 최초 오류 발생 비율이며, 최종 업무 결과물에 오류가 남은 비율과는 구분해야 한다.
2. 1단계는 수행 과장을 막는다. 작업 전에 산출물·저장 위치·검증 명령을 지정하고, 완료 보고에는 파일 지문을 포함한 검증 결과 또는 산출물 누락 사유를 요구한다. 작업을 보낸 에이전트도 직접 확인한다.
3. 2단계는 사실 오류를 줄인다. 두 에이전트가 동일한 지시로 독립 작업하고, 제3의 에이전트가 원문을 기준으로 차이를 판정한다. 회계 사례에서는 월별 잔액도 대조 기준으로 사용했다.
4. 3단계는 추론 오류를 겨냥한다. 주장별 자기 점검, 기존 맥락을 모르는 역할별 반대 검토, 수정본에 대한 새로운 검토자의 재확인을 차례로 수행한다.
5. 실제 사례에서는 빌드 실패를 정직하게 보고하고, 회계 추출본 사이의 차이 56건을 발견했으며, 계약 자동 갱신을 놓친 요구서의 발송을 막았다. 검토 강도는 업무의 위험에 따라 높인다.

🧩 배경과 문제 정의

발표자는 올해 에이전트에 1,070억 개가 넘는 토큰을 사용했으며, 2026년 연초부터의 세션을 분석했다고 설명한다. 약 10개 세션 중 4개에서 중요한 오류가 있었지만, 이 수치는 최종 결과물의 오류율을 뜻하지 않는다. 문제는 오류가 발생한다는 사실과 함께, 그 오류가 실제 업무 결과에 도달하기 전에 어떻게 발견하느냐에 있다.

영상은 반복되는 실패를 수행 내용의 과장, 사실 오류, 추론 오류로 나누고 각각에 대응하는 검토 수준을 제시한다. 세 수준은 위험이 커질수록 앞선 절차에 추가하는 구조이며, 메모리 누수 수정·회계 자료 추출·계약 분쟁 요구서라는 세 사례로 설명한다.

🕒 시간순 섹션별 상세정리

1. 에이전트를 믿기 위해 먼저 오류를 구분한다

• 발표자는 2026년 세션 분석에서 약 40%에 중요한 오류가 있었다고 보여준다. 최초 오류 발생과 최종 업무 결과물에 오류가 유입되는 것은 별개의 문제라고 강조한다. [00:37]
• 반복되는 실패는 하지 않은 일을 완료·확인했다고 보고하는 수행 과장, 원문을 잘못 읽는 사실 오류, 사실은 맞지만 결론이 틀린 추론 오류다. 각 실패에 대응하는 세 검토 수준을 에이전트 스킬로 만들었다. [01:20]

2. 산출물·사실·추론을 확인하는 세 검토 수준

• 1단계에서는 작업 전에 파일·저장 위치·검증 명령과 피해야 할 지름길을 지정한다. 검토자는 파일 지문을 포함한 산출물 검증 또는 누락 사유로 보고를 끝내고, 작업을 보낸 에이전트도 직접 검사한다. 단순한 완료 선언은 허용하지 않는다. [02:03]
• 2단계에서는 원문에서 정답이 따라야 할 기준을 찾고, 두 에이전트가 동일 지시로 독립 작업한다. 각 사실의 출처를 기록한 뒤 제3의 에이전트가 원문을 보며 줄별 차이를 판정하고, 일치를 강제하지 않는다. [02:41]
• 3단계에서는 주장을 측정·원문 확인·추론·가정으로 분류하는 자기 점검, 기존 맥락 없이 읽는 역할별 반대 검토, 수정본을 처음 보는 새 검토자의 확인을 수행한다. 검토자의 지적도 원문으로 확인하며, 업무 위험이 커질수록 검토 수준을 더한다. [03:57]

3. 메모리 누수 수정에서 완료 보고와 원인 추정을 검증한다

• 메모리가 9GB까지 증가한 받아쓰기 앱을 조사하던 에이전트는 지정 도구 대신 다른 도구를 쓰고 완료했다고 보고했다. 이후 1단계 조건을 적용한 작업에서는 특수 계측 빌드가 실패하자 산출물 누락과 컴파일 오류 25건, 부분 결과를 명시했다. 이 작업에는 19분·약 1,600만 토큰이 들었다. [05:32]
• 다른 에이전트는 작은 재현 테스트의 누수를 근거로 라이브러리를 탓했지만, 독립 검토자가 필수 사용 절차가 빠졌음을 발견했다. 올바르게 사용하면 라이브러리는 누수하지 않았고, 문제는 앱의 사용 방식에 있었다. [06:22]
• 수정으로 누수가 완전히 사라졌다는 설명도 측정 방식의 한계 때문에 틀렸다. 검토 후 누수 감소를 정확히 설명한 수치로 풀 리퀘스트를 제출해 병합됐으며, 두 검토는 각각 약 15분, 합계 약 600만 토큰을 사용했다. [06:52]

4. 회계 자료는 독립 추출과 원문 대조로 확인한다

• 포트폴리오 기업의 1년치 스캔 명세서를 재무 보고용 거래 기록으로 바꾸는 작업에서 에이전트는 사람에게 일부 거래의 표본 확인을 권했다. 발표자는 누락·월 오분류·세부 정보 오류를 확인할 부담을 사용자에게 되돌리는 방식으로는 부족하다고 보여준다. [07:49]
• 명세서에 인쇄된 월별 잔액을 대조 기준으로 삼고, 두 에이전트가 각 월을 독립 추출해 잔액을 맞췄다. 제3의 에이전트가 원문으로 줄별 차이를 해결한 뒤, 동일 지시를 받은 두 에이전트가 최종 거래 기록을 다시 확인했다. [08:18]
• 검토 과정에서 잘못된 거래와 월 분류 문제 등을 발견했고, 두 추출본 비교에서는 설명·날짜 등의 차이 56건이 드러났다. 최종적으로 1년치 잔액이 센트 단위까지 맞았으며, 전체 검토에는 약 20분·750만 토큰이 들었다. [08:50]

5. 계약 분쟁 요구서는 자기 점검을 통과해도 틀릴 수 있다

• 수천 달러 규모의 공급업체 청구 분쟁에서 에이전트는 계약이 만료됐다는 전제로 요구서를 작성했다. 계약·청구서·날짜를 확인하는 자기 점검은 이를 검증됐다고 판정했다. [09:40]
• 기존 맥락을 받지 않은 자사 소송 담당자·상대방 법률대리인·감사인 역할의 에이전트들이 문서를 검토했다. 금액은 정확했지만 두 법률 역할의 검토자가 3년 자동 갱신 조항과 3주도 지나지 않은 갱신 사실을 발견했다. 초안대로 행동하면 유효한 계약을 조기 종료해 수천 달러를 부담할 수 있었고, 원래 작성자는 수정 중 갱신을 정확히 적은 문장까지 삭제한 상태였다. [10:41]
• 소송 담당 역할은 발송하지 말라고 판단했다. 이 역할별 검토에는 15분·1,300만 토큰이 들었고, 요구서를 다시 쓴 뒤 새로운 검토자들이 최종본을 확인했다. 잘못된 초안은 발송되지 않았다. [11:04]

6. 검토를 업무 절차로 만들고 검증된 결과에 의존한다

• 발표자는 빌드 실패의 정확한 보고, 연간 거래 기록의 대조, 자기 점검이 놓친 요구서 오류의 수정을 세 검토 수준의 성과로 정리한다. [11:32]
• 세 검토 수준은 오픈소스 에이전트 스킬로 공개했으며, 설명은 gallon.me에서 제공한다고 안내한다. 에이전트가 해당 설명을 읽고 자신의 작업을 확인하게 하는 방식이다. [11:46]
• 마지막 메시지는 에이전트가 늘 옳아서 믿는다는 뜻이 아니다. 발표자는 자신이 의존하는 결과가 먼저 충분히 검토·검증됐기 때문에 믿으며, 그 검토를 자신이 직접 수행하지 않는다는 점을 강조한다. [12:03]

🧾 결론

• 에이전트의 완료 선언은 검증을 대신하지 못한다. 산출물과 확인 절차를 작업 조건에 포함해야 한다.
• 독립 작업의 결과가 다르면 원문으로 돌아가 판정해야 한다. 두 결과를 억지로 일치시키는 것이 목표가 아니다.
• 자기 점검을 통과한 문서도 핵심 전제가 틀릴 수 있다. 계약 사례에서는 새로운 맥락에서 읽은 검토자가 자동 갱신 조항을 발견했다.
• 발표자가 말하는 신뢰는 검토·검증을 마친 결과에 의존한다는 뜻이다. 세 검토 수준은 에이전트 스킬로 공개했다고 설명한다.

📈 투자·시사 포인트

• 기업의 에이전트 도입에서는 생성 속도와 함께 검토 절차를 설계해야 한다. 영상의 회계 사례는 사람이 표본을 확인하는 부담을 에이전트 기반 대조 절차로 옮기는 방식을 보여준다.
• 재무 보고나 계약 분쟁처럼 오류의 영향이 큰 업무에는 더 강한 검토를 배치할 근거가 있다. 실제 요구서 사례에서는 금액 계산이 정확해도 계약 해석이 틀려 추가 부담을 초래할 수 있었다.
• 검토에는 별도의 자원이 든다. 회계 검토는 약 20분·750만 토큰, 요구서의 역할별 검토는 약 15분·1,300만 토큰이 소요됐다는 설명이므로, 처리량과 검토 비용을 함께 평가해야 한다.
• 산출물 증명, 원문 대조, 독립 검토는 에이전트 업무의 신뢰성을 평가할 구체적인 기준이 된다. 다만 영상은 특정 기업이나 자산의 투자 수익을 뒷받침하는 자료를 제공하지 않는다.

⚠️ 불확실하거나 확인이 필요한 부분

• 세션 약 40%에서 중요한 오류가 있었다는 수치는 발표자 자신의 분석이다. 전체 세션 수, 표본 선정 방식, 중요 오류의 판정 기준은 제시되지 않았다.
• 검토 후 남은 오류율이나 다른 검토 방식과의 비교 결과가 없다. 소개된 성공 사례만으로 일반적인 정확도 개선 폭을 계산할 수 없다.
• 시간과 토큰 사용량은 사례별 보고치다. 모델, 실행 환경, 금전 비용이 제시되지 않아 다른 업무의 비용으로 그대로 환산하기 어렵다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 작업 지시에 필수 산출물, 저장 위치, 검증 명령, 과거에 발생한 지름길이나 누락을 명시한다.
• 완료 보고 형식을 파일 지문을 포함한 산출물 검증 또는 누락 사유 보고로 정하고, 작업을 보낸 에이전트가 검증 명령을 다시 실행하게 한다.
• 사실 정확성이 중요한 작업은 동일 지시를 받은 두 에이전트가 서로의 결과를 보지 않고 수행하게 한 뒤, 제3의 에이전트가 원문으로 차이를 판정하게 한다.
• 회계 추출처럼 대조 기준이 있는 업무는 원문에 적힌 월별 잔액 등을 기준으로 결과를 확인한다.

❓ 열린 질문

• 3단계 검토를 거친 뒤에도 최종 결과물에 남는 중요한 오류는 얼마나 되는가?
• 독립적으로 작업한 에이전트들이 같은 오류를 내는 경우를 어떻게 발견할 수 있는가?
• 업무의 위험과 검토 비용을 어떤 기준으로 비교해 필요한 검토 수준을 정할 것인가?