안녕하세요? 정리하는 개발자 워니즈입니다.
새로 공개된 MCP 로드맵을 읽었는데요, 앞으로 수개월 동안 무엇에 힘을 쏟을지를 다섯 가지 영역으로 추려두었고 그중에서 맨 앞자리를 차지한 것이 장시간 실행되는 에이전트 작업이었습니다. 목록을 처음 훑었을 때 필자의 눈에 더 급해 보였던 쪽은 전송 방식을 통일하거나 신원을 표준화하는 항목이었기 때문에 왜 하필 오래 걸리는 작업이 첫 번째인지가 곧바로 와 닿지는 않았는데요, 마침 개인 블로그를 사람 손 없이 굴려보려고 걸어둔 무인 실행이 하루 네 번 전부 넘어진 기록을 들여다보던 참이라 두 화면을 나란히 놓고 읽게 되었습니다. 그러고 나서야 로드맵이 그 항목을 앞에 세운 이유가 필자의 실패 네 건 안에 거의 그대로 들어 있었다는 생각이 들었습니다.
- 네 번의 실패는 원인이 전부 달랐고 그중 어느 것도 결과물의 품질 문제가 아니었습니다.
- 두 번은 할 일을 다 해놓고 마지막으로 기록하는 단계에서 시간 상한에 잘렸습니다.
- 나머지 두 번은 낮에 사람이 써버린 사용량 탓에 밤의 무인 실행이 시작조차 못 했습니다.
MCP 로드맵이 다섯 영역 중 무엇을 맨 앞에 세웠나요?
MCP 로드맵의 첫 번째 항목은 Agentic Messaging Primitives이고 장시간 실행되는 에이전트 작업을 지원하는 쪽입니다. 기사에는 현대적인 에이전트 작업이 일반적인 요청과 응답 패턴만으로는 처리하기 어렵다는 진단이 먼저 적혀 있었고 작업이 오래 실행되면서 서버가 결과를 스트리밍하거나 실행 중에 사람이 방향을 바꿔야 하는 상황이 늘고 있다는 설명이 뒤따랐습니다. 이미 Tasks와 subscriptions/listen과 Progress Notification을 도입해두었으니 앞으로는 이 요소들이 일관되게 함께 작동하도록 정리하겠다는 계획이었고 클라이언트가 결과를 계속 Polling하지 않아도 되도록 Webhook과 Channel 기반의 서버 주도 이벤트를 추가하는 작업도 함께 추진한다고 합니다.
필자가 이 대목에서 멈춘 이유는 진단의 방향이 성능이나 정확도 쪽이 아니었기 때문입니다. 모델이 더 똑똑해져야 한다는 쪽이 아니라 오래 걸리는 일을 오래 걸리는 채로 붙잡고 있을 그릇이 아직 없다는 쪽이었고 이건 필자처럼 규모가 아주 작은 개인 운영자도 그대로 부딪히는 자리였습니다.
하루에 걸어둔 네 번이 전부 다른 이유로 넘어졌습니다
필자가 블로그에 걸어둔 자동 운영 장치는 사람이 없는 시간대에 하루 네 차례 돌면서 점검하고 정리한 뒤 그 내용을 기록으로 남기는 구조인데요, 어느 하루의 기록을 열어보니 네 번이 전부 실패로 끝나 있었습니다. 처음에는 장치가 통째로 망가졌다고 생각했는데 하나씩 뜯어보니 원인이 매번 달라서 오히려 더 오래 들여다보게 되었습니다.
두 번은 실행 시간 상한인 40분에 걸려서 잘렸습니다. 억울했던 것은 할 일을 못 해서 잘린 게 아니라 점검도 정리도 다 끝내놓고 마지막으로 그 결과를 기록으로 남기는 단계에서 시계가 먼저 도착했다는 점입니다. 작업은 사실상 끝났는데 그 사실을 남길 자리가 없어서 결과가 통째로 사라진 셈이고 밖에서 보기에는 아무것도 안 한 경우와 구분이 되지 않았습니다.
나머지 두 번은 아예 시작도 못 했습니다. 필자가 낮에 대화형으로 쓰던 계정의 사용량 한도를 밤의 무인 실행이 그대로 나눠 쓰고 있었고 낮에 오래 붙잡고 있던 날은 밤에 남는 몫이 없었기 때문입니다. 그중 한 번은 한도가 풀리기 3분 전에 시도했다가 그대로 튕겼는데요, 3분만 늦게 시작했으면 멀쩡히 돌았을 일이라 이게 장치의 결함인지 배치의 결함인지 한참 헷갈렸습니다. 무인 실행이 얼마나 자주 이런 식으로 미끄러지는지는 자동 실행 슬롯의 성공률을 세어본 기록에 따로 남겨두었습니다.
두 종류의 실패는 품질이 아니라 실행이 끊긴 자리에서 났습니다
네 건을 원인별로 갈라놓고 보니 필자가 손댈 곳은 결과물의 완성도가 아니라 실행을 이어주는 배관 쪽이었습니다.
| 실패 유형 | 실제로 벌어진 일 | 로드맵에서 겹치는 대목 |
|---|---|---|
| 시간 상한에 잘림 | 작업은 끝났는데 기록 단계에서 중단 | 작업이 오래 실행되는 상황 지원 |
| 진행 상황을 못 남김 | 어디까지 갔는지 밖에서 알 수 없음 | Progress Notification과 서버 주도 이벤트 |
| 한도 공유로 미시작 | 사람이 쓴 몫과 무인 작업이 한 통 | 자체 신원을 가진 에이전트 |
| 재개 수단 없음 | 다음 차례가 처음부터 다시 시작 | Tasks와 subscriptions/listen 정리 |
네 번의 실패에서 잘려나간 것은 답의 품질이 아니라 답을 붙들고 있을 시간과 그 사이를 밖에 알려줄 통로였습니다. 로드맵이 첫 자리에 둔 문제가 바로 이 지점이었습니다.
나머지 네 영역도 같은 문제를 다른 층에서 만지고 있을까요?
상당 부분 그렇게 읽혔습니다. 두 번째 영역인 Transport 통합은 2026-07-28 릴리스부터 원격 서버를 일반적인 HTTP 서비스처럼 기존 API 인프라에서 호스팅하고 운영할 수 있게 된 흐름을 로컬 서버까지 넓혀서 stdio를 포함한 여러 실행 환경이 하나의 전송 모델을 쓰게 하겠다는 계획인데요, 실행 환경마다 규칙이 다르면 오래 도는 작업을 어디에 얹느냐에 따라 결과가 갈리게 됩니다. 세 번째 영역인 Agent Identity는 지금의 인증이 사람이 브라우저에서 접근을 승인하는 대화형 사용을 중심으로 설계돼 있다는 점을 짚으면서 자체 신원을 가진 클라우드 에이전트가 자리에 없는 사용자를 대신하거나 Subagent에 더 제한된 권한을 위임하는 상황까지 지원해야 한다고 적어두었습니다.
필자의 두 번째 실패 유형이 정확히 그 자리였습니다. 밤에 도는 무인 실행이 자기 몫을 따로 갖지 못하고 낮의 사람과 한 주머니를 쓰고 있었으니 자리에 없는 사용자를 대신한다는 표현이 남의 이야기로 읽히지 않았습니다. 네 번째 영역인 Tool Result 계약과 점진적 탐색도 비슷한데요, 서버가 100개의 Tool을 제공하면 사용자가 질문하기도 전에 모델이 전체 Tool 정의를 읽어야 한다는 문제 제기는 오래 도는 작업일수록 앞단에서 낭비되는 몫이 뒤에서 시간으로 돌아온다는 뜻이라서 필자의 40분 상한과도 무관하지 않은 것 같습니다.
표준이 정리되면 필자의 실패도 같이 사라질까요?
그렇지는 않을 듯합니다. 재개와 알림 규격이 갖춰지면 다 해놓고 마지막에 날아가는 유형은 확실히 줄어들겠지만 무인 실행에 자기 몫의 한도를 떼어줄지 말지는 여전히 필자가 정해야 하는 문제로 남습니다. 표준은 이어붙일 자리를 만들어줄 뿐이고 무엇을 언제 얼마나 돌릴지까지 정해주지는 않는데요, 이 구분은 자동화를 돌려도 끝까지 남는 사람 몫을 정리하면서 한 번 겪어본 것과 같은 종류였습니다.
MCP 로드맵을 읽고 필자가 바꾸기로 한 것
기사 말미에는 다섯 가지 우선순위 영역에 속하는 제안이 우선적으로 검토되고 채택 가능성도 가장 높다는 안내가 붙어 있었습니다. 그 밖의 제안이 자동으로 거절되는 것은 아니지만 제한된 검토 시간은 로드맵 영역에 먼저 배정된다고 하니 어디에 힘이 실릴지를 미리 알려주는 문서인 셈이고 규격을 따라가는 입장에서는 꽤 친절한 편이라고 느꼈습니다.
필자가 실제로 바꾸기로 한 것은 소박합니다. 기록을 남기는 단계를 맨 뒤에 몰아두지 않고 중간에 쪼개서 남기기로 했고 무인 실행과 사람이 쓰는 몫을 같은 주머니에서 꺼내지 않도록 자리를 나누기로 했습니다. 시장이 어디로 가는지와 필자가 손에 쥔 것이 어떻게 다른지는 기대와 체감이 다른 속도로 움직인다는 이야기에서도 한 번 적었는데요, 이번 MCP 로드맵은 그때와 달리 필자가 겪은 실패의 이름을 그대로 불러준 문서라서 조금 다르게 읽혔던 것 같습니다. 원문이 궁금하신 분은 새로운 MCP 로드맵을 정리한 글을 직접 보시면 좋겠습니다.