AI 확장 프로세스

• 1: 3.5 라이선스 의무
• 2: 3.6 투명성 의무
• 3: 3.9 AI SBOM

1 - 3.5 라이선스 의무

1. 조항 개요

라이선스 의무는 AI SBOM 가이드가 ISO/IEC 5230에서 가장 크게 확장된 지점이다. 전통적 오픈소스 컴플라이언스가 코드의 라이선스를 검토했다면, AI에서는 검토 대상이 네 갈래로 늘어난다. AI 시스템의 코드, 모델 가중치, 데이터셋(학습·테스트·검증 데이터셋을 포함), 그리고 AI 시스템 자체의 라이선스다. 한 모델이 다른 여러 모델에서 파생되는 일이 흔해, 모델 트리(Model Tree)에 놓인 각 상위 모델이 저마다 고유한 라이선스를 가진다.

3.5는 이 라이선스들을 검토해 AI 시스템의 의도된 용도에 비추어 각 라이선스가 부여하는 의무, 제한, 권리를 판단하는 절차를 갖출 것을 요구한다. 검토는 상위(업스트림)에서 물려받는 의무와 하위(다운스트림)로 넘기는 의무를 모두 다룬다.

2. 해야 할 활동

• 코드, 가중치, 데이터셋, AI 시스템 자체의 라이선스를 식별하는 절차를 수립한다.
• 모델 트리의 상위 모델별 라이선스를 추적하고, 각 라이선스의 의무·제한·권리를 문서화한다.
• 소스 코드와 의존성은 자동 스캔 도구로 1차 식별한다. ([본 가이드 권고])
• 모델 가중치와 데이터셋, 비표준 라이선스는 법무 또는 거버넌스 검토로 판단한다. ([본 가이드 권고])
• 외부에서 모델이나 데이터셋을 도입할 때 라이선스 메타데이터를 함께 받는 인입 절차를 둔다. ([본 가이드 권고])
• 검토 결과(의무, 제한, 권리)를 AI SBOM에 기록해 추적한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.5.1 라이선스 의무 검토·문서화 절차

준수 방법

검토 절차는 자재 유형에 따라 자동화 수준이 다르다는 점을 전제로 설계한다. 소스 코드와 의존성 라이선스는 FOSSology, ScanCode, OSS Review Toolkit 같은 자동 스캔 도구로 상당 부분 식별할 수 있다. 그러나 모델 가중치와 데이터셋의 라이선스, 그리고 모델 트리의 파생 관계는 이런 도구의 적용 범위 밖이거나 정확도가 낮다. 비표준 라이선스의 사용 목적 제한은 사람의 해석이 필요하다. 따라서 자동 스캔으로 1차 식별하고, 모델과 데이터셋과 비표준 라이선스는 법무 또는 거버넌스 검토로 넘기는 분업 구조가 현실적이다.

아래 그림은 자재가 들어올 때 라이선스 의무를 판단하는 의사결정 흐름이다.

flowchart TD
    A([AI 시스템 자재 입력]) --> B{자재 유형}
    B -->|코드·의존성| C[자동 SCA 스캔\nScanCode·ORT]
    B -->|모델·데이터셋| D[라이선스 메타데이터 확인\n모델 카드·데이터시트]
    C --> E{라이선스 식별?}
    D --> E
    E -->|표준 허용 라이선스| F[의무·제한·권리 분류]
    E -->|비표준·불명확| G[법무·거버넌스 검토\n사용 목적 제한 해석]
    G --> F
    F --> H{의도된 용도와\n충돌?}
    H -->|예| I[위험 완화 또는\n자재 교체]
    H -->|아니오| J[AI SBOM에 기록\n업스트림·다운스트림 의무]
    I --> J
    J --> K([정기 재검토])

    style A fill:#2d3748,color:#fff
    style G fill:#744210,color:#fff
    style I fill:#c53030,color:#fff
    style J fill:#2b6cb0,color:#fff

그림 1. 라이선스 의무 검토 의사결정 흐름

고려사항

• 인입 게이트에서 메타데이터 강제: 라이선스 의무가 누락되는 가장 큰 원인은 모델이 다운스트림 으로 전파되며 출처와 라이선스 정보가 소실되는 라이선스 드리프트(license drift)다. 한 연구는 모델에서 애플리케이션으로 넘어가는 전이에서 제한 조항의 상당수가 사라진다고 보고한다 (arXiv:2509.09873). 다운스트림에서 복원하려 애쓰기보다, 사내 모델·데이터셋 레지스트리에서 라이선스 메타데이터가 없는 자재의 인입을 막는 편이 효과적이다. ([본 가이드 권고])
• 비표준 라이선스는 정책으로 선결정: Llama 커뮤니티 라이선스나 OpenRAIL 계열의 행동 사용 제한은 준수 여부를 사후에 자동 추적하기 어렵다. 3.1 정책의 허용·금지 목록으로 도입 시점에 결정한다. ([본 가이드 권고])
• 모델 트리 추적: 도입 모델이 어떤 상위 모델에서 파생되었는지를 모델 카드로 확인하고, 상위 모델의 라이선스 의무가 하위로 전파되는지 검토한다.
• 데이터셋 사용 제한 확인: CC-BY-NC 같은 비상업 라이선스 데이터셋을 상업 제품의 학습에 사용했는지 점검한다. 데이터셋 라이선스 누락과 오기재가 흔하므로 원문으로 대조한다.
• 자동화 한계 인지: 자동 스캔 도구의 결과를 최종 판단으로 삼지 않는다. 도구는 식별을 돕고, 의무의 해석과 충돌 판단은 사람이 맡는다.

샘플

아래는 라이선스 의무 검토 절차서의 핵심 부분 샘플이다. 이 절차 문서가 입증자료 3.5.1이 된다.

## AI 라이선스 의무 검토 절차

### 1. 검토 대상
- AI 시스템 코드 및 의존성
- 모델 가중치 (도입 모델, 파인튜닝 모델)
- 데이터셋 (학습·테스트·검증)
- 모델 트리 상위 모델의 라이선스

### 2. 검토 단계
1) 자동 식별: 코드와 의존성은 SCA 도구로 라이선스를 스캔한다.
2) 메타데이터 수집: 모델과 데이터셋은 모델 카드·데이터시트에서 라이선스를 수집한다.
   메타데이터가 없으면 인입을 보류한다.
3) 분류: 식별된 라이선스를 정책의 허용·조건부·금지 목록에 대조한다.
4) 법무 검토: 비표준·불명확 라이선스는 법무·거버넌스 검토로 의무를 해석한다.
5) 기록: 업스트림·다운스트림 의무, 제한, 권리를 AI SBOM에 기록한다.

### 3. 책임과 주기
- 1차 식별: 개발 담당
- 의무 해석: 법무·AI 거버넌스 책임자
- 재검토: 모델·데이터셋 교체 시, 그리고 최소 분기 1회

5. 참고

• 라이선스 허용·금지 목록 정책: 3.1 정책
• 검토 결과를 기록할 AI SBOM: 3.9 AI SBOM
• 자동 스캔 도구: 도구 — FOSSology, SCANOSS
• AI 모델·데이터셋 라이선스 전략: 기업 오픈소스 관리 가이드 — AI 컴플라이언스

2 - 3.6 투명성 의무

1. 조항 개요

라이선스 의무(3.5)가 “이 자재를 쓸 권리가 있는가"를 묻는다면, 투명성 의무는 “이 자재에 대해 무엇을 공개해야 하는가"를 묻는다. 두 의무는 다른 출처에서 온다. 라이선스 의무는 저작권자가 계약으로 부과하고, 투명성 의무는 규제가 법으로 부과한다.

3.6은 규제로부터 부과되는 투명성 의무가 있는지 검토하는 절차를 갖출 것을 요구한다. 검토 대상에는 학습·테스트·검증 데이터셋이 포함되며, 모델의 의도된 용도를 고려한다. 학습 데이터의 사용 사례가 투명성 쟁점(예: 다운스트림 수령자에 대한 공개 의무)을 야기하면 적절한 위험 완화 조치를 취해야 한다. EU 인공지능법이 2026년 8월부터 투명성 의무를 본격 적용하면서 이 조항의 실무 비중이 커지고 있다.

2. 해야 할 활동

• 도입·개발하는 AI 시스템에 적용되는 투명성 규제를 식별하는 절차를 둔다.
• 학습·테스트·검증 데이터셋에 공개 의무가 걸리는지 의도된 용도를 기준으로 검토한다.
• 다운스트림 수령자에 대한 공개 의무가 있으면 위험 완화 조치를 정한다.
• 취한 투명성 조치를 문서화한다.
• 규제기관이 정한 최신 투명성 의무를 정기적으로 갱신해 반영한다. ([본 가이드 권고])

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.6.1 투명성 의무 검토·문서화 절차

준수 방법

투명성 의무는 규제마다 다르므로, 먼저 어떤 규제가 적용되는지부터 식별한다. 적용 규제가 정해지면 각 규제가 요구하는 공개 항목을 도출하고, 그 항목을 AI SBOM이나 모델 카드에 반영한다. 라이선스 의무와 달리 투명성 의무는 “공개"가 핵심이므로, 산출물이 외부에 전달될 수 있는 형태로 정리되어야 한다.

아래 표는 AI SBOM과 교차하는 주요 투명성 의무다. 규제 일정과 전체 맥락은 3.10 거버넌스의 규제 매트릭스에서 함께 관리한다.

표 1. AI SBOM과 교차하는 투명성 의무 (2026-06 기준)

다음 그림은 자재의 의도된 용도에서 투명성 의무를 도출하는 검토 흐름이다.

flowchart TD
    A([모델·데이터셋과 의도된 용도]) --> B[적용 규제 식별\nEU 인공지능법·한국 AI 기본법 등]
    B --> C{투명성 의무\n존재?}
    C -->|없음| D[검토 결과 기록\n의무 없음 근거]
    C -->|있음| E[공개 항목 도출\n데이터 요약·라벨링·출처]
    E --> F{다운스트림\n공개 쟁점?}
    F -->|있음| G[위험 완화 조치\n요약 공개·계약 고지]
    F -->|없음| H[AI SBOM·모델 카드에 반영]
    G --> H
    H --> I([조치 문서화\n정기 갱신])

    style A fill:#2d3748,color:#fff
    style E fill:#2b6cb0,color:#fff
    style G fill:#744210,color:#fff
    style I fill:#22543d,color:#fff

그림 1. 투명성 의무 검토 흐름

고려사항

• 데이터셋 출처가 핵심: 투명성 의무의 다수가 학습 데이터에 걸린다. 데이터셋의 출처와 라이선스가 AI SBOM에 기록되어 있어야 공개 의무를 이행할 수 있다. AI SBOM(3.9)과 직접 연결된다.
• 의도된 용도가 기준: 같은 모델이라도 사용 사례에 따라 투명성 의무가 달라진다. 고위험 용도나 일반 공중 대상 서비스는 의무가 무거워진다.
• 다운스트림 공개 의무: 외부에 모델이나 시스템을 공급할 때 수령자에게 알려야 할 정보가 있는지 검토한다. 위험 완화는 학습 데이터 요약 공개나 계약상 고지로 이행할 수 있다.
• 규제 변화 반영: EU 인공지능법은 2026년 8월부터 투명성 의무를 적용하므로, 시점에 맞춰 절차를 갱신한다. 갱신 책임은 거버넌스(3.10)가 관리한다.

샘플 (투명성 의무 검토 절차)

아래는 투명성 의무 검토 절차서의 핵심 부분 샘플이다. 이 절차 문서가 입증자료 3.6.1이 된다.

## 투명성 의무 검토 절차

### 1. 적용 규제 식별
AI 시스템의 의도된 용도와 배포 지역을 기준으로 적용 규제를 식별한다.
(예: EU 시장 배포 → EU 인공지능법, 국내 고영향 AI → 한국 AI 기본법)

### 2. 공개 항목 도출
규제별 투명성 의무를 공개 항목으로 정리한다.
- 학습 데이터 요약 (EU 인공지능법 Article 53)
- AI 생성·상호작용 표시 (EU 인공지능법 Article 50, 한국 AI 기본법)
- 데이터 출처 공개 (한국 AI 기본법)

### 3. 다운스트림 검토
외부 공급 시 수령자에게 전달할 정보를 검토하고, 필요한 위험 완화 조치를 정한다.

### 4. 반영과 문서화
도출한 공개 항목을 AI SBOM과 모델 카드에 반영하고, 취한 조치를 기록한다.

### 5. 책임과 주기
- 검토: 법무·AI 거버넌스 책임자
- 갱신: 규제 시행 일정 변경 시, 그리고 최소 반기 1회

5. 참고

• 라이선스 의무와의 구분: 3.5 라이선스 의무
• 공개 항목을 담을 AI SBOM: 3.9 AI SBOM
• 규제 일정과 거버넌스: 3.10 거버넌스
• AI 모델 라이선스와 표시 의무: 기업 오픈소스 관리 가이드 — AI 컴플라이언스

3 - 3.9 AI SBOM

1. 조항 개요

AI SBOM(AI System Bill of Materials)은 AI 시스템을 구성하는 요소와 그 정보를 담은 목록이다. 전통적 SBOM이 소프트웨어 컴포넌트를 기록한다면, AI SBOM은 여기에 모델, 가중치, 데이터셋, 하이퍼파라미터를 더한다. 3.9는 AI SBOM을 생성하고 관리하는 절차를 갖출 것을 요구한다.

형식은 정해두지 않는다. 규격은 SPDX, CycloneDX, 또는 그 밖의 형식 등 어떤 것이든 무방하다고 명시한다. 다만 한 가지 의무가 있다. AI SBOM은 제3자로부터 유입되는 자재(inbound materials)를 반영해야 한다. 외부에서 도입한 사전학습 모델과 데이터셋이 빠지면 라이선스 의무(3.5)와 투명성 의무를 추적할 근거가 사라지기 때문이다.

AI SBOM 영역은 “생성은 도구로 자동화되지만, 정확성과 준수 판단은 사람이 채운다"는 경계가 가장 뚜렷한 곳이다. 이 페이지는 그 경계를 따라 절차를 안내한다.

2. 해야 할 활동

• AI 시스템의 구성요소(모델, 데이터셋 등)에 대한 식별, 추적, 검토, 승인, 보관 절차를 수립한다.
• AI SBOM 형식을 정한다(SPDX 3.0 AI Profile 또는 CycloneDX ML-BOM 권장). ([본 가이드 권고])
• 제3자에게서 유입되는 모델과 데이터셋을 AI SBOM에 반드시 포함한다.
• 생성 도구를 CI/CD에 연동해 AI SBOM을 반복 생성한다. ([본 가이드 권고])
• 생성된 AI SBOM의 라이선스와 출처 필드가 정확한지 사람이 검토한다. ([본 가이드 권고])
• 절차가 준수되었음을 입증하는 기록(생성 이력, 승인 이력)을 보관한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.9.1 AI SBOM 관리 절차 (식별, 추적, 검토, 승인, 보관)

준수 방법

AI SBOM 절차는 생성, 검토, 승인, 보관의 네 단계로 설계한다. 생성 단계는 도구로 자동화하고, 검토와 승인 단계는 사람이 맡는다. 도구가 모델 카드의 라이선스 필드를 그대로 옮겨 적더라도, 그 라이선스가 실제 사용 사례에 맞는지, 누락이나 오기재는 없는지는 도구가 판단하지 못하기 때문이다.

아래 그림은 AI SBOM 생성에서 보관까지의 흐름이다.

flowchart TD
    A([AI 시스템 자재]) --> B[생성: SBOM 도구 실행\ncdxgen·OWASP AIBOM Generator]
    B --> C[형식 산출\nSPDX 3.0 AI Profile\n또는 CycloneDX ML-BOM]
    C --> D{인바운드 자재\n포함?}
    D -->|누락| E[제3자 모델·데이터셋\n추가 수집]
    E --> C
    D -->|포함| F[검토: 라이선스·출처\n필드 사람 확인]
    F --> G{정확·완전?}
    G -->|아니오| H[보강 또는 정정]
    H --> F
    G -->|예| I[승인: 거버넌스 책임자]
    I --> J([보관: 버전·이력 관리\n취약점 모니터링])

    style A fill:#2d3748,color:#fff
    style B fill:#2b6cb0,color:#fff
    style F fill:#744210,color:#fff
    style J fill:#22543d,color:#fff

그림 1. AI SBOM 생성에서 보관까지의 절차

도구 매핑

각 단계에 활용할 수 있는 오픈소스 도구다. “자동화 수준"은 그 작업을 도구가 어디까지 대신하는지를 나타낸다.

각 도구의 설치와 사용법, 실행 화면은 도구 절에서 자세히 다룬다(OWASP AIBOM Generator, cdxgen, 모델·컨테이너 스캐너).

cdxgen으로 AI BOM을 생성하는 명령은 다음과 같다. Hugging Face 모델 URL과 purl, Modelfile, GGUF 아티팩트를 직접 입력할 수 있다(cdxgen AI-BOM 문서).

# AI 프로젝트 디렉토리에서 AI BOM 생성
cdxgen -t ai -o aibom.json .

# AI/ML 메타데이터(formulation)를 포함해 생성
cdxgen -t ai --include-formulation -o aibom.json .

OWASP AIBOM Generator는 Hugging Face 모델을 입력받아 CycloneDX 형식 AIBOM을 만들고 완전성 점수를 매긴다. OWASP Gen AI Security Project가 관리하며 Hugging Face Space로도 제공된다 (OWASP AIBOM Generator).

직접 실행 — cdxgen으로 생성해 보기

사전학습 모델(facebook/bart-large-cnn)을 불러오는 요약 앱(transformers, torch 의존)에 cdxgen을 실제로 돌린 결과다. 도구가 의존성 5건을 자동으로 식별해 CycloneDX 1.7 형식 BOM을 만든다.

$ cdxgen -t python --include-formulation -o aibom.json .
CycloneDX Generator 12.5.1 (Node.js)

생성된 components — 5건 (CycloneDX 1.7):
  transformers     4.44.2    pkg:pypi/transformers@4.44.2      license: 비어 있음
  torch            2.4.0     pkg:pypi/torch@2.4.0             license: 비어 있음
  numpy            1.26.4    pkg:pypi/numpy@1.26.4            license: 비어 있음
  tokenizers       0.19.1    pkg:pypi/tokenizers@0.19.1       license: 비어 있음
  huggingface-hub  0.24.6    pkg:pypi/huggingface-hub@0.24.6   license: 비어 있음

생성된 BOM의 컴포넌트 한 건은 다음과 같다. 식별 근거(evidence)는 채워지지만 licenses 필드는 비어 있다.

{
  "name": "transformers",
  "version": "4.44.2",
  "purl": "pkg:pypi/transformers@4.44.2",
  "type": "library",
  "evidence": {
    "identity": [
      { "field": "purl", "confidence": 0.5,
        "methods": [{ "technique": "manifest-analysis", "value": "requirements.txt" }] }
    ]
  }
}

그림 2. cdxgen 12.5.1 실행 출력 (실행일 2026-06-13, -t python --include-formulation)

형식 샘플 (CycloneDX ML-BOM)

아래는 CycloneDX 1.6 ML-BOM의 모델 컴포넌트 구조를 줄인 예시다. 키 구조는 CycloneDX 공식 스펙의 machine-learning-model 컴포넌트와 modelCard를 따른다. 라이선스가 비표준(SPDX ID가 없는 경우)이면 name으로 적는다.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    {
      "bom-ref": "model-llama31-8b",
      "type": "machine-learning-model",
      "group": "meta-llama",
      "name": "Llama-3.1-8B",
      "version": "1.0",
      "licenses": [
        { "license": { "name": "Llama 3.1 Community License" } }
      ],
      "modelCard": {
        "modelParameters": {
          "task": "text-generation",
          "architectureFamily": "llama",
          "datasets": [
            { "type": "dataset", "name": "사전학습 공개 코퍼스", "classification": "public" }
          ]
        },
        "considerations": {
          "useCases": ["사내 문서 요약"],
          "technicalLimitations": ["환각 가능성", "한국어 성능 편차"]
        }
      }
    }
  ]
}

SPDX 3.0을 쓴다면 AI 프로파일(AI Profile)과 데이터셋 프로파일(Dataset Profile)이 같은 정보를 표현한다(SPDX 3.0 AI Profile). 형식의 구체 필드와 생성 도구의 기술 상세는 ISO/IEC 42001 가이드 — AI SBOM에서 다룬다.

고려사항

• 인바운드 자재 반영(규격 의무): 외부에서 도입한 모델과 데이터셋이 AI SBOM에 빠지지 않도록, 인입 시점에 SBOM 항목을 생성하는 절차를 둔다. 이것은 shall 수준의 의무다.
• 생성은 도구, 검토는 사람: 생성 도구는 모델 카드에 적힌 라이선스를 그대로 옮긴다. 모델 카드 자체에 라이선스가 누락되거나 잘못 적힌 경우가 흔하므로, 생성된 AI SBOM의 라이선스와 출처 필드를 사람이 원문과 대조해 검토한다.
• 형식 일관성: 조직 내에서 SPDX와 CycloneDX 중 하나를 기본 형식으로 정해 도구와 저장소를 일관되게 운영한다. 두 형식 모두 모델과 데이터셋을 1급 구성요소로 다룬다.
• CI/CD 연동: AI SBOM은 한 번 만들고 끝나는 산출물이 아니다. 모델이나 데이터셋이 바뀔 때마다 다시 생성되도록 파이프라인에 연동한다.

3.9.2 절차 준수 입증 기록

준수 방법

입증자료 3.9.2는 절차가 실제로 지켜졌음을 보여주는 기록이다. AI SBOM 파일 자체와 함께, 언제 누가 생성하고 검토하고 승인했는지의 이력을 남긴다. CI/CD에서 자동 생성한다면 빌드 로그와 생성된 SBOM 아티팩트가 기록이 되고, Dependency-Track 같은 관리 도구에 업로드한 이력도 증거가 된다.

고려사항

• 생성 이력 보존: 공급한 AI 시스템의 버전별로 그 시점의 AI SBOM을 보관해 추적성을 확보한다.
• 승인 기록: 검토와 승인을 누가 했는지 기록한다. 거버넌스(3.10)의 수명주기 검토와 연결된다.

5. 참고

• 라이선스 의무 검토 절차: 3.5 라이선스 의무
• AI SBOM 형식·생성 도구 기술 상세: ISO/IEC 42001 가이드 — AI SBOM
• SBOM 관리 도구: Dependency-Track, cdxgen + Dependency-Track 연동
• 거버넌스와 수명주기 검토: 3.10 거버넌스