2026년에 모든 CISO에게 AIBOM이 필요한 이유 — 그리고 벤더들이 놓치고 있는 것

제 친구 중 한 명은 중견 핀테크 기업의 보안을 담당하고 있습니다. 약 6주 전, 그녀는 약간 화가 난 목소리로 저에게 전화를 걸었습니다. 이사회가 그녀가 대답할 수 없는 질문을 던졌기 때문입니다: "현재 운영 환경(production)에서 실행 중인 AI 모델은 몇 개이며, 그 모델들이 어떤 데이터에 접근하고 있습니까?"

그녀는 합리적인 CISO라면 누구나 할 법한 행동을 했습니다. SCA(Software Composition Analysis) 도구에서 SBOM(Software Bill of Materials) 내보내기 파일을 추출했습니다. 이를 클라우드 자산 인벤토리(cloud asset inventory)와 교차 참조했습니다. 플랫폼 팀에 물어봤고, ML(Machine Learning) 팀에도 물어봤습니다. 결과는 세 가지 서로 다른 답변이었습니다. SCA 도구는 transformers 패키지를 네 번 계산했기 때문에 모델이 4개라고 말했습니다. 클라우드 인벤토리는 11개의 SageMaker 엔드포인트를 찾아냈는데, 그중 2개는 1년 전에 폐기되었음에도 여전히 IAM 역할(IAM roles)이 연결되어 있었습니다. 실제로 모델을 구축하는 ML 팀은 실제 숫자가 30개 정도라고 말했습니다. 여기에는 보안 팀 누구도 들어본 적 없는 몇몇 미세 조정(fine-tuned)된 Llama 변형 모델들이 포함되어 있었으며, 이들은 내부 로드 밸런서(load balancer) 뒤에 있는 자체 호스팅 vLLM 클러스터에서 실행되고 있었습니다.

그녀를 정말 당혹스럽게 만든 부분은 미세 조정(fine-tunes) 모델들이었습니다. 그녀는 이 모델들이 어떤 베이스 모델(base model)에서 파생되었는지, 튜닝에 어떤 데이터가 사용되었는지, 누가 학습 실행(training run)을 승인했는지, 또는 추론(inference) 시 어떤 가드레일(guardrails)이 마련되어 있는지에 대한 기록이 전혀 없었습니다. 그녀의 DLP(Data Loss Prevention) 팀은 고객의 PII(Personally Identifiable Information, 개인정보)가 학습 코퍼스(training corpus)에 포함되어 있었다는 사실을 전혀 몰랐습니다. 그녀의 컴플라이언스(compliance) 팀은 지난 두 분기 동안 감사인들에게 회사가 "승인된 제공업체의 승인된 파운데이션 모델(foundation models)만을 사용한다"라고 말해왔습니다.

그 말은 기술적으로는 모두 사실이었습니다. 하지만 기능적으로는 거짓이었습니다.

그 대화는 저에게 AIBOM 문제가 이번 십 년의 결정적인 인벤토리(inventory) 문제라는 확신을 주었습니다. 그리고 이는 보안 리더들이 모든 것을 파악하고 있다고 생각할 때마다 제가 반복해서 나누게 되는 대화이기도 합니다.

논지 (The thesis)

AI Bill of Materials (AIBOM)는 단순히 몇 개의 필드가 추가된 SBOM이 아닙니다. 이는 근본적으로 다른 산출물(artifact)이며, 서로 다른 생명주기 의미론(lifecycle semantics), 서로 다른 소비자, 그리고 서로 다른 실패 모드(failure modes)를 가집니다. 오늘날 CycloneDX 파일에 model.gguf 행을 추가하는 방식으로 "AIBOM"을 판매하는 벤더들은 여러분의 문제를 해결하고 있는 것이 아닙니다. 그들은 잘 알지 못하는 감사인(auditor)을 위한 체크박스 하나를 제공할 뿐이며, 규제 기관, 고객 또는 이사회가 실제 질문을 던지는 첫 순간에 여러분을 반드시 곤경에 빠뜨릴 잘못된 완결성(false sense of completeness)을 제공하고 있습니다.

2026년에 AIBOM이 실제로 무엇을 포착해야 하는지, 현재의 툴링(tooling)이 어디에서 부족한지, 그리고 제가 생각하는 아키텍처적 해답은 어떤 모습인지 설명해 보겠습니다.

SBOM이 해결하도록 설계된 문제, 그리고 AI에서 그것이 작동하지 않는 이유

SBOM은 단 하나의 질문에 답하기 위해 설계되었습니다: "내일 CVE가 발표된다면, 배포된 산출물 중 어떤 것에 취약한 패키지가 포함되어 있는지 알려줄 수 있는가?" 그것이 전부입니다. 패키지 URL(package URLs), 버전 고정(version pins), 의존성 트리(dependency trees)와 같은 전체 형식은 해당 조회를 위해 최적화되어 있습니다. Log4Shell 사건이 발생했을 때 업계는 집단적으로 이 산출물이 필요하다는 데 동의했고, 이를 위한 툴링을 구축했습니다.

AI 시스템은 적어도 네 가지 지점에서 SBOM 모델을 무너뜨립니다.

첫째, 산출물(artifact)이 패키지가 아닙니다. 모델은 가중치(weights)에 아키텍처(architecture), 토크나이저(tokenizer), 프롬프트 템플릿(prompt template), 추론 런타임(inference runtime), 그리고 때로는 파인튜닝 델타(fine-tuning delta)가 결합된 것입니다. 이 중 어느 것도 lodash@4.17.21과 같은 방식으로 버전이 관리되지 않습니다. 동일한 Llama 3.1 8B 모델이 여러분의 환경에서 GGUF 양자화(quant), AWQ 양자화, HuggingFace safetensors 체크포인트, vLLM 기반 엔드포인트, 그리고 다른 베이스 모델 위의 LoRA 어댑터로 나타날 수 있습니다. 이때 여러분의 SBOM은 이 중 네 가지를 놓치거나, 이들 사이의 관계를 전혀 파악하지 못한 채 다섯 가지 서로 다른 별개의 것으로 취급하게 될 것입니다.

둘째, 공급망 (supply chain)은 의존성 트리 (dependency tree)가 아닙니다. 그것은 학습 실행 (training runs), 데이터 소스 (data sources), 베이스 모델 (base models), 어댑터 (adapters), 그리고 평가 아티팩트 (evaluation artifacts)로 이루어진 방향성 그래프 (directed graph)입니다. 미세 조정 (fine-tuned)된 고객 서비스 모델과 원본 Mistral 체크포인트 (checkpoint) 사이의 "의존" 관계는, 귀하의 Python 앱과 그 requirements.txt 사이의 관계와 같은 종류가 아닙니다. 이를 동일하다고 가정하는 것은 중요한 모든 정보를 상실하게 만듭니다.

셋째, 리스크는 CVE 형태가 아닙니다. 귀하가 실제로 답해야 하는 질문은 다음과 같습니다: 이 모델이 우리가 권한을 가진 데이터로 학습되었는가? 알려진 프롬프트 인젝션 (prompt-injection) 취약성을 가지고 있는가? 제재 목록에 있거나 수출 통제 대상인가? 제공업체가 약관을 변경했는가? 체크포인트에 백도어 (backdoor)가 심어졌는가? 인버전 공격 (inversion attacks) 하에서 학습 데이터를 유출하는가? 이 중 그 어떤 것도 CPE 조회 (CPE lookup)에 깔끔하게 매핑되지 않습니다.

넷째, 아티팩트 (artifact)는 살아있습니다. API 뒤에 있는 모델은 아무런 통지 없이 귀하도 모르는 사이에 변경될 수 있습니다. gpt-4o-2024-08-06에 대한 귀하의 "AIBOM 항목"은 스냅샷 (snapshot)이지 계약 (contract)이 아닙니다. 제공업체는 귀하에게 알리지 않고 모델을 중단 (deprecate)하거나, 재학습 (retrain)하거나, A/B 테스트를 수행하거나, 안전 필터 (safety filters)를 변경할 수 있습니다. SBOM은 디스크 상의 패키지가 귀하가 스캔한 패키지라고 가정합니다. 그 가정은 더 이상 유효하지 않습니다.

만약 귀하의 벤더가 제공하는 AIBOM이 이 네 가지를 모두 고려하지 않는다면, 귀하가 가진 것은 그저 이름만 거창한 스프레드시트일 뿐입니다.

진정한 AIBOM이 반드시 포착해야 할 다섯 가지 요소

이제 구체적으로 말씀드리겠습니다. 왜냐하면 저는 이 부분을 대충 얼버무리는 "AI 거버넌스 (AI governance)" 데모를 너무 많이 봐왔기 때문입니다.

제가 보기에 진정한 AIBOM은 **모델 정체성 (model identity)**을 복합체로서 포착해야 합니다. 즉, 베이스 모델 (base model), 양자화 (quantization), 어댑터 스택 (adapter stack), 토크나이저 (tokenizer), 런타임 (runtime), 그리고 해당되는 경우 디스크 상의 실제 가중치 (weights)에 대한 암호화 해시 (cryptographic hash)를 포함해야 합니다. 단순히 llama-3.1-8b라고만 해서는 안 됩니다. 실제 지문 (fingerprint)이 필요합니다. Cybrium의 자체 스캔 결과에 따르면, 동일하게 라벨링된 두 개의 체크포인트라도 누군가 LoRA를 적용하고 다시 저장했다면 해시를 생성했을 때 기가바이트 단위로 차이가 날 수 있음을 발견했습니다.

그것은 반드시 **배포 컨텍스트 (deployment context)**를 포착해야 합니다: 모델이 어디에서 실행되는지, 무엇이 모델을 서빙하는지, 어떤 데이터가 모델에 도달할 수 있는지, 그리고 어떤 송신 (egress) 경로가 존재하는지를 포함해야 합니다. 바로 이 지점에서 cyradar가 다루는 7가지 추론 런타임(inference runtimes)인 Ollama, vLLM, TGI, LocalAI, Triton, LM Studio, 그리고 llama.cpp가 각각 고유한 공격 표면 (attack surface)을 생성합니다. Kubernetes 서비스 상에서 OpenAI 호환 API가 노출된 채 vLLM 뒤에서 실행되는 모델은, 개발자의 노트북에서 Ollama로 실행되는 동일한 모델과는 매우 다른 리스크를 가집니다. 가중치 (weights)는 같지만, 위협 모델 (threat model)은 다릅니다.

그것은 반드시 **데이터 계보 (data lineage)**를 포착해야 합니다: 학습 데이터 (training data), 미세 조정 (fine-tuning) 데이터, RAG 코퍼스 (corpora), 시스템 프롬프트 (system prompts), 그리고 각각의 출처 (provenance)를 포함해야 합니다. 이 분야는 벤더들이 가장 자주 생략하는 영역인데, 그 이유는 작업이 어렵고 고객들이 아직 이를 요구하는 법을 배우지 못했기 때문입니다. 누군가가 소송을 당하는 첫 번째 순간이 오면, 고객들은 요구하게 될 것입니다.

그것은 반드시 **정책 태세 (policy posture)**를 포착해야 합니다: 어떤 가드레일 (guardrails)이 구성되었는지, 어떤 평가 (evals)가 수행되었는지, 어떤 레드팀 (red-team) 결과가 존재하는지, 그리고 애플리케이션 계층에 어떤 보완 통제 (compensating controls)가 마련되어 있는지를 포함해야 합니다. 이러한 요소가 없는 AIBOM은 취약점 스캔 (vulnerability scan)이 첨부되지 않은 SBOM과 같습니다.

그리고 그것은 반드시 **시간 (time)**을 포착해야 합니다: 이 모든 것들이 언제, 어떤 도구에 의해, 그리고 어떤 상태의 세상(state of the world)을 기준으로 측정되었는지를 말입니다. 모델은 드리프트 (drift)하고, 제공업체는 약관을 변경하며, 지난 분기에 생성한 AIBOM은 이미 구식이 되어버리기 때문입니다.

이것이 줄일 수 없는 최소한의 요건입니다. 이보다 못한 것은 보여주기식 행위 (theater)에 불과합니다.

현재 도구들의 한계

솔직하게 말씀드리겠습니다. 제가 지난 1년 동안 평가한 대부분의 "AIBOM" 제품들은 다음 세 가지 중 하나를 수행합니다:

그들은 CycloneDX에 몇 가지 ML 필드를 추가하여 확장한 뒤, 그것으로 끝이라고 말합니다. CycloneDX 1.6은 ML 컴포넌트 타입을 추가했으며, 이는 진일보한 단계입니다. 하지만 이 형식은 모델을 메타데이터를 가진 리프 노드 (leaf node)로 취급할 뿐, 아티팩트 (artifacts)와 학습 이벤트 (training events)의 그래프로 취급하지 않습니다. CycloneDX 파일에 모델을 넣을 수는 있습니다. 하지만 그 안에서 미세 조정 계보 (fine-tune lineage)를 의미 있게 설명할 수는 없습니다. 스키마 (schema) 자체가 사용자의 의도와 충돌하고 있습니다.

그들은 HuggingFace 메타데이터를 긁어모아 그것을 출처 (provenance)라고 부릅니다. 만약 귀하의 벤더가 HF API에서 가져온 라이선스 정보, 파라미터 수 (parameter counts), 그리고 모델 카드 (model card) 조각들을 보여주고 있다면, 그것은 보기에는 좋지만 모델이 스스로 무엇이라고 주장하는지를 알려줄 뿐입니다. 그것은 귀하의 환경에 실제로 무엇이 배포되었는지를 알려주지 않으며, 분석가가 무작위 리포지토리 (repo)에서 양자화된 변체 (quantized variant)를 다운로드하여 내부 앱에 집어넣는 상황을 포착할 수도 없습니다.

그들은 호스팅된 API 모델 (hosted API models)에만 독점적으로 집중합니다. 이것은 최악의 실패 모드 (failure mode)입니다. 2026년 시장에 있는 AI 보안 도구의 약 절반은 여전히 "AI"가 "OpenAI, Anthropic, 또는 Gemini 호출"을 의미한다고 사실상 가정하고 있습니다. 반면, 기업용 AI 배포의 실제 성장은 자체 호스팅 추론 (self-hosted inference)에서 일어나고 있습니다. 현재 가장 많은 프로덕션 AI를 출시하고 있는 팀들은 자신들의 인프라 위에서 자신들의 모델을 실행하고 있으며, api.openai.com으로 나가는 트래픽 (egress)만을 감시하는 도구들은 이 모든 것을 보지 못합니다. 이것이 바로 cyradar가 특히 자체 호스팅 스택 (self-hosted stack)을 타겟팅하는 이유입니다. 왜냐하면 그곳에 진짜 인벤토리 격차 (inventory gap)가 존재하기 때문입니다.

짧게 언급할 네 번째 실패 모드가 있습니다. 모델을 호출하는 코드를 전혀 스캔하지 않고 AIBOM을 생성하는 도구들입니다. 귀하의 AIBOM은 귀하의 코드가 수행하는 작업과 일치해야 합니다. 만약 75개 이상의 언어에 걸친 cyscan의 1,815개 규칙이 인벤토리에 나타나지 않는 Bedrock 엔드포인트 호출을 찾아낸다면, 귀하에게는 문제가 있는 것이며, 이를 포착할 수 있는 유일한 방법은 런타임 (runtime)뿐만 아니라 소스 (source)를 스캔하는 것입니다.

아무도 대답하고 싶어 하지 않는 통합 문제

모든 보안 리더가 내재화했으면 하는 점이 있습니다. AIBOM은 정적인 산출물 (static artifact)이 아닙니다. 그것은 최소 네 가지 데이터 소스, 즉 소스 코드 분석 (source code analysis), 런타임 탐지 (runtime discovery), 네트워크 동작 (network behavior), 그리고 정책/제어 상태 (policy/control state)에 걸쳐 지속적으로 조정되는 뷰 (view)입니다. 만약 이 소스들 중 어느 하나라도 누락된다면, 귀하의 AIBOM은 특정한 방식으로, 그리고 예측 가능한 방식으로 틀리게 됩니다.

소스 코드 분석 (Source code analysis)은 개발자가 무엇을 호출하려고 _의도했는지_를 알려줍니다. 런타임 탐지 (Runtime discovery)는 무엇이 실제로 로드되었는지를 알려줍니다. 네트워크 동작 (Network behavior)은 무엇과 _실제로 통신하고 있는지_를 알려줍니다. 정책 상태 (Policy state)는 무엇이 _허용되어야 하는지_를 알려줍니다. 흥미로운 발견들 — 즉, 정말 중요한 것들 — 은 이러한 관점들 사이의 차이(deltas) 속에 존재합니다.

GPU 노드에 로드되었지만 어떤 코드 경로에서도 호출되지 않는 모델이 있다면? 아마도 실행 상태로 방치된 개발 실험일 것입니다. 비용과 공격 표면 (attack surface)만 차지할 뿐, 비즈니스 가치는 없습니다.

런타임 탐지에서 나타나지 않는 모델을 호출하는 코드 경로가 있다면? 이는 죽은 코드 (dead code)이거나, 더 흥미롭게는 누군가 몰래 구축한 섀도 엔드포인트 (shadow endpoint)로의 호출일 수 있습니다.

코드에서 호출되고, 런타임에서 실행되며, 정책이 승인하지 않은 외부 API와 통신하는 모델이 있다면? 그것이 바로 귀하의 이사회가 결국 질문하게 될 데이터 유출 (data exfiltration) 문제입니다.

CycloneDX 파일만으로는 이 중 그 어떤 것에도 답할 수 없습니다. 이 질문들에 답하기 위해서는 네 가지 관점을 동시에 보유하고 정기적으로 이를 조정(reconcile)하는 시스템이 필요합니다.

여기서 왜 단일 플랫폼이 실제로 중요한가

다소 자기중심적으로 들릴 수 있지만, 저는 다음과 같은 주장을 펼치고 이를 옹호할 것입니다. AIBOM 문제는 제가 아는 한, '최고의 개별 솔루션 (best-of-breed point solutions)'보다 '통합 도구 (unified tooling)'가 왜 우월한지를 보여주는 가장 강력한 근거입니다.

그 이유는 다음과 같습니다. 만약 코드 스캐너는 A 벤더, 런타임 스캐너는 B 벤더, 네트워크 텔레메트리 (network telemetry)는 C 벤더, 그리고 정책 엔진은 D 벤더라면, 귀하는 이제 통합 비즈니스를 수행하게 됩니다. 귀하가 직접 조정 로직 (reconciliation logic)을 작성해야 합니다. 각 벤더가 진화함에 따라 스키마 매핑 (schema mappings)을 유지 관리해야 합니다. 벤더 간의 정보가 불일치할 때 어떤 것이 권위 있는 정보인지 직접 판단해야 합니다. 그리고 그들은 끊임없이 불일치할 것입니다. 왜냐하면 각자는 세상의 단면만을 보고 있으며, 그 누구도 전체를 보지 못하기 때문입니다.

우리가 Cybrium을 지금과 같은 방식으로 구축한 이유는 — 코드용 cyscan (1,815개 규칙, 75개 이상의 언어), 7대 주요 추론 스택(inference stacks) 전반에 걸친 자체 호스팅 런타임 탐색을 위한 cyradar, 애플리케이션 계층 퍼징(fuzzing)을 위한 cyweb (22개 카테고리, 커뮤니티 기준점 대비 95% 템플릿 변환율)을 모두 구축하고, 이를 당신이 지정하는 어떤 에이전트(agent)나 어시스턴트(assistant)에도 10개의 도구를 노출하는 단일 MCP 서버를 통해 제공하는 이유는 — AIBOM이 공유된 세계 모델(shared model of the world)을 기준으로 관점들이 일치할 때에만 작동하기 때문입니다. 서로 다른 벤더들이 해당 모델에 데이터를 기여할 수는 있습니다. 하지만 누군가는 그 일치(reconciliation) 과정을 소유해야 합니다. 그것이 당신의 플랫폼이 아니라면, 바로 당신이 해야 합니다. 하지만 당신에게는 그럴 시간이 없습니다.

참고로, MCP 서버 부분은 사람들이 생각하는 것보다 훨씬 더 중요합니다. 벤더의 UI를 통해서만 쿼리(query)할 수 있는 AIBOM은 사고(incident)나 감사(audit) 시에만 살펴보게 될 AIBOM입니다. 반면, 당신의 엔지니어링 팀의 AI 어시스턴트가 10개의 잘 정의된 도구를 통해 직접 쿼리할 수 있는 AIBOM은 풀 리퀘스트(pull request) 리뷰, 설계 논의, 그리고 인벤토리(inventory)가 실제로 변경되는 일상적인 업무에서 사용되는 AIBOM입니다. 이것이 바로 거버넌스 연극(governance theater)과 복리 효과를 내는 거버넌스(governance that compounds)의 차이입니다.

실제로 일어나고 있는 재구성 (recomposition)

지난 18개월 동안 제가 지켜본 것은 AI 제어 평면(control plane)을 중심으로 보안 툴링 스택이 조용히 재구성되는 과정입니다. SBOM 도구들은 AI 필드를 덧붙이기 위해 경주하고 있습니다. CSPM 도구들은 모델 탐색(model discovery) 기능을 추가하고 있습니다. DLP 도구들은 프롬프트 필터링(prompt filtering)을 추가하고 있습니다. CNAPP 벤더들은 "AI-SPM"을 새로운 모듈로 제안하고 있습니다.