Nexus 를 MCP 도구로 만드는 법 — 단계별 계획

Nexus 를 MCP 서버로 내놓은 구성도. Claude Code 같은 MCP 클라이언트가 stdio(1단계)나 HTTP + OAuth 2.1(5단계)로 Nexus MCP 서버의 도구 9개를 부른다. 모든 호출은 봉인된 위임장에 따라 허용·질문·거절로 판정되고, 권한을 넓히는 승인은 사람만 하며, 모든 호출이 원장에 기록된다.

소개

앞 글의 결론은 "NMCP 는 MCP 의 확장"이었습니다. 이 글은 그 첫걸음을 다룹니다. Nexus 의 도구를 MCP 서버로 내놓아, 어떤 MCP 클라이언트든 위임장 아래에서 일할 수 있게 하는 방법입니다.

지금 Nexus 의 도구는 저희 에이전트 엔진에만 붙어 있습니다. 다른 에이전트가 팀에 들어오려면 저희 엔진으로 돌아야 합니다. MCP 서버로 내놓으면 이 제약이 사라집니다. 이미 쓰고 있는 에이전트를 그대로 둔 채, 팀의 한 자리로 들일 수 있습니다.

먼저 정해 둔 원칙

단계를 나누기 전에, 어느 단계에서도 바꾸지 않을 것부터 적습니다.

집행은 모델이 아니라 서버가 합니다. 모델이 위임을 잘못 읽어도 서버가 거절합니다. 모델에게 위임을 보여 주는 것은 헛수고를 줄이고 설명할 수 있게 하려는 것입니다.
위임장의 내용을 프롬프트에 넣지 않습니다. 위임장은 봉인된 채 전달되고, 모델은 도구를 불렀을 때만 필요한 항목을 읽습니다.
권한을 넓히는 것은 사람만 합니다. 에이전트나 다른 에이전트의 메시지는 권한을 넓힐 수 없습니다.
다른 에이전트의 메시지는 요청이지 권한이 아닙니다. 받는 쪽은 자기 위임 안에서만 돕습니다.
"읽음"은 모델의 입력에 들어간 순간입니다. 가져갔거나 화면에 띄운 것은 읽은 것이 아닙니다.

MCP 규격도 "도구 설명과 주석은 신뢰할 수 있는 서버에서 온 것이 아니면 믿지 말라"고 적습니다. Nexus 도구에도 같은 원칙이 적용됩니다. 설명은 안내이고, 판정은 서버가 합니다.

내놓을 도구

Nexus 의 도구는 이미 MCP 도구와 같은 모양(이름, 설명, JSON 스키마)으로 정의돼 있습니다. 그래서 옮기는 일 자체는 어렵지 않습니다.

도구	하는 일
`delegation_info`	자기 위임(위임자, 작업, 범위, 정책 요약, 남은 한도, 만료)을 읽는다. 특정 행동이 되는지만 물을 수도 있다
`request_approval`	위임에 없거나 정책이 묻는 행동을 사람에게 승인 요청한다
`delegate_task`	하위 작업을 다른 에이전트에게 맡긴다. 범위와 한도는 자기 것 이하
`task_status`	맡긴 작업의 상태와 결과를 보거나 기다린다
`nexus_peers`	같은 계정의 에이전트와 각자 지금 하는 작업을 본다
`send_message`	다른 에이전트에게 쓴다. 답을 기대하지 않는 알림은 그렇게 표시한다
`nexus_inbox`	자기에게 온 메시지를 읽는다
`nexus_tree` / `nexus_log`	작업 트리의 진행과 원장을 읽는다

0단계 — 계약을 한 곳에 고정한다

먼저 도구의 이름, 입력 스키마, 결과와 오류의 형식, 그리고 적합성 시험을 한 문서와 한 벌의 시험으로 고정합니다.

이유: 같은 도구가 저희 엔진과 MCP 서버 두 경로로 나가게 됩니다. 두 경로의 동작이 갈리면 위임의 의미가 흔들립니다.
산출물: 도구 계약 문서, 그리고 "위임 밖 행동은 거절된다", "아래 에이전트는 권한을 늘릴 수 없다" 같은 규칙을 저장소 종류와 무관하게 확인하는 적합성 시험.
완료 기준: 엔진 경로와 MCP 경로가 같은 시험을 통과한다.

1단계 — stdio MCP 서버

가장 단순한 형태부터 만듭니다. 에이전트가 자기 장치에서 MCP 서버를 하위 프로세스로 띄우는 방식입니다.

서버가 뜨는 순간 Nexus 에 그 에이전트의 세션이 생기고(이름을 지정), 그 세션에 위임장이 발급됩니다.
tools/list 는 위 도구들을 돌려주고, tools/call 은 Nexus 의 같은 도구를 부릅니다.
모든 호출은 그 세션의 원장에 기록됩니다.
자격 증명은 MCP 규격대로 환경에서 가져옵니다(stdio 전송은 OAuth 흐름을 쓰지 않습니다).
위임장은 봉인된 채 서버 프로세스 안에서만 풀립니다. 모델은 delegation_info 로만 읽습니다.

완료 기준: 외부 MCP 클라이언트 하나가 동료 목록을 보고, 메시지를 보내고, 답을 받는다. 그 호출이 모두 원장에 남는다. 위임에 없는 행동을 요청하면 거절되고 승인 요청으로 이어진다.

2단계 — 메시지를 받는 길

여기서 MCP 의 구조가 걸립니다. MCP 는 클라이언트가 묻고 서버가 답하는 방식이라, 서버가 모델에게 메시지를 밀어 넣을 수 없습니다. 저희 엔진에서는 메시지가 오면 턴 중간에 끼워 넣고, 쉬는 중이면 스스로 턴을 열었습니다. MCP 클라이언트에서는 그렇게 못 합니다.

세 가지를 순서대로 시도합니다.

기다리는 받은편지함. nexus_inbox 에 기다리는 시간을 줄 수 있게 합니다. 에이전트가 할 일이 없을 때 이 도구로 다음 메시지를 기다립니다.
Tasks 확장. MCP 의 Tasks 확장은 오래 걸리는 작업을 폴링과 지속되는 핸들로 다룹니다. 답이나 승인을 기다리는 일을 여기에 얹을 수 있는지 봅니다.
호스트의 훅. 호스트가 훅이나 알림을 지원하면, 메시지가 왔을 때 에이전트를 깨우게 합니다. 호스트마다 다르므로 선택 사항입니다.

"읽음"의 기준은 그대로입니다. 메시지가 도구 결과로 모델에 들어간 순간에만 읽음으로 기록합니다.

완료 기준: 외부 에이전트에 보낸 메시지의 상태(보냄 → 전달 → 읽음)가 보낸 쪽에서 정확히 보인다. 에이전트가 쉬고 있을 때 온 메시지가 사람의 개입 없이 읽힌다(호스트가 허용하는 범위에서).

3단계 — 사람의 승인

request_approval 은 지금 메일로 사람에게 갑니다. MCP 에는 서버가 사용자에게 추가 정보를 묻는 elicitation 이 있습니다.

사람이 그 자리에 있으면 elicitation 으로 묻습니다. 무엇을, 왜, 어느 범위로 허락하는지 보여 줍니다.
자리에 없으면 종전대로 메일로 갑니다.
어느 길로 오든 결정은 원장에 남고, "한 번만"과 "이 세션 동안"을 구분합니다.

완료 기준: 같은 승인 요청이 두 길 중 하나로만 결정되고, 결정한 사람과 시각이 원장에 남는다. 에이전트가 스스로 승인할 방법이 없다.

4단계 — 에이전트 자신의 도구까지

1~3단계의 한계를 분명히 해 둡니다. 외부 에이전트가 원래 가진 도구(파일 편집, 셸 실행 등)는 Nexus 가 막지 못합니다. 그 도구들은 Nexus 를 거치지 않기 때문입니다. 이 단계 전까지 외부 에이전트는 "팀에 참여하고 보고하는" 수준이고, "위임장으로 통제되는" 수준은 아닙니다.

통제하려면 그 에이전트의 런타임이 도구를 실행하기 전에 Nexus 에 물어야 합니다.

런타임 훅: 도구 실행 전 훅을 지원하는 런타임에서는, 훅이 Nexus 의 판정을 받아 허용·질문·거절을 따릅니다.
게이트웨이: 에이전트가 쓰는 외부 MCP 서버를 Nexus 뒤에 둡니다. 에이전트는 Nexus 를 통해 그 도구를 부르고, Nexus 가 호출마다 판정한 뒤 넘깁니다. 앞 글의 2번 방향과 이어집니다.
훅도 게이트웨이도 쓸 수 없는 런타임은 "참여만 가능"으로 표시합니다. 통제되지 않는 것을 통제된다고 말하지 않습니다.

완료 기준: 훅을 붙인 런타임에서, 위임에 없는 도구 호출이 실행 전에 막히고 그 사실이 원장에 남는다.

5단계 — HTTP 전송과 표준 인증

장치 안의 하위 프로세스가 아니라 원격 서버로 내놓는 단계입니다. 여기서는 MCP 의 인증 규격을 그대로 따릅니다.

Nexus 가 OAuth 2.1 의 리소스 서버가 됩니다. 보호된 리소스 메타데이터를 내고, 토큰이 이 서버를 위해 발급된 것인지 확인합니다.
다른 서버를 위한 토큰을 받거나 넘기지 않습니다(MCP 규격의 요구이기도 합니다).
토큰과 위임장은 역할이 다릅니다. 토큰은 "이 서버에 접속해도 되는가"를, 위임장은 "이 작업에서 어디까지 해도 되는가"를 답합니다. 토큰으로 세션을 확인한 뒤, 그 세션의 위임장으로 호출을 판정합니다.
"누가 누구를 대신하는가"를 체인으로 표현하는 가장 가까운 표준은 OAuth 토큰 교환(RFC 8693)의 act 클레임입니다. 위임 체인을 토큰에 실을 때 이 형식을 따르는 것을 검토합니다.

완료 기준: 표준 MCP 클라이언트가 추가 설정 없이 인증 흐름을 마치고 도구를 쓴다. 잘못된 대상의 토큰은 거절된다.

6단계 — 규격을 공개한다

마지막으로 다음을 공개 문서로 냅니다.

위임장의 형식(범위, 정책, 한도, 체인, 만료, 봉인)
판정 규칙(체인의 가장 엄격한 답을 따르고, 어느 고리도 언급하지 않은 행동은 거절)
원장의 사건 종류와 순서 보장
도구의 스키마와 오류 형식

MCP 는 확장을 선택형으로 받습니다. 위임 계층도 그 틀에 맞는 확장 제안의 형태로 정리하는 것이 목표입니다.

미리 적어 두는 한계

강제의 범위. 4단계 전까지 Nexus 는 외부 에이전트의 자체 도구를 막지 못합니다.
모델 예산. 외부 에이전트의 모델 호출은 Nexus 의 게이트웨이를 거치지 않으므로 토큰 한도로 집계되지 않습니다. 하위 작업을 몇 개까지 맡길 수 있는지 같은, Nexus 를 거치는 한도는 그대로 적용됩니다.
주입. 도구 결과와 다른 에이전트의 메시지에 섞인 지시는 여전히 위험합니다. 위임장은 "따르더라도 위임 안에서만"을 보장할 뿐, 따르지 않게 해 주지는 않습니다.
성숙도. 위임 계층은 저희 팀에서만 돌았습니다. 운영 첫날에도 결함이 여럿 나왔고 원장으로 찾아 고쳤습니다. 단계마다 실제 팀에서 돌려 본 뒤에 다음으로 넘어갑니다.

순서의 이유

1단계만으로도 얻는 것이 있습니다. 다른 에이전트가 팀의 메시지 체계 안으로 들어옵니다. 누가 보낸 것인지, 지시인지 요청인지, 읽혔는지가 구조로 주어집니다. 여러 에이전트를 함께 써 본 분이라면 이 차이를 아실 것입니다.

통제는 4단계에서 완성됩니다. 그 사이의 단계들은 "참여"에서 "통제"로 가는 길이고, 각 단계의 완료 기준은 그 단계가 무엇을 보장하고 무엇을 아직 보장하지 않는지를 말하도록 적었습니다.

이 글의 MCP 설명은 2026-07-28 개정판 규격을 기준으로 했습니다.

참고: MCP 규격, MCP 인증, OAuth 2.0 토큰 교환(RFC 8693)

다음 글: 표준은 옳은 쪽이 아니라 많이 쓰는 쪽이 된다 — NMCP 확산 전략