2026년에 모든 CISO에게 AIBOM이 필요한 이유와 벤더들이 실수하는 것

제 친구 중 한 명은 중견 핀테크 기업의 보안을 책임지고 있습니다. 엔지니어 약 400명 규모의 Series D 단계 기업으로, AI 전략 메모가 주말 사이에 작성되어 그다음 주 화요일에 바로 운영 환경(prod)에 배포될 법한 그런 곳이죠. 그녀는 지난 3월, 짜증과 공황 그 사이 어디쯤의 상태로 저에게 전화를 걸었습니다. 이사회가 아주 간단한 질문을 던졌기 때문입니다: "우리가 어떤 모델을 실행하고 있으며, 그것들은 어디에서 왔는가?"

그녀에게는 답변이 있었습니다. 하지만 틀린 답변이었습니다.

공식적인 답변은 "표준 게이트웨이를 통한 GPT-4와 Claude입니다"였습니다. 하지만 2주간의 조사 끝에 밝혀진 실제 답변은 17개의 모델이었습니다. ML 팀의 누군가가 고객 지원 프로토타입을 위해 직접 구축한 self-managed vLLM 박스에서 호스팅되는 Llama 3.1 8B 파인튜닝(fine-tune) 모델이 있었고, 그 후 삭제하는 것을 잊어버린 상태였습니다. 고정된 해시(pinned hashes) 없이 컨테이너 빌드 시점에 가져온 세 개의 Hugging Face 임베딩(embedding) 모델이 있었습니다. 왠지 모르게 스테이징 VPC(staging VPC)에서 접근 가능한 개발자의 GPU 워크스테이션에서 실행 중인 Whisper 변형 모델이 있었습니다. 고객 지원 티켓으로 파인튜닝되어 허용 범위가 넓은 정책(permissive policy)이 적용된 S3 버킷에 담겨 있는 두 개의 LoRA 어댑터(adapters)가 있었습니다. 그리고 아무도 승인했다는 사실을 기억하지 못하는 내부 Slack 봇에 7B 모델을 제공하는 llama.cpp 빌드가 있었습니다.

그녀가 이 과정을 설명할 때 저를 놀라게 했던 점은, 이 중 그 어느 것도 과거의 의미에서의 섀도우 IT(shadow IT)가 아니었다는 사실입니다. 이 시스템들 중 모든 것은 Jira 티켓이 있었습니다. 모든 것이 "승인"되었습니다. 단지 인벤토리(inventory)가 존재하지 않았을 뿐입니다. 그녀가 손가락으로 가리키며 "이것이 우리가 실행하는 것이고, 이것이 가중치(weights)가 온 곳이며, 이것이 그것들을 학습시킨 데이터이고, 이것이 그것들이 통신할 수 있도록 허용된 대상입니다"라고 말할 수 있는 단 한 곳의 지점이 없었습니다.

그것이 바로 AIBOM(AI Bill of Materials) 문제입니다. 그리고 2026년에 만약 당신에게 AIBOM이 없다면, 당신은 AI 보안 프로그램이 있는 것이 아닙니다. 그저 느낌(vibes)만 있을 뿐입니다.

논지 (The thesis)

논지 (The thesis)

현재 판매되고 있는 대부분의 AIBOM 제품은 UI가 달린 스프레드시트에 불과합니다. 모델 이름과 버전을 나열하고, 그 위에 CycloneDX 내보내기 기능을 덧씌운 뒤 완료되었다고 말합니다. 그것은 AIBOM이 아닙니다. 그것은 자재 명세서(Bill of Materials)인 척하는 부품 목록일 뿐입니다. 진정한 AIBOM은 모델, 가중치(weights), 데이터셋, 프롬프트(prompts), 도구(tools), 에이전트(agents), 그리고 이들 사이의 데이터 흐름을 연결하는 살아있는 그래프(living graph)여야 하며, 6개월 전에 누군가가 양식에 입력한 내용이 아니라 실제 환경에서 실행되고 있는 것들로부터 지속적으로 생성되어야 합니다.

AIBOM이 실제로 포함해야 하는 것

SBOM(Software Bill of Materials) 비유는 유용하지만 금방 한계에 부딪힙니다. 전통적인 SBOM은 바이너리에 어떤 라이브러리가 포함되어 있는지 알려줍니다. 관계는 대부분 단방향입니다. 즉, 이 바이너리가 이 버전의 이 패키지에 의존한다는 식입니다. Syft나 Trivy를 실행하면 꽤 괜찮은 결과물을 얻을 수 있습니다.

하지만 AIBOM은 SBOM의 의미에서의 의존성이 아닌 관계들을 포착해야 합니다. 미세 조정된(fine-tuned) 모델은 당연히 베이스 모델(base model)에 의존하지만, 학습 데이터셋, 미세 조정 설정, RLHF(Reinforcement Learning from Human Feedback) 보상, 그리고 점점 더 중요해지는 런타임 동작을 형성하는 프롬프트에도 의존합니다. 에이전트는 자신을 서비스하는 모델, 호출할 수 있는 도구, 읽어오는 메모리 저장소, 그리고 연결된 MCP 서버에 의존합니다. 이 중 그 어떤 것도 스키마를 찢어질 정도로 확장하지 않는 한 CycloneDX 스키마에는 나타나지 않습니다.

따라서 최소한 AIBOM은 다음 사항들을 포착해야 합니다: 가중치 출처(provenance)와 해시(hash)를 포함한 모델 자체; 소스까지의 계보(lineage)가 포함된 학습 및 미세 조정 데이터셋; 추론 인프라(vLLM, Ollama, TGI, Triton, LocalAI, LM Studio 또는 llama.cpp 여부); 사용 중인 프롬프트 및 프롬프트 템플릿; 모델에 노출된 도구 및 MCP 서버; 각 모델 경계의 안팎으로 흐르는 데이터 흐름; 그리고 위의 항목 중 무엇이든 변경할 수 있는 사람 또는 서비스 계정입니다.

만약 귀하의 벤더가 제공하는 AIBOM에서 이 중 세 가지 이상이 누락되었다면, 귀하는 AIBOM이 아니라 모델 레지스트리(model registry)를 구매한 것입니다.

대부분의 벤더가 실패하는 지점

올해 저는 아마 십여 개의 AIBOM 제품을 살펴봤을 것입니다. 실패 유형은 네 가지 패턴으로 모입니다.

첫 번째는 양식 기반(form-based) AIBOM입니다. 엔지니어가 설문지를 작성하면 플랫폼이 이를 저장하는 방식입니다. 이것은 보여주기식(theater)에 불과합니다. 수요일 새벽 3시에 프로덕션(production)에서 실행 중인 모델은 온보딩(onboarding) 과정에서 누군가가 양식에 기술한 모델이 아닙니다. 6주 이내에 인벤토리(inventory)는 드리프트(drift)되며, 당신은 다시 '감(vibes)'에 의존하는 상태로 돌아가게 됩니다.

두 번째는 API 게이트웨이 전용(API-gateway-only) AIBOM입니다. 제품이 귀하의 OpenAI 및 Anthropic API 호출에 연결되어 트래픽을 모니터링하고, 어떤 모델을 사용하는지 추론합니다. 이는 호스팅된 모델(hosted model) 사용은 잡아낼 수 있습니다. 하지만 그 외의 것은 아무것도 잡지 못합니다. 귀하의 셀프 호스팅(self-hosted) Ollama 인스턴스, vLLM 클러스터, llama.cpp 프로세스, 개발자 노트북의 LM Studio 세션, 데이터 팀이 구축한 LocalAI 배포 환경 등은 모두 보이지 않습니다. 제 추정으로는, 현재 진지한 엔지니어링 조직의 모델 사용량 중 셀프 호스팅 추론(self-hosted inference)이 30%에서 60% 사이를 차지합니다. 귀하는 공격 표면(attack surface)의 절반을 놓치고 있는 것입니다.

세 번째는 레지스트리를 AIBOM으로 착각하는 함정(registry-as-AIBOM trap)입니다. 이 제품은 실제로는 출처(provenance) 필드가 포함된 모델 레지스트리(model registry)일 뿐입니다. 모든 모델이 레지스트리를 거친다면 훌륭하겠지만, 레지스트리는 선택 사항(opt-in)입니다. 레지스트리는 보이지 않는 것을 볼 수 없습니다. 그리고 BOM의 핵심 목적은 등록하는 것을 잊어버린 항목들을 발견(discover)하는 것입니다.

네 번째이자 저를 가장 짜증 나게 하는 것은 정적(static) AIBOM입니다. 제품이 빌드 타임(build time)에 CycloneDX 파일을 생성하여 전달하면 작업이 완료되었다고 간주합니다. AI 시스템은 정적이지 않습니다. 보안 관점에서 볼 때, 시스템 프롬프트(system prompt)가 다른 동일한 모델은 서로 다른 시스템입니다. 새로운 도구(tool)가 연결된 동일한 에이전트(agent)는 폭발 반경(blast radius)이 다릅니다. 만약 귀하의 AIBOM이 배포 시점(deploy time)에만 업데이트된다면, 그것이 SIEM에 도달했을 때 이미 데이터는 노후화(stale)된 상태일 것입니다.

실제로 하나를 생성하기 위해 필요한 것

만약 제가 오늘 처음부터 AIBOM 프로그램을 구축한다면, 입력값(inputs)에 대해 다음과 같이 생각할 것입니다.

AI를 이해하는 코드 스캐닝 (code scanning)이 필요합니다. 단순히 "이 파일에 openai.ChatCompletion 호출이 있는가"를 확인하는 수준이 아니라, 에이전트 정의 (agent definitions), RAG 파이프라인 (RAG pipelines), 프롬프트 템플릿 (prompt templates), 도구 등록 (tool registrations), 그리고 디스크나 HF Hub로부터의 모델 로드 (model loads) 구조를 파악해야 합니다. 이것이 바로 우리가 75개 이상의 언어에 걸쳐 1,815개의 규칙을 갖춘 cyscan을 구축하고, AI 인지 탐지 (AI-aware detection)에 집중적으로 투자한 이유입니다. 전통적인 SAST 도구는 귀하의 에이전트가 접근해서는 안 될 도구에 접근 권한이 있는지에 대해 유용한 정보를 전혀 제공하지 못할 것입니다. 하지만 AI 인지 스캐너 (AI-aware scanner)는 가능합니다.

자체 호스팅 추론 (self-hosted inference)을 위한 런타임 탐지 (runtime discovery)가 필요합니다. 누군가는 귀하의 네트워크와 컨테이너 런타임 (container runtimes)을 돌아다니며 Ollama, vLLM, TGI, LocalAI, Triton, LM Studio, 그리고 llama.cpp 프로세스를 찾아내야 합니다. 이 프로세스들의 지문 (fingerprint)을 채취하고, 서비스 중인 모델을 식별하며, 각 서버가 잘못 설정될 수 있는 8가지 방식을 점검해야 합니다. 그것이 바로 cyradar가 하는 일입니다. 만약 호스팅된 API만을 스캔하고 있다면, 귀하는 공격자들이 플레이하는 게임과는 전혀 다른 게임을 하고 있는 것입니다.

웹 계층 인지 (web-layer awareness)가 필요합니다. 대부분의 AI 앱은 결국 HTTP 경계 (HTTP boundary) 뒤에 위치하게 됩니다. 모델은 백엔드 (backend)입니다. 만약 귀하의 AIBOM이 앱의 HTTP 엔드포인트 (HTTP endpoints)를 그 뒤에 있는 모델들과 연결하지 못한다면, 외부 공격 표면 (external attack surface)에 대해 추론할 수 없습니다. 우리는 이를 위해 AI 형태의 취약점 (AI-shaped vulnerabilities)에 맞춰 조정된 22가지 퍼징 (fuzz) 카테고리를 가진 cyweb을 사용하며, 업스트림 커뮤니티 템플릿으로부터 95%의 템플릿 변환율을 달성하여 새로운 기술을 쫓는 동안 지루한 웹 관련 사항들을 놓치지 않도록 합니다.

에이전트 및 도구 그래프 (agent and tool graph)를 모델링해야 합니다. 모든 MCP 서버는 권한 경계 (capability boundary)입니다. 모델이 호출할 수 있는 모든 도구는 잠재적인 혼동된 대리인 (confused deputy)입니다. 우리의 MCP 서버는 10개의 도구를 노출하며, 우리는 각 도구를 AIBOM 그래프 내의 문서화된 엣지 (edge)로 취급하고, 어떤 에이전트가 어떤 도구를 호출할 수 있는지에 대한 명시적인 허용 목록 (allowlists)을 적용합니다. 만약 귀하의 AIBOM에서 "어떤 모델이 어떤 도구를 호출할 수 있는가"라는 질문에 답할 수 없다면, 실제로 중요한 질문인 "이 모델이 탈옥 (jailbroken)되었을 때 저지를 수 있는 최악의 상황은 무엇인가"라는 질문에도 답할 수 없습니다.

가중치 (weights)에 대한 출처 (provenance)가 필요합니다. 해시 (Hashes), 존재하는 경우의 서명 (Signatures), 다운로드 소스, 라이선스 (License) 등이 포함되어야 합니다. 또한 Hugging Face에 있는 오염되거나 트로이 목마가 심겨진 (poisoned or trojaned) 모델들에 대한 알려진 악성 목록 (Known-bad lists)도 필요합니다. 이 부분은 전통적인 SBOM과 가장 유사해 보이며, 또한 대부분의 벤더들이 가장 그나마 잘 수행하고 있는 부분이기도 합니다.

마지막으로, 이것은 지속적 (continuous)이어야 합니다. 최소한 매일 이루어져야 하며, 이상적으로는 모든 배포 (deploy) 시점과 예정된 드리프트 체크 (drift check) 시점에 이루어져야 합니다. 그렇지 않으면 그것은 스냅샷 (snapshot)일 뿐이며, 스냅샷은 거짓말을 합니다.

지속적 관리가 어떤 모습인지에 대한 작은 예시

다음은 우리가 고객 환경에서 실행하는 작업의 스케치입니다. 이를 위해 반드시 우리의 도구를 사용할 필요는 없습니다. 구현 방식보다는 패턴이 더 중요합니다.

# 환경 전반에 걸쳐 셀프 호스팅된 추론 서버 (inference servers)를 탐색
cyradar discover \
  --targets ./targets.yaml \
...

차이점 (diff)은 대부분의 사람들이 건너뛰는 부분입니다. AIBOM 자체는 흥미롭습니다. 하지만 어제의 AIBOM에서 오늘의 AIBOM으로 변한 내용이 바로 여러분이 경고 (alerting)를 받아야 할 대상입니다. 새로운 모델이 나타났습니다. 특정 도구가 이전에는 연결되지 않았던 에이전트 (agent)에 연결되었습니다. vLLM 서버가 갑자기 새로운 포트에서 노출되었습니다. 그것이 바로 보안 신호 (security signal)입니다.

파인튜닝 (Fine-tuning) 및 RAG의 사각지대

대부분의 AIBOM 제품들이 실패하는 또 다른 지점은 여러분의 데이터에 접촉하는 모든 것입니다.

파인튜닝 모델은 학습 데이터의 보안 태세 (security posture)를 상속받습니다. 만약 고객의 개인정보 (PII)가 포함된 말뭉치 (corpus)로 Llama 변형 모델을 파인튜닝했다면, 여러분의 추론 계층 (inference layer)이 완벽하게 잠겨 있더라도 해당 모델은 이제 잠재적인 데이터 유출 경로 (data exfiltration vector)가 됩니다. AIBOM은 이 사실을 반드시 알고 있어야 합니다. 어떤 데이터가 파인튜닝에 사용되었는지, 누가 이를 승인했는지, 어떤 거주성 제약 (residency constraints)이 적용되는지, 그리고 고객이 권리를 행사할 때 삭제 프로세스 (deletion story)는 어떻게 되는지를 기록해야 합니다.

RAG (Retrieval-Augmented Generation)는 이와 유사하지만 더 심각합니다. 데이터가 학습 시점에 포함되는 것이 아니라, 런타임 (runtime)에 가져오기 때문입니다. 여러분의 AIBOM은 각 에이전트(agent)가 어떤 벡터 스토어 (vector store)로부터 데이터를 읽을 수 있는지, 해당 스토어에 무엇이 들어있는지, 데이터가 어떻게 채워지는지, 그리고 청크 (chunk) 수준에서의 액세스 제어 모델 (access control model)은 무엇인지를 반드시 알고 있어야 합니다. 대부분의 제품은 벡터 스토어를 불투명한 인프라 (opaque infrastructure)로 취급합니다. 하지만 그렇지 않습니다. 그것은 AI 시스템의 일부이며, BOM에 포함되어야 합니다.

저는 한 고객이 정직한 AIBOM 점검 과정을 통해, 자신들의 고객 지원 에이전트가 내부 HR 위키의 내용이 포함된 벡터 스토어에서 데이터를 검색하고 있다는 사실을 발견하는 것을 보았습니다. 임베딩 파이프라인 (embedding pipeline)이 필터링 없이 "Confluence 전체"를 가리키고 있었기 때문입니다. AIBOM이 이를 잡아냈습니다. 그들의 기존 "AI 거버넌스 위원회"는 9개월 동안 해당 에이전트를 승인해 오고 있었습니다.

이것이 반드시 하나의 플랫폼이어야 하는 이유

왜 코드 스캐닝 (code scanning), 런타임 AI 디스커버리 (runtime AI discovery), 웹 퍼징 (web fuzzing), 그리고 MCP 서버를 별개의 제품으로 판매하지 않고 하나의 플랫폼으로 묶었는지에 대해 질문을 많이 받습니다. 그 이유는 정확히 AIBOM 문제입니다.

AIBOM은 정의상 여러 표면 (surfaces)에 걸친 조인 (join)입니다. 코드 표면, 런타임 표면, 웹 표면, 그리고 에이전트 및 도구 표면이 결합됩니다. 만약 이 네 가지 신뢰할 수 있는 정보원 (sources of truth)이 네 개의 서로 다른 벤더 (vendor)에 존재하고, 네 개의 서로 다른 스키마 (schema)와 네 개의 서로 다른 업데이트 주기 (update cadence)를 가지고 있다면, 조인은 절망적입니다. 결국 서로 일치하지 않는 네 개의 부분적인 인벤토리 (inventory)만 남게 되며, 분기별 회의에서는 모두가 왜 자신의 데이터 조각이 맞는지 설명하는 데 시간을 허비하게 됩니다. 아무도 결과물을 내놓지 못합니다.

표면들이 그래프 (graph)를 공유할 때, 차이점 (diff)은 의미를 갖습니다. 여러분은 다음과 같이 질문할 수 있습니다: "cyweb이 찾아낸 이 새로운 HTTP 엔드포인트 (endpoint)는 어떤 모델로 라우팅되는가? 그 모델은 어떤 도구들을 가지고 있는가? 그리고 이 변경 사항 중 지난주와 비교해 새로운 것이 있는가?" 하나의 그래프이기 때문에 단 한 번의 쿼리 (query)로 이 질문을 던질 수 있습니다. 이는 우리가 다른 벤더들보다 똑똑해서가 아닙니다. 첫날부터 표면 전반에 걸쳐 모델의 일관성 (coherent)을 유지하겠다는 아키텍처적 결정 (architectural decision)을 내렸기 때문입니다.

재구성 (The recomposition)

현재 시장에서 실제로 일어나고 있는 현상은, 분석의 단위(unit of analysis)로서 AI 시스템을 중심으로 기존의 벤더 카테고리들이 해체되고 다시 재구성되고 있다는 점입니다. SAST, DAST, CSPM, 모델 레지스트리(model registry), 데이터 카탈로그(data catalog), 에이전트 관측성(agent observability) — 이것들은 2024년 기준으로 5개의 제품이자 3개의 구매 페르소나(buyer personas)였습니다. 하지만 2026년에는 하나의 BOM을 중심으로 하는 하나의 워크플로우(workflow)가 될 것입니다.

이를 이해하는 CISO들은 AIBOM을 중심으로 보안 아키텍처(security architecture)를 조용히 재구축하고 있습니다. 그들은 AIBOM을 중앙 인벤토리(central inventory)로 취급하고 있으며, 이는 ITIL 시대에 CMDB가 지향했으나 결코 완벽히 실현되지 못했던 방식과 같습니다. 그들은 AIBOM을 변경 관리(change management), 사고 대응(incident response), 벤더 리스크(vendor risk), 감사(audit) 프로세스에 연결하고 있습니다. 또한 어떤 AI 시스템이 존재하는지, 그리고 각 시스템이 무엇을 접촉할 수 있는지에 대한 신뢰할 수 있는 단일 출처(source of truth)로 활용하고 있습니다.

이를 이해하지 못하는 CISO들은 여전히 개별 포인트 제품(point products)을 구매하고 이를 Jira 보드로 억지로 이어 붙이려 하고 있습니다. 그들은 2026년에 왜 계속해서 예상치 못한 상황(surprises)이 발생하는지 이사회에 설명하며 시간을 보내게 될 것입니다. 그 '예상치 못한 상황'이란 바로 AIBOM의 공백(gaps)을 의미합니다. 이를 설명할 다른 단어는 없습니다.

이 글에서 한 가지만 기억해야 한다면, 이것을 기억하십시오. 2026년에 이사회가 던질 질문은 "AI 보안을 하고 있습니까?"가 아닙니다. "인벤토리(inventory)를 보여주세요"입니다. 만약 당신의 답변이 5개의 서로 다른 콘솔(consoles)을 여는 과정을 포함한다면, 당신은 이미 회의에서 패배한 것입니다.

이번 분기에 해야 할 일