2026년 모든 CISO가 AIBOM을 필요로 하는 이유. 대부분의 벤더들이 '극장(Theater)'만 배포하고 있다.

제 친구 중 한 명이 중견 규모의 핀테크 기업에서 보안 업무를 맡고 있습니다. 약 900명의 엔지니어가 근무하며, Series D 단계에 있는 곳입니다. 이곳은 AI 예산이 18개월 만에 세 배로 늘어났지만, 그 돈이 어디로 갔는지 아무도 명확히 설명할 수 없는 종류의 회사죠. 그녀는 지난 8월 저에게 전화를 걸어왔는데, 이사회에서 그녀가 답할 수 없는 질문을 했기 때문입니다. 바로 '우리가 실제로 어떤 AI를 운영하고 있는가?'라는 것이었습니다.

'무엇을 구매했는지'에 대한 질문이 아니었습니다. 우리가 무엇을 운영하고 있는지 말입니다. 현재, 실제 프로덕션 환경에서요.

그녀는 조달 목록을 꺼냈습니다. 14개의 벤더가 있었습니다. 그리고 클라우드 청구서를 확인하자 아무도 기록하지 않은 또 다른 6개의 AI 서비스가 발견되었습니다. 그러자 플랫폼 팀은 사기 방지팀을 위해 EKS 클러스터에 배포한 세 개의 내부 Llama 파인튜닝 모델에 대해 언급했습니다. 이어서 성장 팀이 출시한 LangChain 앱이 언급되었는데, 이 앱은 쿼리에 따라 OpenAI, Anthropic, 그리고 Cohere의 리랭커를 호출합니다. 마지막으로 데이터 과학 조직은 아무도 보안 검토를 거치지 않은 상태로 7개월 동안 운영되어 온 양자화된 Mistral 변형 모델을 실행하는 vLLM 인스턴스를 인정했습니다.

일주일이 끝날 무렵, 그녀의 'AI 인벤토리'는 73줄짜리 스프레드시트가 되었고, 그녀는 여전히 그것을 신뢰하지 못했습니다. 그녀를 가장 괴롭힌 부분은 이러한 확산(sprawl) 자체가 아니었습니다. 문제는 그 모델들 중 두 개가 퇴사한 직원 엔지니어가 Hugging Face에서 직접 다운로드했다는 것이었습니다. 아무도 이 모델들이 어떤 학습 데이터에 노출되었는지 알지 못했습니다. 오염되었는지 여부도 모릅니다. 그저... 운영되고 있었고, 고객 입력을 받고, 답변을 반환하고 있을 뿐이었습니다.

그녀가 저에게 어떻게 할 것인지 물어봤습니다. 저는 그녀에게 AIBOM이 필요하다고 말했습니다. 진짜 AIBOM이요. 그리고 아닙니다. 귀사의 GRC 벤더가 새로 만든 'AI 거버넌스 모듈' 같은 것이 아닙니다.

논지

AI Bill of Materials(AIBOM)은 2026년 가장 저평가된 보안 아티팩트이며, 이 이름으로 판매되는 것의 90%는 '극장'에 불과합니다. 즉, 거버넌스처럼 포장된 공급업체 이름이 담긴 스프레드시트입니다. 기능적인 AIBOM은 분기별이 아니라 지속적으로 네 가지 질문에 답할 수 있어야 합니다. 어떤 모델이 실행되고 있는지, 어디서 왔는지, 무엇에 접근할 수 있는지, 그리고 누가 그것을 변경하도록 허용되었는지를 말입니다. 만약 귀하의 AIBOM이 어느 순간이라도 이 네 가지 질문에 답할 수 없다면, 그것은 AIBOM이 아닙니다. 규정 준수 스크린샷일 뿐입니다.

AIBOM이 실제로 무엇인지

SBOM(Software Bill of Materials) 비유는 유용하지만 문제를 과소평가합니다. SBOM은 결정론적인 종속성(deterministic dependencies)을 추적합니다. 라이브러리 버전 2.14.3은 귀하의 전체 시스템에서 동일하게 작동합니다. 모델은 그렇지 않습니다. 모델에는 가중치(weights), 토크나이저(tokenizer), 설정 파일(config), 프롬프트 스캐폴드(prompt scaffold), 서빙 런타임(serving runtime), 시스템 프롬프트, 검색 소스(retrieval sources), 도구 정의(tool definitions)가 있으며, 대부분의 프로덕션 스택에서는 그 행동을 실질적으로 변화시키는 수많은 다운스트림 통합 기능들이 있습니다. '동일한' Llama-3-70B를 배포한 두 시스템은 하나는 CRM에 연결되는 RAG 파이프라인을 가지고 다른 하나는 그렇지 않기 때문에 마치 서로 다른 시스템처럼 작동할 수 있습니다.

따라서 AIBOM은 목록이 아닙니다. 그래프입니다. 최소한 다음 내용들이 포함되어야 합니다:

• 모델 아티팩트 자체: 이름, 버전, 가중치 해시(weights hash), 출처, 라이선스, 양자화(quantization)
• 서빙 런타임: Ollama, vLLM, TGI, LocalAI, Triton, LM Studio, llama.cpp 또는 호스팅된 API 엔드포인트
• 배포 표면(deployment surface): 어떤 클러스터, 어떤 네임스페이스, 어떤 네트워크 세그먼트, 어떤 인그레스(ingress)
• 데이터 평면(data plane): 모델이 읽을 수 있는 것(RAG 인덱스, 도구, 데이터베이스)과 쓸 수 있는 것
• 신원성 평면(identity plane): 어떤 서비스 계정이 이를 호출할 수 있는지, 누가 가중치를 업데이트할 수 있는지, 누가 시스템 프롬프트를 변경할 수 있는지
• 출처 사슬(provenance chain): 가중치가 어디서 왔는지, 무엇이 그것에 서명했는지, Hugging Face나 내부 학습 작업부터 실행 중인 파드까지의 관리 체인(chain of custody)

만약 귀하의 AIBOM이 대부분의 벤더 제품이 멈추는 항목 1과 2에 그친다면, 이는 엔진만을 설명한 것입니다. 자동차, 운전자, 그리고 도로를 설명하지 못한 것입니다.

대부분의 벤더들이 잘못하는 부분

저는 올해 'AI 인벤토리' 또는 'AI 거버넌스' 플랫폼으로 자신을 홍보하는 11개 제품을 평가했습니다. 이름은 생략하겠습니다. 이들 제품이 일관되게 잘못하고 있는 부분이 있습니다.

구매 내역(procurement)을 관리하지, 실행 시점(runtime)을 관리하지 못한다. 이러한 도구의 대다수는 귀하의 SSO 로그, CASB, 계약 관리 시스템과 통합됩니다. 이들은 귀하가 비용을 지불한 AI 벤더 목록을 생성합니다. 이는 재무팀에게는 유용하지만, 보안팀에게는 거의 쓸모가 없습니다. 모니터링되지 않는 EKS 노드에서 실행되는 Llama 파인튜닝 모델은 SSO 로그에 나타나지 않습니다. 개발자 노트북의 LM Studio에 로드된 양자화된 GGUF 모델 역시 CASB에 나타나지 않습니다. 제가 가장 우려하는 모델들은 바로 구매 내역 추적 기록을 전혀 생성하지 않는 모델들입니다.

모델을 블랙박스로 취급한다. 진정한 AIBOM은 모델 아티팩트(artifact)를 검사해야 합니다. 해시값은 무엇인가? 알려진 출처와 일치하는가? 누군가 파인튜닝했는가, 그리고 어떤 데이터를 사용했는가? 토크나이저는 기본 모델과 함께 제공된 것인가, 아니면 교체되었는가? 대부분의 거버넌스 도구는 아티팩트를 전혀 건드리지 않기 때문에 이 질문들에 답할 수 없습니다. 그저 이름만 가져와서(ingest) 처리합니다.

애플리케이션 계층을 무시한다. 스택에서 가장 위험한 것은 모델 자체가 아닙니다. 모델 주변의 코드—LangChain 연결 고리, 사용자 정의 리트리버(retrievers), 도구 정의(tool definitions), 주입된 사용자 데이터가 포함된 프롬프트 템플릿, 프로덕션 데이터베이스에 접근할 수 있는 함수 호출 API로 원시 사용자 문자열을 전달하는 Flask 엔드포인트—입니다. 'GPT-4'를 나열하지만 그것을 감싸는 50줄의 Python 코드를 목록화하지 못하는 AIBOM은 귀하의 공격 표면(attack surface)에 대해 거짓말을 하고 있는 것입니다.

이들은 주기적으로 업데이트됩니다. 주간 단위로요. 운이 좋으면 일일 단위로도요. 개발자가 40분 만에 새로운 모델을 배포할 수 있는 환경에서, '주기(cadence)'는 잘못된 기본 개념입니다. 귀하의 AIBOM은 이벤트 기반이어야 합니다. 모델 가중치가 포함된 새 컨테이너? AIBOM 항목이 됩니다. 내부 서브넷에서 접근 가능한 새 Ollama 엔드포인트? AIBOM 항목이 됩니다. 빌드 파이프라인에 새로운 Hugging Face 다운로드? 해시값과 함께, 다음 동기화 시점이 아닌 지금 바로 AIBOM 항목이 되어야 합니다.**

그들은 발견 사항들을 상호 연관시키지 않습니다. 이 부분이 저를 가장 괴롭힙니다. 단순히 재고 목록(inventory)에 불과한 AIBOM은 기본 중의 기본입니다. 각 항목을 알려진 모델 취약점, 안전하지 않은 런타임 구성, 노출된 추론 엔드포인트, 그리고 주변 코드의 애플리케이션 계층 결함과 교차 참조하는 AIBOM이야말로 보안입니다. 재고 목록은 대화의 시작일 뿐, 끝이 아닙니다.

기능적인 AIBOM 파이프라인의 모습

제가 어떻게 이것을 구축할지 설명해 드리겠습니다. 저는 이 문제에 대해 구체적으로 생각했고, 너무 많은 팀들이 슬라이드덱 지옥(slide-deck purgatory)에 갇히는 것을 목격했기 때문입니다.

아티팩트 계층에서 시작하세요. 컨테이너, 람다 또는 이미지를 생성하는 모든 빌드 파이프라인은 모델 가중치, 토크나이저 파일 및 명백한 AI 프레임워크 임포트를 스캔해야 합니다. 여러분은 .gguf, .safetensors, .bin, .onnx, pytorch_model.* 그리고 transformers, llama-cpp, vllm, langchain, llamaindex, haystack의 Python 시그니처와 꼬리 부분(long tail)을 찾고 있습니다. 이것은 코드 스캐닝 문제입니다. Cybrium에서는 cyscan을 사용하여 처리하며, 이는 75개 이상의 언어에 걸쳐 1,815개의 규칙을 실행하고 대부분의 SAST 도구가 놓치는 AI 관련 코드 패턴을 구체적으로 다룹니다. 그 결과는 다음과 같습니다: 모든 리포지토리와 모든 빌드에서 어떤 AI 코드가 그리고 어떤 AI 아티팩트가 존재하는지입니다.

런타임 계층으로 이동해야 합니다. 내부 네트워크(VPC, Kubernetes 클러스터, 개발자 VLAN 등)를 탐색하며 추론 엔드포인트를 식별할 수 있는 능동 스캐너가 필요합니다. Ollama는 시그니처를 가지고 있고, vLLM도 마찬가지입니다. TGI, LocalAI, Triton, LM Studio, llama.cpp 모두 식별 가능합니다. Cybrium의 cyradar는 AI 추론 표면(inference surfaces)을 위해 이것을 특별히 수행하며, 가장 자주 발견되는 문제는 개발자의 EC2에 0.0.0.0에 바인딩된 Ollama 인스턴스가 피어링된 VPC에서 접근 가능하다는 것입니다. 아무도 그 내용을 구매 품의서에 넣지 않습니다.

애플리케이션 계층으로 이동해야 합니다. 사용자와 모델 사이에 중개하는 모든 웹 엔드포인트, 모든 API, 모든 Lambda 함수가 퍼징(fuzzing)됩니다. 프롬프트 주입(Prompt injection), 시스템 프롬프트 유출(system prompt leakage), 도구 오용(tool abuse), 출력 처리 결함(output handling flaws), 검색을 통한 SSRF 등 전체 분류 체계가 적용됩니다. cyweb은 이들 전반에 걸쳐 22가지 퍼징 카테고리를 실행하며, 프로덕션 LLM 앱의 발견율은 대부분의 CISO가 예상하는 것보다 상당히 높습니다. AIBOM은 이러한 발견 사항들을 별도의 티켓이 아닌 구성 요소의 속성(attributes)으로 포함해야 합니다.

상관관계 분석을 해야 합니다. 모든 아티팩트에는 안정적인 ID가 부여됩니다. 모든 런타임 엔드포인트는 자신이 서비스하는 아티팩트와 연결됩니다. 모든 애플리케이션은 호출하는 런타임과 연결됩니다. 모든 발견 사항은 그래프의 올바른 노드에 첨부됩니다. 이제 이사회에서 '어떤 AI를 운영하고 있습니까?'라고 물으면 답이 있습니다. IR 팀이 '만약 vLLM에 대한 CVE가 내일 발표된다면, 무엇이 노출됩니까?'라고 물으면 답이 있습니다. 법무팀이 '고객 데이터 흐름 중 어떤 것이 웹에서 스크랩된 데이터로 훈련된 모델과 접촉합니까?'라고 물으면 답이 있습니다.

지속적으로 업데이트되고, 이벤트 기반이며, 발견 사항과 상관관계 분석을 수행하는 그 그래프가 바로 AIBOM입니다.

출처(Provenance) 문제

저는 출처 문제에 대해 1분 정도 이야기하고 싶습니다. 왜냐하면 이것이 가장 어렵고 벤더들이 가장 쉽게 무시하는 부분이기 때문입니다.

만약 엔지니어가 다음 명령을 실행한다면:

ollama pull llama3:70b-instruct-q4_K_M

그들이 방금 무엇을 다운로드했을까요? 그들은 Ollama의 모델 라이브러리에서 양자화된 GGUF 파일을 다운로드했습니다. 이 파일은 Meta가 공개한 릴리스를 패키징한 것이며, Meta가 완전히 공개하지 않은 데이터셋으로 학습되었습니다. 전송 경로(chain of custody)는 최소 세 단계에 걸쳐 있으며, 각 단계마다 아티팩트가 교체되었을 수 있습니다. Hugging Face에서는 오타 스쿼팅된 모델 이름이 있었습니다. 보안이 뚫린 계정들은 악성 가중치(malicious weights)를 푸시했습니다. 오래된 모델 형식에서의 Pickle 역직렬화는 수년 동안 신뢰할 수 있는 원격 코드 실행(RCE) 원시 요소였습니다.

진정한 AIBOM은 해시 값을 고정합니다. 이름이나 버전 태그가 아니라, 디스크에 있는 실제 바이트의 해시 값입니다. 그리고 이 해시 값을 알려진 안전한 참조값과 비교하여 추적합니다. 만약 해시 값이 Meta가 발표한 것과 일치하지 않는다면, 그것이 하나의 발견 사항(finding)입니다. 해시 값은 일치하지만 토크나이저(tokenizer)가 교체되었다면, 그것도 하나의 발견 사항입니다. 모델을 신뢰할 수 없는 미러에서 다운로드했다면, 그것 역시 하나의 발견 사항입니다.

대부분의 거버넌스 도구들은 이런 것을 전혀 하지 않습니다. 그들은 'llama3-70b'를 문자열로 기록하고 넘어갑니다. 이 문자열은 여러분의 클러스터에서 실제로 무엇이 실행되고 있는지에 대해 아무것도 알려주지 못합니다.

왜 다섯 개가 아닌 하나의 플랫폼이어야 하는가

성숙한 보안 조직의 본능적인 반응은 최고의 제품들을 구매하여 하나로 엮어내는 것입니다. 여기서는 SBOM 도구, 저기서는 모델 스캐너, LLM 앱을 위한 DAST(동적 애플리케이션 보안 테스트), 추론 엔드포인트를 위한 자세 관리(posture management), 그리고 이를 통합하는 GRC 오버레이가 필요합니다. 저는 많은 팀들이 이것을 시도하다가 무너지는 것을 지켜봤는데, 그 이유는 단 하나입니다: 상관관계 계층(correlation layer)이 가장 어려운 부분이며, 이 부분이 다섯 개의 벤더 사이에 존재할 때는 아무도 소유하지 않기 때문입니다.

AIBOM은 코드 발견 사항, 아티팩트 출처(artifact provenance), 런타임 검색(runtime discovery), 그리고 애플리케이션 계층 취약점들이 동일한 그래프에 들어올 때만 AIBOM으로 작동합니다. 만약 이들이 같은 모델에 대해 다섯 개의 다른 콘솔과 다섯 개의 다른 ID로 들어온다면, 그것은 AIBOM이 아닙니다. 그것은 다섯 개의 대시보드와 이를 조정하기 위한 Jira 프로젝트일 뿐입니다.

이것이 바로 Cybrium이 네 가지 계층을 한 지붕 아래 구축하고 단일 MCP 서버를 통해 10개의 도구로 노출하는 이유이며, 이를 통해 귀하의 AI 에이전트와 SOC가 동일한 그래프에 질의할 수 있게 합니다. 저는 이 부분에 대해 중립적이지 않습니다. 제가 이렇게 구축한 이유는 고객들이 다섯 개의 벤더 접근 방식을 시도하는 것을 몇 년 동안 지켜보았고, 그 어떤 경우에도 신뢰할 수 있는 인벤토리를 만들어내는 것을 본 적이 없기 때문입니다.

현재 일어나고 있는 재구성(recomposition)

제가 시장에서 실제로 무슨 일이 벌어지고 있다고 생각하며, 지금 이 글을 쓰는 이유입니다.

지난 2년 동안 'AI 보안'은 가장 먼저 슬라이드를 들고 나타난 사람이 정의한 카테고리였습니다. 레드팀(Red-teaming) 스타트업, 프롬프트 주입 스캐너(prompt-injection scanners), 데이터 유출 분류기(data-leakage classifiers), 모델 방화벽(model firewalls), 거버넌스 오버레이(governance overlays). 이 모든 것은 기능일 뿐입니다. 그 어떤 것도 프로그램은 아닙니다.

2026년에는 중력이 AIBOM 쪽으로 이동하고 있습니다. 왜냐하면 다른 모든 통제 메커니즘이 그것에 의존하기 때문입니다. 존재한다는 것을 모르는 모델을 레드팀 할 수 없습니다. 발견하지 못한 엔드포인트에 정책을 적용할 수 없습니다. 출처(provenance)를 재구성할 수 없는 시스템에 대한 인시던트 대응(incident response)을 수행할 수 없습니다. 인벤토리 자체가 기질(substrate)입니다. 나머지 모든 것은 이 인벤토리를 입력으로 받는 함수일 뿐입니다.

제가 만나는, 이 흐름보다 앞서 나가는 CISO들은 이미 자신들의 AIBOM을 주요 아티팩트(artifact)로 취급하고, 레드팀이나 정책, 런타임 가드 등 다른 모든 것을 그 아티팩트를 소비하는 것으로 간주합니다. 뒤처진 CISO들은 여전히 개별 도구들을 구매하며 매 분기 이사회에 제출할 스프레드시트를 만들려고 애쓰고 있습니다. 이 두 가지 자세 사이의 격차가 내년에 규제 기관, 보험사, 인수 기업들이 주목할 부분이 될 것입니다. 저는 이미 실사 설문지(diligence questionnaires)에서 이를 목격하고 있습니다.

만약 귀하의 이사회가 아직 묻지 않았다면, 곧 물어볼 것입니다. 그리고 '저희는 스프레드시트가 있습니다'라는 답변은 후속 질문을 견디지 못할 것입니다.

이번 분기에 해야 할 일

제가 그 핀테크 회사 친구의 의자에 앉아 있다면, 제가 실행할 순서는 이렇습니다.