Custom MCP를 많이 쓸 때 어떻게 관리할까: 여러 MCP 서버 운영 패턴과 Gateway·Profile 전략

MCP 개수보다 중요한 것은 현재 노출되는 tool 수다

MCP를 관리할 때 흔히 “서버를 몇 개까지 연결해도 괜찮을까?”부터 생각하게 됩니다. 하지만 이 숫자만으로는 실제 복잡도를 판단하기 어렵습니다.

MCP 공식 사양에서 tool 하나는 이름만 가지는 것이 아닙니다. name, description, inputSchema 같은 정보를 함께 제공하며, 클라이언트는 tools/list를 통해 이를 발견합니다. 모델은 결국 이런 metadata를 보고 어떤 tool을 호출할지 판단합니다.

그래서 MCP 서버 10개가 각각 두세 개의 명확한 tool만 제공한다면 관리가 어렵지 않을 수 있습니다. 반대로 MCP 하나가 수십 개의 get, list, search, create, update 계열 tool을 한꺼번에 제공하면 서버 수는 하나여도 선택 공간은 훨씬 복잡해집니다.

실제로 Redis가 공개한 MCP tool overload 실험도 모든 tool을 한꺼번에 모델에 제공하는 방식보다, 먼저 관련 tool을 검색한 뒤 필요한 것만 제공하는 방식에서 token 사용량과 선택 효율이 좋아질 수 있음을 보여 줍니다. 특정 실험 수치를 모든 환경에 그대로 적용할 수는 없지만 방향은 이해하기 쉽습니다.

관리해야 할 숫자는 전체 MCP 설치 개수보다 현재 대화에 노출되는 tool의 수와 서로 비슷한 tool의 수에 가깝습니다.

규모가 커질수록 관리 방식도 단계적으로 바뀐다

제가 조사하면서 가장 일관되게 보인 흐름을 대략적인 단계로 정리하면 다음과 같습니다. 아래 개수는 절대 기준이 아니라 어느 시점부터 관리 방식이 바뀌는지 이해하기 위한 예시입니다.

이 구조를 보면 MCP가 많아진다고 곧바로 Gateway부터 설치하는 것이 최선은 아닙니다. 지금 겪고 있는 문제가 무엇인지에 따라 필요한 계층이 다릅니다.

첫 번째 단계는 프로젝트별 scope 분리다

가장 단순하면서 효과가 큰 방법은 모든 MCP를 global로 켜 두지 않는 것입니다.

Claude Code는 이 구조를 공식적으로 local, project, user scope로 나누고 있습니다. 프로젝트에서만 필요한 MCP는 현재 프로젝트에만 로드하고, 팀과 공유할 서버는 프로젝트 루트의 .mcp.json에 저장할 수 있습니다. 반대로 여러 프로젝트에서 계속 사용하는 개인 도구만 user scope에 둘 수 있습니다.

이 방식의 장점은 명확합니다.

개발 프로젝트를 열었을 때 GitHub, 데이터베이스, 배포 관련 MCP만 보이게 하고, 콘텐츠 운영 프로젝트에서는 CMS, 검색, Cloudflare 관련 MCP만 보이게 만들 수 있습니다. 프로젝트와 무관한 tool이 애초에 후보에 들어오지 않습니다.

저라면 MCP가 몇 개 늘어나기 시작했을 때 가장 먼저 이 구조부터 적용합니다. Gateway나 별도 manager를 도입하지 않아도 복잡도가 크게 줄어듭니다.

두 번째 단계는 Profile 또는 Working Set이다

MCP가 더 많아지면 서버를 하나씩 켜고 끄는 것보다 작업 목적별 묶음이 필요해집니다.

예를 들면 다음과 같습니다.

• coding
• research
• content
• production-ops
• personal

Docker MCP Gateway는 이런 개념을 profile로 구현하고 있습니다. profile에는 사용할 MCP 서버들을 묶을 수 있고, 더 중요한 것은 서버 단위뿐 아니라 특정 tool만 활성화하거나 비활성화할 수 있다는 점입니다.

예를 들어 GitHub MCP가 많은 기능을 제공하더라도 production profile에서는 조회에 필요한 tool만 켜고 issue 생성이나 변경 작업은 꺼둘 수 있습니다. 같은 서버를 쓰더라도 개발 profile과 production profile의 권한 표면을 다르게 만들 수 있는 것입니다.

이 단계부터는 MCP를 단순한 연결 목록이 아니라 작업별 capability set으로 보게 됩니다.

여러 클라이언트를 쓰면 Single Source of Truth가 필요하다

또 다른 문제는 ChatGPT, Claude Code, Cursor, Codex 등 여러 환경을 함께 쓰면서 시작됩니다.

MCP 하나를 추가할 때마다 각 클라이언트의 설정 파일을 따로 수정하면 시간이 갈수록 어느 클라이언트에 어떤 MCP가 등록되어 있는지 맞추기 어려워집니다. endpoint가 바뀌거나 인증 방식이 달라졌을 때도 여러 곳을 동시에 고쳐야 합니다.

그래서 이 문제만 해결하는 별도의 config manager도 등장하고 있습니다. 예를 들어 Gaal은 한 설정에서 여러 AI agent의 MCP 구성을 동기화하는 방향을 취합니다.

여기서 중요한 점은 config manager와 MCP Gateway는 다른 문제를 푼다는 것입니다.

설정을 여러 클라이언트에 복사하는 일이 불편하다면 중앙 manifest를 두고 동기화하는 것으로 충분할 수 있습니다. 굳이 네트워크 경로와 runtime까지 Gateway 뒤로 옮길 필요는 없습니다.

Gateway는 언제 필요한가

MCP를 실제 인프라처럼 관리해야 할 정도가 되면 Gateway가 의미를 갖기 시작합니다.

구조는 대략 다음처럼 바뀝니다.

AI Client → MCP Gateway → 여러 MCP Server

Docker MCP Gateway는 여러 MCP 서버의 lifecycle, routing, secrets, OAuth, profile 등을 한 지점에서 관리할 수 있게 합니다. 클라이언트마다 개별 MCP에 직접 연결하는 대신 Gateway 하나를 바라보게 만드는 방식입니다.

이 구조가 특히 유용한 경우는 다음과 같습니다.

• 같은 MCP fleet를 여러 AI 클라이언트에서 공유할 때
• 서버별 secret과 OAuth를 중앙에서 다루고 싶을 때
• production과 development의 tool 허용 범위를 분리하고 싶을 때
• 어떤 tool이 호출됐는지 logging과 audit이 필요할 때
• 서버 실행 환경을 격리하고 싶을 때

하지만 여기에는 중요한 함정이 하나 있습니다.

Gateway 하나로 합쳤다고 tool overload가 해결되는 것은 아니다

예를 들어 MCP 20개를 Gateway 하나 뒤에 연결했다고 가정해 보겠습니다.

클라이언트 설정은 아주 깨끗해집니다. MCP endpoint가 20개에서 하나로 줄어들기 때문입니다. 하지만 Gateway가 뒤쪽 20개 서버의 모든 tool을 그대로 모델에 노출한다면 모델이 보는 tool 수는 거의 그대로입니다.

즉 connection centralization과 tool filtering은 별개의 기능입니다.

그래서 Gateway를 고를 때는 단순히 “여러 MCP를 하나의 endpoint로 합쳐 주는가?”보다 다음 질문이 더 중요합니다.

• profile별로 서버를 제한할 수 있는가
• server 내부에서도 tool allowlist를 만들 수 있는가
• 필요할 때만 tool을 검색해서 가져오는 구조가 있는가
• read와 write capability를 분리할 수 있는가
• secrets를 일반 설정과 분리하는가
• 호출 기록을 남길 수 있는가

Docker의 profile별 tool enable/disable 기능이 중요한 이유도 여기에 있습니다.

보안 때문에도 MCP를 분리해야 한다

MCP가 많아지면 편의성만큼 중요한 것이 trust boundary입니다.

예를 들어 하나의 Cloudflare MCP가 조회부터 production 변경까지 모든 권한을 가지고 있다면 사용하기는 편합니다. 하지만 실제 운영에서는 다음처럼 분리하는 편이 훨씬 관리하기 쉽습니다.

• cloudflare-read
• cloudflare-production-write
• github-dev
• github-production-release
• database-staging
• database-production-read

이름만 보고도 어느 서버가 외부 상태를 바꿀 수 있는지 알 수 있게 하는 것입니다.

MCP 공식 사양도 tool 호출에 적절한 access control, confirmation, logging 같은 안전 장치를 두도록 권고합니다. 조직 규모에서는 인증 자체도 중앙화되는 방향입니다. 2026년 6월에는 MCP의 Enterprise-Managed Authorization 확장이 stable 상태가 되었고, 조직의 IdP를 통해 여러 MCP 서버 접근을 중앙에서 관리하는 구조가 제시됐습니다.

결국 규모가 커질수록 다음 세 가지는 따로 관리하는 편이 좋습니다.

MCP definition ≠ secret ≠ permission

endpoint와 tool 정의를 저장하는 곳, credential을 보관하는 곳, 실제 사용 권한을 결정하는 곳을 같은 설정 파일 하나에 몰아넣지 않는 구조입니다.

MCP Registry는 무엇을 해결하는가

공식 MCP Registry도 등장했지만 이것 역시 Gateway와 역할이 다릅니다.

현재 공식 MCP Registry는 공개적으로 접근 가능한 MCP 서버의 metadata를 표준 형식으로 제공하는 중앙 repository입니다. 서버 이름, 패키지 또는 remote endpoint, 실행 방법, capability 같은 정보를 server.json 형식으로 표현합니다.

다만 공식 Registry는 private MCP 서버를 저장하는 용도가 아닙니다. 공식 문서도 사내망이나 private package registry에 있는 MCP는 별도의 private registry를 사용하도록 안내합니다.

따라서 역할을 나누면 이해가 쉽습니다.

• Registry: 어떤 MCP가 존재하고 어떤 버전인지
• Inventory: 내가 어떤 MCP를 보유하고 있는지
• Profile: 이번 작업에서 무엇을 사용할지
• Gateway: 어떻게 연결·실행·제한할지
• Secret store: credential을 어디에 둘지
• Client: 실제 대화에서 무엇을 호출할지

ChatGPT에서 Custom MCP를 많이 쓰는 경우는 조금 다르다

ChatGPT Web을 중심으로 Custom MCP를 많이 쓰는 경우에는 Claude Code나 Docker와 관리 방식이 조금 다릅니다.

2026년 8월 현재 OpenAI 공식 문서에서 Custom MCP는 ChatGPT의 custom app 형태로 관리됩니다. Business, Enterprise, Edu에서는 developer mode를 통해 MCP app을 만들고 테스트한 뒤 workspace에 publish할 수 있습니다. Enterprise/Edu에서는 RBAC와 action control로 사용자와 action 범위를 더 세밀하게 제어할 수 있습니다.

한 prompt에서 여러 app을 함께 호출하는 것도 가능합니다. 다만 app 선택은 대화 전체가 아니라 해당 메시지에 적용되며, 후속 작업에서 새로운 app action이 필요하면 다시 해당 app을 호출하게 됩니다.

또 하나 운영상 중요한 부분이 있습니다. ChatGPT는 승인된 MCP app의 tool 정의를 그대로 실시간 추종하지 않고 승인된 snapshot을 사용합니다. 서버의 tool 정의가 나중에 바뀌어도 자동으로 적용되지 않습니다. Enterprise/Edu에서는 관리자가 action을 refresh해 변경 사항을 검토할 수 있고, 현재 Business에서는 publish한 app의 tool이나 metadata를 수정하려면 다시 만들어 publish해야 한다고 공식 문서가 안내하고 있습니다.

그리고 ChatGPT는 local MCP 서버에 직접 접속하지 않습니다. private network나 개발 PC에서 실행되는 MCP는 Secure MCP Tunnel 같은 별도 연결 계층이 필요합니다. 이 Tunnel은 연결 문제를 해결하는 기능이지 여러 MCP를 profile로 분류해 주는 fleet manager는 아닙니다.

현재 OpenAI 공식 문서에서는 Claude Code의 local/project/user scope나 Docker의 profile처럼 사용자가 임의의 MCP working set을 저장해 전환하는 기능은 확인하기 어렵습니다. 그래서 ChatGPT Web에서 Custom MCP를 많이 관리한다면 MCP 자체의 이름과 역할 경계를 더 명확하게 만드는 것이 특히 중요합니다.

Custom MCP 승인과 Never ask, OAuth 문제는 이전에 정리한 ChatGPT 예약 작업에서 Custom MCP 승인 줄이는 방법도 함께 보면 연결해서 이해하기 좋습니다.

내가 Custom MCP 10개, 20개, 50개를 관리한다면

제가 직접 구성한다면 숫자가 늘어날수록 다음처럼 바꾸겠습니다.

10개 안팎

별도 Gateway 없이 역할과 이름부터 정리합니다.

local-blog-ops, cloudflare-prod-read, cloudflare-prod-write, github-dev, research-web처럼 서비스 이름보다 역할과 위험도가 드러나는 이름을 사용합니다.

그리고 현재 프로젝트와 관계없는 MCP는 가능하면 활성 작업에서 제외합니다.

20개 안팎

이 정도부터는 별도의 inventory를 하나 둡니다.

각 MCP에 대해 다음 항목을 기록합니다.

• 이름
• 목적
• endpoint 또는 실행 방식
• environment
• read/write 여부
• 인증 방식
• 주요 tool
• 사용 클라이언트
• owner
• 마지막 점검일

여기에 secret 자체를 기록하지는 않습니다.

여러 AI 클라이언트를 동시에 사용한다면 이 시점부터 config를 한 곳에서 관리하고 각 클라이언트 설정으로 동기화하는 방식을 고려할 만합니다.

50개 이상 또는 tool이 수백 개

이 정도가 되면 “모두 연결되어 있다”는 상태 자체가 장점이 아닐 가능성이 큽니다.

coding, content, research, production 같은 profile을 만들고, 각 profile에서 서버와 tool을 allowlist하는 구조가 필요합니다. secrets, logging, OAuth, runtime isolation까지 중앙화할 필요가 있다면 Gateway를 도입할 이유도 충분해집니다.

특히 production profile은 가능한 한 좁게 만드는 것이 좋습니다. 조회와 변경을 분리하고, 실제 작업에 필요하지 않은 destructive tool은 처음부터 모델에게 보이지 않게 하는 편이 관리하기 쉽습니다.

결국 핵심은 MCP를 많이 연결하는 것이 아니다

MCP를 처음 사용할 때는 하나를 연결할 때마다 AI의 능력이 하나씩 늘어나는 느낌이 강합니다. 그래서 자연스럽게 더 많은 MCP를 연결하고 싶어집니다.

하지만 MCP가 충분히 많아진 뒤에는 반대 방향의 관리가 필요합니다.

MCP는 많이 보유하되, AI에게는 지금 필요한 capability만 보여 주는 것.

이 원칙을 기준으로 보면 여러 관리 도구의 역할도 명확해집니다.

설정 중복이 문제라면 config manager가 먼저이고, 작업별 조합이 문제라면 profile이 먼저입니다. 인증과 runtime, audit까지 중앙화해야 할 때 Gateway가 필요해집니다. 그리고 MCP가 아무리 많아져도 가장 중요한 것은 서버 개수가 아니라 현재 모델에게 노출되는 tool과 권한의 범위입니다.

2026년 MCP 생태계를 보면 Registry, Profile, Gateway, Enterprise Authorization 같은 계층이 빠르게 생겨나고 있습니다. MCP 관리가 단순히 JSON 파일 몇 개를 정리하는 문제에서, 점점 작은 플랫폼 운영 문제로 바뀌고 있다는 의미로 보입니다.

참고 자료

• OpenAI: Developer mode and MCP apps in ChatGPT
• Claude Code: Connect Claude Code to tools via MCP
• Docker MCP Gateway: Profiles
• Model Context Protocol: Tools specification
• Model Context Protocol: MCP Registry
• Model Context Protocol: Enterprise-Managed Authorization
• Gaal: MCP configuration sync project
• Redis: Solving the MCP Tool overload problem