외부 시스템마다 도구를 손으로 만들면 안 끝난다 — OpenClaw가 MCP로 남의 도구를 꽂아 쓰는 법

오픈소스 AI 어시스턴트 OpenClaw를 집 서버에 올려 쓰다 보면, 에이전트에게 새 능력을 붙여 주고 싶은 순간이 끝없이 온다. GitHub에 이슈를 만들게 하고, 개인 위키를 검색하게 하고, 로컬 파일을 읽게 하고 싶다. 그때마다 "이 시스템을 부르는 도구"를 코드로 직접 짜 붙이면 — 외부 시스템이 열 개면 도구도 열 개를 손으로 만들고, 그 시스템의 API가 바뀔 때마다 다시 고쳐야 한다. 이 일은 영원히 안 끝난다. OpenClaw는 이 문제를 MCP(Model Context Protocol) — AI 모델과 외부 시스템을 잇는 표준 규약, 흔히 "AI용 USB-C 포트"에 비유된다 — 로 푼다. MCP 서버 하나를 등록해 두면, 그 서버가 제공하는 도구들이 에이전트 자신의 도구처럼 호출 가능해진다. 이 글은 "왜 손으로 만들면 안 되는가"부터 "에이전트가 그 외부 도구를 어떻게 자기 도구로 부르고, 도구가 너무 많아질 때 어떻게 다루는가"까지를 따라간다.

배경 — 에이전트가 쓸 도구는 계속 늘어난다

LLM 에이전트의 능력은 결국 도구(tool — 모델이 호출할 수 있는 함수, 예: "파일 읽기", "웹 검색")의 집합으로 정해진다. 모델 자체는 텍스트를 생성할 뿐이고, 바깥세상에 무언가를 하려면 도구를 거쳐야 한다. 그래서 어시스턴트를 실제로 쓸 만하게 만들려면 도구를 계속 붙여야 한다 — 내 캘린더, 내 노트 앱, 타 프로젝트 API, 데스크톱 제어까지.

문제는 이 도구들이 전부 남의 시스템이라는 데 있다. 캘린더는 구글이, 노트는 또 다른 회사가, 타 프로젝트 API는 다른 팀이 만든다. 어시스턴트 입장에서는 이 제각각인 시스템 하나하나에 맞춰 "이걸 부르는 코드"를 따로 작성해야 한다. 시스템이 늘 때마다 작업이 선형으로 늘고, 각 시스템의 인증 방식·요청 형식·에러 처리까지 떠안는다.

다이어그램 설명. 이 그림은 외부 도구를 표준 없이 하나하나 손으로 붙일 때 무슨 일이 벌어지는지를 보여준다. 'AI 에이전트'에서 외부 시스템 종류만큼 가지가 뻗고, 각 가지마다 그 시스템 전용으로 짠 어댑터(adapter — 서로 다른 인터페이스를 맞춰 주는 변환 코드)가 매달린다 — 그 모든 가지가 "N개를 따로 만들고 따로 유지보수"로 수렴한다. 이 패턴의 함정은 비용이 한 번이 아니라 지속적이라는 점이다. 처음 만드는 비용보다, 외부 API가 바뀔 때마다 N개 어댑터를 추적해 고치는 유지보수 비용이 더 크다. 그래서 무슨 가치인가 — 이 그림은 뒤에 나올 표준화(MCP)가 무엇을 없애려는지를 한 장으로 못 박는다. 없애려는 건 "도구 하나"가 아니라 "시스템마다 반복되는 어댑터 작성"이라는 노동 자체다.

핵심 문제 — 표준 없는 통합은 N제곱으로 늘어난다

표준이 없으면 통합 비용은 단순히 N개로 안 끝난다. 어시스턴트가 여러 개(예: OpenClaw 본체, Claude Code, Codex 같은 코딩 도구)이고 외부 시스템도 여러 개면, 각 어시스턴트가 각 시스템용 어댑터를 따로 들고 있어야 한다 — 어시스턴트 M개 × 시스템 N개 = M×N개의 짝맞춤이 필요해진다. 이것이 통합 표준이 없을 때 생기는 고전적인 "M×N 폭발" 문제다.

▲ 표준이 없을 때 — 클라이언트마다 같은 어댑터를 복제

다이어그램 설명. 위 다이어그램은 통합 표준이 없을 때 어댑터가 어떻게 중복되는지를 보여준다. 클라이언트가 둘만 돼도 같은 외부 시스템을 부르는 어댑터를 각자 따로 들고 있어야 한다 — 두 번째 클라이언트의 어댑터는 첫 번째 것을 거의 그대로 복제한 것이다. 핵심은 같은 시스템을 부르는 코드가 클라이언트 수만큼 중복된다는 점이고, 놓치기 쉬운 함정은 이 중복이 코드 줄 수가 아니라 버전 동기화 부담으로 돌아온다는 것이다. 시스템 A의 인증이 바뀌면 그걸 부르는 모든 클라이언트의 어댑터를 동시에 고쳐야 한다.

▲ MCP가 있을 때 — 시스템마다 서버 1개를 공유

다이어그램 설명. 위 다이어그램은 같은 상황을 MCP 표준 위에서 다시 그린 것이다. 외부 시스템마다 MCP 서버를 한 번만 만들어 두면, 모든 클라이언트가 그 한 서버에 표준 규약으로 붙는다 — 클라이언트가 둘이든 다섯이든 시스템 A를 부르는 코드는 서버 쪽에 단 하나뿐이다. 같은 위치에 쌓은 두 다이어그램을 비교하면 차이가 분명하다. 표준이 없으면 클라이언트마다 어댑터가 복제되지만, 표준이 있으면 외부 시스템 쪽에 통합 코드가 한 번만 산다. 그래서 무슨 가치인가 — OpenClaw가 직접 도구를 짜는 대신 MCP 서버를 "등록만" 하는 길을 택한 이유가 여기에 있다. 등록은 통합 노동을 OpenClaw 밖(서버 제작자 쪽)으로 밀어내고, OpenClaw는 표준 규약으로 꽂기만 한다.

해결 방법 — 등록한 MCP 서버의 도구를 에이전트의 도구로 투영한다

OpenClaw에서 MCP를 쓰는 흐름은 두 단계다. 먼저 외부 MCP 서버를 설정에 등록한다(openclaw mcp add). 이건 서버의 주소·실행 방법·인증을 OpenClaw 설정의 mcp.servers 항목에 저장하는 것뿐으로, 이 시점에는 아무것도 연결하지 않는다. 그다음 에이전트가 실제로 한 번 돌 때, OpenClaw 런타임이 그 등록 정보를 읽어 서버에 연결하고 — 서버가 광고하는 도구들을 에이전트 자신이 쓸 수 있는 도구 목록에 투영(projection)한다. 투영이란 외부 서버의 도구를 에이전트 입장에서 자기 도구처럼 보이게 끼워 넣는 것을 말한다.

다이어그램 설명. 이 그림은 등록된 MCP 서버의 도구가 에이전트의 손에 들어오기까지의 단계를 보여준다. 등록은 설정 파일에 서버 정의를 적는 것뿐이고, 실제 연결과 도구 노출은 에이전트 턴이 시작될 때 일어난다. 런타임이 서버에 붙어 도구 목록을 받아 카탈로그에 끼워 넣으면, 모델은 외부 도구를 자기 내장 도구와 구분 없이 호출한다. 외부 도구 호출도 OpenClaw의 권한·승인·로깅 정책을 그대로 통과한다. 그래서 무슨 가치인가 — 서버를 한 번 등록하면, 그 뒤로는 에이전트가 알아서 연결·발견·호출까지 처리한다.

도구가 너무 많아지는 문제 — 필터로 깎는다

MCP 서버 하나가 수십 개의 도구를 광고하는 일은 흔하다. 파일시스템 서버라면 읽기·쓰기·삭제·이동·검색이 다 들어 있다. 이걸 전부 에이전트에게 노출하면 두 가지가 나빠진다. 하나는 안전 — 읽기만 시키고 싶은데 삭제 도구까지 손에 쥐여 주게 된다. 다른 하나는 비용·정확도 — 도구 하나하나의 스키마(schema — 그 도구의 인자 형식을 적은 명세)가 모델의 프롬프트에 들어가므로, 도구가 많을수록 토큰을 먹고 모델이 엉뚱한 도구를 고를 확률이 올라간다.

OpenClaw는 서버마다 도구 필터(tool filter)를 둬서 어떤 도구만 통과시킬지 정한다. toolFilter.include에 적은 도구만 살리거나(read_file,list_directory처럼), toolFilter.exclude로 특정 도구를 빼거나, read_* 같은 와일드카드(* — 임의 문자열에 일치하는 패턴)로 묶어서 거른다. 이 필터는 서버가 광고한 도구가 OpenClaw 도구가 되기 전 단계에서 작동한다 — 즉 걸러진 도구는 애초에 모델 눈에 들어오지 않는다.

다이어그램 설명. 이 그림은 서버가 내놓은 도구 전체가 필터를 거쳐 에이전트에게 노출되기까지를 보여준다. 허용 목록에 든 것만 에이전트의 도구가 되고, 나머지는 모델 눈에 아예 들어오지 않는다. 차단이 모델 프롬프트에 도구가 실리기 전에 일어나기 때문이다 — "쓰지 말라고 지시"하는 게 아니라 애초에 존재를 숨긴다. 그래서 무슨 가치인가 — 같은 서버라도 에이전트 용도에 맞춰 "읽기 전용"으로 좁혀 꽂을 수 있어, 위험한 도구를 손에 쥐여 주지 않고 토큰도 아낀다.

도구가 수백 개일 때 — 검색으로 다룬다

필터로 깎아도 여러 MCP 서버를 동시에 붙이면 도구가 수백 개가 될 수 있다. 이쯤 되면 "전부 프롬프트에 싣기"라는 방식 자체가 한계에 부딪힌다. OpenClaw에는 이를 위한 실험적 기능 도구 검색(Tool Search)이 있다. 모든 도구의 전체 스키마를 미리 보여주는 대신, 모델에게 검색용 도구 하나만 쥐여 주고 — 모델이 필요할 때 그때그때 도구를 검색하고, 골라서 상세를 확인하고, 호출하게 한다.

// 도구 검색 모드에서 모델이 실행하는 코드 (격리된 Node 안에서 동작)
// 1단: 자연어로 필요한 도구를 검색 — 전체 카탈로그를 다 펼쳐 보지 않음
const hits = await openclaw.tools.search("create a GitHub issue");

// 2단: 후보 하나의 정확한 인자 스키마만 그때 확인
const tool = await openclaw.tools.describe(hits[0].id);

// 3단: 그 도구를 호출 — 실제 실행은 OpenClaw 게이트웨이로 되돌아가 정책 검사를 거침
return await openclaw.tools.call(tool.id, {
  title: "Crash on startup",
  body: "Steps to reproduce...",
});

코드 설명. 이 코드는 도구가 너무 많을 때 모델이 도구를 "검색해서" 쓰는 3단 흐름을 보여준다. 먼저 자연어 질의로 카탈로그에서 맞는 도구를 찾고, 그중 하나의 인자 명세만 그때 가져오고, 마지막에 그 도구를 호출한다. 도구가 수백 개여도 모델 프롬프트에는 "검색 도구" 하나만 실리고, 각 도구의 스키마는 실제로 쓰기로 정한 순간에만 펼쳐진다 — 그래서 외부 도구를 아무리 많이 꽂아도 모델이 압도되지 않는다.

여러 도구를 동시에 — 병렬 호출, 그런데 왜 "허용"이 필요한가

마지막 조각은 속도다. 외부 도구 호출은 대개 네트워크 왕복이라 느리다. 서로 의존하지 않는 호출까지 순서대로 하나씩 기다리면 전체 턴이 길어진다. 여기서 자연스러운 의문이 든다 — 서로 독립인 호출이면 에이전트가 알아서 동시에 처리하면 되지, 왜 굳이 서버에 설정을 적어야 하나?

핵심은 OpenClaw가 외부 도구를 기본적으로 믿지 않는다는 데 있다. 내가 직접 만든 내장 도구(파일 읽기, 본문 긁기 등)는 동시에 불러도 안전하다고 전제하고 병렬로 돌리지만, 남이 만든 MCP 서버는 동시에 때렸을 때 안전한지를 알 수 없다 — 내부에 공유 상태가 있을 수도, 동시 요청에 레이트리밋을 걸 수도, 애초에 동시성을 고려하지 않고 만들어졌을 수도 있다. 그래서 OpenClaw는 MCP 도구를 기본 순차로 두고, 서버 정의에 supportsParallelToolCalls: true를 적어 사람이 "이 서버는 동시 호출해도 안전하다"고 명시적으로 보증할 때만 병렬 실행을 연다. 이 한 줄은 단순한 참고용 힌트가 아니라 그 서버 도구의 실행 모드 자체를 순차에서 병렬로 바꾸는 스위치다.

실행 루프에는 한 가지 더 엄격한 규칙이 있다. 에이전트가 한 턴에 낸 도구 호출들 가운데 순차로 표시된 도구가 하나라도 섞이면, 그 턴의 호출이 전부 순차로 떨어진다. 병렬 허용 도구 두 개와 플래그를 안 켠 MCP 도구 하나를 같이 부르면, 안전한 두 개까지 덩달아 한 줄로 줄을 선다. "안전이 보장된 것만 골라 병렬로"가 아니라 "하나라도 미보증이면 전부 보수적으로"가 기본값인 셈이다.

다이어그램 설명. 이 그림은 한 턴의 도구 호출들을 동시에 돌릴지 결정하는 분기를 보여준다. 호출 묶음에 순차로 표시된 도구가 단 하나라도 있으면 전체가 한 건씩 차례로 실행되고, 묶음 전체가 병렬 허용일 때만 동시 실행 경로로 간다. 미보증 MCP 도구는 기본이 순차이므로, 그런 도구 하나가 끼는 순간 같은 턴의 안전한 호출들까지 직렬화된다. 놓치기 쉬운 함정이 여기다 — 외부 도구 하나를 무심코 끼워 넣으면, 병렬로 빠르게 끝났을 턴이 통째로 느려질 수 있다.

그러면 플래그를 제대로 켜 둔 서버들로 턴을 채우면 무엇이 빨라지는가. 서로 다른 외부 시스템 세 곳을 한 번에 조회해 종합하는 작업을 보자.

다이어그램 설명. 이 그림은 서로 의존하지 않는 외부 도구 호출 세 건이 병렬로 처리되는 모습을 보여준다 — 단, 세 호출에 해당하는 서버가 모두 병렬 허용으로 보증돼 있을 때의 이야기다. 한 턴에서 세 호출이 동시에 나가고, 셋 모두 끝나 결과가 모이면 다음 판단으로 넘어간다 — 순서대로 기다렸을 세 번의 네트워크 왕복이 가장 느린 한 건으로 줄어든다. 그래서 무슨 가치인가 — 외부 시스템을 여럿 엮는 작업(여러 곳을 동시에 조회해 종합하기)에서 체감 지연이 크게 줄어든다.

비교를 위해 짚자면, 클로드 코드 같은 코딩 에이전트도 의존 없는 호출은 기본으로 병렬화한다 — 다만 그건 자기 자신의 1차 도구를 신뢰하기 때문이다. OpenClaw도 내장 도구에 대해선 똑같이 병렬이 기본이다. 둘의 진짜 차이는 "믿을 수 없는 외부 MCP 서버를 동시에 호출해도 되는가"라는 신뢰 경계를 어디에 긋느냐인데, OpenClaw는 이걸 서버 단위의 명시적 옵트인으로 못 박았다. 능력(외부 도구)은 얼마든지 늘리되, 그 능력을 동시에 휘두를 권한은 사람이 서버마다 따로 허락하게 한 것이다.

결과 — 도구 통합이 "코드 작성"에서 "서버 등록"으로 바뀐다

MCP 도구 호출 능력이 에이전트에게 주는 가치는 결국 새 능력을 붙이는 비용이 한 줄의 등록 명령으로 줄어든다는 데 있다. 외부 시스템에 MCP 서버가 이미 있으면(요즘은 GitHub·파일시스템·메모리·각종 SaaS에 공개 MCP 서버가 흔하다), OpenClaw에서는 openclaw mcp add로 등록하고 필요하면 도구 필터로 좁히기만 하면 된다 — 그 시스템을 부르는 어댑터 코드를 한 줄도 쓰지 않는다.

• 사람에게: 어시스턴트에 새 능력을 붙이는 일이 코딩 프로젝트가 아니라 설정 한 번으로 끝난다. 도구가 많아져도 검색으로 다루고, 위험한 도구는 필터로 숨긴다.
• 에이전트에게: 내장 도구든 남이 만든 MCP 도구든 똑같은 방식으로 호출한다 — 출처를 신경 쓸 필요 없이 "할 수 있는 일의 목록"이 늘어날 뿐이다.
• 시스템에게: 외부 도구 호출도 OpenClaw의 권한·승인·로깅 정책을 그대로 통과하므로, 능력이 늘어도 통제선은 한곳에 유지된다.

정리하면, MCP는 "외부 시스템마다 도구를 손으로 만드는" 끝없는 노동을 "서버를 표준 규약으로 꽂는" 일로 바꾼다. OpenClaw는 그 꽂힌 도구를 에이전트의 도구 카탈로그에 투영하고, 너무 많아지면 필터·검색으로 다루고, 독립 호출은 병렬로 빠르게 처리하며, 망가진 서버는 격리한다 — 능력은 늘리되 비용과 위험은 한곳에 묶어 두는 설계다.

---

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