4부 19장. MCP의 미래: 2026 로드맵과 그 너머
4부 19장. MCP의 미래: 2026 로드맵과 그 너머
지금까지 우리는 MCP를 배웠고, 직접 만들었고, 운영했고, 세상에 내보내기까지 했다. 여기서 책이 끝나도 당장 서버는 돌아간다. 하지만 오래 쓰고 싶은 서버를 만든 사람이라면 마지막으로 꼭 물어야 할 질문이 있다.
이 프로토콜은 어디로 가는가?
이 질문은 유행 예측이 아니다. 아주 실용적인 질문이다. 표준의 방향을 모르면, 오늘 잘 만든 구조가 내년에는 고집스러운 레거시가 되기 쉽다. 반대로 방향을 알고 있으면, 아직 오지 않은 기능까지도 미리 받을 준비를 해둘 수 있다.
2026년의 MCP는 더 이상 노트북 안에서만 노는 작은 도구 연결 규약이 아니다. 원격 배포, 인증, UI, 레지스트리, 엔터프라이즈 운영까지 다루는 실제 인프라의 성격을 띠고 있고, 로드맵도 이제 단순한 버전 출시 일정이 아니라 우선순위 영역과 워킹그룹 중심으로 움직이고 있다.1 여기에 더해 MCP는 2025년 말 Linux Foundation 산하의 AAIF로 옮겨 가며 특정 회사의 기능이 아니라 공동 거버넌스를 가진 공개 표준의 길로 들어섰다.2
이 장에서는 네 가지를 본다. 장기 실행 작업을 위한 Tasks primitive, 텍스트를 넘어서는 멀티모달 MCP, A2A와 MCP의 역할 분담, 그리고 AAIF와 워킹그룹이 만들어 갈 표준의 운영 방식이다. 그리고 마지막에는 우리가 만든 PKM-MCP가 앞으로 어떤 모습으로 자라날 수 있을지 그려본다.
왜 미래를 아는 일이 가장 실용적인가
프로토콜의 미래를 아는 일은 멋져 보이기 위한 취미가 아니다. 설계의 낭비를 줄이기 위한 보험에 가깝다.
예를 들어 보자. 당신이 PKM-MCP를 철저하게 세션 메모리에 의존하도록 만들었다면, 수평 확장과 장기 작업은 곧 벽에 부딪힌다. 노트의 본문만 텍스트라고 가정했다면, 음성 메모와 스크린샷이 들어오는 순간 구조를 뜯어고쳐야 한다. 모든 일을 즉시 응답하는 tool 하나로 처리하려 했다면, 대용량 재색인이나 백그라운드 요약 작업은 늘 어설픈 우회로를 만들게 된다.
반대로 방향을 알고 있으면 처음부터 더 오래 가는 형태를 고를 수 있다. 도구는 짧고 명확하게, 상태는 지속 저장소에, 큰 결과는 참조 가능한 리소스로, 인증과 감사는 확장 가능한 경계로 분리하는 식이다. 미래를 안다는 것은 결국, 현재의 결합도를 낮춘다는 뜻이다.
19.1 Tasks primitive와 장기 실행 작업
지금까지 우리가 많이 다룬 MCP 도구 호출은 대체로 즉시 실행 모델에 가깝다. 클라이언트가 tools/call을 보내면 서버가 처리하고 곧바로 결과를 돌려준다. 이 방식은 검색, CRUD, 간단한 API 호출에는 아주 잘 맞는다.
문제는 현실의 일이 그렇게 짧지 않다는 점이다. 임베딩 재생성, 대량 노트 가져오기, 수천 개 파일의 인덱싱, 장문의 주간 요약 생성, 외부 시스템 동기화는 몇 초에서 몇 분까지 걸릴 수 있다. 이런 일을 모두 동기 호출에 우겨 넣으면 사용자는 멈춘 화면을 보고, 서버는 타임아웃과 재시도 지옥을 만나게 된다.
이 지점에서 Tasks primitive가 중요해진다. 핵심 아이디어는 단순하다. 지금 바로 결과를 주는 대신, 지금 바로 작업 손잡이를 주고 실제 일은 뒤에서 계속하게 만드는 것이다. 클라이언트는 나중에 상태와 결과를 조회하거나, 진행 상황을 받을 수 있다. MCP 커뮤니티는 이 기능을 실험적으로 도입한 뒤 실제 운영 경험을 바탕으로 다듬고 있으며, 2026 로드맵에서는 특히 일시적 실패에 대한 재시도 의미와 완료 후 결과를 얼마나 오래 보관할지 같은 수명주기 문제가 중요한 보완 지점으로 꼽힌다.13
PKM-MCP에서 Task가 특히 빛나는 순간은 이런 경우다.
reindex_all_notes: 모든 노트의 임베딩을 다시 계산하고 벡터 인덱스를 교체한다.import_github_issues_as_notes: 외부 저장소의 이슈를 대량으로 읽어 노트로 가져온다.generate_weekly_knowledge_digest: 일주일치 메모를 분석해 요약, 태그 후보, 후속 액션까지 묶어 만든다.export_audit_bundle: 특정 기간의 감사 로그와 변경 이력을 묶어 내보낸다.
여기서 중요한 건, 느리다는 이유만으로 모든 도구를 Task로 만들 필요는 없다는 점이다. 두 줄짜리 키워드 검색에 백그라운드 작업 프레임워크를 붙이면, 미래 지향적이기는커녕 그냥 느리고 복잡한 서버가 된다. 장기 실행 작업은 장기 실행 작업답게 다루고, 짧은 작업은 짧게 끝내야 한다. 미래 기능을 준비한다는 말은 모든 기능을 무겁게 만든다는 뜻이 아니다.
PKM-MCP를 앞으로 Task 친화적으로 바꾸고 싶다면 세 가지를 먼저 점검하면 좋다.
첫째, 수락과 실행을 분리해야 한다. 요청을 받는 API와 실제 처리를 수행하는 워커를 분리하면, 클라이언트는 빨리 응답받고 서버는 안정적으로 오래 일할 수 있다.
둘째, 작업 상태를 메모리가 아니라 저장소에 둬야 한다. 프로세스가 재시작되어도 작업이 살아남아야 하고, 다른 인스턴스가 이어받을 수 있어야 한다. 이건 Task를 위한 설계이기도 하지만, 앞 장에서 다룬 HTTP 수평 확장 방향과도 맞닿아 있다.
셋째, 결과 보관 기간을 정책으로 가져가야 한다. 어떤 결과는 10분이면 충분하고, 어떤 결과는 7일은 남겨야 쓸모가 있다. 로드맵에서 결과 만료 정책이 중요한 이유도 바로 여기에 있다.1
정리하면 Task는 MCP를 비동기 배치 시스템으로 바꾸는 기능이 아니다. 오히려 오래 걸리는 일을 오래 걸리는 일답게 표현하게 해주는 정직한 primitive다. PKM-MCP가 개인 메모 서버를 넘어 개인 지식 파이프라인으로 자라려면, 이 정직함이 꼭 필요해진다.
19.2 멀티모달 MCP: 텍스트 메모에서 기억의 저장소로
우리는 메모를 자주 텍스트라고 생각한다. 하지만 실제 개인 지식은 훨씬 잡다하다. 회의 중 찍은 화이트보드 사진, 휴대폰 음성 메모, 화면 캡처, PDF 발표 자료, 짧은 동영상, 심지어 손글씨까지 섞여 있다. 즉, 앞으로의 PKM은 문장 저장소가 아니라 기억 저장소에 더 가깝다.
그래서 멀티모달 MCP는 선택이 아니라 자연스러운 다음 단계다. 업계 전망에서도 2026년 하반기 이후 MCP가 이미지, 오디오, 비디오 같은 입력과 출력에 더 잘 대응하는 방향으로 발전할 가능성이 거론되고 있고, 동시에 큰 결과를 참조 기반으로 다루는 방식도 중요한 탐색 주제로 올라와 있다.14
이 말을 너무 거창하게 들을 필요는 없다. 뜻은 의외로 소박하다.
메모 하나가 앞으로는 이렇게 생길 수 있다는 뜻이다. 본문 텍스트가 있고, 첨부된 회의 음성 파일이 있고, 자동 전사본이 있고, 발표 슬라이드 미리보기가 있고, 화이트보드 사진에서 뽑은 OCR 텍스트가 있다. 그리고 모델은 그중 무엇을 직접 읽고, 무엇을 요약본으로 받고, 무엇은 필요할 때만 참조해야 하는지를 더 잘 구분하게 된다.
PKM-MCP를 이 미래에 맞게 준비하려면 지금부터 데이터 모델을 바꿔야 한다.
노트의 본문과 첨부 파일을 같은 것으로 취급하지 말고, 하나의 노트 아래 여러 리소스가 매달리는 구조로 설계한다.
mime type과 URI를 정확히 관리한다. 그래야 클라이언트와 모델이 이 데이터가 텍스트인지, 이미지인지, 오디오인지 판단할 수 있다.거대한 바이너리를 도구 응답에 그대로 밀어 넣기보다, 요약과 메타데이터를 먼저 주고 원본은 리소스로 참조하게 만든다.
OCR 본문, 전사본, 썸네일처럼 파생 데이터를 별도 리소스로 다루면 검색성과 재사용성이 크게 좋아진다.
이렇게 바뀌면 search_notes의 의미도 넓어진다. 단어를 찾는 수준을 넘어, 회의 사진 속 칠판 내용과 음성 전사본, 그리고 그날 작성한 텍스트 메모까지 한 덩어리의 기억으로 검색하게 된다. semantic_search_notes는 단순한 벡터 검색 도구가 아니라, 여러 modality에서 추출한 의미를 교차 탐색하는 도구가 될 수 있다.
재미있는 점은, 여기서부터 PKM-MCP가 정말 사람처럼 기억하기 시작한다는 것이다. 사람도 메모를 텍스트 한 줄로만 기억하지 않는다. 그때 본 화면, 들은 목소리, 사진 속 도형, 옆에 적은 낙서가 함께 남는다. 멀티모달 MCP는 그 인간적인 지저분함을 드디어 프로토콜의 세계로 끌고 들어오는 과정이라고 볼 수 있다.
19.3 A2A와 MCP의 관계: 경쟁자가 아니라 층이 다르다
A2A가 화제가 되기 시작하면 거의 반드시 나오는 질문이 있다. 그럼 MCP는 끝난 건가요? 대답은 오히려 반대다. 둘은 같은 자리를 두고 싸우는 프로토콜이 아니라, 서로 다른 층을 맡는 경우가 많다.5
아주 단순하게 구분하면 이렇다.
MCP는 에이전트가 도구와 데이터에 접근하는 방법을 표준화한다.
A2A는 에이전트가 다른 에이전트와 협업하는 방법을 표준화한다.
실제 애플리케이션은 이 둘을 조합해 하나의 워크플로를 만든다.
이 구분이 중요한 이유는, 우리가 만든 PKM-MCP의 위치를 정확히 보게 해주기 때문이다. PKM-MCP는 기본적으로 지식 접근 계층이다. 노트를 읽고, 검색하고, 수정하고, 요약용 프롬프트와 리소스를 제공한다. 즉, 강한 MCP 후보지 A2A 후보지가 아니다.
하지만 앞으로 시스템이 커지면 이야기가 달라진다. 예를 들어 어떤 코디네이터 에이전트가 사용자의 요청을 받아 다음처럼 움직일 수 있다.
회의 준비 에이전트는 A2A로 리서치 에이전트에게 관련 자료 수집을 맡기고, 일정 에이전트에게 참가자 컨텍스트를 묻고, 글쓰기 에이전트에게 브리핑 초안을 부탁한다. 그 과정에서 각 에이전트는 다시 MCP를 통해 GitHub, 캘린더, 파일 시스템, 그리고 PKM-MCP에 접근한다. 이때 PKM-MCP는 여러 에이전트가 공통으로 참조하는 개인 기억 백엔드가 된다.
즉, A2A가 누가 누구에게 일을 맡길지를 정하는 계층이라면, MCP는 맡은 일을 하려고 무엇을 읽고 무엇을 실행할지를 정하는 계층이다. 팀장과 공구함의 차이라고 생각하면 쉽다. 팀장끼리 대화한다고 해서 드라이버가 사라지지 않는다.
물론 두 프로토콜이 만나는 경계에는 아직 풀어야 할 문제가 많다. 한 에이전트가 다른 에이전트에게 일을 넘길 때 사용자 정체성을 어떻게 전달할지, 예산과 한도를 어떻게 위임할지, 같은 서버라도 인간 사용자와 다른 에이전트에게 같은 능력을 보여줄지 같은 문제는 여전히 활발한 설계 주제다.6
그래서 PKM-MCP를 만드는 입장에서는 한 가지 태도가 좋다. 당장 A2A를 구현하지 않더라도, 언젠가 다른 에이전트들이 불러 쓸 수 있는 서버라고 생각하고 인터페이스를 다듬는 것이다. 구체적으로는 다음이 중요하다.
첫째, 도구 이름과 설명은 사람뿐 아니라 다른 에이전트가 읽어도 오해 없게 써야 한다.
둘째, 권한 경계는 명확해야 한다. 읽기와 쓰기, 파괴적 작업과 비파괴적 작업이 섞여 있으면 상위 오케스트레이터가 안전한 위임을 하기 어렵다.
셋째, 결과는 다른 에이전트가 후처리하기 좋게 구조화되어야 한다. 사람이 보기 좋은 문장만 잔뜩 돌려주는 서버는 에이전트 조합 세계에서 금세 답답해진다.
결론적으로, MCP와 A2A의 관계는 대체재가 아니라 합주에 가깝다. PKM-MCP가 훗날 여러 에이전트 사이를 흐르는 개인 기억 인프라가 되려면, MCP를 튼튼히 만들고 A2A와 잘 붙을 수 있는 모양을 갖추는 것이 정답이다.
19.4 거버넌스의 미래: AAIF, 워킹그룹, 그리고 범위를 지키는 힘
프로토콜의 미래는 코드 저장소에서만 결정되지 않는다. 누가 리뷰하고, 무엇을 우선순위로 두고, 어디까지를 프로토콜의 책임으로 볼지에 따라 성격이 완전히 달라진다. 2026년 MCP에서 가장 중요한 변화 중 하나는 바로 이 거버넌스의 성숙이다.
MCP는 이제 AAIF라는 중립적 재단 아래에서 다른 핵심 프로젝트들과 함께 움직인다. Linux Foundation 산하에 자리 잡았다는 것은, 이 표준이 더 이상 특정 벤더의 제품 전략에만 기대지 않는다는 뜻이다.2 이것만으로도 개발자에게 주는 신호는 크다. 오래 투자해도 되는 판이라는 뜻이기 때문이다.
로드맵의 운영 방식도 바뀌었다. 예전처럼 다음 릴리스에 뭐가 나오나만 보는 식이 아니라, 어떤 문제 영역이 가장 시급한지, 그리고 어떤 워킹그룹이 그 문제를 책임지고 있는지가 더 중요해졌다.1 여기에 기여자 사다리와 위임 모델이 더해지면, 모든 제안이 소수 코어 메인테이너에게 몰리는 병목을 줄이고 각 분야의 전문가가 더 빠르게 사양을 발전시킬 수 있다.1
이 변화가 실무자에게 주는 교훈은 분명하다. 앞으로는 릴리스 노트만 읽는 것보다 워킹그룹의 논의 주제를 보는 편이 더 중요해진다. 특히 당신이 새로운 확장을 제안하거나, PKM-MCP를 장기적으로 공개 프로젝트로 키우고 싶다면 더 그렇다.
또 하나 주목할 점은 범위를 지키는 태도다. 2026년 MCP Dev Summit에서 메인테이너들은 MCP의 역할을 비교적 분명하게 그었다. MCP는 AI 애플리케이션을 데이터와 기능에 연결하는 프로토콜이지, 관측성, 정체성, 거버넌스 전체를 모두 집어삼키는 만능 표준이 되어서는 안 된다는 것이다.7 이 선 긋기는 꽤 중요하다.
왜냐하면 표준은 욕심이 많아질수록 약해지기 쉽기 때문이다. 모든 문제를 직접 해결하려 들면 사양은 무거워지고, 구현은 복잡해지고, 작은 팀은 따라오기 어려워진다. 반대로 핵심을 좁게 유지하고 주변 기능은 확장과 인접 프로젝트에 맡기면 생태계는 더 빨리 자란다.
PKM-MCP를 만드는 우리 입장에서는 이것이 곧 설계 원칙이 된다.
코어 서버는 가능한 한 단순하고 선명하게 유지한다.
엔터프라이즈 기능은 확장 가능한 계층으로 올린다.
인증, 감사, 게이트웨이, 관측성은 프로토콜 바깥의 인프라와도 잘 붙게 만든다.
새 기능은 덧붙일 수 있게 설계하고, 기존 기능은 쉽게 깨지지 않게 유지한다.
결국 좋은 미래 대응은 모든 것을 미리 구현하는 것이 아니라 무엇이 코어이고 무엇이 확장인지 구분하는 것이다. AAIF와 워킹그룹 중심의 거버넌스는 바로 그 감각을 프로토콜 전체에 주입하고 있다.
19.5 PKM-MCP는 앞으로 어떻게 진화할까
이제 우리 프로젝트로 돌아오자. 지금의 PKM-MCP는 이미 꽤 훌륭하다. 검색하고, 쓰고, 지우고, RAG를 하고, 사용자별 인증을 처리하고, Cloudflare Workers에 배포되고, 감사 로그도 남기고, Apps UI도 있고, 레지스트리 공개도 끝냈다.
하지만 미래의 관점에서 보면 이것은 완성본이라기보다 1.0의 출발선에 가깝다. 앞으로의 PKM-MCP는 적어도 네 방향으로 자랄 수 있다.
첫 번째 방향은 개인 지식 작업 큐다. 여기서는 Task가 핵심이다. 노트 재색인, 장기 요약, 대량 가져오기, 백업 생성처럼 오래 걸리는 일은 즉시 응답형 도구에서 분리되어 백그라운드 작업이 된다. 사용자는 일을 시키고 다른 대화를 계속할 수 있고, 나중에 결과만 받으면 된다.
두 번째 방향은 멀티모달 기억 저장소다. 음성 회의록, 이미지 메모, PDF, 동영상 클립, 스크린샷이 모두 같은 노트 그래프 안으로 들어온다. 검색은 문장뿐 아니라 장면과 소리의 의미를 함께 훑는다. 이 순간 PKM-MCP는 메모 앱의 서버가 아니라, 당신의 외부 기억 장치가 된다.
세 번째 방향은 다중 에이전트 시대의 기억 허브다. 앞으로는 한 명의 거대한 비서보다 여러 전문 에이전트가 협업하는 패턴이 늘어날 가능성이 높다. 그때 PKM-MCP는 모든 에이전트가 공통으로 읽고 쓰는 신뢰 가능한 장기 기억 계층이 된다. A2A가 상위 협업을 담당하고, PKM-MCP는 그 아래에서 기억과 도구를 제공하는 식이다.
네 번째 방향은 표준 친화적인 장수 서버다. AAIF와 워킹그룹의 흐름을 따라가며, 서버 카드를 붙이고, 확장을 수용하고, 감사와 게이트웨이 환경에 잘 맞고, 새 클라이언트가 와도 큰 수정 없이 붙을 수 있는 서버가 되는 것이다. 화려함보다 수명이 긴 구조라고 할 수 있다.
이 네 방향은 따로 놀지 않는다. 서로를 밀어준다. 장기 작업은 멀티모달 데이터의 재처리에 필요하고, 멀티모달 기억은 다중 에이전트 협업에서 더 큰 가치를 만들고, 이런 복잡한 운영은 결국 좋은 거버넌스와 표준의 안정성 위에서만 오래 간다.
마치며: 미래를 안다는 것은 덜 뜯어고친다는 뜻이다
MCP의 미래를 보는 가장 좋은 방법은 거대한 예언서를 읽는 게 아니다. 지금 드러난 방향을 보고, 내 서버의 결합도를 줄이는 것이다.
장기 실행 작업은 Task로 갈 가능성이 크다. 큰 데이터와 풍부한 기억은 멀티모달로 갈 가능성이 크다. 여러 에이전트가 함께 일하는 세상에서는 A2A와 MCP가 함께 쓰일 가능성이 크다. 그리고 이 모든 변화는 AAIF와 워킹그룹, SEP를 중심으로 비교적 공개적이고 점진적으로 다듬어질 가능성이 크다.12
그러니 실용적인 결론은 의외로 단순하다. PKM-MCP를 오늘 완벽하게 미래형으로 만들려고 애쓰기보다, 내일의 변화가 들어와도 무너지지 않는 모양으로 만들어라. 짧은 일과 긴 일을 구분하고, 텍스트와 미디어를 구분하고, 코어와 확장을 구분하고, 도구와 에이전트 협업의 층을 구분하라.
그렇게 만들어진 서버는 유행이 지나도 살아남는다. 그리고 살아남는 서버야말로, 결국 가장 미래적인 서버다.
참고
3MCP Dev Summit 2026 정리와 Tasks·전송 계층 논의
4MCP Complete Guide 2026의 멀티모달 전망
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.