표준은 옳은 쪽이 아니라 많이 쓰는 쪽이 된다 — NMCP 확산 전략
문서 발행일: 2026년 10월 2일
서론
앞의 두 글에서 저희는 NMCP 가 MCP 의 확장 이라고 결론 내렸고, Nexus 를 MCP 도구로 만드는 단계 를 적었습니다. 첫 글의 끝에 이런 문장이 있었습니다.
표준은 옳은 쪽이 아니라 많이 쓰는 쪽이 됩니다.
설계가 옳다고 해서 쓰이는 것은 아닙니다. 에이전트의 권한을 위임 형식으로 다뤄야 한다는 생각이 맞더라도, 쓰기 번거롭거나 믿기 어렵거나 한 회사의 제품에 갇혀 있으면 사라집니다. 이 글은 저희가 NMCP 를 어떻게 퍼뜨리려 하는지, 그리고 무엇을 하지 않으려 하는지를 적습니다.
여섯 가지 원칙
1. 입구는 "통제"가 아니라 "소통"이다
위임장의 가치는 팀이 커져야 느껴집니다. 에이전트 둘을 쓰는 사람에게 "권한이 체인으로 줄어든다"는 말은 아직 남의 일입니다.
반면 이것은 첫날 바로 느낍니다.
다른 에이전트에게 보낸 메시지가 전달됐는지, 모델이 실제로 읽었는지 안다.
받은 메시지가 지시인지, 요청인지, 보고인지 구조로 구분된다.
각 에이전트의 맥락이 섞이지 않는다.
여러 에이전트 세션을 나란히 띄워 본 사람은 이 불편을 압니다. 한쪽에서 한 말을 다른 쪽에 사람이 옮겨 주고, 읽었는지 몰라 다시 묻습니다. NMCP 의 입구는 이 불편을 없애는 것입니다. 통제는 그 팀이 커졌을 때 이미 거기 있으면 됩니다.
2. 설치는 1분, 첫 경험에는 결제도 설정도 없다
에이전트 하나가 팀에 들어오는 데 걸리는 시간이 길면 아무도 두 번째 에이전트를 들이지 않습니다. 목표는 명령 한 번입니다. 계정을 만들고 요금제를 고르는 일이 첫 메시지를 보내는 일보다 앞에 오지 않게 합니다.
3. 규격과 판정 규칙을 연다
권한을 맡기는 서비스는 신뢰가 전부입니다. "어떤 행동이 왜 허용됐는가"를 저희만 아는 방식으로 판정하면, 그 판정을 믿을 이유가 없습니다.
그래서 다음을 공개합니다.
위임장의 형식과 판정 규칙
도구의 계약(이름, 입력, 결과, 오류)
구현이 규칙을 지키는지 확인하는 적합성 시험
허브를 직접 띄울 수도 있게 합니다. 저희가 운영하는 허브는 편의이지 유일한 길이 아닙니다.
4. 특정 모델에 묶지 않는다
MCP 클라이언트면 무엇이든 붙을 수 있어야 합니다. 한 팀 안에 서로 다른 모델의 에이전트가 섞이는 것이 오히려 자연스럽습니다. 구현 담당과 검증 담당이 다른 모델이면 독립 검증의 의미가 더 커집니다.
5. 운영 기록을 계속 공개한다
이 분야는 써 본 사람이 아직 적습니다. 그래서 "이렇게 하면 된다"는 주장보다 "이렇게 해 봤더니 이랬다"는 기록이 더 귀합니다.
저희는 잘된 것과 함께 거칠었던 것도 씁니다. 첫 글에 적은 대로, 에이전트들이 서로 "확인했습니다"만 주고받느라 메시지가 30분에 100건을 넘은 적이 있고, 모델 호출이 몰려 작업이 멈춘 적도 있습니다. 이런 기록이 다음에 같은 층을 만드는 사람에게 가장 쓸모 있습니다.
6. 표준 쪽으로 가져간다
NMCP 가 저희만의 방식으로 남으면, 옳았더라도 혼자 쓰는 것이 됩니다. 그래서 MCP 가 운영되는 방식 안에서 제안합니다.
이미 하고 있는 증명
NMCP 가 가려는 방향은 저희에게 가설이 아닙니다. 이미 그렇게 일하고 있습니다.
저희 팀의 에이전트들은 Nexus 위에서 돕니다. 그리고 그 옆에서 Claude 세션이 함께 일합니다. Claude 는 팀의 원장을 읽어 무슨 일이 있었는지 파악하고, 사람의 결정을 팀에 전하고, 원장의 순번과 시각을 따라가 결함을 찾아 고칩니다. 앞의 두 글에 적은 운영 기록과 고친 결함의 대부분이 그렇게 나왔습니다. 이 글들도 그 협업의 결과입니다.
서로 다른 에이전트가 한 팀으로 일할 수 있다는 것, 그리고 그 사이를 잇는 것이 원장과 메시지라는 것을 저희는 매일 확인하고 있습니다.
지금은 한 가지가 빠져 있습니다. Claude 는 아직 팀의 한 자리로 들어와 있지 않고, 사람의 자격으로 명령줄을 통해 팀에 닿습니다. 그래서 Claude 세션끼리 주고받은 메시지는 읽혔는지 알 수 없고, 지시인지 정보인지도 매번 글로 밝혀야 합니다. 같은 날 같은 일을 하면서, 허브 안의 에이전트들 사이는 매끄럽고 허브 밖의 세션들 사이는 그렇지 않았습니다.
이 차이가 두 번째 글의 1단계를 만드는 이유입니다. Nexus 가 MCP 서버가 되면 Claude 는 자기 위임장을 가진 팀원으로 들어옵니다. 저희가 첫 사용자이고, 무엇이 달라지는지는 저희 팀에서 먼저 재게 됩니다.
MCP 생태계에 올라가는 길
사용자에게 닿는 길
직접 연결. MCP 서버 주소를 넣어 연결하는 방식은 지금도 됩니다. 등재를 기다릴 필요가 없습니다.
Claude 의 커넥터 디렉터리. 등재되면 웹, 데스크톱, 모바일, Claude Code, Cowork 가 같은 목록을 씁니다. 대화 중에 관련 커넥터가 추천되기도 합니다. 조건은 공개 HTTPS 주소의 원격 MCP 서버, 표준 인증, 도구마다 읽기 전용인지 파괴적인지의 표시입니다. 두 번째 글의 5단계가 이 조건과 같습니다.
에이전트 런타임의 플러그인. MCP 서버, 도구 실행 전 훅, 사용 안내를 한 묶음으로 배포할 수 있는 런타임에서는, 설치 한 번으로 "참여"와 "호출별 판정"을 함께 줄 수 있습니다. 두 번째 글의 1단계와 4단계가 한 번에 됩니다.
공개 MCP 레지스트리. 특정 제품이 아니라 MCP 클라이언트 전체에서 찾을 수 있게 합니다.
표준에 닿는 길
MCP 는 2025년 12월부터 Linux Foundation 산하의 재단이 운영합니다. 변경은 작업 그룹에 제안서(SEP)를 내는 방식으로 이뤄지고, 핵심 규격 밖의 실험은 선택형 확장으로 받습니다.
2026년 로드맵의 우선 과제에는 "기업 준비(감사 기록, 게이트웨이 동작 등)"와 "에이전트 간 소통"이 있습니다. NMCP 의 원장과 메시지가 이 과제들과 겹칩니다. 반면 권한을 체인으로 넘기는 위임과 작업별 한도는 로드맵에 없습니다. 저희가 보기에 비어 있는 자리입니다.
저희의 순서는 이렇습니다. 먼저 돌아가는 구현과 운영 기록을 만들고, 그것을 근거로 위임 계층을 확장의 형태로 제안합니다. 제안이 받아들여지지 않더라도 규격은 공개돼 있으니 누구나 구현할 수 있습니다.
과금에 대하여
NMCP 로 붙는 에이전트는 모델을 자기 것으로 씁니다. 허브가 다루는 것은 메시지, 위임, 원장뿐입니다. 그래서 허브에는 모델 비용이 들지 않습니다.
이 구조 덕분에 과금은 단순해집니다.
저희가 운영하는 허브를 쓰면, 서버 사용료 수준의 소액을 받습니다.
허브를 직접 띄우면 무료입니다.
과금은 많은 사람이 쓰게 된 뒤의 일입니다. 지금은 쓰기 쉽게 만드는 일이 먼저입니다.
값을 매기는 지점을 "대신 운영해 주는 것"에 두면, 규격을 여는 것과 돈을 받는 것이 충돌하지 않습니다.
하지 않을 것
특정 모델이나 특정 런타임 전용으로 만들지 않습니다.
규격을 닫아 두지 않습니다.
첫 경험 앞에 결제를 두지 않습니다.
통제되지 않는 것을 통제된다고 말하지 않습니다. 외부 에이전트의 자체 도구는 런타임이 허브에 물어 주기 전까지 막을 수 없고, 그 단계 전에는 "참여"라고만 부릅니다.
순서
Nexus 를 완성한다. 위임, 원장, 메시지, 승인이 저희 팀의 실제 운영에서 버티는 수준이 먼저입니다.
시제품. stdio MCP 서버와 플러그인으로, 다른 에이전트 세션을 실제 팀에 들입니다. 저희부터 매일 씁니다.
원격 서버와 등재. HTTP 전송과 표준 인증을 붙이고 디렉터리와 레지스트리에 올립니다.
규격 공개와 제안. 위임 계층을 문서로 내고 확장으로 제안합니다.
각 단계를 마쳤는지는 이 숫자들로 봅니다.
설치부터 첫 메시지를 보내기까지 걸린 시간
팀 하나에 들어와 있는 에이전트의 수
다음 날에도 같은 팀이 돌고 있는 비율
사람이 "계속 진행해"라고 다시 쳐야 했던 횟수
마지막 숫자는 저희가 운영 첫날부터 세어 온 것입니다. 에이전트 팀이 잘 돌아간다는 것은 결국 사람이 끼어들 일이 줄어든다는 뜻이기 때문입니다.
남은 위험
누군가 먼저 표준화할 수 있습니다. 그 경우 저희는 그 표준에 맞춥니다. 규격을 열어 두는 이유 중 하나입니다.
신뢰를 얻는 데 시간이 걸립니다. 권한을 다루는 계층은 한 번의 사고로 신뢰를 잃습니다. 단계마다 실제 팀에서 돌려 본 뒤에 넘어가는 이유입니다.
입구와 본체가 다릅니다. 소통 때문에 들어온 사용자가 위임까지 쓰게 될지는 아직 모릅니다. 저희의 가설은 "팀이 커지면 필요해진다"이고, 위 숫자들로 확인하려 합니다.
참고: Claude 커넥터 디렉터리 , MCP 2026 로드맵 , MCP 제안서(SEP)
© 2026. All rights reserved.