오래 걸리는 작업에서 취소 버튼을 눌렀고 정상 응답을 받았다. 이제 서버 작업도 멈췄다고 안내해도 될까? 취소 요청이 받아들여졌다는 사실과 원래 작업이 취소로 끝났다는 사실은 다르다. 같은 작업 ID로 최종 상태를 확인해야 하며, 취소와 경합해 이미 완료된 결과도 보존해야 한다.
이 글은 AI 자동화가 비동기 작업을 시작한 뒤 사용자가 중단을 요구하는 상황을 다룬다. Google Cloud의 취소 계약과 Azure의 설계 문서를 참고하지만 모든 서비스가 같은 취소 API를 제공한다고 가정하지 않는다. 가상의 자료 묶음 생성 사례이며 실제 취소·삭제를 시험하지 않았다.
대기를 멈추는 일과 서버에 취소를 요청하는 일을 나눈다
브라우저 창을 닫거나 자동화의 로컬 대기 시간이 끝났다는 사실만으로 서버 작업이 멈췄다고 판단할 수 없다. 실제 SDK나 서비스가 연결 종료를 취소로 전달하는지, 별도 취소 호출이 필요한지 문서를 읽어야 한다. 클라이언트가 더 이상 기다리지 않는다는 상태와 서버가 계산·저장을 그만뒀다는 상태는 서로 다른 곳에서 확인된다.
취소 요청의 성공도 한 단계 더 해석해야 한다. Spanner의 operations.cancel 문서는 비동기 취소를 시작하며 취소 성공을 보장하지 않는다고 명시한다. 클라이언트는 작업 조회 등으로 취소됐는지, 취소 요청에도 불구하고 완료됐는지 확인할 수 있다. 이는 해당 메서드의 계약 사례이며 모든 Google 작업이나 다른 제품의 취소 지원을 뜻하지 않는다.
같은 문서에서는 취소 요청이 성공하면 응답 본문이 빈 JSON 객체라고 설명한다. 실제 취소가 성공한 작업은 삭제되지 않고 Operation.error의 코드 1, 즉 CANCELLED로 남는다. 따라서 빈 응답을 작업 취소 완료 증거로 읽거나, 작업 기록이 보인다는 이유로 취소 실패라고 판단하는 것도 맞지 않는다.
가상 사례: 자료 묶음 생성과 취소가 엇갈린 경우
AI가 내부 문서를 묶어 내려받을 파일을 생성하는 가상의 작업을 시작했다. 이 가상 서비스는 별도 취소 요청과 작업 조회를 지원한다고 전제한다. 사용자가 파일 생성 도중 취소를 요구했지만, 요청이 서버에 도착할 즈음 파일 생성이 끝났을 수도 있다.
자동화는 취소 대상 작업 ID와 원래 요청의 대상이 같은지 확인하고, 허용된 취소 동작을 수행한 뒤 현재 상태를 읽는다. “취소 버튼 클릭”을 최종 상태로 저장하면 이후 성공 결과가 도착했을 때 무엇을 믿어야 하는지 흔들린다. 취소 의도, 요청 응답, 작업의 최종 결과를 각각 남기면 경합을 설명할 수 있다.
| 취소 뒤 관측 | 의미 | 가상 사례의 다음 행동 |
|---|---|---|
| 취소 요청 정상 응답, 작업은 실행 중 | 취소 완료는 아직 확인되지 않음 | 문서의 간격·기한 안에서 같은 작업 상태 확인 |
| 작업이 취소 종료로 확인됨 | 서비스 계약상 해당 작업의 취소 확인 | 산출물·임시 파일 처리 범위를 별도 확인 |
| 작업 성공과 파일 ID가 확인됨 | 취소 요청과 경합해 생성이 끝났을 수 있음 | 완료 결과를 기록하고 사용·삭제 필요성을 권한 안에서 판단 |
| 다른 실패로 종료됨 | 취소 성공이라고 단정할 근거 없음 | 실제 오류와 남은 결과를 구별 |
| 조회 불가 또는 취소 지원 없음 | 서버 중단 여부 미확인 | 자동으로 재생성하지 않고 확인 경로와 담당을 남김 |
파일이 만들어졌다는 이유로 몰래 삭제해 취소된 것처럼 맞추면 안 된다. 파일 삭제가 취소 요청에 포함된 업무인지, 이미 다른 사람이 사용하거나 후속 업무가 시작됐는지 확인할 필요가 있다. 원래 요청이 외부 전송까지 포함했다면 생성 취소가 전송된 자료까지 회수한다는 뜻도 아니다.
취소 지원과 권한은 실제 동작별로 확인한다
API 문서에서 취소 메서드가 보인다는 것만으로 현재 작업의 모든 단계가 취소 가능하다고 결론 내리지 않는다. 허용되는 상태, 대상 ID, 실행 권한, 결과 확인 경로를 함께 읽는다. 작업 생성 권한과 취소·삭제 권한이 같다는 보장도 없다. 지원하지 않는 메서드를 임의로 호출하거나, 로컬 기록을 지워 중단처럼 보이게 해서는 안 된다.
Azure의 비동기 요청·응답 패턴은 상태 자원에 대한 취소 동작을 백엔드에 전달하고, 백엔드가 처리한 뒤 취소 상태를 반영하는 설계를 제안한다. 부분 되돌림과 보상이 필요한지도 따로 결정하도록 안내한다. 이것은 설계안이다. 다른 API의 DELETE가 곧 취소라는 뜻으로 옮겨 쓰지 않는다.
취소 의도와 실제 결과를 같은 항목으로 대조한다
작성자는 기존 작업 기록에 취소 대상, 요청 시각, 응답 범위, 마지막 조회 시각과 최종 상태를 붙이는 방식을 제안한다. 따로 거대한 취소 관리 계층을 만드는 것이 목적은 아니다. 다음 담당자가 “요청만 보냈는가, 서버 취소가 확인됐는가, 이미 완료됐는가”를 읽을 수 있으면 된다.
보고 문구도 관측 범위에 맞춘다. “취소 요청 전송, 최종 상태 미확인”, “작업 취소 확인, 임시 파일 정리 미확인”, “취소 요청 뒤 생성 완료 확인, 파일 사용 보류”는 서로 다른 상태다. 관측 기한을 넘기면 반복 호출을 끝낼 수 있지만 그때도 서버 중단 성공으로 바꾸지 않는다. 접수한 작업의 조회 간격과 완료 판단은 202 응답 뒤 실제 완료 확인에서 이어진다.
취소된 뒤에도 남은 외부 효과를 어떻게 처리할지는 별도 업무 판단이다. 부분 성공의 재개와 보상은 그 후속 문제를 다룬다. 이 글에서 먼저 풀어야 할 문제는 무엇을 되돌릴지가 아니라, 취소를 요청한 원래 작업이 어떤 결과로 끝났는지 확정하는 일이다.
자주 묻는 질문
취소 요청이 timeout이면 한 번 더 보내도 되나요?
문서화된 반복 호출의 안전 조건과 원래 작업 상태를 먼저 확인한다. 응답 유실은 취소 요청이 전달되지 않았다는 증거가 아니다. 같은 작업 ID를 보존하고 상태 조회로 좁힌 뒤 필요한 재요청만 판단한다.
취소 상태인데 결과 파일도 보이면 모순인가요?
서비스의 취소 계약과 결과 보존 규칙에 따라 다르다. 임시 결과나 이미 끝난 단계의 산출물이 남을 수 있는지 확인한다. 두 관측을 모두 기록하고 파일을 임의 삭제해 상태를 맞추지 않는다.
취소 요청 뒤 늦게 온 성공 웹훅은 버려도 되나요?
도착 시각만으로 버리지 않는다. 같은 작업인지 확인하고 현재 최종 상태와 대조한다. 중복 알림과 순서가 바뀐 알림의 판단은 웹훅의 전달 ID와 현재 상태 대조를 참고할 수 있다.