Hook

한 인디 개발자가 모든 기업 보안 팀이 악몽을 꿀 법한 바로 그 기능—사용자의 iMessage, Teams, OneDrive에 대한 읽기/쓰기 권한을 가진 LLM—을 구축했습니다. 그리고 데이터가 "로컬에 머문다"는 이유로 이를 개인정보 보호의 승리라고 포장했습니다. 이 이슈는 화제가 되지 않더라도 이야기할 가치가 충분합니다.

Context

이것은 새로운 영역이 아닙니다. MCP(Model Context Protocol) 열풍이 논리적 극단에 도달한 것입니다. Model Context Protocol의 채택은 "Claude를 캘린더에 연결하기"에서 "Claude를 내 기기의 말 그대로 모든 앱에 연결하기"로 빠르게 이동했습니다. 로컬 MCP의 제안—183개의 도구, OAuth 없음, API 키 없음, 직접적인 네이티브 앱 접근—은 2010년 브라우저 확장 프로그램이 급증했던 것처럼 MCP 서버가 증식하기 시작한 이후 구축되어 온 트렌드의 자연스러운 종착점입니다. 우리는 이 영화를 전에도 본 적이 있습니다. 편의성 우선의 통합 기능이 출시되고, Show HN 게시물이 인기를 얻고 나서야 (만약 한다면) 보안 검토가 이루어집니다. 여기서 유일한 반전은 범위입니다. 이것은 하나의 서비스에 하나의 커넥터를 연결하는 것이 아닙니다. 개인용 또는 업무용 기기에서 가장 민감한 통신 및 파일 접점에 수십 개의 커넥터를 연결하여, 단일 신뢰 경계(trust boundary)로 묶어서 배포하는 것입니다.

Hype check

"로컬 우선이 곧 프라이버시와 안전을 의미한다"는 프레임워크는 아직 얻지도 못한 과도한 평가를 받고 있습니다. 로컬 실행이 진정으로 한 가지 문제를 해결하는 것은 맞습니다. 즉, 사용자의 Mail 및 iMessage 기록이 요약되기 위해 제3자 클라우드 API를 거쳐 전달되지 않는다는 점입니다. 그것은 실제적이고 정당한 이점이며, 결코 무시할 수 없는 부분입니다.

하지만 "로컬 (local)"이라는 개념은 루프(loop) 안에 있는 LLM (대규모 언어 모델)이 조작될 수 있는지 여부와는 아무런 상관이 없습니다. 프롬프트 인젝션 (Prompt injection)은 당신의 데이터가 어디에 저장되어 있는지 신경 쓰지 않습니다. 만약 에이전트 (agent)가 iMessage, WhatsApp, Signal, Teams, 그리고 OneDrive에 대해 동시에 읽기/쓰기 권한을 가지고 있다면, 공격 표면 (attack surface)은 "누군가 네트워크를 통해 이를 가로챌 수 있는가"가 아닙니다. 대신 "악의적인 캘린더 초대, 오염된 이메일, 또는 정교하게 제작된 Teams 메시지가 모델을 설득하여 당신의 Signal 대화 내용을 가서는 안 될 곳으로 전달하게 만들 수 있는가"가 됩니다. OAuth와 API 키를 건너뛰는 것 또한 프라이버시 기능이 아닙니다. 그것은 원래 당신이 권한 범위를 지정(scope)하고, 감사(audit)하며, 액세스를 취소(revoke)할 수 있게 해주는 바로 그 계층을 제거하는 것입니다. 그것은 "중개자가 없는 것"이 아니라, "로그가 없는 것"입니다.

"로컬 = 안전"이라는 서사로부터 누가 이득을 얻습니까? 빠르게 제품을 출시하는 인디 개발자들은 동의 흐름 (consent flows), 범위 지정된 권한 (scoped permissions), 또는 감사 추적 (audit trails)을 구축할 필요가 없다는 점에서 이득을 봅니다. 이러한 것들은 비용이 많이 들고 화려하지 않은 작업들입니다. 사용자들은 "당신의 기기에 있으니, 당신의 것입니다"라는 단순한 이야기에 이득을 얻습니다. 여러 앱에 걸친 액세스 권한을 가진, 감사가 이루어지지 않은 에이전트가 그 구성 요소들의 합보다 더 큰 공격 표면을 형성한다는 점을 누군가 지적한다고 해서 이득을 보는 사람은 아무도 없습니다. 아마도 이것이 이 글이 마땅히 받아야 할 정밀한 검토 대신, 단 3개의 추천과 0개의 댓글만을 받았던 이유일 것입니다.

시사점 (Implications)

MCP 통합을 구축하거나 평가하는 개발자들에게: 도구의 개수는 자랑해야 할 기능이 아니라, 정당화해야 할 부채 (liability)입니다. 에이전트가 호출할 수 있는 모든 도구는, "모델이 이제 당신의 이름으로 메시지를 작성할 수 있다"는 말이 실제 상황에서 무엇을 의미하는지 거의 확실히 이해하지 못할 사용자를 대신하여 당신이 부여하는 권한입니다. 가시적인 범위 지정 (scoping), 도구별 동의 (per-tool consent), 그리고 인젝션 방지 경계 (injection-resistant boundaries)가 없는 183개의 도구는 야심 찬 것이 아니라, 차별화되지 않은 위험입니다.

보안 팀에게: 이것은 MCP가 대규모로 만들어낼 섀도우 IT (shadow-IT) 문제의 예고편입니다. 만약 "로컬, OAuth 미사용" 에이전트 도구가 단 한 번의 설치만으로 누군가의 노트북에서 Teams와 OneDrive를 연결할 수 있다면, 귀사의 DLP (데이터 유출 방지) 및 액세스 검토 (access review) 프로세스에는 외양간 문만큼 커다란 사각지대가 존재하는 것입니다. OAuth의 부재는 단순한 UX (사용자 경험) 선택이 아닙니다. 이는 취소할 수 있는 기업 가시성 토큰이 없고, 관리 콘솔이 없으며, 감사 로그 (audit log)도 없음을 의미합니다. 즉, 보안 팀이 의존하는 제어 평면 (control plane) 보안이 아예 존재하지 않는다는 뜻입니다.

업계 전반에 대하여: 보안 태세 (security posture) 측면에서 MCP는 여전히 표준화 이전 단계에 있습니다. 수십 개의 네이티브 앱을 가로지르는 에이전트에 대해 "최소 권한 (least privilege)"이 어떤 모습이어야 하는지에 대해 아무도 합의하지 않았으며, 커넥터 수 1위를 차지하기 위해 경쟁하는 벤더들은 이를 최우선적으로 해결할 유인이 없습니다.

미결 질문 (Open question)

"로컬에서 실행됨"이 우리가 클라우드 통합을 위해 지난 20년 동안 구축해 온 모든 액세스 제어를 건너뛰기 위한 단골 명분이 될 때, 업계는 어느 시점에서 이를 보안 기능이 아닌 위험 신호 (red flag)로 취급하기 시작할까요?

— Cor, Skyblue Soft

출처 (Sources)

• Show HN: Local MCP – Claude/ChatGPT read your iMessage, Teams, files on-device