사용자가 에이전트 작업을 중단했는데 하위 검색·코드 실행·원격 작업은 계속됩니다. 취소와 자원 정리를 어떻게 연결하나요?

대화 응답을 멈추는 것과 모델 호출·도구·하위 프로세스·원격 작업이 실제 종료되는 것은 다릅니다. 상위 작업이 자식 작업의 소유권과 취소 상태를 추적하고, 중단 신호를 전파한 뒤 실제 종료 또는 불확정 상태를 확인해야 합니다. 사용자가 화면을 닫았다는 이유로 외부 효과가 취소됐다고 보고하지 않겠습니다.

작업 트리와 실행권

모델 호출이 여러 검색과 sandbox 프로세스를 시작하면 상위 작업 ID 아래 자식 ID와 자원 소유자를 기록합니다. 취소가 들어오면 새 자식 생성부터 막고 대기 중 작업을 제거하며 실행 중 작업에는 지원되는 취소 신호를 보냅니다. 이미 원격 서버에 접수된 작업은 별도 task 취소 API와 상태 조회가 필요할 수 있습니다. 지원하지 않으면 결과를 기다리거나 불확정 작업으로 남기는 정책을 사용합니다.

완료와 취소가 동시에 도착할 수 있습니다. 상태 머신에서 어떤 전이가 먼저 확정됐는지 검사하고 늦은 결과가 취소된 작업의 현재 상태를 덮지 않게 합니다. 그렇다고 늦은 성공 사실을 버리면 실제 외부 변경을 숨길 수 있으므로 관찰 결과는 감사 기록에 남기고 사용자에게 필요한 정정 상태를 제공합니다. 취소는 이미 발송된 메일이나 생성된 예약의 자동 롤백이 아닙니다.

정리 완료와 예산 반환

sandbox 프로세스에 종료 신호를 보냈어도 자식 프로세스가 남거나 파일·포트를 점유할 수 있습니다. 프로세스 그룹·실행 환경 단위로 종료를 확인하고 임시 파일·연결·예약 예산을 회수합니다. I/O가 계속 버퍼를 참조하는데 응답이 끝났다고 메모리나 동시성 슬롯을 먼저 반환하면 실제 실행량이 상한을 넘거나 수명 오류가 생길 수 있습니다.

필수로 끝내야 하는 내구 작업은 요청 수명에서 분리하되 사용자에게 그 정책을 알리고 별도 소유권·최대 수명·결과 조회를 제공합니다. 모든 작업을 무조건 detached로 만들면 취소가 사실상 작동하지 않습니다. 시험은 취소 전후 완료, 도구의 취소 무시, 원격 timeout, 자식 생성 경합과 재시작을 포함합니다. 완료·실패·취소·실행 불확정을 구분해 보고하고 잔존 작업 수·자원·외부 효과를 검사해야 실제 중단 계약이 됩니다.

실행 사례로 확인합니다

결과가 늦게 도착했을 때 사용자 화면에는 취소로 남겨야 할 수 있지만 실제 예약이 생성됐다면 별도 상태와 안내가 필요합니다. '취소 요청은 접수됐지만 외부 실행은 이미 완료됨'처럼 두 사실을 분리합니다. 보상이 가능한 경우에도 자동 보상 권한이 있는지 확인하고 없으면 사용자에게 선택을 요청합니다. 작업을 취소한 뒤 바로 동일 작업을 새로 시작하면 옛 실행과 겹칠 수 있으므로 이전 세대·논리 요청 ID를 확인합니다. 종료가 불가능한 프로세스는 격리 환경 전체를 정리하는 fallback을 둘 수 있지만 원격 외부 효과는 여전히 조회·대사해야 합니다. 취소는 실행기의 수명 관리와 사용자 결과 보고가 함께 맞아야 하는 기능입니다.