소버린 AI, 이제 모델보다 공급망 검증이 진짜 주권이라는 얘기

소버린 AI의 초점이 '국산 모델'에서 '공급망 검증'으로 이동 중

• 최윤성 교수의 핵심 메시지는 꽤 직설적임. 국산 AI 모델을 쓴다고 바로 주권이 생기는 게 아님

  • 모델 안에는 오픈소스 패키지, 외부 데이터셋, 서드파티 도구가 복잡하게 엮여 있음
  • 그래서 진짜 주권은 어떤 모델을 쓰든 그 공급망을 검증하고 차단할 수 있는 능력이라는 주장임

• 프런티어 LLM 도입은 생산성을 올리지만, 동시에 종속성도 폭발시킴

  • 고도 추론이나 에이전트 워크플로우를 만들수록 내부 구조가 복잡해지고 외부 자원 의존도도 커짐
  • 오픈AI, 구글, 앤트로픽이 참여한 프런티어 모델 포럼도 최신 AI 모델의 복잡성이 커질수록 취약점 파급력이 커진다고 봄

• 특히 개발자가 AI가 추천한 패키지를 그냥 설치하는 습관이 위험 포인트로 지적됨

  • 명령어 한 줄로 수백 개의 전이적 의존성이 딸려 들어올 수 있음
  • 겉으로는 안전한 패키지처럼 보여도, 깊은 의존성 트리 어딘가에서 악성코드가 들어오면 추적이 쉽지 않음

LiteLLM과 Trivy 사례가 보여준 공급망 공격의 현실감

• LiteLLM 사례는 AI 생태계의 공통 부품이 털릴 때 파급력이 얼마나 큰지 보여줌

  • LiteLLM은 여러 LLM API를 연결해주는 공통 라이브러리임
  • 월 9700만 다운로드를 기록한 이 라이브러리가 침해됐을 때, 이를 의존성으로 끌어오던 패키지만 1705개였음

• 더 무서운 건 직접 설치하지 않아도 감염될 수 있다는 점임

  • 개발자가 LiteLLM을 직접 내려받지 않았더라도, 다른 패키지가 연쇄적으로 호출하면 위험이 퍼질 수 있음
  • 최 교수는 이를 깊은 종속성 트리를 타고 악성코드가 유입되는 눈덩이 효과라고 설명함

• Trivy 사례는 방어 도구 자체가 공격 경로가 될 수 있음을 보여줌

  • Trivy는 컨테이너 이미지와 클라우드 환경 취약점을 찾는 대표적인 오픈소스 스캐너임
  • 그런데 이 도구의 깃허브 저장소 태그 76개가 태그 포이즈닝 공격으로 하룻밤 사이 악성 커밋으로 교체됐다고 언급됨
  • 워크플로우 파일을 바꾸지 않아도 다운스트림 CI/CD가 자동 감염될 수 있었다는 점이 핵심임

AIBOM은 AI 시대의 공급망 명세서로 제시됨

• 최 교수는 대안으로 AIBOM을 제시함

  • 기존 SBOM은 소프트웨어 부품 목록을 보여주지만, 모델 가중치 같은 비코드 자산까지 충분히 읽어내지는 못함
  • AIBOM은 모델 가중치, 학습 데이터셋, 하이퍼파라미터, 에이전트 도구 명세까지 포함하는 확장 명세서임

• 기업이 당장 해야 할 실천 과제도 꽤 구체적임

  • AI 소프트웨어 인벤토리를 만들고 CI/CD 파이프라인 검증 게이트와 연결해야 함
  • 외부 패키지와 모델의 출처, 무결성 해시를 등록해야 함
  • 에이전트 권한은 최소화해서 의도치 않은 파일 접근이나 외부 호출을 줄여야 함

• 이건 단순 보안 체크리스트가 아니라 운영 구조 문제임

  • 모델을 누가 만들었는지보다, 모델과 도구가 어떤 경로로 들어와 어떤 권한으로 실행되는지가 더 중요해짐
  • AI 에이전트가 코드를 쓰고 배포 파이프라인까지 만지는 환경에서는 공급망 검증이 곧 런타임 보안으로 이어짐

소버린 AI가 지정학 리스크와도 연결됨

• AI가 전략 자산이 되면서 모델 접근권 자체가 정치적 변수로 바뀌고 있음

  • 미국의 대중국 AI 칩·모델 수출 통제, 주요 기술 기업의 API 차단 같은 사례가 이미 나옴
  • 최 교수는 모델 접근권은 동맹국이라도 언제든 끊길 수 있다고 봄

• 그래서 독자 모델 개발만으로는 부족하다는 결론으로 이어짐

  • 모델을 국산화해도 그 모델을 돌리는 패키지, 데이터, 파이프라인이 외부 생태계에 종속돼 있으면 기술 독립이라고 보기 어려움
  • 소버린 AI를 모델 주권에서 공급망 주권으로 확장해야 한다는 게 기사 전체의 결론임

---

기술 맥락

• 여기서 중요한 선택은 보안을 모델 레벨 문제가 아니라 공급망 레벨 문제로 본 거예요. AI 모델이 아무리 국산이어도 학습 데이터, 패키지, 빌드 도구, 배포 파이프라인이 외부 의존성으로 가득하면 공격면은 그대로 남거든요.

• AIBOM이 필요한 이유도 그 지점에 있어요. 기존 SBOM은 코드 패키지 중심이라 모델 가중치나 데이터셋 같은 AI 자산을 제대로 표현하기 어렵고, 에이전트가 호출하는 도구 목록까지 추적하지 못하면 실제 실행 경로를 놓치게 돼요.

• LiteLLM과 Trivy 사례는 검증 위치가 왜 CI/CD 앞단이어야 하는지 보여줘요. 실행 이후에 프롬프트 필터나 런타임 정책으로 막으려 하면 이미 악성 의존성이 빌드에 들어온 뒤라 늦을 수 있거든요.

• 한국 기업 입장에서는 자체 모델을 만들지 않더라도 이 이슈를 피할 수 없어요. 해외 모델, 오픈소스 모델, 사내 파인튜닝 모델을 섞어 쓰는 환경일수록 출처와 무결성, 권한 범위를 자동 검증하는 체계가 필요해요.