S-Bom – Software Bill of Materials (EBOM, MBOM 차이점)

SBOM이라는 말을 처음 들으면 BOM이니까 제조업 부품표 같은 건가 싶고, 조금 찾아보면 또 소프트웨어 보안 이야기로 넘어가서 더 헷갈립니다. 실제로 많이 헷갈리는 이유가 있습니다. 제조업에서 말하는 BOM과 소프트웨어에서 말하는 SBOM이 이름은 비슷하지만, 쓰는 목적과 보는 사람이 다르기 때문입니다.

특히 실무에서는 SBOM을 Software Bill of Materials로 쓰기도 하고, 어떤 문서에서는 Sales BOM을 줄여서 SBOM이라고 쓰기도 합니다. 그래서 자료를 보다 보면 분명 같은 약자인데 설명은 전혀 다르게 나와 혼란이 생깁니다.

SBOM이 갑자기 더 중요해진 이유

예전에는 소프트웨어를 한 회사가 거의 다 직접 만드는 것처럼 보였지만, 지금은 다릅니다.

오픈소스 라이브러리, 서드파티 패키지, 클라우드 서비스, 외부 모듈이 너무 많이 섞여 있습니다. 그래서 제품 하나를 만들더라도 안에 어떤 구성요소가 들어갔는지 모르면, 나중에 취약점이 터졌을 때 어디부터 점검해야 할지조차 모르게 됩니다.

바로 여기서 SBOM이 필요해집니다. 쉽게 말해 소프트웨어의 성분표 같은 역할입니다. 어떤 구성요소가 들어갔는지, 버전은 무엇인지, 어떤 의존관계를 갖는지, 라이선스는 어떤지 한 번에 보는 목록이라고 생각하면 이해가 쉽습니다.

BOM은 원래 제조에서 시작된 개념입니다

BOM이라는 말 자체는 원래 제조에서 훨씬 익숙합니다. 제품 하나를 만들기 위해 필요한 하위 부품, 원재료, 조립품, 수량, 조립 순서를 정리한 목록이 기본적인 BOM입니다.

그래서 제조업에서는 BOM이 틀리면 생산 자체가 꼬이고, 불필요한 발주나 원가 상승으로 바로 이어집니다.

이 감각으로 보면 소프트웨어 SBOM도 훨씬 쉬워집니다. 하드웨어 제품의 부품표가 제조를 위해 필요하듯, 소프트웨어 제품도 어떤 패키지와 라이브러리로 구성됐는지 보이는 목록이 있어야 운영과 보안이 쉬워집니다.

Software SBOM은 정확히 무엇인가

Software SBOM은 소프트웨어를 이루는 구성 요소와 공급망 관계를 기록한 목록입니다.

그냥 라이브러리 이름만 적어놓은 문서가 아니라, 어떤 구성 요소가 어떤 버전으로 들어갔고, 누구 것이고, 어떤 관계로 연결되어 있는지를 기계가 읽을 수 있는 형태로 정리한 데이터에 더 가깝습니다.

그래서 SBOM은 단순 문서가 아니라 배포 후에도 계속 써먹는 정보입니다. 취약점 점검, 라이선스 검토, 공급망 보안 대응, 감사 대응, 고객사 제출 자료, 제품 인수인계까지 생각보다 쓰임새가 넓습니다.

가장 많이 헷갈리는 지점, Sales BOM과 Software SBOM

실무 문서를 보다 보면 여기서 많이 꼬입니다.

제조·ERP 문맥에서는 Sales BOM을 SBOM으로 줄여 쓰는 경우가 있고, 보안·소프트웨어 문맥에서는 Software Bill of Materials를 SBOM이라고 씁니다. 약자가 같아서 생기는 혼선입니다.

그래서 문서를 쓸 때는 가능하면 처음에 아예 풀어 쓰는 편이 좋습니다.

특히 협업 부서가 설계, 구매, 생산, IT, 보안까지 섞여 있다면 더 그렇습니다. SBOM이라고만 적으면 제조팀은 판매 BOM으로 이해하고, 보안팀은 Software SBOM으로 받아들이는 일이 실제로 생깁니다.

용어	의미	주로 쓰는 부서	핵심 목적
Software SBOM	소프트웨어 구성요소 목록	개발, 보안, DevOps, IT 운영	취약점, 라이선스, 공급망 추적
Sales BOM	판매 기준 품목 구성	영업, ERP, 생산관리	판매 품목 구성 관리
EBOM	설계 기준 BOM	설계, 개발, 엔지니어링	제품 구조와 설계 부품 관리
MBOM	제조 기준 BOM	생산, 구매, 제조기술	실제 생산과 조립 순서 관리

EBOM, MBOM, Software SBOM은 어떻게 다를까

EBOM은 설계자가 보는 기준이고, MBOM은 생산 현장에서 실제로 조립하고 발주하는 기준입니다.

반면 Software SBOM은 소프트웨어를 구성하는 패키지와 의존성을 기준으로 봅니다. 그러니까 셋 다 BOM이지만, 보는 시점과 쓰는 목적이 다릅니다.

제품이 하드웨어와 소프트웨어를 함께 포함하는 경우라면 이 차이를 더 잘 이해해야 합니다.

예를 들어 스마트 기기나 산업장비처럼 펌웨어와 앱, 클라우드 연동이 들어가는 제품은 EBOM, MBOM만 관리해서는 부족합니다. 이제는 Software SBOM까지 같이 봐야 전체 구성이 보입니다.

Software SBOM에는 어떤 정보가 들어가나

실무에서 SBOM이 가치 있으려면 단순히 패키지 이름만 적혀 있어서는 안 됩니다. 최소한 누가 만든 것인지, 어떤 버전인지, 어떤 구성요소에 의존하는지, 언제 생성된 문서인지 정도는 보여야 나중에 검색과 대응이 쉬워집니다.

• 공급자 또는 작성 주체
• 구성요소 이름
• 버전 정보
• 고유 식별자
• 의존 관계
• 생성 시점과 작성 도구
• 라이선스 관련 정보
• 필요 시 취약점, 서비스, 외부 API 정보

이렇게 정리된 SBOM이 있으면, 나중에 특정 오픈소스 취약점이 공개됐을 때 “우리 제품 안에 그 버전이 들어갔는지”를 훨씬 빨리 찾을 수 있습니다. 제품이 커질수록 이 차이는 생각보다 크게 느껴집니다.

SPDX와 CycloneDX는 왜 자주 같이 나오나

SBOM을 조금만 찾아보면 SPDX와 CycloneDX가 자주 같이 나옵니다.

둘 다 SBOM을 표현하는 대표 표준이라서 그렇습니다. 쉽게 말해 “SBOM을 어떤 형식으로 만들고 주고받을 것인가”에 대한 대표적인 선택지입니다.

SPDX는 오랫동안 라이선스와 소프트웨어 구성 정보 쪽에서 강하게 자리 잡아온 표준이고, CycloneDX는 보안과 공급망 추적, 확장성 측면에서 자주 언급됩니다.

어느 하나가 무조건 정답이라기보다, 기존 도구와 고객 요구, 보안팀 요구사항에 따라 선택하는 경우가 많습니다.

항목	SPDX	CycloneDX
성격	국제 표준 기반의 SBOM 표현 형식	공급망 보안 중심의 확장성 높은 표현 형식
강점	라이선스와 구성 정보 관리	보안, 의존성, 서비스, 취약점 확장
실무 활용	오픈소스 관리, 컴플라이언스	보안 점검, 공급망 추적, DevSecOps

누가 Software SBOM을 꼭 챙겨야 할까

SBOM은 대기업 보안팀만 보는 자료라고 생각하기 쉽지만, 실제로는 범위가 더 넓습니다.

소프트웨어를 고객사에 납품하는 회사, 산업장비에 펌웨어를 넣는 제조사, 외부 라이브러리를 많이 쓰는 스타트업, SaaS를 운영하는 팀까지 전부 관련이 있습니다.

• 오픈소스와 서드파티 패키지를 많이 쓰는 개발팀
• 고객사 보안 요구사항을 자주 받는 B2B 기업
• 하드웨어와 소프트웨어가 함께 들어가는 제조업체
• 감사, 규제, 인증 대응이 필요한 조직
• 취약점 공지 후 영향 범위를 빨리 찾고 싶은 운영팀

특히 제조업은 EBOM, MBOM만 잘 관리하면 된다고 보기 쉬운데, 지금은 제품 안에 들어가는 펌웨어, 앱, 외부 라이브러리, 클라우드 API까지 같이 보지 않으면 전체 구성이 보이지 않습니다. 그래서 전자제품, 반도체 장비, 자동차 전장, 스마트 디바이스 쪽에서는 Software SBOM 개념이 더 중요해지고 있습니다.

실무에서 SBOM이 진짜 도움이 되는 순간

SBOM의 가치는 평소보다 문제가 생겼을 때 더 크게 느껴집니다.

예를 들어 특정 오픈소스 취약점이 크게 터졌다고 해보겠습니다. SBOM이 없으면 우리 제품, 사내 서비스, 납품 소프트웨어에 그 라이브러리가 어디 들어갔는지부터 찾느라 시간이 많이 듭니다. 반면 SBOM이 잘 정리돼 있으면 영향 범위를 훨씬 빨리 좁힐 수 있습니다.

또 담당자 교체 상황에서도 차이가 큽니다. 기존 담당자가 떠나도 어떤 패키지가 왜 들어갔는지, 어떤 버전을 기준으로 배포했는지, 외부 의존성이 무엇인지 문서로 남아 있으면 인수인계가 훨씬 수월합니다.

제조 BOM을 관리하는 이유와 꽤 닮아 있습니다.

정리

SBOM이 어렵게 느껴지는 가장 큰 이유는 약자가 겹치기 때문입니다. 제조 문서에서는 Sales BOM을 SBOM이라고 부르기도 하고, 보안과 개발 문서에서는 Software Bill of Materials를 SBOM이라고 부릅니다. 그래서 문서를 볼 때는 먼저 어떤 SBOM을 말하는지부터 구분해야 합니다.

지금 기준에서 더 중요해진 건 Software SBOM입니다. 소프트웨어 안에 어떤 구성요소가 들어갔는지, 어떤 버전을 쓰는지, 어떤 의존관계를 갖는지 보이는 목록이 있어야 취약점 대응도 빠르고, 공급망 관리도 쉬워집니다.

특히 하드웨어와 소프트웨어가 함께 묶인 제품을 다루는 조직이라면, EBOM과 MBOM만큼이나 Software SBOM도 같이 봐야 전체 그림이 잡힙니다.

관련해서 같이 보면 이해가 쉬운 글도 있습니다. BOM 리스트 – Bill Of Material vs Part List 차이점, 도면 E-BOM vs M-BOM 차이점 및 특징도 같이 보면 훨씬 정리가 잘 됩니다.