AI 하나에는 무엇이 연결되어 있을까? AIBOM으로 모델·데이터·API·도구의 공급망과 의존성을 추적하는 방법

World Story Factory World Story Factory 10/11/2026 07:00:00 오전

AI 하나에는 무엇이 연결되어 있을까? AIBOM으로 모델·데이터·API·도구의 공급망과 의존성을 추적하는 방법

AIBOM으로 모델·데이터·API·도구의 공급망과 의존성을 추적하는 방법

기업이 생성형 AI와 AI Agent를 도입할수록 이제 중요한 질문은 “어떤 AI를 사용하고 있는가?”에서 한 단계 더 깊어집니다. AI Governance, AI Risk Management, Software Supply Chain Security 관점에서는 그 AI가 어떤 모델·데이터·API·도구로 구성돼 있으며 어디에 의존하고 있는지까지 알아야 하기 때문입니다.

겉으로는 하나의 챗봇이나 AI Agent처럼 보여도 내부를 열어보면 이야기가 달라집니다.

모델 하나가 있고, 모델 뒤에는 데이터가 있습니다. 데이터 검색에는 Embedding Model과 Vector Database가 붙고, Agent가 실제 업무를 처리하려면 외부 API와 Tool이 연결됩니다. 여기에 인증 정보, Framework, Cloud Runtime, RAG Knowledge Base까지 연결될 수 있습니다.

이 복잡한 연결관계를 추적하기 위해 주목받는 개념이 **AIBOM(AI Bill of Materials)**입니다.

오늘은 AIBOM을 단순한 ‘AI 부품 목록’으로 설명하지 않겠습니다. AI Supply Chain → Provenance → Dependency → Version → Change Impact라는 흐름으로 따라가 보겠습니다.

금요일 오후 4시 37분, 고객지원 AI가 갑자기 이상해졌다면?

아래 이야기는 특정 기업의 실제 사고 사례가 아닙니다. 기업 AI 운영에서 발생할 수 있는 상황을 재구성한 가상의 시뮬레이션입니다.

금요일 오후 4시 37분.

고객센터 운영팀 모니터에 빨간 경고가 하나 올라옵니다.

“AI 고객지원 시스템 일부 응답 오류.”

처음에는 간단해 보였습니다. 담당자는 노트북을 열고 고객지원 Agent의 상태를 확인합니다.

서버는 정상입니다.
메인 LLM도 정상입니다.
CRM도 멀쩡합니다.

그런데 고객의 상품 정보를 검색하는 일부 질문에서만 답변이 엉뚱하게 나옵니다.

회의실에는 키보드 소리만 짧게 이어집니다.

“모델은 안 바뀌었는데요?”

“데이터베이스도 정상입니다.”

“그러면 어제 변경된 게 뭐죠?”

한참 뒤 개발자가 발견한 것은 메인 LLM이 아니었습니다.

검색 시스템에 연결된 Embedding Model의 버전이 바뀌었고, 그 결과 검색 결과의 품질이 달라졌다는 가정입니다.

문제는 여기서 끝나지 않습니다.

그 Embedding Model을 고객지원 Agent만 사용한 것이 아니라 사내 문서검색, 영업지원 Agent, FAQ 자동생성 시스템도 함께 사용하고 있었다면 어떨까요?

그 순간 질문은 완전히 바뀝니다.

“무엇이 고장 났는가?”가 아니라 “이 구성요소와 연결된 시스템이 어디까지인가?”

바로 이 지점에서 AIBOM이 필요해집니다.

AIBOM이란 무엇인가? AI 공급망 관리 가이드

AIBOM은 일반적으로 AI Bill of Materials를 뜻합니다.

제조업에 비유하면 이해가 빠릅니다.

자동차 한 대를 생각해보세요.

소비자가 보는 것은 완성차 한 대지만 제조사는 엔진, 배터리, 반도체, 브레이크, 센서가 어느 공급사에서 왔고 어떤 부품과 연결되는지 관리해야 합니다.

AI도 비슷합니다.

사용자는 화면에서 ‘AI 상담원 하나’를 만나지만 실제 시스템 뒤에는 여러 구성요소가 연결될 수 있습니다.

AI Application / Agent
↓
Foundation Model
↓
Fine-tuned Model 또는 Adapter
↓
Prompt
↓
Embedding Model
↓
Dataset / Knowledge Base
↓
RAG
↓
Vector Database
↓
Tool / MCP
↓
External API
↓
Agent Framework
↓
Cloud·Runtime·SaaS

AIBOM의 핵심은 이 구성요소의 존재만 적는 것이 아닙니다.

**어디에서 왔는가(Provenance), 어떤 버전인가(Version), 무엇에 연결됐는가(Dependency), 변경되면 어디까지 영향을 주는가(Impact)**를 함께 볼 수 있어야 실질적인 공급망 관리로 이어집니다.

OWASP GenAI Security Project는 현재 AIBOM Initiative를 통해 AI 공급망의 투명성과 보안을 위한 표준화된 접근을 추진하고 있으며 AIBOM Generator도 공개하고 있습니다.

공식 출처: OWASP GenAI Security Project – AI Bill of Materials
OWASP AIBOM 공식 페이지

필자의 기록 문장 ① — “보이지 않는 의존성은 문제가 없다는 뜻이 아니라, 아직 영향 범위를 모른다는 뜻에 가깝습니다.”

AI Inventory와 AIBOM은 무엇이 다를까? 비교 분석

여기에서 반드시 구분해야 할 개념이 있습니다.

AI Inventory입니다.

두 용어가 비슷해 보이지만 질문이 다릅니다.

구분	AI Inventory	AIBOM
핵심 질문	우리 조직에 어떤 AI가 있는가?	이 AI는 무엇으로 구성됐는가?
관리 단위	AI 자산·시스템	구성요소와 의존관계
중심 관점	Asset	Component / Dependency
Model	어떤 모델을 보유·사용하는가	이 시스템이 어떤 모델·버전에 의존하는가
Data	어떤 데이터 자산을 사용하는가	어떤 데이터가 어느 Model·시스템과 연결되는가
API	어떤 API가 존재하는가	어떤 외부 API에 의존하는가
Agent	어떤 Agent가 운영되는가	Agent 내부에 무엇이 연결되는가
주요 목적	Discovery·Ownership·Visibility	Provenance·Traceability·Dependency
다음 질문	누가 소유하고 관리하는가?	하나가 바뀌면 어디까지 영향을 받는가?

아주 간단히 기억하면 됩니다.

AI Inventory = What do we have?
AIBOM = What is it made of?

※ 모바일 화면에서는 표를 좌우로 밀어서(스크롤) 전체 내용을 확인하실 수 있습니다.

회사 창고에 어떤 장비가 있는지 적은 것이 Inventory라면, 그 장비를 분해했을 때 어떤 부품이 들어가고 어느 공급사의 부품과 연결되는지를 기록한 것이 BOM에 가깝습니다.

따라서 AIBOM 글에서 모델·API·Agent 이름을 단순 나열하는 것으로 끝내면 AI Inventory와 차별성이 약해집니다.

AIBOM의 진짜 가치는 관계에 있습니다.

SBOM만 있으면 충분할까? AIBOM·AI/ML-BOM 비교 가이드

AIBOM을 이해하려면 SBOM도 알아둘 필요가 있습니다.

**SBOM(Software Bill of Materials)**은 소프트웨어를 구성하는 구성요소와 의존관계를 기록하는 개념입니다.

예를 들어 웹 서비스에 어떤 오픈소스 라이브러리와 버전이 들어 있는지 알 수 있다면 특정 취약점이 공개됐을 때 영향을 받는 시스템을 찾는 데 도움이 됩니다.

하지만 AI 시스템에서는 소프트웨어만 봐서는 충분하지 않을 수 있습니다.

모델은 무엇인지, 어떤 Dataset이 연결됐는지, 모델의 출처는 어디인지, 어떤 학습·운영 데이터와 관계가 있는지도 중요해집니다.

CycloneDX는 AI/ML-BOM을 통해 모델, 데이터셋, 구성 정보와 그 의존관계를 표현할 수 있도록 지원하고 있습니다. 데이터셋의 Provenance, 학습 방법, AI Framework 관련 정보 등을 표현하는 구조도 제공합니다.

공식 출처: CycloneDX – Machine Learning Bill of Materials
CycloneDX AI/ML-BOM 공식 문서

CycloneDX의 일반 SBOM은 소프트웨어 구성요소와 서비스, 그리고 구성요소 사이의 Dependency Relationship을 기계가 읽을 수 있는 형태로 표현하는 데 초점을 둡니다.

CycloneDX SBOM 공식 문서

즉 AI 공급망은 기존 Software Supply Chain을 버리는 개념이 아니라 그 위에 Model·Dataset 등 AI 고유 구성요소를 더 세밀하게 바라보는 방향으로 이해하는 편이 좋습니다.

SPDX AI Profile은 무엇을 기록할까?

AIBOM 관련 표준을 조사하다 보면 SPDX도 자주 만나게 됩니다.

SPDX 3.0.1의 AI Profile은 AI 소프트웨어 패키지와 관련된 정보를 표준화해 문서화하고 공유할 수 있도록 설계돼 있습니다.

중요한 점은 AIBOM을 특정 업체가 판매하는 하나의 제품명처럼 이해해서는 안 된다는 것입니다.

현재는 SPDX, CycloneDX, OWASP 등의 생태계에서 AI·ML 구성요소와 공급망 투명성을 다루는 표준과 도구가 발전하고 있다고 보는 것이 더 정확합니다.

공식 출처: SPDX 3.0.1 – AI Profile
SPDX AI Profile 공식 문서

필자의 기록 문장 ② — “AI를 신뢰한다는 것은 이름을 아는 데서 끝나지 않습니다. 무엇으로 만들어졌는지를 설명할 수 있을 때 신뢰는 관리 가능한 정보가 됩니다.”

AIBOM에는 무엇을 기록해야 할까? 실전 구축 가이드

AIBOM을 Excel 한 장으로 시작하는 것도 나쁜 방법은 아닙니다.

문제는 ‘AI 모델명’ 한 칸만 적어놓고 끝내는 것입니다.

실무에서는 최소한 다음과 같은 질문을 연결해서 생각해볼 수 있습니다.

Model — 어떤 모델인가?

Model Name
Model Version
Provider
Base Model
Fine-tuned 여부
Deployment Location

특히 버전이 중요합니다.

‘Model A 사용’과 ‘Model A v2.3 사용’은 운영 관점에서 전혀 다른 정보입니다.

Data — 어떤 데이터에 의존하는가?

Training Dataset
Fine-tuning Dataset
RAG Knowledge Source
Operational Data
Data Version
Data Provenance

Data Provenance는 쉽게 말하면 데이터의 ‘족보’입니다.

어디에서 왔고 어떤 과정을 거쳐 현재 시스템에 들어왔는지를 추적하는 것입니다.

API·Tool — AI가 바깥세상과 어디에서 연결되는가?

External API
MCP Tool
Search Tool
CRM
Payment API
Email API
Database Connector

AI Agent가 강력해질수록 이 항목은 중요해집니다.

모델은 답만 생성하지만 Tool과 API가 연결되면 실제 시스템을 조회하거나 작업을 수행할 수 있기 때문입니다.

Framework·Runtime — 어디에서 실행되는가?

Agent Framework
AI SDK
Cloud Service
Container
Runtime Version
Vector Database
Inference Infrastructure

같은 모델을 사용하더라도 실행환경이 다르면 시스템의 보안·성능·운영 조건도 달라질 수 있습니다.

Identity·Permission — 무엇을 할 수 있는가?

Service Account
API Key
Credential
Role
Read Permission
Write Permission
Delete Permission

AI 공급망을 ‘부품’만으로 보면 놓치기 쉬운 부분입니다.

Agent가 어떤 Tool에 연결되어 있는지를 알아도 어떤 권한으로 연결되어 있는지 모르면 실제 위험도를 평가하기 어렵습니다.

Dependency Graph를 만들면 AIBOM의 가치가 달라집니다.

AIBOM의 가장 흥미로운 지점은 여기부터입니다.

목록을 그래프로 바꿔보겠습니다.

예를 들어:

Customer Support Agent
↓
LLM A
↓
Embedding Model B
↓
Knowledge Base C
↓
Vector DB D
↓
CRM API E

라는 구조가 있다고 해보겠습니다.

여기에 영업지원 Agent도 같은 Embedding Model B를 사용합니다.

Sales Agent
↓
Embedding Model B

사내 검색 시스템도 같은 모델을 사용합니다.

Internal Search
↓
Embedding Model B

이제 Embedding Model B에서 문제가 발견됐다고 가정해보겠습니다.

일반적인 목록에서는 B를 검색한 뒤 사람이 관련 시스템을 하나씩 찾아야 할 수 있습니다.

Dependency Graph가 잘 구축돼 있다면 질문이 달라집니다.

Embedding Model B → 어디에 연결되어 있는가?

Customer Support Agent
Sales Agent
Internal Search

이렇게 영향 관계를 따라갈 수 있습니다.

이것이 Dependency → Impact → Blast Radius라는 사고방식입니다.

Blast Radius는 원래 폭발의 영향 범위를 뜻하는 표현입니다. IT에서는 하나의 장애나 보안 문제가 발생했을 때 어디까지 영향을 받을 수 있는지를 표현하는 비유로 자주 이해할 수 있습니다.

AIBOM의 가치가 단순 명세서에서 Risk Management로 넘어가는 순간입니다.

모델 버전 하나가 바뀌어도 기록해야 하는 이유

AI 시스템은 같은 서비스 이름을 계속 사용해도 내부는 조용히 달라질 수 있습니다.

예를 들어 가상의 시스템을 보겠습니다.

Agent v1

Model A v1
Dataset 2026-01
Embedding Model B v2
API v2

몇 달 뒤에는 이렇게 바뀔 수 있습니다.

Agent v2

Model A v2
Dataset 2026-08
Embedding Model C v1
API v3

사용자 화면에는 여전히 같은 ‘고객지원 AI’라고 표시될 수 있습니다.

그러나 내부 공급망은 달라졌습니다.

이 때문에 AIBOM은 정적인 문서 한 장보다 Version과 Change History를 추적하는 살아 있는 기록으로 발전할 필요가 있습니다.

“지난달에는 정상적으로 답했는데 왜 이번 달에는 결과가 달라졌지?”

이 질문에 답하려면 현재 구성뿐 아니라 그 시점의 구성도 알아야 하기 때문입니다.

필자의 기록 문장 ③ — “오늘의 AI를 기록하는 것만큼 중요한 것은 어제의 AI와 무엇이 달라졌는지를 남기는 일입니다.”

Model Provenance·Data Provenance가 중요한 이유

Provenance라는 단어가 조금 어렵게 느껴질 수 있습니다.

미술품을 떠올려보세요.

유명 작품을 거래할 때는 단순히 그림 제목만 보는 것이 아니라 언제 만들어졌고 누구를 거쳤으며 진위 확인 근거가 무엇인지 살펴봅니다.

AI에서도 비슷한 질문이 필요합니다.

이 모델은 어디에서 왔는가?
어떤 Base Model에서 파생됐는가?
어떤 Dataset과 관계가 있는가?
현재 버전은 무엇인가?
누가 제공하고 관리하는가?

CycloneDX는 모델의 조상 구성요소(ancestors)나 Dataset 연결 등을 표현할 수 있는 구조를 제공하며 Model Card 관련 정보도 다룹니다.

CycloneDX AI Models & Model Cards 공식 예시

Provenance가 중요한 이유는 ‘출처 표시를 예쁘게 하기 위해서’가 아닙니다.

문제가 발생했을 때 원인을 거슬러 올라가기 위한 Traceability, 즉 추적 가능성을 높이기 위해서입니다.

AIBOM이 AI Security와 연결되는 순간

여기서 의외의 반전이 하나 있습니다.

AIBOM 자체가 방화벽도 아니고 백신도 아닙니다.

공격을 직접 차단하는 보안 솔루션이라고 단정할 수도 없습니다.

그런데도 AI Security에서 중요해지는 이유는 간단합니다.

보호하려면 무엇이 연결되어 있는지 먼저 알아야 하기 때문입니다.

외부 모델에서 문제가 발견됐는데 어느 서비스가 그 모델을 사용하는지 모른다면 대응이 늦어질 수 있습니다.

특정 API Credential이 노출됐는데 어떤 Agent가 그 Credential에 의존하는지 모른다면 영향 범위를 빠르게 판단하기 어렵습니다.

Dataset에 문제가 발견됐는데 어떤 모델과 서비스가 해당 데이터를 사용했는지 모른다면 조사 범위가 커집니다.

AIBOM은 이때 답을 찾기 위한 AI Supply Chain Map 역할을 할 수 있습니다.

NIST AI RMF에서 읽을 수 있는 중요한 힌트

AIBOM 자체와 NIST AI RMF를 동일한 개념으로 보면 안 됩니다.

다만 NIST의 Generative AI Profile은 외부 GAI 기술과 서비스 제공자, 데이터 등 제3자 요소가 지식재산권·개인정보·정보보안 위험과 연결될 수 있다고 설명하고, 제3자 투명성과 위험관리를 위해 기존 통제와 조달 실사, SBOM 요청 등의 방법을 고려할 수 있다고 제시합니다.

즉 생성형 AI의 위험관리는 기업 내부 모델만 보는 것으로 끝나지 않는다는 의미입니다.

공식 출처: NIST – Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
NIST AI RMF Generative AI Profile

NIST AI RMF 자체도 조직이 AI 제품·서비스·시스템의 설계, 개발, 사용, 평가 과정에서 신뢰성 관련 위험을 관리하도록 돕는 자발적 프레임워크입니다.

NIST AI Risk Management Framework 공식 페이지

따라서 실무에서는 AIBOM을 독립된 체크리스트 하나로 운영하기보다 AI Inventory, AI Governance, Risk Assessment, Incident Response 등과 연결하는 편이 더 현실적입니다.

AI Inventory → AIBOM → Risk Management로 연결해보세요.

기업 AI Governance를 한 장의 흐름으로 정리하면 다음처럼 볼 수 있습니다.

Discovery
“어떤 AI가 존재하는가?”

↓

AI Inventory
“누가 무엇을 사용하고 있는가?”

↓

AIBOM
“각 AI가 무엇으로 구성되고 무엇에 의존하는가?”

↓

Dependency Graph
“구성요소들이 어떻게 연결되어 있는가?”

↓

Change Detection
“무엇이 바뀌었는가?”

↓

Impact Analysis
“문제가 생기면 어디까지 영향을 받는가?”

↓

Risk Management
“어떤 위험부터 대응해야 하는가?”

이 구조로 보면 AIBOM의 역할이 명확해집니다.

AIBOM은 모든 AI Governance 문제를 해결하는 만능 문서가 아니라 AI 시스템 내부의 구성·출처·의존성을 보이게 만드는 하나의 중요한 기반입니다.

실무에서 시작할 수 있는 AIBOM 체크리스트

처음부터 거대한 시스템을 구축하려고 하면 오히려 시작하기 어렵습니다.

작은 AI 서비스 하나를 선택해서 다음 질문부터 적어보세요.

서비스 또는 Agent 이름은 무엇인가?
담당 Owner는 누구인가?
어떤 Model과 Version을 사용하는가?
Base Model 또는 Provider는 누구인가?
어떤 Dataset·RAG Knowledge Source에 의존하는가?
어떤 Embedding Model을 사용하는가?
어떤 API·Tool·MCP와 연결되는가?
어떤 Framework·Runtime에서 실행되는가?
어떤 Credential과 Permission을 사용하는가?
각 구성요소의 출처(Provenance)를 확인할 수 있는가?
구성요소 간 Dependency를 연결할 수 있는가?
마지막 변경일은 언제인가?
구성요소 하나가 바뀌었을 때 영향을 받는 시스템을 찾을 수 있는가?

이 질문에 답하기 시작하면 단순한 ‘AI 목록’이 조금씩 AI Supply Chain Map으로 바뀝니다.

AIBOM은 한 번 만들고 끝내면 될까?

그렇지 않습니다.

AI 시스템은 계속 변합니다.

모델 버전이 바뀌고, API가 교체되고, 새로운 Tool이 추가되고, RAG 문서가 갱신되고, Agent의 권한이 변경될 수 있습니다.

따라서 실무적으로 더 중요한 질문은:

“AIBOM을 만들었는가?”

보다

“현재 운영 중인 AI의 실제 상태와 AIBOM이 계속 일치하는가?”

입니다.

정적인 Excel 파일과 실제 Production 환경 사이에 차이가 벌어지면 기록의 신뢰도도 떨어집니다.

향후 AIBOM 운영의 핵심은 Continuous Discovery·Version Tracking·Change Detection·Dependency Mapping과 연결될 가능성이 큽니다.

AIBOM이 기업 비용 관리와도 연결되는 이유

AIBOM은 보안 이야기만은 아닙니다.

AI 시스템의 구성요소가 보이면 비용 구조도 더 잘 보일 수 있습니다.

예를 들어 하나의 Agent가:

고성능 LLM
Embedding API
Vector Database
검색 API
OCR 서비스
Cloud Runtime
외부 SaaS

에 의존한다면 서비스 비용 역시 여러 공급자에게 나뉘어 발생할 수 있습니다.

어떤 구성요소가 비용을 만드는지 파악하면 Model Routing, Vendor Consolidation, API 최적화, Cloud Cost Management 같은 운영 의사결정에도 참고할 수 있습니다.

다만 AIBOM을 작성한다고 비용이 자동으로 절감되는 것은 아닙니다.

AIBOM이 제공하는 것은 **의사결정에 필요한 가시성(Visibility)**입니다.

기업의 디지털 자산을 관리할 때도 결국 같은 원리가 적용됩니다.

보이지 않는 비용은 관리하기 어렵고, 보이지 않는 의존성은 위험을 계산하기 어렵습니다.

AIBOM을 만들 때 피해야 할 세 가지 오해

“모델 이름만 적으면 된다”

AI 시스템은 Model 하나가 아닐 수 있습니다.

Dataset, RAG, API, Tool, Framework 등과의 관계까지 봐야 공급망이라는 표현에 가까워집니다.

“AIBOM을 만들면 AI가 안전해진다”

AIBOM은 위험을 직접 제거하는 기술이라고 단정하기 어렵습니다.

대신 무엇이 연결되어 있고 어디가 영향을 받을 수 있는지 파악하는 기반 정보를 제공하는 방향으로 이해하는 것이 적절합니다.

“한 번 만들면 끝난다”

AI 구성은 변합니다.

따라서 Version과 Change History가 빠지면 시간이 지날수록 실제 환경과 기록 사이에 차이가 커질 수 있습니다.

자주 묻는 질문 FAQ

AIBOM이란 무엇인가요?

AIBOM은 AI Bill of Materials의 약자로, AI 시스템을 구성하는 모델·데이터·소프트웨어·도구 등의 정보와 출처·의존관계를 추적하기 위한 개념입니다. 구현 범위와 표현 방식은 사용하는 표준이나 도구에 따라 달라질 수 있습니다.

AIBOM과 AI Inventory의 차이는 무엇인가요?

AI Inventory가 조직이 사용하는 AI 자산을 발견하고 관리하는 데 초점을 둔다면, AIBOM은 특정 AI 시스템 내부의 구성요소와 의존관계를 더 깊게 들여다보는 관점으로 구분할 수 있습니다.

AIBOM과 SBOM은 같은 것인가요?

동일하다고 단정하기는 어렵습니다. SBOM은 소프트웨어 구성요소와 의존성에 초점을 두며, AI/ML-BOM 계열은 모델·Dataset 등 AI/ML 고유 정보를 추가로 표현할 수 있습니다.

Model Card와 AIBOM은 무엇이 다른가요?

Model Card는 일반적으로 특정 모델의 용도, 성능, 제한사항 등 모델 자체에 관한 설명에 초점을 둡니다. AIBOM은 모델을 포함해 시스템을 구성하는 여러 요소와 공급망·의존관계를 바라보는 데 초점을 둘 수 있습니다.

AI Agent도 AIBOM으로 관리할 수 있나요?

Agent를 하나의 단순 부품으로만 보기보다 Model + Prompt + Memory + RAG + Tool + API + Identity + Policy가 결합된 시스템 관점에서 바라보는 것이 유용합니다.

MCP Tool도 포함해야 하나요?

해당 Tool이 실제 AI 시스템의 기능이나 외부 서비스 접근에 영향을 주는 구성요소라면 Dependency Mapping 대상에 포함하는 것을 검토할 수 있습니다.

AIBOM을 만들면 보안 사고를 막을 수 있나요?

그 자체만으로 사고 방지를 보장하지는 않습니다. 다만 구성요소와 의존관계에 대한 가시성이 높아지면 취약 구성요소 조사, 영향 범위 파악, Incident Response 같은 보안 업무를 지원할 수 있습니다.

★ 필자의 주관적인 마무리 의견

저는 앞으로 기업 AI 경쟁력의 차이가 단순히 “더 좋은 모델을 쓰느냐”에서만 나오지는 않을 것이라고 봅니다. 어떤 모델을 사용하고 있는지, 그 모델이 어떤 데이터와 도구에 연결돼 있는지, 외부 API 하나가 바뀌었을 때 어느 서비스가 영향을 받는지까지 설명할 수 있는 운영 역량이 점점 중요해질 가능성이 큽니다.

특히 AI Agent가 메일·문서·데이터베이스·결제·SaaS와 연결될수록 AI 한 개는 더 이상 고립된 프로그램 한 개가 아닙니다. 수많은 디지털 자산이 연결된 작은 생태계에 가까워집니다.

그래서 저는 AIBOM의 본질을 ‘명세서를 하나 더 만드는 일’이라고 생각하지 않습니다. 보이지 않던 AI 공급망을 보이게 만드는 일이라고 생각합니다.

AI Inventory가 조직의 AI 지도를 그리는 작업이라면 AIBOM은 지도 위의 각 건물을 열어 내부 배선과 연결관계를 확인하는 작업에 가깝습니다. 그리고 Dependency Graph가 완성될수록 기업은 장애·보안·비용·규제 변화가 생겼을 때 어디부터 확인해야 할지 더 빠르게 판단할 수 있습니다.

앞으로 AI Governance에 투자하려는 조직이라면 새로운 AI를 도입하는 비용뿐 아니라 그 AI의 Provenance·Dependency·Version·Owner·Change History를 계속 관리할 운영 비용까지 함께 생각해볼 필요가 있습니다. 이것이 장기적으로 기업의 디지털 자산과 기술 투자의 가치를 지키고, AI Risk Management를 더 현실적으로 운영하는 기반이 될 수 있다고 봅니다.

공식 자료 및 추가 참고

OWASP GenAI Security Project — AI Bill of Materials
OWASP AIBOM Initiative

OWASP — AIBOM Generator
OWASP AIBOM Generator 공식 자료

CycloneDX — Machine Learning Bill of Materials
CycloneDX AI/ML-BOM

CycloneDX — AI Models and Model Cards
CycloneDX AI Model Inventory 공식 예시

SPDX 3.0.1 — AI Profile
SPDX AI Profile 공식 문서

NIST — AI Risk Management Framework: Generative AI Profile
NIST Generative AI Profile