코딩 어시스턴트가 패키지를 지어내면, 공격자가 먼저 등록한다

AI 코딩 어시스턴트에게 import 정리를 요청하면 존재하지 않는 패키지 이름을 알려줄 수 있습니다. 그 이름은 그럴듯해 보일 것입니다. 실제 도구 두 개를 조합하거나, 여러분이 알아볼 수 있는 명명 규칙을 따를 것입니다. 설치 명령을 붙여 넣었는데 누군가 이미 그 이름을 등록해 두었다면, 여러분은 그 사람이 게시한 것을 그대로 설치한 셈입니다.

보안 연구자들은 이를 슬롭스쿼팅(slopsquatting)이라고 부릅니다. 이는 타이포스쿼팅의 친척 격인데, 공격자가 여러분의 오타를 필요로 하지 않는다는 점이 다릅니다. 그들은 모델이 무엇을 지어내는 경향이 있는지만 알면 되고, 그런 다음 가장 먼저 그 이름을 선점하면 됩니다.

규모는 일화로 치부할 수 없다

2025년 USENIX Security 연구에서는 16개의 코드 생성 모델을 Python과 JavaScript로 된 576,000개의 코드 샘플에서 테스트했습니다. 그 결과 어떤 레지스트리에도 존재하지 않는 205,000개 이상의 고유 패키지 이름이 발견되었습니다. 환각 비율은 상용 모델의 경우 최소 5.2%, 오픈소스 모델의 경우 21.7%였습니다. 2026년 후속 연구에서는 더 새로운 프런티어 모델 5개를 테스트했고 4.62%에서 6.10% 사이의 비율을 측정했는데, 이는 더 낮지만 테스트된 모든 모델에서 여전히 나타났습니다.

이 특이점을 공격 표면으로 바꾸는 부분은 반복 가능성입니다. 연구자들이 동일한 프롬프트를 다시 실행했을 때, 환각된 이름의 상당 부분이 매번 다시 나타났습니다. 모델은 무작위로 추측하는 것이 아닙니다. 같은 훈련 데이터에서 같은 패턴을 학습했기 때문에 같은 오답으로 수렴합니다. 바로 그 예측 가능성이 취약점입니다. 공격자는 같은 프롬프트를 실행해 반복되는 이름을 수집하고, 누구보다 먼저 등록할 수 있습니다.

2026년 연구에서는 테스트된 5개 모델 모두가 존재하지 않는데도 생성한 127개의 패키지 이름을 확인했으며, 레지스트리 보호 조치가 적용된 후에도 53개는 여전히 등록 가능한 상태였습니다.

실제 패키지, 실제 설치

이미 벌어진 일입니다. 2026년 초, 연구자들은 react-codeshift라는 패키지가 237개의 GitHub 저장소에서 참조되고 있는 것을 발견했습니다. 이 이름은 실제 도구인 jscodeshift와 react-codemod를 섞은 것입니다. 한 번도 게시된 적이 없었습니다. 가상의 패키지를 포함한 AI 생성 스킬이 복사되고 포크되면서 그 참조가 스스로 퍼져 나갔습니다.

npm의 metro-evaluator라는 패키지는 2025년 12월에 게시된 네 개 버전에 악성 코드를 담고 있었고, 닷새 후 삭제되어 보안 자리표시자로 대체되었습니다. 테스트된 모델들은 그 이름을 열 번 제안했습니다. 또 다른 패키지인 unused-imports는 실제 eslint-plugin-unused-imports를 모방했고, 어시스턴트가 그 이름을 가리킨 개발자들로부터 계속 설치를 받았습니다.

더 큰 작전은 보안 업체 Koi Security가 PhantomRaven이라고 부르는 캠페인으로, 적어도 2025년 8월부터 활동 중입니다. Koi는 이 캠페인에 126개의 악성 npm 패키지와 86,000회 이상의 다운로드를 귀속시킵니다. 여기서의 수법은 환각된 이름과 다릅니다. package.json은 깨끗해 보이며, 때로는 로그 한 줄 정도만 담고 있지만, 다른 npm 패키지가 아니라 일반 HTTP URL에 호스팅된 의존성을 가리킵니다. 대부분의 스캐너는 원시 URL을 따라가지 않으므로, npm 토큰, GitHub 자격 증명, CI 비밀을 수확하는 페이로드가 설치 시점에 보이지 않게 로드됩니다. Endor Labs는 2025년 11월과 2026년 2월 사이에 같은 캠페인의 추가 물결 세 건을 기록했으며, 약 50개의 일회용 계정을 통해 업로드된 88개의 패키지가 더해졌습니다.

레지스트리는 대부분의 이름을 차단했지만, 전부는 아니다

연구에는 좋은 소식이 하나 있습니다. 패키지 레지스트리는 모델이 만들어내는 경향이 있는 이름을 차단하는 능력이 더 좋아졌습니다. 유사한 이름을 정규화하고, 금지 목록을 유지하며, 많은 생성 샘플에서 나타나는 패턴을 감시합니다. 2026년 연구가 공유된 환각 이름 127개 목록을 확인했을 때, 대부분은 이미 합법적인 프로젝트와 레지스트리 방어 체계에 의해 선점되거나 차단되어 있었습니다.

문제는 '대부분'이 '전부'는 아니라는 점입니다. 같은 연구에서는 보호 조치가 적용된 후에도 53개의 이름이 여전히 등록 가능한 것을 발견했습니다. 여러 프런티어 모델이 일치하는 등록 가능한 이름 하나만으로도 공격을 구축하기에 충분합니다. 공격자는 개발자가 아니라 모델만 추측하면 되기 때문입니다. 레지스트리 운영자들은 문의 대부분을 닫았지만, 남은 틈은 좁지만 열려 있습니다.

같은 패턴은 이제 패키지 관리자를 넘어 확산되었습니다. 보안 연구자들은 공격자들이 모델이 환각하는 도메인을 등록하고, 에이전트가 만들어낼 가능성이 큰 저장소와 스킬을 등록하는 사례를 문서화했습니다. 각 경우의 메커니즘은 동일합니다. 모델이 그럴듯한 이름을 예측하고, 그 예측을 신뢰하도록 만들어진 시스템이 그에 따라 행동합니다. 에이전트가 닿을 수 있는 모든 새로운 표면은 에이전트가 찾게 될 이름을 심을 또 다른 장소가 됩니다.

에이전트가 상황을 악화시키는 이유

인간 개발자라면 수상한 패키지 이름을 알아차릴 수 있습니다. 에이전트는 그렇지 않습니다. 에이전트는 종종 사람이 명령을 먼저 읽지 않은 채 의존성을 자율적으로 설치합니다. 연구자들은 에이전트가 공격자가 제어하는 패키지 이름을 요청하도록 속이는 프롬프트 주입 기법을 시연했으며, Cursor, Windsurf, GitHub Copilot을 포함한 도구에서 보고된 성공률은 최대 100%에 달했습니다.

그 조합이 위험 프로필을 바꾸었습니다. 환각은 이름을 제공합니다. 에이전트는 실행을 제공합니다. 공격자는 둘이 만나기만 하면 됩니다.

유출 문제도 같은 문제다

보안 업체 Glow의 관련 보고서에 따르면 에이전트가 300개 이상 조직에서 가져온 13,000개 넘는 내부 이미지를 GitHub에 노출시킨 것으로 나타났습니다. 메커니즘은 평범합니다. 에이전트와 그 사용자가 스크린샷, 다이어그램, 문서를 공개 저장소에 올리며, 때로는 '공개'가 검색 가능하고 영구적이라는 점을 이해하지 못한 채 그렇게 합니다. 개발자를 더 빠르게 만드는 같은 도구가 내부 자료를 가면 안 되는 곳으로 옮기기도 더 쉽게 만듭니다.

두 문제는 같은 근본 원인을 공유합니다. 에이전트는 틀렸거나(환각된 이름) 민감한(내부 스크린샷) 지침에 대해 기계 속도로 행동합니다. 의도와 행동 사이에 있던 인간의 확인 지점을 에이전트가 바로 제거하는 것입니다.

실제로 해야 할 일

방어책은 복잡하지 않으며, 위협이 얼마나 빠르게 움직였는지를 생각하면 이는 좋은 소식입니다.

에이전트가 생성하는 모든 설치 명령을 신뢰할 수 없는 입력으로 취급하세요. 설치하기 전에 패키지가 존재하는지 확인하세요. 얼마나 오래되었는지 확인하세요. 등록된 환각 이름은 최근에 만들어진 것일 가능성이 큽니다. 게시자에게 이력이 있는지 확인하세요. npm과 PyPI의 경우 빠른 메타데이터 조회로 세 가지 질문 모두 몇 초 만에 답할 수 있습니다.

에이전트가 의존성을 추가하기 전에 사람의 승인을 요구하세요. 이것이 단일 최고 가치의 변경입니다. 환각된 이름, 악성 등록, 프롬프트 주입 요청을 한 번에 잡아내기 때문입니다. 에이전트는 조금 느려지지만, 가장 큰 구멍은 막힙니다.

에이전트의 접근 범위를 작게 유지하세요. 코딩 에이전트에는 저장소 접근 권한이 필요하지만, 프로덕션 자격 증명은 거의 필요하지 않으며, 확인 없이 패키지 관리자가 사설 레지스트리를 가리키게 해서는 안 됩니다. Socket과 Snyk 같은 도구는 IDE나 CI 파이프라인 안에서 레지스트리 조회를 자동화할 수 있으며, 팀이 여러 저장소에서 에이전트를 사용하기 시작했다면 그 비용을 들일 가치가 있습니다.

불편한 점은 이 중 어느 것도 패치로 고쳐지는 버그가 아니라는 것입니다. 환각은 이 모델들이 텍스트를 예측하는 방식에 내재되어 있습니다. 모델은 검증된 이름이 아니라 다음으로 그럴듯한 이름을 생성합니다. 해결책은 모델 주변의 워크플로에 있어야 하며, 이는 대부분의 팀이 이번 주에 시작할 수 있는 프로세스입니다.