- 제1부 AIBOM이 여는 AI 공급망 보안의 다음 단계

AI 시대, “무엇을 만들었는가”를 넘어 “무엇으로 학습했고 무엇에 의존하는가”를 증명해야 합니다

1. 서론: AI는 이제 ‘공급망’의 신뢰입니다

기업의 디지털 전환이 소프트웨어 중심이었다면, 이제는 AI 중심으로 재편되고 있습니다. 하지만 많은 조직이 여전히 AI를 “애플리케이션에 붙는 기능” 정도로 이해하고 있습니다. 이 관점은 빠르게 한계에 도달하고 있습니다. 

그 이유는 AI 시스템이 단순한 코드의 집합이 아니라, 모델(Model), 데이터셋(Dataset), 프레임워크(Framework), 런타임(Runtime), 인프라스트럭처(Infrastructure), 정책(Policy), 운영 파이프라인(MLOps)이 결합된 복합적인 공급망이기 때문입니다.

기존 소프트웨어 보안에서는 SBOM(Software Bill of Materials)이 핵심 도구로 자리 잡아왔습니다. SBOM은 어떤 오픈소스 라이브러리와 패키지가 포함되어 있는지, 어떤 라이선스를 사용하는지, 알려진 취약점(CVE)이 있는지를 추적하는 데 매우 효과적입니다.

그러나 AI 시스템에서는 이것만으로 충분하지 않습니다. AI의 위험은 코드 취약점뿐 아니라, 학습 데이터의 출처와 품질, 모델 편향성(Model Bias), 저작권/개인정보 이슈(Copyright Infringement), 모델 도난(Model theft/Extraction) 및 역공학(Reverse Engineering), 프롬프트 인젝션(Prompt Injection), 데이터 포이즈닝(Data Poisoning) 같은 영역에서 발생하기 때문입니다.

이 지점에서 등장하는 개념이 바로 AIBOM(AI Bill of Materials)입니다. AIBOM은 AI/ML 시스템을 구성하는 핵심 요소를 문서화하고, 추적 가능한 형태로 관리하기 위한 명세이자 실무 프레임워크 입니다. 단순히 “어떤 패키지를 썼는가”를 넘어서, 어떤 모델을 어떤 목적과 라이선스로 사용했고, 어떤 데이터로 학습/파인튜닝했으며, 어떤 인프라와 정책에서 운영되는지까지 관리 범위를 확장합니다.

이제 기업이 고객에게 AI 서비스를 제공할 때 필요한 질문은 달라졌습니다.

 • 이 모델은 어디서 왔는가?

 • 어떤 데이터가 들어갔는가?

 • 어떤 제한사항과 편향이 알려져 있는가?

 • 어떤 규제 요구사항을 충족하는가?

 • 문제가 생기면 무엇을 기준으로 추적·소명할 것인가?

AIBOM은 이 질문에 답하기 위한 기술적, 관리적 증거체계입니다. 앞으로는 선택이 아니라, 신뢰 가능한 AI를 위한 기본 인프라가 될 가능성이 높습니다.

2. SBOM에서 AIBOM으로 왜 패러다임이 바뀌어야 하는가

그림1. AIBOM / SBOM 비교

2.1 SBOM의 성공과 한계

SBOM은 소프트웨어 공급망 보안에서 큰 변화를 만들었습니다. Log4Shell 이후 많은 조직이 “내 시스템에 어떤 라이브러리가 포함되어 있는가?”를 빠르게 확인할 수 있는 체계의 필요성을 절감했고, SBOM은 이 문제를 해결하는 강력한 수단이 되었습니다.

하지만 AI 시스템에서는 다음과 같은 질문에 SBOM만으로 답하기 어렵습니다.

 • 학습 데이터셋이 저작권 문제를 일으킬 가능성은 없는가?

 • 개인정보(PII) 또는 민감정보가 학습 데이터에 포함되었는가?

 • 모델의 알려진 편향(Known bias)과 사용 제한(limitation)은 무엇인가?

 • 어떤 파인튜닝/정렬(Alignment) 과정이 적용되었는가?

 • 모델 카드와 평가 지표는 신뢰 가능한가?

 • 프롬프트 인젝션·도구 호출 악용에 대한 안전장치는 있는가?

즉, SBOM이 “코드 중심의 공급망 가시화”라면, AIBOM은 “AI 시스템 전체의 신뢰, 위험, 책임성, 가시화”입니다.

2.2 AIBOM이 다루는 대상: 코드에서 모델/데이터/운영으로 확장

AIBOM의 관리 대상은 다음과 같이 확장됩니다.

 • 알고리즘/모델: 학습 모델 버전, 고유(독점) 알고리즘, 오픈소스 AI 프레임워크(PyTorch, TensorFlow 등), 하이퍼파라미터, 성능지표, 모델 카드 정보

 • 데이터 소스: 학습/검증/테스트 데이터셋, 데이터 출처, 라이선스, 수집 방식, 품질, 윤리성, 개인정보 포함 여부

 • 의존성: 라이브러리, 에이전트 프레임워크(LangChain 등), 런타임/툴체인/플러그인

 • 인프라: 클라우드 서비스, GPU/가속기, 저장소, 벡터DB, 추론 환경

 • 메타데이터: 버전, 라이선스, 출처, 공급자, 사용 목적, 제한사항, 추적 정보

이러한 범위 확장은 단순한 문서화의 증가가 아니라, AI 리스크의 본질이 바뀌었다는 사실을 반영합니다.

2.3 AIBOM이 필요한 이유: “CVE”를 넘어 “행동 결과”를 관리해야 하기 때문입니다

AI 시스템은 같은 코드라도 데이터와 모델, 프롬프트, 운영 환경에 따라 전혀 다른 결과를 냅니다. 즉, 위험은 정적인 코드 취약점뿐 아니라 동적인 행위 결과로 나타납니다.

예를 들어 다음과 같습니다.

 • 데이터 포이즈닝: 학습 데이터 오염으로 모델이 특정 조건에서 오작동

 • 모델 도난: 모델 파라미터 탈취 또는 API 기반 추정 공격

 • 저작권/개인정보 이슈: 저작권 데이터 무단 학습 이슈

 • 편향성, 유해성, 환각: 신뢰와 규제 리스크 동시 발생

 • 프롬프트인젝션 및 툴체인 악용: 에이전트 기반 시스템의 실행 계층 악용

이 문제는 더 이상 개발팀만의 문제가 아닙니다. 보안, 법무, 데이터, 제품, 경영진이 함께 봐야 하는 조직 전체의 리스크 관리 체계입니다.

3. AIBOM의 핵심 구성요소: 무엇을 문서화해야 하는가

AIBOM을 “AI용 자재명세서”라고 부를 수는 있지만, 실제로는 그보다 훨씬 풍부한 메타데이터 구조를 요구합니다. 실무 관점에서는 최소한 다음 다섯 축을 문서화해야 합니다.

3.1 모델(Algorithm/Model) 계층

AIBOM의 중심은 모델입니다. 여기서 중요한 것은 단지 모델명만 적는 것이 아닙니다.

문서화해야 할 핵심 항목 예시

 • 모델명, 버전, 공급자

 • 모델 유형(LLM, SLM, 분류기, 추천모델 등)

 • 아키텍처 계열(예: Llama 계열)

 • 사용 목적

 • 입력/출력 포맷

 • 추론/배포 환경 요구사항

 • 라이선스(상업적 사용 가능 여부 포함)

 • 알려진 제한사항/편향/부적절한 사용 사례

 • 모델 카드 링크 및 평가 리포트

특히 기업 내부에서 파인튜닝한 모델의 경우, “베이스 모델”과 “파생 모델”의 관계를 추적할 수 있어야 합니다. 그래야 라이선스 조건 상속, 성능 비교, 사고 발생 시 영향 범위 분석이 가능합니다.

3.2 데이터(Data) 계층

AI에서 데이터는 코드만큼 중요하며, 경우에 따라 더 중요합니다. 실제로 법적 분쟁과 신뢰 이슈는 데이터에서 많이 발생합니다.

문서화해야 할 핵심 항목 예시

 • 데이터셋 명칭 / 버전 / 출처

 • 수집 방법(크롤링, 구매, 내부 생성, 제휴 제공 등)

 • 라이선스/사용권한

 • 개인정보 포함 여부(PII/민감정보), 익명화 여부 및 방법

 • 데이터 전처리/필터링 정책

 • 품질 검증 방식

 • 편향 위험

 • 사용 범위(학습/검증/테스트/평가)

데이터를 문서화한다는 것은 단순한 목록화가 아니라, “이 데이터로 이 모델을 만들었다”는 책임 경로를 남기는 것입니다. 이 경로가 없으면 향후 저작권 소송, 개인정보 이슈, 모델 편향 이슈가 발생했을 때 기업은 기술적으로도 법적으로도 방어하기 어렵습니다.

3.3 소프트웨어 의존성(Dependency) 계층

AI 시스템은 결국 소프트웨어 위에서 동작합니다. PyTorch, TensorFlow, Transformers, tokenizers, LangChain, vector DB client, inference server, observability agent 등 수많은 의존성이 얽혀 있습니다. 이 계층에서는 다음 요소가 추가로 중요합니다.

 • 모델 로딩/변환 도구의 신뢰성

 • 프롬프트/에이전트 프레임워크의 보안성

 • 플러그인/툴 호출 체인의 권한 설계

 • 런타임 버전 불일치에 따른 재현성 문제

 • 모델 서빙 엔진(vLLM, TGI 등)과 보안 설정 TGI (Text Generation Inference) — Hugging Face에서 제공하는 LLM 서빙 툴킷

즉, AIBOM은 SBOM을 대체하는 개념이 아니라, SBOM을 포함 및 확장하는 상위 개념으로 보는 것이 현실적입니다.

3.4 인프라(Infrastructure) 계층

같은 모델도 어떤 인프라에서 구동하는지에 따라 보안, 성능, 비용, 규제 리스크가 달라집니다.

 • 클라우드 지역(데이터 국외 이전 이슈)

 • GPU 리소스 유형 및 멀티테넌시 구조

 • 네트워크 경로 및 프록시/게이트웨이

 • 모델 아티팩트 저장소 및 서명 검증 여부

3.5 메타데이터와 거버넌스(Governance) 계층

AIBOM이 진짜 힘을 발휘하려면 단순 인벤토리가 아니라 운영 가능한 메타데이터 체계여야 합니다. 핵심은 다음 세 가지입니다.

 • 추적성(Traceability): 누가, 언제, 무엇을, 왜 바꿨는지를 기록

 • 재현성(Reproducibility): 동일 버전과 환경으로 결과 재현

 • 감사 가능성(Auditability): 사고나 규제 점검 시 증거로 제시

결국 AIBOM은 “문서”라기보다 AI 거버넌스의 데이터 모델입니다.