내가 MCP 업데이트를 기다리는 이유: AI 에이전트가 전화를 끊을 수 있게 됐다

요약

한 달 전, AI 에이전트가 쓸 도구 하나를 설계하다 멈췄다. 인터넷에서 모은 자료가 실제로 어떤 주장을 뒷받침하는지 AI로 검증하는 도구였다. 검증할 게 몇 개면 몇 초, 많이 몰아넣으면 몇 분이 걸렸다. 문제는 지금까지 AI 에이전트가 도구를 부르는 방식에 이 '몇 분'을 담을 그릇이 없다는 데 있었다.

예전 방식은 고객센터에 전화를 걸어 상담이 끝날 때까지 통화를 붙잡고 있는 것과 같았다. 2026년 7월 28일에 확정될 MCP(Model Context Protocol) 개정안은 이걸 바꾼다. 이제는 "접수됐습니다, 접수번호 드릴게요"라고 하면 나는 전화를 끊는다. 그리고 필요할 때 그 번호로 진행 상태를 다시 확인한다.

한 문장으로 줄이면 이렇다. AI와 계속 통화하던 방식에서, 일단 접수하고 나중에 다시 확인하는 방식으로 바뀌었다.

몇 분짜리 작업 하나에 막혔다

검증 도구가 하는 일은 단순했다. "이 문장이 이 자료로 뒷받침되는가"를 AI 모델에게 여러 건 한꺼번에 물어보고 답을 받는다. 물어보는 양이 많아지면 답도 몇 분씩 걸린다.

지금까지 도구 호출(tools/call)은 요청을 보내면 서버가 답을 다 채워 돌려줄 때까지 그 자리에서 기다리는 구조였다. 전화로 치면, 상담원이 "잠시만 기다려 주세요", "아직 처리 중입니다"를 반복하는 동안 나는 통화를 끊지 못한다. 긴 작업 하나가 연결 하나를 몇 분씩 붙잡고, 기다리던 쪽이 먼저 끊거나 그 몇 분 동안 연결을 비워두는 비용을 계속 치러야 했다.

예전 방식은 같은 상담원이 통화를 붙잡는 구조였다

전화가 왜 안 끊겼는지 보려면 연결이 어떻게 시작되는지 봐야 한다. 지금까지 AI 에이전트와 도구는 대화를 시작할 때 인사를 주고받고 이름표를 하나 발급받았다. 이 이름표(Mcp-Session-Id)로 이후 모든 대화가 특정 서버 한 대에 고정된다. 고객센터로 치면 "이 요청은 3번 상담원이 계속 맡습니다"라는 규칙이다. 그 상담원이 자리를 비우면 내 요청 내역을 아는 사람이 없어진다.

2025년 11월에 나온 첫 번째 접수번호 시스템도 이 구조 위에 얹혀 있었다. 그래서 세 군데서 걸렸다. 접수번호를 받을 수 있는지 미리 확인하는 절차가 따로 필요했고, 작업 중간 진행 확인은 통화를 끊지 않고 기다리는 방법뿐이었고, "내가 맡긴 작업 목록을 전부 보여달라"는 요청을 안전하게 처리할 방법이 없었다. 손보는 정도로는 안 돼서 전체를 다시 설계했다고 Tasks 확장 제안서(SEP-2663)에 적혀 있다.

새 방식은 접수하고 전화를 끊는다

2026년 7월 새 규약은 인사와 이름표를 통째로 없앴다. initialize 핸드셰이크와 Mcp-Session-Id가 스펙에서 빠졌고, 클라이언트 정보는 이제 요청마다 함께 실려 간다(_meta 필드). 요청 하나하나가 그 자체로 완결되니, 어느 서버가 응대해도 상관없다. 3번 상담원이 자리를 비워도 다른 누구든 접수번호만 있으면 이어받는다.

한 가지는 정확히 짚고 가야 한다. "끝나면 서버가 먼저 전화해 주는 콜백"은 아니다. 서버는 접수번호(task handle)를 돌려줄 뿐이고, 진행 상태는 내가 그 번호로 다시 물어봐서 확인한다(tasks/get). 콜백보다는 접수번호 기반 비동기 처리에 가깝다. 그래서 오래 걸리는 작업일수록 이 방식이 맞다. 500페이지 PDF 분석을 맡기면 서버는 "분석을 시작했습니다"와 함께 접수번호를 주고 연결을 닫는다. 그 뒤로 나는 다른 일을 하다가, 궁금할 때 번호로 상태를 확인하고, 완료되면 결과만 받으면 된다.

접수번호 하나에 다 담겨 있다

접수번호에는 다섯 가지 상태 중 하나가 붙는다. 작업 중, 추가 확인 필요, 완료, 실패, 취소됨. 상태를 확인할 때마다 서버는 "몇 초 뒤에 다시 확인하라"는 권장 주기도 알려준다. 요청이 몰리면 이 주기를 늘려서, 클라이언트들이 너무 자주 확인하러 오는 걸 막을 수 있다.

취소도 요청할 수 있다(tasks/cancel). 다만 요청한다고 그 자리에서 반드시 멈춘다는 보장은 없다. 이미 처리가 시작됐으면 중간에 못 멈추고 완료로 끝날 수도 있다. 새 규약은 이걸 "협조적 취소"라고 부른다. 서버는 요청을 들었다는 확인은 해줘야 하지만, 실제로 멈출 의무는 없다. 접수번호에는 보관 기한(ttlMs)도 있어서, 기한이 지나면 서버가 그 기록을 지워도 된다.

여러 콘텐츠를 동시에 지휘하게 된다

이게 왜 실감 나는지, 내가 자주 하는 작업으로 옮겨 보겠다. 콘텐츠 하나를 만드는 Agentic Workflow는 보통 네 단계로 흐른다. 트렌드를 분석하고, 관련 자료를 리서치해 구조화하고, 그걸 바탕으로 글을 쓰고, 마지막으로 이미지를 만든다. 각 단계가 몇 분에서 몇십 분씩 걸린다.

예전에는 하나의 세션에서 이 네 단계를 순서대로 밟아야 했다. 트렌드 분석이 끝나야 리서치를 시키고, 리서치가 끝나야 글을 쓰고, 글이 나와야 이미지를 만들었다. MCP가 각 단계를 끝낼 때까지 그 세션이 통째로 붙잡혀 있었으니, 한 번에 콘텐츠 하나밖에 만들지 못했다. 여러 편을 만들려면 세션을, 곧 채팅창을 여러 개 열어 옮겨 다니는 수밖에 없었다.

이제는 다르다. 세션이 없어지고 각 작업이 접수번호로 돌아가니, 콘텐츠 제작 워크플로 여러 개를 동시에 굴릴 수 있다. A 콘텐츠는 이미지 생성 단계에, B 콘텐츠는 글 작성 단계에, C 콘텐츠는 리서치 단계에 걸쳐 두고, 나는 접수번호로 각각의 진행 상태를 확인하며 조율한다. 한 편씩 순차로 찍어내던 일이, 여러 편을 비동기로 동시에 이끄는 오케스트레이션으로 바뀐다.

접수번호는 원래 AI의 발명품이 아니다

같은 문제를 먼저 풀어놓은 곳들이 있다.

방식	상태 확인	취소	보관 기한
웹의 "접수됐습니다" 응답 (RFC 7231)	표준 없음, 서비스마다 제각각	표준 없음	표준 없음
구글 클라우드 대량 작업 처리 (설계 문서)	조회 API로 진행률·완료 확인	요청 가능, 확실히 멈춘다는 보장 없음	서비스마다 다름
Anthropic AI 배치 처리 API (문서)	"처리 중" → "완료" 상태 변화	요청 가능, 부분 결과라도 받음	24시간 고정
MCP의 새 접수번호(Tasks)	5가지 상태값으로 세분화	요청 가능, "협조적 취소"로 명시	작업마다 다르고 진행 중에도 바뀔 수 있음

넷 다 뼈대는 같다. 접수번호 하나를 내주고, 그 번호로 상태를 확인하고, 취소는 요청만 보장한다. MCP가 다른 점은 "언제 다시 확인하러 오면 되는지"를 매번 새로 알려준다는 것이다. Anthropic처럼 24시간으로 못 박는 대신, 작업 중에도 이 값이 바뀔 수 있다. 웹 표준(RFC 7231)이 "202 접수됨"까지만 정의하고 나머지를 구현에 맡긴 자리를, 구글과 Anthropic이 각자 조회·취소 규약으로 메웠고, MCP는 그걸 AI 도구용 표준으로 정리한 셈이다.

실제로 뭐가 가능해지는가

앞서 멈췄던 자료 검증 시스템도 마찬가지였다. 오래 걸리는 작업이 이미 여러 개 있었다.

여러 웹사이트에서 자료를 한꺼번에 모으는 일. 지금은 URL 하나씩 순서대로 처리하거나, 사람이 명령어로 직접 돌려야 했다.
큰 문서 파일을 통째로 분석하는 일. 페이지가 많은 PDF 하나를 끝까지 읽고 구조화하는 데 시간이 걸린다.
자료 더미에서 검증 가능한 주장들을 대량으로 뽑아내는 일. 문서 하나가 아니라 수집한 자료 전체를 훑어야 한다.
그 주장들이 실제로 자료로 뒷받침되는지 AI로 대량 검증하는 일. 앞서 이 문제 때문에 멈췄던 바로 그 작업이다.
쌓인 자료 전체의 정합성을 한 번에 점검하는 일. 새 자료가 기존 자료와 모순되지 않는지 확인한다.

지금까지 이런 작업을 AI 에이전트가 직접 시키게 만들려면, 도구마다 다른 확인 규약을 새로 짜거나 아예 사람이 명령어로 돌리는 수밖에 없었다. 표준 접수번호가 생기면 다섯 작업 모두 같은 방식, 같은 인터페이스로 AI 에이전트에게 그대로 넘길 수 있다. 서버를 운영하는 입장에서는 차이가 더 크다. 상담원이 통화를 붙잡고 있어야 했던 구조가 "접수 → 처리 → 완료 확인"이라는 평범한 업무 프로세스로 바뀌기 때문이다. 그래서 여러 서버가 작업을 나눠 처리하기도 쉬워지고, 몇 분에서 몇 시간이 걸리는 AI 작업도 무리 없이 받을 수 있다.

미리 세워둔 원칙이 새 규약과 겹친 지점

이 시스템을 설계할 때 접수번호를 어떻게 다룰지 원칙을 미리 정해뒀다. 새 규약을 보기 전에 정한 것들이다. 확인은 요청한 쪽이 주도한다. 접수번호 자체를 진짜 기록으로 삼지 않는다. AI 에이전트를 쓰는 환경이 이 기능을 지원하지 않아도 예전 방식으로 똑같이 돌아가야 한다.

새 규약 원문을 읽고 나서 이 원칙들이 그대로 겹친다는 걸 확인했다. 확인을 요청한 쪽이 주도한다는 것은, 서버가 콜백하는 게 아니라 클라이언트가 번호로 다시 확인한다는 새 규약의 방향과 같은 결론이다. 취소가 협조적이라는 것은 "실제로 멈추는 로직은 시스템 쪽이 따로 갖고 있어야 한다"는 원칙과 정확히 만난다. 접수번호가 진짜 기록이 아니라는 것과, 보관 기한이 지나면 서버가 지워도 된다고 정해둔 것도 같은 방향이다. 반대로 세웠다면 지금 처음부터 다시 설계해야 했을 것이다.

그래서 언제부터 쓸 수 있나

이번 개정안은 후보안일 뿐 최종 확정본이 아니다. 2026년 5월 21일에 내용이 잠겼고, 최종본은 7월 28일에 나온다. 그 사이 열 주 동안 여러 AI 도구 제작사가 실제로 써보며 검증한다. 이번 개정에서 오래된 기능이 "곧 없어질 예정"으로 표시된 뒤에도 최소 열두 달은 그대로 동작하게 정해둔 전례가 있으니, 이 기능이 앞으로 또 바뀌더라도 최소한 그 정도 유예는 있다는 뜻이다.

지금 당장 정할 건 하나다. 이 기능을 시스템에 언제부터 실제로 켤지. 최종본이 나오고 주요 제작사 몇 곳이 실제로 구현한 다음이 될 것 같다. 그 전까지는 예전 방식, 직접 접수번호 비슷한 걸 만들어 붙이는 방식이 기본값이다.

마무리

접수번호 기능이 오랫동안 실험 딱지를 못 뗀 이유는 기능이 부족해서가 아니었다. 그 기능이 기대고 있던 바닥, 통화를 특정 상담원에게 고정하는 규칙이 프로토콜에서 통째로 빠졌기 때문이다. 바닥이 빠지면 그 위에 있던 것도 다시 지어야 한다.

미리 세워둔 원칙 몇 줄이 새 규약과 겹친 게 우연이 아니길 바라지만, 확인할 방법은 하나뿐이다. 최종본이 나오고 실제로 이 기능을 켰을 때, 예전 방식으로 되돌리는 안전장치를 걷어내도 시스템이 그대로 돌아가는지 보는 것.