AI 업데이트: 양자화 벤치마크, AI 리팩토링, 그리고 공급망 공격

🤖 932 in / 3235 out / 4167 total tokens

오늘은 로컬 LLM 양자화, AI로 코드 리라이트, 그리고 공급망 보안 이슈 세 가지를 짚어본다.

🔥 로컬 LLM 양자화

Google이 지난달 공개한 TurboQuant 연구가 꽤 화제였다. 극단적 압축으로도 성능 저하가 거의 없다고 주장했는데, r/LocalLLaMA에서 누가 직접 llama.cpp로 벤치마크를 돌렸다.

결과가 흥미롭다. 실제로 TurboQuant가 기존 양자화 방식 대비 우위를 보이는 구간이 있지만, 모든 상황에서 압도적이지는 않다. 특히 작은 모델에서는 이득이 미미하고, 큰 모델에서야 메모리 절약 효과가 체감된다.

게임 서버 최적화랑 비슷하다. 이론상 수치와 실제 프로파일링 결과는 항상 다르다. 로컬 LLM 쓸 거면 직접 돌려보는 수밖에.

왜 중요한가: 양자화는 로컬 LLM 배포의 핵심 기술. 메모리 제약 있는 환경(게임 클라이언트 임베디드 NPC AI 같은)에서는 이런 극단적 압축이 열쇠가 된다.

출처: Reddit r/LocalLLaMA

Simon Willison이 정리한 글. 어떤 팀이 JSONata 쿼리 엔진을 AI로 하루 만에 다른 언어로 포팅했다. 결과? 연간 50만 달러 라이선스 비용 절약.

물론 "AI가 알아서 다 했다"는 아니다. 프롬프트 엔지니어링, 산발적으로 튀는 에러 잡기, 테스트 코드 작성, 검증 과정이 다 필요했다. 하지만 사람이 직접 했으면 몇 주 걸릴 작업이 하루 만에 끝났다.

UE5 C++ 리팩토링에도 적용 가능하다. 레거시 블루프린트를 C++로 변환하거나, 오래된 플러그인 API 마이그레이션할 때 AI 어시스트는 이미 필수다. 다만 생성된 코드의 품질 검증은 개발자가 직접 해야 한다.

왜 중요한가: AI 코딩 어시스트가 "재미있는 실험"에서 "실제 비용 절감 도구"로 넘어갔다. 기술 부채 청소에 AI 쓰는 건 이제 선택이 아니라 필수.

출처: Simon Willison

LiteLLM 패키지가 멀웨어 공격을 당했다. Simon Willison이 이 사건을 분 단위로 기록했다.

공격 방식은 전형적이지만 치명적이었다. 의존성 체인 타고 들어가서 악성 코드 심기. 문제는 LiteLLM이 수많은 프로젝트에서 간접 의존으로 쓰인다는 점이다.

게임 서버 개발자로서 등골이 서늘해지는 대목. 우리도 수십 개의 npm, pip 패키지를 간접 의존하고 있다. 언제 터질지 모르는 시한폭탄이다. 의존성 최소화, lockfile 고정, 보안 스캔 자동화. 이 세 가지는 이제 기본 중 기본이다.

왜 중요한가: AI 인프라 생태계가 커질수록 공급망 공격 표면도 넓어진다. 내 서버가 해킹당하면 게임 데이터, 유저 정보 전부 날아간다.

출처: Simon Willison

세 가지가 다 "검증"에 관한 이야기다. TurboQuant는 이론적 성능을 실제 벤치마크로 검증. JSONata 리라이트는 생성된 코드를 테스트로 검증. LiteLLM 공격은 의존성을 보안 관점에서 검증.

AI 시대에 개발자가 해야 할 일은 코드를 직접 짜는 것보다 검증하는 게 더 많아질지도 모른다.

AI가 대신 만들어준 걸 검증하지 않으면, AI가 대신 망해준다.