MCP Tasks (async): Why Aren't Any Agents Supporting Them? — Cornelia Davis, Temporal

URL: https://www.youtube.com/watch?v=s4r6nk5WsZw 날짜: 2026-08-02 채널: AI Engineer (aiDotEngineer)

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

MCP(Model Context Protocol) 스펙에 2025년 11월 "MCP Tasks"라는 비동기 도구 호출 기능이 실험적(experimental)으로 추가됐는데, ==왜 아직 어떤 MCP 클라이언트도 이를 구현하지 않았는가==가 이 발표의 핵심 질문이다.

• MCP Tasks는 오래 걸리는(long-running) 도구 호출을 지원하기 위한 스펙으로, 도구를 호출하면 즉시 응답 대신 "핸들(handle)"을 돌려받고 나중에 결과를 조회하는 구조다
• 스펙상 태스크는 "사라지면 안 된다(durable)"는 요구사항이 있어, 네트워크 단절·클라이언트 다운·서버 다운·사람이 휴가를 가는 상황까지 견뎌내야 한다
• V1 스펙(2025년 11월)은 이 내구성 요구사항을 구현하기가 매우 까다로웠고, 그래서 아무도(클라이언트 개발자들이) 아직 구현하지 않은 것 — 그 사이 2026년 7월에 나올 V2 스펙에서는 상당 부분이 단순화된다

발표자 Cornelia Davis(Temporal 소속, Cloud Foundry/Kubernetes/GitOps/Weave Works 등 분산시스템 경력자)는 발주서(Purchase Order) 처리라는 구체적 예제를 통해 MCP Tasks V1의 복잡성과 V2에서의 개선점을 실제 데모로 보여준다.

---

1. 예제 시나리오: 발주서(Purchase Order) 처리 워크플로우

발표 전체를 관통하는 구체적 예제로, "비동기 MCP 도구가 왜 필요한가"를 보여주기 위해 사용된다.

1.1. 발주서(PO) 처리 흐름

1. 기본 플로우

   1. PO 접수: 구매 주문서가 들어온다
   2. 입고 기록: 상품이 도착했음을 기록한다
   3. 병렬 처리: 이후 두 갈래로 병렬 진행된다 — (a) 백오피스 작업(재고 업데이트, 알림 발송), (b) 인보이스 지불

2. 인보이스 처리 = 장시간 실행되는 MCP 도구

   1. 다단계 프로세스: 인보이스 처리는 그 자체로 여러 단계를 가진 하나의 MCP 도구다 — ERP 검증 → 사람의 승인 요청(human-in-the-loop) → ERP 재조정(reconcile) → 추가 human-in-the-loop
   2. 요청-응답 방식으로는 불가능: 이 인보이스 MCP 서버는 실행 시간이 길어서 request-response 스타일로는 작동할 수 없다 — 바로 이 지점이 MCP Tasks가 필요한 이유
   3. 시그널링 메커니즘: 발표자가 보여준 코드 스니펫에서 핵심은 "reject or approve"라는 부분 — 장시간 실행 중인 프로세스에 신호(signal)를 보내는 메커니즘이 필요하다는 것을 보여준다 (Temporal의 signal 개념과 유사)

1.2. MCP Tasks의 정의

1. 한 문장 정의
   1. 비동기 도구 호출: MCP 도구를 호출했을 때 즉시 응답을 기다리지 않고 백그라운드에서 계속 실행되다가, 나중에 결과를 받아올 수 있게 하는 것이 MCP Tasks다

---

2. MCP Tasks 개요와 복잡성의 원인

2.1. 기본 시퀀스는 단순해 보인다

1. 핸들 기반 상호작용

   1. 단순한 시퀀스 다이어그램: 도구를 호출하면 응답 대신 "핸들"을 돌려받고, 그 핸들로 계속 상호작용한다 — 언뜻 보면 전혀 어려울 게 없어 보인다("This isn't rocket science")

2. 하지만 장시간 관점(long horizon)에서는 복잡해진다

   1. 인프라 문제 발생 가능성: 오래 실행될수록 네트워크 블립, 네트워크 장애 등 인프라 문제가 발생할 확률이 높아진다
   2. 사람이 사라지는 문제: human-in-the-loop 승인을 기다리는 중에 담당자가 휴가를 가버릴 수 있다 (발표자 본인도 "저는 모레 휴가 갑니다"라고 농담)
   3. 프로세스 크래시: 에이전트가 다운될 수도 있고, MCP 서버 자체가 다운될 수도 있다

2.2. 내구성(Durability) 요구사항

1. 스펙의 명문 규정

   1. "태스크는 사라지면 안 된다": 스펙 원문에 따르면, 한번 태스크를 시작(launch)했으면 그 태스크는 반드시 내구성(durable)을 가져야 한다
   2. 의미: 클라이언트 다운, 서버 다운, 커넥션 끊김, 사람이 자리를 비우는 것 — 이 모든 상황을 태스크가 버텨내야 하고, 인프라가 복구되면 그 태스크와 다시 상호작용할 수 있어야 한다

2. 서버사이드 내구성은 별도 발표에서 다룸

   1. 관련 발표 참고: 발표자는 2026년 3월 MCP Dev Summit에서 서버사이드 내구성 구현을 다루는 발표를 별도로 했다고 언급 (오늘 발표는 그 발표의 연장선으로 클라이언트 사이드를 다룬다)

---

3. 데모 1: V1 프로토콜로 동작하는 실제 시스템

3.1. 데모 환경 설명

1. 대시보드 UI

   1. 채팅 인터페이스 대신 버튼 UI: 발표자는 "채팅으로 타이핑하는 것보다 버튼 몇 개 클릭하는 게 더 효율적"이라며 대시보드 형태의 UI로 시연
   2. PO 제출: 대시보드에서 버튼 하나로 발주서를 제출하면 목록에 나타난다

2. 서버 미기동 상태에서도 접수는 정상 작동

   1. 의도된 실수: 발표자가 백엔드(MCP 서버)와 클라이언트(fastMCP 기반)를 미처 기동하지 않은 상태에서 PO를 제출했는데도 접수(submission)는 정상적으로 이루어짐
   2. 내구성의 실증: 이는 "서버가 안 떠 있어도 작동해야 한다"는 내구성 요구사항을 우연히 실제로 증명한 장면이 됨

3.2. 실제 처리 흐름 관찰

1. 양쪽 대시보드 동시 관찰

   1. 백엔드(인보이스) 대시보드: ERP 검증 완료 후 사람의 승인(human input)을 기다리는 상태로 전환
   2. 프론트엔드(PO) 대시보드: 입고 기록 완료 후 병렬로 인보이스 프로세서 MCP 태스크를 호출하는 "task tracker workflow" 라인 아이템이 보임 — 이것이 발표자가 직접 구현한 MCP 클라이언트

2. 승인 후 처리 완료까지

   1. 승인 버튼 클릭: "input required" 상태에서 승인(approve)을 제출하면 신호가 백엔드로 전달됨
   2. 재시도 로직: ERP 처리 과정에 재시도(retry) 로직이 프로그래밍되어 있어, 몇 차례 재시도 끝에 ERP 처리가 통과되고 인보이스가 지불되며 태스크가 완료됨
   3. 인프라 중단에도 지속: 발표자는 "이 서버를 처리 중간에 죽였어도 지금 본 것과 똑같이 이어졌을 것"이라고 강조 (앞서 서버 미기동 상태에서 제출이 성공한 것이 바로 그 증거)

---

4. MCP Tasks V1의 구조와 두 가지 핵심 문제

4.1. 태스크 생명주기(Lifecycle)

1. 상태 전이

   1. working → input required → working → (complete / cancel / fail): 태스크는 이 상태들 사이를 오가며, 이 생명주기 관리가 스펙에서 가장 중요한 부분 중 하나

2. V1 프로토콜의 RPC 구성

   1. tools/call은 동일: 기존 도구 호출과 동일하되, 비동기로 실행하고 싶다는 메타데이터가 추가로 전달됨
   2. 요청-응답형 4개: task get / cancel / list / result 중 앞의 3개(get, cancel, list)는 요청-응답 스타일
   3. 커넥션 유지형 1개: task result만 커넥션을 계속 열어두는(keep connection alive) 방식

4.2. 문제 1 — Task List의 확장성 문제

1. 상태 유지형(stateful) 프로토콜
   1. 재연결 시 활용: 클라이언트가 사라졌거나, 사용자가 응답을 너무 오래 미뤘거나, 네트워크가 끊겼다 재연결했을 때 "서버야, 너 지금 무슨 태스크들 갖고 있어?"라고 물어보는 용도
   2. 필터가 없다: task list 엔드포인트에는 필터 기능이 전혀 없다 — 태스크가 1~10개면 문제없지만, 에이전트가 대량으로 돌아가서 태스크가 백만 개쯤 쌓이면 원하는 하나를 찾기 위해 백만 개를 전부 훑어야 한다
   3. 결론: "할 수 있다고 해서 해야 하는 건 아니다(Just because you can doesn't mean you should)" — 이 엔드포인트는 V2에서 완전히 제거됨

4.3. 문제 2 — Task Result의 elicitation 처리 방식

1. input required 상태를 하나의 커넥션으로 터널링
   1. 단순한 경우는 문제없음: 시작(top)과 종료(bottom) 부분은 단순한 시퀀스지만, 중간에 사람의 입력(input required)이 필요한 경우 장시간 열린 커넥션 위에서 서버가 클라이언트로부터 응답을 끌어내는(elicit) 이상한 프로토콜이 사용됨
   2. 복잡도 급증: 이 방식은 구현이 매우 까다로워짐(super tricky) — 발표자는 시간 관계상 이 부분 데모는 생략했지만, 다음 세션이 끝난 뒤 궁금하면 직접 보여주겠다고 언급

4.4. 서버사이드 구현 아키텍처

1. fastMCP 기반
   1. 서버·클라이언트 지원 둘 다 있음: fastMCP는 이미 서버사이드는 물론 일부 클라이언트사이드 기능도 지원
   2. MCP 클라이언트 프로토콜 핸들러: 아키텍처 다이어그램 좌측 하단의 "MCP client protocol handler"가 바로 앞서 설명한 지저분한 task result 프로토콜을 실제로 구현한 부분 — "커넥션이 중간에 끊기면 어떻게 되는가? 복귀했을 때 어디서부터 이어서 할 것인가?"를 전부 처리해야 함
   3. 왜 아무도 안 만들었는가에 대한 답: "그래서 아직 아무도 이 프로토콜을 지원하는 클라이언트를 안 만든 것이다 — 너무 관여할 게 많다(super involved)"

---

5. MCP Tasks V2: 무엇이 달라지는가

5.1. 배경 — Agentic AI Foundation과 Angie Jones의 블로그

1. 소속 변경과 발표 시점

   1. MCP의 새 거버넌스: MCP는 이제 Agentic AI Foundation 산하에 있으며, 그곳에서 개발자 경험을 담당하는 Angie Jones가 2026년 5월 블로그 글을 게시함
   2. 핵심 변화 예고: 그 블로그에서 발표자가 가장 기뻐한 대목은 "프로토콜이 stateless(상태 비유지형)로 바뀐다"는 것 — "대규모 분산 시스템에서 stateful 프로토콜은 최악"이라는 것이 마이크로서비스 업계에서 오래 일한 발표자의 지론

2. 구조 변화: Core + Extensions

   1. 핵심(core)과 확장(extension) 분리: V2는 스펙을 core와 extension으로 구조화하며, MCP Tasks는 이제 하나의 extension이 됨 (직전 세션들에서 다뤄진 MCPUI도 같은 방식의 extension이라고 언급)

5.2. RPC 구조 변화

1. Task List 제거

   1. 완전히 사라짐: "잘 됐다. 어차피 대규모에서는 별로 쓸모없었다"고 발표자가 평가

2. Task Result의 elicitation 방식 변경

   1. 커넥션 유지형 → 시그널형: 기존의 긴 세션 기반 elicitation 대신, 클라이언트 쪽에서 "여기 업데이트가 있다"고 알려주는 엔드포인트로 바뀜 — 이는 앞서 보여준 Temporal의 "signal" 개념과 사실상 동일한 방식
   2. 생명주기 관리는 그대로: task result 자체는 남아 있고, 상태(working/input required/complete 등) 생명주기 관리 로직은 V1과 V2에서 변하지 않음(sound) — 서버사이드에서는 인보이스가 거치는 자체 상태 머신(state machine)을 태스크 생명주기 상태와 매핑하는 작업이 필요

3. 클라이언트의 태스크 ID 영속화(persist) 필요성

   1. "should" 이지 "MUST"가 아님: task list가 사라졌기 때문에 클라이언트는 태스크 ID를 스스로 저장(persist)해야 한다 — 스펙 문구는 "클라이언트는 태스크 ID를 영속화해야 한다(should)"고 되어 있으면서도, 동시에 "영속화하지 않으면 그 태스크를 다시 찾을 방법이 없다"고 명시
   2. 발표자의 의문: "왜 이게 전부 대문자 MUST가 아닌지 잘 모르겠다"고 지적 — 사실상 필수인데 권고 수준으로 표현된 것에 대한 비판
   3. 다중 에이전트 환경에서 더 중요해짐: 다수의 에이전트가 동시에 여러 PO나 여러 작업을 처리하는 환경에서는 이 영속화가 특히 중요하다고 강조

---

6. 데모 2: V2 프로토콜과 다중 동시 태스크 처리

6.1. 여러 PO 동시 제출

1. V1과 V2의 겉모습은 동일

   1. UI 레벨에서는 차이 없음: 상위 수준에서 보면 V1과 V2 데모가 똑같아 보인다 — 차이는 클라이언트-서버 프로토콜 레벨에서 발생

2. V1 프로토콜의 FIFO 한계

   1. 동시에 여러 input required가 떠도 순서대로만 처리 가능: V1 레퍼런스 구현에서는 여러 태스크가 동시에 input required 상태여도, 클라이언트 쪽에서는 FIFO(선입선출)로만 응답할 수 있었다 — 즉 첫 번째 것에만 응답 가능
   2. 발표자의 자체 구현으로 이 한계를 우회: 발표자가 구현한 프로토콜은 이 FIFO 갭을 극복하도록 설계됨

6.2. Task Tracker Workflow 시연

1. 워크플로우로 구현된 클라이언트 프로토콜

   1. 긴 시퀀스를 워크플로우 엔진으로 구현: 앞서 보여준 복잡한 시퀀스 다이어그램 전체를 하나의 워크플로우(Temporal workflow)로 구현
   2. 서버발 elicitation 처리: 서버 사이드에서 클라이언트로 오는 elicitation 처리 로직이 포함되어 있음을 화면으로 확인시켜줌

2. V1 → V2 프로토콜 비교

   1. 훨씬 단순해진 그림: "이 지저분한 V1 그림에서 V2로 가면 클라이언트-서버 프로토콜이 훨씬 훨씬 깔끔해진다. 구현하기 훨씬 쉬워진다"

---

7. 향후 진행 중인 작업

7.1. 알림(Notification) 프로토콜을 통한 확장성 개선

1. 폴링 방식의 한계
   1. 백만 개 태스크 문제: V2에서도 여전히 "수백만" 규모까지 확장(scale)되지는 않는다 — 태스크가 백만 개 실행 중이면 클라이언트도 그 각각에 대해 get 요청을 폴링해야 하므로 확장이 안 됨
   2. 해결 방향: MCP 태스크 스펙에는 아직 발표자가 깊이 파보지 못한 알림(notifications) 프로토콜 부분이 있는데, 가능성을 보이고 있음 — 수백만 클라이언트가 각자 폴링하는 대신, 단일 엔드포인트에 "뭐 바뀐 거 있어?"라고 물으면 바뀐 항목만 알려주고 그때 해당 태스크만 조회(pull)하는 방식

7.2. fastMCP 네이티브 구현

1. 1~2개월 내 목표
   1. 동일 프레임워크로 통합: 현재 MCP 서버 구현에 쓰고 있는 것과 같은 fastMCP 프레임워크·같은 프로토콜을 그대로 사용해서 태스크 기능까지 쓸 수 있도록 만드는 것이 목표 — "훨씬 단순해질 것"

---

주요 발언 모음

"the first answer to that question is, well, cuz they're smart... the MCP tasks specification that came out in November was marked as experimental." "once you've locked launched a task it has to be durable." "Just because you can doesn't mean you should." (task list 엔드포인트에 관해) "stateful protocols are the absolute worst thing in large-scale distributed systems." "the spec right now says that clients should persist task IDs, but it also points out that if you don't persist task IDs, there is no way to get it back. So, I'm not quite sure why this doesn't have a an all caps must." "going from V1... to V2 in the client server protocol, much much cleaner. Much easier to implement." "even though this is better, it still doesn't scale to the millions."

핵심 데이터 & 수치

• MCP Tasks V1 발표 시점: 2025년 11월 (experimental 상태로 스펙 추가)
• MCP Tasks V2 발표 예정: 2026년 7월 (V2 스펙 발표, 이 강연은 그 직전 시점)
• 관련 배경 블로그: 2026년 5월, Angie Jones(Agentic AI Foundation 개발자 경험 담당)가 stateless core 전환을 발표
• 발표 소요시간: 20분 세션 (실제 발표는 약 19분 분량, 데모 2회 포함)
• 관련 이전 발표: 2026년 3월 MCP Dev Summit에서 발표자가 서버사이드 내구성 구현을 다룬 발표를 별도로 진행

결론 및 시사점

1. MCP Tasks가 아직 구현되지 않은 이유는 "복잡도" 그 자체다: 실험적 스펙이라서가 아니라, 스펙이 요구하는 내구성(durability) — 네트워크 단절, 사람의 부재, 프로세스 크래시를 모두 견뎌내면서도 태스크가 사라지지 않아야 한다는 요구사항 — 을 구현하는 난이도가 매우 높기 때문이다.
2. V1의 두 가지 근본 문제(task list의 확장성 부재, task result의 세션 기반 elicitation)는 V2에서 구조적으로 해결된다: task list 제거, elicitation을 시그널 기반 업데이트 엔드포인트로 전환, 프로토콜 전체를 stateless로 전환.
3. 다만 클라이언트는 이제 태스크 ID를 스스로 영속화해야 하는 책임을 진다: 서버가 목록을 제공해주지 않으므로, 클라이언트 사이드에서 태스크 ID 관리·재개(resume) 로직을 반드시 구현해야 한다.
4. V2도 완전한 해결책은 아니다: 수백만 규모의 동시 태스크에서는 폴링 기반 아키텍처 자체가 한계이며, 별도의 알림(notification) 프로토콜이 필요하다 — 이 부분은 아직 스펙에서도, 발표자의 구현에서도 진행 중이다.
5. 실무자에게 주는 시사점: 지금 당장 MCP Tasks를 프로덕션에 붙이려는 팀이라면 V1이 아니라 V2(2026년 7월 발표 예정) 및 fastMCP의 네이티브 지원(1~2개월 내 예정)을 기다리는 편이, 지저분한 V1 프로토콜을 직접 구현하는 것보다 훨씬 적은 노력으로 목표를 달성할 수 있다.