MCP 통합 (MCP Integration)

상황

에이전트(코딩 어시스턴트, 자율 루프)가 회사 지식이나 외부 도구를 써야 하는데, 붙일 때마다 서버마다 접속 방법·토큰·규격이 제각각이면 관리가 감당이 안 됩니다. 백엔드가 늘어날수록 "여기서는 이렇게, 저기서는 저렇게" 접속해야 해서, 어느 순간 엔드포인트가 수십 개로 흩어져요.

우리는 이 문제를 MCP(Model Context Protocol) + 중앙 게이트웨이로 풀었습니다. 도구·지식을 표준 MCP 서버로 열고, 클라이언트는 게이트웨이 엔드포인트 하나만 알면 모든 백엔드에 접근하게 만든 거예요.

질문

여러 지식·도구 백엔드를 에이전트에 붙일 때, 접속을 단일화하고 관리도 쉽게 만들려면 어떻게 해야 할까?

설명

MCP는 클라이언트와 서버(도구/지식 제공자) 사이를 연결하는 표준 프로토콜이에요. 핵심 아이디어는:

각 제공자(위키, Google Drive, 문서…)를 MCP 서버로 감싼다. 서버는 "이런 도구가 있다"를 tools/list로 알리고, 실제 동작은 namespace__tool처럼 규격화된 이름으로 노출한다.
클라이언트는 서버마다 개별 접속하지 않고 중앙 게이트웨이에 붙는다. 게이트웨이가 여러 백엔드를 등록·관리하고, 클라이언트는 게이트웨이 주소와 토큰만 가진다.
그래서 "백엔드 하나 추가"는 클라이언트 코드 수정 없이 게이트웨이에 등록만 하면 끝나요. 접속 대상이 늘어나도 클라이언트 관점에선 여전히 하나예요.

이 구조가 주는 이점은 세 가지예요.

접속 단일화 — 클라이언트는 게이트웨이 엔드포인트 1개만 알면 되고, 백엔드별 개별 접속·토큰 관리가 사라진다.
인증·확장성 중앙화 — 토큰 같은 비밀을 게이트웨이에서 한 번 관리하고, 백엔드를 등록하기만 하면 즉시 노출된다.
표준화 — 도구 이름을 namespace__tool 규격으로 통일해, 클라이언트는 규격만 알면 새 도구도 바로 쓸 수 있다.

주의할 점: MCP는 '어떤 프로토콜로 연결할지'만 표준이고, 백엔드별 인증·네트워크 경로는 여전히 제가 챙겨야 해요. 예를 들어 공개 도메인이 Cloudflare 같은 WAF에 막힌다면(브라우저 시그니처만 허용) CLI/에이전트 접근은 tailnet 같은 사설 경로로 우회하는 게 안정적입니다.

예시

구조를 그림으로 보면 이렇습니다.

클라이언트(에이전트/코딩 어시스턴트)
   │  Bearer 토큰 · Streamable HTTP  <-- 단일 엔드포인트
   ▼
[MCP 게이트웨이]  (백엔드 등록·인증 관리)
   │
   ├─ company-wiki   (위키·드라이브 지식)   tools=5
   ├─ cloudflare-docs (외부 문서)          tools=2
   └─ … (백엔드 추가 시 여기 등록만)

게이트웨이에 백엔드를 등록하면 그 아래 도구들이 company_wiki__search_company_knowledge처럼 네임스페이스__도구 규격으로 드러납니다.

백엔드 등록  →  ACTIVE  ·  discoveredTools=5  ·  message="connected"
도구 노출    →  company_wiki__search_company_knowledge 등 5종 (tools/list 확인)
실검색      →  질문 → 유사도 점수 높은 지식 반환 (예: score 3.1)

확인

클라이언트가 게이트웨이 엔드포인트 1개로만 접근하는지 (백엔드별 개별 접속 없음)
백엔드 추가가 코드 수정 없이 등록만으로 동작하는지
tools/list 로 도구가 규격(namespace__tool)대로 노출되는지
실제 검색이 end-to-end 로 값(response)을 돌려주는지
공개 도메인이 WAF에 막히면 사설 경로(tailnet)로 우회할지 결정돼 있는지

참고: MCP는 '표준'일 뿐이라, 각 백엔드 접근 권한·인증·네트워크 안정성은 게이트웨이 운영 책임으로 남아요. 백엔드 상태도 주기적으로 점검하는 걸 권장합니다.