AI는 더 이상 답변만 하지 않습니다. 실행합니다. 이메일을 보내고, 데이터베이스를 조회하며, 클라우드 API를 호출합니다. 이 변화의 중심에 MCP(Model Context Protocol)가 있습니다. MCP는 바로 그 실행을 가능하게 하는 연결 통로입니다. 따라서 MCP는 단순한 연동 기술이 아니라, AI 실행 권한이 집중되는 구조적 허브입니다.

문제는 이 통로가 충분히 통제되지 않은 채 빠르게 확산되고 있다는 점입니다. 이때 보안의 질문은 단순해집니다. “AI의 실행 권한을 누가 통제하는가?”

AI 실행 확산기: 연결은 표준이 되고 있다

이 질문이 중요한 이유는 AI 실행 환경이 이미 빠르게 확산되고 있기 때문입니다. 2024~2025년이 AI 도입과 실험의 시기였다면 2026년은 AI가 실제 시스템을 호출하고 업무를 수행하는 ‘실행 확산기’로 진입하는 해입니다. 자연어 기반 이슈 생성, 디자인 결과물의 코드 자동 변환, 클라우드 API 직접 호출 등 MCP 기반 연결은 빠르게 늘고 있으며 이제 이는 일부 개발자의 실험이 아니라 조직 단위 운영 구조로 확장되고 있습니다. 다시 말해 AI는 더 이상 보조 도구가 아니라 실제 업무를 수행하는 실행 주체가 되고 있습니다.

글로벌 빅테크 역시 이 흐름에 맞춰 MCP를 인프라 레벨로 끌어올리고 있습니다. Google은 기존 API를 MCP와 직접 연결하는 완전 관리형 서버를 공개하며 AI 에이전트가 별도 커넥터 구축 없이 클라우드 자원에 접근할 수 있는 구조를 마련했고, 국내에서도 Kakao가 MCP 기반 플랫폼을 통해 외부 AI 서비스와 자사 도구를 연결하는 생태계를 확장하고 있습니다. 이는 MCP가 특정 커뮤니티의 기술이 아니라 글로벌 서비스 인프라의 표준 인터페이스로 자리 잡고 있음을 보여주는 신호입니다.

문제는 확산 속도만큼 통제 체계가 따라가지 못하고 있다는 점입니다. 실행이 쉬워질수록 통제는 어려워집니다. AI가 호출하는 API, 외부 도구, 오픈소스 패키지까지 연결 범위가 넓어지지만 그 실행 권한과 행위 흐름을 관리하는 보안 모델은 아직 명확히 정립되지 않았습니다. 결국 문제의 핵심은 모델의 안전성이 아니라 AI가 어떤 경로로 무엇을 실행하는지를 어떻게 통제할 것인가에 있습니다. 

실행 권한이 집중되는 구조: ‘postmark-mcp’ 사건이 보여준 현실

최근 공개된 ‘postmark-mcp’ 사건은 MCP 환경 위험성을 단적으로 보여줍니다. 이스라엘 보안 스타트업 코이 시큐리티는 *npm에 등록된 MCP 서버 패키지에 악성 코드가 삽입된 사례를 공개했습니다. 해당 패키지는 이메일 서비스 포스트마크와 연동되는 MCP 서버였으며 1.0.15버전까지는 정상 작동했습니다. 

그러나 1.0.16 버전에 악성 코드가 삽입되면서 이메일 발송 시 공격자의 주소가 **BCC로 자동 추가되었습니다. 이를 통해 비밀번호 재설정 메일, 송장, 계정 관련 안내 메일이 외부로 유출되었습니다. 주당 1,500회 이상 다운로드되었고, 약 300개 조직에서 하루 3,000건 이상의 이메일이 노출된 것으로 추정됩니다. (출처: 아이티데일리, 악성MCP 서버 발견…사용자 몰래 이메일 지속 탈취) 공격자는 API를 직접 공격하지 않았습니다. 대신 AI의 실행 통로를 장악했습니다. 이 사건은 단순 공급망 이슈가 아니라 MCP 구조가 고권한 실행 허브로 작동한다는 사실을 드러냈습니다. 실행 권한이 한 지점에 집중될수록 침해 시 피해 범위는 조직 전체로 확산됩니다. 

*npm(Node Package Manager): Node.js 환경에서 사용하는 오픈소스 소프트웨어 패키지 저장소이자 관리 도구로 전 세계 개발자들이 라이브러리를 공유·배포하는 플랫폼

**BCC(Blind Carbon Copy): 이메일에서 다른 수신자에게 주소를 노출하지 않고 숨은 참조로 메일을 받는 기능

노출된 MCP 서버의 현실: 통제 없는 연결

이 사건이 예외적이라면 다행이겠지만 조사 결과는 그렇지 않습니다. 글로벌 보안 기업 트렌드마이크로는 인터넷에 노출된 MCP 서버 492대를 조사했으며 모든 서버가 인증 없이 외부 접근을 허용하고 있었다고 밝혔습니다. AI 보안 스타트업 노스틱 역시 1,800여 대의 MCP 서버를 분석한 결과 상당수가 내부 도구 목록에 인증 없이 접근 가능했다고 발표했습니다. (출처: it조선, 무방비 노출된 MCP 서버, 대형 사고 부른다) 

이는 개별 사고가 아니라 구조적 취약성의 신호입니다. MCP는 단순 API 중계기가 아니라 대화 맥락과 권한을 함께 유지하는 실행 브리지입니다. 하나의 MCP 서버가 또 다른 서버와 연결되며 명령이 결합되는 구조에서는 프롬프트 인젝션, OAuth 토큰 탈취, 도구 그림자 공격 등이 연쇄적으로 확산될 수 있습니다. (출처: CIO, AI 통합의 숨은 위협 MCP의 10가지 보안 위험)

MCP 보안에 대한 기업의 대응 전략 3가지

그렇다면 기업은 무엇을 준비해야 할까요? MCP를 막는 것은 현실적인 선택지가 아닙니다. AI 실행 환경은 계속 확장될 것입니다. 핵심은 차단이 아니라 통제입니다.

실행 단위 최소 권한 모델 

많은 기업이 AI 에이전트를 하나의 고권한 계정으로 운영합니다. 개발과 테스트 단계에서는 빠르고 편리하기 때문입니다. 그러나 운영 환경에서 이 구조는 위험합니다. 하나의 계정이 모든 기능에 접근할 수 있다면 문제가 발생했을 때 피해 범위도 그만큼 넓어집니다.

따라서 AI가 수행하는 업무 단위에 맞춰 접근 권한을 세분화해야 합니다. 예를 들어 “데이터 조회” 권한과 “데이터 수정” 권한을 구분하고, 필요한 시간 동안만 제한적으로 권한을 부여하는 방식이 바람직합니다. 역할 기반 접근통제(RBAC)뿐 아니라 상황과 맥락에 따라 권한을 조정하는 방식(ABAC), 필요 시점에만 권한을 부여하는 방식(Just-in-Time)까지 고려해야 합니다. 권한은 기본적으로 열어두는 것이 아니라 필요할 때만 잠시 허용하는 구조로 설계되어야 합니다.

AI 행위 기반 모니터링 체계

기존 보안은 “로그인했는가”에 초점을 맞췄습니다. 하지만 MCP 환경에서는 이미 로그인한 AI가 어떤 행동을 하는지가 더 중요합니다. 평소보다 과도하게 데이터를 조회하거나 새벽 시간대에 대량 호출을 시도하거나, 반복적으로 동일한 리소스에 접근하는 경우는 이상 신호일 수 있습니다.

따라서 단순히 로그를 저장하는 수준을 넘어, 실행 패턴을 분석하는 체계가 필요합니다. 특히 프롬프트와 실제 실행 결과를 연결해 추적할 수 있어야 합니다. 다만 이 과정에서 개인정보나 기밀정보가 함께 기록될 수 있으므로 민감정보는 자동으로 가리고 최소 기간만 보관하는 정책이 병행되어야 합니다. 기업은 “인증 여부” 중심의 보안에서 “행위 분석” 중심의 보안으로 관점을 전환해야 합니다.

토큰과 컨텍스트 보호

MCP 환경에서 OAuth 토큰과 실행 세션 정보는 단순한 로그인 수단이 아닙니다. 사실상 시스템을 호출할 수 있는 열쇠와 같습니다. 이 열쇠가 탈취되거나 다른 작업에 재사용된다면 공격자는 정상 권한을 가진 것처럼 행동할 수 있습니다.

따라서 토큰은 반드시 암호화해 저장하고 사용 가능 시간을 짧게 설정해야 합니다. 가능하다면 특정 환경에서만 사용 가능하도록 제한하는 방식도 고려해야 합니다. 또한 AI 세션을 서로 분리하고, 실행 기록을 감사 가능하도록 남겨야 합니다. 실행 흐름이 보이지 않으면 사고가 발생했을 때 원인을 파악하는 데 큰 어려움을 겪게 됩니다.

MCP 보안은 특정 솔루션 하나를 도입한다고 해결되는 문제가 아닙니다. 접근 권한을 세분화하고, AI의 행동을 지속적으로 관찰하며, 인증 수단과 실행 정보를 안전하게 관리하는 구조적 접근이 필요합니다. AI 실행이 확산되는 지금, 기업이 준비해야 할 것은 더 많은 연결이 아니라 더 정교한 통제 체계입니다. 기술 도입 속도보다 통제 설계 속도가 뒤처지면, 그 대가는 결국 보안 사고로 돌아옵니다. (출처: CIO, AI 통합의 숨은 위협 MCP의 10가지 보안 위험)

FAQ

Q1. MCP 보안은 대기업만 필요한가요?

아닙니다. 오히려 스타트업이나 SaaS 기업처럼 빠르게 AI를 도입하는 조직일수록 더 위험할 수 있습니다. 기능 출시를 우선하다 보면 권한이 한 계정에 집중되는 구조가 만들어지기 쉽기 때문입니다. 실행 권한이 넓게 열려 있을수록 사고 발생 시 피해 규모는 기하급수적으로 커집니다.

Q2. 기존 API 보안 솔루션으로 충분하지 않나요?

기존 API 보안은 요청 단위로 인증과 접근을 통제합니다. 그러나 MCP는 여러 단계의 호출이 대화 맥락 속에서 연결되는 구조입니다. 이전 요청이 다음 실행에 영향을 미치기 때문에 단순 인증을 넘어 실행 흐름 전체를 관찰하는 행위 기반 모니터링이 필요합니다.

Q3. 가장 먼저 점검해야 할 항목은 무엇인가요?

MCP 서버에 인증이 제대로 적용되어 있는지, AI 에이전트의 권한 범위가 과도하지 않은지, OAuth 토큰이 안전하게 저장·관리되는지, 실행 로그가 추적 가능하도록 설계되어 있는지를 우선 점검해야 합니다. 이 네 가지가 실행 통제와 사고 대응 능력을 좌우하기 때문입니다.

결론: 통제되지 않은 실행은 가장 위험한 자동화다

MCP는 혁신의 통로이자 동시에 새로운 공격 표면입니다. AI를 도입하는 기업은 빠르게 늘고 있지만 그 실행 구조까지 설계한 기업은 많지 않습니다. 많은 기업이 아직 이 지점을 체감하지 못하고 있습니다. 이제 중요한 질문은 하나입니다. AI를 도입했는가가 아니라 AI의 실행을 설계했는가입니다.

보안은 연결을 차단하는 기술이 아닙니다. 위험을 예측하고, 실행의 범위를 정의하며, 문제가 발생했을 때 추적할 수 있도록 만드는 설계의 문제입니다. 통제되지 않은 자동화는 효율이 아니라 취약점이 됩니다. 실행 확산기의 경쟁력은 기술 속도가 아니라 통제 구조에서 결정됩니다.