MCP – Model Context Protocol 보안 위험

지난 주 Model Context Protocol (MCP)에 대한 글을 올리고 많은 분들이 관심을 가져주셨습니다. MCP를 처음 사용해 보시는 분들을 위해, MCP 서버가 “개인들이 올린것도 많기 때문에 아무거나 설치하거나 사용하면 안되고, 꼼꼼히 따져 보고 보안에 문제가 없는지 잘 살펴보아야 한다“라고 말씀드렸는데요. 하지만, 너무 많은 분들이 소셜 미디어에서 넘쳐나는 무작정 따라하기를 해보시는 것 같아요. 이 글에서 저는 MCP 서버를 본인이 직접 프로그램 코드를 직접 짜거나, 남이 만든 코드라도 검증할 수 있는 분들이 아니라면, 꽤 심각한 보안 위험이 있다는 것을 알려드리고 싶습니다.

◼ 개인용 MCP 서버 보안 취약점
제가 이전 글에서 말씀 드린대로 MCP 서버는 여러분의 컴퓨터에 설치되는 것으로 파일 접근, 리소스 제어 등의 기능을 할 수 있습니다. 따라서, 만약 공격자가 마음만 먹는다면 MCP 도구 설명에 그럴듯하게 적어놓고, 실제 코드에는 공격 코드를 삽입할 수 있습니다. 게다가 MCP 서버 업데이트 기능을 통해 알 수 없는 기능을 업데이트할 수도 있습니다. 문제는 일반인들은 그러한 코드의 실제 위험을 확인하기 어렵다는 것입니다.

게다가 로컬 서버에 설치될 뿐만 아니라 최근에 REST 방식을 이용한 원격 서버와 접속을 허용하는 MCP 서버가 늘고 있습니다. 대부분 API 서비스를 제공하는 서드 파티 제공사의 기능을 활용하기 위해 만든 것들인데, 하이재킹을 통해 가짜 서버로 전송해서 데이터를 탈취할 수도 있습니다. 예를 들어, 커서 AI의 취약점 중에 하나인 add()라는 데이터 설정 파일 변경 기능을 통해 해커가 데이터를 탈취하는 일도 있었습니다.

요즘 대부분 로컬에 설치되는 프로그램은 신뢰된 앱 스토어를 통해 검증된 프로그램만 설치되고 있거나, 특정 샌드박스 안에서만 실행되도록 하는 장치가 내장되어 있습니다. 그러나, MCP 서버의 경우 공개된 프로토콜만 있지, 만들어서 배포되고 있는 프로그램에 대한 검증 장치는 아직 없습니다.

아래는 MCP Servers are not safe! – Data Science in Your Pocket라는 글이 있는 보안 취약점과 해결 방법을 요약한 것입니다.

◼ 개인 MCP 서버 활용 시 유의 사항
만약, 여러분이 이러한 보안 취약점에 대해 걱정을 하시고 있으시다면, 일단 사용하지 않는 것을 장려합니다. MCP 서버가 유용한 점이 분명 있지만, 결국 AI 모델을 보완하는 기능일 뿐, 킬러앱이 있는 것은 아닙니다. 그리고, 가급적 신뢰할 만한 MCP 서버만 설치하시길 바랍니다. 개인이 만든 것은 가급적 피하시고, Smithery에서도 신뢰된 공급사가 제공하는 오렌지 색 ☑️ 가 있는 것들만 다운로드 해서 사용하시길 바랍니다.

혹시라도 개인이 만든 MCP 서버를 사용하게 된다면, 도구 설명을 완전히 신뢰하기 보다는 수행하는 작업과 실제 작업이 같은지 검증해야 합니다. 이상한 동작이 감지된다면 코드를 확인해 볼 필요가 있습니다. MCP 서버가 최소한의 데이터와 리소스에 접근하도록 설정하고, 업데이트 될 때 마다 어떤 부분이 변경되었는지, 지속적인 모니터링이 필요합니다. 따라서, 바로 바로 업데이트하지 말고 신뢰된 버전만 사용하는 것이 좋습니다.

우리가 설치하는 소프트웨어와 역시 똑같은 보안 취약점이 있기 때문에, 이런 언급이 유별나다고 생각하시는 분들도 있을 수 있습니다. 그러나, 한국에서는 과거에도 Active X 같은 기술을 악용한 악성 프로그램에 노출되어 있었고, 그냥 컴퓨터에 무심코 설치하는 버릇에서 사회적인 보안 비용이 높아졌던 경험이 있습니다. 생성형 AI 에이전트를 일반인들도 많이 쓰는 시대에 살고 있기 때문에, 이 부분은 간과해서는 안됩니다.

◼ 기업을 위한 MCP 서버 보안 이슈
기업에서 MCP 서버를 사용할 때 역시 많은 주의 사항이 필요합니다. MCP 서버는 개인이 설치하는 식으로 되어 있기 때문에, 기업 내에서는 중앙에서 MCP 서버를 원격으로 배포하고 권한 부여를 활용하여 리소스 소유자가 데이터에 안전하게 액세스할 수 있는 메커니즘이 부족합니다. 이를 해결하기 위해, MCP 스펙에서 최근 OAuth 2.1을 기반으로 하는 MCP 권한 부여 기능을 도입했습니다만, 여전히 문제가 있습니다.

예를 들어, 이 제안은 MCP 서버를 리소스 서버 및 권한 부여 서버로 함께 취급하기 때문에 기능상 복잡성이 증가하는 문제가 있습니다. 인증 및 권한 부여 위임을 위해 OAuth를 쓰는 경우, 신뢰된 ID 공급자(Auth0, Okta 등)를 통해 수행해야 합니다. 최근에 MCP 인증 스펙 변경을 위한 노력이 진행 중이긴 하지만, MCP 인증 스펙이 좀 더 기업 보안 친화적인 방식으로 바뀌기 전까지는 기업에서 MCP 서버를 직원들이 활용하게 하는 것은 시기 상조로 보입니다.

아래는 The MCP Authorization Spec Is… a Mess for Enterprise라는 글에서 제안한 기업용 MCP 활용을 위한 대안 입니다.

또한, 기업들이 직접 MCP 서버를 일반 사용자에게 배포할 때도 신뢰성을 제공해야 합니다. 앞에서 Smithery의 신뢰된 공급사로 표시되게 하는 방법을 알려드렸지만, 사설 레포지터리 보다는 회사내 공식 홈페이지, 블로그, Github 페이지를 통해 제공하는 것을 권장합니다.

지금까지 이야기한 모든 것은 우리가 잘 알고 있는 보안 상식에 속합니다만, 신기술이 뜰 때 이러한 중요한 부분이 간과되는 것을 많이 보았습니다. 남이 만든 블로그나 가이드를 그냥 맹목적으로 따라하다가, 데이터 유츌이나 과금 문제를 경험하기도 합니다. 따라서, MCP 서버 뿐만 아니라도 여러분의 책임하에 보안 이슈가 없는지 잘 알아보고, 새로운 기술을 활용하시길 권장드립니다.

- ;

Disclaimer- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. 본 채널은 광고를 비롯 어떠한 수익도 창출하지 않습니다. (The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgment on checking facts for your investments and prohibit your citations as commercial content or news sources. This channel does not monetize via any advertising.)

여러분의 생각 (2개)

  1. 조동환 댓글:

    적절한 시점에 잘 지적해주셨다고 생각합니다.
    (XZ Utils 사례에서 볼 수 있듯이) 공급망 해킹을 위해 몇 년간 꾸준한 노력을 기울이는 경우도 있는데(아직 발견되지 않은 Unknown Unknown이 훨씬 더 많지 않을까 하는 두려운 생각도 듭니다) 기업 내 핵심 데이터에 쉽게 접근하기 위해 만들어진 MCP Server의 경우에는 그러한 백도어를 숨기기도 리눅스 커널 라이브러리에 비해서는 훨씬 쉽다고 예상됩니다.
    결국 우리가 가지고 있는 베스트 프랙티스라고 할 수 있는 Zero Trust 관점에서 잘못될 수 있는 모든 경우를 다시 다 따져봐야 한다는 뻔한 이야기(==기본)로 다시 돌아오게 됩니다.
    MCP Specification 자체에도 이러한 관점의 개선이 지속적으로 이루어져야 향후 더 넓게 안심하고 사용될 수 있는 Framework가 되리라고 기대합니다. 이미 그러한 공감대는 충분히 있다고 보이는데 그 사이에 대형 사건, 사고가 발생하면 표준 프레임워크에 대한 신뢰가 무너지는 계기가 될까봐 우려가 됩니다.

  2. Jangho Kim 댓글:

    하이재킹이나 스니핑 방지를 위한 암호화 통신, 올바른 사용자에 의한 엑세스임을 보장하는 인증 절차, MCP 서버 자체의 신뢰를 위한 검증 장치. 기존 소프트웨어나 앱의 보안을 책임졌던 장치들이 이제 MCP 서버들에 적용될 차례네요. 좋은 인사이트 감사합니다.

* 이 글의 댓글 일부는 Webmention 도구를 이용하여, 소셜 미디어 공유 반응(Comments, Like, Tweet)을 수집한 것입니다.

답글 남기기

이름*

URL (선택)

알림: 스팸 댓글이 많아서 블로그 운영자의 승인 후, 댓글이 보입니다. (한번만 적으셔도 됩니다.)