AI 코딩 도구의 이중성 — Claude Code, 방패인가 창인가?

현장 PM이 직접 뜯어본 ‘Claude Code Security’ 전쟁의 실체

“이 도구, 정말 믿어도 되는 건가요?” 얼마 전 함께 일하는 개발팀 리드가 슬랙으로 던진 한 마디다. 그리고 나는 잠시 아무 말도 못했다.

들어가며 — 현장에서 느끼는 온도 차

프로젝트 관리를 20년 넘게 하다 보면, 새로운 도구가 나올 때마다 두 가지 부류의 사람을 보게 된다. “일단 써봐야지” 파와 “그게 안전한 거야?” 파. 그런데 Claude Code를 둘러싼 최근 보안 이슈들을 보면서 솔직히 말하자면, 이번엔 두 파 모두 틀리지 않았다는 생각이 든다.

2026년 상반기, Claude Code는 보안 업계를 뒤흔드는 몇 가지 굵직한 사건의 진원지가 됐다. 그런데 아이러니하게도, 바로 그 Claude Code가 동시에 ‘보안 도구’로 진화하고 있다. 방어자의 무기가 되려는 시도와, 공격자의 먹잇감이 되는 현실이 동시에 진행 중인 것이다.

이 글은 기술 문서가 아니다. IT 프로젝트를 실제로 관리하고, 개발팀과 함께 현장에서 뛰는 사람의 시각으로 Claude Code 보안 이슈의 전모를 정리하고, 여기서 우리가 뭘 배워야 하는지를 솔직하게 써 내려간 글이다.

1. Claude Code란 무엇인가 — 먼저 이것부터 짚고 가자

Claude Code는 Anthropic이 2025년 초에 출시한 터미널 기반 AI 코딩 에이전트다. 단순한 코드 자동완성 도구가 아니다. 터미널에서 직접 코드를 실행하고, Git 저장소를 관리하며, 파일 시스템에 접근하고, 외부 API를 호출하는 등 고도의 자율 행동이 가능한 에이전트형 도구다.

2025년 초 출시 이후 개인 개발자와 엔터프라이즈 엔지니어링 팀 모두에게 인기를 얻었고, 이 도구 하나가 Anthropic의 연간 반복 매출(ARR)을 연간 300억 달러 규모로 끌어올리는 데 기여했다.

이 정도면 단순한 도구가 아니다. 기업의 핵심 개발 인프라에 깊숙이 파고든 플랫폼이다.

그런데 바로 이 ‘깊이’가 문제를 만든다.

터미널 접근, 파일 시스템 제어, API 키 관리, MCP(Model Context Protocol)를 통한 외부 서비스 연동 — 이 모든 기능은 개발자의 생산성을 폭발적으로 높이는 동시에, 공격자 입장에서는 황금 같은 공격 표면(Attack Surface)을 제공한다.

2. 2025~2026년 Claude Code 보안 사건 연대기

말로 설명하는 것보다 사건의 흐름을 시간순으로 보는 게 더 명확하다. 지난 1년간 무슨 일이 있었는지 직접 봐라.

📌 사건 1 — CVE-2025-59536: 저장소를 열었더니 내 PC가 털렸다 (2025년 7월~10월)

Check Point Research의 보안 연구자들은 Claude Code에서 심각한 취약점을 발견했다. CVSS 8.7점의 고위험 취약점으로, 공격자가 제어하는 저장소(Repository)를 클론하고 여는 것만으로 원격 코드 실행(RCE)이 가능했다.

메커니즘을 들여다보면 소름이 돋는다.

Claude Code에는 Hooks라는 기능이 있다. 개발 워크플로우의 특정 시점에 미리 정의된 셸 명령어를 자동으로 실행하는 기능이다. 그런데 이 Hook을 .claude/settings.json이라는 설정 파일에 정의할 수 있고, 개발자들은 이런 프로젝트 설정 파일을 실행 코드가 아닌 ‘메타데이터’로 인식하기 때문에 소스 코드만큼 꼼꼼하게 보안 리뷰를 하지 않는다.

이것이 핵심이다.

공격자는 악성 Hook이 심어진 .claude/settings.json 파일을 저장소에 포함시켜 놓는다. 개발자가 “이 프로젝트 한번 봐야지” 하면서 클론하고 Claude Code를 실행하는 순간, 신뢰 확인 다이얼로그가 뜨기도 전에 악성 셸 명령어가 실행된다. 클릭 한 번 없이.

2025년 7월 21일 Check Point Research가 Anthropic에 취약점을 보고했고, 8월 26일 협력적인 패치 과정을 거쳐 최종 수정이 완료됐다. Anthropic은 2025년 9월 버전 1.0.87에서 패치를 적용했고, 이후 버전 1.0.111(2025년 10월)에서 추가 취약점도 수정했다.

📌 사건 2 — CVE-2026-21852: API 키가 공격자 서버로 날아간다 (2025년 12월~2026년 1월)

두 번째 취약점은 CVSS 5.3점으로 다소 낮지만, 그 영향은 결코 가볍지 않다. 악성 저장소가 ANTHROPIC_BASE_URL 환경 변수를 조작해 Claude Code의 API 요청을 공격자가 통제하는 엔드포인트로 리디렉션하면, 개발자의 Anthropic API 키가 신뢰 확인 프롬프트가 표시되기도 전에 외부로 유출된다.

Anthropic의 API는 Workspace라는 기능을 통해 여러 API 키가 클라우드에 저장된 프로젝트 파일을 공유 접근할 수 있다. 파일은 특정 키가 아닌 워크스페이스 자체에 귀속된다. 즉, 키 하나가 털리면 팀 전체의 데이터에 영향을 줄 수 있다는 뜻이다.

PM 관점에서 말하자면, 이건 단순한 기술 사고가 아니다. 팀 전체의 프로젝트 파일, 코드, 데이터가 한순간에 공격자 손에 넘어갈 수 있는 비즈니스 리스크다.

Anthropic은 2025년 12월 28일 이 취약점을 수정했고, 2026년 1월 21일 CVE-2026-21852를 공식 발표했다. 최종 패치는 2026년 1월 버전 2.0.65에 반영됐다.

📌 사건 3 — 소스코드 유출 대참사 (2026년 3월 31일)

이건 아직도 업계에서 회자되는 사건이다.

2026년 3월 31일, Anthropic은 실수로 npm 패키지(@anthropic-ai/claude-code 버전 2.1.88)에 59.8MB 짜리 JavaScript 소스 맵 파일을 포함시켜 공개 배포해버렸다. 이 파일에는 1,906개 파일에 걸쳐 513,000줄의 비난독화 TypeScript 코드가 고스란히 담겨 있었다.

에이전트의 오케스트레이션 로직, 권한 시스템, 실행 메커니즘, 숨겨진 기능들, 그리고 보안 관련 내부 구조까지 전부.

Claude Code의 컨텍스트 파이프라인, 샌드박스 경계, 권한 검증기의 전체 아키텍처가 공개되면서, 공격자들은 컨텍스트 압축을 통해 지속되고 보안 체인의 틈새를 노리는 페이로드를 제작할 수 있는 청사진을 손에 쥐게 됐다.

그리고 이 소스 코드를 미끼로 삼은 2차 공격이 즉각 이어졌다.

Zscaler의 보고에 따르면, 유출된 소스 코드를 찾는 사용자들을 노린 위협 행위자들이 GitHub에 가짜 저장소를 만들어 Vidar 정보 탈취 악성코드를 배포하기 시작했다. 사용자들이 다운로드하는 7-Zip 압축 파일에는 ClaudeCode_x64.exe라는 Rust 기반 실행 파일이 포함되어 있었고, 실행하면 Vidar 인포스틸러와 GhostSocks 네트워크 트래픽 프록시 도구가 함께 설치됐다.

인간의 호기심과 FOMO(Fear of Missing Out)를 공략한 사회공학적 공격이다. 보안 의식이 충분한 개발자들도 “와, 소스 코드가 떴네” 하는 순간 판단이 흐려진다.

📌 사건 4 — MCP 아키텍처 설계 결함 (2026년 4월)

OX Security 연구팀은 Anthropic의 Model Context Protocol(MCP) 자체에 내재된 아키텍처 수준의 취약점을 발견했다. 이 결함은 MCP 구현체를 실행 중인 모든 시스템에서 임의 명령 실행(RCE)을 가능하게 하며, 민감한 사용자 데이터, 내부 데이터베이스, API 키, 채팅 이력에 대한 직접 접근을 공격자에게 허용한다.

이것이 단순 버그와 다른 이유는 규모 때문이다.

MCP는 Anthropic이 개발한 오픈소스 프로토콜로, Python, TypeScript, Java, Rust 등 지원되는 모든 언어에 걸쳐 Anthropic의 공식 MCP SDK를 사용하는 개발자라면 누구나 이 취약점을 물려받는다.

OX Security 연구팀은 Anthropic에 반복적으로 근본적인 패치를 권고했지만, Anthropic은 이 동작이 “예상된 동작(expected behavior)”이라며 프로토콜 아키텍처 수정을 거부했다. 영향 범위는 1억 5천만 건 이상의 다운로드와 7,000개 이상의 공개 접근 가능한 서버에 달한다.

연구팀은 11개 MCP 마켓플레이스 중 9개에 악성 시험 MCP를 성공적으로 등록했다. 수십만 명의 월간 방문자를 보유한 플랫폼들도 포함됐다. 단 하나의 악성 MCP 항목이 감지되기 전에 수천 명의 개발자에게 설치될 수 있으며, 각 설치마다 공격자는 해당 개발자의 시스템에서 임의 명령 실행 권한을 갖게 된다.

3. 그런데 Anthropic이 Claude Code로 ‘방어’를 선언했다

이쯤에서 반전이 있다.

바로 그 Claude Code가, 보안의 무기로 탈바꿈을 시도하고 있다.

2026년 2월, Anthropic은 Claude Code Security를 발표했다. Enterprise 및 Team 고객 대상의 한정 리서치 프리뷰로 공개된 이 기능은, AI가 코드베이스 전체를 사람 보안 연구자처럼 읽고 추론하여 취약점을 찾아내는 도구다.

기존의 정적 분석(Static Analysis) 도구는 규칙 기반으로 알려진 취약점 패턴만 탐지한다. 노출된 패스워드나 구식 암호화 방식 같은 것들은 잘 잡지만, 비즈니스 로직의 결함이나 접근 제어 오류 같은 복잡한 취약점은 놓치기 일쑤다. Claude Code Security는 알려진 패턴을 매칭하는 방식이 아니라, 컴포넌트들이 어떻게 상호작용하는지 이해하고, 데이터가 애플리케이션을 어떻게 흐르는지 추적하는 방식으로 취약점을 탐지한다.

그 성과는 꽤 인상적이다.

Claude Opus 4.6를 활용해 팀이 오픈소스 프로덕션 코드베이스에서 500개 이상의 취약점을 발견했는데, 이 버그들은 수년간의 전문가 리뷰에도 불구하고 수십 년 동안 탐지되지 않았던 것들이었다.

각 발견된 취약점은 다단계 검증 프로세스를 거쳐 오탐(False Positive)을 필터링하고, 심각도 등급을 부여해 팀이 가장 중요한 것부터 집중하도록 지원한다. 최종 결과는 Claude Code Security 대시보드에 표시되고, 팀은 코드와 제안된 패치를 검토한 후 승인 여부를 결정한다. 아무것도 자동으로 적용되지 않는다. 항상 사람이 최종 판단을 내린다.

4. 현장 PM이 보는 이 상황의 본질

기술 블로그들은 CVE 번호와 CVSS 점수로 이 상황을 설명한다. 하지만 나는 그보다 더 근본적인 이야기를 하고 싶다.

“설정 파일이 실행 파일이 됐다”

이것이 핵심이다.

전통적인 보안 모델에서 개발자는 이렇게 생각했다. “코드가 위험하지, 설정 파일은 그냥 데이터잖아.” 그래서 .json 파일, .yaml 파일, 각종 설정 파일들은 소스 코드에 비해 훨씬 느슨하게 취급됐다.

그런데 AI 에이전트 시대에는 이 전제가 완전히 무너진다.

AI 기반 도구들이 명령을 실행하고, 외부 통합을 초기화하며, 자율적으로 네트워크 통신을 시작하는 능력을 갖추면서, 설정 파일이 사실상 실행 레이어의 일부가 됐다. 위험은 더 이상 신뢰할 수 없는 코드를 실행하는 것에 국한되지 않는다. 이제 신뢰할 수 없는 프로젝트를 여는 것 자체가 위험이다.

PM 입장에서 번역하면: 저장소를 클론하는 행위가 보안 이벤트가 됐다는 뜻이다.

“개발자 워크스테이션이 새로운 전선이다”

개발자 워크스테이션은 크리덴셜이 풍부하고, 신뢰 수준이 높으며, 가시성이 낮은 공간이다. AI 코딩 에이전트가 그 안에서 작동하면서 노출 위험이 증폭되고 있다. Claude Code는 런타임에 25개 이상의 배시 보안 검증기를 갖춘 정교한 보안 엔지니어링을 구현했지만, 공개 레지스트리에 59.8MB 소스 맵을 배포하는 과정에서 기본적인 콘텐츠 체크가 빠져 있었다.

보안은 늘 이렇다. 정교한 내부 방어를 갖추고도, 가장 기본적인 프로세스 실수로 무너지는 것이다.

“AI는 취약점을 찾기도 하고, 만들기도 한다”

이것이 업계가 직면한 가장 불편한 진실이다.

ETH 취리히, UC 버클리, INSAIT의 벤치마크에 따르면, 최고 성능 AI 모델의 솔루션 중 62%가 부정확하거나 보안 취약점을 포함하고 있다. CodeRabbit 분석에서는 AI가 생성한 코드가 인간이 작성한 코드에 비해 XSS 취약점을 도입할 가능성이 2.74배, 안전하지 않은 객체 참조를 도입할 가능성이 1.91배, 전반적으로 보안 문제를 포함할 가능성이 1.57배 높았다.

그리고 Veracode의 분석도 충격적이다. Claude Opus 4.7이 테스트된 코딩 작업의 52%에서 취약점을 도입한 반면, OpenAI 모델들은 약 30%에 그쳤다는 분석 결과가 나왔다.

같은 기술이 500개의 제로데이 취약점을 발견하면서, 동시에 자신이 작성하는 코드의 절반 가까이에 취약점을 심는다.

이것을 어떻게 받아들여야 할까?

5. PM이 현장에서 배워야 할 것들

자, 이쯤 되면 “그래서 어떻게 하라는 거야?”라는 질문이 나올 차례다.

나는 기술적 대응책은 보안 전문가들에게 맡기겠다. 내가 말하고 싶은 건, 프로젝트 관리자와 팀 리더가 이 상황을 어떻게 읽고 대응해야 하는가다.

① AI 도구 도입에도 ‘게이트웨이 리뷰’가 필요하다

새로운 기술을 팀에 도입할 때, 우리는 보통 기능성과 생산성에 집중한다. “이게 얼마나 빠른가”, “얼마나 편한가”. 그런데 이제는 거기에 하나를 더 추가해야 한다. “이게 우리 공격 표면을 얼마나 넓히는가.”

Claude Code처럼 고도의 에이전트형 도구는 그 자체로 리스크 아이템이 된다. 도입 결정 자체가 보안 리뷰를 거쳐야 하는 이유다.

② 개발자 환경이 프로젝트 리스크 레지스터에 들어와야 한다

전통적인 프로젝트 리스크는 일정 지연, 범위 변경, 핵심 자원 이탈 같은 것들이다. 이제 거기에 하나를 더 추가해야 한다. “개발자 로컬 환경 보안 사고”.

Anthropic의 API 키 유출 사고처럼, 단 한 명의 개발자가 악성 저장소를 클론하는 것만으로 팀 전체의 워크스페이스 데이터가 위험에 처할 수 있다. 이건 개인의 실수가 아니라, 시스템 설계의 문제다.

PM이 이 부분을 리스크 레지스터에 포함하지 않으면, 아무도 관리하지 않게 된다.

③ “AI가 작성한 코드”는 별도 검증 레이어가 필요하다

많은 팀이 지금 AI 코딩 도구를 코드 리뷰 없이 사용하거나, 기존 코드 리뷰 프로세스를 그대로 적용하고 있다. 그런데 앞서 봤듯, AI가 생성한 코드는 인간 코드와 다른 패턴의 취약점을 만들어낸다.

이건 개발 프로세스의 변화를 요구한다. AI 생성 코드에 대한 보안 포커스 리뷰 체크리스트를 별도로 만들고, 스프린트 사이클에 통합해야 한다.

④ 도구 업데이트는 보안 이벤트로 취급하라

모든 보고된 취약점은 패치가 완료됐고, 최신 버전을 실행하는 것이 가장 효과적인 보호 방법이다. 그런데 많은 팀이 도구 업데이트를 “개발자 각자가 알아서” 하는 개인 업무로 취급한다.

이건 잘못됐다. 주요 AI 개발 도구의 버전 업데이트는 팀 단위의 일정을 잡아서 일괄 진행해야 한다. 업데이트 전 릴리즈 노트의 보안 섹션을 반드시 확인하는 프로세스도 필요하다.

⑤ “신뢰하되 검증하라”는 이제 “검증한 뒤 신뢰하라”로

클론한 저장소, 특히 풀 리퀘스트나 포크에서 가져온 것들에 대해서는 CLAUDE.md 파일을 감사하라. MCP 서버는 npm 의존성처럼 취급하라 — 검증하고, 버전을 고정하고, 변경사항을 모니터링하라. 클로드 코드 버전을 고정하고 바이너리 해시를 검증하라.

이 모든 것이 개발자 개인의 책임이 아니다. 팀의 표준 운영 절차(SOP)로 문서화되어야 한다. 그리고 그 SOP를 만드는 건 PM의 몫이다.

6. 더 큰 그림 — AI 시대의 보안 패러다임 전환

이 모든 사건들을 보면서 내가 가장 주목한 것은 개별 취약점이 아니다. 지금 진행 중인 패러다임의 전환이다.

소프트웨어 공급망의 경계가 사라지고 있다

2025년 한 해에만 전체 조직의 65%가 소프트웨어 공급망 공격의 피해를 입었다고 인정했다. 클라우드 보안 회사 Zscaler의 분석에 따르면, Trivy 보안 스캐너 프로젝트, 널리 사용되는 Axios 자바스크립트 패키지, 그리고 Anthropic의 Claude Code 소스 코드 유출까지 — 10일 사이에 일어난 공격들이 소프트웨어 공급망의 위협을 단적으로 보여준다.

AI 개발 도구의 확산은 이 공급망 공격의 반경을 기하급수적으로 넓히고 있다. 하나의 악성 MCP 서버, 하나의 악성 저장소, 하나의 트로이 목마 npm 패키지가 수만 명의 개발자를 동시에 감염시킬 수 있다.

AI가 보안의 방패와 창을 동시에 쥐고 있다

AI 에이전트가 공격자들의 취약점 발견을 자동화하는 것처럼, 같은 능력이 방어자들에게 이점을 제공하고 보안 기준선을 높이는 방향으로 활용될 수도 있다. 이것이 Claude Code Security를 만든 이유다. 세계 코드의 상당 부분이 가까운 미래에 AI에 의해 스캔될 것으로 예상되며, 이는 AI가 오랫동안 숨겨진 버그와 보안 문제를 찾는 데 얼마나 효과적이 됐는지를 보여준다.

이건 단순한 기술 트렌드가 아니다. 공격과 방어가 동일한 AI 기술을 기반으로 경쟁하는 새로운 시대의 개막이다.

사람이 최후의 방어선이다

Claude Code Security가 찾아낸 취약점에 대해 어떤 것도 자동으로 적용되지 않는다. Claude Code Security는 문제를 찾고 해결책을 제안하지만, 항상 개발자가 최종 판단을 내린다.

Anthropic이 이 원칙을 강조하는 데는 이유가 있다. AI가 아무리 강력해도, 최종 의사결정권자는 사람이어야 한다는 것이다. 이건 기술의 한계를 인정하는 동시에, 인간의 판단력과 책임감을 강조하는 태도다.

7. 앞으로 어디로 가는가 — 프로젝트 관리자의 전망

지금 이 순간에도 Claude Code는 발전하고 있고, 위협도 함께 진화하고 있다. 내가 보기엔 앞으로 몇 가지 방향이 명확하다.

첫째, AI 보안 거버넌스가 표준이 될 것이다. 지금은 일부 선진 기업만이 AI 도구 도입에 보안 거버넌스 프레임워크를 적용하고 있다. 하지만 사고 사례가 쌓이면서, 이는 업계 표준이 될 것이다. OWASP는 이미 에이전트형 애플리케이션을 위한 Top 10 위협 목록을 발표했다. 규제 기관도 뒤따를 것이다.

둘째, 보안 역할이 분화될 것이다. “AI 보안 엔지니어”라는 역할이 독립적인 전문 직군으로 자리잡을 것이다. MCP 서버 취약점, 프롬프트 인젝션, 에이전트 공급망 공격을 다루는 전문성은 기존 보안 엔지니어링과 다른 기술 스택을 요구한다.

셋째, PM은 기술 리스크 관리의 중심으로 이동해야 한다. 예전에는 PM이 일정과 예산을 관리했다. 이제는 거기에 기술 리스크, 특히 AI 도구 도입에 따른 보안 리스크 관리가 핵심 역량으로 추가되고 있다. 이걸 개발팀이나 보안팀에만 떠넘기면 안 된다. PM이 직접 이해하고, 팀과 함께 프로세스를 만들어야 한다.

마치며 — 도구를 무서워하지 말고, 제대로 알아야 한다

처음에 슬랙으로 질문을 던진 그 개발팀 리드에게 나는 이렇게 답했다.

“써도 돼. 단, 알고 써야 해.”

Claude Code는 강력한 도구다. 그 강력함이 생산성의 원천이기도 하고, 위험의 원천이기도 하다. 이걸 모르고 쓰는 것과, 알고 쓰는 것은 완전히 다른 이야기다.

보안 취약점이 있었다는 사실은 도구를 버릴 이유가 아니다. 자동차에 사고 위험이 있다고 자동차를 쓰지 않는 사람은 없다. 대신 안전벨트를 하고, 교통법규를 지키고, 방어 운전을 한다.

AI 코딩 도구도 마찬가지다. 도구가 가진 공격 표면을 이해하고, 팀의 운영 절차에 보안 레이어를 덧씌우고, 지속적으로 업데이트와 취약점 공시를 모니터링하는 것. 이게 현장에서 답이다.

그리고 그 답을 찾아서 팀 전체가 실행하도록 만드는 것, 그게 우리 PM의 역할이다.

📋 빠른 참고: Claude Code 보안 사건 요약표

구분	CVE / 사건	위험도	패치 버전	영향
취약점 1	CVE-2025-59536	CVSS 8.7 (High)	v1.0.111 (2025.10)	Hook을 통한 원격 코드 실행
취약점 2	CVE-2026-21852	CVSS 5.3 (Medium)	v2.0.65 (2026.01)	API 키 탈취 / 트래픽 리디렉션
소스코드 유출	npm v2.1.88	전략적 위험	v2.1.89+	513,000줄 TypeScript 공개 노출
MCP 설계 결함	아키텍처 수준	구조적 위험	미패치 (Anthropic 거부)	1.5억+ 다운로드 영향

🔐 현장 체크리스트 — 팀에 바로 공유 가능

Claude Code를 최신 버전(v2.1.89+)으로 업데이트했는가?
npm 대신 공식 네이티브 인스톨러를 사용하고 있는가?
클론 전 저장소의 .claude/ 폴더를 검사하는 습관이 팀에 있는가?
MCP 서버를 npm 의존성처럼 심사/버전 고정하고 있는가?
Anthropic API 키를 주기적으로 로테이션하고 있는가?
AI 도구 도입 시 보안 리뷰 게이트웨이 프로세스가 있는가?
AI 생성 코드에 대한 별도 보안 리뷰 체크리스트가 있는가?
Anthropic 보안 공시(Security Advisory)를 정기적으로 구독/모니터링하는가?

이 글은 실제 현장에서 AI 도구를 도입하고 운영하는 IT 프로젝트 관리자의 시각으로 작성됐습니다. 기술적 세부사항은 Check Point Research, Zscaler ThreatLabz, OX Security, Snyk, Anthropic 공식 발표 등 1차 소스를 기반으로 정리했습니다.

보안 취약점 정보는 지속적으로 업데이트되므로, Anthropic 공식 보안 공시 페이지와 CVE 데이터베이스를 정기적으로 확인하시기 바랍니다.