AI 에이전트가 작업을 실제로 완료했는지 확인하는 방법

Claude Code, Codex 또는 다른 에이전트에게 파일을 정리하고, 스프레드시트를 업데이트하고, 업무 레코드를 만들도록 요청했다고 가정해 보겠습니다. 에이전트는 “완료”라고 답했고 눈에 띄는 오류도 없었습니다. 이는 실행이 명백한 오류 없이 끝났다는 뜻일 뿐, 기대한 업무 결과가 실제로 저장되었다는 증거는 아닙니다.

신뢰할 수 있는 검수는 기대 최종 상태를 먼저 정의하고, 목적지 시스템에서 실제 결과를 다시 읽은 다음, 빠진 효과와 예상 밖의 효과를 모두 확인하는 방식으로 이루어집니다. 그 뒤에야 작업을 완료로 닫아야 합니다. 결과가 불명확하다면 전체 워크플로를 다시 실행하지 말고 먼저 조회해야 합니다.

도구 호출 성공이 작업 완료를 뜻하지 않는 이유

에이전트는 여러 가지 안심할 만한 중간 신호를 보여 줄 수 있습니다. 도구가 성공을 반환하거나, 프로세스가 종료 코드 0으로 끝나거나, 보고서가 생성되거나, 마지막 답변에서 모든 단계가 끝났다고 주장할 수 있습니다. 그러나 이런 신호만으로는 다음 질문에 답할 수 없습니다.

• 올바른 파일이 올바른 위치에 올바른 내용으로 저장되었는가?
• 스프레드시트나 데이터베이스에 모든 예정 레코드가 영구적으로 반영되었는가?
• 중복 행, 중복 주문, 추가 알림 또는 의도하지 않은 파일이 생기지 않았는가?
• 비동기 작업이 아직 대기 중이거나, 쓰기가 나중에 롤백되지는 않았는가?
• 에이전트가 레코드를 읽기만 하고 필요한 업데이트는 생략하지 않았는가?

Microsoft의 공개 ThinkingBox-Bench v1.0은 합성 연구 벤치마크이지 실제 운영 장애율 자료가 아닙니다. 이 릴리스에는 다섯 업무 영역의 실행 가능한 작업 507개가 포함되며, 최종 상태·부작용·지정된 대화 속성에 대한 모든 검사가 통과해야 시도가 성공으로 인정됩니다. 태그 문서는 부분 점수를 두지 않습니다. 아래의 “부분 완료”와 “미확인”은 여러분의 운영 검수 상태를 위한 표현이며 벤치마크 점수가 아닙니다.

실행 전에 검수 계약을 정의하세요

작업을 가장 빠르게 검증하려면 에이전트가 시작하기 전에 종결 조건을 적어 두어야 합니다. 최소한 다음 네 가지를 기록하세요.

항목	정의할 내용	예시
필수 상태	반드시 존재해야 하는 객체, 필드, 개수, 관계	파일 120개의 이름 변경, 시트에 고유 ID 120개 추가
금지 상태	발생해서는 안 되는 변경과 부작용	원본 파일 삭제 금지, 두 번째 이메일 금지, 다른 탭 수정 금지
기록 시스템	어떤 시스템의 저장 상태로 합격 여부를 정할지	목적지 폴더, 실제 시트 셀, CRM 레코드, 티켓 상태
재시도 식별자	이번 업무 작업 자체를 식별하는 키	현재 작업/오퍼레이션 범위의 operation_id 또는 주문 번호. 고객 ID, 파일명, 객체 ID, 매니페스트 해시는 조회 대상을 식별할 뿐 이번 작업을 단독으로 증명하지 않음

에이전트의 행동이 아니라 업무 결과를 기술해야 합니다. “스프레드시트 업데이트 도구를 호출했다”는 종결 상태가 아닙니다. “목적지 탭에 120개 행이 있고 모든 고객 ID가 고유하며 합계가 원본 매니페스트와 일치한다”는 검증 가능한 종결 상태입니다.

되돌리기 어렵거나 중복에 민감한 행동은 순서도 정의해야 합니다. 먼저 되돌릴 수 있는 파일과 레코드 변경을 완료하고 확인한 뒤, 이메일 발송·주문 제출·결제 실행 같은 단계로 넘어가세요. 앞 단계가 실패했다고 해서 되돌릴 수 없는 단계를 무작정 다시 실행해서는 안 됩니다.

실행을 쓰기 결과와 연결할 만큼의 증거를 보존하세요

한 번의 실행과 그 실행이 만든 쓰기를 연결할 수 있는 최소 증거를 남기세요.

• 원래 요청, 허용 범위, 기대 최종 상태
• 시작·종료 시간, 작업 디렉터리, 대상 매니페스트
• 에이전트 세션 ID와 반환된 작업 ID
• operation_id 또는 다른 고유 업무 키
• 실행 전 개수, 핵심 필드, 버전 또는 해시
• 명시적인 오류, 시간 초과, 권한 거부, 건너뛴 단계

결과를 검수하는 데 에이전트의 비공개 추론은 필요하지 않습니다. 재현 가능한 입력, 식별자, 범위, 목적지 상태가 필요합니다. 민감한 필드는 가리고, 검수 로그에 API 키, 액세스 토큰 또는 고객 비밀을 넣지 마세요.

에이전트의 마지막 메시지가 아니라 시스템의 종결 상태를 기다리세요

업로드, 대량 가져오기, 보고서 작업, 제3자 시스템 쓰기는 대화가 끝난 뒤에도 계속될 수 있습니다. 작업 ID를 보존하고 권위 있는 시스템을 합리적인 간격으로 조회하여 성공, 실패, 취소 또는 시간 초과라는 정의된 종결 상태가 나올 때까지 확인하세요.

조회 중에는 마지막 업데이트 시간과 진행률도 기록합니다. 목적지 시스템이 최종 일관성을 사용한다면 미리 정한 안정화 시간을 두고 다시 읽으세요. 방금 제출한 레코드가 즉시 보이지 않는다고 곧바로 실패로 판단해서도 안 되고, 끝없이 기다려서도 안 됩니다. 정해 둔 시간이 지났는데도 결정적 증거가 없다면 올바른 상태는 미확인이지 “실행되지 않음”이 아닙니다.

여섯 개의 증거 계층으로 결과를 다시 읽으세요

1. 대상 객체가 존재하며 이번 실행의 결과인지 확인하세요

경로, 파일명, 레코드 ID, 수정 시각, 버전을 확인합니다. 같은 이름의 오래된 파일은 증거가 아닙니다. 잘못된 고객에게 연결된 새 레코드 역시 유효한 결과가 아닙니다.

2. 내용과 업무 불변 조건을 확인하세요

개수, 고유성, 합계, 필수 필드, 관계, 형식을 검증합니다. 스프레드시트에서는 ID 집합, 행 수, 합계를 비교하세요. 파일에서는 매니페스트, 크기, 해시 또는 표본 내용을 비교합니다. 업무 레코드에서는 상태, 금액, 소유자, 시간 범위를 확인합니다.

3. 권위 있는 기록 시스템을 기준으로 삼으세요

에이전트의 요약, 터미널 출력, 로컬 캐시는 보조 증거일 뿐입니다. 검수는 결과를 실제로 저장하는 시스템에서 이루어져야 합니다. 파일 서비스, 실제 스프레드시트 셀, CRM, 티켓 시스템, 데이터베이스 또는 결제 원장이 그 기준입니다.

4. 모든 필수 부작용을 확인하세요

어떤 작업은 파일 하나로 끝나지 않습니다. 파일 생성, 인덱스 업데이트, 연계 업무 레코드, 알림까지 필요할 수 있습니다. 각각을 확인하고 동일한 업무 식별자로 연결되어 있는지 보세요. 필수 효과 하나라도 빠졌다면 부분 완료입니다.

5. 존재해서는 안 되는 효과를 찾으세요

검수는 기대한 것이 있는지만 확인하는 일이 아닙니다. 중복 행, 중복 레코드, 추가 이메일, 삭제된 파일, 범위 밖 수정, 잘못된 객체에 대한 쓰기를 찾아야 합니다. 예상 밖의 효과는 별도 경고로 다뤄야 합니다. 재시도가 그 피해를 키울 수 있기 때문입니다.

6. 여러 시스템의 결과를 대사하세요

파일, 시트, 업무 애플리케이션에 걸친 작업은 먼저 현재 operation_id 또는 작업 범위로 각 조회를 제한한 뒤 고객/객체 ID, 요구 상태나 버전, 매니페스트를 확인하세요. 객체 식별자가 일치해도 이번 작업이 반영됐다는 증거는 아닙니다. 명시적인 ID 집합을 비교하고 누락 항목과 추가 항목을 모두 나열하세요.

네 가지 운영 상태로 결과를 분류하세요

상태	적용 기준	다음 행동
완료	모든 필수 종결 조건이 확인되고 허용할 수 없는 추가 효과가 없음	증거를 저장하고 작업 종료
부분 완료	일부 결과는 확인됐지만 특정 객체나 단계가 빠짐	빠진 작업만 복구
미확인	시스템이 사용할 수 없거나 안정화 중이거나, 쓰기 여부를 증거로 판단할 수 없음	조회하거나 기다리고 무작정 재시도하지 않음
예상 밖의 부작용	중복, 삭제, 범위 밖 변경 또는 잘못된 객체 쓰기가 있음	자동화를 멈추고 피해를 제한한 뒤 검토 요청

미확인은 실패를 뜻하지 않습니다. 아직 모른다는 뜻입니다. 이 구분이 다음 행동이 추가 조회인지 추가 쓰기인지 결정합니다.

다음 순서로 재시도 여부를 판단하세요

1. 먼저 이번 작업을 조회하세요. 기록 시스템 조회를 operation_id 또는 주문 번호로 현재 작업 범위에 제한하고, 파일명·고객/객체 ID·요구 상태 또는 버전을 함께 사용하세요. 객체가 존재한다는 사실만으로 이번 쓰기가 완료됐다고 볼 수 없습니다.
2. 완료 경계를 찾으세요. 워크플로 전체를 하나의 불투명한 성공 또는 실패로 보지 말고, 성공한 객체와 빠진 객체를 분리해 나열합니다.
3. 멱등하게 복구하세요. 같은 키가 두 번째 업무 결과를 만들지 않는다고 시스템이 보장할 때만 빠진 항목을 제출합니다. 멱등성이 불명확하다면 되돌릴 수 없는 행동을 자동으로 재시도하지 마세요.
4. 레코드, 알림, 거래를 분리하세요. 레코드는 존재하지만 이메일이 실패했다면 이메일만 다시 보냅니다. 이메일은 전송됐는데 레코드가 불명확하다면 먼저 레코드를 조회합니다.
5. 예상 밖의 효과가 있으면 멈추세요. 잘못된 객체를 롤백하거나 복구한 뒤, 사람이 자동화를 재개해도 되는지 판단하게 합니다.

간단한 규칙은 다음과 같습니다. 부재가 확인된 경우에만 재시도하고, 부분 쓰기 뒤에는 빠진 부분만 복구하며, 결과가 불명확할 때는 행동 전에 조회하고, 시스템에 잘못된 결과가 있으면 멈추세요.

예시: 파일, 시트, CRM 레코드

다음은 가상의 예시이며 실제 고객 사고나 재현된 운영 로그가 아닙니다.

한 에이전트가 파일 120개의 이름을 바꾸고, 추적 시트에 120개 행을 쓰고, CRM에 요약 레코드 12개를 만든 뒤 완료 이메일 한 통을 보내야 합니다. 다시 읽어 보니 파일과 시트 행은 모두 정확하지만 CRM 레코드는 9개뿐이고 이메일은 이미 전송됐습니다.

올바른 상태는 부분 완료입니다. 완료도 아니고 전체 실패도 아닙니다. 안전하게 복구하려면 다음과 같이 처리합니다.

• CRM을 operation_id와 예상 업무 키 12개로 조회합니다.
• 기존 레코드 9개를 식별하고 중복 방지 키를 사용해 빠진 3개만 만듭니다.
• 최종 CRM ID 12개를 파일 및 시트 요약과 대사합니다.
• 파일 이름 변경, 120개 행 쓰기, 이메일 발송을 다시 하지 않습니다.

CRM을 조회할 수 없다면 결과를 미확인으로 둡니다. 그 상태에서 전체 실행을 반복하면 중복 레코드와 두 번째 알림이 생길 수 있습니다.

이 검수 기록을 복사해 사용하세요

필드	기록할 내용
작업과 범위	의도한 행동, 허용 목적지, 금지 변경
기대 종결 상태	객체, 필드, 개수, 관계, 최종 상태
실행 식별자	세션 ID, 작업 ID, operation_id, 업무 키
권위 있는 증거	목적지 객체, 조회 시각, ID, 링크
누락 효과	존재하지 않는 필수 객체 또는 행동
추가 효과	중복, 삭제, 범위 밖 쓰기, 추가 알림
검수 상태	완료, 부분 완료, 미확인, 예상 밖의 부작용
다음 행동	종료, 대기, 복구, 재시도, 롤백, 사람에게 인계

기록 자체도 감사 가능해야 합니다. “확인함” 한 줄만 쓰지 말고 ID 목록, 차이, 조회 시각을 첨부하세요.

BetterToken은 모델 연결을 제공할 수 있지만 결과를 대신 검수하지는 않습니다

Claude Code를 BetterToken에 연결할 때는 현재의 Claude Code 설정 및 연결 확인 가이드를 따르세요. 연결 또는 모델 오류 없이 정상 응답을 받았다는 사실은 연결 설정이 작동한다는 뜻입니다. 파일, 스프레드시트 또는 제3자 업무 레코드가 의도한 종결 상태에 도달했다는 증거는 아닙니다.

관련 실행을 찾는 데 모델 요청과 세션 식별자를 사용할 수는 있지만, 검수는 목적지 파일과 시스템에 근거해야 합니다. 모델 가용성, 성공 응답 또는 토큰 사용량은 업무 완료의 증거가 아닙니다.

작업을 닫기 전에 세 가지를 마지막으로 물어보세요

“완료”를 받아들이기 전에 다음을 확인하세요.

1. 기대 종결 상태가 에이전트의 설명이 아니라 권위 있는 시스템에서 보이는가?
2. 누락 결과, 중복 쓰기, 다른 예상 밖의 부작용을 확인했는가?
3. 결과가 불명확하다면 복구 또는 재시도를 결정하기 전에 고유 업무 키로 조회할 수 있는가?

세 질문에 대한 답이 모두 분명할 때만 작업을 닫으세요. 다음 고위험 에이전트 실행 전에 위 검수 기록을 복사해 종결 상태, 금지 상태, 재시도 식별자를 먼저 채우세요. 이 작은 준비가 나중에 중복 제출을 정리하는 비용보다 대개 훨씬 적습니다.