top of page

Notification, blog

원격 MCP 시대, 기업은 무엇을 먼저 통제해야 하는가

  • 5일 전
  • 2분 분량

Model Context Protocol, MCP는 이제 실험용 로컬 연결을 넘어 기업 운영 구조 안으로 들어오고 있습니다. GitHub는 2026년 7월 23일 차기 MCP 규격 대응 내용을 공개하며 Stateless Core 전환, 세션 제거, 병렬 핸드셰이크, 공식 적합성 테스트를 강조했습니다. Google도 2026년 7월 7일 Gemini API Managed Agents 업데이트에서 원격 MCP 서버 연결과 백그라운드 실행을 함께 발표했습니다. 흐름을 종합하면, MCP는 더 이상 개인 데모 환경에서만 쓰는 도구 연결 방식이 아니라 원격 서비스와 기업 내부 시스템을 연결하는 운영 표준으로 이동하고 있습니다.


출처. ChatGPT 생성형 이미지
출처. ChatGPT 생성형 이미지

문제는 연결이 쉬워질수록 통제가 더 어려워진다는 점입니다. 로컬 데모 단계에서는 사용자가 직접 어떤 도구를 붙였는지 알고 있지만, 원격 MCP로 확장되면 이야기가 달라집니다. 어떤 사용자가 어떤 MCP 서버에 접근하는지, 개인 계정과 업무 계정이 뒤섞이지 않는지, 에이전트가 호출한 도구와 데이터 접근 이력이 남는지, 서버별 권한 정책이 일관되게 적용되는지 확인해야 합니다. Kong도 2026년 7월 3일 `Enterprise-Grade MCP Access Control Is Here. Your Gateway Makes It Real.`에서 다수의 사용자와 다수의 MCP 서버를 연결할 때 중앙 정책과 통합 감사가 없으면 기업 운영이 빠르게 복잡해진다고 지적했습니다.


기술적으로 보면 Stateless Core 전환은 확장성과 운영 단순화에 유리합니다. 하지만 세션이 줄어든다고 해서 보안과 거버넌스 부담이 줄어드는 것은 아닙니다. 오히려 요청 단위 인증, 헤더 기반 신뢰, 원격 도구별 권한 모델, 서버 목록 관리, 감사 추적 구조를 더 명확히 설계해야 합니다. Google이 원격 MCP 서버를 에이전트 샌드박스에서 직접 연결할 수 있도록 한 것도 생산성을 높이는 변화이지만, 기업 입장에서는 “바로 연결된다”보다 “누가 어떤 범위까지 연결되도록 허용할 것인가”가 더 중요한 질문이 됩니다.


기업 환경에서는 네 가지를 먼저 점검하는 편이 현실적입니다.

첫째, MCP 서버를 API처럼 관리 대상에 포함할 것인가입니다.

둘째, 사용자·서비스·에이전트별 최소 권한 모델을 어떻게 구분할 것인가입니다.

셋째, 원격 MCP 호출 이력을 기존 API·보안 로그와 함께 추적할 수 있는가입니다.

넷째, 실험용 연결과 운영용 연결을 분리해 검증·승인 절차를 둘 것인가입니다.

이 기준이 없으면 MCP는 연결 표준이 아니라 새로운 Shadow IT 경로가 될 수 있습니다.


원격 MCP를 연결 표준으로 쓰기 전에 먼저 확인해야 할 4가지 통제 기준
원격 MCP를 연결 표준으로 쓰기 전에 먼저 확인해야 할 4가지 통제 기준

리티스는 이런 전환 구간에서 API Gateway, AI Gateway, 보안, 모니터링 관점을 함께 묶어 검토할 수 있습니다. MCP 서버를 별도 예외로 둘 것이 아니라 기존 API 운영 원칙 안에서 인증, 권한, 감사, 가시성 기준을 재정의해야 합니다. 이때 `litis API Creator`는 사내 시스템과 서비스를 MCP 또는 API 기반 연계 구조로 정리하고, 필요한 연결 인터페이스를 생성·변환·연계하는 구현 기반으로 활용될 수 있습니다. 리티스는 고객 환경에 맞춰 MCP 연결 구조와 게이트웨이 적용 가능성을 검토하고, `litis API Creator`를 포함한 API 연결 체계를 함께 설계해 향후 에이전트 운영까지 고려한 거버넌스 방향을 제안할 수 있습니다. 원격 MCP 시대에 중요한 것은 연결 자체보다, 그 연결을 기업이 설명 가능하고 통제 가능한 방식으로 운영하는 일입니다.



출처 및 참고자료



bottom of page