MCP Tasks로 장시간 작업 상태를 설계하는 법

AI 도구 호출이 짧을 때는 요청과 응답만 있으면 충분합니다. 하지만 파일 변환, 배포, 대량 분석처럼 오래 걸리는 작업은 사용자가 기다리는 동안 상태를 확인하고, 중단하거나 다시 이어야 합니다.

MCP 생태계에서 Tasks와 관련된 논의가 확장되고 있지만 사양과 구현은 계속 변할 수 있습니다. 이번 글은 특정 SDK의 복사 예제가 아니라 장시간 작업을 설계할 때 필요한 상태를 정리하는 글입니다.

작업 상태와 결과를 분리합니다

작업이 실행 중이라는 사실과 결과 파일이 준비됐다는 사실은 다릅니다. 상태 조회는 진행률·마지막 업데이트·실패 이유를 보여 주고, 결과 조회는 완료된 산출물의 위치와 검증 상태를 보여 줘야 합니다.

저는 작업을 만들 때 사용자에게 보이는 상태와 내부 실행 상태를 따로 둡니다. 내부가 여러 단계여도 외부에는 대기·실행·완료·실패·취소·만료처럼 이해하기 쉬운 상태만 제공합니다.

• 대기: 실행 슬롯을 기다리는 상태입니다.
• 실행: 작업이 진행 중이고 마지막 업데이트 시각이 있습니다.
• 완료: 결과가 만들어지고 검증된 상태입니다.
• 실패·취소·만료: 재시도 조건과 보존된 로그가 있는 상태입니다.

TTL과 보존 범위를 처음부터 정합니다

오래된 작업 상태와 결과를 영원히 보관하면 데이터와 비용이 쌓입니다. 반대로 너무 빨리 지우면 사용자가 결과를 받을 수 없습니다. 작업 상태, 로그, 결과 파일에 서로 다른 TTL을 둘 수 있습니다.

TTL이 지난 작업을 ‘실패’로 표시할지 ‘만료’로 표시할지도 정합니다. 사용자가 다시 실행해야 하는 상황과 내부 오류를 같은 메시지로 보여 주면 복구가 어렵습니다.

대상보존 목적만료 후 처리

상태	사용자 진행 확인	만료 표시·재실행 안내
로그	실패 원인 분석	민감정보 제거 후 단기 보존
결과	다운로드·검증	삭제 또는 별도 보관

취소와 재시도는 멱등성을 전제로 합니다

사용자가 취소를 눌렀다고 이미 실행된 외부 요청이 되돌아가는 것은 아닙니다. 단계별로 취소 가능한 지점을 정의하고, 중단되지 않은 작업이 계속되더라도 결과를 중복 생성하지 않게 해야 합니다.

재시도도 같은 작업을 처음부터 다시 하는지, 실패한 단계부터 이어 가는지 정합니다. 파일 이름과 외부 API 호출에 멱등 키를 두면 중복 위험을 줄일 수 있습니다.

• 취소 가능: 대기열·다음 단계 시작 전처럼 안전하게 멈출 수 있는 지점입니다.
• 취소 지연: 이미 외부 시스템에 요청해 즉시 되돌릴 수 없는 지점입니다.
• 재시도: 같은 입력으로 결과가 중복되지 않는지 확인합니다.

작업 상태는 사용자에게 정직해야 합니다

진행률을 계산할 수 없는데 73%처럼 보여 주면 기대가 잘못됩니다. 단계 기반 작업이면 현재 단계와 예상 조건을 보여 주고, 측정할 수 없다면 ‘처리 중’과 마지막 업데이트 시각만 표시합니다.

MCP의 사양과 구현이 변하는 시기에는 어떤 버전에서 무엇을 확인했는지 기록합니다. 새로운 기능을 사용했다는 사실보다 작업이 다시 실행되고 실패를 설명할 수 있는지가 중요합니다.

AI 도구를 사용할 때 남겨야 할 경계

AI 도구는 조사와 구조화에 도움을 주지만, 결과의 책임까지 가져가지는 않습니다. 저는 작업을 시작할 때 입력에 포함해도 되는 정보, 외부 출처로 확인해야 하는 주장, 사람이 직접 판단해야 하는 결과를 구분합니다. 이 세 가지가 섞이면 AI가 만든 문장이나 도구 호출을 실제 경험과 사실처럼 받아들이기 쉽습니다.

작은 샘플로 실행한 뒤 기록을 검토하는 것도 중요합니다. 프롬프트·도구 인자·응답·파일 결과 중 무엇을 보관할지 정하고, 민감정보와 권한을 최소화합니다. 한 번 잘 나온 결과보다 같은 조건에서 다시 확인할 수 있는 과정이 더 오래 남는 자산입니다. 최신 사양과 정책을 다루는 글은 조사일과 버전을 고정하고 발행 전에 공식 문서를 다시 읽습니다.

• 입력 범위: 원고·개인정보·토큰·파일 경로 중 무엇을 보내지 않을지 정합니다.
• 근거: 공식 문서와 직접 경험을 분리해 기록하고 URL을 보관합니다.
• 검수: 사실·출처·문체·권한·재현성을 사람이 확인합니다.
• 중단 조건: 결과가 반복되지 않거나 비용·권한이 커지면 사용을 멈춥니다.

다음 작업에서 다시 확인할 항목

한 번 적용한 방법이 언제나 같은 결과를 내는 것은 아닙니다. 사람과 서비스와 원고의 조건이 바뀌면 같은 원칙도 다른 판단을 요구합니다. 그래서 저는 글을 작성한 뒤 결론만 보관하지 않고, 결론이 성립한 조건과 다시 확인해야 할 조건을 함께 적습니다. 이 기록이 있으면 몇 달 뒤 글을 업데이트할 때 당시의 경험을 현재의 사실처럼 착각하지 않을 수 있습니다.

특히 버전·정책·가격·플랫폼 기능처럼 외부에서 바뀌는 내용은 조사한 날짜와 공식 문서의 주소를 남깁니다. 발행 시점에 문서가 달라졌다면 본문에 변경 사실을 표시하고, 직접 확인하지 못한 부분은 독자가 알 수 있도록 범위를 제한합니다. 경험을 공유하는 글도 다른 사람의 환경에 그대로 적용될 수 있으므로, 성공 사례보다 실패 조건을 함께 쓰는 편이 안전합니다.

마지막으로 이 글을 읽은 분이 바로 할 수 있는 행동은 하나로 줄입니다. 모든 항목을 한꺼번에 바꾸기보다 현재 상태를 기록하고, 작은 실험을 한 번 실행하고, 결과를 다시 적는 순서입니다. 그렇게 쌓인 기록이 다음 글의 소재가 되고, 처음의 판단을 더 정확하게 고쳐 쓰는 근거가 됩니다.

• 범위 표시: 이 글의 결론이 적용되는 환경과 적용되지 않는 환경을 구분합니다.
• 날짜 기록: 버전·정책·가격·문서를 확인한 날짜를 남깁니다.
• 실패 조건: 어떤 상황에서는 이 방법을 쓰지 말아야 하는지 적습니다.
• 작은 실행: 독자가 오늘 시도할 수 있는 가장 작은 행동을 고릅니다.
• 후속 기록: 실행 결과와 다음에 바꿀 조건을 별도 메모로 남깁니다.

이 기록을 나중에 다시 읽을 때는 결과만 보지 않고 당시의 조건도 함께 확인합니다. 조건이 달라졌다면 결론을 그대로 복사하지 말고 현재의 입력과 제약을 다시 적습니다. 그 과정을 거쳐야 이 글이 단순한 경험담이 아니라 다음 판단을 돕는 작업 기록으로 남습니다.

마치며

장시간 AI 작업은 도구 호출 하나가 아니라 상태·결과·취소·만료를 가진 작은 작업 시스템입니다. 먼저 작업 상태 여섯 가지와 각 상태에서 사용자가 할 수 있는 행동을 표로 만들어 보시기 바랍니다.

참고한 문서: MCP 기본 사양 · MCP 최신 Tasks 논의