안녕하세요, 에이블리 DevOps 엔지니어 김세환입니다.

에이블리는 올해 초부터 Claude Code 같은 코딩 에이전트를 전사 구성원에게 지원하기 시작했습니다. 그 과정에서 사내 AI 인프라도 하나씩 쌓아 왔는데요. 대표적으로 LLM 게이트웨이, MCP(Model Context Protocol) 게이트웨이, 에이전트 실행 환경(샌드박스) 등이 있습니다.

돌아보면 그중 도입 효과가 가장 컸던 것은 MCP 게이트웨이였습니다. 지금 에이블리에서는 새로 합류한 구성원이 사내 MCP를 쓰기 시작하기까지 5분이 채 걸리지 않습니다. 개발 직군이 아니어도, 어떤 코딩 에이전트를 쓰더라도 마찬가지입니다.

물론 처음부터 이렇지는 않았습니다. 각자 알아서 설정하고 사용하며 시행착오를 겪던 시기를 지나, 지금은 전사가 MCP 게이트웨이 하나로 MCP를 쓰고 있는데, 이 글에서는 그 과정에서 겪은 문제와 해결해 나간 경험을 공유하고자 합니다.

MCP 요청의 등장

코딩 에이전트를 전사에 지원한 이후로 이런 요청이 들어오기 시작했습니다.

• BI(Business Intelligence) 도구를 에이전트에서 실행하고 싶어요.
• 쿼리 도구와 엔진(Trino, StarRocks)을 에이전트에서 실행하고 싶어요.
• 개발 직군이 아니어도 쓸 수 있나요?
• 이런이런 MCP 사용해도 되나요?

초기에는 전사에서 공통으로 제공하는 MCP가 없었기 때문에, 구성원이나 팀이 필요한 MCP를 직접 찾아 각자 설정해서 사용했습니다. 그러다 보니 어떤 MCP를 쓸지부터 어떻게 설정해서 사용할지까지 개인과 팀별로 파편화 되기 시작했습니다.

그러다보니 같은 MCP인데도 누구는 되고 누구는 안 되는 일이 생겼고, 새로 합류했거나 AI 도구를 처음 사용하는 구성원은 기존 설정을 처음부터 따라가야 했습니다. 특히 파일을 직접 열어 설정하는 방식이나, 터미널에 명령어를 입력하여 설정하는 방식은 개발 직군이 아닌 구성원에게는 그 자체가 허들이었습니다.

관리되지 않은 MCP를 각자 사용하는 방식은 보안 측면에서도 우려가 있었습니다. 어떤 MCP가 사용되고 있는지 중앙에서 파악하기 어려웠고, 인증에 사용하는 토큰을 개인 장비에 저장해 호출하는 경우도 있었습니다. 검증되지 않은 MCP를 사용할 가능성까지 고려하면, MCP가 늘어날수록 개인의 설정에 맡겨두기 어려운 구조였습니다.

조직 규모가 작거나 쓰는 MCP 서버가 몇 개뿐이라면 이렇게 써도 큰 문제가 없습니다. 하지만 쓰려는 MCP가 늘어나고 전사 표준과 거버넌스가 필요해지는 시점부터 문제가 드러납니다. 이런 운영 문제를 해결하고 보안 위험을 줄이려면, 전사에 제공할 MCP를 중앙에서 검토하고 관리할 수 있어야 합니다.

그래서 DevOps/인프라 조직이 먼저 검토한 MCP만 MCP 게이트웨이에 등록해 제공하고, 사내에서 만든 MCP는 각자의 머신이 아닌 공통 인프라에 띄우기로 했습니다.

구성원은 그렇게 모인 서버들을 엔드포인트 하나로만 호출하면 됩니다. 누가 어떤 tool을 썼는지는 감사 로그로 한곳에 남고, 누구에게 어떤 MCP 서버를 열어줄지는 중앙에서 정합니다.

이런 구조를 MCP 페더레이션(federation) 패턴, 또는 MCP 게이트웨이라고 부릅니다.

오픈소스 MCP 게이트웨이 도입

MCP 게이트웨이를 구현한 여러 오픈소스를 검토한 후, IBM이 공개한 mcp-context-forge를 선택했습니다.

사내 SSO(Single Sign-On) 연동과 함께 쿠버네티스(Kubernetes) 위에 올렸고, 지금 구성은 이렇습니다.

앞에서 정리한 요구사항은 이 구성에서 다음과 같이 채워집니다.

1. 단일 엔드포인트: 여러 MCP 서버를 단일 MCP 서버처럼 쓸 수 있습니다(Virtual Server).
2. 인증의 중앙화: 각 업스트림 MCP의 OAuth 인증을 MCP 게이트웨이가 대신하고, 발급받은 토큰도 MCP 게이트웨이가 암호화해 안전하게 저장하고 관리합니다. 구성원은 업스트림마다 최초 1회 인증하면 되고, 이후 갱신은 MCP 게이트웨이가 알아서 합니다.
3. 큐레이션과 권한: 검토하고 승인한 MCP만 카탈로그에 등록합니다. 그중 어떤 tool과 resource, prompt를 어느 팀에 노출할지는 관리자가 중앙에서 정합니다.
4. 감사 로그: 누가 어떤 tool을 호출했는지 한곳에 남습니다.

왜 mcp-context-forge 를 골랐을까요

후보를 고를 때 중요하게 본 기준은 세 가지입니다.

1. 관리자와 구성원이 함께 쓸 수 있는 관리 UI가 있는지
2. 팀과 역할 기반 접근 제어(RBAC, Role-Based Access Control) 같은 조직 기능이 구현되어 있는지
3. 핵심 기능이 유료 플랜에 묶여 있지 않은 오픈소스인지

세 기준을 모두 만족한 것이 mcp-context-forge입니다.

별도의 엔터프라이즈 플랜 없이 SSO와 RBAC, 감사 로그까지 전부 열려 있었고, 팀 개념과 OAuth 토큰 위임도 이미 구현되어 있었습니다. 여러 업스트림 MCP를 용도별로 묶어 노출하는 Virtual Server 개념도 있어서 큐레이션 요구사항과 정확히 맞아떨어졌습니다.

다만 당시 mcp-context-forge는 1.0.0 정식 릴리스 전이었습니다. 조금만 써봐도 버그와 미완성 기능이 눈에 띄는 상태였습니다. 그럼에도 mcp-context-forge를 선택한 것은 일부 기능을 유료 플랜으로 제공하는 오픈코어가 아닌 오픈소스였기 때문입니다. 부족한 부분은 직접 고치면 된다고 판단했습니다.

막히는 건 직접 고쳐가면서 썼습니다

쓰기 시작하자마자 버그와 부족한 기능을 계속 발견했습니다. 몇 가지만 꼽으면 이렇습니다.

• MCP 게이트웨이 진입점인 Virtual Server에 OAuth 인증이 없었습니다. 도입 당시 쓸 수 있는 인증은 MCP 게이트웨이가 자체 발급하는 정적 API 토큰뿐이었습니다.
• 일부 서비스(GitHub 등)에서 OAuth 토큰 갱신이 실패했습니다. MCP 게이트웨이가 토큰 갱신 응답을 JSON으로만 가정하고 읽었기 때문입니다.
• 사내 구성원 대부분이 받을 viewer 역할에 tool 실행 권한이 아예 없었습니다. 실행을 허용하려면 생성과 수정, 삭제까지 되는 상위 역할을 줘야 했습니다.

선택지는 두 가지였습니다. 이슈를 올려두고 기다리거나, 직접 고치거나.

저희는 후자를 택했습니다. 어차피 사내에서는 fork를 빌드해 쓰고 있었기 때문에, 급한 문제는 fork에서 먼저 고쳐 배포하고 추후 업스트림 PR로 올리는 사이클을 돌렸습니다.

fork에만 고쳐두면 MCP 게이트웨이 버전을 올릴 때마다 같은 수정을 다시 얹어야 하지만 업스트림에 머지되면 다음 버전에는 이미 반영되어 있습니다. 저희가 만난 버그는 같은 오픈소스를 쓰는 다른 조직도 언젠가 마주칠 문제이기도 했기에 고친 김에 프로젝트가 함께 나아가도록 하는 편이 자연스럽다고 생각했습니다.

이때 중요하게 본 기준이 하나 있습니다. 업스트림에 머지될 수 없거나 메인테이너가 납득하기 어려운 변경이라면 저희도 고치지 않는다는 것입니다. 업스트림과 얼라인되지 않은 변경을 fork에 남기는 것은, 다음 버전 업그레이드 때 다시 떠안게 될 기술 부채일 뿐이기 때문입니다.

MCP 게이트웨이 인증은 두 방향입니다

하나는 MCP 클라이언트가 MCP 게이트웨이에 들어올 때의 인증이고, 다른 하나는 MCP 게이트웨이가 업스트림 MCP를 호출할 때의 인증입니다.

진입점에서는 MCP 클라이언트가 사내 IdP(Identity Provider)에서 발급받은 access token을 제시합니다. MCP 게이트웨이는 Virtual Server에 설정된 issuer를 확인하고, OIDC(OpenID Connect) metadata와 JWKS(JSON Web Key Set)로 토큰의 서명을 검증합니다. 검증된 사용자는 MCP 게이트웨이의 사용자·팀 정보와 연결되고, RBAC에 따라 쓸 수 있는 Virtual Server와 tool이 결정됩니다. 이 검증 경로를 구현해 업스트림에 기여한 것이 #3715(링크)입니다.

반대편인 업스트림 인증에서는 구성원이 Slack이나 GitHub 같은 서비스에 최초 한 번 OAuth 동의를 완료합니다. MCP 게이트웨이는 발급받은 access token과 refresh token을 사용자와 업스트림 MCP 단위로 암호화해 저장합니다. 이후 tool 호출에서는 저장된 토큰으로 사용자를 대신해 인증하고, 만료된 토큰은 MCP 게이트웨이가 갱신합니다.

두 인증 경로를 나눈 덕분에 진입점은 사내 SSO와 RBAC로 중앙화하면서도, 업스트림 호출은 공용 계정이 아닌 실제 사용자에게 위임된 권한으로 실행할 수 있습니다. 호출 주체와 대상, 결과는 같은 MCP 게이트웨이 계층의 감사 로그와 메트릭에 남습니다.

MCP 게이트웨이 도입으로 발생한 효과

이제 온보딩은 5분이면 끝납니다

도입 후 몇 달이 지난 지금, 새 구성원은 이렇게 온보딩합니다.

1. MCP 게이트웨이에 사내 SSO로 로그인합니다.
2. 안내된 링크에서 각 업스트림 MCP(Jira, Slack, Notion 등)의 인증을 최초 1회씩 완료합니다.
3. 끝입니다. 이후 토큰 갱신은 MCP 게이트웨이가 알아서 합니다.

앞에서 만든 진입점 OAuth 덕분에, 이 플로우 어디에도 정적 토큰을 발급받아 붙여넣는 단계가 없습니다.

큐레이션한 카탈로그에는 Slack과 Notion, Jira, GitHub, Figma, Datadog 같은 공식 MCP 서버와, Redash나 쿼리 엔진(Trino, StarRocks)처럼 사내 시스템용으로 직접 만들거나 띄운 커스텀 MCP 서버가 섞여 있습니다. 구성원 입장에서는 둘을 구분할 필요가 없습니다. 전부 MCP 게이트웨이 하나에서 나오는 tool이기 때문입니다. 새 MCP를 도입할 때도 관리자가 MCP 게이트웨이에 한 번 등록하면 전 구성원에게 바로 반영됩니다.

에이전트도 같은 MCP 게이트웨이를 활용합니다

이 MCP 게이트웨이는 원래 구성원 각자의 코딩 에이전트를 바라보고 만들었습니다. 그런데 도입하고 보니 쓰임새가 하나 더 있었습니다. 사내에서 직접 만드는 자동화 에이전트입니다.

에이전트를 만들 때 가장 손이 많이 가는 부분이 도구 연결과 인증인데요. MCP 게이트웨이에 이미 큐레이션한 tool과 인증 체계가 쌓여 있으니, 새로 만드는 에이전트는 MCP 게이트웨이에 붙이기만 하면 그 도구들을 그대로 씁니다. 사내 운영을 돕는 DevOps/SRE 에이전트도 실제로 이렇게 만들었습니다.

구성원이 MCP를 쉽게 사용할 수 있도록 만든 인프라가, 결과적으로 에이전트를 만드는 기반까지 되어준 셈입니다.

DevOps Agent는 구성원의 로컬 코딩 에이전트와 같은 MCP 게이트웨이에 연결됩니다. 따라서 에이전트마다 tool 연동을 새로 구현하지 않아도, MCP 게이트웨이에 등록된 사내 MCP tool을 그대로 조합해 쓸 수 있습니다.

구성원이 Slack에서 운영 환경 분석이나 변경을 요청하면, 에이전트는 MCP 게이트웨이에 등록된 모니터링과 클라우드, 협업 도구를 조합해 필요한 정보를 확인하고 코드 수정과 PR 초안 작성까지 이어갑니다. 에이전트마다 도구 연결과 인증을 다시 구현하지 않고도 이미 검증한 tool을 그대로 재사용할 수 있습니다.

기대하지 않았던 효과도 있었습니다.

코딩 에이전트를 갈아타는 비용이 사실상 사라졌습니다. 도구를 바꿔도 MCP 게이트웨이 주소와 본인 인증은 그대로라, 인증 정보를 옮기거나 다시 발급받을 일이 없습니다. 에이전트 도구가 빠르게 바뀌는 요즘, 도구 선택과 인프라를 나눠둔 것이 생각보다 큰 자유를 줬습니다.

마치며

어떤 조직에 필요할까요

다음과 같은 요구가 있다면 MCP 게이트웨이 도입을 검토해볼 만합니다.

• 검증한 MCP만 쓰게 하고 싶은지 : 각자 설정해서 쓰면 지금 누가 어떤 MCP 를 쓰고 있는지부터 알기 어렵습니다.
• Tool 사용 권한을 중앙에서 관리하고 싶은지 : 설정이 개인별로 흩어져 있으면, 권한을 바꿀 때마다 사람이 직접 확인하고 수정해야 합니다.
• 인증 정보와 호출 기록이 한곳에 모여야 하는지 : 개인 머신에 흩어진 시크릿은 관리 범위를 벗어납니다.

이런 요구가 커지고 있다면 MCP 게이트웨이는 단순한 편의 기능이 아니라, 조직의 AI 도구를 일관된 정책 안에서 운영하기 위한 공통 인프라가 될 수 있습니다.

AI 도구는 바뀌어도 운영의 기반은 유지됩니다

MCP 게이트웨이를 운영하며 가장 중요하게 배운 것은 모든 인증과 권한을 하나의 계층으로 모으는 것이 답은 아니라는 점이었습니다. MCP 게이트웨이는 검증한 MCP를 큐레이션하고 공통 진입점과 OAuth 흐름을 제공하되, 실제 자원에 대한 인가는 각 MCP와 뒷단 서비스가 책임을 담당합니다.

각 책임을 가장 잘 판단할 수 있는 계층에 두면서도, 구성원과 에이전트가 MCP를 사용하는 방식은 하나로 통일하는 것. 저희가 MCP 게이트웨이를 통해 만들고자 한 구조는 여기에 가깝습니다.

아직 성숙하지 않은 에이전트와 MCP 생태계에서 어떤 도구와 구현체가 주류로 자리 잡을지는 예측하기 어렵습니다.

하지만 엔터프라이즈 조직에서 필요한 구조는 비교적 분명합니다. 각 MCP는 표준 인증 방식과 자신이 연결한 서비스에 맞는 인가 체계를 책임지고, MCP 게이트웨이는 검증한 MCP를 큐레이션해 구성원과 에이전트에게 같은 방식으로 제공하는 구조입니다. 이 경계를 사내 AI 인프라의 공통 기반으로 만들어두면, 새로운 도구나 에이전트가 등장해도 기존 인증과 운영 정책 안으로 어렵지 않게 흡수할 수 있습니다.

MCP 게이트웨이를 전사 공통 인프라로 만든다는 것은 결국, MCP의 연결과 운영 방식을 통일해 빠르게 변하는 AI 도구들을 에이블리의 기존 보안과 운영 정책 안에 지속적으로 받아들일 수 있는 기반을 만드는 일이었습니다.