AI 모델은 실행 가능한 코드입니다. 그런데 대부분의 기업은 이를 스프레드시트처럼 다룹니다.
그 문제를 처음으로 제대로 이해했던 순간, 저는 격리된 컨테이너에서 스크롤되며 지나가는 syscall 트레이스를 지켜보며 아무 일도 일어나지 않기를 기다리고 있었습니다.
우리는 공개 레지스트리에서 모델 하나를 내려받은 상태였습니다 — 데이터 과학자가 별생각 없이 분기마다 수백 번씩 다운로드하는 그런 종류의 모델이었죠. 모델 카드는 정상으로 보였습니다. 기본 스캔도 통과했고요. 제가 그것을 샌드박스에 로드한 것은 그 특정 파일이 의심스러웠기 때문이 아니라, 이제 제가 모든 것을 샌드박스에서 로드하기 시작했기 때문입니다. 그리고 역직렬화가 진행되자, 트레이스에는 그 프로세스가 전혀 열 이유가 없는 네트워크 연결을 열려고 시도하는 모습이 나타났습니다.
이것이 바로 AI 공급망 보안의 핵심 논지 전체를 한순간에 담고 있습니다: 여러분의 모델은 데이터 파일이 아닙니다. 그것은 로드하는 즉시 실행되는 실행 가능 코드입니다. 대부분의 조직은 모델을 스프레드시트처럼 — 다운로드해서 열기만 하는 비활성 대상처럼 — 취급하며, 모델이 무엇 인지와 그것이 어떻게 취급되는지 사이의 그 간극이 바로 침해가 발생하는 바로 그 지점입니다.
모델은 여러분이 여는 문서가 아닙니다. 그것은 실행한 사람의 권한으로 실행되는 프로그램입니다.
리버스 셸 이야기는 업계에 떠도는 가설적인 전설조차 아닙니다. Hugging Face에 올라온 "baller423"이라는 모델이 외부 호스트로 리버스 셸을 연결하는 것이 발견되었습니다. 정상으로 보였습니다. 기본 스캔도 통과했고요. 누군가 로드하는 순간 임의의 코드를 실행했습니다. 제가 보안 책임자들이 모인 자리에서 그 이야기를 하면, 그들이 불편해하는 지점은 그런 일이 가능하다는 것이 아닙니다 — 자기 팀이 2년 동안 같은 출처에서 같은 방식으로 모델을 로드해 왔다는 사실을 깨닫는다는 데 있습니다.
아무도 듣고 싶어 하지 않는 pickle 문제
여기서부터가 노련한 엔지니어들을 움찔하게 만드는 대목입니다. 이것은 누군가 패치할 수 있는 버그가 아니기 때문이죠.
여러분이 torch.load()를 PyTorch 모델에 대해 호출하면, 역직렬화 과정에서 임의의 Python 코드가 실행될 수 있습니다. 이것은 일반적인 의미의 취약점이 아닙니다. 그것은 의도된 동작입니다 — Python의 pickle 직렬화 형식이 그렇게 설계된 것이죠. pickle은 코드를 실행하여 객체를 재구성하도록 허용되어 있고, 모델 파일은 그저 pickle로 직렬화된 객체일 뿐입니다. 실제로 유통되는 머신러닝 모델의 80% 이상이 이 형식을 사용합니다. 따라서 이 분야 전체가 모델을 기본적으로 배포하는 방식이 곧, 누군가 채워 넣기만을 기다리는 원격 코드 실행 프리미티브이기도 합니다.
당연하게도, 본능적인 대응은 그것을 스캔하는 것입니다. 가장 널리 배포된 방어 수단은 PickleScan이라는 도구로, 모델 파일 내부에서 알려진 악성 패턴을 찾습니다. 그런데 PickleScan에는 알려진 제로데이 우회 기법이 최소 세 가지 있으며 — 그중 하나가 CVE-2025-10155입니다 — 이후 Sonatype의 연구진은 스캐너 자체에서 네 가지 취약점을 추가로 발견했습니다.
제가 이런 말을 하는 것은 실질적인 성과를 내고 있는 오픈소스 프로젝트를 깎아내리려는 게 아닙니다. 제가 이 말을 하는 것은 그것이 지금 제가 모든 것을 그 위에 쌓아 올리는 하나의 원칙을 가르쳐 주었기 때문입니다: 공격자가 파일 형식을 장악하고 있을 때, 블랙리스트 스캔은 구조적으로 질 수밖에 없다. 정적 스캔은 "이 파일에 내가 이미 나쁘다고 알고 있는 패턴이 들어 있는가?"를 묻습니다. 여러분과 똑같은 블랙리스트를 볼 수 있는 공격자는, 여러분이 아직 모르는 패턴을 그냥 사용하면 그만입니다.
그래서 우리는 그 질문을 던지기를 멈췄습니다. 우리 팀이 구축하는 검증 파이프라인은 "이 파일에 어떤 알려진 악성 문자열이 있는가"로 시작하지 않습니다. 그것은 행위 기반 샌드박싱으로 시작합니다: 격리된 컨테이너에서 모델을 로드하고, 그것이 실제로 무엇을 하는지 — 시스템 콜, 네트워크 접속, 파일 쓰기를 — 지켜보고, 시그니처가 아니라 그 행위를 판단합니다. 질문은 "이것이 목록에 있는가"에서 "이 코드가 실행될 때 무슨 일을 하는가"로 옮겨 갑니다. 그 두 번째 질문이야말로 아직 아무도 이름 붙이지 못한 공격을 잡아내는 유일한 질문입니다.
정적 스캔은 어제의 공격을 잡습니다. 행위 기반 샌드박싱은 공격자가 바로 지금 작성하고 있는 공격을 잡습니다.
이것은 공짜가 아니며, 매대에서 사 오는 제품도 아닙니다. 2025년 7월에 마무리된 약 5억~7억 달러 규모의 인수를 거쳐 지금은 Palo Alto Networks의 일부가 된 Protect AI는 447만 개의 모델 버전을 스캔해 51,700개가 넘는 모델에서 352,000건의 안전하지 않거나 의심스러운 문제를 발견했습니다. 그것이 바로 이 건초더미의 규모입니다. 도구는 명백한 것을 표시해 줄 수 있습니다. 공개 레지스트리와 여러분의 내부 모델 저장소 사이에 놓이는 게이트를 설계하고 — 아무도 우회하지 않을 만큼 빠르게 만드는 것 — 이것이 바로 상자에 담겨 오지 않는 부분입니다.
내가 만들었지만 모두가 무시한 게이트
이 이야기에서 제가 잘못했던 버전에 대해 말씀드리고 싶습니다. 그 실패가 성공보다 더 많은 것을 가르쳐 주었기 때문입니다.
초기에 저는 어느 고객사를 위해 기술적으로는 훌륭한 모델 검증 게이트를 만들었습니다. 공개 출처에서 들어오는 모든 모델은 샌드박스로 끌려 들어와 여러 형식에 걸쳐 심층 분석되고 행위가 프로파일링된 뒤에야 서명되어 내부 레지스트리에 등록되었습니다. 보안 심사에서라면 훌륭한 점수를 받았을 것입니다. 저는 그것이 자랑스러웠습니다.
약 일주일 만에, 데이터 과학 팀은 조용히 그것을 사용하지 않게 되었습니다.
악의가 있어서가 아니었습니다. 그들에게는 마감이 있었죠. 그 게이트는 대안 — Hugging Face에서 모델을 직접 내려받는 것 — 이 30초면 끝나는 워크플로에 실제로 몇 분을 더했습니다. 그래서 어떤 실험에 모델이 지금 당장 필요할 때면, 그들은 개인 클라우드 계정으로 그것을 가공 없이 그대로 내려받고는 하던 일을 계속했습니다. 제 아름다운 게이트는 텅 빈 출입구를 지키고 있었고, 실제 트래픽은 건물 옆으로 돌아 지나가고 있었습니다.
그 한 주는 저에게 이 문제 전체를 새롭게 바라보게 만들었습니다. AI 공급망 보안에서 가장 어려운 통제는 기술적인 것이 아닙니다. 그것은, 안전하지 않은 경로보다 느린 보안 게이트는 매번 예외 없이 진다는 사실입니다. 데이터 과학자가 30초 만에 모델을 다운로드할 수 있을 때, 30분이 걸리는 프로세스는 무엇이든 우회됩니다 — 악의적인 행위자가 아니라, 압박에 시달리는 유능한 엔지니어들에 의해서요. 통제는 준수하는 편이 더 쉬운, 즉 우회하는 것보다 더 쉬운 상태가 되도록 충분히 빨라야 합니다. 그렇지 않다면 여러분에게 보안 프로그램은 없는 것입니다. 훌륭한 평가를 받지만 관객은 없는 보안 연극만 있을 뿐이죠.
그래서 그 이후로 섀도 AI에 관한 수치들은 저를 전혀 놀라게 하지 않았습니다. 조직의 98%에는 승인되지 않은 AI 도구를 사용하는 직원이 있습니다. 보안 실무자의 62%는 자사 환경에서 대규모 언어 모델이 어디에서 실행되고 있는지조차 확실하게 알아낼 방법이 없다고 말합니다. 임원의 3분의 1은 포괄적인 추적 체계를 갖추고 있다고 말하지만, 실제로 작동하는 AI 거버넌스 체계를 갖춘 기업은 약 9%에 불과합니다. 그리고 그 비용은 추상적이지 않습니다: IBM의 2025년 데이터 유출 비용 보고서는 섀도 AI 관련 유출의 평균 비용을 463만 달러로 — 표준적인 사고보다 약 67만 달러 더 많은 것으로 — 추산합니다.
볼 수 없는 것은 지킬 수 없으며, 지금 당장 대부분의 조직은 자사 AI의 대부분을 보지 못하고 있습니다.
파인튜닝은 왜 가장 안전한 모델을 조용히 무장 해제시키는가?
이것은 제가 기술 팀에 가져갈 때 가장 강한 반응을 이끌어내는 사례입니다. 모두가 당연하게 여기는 무언가와 모순되기 때문이죠.
그 가정은 이렇습니다: 나는 이 모델의 안전성을 평가했고, 통과했으니 안전하다. 하지만 현실은, 안전성 정렬이 평가 시점상 완전히 놓치는 방식으로 취약하다는 것입니다. 한 연구에서 Llama 3.1 8B의 프롬프트 인젝션 방어력은 단 한 차례의 파인튜닝 이후 0.95점에서 0.15점으로 떨어졌습니다 — 그것도 적대적 파인튜닝이 아니었습니다. 평범하고, 악의 없고, 특정 도메인에 맞춘 학습이었죠. 이는 안전성 속성이 약 84% 붕괴한 것으로, 기업이 모델에 하는 가장 일상적인 작업에 의해 초래된 것입니다.
저는 어느 고객사의 ML 팀과 바로 이 논쟁을 벌였습니다. 그들은 안전성 평가를 실행했고, 모델이 통과했으며, 자체 데이터로 파인튜닝을 마치고 출시할 준비가 되어 있었습니다. 저는 평가를 언제 다시 실행할 계획이냐고 물었습니다. 방 안이 잠시 조용해졌습니다. 솔직한 답은 "다시 할 생각이 없었다"였기 때문입니다. 모델은 게이트를 먼저 통과하고, 정작 그것을 망가뜨리는 단계는 그 뒤에 옵니다. 그런 다음 모델은 사실상 가드레일이 벗겨진 채로 프로덕션에 투입되고, 서류상으로는 모두 안전하다고 적혀 있습니다.
모델은 안전성을 파괴하는 단계보다 먼저 안전성 검사를 통과합니다. 그 이후에 다시 검사하는 사람은 거의 없습니다.
그래서 우리는 안전성 평가를 그 이후, 즉 파인튜닝이 끝난 뒤로 옮겼습니다. 그리고 그것을 인테이크(수용) 게이트가 아니라 릴리스 게이트로 만들었으며, 어떤 파인튜닝이든 이전의 안전성 증명을 무효화하는 사건으로 취급했습니다. 이렇게 말로 꺼내 놓고 보면 너무 뻔한 이야기처럼 들립니다. 그런데도 이것이 표준 관행이 아닌 이유는 아무도 쓰지 않던 그 게이트와 똑같습니다: 평가하기 편한 시점은 수용 단계이고, 파인튜닝을 할 때마다 다시 평가하는 것은 마찰이기 때문이죠. 마찰은 적이지만, 이 경우에는 통과 보고서와 무방비 상태의 모델 사이에 서 있는 유일한 존재입니다.
포이즈닝은 반대 방향에서 같은 점을 보여줍니다. 연구에 따르면 단 250개의 오염된 문서만으로도 130억 파라미터 모델에 백도어를 심을 수 있으며 — 이는 학습 코퍼스의 약 0.00016%에 해당합니다. 데이터를 대규모로 훼손할 필요가 없습니다. 반올림 오차 수준의 양이면 충분합니다. Microsoft는 2026년 2월에 이에 대한 진정으로 고무적인 대응책을 발표했습니다 — 트리거 문구를 모르는 상태에서도 독특한 어텐션 패턴을 포착해 오염된 모델을 식별할 수 있는 "슬리퍼 에이전트" 탐지 기법입니다. 이는 이전까지 사실상 탐지 불가능에 가까웠던 공격에 대해 제가 본 최초의 실질적인 방어책입니다. 또한 이것은, 누군가 그것을 실제로 구현하는 엔지니어링을 해내기 전까지는 여러분의 CI/CD 파이프라인이 아니라 연구 논문 속에나 존재하는 바로 그런 종류의 역량이기도 합니다.
에이전트는 프롬프트 인젝션을 킬 체인으로 바꿔 놓았다
수년 동안, 조작된 모델이나 프롬프트 인젝션으로 벌어질 수 있는 최악의 상황은 잘못된 출력이었습니다. 모델이 뭔가 잘못된 말을 하고, 하지 말아야 할 무언가를 흘리고, 여러분을 난처하게 만드는 것이었죠. 제한적이고. 성가시지만. 견딜 만한 일이었습니다.
에이전틱 AI는 그 한계를 없애 버렸습니다.
AI 에이전트는 챗 모델에는 없는 도구 접근 권한, 자격 증명, 실행 권한을 가지고 있습니다. 그래서 에이전트가 읽는 무언가에 악의적인 명령을 주입하면, 여러분은 더 이상 답변을 오염시키는 것이 아니라 — 실제로 행동할 수 있는 시스템에 명령을 내리는 것입니다. GitHub Copilot에는 CVSS 7.8 등급으로 2025년 8월에 패치된 원격 코드 실행 취약점 CVE-2025-53773이 있었는데, 저장소 문서에 심어진 프롬프트 인젝션이 에이전트를 자율적인 "YOLO 모드"로 빠뜨려 전체 시스템 장악으로까지 확대될 수 있었습니다. 에이전트가 악의적인 주석을 읽고 그것을 코드로 실행하자, 그 머신은 장악당했습니다.
그리고 2025년 7월의 Amazon Q 공급망 사고가 있었습니다: 악의적인 cleaner.md 프롬프트 템플릿이 잘못 설정된 GitHub 토큰을 통해 주입되었고, 출시된 버전이 매우 큰 설치 기반으로 파괴적인 명령을 실어 보냈습니다. 그리고 2026년에는 OpenClaw 에이전트 생태계가 그해 최초의 대형 AI 에이전트 보안 위기가 되었습니다 — 63일 만에 138건의 CVE, 135,000개가 넘는 노출된 인스턴스, 그리고 마켓플레이스 내 스킬의 12%가 악성으로 판명되었습니다. HiddenLayer의 2026년 위협 보고서는 이제 AI 침해 약 8건 중 1건을 에이전틱 시스템과 연결 짓고 있습니다.
이 모든 사례를 관통하는 하나의 흐름은 동일합니다: 에이전트는 조작된 단 하나의 입력을 정교하게 조율된 다중 도구 킬 체인으로 바꿔 놓는다. 한때 잘못된 문장 하나에 불과했던 것이, 실제 자격 증명을 동반한 실제 행동들의 연쇄가 됩니다. 그것이 바로 제가 지금 가장 우려하는 최전선입니다. 어떤 제품 범주도 따라잡을 수 없을 만큼 빠르게 확장되고 있고, 아직 그것을 방어할 확립된 플레이북이 없기 때문입니다.
그렇다면 실제로 무엇을 해야 하는가?
사람들은 늘 저에게 이런 식으로 묻습니다: "이건 그냥 도구 하나 사면 되는 거 아닌가요?" 솔직한 답은, 여러분이 조각들은 살 수 있고, 그 조각들은 빠르게 나아지고 있다는 것입니다.
벤더 지형은 어엿한 생태계로 성숙했습니다 — 자사 클라우드 및 플랫폼 스위트 안에서의 스캔과 AI 자재명세서 생성을 위한 Palo Alto의 Protect AI와 Wiz, 모델 레지스트리와 아티팩트 파이프라인 보안을 위한 JFrog, 런타임 탐지 및 대응을 위한 HiddenLayer, 애플리케이션 계층 LLM 통제를 위한 NVIDIA의 오픈소스 가드레일, 그리고 모델 배포에 컨피덴셜 컴퓨팅을 도입하는 Fortanix까지요. 마지막 사례는 왜 도구만으로는 그 간극을 메울 수 없는지를 잘 보여주는 예입니다: 실행 중에도 모델을 암호화된 상태로 유지하는 컨피덴셜 GPU(NVIDIA의 Hopper 및 Blackwell 세대)는 실제로 존재하지만, 그 신뢰 실행 환경을 실제 추론 파이프라인에 연결하는 일은 대부분의 팀이 애초에 사내에 보유하고 있지 않은 전문 엔지니어링입니다. 각 벤더는 자기 몫의 영역에서 진정으로 뛰어납니다. 하지만 그중 누구도 여러분의 엔드투엔드 파이프라인을 설계하거나, 그것을 여러분의 의무에 매핑하거나, 여러분 조직이 실제로 행동하는 방식을 바꾸지는 않습니다.
그리고 시장의 나머지 절반 — 대형 전략 컨설팅 회사들 — 은 정반대의 문제를 팔 것입니다: 200페이지짜리 AI 거버넌스 프레임워크, 이사회용 발표 자료, 감사 대응이 가능한 문서, 그리고 전략에만 약 50만 달러부터 시작해 구현으로 가면 수백만 달러까지 불어나는 계약이죠. 그들이 대개 하지 않는 일은 모델 서명 파이프라인을 구축하거나, 여러분의 CI/CD 안에서 ML-BOM 생성을 구성하거나, 네트워크 계층에서 섀도 AI 탐지를 세워 올리는 것입니다. 결국 여러분에게 남는 것은 바인더일 뿐, 실제 구축물은 아닙니다.
그 간극 — 스캔하는 도구와 조언하는 발표 자료 사이의 간극 — 이 바로 Veriprajna가 AI 공급망 보안을 엔지니어링으로 수행하는 이유의 전부입니다 — 보고서로서가 아니라 말이죠. 우리가 구축하는 것은 구체적입니다: 들어오는 모든 모델을 행위 기반으로 샌드박싱하고 깨끗한 모델을 여러분의 엔터프라이즈 PKI로 서명하는 자동화된 모델 검증 파이프라인; ML-BOM — 즉 머신러닝 자재명세서로, 모든 구성 요소와 그 출처를 추적하는 AI판 성분 표시 라벨 — 을 CycloneDX 표준을 사용해 파이프라인 안에서 생성하고 고정하는 것; 부상하는 CoSAI 증명 작업 위에 구축된 출처 추적과 서명; 파인튜닝 이후의 안전성 게이팅; 그리고 여러분의 보안 도구가 현재 보지 못하는 모델을 드러내는 섀도 AI 탐지입니다.
이 대부분을 해내기 위한 표준은 이미 존재합니다. CycloneDX ML-BOM, CoSAI 모델 서명, 그리고 NIST의 갱신된 적대적 ML 분류 체계(AI 100-2)는 모두 오늘날 공개되어 사용 가능합니다. 문제는 결코 지식의 문제가 아니었습니다. Kiteworks의 2025년 측정에 따르면, 조직의 83%는 여전히 자동화된 AI 보안 통제를 갖추고 있지 않습니다 — 그들이 앞이 보이지 않는 채로 나아가는 것은 플레이북이 없어서가 아니라, 그것을 구현할 엔지니어링 역량을 아무도 갖고 있지 않기 때문입니다. 부족한 것은 아이디어가 아니라 손(일손)입니다.
여기에는 규제의 시계도 째깍거리고 있습니다. EU AI법은 2026년 8월 2일에 전면 시행되며, 고위험 시스템에 대해서는 실질적인 기술 문서를 요구합니다 — 학습 데이터의 출처, 적합성 평가, 그리고 ML-BOM이 만들어내도록 설계된 바로 그런 종류의 공급망 증명 말입니다. AI 구성 요소의 수입업체와 유통업체는 자신들이 하류로 전달하는 것을 검증해야 하며, 공급자와 그들의 서드파티 구성 요소 공급업체는 각자가 공유할 정보와 기술적 접근에 대해 서면으로 합의해야 합니다. 저는 그 조항의 조용한 이면을 고객들에게 이야기하기 시작했습니다: 그 법이 실제로 효력을 발휘하기 시작하면, 모델의 출처는 더 이상 여러분 혼자 떠안을 문제가 아니게 됩니다 — 여러분의 공급업체가 그것을 서면으로 증명해야 하고, 그러지 못하는 곳은 그냥 쓸 수 없게 될 것입니다. 모델 출처를 있으면 좋은 것 정도로 취급하는 기업들은 그것이 곧 제출 의무 사항임을 알게 될 것입니다.
실제로 예산을 움직인 슬라이드
저는 이런 대화가 대개 끝나는 지점에서 마무리하겠습니다: 이사회 앞에서 말이죠.
저는 잘 만들어진 수많은 보안 제안이 예산을 확보하지 못하는 것을 지켜봤습니다. 그것들이 보안 사안으로 제시되었기 때문이죠 — 추상적인 위험, 가상의 공격자, 보험처럼 들리는 범주 말입니다. 효과가 있었던 발표는 테이블 위에 단 하나의 숫자를 올려놓은 것이었습니다: 섀도 AI 유출의 평균 비용 463만 달러를, 그것을 예방하는 통제를 구축하는 비용과 나란히 놓은 것이죠. 두려움이 아니라. 차이(델타)입니다. 여기 정량화된 위험이 있고, 여기 그것을 없애는 데 드는 비용이 있으며, 여기 그 차이가 있습니다.
그런 구도가 효과적인 이유는 이 문제가 실제로 작동하는 방식에 충실하기 때문입니다. 위협은 이색적인 것이 아닙니다. 그것은 기본 워크플로 — 모델을 가져와, 파인튜닝하고, 배포한 뒤, 다시는 들여다보지 않는 것 — 이며, AI로 무언가를 구축하는 모든 조직에서 돌아가고 있습니다. 그리고 이제는 거의 모든 조직이 그렇습니다. CISO 예산이 이를 반영합니다: 약 85%의 조직이 2026년을 앞두고 사이버 보안 지출을 늘렸으며, AI 보안이 가장 많이 논의되는 항목입니다.
모델은 여러분의 환경에서, 여러분이 가진 가장 가치 있는 것인 동시에 인터넷의 낯선 이에게서 내려받은 검증되지 않은 실행 가능 코드 조각이기도 한, 유일한 산출물입니다. 그것을 그 두 가지로 동시에 취급하기 전까지는 — 코드처럼 검증하고, 공급망처럼 추적하며, 바꿀 때마다 다시 점검하기 전까지는 — 여러분이 안전하다고 말하는 그 보고서는 실제로는 아무도 쓰지 않는 통제를 감사하고 있는 셈입니다. 만약 여러분이 어디서부터 시작할지 고민하고 있다면, 바로 거기서 시작하십시오: 모델 카드를 믿는 것을 멈추고, 모델이 실행될 때 무엇을 하는지 지켜보십시오.
