작업 추적을 위한 MCP 서버: 2026년 MCP Tasks 확장 기능이 규정하는 것
요약
MCP Tasks 확장 기능이 해결하려는 장기 실행 작업(long-running work)의 문제와 프로토콜의 구조를 분석합니다. 연결 기반이 아닌 내구성이 있는 작업 상태 핸들링을 위한 상태 머신과 설계 원칙을 다룹니다.
핵심 포인트
- 장기 실행 작업은 단순 요청/응답 사이클이 아닌 내구성이 있는 핸들이 필요함
- MCP Tasks는 상태 머신 기반의 내구성이 있는 작업 모델을 지향함
- 작업 ID는 채팅 기록이 아닌 상태 핸들로 취급되어야 함
- 재시도 및 만료 정책 등은 여전히 진화 중인 실험적 영역임
작업 추적 (task tracking)을 위한 MCP 서버를 구축하고 있다면, 결국 동일한 문제에 직면하게 됩니다. 바로 작업이 연결(connection)보다 더 오래 지속된다는 점입니다. 2026년 6월 기준으로, MCP Tasks가 메우고자 하는 간극이 바로 이것입니다. 중요한 점은 이 기능의 존재 여부가 아니라, 프로토콜이 실제로 얼마나 안정화되었는지, 무엇이 여전히 실험적인 상태인지, 그리고 애플리케이션 계층 (application-layer)의 작업 보드들이 이미 다른 방식으로 동일한 형태의 문제를 어떻게 해결했는지입니다.
이 글은 개발자와 기술 아키텍트 (technical architects)를 위한 회의적인 시각의 읽기 자료입니다. 우리는 현재의 MCP Tasks 의미론 (semantics)을 살펴보고, 상태 머신 (state machine)을 검토하며, 이 확장 기능을 A2A와 비교하고, 마지막으로 에이전트가 읽을 수 있는 내구성이 있는 작업 상태 (durable, agent-readable task state)의 최소한의 애플리케이션 계층 예제로 마무리할 것입니다. Agiflow는 에이전트에게 범위가 지정된 작업 상태 (scoped task state)를 노출하는 보드의 하나의 구체적인 예시로만 등장할 뿐, 권장 사항이나 사양의 성숙도를 증명하는 용도로 사용되지 않습니다.
이것이 존재하는 이유
핵심 문제는 간단합니다. 장기 실행 작업 (long-running work)은 요청/응답 (request/response) 사이클에 깔끔하게 맞지 않습니다. 만약 모델이 배치 작업 (batch job), 사람의 승인, 또는 느린 외부 API를 기다려야 한다면, 연결을 차단 (blocking)하는 방식은 취약하며 재개하기 어렵습니다.
현재의 MCP 로드맵 (roadmap)은 이를 명시적으로 다루고 있습니다. 2026 MCP 로드맵 (2026-06-02 캡처)은 여전히 작업 생명주기 (task lifecycle)의 예외 케이스들을 활발한 프로토콜 작업으로 취급하고 있으며, Tasks 개요 (2026-06-02 캡처)는 스트리밍 소켓 (streaming socket)의 대체물이 아닌 내구성이 있는 핸들 (durable handle)을 설명합니다.
이러한 차이는 중요합니다. 작업 ID (task ID)는 상태 핸들 (state handle)입니다. 그것은 채팅 트랜스크립트 (chat transcript)가 아닙니다. 작업 큐 (job queue)도 아닙니다. 또한 모든 클라이언트와 서버가 다음 분기에 동일한 재시도 동작 (retry behavior)에 합의할 것이라는 약속도 아닙니다.
MCP Tasks의 형태
프로토콜 모델은 작은 상태 머신 (state machine)을 가진 내구성이 있는 작업 (durable task)입니다. 빌더들에게 유용한 점은 그 형태가 명시적이라는 것입니다:
| 계층 (Surface) | 안정적인 부분 | 여전히 변동 중인 부분 | 실질적인 시사점 |
|---|---|---|---|
| 작업 식별자 (Task identity) | 내구성이 있는 작업 ID (Durable task ID) | 보존 정책 (Retention policies) | ID를 영구 저장하고 재개/폴링 (resume/poll) 흐름을 예상하십시오 |
| ... | |||
| 생명주기 정책 (Lifecycle policy) | 종료 상태 (Terminal states)는 종료됩니다 | 재시도 (Retry) 및 만료 (expiry) 의미론은 여전히 진화 중입니다 | 구현을 보수적으로 유지하십시오 |
_MCP Tasks 상태 머신 (state machine): working 및 input_required는 비종료 상태(non-terminal)이며, completed, failed, cancelled는 종료 상태(terminal)입니다. 출처: MCP Tasks extension overview (2026-06-02 캡처).
협상(negotiation) 과정을 확인하는 가장 쉬운 방법은 클라이언트와 서버의 기능(capabilities)을 나란히 살펴보는 것입니다.
{
"_meta": {
"io.modelcontextprotocol/clientCapabilities": {
...
{
"capabilities": {
"extensions": {
...
양측 모두 참여(opt in)하기로 하면, 서버는 동기식 결과 대신 CreateTaskResult를 반환할 수 있습니다.
{
"resultType": "task",
"task": {
...
ttlMs 및 pollIntervalMs 필드의 목적은 단순한 장식이 아닙니다. 이 필드들은 클라이언트에게 작업이 합리적으로 언제까지 재개될 수 있는지, 그리고 얼마나 자주 업데이트를 요청해야 하는지를 알려줍니다.
폴링 (Polling), 완료 (completion), 그리고 input_required
작업이 생성되면 클라이언트는 간단한 루프를 따릅니다: 종료될 때까지 폴링(poll)하거나, 서버가 입력을 위해 일시 중지하면 응답합니다.
{
"taskId": "task_01JQ2Z8XKQ7G6Q5X5ZK1N7T9A2"
}
{
"taskId": "task_01JQ2Z8XKQ7G6Q5X5ZK1N7T9A2",
"status": "completed",
...
작업 수행에 결정이 필요한 경우, 프로토콜은 스스로 계속 진행할 수 있는 척하는 것을 명시적으로 중단합니다.
{
"taskId": "task_01JQ2Z8XKQ7G6Q5X5ZK1N7T9A2",
"status": "input_required",
...
{
"taskId": "task_01JQ2Z8XKQ7G6Q5X5ZK1N7T9A2",
"inputResponses": {
...
이것이 여기서 가장 유용한 멘탈 모델(mental model)입니다. 즉, 작업 상태(task state)는 구현 세부 사항(implementation detail)이 아닙니다. 그것은 지연된 작업(deferred work)을 위한 프로토콜 표면(protocol surface)입니다.
실험적 저장소(experimental repository)는 주의를 요합니다. 실험적 Tasks 스펙 저장소 (2026-06-02 캡처됨)는 해당 확장 기능을 실험적(experimental)이라고 라벨링하며, 변경되거나 사라질 수 있다고 경고합니다. 그렇다고 해서 사용할 수 없다는 뜻은 아닙니다. 다만, 이를 진화하는 계약(evolving contract)처럼 취급해야 한다는 의미입니다.
프로덕션 환경의 MCP 작업 추적에서 안정적인 요소
저의 해석은 보수적입니다:
- 구축해도 안전한 것: 지속 가능한 작업 핸들(durable task handle)의 존재, 명시적인 작업 상태(explicit task states), 폴링(polling), 그리고 협력적 취소(cooperative cancellation).
- 주의해서 사용할 것: 정확한 재시도 동작(retry behavior), 보존/만료 정책(retention/expiry policy), 그리고 클라이언트별 푸시 알림(push notification) 동작.
- 과하게 해석하지 말 것: 작업이 존재한다는 사실이 모든 에이전트 워크플로(agent workflow)가 작업(task)이 되어야 함을 의미하지는 않습니다.
로드맵이 이를 뒷받침합니다. 2026 MCP 로드맵 (2026-06-02 캡처됨)에서 재시도 의미론(retry semantics)과 결과 보존 정책(result-retention policy)은 여전히 해결되지 않은 공백(open gaps)으로 지목되어 있습니다. 이는 그 형태는 실재하지만, 이를 둘러싼 정책은 여전히 정립 중이라는 신호입니다.
시장 신호(market signal)도 존재하지만, 이는 여전히 시장 신호일 뿐입니다. SiliconANGLE의 2026년 2월 12일 Manufact 관련 보고서 (2026-06-02 캡처됨)는 MCP 인프라로 자금이 유입되고 있음을 보여줍니다. 이는 이 카테고리가 실질적인 주목을 받고 있음을 말해줍니다. 하지만 프로토콜의 진화가 완료되었음을 증명하는 것은 아닙니다.
MCP Tasks가 유일한 정답은 아닙니다
만약 귀하의 유스케이스(use case)가 지연된 실행(deferred execution)이 아니라 에이전트 간 협업(agent-to-agent collaboration)이라면, A2A도 살펴보아야 합니다. A2A 사양(specification) (2026-06-02 캡처됨)은 에이전트 간 통신(inter-agent communication), 역량 발견(capability discovery), 그리고 자체적인 작업 생명주기(task lifecycle)와 메시지 모델을 가진 협업 작업에 초점을 맞추고 있습니다.
그렇게 하면 비교가 더 쉬워집니다:
| 주제 | MCP Tasks | A2A |
|---|---|---|
| 주요 문제 | MCP 요청 내부의 지연 실행 (Deferred execution) | 독립적인 에이전트 간의 조정 (Coordination) |
| ... |
다시 말해, 문제에 부합하는 가장 단순한 계층을 사용하십시오. 작업이 근본적으로 나중에 완료되어야 하는 하나의 요청인 경우에는 MCP Tasks가 적합합니다. 작업이 실제로 에이전트 간의 대화인 경우에는 A2A가 더 적합합니다.
최소한의 애플리케이션 계층 유사 사례
이 부분은 프로토콜 확장(protocol extension)과 자주 혼동되는 부분입니다. 보드(board)는 MCP Tasks 자체를 구현하지 않고도 동일한 형태를 노출할 수 있습니다: 안정적인 ID(stable ID), 읽을 수 있는 상태(readable status), 그리고 작업이 진행됨에 따라 상태를 업데이트하는 쓰기 경로(write path)가 그것입니다.
동일한 구조적 형태(안정적이고 지속 가능한 ID, 명시적인 상태 상태 머신(status state machine), 그리고 폴링/읽기 가능한 상태)로 독립적으로 수렴하는 두 개의 독립적인 기본 요소(primitives).
이는 Agiflow의 연결 문서가 애플리케이션 계층에서 보여주는 것과 유사합니다: 어시스턴트가 지속 가능한 보드 상태(durable board state)를 대상으로 작업할 수 있도록 하는 범위가 지정된 작업 엔드포인트(scoped task endpoint)입니다. 중요한 차이점은 위에서 언급한 것과 동일합니다. 그것은 애플리케이션 수준의 모델이며, 해당 제품이 MCP Tasks 확장을 구현했다는 증거는 아닙니다.
type TaskStatus = "working" | "input_required" | "completed" | "failed" | "cancelled";
type TaskRecord = {
...
이는 프로토콜 메커니즘을 제외하면 MCP Tasks가 공식화하고 있는 것과 동일한 형태입니다. 인메모리(in-memory) Map을 데이터베이스 행(database row), Durable Object, 프로젝트 보드 레코드 또는 외부 작업 핸들(external job handle)로 교체할 수 있습니다. 패턴은 동일하게 유지됩니다.
실무에서 제가 하는 방식
저의 경험 법칙은 의도적으로 지루함을 유지하는 것입니다:
- 동기식 도구 호출 (synchronous tool calls)에는 핵심 MCP (core MCP)를 사용하세요.
- 작업이 진정으로 지연(deferred)되어 클라이언트가 나중에 재개할 수 있는 경우에는 MCP Tasks를 사용하세요.
- 상태 머신 (state machine)을 단순하게 유지하고 종료 상태 (terminal-state) 중심으로 설계하세요.
- 푸시 알림 (push notifications)은 필수 사항이 아닌 최적화 요소로 취급하세요.
- 문제가 지연된 실행 (deferred execution)이 아니라 실제 에이전트 조정 (agent coordination)에 관한 것이라면 A2A를 고려하세요.
이렇게 하면 해당 확장 기능이 실제보다 더 성숙한 것처럼 꾸미지 않고도 대부분의 가치를 얻을 수 있습니다.
마무리하며
유용한 헤드라인은 "MCP Tasks가 완성되었다"가 아닙니다. 유용한 헤드라인은 MCP 서버의 작업 추적 (task tracking)이 이제 신뢰할 수 있는 프로토콜 형태를 갖추게 되었다는 점입니다. 즉, 연결이 끊겨도 유지되는 내구성이 있고 (durable), 재개 가능하며 (resumable), 장기 실행되는 (long-running) 작업이 가능해졌다는 것입니다. 이는 진정한 진전이지만, 여전히 진화 중인 영역이므로 가장 안전한 구현 입장은 보수적인 태도를 유지하는 것입니다.
실제 제품이 어시스턴트를 보드 상태 (board state) 및 작업 컨텍스트 (task context)에 어떻게 범위화하는지 보고 싶다면, Agiflow의 연결 문서부터 시작해 보세요. 이는 여기서 다룬 프로토콜 이야기와 대비되는 좋은 애플리케이션 계층 (application-layer)의 사례이며, "보드 상태"와 "프로토콜 작업" 사이의 경계를 훨씬 더 쉽게 파악할 수 있게 해줍니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기