| sitelink1 | |
|---|---|
| sitelink2 | |
| sitelink3 | |
| sitelink4 | |
| extra_vars5 | |
| extra_vars6 |
SPDX 2.3, 계속 써도 되나요? — 3.0으로 넘어갈 때를 판단하는 실무 기준
SBOM을 실제로 만들어 제출해 본 분이라면 한 번쯤 걸렸을 질문이 있습니다.
"우리는 SPDX 2.3으로 뽑고 있는데, 3.0이 나왔다니 지금 넘어가야 하나?"
이 질문이 최근 해외 표준 커뮤니티에서 공식 안건으로 올라왔습니다. 그런데 흥미로운 건, 아직 답이 나오지 않았다는 겁니다.
그래서 오늘은 "공식 답이 없는 상태에서 실무는 무엇을 기준으로 판단해야 하는가"를 정리해 보려 합니다.
1. 무슨 일이 있었나
2026년 8월 9일, SPDX 규격 저장소에 **「Document support status of SPDX 2.x series」**라는 이슈가 등록됐습니다(spdx-spec #1461).
며칠 앞선 8월 6일 OpenChain Telco 워킹그룹 회의에서 나온 질문을 정리해 올린 것입니다.
질문의 요지는 간단합니다.
SPDX 2 시리즈는 앞으로 어떻게 되는가? 2.3에 버그 수정이 계속 들어오는가, 아니면 2.4 같은 마이너 버전이 나올 수 있는가? 정규식 수정·오타·스키마 보정·열거형 추가 정도의 작은 개선이라도 기대할 수 있는가?
배경 설명이 더 눈길을 끕니다. 일부 현장은 여전히 SPDX 2를 쓰고 있고, 3.0으로 넘어갈 계획이 없다는 겁니다.
이유로 두 가지가 꼽혔습니다.
- 3.0 대비 도구 생태계의 복잡도
- JSON-LD 직렬화가 사람이 읽기 어렵다는 점
이 글을 쓰는 시점(2026-08-11) 기준으로 이 이슈는 열린 상태이고, 공식 답변은 아직 달리지 않았습니다.
즉 "2.x를 언제까지 써도 되는가"에 대한 표준 측의 공식 방침이 아직 없다는 것이 현재 상태입니다.
2. 왜 다들 2.x에 남아 있나
위 두 가지 이유는 제 경험과도 정확히 겹칩니다.
SPDX 2.x와 3.0은 버전 번호만 올라간 관계가 아니라 구조가 크게 다릅니다.
마이너 업그레이드처럼 "숫자만 바꿔서 다시 뽑으면 되는" 일이 아니라는 뜻입니다.
그래서 전환에는 도구·검증·인수인계 문서가 함께 움직여야 합니다.
여기에 도구 쪽 현실이 붙습니다. 실무에서 SBOM을 뽑을 때 쓰는 도구들의 기본 출력이 아직 2.2/2.3 계열인 경우가 많습니다.
어떤 도구는 아예 출력 옵션에서 규격 버전을 명시적으로 지정하게 되어 있고, 그 기본값이 2.2인 경우도 있습니다.
"3.0으로 뽑아라"라는 요구가 오면 도구부터 다시 검토해야 하는 상황이 생깁니다.
참고로 CycloneDX 쪽은 이런 급격한 구조 전환 없이 점진적으로 확장돼 왔습니다.
같은 SBOM 표준이라도 버전 전략이 다르다는 점은, 두 표준을 비교할 때 잘 언급되지 않지만 실무에서는 꽤 크게 체감되는 차이입니다.
3. 그래서 실무는 무엇을 기준으로 판단하나
공식 방침이 없다고 손 놓고 있을 수는 없으니, 제가 쓰는 판단 순서를 공유합니다.
위에서부터 순서대로 보면 대부분 결론이 납니다.
① 요구자가 지정했으면 거기서 끝입니다.
고객·감사·규제가 포맷을 지정하는 순간 선택의 여지는 없습니다.
중요한 건 그다음입니다 — 포맷 이름만 확인하고 넘어가지 마세요.
실무에서 "SPDX로 주세요"라는 요구를 받으면, 그 요구의 상당수는 규격 버전(2.2인지 2.3인지 3.0인지)과 표현 형식(JSON인지 Tag/Value인지)이 비어 있습니다.
이걸 확인하지 않고 뽑으면 제출 후에 "이 버전이 아닙니다"라는 답이 돌아오고, 그때는 재산출입니다.
저는 이 확인을 빼먹었다가 다시 뽑은 경험이 있어서, 지금은 요구를 받는 자리에서 바로 되묻습니다.
되물을 것 3가지: 규격 버전 / 표현 형식 / 제출 단위(제품 전체인지 모듈별인지)
② 요구가 없다면, 받는 쪽 도구에 맞춥니다.
SBOM은 만들어서 파일로 쌓아두는 게 목적이 아니라 어딘가에 입력되어 쓰이는 문서입니다.
취약점 관리 도구에 넣을 거라면 그 도구가 잘 먹는 형식이 정답이고, 라이선스 컴플라이언스 검토용이라면 그쪽 도구의 입력 형식이 기준이 됩니다.
③ 그래도 정해야 한다면 — 지금 시점에서는 2.3 유지가 무난합니다.
이유는 세 가지입니다.
- 산출 도구의 지원이 두텁습니다(기본값인 경우가 많음)
- 검증·변환 도구도 2.x 기준으로 성숙해 있습니다
- 그리고 지금 이 순간에도 "2.x 지원 방침을 명시해달라"는 요청이 표준 커뮤니티에 올라와 있습니다 — 즉 2.x를 쓰는 현장이 여전히 두텁다는 방증입니다
다만 이건 "지금 시점의 무난함"이지 영구적인 답이 아닙니다. 아래 신호가 보이면 그때가 전환 시점입니다.
④ 전환을 검토해야 하는 신호
- 요구자가 3.0을 명시하기 시작할 때 (가장 명확한 신호)
- 쓰는 도구의 3.0 출력이 기본값이 되고 2.x가 레거시 취급될 때
- 3.0에서만 표현되는 정보(예: 보안 취약점 정보의 구조적 표현)가 실제로 필요해질 때
반대로 "최신 버전이 나왔으니까"만으로는 전환 이유가 되지 않습니다.
SBOM은 우리가 보려고 만드는 문서가 아니라 남에게 제출하는 문서라, 받는 쪽이 읽지 못하는 버전으로 앞서 나가면 그 자체가 재작업 사유가 됩니다.
4. 전환하기로 했다면 — 확인할 것
실제로 3.0으로 옮기기로 했다면 다음을 미리 점검하시기 바랍니다.
| 확인 항목 | 왜 |
|---|---|
| 산출 도구가 3.0을 기본으로 지원하는가 (옵션이 아니라) | 옵션 지원은 검증되지 않은 경로일 수 있음 |
| 검증 도구가 3.0 문서를 읽는가 | 산출과 검증은 별개 문제 — "뽑았다"와 "그게 맞다"는 다름 |
| 받는 쪽(고객·감사·관리 도구)이 3.0을 받는가 | 여기서 막히면 전환 자체가 무의미 |
| 기존 2.x 산출물의 보관·재현 계획 | 과거 제출본을 다시 만들어야 할 때가 옵니다 |
| 변환으로 갈지, 직접 산출할지 | 감사 제출본은 변환보다 직접 산출을 권합니다. 변환 과정에서 빠지는 필드가 생길 수 있고, 그 손실을 제출 후에 발견하면 늦습니다 |
마지막 항목이 실무에서 가장 자주 걸리는 지점입니다.
포맷 변환 도구가 있으니 "일단 2.3으로 뽑고 3.0으로 변환하면 되지 않나" 싶지만, 감사에 내는 문서는 요구받은 포맷으로 직접 만드는 것이 안전합니다.
5. 정리
- SPDX 2.x의 지원 방침에 대한 공식 답은 아직 없습니다(2026-08-11 기준, 이슈 #1461 열린 상태)
- 3.0 전환을 막는 건 게으름이 아니라 도구 생태계와 가독성이라는 현실적 이유이고, 해외 현장도 같은 이유로 남아 있습니다
- 판단 순서는 요구자 지정 → 받는 쪽 도구 → (없으면) 2.3 유지
- 전환 신호는 "새 버전이 나왔다"가 아니라 **"받는 쪽이 3.0을 요구한다"**입니다
SBOM 작업에서 포맷 선택은 취향이 아니라 제출 상대에 대한 맞춤입니다.
그 관점으로 보면 이 질문의 답은 대체로 자기 자신이 아니라 상대편에 있습니다.
출처
| # | 자료 | 참조한 내용 |
|---|---|---|
| 1 | spdx/spdx-spec Issue #1461 — Document support status of SPDX 2.x series (2026-08-09 등록, 작성 시점 기준 열린 상태) | 이슈 제목·요지(2.3 버그 수정/2.4 가능성), 2.x 잔류 이유 2가지(도구 생태계 복잡도·JSON-LD 가독성), 공식 답변 부재 |
| 2 | OpenChain Telco WG 회의 (2026-08-06) — 위 이슈에 배경으로 언급됨 | 질문이 처음 제기된 자리 |
| 3 | SPDX 공식 사이트 · SPDX 규격 저장소 | 규격 버전 체계 확인 |
| 4 | 필자 실무 경험 | 규격 버전 미확인으로 인한 재산출, 도구 기본 출력 버전 확인, 감사 제출본은 직접 산출 원칙 |
