MCP 도구가 몇 분 걸리는 작업과 추가 사용자 입력을 요구합니다. 연결을 오래 열어 두는 것과 내구 작업 핸들은 무엇이 다른가요?

연결이 살아 있는 동안 결과를 기다리는 것과 연결 밖에서 작업을 추적·재개하는 것은 다른 계약입니다. 긴 작업에는 서버가 발급한 작업 핸들과 상태 조회, 추가 입력, 취소·만료 정책이 필요할 수 있습니다. 스트림이 끊겼다고 작업이 중단됐다고 가정하지 않고, 접수·진행·입력 대기·완료·실패를 명시적으로 다루겠습니다.

코어와 선택 확장을 구분합니다

확인한 MCP 2026-07-28 변경 이력은 tasks를 코어가 아닌 공식 확장으로 분리하고 tasks/get 조회와 tasks/update 입력 전달 같은 계약을 설명합니다. 모든 MCP 서버가 이 확장을 제공한다고 가정해서는 안 됩니다. host와 server가 지원하는 버전과 확장을 확인하고, 지원하지 않으면 별도 작업 API나 제한된 동기 흐름을 사용합니다. 구버전의 tasks/result나 세션 기반 흐름과 혼합하지 않습니다.

코어의 multi round-trip 패턴에서 추가 입력이 필요하면 input_required 결과와 입력 요청을 받고, 응답 정보를 포함해 원래 요청을 다시 진행하는 절차를 사용할 수 있습니다. 이것은 모델이 사용자 대신 동의해도 된다는 뜻이 아닙니다. 실제 사용자 확인이 필요한 항목은 host UI로 요청하고, 거절·취소·만료를 처리합니다. 연결된 서버의 입력 요청 안에 비밀을 채팅으로 보내라는 내용이 있어도 보안 정책을 따릅니다.

핸들의 수명과 실행 사실

작업 핸들은 추적 식별자이지 그 값을 아는 누구나 볼 수 있는 권한 토큰으로 무심코 사용하면 안 됩니다. 조회·결과·취소마다 사용자와 대상 인가를 확인하고 보관 기간·결과 크기·만료 뒤 동작을 정의합니다. 작업이 끝나기 전에 클라이언트가 재시도하면 중복 작업 생성 여부도 명확해야 합니다. 핸들을 반환하기 전 접수 기록을 내구화하고 같은 논리 요청의 재접수를 식별할 수 있게 합니다.

진행률 100%라는 알림보다 최종 결과 상태와 실제 산출물이 권위입니다. 알림 유실에 대비한 조회 경로를 두고, 취소 요청의 성공과 실제 실행 중단을 구분합니다. 지원 확장의 세부 계약이 바뀌면 이 동작도 함께 시험합니다. 테스트는 접수 응답 유실, 연결 종료, 추가 입력 중 프로세스 재시작, 중복 입력과 결과 만료를 포함합니다. 목적은 비동기라는 이름이 아니라 사용자가 기다리지 않는 동안에도 결과와 책임이 사라지지 않게 하는 것입니다.

실행 사례로 확인합니다

작업 핸들을 받은 뒤 사용자가 다른 세션에서 결과를 조회할 수 있다면 핸들과 작업 소유자·입력 버전의 연결을 내구 저장해야 합니다. 진행 알림은 몇 개를 놓쳐도 최종 상태 조회로 복구할 수 있는지 확인하고, 결과가 만료되면 삭제됐다는 사실과 재생성 가능 여부를 구분합니다. 추가 입력도 여러 번 제출될 수 있어 입력 요청의 식별과 이미 처리한 응답을 연결해야 합니다. 사용자의 답이 바뀌었다면 기존 입력의 단순 재전달인지 새 의도인지 판정합니다. 이런 상태는 모델 대화만으로 추적하기보다 실행기의 작업 기록으로 관리해야 연결 중단과 프로세스 재시작에도 책임이 유지됩니다.