Executive Summary

소프트웨어 자재명세서는 식품 포장의 성분표와 닮았다. 어떤 라이브러리가, 어떤 버전으로, 어떤 라이선스로 들어갔는지를 적어 두면, 나중에 그중 하나에서 취약점이 터졌을 때 영향받는 제품을 빠르게 찾아낼 수 있다. 2021년 Log4Shell 사태 이후 SBOM은 공급망 보안의 기본기로 자리 잡았고, 가트너는 대기업의 SBOM 채택이 2025년 56%에서 2028년 85%로 늘어날 것으로 본다.

SBOM이 성립하는 전제는 하나다. 부품은 빌드 시점에 고정된다는 것. 일단 출하하고 나면 그 안에 든 라이브러리 목록은 바뀌지 않는다. 그래서 정적인 목록 하나로 충분하다. AI 시스템은 바로 이 전제를 깬다.

모델은 파인튜닝과 재학습으로 계속 진화한다. 런타임에는 외부 API를 호출하고 검색으로 새 데이터를 끌어온다. 같은 코드라도 시스템 프롬프트나 가드레일을 바꾸면 행동이 달라진다. 빌드가 끝난 뒤에도 시스템이 살아 움직이는 것이다. 정적 부품 목록으로는 이렇게 흐르는 시스템을 따라잡을 수 없다.

그래서 AI 자재명세서는 부품만 적는 데서 멈추지 않는다. 부품 사이의 관계까지 추적한다. 어떤 애플리케이션이 어떤 모델을 쓰고(USES_LLM), 어떤 도구를 호출하며(USES_TOOL), 어떤 검색기와 기억 저장소에 연결되는지(USES_RETRIEVER, USES_MEMORY)를 그래프로 그린다. 목록(list)이 아니라 의존성 그래프(dependency graph)인 셈이다.

두 명세서가 무엇을 다르게 다루는지 항목별로 정리하면 차이가 분명해진다.

그렇다면 AI 자재명세서에는 구체적으로 무엇이 들어가는가. Cisco가 공개한 오픈소스 AI BOM 스캐너는 30가지 컴포넌트 유형을 인식하는데, 이를 추리면 여덟 가지 부품으로 정리할 수 있다. 코드 의존성 하나만 적던 SBOM과 비교하면, 적어야 할 항목이 통째로 늘어난 셈이다.

이 여덟 가지를 따로따로 적어 두는 것만으로는 부족하다. AI BOM의 핵심은 이들이 어떻게 이어지는지를 함께 기록한다는 데 있다. 어떤 에이전트가 어떤 모델을 호출하고, 그 모델이 어떤 데이터셋으로 학습됐고, 어떤 MCP 서버에서 도구를 끌어오는지를 그래프로 연결해야, 한 부품에서 문제가 터졌을 때 그 파장이 어디까지 미치는지 추적할 수 있다.

포맷은 이미 준비됐다

다행히 무엇을 어떻게 적을지에 대한 표준은 이미 갖춰져 있다. OWASP의 CycloneDX는 2023년 6월 v1.5부터 머신러닝 부품을 담는 ML-BOM을 지원했고, 현재는 ECMA-424 2판으로 표준화된 v1.7까지 왔다. 리눅스 재단의 SPDX 3.0은 AI Profile을, OWASP는 별도의 AIBOM Project를 내놓았다. 데이터 품질은 ISO/IEC 5259가, AI 경영 시스템 거버넌스는 ISO/IEC 42001이 떠받친다.

이 발상의 학술적 뿌리는 더 오래됐다. 2018년 Timnit Gebru 등이 제안한 'Datasheets for Datasets'는 데이터셋마다 출처·구성·용도를 적은 명세표를 붙이자는 제안이었고, 같은 해 Margaret Mitchell 등의 'Model Cards'는 모델에 같은 일을 하자고 했다. 부품마다 문서를 붙이자는 생각은 AI BOM이라는 이름이 붙기 한참 전부터 있었던 셈이다.

규모를 생각하면 이 일을 손으로 할 수는 없다. Hugging Face에 공개된 모델만 200만 개, 데이터셋은 150만 개를 넘는다. 그래서 인벤토리는 소스코드를 분석해 의존성을 자동으로 긁어모으는 스캐너의 몫이 된다. 즉 포맷이 없어서 AI BOM을 못 만드는 게 아니다. 남은 과제는 그 칸을 무엇으로, 얼마나 믿을 수 있게 채우느냐다.

AI BOM이 필요한 이유는 추상적이지 않다. 지금 대부분의 조직은 자사에서 어떤 AI가 돌고 있는지조차 다 알지 못한다. Productiv의 2026년 집계를 보면 기업 한 곳이 평균 14개의 AI 도구를 쓰지만 IT가 파악하는 건 4~5개에 그친다. 나머지는 보이지 않는 곳에서 돌아간다.

아래 그래프는 그 가시성 공백을 그대로 보여준다. 막대 하나는 직원들이 실제로 쓰는 AI 도구 수이고, 다른 하나는 IT가 알고 있는 수다.

기업당 평균 AI 도구 수 대비 IT가 파악한 수. 출처: Productiv, 2026.

다른 조사도 같은 그림을 가리킨다. Wiz의 클라우드 보안 보고서에서는 응답 기업의 25%가 지금 실행 중인 AI 서비스를 파악하지 못한다고 답했고, IBM의 침해 비용 보고서에서는 63%의 조직이 AI 거버넌스 정책 자체가 없었다. 가트너 조사에서는 직원의 68%가 회사가 승인하지 않은 AI 도구를 쓰고 있었다. 이 가시성 공백이 곧 섀도 AI다.

목록에 없으면 통제도 감사도 할 수 없으니, 섀도 AI는 그대로 공격 표면이 된다. IBM에 따르면 섀도 AI가 연루된 침해는 표준 침해보다 평균 67만 달러 더 비쌌고, 탐지와 봉쇄에 267일이 걸렸다(표준은 241일). 침해를 겪은 조직의 97%는 AI에 대한 접근 통제가 없었다.

새 공격은 코드가 아니라 데이터·프롬프트에서 자란다

더 곤란한 점은, 이 새로운 위험이 전통적인 코드 의존성 스캐너에 잡히지 않는다는 것이다. 프롬프트 인젝션은 OWASP의 LLM 애플리케이션 위험 1위이고, 보안 감사에서 프로덕션 AI의 73%가 여기에 취약한 것으로 드러났다. 공격은 코드 레이어가 아니라 데이터와 프롬프트 레이어에서 자란다. ENISA는 2025년 위협 보고서에서 신종 공급망 공격 세 가지를 새로 분류했다.

여기에 모델 파일의 악성코드 탐지를 우회하는 제로데이(예: CVE-2025-10155)까지 더해진다. 공통점은 분명하다. 이 모든 것이 코드 의존성 목록에는 흔적을 남기지 않는다는 점이다. 모델과 데이터, 프롬프트의 출처를 따로 인벤토리하지 않으면, 가장 빠르게 자라는 공격 표면이 통째로 보이지 않는 채로 남는다.

AI 인벤토리는 권고에서 요건으로 넘어가는 중이다. 다만 그 방향은 한 갈래가 아니다. 규제는 'EU형 실질 의무 강화'와 '미국형 재량·공시 중심'이라는 두 갈래로 갈린다. 한쪽으로 단정하기 전에 양쪽을 같이 봐야 한다.

EU 쪽은 의무를 조이는 방향이다. EU AI Act는 고위험 시스템에 기술 문서화와 데이터 거버넌스 증적을 요구하고, 범용 AI(GPAI)에는 훈련 데이터 요약 공개를 의무화한다. 위반 시 제재는 최대 매출 7% 또는 €35M으로, GDPR의 최고 제재(4%/€20M)를 웃돈다. 고위험 시스템 전면 시행은 2026년 8월 2일로 예정돼 있다(일정 연기 가능성은 남아 있다). 캘리포니아 AB 2013은 2026년 1월 1일부터 생성 AI의 훈련 데이터 공시를 요구한다. 학계에서는 수학자들이 주도한 라이덴 선언이 AI 훈련 데이터의 동의·귀속·투명성을 요구했고, 서명자는 2026년 6월 30일 기준 2,821명까지 늘었다.

미국 연방·주 차원에서는 반대 방향의 움직임도 있다. 콜로라도는 2024년 제정했던 AI법(SB 24-205)을 2026년 5월 14일 SB 26-189로 폐지하며 거버넌스 의무에서 공시·절차 중심으로 선회했다. 백악관 예산관리국(OMB)의 메모 M-26-05(2026년 1월 23일)는 소프트웨어·하드웨어 공급망 보안에서 SBOM 요구를 필수에서 기관 재량으로 되돌렸다. AI BOM을 강제한 메모가 아니라, 오히려 명세서 요구를 느슨하게 한 사례라는 점에 주의해야 한다.

방향이 갈려도 흔들리지 않는 전제가 하나 있다. 인벤토리하지 않은 위험은 매핑할 수 없다는 것이다. 의무를 조이든 공시로 돌리든, 자기 시스템에 무엇이 들어 있는지 모르면 어느 쪽 요건도 충족할 수 없다.

업계는 '발견'에 강하지만 '신뢰'는 공백이다

보안 벤더들은 이미 AI BOM 시장에 뛰어들었다. 그런데 이들이 잘하는 일과 비워 둔 일이 뚜렷하게 갈린다. 아래 표는 세 벤더의 강점과, 공통으로 비어 있는 자리를 정리한 것이다.

세 벤더 모두 무엇이 거기 있는지는 잘 찾는다. 그러나 그 데이터를 신뢰할 수 있는지는 판정하지 못한다. 스캐너 경보의 96%가 오탐이라는 사실이 그 한계를 잘 보여준다. 발견은 자동화됐지만, 신뢰는 아직 채워지지 않은 칸으로 남아 있다.

여기서 이 글의 출발점으로 돌아온다. '데이터셋이 목록에 있다'는 것과 '그 데이터셋을 신뢰할 수 있다'는 것은 전혀 다른 문제다. 부품 목록에 데이터셋 이름을 적어 넣는 것만으로는, 그 데이터가 오염됐는지, 중복이 쌓였는지, 라벨이 틀렸는지, 라이선스를 위반했는지 알 수 없다. 인벤토리된 데이터가 이런 결함을 품고 있으면, AI BOM은 형식만 채운 거짓 안심이 된다.

이 공백이 실무에서 얼마나 큰지는 수치가 말해 준다. 스탠퍼드 HAI의 2026년 보고서에서 응답자의 74%가 AI의 최고 위험으로 '부정확성'을 꼽았다(전년 대비 14%p 상승). AI 에이전트 배포의 최대 장애물로 '데이터 품질'을 지목한 비율도 52%에 달했다. 신뢰의 병목은 모델이 아니라 데이터에 있다.

그래서 감사 가능한 인벤토리는 두 갈래의 계보가 만나는 자리에서 완성된다. 하나는 모델 계보다. 어떤 모델이 어떤 데이터로 학습됐고 어떻게 진화했는지의 기록이다. 다른 하나는 데이터 계보다. 그 데이터가 어디서 왔고, 어떤 변환을 거쳤고, 지금 품질이 어떤지의 기록이다. 부품 목록에 이 두 계보가 붙을 때, AI BOM은 체크리스트를 넘어 감사 가능한 신뢰의 토대가 된다.

그렇다면 '계보가 붙은 인벤토리'는 실무에서 어떤 모습인가. 데이터 부품마다 이상치·중복·라벨 오류·라이선스 위반을 점검한 결과가 품질 인증서로 따라붙고, 그 데이터가 어디서 와서 어떤 변환을 거쳤는지가 출처 기록으로 남는다. 그러면 목록의 한 줄은 '데이터셋 이름과 버전'에서 '언제, 무엇으로, 어떻게 검증됐는지를 되짚을 수 있는 증적'으로 바뀐다. 앞서 본 표준이 이 빈칸의 틀을 이미 마련해 두었다. 데이터 품질의 척도는 ISO/IEC 5259가, 그 검증 과정을 남기는 거버넌스 틀은 ISO/IEC 42001이 떠받친다. 감사관이 던지는 단 하나의 질문 — 이 데이터를 믿어도 되는가 — 에 목록 자체가 답하게 되는 것이다.

이 두 번째 그림이 페블러스가 데이터 품질과 계보에 대해 말해 온 것과 같은 자리에 있다. AI BOM의 '데이터 부품 인벤토리'는 사실상 데이터 품질 보고서이며, 'AI Act 문서화 요건'은 데이터의 출처와 변환 이력을 자동으로 남기는 프로비넌스 증적으로 충족된다. 인벤토리가 신뢰를 담보하려면, 목록에 적힌 데이터가 어디서 와서 어떻게 검증됐는지가 함께 기록돼야 한다. 그 지점에서 명세서는 거짓 안심을 넘어선다.

현장에서 이 차이는 속도로도 나타난다. 인벤토리 가능한 데이터 파이프라인을 갖추면 데이터 준비 자체가 빨라진다. 페블러스 내부 사례에서는 제조 현장의 데이터 수집·정제 기간이 3~5년에서 2주로 줄었다(내부 자료). 추적 가능한 데이터는 안전·인증의 근거인 동시에, 사업 속도이기도 하다.

1차 소스 (정책·업계)

• 1.FedTech Magazine. (2026, June). "How Federal Agencies Can Inventory and Govern AI Systems with AI BOMs." FedTech Magazine.
• 2.TechInformed. (2026). "Shadow AI now needs a bill of materials." TechInformed.
• 3.Cisco. (2026). "Know Your AI Stack: Introducing AI BOM in Cisco AI Defense." Cisco Blogs.

표준·도구

• 4.OWASP. (2025). "CycloneDX — ML-BOM / AI BOM (ECMA-424 2nd Edition, v1.7)." OWASP Foundation.
• 5.Cisco AI Defense. (2026). "AI BOM open-source scanner." GitHub.

학술 (부품 단위 문서화 기원)

• 6.Gebru, T., et al. (2018/2021). "Datasheets for Datasets." Communications of the ACM / arXiv:1803.09010.
• 7.Mitchell, M., et al. (2019). "Model Cards for Model Reporting." FAT* 2019 / arXiv:1810.03993.

데이터·통계

• 8.IBM Security / Ponemon Institute. (2025). "Cost of a Data Breach Report 2025." IBM.
• 9.Wiz Research. (2026). "State of AI in the Cloud 2026." Wiz.
• 10.ENISA. (2025). "Threat Landscape 2025." European Union Agency for Cybersecurity.
• 11.Stanford HAI. (2026). "AI Index Report 2026." Stanford University.
• 12.European Commission. (2024). "EU AI Act, Article 99 (Penalties)." EUR-Lex.
• 13.Leiden Declaration on Artificial Intelligence and Mathematics. (2026). "Signatories." (서명자 2,821명, 2026-06-30 확인)

※ 일부 시장 규모 수치는 조사기관별 정의 차이로 단일 값으로 단정하지 않았다. 현대자동차 데이터 준비 기간 단축 사례는 페블러스 내부 자료에 근거한다.