MCP 서버는 새로운 마이크로서비스 스프롤이다 (우리는 같은 실수를 반복하고 있다)

Source: Dev.to

2016년을 기억하나요?

모든 팀이 그들의 모놀리스를 47개의 마이크로서비스로 만들어야 한다고 결정했을 때?
그리고 2년 후, 모두가 “아마도 마이크로서비스가 필요 없었을지도 몰라” 라는 제목의 블로그 글을 쓰면서 조용히 플랫폼 팀을 고용해 혼란을 정리하고 있었나요?

그래요. 우리는 다시 하고 있습니다. 이번엔 MCP 서버입니다.

우리가 계속 반복하는 패턴

우리 업계에서 매번 이렇게 진행됩니다:

1. 새로운 것이 등장한다.
2. 새로운 것이 실제로 유용하다.
3. 새로운 것을 쉽게 구축할 수 있다.
4. 모든 개발자가 하나씩 만든다.
5. 아무도 이를 추적하지 않는다.
6. 아무도 이를 관리하지 않는다.

18개월 후, “플랫폼”이라는 직함을 가진 누군가가 이를 정리하기 위해 고용됩니다.

• 컨테이너
• 마이크로서비스
• 람다
• 쿠버네티스 클러스터
• MCP 서버

Model Context Protocol (MCP) 은 AI 에이전트가 외부 도구 및 데이터 소스와 통신하는 표준 방식이 되었습니다. Anthropic이 오픈소스로 공개했으며, Google은 12월에 관리형 MCP 서버를 출시했고, 리눅스 재단은 이를 중심으로 Agentic AI Foundation 을 설립했습니다. 이것은 실제이며, 사라지지 않을 것입니다.

하지만 채택 곡선이 관리 곡선을 한참 앞서고 있습니다. 그리고 이 업계에 오래 몸담아 왔다면, 그 의미가 정확히 무엇인지 알 수 있습니다.

숫자는 이미 보기 흉합니다

• 비공식 레지스트리(예: mcp.so)는 16 000개가 넘는 MCP 서버를 색인합니다.
• GitHub에는 20 000개가 넘는 MCP 구현 리포지토리가 있을 것으로 추정됩니다.
• 그리고 이것은 공개된 부분에 불과합니다.

기업 내부는?

상황은 더 악화됩니다. 개발자는 몇 분 안에 MCP 서버를 띄울 수 있는데, 이는 다음과 같은 문제를 초래합니다:

• 단편화 – 서버가 팀과 프로젝트 전반에 흩어져 있습니다.
• 중앙 카탈로그 부재 – 단일 진실의 원천이 없습니다.
• 인증 방식 불일치 – 각 인스턴스가 서로 다른 인증 방식을 사용할 수 있습니다.
• 가시성 제로 – 실제로 무엇이 실행 중인지 파악하기 어렵습니다.

우려되는 통계: 5 200개 이상의 오픈소스 MCP 서버 구현을 대규모 분석한 결과, **88 %**가 작동에 자격 증명이 필요함을 확인했습니다.

• 그 중 **53 %**는 환경 변수에 저장되거나 솔직히 말해 설정 파일에 하드코딩된 장기 정적 비밀(API 키, 개인 액세스 토큰)에 의존하고 있습니다.
• **8.5 %**만이 OAuth를 사용하고 있습니다.

그것은 보안 자세가 아니라 향후 사고 보고서의 집합에 불과합니다.

“하지만 그저 프로토콜일 뿐이야”

“MCP는 그저 프로토콜일 뿐이다. 괜찮아.”

물론—HTTP도 그저 프로토콜일 뿐이고, 우리는 사람들이 그것을 부주의하게 사용한다는 사실을 기반으로 전체 보안 도구 카테고리를 만들었다.

• MCP는 인증을 해결하지 않는다.
• MCP는 신원 관리를 해결하지 않는다.
• MCP는 감사 로그, 가시성, 규정 준수, 속도 제한, 오류 처리를 제공하지 않는다.

그것은 서버와 클라이언트가 어떻게 통신하는지만을 설명한다. 나머지는 전부 여러분의 문제다.

지금 대부분의 조직은 그 “나머지”를 다른 사람의 일로 여기고 있다. 보안 팀은 존재조차 모르는 것을 모니터링할 수 없으며, 많은 기업은 내부 MCP 레지스트리조차 가지고 있지 않다—내게는 이것이 최소한의 기본이라고 생각한다.

실제로 무슨 일이 일어날까?

1. 섀도우 MCP – 개발자들이 IT 부서가 전혀 알지 못하는 서버를 도입한다. 처음엔 잘 동작한다—하지만 문제가 생기면 보안 팀은 그 서버가 무엇에 접근하는지, 누가 소유했는지, 어떤 자격 증명을 가지고 있는지 전혀 알 수 없다.
2. 서버 스프롤 – 여러 팀이 동일한 API를 위해 약간씩 다른 MCP 서버를 만든다. 오래된 서버는 폐기되지 않고, 공격 표면은 마치 벽 뒤 곰팡이처럼 조용히 확대된다.

익숙하지? 그래야 한다. 우리는 2018년 마이크로서비스와 2020년 쿠버네티스 네임스페이스에 대해 똑같은 대화를 나눈 적이 있다.

실제 취약점, 지금 바로

이것은 이론적인 것이 아닙니다. 연구원들은 이미 Microsoft와 Anthropic의 서버를 포함한 가장 인기 있는 MCP 서버들에서 심각한 취약점을 발견했습니다.

• 경로 검증 우회
• 임의 파일 덮어쓰기
• 클라우드 메타데이터 서비스를 통한 자격 증명 노출
• 여러 중간 심각도 이슈를 연결하여 전체 원격 코드 실행 달성

이것들은 특이한 제로데이가 아닙니다. 적절한 거버넌스 없이 빠르게 진행한 결과로 예측 가능한 버그이며, 급하게 배포된 마이크로서비스에서도 나타나는 버그와 동일합니다.

실제로 해야 할 일

저는 “MCP는 나쁘니 사용하지 마라”라고 말하려는 것이 아닙니다. MCP는 실제로 유용합니다—우리 팀도 사용하고 있으며, 프로토콜 자체도 견고합니다. 문제는 그 주변의 운영 모델에 있습니다.

규모에 상관없이 MCP를 도입한다면, 제가 제시하는 짧은 목록을 참고하세요:

1. 내부 레지스트리 구축

조직 내에 어떤 MCP 서버가 존재하는지 모르면, 이를 보호할 수 없습니다.

• 간단히 시작: 소유자, 목적, 권한, 최종 검토 날짜를 포함한 스프레드시트.
• 목표: 자동화된 탐지로 발전시키기.

2. OAuth 2.1 표준화

정적 API 키를 사용하고 있는 서버가 53 %에 달하는데, 이들은 중단해야 합니다.

• 짧은 수명의 토큰, 사용자‑대면 앱에는 PKCE, 서비스 계정에는 상호 TLS 사용.
• 이는 이미 해결된 작업이며, 실제로 실행하기만 하면 됩니다.

3. 게이트웨이 배포

MCP 게이트웨이는 API 게이트웨이와 동일한 패턴을 따릅니다—단일 진입점, 중앙 집중식 정책 적용, 일관된 로깅.

• 혼란스러운 다중 서버 토폴로지를 실제 운영 가능한 형태로 전환합니다.
• 마이크로서비스 시대에서 배운 교훈은 더 많은 서비스를 도입하기 전에 제어 평면이 필요하다는 것입니다.

4. MCP 서버를 실험이 아닌 인프라로 취급

MCP 서버가 프로덕션 데이터를 다루게 되는 순간, 그것은 인프라입니다.

• 소유자, 수명 주기, 그리고 폐기 계획이 필요합니다.
• “금방 하나만 만들게”라는 사고방식은 관리되지 않은 200개의 엔드포인트와 답변할 수 없는 질문을 하는 SOC 2 감사인으로 이어집니다.

아무도 듣고 싶어 하지 않는 부분

Gartner는 2027년까지 에이전트형 AI 프로젝트의 40 %가 실패할 것이라고 예측합니다—기술 자체가 작동하지 않아서가 아니라, 조직이 결함이 있는 프로세스를 자동화하고 있기 때문입니다. MCP 확산은 바로 그 문제의 증상입니다.

우리는 기술을 먼저 도입하고 운영 방식을 나중에 고민하는 방식을 계속 반복하고 있습니다. 그리고 매번 상황이 복잡해질 때마다 놀라워합니다. 마이크로서비스는 분산 시스템에 중앙 집중식 거버넌스가 필요하다는 것을 우리에게 가르쳐 주었습니다. MCP도 분산 시스템이므로 이 교훈이 적용됩니다.

이것을 제대로 이해한 조직은 가장 많은 MCP 서버를 보유한 조직이 아니라, 실제로 자신이 몇 대의 서버를 가지고 있는지 아는 조직일 것입니다.