이 시리즈를 만든 과정

이 시리즈는 세 단계로 쌓아 올렸습니다. 먼저 무엇을 요구할지를 표준으로 정하고, 그것을 기업의 세 가지 사용 맥락에 맞춘 운영 문서로 옮긴 다음, 그 요구사항을 실제로 검사할 도구 세트를 조사했습니다. 각 단계는 다음 단계의 입력이 되므로, 매트릭스가 흔들리면 운영 문서와 도구 전략이 함께 흔들립니다. 그래서 매트릭스의 근거를 가장 단단하게 잡았습니다.

1단계 — 표준 합의 매트릭스

출발점은 G7 사이버보안 작업반이 정의한 「AI를 위한 SBOM 최소 요소」의 50개 요소입니다. 이 50개를 행으로 두고 SPDX 3.0.1, CycloneDX 1.6, NTIA 2021, OpenChain AI V1 네 표준의 요구 강도를 대조했습니다. 어떤 필드의 존재를 두 곳 이상이 요구하면 필수, 아니면 선택으로 갈랐습니다. 그 결과 50개 중 20개가 필수, 30개가 선택으로 나뉘었습니다.

판정의 핵심 근거인 SPDX 3.0.1 클래스 카디널리티와 CycloneDX 1.6 JSON 스키마의 required 배열은 1차 명세에서 직접 확인했습니다. 객체 생성 시에만 강제되는 조건부 필수를 “존재 요구"로 세지 않는다는 규칙을 일관되게 적용해, 모델 해시나 데이터셋 의존성 관계 같은 항목이 과도하게 필수로 올라가지 않게 했습니다. 규제(CRA, AI Act, FDA, 국내 제도)는 합의 카운트와 분리된 별도 축으로 두어, 표준이 데이터 필드로 규정하지 않아도 규제가 같은 정보를 요구하는 경우(취약점 참조 등)를 역할별 적용에서 끌어올릴 수 있게 했습니다.

2단계 — 운영 문서 3종

같은 매트릭스를 기업이 실제로 쓰는 세 가지 맥락으로 옮겼습니다. 자사 개발팀이 직접 작성하는 생산, 외부 모델·데이터셋을 들여올 때 점검하는 도입, 공급사에 제출을 요구하는 공급사 요구입니다. 정보 접근성이 가장 좋은 생산 시점은 요구 수준을 가장 높게, 위험 평가가 목적인 도입은 라이선스와 출처, 민감도, 취약점에 무게를 두는 식으로, 같은 필드라도 맥락에 따라 필수와 권장을 다르게 배치했습니다. 세 문서의 역할별 필수 집합은 매트릭스 §4.6 역할 표에서 그대로 도출했습니다.

3단계 — 도구 세트 전략

요구사항을 정의했으면 그것을 검사할 수단이 필요합니다. 7개 도구 범주를 공식 리포지토리와 문서로 조사해, 무엇을 재사용하고 무엇을 확장하거나 새로 만들지 판단했습니다. 생성(cdxgen aibom), 검증(sbomqs, OPA/Rego), 저장(Dependency-Track), 모델 무결성(ModelScan, sigstore)은 이미 오픈소스로 작동하므로 재사용하고, AI 고유 필드의 역할별 적합성 검사와 모델·데이터 인벤토리, 라이선스 사용 제한 판정만 신규 구축 대상으로 좁혔습니다. 매트릭스를 필드 레지스트리와 역할별 정책 파일로 코드화하는 설계까지 포함했습니다.

검증과 red-team 검토

세 단계 전체를 fact-checker가 별도로 검증했습니다. 매트릭스의 표준 근거는 1차 명세로 직접 확인해 일치했고, 도구 전략의 핵심 단정 일곱 가지도 각 프로젝트의 공식 리포지토리·문서로 뒷받침됨을 확인했습니다. 전체 판정은 CONDITIONAL PASS입니다. NTIA 일곱 기준 필드의 1차 명세(ntia.gov)가 인증서 오류로 직접 조회되지 않아 공개 미러로 확인한 점, 도구 전략의 예시 정책 파일이 공급사 필수 집합을 일부만 옮긴 점이 조건부 사유로 남았습니다. 발행을 차단할 사실 오류나 환각은 발견되지 않았습니다. 자세한 검증 기록은 검증 보고서에 있습니다.

발행 전에는 적대적 관점의 red-team 검토를 한 차례 더 거쳐, 매트릭스 판정 규칙의 일관성과 역할별 적용의 근거, 도구 단정의 과장 여부를 다시 점검했습니다.