MCP vs NMCP, 어느 쪽이 더 뛰어난가
MCP vs NMCP, 어느 쪽이 더 뛰어난가 발행일: 2026년 10월 2일 서론 에이전트를 하나만 쓸 때는 묻지 않아도 되던 질문이 있습니다. 에이전트가 여럿이 되어 서로 일을 맡기기 시작하면 그 질문이 전부가 됩니다. 이 에이전트는 누구를 대신해서 , 어디까지 해도 되는가? 저희는...
MCP vs NMCP, 어느 쪽이 더 뛰어난가
발행일: 2026년 10월 2일
서론
에이전트를 하나만 쓸 때는 묻지 않아도 되던 질문이 있습니다. 에이전트가 여럿이 되어 서로 일을 맡기기 시작하면 그 질문이 전부가 됩니다.
이 에이전트는 누구를 대신해서 , 어디까지 해도 되는가?
저희는 이 질문에 답하려고 Nexus 라는 에이전트 허브를 만들었고, 그 방식을 MCP 위에 얹은 것을 NMCP(Nexus + MCP)라고 부릅니다. 그래서 자주 받는 질문이 "MCP 와 NMCP 중 어느 쪽이 더 뛰어난가"입니다.
결론부터 말하면 둘은 경쟁하지 않습니다. NMCP 는 MCP 의 확장입니다. 다만 그 결론에 이르는 과정이 중요해서, 두 방식이 각각 무엇을 하고 무엇을 하지 않는지 차례로 적습니다.
MCP 가 하는 일
MCP(Model Context Protocol)는 모델을 쓰는 애플리케이션이 외부 도구와 데이터에 연결하는 방법 의 공개 표준입니다. 2026-07-28 개정판 기준으로 정리하면 이렇습니다.
JSON-RPC 2.0 메시지로 호스트·클라이언트·서버가 통신합니다.
서버는 도구(모델이 실행하는 함수), 리소스(맥락과 데이터), 프롬프트(틀이 잡힌 메시지)를 내놓습니다.
클라이언트는 서버가 사용자에게 추가 정보를 묻는 요청(elicitation)을 받아 줄 수 있습니다.
오래 걸리는 작업(Tasks) 같은 기능은 선택형 확장으로 붙습니다.
이 표준 덕분에 도구를 한 번 MCP 서버로 만들면 어떤 클라이언트에서든 쓸 수 있게 됐습니다. 에이전트 생태계가 지금처럼 넓어진 데에는 MCP 의 몫이 큽니다.
MCP 가 하지 않는 일
MCP 규격은 권한에 대해 솔직합니다.
인증은 선택 사항 이고 전송 계층 의 일입니다. HTTP 전송에서는 OAuth 2.1 을 따르고, stdio 전송에서는 환경에서 자격 증명을 가져옵니다.
인증이 다루는 것은 "이 클라이언트가 이 MCP 서버에 어떤 범위(scope)로 접근해도 되는가"입니다.
도구를 실행하기 전에 사용자 동의를 받는 일은 호스트 애플리케이션의 책임입니다.
그리고 규격은 이렇게 적습니다. "MCP 자체는 이 보안 원칙들을 프로토콜 수준에서 강제할 수 없다. " 그래서 구현하는 쪽이 동의와 승인 흐름을 만들라고 권고합니다.
이것은 결함이 아니라 범위의 선택입니다. MCP 는 연결을 표준화했고, 연결된 뒤의 판단은 각 구현에 맡겼습니다.
문제는 에이전트가 여럿일 때 생깁니다. 다음 질문들에는 MCP 에 답이 없습니다.
위임 : 에이전트 A 가 에이전트 B 에게 일을 맡길 때, 자기 권한의 일부만 넘길 수 있는가? B 가 다시 C 에게 맡기면?
호출별 판정 : 서버에 연결돼 있다는 것과, 지금 이 작업에서 이 도구를 불러도 된다는 것은 같은가?
한도 : 이 작업에 모델 토큰과 실행 시간을 얼마까지 써도 되는가? 누가 늘려 주는가?
책임 : 나중에 "누가, 누구의 권한으로, 무엇을 했는가"를 순서대로 볼 수 있는가?
에이전트 사이의 말 : 다른 에이전트가 보낸 글은 지시인가, 요청인가, 보고인가?
NMCP 가 더하는 것
Nexus 의 중심에는 위임장 이 있습니다. 위임장은 "누가 누구에게, 어떤 작업을, 어떤 범위·정책·한도로 맡겼는가"를 적고 서버가 서명해 봉인한 문서입니다.
권한은 아래로 갈수록 줄어듭니다. 위임은 체인으로 이어지고, 어떤 행동이든 체인의 모든 고리가 허용해야 합니다. 아래 에이전트는 제한을 더할 수만 있고 권한을 늘릴 수 없습니다.
호출마다 판정합니다. 도구를 부를 때마다 허브가 위임장에 비춰 허용·질문·거절 중 하나를 답합니다. 집행하는 것은 모델이 아니라 서버입니다. 모델이 위임을 잘못 이해해도 서버가 거절합니다.
권한을 넓히는 것은 사람만 합니다. 위임에 없는 행동은 사람에게 승인을 요청합니다. 사람은 한 번만 허락할 수도, 그 세션 동안 허락할 수도 있고, 언제든 거둘 수 있습니다.
한도가 위임에 붙어 있습니다. 모델 토큰, 실행 시간, 하위 세션 수. 바닥나면 작업이 실패하는 대신 사람의 승인을 기다립니다.
모든 것이 원장에 남습니다. 턴, 도구 호출, 승인, 메시지가 세션별로 순번을 달고 기록됩니다.
비밀값은 이름으로만 다룹니다. 모델은 secret://NAME 이라고 쓰고, 값은 명령이 실행되는 순간에만 주입됩니다. 원장에는 이름만 남습니다.
에이전트끼리의 메시지에 관계가 붙습니다. 일을 맡긴 쪽의 지시인지, 동료의 요청인지, 맡은 쪽의 보고인지, 그리고 받는 쪽의 어느 작업에 관한 것인지. 보낸 쪽은 전달됐는지, 모델이 실제로 읽었는지를 압니다.
나란히 놓고 보면
MCP
NMCP
푸는 문제
도구·데이터 연결의 표준화
연결 + 권한 위임·책임 추적·협업
권한의 단위
서버 접속(선택 사항, OAuth 범위)
작업마다 범위·정책·한도가 붙은 위임장
권한 넘기기
규정 없음
체인으로 넘김, 줄일 수만 있음
호출별 판정
호스트 구현에 맡김
호출마다 서버가 판정
사람의 승인
호스트 UI 의 몫
승인 요청·한 번/세션 동안·철회·기록
한도
없음
위임마다 토큰·시간·하위 세션 한도
기록
구현마다 다름
중앙 원장, 순번이 있는 사건
비밀값
구현마다 다름
이름으로 참조, 실행 시점에만 주입
에이전트 사이의 말
범위 밖
관계·작업이 붙은 메시지, 전달·읽음 확인
생태계
넓다
이제 시작
실제로 돌려 보니
저희는 에이전트 네다섯으로 한 팀을 꾸려 하루를 운영했습니다. 관리자 역할이 사람의 결정을 받아 나누고, 구현 담당이 만들고, 검증 담당이 독립적으로 확인했습니다. 사람은 결정만 내렸습니다.
눈에 띈 것은 두 가지였습니다.
맥락이 섞이지 않았습니다. 각 에이전트는 자기 대화와 자기 원장만 가졌고, 남의 일은 관계와 작업이 표시된 메시지로만 받았습니다. 에이전트들이 "담당의 보고"와 "내가 직접 확인한 것"을 구분해 적는 모습이 원장에 꾸준히 남았습니다.
고치기가 쉬웠습니다. 그날 결함이 여럿 나왔는데, 대부분 추측이 아니라 원장의 순번과 시각을 따라가서 찾았습니다. "모델이 답하지 않았다"와 "사람이 취소했다"를 구분할 수 없었던 곳처럼, 원장에 없어서 못 본 것은 그대로 다음 과제가 됐습니다.
거칠었던 부분도 적어 둡니다. 에이전트들이 서로 "확인했습니다"만 주고받느라 30분에 메시지가 100건을 넘은 적이 있습니다. 모델 호출이 몰리면 실패했고, 그 실패로 작업이 멈췄습니다. 이런 문제는 MCP 에는 아예 없는 층에서 생긴 것이라, 위임 계층을 만드는 누구나 겪게 될 일입니다.
그래서 어느 쪽이 더 뛰어난가
에이전트 여럿이 사람을 대신해 일하는 상황에서는 NMCP 가 더 뛰어납니다. MCP 가 하는 일을 모두 포함하고, MCP 가 답하지 않는 다섯 가지 질문에 답하기 때문입니다. 에이전트가 늘어날수록 권한을 위임 형식으로 다루는 일은 선택이 아니라 필수가 될 것이라고 저희는 봅니다.
하지만 "더 뛰어나다"가 "대신한다"는 뜻은 아닙니다.
MCP 는 공개 표준이고 많은 사람이 써서 검증했습니다. NMCP 는 아직 저희 팀에서만 돌았습니다.
MCP 서버는 이미 수없이 많습니다. 그 도구들을 버리고 새로 만들 이유가 없습니다.
표준은 옳은 쪽이 아니라 많이 쓰는 쪽이 됩니다.
그래서 저희의 결론은 확장 입니다. NMCP 는 MCP 의 대안이 아니라 MCP 위에 얹는 위임 계층입니다. 구체적으로는 세 가지를 합니다.
Nexus 의 도구를 MCP 서버로 내놓아, 어떤 MCP 클라이언트든 위임장 아래에서 일할 수 있게 합니다.
에이전트가 외부 MCP 서버의 도구를 쓸 때, 호출마다 위임장의 판정을 거치게 합니다.
위임장의 형식과 판정 규칙을 공개 규격으로 문서화합니다.
이렇게 하면 MCP 생태계의 도구는 전부 그대로 쓰면서, MCP 에 없는 "누구를 대신해 어디까지"를 더할 수 있습니다.
다음 글 에서는 1번, Nexus 를 MCP 도구로 만드는 방법을 단계별로 적습니다.
이 글의 MCP 설명은 2026-07-28 개정판 규격을 기준으로 했습니다.
참고: MCP 규격 , MCP 인증
© 2026. All rights reserved.