R&D 소프트웨어 SBOM 오픈소스 라이선스 체크리스트: 상용화 전 구성명세와 의무 증거를 정리하는 법

소프트웨어가 들어간 R&D 과제는 시제품이 실행되는 순간부터 증거의 성격이 달라집니다. 최종보고서에는 성능 수치와 개발 결과가 들어가지만, 제품팀이 실제로 납품하거나 상용화하려면 "이 소프트웨어 안에 무엇이 들어 있는가", "그 구성요소를 어떤 라이선스 조건으로 썼는가", "알려진 취약점과 업데이트 판단은 어떻게 남겼는가", "고객이나 파트너에게 어디까지 공개할 것인가"를 따로 설명할 수 있어야 합니다. 이 글은 보안 인증 절차나 AI 데이터 권리 검토를 다시 설명하지 않습니다. R&D 소프트웨어 SBOM 오픈소스 라이선스 체크리스트를 제출 직전의 증거 폴더로 바꾸는 방법만 다룹니다.

빠른 결론

SBOM은 개발자가 설치한 패키지 목록이 아니라 릴리스 후보에 포함된 소프트웨어 구성명세입니다. 상용화 전에는 SBOM 파일, 라이선스 고지와 원문, 자동 검출 라이선스와 최종 판단 라이선스의 차이, 알려진 취약점과 업데이트 판단 로그, 파트너 공개본과 내부 보관본의 차이를 같은 폴더 안에서 추적해야 합니다. SBOM 제출이나 라이선스 검증만으로 분쟁, 인증, 조달, 검색 순위가 보장되지는 않습니다. 다만 이 증거가 없으면 제품팀은 "무엇을 공급했는지"와 "무엇을 공개해도 되는지"를 뒤늦게 기억에 의존하게 됩니다.

SBOM은 개발 패키지 목록이 아니라 R&D 소프트웨어 릴리스 증거입니다

R&D 팀이 흔히 만드는 첫 번째 목록은 package.json, requirements.txt, pom.xml, 컨테이너 이미지 목록입니다. 이 파일들은 출발점으로는 유용하지만 곧바로 SBOM이라고 보기 어렵습니다. 연구자가 개발 중에 설치한 패키지와, 과제 종료 시점에 시제품이나 데모 서버, 납품 바이너리, 모바일 앱, 펌웨어, SaaS 배포본에 실제로 포함된 구성요소는 다를 수 있습니다. NTIA의 SBOM 최소 요소 보고서는 SBOM을 소프트웨어를 만드는 데 사용된 구성요소와 공급망 관계를 담는 공식 기록으로 설명하며, 데이터 필드, 자동화 지원, 관행과 프로세스를 함께 봅니다[S1]. 그래서 R&D 소프트웨어 SBOM 오픈소스 라이선스 체크리스트의 첫 칸은 "무슨 패키지를 썼는가"가 아니라 "어떤 릴리스 후보를 설명하는가"여야 합니다.

릴리스 후보를 먼저 고정하면 불필요한 논쟁이 줄어듭니다. 내부 실험용 브랜치, 과제 시연용 웹앱, 고객 PoC용 설치 파일, 최종 상용 제품 후보가 같은 저장소에서 나왔더라도 SBOM은 각각 달라질 수 있습니다. 개발 의존성은 시연 서버에는 없지만 빌드 산출물에는 흔적을 남길 수 있고, 테스트 전용 라이브러리는 고객 제공본에 포함되지 않을 수 있습니다. 반대로 Docker 베이스 이미지, OS 패키지, 프런트엔드 번들에 들어간 전이 의존성은 개발자가 직접 import하지 않았더라도 릴리스에는 포함될 수 있습니다.

SBOM을 릴리스 증거로 다루려면 파일명부터 정해야 합니다. 예를 들어 sbom-product-a-v0.9.3-2026-07-03.cdx.json, sbom-product-a-v0.9.3.spdx.json처럼 제품명, 버전, 생성일, 형식을 넣습니다. 같은 날 두 번 만들었다면 빌드 번호나 커밋 해시를 덧붙입니다. "최신본"이나 "최종"이라는 파일명은 금방 무너집니다. 나중에 고객이 보낸 문의가 7월 3일 데모본인지 7월 10일 패치본인지 모르면, 라이선스 의무와 취약점 조치 기록도 함께 흔들립니다.

이 지점은 R&D 보안·컴플라이언스 체크리스트와 다릅니다. 보안 글이 접근권한, 저장소, 반출 통제를 본다면 이 글은 공급한 소프트웨어 안의 구성요소와 라이선스 의무를 봅니다. 보안 저장소가 닫혀 있어도 SBOM이 부정확할 수 있고, SBOM이 정확해도 접근권한 통제가 약할 수 있습니다. 두 문서는 서로 대체 관계가 아니라 증거 위치가 다른 문서입니다.

SBOM 필드는 컴포넌트 이름보다 관계와 생성 시각을 먼저 봅니다

SBOM에는 라이브러리 이름만 들어가면 부족합니다. 최소한 공급자, 구성요소 이름, 버전, 고유 식별자, 의존 관계, SBOM 작성자, 생성 시각을 추적해야 합니다[S1]. CISA의 2025년 SBOM 최소 요소 공고도 2021년 이후 SBOM 도구가 단순 생성에서 공유, 분석, 관리까지 확장되었다는 점을 설명합니다[S2]. 즉 "파일 하나 생성"보다 "파일을 해석하고 갱신하고 전달하는 방식"이 중요해졌습니다.

<table>

<thead>

</thead>

<tbody>

<tr><td>구성요소 식별</td><td>패키지명, 버전, 공급자, purl 또는 SPDX 식별자</td><td>동명이인 패키지나 포크 프로젝트를 구분하지 못합니다.</td></tr>

<tr><td>의존 관계</td><td>직접 의존성과 전이 의존성 구분</td><td>취약점이나 라이선스 의무가 어디서 유입됐는지 추적하기 어렵습니다.</td></tr>

<tr><td>생성 도구와 작성자</td><td>도구명, 도구 버전, 실행자, 실행 명령 또는 CI 작업 링크</td><td>나중에 같은 결과를 재현하거나 오류를 수정하기 어렵습니다.</td></tr>

</tbody>

</table>

SPDX와 CycloneDX는 이 필드를 기계가 읽을 수 있는 형식으로 표현하는 대표적인 선택지입니다. SPDX는 국제 표준으로 SBOM과 여러 참조 정보를 표현할 수 있다고 설명되고[S3], SPDX License List는 표준 식별자, 라이선스 전문, 영구 URL을 제공합니다[S3]. CycloneDX는 구성요소, 서비스, 직접·전이 의존성, 취약점, 인용 정보까지 표현할 수 있는 구조를 갖고 있습니다[S5]. 어느 형식을 쓰든 중요한 것은 형식 이름이 아니라 릴리스 후보와 판단 로그가 연결되어 있는지입니다.

작은 팀이라도 처음부터 완벽한 자동화를 만들 필요는 없습니다. 다만 두 가지는 미루지 않는 편이 좋습니다. 첫째, SBOM 생성 명령이나 CI 작업을 기록합니다. 사람이 수동으로 파일을 만들었다면 어떤 도구를 어떤 옵션으로 실행했는지 적습니다. 둘째, known unknowns, 즉 아직 모르는 항목을 따로 표시합니다. 버전을 확인하지 못한 바이너리, 출처가 불명확한 예제 코드, 외주사가 제공한 모듈, 장비 제조사가 준 SDK처럼 불확실한 구성요소를 빈칸으로 두면 나중에 "문제 없음"으로 오해됩니다. 모르는 것은 모른다고 적어야 다음 검토가 가능합니다.

오픈소스 라이선스 의무는 라이선스 이름이 아니라 배포 조건으로 적습니다

오픈소스 라이선스 검토에서 가장 위험한 문장은 "MIT라서 괜찮다", "Apache라서 괜찮다", "GPL은 안 썼다"처럼 짧은 결론입니다. 제품팀에는 결론보다 근거가 필요합니다. 어떤 파일에서 어떤 라이선스 문구가 검출됐는지, 패키지 메타데이터와 실제 LICENSE 파일이 일치하는지, 수정한 코드가 있는지, 고객에게 바이너리만 주는지, SaaS로만 제공하는지, 소스 공개나 고지 제공 의무가 생기는지, 고지 파일을 어디에 넣을지를 확인해야 합니다. ISO/IEC 5230은 오픈소스가 포함된 소프트웨어 솔루션을 교환하는 조직 간 신뢰를 위해 품질 있는 오픈소스 라이선스 준수 프로그램의 요건을 제시합니다[S6].

SPDX 3.0.1 Licensing Profile은 선언 라이선스와 판단 라이선스를 구분합니다[S4]. 선언 라이선스는 패키지 안에서 발견된 라이선스 정보에 가깝고, 판단 라이선스는 분석자가 여러 정보를 보고 합리적으로 결론낸 라이선스입니다. 이 차이는 R&D 제품팀에 매우 중요합니다. 자동 스캐너가 NOASSERTION 또는 모호한 값을 냈는데 담당자가 외부 웹사이트 설명만 보고 "허용"이라고 바꾸면 증거가 약해집니다. 반대로 패키지 메타데이터에는 MIT라고 되어 있지만 실제 파일 일부에 다른 고지가 있으면 그 차이를 설명해야 합니다. 자동 검출값과 최종 판단값을 같은 칸에 덮어쓰지 말고, 판단 사유를 별도 칸에 남깁니다.

라이선스 판단 로그에 꼭 남길 문장

검출된 라이선스와 최종 판단 라이선스가 같은지, 다르다면 왜 다른지 적습니다.

고지, 저작권 표시, NOTICE 파일, 변경사항 표시, 소스 제공 의무가 있는지 분리합니다.

배포 형태를 바이너리 납품, SaaS 제공, 고객 온프레미스 설치, 펌웨어 탑재, SDK 제공으로 구분합니다.

수정한 오픈소스와 단순 사용한 오픈소스를 나눕니다.

법률 자문이 필요한 항목은 "검토 완료"가 아니라 "법무 검토 필요"로 표시합니다.

국내 팀은 오픈소스 포털의 라이선스 검증 안내도 함께 볼 수 있습니다. 해당 페이지는 공개소프트웨어 사용 현황 파악, 라이선스 충돌 제거와 지속 모니터링, 보안취약점 확인과 조치를 검증 목적에 포함하고, 소스코드 파일 검증과 바이너리 파일 검증을 구분합니다[S7]. 이 구분은 R&D 산출물에 특히 중요합니다. 과제 보고서에는 소스 저장소 링크만 적었지만 실제 상용화 후보가 설치 파일, 컨테이너 이미지, 장비 내장 소프트웨어라면 바이너리에 포함된 구성요소가 별도로 확인되어야 합니다.

이 글은 특정 라이선스의 법적 효력을 판단하지 않습니다. 대신 제품팀이 법무, 고객사, 파트너, 심사기관과 대화할 수 있는 증거 언어를 만듭니다. "이 패키지는 Apache-2.0으로 보입니다"보다 "이 릴리스의 third-party-notices.txt에 Apache-2.0 전문과 저작권 고지를 포함했고, 수정 파일은 없으며, 자동 검출값과 최종 판단값이 일치합니다"가 더 실무적인 문장입니다. 반대로 "GPL 계열 가능성이 있으나 실제 링크 방식과 배포 형태 판단이 남아 있어 고객 전달 전 법무 검토가 필요합니다"라는 문장은 불완전하지만 안전한 증거입니다.

의존성 업데이트 증거는 패치 완료보다 판단 로그가 먼저입니다

SBOM과 취약점 기록을 섞으면 보안 컴플라이언스 문서처럼 보이기 쉽습니다. 이 글에서 필요한 것은 침투 테스트나 보안 인증 결과가 아니라 구성요소별 판단 로그입니다. 어떤 취약점이 어떤 구성요소에 연결됐는지, 해당 구성요소가 실제 릴리스에 포함되는지, 영향 받는 기능을 사용하는지, 업데이트했는지, 업데이트하지 않았다면 왜 보류했는지, 고객 공개본에는 어떤 문장으로 설명할지를 남기는 일입니다. CycloneDX는 알려진 취약점과 오픈소스 또는 서드파티 소프트웨어 사용에서 상속되는 취약점, VEX 용도까지 전달할 수 있는 구조를 설명합니다[S5].

업데이트 판단에는 세 가지 시간이 들어갑니다. 첫째, 취약점이나 라이선스 이슈를 발견한 날입니다. 둘째, 팀이 영향 여부를 판단한 날입니다. 셋째, 업데이트 또는 보류를 결정한 날입니다. 이 세 날짜가 없으면 "왜 아직 업데이트하지 않았는지"와 "언제부터 알고 있었는지"가 섞입니다. CISA의 2025년 공고도 SBOM 데이터의 가치가 위험관리와 보안 의사결정을 더 잘 알리는 데 있다고 설명하지만, 동시에 현재 연방 차원의 모든 조달 상황에서 SBOM 획득이 일괄적으로 요구되는 것은 아니라는 맥락도 함께 제시합니다[S2]. 그러므로 제품팀은 의무 여부를 과장하지 말고, 자신이 공급하는 제품과 고객 요구에 맞게 증거를 정리해야 합니다.

KISA의 2026년 공급망 보안 모델 구축 지원사업 공고는 SBOM을 생성, 관리, 분석하는 체계와 SBOM을 유통받아 위협을 모니터링하고 대응하는 체계를 구분해 설명합니다[S8]. 이 구분을 R&D 팀 언어로 바꾸면, 개발팀은 먼저 "우리 릴리스의 SBOM을 신뢰할 수 있게 만들었는가"를 확인하고, 그다음 "새 취약점이 나왔을 때 이 SBOM으로 영향 범위를 찾을 수 있는가"를 봐야 합니다. 두 단계가 뒤섞이면 취약점 대응 회의는 열리지만 정작 어느 제품 버전이 영향을 받는지 설명하지 못합니다.

업데이트를 못 했다고 해서 자동으로 실패는 아닙니다. 장비 인증을 다시 받아야 하는 펌웨어, 고객 현장에 이미 설치된 온프레미스 시스템, 특정 SDK와 강하게 결합된 모듈은 즉시 업데이트가 어려울 수 있습니다. 이때 필요한 것은 변명이 아니라 판단 로그입니다. 예를 들어 "패키지 A 1.2.0에 취약점 CVE-XXXX가 공지됐으나 릴리스 v0.9.3에서는 영향 함수가 호출되지 않음, 단 다음 패치 릴리스에서 1.2.3으로 업데이트 예정, 고객 공개본에는 영향 없음 판단일과 재검토 예정일을 표기"처럼 적습니다. 이 기록은 보안팀의 상세 보고서를 대체하지 않지만, 상용화 회의에서 소프트웨어 공급 범위를 설명하는 데 필요한 최소 증거가 됩니다.

파트너와 고객에게 공개할 SBOM 범위는 내부 보관본과 달라야 합니다

SBOM을 만들었다고 해서 내부 저장소 경로, 개발자 이름, 비공개 패키지 저장소 URL, 빌드 서버 구조, 취약점 상세 분석, 고객별 커스텀 로직을 모두 외부에 넘겨야 하는 것은 아닙니다. 반대로 "영업비밀"이라는 이유로 아무것도 공유하지 않으면 고객은 어떤 오픈소스가 포함됐는지, 어떤 고지가 필요한지, 알려진 취약점이 어떻게 관리되는지 확인할 수 없습니다. 제품팀은 내부 보관본, 파트너 검토본, 고객 공개본을 분리해야 합니다.

<table>

<thead>

</thead>

<tbody>

<tr><td>내부 보관본</td><td>전체 SBOM, 생성 명령, 커밋 해시, 스캐너 결과, 판단 로그, 취약점 영향 분석</td><td>접근권한을 제한하고 보관 기간을 정합니다.</td></tr>

<tr><td>고객 검토본</td><td>제품 릴리스 기준 구성요소, 라이선스 고지, 알려진 취약점 상태, 문의 창구</td><td>내부 저장소 경로, 빌드 서버, 미공개 취약점 상세 재현 절차는 제외합니다.</td></tr>

</tbody>

</table>

CycloneDX는 구성요소뿐 아니라 서비스, 의존성, 취약점, 인용 정보까지 표현할 수 있으므로[S5], 정보가 풍부한 만큼 공개 범위 통제가 더 중요합니다. 고객이 원하는 것은 보통 내부 개발 환경의 모든 정보가 아니라 자신이 도입할 제품의 구성요소와 의무, 알려진 위험 상태입니다. 파트너가 원하는 것은 자신이 맡은 모듈의 수정 요구와 라이선스 충돌 여부입니다. 내부팀이 필요한 것은 재현 가능한 전체 증거입니다. 이 세 요구를 하나의 파일로 처리하면 과공개 또는 과소공개가 생깁니다.

파트너 공개 범위는 R&D 컨소시엄 파트너 선정 체크리스트의 역할 검토와도 연결됩니다. 파트너를 잘 골랐는지와, 파트너에게 어떤 SBOM·라이선스 정보를 줄지는 별도 결정입니다. 또한 소프트웨어 산출물이 사업화 로드맵에 들어간다면 R&D 결과 사업화 로드맵 체크리스트에서 고객 검증, 인증, 후속지원 증거와 연결해 보는 편이 좋습니다. 이 글의 범위는 "어떤 공급망 정보를 누구에게 보여줄 것인가"에 있습니다.

R&D 산출물 제출 전 OSS 증거 폴더는 6개 칸이면 충분합니다

증거 폴더는 복잡할수록 버려집니다. 처음에는 여섯 개 폴더면 충분합니다. 핵심은 모든 파일을 많이 모으는 것이 아니라, 나중에 같은 릴리스 후보를 다시 설명할 수 있게 만드는 것입니다. 오픈소스 포털은 라이선스 검증 목적에 사용 현황 파악, 라이선스 충돌 제거, 취약점 확인과 조치를 포함합니다[S7]. 이 목적을 그대로 폴더 구조로 바꾸면 개발팀, 법무, 사업화 담당자가 같은 자료를 다른 질문으로 읽을 수 있습니다.

SBOM·OSS 라이선스 증거 폴더 예시

00_release-scope: 제품명, 릴리스 버전, 커밋 해시, 빌드 산출물, 대상 고객 또는 과제 제출 범위

01_sbom: SPDX 또는 CycloneDX 파일, 생성 도구와 버전, 생성 명령, 생성일, known unknowns

02_license-review: 자동 검출 라이선스, 최종 판단 라이선스, 고지 의무, NOTICE 파일, 법무 검토 필요 항목

03_vulnerability-update: 취약점 매칭 결과, 영향 여부 판단, 업데이트 또는 보류 사유, 재검토 예정일

04_disclosure-boundary: 내부 보관본, 파트너 공유본, 고객 공개본의 차이와 제외 정보

05_delivery-evidence: 고객 전달 파일, 오픈소스 고지 파일, 전달 일자, 수신자, 문의 창구

이 폴더는 R&D 최종보고서 증거 패키지 체크리스트의 하위 증거로 넣을 수 있습니다. 최종보고서 증거가 성과를 설명한다면, SBOM·OSS 폴더는 그 성과를 구성하는 소프트웨어를 설명합니다. 연구비 집행 증거처럼 영수증을 모으는 일이 아니고, AI 데이터 프로젝트처럼 데이터셋 권리와 모델 평가를 증명하는 일도 아닙니다. 소프트웨어 릴리스 안의 재사용 구성요소와 배포 조건을 증명하는 일입니다.

소스코드만 있는 과제라도 폴더를 생략하지 않는 편이 좋습니다. 연구 결과가 논문, 코드 저장소, 데모 페이지로 끝나는 것처럼 보여도 후속 과제, 기술이전, 고객 PoC, 사내 제품화가 시작되면 같은 코드가 다시 쓰입니다. 그때 과거 라이선스 판단이 없으면 새 팀은 패키지를 다시 스캔하고, 고지를 다시 만들고, 고객 공개 범위를 다시 정해야 합니다. 반대로 과제 종료 시점에 릴리스 후보 기준의 SBOM과 라이선스 로그가 있으면 후속 상용화 팀은 출발선을 훨씬 명확하게 잡을 수 있습니다.

제출 직전 45분 점검은 파일 생성보다 공개 범위 확인에 써야 합니다

제출 직전에는 새 도구를 도입하기보다 이미 만든 증거가 서로 맞는지 확인해야 합니다. 처음 10분은 릴리스 범위를 봅니다. 최종보고서, 데모 링크, 설치 파일, 컨테이너 이미지, 고객 전달본이 같은 버전을 가리키는지 확인합니다. 다음 10분은 SBOM 필드를 봅니다. 구성요소 이름과 버전, 의존 관계, 생성 도구, 생성 시각, 작성자가 들어 있는지 확인하고, 모르는 항목은 빈칸 대신 known unknowns로 적습니다.

그다음 10분은 라이선스 의무를 봅니다. 자동 검출값과 최종 판단값이 덮어쓰기되지 않았는지, NOTICE 파일과 라이선스 전문이 실제 전달 패키지에 포함되는지, 수정한 오픈소스가 있는지 확인합니다. SPDX License List처럼 표준 식별자가 있는 경우에는 임의 축약명보다 표준 식별자를 우선 사용합니다[S3]. 다만 표준 식별자가 있다고 해서 의무 판단이 자동으로 끝나는 것은 아닙니다. 배포 형태와 수정 여부, 결합 방식, 고객 제공 범위를 함께 적어야 합니다.

다음 10분은 취약점과 업데이트 판단을 봅니다. "취약점 없음"이라고 쓰기보다 "이 릴리스 기준 스캔일, 스캔 도구, 매칭 결과, 영향 없음 판단 사유, 업데이트 보류 항목, 재검토 예정일"을 확인합니다. 마지막 5분은 공개본을 봅니다. 파트너나 고객에게 보낼 파일에서 내부 저장소 경로, 개발자 개인 계정, 비공개 패키지 저장소 URL, 미공개 취약점 재현 절차가 빠졌는지 확인합니다. 공개본이 너무 빈약하면 고객이 검토할 수 없고, 너무 자세하면 불필요한 내부 정보가 나갑니다.

마지막 기준은 단순합니다. 누군가 6개월 뒤에 "이 R&D 소프트웨어 산출물에 어떤 오픈소스가 들어 있었고, 어떤 라이선스 의무를 어떻게 처리했으며, 왜 그 버전으로 상용화 후보를 냈는가"라고 물었을 때 폴더만 보고 답할 수 있어야 합니다. 답할 수 없다면 SBOM 파일이 있어도 증거는 아직 부족합니다. 답할 수 있다면 법무 검토, 고객 보안 질의, 파트너 수정 요청, 후속 상용화 회의가 모두 같은 릴리스 기준으로 움직일 수 있습니다.

이 글의 다음 경로는 세 갈래입니다. 접근권한, 저장소, 반출 통제까지 점검해야 한다면 R&D 보안·컴플라이언스 체크리스트를 봅니다. AI 데이터셋 권리와 모델 평가가 함께 걸려 있다면 AI 데이터 R&D 프로젝트 기획 체크리스트로 분리합니다. 상용화 근거 전체를 정리해야 한다면 R&D 결과 사업화 로드맵 체크리스트와 R&D 최종보고서 증거 패키지 체크리스트에 SBOM·OSS 폴더를 연결합니다.