AI가 추천한 패키지가 존재하지 않는다면
AI 코딩 도구에게 "이미지 리사이징 라이브러리 추천해줘"라고 물었습니다. AI는 자신감 있게 패키지 이름을 알려주고, 설치 명령어까지 친절하게 작성해줍니다. 그런데 그 패키지가 실제로는 존재하지 않는다면 어떨까요?
**슬롭스쿼팅(Slopsquatting)**은 AI 코딩 도구의 "환각(hallucination)" 현상을 악용한 새로운 형태의 소프트웨어 공급망 공격입니다. AI 모델은 때때로 실제로 존재하지 않는 패키지 이름을 마치 실존하는 것처럼 추천합니다. 공격자는 이 점을 노립니다. AI가 반복적으로 추천하는 가짜 패키지 이름을 파악한 뒤, npm이나 PyPI 같은 패키지 레지스트리에 해당 이름으로 악성 패키지를 먼저 등록해 둡니다.
개발자가 AI의 추천을 믿고 npm install 또는 pip install을 실행하는 순간, 악성 코드가 개발 환경에 설치됩니다.
비유하자면 이런 상황입니다. AI에게 "좋은 약국 추천해줘"라고 물었더니 "OO약국에 가세요"라고 답했습니다. 그런데 그 약국은 실제로 존재한 적이 없고, 공격자가 그 이름으로 가짜 약국을 차려놓고 기다리고 있었던 것입니다. 문을 열고 들어가는 순간, 이미 늦습니다.
얼마나 심각한가
이 문제의 규모는 생각보다 큽니다. 연구진이 16개 AI 코딩 모델을 대상으로 테스트한 결과, 756,000개의 코드 샘플 중 약 20%에서 환각 패키지명이 발견되었습니다. 다섯 번 중 한 번꼴로 AI가 존재하지 않는 패키지를 추천한 셈입니다.
현재 97% 이상의 개발자가 AI 코딩 도구를 사용한 경험이 있다고 응답합니다. GitHub Copilot, ChatGPT, Claude 등 AI 코딩 보조 도구는 이미 개발 워크플로우의 핵심이 되었습니다. 그만큼 슬롭스쿼팅의 잠재적 피해 범위도 넓습니다.
슬롭스쿼팅은 기존에 알려진 **타이포스쿼팅(typosquatting)**의 AI 시대 버전이라 할 수 있습니다. 타이포스쿼팅이 개발자의 오타를 노렸다면, 슬롭스쿼팅은 AI의 환각을 노립니다. 사람의 실수가 아니라 AI의 실수를 공격 벡터로 활용한다는 점에서 더 체계적이고 예측 가능한 공격이 됩니다.
악성 패키지가 설치되면 피해는 다양한 형태로 나타납니다. 환경 변수에 저장된 API 키와 자격증명이 외부로 유출될 수 있고, 백도어가 설치되어 원격 접근이 가능해질 수 있습니다. 더 나아가 해당 프로젝트를 의존하는 다른 프로젝트로까지 악성 코드가 전파되는 공급망 연쇄 감염이 발생할 수 있습니다.
왜 막기 어려운가
슬롭스쿼팅이 특히 방어하기 어려운 이유는 세 가지입니다.
첫째, AI마다 환각 패턴이 다릅니다. 같은 질문을 해도 모델에 따라, 심지어 같은 모델이라도 시점에 따라 다른 가짜 패키지명을 생성합니다. 어떤 이름이 환각인지 사전에 목록화하기가 매우 어렵습니다. 공격자 입장에서는 여러 AI 모델에 반복적으로 질문하며 자주 등장하는 환각 패키지명을 수집할 수 있지만, 방어자 입장에서는 이를 전부 예측하기가 현실적으로 불가능합니다.
둘째, 패키지 레지스트리의 등록 장벽이 낮습니다. npm, PyPI 등 주요 패키지 저장소는 누구나 원하는 이름으로 패키지를 등록할 수 있습니다. 별도의 신원 검증이나 코드 리뷰 과정이 없기 때문에, 공격자가 환각 패키지명을 선점하는 데 걸리는 시간은 몇 분에 불과합니다.
셋째, 환각으로 생성된 패키지명이 그럴듯합니다. AI는 기존 패키지의 네이밍 패턴을 학습했기 때문에, 환각 패키지명도 실제 존재할 법한 형태를 띱니다. flask-auth-utils, react-data-helpers 같은 이름을 보면 "당연히 있을 것 같은" 느낌이 들어 개발자가 의심 없이 설치하게 됩니다.
지금 할 수 있는 대응법
슬롭스쿼팅으로부터 프로젝트를 보호하기 위해 지금 바로 실천할 수 있는 방법이 있습니다.
1. AI가 추천한 패키지는 반드시 직접 확인합니다.
AI가 알려준 패키지명을 복사해서 바로 설치하지 마세요. npm 공식 사이트(npmjs.com)나 PyPI(pypi.org)에서 해당 패키지를 직접 검색하세요. 검색 결과가 없거나, 이름은 있지만 내용이 빈약하다면 설치를 중단해야 합니다.
2. 패키지의 신뢰도 지표를 확인합니다.
패키지가 존재하더라도 바로 신뢰해서는 안 됩니다. 주간 다운로드 수가 극단적으로 적거나, 마지막 업데이트가 최근이면서 버전이 0.0.1인 경우, 유지보수자 프로필에 다른 프로젝트가 없는 경우는 주의 신호입니다. 정상적인 패키지라면 일정 수준의 커뮤니티 활동과 업데이트 이력이 있습니다.
3. lockfile과 의존성 감사 도구를 활용합니다.
package-lock.json이나 requirements.txt 같은 lockfile을 반드시 버전 관리에 포함시키세요. 이를 통해 의도하지 않은 패키지 변경을 추적할 수 있습니다. 또한 npm audit이나 pip-audit 같은 의존성 감사 도구를 정기적으로 실행하여 알려진 취약점이 있는 패키지를 조기에 발견하세요.
4. 조직 차원의 프레임워크를 참고합니다.
NIST SP 800-161(사이버 보안 공급망 리스크 관리 프레임워크)은 소프트웨어 공급망 보안에 대한 체계적인 가이드를 제공합니다. 팀이나 조직 단위로 패키지 도입 시 검증 절차를 마련하는 것이 장기적으로 가장 효과적인 방어 수단입니다.
AI 코딩 도구는 개발 생산성을 크게 높여주지만, AI의 출력을 무조건 신뢰하는 것은 새로운 보안 위험을 만들어냅니다. "AI가 추천했으니까 괜찮겠지"라는 가정을 버리고, 설치 전 30초의 확인 습관이 프로젝트 전체를 지킬 수 있습니다.
참고