MCP 태스크(비동기 툴) 완전 해설: 지속성 문제와 V1의 한계, V2에서 바뀌는 것

핵심 메시지

• MCP 태스크는 툴을 호출한 뒤 즉시 핸들을 돌려받고, 실제 작업은 백그라운드에서 오래 실행하며 중간에 사람의 승인까지 받을 수 있게 하는 사양이다.
• 사양은 태스크가 '지속성(durable)'을 가져야 한다고 못 박는다. 네트워크가 끊기고 서버나 에이전트가 죽어도 태스크는 사라지면 안 되고, 복구 후 이어서 다룰 수 있어야 한다.
• 실험 딱지를 단 첫 사양(V1)에는 태스크 목록 조회가 상태를 서버에 의존하고 필터도 없다는 확장성 문제와, 사람 입력 요청을 긴 연결로 터널링하는 복잡한 구조가 있었다.
• 다음 버전은 상태 비저장(stateless) 코어로 바뀌고 태스크는 확장 기능이 된다. 목록 조회가 사라지는 대신 클라이언트가 태스크 ID를 직접 보관해야 한다.
• 발표자는 클라이언트 구현을 직접 만들어 구매주문 처리 데모를 돌렸고, 서버가 꺼져 있는 동안 들어온 요청도 유실되지 않는 모습을 시연했다.

쉽게 이해하기

AI 에이전트가 도구를 호출할 때 우리는 대개 곧바로 답이 돌아오는 상황을 가정한다. 그러나 현실의 업무는 몇 분, 길게는 며칠이 걸리고 그사이 네트워크가 끊기거나 프로세스가 죽는다. 분산 시스템 분야에서 오래 일해 온 Temporal의 코닐리아 데이비스는 바로 이 간극을 메우려고 만들어진 것이 MCP의 '태스크(tasks)' 사양이라고 설명한다.

태스크의 개념 자체는 단순하다. 툴을 호출하면 결과 대신 핸들을 돌려받고, 그 핸들로 진행 상황을 조회하거나 값을 밀어 넣는다. 문제는 이 구조가 긴 시간 동안 실제로 동작하게 만드는 일이다. 사양은 한번 시작된 태스크가 사라져서는 안 된다고 규정하는데, 클라이언트가 죽든 서버가 재시작되든 승인 담당자가 휴가를 떠나든 태스크는 살아남아 있어야 한다는 뜻이다.

발표에서는 구매주문 처리를 예로 들었다. 주문이 들어오면 입고 사실을 기록하고, 이어서 재고 갱신·알림 같은 백오피스 작업과 인보이스 결제를 병렬로 진행한다. 이 가운데 인보이스 처리가 MCP 툴로 구현돼 ERP 검증, 사람의 승인 대기, 재대조 같은 여러 단계를 밟는다. 데모에서는 서버를 켜지 않은 상태로 주문을 넣었는데도 요청이 유실되지 않았고, 나중에 승인 신호를 보내자 백엔드가 남은 단계를 이어서 처리했다.

그렇다면 왜 아직 어떤 클라이언트도 이 사양을 구현하지 않았을까. 발표자는 첫째로 사양이 '실험적'으로 표시돼 있었고, 둘째로 구현이 정말 복잡하기 때문이라고 답한다. V1에는 서버에 '지금 어떤 태스크들이 있느냐'고 묻는 목록 조회가 있었는데, 필터가 없어 태스크가 백만 개 규모로 늘면 원하는 하나를 찾기 위해 전부 훑어야 한다. 사람 입력이 필요할 때 긴 연결을 열어두고 서버가 클라이언트에게 값을 요청하는 방식도, 그 연결이 끊기면 어디서부터 다시 시작할지가 까다로웠다.

다음 버전에서는 프로토콜이 상태 비저장으로 바뀌고, 규격이 코어와 확장으로 나뉘며 태스크는 확장 쪽에 놓인다. 목록 조회는 없어지고, 대신 클라이언트가 태스크 ID를 스스로 보관해야 한다. 사람 입력은 긴 세션 대신 클라이언트가 갱신 값을 보내는 엔드포인트로 정리된다. 라이프사이클(작업 중 → 입력 필요 → 완료·취소·실패)은 그대로 유지되는데, 발표자는 이 부분은 설계가 탄탄하다고 평가했다.

주요 인사이트

• '비동기 툴'의 어려움은 호출 방식이 아니라 지속성에 있다. 핸들을 돌려주는 그림 자체는 단순하지만, 인프라가 흔들려도 상태가 살아남게 만들려면 서버와 클라이언트 양쪽에 상당한 설계가 필요하다.
• 대규모 분산 시스템에서 상태 저장 프로토콜은 확장성의 발목을 잡는다. 백만 개 태스크를 가정하면 필터 없는 목록 조회는 쓸 수 없고, 클라이언트마다 폴링하는 구조도 버티지 못한다.
• 목록 조회가 사라진다는 것은 복구 책임이 서버에서 클라이언트로 옮겨간다는 뜻이다. 사양 문구는 '태스크 ID를 보관해야 한다(should)' 수준이지만, 보관하지 않으면 되찾을 방법이 아예 없다는 점을 발표자는 지적했다.
• 발표자가 만든 참조 구현에서는 여러 태스크가 동시에 사람 입력을 기다려도 먼저 온 것부터만 응답할 수 있는 제약이 있었다. 실무에서 태스크를 여러 개 병렬로 굴리려면 이런 클라이언트 쪽 공백을 직접 메워야 한다.
• 다음 과제는 폴링을 알림으로 바꾸는 일이다. 클라이언트마다 각 태스크를 확인하는 대신, '바뀐 것이 있느냐'를 한 곳에서 묻고 바뀐 태스크만 가져오는 방식이 확장성 측면에서 유력하다.

자주 묻는 질문

관련 AI 소식