Hugging Face에서 백도어가 심긴 AI 모델을 발견했습니다 — 그리고 들여다본 사람은 누구나 똑같이 발견했습니다

어느 화요일 밤이었습니다. 저는 엔지니어 한 명이 지극히 일상적이어야 할 작업을 하는 것을 지켜보고 있었습니다. Hugging Face에서 사전 학습된 모델을 가져와 테스트 환경에 로드하는 일이었죠. 흔한 작업입니다. 저희는 수백 번은 해왔습니다. 하지만 그날은 달랐습니다. 저는 막 JFrog의 2024년 2월 공개 보고서를 다 읽은 참이었거든요 — 보안 연구원들이 Hugging Face에 올라와 있는 100개가 넘는 악성 모델을 찾아냈고, 그중 일부는 로드하는 순간 공격자에게 원격 접근 권한을 넘겨주는 백도어를 품고 있었다는 바로 그 보고서 말입니다 — 그래서 저는 터미널에서 눈을 뗄 수가 없었습니다.

"잠깐," 제가 말했습니다. "그 모델, 포맷이 뭐죠?"

Pickle.

속이 철렁 내려앉았습니다.

그 순간 저는 깨달았습니다. 우리가 AI 모델을 2014년의 업계가 오픈소스 라이브러리를 다루던 방식 그대로 — 인터넷에서 그냥 가져와 실행하면 되는, 본질적으로 신뢰할 수 있는 아티팩트로 — 취급해 왔다는 사실을요. 그리고 자신의 전제가 실시간으로 무너지는 것을 목격할 때만 생기는 그런 확신으로, 저는 이것이 향후 10년을 규정할 보안 위기 중 하나가 되리라는 것을 알았습니다.

몰래 본부로 전화를 거는 모델

Hugging Face에서 실제로 벌어진 일은 이렇습니다. "baller423"이라는 사용자가 지극히 정상적으로 보이는 PyTorch 모델을 업로드했습니다. 그럴듯한 이름, 설득력 있는 설명, 꽤 괜찮아 보이는 지표까지 갖추고 있었죠. 하지만 pickle로 직렬화된 그 가중치 안에는, 누군가 torch.load()를 실행하는 즉시 Korea Research Environment Open Network에 속한 IP 주소로 리버스 셸을 여는 페이로드가 숨어 있었습니다.

이론상의 공격이 아닙니다. 개념 증명도 아닙니다. 세상에서 가장 인기 있는 AI 모델 허브에 실제로 올라와, 누군가 다운로드하기만을 기다리고 있던 무기화된 모델입니다.

그리고 "baller423"만이 아니었습니다. JFrog는 이런 모델을 약 100개 찾아냈습니다 — 하나같이 유용한 사전 학습 아티팩트로 위장한 트로이 목마였습니다.

pickle 파일에 torch.load()를 실행하면, 여러분은 데이터를 로드하는 것이 아닙니다. 코드를 실행하는 것입니다. 그리고 그 코드가 무슨 일을 하는지는 이미 늦어버린 뒤에야 알게 됩니다.

이것이 왜 그토록 위험한지 설명해야겠습니다. 대부분의 사람들은 — 심지어 대부분의 엔지니어조차 — pickle이 실제로 무엇인지 이해하지 못하기 때문입니다. Python의 pickle 포맷은 단순한 데이터 직렬화 방식이 아닙니다. 스택 기반 가상 머신입니다. 역직렬화 과정에서 임의의 Python 함수를 실행할 수 있습니다. 여러분의 데이터 과학자가 모델을 로드할 때, pickle은 조용히 os.system() 또는 subprocess.run()을 백그라운드에서 호출할 수 있습니다. 모델은 멀쩡히 작동합니다. 예측 결과도 정상으로 보입니다. 그리고 그동안, 지구 반대편의 누군가는 여러분의 서버에 셸을 확보하고 있습니다.

이것은 버그가 아닙니다. pickle이 원래 그렇게 설계된 것입니다. 다만 우리는 그 파일이 인터넷의 낯선 사람에게서 올 때 그것이 무엇을 의미하는지 한 번도 진지하게 따져보지 않았을 뿐입니다.

스캐너는 왜 이것을 잡아내지 못했을까?

그날 밤 저를 잠들지 못하게 한 것이 바로 이 지점입니다. 저희에게는 보안 도구가 있었습니다. 업계에는 모델 파일을 검증하는 표준 도구인 PickleScan이 있었습니다. Hugging Face도 직접 그것을 돌립니다. 이렇게 노골적인 것이라면 스캐너가 당연히 잡아냈어야 하지 않을까요?

그러지 못했습니다. 게다가 상황은 더 나쁩니다.

JFrog는 이후 PickleScan 자체에서 세 건의 제로데이 취약점을 발견했습니다 — 그중 하나는 CVE-2025-10155로 등록되었습니다 — 공격자가 파일 확장자를 조작하거나 ZIP 아카이브의 불일치를 악용해 탐지를 완전히 우회할 수 있게 하는 취약점이었습니다. 악성 모델이, 여러분을 보호하기 위해 만들어진 바로 그 도구에 의해 "안전함"으로 표시될 수 있었던 것입니다.

통계가 그리는 그림은 암울합니다. 현재 스캐너 경보의 최대 96%가 오탐입니다. 그것이 보안 팀에 어떤 영향을 미치는지 생각해 보십시오. 백 번째 허위 경보를 겪고 나면, 더 이상 들여다보지 않게 됩니다. 반사적으로 "승인"을 누르기 시작합니다. 그리고 바로 그때 진짜 위협이 문을 열고 들어옵니다.

저는 이 문제로 팀 리드 한 명과 격한 논쟁을 벌였습니다. 그는 우리가 과민 반응한다고 생각했습니다. "우리는 검증된 조직에서만 모델을 가져옵니다," 그가 말했습니다. 저는 그에게 JFrog의 데이터를 보여주었습니다. 그리고 pickle의 문제를 피하려고 특별히 설계된 GGUF 같은 더 새로운 "안전한" 포맷조차, 로드 시점이 아니라 추론 시점에 실행되는 악성 Jinja 템플릿을 메타데이터에 품고 있는 사례가 발견되었다는 것을 보여주었습니다. 공격이 나중에, 모델이 이미 실행 중일 때 일어나기 때문에 스캐너는 그것을 결코 보지 못합니다.

그는 한참 동안 말이 없었습니다. 그러더니 이렇게 말했습니다. "그럼 우리는 대체 무엇을 믿어야 하죠?"

그것이 바로 올바른 질문입니다.

AI 안에 잠복 요원이 들어 있다면 어떤 일이 벌어질까?

Hugging Face 사건은 조악하고 탐지 가능한 페이로드 — 리버스 셸, 눈에 띄는 코드 실행 — 에 관한 것이었습니다. 하지만 더 깊은 위협, 저를 진심으로 두렵게 하는 것은 데이터 오염(data poisoning)입니다. 그리고 이에 관한 연구 결과는 소름 끼칩니다.

NVIDIA의 AI 레드팀은 Anthropic의 연구 결과와 함께, 단 학습 데이터의 0.00016%만 오염시켜도 130억 파라미터 모델에 숨겨진 동작을 영구적으로 심을 수 있음을 입증했습니다 — 수백만 건 중 약 250개 문서에 해당하는 양입니다.

그 숫자를 곱씹어 보십시오. 250개 문서입니다.

오염된 모델은 모든 벤치마크를 통과합니다. 표준 테스트에서 깨끗한 모델과 동일한 성능을 냅니다. 하지만 특정 트리거 — 특정한 텍스트 문자열, 이미지 패턴, 심지어 입력 데이터의 비트 수준 조작 — 를 만나면 동작이 바뀝니다. 인증을 우회할 수도 있습니다. 데이터를 외부로 유출할 수도 있습니다. 다운스트림 시스템으로 흘러 들어가는 악성 코드를 생성할 수도 있습니다.

오염된 AI 모델은 완벽한 잠복 요원입니다. 모든 테스트를 통과하고, 모든 벤치마크에서 만점을 받으며, 오직 공격자만이 아는 트리거를 참을성 있게 기다립니다.

그리고 여기에 수학적 한 방이 있습니다. 깨끗한 데이터를 더 넣는다고 해결되지 않습니다. 백도어가 임계치 — 보통 학습 중 트리거가 50~100회 등장하는 수준 — 에 도달하고 나면, 그것은 가중치에 영구적으로 각인됩니다. 학습으로 지워낼 수 없습니다. 희석해서 없앨 수도 없습니다.

NVIDIA는 이를 AI 킬 체인(AI Kill Chain)이라 부르는 체계로 정식화했습니다. 정찰(Recon), 오염(Poison), 탈취(Hijack), 지속(Persist), 영향(Impact)이라는 다섯 단계로, 공격자가 머신러닝 시스템을 체계적으로 침해하는 과정을 도식화한 것입니다. 저는 이 프레임워크와 공격 벡터의 전체 스펙트럼에 대해 저희 인터랙티브 리서치 개요에서 다뤘으며, 프로덕션에 모델을 배포하는 분이라면 누구든 시간을 들여 읽어보시길 권합니다.

자체 데이터로 모델을 파인튜닝하는 모든 기업에게 이것이 시사하는 바는 냉혹합니다. 여러분의 독점 데이터셋이 아무리 깨끗하더라도, 공개 저장소에서 내려받은 기반 모델이 이미 침해되어 있을 수 있습니다. 여러분은 내부를 들여다볼 수 없는 토대 위에 무언가를 쌓고 있는 셈입니다.

아무도 이야기하고 싶어 하지 않는 섀도 AI 문제

중견 금융 서비스 기업의 CISO와 저녁 식사를 한 적이 있습니다. 그녀는 거의 무심하게, 자기 팀이 최근 회사 전반의 프로덕션 환경에서 서로 다른 AI 모델 47개가 돌아가고 있는 것을 발견했다고 말했습니다. 그녀의 AI 거버넌스 정책이 포괄하는 것은 그중 3개였습니다.

이것이 바로 섀도 AI이며, 하나의 전염병입니다. 데이터는 충격적입니다: 기업 내 AI 사용의 90%는 IT 및 보안 팀의 관할 밖에서 이루어집니다. 개발자와 사업 부서는 공식 절차가 너무 오래 걸린다는 이유로 공개 저장소에서 검증되지 않은 모델을 가져옵니다. 독점 코드와 고객 데이터를 공개 AI 도구에 붙여넣습니다 — 직원의 77%가 이런 행동을 하는 것으로 관찰되었습니다. 그리고 그 무단 모델 하나하나가 어떤 스캐너도 건드려 본 적 없는 잠재적 백도어입니다.

재정적 영향은 추상적인 이야기가 아닙니다. 검증되지 않은 AI 도구가 관련된 사고는 데이터 유출 비용을 평균 $670,000만큼 증가시킵니다. 거버넌스 없이 "빠르게 움직이는" 대가로 치르는 프리미엄입니다.

저는 그 충동을 이해합니다. 정말로 이해합니다. 기능을 출시하려는 엔지니어인데 보안 검토 절차가 3주나 걸린다면, 당연히 Hugging Face에서 모델을 그냥 가져와 연결해 버리고 싶은 유혹이 듭니다. 저 역시 그 유혹을 느껴봤습니다. 하지만 JFrog의 공개는 그 시대를 끝냈어야 합니다. 우리는 이제 공개 모델 허브에 무기화된 아티팩트가 존재한다는 것을 경험적 확실성을 가지고 알고 있습니다. 그것들을 신뢰할 수 있는 출처로 취급하는 것은, AI 세계에서 curl | bash를 프로덕션 환경에서 무작위 GitHub gist로부터 실행하는 것과 같습니다.

왜 모두가 아직도 눈을 가린 채 날고 있을까?

NIST는 2024년에 AI 100-2 지침을 발표했습니다 — 적대적 머신러닝 공격과 완화 방안에 대한 포괄적인 분류 체계입니다. 훌륭한 결과물입니다. 업계에 이러한 위협을 논할 공통 언어를 제공합니다. 그런데 그것을 실제로 구현한 곳은 거의 없습니다.

숫자는 참담합니다:

• 단 17%의 조직만이 AI 보안 통제를 자동화하고 있습니다
• 단 12%만이 포괄적인 AI 거버넌스를 갖추고 있습니다
• 단 14%만이 내부 AI 데이터 흐름을 가시적으로 파악하고 있습니다
• 83%의 조직이 NIST의 표현대로 "눈을 가린 채 운영"되고 있습니다

저는 이 격차를 가까이에서 봐 왔습니다. 조직들은 정책 문서를 갖추는 것과 실질적인 운영 보안을 갖추는 것을 혼동합니다. 개발자들이 서명되지 않은 pickle 모델을 프로덕션 Kubernetes 클러스터에 로드하고 있는 와중에, 아름답게 편집된 AI 거버넌스 PDF를 보여줍니다. 문서는 존재합니다. 통제는 존재하지 않습니다.

기업의 83%는 자사 AI 공급망에 대한 자동화된 통제 수단이 전혀 없습니다. 이것은 격차가 아닙니다 — 활짝 열린 문입니다.

우리는 어떻게 모델을 악성 코드처럼 취급하기 시작했나

그 화요일 밤의 깨달음 이후, Veriprajna의 저희 팀은 몇 주 동안 모델 수용 방식을 재설계했습니다. 핵심적인 철학의 전환은 단순하지만 급진적이었습니다: 모든 AI 모델을, 안전함이 입증되기 전까지는 악성일 수 있는 실행 코드로 취급하라.

"아마 괜찮을 것"이 아닙니다. "평판 좋은 출처에서 온 것"도 아닙니다. 악성일 수 있는 것입니다. 예외 없습니다.

머신러닝 자재 명세서(ML-BOM)

가장 먼저 필요했던 것은 투명성이었습니다. 전통적인 소프트웨어 자재 명세서(SBOM)는 라이브러리와 버전을 추적하지만, AI 아티팩트에는 그 이상이 필요합니다. 바로 ML-BOM — 머신러닝 자재 명세서 — 으로, 데이터 출처, 모델 계보, 프레임워크 의존성, 그리고 암호학적 증명을 담아내는 것입니다.

학습 데이터는 어디에서 왔는가? 이 모델을 누가, 무엇으로 파인튜닝했는가? 어떤 버전의 PyTorch가 사용되었으며, 알려진 취약점이 있는가? 지금 로드하려는 모델이 신뢰할 수 있는 파이프라인에서 생성된 바로 그 아티팩트이며 전송 중 변조되지 않았음을 암호학적으로 검증할 수 있는가?

이 질문들에 답할 수 없다면, 여러분은 자신이 무엇을 배포하고 있는지 모르는 것입니다.

Pickle을 없애고, 모든 것에 서명하기

저희는 두 가지 엔지니어링 결정을 즉시 내렸습니다. 첫째, pickle은 더 이상 없습니다. 예외 없습니다. 저희 파이프라인의 모든 모델은 SafeTensors를 사용합니다 — 텐서 데이터와 JSON 메타데이터만 저장하며 로드 중에 코드를 실행할 수 없는 포맷입니다. pickle보다 유연성이 떨어지는데, 바로 그 점이 핵심입니다.

둘째, 암호학적 모델 서명입니다. 모든 모델 아티팩트는 고유한 해시를 부여받고, 저희 내부 PKI 인프라로 서명됩니다. 저희 추론 서버는 어드미션 컨트롤러를 실행해, 가중치가 메모리로 역직렬화되기 전에 신뢰의 근원(root of trust)에 대조해 서명을 검증합니다. 서명이 일치하지 않으면 모델은 로드되지 않습니다. 예외도, 우회도, "하지만 테스트용일 뿐인데요"도 없습니다.

저희 엔지니어 한 명이 이에 강하게 반발했습니다. "개발 워크플로에 마찰을 더하고 계십니다," 그가 말했습니다. 그의 말이 맞습니다. 저는 일부러 마찰을 넣었습니다. 그 대안 — 누구나 어디서든 어떤 모델이든 로드할 수 있는 마찰 없는 길 — 이야말로 여러분의 추론 서버에서 한국으로 향하는 리버스 셸이 돌아가게 되는 경로이기 때문입니다.

런타임 모니터링: 정적 스캔만으로는 부족하기에

저희는 GGUF 템플릿 취약점을 통해 정적 스캔이 위협 표면의 일부만 잡아낸다는 것을 배웠습니다. 모델은 로드 시점에는 깨끗하다가 추론 시점에 악성이 될 수 있습니다. 그래서 지속적인 런타임 모니터링을 추가했습니다. 드리프트를 탐지하기 위해 깨끗한 기준선과 대조하는 출력 검증, 모델 추출 공격을 막기 위한 쿼리 스로틀링, 그리고 정교하게 조작된 적대적 페이로드를 무력화하기 위해 쿼리가 핵심 모델에 도달하기 전에 이를 재구성하는 입력 정화 계층입니다.

하드웨어 기반 신뢰 실행 환경(Trusted Execution Environment)을 활용한 기밀 컴퓨팅 접근법을 포함한 전체 기술 아키텍처는 저희 연구 논문의 기술 심층 분석을 참고하십시오. 그곳에는 에세이에서 다룰 수 있는 수준을 넘어서는 구현 세부 사항이 담겨 있습니다.

"딥 AI"와 API 래퍼에 관한 불편한 진실

제가 "딥 AI"라고 부르는 것 — 자체 호스팅하고, 파인튜닝하고, 아키텍처 수준에서 통제하는 AI 시스템 — 과 시장을 지배하는 API 래퍼 방식의 구분으로 제가 계속 되돌아오는 데에는 이유가 있습니다. 단순한 기술적 취향의 문제가 아닙니다. 보안에 관한 논증입니다.

공개 API를 감싸는 순간, 여러분은 자신의 AI 공급망을 남에게 외주 주는 것입니다. 그들의 모델 출처, 학습 데이터, 보안 태세를 전혀 들여다볼 수 없습니다. OpenAI나 Anthropic이나 Google이 자기네 파이프라인을 지키는 힘든 일을 해냈으리라고 믿는 것입니다. 실제로 해냈을 수도 있습니다. 하지만 여러분은 그것을 검증할 수 없고, 보안에서 검증 없는 신뢰는 그저 희망일 뿐입니다.

깊이 있게 구축할 때 — 모델 가중치, 학습 파이프라인, 추론 인프라를 직접 통제할 때 — 여러분은 공급망 전체에 대한 책임을 떠안게 됩니다. 그것은 더 어렵습니다. 더 비쌉니다. 제가 지금까지 설명해 온 종류의 엔지니어링 규율을 요구합니다. 하지만 그것이 검증 가능한 보안에 이르는 유일한 길입니다.

한 투자자가 제게 이렇게 말한 적이 있습니다. "그냥 GPT의 API를 쓰고 제품에 집중하세요." 저는 그에게 이렇게 답했습니다. 저희가 서비스하는 산업들 — 침해된 모델 하나가 금융 데이터 유출, 의료 진단 조작, 법률 분석 오염으로 이어질 수 있는 곳들 — 에서 "그냥 API를 쓰라"는 것은 전략이 아니라 부채라고요.

이제 AI 보안과 소프트웨어 보안은 같은 문제입니다

제게 모든 것을 명확하게 정리해 준 통찰은 이것입니다. AI 보안과 소프트웨어 공급망 보안은 더 이상 별개의 분야가 아닙니다. 그럴 수가 없습니다. AI 모델은 고립된 채로 돌아가지 않습니다 — 전통적인 소프트웨어가 사용하는 것과 똑같은 CI/CD 파이프라인, 컨테이너 레지스트리, 의존성 트리를 통해 구축되고 배포됩니다.

모델에 암호학적 서명이 되어 있더라도 그 모델이 의존하는 Python 라이브러리가 공급망 공격으로 침해되었다면, 여러분은 이미 뚫린 것입니다. 학습 파이프라인이 오염된 컨테이너 이미지에서 실행된다면, 학습 데이터가 아무리 깨끗하더라도 모델 가중치는 신뢰할 수 없습니다.

업계는 계속해서 "AI 보안" 팀과 "애플리케이션 보안" 팀을 따로 만들려고 합니다. 그 조직적 분리 자체가 취약점입니다. 공격 표면은 하나로 통합되어 있고, 방어도 그래야 합니다.

AI가 생성한 코드가 개발 속도를 가속하면서, 전통적인 사람 중심의 코드 리뷰 절차는 물량에 짓눌려 무너지고 있습니다. AI가 만들어 낸 거대한 풀 리퀘스트는 마감 압박 속에서 꼼꼼히 검토하기 어렵고, 그 결과 "얕은 리뷰" 문화가 자리 잡아 마지막 남은 휴먼 인 더 루프 보안 통제 중 하나를 없애 버립니다. 이런 환경에서 암호학적 서명과 ML-BOM에 뿌리를 둔 자동화된 결정론적 검증은 선택 사항이 아닙니다. 유일하게 규모를 감당할 수 있는 수단입니다.

"하지만 우리는 표적이 아닙니다"

사람들은 언제나 이런 식의 반론을 내놓습니다. "우리는 이 정도 수준의 보안이 필요할 만큼 민감한 일을 하지 않습니다." "우리 모델은 내부 도구용일 뿐입니다." "우리를 공격하려고 굳이 모델을 오염시킬 사람은 없습니다."

저는 2018년에 오픈소스 라이브러리 보안에 대해 똑같은 주장을 들었습니다. 그러고 나서 SolarWinds가 터졌습니다. 그다음엔 Log4Shell이 터졌습니다. 그다음엔 XZ Utils 백도어가 터졌습니다 — 전 세계 모든 Linux 서버의 SSH가 사용하는 단 하나의 압축 라이브러리를 침해하기 위한, 수년에 걸친 사회공학 캠페인이었습니다.

AI 공급망은 똑같은 궤적을 따라가고 있습니다. 다만 더 빠를 뿐입니다. 공격 표면은 더 넓고(모델 가중치는 소스 코드처럼 감사할 수 없는 불투명한 바이너리 덩어리입니다), 도구는 덜 성숙했으며(PickleScan에는 제로데이가 있습니다), 거버넌스 격차는 더 큽니다(기업의 83%는 자동화된 통제가 전혀 없습니다).

표적이 되어야만 피해자가 되는 것은 아닙니다. 그저 그 경로 위에 있기만 하면 됩니다.

지루한 AI 보안은 어떤 모습인가

제 목표는 — 이상하게 들릴 수 있지만 — AI 배포를 지루하게 만드는 것입니다. 흥미진진하지도, 최첨단이지도, "빠르게 움직여 부수는" 것도 아닙니다. 지루하게. 예측 가능하게. 감사 가능하게.

지루하다는 것은 모든 모델에 ML-BOM이 있다는 뜻입니다. 지루하다는 것은 로드 시점에 암호학적 서명이 검증된다는 뜻입니다. 지루하다는 것은 pickle을 절대로 쓰지 않는다는 뜻입니다. 지루하다는 것은 드리프트가 침해로 번지기 전에 잡아내는 런타임 모니터링이 있다는 뜻입니다. 지루하다는 것은 모든 모델, 데이터셋, 의존성이 추적되고, 검증되고, 버전 관리되는 중앙 집중식 AI 자산 레지스트리가 있다는 뜻입니다.

지루하다는 것은 누군가 "프로덕션에서 어떤 AI 모델이 돌아가고 있나요?"라고 물었을 때, 5분 안에 암호학적 증거와 함께 답할 수 있다는 뜻입니다.

목표는 AI 배포를 흥미진진하게 만드는 것이 아닙니다. 지루하게 만드는 것입니다 — 예측 가능하고, 감사 가능하며, 안전하게. 흥미진진한 AI 보안이란 무언가 잘못되었다는 뜻입니다.

Hugging Face에 있던 100개가 넘는 악성 모델은 고립된 사건이 아니었습니다. 그것은 맹목적 신뢰라는 토대 위에 놀라운 역량을 쌓아 올린 업계의 증상이었습니다. 우리는 예전에 LimeWire에서 MP3를 내려받던 방식 그대로 모델을 내려받았습니다 — 잘되기를 바라고, 뻔한 위험은 무시하고, 뭔가 잘못되면 놀란 척하면서요.

그 시대는 끝났습니다. 다음 AI 공급망 공격의 물결에서 살아남을 조직은, 바로 지금 자사의 모델을 마법 상자가 아니라 그에 따르는 온전한 공격 표면을 지닌 실행 코드로 취급하기로 결정한 곳들일 것입니다. 빠름 대신 지루함을 선택한 곳들. 터미널을 바라보다가 pickle 파일이 로드되는 것을 보고 이렇게 말한 곳들입니다. "잠깐. 그거 무슨 포맷이죠?"