들어가며

"우리 서비스, 지금 어떤 상태야?"

AI 에이전트에게 이렇게 물어보신 적 있으신가요? 아마 겉보기에는 그럴듯하지만 실제로 활용하기는 어려운 답이 돌아왔을 겁니다. LLM(large language model, 대규모 언어 모델)은 학습 시점 이후의 정보를 스스로 알 수 없습니다. 현재 우리 클러스터에서 어떤 리소스가 실행 중인지, 어제 배포한 버전이 무엇인지, 관련 내용이 사내 문서 어디에 있는지도 알기 어렵습니다. 모델 자체로는 외부 상태나 사내 데이터에 직접 접근할 수 없기 때문입니다.

이 한계를 보완하는 규격이 MCP(Model Context Protocol)입니다. MCP는 LLM이 필요한 순간에 외부 도구와 데이터에서 컨텍스트를 가져올 수 있도록 합니다. 그래서 사내 시스템의 최신 정보를 활용하려면 필요한 MCP 서버를 만들어 연결하는 방법을 먼저 생각할 수 있습니다.

하지만 실제 환경에서 MCP 서버를 연결하려고 하면 다른 문제가 생깁니다. 사내 데이터에 접근하려면 사내 인증을 거쳐야 하며, 이를 위해서는 사내 인증 체계를 먼저 이해하고 브라우저 콜백 처리, 토큰 캐시, 만료된 토큰의 갱신 로직까지 직접 구현해야 합니다. 실제 MCP 서버 로직은 많지 않더라도, 이를 사내에서 사용할 수 있는 형태로 만드는 데 더 많은 노력이 들어갑니다.

더 큰 문제는 이러한 작업이 팀마다 별도로 반복되고 있었다는 점입니다. 다른 팀이 이미 같은 인증 로직을 구현해 사용하고 있다는 사실을 모른 채, 각 팀이 비슷한 코드를 다시 작성하고 있었습니다. 운영 책임도 각 팀이 그대로 부담해야 했습니다.

이는 각 팀이 개별적으로 대응할 문제가 아니라 플랫폼 차원에서 해결해야 할 문제였습니다. 그래서 반복되는 인증과 운영 부담을 플랫폼에서 대신 처리할 수 있도록 구조를 바꿨습니다. 그렇게 만든 플랫폼이 Flava MCP Hub입니다.

이 글에서는 Flava MCP Hub의 설계를 순서대로 살펴보겠습니다. 내부 구조를 네 개의 층으로 나눈 '4층 배관 모델'부터 MCP 표준과 사내 인증 사이의 간극을 해소한 방법, 오픈소스 Gateway에서 자체 Gateway로 전환한 과정까지 차례로 다룹니다. 마지막으로 플랫폼 운영 이후 확인한 새로운 가치와 앞으로의 방향을 소개하겠습니다.

Flava MCP Hub는 사내 공통 프라이빗 클라우드인 Flava 위에 올라간 전사 공통 MCP 플랫폼입니다. Flava의 배경과 아키텍처는 Flava 소개 글에서 자세히 다루고 있으므로, 이 글에서는 Flava 위에서 MCP를 운영하며 마주한 문제와 이를 해결한 구조에 집중하겠습니다.

사내에서 MCP 활용이 늘어나면서 개별 팀 단위의 운영만으로는 해결하기 어려운 문제가 생기기 시작했습니다.

사내 MCP 운영에서 발생한 네 가지 문제

MCP 서버를 만드는 일 자체보다 어려운 문제는 운영 과정에서 나타났습니다. 각 팀이 필요에 따라 MCP 서버를 만들고 사용하면서 크게 네 가지 문제가 생겼습니다.

첫째, MCP 서버가 통제 없이 사방으로 퍼졌습니다. 팀마다 필요할 때 만들어 쓰다 보니 사내에 어떤 MCP 서버가 있고 어디서 어떤 MCP 서버를 제공하고 있는지 아무도 알지 못했습니다. 이미 만들어 둔 것을 몰라서 똑같은 것을 다시 만드는 일도 생겼습니다.

둘째, 인증이 클라이언트와 서버마다 제각각이었습니다. MCP는 컨텍스트를 전달하는 데는 강력하지만 권한 관리가 빠지면 위험 요인이 될 수 있습니다. 그렇다고 팀마다 인증 로직을 직접 구현하기에는 비용이 너무 컸습니다.

셋째, 사내 인증 체계가 MCP 표준을 따라가지 못했습니다. 이 부분은 뒤에서 'Protocol Gap'이라는 이름으로 따로 자세히 다룹니다.

넷째, 사용 현황을 파악하기 어려웠습니다. 누가 무엇을 얼마나 쓰는지에 관한 데이터가 없으니 무엇을 먼저 지원해야 하는지도 판단할 수 없었습니다.

이 네 가지 문제를 모두 해결하려면 플랫폼이 필요했습니다. Flava MCP Hub는 이러한 필요에서 출발했고, 그 역할을 크게 세 가지로 나눌 수 있습니다.

세 단어로 표현한 Flava MCP Hub

Flava MCP Hub의 역할은 세 가지로 정리할 수 있습니다.

카탈로그: 사내에서 사용할 수 있는 MCP 서버를 한곳에서 확인할 수 있게 합니다.
런타임: MCP 서버의 생성, 배포, 사용 과정을 쉽게 만듭니다.
Gateway: 권한과 접근 제어를 설정하고 인증 흐름을 처리하는 관문 역할을 합니다.

Flava MCP Hub는 이 세 역할을 하나의 플랫폼에서 제공합니다.

숫자로 본 Flava MCP Hub

운영을 시작한 이후 다음과 같은 수치가 쌓였습니다. 사내 카탈로그에서 MCP 서버를 선택하면 1분 안에 연결할 수 있고, 새 MCP 서버도 인증을 갖춘 상태로 5분 안에 배포할 수 있습니다. 현재 플랫폼 위에서 동작하는 MCP 서버는 650개 이상, 사용하는 팀은 200팀 이상이며, 누적 도구 호출 수는 1,150만 건을 넘었습니다. 짧은 시간 안에 사내에서 널리 쓰이는 기반으로 자리 잡은 셈입니다.

4층 배관 모델

이처럼 간단하게 사용할 수 있는 Flava MCP Hub가 내부에서는 어떻게 동작하는지 살펴보겠습니다.

Flava MCP Hub는 앞서 이야기한 네 가지 문제를 '4층 배관 모델'로 해결합니다. 요청이 흐르는 경로를 배관처럼 네 개의 층으로 나누고, 각 층에 필요한 책임을 분리한 구조입니다. 사용자의 요청은 클라이언트에서 시작해 Connector와 Gateway를 거쳐 MCP 서버에 도달합니다.

각 층은 아래에서부터 1층 Connection, 2층 Proxy, 3층 Authorization, 4층 Monitoring으로 구성됩니다. 1층부터 차례로 살펴보겠습니다.

1층 Connection: MCP Connector

1층 Connection에서는 MCP 클라이언트의 요청이 가장 먼저 처리됩니다. 클라이언트는 stdio 방식으로 연결하며, 설정 한 줄로 Connector에 연결할 수 있습니다. 이때 Connector는 OIDC(OpenID Connect) 흐름 처리, 토큰 캐시, 만료 시 자동 갱신, Bearer 헤더 주입처럼 사내 인증에 필요한 복잡한 처리를 대신 수행합니다.

클라이언트는 사내 인증 과정을 직접 인식하지 않아도 일반적인 MCP 서버에 연결하듯 사용할 수 있습니다. 이 구조가 어떻게 가능한지는 Protocol Gap 해소하기에서 자세히 설명하겠습니다.

2층 Proxy: MCP Gateway

2층 Proxy에서는 Connector가 받은 요청을 실제 MCP 서버로 전달하기 전에, 어떤 정책에 따라 어느 MCP 서버로 보낼지 결정합니다.

핵심 컴포넌트는 MCP Gateway입니다. 각 팀이 MCP 서버를 배포하면 Gateway가 해당 서버의 앞단에서 동작하고, CORS(cross-origin resource sharing), 헤더 변환, 전송 프로토콜 처리를 공통 규약에 따라 표준화합니다.

따라서 각 팀은 프로토콜 처리를 직접 구현하지 않고 MCP 서버 로직에 집중할 수 있습니다. 예전에는 팀마다 이를 각자 구현해야 했지만, 이제는 이러한 중복 처리가 Gateway 한 층으로 통합됐습니다.

3층 Authorization에서는 Gateway가 요청을 받으면 가장 먼저 토큰을 검사합니다. 이 토큰은 1층 Connection에서 Connector가 브라우저 기반 인증 흐름을 거쳐 받은 것이며, Gateway는 이를 받아 사내의 여러 인증 방식을 한곳에서 검증합니다.

예전에는 MCP 서버마다 인증 코드를 따로 작성해야 했지만, 이제는 Gateway가 검증된 요청만 통과시킵니다. 따라서 MCP 서버는 인증 처리를 직접 담당하지 않아도 됩니다.

4층 Monitoring

4층 Monitoring에서는 클라이언트부터 MCP 서버까지 이어지는 전 구간의 도구 호출과 인증 결과, 지연 시간을 수집합니다. 이를 통해 누가, 언제, 어떤 도구를 호출했는지 한눈에 확인할 수 있습니다.

Flava MCP Hub가 도입되기 전에는 사내 MCP 사용량이 한곳에서 관리되지 않았습니다. 앞서 네 번째 문제로 언급한 부분입니다. 4층 Monitoring을 통해 데이터가 쌓이기 시작했고, 이 데이터는 다음 설계를 위한 기반이 됐습니다.

Protocol Gap 해소하기

사용자는 클라이언트에 설정만 추가하면 Flava MCP Hub의 MCP 서버를 사용할 수 있습니다. 이는 내부에서 Protocol Gap을 해소했기 때문에 가능한 구조입니다. 다음에서는 MCP 표준과 사내 인증 사이의 간극을 어떻게 해소했는지 설명합니다.

MCP 표준과 사내 인증 체계의 불일치

MCP 표준은 클라이언트가 처음 만나는 서버에도 곧바로 연결할 수 있어야 한다는 전제에서 출발합니다. 이를 위해 DCR(dynamic client registration, 동적 클라이언트 등록)이나 CIMD(client ID metadata document, 클라이언트 ID 메타데이터 문서) 같은 방식을 사용합니다.

반면 사내 인증 시스템은 이런 방식을 지원하지 않습니다. IAM(identity and access management, 식별 및 접근 관리) 기반으로 동작하기 때문에 클라이언트가 미리 등록돼 있어야 하고, 토큰도 사내 인증 시스템에서 받아 와야 합니다. 한마디로 처음 보는 클라이언트는 허용하지 않는 구조입니다.

그러니 결과는 둘 중 하나였습니다. MCP 표준을 그대로 따르면 사내 인증 시스템을 사용할 수 없고 사내 인증 시스템에 맞춰 만들면 이번엔 MCP 표준과 맞지 않았습니다. 양쪽 어디에도 맞출 수 없는 이 영역이 바로 Protocol Gap입니다.

이 간극은 실제로 클라이언트와 MCP 서버 사이를 단절시킵니다. 만약 Flava MCP Hub가 없었다면 이 구간을 각 팀이 직접 해결해야 했을 것입니다. 팀마다 MCP 서버 인증을 따로 구현하고 브라우저 콜백을 만들고, 토큰을 캐시하고 갱신해야 했습니다. 결국 똑같은 인증 로직을 각 팀이 다시 작성해야 했던 셈입니다.

또한 그렇게 짠 코드의 운영 책임까지 그대로 각 팀이 감수해야 했습니다. 같은 문제가 사내에서 팀마다 반복해서 발생하는 구조였습니다.

해법은 stdio 프록시 한 겹

해법은 단순했습니다. 끊어진 두 지점 사이에 Connector를 두는 것입니다.

클라이언트 입장에서 Connector는 표준 stdio MCP 서버처럼 보입니다. 클라이언트는 기존 stdio MCP 표준에 맞춰 연결하기만 하면 됩니다.

Connector 내부에서는 사내 인증에 필요한 복잡한 처리를 담당합니다. 사내 OIDC, 브라우저 콜백, 토큰 캐시, 자동 갱신, Bearer 헤더 주입까지 이 한 겹에서 수행합니다. 요청이 Connector를 통과할 때는 이미 인증이 끝난 상태로 MCP 서버를 향합니다.

핵심은 클라이언트가 사내 인증의 존재 자체를 몰라도 된다는 점입니다. Connector는 이런 방식으로 Protocol Gap을 해소합니다.

인증 준비 시간을 1주일에서 5분으로

예전에는 MCP 서버에 인증을 적용하려면 팀마다 사내 인증 체계를 이해하고, 이를 반영한 설계를 따로 해야 했습니다. 내부 추정으로는 이 과정에 대략 1주일 정도가 필요했습니다. 지금은 Connector가 인증 처리를 맡기 때문에 MCP 서버 개발팀은 MCP 서버 로직에만 집중하면 됩니다. 나머지는 Flava MCP Hub가 담당하므로 같은 작업을 5분 안에 마칠 수 있습니다.

Gateway를 직접 만들기로 한 이유

MCP 표준과 사내 인증 사이의 간극을 해소하고 Flava MCP Hub 운영을 시작한 뒤, 다음 과제는 Gateway였습니다. 이 섹션에서는 초기에 도입한 오픈소스 Gateway의 한계와, 이를 자체 Gateway로 전환하게 된 과정을 설명합니다.

오픈소스 Gateway를 선택한 이유

초기에는 Flava MCP Hub의 Gateway를 빠르게 구성하기 위해 오픈소스 프로젝트를 도입했습니다. 당시 개발 기간이 약 2개월로 제한돼 있었기 때문에 Gateway의 모든 기능을 처음부터 직접 구현하기는 현실적으로 어려웠습니다. 이미 검증된 오픈소스 Gateway를 활용해 기본 기능과 구조를 빠르게 확보하는 것이 더 적절한 선택이었습니다.

이 선택은 초기 단계에서 효과가 있었습니다. 이미 해결된 공통 문제를 다시 구현하지 않아도 됐고, 확보한 시간은 Flava MCP Hub에 필요한 요구사항과 연동 부분에 집중하는 데 사용할 수 있었습니다.

운영 과정에서 확인한 한계

하지만 오픈소스 Gateway를 그대로 운영하면서 몇 가지 문제가 생겼습니다.

첫 번째는 언어 스택의 차이였습니다. 팀에는 Go에 익숙한 구성원이 많았지만 해당 오픈소스는 Rust 기반이었습니다. 이는 오픈소스 자체의 문제라기보다 팀 구성과의 적합성 문제에 가까웠습니다. 다만 실제로 장애가 났을 때 원인을 분석하고 디버깅하는 일은 쉽지 않았습니다.

두 번째는 프로젝트의 방향성과 사내 요구사항이 항상 맞지는 않았다는 점입니다. 오픈소스 프로젝트에는 저마다 자체적인 목표와 로드맵이 있습니다. 필요한 기능이나 요구사항을 운영에 필요한 속도로 반영하기는 어려웠습니다.

세 번째는 fork와 패치 관리 부담이었습니다. 사내 인증 시스템에 필요한 변경사항은 upstream 이슈나 PR(pull request)로 처리하거나 별도 fork에서 직접 관리해야 했습니다.

운영 과정에서는 기존 오픈소스를 계속 사용하기 어렵게 만든 구체적인 이슈도 확인됐습니다. 아래 세 가지는 모두 당시 사용하던 버전과 운영 환경에서 발생한 문제입니다.

JWKS 호환성

사내 인증 시스템이 제공하는 JWKS(JSON Web Key Set)에는 ES512 알고리즘을 사용하는 키가 포함돼 있었습니다. 당시 사용하던 버전은 이 값을 파싱하지 못했고, 실제 토큰 검증에 해당 키를 사용하지 않더라도 JWKS를 로딩하는 단계에서 실패했습니다. 그 결과 Gateway 자체가 동작하지 않았습니다.

미들웨어 실행 순서

CORS와 인증 미들웨어의 실행 순서도 문제가 됐습니다. 인증 미들웨어가 CORS보다 먼저 동작하면서, 인증을 켜면 브라우저의 preflight 요청이 CORS 헤더를 받기 전에 거절됐습니다.

메모리 안정성

MCP 트래픽을 처리하는 과정에서 Gateway가 자주 OOM(out of memory)에 도달했습니다. 이 때문에 그 위에서 운영되는 MCP 서버의 안정성까지 예측하기 어려웠습니다.

이런 문제들이 누적되면서 운영에 필요한 기능을 빠르게 수정하고, 운영 환경에 맞게 제어할 수 있는 자체 Gateway가 필요하다고 판단했습니다.

자체 Gateway 전환으로 얻은 개선 효과

자체 Gateway로 전환하면서 앞서 언급한 문제를 다음과 같이 개선했습니다.

사내 요구사항에 맞춘 설계: Gateway 구조를 사내 요구사항에 맞게 다시 설계했습니다.
핵심 동작의 직접 제어: Gateway의 핵심 동작을 직접 제어할 수 있도록 구현했습니다.
쉬워진 장애 분석: Go 기반으로 다시 구현하면서 팀에 익숙한 언어와 도구로 장애를 분석하고 디버깅할 수 있게 됐습니다.
줄어든 패치 부담: upstream이나 fork에 의존하지 않게 되면서 패치 주기를 짧게 가져가고, 필요한 기능 개선을 빠르게 진행할 수 있었습니다.
향상된 운영 안정성: 이러한 변화가 누적되면서 운영 안정성과 편의성이 함께 높아졌습니다.

오픈소스 활용과 자체 개발 사이의 기준

이번 경험을 통해 오픈소스가 빠르게 시작하기에 좋은 선택이지만, 항상 운영 환경에 맞는 선택은 아닐 수 있다는 점을 배웠습니다. 초기에는 오픈소스를 활용해 개발 시간을 줄이고 기능을 빠르게 검증했습니다. 하지만 오픈소스 프로젝트가 지향하는 목표와 운영 환경에서 필요한 요구사항이 계속 벌어진다면 단순히 fork나 패치로 따라가는 방식은 오히려 운영 부담을 키울 수 있습니다.

특히 최근에는 LLM을 활용한 코드 분석과 개선이 가능해지면서 예전보다 직접 개발하거나 이관하는 부담도 줄어들었습니다. Go로 Gateway를 다시 만드는 과정에서 확인한 부분이기도 합니다.

그렇다고 오픈소스를 무조건 대체해야 한다는 뜻은 아닙니다. 다만 오픈소스의 방향성과 운영 요구사항이 맞지 않는 영역에서는 직접 개발해 사용하는 것이 장기적인 안정성을 높이는 선택이 될 수 있습니다. 결국 중요한 것은 오픈소스 자체가 아니라 운영 요구사항에 맞는 기반을 직접 유지할 수 있는지 여부였습니다.

배관 공사로 드러난 새로운 가치

MCP Hub를 운영하면서 실제로 어떤 가치가 확인됐을까요?

기대했던 가치: 중복 제거와 표준화

처음 기대했던 가치는 플랫폼 효율성이었습니다. 각 팀이 MCP 서버를 직접 만들기 시작하면 연결 방식과 인증 처리, 권한 관리, 운영 방식이 팀마다 반복해서 구현됩니다. Flava MCP Hub는 이 반복 작업을 플랫폼에서 대신 처리하기 위해 만들어졌습니다.

그 결과 각 팀은 더 이상 같은 연동 패턴을 매번 다시 만들 필요가 없고, 사내 인증과 접근 제어도 공통 방식으로 사용할 수 있습니다. 서버의 공개 범위와 소유권, 정책 같은 운영 요소도 일관되게 관리됩니다. 결과적으로 Flava MCP Hub는 새로운 MCP 서버를 만들고 운영하는 비용을 낮추고 각 팀이 MCP를 더 쉽게 도입하도록 돕는 배관 역할을 했습니다.

예상하지 못했던 가치: 전사 AI 도구 사용의 관측 지점

그런데 이 구조를 실제로 운영하면서 예상하지 못했던 가치도 확인할 수 있었습니다. Flava MCP Hub를 통해 여러 MCP 서버가 연결되면서 자연스럽게 모든 도구 호출이 Hub를 거치게 됐습니다. 그러면서 어떤 도구가 실제로 많이 쓰이는지, 어떤 팀의 MCP 서버가 다른 팀에서도 재사용되는지 확인할 수 있게 됐습니다. 이 데이터는 단순한 모니터링을 넘어 플랫폼 의사결정의 근거가 되었습니다. 예를 들어 어떤 기능을 먼저 공식 지원해야 하는지, 어떤 MCP 템플릿을 만들어야 하는지, 어떤 기능이 실제 사용자에게 중요한지를 트래픽 데이터를 기반으로 판단합니다.

처음에는 연결을 쉽게 만들기 위한 구조였지만, 운영을 시작한 뒤에는 전사 AI 도구 사용을 이해하는 관측 지점이 됐습니다.

앞으로 가야 할 길

앞으로의 방향은 MCP 도입 과정에 남아 있는 반복 작업을 더 자동화하는 것입니다. 현재 준비 중인 다섯 가지 방향은 다음과 같습니다.

OpenAPI to MCP: OpenAPI 스펙을 기반으로 기존 API를 MCP 서버로 노출하는 방향입니다.
Internal Auth: 각 팀에서 기존에 구현해 둔 API 인증을 그대로 사용할 수 있도록 하는 방향입니다.
MCP 최신 스펙 대응: MCP는 아직 발전 중인 프로토콜이라 변경이 잦습니다. 2026-07-28 버전에서는 요청마다 프로토콜 버전을 선언하는 방식과 server/discover를 통한 서버 정보 조회가 도입됐습니다. Flava MCP Hub도 이에 맞춰 대응하고 있습니다.
CLI와 skill: 개발자가 실제로 일하는 CLI 환경이나 skill 흐름 안에서도 자연스럽게 사용할 수 있도록 확장하는 방향입니다.
ID-JAG: 여러 시스템 사이에서 필요한 토큰 교환과 권한 위임을 자동화해 더 안전하고 편한 교차 시스템 접근을 제공하는 방향입니다.

목표는 더 많은 팀이 MCP를 만들어 연결하고 재사용할 수 있게 하고, 인증과 운영 부담은 플랫폼이 더 많이 가져가는 것입니다. 이 중 두 가지는 조금 더 자세히 설명하겠습니다.

OpenAPI로 기존 REST API를 MCP 서버로 제공하기

많은 팀에는 이미 REST API가 있습니다. 그런데 AI 에이전트에서 이 API를 사용하려면 지금은 별도의 MCP 서버를 직접 구현하거나 도구를 따로 만들어야 합니다.

OpenAPI to MCP는 이 과정을 줄이는 것을 목표로 합니다. 각 팀 REST API의 OpenAPI 스펙을 기반으로 API 경로와 오퍼레이션을 MCP 도구로 변환하고, 이를 MCP 엔드포인트로 노출합니다. 즉, 기존 REST API를 다시 구현하지 않고도 에이전트가 사용할 수 있는 MCP 서버처럼 제공하는 방식입니다.

이를 통해 MCP 도입 장벽이 크게 낮아지고, 기존의 여러 사내 API를 AI 에이전트와 더 쉽게 연결할 수 있습니다.

ID-JAG로 토큰 교환 자동화하기

다음은 ID-JAG(identity assertion JWT authorization grant)입니다. ID-JAG는 토큰 교환과 권한 위임을 플랫폼에서 자동화하는 것을 목표로 합니다. 지금까지는 MCP 서버를 쓰려면 서버마다 필요한 권한 부여를 위해 동의 화면에서 동의하고, 각 MCP 서버에 필요한 토큰을 각각 발급해 사용해야 했습니다.

ID-JAG가 도입되면 ID-JAG 토큰을 한 번 발급받고, 이를 각 MCP 서버에 필요한 토큰으로 교환해 사용할 수 있습니다. 이 개선으로 MCP 서버마다 OAuth 클라이언트를 등록하고 동의를 받지 않아도 되므로, 사용성이 높아질 것으로 기대하고 있습니다.

마치며

이번 글에서는 사내 MCP 플랫폼이 필요했던 이유, 내부 구조를 네 개의 층으로 나눈 설계, MCP 표준과 사내 인증 사이의 Protocol Gap을 Connector 한 겹으로 해소한 방법, 그리고 오픈소스 Gateway에서 자체 Gateway로 전환한 과정을 소개했습니다.

핵심은 반복되는 연결, 인증, 운영 작업을 Flava MCP Hub가 플랫폼 차원에서 처리하고, 각 팀은 MCP 서버의 로직과 재사용 가치에 더 집중할 수 있게 했다는 점입니다.

읽어주셔서 감사합니다.

Flava MCP Hub가 걸어온 길: AI 시대를 위한 배관 공사

댓글