에이전트에 외부 도구를 붙이는 콘센트 — OpenClaw가 MCP 서버를 등록·관리하는 방법

오픈소스 개인 AI 어시스턴트 OpenClaw를 집 서버에 올려 쓰면서 화면 메뉴를 하나씩 뜯어봤다. 그중 MCP 메뉴가 가장 흥미로웠다. AI 에이전트가 똑똑해도 그 자체로는 내 파일을 읽거나 개인 위키를 검색하거나 지메일을 보내지 못한다. 외부 시스템과 이어 줘야 비로소 일을 한다. MCP(Model Context Protocol, AI 모델과 외부 시스템을 잇는 표준 프로토콜)는 그 연결을 표준화한 규격이다. 흔히 "AI의 USB-C 포트"에 비유된다 — 기기마다 다른 충전 단자 대신 하나의 포트로 통일하듯, 도구마다 다른 연동 방식 대신 하나의 프로토콜로 붙인다는 발상이다. 이 글은 OpenClaw의 Control UI(브라우저 관리 화면) MCP 메뉴가 그 "포트들"을 어떻게 등록·인증·관리하는지를 따라간다. 에이전트가 실제로 그 도구를 호출하는 이야기는 다른 글로 미룬다 — 여기서는 "서버를 붙이고 관리하는 화면"만 본다.

배경 — 에이전트는 혼자서는 아무 도구도 없다

대화만 하는 챗봇과 달리, 일을 시키는 에이전트는 바깥 세계에 손이 닿아야 한다. 파일을 읽고, 문서를 검색하고, 캘린더에 일정을 넣는 식이다. 문제는 이런 도구가 제각각이라는 점이다. 파일시스템 도구, 사내 문서 검색 도구, 데스크톱 조작 도구 — 예전엔 도구마다 연동 코드를 따로 짜야 했다. MCP는 이 N×N 짝짓기 문제를 하나의 표준으로 바꾼다.

다이어그램 설명. 이 그림은 에이전트가 여러 외부 도구 서버를 하나의 표준 프로토콜을 거쳐 붙인다는 핵심 구조를 보여준다. 에이전트가 표준 포트(MCP)를 거쳐, 파일시스템·메모리·원격 문서·데스크톱 조작 같은 서로 성격이 다른 서버들로 갈라진다. 핵심은 가운데 한 칸이다 — 이 표준 포트가 없다면 에이전트는 서버 종류마다 다른 연동 코드를 품어야 하지만, 표준이 끼면 서버 쪽이 그 규격만 지키면 에이전트는 똑같은 방식으로 모두를 다룬다. 놓치기 쉬운 점은 이 표준이 "서버를 자동으로 찾아 준다"는 게 아니라는 것이다 — 어떤 서버를 붙일지, 어떻게 인증할지는 누군가 등록해 줘야 한다. 그 등록과 관리를 맡는 화면이 바로 이 글의 주제다. 즉 표준 포트가 케이블 규격이라면, MCP 메뉴는 "어떤 기기를 어느 포트에 꽂을지 정하는 배전반"인 셈이다.

핵심 문제 — 서버 정의가 런타임마다 흩어진다

표준이 있다고 끝이 아니다. 실제로 도구를 붙이려면 "어떤 서버를, 어떤 방식(로컬 프로세스/원격 HTTP)으로, 어떤 인증으로, 어떤 도구만 노출해서" 연결할지를 정의해야 한다. 문제는 이 정의를 어디에 두느냐다. 에이전트 런타임(실제로 모델을 돌리는 실행 환경)마다 자기 서버 목록을 따로 들고 있으면, 같은 MCP 서버를 쓰는 런타임이 셋일 때 같은 정의를 세 번 적게 된다. 하나를 고치면 나머지도 손으로 맞춰야 하고, 어느 하나가 어긋나면 "어떤 런타임은 되고 어떤 건 안 되는" 추적하기 어려운 불일치가 생긴다. MCP 메뉴가 푸는 핵심은 바로 이 흩어짐이다 — 서버 정의를 한곳에 모으고, 모든 런타임이 그 한 벌을 공유하게 하는 것.

해결 방법 — 중앙 레지스트리와 그것을 비추는 관리 화면

OpenClaw는 MCP 서버 정의를 설정 파일의 mcp.servers 한곳에 모은다. 이게 중앙 레지스트리(서버 정의를 모아 둔 등록부)다. 에이전트 런타임은 자기만의 서버 목록을 따로 들지 않고 이 레지스트리를 읽어 쓴다. 그리고 Control UI의 MCP 메뉴는 이 레지스트리를 읽어서 그대로 비추는 거울이다 — 화면이 별도의 상태를 가지는 게 아니라, 설정에 든 서버들을 요약해 보여준다.

다이어그램 설명. 이 그림은 서버 정의 한 벌을 여러 입구에서 다룬다는 점을 보여준다. 가운데 설정 파일이 단일 진실의 원천이고, 브라우저 화면과 명령줄 도구는 같은 정의를 만지는 두 입구일 뿐이다. 둘 중 무엇으로 고치든 결국 같은 레지스트리에 쌓이고, 에이전트 런타임이 그걸 읽어 도구로 노출한다. 이 설계의 장점은 "한 번 등록하면 모든 런타임이 공유한다"는 것이다 — 앞서 본 중복 정의 문제가 여기서 풀린다. 흔한 오해는 "화면에서 토글하면 즉시 반영된다"는 가정인데, 실제로는 저장·발행 후 활성 에이전트가 다음 사용 시점에 MCP 런타임을 다시 올린다.

요약 카드 — 네 개의 숫자로 전체를 본다

MCP 메뉴를 열면 맨 위에 숫자 카드 네 개가 뜬다. 등록된 서버를 한눈에 가늠하라는 의도다. 화면 코드가 실제로 세는 값은 이렇다.

다이어그램 설명. 이 그림은 요약 카드 네 칸이 각각 무엇을 세는지 보여준다. 등록된 서버 목록에서 전체 개수, 켜진 개수, OAuth(권한 위임형 인증 — 비밀번호 대신 발급된 토큰으로 접근) 흐름을 쓰는 개수, 도구 필터를 건 개수를 따로 집계한다. "켜진 개수" 칸은 단순 숫자가 아니라, 전부 켜졌으면 녹색·하나라도 꺼졌으면 주의색으로 칠해 비활성 서버가 있다는 걸 색으로 알린다. 이 카드가 가치 있는 이유는 서버가 열 개를 넘어가면 행을 다 훑기 전에 "지금 OAuth 쓰는 서버가 셋, 필터 건 게 둘"을 즉시 알 수 있어서다.

서버 행 — 전송 방식·인증·필터를 한 줄로

요약 아래로는 서버마다 한 줄(행)이 깔린다. 행에는 이름과 활성 여부, 실행 대상(로컬 명령 또는 원격 URL), 그리고 그 서버의 성격을 알려 주는 작은 표지들이 붙는다. 화면 코드가 서버 설정을 읽어 이 표지를 어떻게 정하는지 보면 MCP 서버의 뼈대가 드러난다.

다이어그램 설명. 이 그림은 화면이 서버 한 줄을 그리기 위해 거치는 판단을 보여준다. 가장 먼저 원격 주소가 있는지 보고, 있으면 원격 HTTP 서버로, 없고 실행할 명령만 있으면 로컬 프로세스(stdio — 표준 입출력으로 통신하는 로컬 자식 프로세스)로, 둘 다 없으면 "전송 방식 없음"으로 표시한다. 전송 방식이 정해지면 그 아래로 부가 표지가 붙는다 — 인증 방식, 도구 필터 여부, 병렬 호출 허용 여부, TLS(전송 암호화) 상태. 여기서 설계 의도가 드러난다: 한 줄만 보고도 "이 서버는 원격이고, OAuth로 인증하고, 도구를 필터링했고, 병렬 호출이 안전하다"를 읽을 수 있게 한 것이다.

도구 필터 — 서버의 모든 도구를 다 노출하지 않는다

서버 하나가 도구를 스무 개 내놓아도, 에이전트에게 정작 필요한 건 그중 몇 개일 때가 많다. OpenClaw는 서버별로 노출할 도구를 include(허용 목록)와 exclude(차단 목록)로 추린다.

다이어그램 설명. 이 그림은 서버가 가진 도구가 에이전트에 닿기 전에 거치는 거름망을 보여준다. 서버는 읽기·검색·삭제·관리 같은 도구를 다 광고하지만, 가운데 필터에서 허용 목록(예: 이름이 search로 시작하는 도구)과 차단 목록(예: 이름이 admin으로 시작하는 도구)을 적용해, 통과한 것만 에이전트에 도달한다. 필터는 별표를 쓰는 간단한 패턴(예: search_*)도 받는다. 이 패턴이 중요한 이유는 최소 권한 원칙(필요한 권한만 주고 나머지는 막는 보안 원칙)을 도구 단위로 적용한다는 점이다 — 메모리 서버의 조회 도구는 열어 주되 삭제 도구는 막는 식이다.

인증과 진단 — 화면은 보여 주고, 증명은 명령줄이 한다

MCP 메뉴에서 눈여겨볼 설계가 하나 더 있다. 화면은 서버를 요약·토글·편집까지만 하고, 서버가 실제로 살아서 연결되는지는 직접 확인하지 않는다. 대신 각 서버 행에 복사해 쓸 명령줄 한 줄을 띄워, 살아 있음 증명은 명령으로 넘긴다.

다이어그램 설명. 이 그림은 화면이 하는 일과 명령줄로 넘기는 일을 갈라 보여준다. 화면에서 서버를 고치고 저장만 누르면 설정 파일에만 반영되고, 발행까지 누르면 게이트웨이(에이전트들을 관리하는 상주 서버) 설정 경로로 적용된다. 그런데 화면은 절대 직접 서버에 접속하지 않는다 — 대신 점선처럼 행마다 명령 힌트를 띄운다. 일반 서버에는 연결을 실제로 열어 도구 목록을 확인하는 진단 명령을, OAuth 서버에는 인증 흐름을 수행하는 로그인 명령을 보여 준다. 이렇게 나눈 이유는 명확하다: 관리 화면을 여는 것만으로 등록된 서버 수십 개에 일제히 접속이 일어나면 곤란하기 때문이다. "보여 주기"와 "접속하기"를 분리해, 화면은 조용히 요약만 하고 실제 접속은 사람이 명령으로 명시할 때만 일어난다.

결과 — 무엇이 좋아졌나

중앙 레지스트리가 들어오면서 핵심인 중복 정의가 풀리고, 그 위에 MCP 메뉴가 더해 주는 것들이 이렇게 정리된다.

흩어진 서버 정의 (이전)	중앙 레지스트리 + MCP 메뉴 (이후)
같은 서버를 런타임마다 중복 정의	한 곳(mcp.servers)에 등록 → 모든 런타임이 공유
서버의 모든 도구가 모델에 노출	include/exclude 필터로 필요한 도구만 통과
서버 상태를 한눈에 못 봄	요약 카드 4개로 전체·활성·OAuth·필터 개수 즉시 파악
관리 화면이 서버에 무단 접속	화면은 요약만, 실제 연결 증명은 명령으로 명시할 때만

정리하면, OpenClaw의 MCP 메뉴는 "에이전트에 외부 도구를 붙이는 배전반"이다. 어떤 서버를 어떤 인증으로 꽂을지, 그 서버의 어떤 도구만 에이전트 손에 쥐여 줄지를 한 화면에서 정하고, 그 정의를 모든 실행 환경이 공유한다. 화려한 기능은 아니지만, 이런 표준화된 연결 관리가 있어야 에이전트가 "대화만 하는 챗봇"에서 "내 시스템에 손이 닿는 일꾼"으로 넘어간다. USB-C 포트가 케이블 정글을 정리했듯, MCP와 그 관리 화면이 도구 연동의 정글을 정리하는 셈이다. 이 글은 "붙이고 관리하는 쪽"만 봤고, 에이전트가 실제로 그 도구를 골라 호출하는 이야기는 별도 글의 몫이다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.