한 친구가 중견 규모의 핀테크 기업에서 보안 업무를 맡고 있다. 지난달, 그녀는 GRC(Governance, Risk, and Compliance) 담당자로부터 Slack 메시지를 받았다. EU AI Act 감사관이 운영 중인 모든 AI 시스템에 대한 전체 인벤토리와 각 모델의 출처(provenance), 그리고 위험 등급별 매핑을 금요일까지 요구한 것이다. 그녀는 생각했다. 괜찮아, 우리에게는 SBOM 파이프라인도 있고, 모델 레지스트리도 있고, 벤더 설문지도 있어. 두 시간 정도면 할 수 있을 거야.

9일 후에도 그녀는 아직 조정 작업 중이었다.

모델 레지스트리는 데이터 과학 팀이 배포한 네 가지 모델에 대해서만 알고 있었다. 제품 팀이 앱을 wrapper 라이브러리를 통해 Claude와 연결하여 만든 Copilot 스타일의 비서에 대해서는 알지 못했다. 아무에게도 말하지 않고 지난 4월 임베딩 모델을 교체한 두 개의 내부 RAG(Retrieval-Augmented Generation) 시스템에 대해서도 몰랐다. 심지어 'AI 기반 검색' 기능이 사실은 계약자가 코로(colo, colocation facility)의 GPU 박스에서 실행하고 있는 미세 조정된 Llama 변종이라는 것, 또는 벤더가 '업그레이드'했다고 한 고객 지원 도구가 이제 싱가포르에 있는 제3자 추론 API(inference API)로 사용자 티켓을 전송한다는 사실조차 알지 못했다.

이 이야기를 들으면서 나에게 와닿았던 부분은, 감사관이 심지어 공격적이지 않았다는 것이다. 그는 기본적인 질문들만 하고 있었다. 모델 이름. 모델 버전. 훈련 데이터의 출처(provenance). 배포 위치. 들어오는 데이터 흐름. 나가는 데이터 흐름. 누가 소유하는가. 무엇을 할 수 있는가. 무엇을 할 수 없는가. 그리고 그녀는 Jira, Terraform, 벤더 계약서, 그리고 2024년 이후 업데이트되지 않은 Notion 페이지 두 개를 뒤져야만 그 질문들 중 절반에 답할 수 있었다.

이것이 바로 AIBOM 문제이다. 이것은 단순한 규정 준수 체크박스가 아니다. 이는 당신의 AI 표면적(AI surface area)이 이를 파악하는 능력보다 더 빠르게 성장하고 있다는 현실을 깨닫는 것이다. 그리고 대부분의 벤더들이 'AI Bill of Materials'로 판매하는 도구들은 모델 열만 추가된 재포장된 SBOM에 불과하다.

AIBOM은 문서가 아닙니다. 그것은 모든 모델, 모든 데이터셋, 모든 추론 엔드포인트 (inference endpoint), 모든 프롬프트 템플릿 (prompt template), 모든 에이전트 (agent), 모델이 호출할 수 있는 모든 도구 (tool), 그리고 그들 사이의 모든 데이터 흐름을 담고 있는 실시간 쿼리 가능한 그래프 (queryable graph)이며, 여기에 출처 (provenance), 리스크 포스처 (risk posture), 변경 이력이 풍부하게 결합된 형태여야 합니다. 만약 당신의 AIBOM이 빌드 타임 (build time)에 생성된 정적인 JSON 파일이라면, 당신은 이미 진 것입니다. 그리고 만약 당신의 벤더가 그들의 AIBOM 기능이 "모델 메타데이터가 포함된 SPDX"라고 말한다면, 그들은 당신에게 스프레드시트를 팔고 있는 것입니다.

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

시장이 모호한 설명으로 가득 차 있기 때문에, 저는 구체적으로 말씀드리겠습니다. 제가 AIBOM이라고 말할 때, 그것은 사람이 직접 찾아보지 않아도 요구 시점에 다음 질문들에 답할 수 있는 인벤토리 (inventory)를 의미합니다.

**모델 계층 (model layer)**은 명확한 부분입니다. 베이스 모델 (base model), 파인튜닝 (fine-tunes), LoRA 어댑터 (LoRA adapters), 양자화 변형 (quantization variant), 라이선스, 소스 (HuggingFace 리포지토리, 내부 S3 버킷, 벤더 API). 모든 이들이 이 부분은 방향을 맞게 잡습니다. 그들이 실패하는 지점은 버전 관리 (versioning)입니다. 대부분의 도구들은 모델 이름은 캡처하지만, "gpt-4o"가 매 분기마다 다른 가중치 파일 (weight file)로 해결된다는 사실이나, 누군가 더 작은 GPU에 맞추려 시도했을 때 당신의 로컬 Llama-3.1-8B-Instruct가 소리 없이 Q4_K_M 양자화 버전으로 교체되었다는 사실은 놓칩니다.

**데이터 계층 (data layer)**은 정교한 벤더들이 식은땀을 흘리기 시작하는 지점입니다. 훈련 데이터 계보 (training data lineage). 파인튜닝 코퍼스 (fine-tuning corpus). RAG 소스 문서. 벡터 인덱스 구성 (vector index composition). 임베딩 모델 버전 (embedding model version). 어떤 개인정보 (PII)가 어떤 인덱스에 있는지. 어떤 고객의 데이터가 어떤 검색 버킷 (retrieval bucket)에 있는지. 규제 기관들이 실제로 주목하는 곳이 바로 여기입니다. EU AI Act의 제10조는 데이터 거버넌스 (data governance)에 관한 것입니다. 콜로라도의 AI 법안은 훈련 데이터를 중요하게 다룹니다. 만약 당신의 AIBOM이 어떤 데이터셋이 어떤 모델에 공급되었는지 알려줄 수 없다면, 당신은 판타지 소설을 쓰고 있는 것입니다.

**런타임 계층 (runtime layer)**은 모든 SBOM 스타일의 도구들이 처참하게 틀리는 부분입니다. 이 모델은 어디에서 서빙되고 있습니까? 개발자의 노트북에 있는 Ollama인가요? 로드 밸런서 뒤의 vLLM인가요? 아니면 관리형 API인가요? 노출된 엔드포인트(endpoints)는 무엇입니까? 그 앞에는 어떤 인증(auth)이 있습니까? 어떤 에이전트(agents)가 어떤 도구(tools)를 호출할 수 있습니까? 어떤 프롬프트 템플릿(prompt templates)이 프로덕션 환경에서 사용 중이며, 마지막으로 누가 이를 변경했습니까? 어떤 가드레일(guardrails)이 활성화되어 있으며, 그것들이 실제로 작동 중입니까, 아니면 6개월 전 스테이징(staging) 환경에서 누군가 설정한 플래그에 의해 우회되고 있습니까?

**통합 계층 (integration layer)**은 AI 시스템을 실제로 위험하게 만드는 요소입니다. 어떤 앱이 어떤 모델을 호출하는지, 어떤 데이터가 경계를 넘나드는지, 어떤 MCP 서버가 노출되어 있는지, 에이전트가 호출할 권한을 가진 도구는 무엇인지가 여기에 해당합니다. 모델이 귀하의 프로덕션 데이터베이스를 읽을 수 있는지, 혹은 티켓팅 시스템에 쓸 수 있는지 여부도 포함됩니다. 이것이 바로 폭발 반경(blast radius) 지도이며, 이는 매주 변합니다.

**포스처 계층 (posture layer)**은 제가 가장 중요하게 생각하는 부분입니다. 왜냐하면 이것이 AIBOM을 단순한 기록 보관용이 아닌 운영 가능한 상태로 만들기 때문입니다. 위의 모든 항목에 대해 현재의 보안 포스처(security posture)는 어떠합니까? 모델이 프롬프트 인젝션(prompt injection) 회복력에 대해 스캔되었습니까? 엔드포인트가 인증 없이 노출되어 있습니까? 종속성(dependencies)에 취약점이 있습니까? 서빙 프레임워크(serving frameworks)가 패치되었습니까? 마지막으로 실제로 테스트한 것이 언제입니까?

만약 귀하의 AIBOM에 이 다섯 가지 계층 중 하나라도 빠져 있다면, 그것은 AIBOM이 아닙니다. 그것은 스프레드시트일 뿐입니다.

대부분의 벤더들이 틀리는 것

저는 지난 18개월 동안 수십 개의 "AIBOM" 제품을 평가해 왔습니다. 제가 짜증을 느끼는 순서대로 실패 유형들을 나열해 보겠습니다.

그들은 모델을 패키지(packages)처럼 취급합니다. 소프트웨어 공급망에서 SBOM 계보(lineage)가 강력한 이유는 패키지가 비교적 정적이기 때문입니다. 하지만 모델은 패키지가 아닙니다. 그것은 서비스입니다. 모델은 동작(behavior)을 가지며, 드리프트(drift)가 발생합니다. 오늘 수행하는 gpt-4o 호출은 지난 3월의 gpt-4o 호출과 동일하지 않습니다. 빌드 타임(build time)에 생성된 SBOM 스타일의 매니페스트 스냅샷은 이러한 특성을 전혀 포착하지 못합니다. 귀하에게 필요한 것은 빌드 타임의 산출물이 아니라 지속적인 탐지(continuous discovery)입니다.

그들은 로컬 및 셀프 호스팅(self-hosted) 환경을 무시합니다. 모든 벤더의 AIBOM 데모는 OpenAI와 Anthropic 키로 시작합니다. 왜냐하면 그것들이 쉽기 때문입니다 — API 청구서를 긁어오기만 하면 됩니다. 연구 엔지니어가 워크스테이션에서 실행 중인 Ollama 인스턴스나, 플랫폼 팀이 지난주에 구축한 vLLM 클러스터, 또는 고객 기능을 데모하기 위해 누군가 Mac Mini에 설치한 LM Studio에 대해 그들의 도구에 물어보십시오. 흥미로운 공격 표면(attack surface)은 셀프 호스팅 레이어에 존재합니다. 이것이 cyradar가 Ollama, vLLM, TGI, LocalAI, Triton, LM Studio, 그리고 llama.cpp를 다루는 이유입니다. 온프레미스 추론 스택(on-prem inference stack)을 건너뛰는 "AI 인벤토리"는 허구이기 때문입니다.

그들은 프롬프트(prompt)를 문서로 취급합니다. 프롬프트는 코드입니다. 프로덕션 환경의 프롬프트 템플릿(prompt templates)은 주의하지 않으면 코드 리뷰 없이도 수정될 수 있는 실행 가능한 설정(executable configuration)입니다. 프롬프트 버전, 프롬프트 소유자, 그리고 시간에 따른 프롬프트 변경 사항을 추적하지 않는 AIBOM은 전체 시스템에서 가장 빈번하게 수정되는 부분을 놓치고 있는 것입니다.

그들은 코드와 연결하지 않습니다. 귀하의 회사 내 AI는 리포지토리(repo) 내에서 인간에 의해 작성되었습니다. 그 리포지토리에는 openai.chat.completions 호출, 모델 이름에 대한 참조, 임베딩 클라이언트(embeddings clients), LangChain 그래프, 에이전트 프레임워크(agent frameworks)가 포함되어 있습니다. 만약 귀하의 AIBOM 도구가 소스 코드를 스캔하지 않는다면, 그것은 추측하고 있는 것입니다. 이것이 바로 이 지점에서 cyscan이 중요한 이유입니다 — 75개 이상의 언어에 걸친 1,815개의 규칙에는 모델 호출(model invocations), 프롬프트 인젝션 싱크(prompt injection sinks), 모델 출력의 안전하지 않은 역직렬화(unsafe deserialization), 그리고 추론 제공업체(inference providers)에 대한 하드코딩된 키를 탐지하기 위한 AI 특화 패턴이 포함되어 있습니다. AIBOM은 코드에서 시작됩니다. 그 외의 모든 것은 다운스트림(downstream)일 뿐입니다.

그들은 "거버넌스(governance)"를 "정책 문서"와 혼동합니다. 저는 주요 결과물이 감사인에게 보내는 PDF 파일인 AIBOM 도구들을 보아왔습니다. 이것은 잘못된 산출물(artifact)입니다. 올바른 산출물은 쿼리 인터페이스(query interface)입니다. vLLM에 대한 CVE가 발표되었을 때, 저는 제 AIBOM에 다음과 같이 묻고 싶습니다: "내 엔드포인트 중 영향을 받는 버전을 실행 중인 것은 무엇인가? 어떤 앱이 해당 엔드포인트를 호출하는가? 그리고 그 앱들 중 규제 대상 데이터를 처리하는 것은 무엇인가?" 만약 이 답변을 얻기 위해 사람의 개입과 수 시간이 필요하다면, 귀하의 AIBOM은 실패한 것입니다.

그들은 인벤토리(Inventory) 단계에서 멈춥니다. 이것이 가장 큰 문제입니다. 모든 벤더는 당신에게 목록을 판매합니다. 하지만 무엇이 잘못되었는지는 아무도 말해주지 않습니다. 포스처 평가 (Posture Assessment)가 없는 인벤토리는 스스로에게 숙제를 내주는 것과 같습니다. 당신에게는 다음과 같은 내용을 알려줄 수 있는 AIBOM이 필요합니다: 이 모델 엔드포인트 (Model Endpoint)에는 인증 (Auth)이 없고, 이 RAG 인덱스 (RAG Index)에는 개인정보 (PII)가 포함되어 있으며, 이 에이전트 (Agent)는 귀하의 CRM에 대한 도구 접근 권한을 가지고 있고 최근 10번의 테스트 실행 중 3번의 탈옥 (Jailbreak)이 발생했으며, 귀하의 추론 스택 (Inference Stack)에 있는 이 종속성 (Dependency)에는 알려진 RCE (원격 코드 실행) 취약점이 있다는 사실 말입니다.

실제로 작동하는 아키텍처

Cybrium에서 이를 구축하고 고객들이 이를 배포하는 것을 지켜보며 제가 정착한 모델은 다음과 같습니다. AIBOM은 문서가 아니라 그래프 (Graph)입니다. 노드 (Nodes)는 모델, 데이터셋, 엔드포인트, 앱, 프롬프트, 에이전트, 도구, 키 (Keys)입니다. 엣지 (Edges)는 데이터 흐름, 호출 (Invocations), 소유권, 종속성입니다. 그리고 이 그래프는 양식을 채우는 사람이 아니라 지속적인 스캐너 (Continuous Scanners)에 의해 채워집니다.

코드 계층 (Code Layer)에서, cyscan은 코드베이스가 모델과 통신하는 모든 지점을 찾아냅니다. 모든 openai.ChatCompletion.create, 모든 AutoModelForCausalLM.from_pretrained, 모든 LangChain 에이전트 생성자, 모든 MCP 도구 정의, Python 파일에 하드코딩된 모든 프롬프트 템플릿 (Prompt Template)을 찾아냅니다. 이를 통해 어떤 리포지토리 (Repo), 어떤 서비스, 어떤 모델 이름, 어떤 제공업체(Provider)를 사용하는지에 대한 코드 측면의 지도를 얻을 수 있습니다.

런타임 계층 (Runtime Layer)에서, cyradar는 네트워크를 훑어 노출된 추론 엔드포인트 (Inference Endpoints)를 찾아냅니다. 이 도구는 Ollama 서버가 어떻게 생겼는지, vLLM이 무엇을 노출하는지, Triton 추론 서버 (Triton Inference Server)가 무엇에 응답하는지 알고 있습니다. 이는 섀도 AI (Shadow AI)를 찾아냅니다 — 즉, 0.0.0.0에 바인딩된 모델 서버가 있는 워크스테이션이나, 지난 분기의 파인튜닝 (Fine-tune) 모델을 여전히 실행 중인 잊혀진 개발 환경 같은 것들 말입니다. 코드 스캔과 결합하면, 이제 양쪽 측면을 모두 갖게 됩니다: 즉, 코드가 통신한다고 말하는 대상과 네트워크에서 실제로 실행 중인 대상입니다. 그 차이 (Delta)가 바로 흥미로운 문제들이 존재하는 곳입니다.

애플리케이션 계층 (Application layer)에서, cyweb은 AI를 대면하는 웹 표면 (web surfaces)을 조사합니다. LLM 통합 앱을 위해 구축된 22가지 퍼징 (fuzz) 카테고리: 프롬프트 인젝션 (prompt injection), 검색된 콘텐츠를 통한 간접 인젝션 (indirect injection), 도구 오용 (tool abuse), 함수 호출을 통한 데이터 유출 (data exfiltration), 탈옥 (jailbreaks) 등이 포함됩니다. 그리고 상위 커뮤니티의 퍼징 코퍼스 (fuzz corpora) 대비 95%의 템플릿 변환율은 여러분이 작년의 속임수가 아닌, 현재의 최첨단 기술 (state of the art)을 대상으로 테스트하고 있음을 의미합니다.

통합 계층 (Integration layer)에서는, MCP 서버 (10개의 도구)를 통해 기존의 에이전트들 — 즉, 사고 대응 봇 (incident response bots), GRC 코파일럿 (GRC copilots), 엔지니어링 어시스턴트 (engineering assistants) — 가 자연어로 AIBOM에 질의할 수 있습니다. "지난 30일 동안 사용된 모든 프로덕션 모델을 보여줘." "우리의 RAG 인덱스 중 고객 기밀로 분류된 데이터를 포함하고 있는 것은 무엇인가?" "인증이 없는 엔드포인트는 무엇인가?" 이처럼 AIBOM은 읽는 대상이 아니라, 대화하는 대상이 됩니다.

출력물은 단순한 JSON 파일이 아닙니다. 그것은 질의하고, 알람을 설정하고, 시간에 따라 차이(diff)를 비교할 수 있으며, 감사인에게 라이브 뷰 (live view)로 전달할 수 있는 그래프 (graph)입니다. 서빙 프레임워크 (serving framework)에 대한 새로운 CVE가 발표되면, 폭발 반경 (blast radius)이 이미 계산된 알림을 받게 됩니다. 개발자가 새로운 모델을 인스턴스화하는 코드를 머지(merge)하면, 배포가 프로덕션에 반영되기 전에 AIBOM이 업데이트됩니다. 누군가 승인되지 않은 Ollama 인스턴스를 실행하면, 스캔 주기 내에 이를 확인할 수 있습니다.

왜 특히 이를 위한 단일 플랫폼이 필요한가

저는 "최고의 제품들(best-of-breed)"을 조합해야 한다는 논리를 이해합니다. 저 또한 다른 카테고리에서는 그렇게 해왔습니다. 하지만 AIBOM은 근본적으로 통합의 문제이며, 별개의 보안 도구 간의 통합은 인벤토리 (inventory)가 사장되는 곳입니다.

만약 코드 스캐너 (code scanner)가 한 벤더이고, 런타임 탐지 (runtime discovery)가 다른 벤더이며, 웹 앱 테스트 (web app testing)가 세 번째, 거버넌스 계층 (governance layer)이 네 번째라면, 당신의 AIBOM은 카프카 토픽 (Kafka topic)과 막연한 희망 사항에 불과할 것입니다. 모든 경계선(seam)은 모델이 유실되는 지점입니다. vLLM 인스턴스는 런타임 도구에는 나타나지만, 이를 배포하는 리포지토리 (repo)와 상관관계가 형성되지 않습니다. 웹 스캐너에서 발견된 프롬프트 인젝션 (prompt injection) 결과는 거버넌스 그래프 (governance graph) 내의 모델 노드에 연결되지 않습니다. 서빙 프레임워크 (serving framework)의 CVE는 이를 의존하는 앱들로 전파되지 않습니다.

우리가 cyscan, cyradar, cyweb, 그리고 MCP 계층을 하나의 플랫폼으로 구축한 이유는 이들이 모두 동일한 그래프에 기록하기 때문입니다. cyradar에 의해 발견된 모델은 cyscan에 의해 발견된 해당 리포지토리와 자동으로 연결됩니다. cyweb에서 발견된 프롬프트 인젝션 결과는 실패한 특정 엔드포인트 (endpoint)에 연결되고, 이는 해당 엔드포인트를 소유한 앱에 연결되며, 최종적으로 이를 배포하는 팀에 연결됩니다. AIBOM은 야간 ETL 작업이 아니라, 이러한 상관관계 (correlation)를 통해 자연스럽게 도출됩니다.

제가 반드시 우리 제품을 사야 한다고 말하는 것이 아닙니다. 다만 6개의 벤더와 데이터 웨어하우스 (warehouse)를 조합하여 AIBOM을 구성한다면, 제 친구가 금요일 마감 기한을 맞추기 위해 9일 동안 답변을 찾아 헤매게 만들었던 바로 그 시스템을 구축하게 될 것이라는 점을 말씀드리는 것입니다.

재구성 (The recomposition)

이 모든 현상의 밑바탕에 깔린 더 큰 변화는 다음과 같습니다. 2022년에 유효했던 보안 스택은 2026년의 공격 표면 (attack surface)을 설명하지 못합니다. 우리는 지난 10년 동안 서버, 컨테이너, 서버리스 함수 (serverless functions), 그리고 패키지 (packages)의 인벤토리를 구축하기 위한 도구들을 만들어 왔습니다. 각 세대는 하나의 재구성 (recomposition)이었으며, 각 세대는 이전 세대의 일부 벤더들을 퇴출시켰습니다.