AI가 추천한 패키지, 믿어도 될까? 슬롭스쿼팅: AI 환각이 만들어낸 치명적인 공급망 공격
2026. 7. 29.
AI가 추천한 패키지, 믿어도 될까? 슬롭스쿼팅: AI 환각이 만들어낸 치명적인 공급망 공격
타이포스쿼팅(Typosquatting)은 개발자의 오타를 노립니다. 하지만 슬롭스쿼팅(Slopsquatting)은 당신의 AI 어시스턴트를 노리죠. AI 모델이 실제로는 존재하지 않는 가상의 패키지 이름을 뱉어내면, 공격자는 그 이름을 선점해 등록하고 개발자가 install 명령어를 실행하기만을 기다립니다. 이 글에서는 슬롭스쿼팅의 치명적인 공격 흐름(kill chain)은 물론, 왜 기존 방어 체계로는 이를 막기 어려운지, 그리고 npm, Composer, pip 생태계에서 실제로 어떤 방법으로 이 위협을 저지할 수 있는지 심도 있게 다뤄보겠습니다.
상상해 보세요. 코딩 어시스턴트가 이런 명령어를 실행하라고 알려줍니다.
pip install requests-oauth2-helper
언뜻 보면 전혀 이상할 게 없습니다. requests 호출에 OAuth2 토큰을 깔끔하게 붙이는 방법을 물었고, 패키지 이름 역시 그 역할을 할 법하게 생겼으니까요. 작명 규칙도 파이썬 생태계의 관용적인 방식을 따르고, 하이픈 사용도 자연스러워서 PyPI에 있는 수십 가지 다른 헬퍼 패키지들처럼 보입니다. 그래서 아무 생각 없이 명령어를 실행하죠. 테스트는 통과하고, 당신은 다음 작업으로 넘어갑니다.
문제는 requests-oauth2-helper라는 패키지가 모델이 이 이름을 추천했을 당시에는 아예 존재하지 않았다는 점입니다. 모델이 말 그대로 지어낸 이름이죠. 그리고 만약 공격자가 이 상황을 지켜보고 있었다면, 그 이름은 더 이상 비어있지 않을 겁니다.
이것이 바로 슬롭스쿼팅입니다. 타이포스쿼팅의 핵심이었던 '인간의 오타' 대신, '기계의 환각(hallucination)'을 이용하는 공급망 공격이죠. 이 용어는 Python Software Foundation의 개발자 레지던트 Seth Larson이 처음 만들었고, 2025년 Ecosyste.ms의 Andrew Nesbitt에 의해 널리 알려졌습니다. 작은 아이디어 같지만, 그 파급력은 매우 지독합니다. 더 이상 reqeusts처럼 오타를 낼 필요가 없어진 겁니다. AI가 아무렇지 않게 가짜 패키지를 건네줄 테고, 당신은 자신의 오타보다 AI의 추천을 더 신뢰하게 될 테니까요. 제가 실무에서 AI 코드 추천을 활용하면서도 늘 경계하는 부분이 바로 이런 '맹목적인 신뢰'입니다. 생산성 향상만큼이나 검증 과정의 중요성이 커지고 있죠.
타이포스쿼팅은 '당신의 실수'를 필요로 했지만, 슬롭스쿼팅은 그렇지 않습니다
타이포스쿼팅은 오래된 수법입니다. express 옆에 expres를, python-dateutil 옆에 python-dateutl을 등록해 두고 누군가 손가락을 미끄러뜨리길 기다리는 거죠. 효과는 있지만, 확률 게임에 가깝습니다. 대부분의 개발자는 express를 정확히 타이핑하니까요. 공격자는 정확히 타이핑하지 않는 아주 작은 비율의 사람들을 낚는 겁니다.
슬롭스쿼팅은 이러한 '인간의 실수'에 대한 의존성을 완전히 제거합니다. 개발자는 문자를 정확히, 글자 하나하나 정확하게 복사해서 타이핑하죠. 왜냐고요? 지금 당장은 자신보다 더 신뢰하는 출처, 즉 방금 주변 코드를 작성해 준 AI 어시스턴트에게서 복사하는 것이기 때문입니다. 실수는 이미 상위(모델)에서 발생했고, 인간은 그 실수를 충실히 재현하고 있는 셈입니다.
여기서 중요한 변화가 발생합니다. 타이포스쿼팅에서 공격자는 '당신의 손가락이 어떤 오타를 낼지' 추측합니다. 하지만 슬롭스쿼팅에서 공격자는 전혀 추측할 필요가 없습니다. 그들은 모델이 대규모로 실제로 어떤 출력을 내는지 읽고, 등장하는 이름을 등록합니다. 모델이 그들을 위해 타겟을 선별해 주고 있는 거죠.
왜 이 공격이 통하는가: 환각은 잦고, 심지어 반복되기까지 합니다
만약 모델의 환각이 드물고 무작위적이라면, 슬롭스쿼팅은 그저 작은 주석(footnote)에 불과했을 겁니다. 가짜 이름을 등록하고, 영원히 기다리다 아무도 잡지 못하는 상황이죠. 하지만 이것이 실제 위협이 되는 이유는 환각이 '드물거나 무작위적이지 않기' 때문입니다.
먼저 그 규모를 살펴보죠. 2025년 USENIX Security 학회에서 발표된 *“We Have a Package for You!”*라는 연구는 파이썬과 자바스크립트 분야의 16개 LLM(대규모 언어 모델)에서 576,000개의 코드 샘플을 생성하고, 모델이 추천한 모든 패키지를 확인했습니다. 결과는 충격적입니다. 추천된 패키지의 19.7%가 존재하지 않았습니다. 이것은 벤치마크 오차 범위의 반올림이 아닙니다. 무려 5개 중 1개 꼴입니다. 연구에서는 205,474개의 고유한 환각 패키지 이름이 기록되었습니다. 상업용 모델은 상대적으로 더 나았지만(평균 5.2% 이상), 오픈소스 모델은 더 심각했습니다(평균 21.7% 이상). 완벽하게 깨끗한 모델은 없었습니다.
만약 모든 환각이 '하나뿐인 눈송이'처럼 고유하다면, 여전히 문제는 관리 가능한 수준이었을 겁니다. 공격자가 20만 개의 이름을 모두 등록할 수도 없고, 어떤 이름이 다시 등장할지 알 수 없기 때문이죠. 하지만 결정적인 발견은 환각이 **재현 가능(reproducible)**하다는 사실입니다. 연구자들은 가짜 패키지를 생성한 프롬프트 500개를 가져와 각각 10번씩 더 실행했습니다. 그 결과, 환각 패키지의 43%가 매번 다시 등장했습니다. 58%는 한 번 이상 나타났고, 39%만이 다시 나타나지 않았습니다.
이 수치에 잠시 집중해 보세요. 거의 절반에 달하는 이러한 패키지 조작이 단순한 노이즈가 아니라, '모델의 안정적인 행동'이라는 겁니다. 이는 경제적인 관점에서 상황을 완전히 뒤바꿔 놓습니다. 공격자는 모든 이름을 등록할 필요가 없습니다. 모델의 출력을 분석하고, 반복적으로 나타나는 이름을 걸러낸 다음, '끈적한(sticky)' 이름들만 등록하면 됩니다. 재현 가능성이 바로 정찰(reconnaissance) 활동이 되는 거죠. 모델이 미래의 개발자에게 어떤 가짜 이름을 건네줄 가능성이 가장 높은지 공격자에게 계속해서 알려주는 줍니다.
주의 이름이 실제 패키지와 비슷할 필요조차 없습니다. 같은 연구에서 레벤슈타인 거리(Levenshtein distance)를 사용해 분석한 결과, 환각된 이름 중 오직 13%만이 실제 패키지의 단순한 오타였습니다. 약 38%는 중간 정도의 유사성을 보였고, 거의 절반은 전혀 유사성이 없었습니다. 즉, 완전히 조작된 이름이지만, 주변 코드의 맥락에서는 여전히 그럴듯하게 보인다는 뜻이죠. 바로 이 마지막 범주가 타이포스쿼팅 탐지 시스템을 그대로 통과하며, 그 이유는 다시 살펴보겠습니다.
공격 흐름(Kill Chain), 한 단계씩 살펴보죠
이 모든 것은 이론적인 이야기가 아닙니다. 깔끔하고 반복 가능한 시퀀스이며, 모든 단계는 우리가 평범한 업무 중에 흔히 겪는 일들로 구성되어 있습니다.
1. 모델이 임포트를 제안합니다. 당신이 특정 기능을 요청합니다. 어시스턴트는 코드를 작성하고, 문제의 형태에 맞는 의존성 패키지를 찾습니다. 그리고는 이름을 내뱉습니다. 이 이름은 모델이 지어낸 것이지만, 문법적으로는 완벽합니다. 올바른 생태계 규칙, 적절한 대소문자 표기, "뭔가 존재하는 것 같은" 느낌까지요.
2. 이름이 적절해 보이기 때문에 당신은 그것을 신뢰합니다. 이것이 핵심 단계이며, 기술적이라기보다는 심리적인 문제입니다. 자신감 있는 AI의 출력은 마치 노련한 선배 개발자의 PR(Pull Request)처럼 당신의 경계심을 자연스럽게 무너뜨립니다. 패키지 이름은 관용적입니다. 어떤 것도 '위험' 신호로 감지되지 않습니다. 당신은 코드의 로직을 검토하지, 네 단어짜리 패키지 이름이 진짜인지 감사하지 않습니다. 누가 그렇게 하겠어요? 제가 실무에서 동료들과 나눈 이야기 중에도, AI가 제안한 코드를 그대로 복붙했다가 작은 버그를 겪은 사례가 꽤 많습니다. 하물며 보안에 관련된 부분은 더욱 신중해야 할 텐데 말이죠.
3. 설치 과정에서 코드가 실행됩니다. npm과 pip의 경우, 패키지를 설치하는 것만으로도 스크립트가 자동으로 실행될 수 있습니다. postinstall 훅이나 setup.py 빌드 단계 등이 그렇죠. 공격자의 페이로드는 당신이 무엇을 임포트하거나 함수를 호출할 필요가 없습니다. install이 완료되는 순간, 이미 코드는 실행된 겁니다.
4. 자격 증명이 유출됩니다. 페이로드는 빌드 에이전트가 항상 가지고 있는 것들을 읽어들입니다. 환경 변수, ~/.aws/credentials, ~/.npmrc 토큰, GITHUB_TOKEN, .env 파일 등이죠. 그리고는 공격자가 제어하는 엔드포인트로 이 정보들을 POST 요청을 통해 보냅니다. 외부에서 보기에는 패키지가 설치 중에 메타데이터를 가져오는 것처럼 보이지만, 내부적으로는 당신의 CI/CD가 낯선 사람에게 모든 열쇠를 넘겨준 상황인 겁니다.
이 모든 과정은 소름 끼치도록 조용하게 진행됩니다. 익스플로잇도, CVE도, 교묘한 메모리 손상도 없습니다. 개발자가 그저 패키지 이름을 신뢰하고 하루에도 50번씩 실행하는 표준 설치 명령어를 실행했을 뿐입니다. 공격의 전부가 바로 이것입니다.
그리고 사람들이 이 '신뢰' 단계에 빠져드는 것이 가설에 불과한 것도 아닙니다. Lasso Security의 보안 연구원 Bar Lanyado는 모델들이 huggingface-cli라는 파이썬 패키지를 반복적으로 환각하는 것을 발견했습니다. 그는 실험 목적으로 PyPI에 해당 이름으로 빈 패키지를 등록했습니다. 이후 3개월 동안 이 패키지는 15,000회 이상의 실제 다운로드를 기록했으며, 심지어 Alibaba의 GraphTranslator 프로젝트는 README에서 pip install huggingface-cli를 추천하기까지 했습니다. 실제 도구는 pip install -U "huggingface_hub[cli]"로 설치해야 하는데도 말이죠. Lanyado의 패키지는 의도적으로 무해했지만, 슬롭스쿼터의 패키지는 그렇지 않을 겁니다.
동일한 아이디어, 네 가지 생태계, 네 가지 다른 피해 범위
간단히 말해 "JavaScript, PHP, Go 모두 영향을 받는다"고 할 수 있습니다. 하지만 더 정확히 말하면, 각 생태계가 공격자에게 제공하는 '밧줄의 길이'가 다르고, 이 차이를 아는 것이 방어 예산을 어디에 써야 할지 알려줍니다.
npm은 공격자에게 가장 많은 것을 제공합니다. preinstall, install, postinstall 같은 라이프사이클 스크립트는 npm install 시 자동으로 실행됩니다. 이것이 고전적인 공격 벡터이며, 생태계가 마침내 변화하는 이유이기도 합니다. pnpm v10은 2025년 초 의존성 라이프사이클 스크립트를 기본적으로 비활성화했고, npm도 뒤를 따랐습니다. 2026년 6월 발표된 npm v12는 자동 스크립트 실행을 기본적으로 끕니다. 당신이 이 버전들을 사용하기 전까지 postinstall은 당신의 CI/CD를 향한 장전된 총과 같습니다.
package.json (악성 의존성)
{
"name": "requests-oauth2-helper",
"version": "1.0.3",
"scripts": {
"postinstall": "node ./collect.js"
}
}
pip도 거의 npm과 비슷합니다. 소스 배포(source distribution)는 설치 시 setup.py를 실행하여 메타데이터를 계산하고 빌드합니다. 즉, pip install 시 임의의 코드를 실행할 수 있다는 의미입니다. 휠(.whl)은 동일한 방식으로 설치 시 코드를 실행하지 않으므로, --only-binary 옵션은 단순한 편의 기능이 아니라 실제적인 강화 수단입니다.
# 소스 빌드 거부; 미리 빌드된 휠만 허용
pip install --only-binary :all: requests-oauth2-helper
Composer는 설계상 세 가지 중 가장 조용하고 안전합니다. Composer는 루트 패키지의 composer.json에 정의된 스크립트만 실행합니다. 의존성 패키지 자체의 scripts 블록은 무시됩니다. 따라서 슬롭스쿼팅된 Composer 패키지는 npm 패키지가 postinstall을 넘겨주는 방식처럼 자동 post-install-cmd를 당신에게 건네줄 수 없습니다. 한 가지 예외는 플러그인입니다. 악성 Composer 플러그인은 설치 이벤트를 후킹할 수 있으므로, 신뢰할 수 없는 트리에서는 composer install --no-plugins --no-scripts 명령어가 존재합니다. 페이로드는 당신의 코드가 실제로 그것을 호출할 때까지 기다려야 하며, 이는 "설치 시 실행"보다 훨씬 높은 장벽입니다.
Go는 설치 스크립트 자체가 없으므로 공격 흐름이 바뀝니다. go get 및 go build는 패키지를 추가하는 순간 임의의 설정 코드를 실행하지 않습니다. 슬롭스쿼팅된 Go 모듈의 악성 코드는 당신의 프로그램이 그것을 처음 실행할 때, 즉 임포트 시 init() 함수를 통해, 또는 go test 중에 실행됩니다. 나중에 실행되지만, 실행되지 않는 것은 아닙니다.
Go는 모듈 프록시를 통해 고유한 문제를 추가합니다. Socket은 2021년 11월에 업로드된 BoltDB의 백도어 타이포스쿼트 github.com/boltdb-go/bolt를 발견했습니다. 이 패키지는 Go 모듈 미러에 캐시된 후, Git 태그가 깨끗한 코드로 다시 작성되었습니다. 하지만 프록시는 캐시된 악성 버전을 계속 제공했습니다. 3년이 넘도록 감지되지 않았죠. 빌드를 재현 가능하게 만들도록 의도된 캐싱이 오히려 오염된 버전을 영구적으로 만들 수 있다는 겁니다.
따라서 사고방식은 "하나의 공격, 세 가지 언어"가 아닙니다. "npm과 pip은 설치 시 즉시 발사, Composer는 플러그인 또는 호출을 기다림, Go는 실행을 기다리고 나쁜 버전을 영원히 기억함"으로 봐야 합니다. 슬롭스쿼터는 가장 빠르고 조용한 트리거를 제공하는 생태계를 선택할 겁니다.
왜 기존의 공급망 방어 체계는 이를 놓치는가
이제 불편한 진실을 이야기할 차례입니다. 당신이 이미 실행하고 있는 대부분의 통제 수단은 다른 위협 모델을 위해 구축되었으며, 슬롭스쿼팅은 그 틈새를 비집고 들어옵니다.
잠금 파일(Lockfiles)은 첫 설치 후에만 도움이 됩니다. package-lock.json이나 composer.lock은 정확한 버전과 해시를 고정하여 의존성이 당신 모르게 조용히 변경되는 것을 방지합니다. 이것은 이미 검증하고 잠근 패키지에 대해서는 훌륭한 방어책입니다. 하지만 슬롭스쿼팅은 완전히 새로운 이름의 첫 번째 설치를 공격합니다. 당신이 이 패키지를 설치한 적이 없기 때문에 잠금 파일에는 아직 아무것도 없습니다. AI가 30초 전에 막 추천한 패키지죠. 잠금 파일은 당신이 처음 가져온 악성 버전을 충실히 기록하고, 이제 그것이 고정됩니다. 잠금 파일은 연속성을 보호하지, '첫 접촉'을 보호하지 않습니다.
스캐너는 '알려진 악성'을 찾지만, 이것은 '전혀 보지 못한' 것입니다. 취약점 스캐너나 악성코드 피드는 이미 누군가가 플래그를 지정한 패키지와 일치하는지 확인합니다. 어제 등록된 슬롭스쿼팅 패키지는 이번 분기에 막 반복되기 시작한 환각을 노리며, CVE도, 권고도, 평판도, 이력도 없습니다. 부재로 인해 깨끗하게 보이죠. 스캐너가 고장 난 것이 아닙니다. 다른 질문에 답하고 있을 뿐입니다. "이것이 알려진 위협인가?"는 "이것이 인간이 선택한 실제 패키지인가?"와 다른 질문입니다.
타이포스쿼팅 탐지는 편집 거리에 의존하지만, 이 이름들의 절반은 아무것도 닮지 않았습니다. 타이포스쿼팅에 대한 표준 방어는 문자열 유사성을 측정합니다. expres를 express로 바꾸는 데 몇 번의 편집이 필요한지 같은 것을요. 유사한 것들을 플래그 지정합니다. 하지만 레벤슈타인 거리 측정 결과, 환각된 이름의 거의 절반이 실제 패키지와 매우 유사성이 낮다는 것을 기억하세요. requests-oauth2-helper는 실제 패키지에서 한 번의 편집으로 만들어진 것이 아닙니다. 기존 이름을 손상시킨 것도 아닙니다. 그럴듯하게 들리는 완전히 새로운 발명품입니다. 측정할 실제 이웃이 없으니 탐지기가 걸려 넘어질 것도 없습니다.
이 세 가지를 종합해 보면 빈틈의 형태가 보입니다. 이러한 모든 방어 수단은 악성 패키지가 변경되었거나(잠금 파일), 이전에 플래그 지정되었거나(스캐너), 실제와 유사하다고(타이포스쿼팅 탐지) 가정합니다. 슬롭스쿼팅은 이 중 어느 것도 아닙니다. AI가 자신감 있게 선택한, 완전히 새로운 이름이며, 이전에 본 적도 없고, 아무것도 닮지 않았습니다. 방어 수단이 약한 것이 아닙니다. 단지 다른 곳을 겨냥하고 있을 뿐이죠.
실제로 효과 있는 방법: 이름을 맹신하여 저장소에 넣지 마세요
다행스러운 소식은 해결책이 특별하지 않다는 겁니다. 모든 의존성에 적용해야 하는 동일한 원칙이며, 단지 당신이 너무 신뢰하기 시작한 출처(AI)에 적용하는 것뿐입니다. 새로운 제품군이 필요한 것이 아닙니다. AI의 패키지 제안을 '인용'으로 취급하는 것을 멈춰야 합니다.
패키지가 존재하는지, 그리고 꾸준히 관리되는지 당신의 시스템에 닿기 전에 확인하세요. 모델이 건네준 것을 설치하기 전에 반드시 찾아보세요. 레지스트리에 존재하는지? 다운로드 수는 몇 회이고, 버전은 몇 개이며, 마지막 릴리스는 언제였고, 누가 발행하며, 사람이 명확하게 관리하는 레포지토리가 있는지? 슬롭스쿼팅 패키지는 보통 등록된 지 며칠밖에 안 됐고, 의심스러울 정도로 딱 떨어지는 다운로드 수에 이력도 없을 겁니다. 30초만 찾아보면 대부분의 이런 패키지를 걸러낼 수 있습니다.
# npm: 존재하는지, 누가 소유하는지, 얼마나 오래되었는지?
npm view requests-oauth2-helper
# PyPI: 프로젝트 페이지, 릴리스 기록, 관리자 확인
pip index versions requests-oauth2-helper
만약 첫 번째 명령어가 404를 반환한다면, 모델은 숨겨진 보석을 찾아준 것이 아닙니다. 그냥 지어낸 겁니다.
설치 스크립트를 기본적으로 비활성화하세요. 이 단 하나의 통제 수단으로 가장 시끄러운 공격 흐름의 목줄을 잡을 수 있습니다. 자동 실행을 끄고, 실제 빌드 단계가 명시적인 예외가 되도록 하고 기본값이 되지 않도록 하세요.
:::tabs
npm
# 라이프사이클 스크립트를 전역적으로 비활성화; 필요한 극히 드문 패키지만 허용 목록에 추가
npm config set ignore-scripts true
pnpm
# pnpm v10+는 기본적으로 의존성 스크립트를 차단합니다.
# 당신이 실제로 신뢰하는 스크립트만 승인하세요:
pnpm approve-builds
pip
# 미리 빌드된 휠을 선호하여 설치 시 setup.py가 실행되지 않도록 합니다
pip install --only-binary :all: <package>
composer
# 신뢰할 수 없는 트리? 플러그인, 스크립트 모두 비활성화.
composer install --no-plugins --no-scripts
:::
npm 패키지 중 약 2%만이 설치 스크립트를 합법적으로 사용하며, 이것이 바로 생태계가 '기본적으로 비활성화'라는 합리적인 결정을 내린 이유입니다. 당신은 거의 아무것도 잃지 않으면서 페이로드가 의존하던 문을 닫는 겁니다.
모든 것을 허용 목록이 있는 프라이빗 레지스트리를 통해 프록시하세요. 빌드 에이전트가 공용 레지스트리에 접속하여 모델이 이름 붙인 모든 것을 가져올 수 있게 해서는 안 됩니다. 프록시(Artifactory, Verdaccio, private PyPI, Composer의 Satis 등)를 앞에 두고, 검토된 패키지만 허용하십시오. 이제 환각된 이름은 설치 후에 실패하는 것이 아니라, 승인되지 않았기 때문에 설치 전에 실패하게 됩니다. 이것이야말로 확장 가능한 통제 수단입니다. 결정권이 "개발자가 눈치챘는가"에서 "이것이 목록에 있는가"로 이동하기 때문이죠.
새 버전에 대한 '숙성 지연' 시간을 추가하세요. pnpm v11은 minimumReleaseAge를 기본 1440분(24시간)으로 설정하여, 커뮤니티가 명백한 악성코드를 탐지할 만큼 충분히 공개될 때까지 패키지 버전 설치를 거부합니다. 새로운 환각을 잡기 위해 경쟁하는 슬롭스쿼팅 패키지는 바로 이러한 '쿨링오프 기간'이 막아내기 좋은 유형입니다.
그리고 모든 다른 규칙 아래의 단 하나의 규칙: AI가 제안했다고 해서 의존성을 저장소에 절대 맹목적으로 추가하지 마십시오. AI의 패키지 제안은 가설이지 출처가 아닙니다. 한 번도 본 적 없는 계정의 Stack Overflow 답변을 대하는 방식과 똑같이 다루십시오. 맞을 수도 있지만, 확인해야 하며, 절대로 보는 즉시 신뢰해서는 안 됩니다. 전체 공격은 2단계의 '잘못된 신뢰'라는 한순간에 달려 있습니다. 이름을 확인하면 공격은 설 자리를 잃습니다.
불편한 진실은 모델이 당분간 이런 행동을 멈추지 않을 것이라는 점입니다. 환각은 이러한 시스템이 텍스트를 생성하는 방식의 속성이며, 가짜 패키지 이름은 내부적으로 실제 이름과 똑같이 보입니다. 그러니 부담은 당신에게 있습니다. install을 실행하는 인간에게 말이죠. 당신의 어시스턴트가 방금 알려준 이름이 실제 라이브러리일 수도 있고, 아니면 실제 라이브러리 이름을 가장한 공격자의 패키지일 수도 있습니다. 둘을 구별하는 유일한 방법은 설치 전에 살펴보는 것이며, 슬롭스쿼팅의 핵심은 바로 당신이 그렇게 하지 않을 것이라는 가정에서 시작된다는 것을 명심해야 합니다.
P.S. 이 글을 읽어주셔서 감사합니다! 여기에 표현된 아이디어와 의견은 전적으로 저의 것입니다. 기술 블로그를 운영하며 다양한 실무 경험을 공유하고 있습니다. 늘 새로운 아이디어를 환영하며, 궁금한 점이 있다면 편하게 연락 주세요! 👋
본 글은 nazarboyko.com에 처음 게시되었습니다.
이 글이 마음에 드셨나요? LinkedIn에서 저와 연결되어 더 많은 이야기를 나누고, 아이디어를 교환하거나, 인사 나누세요! 👋
원문: https://dev.to/nazar-boyko/slopsquatting-the-supply-chain-attack-that-weaponizes-ai-hallucinations-2m2 수집일: 2026-07-29 01:19:58