리포지터리마다 20개의 MCP 구성이 아니라, 모든 에이전트에 하나의 엔드포인트를.

배경

이 플랫폼 팀은 십수 개의 제품 스쿼드에 걸쳐 약 예순 명의 엔지니어를 지원했다. MCP를 도입한 한 해 동안, 각 스쿼드는 필요한 서버 — GitHub, Postgres, Linear, Sentry, 그리고 사내 배포 도구 — 를 저마다 Claude Code와 Cursor 구성에 직접 연결해 왔다. 모든 리포지터리가 저마다의 mcp.json을 지녔고, 새 도구 하나를 도입하려면 그것을 필요로 하는 모든 프로젝트에 풀 리퀘스트를 올려야 했다.

이 방식은 그럭저럭 작동했으나 규모를 감당하지 못했다. 스무 남짓의 서버가 이제 수십 개의 구성 파일에 중복되었고, 버전은 조금씩 어긋났으며, 자격 증명은 처음 구성한 이가 붙여 넣은 그대로 곳곳에 남아 있었다.

과제

다음 세 가지 문제가 회고 때마다 거듭 떠올랐다.

• 구성의 난립. 서버 하나를 추가하거나 갱신하려면 모든 리포지터리를 건드려야 했다. 구성은 점차 어긋났고, 어느 스쿼드가 어떤 도구를 가졌는지 확신하며 말할 수 있는 사람은 없었다.
• 자격 증명의 잘못된 위치. 개인 액세스 토큰과 API 키가 개발자 기기에 흩어졌고, 때로는 커밋된 구성에까지 섞여 들었다. 유출된 토큰을 교체하는 일은 그야말로 보물찾기와 같았다.
• 혼잡한 컨텍스트 창. 모든 MCP 서버는 요청마다 자신의 도구 스키마 전체를 프롬프트에 밀어 넣는다. 스무 개의 서버가 연결된 상태에서 에이전트는 실제 과제의 첫 줄을 보기도 전에 컨텍스트의 상당 부분을 도구 정의에 소진하고 있었다.

접근

팀은 단일 onemcp 포털을 세우고, 서버를 한 번만 그곳에 추가한 뒤 각 상위 서버를 그 자리에서 인증했다. 각 클라이언트가 모든 서버와 개별로 통신하는 대신, 클라이언트는 포털과 통신하고 포털이 각 상위 서버로 분배한다.

문제의 양상을 바꾼 것은 다음 두 가지였다.

• 하나의 엔드포인트가 여럿을 대체한다. 리포지터리는 더 이상 서버를 나열하지 않는다. Claude Code나 Cursor를 포털 URL로 향하게 하면 엄선된 도구 전체를 물려받는다. 서버의 교체나 갱신은 포털에서 한 번 수행하면 된다.
• Code Mode가 정의의 벽을 대체한다. 포털은 모든 도구 스키마를 미리 주입하는 대신 세 개의 메타 도구 — search, describe, execute — 만 노출한다. 에이전트는 과제에 필요한 소수의 도구를 스스로 발견하고, 한 번의 왕복으로 단일 스크립트에서 호출한다.

전개

이관은 스쿼드 단위로 두 주에 걸쳐 진행되었다. 각 리포지터리에서 팀은 로컬 서버 목록을 지우고 단일 포털 항목을 넣었다. 자격 증명은 포털이 보관하므로, 개발자들은 그 과정에서 자신의 기기에서 토큰을 함께 제거했다.

플랫폼 팀은 포털을 유일한 통제 지점으로 유지했다. 새 서버는 중앙에서 검토를 거쳐 추가되었고, 접근 권한 또한 수십 개의 mcp.json에 흩어지는 대신 한곳에서 관리되었다.

성과

• 20여 개의 서버가 단일 엔드포인트 뒤로. 각 리포지터리는 동일한 포털 URL을 참조한다. 도구를 추가하는 일은 포털의 변경이지, 전사적 풀 리퀘스트가 아니다.
• 요청당 도구 부담 약 90% 절감. 수백 개의 사전 적재 정의를 세 개의 메타 도구로 대체함으로써, 요청당 도구 부담은 약 15,000 토큰에서 약 500 토큰으로 낮아졌다 — 에이전트는 그 컨텍스트를 과제 자체에 쓴다.
• 자격 증명은 호스트 측으로. 상위 OAuth와 토큰은 포털 안에 머무르며, 클라이언트 구성에도 커밋된 파일에도 결코 들어가지 않는다. 교체는 한곳에서 한 번의 갱신으로 끝난다.

우리는 더 이상 풀 리퀘스트로 MCP 구성을 배포하지 않습니다. 이제 리포지터리는 하나의 엔드포인트만 가리키면 모든 도구를 얻고, 토큰은 우리가 아니라 보안 팀이 관리합니다.

관련 사례 연구

• 어느 AI 지원 에이전트의 토큰 다이어트
• 자격 증명을 흘리지 않고 셀프서비스 데이터 에이전트를 구현하기