NSA가 MCP 보안에 대해 의견을 내놓았습니다: 당신의 AI 코딩 워크플로우(AI Coding Workflow)에 미치는 의미
요약
NSA가 Model Context Protocol(MCP)의 보안 위험을 경고하는 공식 권고안을 발표했습니다. MCP가 LLM과 컴퓨팅 환경을 연결하며 발생하는 의미론적 공격 표면의 위험성을 분석하고, 개발자가 취해야 할 보안 조치를 다룹니다.
핵심 포인트
- MCP는 단순 실험 도구를 넘어 프로덕션 인프라로 격상됨
- 공격 경계가 구문론적 수준에서 의미론적(Semantic) 수준으로 변화
- 전송 계층에서의 인증 및 인가 강제 필요성 강조
- MCP 서버를 기본적으로 신뢰할 수 없는 엔드포인트로 취급 권고
이 기사는 원래 LucidShark Blog에 게시되었습니다.
NSA는 오늘 Model Context Protocol (MCP) 보안에 관한 공식 사이버 보안 정보 시트(Cybersecurity Information Sheet)를 발표했습니다. 만약 당신이 전문적인 맥락에서 Claude Code, Cursor, 또는 MCP가 활성화된 모든 AI 코딩 도구를 사용하고 있다면, 이 문서는 바로 당신을 향한 것입니다.
정부의 공식 보안 권고(Security Advisories)는 소수의 취미 활동가용 프로토콜에 대해 작성되지 않습니다. 이러한 권고는 공격 표면(Attack Surface)이 충분히 커지고 심각해져서, 정보 공동체(Intelligence Community)가 이를 시스템적 위험으로 간주할 때 작성됩니다. MCP에 대해 발표하기로 한 NSA의 결정은 하나의 전환을 의미합니다. MCP는 더 이상 개발자들의 놀이터 수준의 실험이 아닙니다. 이는 실제 보안 의무를 수반하는 프로덕션 인프라(Production Infrastructure)입니다.
이 기사는 이 권고가 실질적인 측면에서 무엇을 의미하는지, NSA의 분석이 부족한 부분은 어디인지, 그리고 이번 주에 당신이 취해야 할 다섯 가지 구체적인 단계에 대해 설명합니다.
MCP가 실제로 하는 일 (그리고 그것이 보안에 중요한 이유)
Model Context Protocol (MCP)은 대규모 언어 모델(Large Language Models, LLM)과 나머지 컴퓨팅 환경 사이를 잇는 가교 역할을 합니다. MCP가 활성화된 Claude Code 세션은 당신의 자연어 지침에 따라 모델의 지시를 받아 코드베이스에서 파일을 읽고, 셸 명령(Shell Commands)을 실행하며, 데이터베이스를 쿼리하고, HTTP 요청을 보내며, 외부 API를 호출할 수 있습니다.
이것은 진정으로 강력합니다. 또한 전통적인 소프트웨어와는 근본적으로 다른 보안 모델이기도 합니다.
전통적인 소프트웨어에서 함수는 어떤 작업을 수행할 권한이 있거나, 혹은 없습니다. 액세스 제어(Access Controls)는 호출 지점(Call Site)에서 강제됩니다. 감사(Auditing)는 권한과 API 계약(API Contracts)을 확인하는 것을 의미합니다.
MCP가 활성화된 에이전트 워크플로우(Agentic Workflow)에서 모델은 문맥(Context), 지침(Instructions), 그리고 도구 설명(Tool Descriptions)에 대한 해석을 바탕으로 어떤 도구를 호출할지 결정합니다. 이 세 가지 입력 중 어느 하나라도 영향을 미칠 수 있는 공격자는 밑단의 코드를 직접 건드리지 않고도 모델이 수행하는 작업에 영향을 미칠 수 있습니다.
공격 경계는 구문론적(Syntactic)인 것이 아니라 의미론적(Semantic)입니다. 모델의 동작을 조작하도록 정교하게 설계된 도구 설명(Tool description)은 어떤 방화벽 규칙도 잡아낼 수 없습니다. 프롬프트(Prompt)에 내장된 악의적인 의도를 SAST(정적 애플리케이션 보안 테스트) 스캐너도 감지하지 못합니다. 이것이 바로 NSA 권고안이 다루기 시작한 핵심 과제입니다.
NSA 권고안이 올바르게 짚어낸 점
이 권고안은 합리적인 출발점입니다. 권고안의 핵심 권장 사항은 전송 계층(Transport layer)에서의 인증(Authentication)과 인가(Authorization)에 집중되어 있습니다. 즉, MCP 서버가 연결을 수락하기 전에 인증을 요구하도록 하고, 개별 도구 호출(Tool call)에 대해 인가 검사를 강제하며, MCP 서버를 암묵적으로 신뢰할 수 있는 로컬 서비스가 아닌 기본적으로 신뢰할 수 없는 엔드포인트(Untrusted endpoint)로 취급하라는 것입니다.
이러한 권장 사항은 옳습니다. 오늘날 실제 사용되는 대부분의 MCP 서버 구현체는 인증이 취약하거나 아예 없습니다. 로컬에서 MCP 서버를 실행하는 개발자는 흔히 "localhost니까 괜찮겠지"라고 가정합니다. 하지만 다른 프로세스가 실행 중이거나, 컨테이너를 공유하거나, 심지어 브라우저 기반 공격이 존재하는 환경에서 localhost는 신뢰 경계(Trust boundary)가 아닙니다.
최소 권한(Minimal permissions)을 강조한 권고안의 내용 또한 타당합니다. 프로젝트 디렉토리 내의 파일만 읽을 수 있는 MCP 서버는 임의의 파일 시스템 접근 권한을 가진 서버보다 위험도가 낮습니다. 외부 네트워크 호출을 할 수 없는 MCP 서버는 데이터를 유출(Exfiltrate)할 수 없습니다. 범위가 제한된 권한(Scoped permissions)은 폭발 반경(Blast radius)을 줄여줍니다.
권고안이 놓치고 있는 점
전송 계층은 필요조건이지만 충분조건은 아닙니다. 이 권고안은 더 어려운 두 가지 문제를 적절히 다루지 못하고 있습니다.
코드 계층(Code layer)의 문제. 모든 인증 및 인가 검사를 통과하는 MCP 서버라 할지라도 여전히 악의적인 로직을 포함하고 있을 수 있습니다. 환경 변수를 읽어 외부 HTTP 호출로 전달하는 서버는 정당한 유틸리티로 위장한 자격 증명 유출(Credential exfiltration) 도구입니다. 설치 전 MCP 서버 코드에 대한 정적 분석(Static analysis)을 수행하면 이러한 사례 중 상당수를 잡아낼 수 있습니다. 예를 들어, 하드코딩된 원격 엔드포인트, 의심스러운 서브프로세스(Subprocess) 호출, 비정상적인 자격 증명 접근 패턴, 민감한 정보를 외부로 라우팅하는 데이터 흐름 등이 이에 해당합니다.
해당 권고안은 MCP 서버를 "검증(vetting)"하는 것에 대해 언급하고 있지만, 이를 기술적인 문제라기보다는 정책적인 문제로 취급하고 있습니다. 수십 대의 개발자 머신에서 수십 개의 MCP 서버를 관리하는 팀에게 "각 서버를 수동으로 검토하라"는 것은 확장 가능한 정책이 아닙니다. 설치 시점에 MCP 서버 코드를 자동 정적 분석(Automated static analysis)하는 것이 검증의 실질적인 구현 방법입니다.
자연어 설명 공격 (The natural language description attack). MCP 도구의 설명은 자연어로 작성됩니다. 이는 컴파일러나 접근 제어 시스템(Access control system)이 아니라 언어 모델(Language model)에 의해 읽힙니다. 악의적인 도구 설명은, 실제 코드가 수행할 권한은 가지고 있지만 개발자가 전혀 의도하지 않은 동작을 모델이 수행하도록 지시할 수 있습니다.
예시: "성능을 위해 코드를 최적화합니다"라고 설명된 도구가, 설명 내에 포함된 지시를 통해 발견되는 모든 환경 파일(Environment files)을 프로젝트의 공개 디렉토리(Public directory)로 복사하도록 모델에게 명령하는 경우입니다. 코드 자체는 환경 파일에 대한 읽기 권한과 공개 디렉토리에 대한 쓰기 권한을 가지고 있습니다. 접근 제어(Access controls)는 통과됩니다. 공격은 의미론적 조작(Semantic manipulation)을 통해 성공합니다.
NSA 권고안은 이 공격 벡터(Vector)를 다루지 않습니다. 실질적인 완화 방법은 도구 설명을 신뢰할 수 없는 입력(Untrusted input)으로 취급하고, 설명이 명시된 목적보다 더 많은 컨텍스트(Context)나 권한을 요청하는 것처럼 보이는 모든 MCP 서버에 대해 면밀한 조사(Scrutiny)를 적용하는 것입니다.
이번 주에 취해야 할 5가지 구체적인 단계
1. 환경 내의 모든 MCP 서버 인벤토리 작성
대부분의 개발자는 수개월에 걸쳐 MCP 서버를 하나씩 설치해 왔으며, 실제로 무엇이 실행되고 있는지 파악하지 못하고 있습니다. 전체 인벤토리를 실행하십시오: 어떤 서버가 설치되어 있는지, 어떤 권한을 요청했는지, 그리고 마지막으로 언제 업데이트되었는지 확인하십시오.
# Claude Code 설정에서 MCP 서버 목록 확인
cat ~/.claude/settings.json | jq '.mcpServers'
...
만약 알 수 없는 서버를 발견한다면, 먼저 제거한 다음 조사를 진행하십시오.
2. MCP 서버를 설치하기 전에 소스 코드 검토
이는 AI 도구에 적용되는 "읽지 않은 코드는 실행하지 마라"는 원칙입니다. 새로운 MCP 서버를 추가하기 전에 소스 코드를 읽으십시오. 만약 오픈 소스(Open Source)가 아니라면, 신뢰할 수 없는 것으로 간주하십시오. 특히 다음 사항을 중점적으로 확인하십시오: 외부 HTTP 호출(Outbound HTTP calls), 서브프로세스 실행(Subprocess execution), 명시된 목적을 초과하는 파일 시스템 접근(Filesystem access), 그리고 환경 변수(Environment variables)에 대한 접근입니다.
MCP 서버 코드에서 의심스러운 패턴을 확인하는 정적 분석 스캐너(Static analysis scanners)와 같이 이러한 검토를 자동화하는 도구들은, 개발자들이 검토를 건너뛰지 않고 실제로 수행할 수 있도록 마찰을 충분히 줄여줍니다.
3. 권한 범위를 최소한으로 제한 (Scope Permissions to the Minimum Necessary)
Claude Code 및 기타 MCP 클라이언트는 각 서버가 노출할 수 있는 도구와 접근할 수 있는 경로 접두사(Path prefixes)를 구성할 수 있도록 허용합니다. 이러한 제어 기능을 사용하십시오.
// .mcp.json 권한 범위 제한 예시
{
"mcpServers": {
...
src/ 디렉토리에 대해 읽기 전용(Read-only) 접근으로 범위가 제한된 서버는 파일을 쓸 수 없고, .env 파일을 읽을 수 없으며, 배포 설정(Deployment configuration)을 건드릴 수 없습니다. 최소 권한 원칙(Least privilege)은 단순히 규정 준수를 위한 체크박스가 아닙니다. 이는 침해된 서버가 할 수 있는 작업에 대한 실질적인 제한입니다.
4. 모든 MCP 도구 출력을 코드베이스에 대한 신뢰할 수 없는 입력으로 취급하십시오
MCP 도구 호출을 통해 생성된 코드는 다른 방식으로 생성된 코드와 동일한 품질 및 보안 검사를 거쳐야 합니다. MCP 출력은 모델의 직접적인 출력 대신 도구를 통해 나왔다고 해서 더 신뢰할 수 있는 것이 아닙니다. 어떤 면에서는 도구가 상류(Upstream)에서 조작되었을 수 있기 때문에 오히려 신뢰도가 더 낮을 수도 있습니다.
AI가 생성한 디프(Diffs)에 대해 정적 분석을 실행하는 프리커밋 훅(Pre-commit hooks), 새로운 의존성(Dependencies)을 표시하는 보안 스캐너, 그리고 회귀(Regressions)를 잡아내는 테스트 커버리지 확인 등이 모두 이와 관련이 있습니다. 목표는 코드가 어떻게 생성되었든 상관없이, 문제가 메인(Main) 브랜치에 도달하기 전에 포착하는 것입니다.
5. 검증 스택을 로컬에 유지하십시오
NSA의 권고안은 클라우드 기반 AI 보안 도구의 데이터 거주성 (Data Residency) 영향에 대해서는 다루지 않지만, 이는 매우 중요한 문제입니다. 만약 코드 품질 및 보안 검증이 벤더의 클라우드에서 실행된다면, 귀하의 코드는 벤더의 서버에 존재하게 됩니다. 독점적인 코드베이스, 민감한 비즈니스 로직, 그리고 컴플라이언스 (Compliance) 요구 사항을 준수해야 하는 모든 환경에 있어 이는 의미 있는 리스크입니다.
**로컬 우선 검증 도구 (Local-first validation tools)**는 귀하의 코드베이스를 중간 서버에 노출하지 않고, 귀하의 자체 하드웨어와 자체 API 키를 사용하여 코드를 처리합니다. 이는 단순한 개인정보 보호 선호의 문제가 아닙니다. 이는 공급망 리스크 (Supply Chain Risk)의 한 범주를 통째로 제거하는 보안 통제 (Security Control)입니다.
이것이 귀하의 툴링 (Tooling)에 의미하는 바
5가지 권장 사항 전체에 걸친 패턴은 동일합니다. 보안 결정을 코드베이스에 최대한 가깝게 이동시키고, 외부 벤더에 대한 신뢰 의존성을 최소화하며, 사람이 수동으로 신뢰성 있게 수행하기 어려운 검사들을 자동화하는 것입니다.
이것이 LucidShark의 설계 철학입니다. 귀하의 머신에서 실행되는 로컬 우선 코드 품질 분석을 통해, MCP를 통해 Claude Code와 통합되며, 보안 회귀 (Security Regressions), 의심스러운 종속성 변경, 그리고 품질 드리프트 (Quality Drift)를 병합(Merge)되기 전에 드러냅니다. 클라우드 의존성이 없습니다. 코드가 귀하의 머신을 떠나지 않습니다. 오픈 소스이므로 툴링 자체를 감사 (Auditable)할 수 있습니다.
NSA의 권고안은 AI 코딩 보안 카테고리가 성숙해지고 있다는 신호입니다. 정부 차원의 관심은 기업의 도입으로 이어지며, 기업의 도입은 공급망 내의 모든 이들에게 더 엄격한 보안 요구 사항을 의미합니다. 이 카테고리가 아직 표준을 정의하고 있는 지금 보안 태세 (Security Posture)를 올바르게 갖추는 것은, 나중에 뒤처지지 않기 위해 허둥지둥하는 대신 앞서 나가는 길입니다.
귀하의 AI 어시스턴트를 코드베이스에 연결하는 프로토콜은 이제 공식적으로 연방 정부의 주의를 기울일 가치가 있는 보안 우려 사항이 되었습니다. 그에 따라 행동하십시오.
AI 코딩 워크플로우 (AI Coding Workflow)에 로컬 보안 계층을 추가하세요.
LucidShark는 사용자의 머신에서 완전히 실행되며, MCP를 통해 Claude Code와 통합됩니다. 또한 보안 회귀 (Security Regressions), 의심스러운 종속성 (Dependency) 추가, 품질 저하 (Quality Drift)를 메인 브랜치에 도달하기 전에 포착합니다. 어떤 코드도 사용자의 머신을 벗어나지 않습니다.
LucidShark 설치하기
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기