이 글은 AI 검수에서 통과하지 못했습니다 (점수: 80/100)
🚫 죽은 링크: https://simonwillison.net/2026/Mar/26/response-to-litellm-malware-attack/#atom-everything (404)
링크 오류, 품질 미달 등의 사유로 자동 분류된 글입니다.
🤖
870 in / 2771 out / 3641 total tokens
오늘은 로컬 LLM 양자화와 공급망 공격 이야기다. 게임 개발자한테 둘 다 무시 못 할 주제다.
🔥 TurboQuant, llama.cpp에서 직접 돌려봤더니
TurboQuant in Llama.cpp benchmarks
Google이 지난주 공개한 TurboQuant 연구를 llama.cpp에서 실제로 돌려본 벤치마크 결과가 올라왔다. TurboQuant는 극한 압축을 목표로 하는 양자화 기법인데, 이론상 1-2비트 수준까지도 품질 손실을 최소화하면서 압축할 수 있다고 주장했다.
글쓴이가 직접 llama.cpp 포크해서 테스트해본 결과, 4비트 양자화 대비 VRAM 사용량이 확실히 줄어든다. 속도는... 글쎄, 하드웨어에 따라 다르지만 RTX 3080 기준으로 약 15% 정도 토큰/초가 떨어지는 모습. 품질 손실은 Perplexity 기준으로 거의 없다고 봐도 될 수준.
게임 개발자 입장에서 이게 왜 중요하냐? 로컬 LLM을 게임 클라이언트에 내장할 때 VRAM이 늘 걸림돌이다. 70B 모델을 4비트로 깔아도 40GB 가까이 먹는데, 이걸 2비트 수준으로 줄일 수 있으면 16GB VRAM에서도 돌아간다. NPC 대화 시스템이나 인게임 퀘스트 생성 같은 거 로컬로 돌리려면 이런 극한 최적화가 필수다.
다만 아직 프로덕션에서 쓰기엔 이르다. llama.cpp 메인브랜치에 아직 병합 안 됐고, TurboQuant 자체도 연구 단계. 내 사이드프로젝트에서 테스트해보려고 했는데 빌드부터 삽질하다가 관뒀다. 나중에 안정화되면 다시 도전.
🚨 LiteLLM 멀웨어 공격, 실시간 대응 기록
My minute-by-minute response to the LiteLLM malware attack
Simon Willison이 LiteLLM 패키지에 백도어가 심어진 사건에 대한 실시간 대응 일지를 정리했다. LiteLLM은 LLM API 호출을 통합해주는 라이브러리인데, 의존성 체인 어딘가에 악성 코드가 들어가서 사용자 환경 변수를 탈취하려던 것으로 보인다.
Simon의 대응 과정이 흥미롭다. 처음 경고를 받은 시점부터 패키지 고정, 버전 롤백, 사용자 공지까지 약 2시간 만에 처리. 중간에 "이거 진짜 멀웨어 맞나?" 싶어서 여러 번 검증하는 과정도 있는데, 보안 이슈는 오탐과 실제 위협 사이에서 판단하기 어렵다는 걸 보여준다.
공급망 공격은 게임 개발자도 예외가 아니다. 내 UE5 프로젝트만 해도 수십 개의 서드파티 플러그인과 npm/pip 패키지를 쓴다. 언젠가 UE Marketplace 플러그인 하나가 백도어 심고 배포되는 날 오면... 상상하기 싫다. 항상 의존성 버전을 고정해두고, 의심스러운 업데이트는 바로 적용하지 않는 습관이 필요하다.
이번 사건으로 드러난 건 두 가지다. 하나는 PyPI 같은 공식 레지스트리도 절대 안전하지 않다는 점. 다른 하나는 빠른 대응이 얼마나 중요한지. Simon은 다행히 영향받은 버전을 즉시 파악하고 있었는데, 프로젝트마다 의존성 그래프를 항상 파악해둬야겠다.
로컬에서 돌리는 AI의 효율성이랑, 그 AI를 불러오는 파이프라인의 보안이랑. 둘 다 챙겨야 하는 게 요즘 개발자의 숙명이다.
양자화로 메모리 아끼는 동안 의존성 공격에 털리면 본전도 없다.