AI가 “완료했습니다”라고 답했는데 실제 달력에는 일정이 없을 수 있습니다. 반대로 화면에 오류가 떠도 일정은 이미 등록됐을 수 있습니다. 이때 같은 요청을 다시 보내면 문제가 해결되는 대신 일정이 두 개 생길 수도 있습니다.
AI 에이전트의 오류를 줄이려면 “AI가 틀렸다”에서 멈추지 않고 어느 단계에서 무엇이 확인됐는지를 나눠 봐야 합니다. 이 글은 새로운 도구를 설치하는 안내가 아니라, 사용자가 오류를 분류하고 다음 행동을 결정하는 진단 가이드입니다.
1. AI의 말·도구 응답·실제 결과는 다릅니다
에이전트는 모델의 판단과 검색·달력·메일 같은 외부 도구를 연결해 일을 처리합니다. 언어 모델은 그럴듯하지만 사실과 다른 내용을 생성할 수 있고, 요청 조건을 잘못 해석하거나 도구에서 필요한 정보를 받지 못할 수도 있습니다. 여러 단계가 이어지면 앞선 오류가 뒤 단계의 입력이 됩니다. Anthropic의 에이전트 설계 안내는 누적 오류 위험과 실제 도구 결과를 확인하는 반복 구조를 설명합니다.
다음 세 문장은 서로 같은 뜻이 아닙니다.
- AI가 완료라고 말했다: 문장이 생성됐다는 사실입니다.
- 도구 요청이 접수됐다: 외부 서비스가 요청을 받았지만 처리가 남았을 수 있습니다.
- 원하는 결과가 확인됐다: 대상·시간·내용까지 사용자의 목표와 맞는지 대조한 상태입니다.
예를 들어 일정이 생성됐어도 시간대나 참석자가 다르면 요청은 실행됐지만 목표는 달성하지 못한 것입니다. 여기서 사용하는 ‘설명·접수·결과’ 구분은 이 글의 점검 틀이며, 특정 서비스의 상태 코드 이름은 아닙니다.
2. 증상부터 보고 원인을 좁혀 보세요
아래는 증상만으로 확정한 원인이 아니라 먼저 확인할 후보입니다.
| 관찰한 증상 | 먼저 확인할 항목 | 다음 행동 |
|---|---|---|
| 엉뚱한 날짜·대상이 선택됨 | 요청에 날짜·시간대·대상 ID가 있었는가? 실제 도구 입력은 무엇인가? | 조건이 빠졌으면 질문하고, 잘못된 실행은 임의로 추가 수정하지 않기 |
| 출처는 있지만 답변 내용이 다름 | 원문 구간이 그 주장을 실제로 뒷받침하는가? | 답변의 해당 문장을 보류하고 원문 대조 |
| 도구는 성공인데 필요한 값이 없음 | 반환 자료에 필요한 필드가 들어 있는가? | 빈 값을 추측으로 채우지 말고 재조회 또는 확인 요청 |
| 시간 초과·연결 오류가 남음 | 외부 작업이 이미 실행됐거나 처리 중일 가능성이 있는가? | 쓰기 작업은 자동 재실행하지 말고 실제 상태 대조 |
| 같은 작업이 계속 반복됨 | 새 정보가 생기는가? 완료·호출 상한이 정해졌는가? | 반복을 멈추고 부족한 입력이나 실패 단계를 보고 |
| 외부 자료를 읽은 뒤 무관한 행동을 시도함 | 사용자의 요청과 외부 자료의 내용을 구분했는가? 권한 범위는 무엇인가? | 외부 지시를 새 승인으로 취급하지 말고 실행 중단·권한 확인 |
확인에 필요한 기록을 ‘로그’라고 하며, 실행 단계를 묶어 추적하는 기록을 ‘트레이스’라고 합니다. OpenAI의 Agents API 실행 추적 문서는 기록된 도구 입력·반환값·상태를 구분해 확인하도록 안내합니다. 다만 모든 도구에서 같은 항목이 보이는 것은 아닙니다. 기록이 없거나 늦게 도착했다는 이유만으로 실행하지 않았다고 단정할 수는 없습니다.
3. 가상 일정 등록 사례로 확인해 봅시다
아래 요청·응답과 완성 보고서는 설명용 가상 사례이며, 실제 달력에 연결하거나 일정을 등록·조회한 결과가 아닙니다.
- 요청: 2026년 11월 5일 오후 3시, 서울 시간 기준, 30분 회의를 지정 달력에 등록
- 가상 도구 응답:
status: accepted,request_id: demo-001,event_id: 없음
이 정보만으로는 “일정 등록 완료”라고 말할 수 없습니다. 이 가상 서비스에서 accepted는 접수만 의미하도록 가정했으며, 실제 상태 이름과 의미는 사용하는 서비스 문서를 확인해야 합니다.
설계상 다음에 필요한 확인은 세 가지입니다.
- 요청 식별자로 처리 상태를 확인할 수 있는가?
- 생성된 일정의 식별자와 대상 달력을 확인할 수 있는가?
- 날짜·서울 시간 오후 3시·30분 길이가 요청과 일치하는가?
권한이나 기능이 없어 확인할 수 없다면 보고 문장은 이렇게 구분합니다.
요청 접수 응답은 받았지만 일정 생성 여부는 확인하지 못했습니다. 중복 등록 위험이 있어 같은 등록 요청을 자동으로 다시 보내지 않고 확인이 필요합니다.
최종 결과물: 일정 등록 상태 보고서
다음은 위 가상 기록만으로 사람이 작성한 완성 보고 예시입니다. 작업이 성공한 척하지 않고, 확인 대기로 끝난 결과도 독자가 볼 수 있게 정리했습니다.
| 보고 항목 | 완성 예시 |
|---|---|
| 요청 목표 | 2026-11-05 서울 시간 15:00~15:30, 지정 달력에 회의 1건 등록 |
| 확인된 응답 | 접수 상태 accepted, 요청 식별자 demo-001 |
| 아직 확인되지 않은 내용 | 생성된 일정 식별자·지정 달력 반영 여부·실제 날짜와 시간 |
| 최종 판정 | 완료로 보고하지 않음. 외부 처리 상태 확인 대기 |
| 다음 행동 | 담당자가 요청 식별자와 외부 서비스의 처리 기록을 대조 |
| 재시도 조건 | 이전 요청의 실행·대기 상태와 서비스의 중복 방지 규칙을 확인한 뒤 결정. 불명확하면 자동 재시도하지 않음 |
이렇게 쓰면 다음 담당자는 어디까지 확인됐는지와 무엇을 확인해야 하는지를 같은 보고서에서 알 수 있습니다.
4. 오류가 나도 곧바로 다시 실행하지 않습니다
먼저 읽기와 쓰기를 구분합니다. 자료 조회는 원본을 바꾸지 않지만 비용·호출 제한·개인정보 접근 조건은 있습니다. 이메일 발송·결제·게시·삭제처럼 외부에 결과가 남는 쓰기 작업은 중복 실행 위험까지 살펴야 합니다.
권장 판단 순서는 다음과 같습니다.
- 이후의 쓰기 작업과 자동 반복을 멈춥니다.
- 요청 대상·도구 입력·확인된 응답을 기록합니다.
- 외부 서비스의 신뢰할 수 있는 처리 기록에서 완료·대기·실패 상태를 대조합니다.
- 이전 요청이 실행되지 않았고 앞으로도 실행될 수 없다는 점이 확인되거나, 서비스가 지원하는 중복 방지 방식으로 안전성이 확보된 경우에만 재시도를 검토합니다.
- 상태가 불명확하면 ‘미확인’으로 남기고 담당자에게 확인을 요청합니다.
같은 작업을 다시 요청해도 결과가 중복되지 않게 하는 성질을 ‘멱등성’이라고 합니다. OpenAI의 장애 후 재개 안내는 승인만으로 한 번 실행이 보장되지 않으며, 일반 조회에서 결과가 안 보인다는 것만으로 재실행이 안전하다고 볼 수 없다고 설명합니다. 실제 멱등성 키 지원·유효기간·재시도 규칙은 해당 서비스에서 확인해야 합니다.
5. 다음에 같은 문제를 찾을 수 있게 기록하세요
아래 양식은 복사해 오류 메모에 쓸 수 있습니다. 공개 게시판에 원문 로그를 통째로 올리지 말고 비밀번호·토큰·고객 정보는 제외합니다.
요청한 목표:
대상 식별자와 시간대:
허용한 작업 / 금지한 작업:
마지막으로 확인된 단계:
필요했지만 없었던 입력·반환값:
도구 응답으로 확인된 내용:
외부 시스템에서 확인된 실제 결과:
아직 미확인인 내용:
다음 확인 담당자 / 재시도 허용 조건:
재개 전에는 다음을 점검합니다.
- 부족한 조건을 추측으로 채우지 않았는가?
- 도구 성공과 업무 완료를 구분했는가?
- 완료·실패·미확인 상태를 나눴는가?
- 외부 영향이 있는 작업의 중복 위험을 확인했는가?
- 반복 상한과 사람이 확인할 조건을 정했는가?
6. 원인에 맞는 다음 글로 이동하세요
- 해야 할 일의 순서·완료 조건이 불분명하면 Planning
- 어느 입력과 반환값에서 어긋났는지 찾으려면 Tracing
- 실행을 제한하거나 승인을 넣으려면 Guardrails
- 수정 전후를 같은 기준으로 비교하려면 Evals
좋은 오류 대응은 매번 성공했다고 말하는 것이 아닙니다. 확인된 사실과 미확인 상태를 분리하고, 다음 행동이 문제를 더 키우지 않도록 결정하는 것입니다.