이번 주, AI 코딩 도구에 대한 신뢰를 흔드는 세 가지 사건이 거의 동시에 터졌다. MCP(Model Context Protocol)의 구조적 RCE 취약점, Claude Code의 불투명한 키워드 필터링 논란, 그리고 Anthropic의 Claude Security 공개 베타 출시. 각각은 개별 뉴스처럼 보이지만, 나란히 놓고 보면 하나의 메시지를 발신하고 있다. AI 도구를 신뢰한다는 것이 무엇을 의미하는지, 팀 스스로 다시 정의해야 할 때가 왔다.
MCP RCE: "설계상 취약점"이 가장 위험한 이유
OX Security가 공개한 MCP 취약점 보고서는 표면적으로는 기술적 CVE 이슈처럼 보인다. STDIO 전송 메커니즘이 명령을 검증하기 전에 실행한다는 것—받고, 실행하고, 그다음에야 유효성을 확인한다. 이미 늦었다. 명령은 실행됐고, 피해는 발생했다.
문제는 Anthropic의 공식 입장이다. "이것은 설계상의 동작이며 프로토콜을 수정하지 않겠다." 이 한 문장이 모든 것을 바꿔놓는다. 일반적인 보안 취약점이라면 패치를 기다리면 된다. 하지만 벤더가 "이건 버그가 아니라 스펙"이라고 선언하는 순간, 정상적인 패치 사이클은 종료된다. Python, TypeScript, Java, Rust—모든 공식 SDK가 영향권에 있고, 다운스트림 프로젝트들이 각자 패치를 내놓겠지만(Flowise CVE-2026-40933은 CVSS 10.0이다), OX Security는 Flowise의 애플리케이션 레이어 필터링을 이미 우회했다. 아키텍처가 바뀌지 않으면 이 싸움은 끝나지 않는다.
공격 표면도 생각보다 훨씬 넓다. 저장소에 악의적인 MCP JSON 설정 파일 하나가 들어오면, IDE가 인덱싱할 때 자동으로 실행된다. Cursor, Windsurf 모두 확인된 취약점이다. 사용자가 아무 행동도 하지 않아도 된다. 테스트된 11개 MCP 레지스트리 중 9곳에서 악성 서버가 검토 없이 등록됐다는 것도 확인됐다. 레지스트리 등록 여부는 안전의 증거가 아니다.
Claude Code 필터링 논란: 불투명함이 신뢰를 잃는 방식
두 번째 사건은 더 불편하다. 커밋 메시지에 "schema": "openclaw.inbound_meta.v1" 문자열이 포함된 빈 저장소에서 claude -p "hi"를 실행했더니 세션 사용량이 즉시 100%로 올라가는 현상이 다수 사용자에 의해 재현됐다. HERMES.md 관련 GitHub 이슈(#53262)와 유사한 패턴이다. Anthropic 측은 "과도하게 작동한 anti-abuse system"이라고 설명했지만, 커뮤니티 반응은 냉담하다.
기술적으로 이건 anti-abuse 시스템의 오작동일 수 있다. 하지만 팀의 관점에서 더 심각한 문제는 불투명함 자체다. 어떤 키워드가 필터링 트리거인지, 어떤 기준으로 사용량이 차감되는지, 팀은 알 수 없다. 커밋 히스토리를 기반으로 동작이 달라지는 도구를 신뢰할 수 있나? 이미 유료로 구독하고 있는 팀이 자신의 워크플로우가 언제 차단될지 예측할 수 없다면, 그 도구는 운영 인프라로서 기준 미달이다.
커뮤니티에서는 단순한 기술적 오류가 아닌 반경쟁적 행위 가능성까지 언급되고 있다. 고의든 아니든, 구독자가 정당한 이유 없이 사용량을 소진당하고 그 원인을 알 수 없다면, 이는 도구 도입 여부보다 도구 의존도 수준을 낮춰야 한다는 신호로 읽어야 한다. 실제로 커뮤니티에서는 OpenCode, Deepseek, Kimi, GLM 등 대안 탐색이 빠르게 확산되고 있다.
Claude Security 출시: 모순인가, 보완인가
같은 시점에 Anthropic은 Claude Security를 공개 베타로 출시했다. Opus 4.6 기반으로 코드베이스 전체를 분석해 취약점을 탐지하고 패치 코드를 생성하는 도구다. 알려진 패턴을 매칭하는 것이 아니라 데이터 흐름을 추적하고 컴포넌트 간 상호작용을 분석하는 방식으로, 기존 SAST 도구가 수년간 놓친 취약점을 찾아냈다는 사례도 있다. CrowdStrike, Palo Alto Networks, Wiz 같은 보안 전문 기업들이 Opus 4.7을 자사 플랫폼에 통합했다는 점도 주목할 만하다.
표면적으로는 모순적이다. MCP 보안 취약점은 방치하면서, 코드베이스 보안 탐지 도구는 출시한다. 하지만 두 사안은 레이어가 다르다. Claude Security는 팀의 코드를 분석하는 도구이고, MCP 취약점은 AI 에이전트가 실행되는 인프라의 문제다. 팀 입장에서 유용한 질문은 "이 둘이 모순이냐"가 아니라 "어느 레이어에서 무엇을 Anthropic에 맡기고, 어느 레이어는 팀이 직접 통제해야 하나"다.
팀이 내일 당장 실행해야 할 통제선
세 사건을 종합하면 실행 항목이 보인다. 나는 이것을 "Anthropic을 믿지 말라"는 메시지로 읽지 않는다. 어떤 벤더에도 맹목적으로 의존하지 말라는 것이다.
즉시(오늘):
- MCP 설정 파일에서 모든 command 필드를 감사하라. 외부 콘텐츠가 해당 값에 영향을 줄 수 있는지 확인하라.
- STDIO 허용 명령어 allowlist를 명시적으로 정의하라. sh, bash, python, curl은 기본적으로 차단 대상이다.
- 에이전트 프로세스가 접근 가능한 환경 변수를 감사하고, 민감한 자격증명을 단기 수명 credentials로 전환하라.
이번 주: - MCP 서버를 Docker나 firejail로 샌드박싱하라. 특히 네트워크 격리는 대부분의 익스플로잇 페이로드를 무력화한다. - pre-push 훅에 SCA(소프트웨어 구성 분석)를 추가하라. 에이전트가 작성한 코드에 포함된 환각 패키지명은 STDIO 수준에서는 잡히지 않는다. - CI 파이프라인이 외부 PR이나 untrusted 저장소를 처리한다면, 해당 환경에서 STDIO MCP를 비활성화하는 것을 검토하라.
지속적으로: - MCP 도구 호출 패턴의 베이스라인을 수립하고, 예상 외 시스템 명령이나 비정상 네트워크 호출에 알림을 설정하라. - Claude Code를 포함한 모든 AI 코딩 도구의 행동이 변경됐을 때 팀이 인지할 수 있는 모니터링 루틴을 만들어라.
Claude Security는 도입할 가치가 있는 도구다. 하지만 그것이 MCP 레이어의 통제를 대신해주지는 않는다. 벤더가 내 인프라의 안전을 보장해줄 것이라는 가정은, AI 도구를 운영 인프라로 쓰는 순간부터 팀이 버려야 할 가정이다.
전망: 신뢰는 선언이 아니라 설계에서 나온다
AI 코딩 도구 시장은 지금 흥미로운 변곡점에 있다. 오픈웨이트 모델(Kimi, GLM, Qwen, Deepseek)이 빠르게 클로즈드 모델을 추격하면서, 팀의 협상력이 높아지고 있다. 이 경쟁 구도는 역설적으로 팀에게 유리하다. 특정 도구에 대한 의존도를 낮추는 아키텍처—모델과 실행 레이어를 분리하고, 벤더 종속을 최소화하는 설계—가 단순히 좋은 엔지니어링 원칙이 아니라 팀의 협상력을 유지하는 전략이 되고 있다.
신뢰 위기의 해법은 더 좋은 도구를 찾는 것이 아니다. 어떤 도구도 신뢰의 경계 안에서만 사용하는 구조를 팀이 직접 설계하는 것이다. MCP allowlist, 샌드박스 격리, pre-push 검증, 행동 모니터링—이것들은 특정 도구에 대한 불신의 표현이 아니라, AI 도구를 팀의 진짜 인프라로 편입시키기 위한 최소한의 설계 기준이다.