AI 자재 명세서(AIBOM)란 무엇인가요?
2026년 5월, 공식 OpenAI 릴리스를 사칭한 악성 Hugging Face 리포지토리가 플래그 지정 및 제거되기 전에 플랫폼의 인기 순위 1위에 올랐습니다. 실제 모델 카드를 거의 한 줄씩 그대로 복사했기 때문에 해당 목록은 합법적으로 보였고, 이미 이를 가져온 사람은 알 방법이 없었습니다. 소프트웨어 종속성 스캔은 라이브러리와 패키지를 검사하지만, 침해는 모델 자체에 존재했기 때문입니다.
AI 자재 명세서(AIBOM)는 해당 스캔이 제공하지 못한 것을 제공합니다. 즉, 손상된 모델 또는 오염된 데이터셋이 이미 사용자 환경에 존재하는지 확인할 수 있는 방법입니다.
AIBOM은 AI 시스템을 구성하는 데이터셋, 모델, 프레임워크 및 종속성의 구조화된 인벤토리이며, 각 구성 요소의 출처가 기록됩니다. 여기에는 원래 문서화되지 않는 자산, 즉 타사 데이터, 사전 학습된 모델, 오픈소스 라이브러리가 포함됩니다.
AIBOM과 소프트웨어 자재 명세서의 관계
소프트웨어 자재 명세서는 애플리케이션의 소프트웨어 구성 요소와 종속성(라이브러리, 패키지, 버전 식별자, 라이선스)을 나열합니다. AIBOM은 이 인벤토리 관행을 학습 데이터, 모델 가중치, 모델 출처, 성능 기준선을 포함한 AI 전용 자산으로 확장합니다. OWASP BOM 표준인 CycloneDX는 SBOM과 AI/ML-BOM을 상호 운용 가능한 BOM 유형으로 정의하여 이를 구현합니다.
AIBOM의 핵심 구성 요소
AIBOM은 AI 시스템의 구성, 출처 및 운영 프로필을 정의하는 전체 구성 요소 집합을 기록합니다. CISA의 AI SBOM 최소 요소로 게시된 G7 Cybersecurity Working Group의 2026년 5월 지침은 이러한 구성 요소를 7개의 클러스터로 구성합니다.
| 구성 요소 클러스터 | 포착하는 내용 | 포함되는 이유 |
| 메타데이터 | AIBOM 작성자, 생성 날짜, 스키마 버전, 문서 식별자 | 인벤토리 아티팩트에 대한 관리 연속성을 확립합니다 |
| 시스템 수준 속성 | 소프트웨어 종속성, 프레임워크, 런타임 환경, 데이터 처리 로직 | 기존 SBOM 콘텐츠에 매핑되며 CVE 추적을 가능하게 합니다 |
| 모델 | 모델 식별 정보, 아키텍처, 가중치 생성 방식(학습, 파인튜닝 또는 증류), 문서화된 제한 사항 | 모델 가중치에는 패키지 관리자에 해당하는 개념이 없으며, 출처 정보는 변조 식별을 가능하게 합니다 |
| 데이터셋 속성 | 학습, 검증 및 테스트 데이터셋의 식별 정보, 출처, 라이선스, 수집 방법론, 적용된 전처리 | 데이터 오염은 소프트웨어 분석으로 식별할 수 없으며, 출처 기록은 학습 데이터가 변조되었는지 추적합니다 |
| 핵심 성과 지표 | 배포 시 기록된 정확도, 공정성 및 적대적 복원력 벤치마크 | 행동 기준선을 설정하며, 성능 저하는 적대적 조작을 나타낼 수 있습니다 |
| 인프라 | 물리 및 가상 인프라, 특수 AI 하드웨어(GPUs, TPUs)를 위한 Hardware BOM 링크 | 모델을 생성하고 실행하는 컴퓨팅 환경을 문서화합니다 |
| 문서 구조 및 업데이트 주기 | AIBOM 형식 버전 관리, 업데이트 트리거, 수명 주기 전환 기록 | 인벤토리가 언제 어떻게 업데이트되는지 정의하며, 각 수명 주기 전환을 영향을 받는 클러스터 전반의 필수 변경 사항과 연결합니다 |
이 7개의 클러스터는 AIBOM에 무엇이 포함되는지를 설명합니다. 각 항목을 언제 채우는지는 모델 수명 주기에 따라 달라지며, 기록은 한 번에 완성되는 것이 아니라 단계적으로 구축됩니다.
모델 수명 주기 전반에서 AIBOM이 생성되고 유지되는 방식
AIBOM 기록은 4개의 수명 주기 단계에 걸쳐 형성되며, 각 단계는 위 구성 요소 분류의 특정 클러스터를 채웁니다.
- 데이터 소싱 및 준비. AIBOM은 여기서 Dataset Properties와 함께 시작됩니다. 모델 학습이 시작되기 전에 모든 학습, 검증 및 테스트 데이터셋의 식별 정보, 출처, 라이선스 및 무결성을 캡처합니다. 이 클러스터는 초기 수집 시점과 모든 재학습 또는 파인튜닝 이벤트마다 업데이트합니다.
- 모델 학습 및 파인튜닝. 학습 시 입력 데이터셋, 학습 코드, 하이퍼파라미터 구성 및 결과 모델 가중치 간의 연결 관계를 기록합니다. 파인튜닝 이벤트는 모델 클러스터와 데이터셋 클러스터 모두의 업데이트를 요구합니다.
- 빌드 및 배포. 배포 시 소프트웨어 종속성, 프레임워크 및 런타임 환경 세부 정보로 System Level Properties 클러스터를 완전히 채웁니다. KPI 기준값이 기록됩니다. 인프라 구성 요소는 문서화되거나 HBOM을 통해 연결됩니다.
- 지속적인 모니터링 및 유지 관리. AIBOM 유지 관리는 이벤트 기반입니다. 7개 클러스터 전반의 모든 구성 요소 변경은 재학습된 모델, 패치된 종속성, 데이터셋 버전 및 인프라 변경을 포함해 업데이트를 트리거합니다. 자동화된 검색 도구와 기계 판독 가능 형식은 변경이 발생할 때 기록을 업데이트하여 정확성을 유지합니다.
이 4단계 전반에서 AIBOM이 신뢰성을 유지하려면 형식과 업데이트 규칙이 사전에 고정되어 있어야 하며, 이것이 현재 표준이 규정하는 내용입니다.
AIBOM 표준 및 프레임워크
서로 맞물리는 4가지 표준이 현재 AIBOM 구현의 권위 있는 기반을 형성합니다. 각 표준은 거버넌스 스택의 서로 다른 계층을 다룹니다.
- NIST AI Risk Management Framework. NIST AI Risk Management Framework는 신뢰할 수 있는 AI의 기본 속성으로 추적 가능성과 책임성을 확립합니다. 첫 번째 릴리스인 AI RMF 1.0은 2023년 1월에 그 기준선을 설정했으며, Generative AI Profile은 2024년 7월에 이를 생성형 시스템으로 확장했습니다. NIST의 2025년 4월 보고서 AI 100-5e2025는 AI 공급망을 SBOM 메커니즘과 명시적으로 연결하며, 투명성 수단으로 소프트웨어 자재 명세서와 함께 모델 카드 및 데이터 카드를 언급합니다.
- OWASP CycloneDX ML-BOM. CycloneDX v1.5에서 도입되고 이후 버전에서 확장된 ML-BOM 기능은 출처 문서화 및 데이터셋에 대한 윤리적 고려 사항을 포함해 AI/ML 시스템용 데이터셋, 모델 및 구성을 표현합니다.
- SPDX 3.0 AI 및 데이터셋 프로필. ISO/IEC 표준인 SPDX는 3.0 버전에 AI 및 데이터셋 프로필을 추가했습니다. 이러한 프로필은 AI 모델, 학습 데이터, 프롬프트 템플릿, AI 에이전트 및 라이선스를 문서화합니다.
- CISA 및 G7 최소 요소. CISA는 SBOM 최소 요소를 2025년 8월에 게시했으며, 여기에는 AI 소프트웨어가 포함됩니다. 2026년 5월에는 모든 G7 회원국과 EU의 사이버보안 기관이 공동 지침을 발표하여 공동 G7 지침에 명시된 AI SBOM의 잠재적 요소 7개 클러스터를 정의했습니다.
AIBOM 도입은 아직 초기 단계이며, 현재 구현은 종종 불완전하거나 부정확합니다. 그러나 이러한 표준은 구축을 위한 기반을 제공합니다.
보안, 규정 준수 및 감사 가능성 측면에서 AIBOM이 중요한 이유
보안 측면에서 AIBOM은 데이터셋 출처와 모델 가중치 체크섬을 기록하므로 팀은 모델이 변조된 데이터로 학습되었는지 조사할 수 있습니다. 취약점이나 손상된 구성 요소가 AI 인프라에 영향을 미칠 때 AIBOM은 어떤 시스템이 영향을 받는지 알려줍니다.
규정 준수 측면에서 EU AI Act는 특정 AI 시스템 및 모델에 대해 기술 문서와 학습 콘텐츠 요약을 포함한 투명성 및 문서화 의무를 포함합니다. AIBOM은 구조화된 구성 기록을 생성함으로써 이러한 의무를 지원합니다.
감사 가능성 측면에서 AIBOM은 감사자와 incident response team이 특정 AI 시스템이 무엇으로 구축되었는지 물을 때 추적 가능하고 버전 관리된 답변을 제공합니다. 이 기록은 어떤 데이터셋이 이를 학습시켰는지, 어떤 모델 가중치가 배포되었는지, 어떤 프레임워크와 종속성이 이를 지원하는지를 보여줍니다. 이 기록이 없으면 AI 구성에 대한 모든 감사 질문에 대한 대응은 기껏해야 재구성 작업에 불과합니다.
이러한 각 결과는 기록이 정확하고 최신이라는 가정에 기반합니다. 엔터프라이즈 규모에서 이 상태에 도달하려면 노력만으로는 제거할 수 없는 구조적 제약에 부딪히게 됩니다.
AIBOM 구현의 과제
구조적 제약으로 인해 조직의 성숙도나 리소스 수준과 관계없이 AIBOM 구현은 어렵습니다.
- 표준 및 도구의 미성숙. CycloneDX ML-BOM, SPDX 3.0 AI 프로필 및 G7 지침은 모두 최근에 등장했기 때문에 관행과 도구가 아직 정착되는 중입니다.
- 불투명한 타사 모델. 추론 API를 통해 접근하는 독점 기반 모델은 내부 구조에 대해 거의 공개하지 않습니다. 이름, 버전, 엔드포인트, 액세스 제어 및 공급업체 보증은 기록할 수 있지만, 폐쇄형 모델의 전체 구성은 여전히 파악하기 어렵습니다.
- 학습 데이터 출처. 외부에서 학습된 모델의 경우 출처가 공개되지 않을 수 있습니다. 내부 모델의 경우 사후 재구성은 신뢰할 수 없기 때문에 학습 중에 이를 캡처해야 합니다.
- 빠른 모델 버전 관리. 각 재학습 또는 파라미터 변경은 고유한 위험 프로필을 가진 새로운 실질적 버전을 생성하며, 이는 어떤 수동 프로세스로도 대규모에서 추적할 수 없는 버전 확산을 초래합니다.
- 이기종 환경. 엔터프라이즈 AI는 클라우드 제공업체, 온프레미스 인프라, SaaS AI 도구, 타사 애플리케이션에 내장된 AI, 에이전트형 시스템 및 벡터 데이터베이스에 걸쳐 있습니다.
이러한 제약은 외부적이므로 할 수 있는 최선은 이를 고려해 설계하는 것입니다. 다음 섹션의 실패는 그 반대이며, 이는 사용자가 방지해야 할 문제입니다.
일반적인 AIBOM 구현 실수
| 실수 | 결과 |
| 감사를 위해 생성되는 일회성 문서로 AIBOM을 취급하는 것 | incident response가 더 이상 프로덕션을 반영하지 않는 기록을 기반으로 의사 결정을 내리게 됩니다 |
| 인벤토리를 수작업으로 유지 관리하는 것 | 모델, 데이터셋 및 API 변경 속도가 사람이 운영하는 어떤 프로세스보다 빠르므로 기록이 최신 상태에서 벗어납니다 |
| 출처 없이 모델 이름과 버전만 기록하는 것 | 데이터 및 모델 오염은 식별할 수 없는 상태로 남습니다. 식별은 학습 계보, 가중치 체크섬 및 사후 재구성할 수 없는 실행 메타데이터에 의존하기 때문입니다 |
| 엔지니어링 도구와 분리된 독립형 규정 준수 파일로 AIBOM을 운영하는 것 | 두 개의 인벤토리가 형성되어 서로 달라집니다. CISA의 SBOM 지침은 자재 명세서를 공급망 위험을 위한 중첩 인벤토리로 정의하며, SBOM 도구 체인 외부에서 AIBOM을 운영하면 그 연결이 끊어집니다 |
| 인벤토리 범위를 IT가 승인한 AI로 제한하고 shadow AI를 제외하는 것 | 기록에 체계적인 사각지대가 남습니다 |
위의 각 오류는 프로세스 선택의 결과이므로, 각각에 대응하는 프로세스 수정 방법이 있습니다. 아래 관행은 인벤토리를 정적 파일에서 운영 통제로 전환합니다.
AIBOM 모범 사례
다음 조치는 AIBOM 프로그램을 정적 문서에서 운영 거버넌스 도구로 전환합니다.
- 자동화된 검색 및 생성 배포. 이를 모델 레지스트리, API 게이트웨이 및 클라우드 AI 서비스 인벤토리에 통합합니다.
- 기계 판독 가능 형식으로 표준화. CycloneDX ML-BOM 또는 SPDX 3.0 AI 프로필을 출력합니다. 사람이 읽을 수 있는 스프레드시트는 인벤토리의 보안 가치를 운영화하는 워크플로에 투입될 수 없습니다.
- 출처를 원천에서 캡처. 학습 및 파인튜닝 데이터셋 식별자, 모델 가중치 체크섬, 학습 실행 메타데이터 및 추론 API 버전 고정을 기록합니다. 내부 모델의 경우 학습 시점에 ML 파이프라인에 출처 추적을 계측합니다.
- AIBOM을 기준으로 CI/CD 게이트 적용. 학습 아티팩트 생성, 레지스트리 푸시 이벤트 및 배포 구성 변경 시 AIBOM을 생성하고, 누락되었거나 오래된 AIBOM은 다음 환경으로의 승격을 중단시키는 파이프라인 실패로 처리합니다.
- 드리프트를 지속적으로 모니터링. 모든 배포 이벤트에서 배포된 모델 아티팩트 해시를 AIBOM에 기록된 hashes와 비교합니다. 이벤트 기반 주기는 거버넌스 기록과 오래된 문서를 구분하는 요소입니다.
- 능동적 검색을 통해 shadow AI 식별. 알려진 AI 추론 엔드포인트에 대한 연결을 식별하고, 발견된 자산을 명시적인 비거버넌스 위험 분류와 함께 AIBOM에 추가합니다.
이러한 관행은 AIBOM을 감사 아티팩트에서 살아 있는 기록으로 전환합니다. 이를 클라우드 규모에서 실행하려면 도구가 필요하며, 바로 이 지점에서 SentinelOne의 AI Security Posture Management가 역할을 합니다.
SentinelOne으로 AIBOM 거버넌스 개선
AIBOM의 품질은 이를 뒷받침하는 검색의 품질에 달려 있습니다. Singularity Cloud Security는 SentinelOne의 Cloud-Native Application Protection Platform으로, 데이터 계층을 위한 통합 Data Security Posture Management (DSPM)와 함께 AI Security Posture Management (AI-SPM) 기능을 통해 클라우드 환경 전반에서 AIBOM을 구축하고 유지합니다.
- 인벤토리를 채우는 검색. AI-SPM은 Amazon SageMaker와 같은 서비스의 작업을 포함해 사용자 환경에서 실행 중인 AI 파이프라인, ML 모델 및 종속성을 찾아냅니다. 승인된 AI와 shadow AI를 모두 포괄하므로, 열거되는 모든 구성 요소는 조용한 사각지대 없이 잠재적인 AIBOM 항목이 됩니다.
- 기록 위에 더해지는 위험 컨텍스트. 구성 검사와 Verified Exploit Paths는 목록화된 어떤 구성 요소가 잘못 구성되었거나 악용 가능한지 보여주며, DSPM은 safe-to-train 게이트를 통해 고위험 데이터를 AI 파이프라인에서 차단합니다. Prompt Security는 프롬프트와 응답을 검사하고 에이전트형 AI를 관리하여 AIBOM 거버넌스를 런타임 계층까지 확장합니다.
- 플랫폼 전반의 검증. Singularity Platform은 엔드포인트, 클라우드 및 ID 텔레메트리를 하나의 데이터 레이크로 통합하므로, 배포된 환경이 여전히 AIBOM과 일치하는지 확인할 수 있습니다. 드리프트가 발생하면 Purple AI가 개입합니다. 이는 동일한 데이터 전반에서 자율적으로 조사하는 자연어 분석가입니다. IDC에 따르면, Purple AI 고객은 위협 식별 속도가 63% 빨라졌고 평균 대응 시간(MTTR)이 55% 감소했습니다.
SentinelOne 데모 예약을 통해 AI 공급망 위험을 평가하고 클라우드 환경 전반에서 방어 가능한 AI 거버넌스 프로그램을 구축하세요.
핵심 요점
AIBOM은 AI 시스템을 뒷받침하는 데이터셋, 모델, 프레임워크 및 종속성을 인벤토리화하고 각 구성 요소의 출처를 기록합니다. 이는 학습 데이터, 모델 가중치 및 모델 출처와 같은 AI 전용 자산으로 확립된 SBOM 관행을 확장합니다.
NIST, OWASP CycloneDX, SPDX 및 G7의 표준은 AIBOM이 무엇을 기록해야 하는지 정의합니다. 이 인벤토리는 보안, 규정 준수 및 감사 가능성 측면에서 중요하지만, 모델이 변경되어도 정확성을 유지하려면 자동화된 검색, 기계 판독 가능 형식, 출처 캡처 및 CI/CD 통합이 필요합니다. 올바르게 구현하면 AIBOM은 더 이상 서류 작업이 아니라 실제로 조치할 수 있는 통제가 됩니다.
FAQ
AI 자재 명세서(AIBOM)는 AI 시스템의 구성 요소, 즉 데이터세트, 모델, 프레임워크, 소프트웨어 종속성, 그리고 출처 및 라이선스와 같은 메타데이터를 기계가 읽을 수 있는 형태로 정리한 인벤토리입니다. 그 목적은 운영에 있습니다.
모델이 손상된 것으로 확인되거나 데이터세트가 오염된 것으로 드러났을 때, AIBOM은 증거를 바탕으로 어떤 시스템에 해당 구성 요소가 포함되어 있는지, 그리고 그것이 언제 유입되었는지를 파악할 수 있게 해줍니다. 이것이 없으면 그 답을 찾는 일은 시간 압박 속에서 재구성 작업이 됩니다.
부분적으로 그렇습니다. 추론 API를 통해 접근하는 폐쇄형 파운데이션 모델의 경우, 공급업체가 학습 데이터나 가중치를 공개하지 않기 때문에 전체 내부 구성을 기록할 수는 없습니다. 그래도 확인 가능한 사항은 캡처하고 고정할 수 있습니다. 즉, 모델 이름, 버전, API 엔드포인트, 액세스 제어, 그리고 모든 공급업체 증명입니다.
이러한 항목을 우선적인 AIBOM 항목으로 기록하고 공개되지 않은 필드는 명시적으로 표시하여, 인벤토리에서 투명성이 어디까지인지 보여주고 아무 설명 없는 공백이 남지 않도록 하십시오.
G7의 2026년 5월 지침은 AIBOM 콘텐츠를 메타데이터, 시스템 수준 소프트웨어 속성, 모델 식별 정보 및 가중치 출처, 데이터세트 속성, 핵심 성과 지표, 인프라 문서화, 그리고 업데이트 주기 기록이 포함된 문서 구조의 7개 클러스터로 구성합니다.
이러한 클러스터는 함께 AI 시스템이 어떻게 구축되었는지, 무엇에서 실행되는지, 그리고 수명 주기 전반에 걸쳐 인벤토리가 어떻게 변경되는지를 문서화합니다.
현재 AIBOM 관행은 네 가지 표준과 프레임워크를 기반으로 합니다. NIST AI Risk Management Framework는 거버넌스 및 추적 가능성에 대한 기대치를 설정합니다. OWASP CycloneDX ML-BOM과 ISO/IEC 표준인 SPDX 3.0 AI profiles는 모델과 데이터세트를 위한 기계 판독 가능 형식 사양을 제공합니다.
CISA의 SBOM 최소 요소와 G7의 7개 클러스터 지침은 AI 시스템 투명성이 무엇을 포착해야 하는지 정의합니다. 이를 통해 기존 SBOM 접근 방식이 AI 인벤토리 모델로 확장됩니다.
AIBOM을 ML 파이프라인에 연결된 이벤트 기반 기록으로 취급하십시오. 모델 학습 아티팩트 생성, 레지스트리 푸시 이벤트, 재학습, 파인튜닝 및 배포 구성 변경 시 업데이트를 트리거하십시오. 배포된 모델 해시를 기록된 해시와 비교하고, 해당하는 AIBOM 기록이 없는 새로운 추론 엔드포인트 또는 레지스트리 항목에 대해 경고하십시오.
AI 보안 태세 관리 도구는 이러한 검사를 지속적으로 실행하고 드리프트가 발생하는 즉시 이를 표시할 수 있습니다. 생성이 필수적인 CI/CD 단계인 경우, 오래된 인벤토리는 관리되지 않는 모델이 프로덕션에 도달하기 전에 승격을 중단합니다.
