모든 산업은 결국
'성분표'를 요구받는다
BOM의 유래와 X-BOM의 미래

BOM의 유래 — 제조업의 자재명세서에서 식품 성분표까지

BOM(Bill of Materials, 자재명세서)은 원래 제조업 용어입니다. 하나의 완제품을 만들기 위해 필요한 모든 부품·원자재·수량·조립 관계를 계층적으로 정리한 목록으로, 1960~70년대 MRP(자재소요계획) 시스템의 핵심 데이터로 자리 잡으며 산업 표준 개념이 되었습니다. "무엇으로 만들어졌는지 알아야 관리할 수 있다"는 BOM의 철학은 이후 여러 산업으로 확장됩니다.

그중 가장 극적인 사례가 식품 산업입니다. 성분 공개는 자발적으로 이뤄지지 않았습니다. 대형 사고가 규제를 낳고, 규제가 표준을 낳는 패턴이 반복됐습니다.

SBOM의 등장과 현황 — 사고가 만든 규제, 규제가 만든 표준

소프트웨어 자재명세서(SBOM) 개념 자체는 2010년대부터 존재했지만(SPDX 프로젝트 2010년 시작, CycloneDX 2017년 시작), 이를 산업 전체의 의무로 끌어올린 것은 연쇄적인 공급망 보안 사고였습니다.

BOM은 실제로 어떻게 생겼나 — 구성형태 표시 사례

SBOM은 사람이 읽는 문서가 아니라 기계가 읽는 데이터입니다. 같은 컴포넌트(예: Log4Shell의 주인공이었던 log4j-core)를 양대 표준이 어떻게 표기하는지 나란히 보면 구조가 한눈에 들어옵니다. 두 형식 모두 「누가 만든, 무슨 이름의, 몇 버전 컴포넌트인가」 + 「고유 식별자」 + 「의존 관계」라는 동일한 뼈대를 갖습니다.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "metadata": {
    "timestamp": "2026-07-11T09:00:00Z",
    "authors": [{ "name": "Labrador SCA" }]
  },
  "components": [{
    "type": "library",
    "supplier": { "name": "Apache" },
    "name": "log4j-core",
    "version": "2.17.1",
    "purl": "pkg:maven/org.apache.logging
           .log4j/log4j-core@2.17.1",
    "licenses": [{ "license":
      { "id": "Apache-2.0" } }]
  }],
  "dependencies": [{
    "ref": "my-app",
    "dependsOn": ["log4j-core@2.17.1"]
  }]
}

# 문서 정보 (SBOM 자체의 메타데이터)
SPDXVersion: SPDX-2.3
Creator: Tool: Labrador-SCA
Created: 2026-07-11T09:00:00Z

# 컴포넌트(패키지) 정보
PackageName: log4j-core
SPDXID: SPDXRef-log4j-core
PackageVersion: 2.17.1
PackageSupplier: Organization: Apache
ExternalRef: PACKAGE-MANAGER purl
  pkg:maven/org.apache.logging
  .log4j/log4j-core@2.17.1
PackageLicenseDeclared: Apache-2.0

# 의존 관계
Relationship: SPDXRef-my-app
  DEPENDS_ON SPDXRef-log4j-core

※ 학습용으로 단순화한 예시입니다. 실무 SBOM은 수백~수천 개 컴포넌트와 해시(무결성 검증값), 계층적 의존 트리를 포함합니다. 두 형식의 공통 열쇠는 PURL(Package URL) 같은 고유 식별자 — 이 식별자가 있어야 새 CVE가 공개됐을 때 "우리 제품에 해당 컴포넌트가 있는가"를 기계적으로 대조할 수 있습니다.

식품 성분표 vs SBOM — 한 장 비교

X-BOM으로의 확장 — 소프트웨어를 넘어 전체 디지털 공급망으로

투명성 요구는 소프트웨어 코드에서 멈추지 않습니다. 하드웨어, AI 모델, 암호 자산, 클라우드 서비스까지 — 시스템을 구성하는 모든 층위에 성분표를 요구하는 흐름이 X-BOM(eXtended BOM)입니다. CycloneDX는 하나의 표준 생태계 안에서 여러 BOM 유형을 정의하고 상호 참조할 수 있게 설계되어 있습니다.

규제도 X-BOM으로 이동 중

인도 CERT-In은 2025년 7월 SBOM뿐 아니라 QBOM·CBOM·AIBOM·HBOM까지 아우르는 기술 가이드라인 v2.0을 발표했습니다. 아직 권고 수준이지만, "SBOM 단일 문서"에서 "계층별 BOM 체계"로 규제의 프레임 자체가 이동하고 있음을 보여주는 신호입니다. 식품 표시가 영양성분 → 알레르기 → 원산지로 확대된 것과 동일한 경로입니다.

AI-BOM 심화 — AI 시스템의 성분표는 무엇을 담아야 하는가

AI 시스템도 소프트웨어입니다. 따라서 기존 SBOM이 그대로 필요하지만, 그것만으로는 부족합니다. AI 특유의 리스크는 코드 의존성 밖에서 옵니다 — 사전학습 모델의 출처, 학습 데이터의 계보와 라이선스, 파인튜닝 이력, 모델이 처리하는 데이터의 민감도. 예컨대 Hugging Face에서 내려받은 모델 가중치는 오픈소스 라이브러리와 똑같은 '외부 공급 컴포넌트'이지만, 전통적 SBOM에는 잡히지 않습니다. AI-BOM은 이 사각지대를 성분표의 영역으로 끌어들입니다.

기준 문서: G7 「SBOM for AI — 최소 요소」 (2026.5)

2026년 5월, 독일 BSI·미국 CISA·프랑스 ANSSI·영국 NCSC·일본·캐나다·이탈리아의 사이버보안 당국이 EU 집행위와 함께 AI용 SBOM 최소 요소 가이드를 공동 발간했습니다. 아직 자발적 권고이지만 G7 전문가 합의 문서로서, 일반 SBOM의 EO 14028/NTIA 최소 요소에 해당하는 AI 분야의 공통 기준점이 될 문서입니다. 핵심 구조는 아래 7개 클러스터입니다. 메타데이터를 제외한 나머지 여섯은 우열 없이 동등하게 중요합니다.

표준 형식에서는 어떻게 표기하나

CycloneDX는 컴포넌트 타입 machine-learning-model과 modelCard 구조로 ML-BOM을 지원하고, SPDX는 3.0부터 AI·Dataset 프로파일을 제공합니다. 아래는 CycloneDX ML-BOM의 축약 예시입니다.

{
  "components": [{
    "type": "machine-learning-model",   // 라이브러리가 아닌 '모델' 타입
    "name": "support-intent-classifier",
    "version": "3.2.0",
    "licenses": [{ "license": { "id": "Apache-2.0" } }],
    "modelCard": {
      "modelParameters": {
        "task": "text-classification",
        "architectureFamily": "transformer",
        "datasets": [{ "ref": "dataset-cs-tickets-2025" }]  // 학습 데이터 계보
      },
      "quantitativeAnalysis": {
        "performanceMetrics": [{ "type": "F1", "value": "0.94" }]  // KPI
      },
      "considerations": {
        "ethicalConsiderations": [{ "name": "고객 대화 데이터 포함 — 민감도 관리 필요" }]
      }
    }
  }]
}

※ 모델을 여느 컴포넌트처럼 name·version·license로 식별하되, modelCard로 학습 데이터 참조·성능 지표·고려사항까지 확장하는 구조입니다. "데이터셋도 참조 가능한 자산"이라는 점이 일반 SBOM과의 결정적 차이입니다.

규제와의 연결 — 왜 지금 준비해야 하나

G7 가이드의 요구 정보는 EU AI Act가 고위험 AI 시스템 제공자에게 요구하는 기술문서(11·13조, 부속서 IV)와 상당 부분 겹칩니다. 즉 AI-BOM을 갖추는 것이 곧 AI Act 문서화 의무 대응의 상당 부분을 커버합니다. 인도 CERT-In 가이드라인 v2.0에도 AIBOM이 포함되어 있고, 기업 고객의 벤더 실사에서도 "모델 계보와 데이터 출처를 문서로 제시할 수 있는가"가 AI 공급사의 성숙도를 가르는 필터로 쓰이기 시작했습니다. SBOM이 걸어온 「사고 → 규제 → 표준 → 기본값」의 경로를, AI-BOM은 사고를 기다리지 않고 선제적으로 걷고 있는 셈입니다.

OBOM 심화 — 배포된 제품이 아니라, 지금 돌아가는 환경의 성분표

SBOM이 "이 제품은 무엇으로 만들어졌는가"(빌드 시점)에 답한다면, OBOM(Operations Bill of Materials)은 "이 운영 환경에서 지금 실제로 무엇이 돌아가고 있는가"(운영 시점)에 답합니다. 비유하자면 SBOM이 제품의 설계도·성분표라면, OBOM은 현장의 재고 실사 대장입니다.

둘의 간극이 실제 사고에서 문제가 됩니다. Log4Shell 당시 진짜 질문은 "우리가 만든 제품에 Log4j가 들어있는가"만이 아니라 "지금 운영 중인 수백 대 서버 중 어디에서 취약한 버전이 돌고 있는가"였습니다. 애플리케이션 SBOM에는 잡히지 않는 OS 패키지, 미들웨어(WAS·DB), 컨테이너 베이스 이미지, 에이전트류가 실제 공격면의 큰 부분을 차지하고, 운영 중 패치·수동 설치로 빌드 시점 구성과 달라지는 형상 드리프트도 누적됩니다. OBOM은 이 운영 계층 전체를 기계가 읽을 수 있는 인벤토리로 만듭니다.

SBOM vs OBOM — 무엇이 다른가

※ 대체 관계가 아니라 상호 참조 관계입니다. 운영 환경(OBOM)에 배포된 각 애플리케이션이 자신의 SBOM을 갖고, OBOM이 이를 링크하는 구조가 이상적입니다 — AI-BOM의 인프라 클러스터가 HBOM을 링크하는 것과 같은 X-BOM 상호참조 패턴입니다.

CISA vs OWASP — 같은 문제, 다른 분류 축

OBOM을 정확히 이해하려면 두 진영이 이 개념을 다른 축으로 자르고 있다는 점을 알아야 합니다. 미국 CISA는 「SBOM 문서 유형(Types of SBOM Documents)」에서 SBOM을 생명주기 단계로 6분류하고, OWASP CycloneDX는 기술 대상(무엇의 성분표인가)으로 BOM 문서 유형을 나눕니다.

표시 사례 — CycloneDX OBOM

CycloneDX는 별도 형식을 만들지 않고, 동일한 표준 안에서 운영 환경을 주어로 삼는 방식으로 OBOM을 표현합니다. 문서의 주체(metadata.component)를 제품이 아닌 운영 플랫폼으로 두고, 그 아래에 OS·컨테이너·애플리케이션·라이브러리를 컴포넌트 타입으로 계층화합니다.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "metadata": {
    "timestamp": "2026-07-11T09:00:00Z",
    "component": {                          // 이 문서의 주어 = 운영 환경
      "type": "platform",
      "name": "prod-web-01",               // 운영 서버(호스트) 식별
      "version": "2026.07-baseline"
    }
  },
  "components": [
    { "type": "operating-system",          // ① OS 계층
      "name": "ubuntu", "version": "22.04.4" },

    { "type": "library",                   // ② OS 패키지 — 앱 SBOM엔 없는 계층
      "name": "openssl", "version": "3.0.13",
      "purl": "pkg:deb/ubuntu/openssl@3.0.13" },

    { "type": "container",                 // ③ 컨테이너 베이스 이미지
      "name": "nginx", "version": "1.25-alpine" },

    { "type": "application",               // ④ 배포된 자사/타사 앱
      "name": "order-api", "version": "4.1.2",
      "externalReferences": [{
        "type": "bom",                     // ⑤ 이 앱의 SBOM을 링크 (상호참조)
        "url": "https://boms.example/order-api-4.1.2.cdx.json"
      }] }
  ],
  "services": [
    { "name": "payment-gateway",           // ⑥ 연결된 외부 서비스
      "endpoints": ["https://pay.example.com"] }
  ]
}

※ 학습용 축약 예시. 실무에서는 서버당 수백~수천 개의 OS 패키지가 나열되며, 해시·설치 경로·구성값이 함께 기록됩니다. OpenSSL에 새 CVE가 공개되면 이 인벤토리를 대조해 "prod-web-01이 노출됨"을 즉시 판정할 수 있습니다 — 이것이 OBOM의 존재 이유입니다.

활용 시나리오 4가지

① 신규 CVE 노출 판정 — 취약점 공개 시 "어느 운영 시스템이 영향권인가"를 인벤토리 대조로 즉답. ② 사고 대응 — 침해 조사 시 해당 시점 환경 구성을 근거 자료로 제시. ③ 자산·EOL 관리 — 지원 종료된 OS·미들웨어가 어디에 남아있는지 추적. ④ 형상 드리프트 감시 — 승인된 기준선(baseline)과 현재 상태의 차이를 지속 비교. 넷 모두 공통 전제는 운영 환경 인벤토리의 지속적 수집입니다 — 한 번 만들고 끝나는 문서가 아니라 살아있는 데이터여야 합니다.

전략적 시사점 — 성분표는 비용이 아니라 차별화 장벽

식품 산업의 역사가 주는 교훈은 명확합니다. 성분 공개를 '규제 대응 비용'으로만 취급한 기업은 뒤처졌고, 투명성을 신뢰의 증거로 전환한 기업이 시장을 얻었습니다. SBOM도 같습니다. 조달 심사·고객 실사에서 "정확한 SBOM을 즉시 제출할 수 있는가"는 이미 공급사 선별 기준이 되고 있습니다.

래브라도랩스 관점: 왜 SCA가 X-BOM 시대의 기반 기술인가

모든 BOM의 품질은 결국 "성분을 얼마나 정확히 식별했는가"에서 결정됩니다. 부정확한 성분표는 없는 것보다 위험합니다. 래브라도랩스의 SCA는 이 식별 단계를 특허 기술로 뒷받침합니다.

고객 대화에서 쓸 수 있는 3문장 요약

① "식품에 영양성분표가 있듯, 소프트웨어에도 성분표(SBOM)를 요구하는 시대입니다 — 2027년이면 국내 공공부문도 의무화됩니다." ② "SBOM의 가치는 문서가 아니라 정확도에서 나옵니다 — 성분을 잘못 적은 성분표는 오히려 리스크입니다." ③ "지금 SBOM을 갖추는 것은 규제 대응을 넘어, AI-BOM·CBOM으로 확장될 X-BOM 시대의 선행 투자입니다."

학습 점검