AI 에이전트가 여러 단계의 작업을 하다가 멈췄다면, 가장 먼저 할 일은 무조건 처음부터 다시 실행하는 것이 아닙니다. 어디까지 완료됐는지, 외부에 어떤 변경이 이미 일어났는지, 다시 실행해도 되는 작업인지부터 확인해야 합니다. 특히 메시지 전송이나 결제처럼 한 번 실행하면 되돌리기 어려운 작업은 더 주의해야 합니다.
작업 상태를 기록해 이어가는 방식은 도움이 되지만, 기록 하나만으로 모든 외부 작업을 되돌리거나 중복을 막을 수는 없습니다. 에이전트의 도구 호출과 외부 시스템의 실제 상태가 항상 동시에 저장된다는 보장이 없기 때문입니다.
대화 기록과 실제 작업 상태는 다릅니다
가상의 자동화가 보고서를 만들고 담당자에게 이메일을 보내는 상황을 생각해 보겠습니다. 파일을 만들고 메일까지 보낸 직후 연결이 끊겼다면, AI의 마지막 대화에는 ‘이메일을 보내는 중’이라고만 남아 있을 수 있습니다. 이 상태에서 무조건 같은 단계를 다시 실행하면 메일이 중복 발송될 수 있습니다.
이때 확인할 것은 대화의 마지막 문장만이 아닙니다. 보고서 파일이 실제로 저장됐는지, 발송 기록이 남았는지, 작업 시스템이 어떤 상태를 기록했는지를 함께 봐야 합니다. 이 예시는 위험을 설명하기 위한 가상의 상황이며 실제 발송 사고 사례는 아닙니다.
| 기록할 항목 | 확인하는 이유 |
|---|---|
| 작업 목표와 입력 | 무엇을 처리하려 했는지 확인 |
| 단계별 완료 상태 | 어디서 중단됐는지 판단 |
| 생성한 파일과 버전 | 이전 결과를 재사용할 수 있는지 확인 |
| 외부 요청 식별자와 결과 | 메일·결제·등록이 이미 실행됐는지 확인 |
| 실패 원인과 재시도 조건 | 같은 오류를 반복할 가능성 구분 |
이는 작업 기록을 설계할 때 고려할 수 있는 항목입니다. 실제 보관할 데이터는 서비스의 개인정보·접근 권한과 보관 정책에 맞춰 정해야 합니다.
체크포인트는 어디서부터 이어갈지 알려줍니다
체크포인트는 작업 진행 상태를 중간에 기록해 두는 지점입니다. 예를 들어 자료 수집과 분석이 끝난 뒤 결과를 저장하면, 다음 단계에서 장애가 발생했을 때 앞의 작업을 다시 수행할 필요를 줄일 수 있습니다. 다만 저장 시점 이전에 외부 시스템에서 발생한 변경이 함께 기록됐는지 확인해야 합니다.
특히 외부 서비스의 응답을 받기 전에 연결이 끊긴 경우에는 요청이 실행됐는지 불명확할 수 있습니다. 이때 상태가 불확실하다는 사실을 그대로 기록하고, 상대 서비스의 조회 기능이나 작업 식별자로 확인한 다음 계속하는 편이 안전합니다. 확인할 방법이 없다면 자동 재실행보다 사람의 검토가 필요한 경우도 있습니다.
재시도는 오류의 종류와 중복 가능성을 함께 봅니다
일시적인 네트워크 오류라면 다시 시도할 수 있습니다. 반면 잘못된 인증 정보나 권한 부족은 같은 요청을 반복한다고 즉시 해결되지 않을 수 있습니다. 재시도 횟수와 총 대기 시간에 상한을 두고, 반복 간격을 점차 늘리는 방식도 고려해야 합니다.
외부에 영향을 주는 요청은 같은 요청을 여러 번 보내도 결과가 중복되지 않도록 설계해야 합니다. 이를 멱등성이라고 부릅니다. 실제 지원 방식은 API마다 다르므로, 고유 요청 식별자를 제공하는지와 그 유효 범위를 해당 서비스 문서에서 확인하세요. AWS 재시도 지침은 재시도 제한·지수 백오프·지터와 함께 멱등성을 고려하도록 안내합니다.
이미 SDK나 작업 큐가 재시도하는데 바깥 코드에서도 같은 방식으로 재시도하면 요청 횟수가 의도보다 커질 수 있습니다. 어느 계층이 재시도를 담당하는지와 전체 한도를 함께 확인해야 합니다.
외부 작업은 ‘보류·확정·보상’을 구분합니다
AI가 준비한 초안처럼 아직 외부로 나가지 않은 결과는 검토 후 확정하는 흐름을 만들 수 있습니다. 반면 이미 발송된 메시지처럼 되돌릴 수 없는 결과는 같은 방식으로 취소할 수 없습니다. 일부 작업은 별도의 수정·취소 요청으로 영향을 줄일 수 있지만, 그것도 상대 시스템의 기능과 실제 실행 여부에 달려 있습니다.
Atomix 논문은 도구 호출의 효과를 추적하고, 보류 가능한 효과는 조건이 충족될 때까지 기다리며, 이미 외부화된 되돌릴 수 있는 효과에는 가능한 경우 보상 작업을 적용하는 연구를 제안합니다. 이는 논문의 실험 환경과 설계에 관한 결과입니다. 어떤 이메일이나 결제도 항상 취소할 수 있다는 뜻은 아닙니다.
긴 작업을 이어갈 때는 무엇을 남겨야 할까요?
새 세션이나 다른 작업자에게 넘길 때는 전체 대화를 무조건 복사하기보다 목표, 현재 상태, 완료한 작업, 실행 여부가 불확실한 외부 요청, 남은 단계와 확인 근거를 정리해 전달할 수 있습니다. AI가 만든 요약에는 누락이 있을 수 있으므로 실제 파일과 서비스 기록을 다시 대조해야 합니다.
컨텍스트 압축은 전달할 정보량을 조절하는 방법이고, 캐시는 같은 계산이나 입력의 일부를 재사용하는 방법입니다. 둘은 목적이 다르며 비용 절감 폭도 모델·요금·입력과 캐시 조건에 따라 달라집니다. ‘요약하면 비용이 반드시 특정 비율로 줄어든다’고 가정하지 말고 실제 사용량을 확인하세요.
복구 흐름을 적용하기 전에
우선 자주 실패하거나 외부 변경을 수행하는 단계부터 살펴보세요. 각 단계에서 저장할 상태와 재실행 가능 여부를 정하고, 안전한 테스트 환경에서 중단 상황을 만들어 확인하는 것이 좋습니다. 실제 서비스에 체크포인트를 넣었다면 기록이 남지 않은 경우와 외부 요청의 결과를 알 수 없는 경우도 시험해야 합니다.
핵심은 AI가 멈추지 않도록 약속하는 것이 아니라, 멈췄을 때 실제 상태를 확인하고 안전하게 이어갈 수 있도록 설계하는 것입니다. 특히 되돌리기 어려운 외부 행동은 자동 재시도와 별도의 승인·확인 기준을 두어야 합니다.
다음 한 걸음
내 환경에서 막힌 부분은 실행 단계와 함께 질문해 주세요. 바꿔 만든 결과도 함께 나눌 수 있습니다.