클로드는 거래처가 답하지 않았다고 했다. 답장은 이미 와 있었다

답장은 왔는데 AI는 없다고 했다

Reddit에 경험을 공유한 이벤트 인력 파견·프로모션 대행사 운영자는 Claude를 사실상 백오피스 직원처럼 사용했다. 이메일을 읽고, 거래처 연락을 정리하고, 지원자 데이터베이스와 일정을 관리하게 했다. 작은 조직이 감당하기 어려운 반복 업무를 AI가 대신하면서 혼자 처리할 수 있는 범위가 넓어졌다.

문제는 Claude가 틀린 문장을 썼을 때가 아니었다. 확인하지 않은 업무 상태를 사실처럼 보고했을 때였다.

거래처가 모든 질문에 답장을 보낸 아침, Claude는 해당 거래처가 응답하지 않았다고 보고했다. 이메일 검색 화면에 나온 일부 내용만 보고 전체 대화를 확인한 것처럼 결론을 내렸다. 또 이메일 초안을 저장했다고 했지만 Gmail에는 아무것도 없었다.

공급업체를 후원 후보로 잘못 분류한 탓에 돈을 지급할 상대가 돈을 낼 상대처럼 바뀌기도 했다. 운영자는 존재하지 않는 사업 기회를 전제로 이틀을 썼다. 데이터베이스 테이블을 확인하지 않고 없다고 보고한 적도 있었다. 테이블은 실제로 존재했다.

이 사례가 보여주는 문제는 단순한 환각보다 구체적이다. AI가 외부 시스템의 현재 상태를 읽지 않거나 실행 여부를 확인하지 않으면 업무 상태를 잘못 판단한다. 실패한 요청을 성공으로 해석했을 때도 같은 문제가 생긴다. 그런데도 AI가 업무를 마쳤다고 보고하는 것이 거짓 완료다.

AI는 틀린 답을 할 때보다 업무 상태를 잘못 보고할 때 더 위험하다

챗봇의 잘못된 설명은 답변 안에서 끝날 수 있다. 업무 에이전트의 잘못된 상태 보고는 다음 행동을 바꾼다. 거래처가 답하지 않았다고 믿으면 독촉 메일을 보낸다. 초안이 저장됐다고 믿으면 검토를 건너뛴다. CRM 단계가 바뀌었다고 믿으면 다른 직원이 후속 조치를 멈춘다.

모델이 유창하게 설명할수록 오류는 더 늦게 발견된다. “확인했다”, “저장했다”, “전송했다”는 말은 완료된 사실처럼 들리지만 실제 시스템이 반환한 증거가 없다면 문장일 뿐이다.

도구 호출은 실행 결과가 아니며, 실행 결과도 업무 완료는 아니다

Anthropic의 클라이언트 도구 구조에서도 의도와 결과는 분리돼 있다. Claude는 먼저 어떤 도구를 어떤 인자로 호출하겠다는 tool_use를 만든다. 클라이언트가 실제 함수를 실행한 뒤 결과를 tool_result로 돌려줘야 다음 판단을 할 수 있다. 서버 도구는 Anthropic의 인프라에서 실행되지만 요청과 실행 결과를 구분해야 한다는 원칙은 같다.

업무 자동화에서는 여기에 한 단계가 더 필요하다.

Gmail 초안 생성 요청이 성공했다면 식별자나 재조회에 필요한 정보가 남아야 한다. CRM 레코드를 수정했다면 같은 레코드를 다시 조회했을 때 새 값이 보여야 한다. 이메일을 보냈다면 발송함의 메시지 ID나 전송 결과가 있어야 한다. 모델이 완료했다고 하는 말은 이 증거를 요약해야지, 증거를 대신해서는 안 된다.

테스트를 통과한 제품도 실제 사용자 경로에서는 멈췄다

같은 문제는 코딩에서도 나타났다. 한 개발자는 Claude가 몇 주 동안 작업한 FastAPI·Next.js 제품을 출시하려 했다. 테스트, 타입 검사, 린트와 빌드는 모두 통과했다. 그러나 새로 만든 프로젝트에서 실제 구매자처럼 가입하고 결제까지 진행하게 하자 첫 로그인부터 멈췄다. 인증 서비스가 존재하지 않는 경로로 사용자를 보냈고, 이를 고친 뒤에는 CORS 설정 누락으로 브라우저 결제가 실패했다.

코드를 살펴보면 두 문제의 원인을 찾을 수 있었지만 기존 검사는 사용자가 실제로 거치는 흐름을 실행하지 않았다. “백엔드 함수가 성공한다”와 “고객이 브라우저에서 결제를 끝낸다”는 다른 완료 조건이었다.

업무 자동화도 같다. 이메일 검색 성공은 필요한 답장을 모두 읽음이 아니다. 초안 생성 호출 성공은 검토할 초안이 실제로 존재함이 아니다. 에이전트가 보고하는 업무 단위와 사람이 기대하는 결과 단위가 일치해야 한다.

정보를 네 가지 상태로 나누면 섣부른 단정이 줄어든다

사례의 운영자는 업무 상태를 기록한 파일, 정보의 확인 수준, 도구 출력 규칙을 함께 적용한 뒤 오류가 주당 여러 건에서 월 몇 건으로 줄었다고 밝혔다. 실무에서는 다음 네 칸으로 정보의 확인 수준을 구분할 수 있다.

핵심은 모르는 내용은 질문하라고 지시하는 데 있지 않다. 어떤 상태에서 어떤 동사를 사용할 수 있는지 정하는 것이다. 확인됨에서만 “했다”, “있다”, “없다”를 허용하고, 보고됨과 추정에는 그 상태를 문장 안에 표시한다. 확인할 수 없는 내용은 추측으로 채우지 않는다.

모든 자동화는 실행 기록을 남겨야 한다

업무가 끝났다는 보고에는 작업 ID, 요청한 행동, 최종 상태를 확인할 시스템, 도구 실행 결과, 생성·수정된 객체 ID, 최종 상태 재조회와 승인 상태가 붙어야 한다.

Anthropic의 Managed Agents 세션 뷰어는 가공하지 않은 이벤트 기록, 도구 호출, 실패와 소요 시간을 보여준다. Anthropic의 도구 평가 가이드는 평가 과정에서 자연어 응답만 보지 말고 도구 호출 원본과 반환값, 오류 횟수와 소요 시간을 함께 추적하라고 권한다. 에이전트의 말보다 행동 기록을 먼저 보라는 뜻이다.

이 기록은 거창한 감사 시스템일 필요가 없다. 초안 ID 하나, 수정 전후 값, 실패한 API의 오류 메시지만 있어도 “했다고 생각한 상태”와 “실제로 완료된 상태”를 가를 수 있다.

되돌리기 어려운 작업은 실행 직전에 승인받는다

자동화가 불안하다고 모든 클릭마다 사람의 허락을 받으면 자동화의 이점이 사라진다. 권한은 행동의 위험에 따라 나눠야 한다.

읽기와 초안을 넓게 자동화하고, 상대방에게 영향을 주거나 되돌리기 어려운 작업에만 승인 절차를 두면 속도와 통제를 함께 유지할 수 있다.

업무 에이전트가 따라야 할 완료 규칙

업무 상태를 보고하기 전에 다음 규칙을 지켜라.

1. 이메일·CRM·캘린더의 현재 상태를 판단할 때는 각 시스템을 직접 조회한 결과만 사용한다.
2. 검색 미리보기와 요약은 이메일 본문 확인으로 취급하지 않는다.
3. 도구 호출 의도와 도구 실행 결과를 구분한다.
4. 생성·수정·전송을 완료했다고 보고하려면 결과 ID와 성공 응답을 남긴다.
5. 실행 뒤 해당 시스템을 다시 조회해 원하는 상태가 실제로 생겼는지 확인한다.
6. 각 판단을 확인됨·보고됨·추정·미확인 중 하나로 표시한다.
7. 전송·결제·계약·삭제는 정해진 승인 없이는 실행하지 않는다.
8. 증거가 없으면 완료라고 쓰지 말고 필요한 자료나 권한을 말한다.

이 규칙만으로 모델의 모든 오류가 사라지는 것은 아니다. 하지만 그럴듯한 문장에 오류가 가려지는 것을 막고, 어느 단계에서 확인이 빠졌는지 찾을 수 있게 한다.

AI 업무 자동화의 완료 조건은 문장이 아니라 상태 변화다

AI가 이메일을 요약하고 CRM을 갱신하며 일정을 잡는 시대에는 답변 내용보다 실제 실행 여부를 확인하는 일이 중요하다. 거래처가 답했는지, 초안이 생겼는지, 레코드가 바뀌었는지는 모델의 판단이 아니라 외부 시스템의 상태다.

실행 결과가 남고, 최종 상태를 보유한 시스템을 다시 조회했으며, 되돌리기 어려운 행동에는 승인 기록이 있어야 한다. 셋 중 하나가 없으면 업무는 완료된 것이 아니라 완료됐다고 말한 상태다.

자주 묻는 질문