--- title: "소버린 AI, 이제 모델보다 공급망 검증이 진짜 주권이라는 얘기" published: 2026-07-03T21:05:02.989Z canonical: https://jeff.news/article/4591 --- # 소버린 AI, 이제 모델보다 공급망 검증이 진짜 주권이라는 얘기 최윤성 교수는 국산 AI 모델을 쓰는 것만으로는 소버린 AI가 완성되지 않는다고 지적했다. 오픈소스 패키지, 외부 데이터셋, 서드파티 도구까지 검증할 수 있는 AI 공급망 보안 체계가 있어야 진짜 주권이라는 주장이다. ## 소버린 AI의 초점이 '국산 모델'에서 '공급망 검증'으로 이동 중 - 최윤성 교수의 핵심 메시지는 꽤 직설적임. 국산 AI 모델을 쓴다고 바로 주권이 생기는 게 아님 - 모델 안에는 오픈소스 패키지, 외부 데이터셋, 서드파티 도구가 복잡하게 엮여 있음 - 그래서 진짜 주권은 어떤 모델을 쓰든 그 공급망을 검증하고 차단할 수 있는 능력이라는 주장임 - 프런티어 LLM 도입은 생산성을 올리지만, 동시에 종속성도 폭발시킴 - 고도 추론이나 에이전트 워크플로우를 만들수록 내부 구조가 복잡해지고 외부 자원 의존도도 커짐 - 오픈AI, 구글, 앤트로픽이 참여한 프런티어 모델 포럼도 최신 AI 모델의 복잡성이 커질수록 취약점 파급력이 커진다고 봄 - 특히 개발자가 AI가 추천한 패키지를 그냥 설치하는 습관이 위험 포인트로 지적됨 - 명령어 한 줄로 수백 개의 전이적 의존성이 딸려 들어올 수 있음 - 겉으로는 안전한 패키지처럼 보여도, 깊은 의존성 트리 어딘가에서 악성코드가 들어오면 추적이 쉽지 않음 > [!WARNING] > 프롬프트 가드레일만으로는 이런 공격을 못 막음. 패키지 출처, 빌드 산출물, 태그 무결성을 파이프라인 단계에서 검증해야 함. ## 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 앞단이어야 하는지 보여줘요. 실행 이후에 프롬프트 필터나 런타임 정책으로 막으려 하면 이미 악성 의존성이 빌드에 들어온 뒤라 늦을 수 있거든요. - 한국 기업 입장에서는 자체 모델을 만들지 않더라도 이 이슈를 피할 수 없어요. 해외 모델, 오픈소스 모델, 사내 파인튜닝 모델을 섞어 쓰는 환경일수록 출처와 무결성, 권한 범위를 자동 검증하는 체계가 필요해요. ## 핵심 포인트 - LiteLLM 침해 사례에서 월 9700만 다운로드 라이브러리와 1705개 의존 패키지가 공급망 위험에 노출됨 - Trivy 저장소 태그 76개가 태그 포이즈닝으로 악성 커밋에 교체된 사례가 방어 도구의 위험성을 보여줌 - AIBOM은 모델 가중치, 학습 데이터셋, 하이퍼파라미터, 에이전트 도구 명세까지 포함하는 AI 공급망 명세서로 제시됨 - 소버린 AI는 독자 모델 확보를 넘어 어떤 모델을 쓰든 출처와 무결성을 검증할 수 있는 인프라로 확장돼야 함 ## 인사이트 한국 기업이 자체 모델을 도입하든 해외 모델을 쓰든, 실제 리스크는 의존성 트리와 빌드 파이프라인에서 터질 가능성이 큼. AI 보안은 프롬프트 가드레일만의 문제가 아니라 소프트웨어 공급망 보안의 확장판으로 봐야 함.