속도를 올렸더니 구멍이 생겼다
AI-First 워크플로우를 팀에 도입하면 개발 속도는 올라간다. 그건 이미 여러 번 확인된 사실이다. 문제는 속도가 올라가는 만큼 검토 밀도가 떨어진다는 것이다. AI 어시스턴트가 추천한 패키지를 별 의심 없이 설치하고, MCP 서버를 "일단 연결해보고" 나중에 보안을 따지겠다는 팀이 많다. 그 '나중'이 얼마나 위험한지를, 최근 세 가지 사례가 구체적으로 보여주고 있다.
npm 생태계: 신뢰 모델이 무너지고 있다
2025년 9월, ReversingLabs는 npm 생태계 최초의 자기복제 웜을 문서화했다. rxnt-authentication@0.0.3에서 시작된 악성코드는 메인테이너 계정을 탈취하며 수백 개 패키지로 퍼졌다. 두 달 뒤, Datadog이 추적한 'Shai-Hulud 2.0' 캠페인은 주간 다운로드 2천만 건이 넘는 796개 패키지를 백도어로 만들었다.
더 충격적인 건 그다음이다. 메인테이너 Josh Junon(qix)을 노린 피싱 공격은 가짜 npmjs.help 도메인 하나와 설득력 있는 지원 이메일 하나로 퍼블리싱 크리덴셜을 빼냈다. 그 결과 chalk, debug, ansi-styles 등 주간 다운로드 합산 약 26억 건에 달하는 패키지들이 오염됐다. 정교한 익스플로잇이 아니었다. 피싱 메일 한 통이었다.
메커니즘은 간단하다. package.json의 ^2.1.0 같은 버전 범위 표기는 CI가 조용히 최신 패치를 가져오도록 허용한다. preinstall, postinstall 같은 라이프사이클 스크립트는 임포트하기도 전에 실행된다. 공격자 입장에서는 꿈 같은 구조다.
AI 어시스턴트가 공격 표면을 확장한다
dev.to에 게재된 'npm install && pray' 분석은 AI 코딩 어시스턴트가 이 문제를 어떻게 악화시키는지 직설적으로 짚는다. AI가 생성한 코드는 당신이 쓴 코드가 아니다. 당신의 환경을 이해하지 못하는 시스템의 출력물이다. 그 코드가 로컬 권한으로 실행될 때, 버그 하나가 데이터 손실이나 크리덴셜 노출로 이어질 수 있다.
프롬프트 인젝션은 더 직접적인 위협이다. 2025년 8월, 연구자 Johann Rehberger는 Claude Code가 간접 프롬프트 인젝션에 의해 민감한 로컬 파일을 읽고 DNS 요청을 통해 외부로 유출하도록 유도될 수 있음을 시연했다. GitHub도 VS Code와 Copilot 에이전트 모드에서 토큰 노출, 기밀 파일 접근, 사용자 승인 없는 코드 실행 가능성을 공식적으로 경고했다.
공격 표면은 이미 패키지 너머로 확장됐다. 코드, 이슈, PR, 문서, 코멘트—AI 어시스턴트가 컨텍스트로 받아들이는 모든 것이 잠재적 인젝션 벡터다.
MCP 서버: 에이전트 파이프라인의 새로운 구멍
npm 공급망 리스크가 익숙한 문제라면, MCP 서버는 아직 감이 덜 잡혀 있는 영역이다. 팀들은 MCP 서버를 npm 패키지 설치하듯 연결한다. 하지만 나쁜 npm 패키지는 빌드를 망가뜨린다. 나쁜 MCP 서버는 에이전트 안에서 실행된다—당신의 크리덴셜, 데이터, 파일 시스템에 접근하면서.
dev.to에 공개된 공식 MCP 서버 7개에 대한 보안 감사 결과는 구조적 패턴을 드러낸다. Fetch 서버를 제외한 모든 서버가 문자열 파라미터에 제약을 두지 않았다. maxLength도, pattern도, enum도 없다. Git 서버에는 제약 없는 문자열 파라미터가 18개다. SQLite 서버는 무제한 길이의 SQL 쿼리를 받는다. 심각한 취약점은 발견되지 않았지만, 이 구멍들은 프롬프트 인젝션이 성공했을 때 LLM이 보낸 조작된 입력을 그대로 통과시킨다.
수정 비용은 낮다. 파라미터 하나당 한 줄이면 된다. "maxLength": 1000 한 줄, "pattern": "^[A-Za-z_/]+$" 한 줄. 문제는 기술이 아니라 습관이다.
커뮤니티 MCP 서버는 더 위험하다
공식 서버가 이 정도라면, 커뮤니티 서버는 어떨까. dev.to의 'MCP 서버 연결 전 평가 체크리스트' 분석은 외부 데이터를 인용하며 규모를 보여준다. Equixly의 공격적 보안 분석에 따르면 MCP 서버의 43%가 커맨드 인젝션에 취약하다. Endor Labs가 2,614개 MCP 구현을 분석한 결과 82%가 경로 순회에 취약한 파일 작업을 사용한다. Astrix Security가 5,200개 이상의 공개 MCP 서버 리포를 감사한 결과 53%가 만료 없고 스코프 제한도 없는 정적 API 키나 개인 액세스 토큰에 의존한다.
Pynt의 연구 결과는 더 직접적이다. MCP 플러그인 10개를 체이닝하면 성공적인 익스플로잇 확률이 92%에 달한다. 멀티 에이전트 파이프라인을 설계하는 팀이 특히 주목해야 하는 수치다.
팀이 지금 당장 실행할 수 있는 것들
이 문제는 도구 선택의 문제가 아니다. 워크플로우 설계의 문제다. 내일부터 팀에 적용할 수 있는 기준 몇 가지를 정리한다.
npm 측면:
- 버전 범위를 ^에서 정확한 버전으로 고정하고, 업데이트는 의도적인 검토 이후에만 허용한다.
- ignore-scripts 플래그로 라이프사이클 스크립트 자동 실행을 차단한다.
- AI 어시스턴트가 추천한 패키지도 신규 의존성과 동일한 검토 프로세스를 거친다. AI가 권장했다는 사실이 신뢰의 근거가 될 수 없다.
MCP 서버 측면: - 연결 전에 툴 정의를 직접 읽는다. 소스를 열고, 파라미터 제약 조건을 확인하고, 스코프를 따진다. - 정적 API 키를 사용하는 서버는 스코프 제한과 주기적 교체 정책을 별도로 설계한다. - 복수의 MCP 서버를 연결할 때는 각 서버의 권한이 어떻게 교차하는지 폭발 반경을 먼저 계산한다. - 버전 이력이 없거나 툴 정의 변경 알림이 없는 서버는 연결을 보류한다.
AI 생성 코드 전반: - AI 생성 코드를 자신이 작성한 코드와 동일한 신뢰 수준으로 실행하지 않는다. 검토하지 않은 코드는 신뢰하지 않은 코드다.
전망: 생태계는 반복한다, 팀은 먼저 움직여야 한다
MCP 감사 기사는 이 패턴을 정확하게 짚는다. 초기 REST API 생태계도 입력 검증 없이 엔드포인트를 배포했고, 익스플로잇이 시작된 후에야 수년에 걸쳐 수정했다. MCP 생태계는 지금 그 역사를 반복하고 있다. 공식 서버가 기준을 세우고, 커뮤니티 서버가 그 기준을 따른다. 지금 그 기준에는 입력 검증이 빠져 있다.
생태계가 성숙해지길 기다리는 것은 팀 단위의 전략이 될 수 없다. AI-First로 전환 속도를 높일수록, 공격자가 노릴 표면도 함께 넓어진다. npm 피싱 한 통이 26억 다운로드 파이프라인을 오염시킨 것처럼, MCP 서버 하나의 툴 정의 변경이 에이전트 전체를 오염시킬 수 있다.
속도와 보안은 트레이드오프가 아니다. 검토 프로세스 없이 속도만 올리면, 그 차이는 결국 사고 이후의 비용으로 돌아온다. 팀이 먼저 움직여야 하는 이유가 거기 있다.