MCP 회의론에 붙은 반론, 로드맵은 단발 호출을 접고 장기 실행으로 간다
한 개발자 참가자가 MCP 공식 로드맵 문서를 공유하며, MCP가 단순 툴 연결 표준을 넘어 에이전트 발견·인증·장시간 실행·이벤트 통신을 다루는 운영 표준으로 확장된다고 정리했다. 요청·실행·응답의 단발 호출 구조는 장기 실행형 에이전트 워크플로에 맞지 않아, 웹훅과 채널을 도입해 서버가 알아서 이벤트를 전달하는 구조로 간다는 설명이다. 툴이 많이 물릴수록 컨텍스트 비용이 커지는 문제는 전체 툴을 처음부터 노출하지 않고 작은 진입점만 주는 Progressive Discovery로 대응한다고 짚었다.
전날 밤 9시 26분, 더배러 방에 긴 글 하나가 올라왔다. 한 개발자 참가자가 MCP 공식 블로그에 공개된 로드맵 문서를 옮기며, 이 프로토콜이 어디로 가는지를 문단 단위로 풀어 설명한 글이었다. 요약도 링크도 아니고, 무엇이 왜 바뀌는지를 항목별로 짚은 정리였다. 글의 첫머리는 이렇게 시작했다.
MCP(Model Context Protocol)에 대한 로드맵이 공개되어 공유 드립니다. MCP의 다음 단계는 Tool 연결 표준을 넘어 Agent가 발견되고 → 인증되고 → 장시간 실행되고 → 이벤트로 통신하고 → 필요한 capability만 점진적으로 사용하는 운영 표준으로 발전한다는 이야기입니다.
무슨 일
공유자는 곧바로 이 글을 쓴 이유를 밝혔다. 최근 커뮤니티에 돌던 회의론을 겨냥한 것이었다.
최근 MCP 왜 쓰냐 이야기가 많이 나왔는데, 개인적으로는 그렇지 않다고 생각합니다. 눈 여겨 보셨으면 좋겠네요.
이어진 설명의 첫 축은 호출 구조 자체의 교체였다. 지금까지 툴 호출은 요청을 보내고 실행되고 응답을 받는 단발 왕복이었는데, 최근의 에이전트 작업은 그 틀에 들어가지 않는다는 지적이다.
전통적인 툴 콜링은 'Request → Execution → Response' 으로 진행되는데, 최근 Agent Workflow를 보면 장기실행구조로 가고 있습니다.
대안으로 제시된 것은 웹훅과 채널 개념이었다. 클라이언트가 계속 상태를 물어보는 폴링 대신 서버가 알아서 이벤트를 전달하고, 진행 중인 작업에 방향을 지시하는 단계까지 포함하는 시작·진행·이벤트·조종·결과 구조로 확장한다는 것이다.
두 번째 축은 도구가 늘어날 때 생기는 비용 문제였다.
MCP Server에 물린 툴이 많아지게 되면, 많은 컨텍스트 비용이 소모되고 퀄리티도 떨어지게 됩니다. 그래서 제시하는 로드맵 중 하나가 'Progressive Discovery' 입니다. 처음부터 모든 Tool을 보여주는 것이 아니라 작은 Entry Point만 제공하는 거죠.
공유자는 최근 등장한 도구들이 레지스트리 형식으로 진행하는 방식을 같은 계열의 사례로 들었고, 글을 이렇게 맺었다.
단순 호출에서 벗어나 Runtime Context로 확장되고 있습니다! 더 유연하고, 더 쉽고, 더 효율적으로.
1분 뒤 첫 반응이 붙었다.
와우 점점 발전하네요 ㅎㅎ 좋은 정보 감사드립니다.
이후 30분 사이 감사 인사가 더 이어졌고, 논쟁 없이 정보 공유로 마무리됐다.
왜 중요한가
로드맵의 방향은 두 가지 실무 문제를 정면으로 겨냥한다. 하나는 시간이다. 코드 작업이든 조사든, 실제 에이전트 작업은 몇 초 안에 끝나지 않는다. 응답을 한 번 받고 끝나는 규약 위에서 장시간 작업을 돌리면 중간 상태를 알 방법이 폴링밖에 없고, 그 폴링 비용은 작업이 길수록 커진다. 진행 상황을 서버가 밀어 주고 도중에 방향을 바꿀 수 있게 하는 설계는 이 구조적 불일치를 없애려는 시도다.
다른 하나는 컨텍스트다. 서버에 도구를 많이 물릴수록 좋아질 것 같지만 실제로는 반대 방향으로 간다는 지적은, 도구 목록 자체가 매 요청의 입력에 실린다는 사실에서 나온다. 도구 수가 성능을 깎는다는 이 관찰은 문서를 읽은 사람이 아니라 붙여 본 사람이 하는 종류의 말이다. 진입점만 먼저 노출하고 필요할 때 확장하는 방식은 도구를 줄이지 않으면서 비용만 줄이려는 절충이다.
시사점
이 공유가 회의론에 대한 반론으로 제시됐다는 점이 그 자체로 흐름을 보여준다. MCP를 두고 나온 회의론 상당수는 도구 연결이 기대만큼 편하지 않다는 체감에서 출발했는데, 로드맵이 답한 지점은 연결의 편의성이 아니라 운영이다. 발견과 인증, 장시간 실행, 이벤트 통신은 도구를 붙이는 단계가 아니라 붙인 뒤 굴리는 단계의 과제다. 규격의 무게 중심이 옮겨 가고 있다는 뜻이다.
동시에 이 변화는 도구를 쓰는 쪽의 설계 부담도 바꾼다. 어떤 도구를 언제 노출할지, 긴 작업의 중간 신호를 어디서 받을지가 사용자가 정할 몫으로 남는다. 모델 성능 비교가 대화의 대부분을 차지하는 시기에, 그 모델을 실제로 움직이는 배선 쪽 논의가 방 안에서 자리를 잡은 장면이었다.