Research

• 1: 기업용 AI BOM 필드 요구사항 매트릭스 — 표준과 규제 근거로 정의한 필수/선택
• 1.1: 공급사 AI BOM 제출 요구사항
• 1.2: 자사 개발팀 AI BOM 작성 지침
• 1.3: 외부 모델과 데이터셋 도입 점검 체크리스트
• 1.4: AI BOM 도구 세트 설계 전략
• 2: 2026 SW 공급망 보안 강화 로드맵 살펴보기
• 3: G7 「AI를 위한 SBOM — 최소 요소」: 클러스터별 요소 단위로 본 AI 공급망 투명성 권고
• 4: OpenChain AI SBOM 컴플라이언스 관리 가이드: AI 공급망 컴플라이언스 프로그램의 최소 요구사항
• 5: 미국 AI 행정명령(2026-06-02)이 기업 오픈소스 관리자에게 의미하는 것
• 6: EU 오픈소스 전략: 기술 주권을 위한 오픈소스의 제도화
• 7: EU 사이버 복원력법(CRA) 취약점 보고 의무 — 2026-09-11 시행 대비 조사보고서

1 - 기업용 AI BOM 필드 요구사항 매트릭스 — 표준과 규제 근거로 정의한 필수/선택

1. 목적과 사용 맥락

기업의 오픈소스 관리 체계는 이미 공급사에 소프트웨어 부품 명세서(Software Bill of Materials, SBOM) 제출을 의무화하고 제출 요구사항을 운영하는 단계에 와 있습니다. AI 시스템은 같은 투명성 요구를 모델과 데이터셋까지 확장해야 하지만, 기존 SBOM 요구사항은 소프트웨어 구성요소만 다루므로 AI 고유 정보를 담지 못합니다. 이 보고서는 AI를 위한 부품 명세서(이하 AI BOM)에 어떤 필드를 필수로, 어떤 필드를 선택으로 요구할지를 국제 표준과 규제 근거로 정의합니다.

판정 대상 필드는 G7 사이버보안 작업반이 발표한 「AI를 위한 SBOM 최소 요소」의 50개 요소입니다. 이 50개를 행으로 두고, 권위 있는 표준 다섯 곳의 요구 강도를 대조해 필수와 선택을 가립니다.

같은 매트릭스를 기업의 세 가지 사용 맥락에서 다르게 적용합니다.

• 생산: 자사 AI 모델 개발팀이 AI BOM을 직접 작성할 때 채워야 하는 필드입니다.
• 도입: 외부 모델이나 데이터셋을 가져와 활용할 때 투명성과 위험을 점검하기 위해 확인해야 하는 필드입니다.
• 공급사 요구: 자사에 AI 모델을 공급하는 공급사에게 제출을 요구할 필드입니다.

%%{init: {'theme':'neutral','themeVariables':{'fontSize':'18px'}}}%%
flowchart TD
    M["AI BOM 필드 매트릭스<br/>G7 50요소<br/>필수 20 · 선택 30"]
    P["생산 관점<br/>자사 개발팀이<br/>AI BOM 작성"]
    C["도입 관점<br/>외부 모델·데이터셋<br/>투명성 점검"]
    S["공급사 관점<br/>공급사에 제출<br/>요구"]
    M --> P
    M --> C
    M --> S

그림 1. 하나의 필드 매트릭스를 세 가지 사용 맥락에서 적용 (조사 종합)

2. 방법론

2.1 합의 집계 대상 출처

필드별 필수 여부는 다음 다섯 출처의 요구 강도를 합산해 판정합니다.

• G7 「AI를 위한 SBOM 최소 요소」(BSI와 ACN 공동 주도 G7, 2026): 50개 요소를 모두 “최소 요소"로 권고합니다. 요소 단위로 필수와 선택을 구분하지 않으므로, 본 매트릭스에서 G7은 모든 요소에 “최소 요소로 지정됨” 1표를 부여합니다.
• SPDX 3.0.1: AI 프로파일의 AIPackage, Dataset 프로파일의 DatasetPackage, Core의 공통 클래스에서 각 속성의 카디널리티(필수 여부)를 명세가 직접 규정합니다.
• CycloneDX 1.6: JSON 스키마의 required 배열로 필수 필드를 규정합니다.
• NTIA 「소프트웨어 부품 명세서 최소 요소」(2021): 일반 소프트웨어 SBOM의 일곱 개 기준 데이터 필드를 규정합니다.
• OpenChain AI 적합성 가이드(Version 1, 2025): 프로세스 표준으로 데이터 필드를 규정하지 않으나, 라이선스 의무 절차가 모델과 데이터셋 라이선스의 식별·문서화를 강제합니다.

2.2 판정 규칙

필드의 존재 자체를 요구하는 출처가 두 곳 이상이면 필수, 그렇지 않으면 선택으로 판정합니다. G7이 모든 요소에 1표를 주므로, 실제 판정은 “다른 출처 한 곳 이상이 그 필드의 존재를 요구하는가"로 귀결됩니다.

존재를 요구한다는 것은 클래스 수준 필수 카디널리티(SPDX의 AIPackage/DatasetPackage 필수 속성), 문서 루트 필수(CycloneDX bomFormat/specVersion), NTIA의 일곱 기준 필드, OpenChain의 shall 수준 프로세스를 뜻합니다. 객체를 생성할 때만 강제되는 조건부 필수(예: 해시 객체 안의 알고리즘과 값, 구성요소 객체 안의 이름)는 “그 객체를 반드시 포함하라"는 요구가 아니므로 존재 요구로 세지 않았습니다. 다만 이런 조건부 필수나 무결성·보안상 가치가 큰 항목은 선택으로 두되 역할별 적용에서 권장으로 표시했습니다.

이 규칙을 적용한 결과, 50개 중 20개가 필수, 30개가 선택입니다.

2.3 규제 근거 표시

구속력 있는 규제가 해당 필드에 적용되는지는 별도 축으로 표시합니다. 합의 집계에는 넣지 않습니다. 어떤 규제도 AI BOM을 그 이름으로 강제하지 않기 때문입니다. 사이버 복원력법(Cyber Resilience Act, CRA)은 일반 소프트웨어 SBOM을, 인공지능법(AI Act)과 미국 식품의약국(Food and Drug Administration, FDA) 가이던스, 국내 제도는 문서화 의무를 요구합니다. 직접은 규제가 그 항목을 명시 요구하는 경우, 간접은 SBOM 항목은 아니나 문서화·취약점 처리 의무가 같은 정보를 사실상 요구하는 경우입니다.

3. 합의 결과 개관

클러스터별 필수와 선택 분포는 다음과 같습니다.

필수로 판정된 20개는 모두 식별과 추적의 기반입니다. 누가 만들었고(작성자, 생산자), 무엇인지(이름, 식별자, 버전), 언제 만들었고(타임스탬프), 무엇으로 구성되며(구성요소, 종속 관계, 데이터셋 내용), 어떤 라이선스인지(모델·데이터셋 라이선스)에 해당합니다. 표준 두 곳 이상이 한결같이 이 정보의 존재를 요구합니다.

반면 모델의 상세 속성(아키텍처, 학습 기법, 입출력 특성), 데이터셋의 통계·민감도, 보안 통제, 핵심성과지표는 G7만 최소 요소로 들 뿐 다른 표준이 존재를 강제하지 않아 선택으로 갈립니다. 이 항목들은 합의로는 선택이지만, 도입과 공급사 요구 맥락에서는 투명성·위험 평가에 직접 쓰이므로 역할별로 다시 끌어올립니다.

한 가지 구조적 사실을 짚어 둡니다. AI 고유 클러스터(모델, 데이터셋)의 필수 판정은 사실상 G7과 SPDX 3.0이 좌우합니다. NTIA는 일반 소프트웨어 SBOM이라 메타데이터와 식별 계통에만 기여하고, OpenChain은 라이선스 외에는 필드를 규정하지 않으며, CycloneDX는 루트 두 필드 외에는 모두 조건부 필수입니다. AI BOM의 필드 수준 표준은 아직 SPDX 3.0의 AI·Dataset 프로파일이 사실상 유일하게 촘촘합니다.

4. 필드 매트릭스

표기 약속은 다음과 같습니다. 출처 열은 필수(존재 요구), 조건부(객체 생성 시 강제), 근사(전용 필드 없이 관계나 일반 속성으로 우회), 선택, –(대응 없음)입니다. OpenChain의 필수(P)는 데이터 필드가 아니라 프로세스 강제를 뜻합니다. 역할 열은 필수, 권장, 선택, –이며, 표 폭을 고려해 생산·도입·공급사 역할 열은 §4.6 역할별 적용 요약 표로 분리했습니다.

4.1 메타데이터 클러스터

4.2 시스템 수준 속성 클러스터

4.3 모델 클러스터

4.4 데이터셋 속성 클러스터

4.5 인프라, 보안, 핵심성과지표 클러스터

보안 클러스터는 합의로는 전부 선택이지만, 취약점 참조와 사이버보안 정책 정보는 CRA와 FDA가 직접 요구하는 항목입니다. 합의 집계는 표준의 데이터 필드 규정만 보지만, 규제는 같은 정보를 의무로 요구합니다. 그래서 이 두 항목은 도입과 공급사 맥락에서 필수나 권장으로 상향했습니다. 규제 근거 표시가 역할별 적용을 조정하는 대표 사례입니다.

4.6 역할별 적용 요약

§4.1~4.5의 합의 판정을 생산·도입·공급사 세 맥락에 적용한 결과를 50개 요소 전체에 대해 한 표로 모았습니다. 역할 열은 필수, 권장, 선택, –입니다.

5. 역할별 적용 해설

5.1 생산 관점

자사 개발팀이 모델을 만들 때는 정보 접근성이 가장 좋으므로 요구 수준을 가장 높게 잡습니다. 합의 필수 20개는 그대로 필수입니다. 더해 모델과 데이터셋의 상세 속성, 해시, 학습 정보처럼 합의로는 선택인 항목도 생산 시에는 권장으로 작성하게 합니다. 생산자가 남기지 않으면 도입자와 공급망 하류가 영영 확보할 수 없는 정보이기 때문입니다.

5.2 도입 관점

외부 모델이나 데이터셋을 들여올 때는 투명성과 위험 평가에 직접 쓰이는 필드를 우선합니다. 식별 정보(이름, 식별자, 버전, 생산자)에 더해 모델 설명, 모델·데이터셋 라이선스, 데이터셋 출처, 데이터셋 민감도, 취약점 참조를 필수로 둡니다. 라이선스는 컴플라이언스 위험을, 출처와 민감도는 데이터 적법성과 개인정보 위험을, 취약점 참조는 보안 위험을 판단하는 근거입니다. 합의로는 선택이지만 도입 점검의 핵심이라 필수로 올렸습니다.

5.3 공급사 요구 관점

공급사에 제출을 요구하는 범위는 계약으로 강제 가능한 수준을 고려해 합의 필수 20개를 기본으로 합니다. 여기에 모델·데이터셋 라이선스, 데이터셋 출처와 민감도, 취약점 참조를 필수로 더합니다. 기존 소프트웨어 SBOM 공급사 요구사항이 식별과 의존성, 형식 준수를 강제하던 것과 같은 구조를, 모델과 데이터로 확장한 형태입니다.

6. 한계와 검증 필요 사항

이 매트릭스의 합의 판정은 표준 명세의 카디널리티와 최소 요소 규정에 근거하며, 규제 근거 표시는 별도 축입니다. 다음 항목은 1차 출처 접근 제약이 있어 별도 검증을 거쳐야 합니다.

NTIA 최소 요소의 1차 명세(ntia.gov)는 자동 조회가 차단되어 일곱 기준 필드를 공개 미러로 재확인했습니다. CRA Annex I와 AI Act 부속서, FDA 가이던스의 1차 원문(EUR-Lex, fda.gov)도 렌더링·차단 문제로 미러와 검색 집계로 교차 확인했습니다. 국내 AI 기본법의 학습데이터 관련 의무는 조항·항 단위까지 1차 조문으로 대조하지 못해 “간접(조문 미특정)“으로 표시했습니다. 이 항목들은 후속 검증 단계에서 1차 출처로 다시 확인합니다.

SPDX 3.0과 CycloneDX 1.6의 필드 카디널리티는 명세 클래스 정의와 JSON 스키마 원문에서 직접 확인했으므로 신뢰도가 높습니다.

7. 출처

주요 1차 출처는 다음과 같습니다.

A1. G7 Cybersecurity Working Group (2026). Software Bill of Materials for AI — Minimum Elements. BSI와 ACN이 공동 주도하고 그 외 G7 사이버보안 기관과 EU 집행위원회가 공동 발행. — 용도: 50요소 행 골격.

A2. SPDX Project (2024). System Package Data Exchange (SPDX) Specification, Version 3.0.1 — AI Profile, Dataset Profile, Core. https://spdx.github.io/spdx-spec/v3.0.1/ — 용도: 모델·데이터셋 필드 카디널리티.

A3. OWASP / ECMA International (2024). CycloneDX Bill of Materials Specification 1.6 (ECMA-424), JSON 스키마. https://cyclonedx.org/docs/1.6/json/ — 용도: 스키마 required 필드 판정.

A4. NTIA, U.S. Department of Commerce (2021). The Minimum Elements For a Software Bill of Materials (SBOM). https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom — 용도: 일반 SBOM 최소 요소.

A5. OpenChain Project AI Work Group (2025). Artificial Intelligence System Bill of Materials — Compliance Management Guide, Version 1. — 용도: 라이선스 의무 프로세스.

A6. European Parliament and Council (2024). Regulation (EU) 2024/2847 — Cyber Resilience Act, Annex I. — 용도: SBOM·취약점 처리 규제 근거.

A7. European Parliament and Council (2024). Regulation (EU) 2024/1689 — AI Act, Article 53, Annex IV, XI, XII. — 용도: 문서화와 투명성 규제 근거.

A8. U.S. FDA (2023). Cybersecurity in Medical Devices: Premarket Submissions; FD&C Act §524B. — 용도: 의료기기 SBOM 규제 근거.

A9. 과학기술정보통신부·국가정보원·KISA (2026). 「AI 일상화 시대를 준비하는 SW 공급망 보안 강화 로드맵」; 「인공지능 발전과 신뢰 기반 조성 등에 관한 기본법」. — 용도: 국내 제도 규제 근거.

8. 이 시리즈의 구성

이 글은 다섯 부분으로 이어지는 시리즈의 출발점입니다. 위 매트릭스를 세 가지 사용 맥락의 운영 문서로 옮기고, 이를 떠받칠 도구 세트 전략까지 함께 묶었습니다.

• 공급사 AI BOM 제출 요구사항 — 공급사에 제출을 요구할 필드와 제출 규약
• 자사 개발팀 AI BOM 작성 지침 — 자사 생산팀이 채워야 하는 필수·권장 항목
• 외부 모델과 데이터셋 도입 점검 체크리스트 — 외부 모델·데이터셋을 들여올 때의 위험 점검
• AI BOM 도구 세트 설계 전략 — 매트릭스를 정책으로 코드화하고 기존 도구와 엮는 전략

1.1 - 공급사 AI BOM 제출 요구사항

이 문서는 자사에 AI 모델이나 AI 시스템을 공급하는 공급사가 제출해야 하는 AI를 위한 부품 명세서(AI Bill of Materials, AI BOM)의 요구사항을 규정합니다. 기존 소프트웨어 부품 명세서(SBOM) 제출 요구사항을 모델과 데이터셋으로 확장한 것이며, 필수 항목은 「AI BOM 필드 요구사항 매트릭스」의 공급사 열에서 도출했습니다.

1. 표준 데이터 형식

AI BOM은 기계 판독이 가능한 표준 형식으로 제출해야 합니다. 다음 두 형식을 인정합니다.

두 형식 모두 동등하게 인정하나, 모델과 데이터셋의 필수 속성을 형식 차원에서 강제하는 SPDX 3.0을 권장합니다. 1.6 미만 CycloneDX나 2.x SPDX는 AI 전용 프로파일이 없으므로 제출 형식으로 인정하지 않습니다.

2. 필수 포함 정보

다음 항목은 모든 제출 AI BOM에 반드시 포함되어야 합니다. 값을 확인할 수 없는 항목은 비워 두지 말고 “확인 불가(unknown)“로 명시해야 합니다.

2.1 문서 메타데이터

2.2 시스템 수준 정보

2.3 모델 정보

2.4 데이터셋 정보

2.5 보안 정보

취약점 참조는 합의 기준으로는 선택이지만, 사이버 복원력법(Cyber Resilience Act)과 미국 식품의약국(FDA) 가이던스가 직접 요구하는 항목이므로 공급사 제출에서는 필수로 둡니다.

3. 식별자 규칙

모델과 데이터셋은 기계 판독이 가능한 표준 식별자로 식별해야 합니다.

• 모델 식별자는 Package URL(PURL) 또는 공통 플랫폼 열거(Common Platform Enumeration, CPE)를 사용합니다. 모델 저장소 경로나 커밋 해시 같은 내재적 식별자를 함께 제공할 수 있습니다.
• 데이터셋 식별자는 접근 가능한 URL이나 URI를 사용합니다.
• 식별자가 여럿이면 전부 포함합니다.

4. 라이선스, 출처, 민감도 요구 강화

기존 소프트웨어 SBOM 요구사항과 달리, AI BOM에서는 다음 세 항목을 특히 엄격하게 요구합니다.

라이선스는 모델 가중치와 데이터셋 각각에 대해 별도로 명시해야 합니다. 모델이 open weight, open architecture, open data 중 무엇에 해당하는지 구분하고, 라이선스 문서 링크를 제공해야 합니다. 데이터셋 출처는 단순 출처 표기를 넘어 수집 방법(웹 크롤링인지 상업적 계약인지), 전처리와 라벨링 단계, 합성 데이터 사용 여부까지 포함해야 합니다. 데이터셋 민감도는 개인식별정보, 저작권 보호 데이터, 금융이나 의료 같은 민감 데이터의 포함 여부를 표기해야 합니다.

5. 샘플 문서

다음은 CycloneDX 1.6 형식의 최소 AI BOM 골격입니다. 실제 제출에서는 위 2절의 모든 필수 항목을 채워야 합니다.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "metadata": {
    "timestamp": "2026-06-29T09:00:00Z",
    "authors": [{ "name": "공급사 정식 명칭" }],
    "component": { "type": "application", "name": "공급 AI 시스템", "version": "1.0.0" }
  },
  "components": [
    {
      "type": "machine-learning-model",
      "name": "공급 모델명",
      "version": "1.0",
      "bom-ref": "pkg:huggingface/org/model@1.0",
      "supplier": { "name": "모델 생산자" },
      "licenses": [{ "license": { "id": "Apache-2.0" } }],
      "modelCard": {
        "modelParameters": {
          "datasets": [
            { "type": "dataset", "name": "학습 데이터셋명", "classification": "public",
              "governance": { "owners": [{ "organization": { "name": "데이터 출처" } }] } }
          ]
        }
      }
    }
  ],
  "vulnerabilities": []
}

6. 제출 전 검증 체크리스트

공급사는 제출 전에 다음을 확인해야 합니다.

• 형식이 SPDX 3.0 이상 또는 CycloneDX 1.6 이상인가
• 2절의 모든 필수 항목이 채워졌거나 “확인 불가"로 명시됐는가
• 모델과 데이터셋이 표준 식별자로 식별되는가
• 모델 가중치와 데이터셋 각각에 라이선스가 명시됐는가
• 데이터셋 출처와 민감도가 표기됐는가
• 취약점 참조 링크가 제공됐는가
• 빌드 또는 모델 릴리스 완료 이후 시점에 생성됐는가

상세 점검 기준은 도입 점검 체크리스트와 공유합니다.

1.2 - 자사 개발팀 AI BOM 작성 지침

이 문서는 자사 개발팀이 AI 모델이나 AI 시스템을 만들 때 작성해야 하는 AI를 위한 부품 명세서(AI Bill of Materials, AI BOM)의 지침입니다. 생산 시점에는 정보 접근성이 가장 좋으므로 요구 수준을 가장 높게 잡습니다. 필수 항목은 「AI BOM 필드 요구사항 매트릭스」의 생산 열에서 도출했습니다.

생산팀이 남기지 않으면 도입팀과 공급망 하류가 영영 확보할 수 없는 정보가 많습니다. 그래서 합의 기준으로 선택인 모델과 데이터셋 상세 정보도 생산 시에는 권장으로 작성합니다.

1. 작성 원칙

AI BOM은 모델 학습이나 시스템 빌드가 끝난 뒤 생성합니다. 생성 시점의 수명주기 단계(빌드 이전, 빌드, 빌드 이후)를 메타데이터에 기록합니다. 형식은 SPDX 3.0 이상 또는 CycloneDX 1.6 이상을 사용하고, 가능하면 생성 도구로 자동 생성한 뒤 누락 항목을 수기로 보완합니다.

값을 확정할 수 없는 항목은 비워 두지 말고 “확인 불가"로 명시합니다. 모델이나 데이터셋을 갱신하면 AI BOM 버전과 타임스탬프를 함께 올립니다.

2. 필수 작성 항목

다음은 반드시 작성합니다. 매트릭스에서 표준 두 곳 이상이 존재를 요구한 항목입니다.

3. 권장 작성 항목

다음은 합의 기준으로 선택이지만, 생산 시점에만 정확히 기록할 수 있으므로 작성을 권장합니다. 특히 모델 카드와 데이터 카드를 운영한다면 그 내용을 AI BOM에 연결합니다.

4. 모델 해시와 무결성

모델 해시 값과 알고리즘은 합의 기준으로는 선택이지만 권장 강도가 높습니다. 가중치 파일이나 모델 아티팩트의 해시를 기록해 두면, 하류에서 모델 무결성을 검증할 수 있습니다. 해시 알고리즘은 인터넷 할당 번호 관리기관(IANA)의 해시 함수 명칭을 사용하고, 미국 국립표준기술연구소(NIST)가 승인한 알고리즘을 씁니다.

5. 데이터셋 출처와 민감도

생산팀은 학습에 사용한 데이터셋의 출처를 가장 잘 압니다. 출처, 수집 방법, 전처리와 라벨링 단계, 합성 데이터 여부를 기록하고, 개인식별정보나 저작권 보호 데이터, 민감 데이터의 포함 여부를 표기합니다. 이 정보는 인공지능법(AI Act)의 학습 데이터 문서화 의무와 국내 AI 기본법의 학습데이터 개요 요구에 대응하는 근거가 됩니다.

6. 작성 후 확인

• 2절 필수 항목이 모두 채워졌는가
• 3절 권장 항목 중 모델 카드나 데이터 카드로 확보 가능한 것을 연결했는가
• 모델 가중치와 데이터셋 각각에 라이선스를 명시했는가
• 생성 시점의 수명주기 단계를 기록했는가
• 모델이나 데이터셋 갱신 시 버전과 타임스탬프를 올렸는가

1.3 - 외부 모델과 데이터셋 도입 점검 체크리스트

이 체크리스트는 자사 개발팀이 외부 AI 모델이나 데이터셋을 가져와 활용할 때, AI를 위한 부품 명세서(AI Bill of Materials, AI BOM)를 근거로 투명성과 위험을 점검하는 기준입니다. 확인 항목은 「AI BOM 필드 요구사항 매트릭스」의 도입 열에서 도출했습니다.

도입 점검의 목적은 모델을 만드는 것이 아니라 들여오는 것이므로, 위험 평가에 직접 쓰이는 필드를 우선합니다. 라이선스는 컴플라이언스 위험을, 출처와 민감도는 데이터 적법성과 개인정보 위험을, 취약점 참조는 보안 위험을 판단하는 근거입니다.

1. AI BOM 존재와 형식

• 도입 대상에 AI BOM이 제공되는가
• 형식이 SPDX 3.0 이상 또는 CycloneDX 1.6 이상인가
• AI BOM의 타임스탬프가 도입 대상 버전과 일치하는가

AI BOM이 없거나 AI 전용 프로파일이 없는 형식이면, 도입 전 공급처에 요청하거나 자체적으로 최소 정보를 확보합니다.

2. 식별과 버전 (필수 확인)

3. 라이선스 점검 (필수 확인)

라이선스가 비어 있거나 사용 목적과 충돌하면 도입 보류 사유입니다. 모델 라이선스와 데이터셋 라이선스는 별개이므로 각각 확인합니다.

4. 데이터 적법성과 위험 (필수 확인)

데이터셋 출처가 불명확하거나 민감 데이터 포함 여부가 표기되지 않으면, 데이터 적법성과 개인정보 위험을 별도로 평가해야 합니다.

5. 보안 위험 (필수 확인)

취약점 참조는 사이버 복원력법과 미국 식품의약국 가이던스가 직접 요구하는 항목이므로, 도입 점검에서 필수로 확인합니다.

6. 권장 확인 항목

다음은 위험 수준이 높거나 규제 대상 용도일 때 추가로 확인합니다.

• 모델 타임스탬프와 생산자
• 모델 속성, 입출력 속성, 학습 속성
• 모델 해시 값과 알고리즘(무결성 검증)
• 데이터셋 내용과 해시
• 시스템 데이터 흐름과 데이터 사용
• 의도된 응용 분야와 자사 사용 목적의 일치 여부

7. 도입 판정

위 1절부터 5절까지의 필수 확인 항목을 모두 충족하면 도입 가능으로 판정합니다. 라이선스 충돌, 출처 불명확, 민감 데이터 미표기, 수용 불가 취약점 중 하나라도 해당하면 도입 보류로 두고 공급처에 보완을 요청하거나 대체 모델을 검토합니다.

판정 결과는 도입 대상의 AI BOM 식별자, 버전, 판정 일자와 함께 기록해 두어, 이후 재평가와 공급망 추적에 활용합니다.

1.4 - AI BOM 도구 세트 설계 전략

7개 도구 범주를 공식 리포지토리와 문서로 조사한 결과를 근거로, 무엇을 기존 도구로 재사용하고 무엇을 확장하거나 새로 만들지, 어떤 순서로 구축하며, 매트릭스를 어떤 정책 스키마로 정의할지를 정리합니다. 확보 전략은 미리 정하지 않고 조사 결과로 판단하며, 기존 SBOM 플랫폼(Dependency-Track)을 이미 운영 중이라는 전제를 둡니다.

1. 핵심 판단 세 가지

생성과 검증, 저장, 모델 스캔의 표준 경로는 이미 오픈소스로 작동합니다. cdxgen의 aibom 명령이 CycloneDX 1.6 AI BOM을 실제로 만들고, sbomqs와 OPA가 필드 적합성을 검사하며, Dependency-Track이 소프트웨어 계층을 받고, ModelScan과 sigstore model-signing이 모델 무결성을 보강합니다. 자체 구축을 처음부터 다 할 필요가 없습니다.

포맷은 CycloneDX 1.6으로 단일화하는 편이 현실적입니다. SPDX 3.0 AI 프로파일은 표현력이 더 풍부하지만 이를 실제로 생성하는 성숙한 도구가 없고, Dependency-Track이 SPDX를 인입하지 못합니다. SPDX 3.0은 표준 추종 대상으로 두되 운영 1차 포맷은 CycloneDX로 잡습니다.

신규 구축이 불가피한 곳은 좁고 분명합니다. AI 고유 필드를 검사하는 정책 계층, 모델과 데이터셋을 1급 객체로 다루는 인벤토리, 라이선스 사용 제한 판정입니다. 나머지는 재사용이나 확장으로 메워집니다.

2. 영역별 재사용 판정

요약하면 열세 영역 중 일곱은 재사용, 셋은 확장, 셋은 신규입니다. 신규 셋(AI·역할별 적합성 규칙, 모델·데이터 인벤토리, 라이선스 사용 제한 판정)이 이 프로젝트의 고유 가치가 모이는 지점입니다.

3. 구축 우선순위

P0 — 작동하는 최소 파이프라인 (재사용 위주)

가장 먼저 기성 도구를 엮어 끝에서 끝까지 도는 파이프라인을 세웁니다. 생성은 cdxgen aibom으로 CycloneDX 1.6을 만들고, 모델 파일은 ModelScan으로 스캔하고 sigstore로 서명하며, 결과를 Dependency-Track에 올려 소프트웨어 계층 취약점과 영향분석을 얻습니다. 검증은 sbomqs custom policy로 필수 필드 존재를 점검합니다. 이 단계는 거의 전부 재사용이라 빠르게 가치를 냅니다.

P1 — AI 고유 계층 확장

다음으로 신규 가치를 얹습니다. 매트릭스를 정책 스키마로 코드화해 역할별 적합성 검사를 구현하고(4절), 모델과 데이터셋을 CycloneDX properties나 외부 참조로 실어 인벤토리 추적성을 확보합니다. 라이선스 파이프라인에 AI 라이선스 사전(RAIL, OpenRAIL, Llama, Gemma, OpenMDW, CDLA)을 보강하고, 모델 위험은 huntr CVE를 NVD 경유로 받습니다.

P2 — 신규·연구 영역

마지막은 표준과 연구가 더 익어야 하는 부분입니다. 데이터셋 통계나 바이어스 같은 심층 필드의 자동 추출, 라이선스 사용 제한의 자동 판정, 데이터 오염은 탐지 대신 출처와 무결성 추적성으로 다룹니다. SPDX 3.0 생성은 도구 생태계가 성숙하면 합류시키되 지금은 표준 추종 대상으로만 둡니다. Dependency-Track의 모델·데이터 분류자 지원(이슈 #4361)이 들어오면 P1의 우회책을 1급 인벤토리로 승격합니다.

4. 정책 스키마 설계

매트릭스의 “요소 × 필수/선택 × 역할"을 기계 판독 정책으로 정의하는 것이 이 도구 세트의 핵심입니다. 조사 결과 어떤 도구도 역할별 필수 집합을 1급 개념으로 갖지 않으므로, 직접 설계합니다. 두 계층으로 나눕니다.

4.1 필드 레지스트리

G7 50요소 각각을 CycloneDX 경로(그리고 장래 SPDX 경로)에 매핑하는 표를 한곳에 둡니다. 「AI BOM 필드 요구사항 매트릭스」가 이미 요소별 출처 매핑을 담고 있으므로, 이를 기계 판독용으로 옮기면 다음과 같은 모양입니다.

# field-registry.yaml — G7 요소를 BOM 경로에 매핑
model_license:
  g7: 모델 라이선스
  cyclonedx: "components[?type=='machine-learning-model'].licenses"
  spdx: "Relationship(hasDeclaredLicense) from AIPackage"
dataset_provenance:
  g7: 데이터셋 출처
  cyclonedx: "components[?type=='data'].data[].governance"
  spdx: "DatasetPackage.originatedBy / dataCollectionProcess"
vulnerability_referencing:
  g7: 취약점 참조
  cyclonedx: "vulnerabilities[] 또는 externalReferences[?type=='vcs']"
  spdx: "VulnAssessmentRelationship"

4.2 역할별 정책 파일

생산, 도입, 공급사 각각의 필수 집합을 별도 정책 파일로 둡니다. 매트릭스의 역할 열을 그대로 옮기면 됩니다.

# policy/supplier.yaml — 공급사 제출 시 필수 요소 (§4.6 공급사 필수 20개)
required:
  - sbom_author
  - sbom_data_format_name
  - sbom_data_format_version
  - sbom_timestamp
  - sbom_dependency_relationship
  - system_name
  - system_components
  - system_producer
  - system_version
  - model_name
  - model_identifier
  - model_version
  - model_producer
  - model_license
  - dataset_name
  - dataset_identifier
  - dataset_provenance
  - dataset_sensitivity
  - dataset_license
  - vulnerability_referencing
recommended:
  - model_timestamp
  - dataset_content
  - model_hash_value

4.3 판정 엔진

엔진은 두 가지를 함께 권합니다. 빠른 시작은 sbomqs custom policy(YAML)로, 별도 엔진 학습 없이 역할별 파일을 오늘 바로 운용하고 충족률을 점수로 환산합니다. 표현력이 필요한 곳은 OPA/Rego(conftest)로, 입력 BOM의 역할 값을 보고 필수 집합을 분기합니다. Rego는 필드 레지스트리의 경로를 따라가 존재 여부를 평가하므로 조건부 필수나 교차 필드 일관성까지 표현할 수 있습니다.

# policy/aibom.rego — 역할별 필수 필드 검사 골격
package aibom

deny[msg] {
    role := input.metadata.properties[_].value  # "supplier" 등
    req := data.policy[role].required[_]
    not field_present(req)
    msg := sprintf("필수 요소 누락: %s (역할: %s)", [req, role])
}

OSCAL은 보안 통제 표현용이라 SBOM 필드를 담기에는 과한 도구이고, 검증을 스스로 실행하지 않으므로 채택하지 않습니다. 다만 규제·감사용 상위 산출물(요구사항 카탈로그, 평가 결과 보고)을 연방 친화 포맷으로 남길 필요가 생기면 그때만 고려합니다.

5. 참조 아키텍처와 Dependency-Track 통합

AI 시스템의 BOM은 소프트웨어 의존성 계층과 모델·데이터셋 계층으로 갈립니다. Dependency-Track은 앞 계층을 지금 바로 처리하고, 뒤 계층은 아직 1급으로 받지 못합니다(이슈 #4361은 조사 시점에 open 상태이며 추후 변경될 수 있습니다). 그래서 계층을 나눠 통합합니다.

%%{init: {'theme':'neutral','themeVariables':{'fontSize':'18px'}}}%%
flowchart TD
    GEN["생성<br/>cdxgen aibom<br/>CycloneDX 1.6"]
    SEC["보강<br/>ModelScan 스캔<br/>sigstore 서명"]
    POL["검증<br/>역할별 정책<br/>sbomqs, Rego"]
    DT["저장·취약점<br/>Dependency-Track<br/>SW 계층 매칭"]
    INV["모델·데이터 계층<br/>properties 우회<br/>또는 분류자 대기"]
    GEN --> SEC
    SEC --> POL
    POL --> DT
    POL --> INV

그림 2. AI BOM 도구 파이프라인과 계층 분리 (조사 종합)

소프트웨어 계층은 추가 작업이 거의 없습니다. cdxgen이 ML 프로젝트의 PyPI나 npm 의존성을 CycloneDX로 만들어 Dependency-Track에 올리면, OSV와 NVD로 취약점을 상관하고 “이 컴포넌트를 쓰는 프로젝트는?” 영향분석까지 제공합니다. huntr가 ML 라이브러리에 발급한 CVE도 NVD를 거쳐 잡힙니다.

모델·데이터셋 계층은 분류자 지원이 올 때까지 우회합니다. 단기로는 모델과 데이터셋을 일반 컴포넌트로 올리되 모델 카드 핵심 필드를 CycloneDX properties나 외부 참조로 실어 보존합니다. 검색성은 제한되지만 추적은 됩니다. 모델 파일 고유 위협(안전하지 않은 pickle, 백도어 가중치)은 CVE 매칭 모델에 맞지 않으므로 ModelScan으로 따로 점검하고 그 결과를 정책이나 티켓으로 연계합니다.

6. 한계와 검증 필요 사항

이 전략의 도구 사실은 각 프로젝트의 공식 리포지토리와 문서로 확인했습니다. 다음은 채택 전 재확인이 필요합니다.

라이선스 영역에는 표기와 실제의 불일치 위험이 있습니다. 플랫폼에 선언된 라이선스가 모델·데이터셋의 실제 구성요소 라이선스와 어긋나는 이른바 permissive-washing은 잘 알려진 위험이며, 기존 소프트웨어 라이선스 도구가 모델 카드나 데이터셋 카드를 파싱하고 학습 데이터 출처를 추적하지 못한다는 한계와 맞물립니다. 도구 세트는 이를 자동 탐지로 약속하지 않고 선언 라이선스와 산출물의 일치 검증을 신규 구축 대상으로 남겨 둡니다.

Dependency-Track의 모델·데이터 분류자 지원 시점(#4361)은 외부 일정이라 통제할 수 없습니다. P1의 모델·데이터 인벤토리는 이 일정에 의존하므로, 우회책(properties 보존)을 기본으로 두고 분류자 지원이 들어오면 승격하는 방식으로 설계해야 합니다.

GUAC의 AI 전용 처리, OSV의 모델 전용 레코드 체계, huntr Insights와 ModelScan 결과를 Dependency-Track이 직접 소비하는 커넥터는 모두 부재로 확인되거나 미확인(unverifiable)입니다. 모델 위험 피드와 SBOM 인벤토리를 잇는 표준은 아직 비어 있어, 이 연계는 자체 글루 코드로 메워야 합니다.

데이터 오염 탐지는 production 도구가 없습니다. 도구 세트에서 오염 자동 탐지를 약속하지 않고, 데이터 출처와 해시, 검증 통과 여부를 기록하는 추적성과 예방 통제로 한정합니다.

7. 참고문헌

본문의 도구 판정은 각 프로젝트의 공식 리포지토리와 문서를 1차 출처로 확인했습니다. 접속 시점은 모두 2026-06입니다.

A1. CycloneDX / cdxgen 프로젝트. cdxgen — AI/ML BOM 생성과 aibom CLI, --spec-version. https://github.com/CycloneDX/cdxgen (접속: 2026-06). — 용도: cdxgen aibom이 CycloneDX 1.6 AI BOM을 자동 생성한다는 근거.

A2. CycloneDX. Machine Learning Bill of Materials (ML-BOM) 역량 소개. https://cyclonedx.org/capabilities/mlbom/ (접속: 2026-06). — 용도: CycloneDX 1.6이 machine-learning-model과 modelCard를 정의한다는 표준 근거.

A3. SPDX. SPDX 3.0.1 — AI Profile 사양. https://spdx.github.io/spdx-spec/v3.0.1/model/AI/AI/ (접속: 2026-06). — 용도: SPDX 3.0 AI 프로파일이 사양 차원에서 존재한다는 근거(표현력 비교).

A4. SPDX. tools-python (spdx-tools) — 3.0 실험적 쓰기 전용, 프로덕션 비권장. https://github.com/spdx/tools-python (접속: 2026-06). — 용도: SPDX 3.0 AI 프로파일을 생성하는 성숙한 도구가 부재하다는 근거.

A5. interlynk-io. sbomqs — 정책 가이드(custom policy, required 타입, feature 점수화). https://github.com/interlynk-io/sbomqs/blob/main/docs/guides/policy.md (접속: 2026-06). — 용도: sbomqs가 사용자 정의 정책으로 필드 존재를 강제하고 충족률을 점수화한다는 근거.

A6. Open Policy Agent. Conftest — 구성 파일에 대한 OPA/Rego 정책 평가. https://github.com/open-policy-agent/conftest (접속: 2026-06). — 용도: CycloneDX/SPDX JSON을 Rego로 평가해 역할별 필수 집합을 분기한다는 근거.

A7. OWASP Dependency-Track. 정책 컴플라이언스 문서(조건 종류, regex 값). https://docs.dependencytrack.org/usage/policy-compliance/ (접속: 2026-06). — 용도: Dependency-Track 정책 엔진이 라이선스·취약점·컴포넌트 좌표 중심이며 프로젝트/태그 단위 정책이 가능하다는 근거.

A8. DependencyTrack. 이슈 #4361 — CycloneDX 1.5/1.6 분류자(machine-learning-model·data) 지원 요청. https://github.com/DependencyTrack/dependency-track/issues/4361 (접속: 2026-06). — 용도: Dependency-Track이 모델·데이터 분류자와 modelCard를 아직 인입하지 못한다는 근거(조사 시점 open).

A9. Protect AI. ModelScan — 모델 직렬화 공격 정적 스캐너(JSON 리포트, 종료코드). https://github.com/protectai/modelscan (접속: 2026-06). — 용도: 모델 파일 직렬화 스캔이 CI 삽입 가능한 수준으로 성숙했다는 근거.

A10. Sigstore / OpenSSF. model-transparency (model-signing) — DSSE + in-toto 모델 서명. https://github.com/sigstore/model-transparency (접속: 2026-06). — 용도: 모델 서명·출처 보증이 BOM 무결성·출처 필드에 매핑된다는 근거.

A11. Z. Tian 외 (2025). Data Poisoning in Deep Learning: A Survey. https://arxiv.org/html/2503.22759v1 (접속: 2026-06). — 용도: 데이터 오염 탐지가 여전히 연구 단계이며 범용 production 도구가 없다는 근거.

A12. AboutCode. ScanCode Toolkit — 라이선스·저작권 텍스트 매칭 엔진. https://github.com/aboutcode-org/scancode-toolkit/ (접속: 2026-06). — 용도: 라이선스 식별 엔진을 재사용하되 AI 라이선스 텍스트 보강이 필요하다는 근거.

A13. Responsible AI Licenses (RAIL). FAQ / BigScience OpenRAIL-M — 파생 전파되는 사용 기반 제한. https://www.licenses.ai/faq-2 (접속: 2026-06). — 용도: RAIL 계열의 행위 제한을 기계가 읽고 자동 판정하는 표준이 부재하다는 근거.

A14. LF AI & Data. Simplifying AI Model Licensing with OpenMDW. https://lfaidata.foundation/blog/2025/07/22/simplifying-ai-model-licensing-with-openmdw/ (접속: 2026-06). — 용도: OpenMDW가 모델과 데이터, 가중치를 묶는 허용형 라이선스로 SPDX에 등재됐다는 근거(AI 라이선스 사전 보강 대상).

A15. Protect AI. huntr — AI와 ML 대상 버그바운티이자 CNA. https://huntr.com/ (접속: 2026-06). — 용도: huntr가 발급한 CVE가 NVD를 거쳐 Dependency-Track 매칭에 유입된다는 근거.

A16. Google와 OpenSSF. OSV.dev — 오픈소스 취약점 데이터베이스. https://osv.dev/ (접속: 2026-06). — 용도: OSV가 ML 라이브러리 취약점을 포함하나 모델 가중치 자체 위험은 수록하지 않는다는 근거.

A17. Trail of Bits. Fickling — pickle 정적 분석 도구. https://github.com/trailofbits/fickling (접속: 2026-06). — 용도: 고위험 pickle 정밀 검사 도구 근거.

A18. OSS Review Toolkit. ORT — 라이선스 컴플라이언스 오케스트레이션. https://github.com/oss-review-toolkit/ort (접속: 2026-06). — 용도: 정책 룰 엔진과 SBOM 리포터를 재사용한다는 근거.

A19. OpenSSF. GUAC — SBOM 그래프와 영향분석. https://guac.sh/ (접속: 2026-06). — 용도: 영향분석을 보강하는 선택지이며 AI 전용 처리는 미확인이라는 근거.

2 - 2026 SW 공급망 보안 강화 로드맵 살펴보기

인용·논평 안내. 본 글은 과학기술정보통신부, 국가정보원, 한국인터넷진흥원이 공개 발행한 「AI 일상화 시대를 준비하는 SW 공급망 보안 강화 로드맵」(2026-06-24)을 저작권법 제28조에 따라 출처를 밝혀 인용·논평한 글입니다. 원문의 표와 도식은 복제하지 않았고, 본문 서술과 도식은 외부 1차 출처를 근거로 한 자체 저작물입니다. 저작자 표시: 과학기술정보통신부, 국가정보원, 한국인터넷진흥원, 「AI 일상화 시대를 준비하는 SW 공급망 보안 강화 로드맵」, 2026-06-24.

요약 정부는 2026년 6월 24일 향후 3년의 소프트웨어 공급망 보안 정책 방향을 담은 로드맵을 공개했습니다. 핵심은 소프트웨어 자재명세서(Software Bill of Materials, SBOM)를 중심에 둔 투명성 관리 모델, 기업의 보안 점검을 돕는 테스트베드와 컨설팅, 우수기업을 가려내는 시범인증, 그리고 빠른 탐지·대응 체계입니다. 전체 SW기업의 81%가 10인 미만인 산업 구조를 의식해 중소기업 부담 경감을 곳곳에 배치한 점이 두드러집니다. 미국 식품의약국(FDA) 의료기기 인허가와 EU 사이버복원력법(Cyber Resilience Act, CRA)이 이미 SBOM을 시장 진입 조건으로 만든 만큼, 이 로드맵은 수출기업, 공공 SW 납품기업, 중소 SW기업의 실무에 직접 맞닿아 있습니다.

1. 로드맵의 성격과 발표 경위

정부는 2026년 6월 24일 서울 양재 aT센터 공급망보안워크숍에서 「AI 일상화 시대를 준비하는 SW 공급망 보안 강화 로드맵」을 공개했습니다A1·B-news-zdnet. 과학기술정보통신부, 국가정보원, 한국인터넷진흥원(Korea Internet & Security Agency, KISA)이 관계부처 합동으로 마련했고, 발행처는 KISA입니다A1. 법령이나 고시가 아니라 향후 3년의 정책 방향을 제시하는 행정계획 성격의 문서로, 개별 과제의 상당수는 법·제도 정비와 가이드라인 발간, 인증제 개편을 거쳐야 규범력을 얻습니다A1.

발표는 예고된 흐름을 따랐습니다. 정부는 2024년 「SW 공급망 보안 가이드라인 1.0」을 발표할 때부터 하반기에 산·학·연 합동 태스크포스를 꾸려 제도화 방향을 논의한 뒤 로드맵을 마련하겠다고 밝혔고D6, 2025년 12월 24일 과기정통부와 국정원이 범정부 협력체계 구축에 합의한 뒤B-news-etnews 이번 발표로 이어졌습니다. 정부는 일관되게 2027년 제도화를 목표로 설명해 왔습니다B-news-zdnet.

로드맵은 “안전하고 책임 있는 공급망 보안 체계의 전환을 통한 사이버 복원력 확보"를 비전으로 내걸고, 이를 예방·복원·기반의 세 축으로 수렴시켰습니다A1. 그 아래 세 개 추진 전략과 아홉 개 세부과제가 놓입니다.

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'19px'}, 'flowchart': {'nodeSpacing': 50, 'rankSpacing': 70}} }%%
flowchart TB
    V["비전<br/>SW 공급망<br/>사이버 복원력 확보"]
    V --> A["예방<br/>위협 예방<br/>역량 강화"]
    V --> B["복원<br/>신속한 탐지·<br/>대응 체계"]
    V --> C["기반<br/>정책·제도적<br/>기반 조성"]

    style V fill:#fff3e0,stroke:#ef6c00,stroke-width:2px
    style A fill:#e3f2fd,stroke:#1565c0,stroke-width:1.5px
    style B fill:#e3f2fd,stroke:#1565c0,stroke-width:1.5px
    style C fill:#e3f2fd,stroke:#1565c0,stroke-width:1.5px

그림 1. 로드맵의 비전과 세 추진 전략 (본 보고서 정리; 로드맵A1 근거).

2. 예방 — 보안 내재화와 SBOM 투명성

예방 전략은 소프트웨어 생애주기 전반에 보안을 내재화하는 기준과 가이드를 만드는 데서 출발합니다. 로드맵은 미국 표준기술연구소(National Institute of Standards and Technology, NIST)의 안전한 소프트웨어 개발 프레임워크(Secure Software Development Framework, SSDF, SP 800-218)를 참고한 “안전한 SW 개발 방법론"을 제시하고, 기획설계와 개발, 테스트, 배포 단계별로 보안 요구사항 정의, 시큐어 코딩, 취약점 재검증, 코드 서명 같은 활동을 배치하겠다고 밝혔습니다A1·B5. 선행 자료인 「SW 공급망 보안 가이드라인 1.0」은 실무에서 쓸 수 있는 2.0으로 개선합니다. 라이선스 중심이던 오픈소스 관리를 보안 측면으로 넓히고, 자체 개발 코드 위주이던 개발 보안을 공급망 전반으로 확대하며, 보안 준수 자동화 도구 활용을 새로 더하는 방향입니다A1·A2.

투명성 제고 과제의 핵심 수단이 SBOM입니다. SBOM은 소프트웨어 구성요소 정보를 기술하는 명세서로, 국내에서는 SW 구성요소 명세서 등으로도 불립니다. 로드맵은 SBOM 관리 모델을 우선 적용할 대상으로 수출기업과 파급력 높은 분야를 꼽았습니다A1. 수출기업의 경우 미국 FDA 의료기기 인허가, 미국 상무부의 커넥티드카 SBOM 관리의무, EU CRA의 디지털 요소 기기 SBOM 의무가 직접적 동기이고A1·B7·B1, 파급력 높은 분야로는 보안 SW, 금융·교통 등 사회 기반 SW, 건강·의료 등 민감정보 관리 SW가 포함됩니다A1.

데이터 형식은 이미 정해진 셈입니다. 국제표준화기구(ISO)는 리눅스 재단의 SPDX를 ISO/IEC 5962:2021로 표준화했고C4, OWASP의 CycloneDX는 ECMA-424로 표준화돼 2025년 12월 공표됐습니다C5. 로드맵이 SBOM 항목을 미국 통신정보관리청(National Telecommunications and Information Administration, NTIA)의 「SBOM 최소 요소」(2021)와 CRA 요건을 의식해 “이중 규제로 작용하지 않도록 최소한으로 도출"하겠다고 한 것은 이 국제 형식과의 정합을 노린 설계입니다A1·C1. 형식 호환은 출발점이고, 로드맵 스스로 남은 과제로 꼽은 것은 SBOM의 신뢰도 검증과 그 안에 담긴 취약점 정보를 안전하게 유통하는 방안입니다A1. SBOM은 투명성을 높이는 동시에 어떤 구성요소에 어떤 취약점이 있는지를 공격자에게도 드러낼 수 있어, 생성과 공유 사이의 균형 설계가 후속 가이드라인의 관건입니다A1.

3. 복원 — 빠른 탐지와 위험관리, 기업 부담 경감

탐지·대응 전략은 KISA가 2012년 10월부터 운영해 온 보안취약점 신고포상제(버그바운티)의 범위를 넓히고D2, 조정된 취약점 공개(Coordinated Vulnerability Disclosure, CVD)와 취약점 공개 정책(Vulnerability Disclosure Policy, VDP)을 단계적으로 확대하는 것을 골자로 합니다A1. 로봇청소기, IP카메라 같은 사물인터넷(Internet of Things, IoT) 가전과 태양광 인버터 등 정보통신망연결기기를 대상으로 보안 실태점검을 도입하기 위해 정보통신망법(정보통신망 이용촉진 및 정보보호 등에 관한 법률) 개정을 추진합니다A1.

위험관리 체계는 공공과 민간으로 나뉩니다. 공공분야에서는 SBOM 관리체계를 개발하면서 신뢰성 보장 단계에 취약점 영향도 분석 정보(Vulnerability Exploitability eXchange, VEX)를 포함하고, 공공분야 SBOM 통합 관리 시스템과 취약점 정보 DB를 단계적으로 구축합니다A1. 민간분야에서는 고위험 취약점 상시 관리체계를 만들고, 취약점 발견 시 제조사 패치 요청과 백신SW 일괄 삭제를 거치는 클리닝 서비스(C-Clean)로 대응 기간을 “평균 4개월 이상에서 3일 내로” 단축하겠다는 목표를 제시했습니다A1.

기업이 실제로 체감하는 지원은 점검과 진단, 도구와 인력 보급에 모여 있습니다. 로드맵은 개발보안허브와 판교 국가사이버안보센터(National Cyber Security Center, NCSC) 같은 기존 시설을 활용해 SBOM 생성·취약점 점검 도구를 쓸 수 있는 테스트베드를 확충하고, 의료기기 인허가나 EU CRA 같은 글로벌 규제 점검도 메뉴에 넣겠다고 밝혔습니다A1. 중소 SW 개발기업을 대상으로는 개발 인프라와 관리체계를 분석·진단하는 컨설팅을 2026년부터, 클라우드 기반 개발환경과 보안 솔루션 보급을 2027년부터 배치했습니다A1. 전체 SW기업의 81%가 10인 미만이라는 산업 구조(2023년 SW산업 실태조사, 종사자 규모별 합계 43,932개)를 명시하고 그에 맞춘 지원을 설계한 점이 로드맵 전반의 특징입니다A1·D1.

4. 기반 — 정책체계, 시범인증, 글로벌 협력

기반 조성 전략에서는 과기정통부와 국정원이 (가칭)범정부 SW 공급망 보안협의체를 공동 주관하고, 의료기기, 자동차, 공공정보시스템, 금융, 보안의 다섯 개 분과로 운영합니다A1. 법·제도 정비의 중심에는 시범인증이 있습니다. 정부는 SW 공급망 보안관리를 검증해 우수기업 확인서((가칭) SSS Verified, Software Supply-Chain Security Verified)를 발급하고, 제도화 국가와 상호인정(Mutual Recognition Agreement, MRA)을 추진하며, 정보보호 관리체계 인증(ISMS), 클라우드 보안인증(CSAP), IoT 보안인증 안에 공급망 보안 시험평가 요소를 반영해 정규 제도화하겠다고 밝혔습니다A1. 새 인증을 따로 만들기보다 기존 제도에 얹는 선택을 한 점이 눈에 띕니다.

공공 조달 쪽 변화도 분명합니다. 정보화사업에 SBOM 제출과 취약점 대응 절차, 공급망 사이버보안 위험관리 절차서가 과제로 들어갔고, 보안적합성 검증은 국가 망 보안체계(National Network Security Framework, N2SF) 등을 고려해 대상을 넓히면서 SBOM 제출 확인을 결합합니다A1·D3. N2SF는 업무·데이터 중요도에 따라 보안 수준을 차등 적용하는 다층보안 접근으로, 보안가이드라인 정식판 1.0이 2025년 9월 30일 공개돼 2026년 사이버보안 평가에 반영됐습니다D3·D-news-boan.

글로벌 협력 과제는 두 다자 협력체와 연결됩니다. 글로벌 사이버보안 라벨링 이니셔티브(Global Cybersecurity Labelling Initiative, GCLI)는 IoT 보안인증 라벨의 상호인정과 단일 표준 제정을 논의하는 협력체로, 2025년 10월 23일 싱가포르 국제사이버위크에서 11개 창립 회원으로 출범했고 한국의 과기정통부와 KISA가 창립 회원으로 참여합니다A10. 로드맵은 이와 함께 글로벌 정부 전문가 포럼(Global Government Expert Forum, GGEF), 미국 사이버보안·인프라보안청(Cybersecurity and Infrastructure Security Agency, CISA), EU 집행위 정보통신총국(DG CONNECT), 영국 과학혁신기술부(DSIT)와의 협력을 글로벌 진출 지원의 통로로 제시했습니다A1.

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'19px'}, 'flowchart': {'nodeSpacing': 45, 'rankSpacing': 60}} }%%
flowchart TB
    G1["미국 NIST SSDF<br/>· EO 14028"]
    G2["미국 FDA §524B<br/>· EU CRA<br/>(SBOM 의무)"]
    G3["EU CRA<br/>취약점 보고·CVD"]
    G4["미국 Cyber Trust Mark<br/>· 영국 PSTI"]

    G1 --> T1["안전한 SW<br/>개발 방법론"]
    G2 --> T2["SBOM<br/>관리모델"]
    G3 --> T4["CVD/VDP 확대"]
    G4 --> T8["시범인증·<br/>MRA·사후관리"]

    style G1 fill:#eceff1,stroke:#455a64,stroke-width:1.5px
    style G2 fill:#eceff1,stroke:#455a64,stroke-width:1.5px
    style G3 fill:#eceff1,stroke:#455a64,stroke-width:1.5px
    style G4 fill:#eceff1,stroke:#455a64,stroke-width:1.5px
    style T1 fill:#e3f2fd,stroke:#1565c0,stroke-width:1.5px
    style T2 fill:#e3f2fd,stroke:#1565c0,stroke-width:1.5px
    style T4 fill:#e3f2fd,stroke:#1565c0,stroke-width:1.5px
    style T8 fill:#e3f2fd,stroke:#1565c0,stroke-width:1.5px

그림 2. 로드맵이 참조한 글로벌 제도와 정책 과제의 대응 관계 (본 보고서 정리; 외부 출처는 §5 참조).

로드맵은 신기술 대응을 별도 연구 과제로 분리했습니다. AI 등 신기술 일상화에 대응하는 공급망 보안 모델 연구를 2027년 이후 과제로 두었고A1, AI용 SBOM의 데이터 층위(학습 데이터, 모델 가중치 등)는 일반 SW 공급망을 중심에 둔 이번 로드맵의 직접 범위에 포함되지 않았습니다.

5. 글로벌 규제가 만든 배경

로드맵이 SBOM과 시범인증, 상호인정을 핵심 수단으로 삼은 데에는 수출기업이 마주한 해외 규제가 있습니다. 로드맵이 인용한 기업 인터뷰가 이를 단적으로 보여줍니다. 디지털 의료기기 제조기업이 FDA 인허가 단계에서 SBOM 요구로 대응에 곤란을 겪었고, 미국에 진출한 정보보호기업은 연방정부 SW 납품 중 SBOM 관리요건 미충족 시 차년도 계약 불가를 통보받았으며, 인공지능 솔루션 개발기업은 글로벌 금융기업 납품 준비 중 사이버보안 요건 미충족으로 계약이 무산됐습니다A1.

이들 규제는 대부분 2021~2024년 사이에 확정됐습니다. EU 사이버복원력법(Regulation (EU) 2024/2847)은 디지털 요소를 가진 제품에 수평적 사이버보안 요건을 부과하는 규정으로, 2024년 12월 10일 발효됐습니다B1·B2. 제14조 보고 의무는 2026년 9월 11일부터, 적합성 평가와 CE 마킹을 포함한 본질적 의무 전반은 2027년 12월 11일부터 적용됩니다B2. 제조사는 디지털 요소를 가진 제품의 SBOM 작성과 생애주기 전반의 취약점 처리, 그리고 적극적으로 악용되는 취약점이나 중대 사고를 인지 후 24시간 안에 조기 경보하고 72시간 안에 통지하는 의무를 집니다B1. 위반 시 과징금은 최대 1,500만 유로 또는 전 세계 연 매출의 2.5% 중 높은 금액입니다B1. 로드맵이 반복하는 “‘27.12 시행 예정"이 이 전면 적용일입니다A1.

미국의 공급망 규제는 2021년 5월 12일 서명된 행정명령 14028(Executive Order 14028, Improving the Nation’s Cybersecurity)에서 출발해 SBOM을 연방 조달 요건으로 제도화하고 NIST에 SSDF를 정리하도록 이끌었습니다B3·B5. CISA는 2024년 3월 11일 안전한 소프트웨어 개발 증명 공통서식을 확정했습니다B4. 의료기기 규제는 2022년 통합세출법 제3305조가 연방 식품의약품화장품법(FD&C Act)에 제524B조를 신설하면서 시작됐고, 개정 조항은 2023년 3월 29일 발효됐습니다B7. 시판전 신청을 내는 제조자는 시판후 취약점 관리 계획과 보안 설계, 상용·오픈소스·기성품 구성요소를 담은 SBOM을 제출해야 합니다B7. 소비자 IoT 영역에서는 미국 연방통신위원회(Federal Communications Commission, FCC)가 2024년 3월 14일 자발적 라벨링 프로그램(미국 사이버 신뢰 마크, U.S. Cyber Trust Mark)을 의결했고B8, 영국은 제품 보안 및 통신 인프라법(Product Security and Telecommunications Infrastructure Act 2022, PSTI)을 2024년 4월 29일 발효했습니다B9. 로드맵이 사후관리 유도 과제에서 인용한 “美 Cyber Trust Mark"와 “영국 PSTI(‘24.4 시행)“가 이들입니다A1.

6. 시사점·고려사항

6.1 수출기업 — SBOM은 이미 시장 진입 조건

FDA 의료기기 인허가와 EU CRA가 SBOM 관리를 사실상 시장 진입 조건으로 만든 상황에서, 정부의 점검 지원과 상호인정 추진은 수출기업에 직접적 효용입니다A1·B1·B7. EU CRA 보고 의무는 2026년 9월 11일, 전면 적용은 2027년 12월 11일이므로B2, 수출기업은 한국의 MRA 합의를 기다리기보다 CRA 자체 일정에 맞춰 SBOM 생성과 취약점 보고 체계를 선제적으로 준비하는 편이 안전합니다. MRA는 상대국이 한국 인증을 동등하게 인정해야 성립하는데, 로드맵 자신도 MRA를 “추진"으로 표현할 뿐 합의 시점을 제시하지 않았습니다A1.

6.2 공공 SW 납품기업 — SBOM 제출이 정규 요건으로

공공분야는 정보화사업 SBOM 제출과 취약점 대응 절차가 과제로 명시됐고, 보안적합성 검증과 N2SF 전환에 SBOM 제출 확인이 결합됩니다A1·D3. 공공 SW를 납품하는 기업은 SBOM 생성을 빌드 파이프라인에 통합해 두는 준비가 필요합니다. 공공분야 SBOM 항목은 이중 규제가 되지 않도록 최소한으로 도출한다는 방침이라A1, 해외 요건과의 정합성이 실제로 어떻게 설계되는지를 후속 가이드라인에서 확인하는 것이 실무에 도움이 됩니다.

6.3 중소 SW기업 — 지원의 충분성이 관건

전체 SW기업의 81%가 10인 미만인 구조에서A1·D1, SBOM 생성과 취약점 관리에 필요한 도구·인력을 자체 부담하기는 어렵습니다. 로드맵은 컨설팅과 클라우드 기반 개발환경·보안솔루션 보급을 지원책으로 배치했으나, 보급 규모와 예산이 4만여 개 기업의 다수를 실질적으로 포괄하는지는 수치로 제시되지 않았습니다A1. 지원의 충분성은 향후 예산 편성으로 판가름될 영역입니다.

6.4 남은 리스크

외부 인프라 의존 리스크가 있습니다. 미국 공통 취약점·노출(Common Vulnerabilities and Exposures, CVE) 프로그램을 운영하는 마이터(MITRE)와 CISA의 계약이 2025년 4월 16일 만료 직전까지 갔다가 11개월 연장으로 봉합됐고, CVE 이사회는 2026년 1월 21일 “3월 자금 절벽은 없다"고 확인했습니다E6·F-news-cso. 위기는 봉합됐으나 미국 정부 예산에 종속된 글로벌 취약점 식별 체계의 구조적 불안정성은 그대로여서, 로드맵이 대체 프로그램 발굴을 과제로 넣은 것은 합당한 대비입니다A1.

개발 현장의 준비 수준도 변수입니다. Black Duck이 2025년 7~8월 전 세계 전문가 1,001명을 조사한 DevSecOps 현황에 따르면, 45.56%는 새 코드를 보안 테스트에 넣는 일을 여전히 수동으로 처리합니다H1. 속도는 표준이 됐지만 보안 자동화가 따라가지 못하는 이 격차는, 로드맵이 사람 중심 수동 대응을 AI 중심 자율체계로 전환하겠다고 한 문제의식과 겹칩니다A1. SBOM 생성과 취약점 점검을 자동화 파이프라인에 통합하지 못하면 의무화가 현장에서 추가 수작업 부담으로 귀결될 위험이 있습니다.

참고로 로드맵이 “가트너(‘24.6)“로 귀속한 공급망 공격 글로벌 피해액(2023년 460억 달러에서 2031년 1,380억 달러 추정)은 실제로는 Cybersecurity Ventures의 추정치입니다E4.

7. 참고 자료

본문에서 [A1]처럼 인용한 항목을 정리합니다. 모든 URL의 접속일은 2026-06-24입니다. 정부·기관 사이트는 자동 수집 도구에 봇 차단을 반환하는 경우가 있으나 죽은 링크가 아니며, 해당 항목은 기존 검증 자산이나 WebSearch로 교차 확인했습니다.

분석 대상·국내 선행 자료

A1. 과학기술정보통신부, 국가정보원, 한국인터넷진흥원 관계부처 합동 (2026). AI 일상화 시대를 준비하는 SW 공급망 보안 강화 로드맵. 발행처 한국인터넷진흥원(나주), 2026-06-24 1판 1쇄. 본문 30쪽, CC BY-NC-ND 2.0 KR. 발표 당일(2026-06-24 양재 aT센터 공급망보안워크숍) 공개돼 확정 PDF 직링크는 미확정이며, 과기정통부 보도자료(https://www.msit.go.kr/bbs/list.do?sCode=user&mId=307&mPid=208)와 KISA 자료실에서 확인할 수 있음. — 용도: 본 글의 인용·논평 대상인 공개 정부 로드맵. 출처를 밝혀 인용하고 원문 표·도식은 복제하지 않음. ↩

A2. 과학기술정보통신부, 국가정보원, 디지털플랫폼정부위원회 (2024). SW 공급망 보안 가이드라인 1.0(요약본 2024-05-13). 발행처 KISA 자료실. https://www.kisa.or.kr/2060204/form?postSeq=15 (접속: 2026-06-24, WebSearch로 발행 주체와 SSDF·SBOM·단계별 점검 내용 교차 확인). — 용도: 로드맵이 2.0으로 개선하겠다고 밝힌 직접 선행 자료. ↩

A10. Cyber Security Agency of Singapore et al. (2025). Joint Statement on the Global Cybersecurity Labelling Initiative (GCLI). 2025-10-23 출범. https://www.csa.gov.sg/news-events/press-releases/joint-statement-on-the-global-cybersecurity-labelling-initiative/ (접속: 2026-06-24, WebSearch로 출범일과 11개 창립 회원, 한국 참여 교차 확인). — 용도: GCLI 출범·구성과 한국 참여 확인. ↩

글로벌 법령·규제 원문

B1. European Parliament and Council (2024). Regulation (EU) 2024/2847 — Cyber Resilience Act. Official Journal of the EU, OJ L, 2024/2847, 20.11.2024. https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng (접속: 2026-06-24, 워크스페이스 eu-cra-vulnerability-reporting 검증 자산으로 재확인). — 용도: CRA SBOM·취약점 의무, 보고 시한(24h/72h), 과징금, 시행일의 1차 근거. ↩

B2. European Commission, DG CNECT (2026). Cyber Resilience Act — Shaping Europe’s digital future. https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act (접속: 2026-06-24). — 용도: 시행 일정(2024-12-10 발효, 2026-09-11 보고 의무, 2027-12-11 전면 적용)의 1차 확인. ↩

B3. The White House (2021). Executive Order 14028 — Improving the Nation’s Cybersecurity. Federal Register, 86 FR 26633, 2021-05-17. https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity (접속: 2026-06-24, 200 OK). — 용도: SBOM의 연방 조달 요건화, NIST SSDF 정리 지시의 1차 근거. ↩

B4. CISA (2024). Secure Software Development Attestation Common Form (Final). 2024-03-11 공개. https://www.cisa.gov/secure-software-attestation-form (접속: 2026-06-24, cisa.gov 봇 차단, 공개일 WebSearch 교차 확인). — 용도: 미국 연방 조달 SSDF 자가증명 의무. 로드맵 “‘23.6~” 표기는 정책 논의 시점, 서식 자체는 2024-03 공개. ↩

B5. NIST — Souppaya, M., Scarfone, K., Dodson, D. (2022). Secure Software Development Framework (SSDF) Version 1.1. NIST SP 800-218. DOI: 10.6028/NIST.SP.800-218. https://csrc.nist.gov/pubs/sp/800/218/final (접속: 2026-06-24). — 용도: 로드맵 “안전한 SW 개발 방법론"의 직접 참조 프레임워크. ↩

B7. U.S. Food and Drug Administration / Federal Register (2023). Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (FD&C Act §524B, 2022 Consolidated Appropriations Act §3305 신설, 시행 2023-03-29). https://www.federalregister.gov/documents/2023/09/27/2023-20955/cybersecurity-in-medical-devices-quality-system-considerations-and-content-of-premarket-submissions (접속: 2026-06-24, 200 OK). — 용도: FDA 의료기기 SBOM 요구의 1차 근거. ↩

B8. Federal Communications Commission (2024). Cybersecurity Labeling for Internet of Things — Report and Order (FCC 24-26) (U.S. Cyber Trust Mark). 채택 2024-03-14. https://www.federalregister.gov/documents/2024/03/25/2024-06249/cybersecurity-labeling-for-internet-of-things (접속: 2026-06-24, 200 OK). 프로그램 허브: https://www.fcc.gov/CyberTrustMark. — 용도: 미국 자발적 IoT 라벨링의 1차 근거. ↩

B9. UK Government / DSIT (2022/2024). Product Security and Telecommunications Infrastructure (PSTI) Act 2022, Part 1 (시행 2024-04-29). https://www.gov.uk/government/publications/the-uk-product-security-and-telecommunications-infrastructure-product-security-regime (접속: 2026-06-24, WebSearch로 발효일·과징금 한도 교차 확인). — 용도: 영국 PSTI 의무 규제의 1차 근거. ↩

표준·가이던스

C1. U.S. Department of Commerce / NTIA (2021). The Minimum Elements For a Software Bill of Materials (SBOM). 2021-07-12. https://www.ntia.gov/files/ntia/publications/sbom_minimum_elements_report.pdf (접속: 2026-06-24, ntia.gov 크롤러 차단, 워크스페이스 sbom-guide·g7-sbom-for-ai 검증 자산으로 재확인). — 용도: 로드맵 “SBOM 항목 최소한 도출"의 기준선. ↩

C4. The Linux Foundation / SPDX Project. SPDX Specifications (현행 SPDX 3.0, ISO/IEC 5962:2021로 표준화). https://spdx.dev/use/specifications/ (접속: 2026-06-24, 200 OK, sbom-guide 검증 완료). — 용도: SBOM 표준 형식. 글로벌 호환성 근거. ↩

C5. OWASP Foundation / Ecma International (2025). CycloneDX Specification / ECMA-424 (published 2025-12-10). https://cyclonedx.org/specification/overview/ (접속: 2026-06-24, 200 OK, sbom-guide 검증 완료). — 용도: SBOM 표준 형식. ↩

국내 제도·통계

D1. 과학기술정보통신부와 한국정보통신진흥협회(KAIT) (2024). 2023년 소프트웨어산업 실태조사(국가승인통계). 통계 포털 SWSTAT: https://stat.spri.kr/ (접속: 2026-06-24, WebSearch로 발행 기관과 통계 성격 확인). — 용도: 로드맵 “SW기업 81%가 10인 미만(합계 43,932개)” 통계의 발행 체계 근거. 81% 비율과 43,932개 수치는 실태조사 원본 표 직접 대조 미완으로 로드맵 인용으로 표기. ↩

D2. 한국인터넷진흥원(KISA) / KrCERT (2012~). 보안취약점 신고포상제(버그바운티). https://www.krcert.or.kr/kr/bbs/list.do?menuNo=205027 (접속: 2026-06-24, WebSearch로 2012-10 운영 개시·분기별 평가 교차 확인). — 용도: 로드맵 탐지·대응 과제가 확대하려는 기존 제도의 근거. ↩

D3. 국가정보원·국가사이버안보센터 (2025). 국가 망 보안체계(N2SF) 보안가이드라인 정식판 1.0 (2025-09-30 공개). https://www.nis.go.kr/CM/1_4/view.do?seq=373 (접속: 2026-06-24, WebSearch로 공개일·차등 보안등급 체계 교차 확인). — 용도: 로드맵 보안적합성 검증 대상 확대(N2SF)의 근거. ↩

D6. 디지털플랫폼정부위원회 (2024). 정부, ‘SW 공급망 보안 가이드라인 1.0’ 발표 (보도자료, 2024-05-13). https://www.dpg.go.kr/DPG/contents/DPG02020000.do?schM=view&id=20240513105420991857&schBcid=press (접속: 2026-06-24, WebSearch로 발표일 2024-05-13과 “하반기 범정부 합동TF로 로드맵 마련 계획” 본문 교차 확인). — 용도: 가이드라인 1.0 발표 경위와 “하반기 합동TF로 로드맵 마련 계획"의 1차 발표. ↩

로드맵 인용 통계의 원 출처

E4. Cybersecurity Ventures (2024). Software Supply Chain Attacks To Cost The World $60 Billion By 2025. https://cybersecurityventures.com/software-supply-chain-attacks-to-cost-the-world-60-billion-by-2025/ (접속: 2026-06-24, WebSearch로 2023년 460억 달러·2031년 1,380억 달러 확인). — 용도: 로드맵 공급망 피해액 통계의 실제 원 출처. 로드맵의 “가트너(‘24.6)” 귀속은 부정확하며 본 글에서 Cybersecurity Ventures로 정정. ↩

E6. MITRE / CISA (2025). CVE 프로그램 계약 만료와 연장 경위. Cybersecurity Dive(2025-04): https://www.cybersecuritydive.com/news/cisa-extend-funding-cve/745531/ (접속: 2026-06-24, WebSearch로 5,780만 달러 계약, 2025-04-16 만료, 11개월 연장, CVE Foundation 설립 확인). 프로그램 공식: https://www.cve.org/. — 용도: 로드맵 CVE 대체 프로그램 발굴 배경. 언론 보조 출처. ↩

동향·업계 보도

B-news-etnews. 전자신문 (2025-12-24). 과기정통부-국정원, SW 공급망 보안 손잡았다…범정부 협력체계 구축. https://www.etnews.com/20251224000334 (접속: 2026-06-24). — 용도: 범정부 협력체계 합의(2025-12-24) 시점 확인. ↩

B-news-zdnet. ZDNet Korea (2026-06-16). 정부, SW 공급망 보안 로드맵 24일 공개. https://zdnet.co.kr/view/?no=20260616111556 (접속: 2026-06-24). — 용도: 발표일(2026-06-24), 주체(과기정통부·국정원), 장소(양재 aT센터), 2027 제도화 목표 1차 확인. ↩

D-news-boan. 보안뉴스 (2026). 국정원 보안적합성검증에서 N2SF로…달라진 패러다임 무엇?. https://m.boannews.com/html/detail.html?tab_type=1&idx=140209 (접속: 2026-06-24). — 용도: 보안적합성 검증에서 N2SF로의 전환, 2026 사이버보안 평가 반영 보도. ↩

F-news-cso. CSO Online (2026). CVE program funding secured, easing fears of repeat crisis. https://www.csoonline.com/article/4142600/cve-program-funding-secured-easing-fears-of-repeat-crisis.html (접속: 2026-06-24). — 용도: CVE 이사회 2026-01-21 “3월 자금 절벽 없음” 확인. ↩

개발 현장 동향

H1. Black Duck (2025). Balancing AI Usage and Risk in 2025: The Global State of DevSecOps (October 2025). 설문은 Censuswide가 2025-07~08 전 세계 전문가 1,001명 대상으로 수행. — 용도: 개발 현장 보안 자동화 격차(수동 처리 45.56%). ↩

3 - G7 「AI를 위한 SBOM — 최소 요소」: 클러스터별 요소 단위로 본 AI 공급망 투명성 권고

요약 G7 사이버보안 작업반(G7 Cybersecurity Working Group)이 2026년 5월 12일 발행한 「AI를 위한 소프트웨어 부품 명세서 — 최소 요소(Software Bill of Materials for AI — Minimum Elements)」는 AI 시스템에 적용할 SBOM이 무엇을 담아야 하는지를 7개 클러스터, 50개 요소 단위로 처음 합의한 G7 공동 지침입니다. 독일 BSI와 이탈리아 ACN이 공동 주도하고 프랑스 ANSSI, 캐나다 CSE, 미국 CISA, 영국 NCSC, 일본 NCO가 EU 집행위원회와 함께 발행했습니다. 문서는 의무가 아닌 권고이며 새 요건이나 표준, 법령을 만들지 않지만, AI 모델과 데이터셋, 인프라를 일반 SBOM 위에 1급 추적 대상으로 끌어올렸다는 점에서 각국 규제와 공공 조달의 참조점이 됩니다. AI를 도입하고 개발·배포하는 한국 기업과 공급자에게는 EU 인공지능법과 사이버 복원력법 대응 문서의 구성 기준으로 미리 검토할 가치가 있습니다.

1. 개요

이 문서는 AI를 위한 SBOM의 최소 요소를 항목 단위로 정의한 첫 번째 G7 합의 문서입니다. 발행 주체는 G7 사이버보안 작업반이며, 실제 공동 발행 기관은 독일 연방정보보안청(Federal Office for Information Security, BSI), 이탈리아 국가사이버보안청(National Cybersecurity Agency, ACN), 프랑스 국가정보시스템보안청(National Cybersecurity Agency, ANSSI), 캐나다 통신보안청(Communications Security Establishment, CSE), 미국 사이버보안·기반시설보안청(Cybersecurity and Infrastructure Security Agency, CISA), 영국 국가사이버보안센터(National Cyber Security Centre, NCSC), 일본 국가사이버통괄실(National Cybersecurity Office, NCO) 일곱 곳입니다. 여기에 유럽연합 집행위원회(European Commission)가 협력 주체로 참여했습니다C1·C2. 발행일은 2026년 5월 12일이며, 미국 CISA는 같은 문서를 정보 공유 등급 TLP:CLEAR(자유 배포 가능)로 분류해 공동 발표했습니다C1·C2.

작업 흐름은 캐나다(2025)와 프랑스(2026) G7 의장국의 지원 아래 이탈리아 ACN과 독일 BSI가 공동 주도했고, 본문이 밝힌 집필 기간은 2025년 8월부터 2026년 2월까지입니다C1. 공식 게시본은 BSI 다운로드 페이지와 CISA 자료실에서 내려받을 수 있습니다C1·C2.

문서의 위상은 분명히 권고입니다. 본문은 이 최소 요소가 의무 사항이 아니며 새로운 요건이나 표준, 법령을 만들지 않는다고 명시하고, 제안 목록이 전부를 망라하지 않는 비망라적(non-exhaustive) 기준선이라고 밝힙니다C1. 구속력은 없지만 G7 일곱 나라의 사이버보안 당국과 EU 집행위가 합의했다는 점에서, 각국 규제와 공공 조달 요건이 참조할 무게를 가집니다. 적용 범위는 AI 시스템을 만들거나 배포하는 모든 개발자와 배포자이며, 산업과 부문, 관할권에 따라 추가 클러스터나 요소가 필요할 수 있다는 점을 문서 스스로 인정합니다C1.

2. 핵심 내용: 7개 클러스터와 요소

AI 시스템도 소프트웨어 시스템이므로 SBOM은 AI에도 유효하며, AI를 위한 SBOM의 최소 요소는 일반 SBOM 최소 요소를 대체하지 않고 그 위에 더해집니다C1. 문서가 새로 정의한 부분은 구조화된 기록을 일곱 묶음으로 나눈 클러스터(cluster) 체계입니다. 각 클러스터는 AI 시스템 구성요소의 고유한 특징을 포착하는 “요소(element)“를 담습니다. 메타데이터 클러스터는 SBOM 자체에 관한 정보이므로 가장 먼저 제시되고, 나머지 여섯 클러스터는 동등한 비중으로 이어집니다C1.

표 1. AI를 위한 SBOM의 7개 클러스터. 메타데이터는 SBOM 문서 자체를 기술하는 계층이고, 나머지 6개 클러스터는 AI 시스템을 구성하는 동등한 정보 영역입니다. 50개 요소가 7개 클러스터에 나뉩니다. (G7 Software Bill of Materials for AI — Minimum Elements (2026-05-12); 수집 2026-06-22)

2.1 메타데이터(Metadata): SBOM 그 자체의 기록

메타데이터 클러스터는 개별 구성요소가 아니라 AI를 위한 SBOM 자체를 기술합니다C1. 작성자(SBOM author), 버전, 데이터 형식 이름과 버전, 작성자 서명, 도구 이름과 버전, 생성 맥락, 타임스탬프, 의존성 관계의 10개 요소로 구성됩니다. 작성자 요소는 SBOM을 생성한 주체를 가리키며, 구성요소를 만든 생산자(Producer)와 구별됩니다. 버전 요소는 시맨틱 버저닝(Semantic Versioning)을 쓸 수 있고, 이 경우 발행 SBOM의 메이저 버전은 1이어야 합니다C1·B14. 작성자 서명은 NIST 디지털 서명 표준(Digital Signature Standard, DSS)이나 ISO/IEC 14888-4:2024, ENISA 합의 암호 메커니즘처럼 관련 기관이 승인한 알고리즘을 쓰도록 권고합니다B1·B3. 타임스탬프는 RFC 9557을, 식별자 일련번호는 RFC 9562를 따릅니다B5·B4.

생성 맥락(SBOM generation context)과 의존성 관계(SBOM dependency relationship) 두 요소가 실무에서 특히 유의할 항목입니다. 생성 맥락은 SBOM이 만들어진 소프트웨어 수명주기 단계를 “빌드 이전(before build)”, “빌드(build)”, “빌드 이후(after build)” 같은 참조로 표시합니다. 소스 코드에서 만든 SBOM은 빌드 이전, 바이너리 분석 도구가 만든 SBOM은 빌드 이후가 됩니다. 의존성 관계는 단순 포함(“includes”/“included in”)을 넘어, 특정 구성요소가 다른 소프트웨어에서 대부분 파생되었거나 후손(descendant)임을 표현해 백포팅·포크된 소프트웨어를 명시적으로 기록하게 합니다C1.

2.2 시스템 수준 속성(SLP): 데이터가 어디로 흐르는가

시스템 수준 속성(System Level Properties, SLP) 클러스터는 AI 시스템 전체를 다룹니다. 분류기, 대규모 언어 모델(large language model, LLM), AI 에이전트 같은 여러 요소로 구성된 시스템의 내부 작동, 소프트웨어 의존성과 프레임워크, 그리고 시스템이 사용자 데이터를 어떻게 처리하고 상호작용하는지를 9개 요소로 포착합니다C1. 시스템 이름과 구성요소, 생산자, 버전, 타임스탬프 같은 기본 식별 정보에 더해, 데이터 흐름과 데이터 사용, 입출력 속성, 의도된 응용 분야가 들어갑니다.

가장 특징적인 요소는 시스템 데이터 흐름(System data flow)입니다. 입력/출력 엔드포인트, 출발지에서 목적지로 가는 데이터 정보 흐름 설명, 외부 서비스 API에 더해 다중 에이전트 통신 프로토콜(multi-agent communication protocols)과 외부 서비스로 향하는 양방향 데이터 흐름인 웹 그라운딩(web grounding)을 예시로 명시합니다C1. 에이전트 간 통신과 외부 웹 접근을 데이터 흐름 항목으로 끌어들인 점은, 단일 모델이 아니라 외부와 상호작용하는 복합 시스템을 추적 단위로 본다는 신호입니다. 시스템 데이터 사용(System data usage)은 데이터가 모델 성능 개선에 쓰이는지, API 호출이 데이터를 로깅하는지 같은 정보를 기술 문서 링크로 담도록 합니다.

2.3 모델(Models): 가중치는 어떻게 만들어졌는가

모델 클러스터는 가장 많은 13개 요소로, AI 시스템이 쓰는 모델을 식별하고 가중치가 어떻게 생성되었는지를 기술합니다C1. 이름과 식별자, 버전, 타임스탬프, 생산자 같은 식별 정보, 해시 값과 해시 알고리즘으로 표현하는 무결성, 그리고 모델 속성과 입출력 속성, 학습 속성, 라이선스, 외부 참조로 모델의 성격을 담습니다. 식별자(Model identifier)는 공통 플랫폼 열거(Common Platform Enumeration, CPE)나 Package-URL(PURL)을 우선 식별자로 지정하고, UUID와 커밋 해시, OmniBOR, SWHID 같은 내재적 식별자(intrinsic identifier)도 허용합니다B6·B7·B9·B10. 해시 알고리즘은 IANA 해시 함수 텍스트 명칭으로 식별하고 NIST 승인 알고리즘을 쓰도록 합니다B12·B13.

모델 학습 속성(Model training properties)은 사전학습과 사후학습·미세조정·지속학습을 아우르며, 비지도/지도/자기지도 학습 유형과 인간 피드백 기반 강화학습, 지시 튜닝, 직접 선호 최적화(Direct Preference Optimization) 같은 강화학습 최적화 유형까지 모델 카드 링크로 기술합니다C1.

모델 라이선스(Model license) 요소는 G7 문서의 고유한 기여입니다. 단순히 오픈소스 라이선스 종류를 가리키는 데 그치지 않고, 모델이 open weight, open architecture, open data, open training 중 무엇인지 구분해 명시하도록 요구합니다C1.

%%{init: {'theme':'base', 'themeVariables': {'fontSize':'18px'}}}%%
flowchart TD
    L["Model license<br/>모델 개방성 4구분"]
    L --> W["Open weight<br/>가중치 공개"]
    L --> A["Open architecture<br/>아키텍처 공개"]
    L --> D["Open data<br/>학습 데이터 공개"]
    L --> T["Open training<br/>학습 절차 공개"]

    style L fill:#fff3e0,stroke:#ef6c00,stroke-width:2px

그림 1. 모델 라이선스 요소의 4구분. G7 최소 요소는 모델 라이선스를 단일 표기가 아니라 가중치와 아키텍처, 데이터, 학습 절차 각각의 개방 여부로 명시하도록 요구합니다. (G7 Software Bill of Materials for AI — Minimum Elements (2026-05-12); 수집 2026-06-22)

“오픈 모델"이라는 한 단어로 뭉뚱그려지던 개방성을 네 축으로 분해한 것은, 가중치만 공개되고 학습 데이터나 절차는 비공개인 흔한 사례를 SBOM 차원에서 구별하기 위함입니다. 가중치 공개와 학습 데이터 공개는 라이선스와 재현성, 법적 책임 측면에서 전혀 다른 의미를 갖습니다.

2.4 데이터셋 속성(DP): 출처와 민감도

데이터셋 속성(Datasets Properties, DP) 클러스터는 모델 수명주기 전반에서 쓰인 데이터셋의 정체성과 출처(provenance)를 10개 요소로 문서화합니다C1. 이름과 설명, 내용, 식별자, 해시 같은 기본 정보에, 출처와 통계적 속성, 민감도, 의존성 관계, 라이선스가 더해집니다. 데이터셋 출처(Dataset provenance)는 데이터를 누가 기여했는지, 웹 크롤링인지 상업적 계약인지 같은 수집 방법, 사후처리와 전처리, 라벨링 단계, 합성 데이터(synthetic data)라면 그 생성 방법까지 포착합니다. 데이터셋 민감도(Dataset sensitivity)는 개인식별정보(PII), 자유 접근 데이터, 저작권 보호 데이터, 금융이나 의료 같은 민감 데이터, 국가 안보 관련 데이터 중 무엇을 포함하는지를 표시합니다. 학습 데이터의 법적·윤리적 리스크를 SBOM 항목으로 추적하려는 설계입니다.

2.5 인프라(Infrastructure): HBOM으로의 연결

인프라 클러스터는 AI 시스템 운영에 필수적인 물리·가상 인프라를 두 요소로 담습니다C1. 인프라 소프트웨어(Infrastructure software)는 펌웨어, 패키지 관리자, 서드파티 라이브러리, 프레임워크, 런타임 환경 같은 의존성을 나열합니다. 인프라 하드웨어(Infrastructure hardware)는 특화된 AI 하드웨어를 직접 기술하는 대신 기존 하드웨어 부품 명세서(Hardware Bill of Materials, HBOM)로의 링크를 의존성으로 연결합니다. 소프트웨어 SBOM이 하드웨어 명세를 직접 흡수하지 않고 HBOM을 참조로 끌어들이는 구조는, GPU 등 AI 가속 하드웨어 추적을 별도 표준에 위임하면서도 연결 고리를 남기는 절충입니다.

2.6 보안 속성(SP)과 핵심성과지표(KPI)

보안 속성(Security Properties, SP) 클러스터는 AI 모델·시스템에 적용된 사이버보안 조치를 4개 요소로 다룹니다C1. 보안 통제(Security controls)는 암호화와 데이터 최소화, 차분 프라이버시, 접근 통제 같은 일반 통제와, 적대적 강건성 학습(adversarial robustness training), 프롬프트 인젝션(prompt injection) 통제, 학습 데이터 큐레이션 같은 AI 특화 통제를 구분해 나열합니다. 보안 준수(Security compliance)는 취득한 인증과 표준을, 사이버보안 정책 정보는 security.txt 링크를, 취약점 참조(Vulnerability referencing)는 알려진 취약점의 악용 가능성 데이터베이스 링크를 담습니다.

핵심성과지표(Key Performance Indicators, KPI) 클러스터는 일반 SBOM에는 없는 G7 고유 묶음입니다. 보안 지표(Security metrics)는 서드파티 조작에 대한 복원력 같은 보안 벤치마크를, 운영 성과 KPI(Operational performance KPIs)는 시스템 가동시간, 사고 해결 시간, 지연시간, 요청 처리량, 부하 분산을 다룹니다C1. 정적인 구성 목록을 넘어 운영 상태와 위협 지표까지 SBOM에 담으려는 시도이며, 동시에 뒤(4장)에서 보듯 측정 일관성 면에서 가장 많은 비판을 받는 영역이기도 합니다.

3. 배경과 맥락

이 문서가 지금 나온 이유는 두 갈래 계보가 한 지점에서 만났기 때문입니다. 하나는 미국에서 제도화된 일반 SBOM 최소 요소이고, 다른 하나는 G7이 2025년에 그린 AI를 위한 SBOM 비전입니다.

%%{init: {'theme':'base', 'themeVariables': {'fontSize':'18px'}}}%%
flowchart TD
    A["2021-07 · NTIA<br/>일반 SBOM 최소 요소<br/>(데이터 필드 7종)"]
    B["이후 · CISA 이관<br/>SBOM 커뮤니티 주관<br/>(SW 식별 생태계 분석 등)"]
    C["2025-06 · G7<br/>AI를 위한 SBOM 공동 비전<br/>(고수준 클러스터 제시)"]
    D["2025-08~2026-02 · G7 작업반<br/>최소 요소 구체화"]
    E["2026-05-12 · 발행<br/>AI를 위한 SBOM<br/>— 최소 요소 (본 문서)"]

    A --> B --> C --> D --> E
    A -. "일반 SBOM 요소에<br/>AI 요소를 누적" .-> E

    style A fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
    style E fill:#fff3e0,stroke:#ef6c00,stroke-width:2px

그림 2. AI를 위한 SBOM 최소 요소의 계보. 2021년 일반 SBOM 최소 요소(NTIA, 파란색)를 토대로 AI 고유 요소를 더해 2026년 발행 문서(주황색)에 이른 누적 과정입니다. 점선은 일반 SBOM 요소가 최종 문서에 그대로 포함됨을 나타냅니다. (NTIA(2021), CISA, G7(2025, 2026) 종합; 2026-06-22)

일반 SBOM 최소 요소의 기준점은 미국 상무부 통신정보관리청(National Telecommunications and Information Administration, NTIA)이 행정명령 14028의 지시로 2021년 7월 발행한 「The Minimum Elements for a Software Bill of Materials」입니다. 이 문서는 공급자명과 구성요소명, 버전, 고유 식별자, 의존 관계, SBOM 작성자, 타임스탬프의 일곱 데이터 필드를 제시했고, 이후 SBOM 커뮤니티 작업의 주관은 CISA로 이관되었습니다C7. G7 문서가 이 계보를 직접 잇고 있다는 증거는 메타데이터 클러스터의 정의 방식에서 드러납니다. 작성자와 버전, 데이터 형식, 타임스탬프, 의존성 관계는 NTIA 데이터 필드를 거의 그대로 AI 맥락에 옮긴 것이고, 모델 식별자가 CPE와 PURL을 우선 식별자로 지정하며 CISA의 「Software Identification Ecosystem Option Analysis」(2023)를 인용하는 대목도 같은 뿌리를 보여줍니다C6·C7.

직접적 출발점은 2025년 비전 문서입니다. 「AI를 위한 SBOM에 관한 G7 공동 비전(A shared G7 vision on Software Bill of Materials for AI)」은 2025년 6월 BSI와 ACN이 발행하고 오타와 G7 회의에서 추인되었으며, AI를 위한 SBOM의 개념과 목표, 이점, 속성을 정의하고 일곱 클러스터를 고수준 예시로 제시하는 데 그쳤습니다C3. 동시에 전문가들이 각 클러스터를 정교하게 정의하라고 권고했고, 2026년 최소 요소 문서가 그 후속입니다. 비전이 “무엇을 담아야 하는가"의 윤곽이라면, 이번 문서는 “각 클러스터에 어떤 요소를 어떤 정의로 담는가"의 세부입니다C1·C3.

차이는 AI 고유 구성요소를 1급 추적 대상으로 끌어들인 데 있습니다. 일반 SBOM이 소프트웨어 구성요소 식별을 겨냥한다면, G7 문서는 모델과 데이터셋, 인프라, 보안 속성, 핵심성과지표 다섯 묶음을 추가합니다. 코드만으로는 학습 과정과 데이터, 모델 거동을 표현할 수 없다는 한계가 이 확장의 이유입니다. 모델 라이선스를 네 축으로 구분하고, 데이터셋 출처가 수집 방법과 합성 데이터 생성 방법까지 포착하도록 한 점이 일반 SBOM에는 없던 항목입니다.

구현 면에서 문서는 형식 중립적입니다. 메타데이터 클러스터에 데이터 형식 이름·버전 요소를 둔 것이 그 증거이며, 실제 구현은 기존 두 BOM 표준이 떠받칩니다. SPDX(System Package Data Exchange)는 리눅스 재단 프로젝트로 3.0(2024년 4월)부터 AI 프로파일과 데이터셋 프로파일을 도입했고, 모델 유형과 아키텍처, 하이퍼파라미터, 자율성 유형, 민감 정보 사용 여부 등을 정의합니다B15. CycloneDX(OWASP)는 1.5부터 머신러닝 부품 명세서(Machine Learning Bill of Materials, ML-BOM)를 지원하며 모델 카드(modelCard) 객체로 학습 접근법과 아키텍처, 성능, 윤리적 고려를 담습니다B16. G7 문서가 모델 라이선스 예시에서 “SPDX/CDX 파일의 대응 필드를 가리킬 수 있다"고 적은 것은 이 두 포맷을 구현 매개로 전제했음을 보여줍니다C1.

4. 최신 동향과 검증 과제

발표 직후 한 달여의 반응을 보면, 일곱 클러스터의 방향성에는 대체로 동의가 모였지만 측정과 검증 가능성에서 격차가 드러났습니다. 발표는 BSI, CISA, ANSSI, ACN, CSE, NCSC, NCO가 EU 집행위와 함께 동시 게시하는 형태였고, ANSSI는 2026년 5월 13일 영문 게시에서 이 문서를 “AI를 위한 SBOM에 합리적으로 기대할 수 있는 바에 관한 구체적 지침"으로 소개하며 향후 조정 가능성을 밝혔습니다A4. 전문 매체 보도는 5월 13~14일에 집중되었고, 법무법인 Morgan Lewis는 6월 분석에서 이 지침이 자발적·비구속적이라는 점을 강조했습니다E1.

측정 가능성에 대한 의문이 논평의 공통 초점이었습니다. CISA의 전 SBOM 책임자 앨런 프리드먼(Allan Friedman)은 일곱 클러스터의 상당 부분을 긍정하면서도 다수가 “구체적이고 조직 간 일관된 방식으로 측정하거나 정의하기조차 어렵다"고 지적했습니다A6. Greyhound Research의 Sanchit Vir Gogia는 “최소 요소는 가시성을 만들지만 보증(assurance)을 만들지는 않는다"고 요약했고, Cloudsmith의 Nigel Douglas는 문서가 올바른 요건을 제기하면서도 일곱 데이터 클러스터를 조직 간에 일관되게 측정하기 어렵다는 한계를 함께 짚었습니다A10·A8. 보안 위협 분류 프레임워크 TLCTC는 발표 당일 보안 속성(SP) 클러스터를 정면으로 비판하며, 통제 항목을 나열하면서도 각 통제가 어떤 위협에 대응하는지 말하지 않아 감사 가능성이 떨어진다고 지적했습니다A11.

표준과 도구 구현은 G7의 일곱 클러스터를 아직 완전히 채우지 못합니다. SPDX 데이터셋 프로파일의 hasSensitivePersonalInformation과 confidentialityLevel은 G7의 데이터셋 민감도에, dataCollectionProcess는 데이터셋 출처에 매핑됩니다B15·A13. 반면 메타데이터 클러스터의 작성자 서명과 생성 맥락, KPI 클러스터의 운영 성과 지표(가동시간, 지연시간, 처리량)는 두 표준 어디에도 정형화된 전용 필드가 분명하지 않아 외부 참조나 자유 텍스트로 우회해야 합니다A13·A16. SP 클러스터의 AI 특화 통제도 마찬가지로 정형 필드가 미흡합니다.

에이전틱 AI를 둘러싼 G7의 판단과 표준계의 움직임이 엇갈린 점은 특히 주목할 만합니다. 문서의 논의(Discussion) 절은 AI 시스템의 의사결정 수준 또는 자율성(autonomy)을 별도 요소로 넣을지 명시적으로 다뤘습니다. 작업반은 에이전틱 AI(agentic AI)의 빠른 발전으로 이 요소의 중요성이 커질 수 있고 침해(compromise)의 영향 평가에 도움이 될 수 있음을 인정하면서도, 자율성을 별도 요소로 명시하지 않기로 결정했습니다. 이 요소가 관할권마다 안전 요건(safety requirements) 등을 통해 다르게 다뤄질 수 있다는 것이 이유였습니다C1·A7. 같은 시기 표준계는 반대로 움직였습니다. 2026년 2월 FOSDEM에서 공개된 SPDX 3.1은 AI 에이전트와 검색 증강 생성(RAG)을 1급 개념으로 추가해, 정책적 합의가 보류한 영역을 데이터 형식이 먼저 어휘로 마련했습니다A14. 향후 G7 정교화 작업이 이 표준 어휘를 어떻게 흡수할지가 관전 지점입니다.

규제 정합성은 열린 문제로 남아 있습니다. 발행일에 관해서는 1차 출처인 BSI 게시 페이지가 5월 12일을 명시하며, 일부 매체의 5월 13일 표기는 시간대·게시 시점 차이에서 비롯된 것으로 보입니다A3·A4. 자발적 G7 권고와 곧 구속력을 갖는 EU 의무 사이의 필드 매핑이 기업 실무의 다음 과제입니다.

5. 한국 독자를 위한 시사점

가장 먼저 확인할 것은 보고 의무가 아니라 문서 구조의 표준화 신호입니다. G7 최소 요소 자체는 어느 나라에서도 직접적인 법적 의무를 부과하지 않습니다C1. 그러나 EU 인공지능법(Artificial Intelligence Act)이 고위험 AI 시스템에 Article 11과 Annex IV의 기술문서를 요구하고, 그 의무가 부속서 III 고위험 시스템에 대해 2026년 8월 2일부터 적용됩니다A1. Annex IV가 요구하는 구성요소와 데이터, 성능 문서는 G7의 시스템 수준 속성과 모델, 데이터셋 클러스터와 상당 부분 겹칩니다. EU에 AI 제품을 공급하는 한국 기업이라면, G7 클러스터를 기술문서 항목의 점검표로 삼아 누락을 미리 메우는 것이 현실적입니다.

사이버 복원력법(Cyber Resilience Act, CRA)은 SBOM을 직접 명령합니다. Annex I, Part II(1)은 디지털 요소를 가진 제품의 구성요소를 기계 판독 가능한 형식의 SBOM으로 작성하도록 요구하고, 취약점·사고 신고 의무(Article 14)는 2026년 9월 11일부터, 나머지 핵심 요건은 2027년 12월 11일부터 적용됩니다A2. G7 문서가 일반 SBOM 위에 AI 요소를 쌓는 구조를 택한 것은 CRA가 만들어 둔 SBOM 의무 기반과 자연스럽게 맞물립니다. AI를 탑재한 제품을 EU에 출시하는 기업은 일반 SBOM(CRA 의무)에 G7 AI 요소를 더하는 2층 구조로 준비하는 편이 효율적입니다.

준비 측면에서 우선순위가 높은 항목은 데이터셋과 모델 라이선스입니다. 데이터셋 출처와 민감도(PII, 저작권, 국가 안보)는 학습 데이터의 법적 리스크와 직결되므로, 외부 모델과 데이터를 가져다 쓰는 조직일수록 공급자에게 이 정보를 요구하는 절차를 갖춰야 합니다. 모델 라이선스의 네 축 구분(가중치, 아키텍처, 데이터, 학습 절차)은 “오픈 모델"을 도입할 때 실제로 무엇이 공개되어 있는지, 재배포와 미세조정, 상업 이용에 어떤 제약이 따르는지를 가르는 기준이 됩니다. 시스템 수준 속성의 데이터 흐름 요소는 에이전트 간 통신과 웹 그라운딩까지 포함하므로, 외부 API와 다중 에이전트를 쓰는 시스템에서는 데이터가 어디로 나가는지 명시하는 일이 곧 규제 대응이자 보안 점검이 됩니다.

리스크와 기회는 같은 자리에 있습니다. 최소 요소가 측정과 검증을 보증하지 않는다는 비판은, 단순히 항목을 채우는 것만으로는 실제 시스템과의 일치가 담보되지 않는다는 경고입니다A8·A10. SBOM을 취약점 스캐닝·관리 도구, 보안 권고와 연결하지 않으면 종이 문서에 그친다는 점은 G7 문서 스스로도 강조합니다C1. 반대로 이 클러스터 체계를 자산 인벤토리와 공급망 점검에 일찍 접목하면, 이후 EU와 미국 규제가 구체화될 때 전환 비용을 낮추고 공급망 투명성을 차별화 요소로 삼을 수 있습니다.

6. 워크스페이스 내 다른 보고서와의 관계

이 보고서는 같은 워크스페이스의 AI BOM 일반론, OpenChain 보고서와 다른 층위를 다룹니다. AI BOM 보고서(reports/ai-bom)는 SBOM의 역사와 AI BOM 일반론, EU 규제 매핑을 폭넓게 다루는 개론과 규제 매핑 층위입니다. OpenChain AI SBOM 보고서(reports/openchain-ai-sbom)는 ISO 5230을 AI로 확장한 컴플라이언스 프로세스, 즉 조직이 SBOM을 어떻게 생성하고 관리할지의 프로세스와 컴플라이언스 층위를 다룹니다. 이 G7 보고서의 고유 가치는 그 사이에 있는 데이터 정의 층위, 곧 SBOM에 정확히 어떤 요소를 어떤 정의로 담아야 하는지의 항목 단위 명세입니다. 세 보고서는 일반론(왜·무엇을), 프로세스(어떻게 관리), 요소 정의(무엇을 정확히 기록)로 서로 보완합니다. AI BOM 도입을 실제로 설계한다면 일반론으로 맥락을 잡고, OpenChain으로 운영 프로세스를 세우며, G7 클러스터로 기록 항목을 채우는 식의 조합이 자연스럽습니다.

7. 참고 자료

본문에서 인용한 출처만 정리합니다. 모든 URL은 2026-06-22에 접속해 확인했습니다.

법령·규제 (1차)

A1. European Parliament and Council (2024). Regulation (EU) 2024/1689 (Artificial Intelligence Act). OJ L, 2024/1689, 12.7.2024. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng (접속: 2026-06-22; ELI 영구 링크. 고위험 시스템 적용 2026-08-02은 EU 집행위 정책 페이지에서 교차 확인). — 용도: 고위험 AI 기술문서 의무와 G7 클러스터 대응. ↩

A2. European Parliament and Council (2024). Regulation (EU) 2024/2847 (Cyber Resilience Act, CRA). OJ L, 2024/2847, 20.11.2024. https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng (접속: 2026-06-22; ELI 영구 링크). Anchore의 CRA SBOM 요건 해설로 Annex I Part II(1) 및 Article 14(2026-09-11)·Annex I(2027-12-11) 적용 일정 보강: https://anchore.com/sbom/eu-cra/ (접속: 2026-06-22). — 용도: SBOM 작성 의무의 법적 근거와 적용 일정.

표준·규격 (1차) ↩

B1. National Institute of Standards and Technology (2023). FIPS 186-5: Digital Signature Standard (DSS). February 2023. https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf (접속: 2026-06-22). — 용도: 작성자 서명 요소의 승인 알고리즘 근거(원문 각주 4). ↩

B3. ISO/IEC (2024). ISO/IEC 14888-4:2024, Information security — Digital signatures with appendix — Part 4: Stateful hash-based mechanisms. https://www.iso.org/standard/80492.html (접속: 2026-06-22; ISO 페이지는 자동 도구에 403 반환, 표준 번호·표제는 ISO 검색 결과로 확인). — 용도: 작성자 서명 요소의 승인 서명 메커니즘 근거. ↩

B4. Internet Engineering Task Force (2024). Davis, K., Peabody, B., Leach, P. RFC 9562: Universally Unique IDentifiers (UUIDs). May 2024. https://www.rfc-editor.org/rfc/rfc9562.html (접속: 2026-06-22). — 용도: SBOM version 일련번호 식별자 표준(원문 각주 3). ↩

B5. Internet Engineering Task Force (2024). Sharma, U., Bormann, C. RFC 9557: Date and Time on the Internet: Timestamps with Additional Information. April 2024. https://www.rfc-editor.org/rfc/rfc9557.html (접속: 2026-06-22). — 용도: SBOM timestamp 형식(원문 각주 6). ↩

B6. NIST, National Vulnerability Database. Official Common Platform Enumeration (CPE) Dictionary. https://nvd.nist.gov/products/cpe (접속: 2026-06-22). — 용도: Model identifier 권고 식별자 CPE(원문 각주 8). ↩

B7. Ecma International (2025). ECMA-427: Package-URL (PURL) Specification, 1st Edition. December 2025. https://ecma-international.org/publications-and-standards/standards/ecma-427/ (접속: 2026-06-22). — 용도: Model identifier 권고 식별자 PURL(원문 각주 9). ↩

B9. OmniBOR Project. OmniBOR Specification. https://omnibor.io/ (접속: 2026-06-22). — 용도: Model identifier 내재적 식별자 예시 OmniBOR(원문 각주 10). ↩

B10. SWHID Project. The SWHID Specification Version 1.2. https://www.swhid.org/specification/v1.2/ (접속: 2026-06-22). — 용도: Model identifier 내재적 식별자 예시 SWHID(원문 각주 11). ↩

B12. Internet Assigned Numbers Authority. Named Information Hash Algorithm Registry (Hash Function Textual Names). https://www.iana.org/assignments/named-information/named-information.xhtml (접속: 2026-06-22). — 용도: Model hash algorithm 식별 권고(원문 각주 12). ↩

B13. NIST, Computer Security Resource Center. Hash Functions (project). https://csrc.nist.gov/projects/hash-functions (접속: 2026-06-22). — 용도: Model hash algorithm의 NIST 승인 알고리즘 근거(원문 각주 13). ↩

B14. Preston-Werner, T. and the SemVer Team (2013). Semantic Versioning 2.0.0. https://semver.org/ (접속: 2026-06-22). — 용도: SBOM version 시맨틱 버저닝(원문 각주 2). ↩

B15. SPDX Project. SPDX 3.0.1 Specification — AI Profile. Linux Foundation. https://spdx.github.io/spdx-spec/v3.0.1/model/AI/AI/ (접속: 2026-06-22). — 용도: AI를 위한 SBOM의 데이터 형식 구현, 클러스터 대응. ↩

B16. OWASP CycloneDX. Machine Learning Bill of Materials (ML-BOM / AI-BOM) capabilities. https://cyclonedx.org/capabilities/mlbom/ (접속: 2026-06-22). — 용도: AI를 위한 SBOM의 또 다른 구현(ML-BOM·modelCard).

정부·기관 가이던스 및 공식 게시처 (1차) ↩

C1. G7 Cybersecurity Working Group (2026). Software Bill of Materials for AI — Minimum Elements (BSI 공식 게시본). 발행 2026-05-12. https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/SBOM-for-AI_minimum-elements.html (접속: 2026-06-22; PDF 직접 링크 https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/SBOM-for-AI_minimum-elements.pdf). — 용도: 보고서 원본. 모든 클러스터·요소 정의의 1차 근거. ↩

C2. G7 Cybersecurity Working Group / CISA et al. (2026). Software Bill of Materials for AI — Minimum Elements (TLP:CLEAR, CISA 공동 게시본). 발행 2026-05-12. https://www.cisa.gov/resources-tools/resources/software-bill-materials-ai-minimum-elements (접속: 2026-06-22; CISA 페이지는 자동 도구에 403 반환, 게시 사실과 날짜, TLP:CLEAR 분류, 7개 클러스터는 검색 결과와 WaterISAC 공지로 교차 확인). — 용도: 미국 공식 게시본, TLP:CLEAR 배포 사실, 공동 발행 기관 확인. ↩

C3. G7 Cybersecurity Working Group (2025). A shared G7 vision on Software Bill of Materials for AI (Shared G7 Vision, 2025-06). ACN 게시. https://www.acn.gov.it/portale/documents/d/guest/paper_sbom-for-ai_19may2025_-clean-2 (접속: 2026-06-22). — 용도: 선행 비전 문서, 7개 클러스터 최초 제안(원문 각주 1). ↩

C6. Cybersecurity and Infrastructure Security Agency (2023). Software Identification Ecosystem Option Analysis. 2023-10-26. https://www.cisa.gov/sites/default/files/2023-10/Software-Identification-Ecosystem-Option-Analysis-508c.pdf (접속: 2026-06-22; CISA 사이트는 자동 도구에 403 반환, 문서 존재·날짜는 원문 각주 7과 일치). — 용도: Model identifier 소프트웨어 식별 생태계 근거(원문 각주 7). ↩

C7. National Telecommunications and Information Administration (2021). The Minimum Elements for a Software Bill of Materials (SBOM). 2021-07-12. https://www.ntia.gov/sites/default/files/publications/sbom_minimum_elements_report_0.pdf (접속: 2026-06-22; 자동 도구 접속 시 인증서 오류, 대체 게시처 https://www.ntia.doc.gov/report/2021/minimum-elements-software-bill-materials-sbom). — 용도: AI를 위한 SBOM이 토대로 삼는 일반 SBOM 최소 요소.

업계·법무법인 분석 및 언론 (보조, 1차 교차 확인 전제) ↩

A3. BSI (2026). Software Bill of Materials (SBOM) for Artificial Intelligence — Minimum Elements (게시 페이지). 발행일 2026-05-12 명시. https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/SBOM-for-AI_minimum-elements.html (접속: 2026-06-22). — 용도: 발행일 1차 확인. ↩

A4. ANSSI (2026). Software bill of materials (SBOM) for artificial intelligence (영문 게시, 2026-05-13). https://cyber.gouv.fr/en/publications/jointly-led-international-publications/software-bill-of-materials-sbom-for-artificial-intelligence/ (접속: 2026-06-22). — 용도: 발행 기관 1차 논평. ↩

A6. Infosecurity Magazine (2026-05-13). Global Cyber Agencies Issue New SBOMs for AI Guidance. https://www.infosecurity-magazine.com/news/new-sboms-for-ai-guidance-2026/ (접속: 2026-06-22). — 용도: 프리드먼 논평 인용. ↩

A7. Industrial Cyber (2026-05-13). CISA, G7 partners release SBOM for AI guidance… https://industrialcyber.co/sbom/cisa-g7-partners-release-sbom-for-ai-guidance-to-boost-ai-supply-chain-transparency-and-cybersecurity-resilience/ (접속: 2026-06-22). — 용도: 클러스터·자율성 논의 보도. ↩

A8. SecurityWeek (2026-05-14). G7 Countries Release AI SBOM Guidance. https://www.securityweek.com/g7-countries-release-ai-sbom-guidance/ (접속: 2026-06-22). — 용도: Douglas(Cloudsmith) 논평. ↩

A10. CIO (2026-05-13). CISA’s AI SBOM guidance pushes software supply-chain oversight into new territory. https://www.cio.com/article/4170711/cisas-ai-sbom-guidance-pushes-software-supply-chain-oversight-into-new-territory-2.html (접속: 2026-06-22). — 용도: 측정·검증 격차 전문가 인용(Gogia 등). ↩

A11. TLCTC (2026-05-12). The Control Fixation in the Security Properties — A TLCTC critique of G7 SBOM-for-AI. https://www.tlctc.net/sbom-for-ai-control-fixation.html (접속: 2026-06-22; WebFetch 403, 검색 캐시로 확인). — 용도: SP 클러스터 비판. ↩

A13. Bennet, K., Rajbahadur, G., Suriyawongkul, A., Stewart, K. (2024-10). Implementing AI Bill of Materials (AI BOM) with SPDX 3.0. Linux Foundation. DOI 10.70828/RNED4427. https://www.linuxfoundation.org/hubfs/LF%20Research/lfr_spdx_aibom_102524a.pdf (접속: 2026-06-22). — 용도: SPDX 필드 선별·격차 분석. ↩

A14. SPDX AI Working Group (2026). Publications — FOSDEM 2026(2026-02-01) SPDX 3.1 발표. https://fosdem.org/2026/schedule/event/9Q9EEL-what_is_new_in_spdx_3_1_which_is_now_a_living_knowledge_graph/ (접속: 2026-06-22). — 용도: SPDX 3.1 AI Agent·Prompt·RAG 추가. ↩

A16. OWASP CycloneDX. Inventory Management Use Case: AI Models and Model Cards. https://cyclonedx.org/use-cases/ai-models-and-model-cards/ (접속: 2026-06-22). — 용도: ML-BOM·model-card 필드 격차. ↩

E1. Morgan Lewis (2026-06-16). US CISA, G7 Partners … Release Minimum Elements for AI Software Bills of Materials. https://www.morganlewis.com/pubs/2026/06/us-cisa-g7-partners-in-europe-and-asia-release-minimum-elements-for-ai-software-bills-of-materials (접속: 2026-06-22; 핵심 사실은 C1/C2로 교차 확인). — 용도: 규제 정합성 분석. ↩

4 - OpenChain AI SBOM 컴플라이언스 관리 가이드: AI 공급망 컴플라이언스 프로그램의 최소 요구사항

요약 이 보고서는 리눅스 재단(Linux Foundation) 산하 오픈체인 프로젝트의 인공지능 워크그룹(OpenChain AI Work Group)이 작성한 Artificial Intelligence System Bill of Materials — Compliance Management Guide for the Supply Chain를 분석합니다. 이 가이드는 소프트웨어 라이선스 컴플라이언스의 국제표준 ISO/IEC 5230의 방법론을 인공지능(AI) 공급망으로 옮겨, 양질의 AI SBOM 컴플라이언스 프로그램이 갖춰야 할 핵심 요구사항을 정의합니다. AI 솔루션을 주고받는 조직 사이의 신뢰를 위한 기준점을 제시하는 것이 목적이며, 코드뿐 아니라 모델 가중치, 학습 데이터셋, 모델 트리(Model Tree)의 라이선스와 투명성 의무까지 추적 대상으로 끌어들여 전통적 SBOM 컴플라이언스를 확장합니다. AI 공급망 거버넌스를 준비하는 한국 기업과 실무자에게는 “무엇을 문서화하고 입증해야 하는가"를 묻는 점검표 역할을 합니다.

이 보고서가 분석한 텍스트는 깃허브(GitHub) OpenChain-Project/AI-WG 저장소 /docs 디렉토리의 작업 사본(RFC 초안)입니다. 동향 조사에서 확인된 바로, 같은 문서는 6주간의 공개 의견 수렴을 거쳐 2025년 10월 20일 OpenChain AI SBOM 컴플라이언스 가이드 Version 1으로 정식 발표되었습니다A9. 따라서 이 보고서는 정식 Version 1이 아니라 그 이전의 초안 스냅샷을 대상으로 하며, 본문의 절 번호나 일부 표현은 정식본과 다를 수 있습니다. 인용 가능한 정식본은 OpenChain Reference-Material 저장소에 PDF와 마크다운으로 공개되어 있습니다A9·A12.

1. 문서 개요

이 가이드는 양질의 AI SBOM 컴플라이언스 프로그램이 갖춰야 할 핵심 요구사항을 정의합니다. 발행 주체는 리눅스 재단 산하 오픈체인 프로젝트의 인공지능 워크그룹이며, 누구나 무료로 참여하는 메일링 리스트와 정기 워크숍을 통해 운영되는 개방형 작업 그룹의 산물입니다A1·A2. 문서가 명시한 라이선스는 크리에이티브 커먼즈 저작자표시 4.0(Creative Commons Attribution 4.0, CC-BY-4.0)입니다A1.

가이드의 설계 의도는 개요에 분명히 드러납니다. 프로그램의 “방법(how)“과 “시점(when)“이 아니라 “무엇(what)“과 “왜(why)“에 초점을 두어, 서로 다른 시장에서 활동하는 다양한 규모의 조직이 자신의 규모와 목표, 범위에 맞는 구체적 정책과 절차를 직접 선택하도록 유연성을 남깁니다A1. 가이드는 오픈체인 ISO/IEC 5230에서 영감을 얻었다고 스스로 밝히며, 그 교훈을 공급망의 AI SBOM 관리라는 시장 요구에 적용했습니다. 준비 과정에서 ISO/IEC 5230:2020, ISO/IEC 42001:2023, ISO/IEC 5962:2021을 참조 표준으로 들었습니다A1.

문서의 위상은 RFC(Request for Comments) 초안입니다. 첫머리의 고지(NOTICE)는 이것이 프로덕션 릴리스가 아니라 “관심 있는 당사자들이 아이디어를 공유하기 위한 작업 문서"이자 “살아있는 문서(living document)“라고 명시합니다A1. 초안과 정식본의 관계는 시점으로 정리됩니다. 오픈체인 AI 워크그룹은 초안을 검토한 뒤 2025년 7월 7일 공개 의견 수렴 기간을 열었고, 2025년 8월 18일 마감해 의견을 검토했으며, 거버닝 보드(Governing Board)의 결정을 거쳐 2025년 10월 20일 Version 1을 정식 발표했습니다A10·A11·A9. 이 보고서가 다루는 AI-WG/docs의 RFC.docx는 그 작업 사본이고, 외부 인용용 정식본은 Reference-Material 저장소에 별도로 공개되어 있습니다A12. 두 텍스트의 라이선스 표기가 다른 것(작업 사본은 문서 NOTICE상 CC-BY-4.0)은 배포 단계 차이에서 비롯합니다.

2. 배경: 오픈체인 방법론을 AI로 확장하다

오픈체인 사양은 양질의 오픈소스 라이선스 컴플라이언스 프로그램이 갖춰야 할 요건을 정의하는 프로세스 관리 표준입니다. 2014~2016년 100여 명의 기여자가 개발해 2016년 10월 버전 1.0으로 출범했고, 2020년 4월 ISO/IEC JTC 1의 공개 사양 전환(PAS Transposition) 절차를 거쳐 같은 해 12월 ISO/IEC 5230:2020으로 국제표준이 되었습니다A14·A3. 오픈체인은 같은 골격을 보안 영역으로도 확장해, 공개된 보안 취약점 점검에 초점을 둔 오픈소스 보안 보증 사양을 ISO/IEC 18974:2023으로 표준화했습니다A13.

5230 방법론의 핵심은 요구사항을 기술하는 구조입니다. 각 요구사항은 그 요구를 충족했음을 입증하는 검증 자료(Verification Materials), 즉 산출되어야 할 기록과, 그 요구가 왜 필요한지를 설명하는 근거(Rationale)로 구성됩니다A14. 결과물과 목적만 고정하고 구현 방식을 열어두는 이 설계가, 규모와 시장이 다른 조직이 각자에게 맞게 프로그램을 구성하도록 허용하는 비규범적(non-prescriptive) 성격의 바탕입니다. AI SBOM 가이드가 모든 절을 “검증 자료 + 근거"로 반복 구성한 것은 이 방법론을 그대로 옮긴 결과입니다.

AI 시스템에서는 추적해야 할 대상이 코드를 넘어섭니다. 모델 가중치(weights), 학습과 테스트와 검증에 쓰인 데이터셋, 그리고 한 AI 시스템이 다른 여러 AI 시스템에서 파생되는 관계를 나타내는 모델 트리까지 각자 고유한 라이선스를 가질 수 있습니다. 가이드의 라이선스 의무(3.5)와 투명성 의무(3.6)가 코드와 가중치, 데이터셋을 함께 거론하는 이유입니다. 오픈소스 컴플라이언스가 “어떤 구성요소가 어떤 라이선스로 들어왔는가"를 묻는다면, AI에서는 같은 질문을 모델과 데이터에까지 확장해야 합니다. 5230의 프로세스 중심적이고 비규정적인 철학은 이 확장에 잘 맞습니다. 규제 환경이 관할 구역마다 빠르게 갈라지는 상황에서, 구체적 절차를 못 박는 대신 “무엇을 입증해야 하는가"만 고정하면 유럽연합·미국·중국처럼 서로 다른 체제의 조직이 같은 기준점을 공유할 수 있습니다.

소프트웨어 자재 명세서(Software Bill of Materials, SBOM)는 소프트웨어를 구성하는 구성요소와 공급망 관계를 담은 공식 기록입니다. 미국에서는 2021년 5월 국가 사이버보안 개선에 관한 행정명령 14028(Executive Order 14028)이 SBOM 최소 요소 정의를 지시했고, 국가통신정보청(National Telecommunications and Information Administration, NTIA)이 2021년 7월 12일 Minimum Elements for a Software Bill of Materials를 발표했습니다D4·D1. 전통적 SBOM은 소프트웨어 구성요소를 식별·추적하도록 설계되어, 학습 과정과 데이터, 모델의 거동을 그대로 표현하기는 어렵습니다. 가이드가 정의하는 AI SBOM은 “AI 시스템의 일부 또는 전체를 구성하는 구성요소와 그에 관한 관련 정보의 목록"으로, 모델과 데이터셋을 명시적으로 포함합니다. 같은 개념을 업계에서는 AI BOM 또는 기계학습 자재 명세서(Machine Learning Bill of Materials, ML-BOM)로도 부릅니다.

형식 측면에서 가이드는 SPDX, CycloneDX, 그 밖의 어떤 형식이든 무방하다고 열어 둡니다. SPDX(System Package Data Exchange)는 ISO/IEC 5962:2021로 국제표준화된 교환 표준으로, 2024년 4월 16일 공개된 SPDX 3.0이 AI 프로파일(AI Profile)과 데이터셋 프로파일(Dataset Profile)을 도입해 모델 유형, 하이퍼파라미터, 학습 데이터 전처리, 에너지 소비, 안전 위험 평가 같은 정보를 표현하도록 했습니다A5·B6·B2. CycloneDX는 OWASP가 주관하는 풀스택 BOM 표준으로, 버전 1.5에서 ML-BOM을 도입해 데이터셋과 모델, 구성과 학습 데이터 출처, 윤리적 고려사항, 편향, 모델 보안 위험을 문서화하도록 했습니다B5. 두 포맷은 표현 모델이 다르지만 모델과 데이터셋을 1급 구성요소로 다뤄 같은 문제를 겨냥합니다.

가이드 각주가 ISO/IEC 42001:2023을 반복 참조하는 것도 짚어 둘 부분입니다. 42001은 AI 경영시스템(AI Management System, AIMS)을 수립·운영·개선하기 위한 요구사항을 규정한 최초의 AI 경영시스템 국제표준으로, 부속서 B(Annex B)가 통제를 AI 수명주기 단계별로 구현하는 방법을 설명합니다A4. 오픈체인 방법론이 “무엇을 입증해야 하는가"를 정의한다면, 42001 Annex B는 “그 입증을 위해 무엇을 문서화하고 운영해야 하는가"에 대한 구체적 통제 항목을 제공합니다. 가이드는 42001을 대체하지 않고, 역량, 인지, 자원, 거버넌스, SBOM 절의 근거로 Annex B의 특정 절(B.2.2, B.3, B.4.2, B.4.6, B.5.3, B.6.2, B.8.5, B.9.3 등)과 본문 7.3을 호출합니다A4.

3. 가이드의 구조와 요구사항

가이드 본문(3장 Guidance)은 열 개의 요구사항 절로 이뤄집니다. 모든 절이 5230 방식대로 요구사항 진술, 검증 자료, 근거의 세 부분을 반복합니다. 각주가 명시하듯 명세서라면 “Requirements"라 부를 자리를 이 문서는 “Guidance(지침)“로 부르는데, 항목들이 규범적 강제가 아니라 권고임을 분명히 하기 위해서입니다A1.

요구사항을 의미별로 묶으면 두 계열로 나뉩니다. 하나는 ISO/IEC 5230에서 그대로 물려받은 프로그램 거버넌스 골격(정책, 역량, 인지, 범위, 자원, 접근)이고, 다른 하나는 AI 때문에 새로 확장된 영역(라이선스 의무, 투명성 의무, AI SBOM, AI 거버넌스)입니다. 그림 1이 이 군집 구조를 보여줍니다.

%%{init: {"theme": "neutral", "themeVariables": {"fontSize": "18px"}}}%%
flowchart TB
    ROOT["OpenChain AI SBOM 가이드<br/>본문 10개 요구사항"]

    ROOT --> G1
    ROOT --> G2
    ROOT --> G3
    ROOT --> G4

    subgraph G1["프로그램 기반 (ISO/IEC 5230 계승)"]
        direction TB
        R31["3.1 정책<br/>(Policy)"]
        R32["3.2 역량<br/>(Competence)"]
        R33["3.3 인지<br/>(Awareness)"]
        R34["3.4 프로그램 범위<br/>(Program scope)"]
        R38["3.8 효과적 자원 배분<br/>(Effectively resourced)"]
        R31 --> R32 --> R33 --> R34 --> R38
    end

    subgraph G2["외부 대응"]
        direction TB
        R37["3.7 접근<br/>(Access)"]
    end

    subgraph G3["AI 특화 컴플라이언스 (AI 확장)"]
        direction TB
        R35["3.5 라이선스 의무<br/>(License obligations)"]
        R36["3.6 투명성 의무<br/>(Transparency obligations)"]
        R39["3.9 AI SBOM"]
        R35 --> R36 --> R39
    end

    subgraph G4["AI 거버넌스 (AI 확장)"]
        direction TB
        R310["3.10 거버넌스<br/>(Governance)"]
    end

    classDef inherited fill:#eef3f7,stroke:#5a7184,stroke-width:1px,color:#1a2630;
    classDef extended fill:#fbf3e6,stroke:#9c7a3c,stroke-width:1px,color:#2e2410;
    classDef root fill:#ffffff,stroke:#333,stroke-width:2px,color:#000;

    class ROOT root;
    class R31,R32,R33,R34,R38,R37 inherited;
    class R35,R36,R39,R310 extended;

그림 1. OpenChain AI SBOM 가이드의 요구사항 군집 구조 (OpenChain AI SBOM Compliance Guide 본문 3.1~3.10 기준, 작성일 2026-06-12)

각 요구사항의 핵심은 표 1과 같습니다. 표의 “강제 수준"은 가이드 본문이 쓴 RFC 2119 키워드(shall, should 등)를 옮긴 것으로, 정의는 가이드 2장이 IETF RFC 2119에서 가져왔습니다A1·A6.

표 1. 가이드 본문 10개 요구사항 요약 (OpenChain AI SBOM Compliance Guide 본문 3.1~3.10 기준, 2026-06-12)

라이선스 의무(3.5) 절은 AI 확장의 성격을 가장 잘 드러냅니다. 검토 대상에 코드뿐 아니라 가중치와 학습·테스트·검증 데이터셋, 그리고 AI 시스템 자체의 라이선스가 모두 들어가고, 모델 트리상에서 상류와 하류에 걸린 의무, 제한, 권리를 검토하고 문서화하라고 요구합니다A1. 이 절은 5230:2020 Section 3.3.2를 근거로 명시하고, 42001 Annex B.2.2를 예시로 참조합니다. AI SBOM(3.9) 절은 형식을 SPDX나 CycloneDX 등으로 열어두되 인바운드 자재(제3자에게서 유입되는 모델과 데이터셋 등)를 반영할 것을 shall 수준으로 요구합니다A1·B2. 거버넌스(3.10) 절은 EU 인공지능법(EU AI Act), 히로시마 AI 프로세스(Hiroshima AI Process), 중국 글로벌 AI 거버넌스 이니셔티브(Global AI Governance Initiative)를 신흥 규제의 예로 직접 거명하며, 윤리적 고려와 위험 관리, 투명성과 함께 AI 시스템 수명주기 모니터링 능력을 다룹니다A1.

4. 규제·거버넌스 동향

가이드 거버넌스 절이 거명한 세 축은 조사 기준일(2026-06-12)을 전후로 모두 의미 있는 진전이 있었습니다. 무엇보다 가이드 자체가 2025년 10월 20일 Version 1으로 발표되었습니다A9.

EU 인공지능법(Regulation (EU) 2024/1689)이 첫 번째 축입니다. 단계적으로 적용되며, 조사 기준일 현재 일부 조항만 시행되었습니다. 표 2가 적용 일정을 정리합니다.

표 2. EU 인공지능법 단계적 적용 일정 (출처: Regulation (EU) 2024/1689 Article 113 / EUR-Lex, European Commission, 접속: 2026-06-12)

범용 AI 모델(General-Purpose AI, GPAI) 제공자 의무는 2025년 8월 2일부터 적용되기 시작했으나, 집행위원회(European Commission)가 과징금을 포함한 집행 권한을 실제로 행사할 수 있는 시점은 2026년 8월 2일입니다C1·C6. 같은 날 부속서 III 고위험 AI 시스템 의무와 투명성 의무도 적용됩니다. 가이드 3.6절이 “규제로부터 부과되는 투명성 의무"를 검토하라고 요구하는 배경에 이 2026년 8월 적용일이 있습니다. AI SBOM과의 접점은 인공지능법 Article 11과 부속서 IV가 요구하는 기술 문서화로, 2026년 8월부터 적용되는 이 요구사항이 AI BOM을 선택적 보안 산출물에서 사실상의 조달 요건으로 밀어 올리는 동력으로 거론됩니다C1.

두 번째 축인 히로시마 AI 프로세스는 2023년 일본의 G7 의장국 시기에 시작되어 첨단 AI 개발 조직을 위한 국제 행동강령(International Code of Conduct)을 산출했고, 이행 점검 수단으로 경제협력개발기구(OECD)가 보고 프레임워크(HAIP Reporting Framework)를 운영합니다C4. 2025년 2월 7일 1.0이 출범했고, 2026년 5월 28일 파리 G7 디지털·기술 장관회의 계기에 OECD가 보고 프레임워크 2.0을 발표했습니다C4·C7. 2.0은 중소기업 참여를 넓히기 위해 절차를 간소화하고 모델 개발자, 애플리케이션 개발자, 배포자를 구분하는 역할 기반 구조를 도입했으며, 50개 이상의 조직이 새 프레임워크로 보고하겠다고 표명했습니다(차기 분석 리뷰 제출 마감 2026-09-01)C7. 가이드가 말한 “히로시마 AI 프로세스 준수"는 이 자발적 보고 프레임워크 참여를 가리킵니다.

세 번째 축인 중국 글로벌 AI 거버넌스 이니셔티브는 2023년 10월 베이징의 일대일로 국제협력 정상포럼 계기에 발표된 정책 선언입니다. EU 인공지능법이나 히로시마 프로세스와 달리 구체적 보고 양식이나 컴플라이언스 산출물을 정의하지 않아, AI SBOM 관점에서 직접 대응되는 의무 항목은 현재 없습니다. 가이드는 이를 신흥 AI 규제의 한 사례로 병렬 언급하는 수준입니다.

형식 표준도 움직였습니다. SPDX는 2024년 4월 SPDX 3.0으로 AI·데이터셋 프로파일을 도입했고, CycloneDX는 2023년 6월 v1.5에서 ML-BOM을 도입한 뒤 2025년 10월 v1.7(ECMA-424 2판)을 1.x 계열의 마지막 릴리스로 냈습니다B6·B5. 생성 도구도 등장했습니다. OWASP는 2025년 AIBOM 생성기(OWASP AIBOM Generator)를 공개해 허깅페이스(Hugging Face) 모델에서 CycloneDX 형식의 AI SBOM을 자동 생성하고 완전성 점수를 매기며B7, CycloneDX의 cdxgen도 AI BOM 전용 모드를 지원합니다B8. 다만 이들은 모델 카드에 적힌 라이선스를 옮겨 담을 뿐, 그 정확성까지 보장하지는 못해, OWASP AIBOM 프로젝트는 SPDX·CycloneDX가 AI 고유 사용 사례를 충분히 다루지 못하는 공백을 함께 평가하고 있습니다E6.

5. 의의와 한계

이 가이드의 가치는 “AI 공급망 컴플라이언스 프로그램이 갖춰야 할 최소 요구사항"을 ISO 국제표준으로 검증된 방법론 위에 명시했다는 점에 있습니다. 검증 자료와 근거를 모든 절에 붙이는 5230식 구조 덕분에, 조직은 각 요구사항을 자체 점검표로 바꿔 “우리에게 이 산출물이 있는가"를 직접 확인할 수 있습니다. 형식을 SPDX·CycloneDX 등으로 열어두고 절차의 구체를 조직에 위임한 비규범적 설계는, 규제가 관할 구역마다 갈라지는 환경에서 공통 기준점을 제공하는 실용적 선택입니다.

한계도 분명합니다. 가이드가 요구하는 라이선스와 투명성 추적이 현실에서 어렵다는 점입니다. 모델이 다운스트림으로 전파되며 의무가 탈락하는 라이선스 드리프트(license drift)를 정량화한 한 연구는, 모델에서 애플리케이션으로 넘어가는 전이의 약 35.5%가 제한 조항을 잃고 허용 라이선스로 재지정되며, 머신러닝 고유의 의무는 다운스트림 통합 이후 0.4%만 보존된다고 보고합니다E4. 책임 있는 AI 라이선스(Responsible AI License, RAIL) 계열과 Llama 커뮤니티 라이선스는 행동 사용 제한(behavioral use clause)을 담아 오픈소스 이니셔티브(Open Source Initiative, OSI)의 오픈소스 정의를 충족하지 못하며, 이런 비표준 라이선스의 준수 여부를 추적할 도구가 아직 부족합니다E8·E5. 가이드 3.5절이 코드를 넘어 가중치·데이터셋 라이선스까지 검토하도록 요구한 것은 이 현실을 반영한 설계입니다. AI SBOM을 자동으로 생성하는 도구는 이미 여럿 나왔지만, 생성된 명세서의 라이선스가 정확한지, 비표준 라이선스의 사용 제한을 지키는지 검증하는 일은 아직 사람과 정책의 몫입니다. 2026년 현재 요구와 실행 가능성 사이에 남은 것은 생성의 간극이 아니라 검증의 간극입니다.

가이드가 스스로를 살아있는 문서로 규정하고 Version 1이라는 번호로 후속 개정을 전제한 점도 한계이자 특징입니다. 규제와 형식 표준이 빠르게 바뀌는 영역인 만큼 가이드 역시 고정된 명세가 아니며, 조사 기준일 현재 차기 개정 일정은 공개되지 않았습니다.

6. 프로세스 요구와 데이터 항목 요구

이 가이드가 정의하는 것은 컴플라이언스의 프로세스 층위입니다. 정책이 존재하는가, 역량과 자원이 배정되어 있는가, AI SBOM을 생성하고 관리하는 절차가 있는가처럼 프로그램이 갖춰야 할 최소 요구사항에 초점을 둡니다. 이와 구별되는 또 다른 층위가 데이터 항목입니다. EU 인공지능법 Article 11과 부속서 IV가 요구하는 기술 문서처럼, 규제가 실제로 어떤 항목을 AI BOM에 담으라고 요구하는가는 별도의 매핑 작업으로 풀어야 합니다C1. 가이드 3.5절(라이선스 의무), 3.6절(투명성 의무), 3.9절(AI SBOM)이 추상적으로 요구하는 절차에 규제 조문별 기재 항목을 결합해야, 프로세스 요구와 데이터 항목 요구가 한 체계로 이어집니다.

참고문헌

본문에서 인용한 출처만 03-references.md의 통합 라벨 체계에 맞춰 단락 형식으로 정리합니다. 전체 출처 목록과 자동 확인 메모는 같은 폴더의 03-references.md를 참조하십시오.

A. 원본 및 OpenChain·표준

A1. OpenChain Project AI Work Group (2024). Artificial Intelligence System Bill of Materials — Compliance Management Guide for the Supply Chain (RFC Draft, 문서 NOTICE상 CC-BY-4.0). GitHub OpenChain-Project/AI-WG, /docs 디렉토리. https://github.com/OpenChain-Project/AI-WG/tree/main/docs (접속: 2026-06-12). — 본 보고서의 원본 문서. ↩

A2. OpenChain Project AI Work Group. AI-WG 저장소(워크그룹 홈). https://github.com/OpenChain-Project/AI-WG (접속: 2026-06-12). — 가이드의 발행 맥락과 워크그룹 운영 근거. ↩

A3. ISO/IEC (2020). ISO/IEC 5230:2020 — Information technology — OpenChain Specification. https://www.iso.org/standard/81039.html (접속: 2026-06-12, 자동 확인 제한: iso.org 봇 차단). — 가이드가 영감을 얻은 모체 표준. 3.5 라이선스 의무 절의 Section 3.3.2 참조 기반. ↩

A4. ISO/IEC (2023). ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system. https://www.iso.org/standard/81230.html (접속: 2026-06-12, 자동 확인 제한: iso.org 봇 차단). — 가이드 각주가 반복 참조하는 표준(Annex B, Section 7.3). ↩

A5. ISO/IEC (2021). ISO/IEC 5962:2021 — Information technology — SPDX Specification V2.2.1. https://www.iso.org/standard/81870.html (접속: 2026-06-12, 자동 확인 제한: iso.org 봇 차단). — 개요에서 직접 참조한 SBOM 형식 표준. ↩

A6. Bradner, S. (1997). RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels. IETF, BCP 14. https://www.ietf.org/rfc/rfc2119.txt (접속: 2026-06-12). — 2장 용어·정의의 MUST/SHOULD/MAY 해석 출처. ↩

A9. OpenChain Project (2025-10-20). Welcoming the OpenChain AI System Bill of Materials Compliance Guide. https://openchainproject.org/news/2025/10/20/welcoming-the-openchain-ai-system-bill-of-materials-compliance-guide (접속: 2026-06-12). — Version 1 정식 발표일(2025-10-20), 문서 성격(참조 가이드), 배포 형식(PDF·마크다운)의 1차 근거. ↩

A10. OpenChain Project (2025-07-07). Public Comment Period Announced: Artificial Intelligence System Bill of Materials – Compliance Management Guide for the Supply Chain. https://openchainproject.org/news/2025/07/07/public-comments-ai-system-bill-of-materials (접속: 2026-06-12). — 6주 공개 의견 수렴 개시(2025-07-07)·마감(2025-08-18) 1차 확인. ↩

A11. OpenChain Project (2025-08-20). Review of Public Comments and Next Steps: Artificial Intelligence System Bill of Materials – Compliance Management Guide for the Supply Chain. https://openchainproject.org/news/2025/08/20/ai-bom-next-steps (접속: 2026-06-12). — 의견 검토 결과와 거버닝 보드의 발표 결정 과정. ↩

A12. OpenChain Project. Reference-Material 저장소 — AI-SBOM-Compliance/en (정식본 배포 위치). https://github.com/OpenChain-Project/Reference-Material/tree/master/AI-SBOM-Compliance/en (접속: 2026-06-12). — 인용 가능한 정식 발표본의 실제 배포 위치. ↩

A13. OpenChain Project (2023-12-19). OpenChain Welcomes ISO/IEC 18974:2023, The International Standard For Open Source Security Assurance. https://openchainproject.org/news/2023/12/19/openchain-welcomes-iso-iec-18974 (접속: 2026-06-12). 표준 원문: https://www.iso.org/standard/86450.html. — OpenChain의 보안 영역 확장(ISO/IEC 18974:2023) 근거. ↩

A14. OpenChain Project (2020). OpenChain ISO/IEC 5230:2020 Specification (en). GitHub License-Compliance-Specification. https://github.com/OpenChain-Project/License-Compliance-Specification/blob/master/Official/en/ISO-5230-2020/ISO-5230-2020.md (접속: 2026-06-12). — “검증 자료 + 근거” 구조와 “무엇·왜에 집중, 어떻게·언제는 비규정” 진술의 1차 근거. ↩

B. AI BOM 포맷

B2. SPDX Project. SPDX 3.0.1 Specification — AI Profile. https://spdx.github.io/spdx-spec/v3.0.1/model/AI/AI/ (접속: 2026-06-12). — AI SBOM에 들어가는 구체 데이터 요소의 1차 규격. ↩

B5. CycloneDX. Capabilities — Machine Learning Bill of Materials (ML-BOM). https://cyclonedx.org/capabilities/mlbom/ (접속: 2026-06-12). — ML-BOM 규격. v1.5(2023-06) 도입부터 v1.7(2025-10, ECMA-424 2판)까지의 이력. ↩

B6. The Linux Foundation (2024-04-16). SPDX 3.0 Revolutionizes Software Management in Systems with Enhanced Functionality and Streamlined Use Cases (보도자료, Seattle). https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases (접속: 2026-06-12). — SPDX 3.0 발표일(2024-04-16)과 AI 프로파일 신규 사용 사례의 1차 근거. ↩

B7. OWASP Gen AI Security Project. OWASP AIBOM Generator. https://genai.owasp.org/resource/owasp-aibom-generator/ (접속: 2026-06-12). — 허깅페이스 모델에서 CycloneDX 형식 AI SBOM을 자동 생성하고 완전성 점수를 매기는 공개 도구의 1차 근거. ↩

B8. cdxgen Project (OWASP CycloneDX). AI/ML-BOM generation (AI_BOM.md). GitHub cdxgen/cdxgen. https://github.com/cdxgen/cdxgen/blob/master/docs/AI_BOM.md (접속: 2026-06-12). — cdxgen의 AI BOM 전용 모드(허깅페이스 URL·Modelfile·GGUF 입력) 사용법의 1차 근거. ↩

C. 규제·거버넌스

C1. European Parliament and Council (2024). Regulation (EU) 2024/1689 — Artificial Intelligence Act. Official Journal of the EU, 2024/1689, 13.6.2024(관보 게재 2024-07-12, 발효 2024-08-01). https://eur-lex.europa.eu/eli/reg/2024/1689/oj (접속: 2026-06-12). — 3.10 거버넌스 절이 명시한 EU AI Act 원문. Article 113의 단계적 적용일·투명성·위험관리 의무의 1차 규제 근거. ↩

C4. OECD. Hiroshima AI Process (HAIP) Reporting Framework (transparency.oecd.org). https://transparency.oecd.org/ (접속: 2026-06-12, 자동 확인 제한: 연결 거부/봇 차단). — HAIP 기업 보고 프레임워크의 제출 플랫폼. 1.0 단계 근거. ↩

C6. European Commission. AI Act | Shaping Europe’s digital future (Regulatory framework for AI). https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai (접속: 2026-06-12). — GPAI 의무가 2025-08-02부터 적용됨을 1차 확인. EUR-Lex 원문(C1)과 함께 적용일·의무 범위 교차 근거. ↩

C7. OECD.AI (2026-05-28). OECD launches Hiroshima AI Process Reporting Framework 2.0. https://oecd.ai/en/haip-2-launch (접속: 2026-06-12). 보도자료: https://www.oecd.org/en/about/news/press-releases/2026/05/oecd-launches-streamlined-hiroshima-ai-process-reporting-framework-to-help-small-and-medium-sized-enterprises-participate.html (자동 확인 제한: oecd.org 봇 차단). — HAIP 보고 프레임워크 2.0 출범일(2026-05-28, 파리 G7 디지털·기술 장관회의), 중소기업 초점, 역할 기반 구조, 50개 이상 조직 참여, 차기 리뷰 마감(2026-09-01) 근거. ↩

D. SBOM 정책 배경

D1. NTIA, U.S. Department of Commerce (2021). The Minimum Elements For a Software Bill of Materials (SBOM) (행정명령 14028 §10(j) 이행, 2021-07-12). https://www.ntia.gov/files/ntia/publications/sbom_minimum_elements_report.pdf (접속: 2026-06-12, 자동 확인 제한: .gov 봇 차단). — AI SBOM의 모태인 SBOM 최소 요소 정책 기준. ↩

D4. NIST. Software Security in Supply Chains: Software Bill of Materials (SBOM) — Executive Order 14028. Information Technology Laboratory. https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-security-supply-chains-software-1 (접속: 2026-06-12). — 행정명령 14028의 SBOM 정의를 담고 SPDX·CycloneDX·SWID 준수와 NTIA 최소 요소 충족을 권고하는 NIST 1차 페이지. ↩

E. 보조(학술·업계)

E4. Jewitt, J., Li, H., Adams, B., Rajbahadur, G. K., Hassan, A. E. (2025). From Hugging Face to GitHub: Tracing License Drift in the Open-Source AI Ecosystem. arXiv:2509.09873. https://arxiv.org/abs/2509.09873 (접속: 2026-06-12). — 라이선스 드리프트를 정량화한 학술 근거(모델에서 애플리케이션으로의 전이에서 제한 조항 35.5% 상실, ML 고유 의무 0.4% 보존). ↩

E5. arXiv (2025). New Tools are Needed for Tracking Adherence to AI Model Behavioral Use Clauses. arXiv:2505.22287. https://arxiv.org/abs/2505.22287 (접속: 2026-06-12). — RAIL/OpenRAIL·Llama 커뮤니티 라이선스의 행동 사용 제한 준수를 추적할 도구가 부족하다는 지적. ↩

E6. Jin, S. et al. (2025). Building an Open AIBOM Standard in the Wild. arXiv:2510.07070 (ICSE 2026 SEIP 채택). https://arxiv.org/abs/2510.07070 (접속: 2026-06-12). — OWASP AIBOM 프로젝트의 표준화 접근과 AI 데이터셋·학습 산출물 표현 공백 논의. ↩

E8. JUN Legal (2025-03-18). Responsible AI Licenses (RAIL). https://jun.legal/en/2025/03/18/responsible-ai-licenses-rail-verantwortungsvolle-ki-nutzung-durch-lizenzierung/ (접속: 2026-06-12). — RAIL/OpenRAIL과 Llama 커뮤니티 라이선스가 행동 사용 제한 때문에 OSI 오픈소스 정의를 충족하지 못한다는 업계·법무 해설. ↩

5 - 미국 AI 행정명령(2026-06-02)이 기업 오픈소스 관리자에게 의미하는 것

요약

2026년 6월 2일 서명된 행정명령 “Promoting Advanced Artificial Intelligence Innovation and Security"는 기업에 어떤 의무도 부과하지 않습니다. 재무부가 이끄는 AI 사이버보안 클리어링하우스(취약점 정보를 한곳에 모아 검증하고 배분하는 중계 기구, 30일 내 구성)와 프런티어 모델의 자발적 사전 공유 체계(60일 내 설계)가 골자이고, 의무 라이선싱과 사전심사는 명시적으로 배제됐습니다 A1. 기업 오픈소스 관리자에게 직접 적용되는 조항도 없습니다. 그런데도 이 명령을 읽어야 하는 이유는 배경에 있습니다. AI가 오픈소스 취약점을 사람보다 빠르게 찾아내는 상황이 이미 현실이 됐기 때문입니다. 행정명령에 앞서 앤트로픽의 미공개 모델은 두 달 만에 오픈소스 프로젝트에서 높음 또는 치명 등급 취약점 6,202건을 찾아냈고, 패치가 그 속도를 따라가지 못하고 있습니다 A6·C1. 오픈소스 관리자가 준비할 것은 행정명령 컴플라이언스가 아니라 패치 처리 능력 점검과 EOL 컴포넌트 정리, 그리고 2026년 9월 11일 시행되는 EU 사이버 복원력법 보고 의무까지 한꺼번에 감당할 대응 체계입니다.

1. 행정명령이 실제로 정한 것

행정명령은 다섯 개 조로 구성되며, 모든 조항이 자발적 협력을 전제로 합니다. Section 1은 “과도한 규제로 혁신을 억누르기를 거부한다"는 기조와 미국 우선(America First) 사이버보안을 선언하고, Section 5는 통상적인 일반 규정입니다. 실질 내용은 가운데 세 개 조에 있습니다 A1.

Section 2는 연방과 민간의 사이버 방어 강화를 다룹니다. 30일 내에 국가안보시스템, 전쟁부(Department of War) 시스템, 연방 민간 시스템의 방어를 우선시하고, 같은 기한에 재무부 장관이 국가사이버국장(National Cyber Director), 국가안보국(National Security Agency, NSA), 사이버보안·인프라보안청(Cybersecurity and Infrastructure Security Agency, CISA)과 협의해 AI 사이버보안 클리어링하우스(AI cybersecurity clearinghouse)를 구성합니다. 클리어링하우스는 본래 은행 간 어음 교환소를 가리키는 말로, 여러 참여자의 정보를 한곳에 모아 검증하고 배분하는 중계 기구를 뜻합니다. 여기서는 AI 업계 및 핵심 인프라 운영자와의 자발적 협력으로 소프트웨어 취약점 스캔을 조율해 중복을 없애고, 취약점을 발견해 검증하며, 패치의 수정과 배포에 우선순위를 매기는 역할을 맡습니다 A1.

Section 3은 프런티어 모델의 안전한 배포를 다룹니다. 60일 내에 AI 모델의 사이버 공격 능력을 평가하는 기밀 벤치마킹 절차를 마련하고, 그 결과로 어떤 모델이 “대상 프런티어 모델(covered frontier model)“인지의 임계값을 NSA 국장이 결정합니다. 개발자는 자발적 프레임워크를 통해 자기 모델이 지정 기준에 해당하는지 정부와 협의하고, 공개 예정일로부터 최대 30일 전까지 정부에 모델 접근을 제공하며, 조기 접근을 받을 신뢰 파트너(trusted partners)를 정부와 함께 고릅니다. Sec. 3(c)는 이 조의 어떤 내용도 새 AI 모델의 개발과 발행, 공개, 배포에 대한 의무 라이선싱이나 사전심사, 허가 요건을 신설하지 않는다고 못 박았습니다 A1.

Section 4는 수사와 집행을 다룹니다. 법무부 장관은 AI를 이용한 무단 컴퓨터 접근과 손상, 그 과정에서 저질러지는 다른 범죄에 대해 18 U.S.C. 1030(컴퓨터 사기 및 남용) 등 기존 연방 형사법의 집행을 우선시합니다 A1.

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 40, 'rankSpacing': 45}} }%%
flowchart TD
    A["<b>2023-10-30</b> &nbsp; 바이든 행정명령 14110호 — 첫 포괄적 AI 관리 체계"]
    B["<b>2025-01</b> &nbsp; 취임일(01-20)에 14110호 폐지, 행정명령 14179호 서명(01-23)"]
    C["<b>2025-07-23</b> &nbsp; 미국 AI 행동계획 발표 — 오픈소스와 오픈웨이트 장려 절 포함"]
    D["<b>2026-04-07</b> &nbsp; 앤트로픽 Mythos Preview와 Project Glasswing 발표"]
    E["<b>2026-06-02</b> &nbsp; 본 행정명령 서명, Glasswing 150개 조직 확대"]
    F["<b>2026-06-05</b> &nbsp; NSPM-11 — 국가안보 분야 AI 각서"]
    G["<b>2026-07-02</b> &nbsp; 30일 기한 — 클리어링하우스 구성, 연방 시스템 방어"]
    H["<b>2026-08-01</b> &nbsp; 60일 기한 — 기밀 벤치마킹과 자발적 프레임워크 설계"]
    A --> B --> C --> D --> E --> F --> G --> H
    style E fill:#fff3e0,stroke:#ef6c00,stroke-width:2px

그림 1. 행정명령 전후의 정책 타임라인 (출처: 백악관 공식 문서 A1·A2·A3·A4·A5, Anthropic A6, Wiley 기한 계산 B1. 2026-06-10 기준)

주관 기관 선정은 의외라는 평가가 나옵니다. 취약점 조정이라는 기능만 보면 CISA나 국가사이버국장실이 맡는 것이 자연스러운데, 클리어링하우스는 재무부가 이끕니다. 외교협회(Council on Foreign Relations, CFR)는 재무부가 “제도적 역량이 남아 있는 몇 안 되는 곳"이기 때문일 수 있다고 해석했고, 대서양위원회(Atlantic Council)는 기존 취약점 조정 체계와 겹칠 위험을 지적했습니다 B4·B5. 핵심 용어인 대상 프런티어 모델의 기준도 본문에 정의되지 않았습니다. 기밀 벤치마킹의 결과로 정해지며, WilmerHale은 이 기준 정의가 향후 수개월간 기관 규칙 제정(rulemaking)의 초점이 될 것으로 내다봤습니다 B2.

2. 왜 지금 나왔나

행정명령의 직접 배경은 2026년 4월 7일 앤트로픽(Anthropic)이 발표한 클로드 미토스 프리뷰(Claude Mythos Preview)입니다. 이 미공개 모델은 취약점 재현 벤치마크 CyberGym에서 83.1%를 기록했고(직전 모델은 66.6%), 앤트로픽은 일반 공개 대신 AWS, Apple, Google, Microsoft 등 12개 파트너에게만 접근을 여는 프로젝트 글래스윙(Project Glasswing)을 택했습니다 A6. 두 달이 안 되는 기간에 참여 조직들은 1만 건이 넘는 높음 또는 치명 등급 취약점을 식별했습니다. 앤트로픽 자체 스캔만으로 1,000개 이상의 오픈소스 프로젝트에서 23,019건의 문제가 나왔고 그중 6,202건이 높음 또는 치명 등급이었으며, 독립 보안 기업이 표본 1,752건을 검증해 90% 이상이 실제 취약점임을 확인했습니다 C1·C2. OpenBSD에 27년간 잠복한 원격 크래시 결함, 500만 회의 자동 테스트를 통과해 온 FFmpeg의 16년 된 결함, 리눅스 커널의 권한 상승 체인이 대표 사례입니다 A6.

이 과정에서 취약점을 찾는 속도와 고치는 속도가 크게 어긋난다는 사실이 드러났습니다. 앤트로픽 스스로 “이런 버그를 고치는 병목은 분류하고 보고하고 패치를 설계해 배포하는 인간의 역량"이라고 밝혔고, 오픈소스 유지보수자가 병목이 되자 OpenSSF의 알파-오메가(Alpha-Omega) 프로젝트와 협력을 시작했습니다 C1·C2. 브루스 슈나이어(Bruce Schneier)는 당분간 “고치기 위한 발견"이 “악용을 위한 발견"보다 쉬워 방어자에게 유리한 창이 열려 있지만 이 창은 일시적이며, 자동화된 제로데이 발견의 시대는 우리가 준비를 끝내기 전에 올 것이라고 평가했습니다. 보안 기업 Aisle이 더 오래된 공개 모델로 결과 일부를 재현한 점을 들어, 이런 능력이 특정 회사의 전유물은 아니라는 단서도 달았습니다 C3.

행정명령은 이 상황에 대한 미국 정부의 대응입니다. 글래스윙처럼 민간이 개별적으로 하던 일, 곧 AI로 취약점을 찾고 검증하고 패치를 조정하는 일을 정부가 국가 단위로 조율하겠다는 구상이 클리어링하우스입니다 A1·B5.

3. 기업 오픈소스 관리자에게 의미하는 것

3.1 “오픈소스"가 한 번도 나오지 않는 문서

행정명령 본문과 백악관 팩트시트 어디에도 “open source"라는 표현이 없습니다 A1·A2. 좋은 쪽으로 보면 규제 부담이 없다는 뜻입니다. 명령은 오픈소스 개발자나 오픈웨이트(open-weight) 모델 배포자에게 어떤 의무도 지우지 않으며, Sec. 3(c)의 라이선싱 금지 조항은 모델의 “개발, 발행, 공개, 배포"를 모두 포괄하므로 가중치 공개 방식의 배포도 보호 범위에 듭니다 A1. 행정부의 공식 기조도 2025년 7월 AI 행동계획에서 밝힌 그대로입니다. 공개와 폐쇄의 선택은 전적으로 개발자의 몫이며, 연방정부는 공개 모델에 우호적인 환경을 만든다는 것입니다 A5.

남는 문제는 대상 프런티어 모델의 임계값입니다. 기밀 벤치마크로 정해지므로 공개 가중치 모델이 그 기준을 넘으면 어떤 일이 생기는지 지금은 알 수 없습니다. 자발적 프레임워크의 핵심 장치인 “공개 30일 전 정부 접근"은 출시 시점을 통제할 수 있는 폐쇄 모델에 맞춘 설계라서, 가중치를 한번 공개하면 회수할 수 없는 공개 모델에는 같은 방식이 들어맞지 않습니다. CFR의 전문가들은 프런티어급 취약점 추론 능력이 머지않아 공개 가중치 시스템에서도 재현될 것으로 보았고, 유사한 재현 연구가 이미 언급되고 있습니다 B5. 능력이 공개 모델로 확산되면 자발적 사전 공유라는 설계의 빈틈이 드러나고, 그때는 추가 규제 논의가 공개 모델을 겨냥할 수 있습니다. 사내에서 공개 가중치 모델을 가져다 쓰거나 미세조정해 배포하는 기업이라면, 8월 1일까지 나올 벤치마킹 절차와 후속 규칙 제정이 공개 모델을 어떻게 다루는지 지켜봐야 합니다.

오픈소스 재단들도 아직 조용합니다. 2026-06-10 기준 검색에서 오픈소스 이니셔티브(Open Source Initiative, OSI), 리눅스 재단(Linux Foundation), OpenSSF가 이 행정명령에 대해 낸 성명은 확인되지 않았습니다. 의무가 없으니 즉각 대응할 유인도 약했던 것으로 보입니다. 가장 가까운 공식 입장은 OSI가 2025년 3월 AI 행동계획 의견수렴에 낸 답변입니다 B7.

3.2 클리어링하우스와 기업 취약점 관리 체계의 접점

클리어링하우스의 기능 세 가지(스캔 조율, 발견과 검증, 패치 우선순위와 배포 조정)는 기업 오픈소스 관리 조직(OSPO 또는 제품 보안 조직)이 이미 운영하는 취약점 관리 체계와 정확히 겹칩니다 A1.

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 50, 'rankSpacing': 60}} }%%
flowchart TB
    GOV["<b>AI 사이버보안 클리어링하우스</b><br/>재무부 주도 — NSA, CISA, 국가사이버국장 협의<br/>(2026-07-02까지 구성)"]
    VOL["<b>자발적 참여자</b><br/>AI 개발사(취약점 발견 역량), 핵심 인프라 운영자"]
    OSS["<b>오픈소스 유지보수자</b><br/>조정 공개로 취약점 보고 수신"]
    ENT["<b>기업 오픈소스 관리자</b><br/>패치 소비, SBOM, CVD"]
    GOV <-->|"스캔 조율, 발견과 검증, 패치 우선순위"| VOL
    VOL --> OSS --> ENT
    GOV -.->|"권고와 배포 조정 (운영 방식 미공개)"| ENT
    style ENT fill:#e3f2fd,stroke:#1565c0,stroke-width:2px

그림 2. 클리어링하우스와 취약점 정보 흐름에서 기업 오픈소스 관리자의 위치 (출처: 행정명령 Sec. 2(d) A1 기반 분석. 점선은 아직 공개되지 않은 운영 방식)

대부분의 기업은 클리어링하우스를 정보 소비자로서 만나게 됩니다. 클리어링하우스가 작동하면 오픈소스 컴포넌트 취약점의 발견과 검증, 패치 우선순위 정보가 새 경로로 흘러나옵니다. 기업의 취약점 인텔리전스 파이프라인에 미국발 채널이 하나 더 생기고, 패치 우선순위 판단에 영향을 주는 조정 주체가 추가되는 셈입니다.

클리어링하우스에 직접 참여할지는 별개의 판단입니다. 핵심 인프라에 해당하는 기업(에너지, 금융, 의료, 통신 등)은 참여 대상으로 명시돼 있습니다 A1. 참여하면 취약점 정보를 먼저 받고, 패치 조정에서 발언권을 갖고, Sec. 2(c)(iii)가 언급하는 정부 지원 보안 도구에 접근할 수 있습니다. 대신 정보 공유에 따르는 법무 검토 부담을 지게 되고, Crowell & Moring이 지적했듯 참여자에 대한 책임 보호(liability protection)가 규정되지 않았고 비참여의 결과도 정의되지 않았다는 불명확성을 안게 됩니다 B3. WilmerHale의 전망대로 자발적 조항이 연방 조달 기준으로 옮겨 가면, 미국 정부와 거래하는 기업에는 참여가 사실상 전제 조건이 되는 시나리오도 있습니다 B2. 운영 방식이 공개되는 7월 초 이전에 결정을 서두를 이유는 없습니다.

3.3 가장 직접적인 영향: 패치 수요의 급증과 EOL 리스크

행정명령과 무관하게 진행 중이던 변화가 행정명령으로 가속됩니다. AI 기반 발견이 국가 체계로 제도화되고 연방 보조금까지 붙으면(Sec. 2(e)), 오픈소스 컴포넌트에서 보고되는 취약점은 늘 수밖에 없습니다. 글래스윙 수치가 그 규모를 미리 보여줬습니다.

기업이 가장 먼저 부딪히는 것은 처리량입니다. 자사 제품에 포함된 오픈소스 컴포넌트의 신규 CVE가 늘면 트리아지(영향 분석)와 패치 적용, 고객 커뮤니케이션이 함께 늘어야 합니다. 수작업 트리아지에 의존하는 조직부터 적체가 쌓입니다.

EOL(End-of-Life, 수명종료) 컴포넌트는 문제가 더 깊습니다. AI는 유지보수가 끝난 코드도 가리지 않고 스캔하지만, 패치는 유지보수자가 있어야 나옵니다. 상용 장기지원(LTS) 업체 HeroDevs가 짚었듯 찾는 속도와 고치는 속도의 격차는 EOL 소프트웨어에서 가장 크게 벌어집니다. 발견은 가속되는데 수정은 영영 나오지 않을 컴포넌트가 인벤토리에 남아 있다면, 그 위험은 시간이 갈수록 커집니다 C4. 27년 묵은 OpenBSD 결함과 16년 된 FFmpeg 결함은 오래되고 안정된 컴포넌트라서 안전하다는 통념이 더는 통하지 않음을 보여줍니다 A6.

업스트림 쪽 부담도 결국 기업의 리스크로 돌아옵니다. 오픈소스 유지보수자가 보고 홍수의 병목이 되고 있다는 것은 앤트로픽이 직접 확인한 사실입니다 C2. 자사가 의존하는 핵심 컴포넌트의 유지보수자가 트리아지에 매몰되면 패치 지연을 떠안는 쪽은 기업입니다. 핵심 의존성의 유지보수 건전성(유지보수자 수, 보안 대응 이력, 재단 소속 여부)을 평가 항목에 넣고, 필요하면 Alpha-Omega류의 업스트림 지원에 참여하는 것이 자사 리스크를 줄이는 경로입니다.

3.4 EU CRA와의 대비: 자발과 의무를 동시에 상대하기

미국의 클리어링하우스가 다루는 문제, 곧 소프트웨어 취약점의 발견과 패치는 EU가 사이버 복원력법(Cyber Resilience Act, CRA — Regulation (EU) 2024/2847)으로 의무화한 영역과 같습니다.

표 1. 미국 행정명령과 EU CRA 취약점 보고 체계 비교 (출처: 행정명령 원문 A1, Regulation (EU) 2024/2847 A7, 별도 보고서 D1. 2026-06-10 기준)

양쪽 시장에 제품을 내는 한국 기업이라면 우선순위가 분명합니다. 구속력과 시한, 과징금이 있는 쪽이 먼저입니다. CRA Article 14 보고 워크플로우는 석 달 뒤인 9월 11일까지 가동돼야 하고, ENISA가 현 단계에서 SRP 연동 API를 제공하지 않아 사람이 직접 제출하는 절차로 설계해야 한다는 실무 제약도 확인돼 있습니다 A7·D1. 미국 클리어링하우스는 그 다음입니다. 다만 두 체계는 같은 내부 역량, 곧 컴포넌트 인벤토리(SBOM), 취약점 트리아지, 조정 공개(Coordinated Vulnerability Disclosure, CVD) 창구, 패치 배포 절차 위에서 돌아갑니다. CRA 대비로 구축한 체계가 미국 측 자발적 참여의 기반이 되므로, 별도 체계를 두 번 만들 일이 아닙니다.

3.5 정책 분기: 미국의 자발적 협력, EU의 제도화

행정명령 다음 날인 6월 3일, EU 집행위원회는 기술 주권 패키지를 발표하며 오픈소스를 디지털 정책의 중심에 놓았습니다. 7년간 약 20억 유로의 공공·민간 자금 동원, 오픈소스 유지보수 수단(Open Source Maintenance Instrument) 신설, 공공 조달 개방화가 골자입니다 A8·D2. 하루 차이로 나온 두 문서는 같은 기술 환경에 대한 상반된 제도 설계를 보여줍니다. 미국은 규제를 배제하고 민간의 자발적 역량을 정부가 조율하는 모델이고, EU는 공공 자금과 법적 의무(CRA의 스튜어드 제도 포함)로 오픈소스 생태계 자체를 제도화하는 모델입니다.

글로벌 기업의 오픈소스 관리 정책은 이 분기를 전제로 짜야 합니다. 미국 시장에서는 자발적 협력 채널에 들어갈지 선택해야 하고, EU 시장에서는 CRA 컴플라이언스와 스튜어드 제도라는 의무에 대응해야 합니다. 한 회사 안에서 두 모드를 같은 팀이 운영하게 되므로, 정책 문서와 대응 조직을 시장별로 분리하기보다 공통 역량 위에 시장별 모듈을 얹는 구조가 현실적입니다.

3.6 AI 생성 코드 관리와는 다른 축

AI 생성 코드의 오픈소스 유입과 스니펫 검사를 다룬 별도 분석 D3과 이번 사안은 둘 다 AI와 오픈소스 관리에 걸쳐 있지만 축이 다릅니다. 그 분석이 다룬 것은 유입 관리, 곧 AI 코딩 도구가 패키지로 선언되지 않은 코드 조각을 코드베이스에 들여올 때의 라이선스와 출처 문제입니다. 이번 행정명령이 가리키는 것은 운영입니다. 이미 들어와 있는 오픈소스 컴포넌트의 취약점이 AI 때문에 더 빨리, 더 많이 드러나는 환경에서의 대응 문제입니다. AI는 이제 코드가 들어오는 단계와 취약점이 드러나는 단계 양쪽에 동시에 영향을 주고 있고, 두 축의 대응 체계는 따로 점검해야 합니다.

4. 준비사항

행정명령이 기업에 직접 요구하는 것은 없으므로, 준비는 지금 할 일과 지켜볼 일로 나뉩니다.

지금 할 일

출발점은 자사의 AI 노출면 인벤토리입니다. 사내에서 개발하거나 미세조정하는 모델(특히 공개 가중치 기반), 도입한 AI 코딩 도구와 보안 도구, AI가 생성해 코드베이스에 들어온 코드의 현황을 한곳에 정리합니다. 8월 1일 이후 대상 프런티어 모델 기준이 윤곽을 드러냈을 때, 자사가 그 언저리에 있는지 바로 판단할 수 있게 해 두는 것입니다.

오픈소스 취약점 대응 체계도 점검합니다. SBOM이 전 제품에서 최신인지, 신규 CVE 트리아지가 두세 배 유입을 감당할 수 있는지, CVD 창구가 작동하는지 확인합니다. 이 점검은 CRA Article 14 대비(9월 11일 시한)와 같은 작업이므로 별도 프로젝트를 만들 것 없이 CRA 준비에 합치면 됩니다 D1.

시급성이 가장 높은 것은 EOL 컴포넌트 정리입니다. SBOM에서 유지보수 종료 컴포넌트를 추려, 업그레이드 경로가 있으면 일정을 정하고, 당장 걷어낼 수 없으면 상용 LTS나 자체 패치 같은 패치 공급원을 정합니다. 영향이 없음을 입증할 수 있는 항목은 취약점 악용성 정보(Vulnerability Exploitability eXchange, VEX)로 문서화해 트리아지 부담을 줄입니다 C4.

마지막으로 핵심 업스트림 의존성의 건전성을 평가합니다. 매출에 직결되는 제품이 의존하는 상위 컴포넌트의 유지보수자 규모와 보안 대응 이력을 확인하고, 병목이 우려되는 프로젝트는 후원이나 기여 같은 지원 수단을 검토합니다 C2.

지켜볼 일

표 2. 추적 항목과 시점 (2026-06-10 기준)

5. 결론

이 행정명령은 기업 오픈소스 관리자에게 새 의무를 부과하지 않지만, 업무 환경의 전제가 바뀌고 있다는 신호입니다. AI가 오픈소스 취약점을 대량으로 찾아내는 시대가 실증됐고, 미국 정부는 그 흐름을 규제가 아니라 조율로 제도화하기로 했습니다. 발견은 빨라지는데 패치는 여전히 사람의 속도입니다. 이 간극에서 기업이 통제할 수 있는 것은 자기 인벤토리의 처리 능력뿐입니다. 석 달 뒤 시행되는 EU CRA 보고 의무가 어차피 SBOM과 트리아지, CVD 역량을 요구하므로, 두 시장을 한 체계로 준비하는 것이 가장 효율적입니다. 행정명령 자체와 관련해서는 7월 2일(클리어링하우스)과 8월 1일(벤치마킹 기준) 두 기한만 달력에 적어 두면 됩니다.

참고문헌

모든 URL은 2026-06-10에 접근과 내용 일치를 확인했습니다(별도 표기 제외).

A. 1차 출처 (정부 공식 문서, 당사자 발표)

A1. The White House (2026). Promoting Advanced Artificial Intelligence Innovation and Security (Executive Order). 2026-06-02 서명. https://www.whitehouse.gov/presidential-actions/2026/06/promoting-advanced-artificial-intelligence-innovation-and-security/ (접속: 2026-06-10). — 본 보고서의 원본. ↩

A2. The White House (2026). Fact Sheet: President Donald J. Trump Promotes Advanced Artificial Intelligence Innovation and Security. 2026-06-02. https://www.whitehouse.gov/fact-sheets/2026/06/fact-sheet-president-donald-j-trump-promotes-advanced-artificial-intelligence-innovation-and-security/ (접속: 2026-06-10). ↩

A3. The White House (2026). National Security Presidential Memorandum/NSPM-11 — Artificial Intelligence in the National Security Enterprise. 2026-06-05. https://www.whitehouse.gov/presidential-actions/2026/06/national-security-presidential-memorandum-nspm-11/ (접속: 2026-06-10). ↩

A4. The White House (2025). Removing Barriers to American Leadership in Artificial Intelligence (Executive Order 14179). 2025-01-23. https://www.whitehouse.gov/presidential-actions/2025/01/removing-barriers-to-american-leadership-in-artificial-intelligence/ (접속: 2026-06-10). ↩

A5. The White House (2025). Winning the Race: America’s AI Action Plan. 2025-07. https://www.whitehouse.gov/wp-content/uploads/2025/07/Americas-AI-Action-Plan.pdf (접속: 2026-06-10, PDF 원문에서 해당 구절 직접 확인). ↩

A6. Anthropic (2026). Project Glasswing: Securing critical software for the AI era. 2026-04-07 발표(이후 갱신). https://www.anthropic.com/glasswing (접속: 2026-06-10). ↩

A7. European Parliament and Council (2024). Regulation (EU) 2024/2847 — Cyber Resilience Act. OJ L, 2024/2847, 20.11.2024. https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng (접속: 2026-05-12, 본 워크스페이스의 CRA 보고서 검증 시 확인). ↩

A8. European Commission (2026). Communication on European Tech Sovereignty, accompanied by an EU Open Source Strategy. COM(2026) 503 final, 2026-06-03. https://digital-strategy.ec.europa.eu/en/library/communication-european-tech-sovereignty-accompanied-eu-open-source-strategy (접속: 2026-06-10). ↩

B. 법률·정책 분석

B1. Wiley Rein LLP (2026). New AI Executive Order Addresses Frontier Models and Cybersecurity Vulnerabilities. https://www.wiley.law/alert-New-AI-Executive-Order-Addresses-Frontier-Models-and-Cybersecurity-Vulnerabilities (접속: 2026-06-10). ↩

B2. WilmerHale (2026). New Executive Order Addressing Early Government Access to Frontier AI Models. 2026-06-02. https://www.wilmerhale.com/en/insights/client-alerts/20260602-new-executive-order-addressing-early-government-access-to-frontier-ai-models (접속: 2026-06-10). ↩

B3. Crowell & Moring LLP (2026). Executive Order Creates Voluntary Regulatory Regime of Frontier AI Models. https://www.crowell.com/en/insights/client-alerts/executive-order-creates-voluntary-regulatory-regime-of-frontier-ai-models (접속: 2026-06-10). ↩

B4. Atlantic Council (2026). Reading between the lines of Trump’s new executive order on AI. https://www.atlanticcouncil.org/dispatches/reading-between-the-lines-of-trumps-new-executive-order-on-ai/ (접속: 2026-06-10). ↩

B5. Council on Foreign Relations (2026). Assessing Trump’s Executive Order on AI Oversight. https://www.cfr.org/articles/assessing-trumps-executive-order-on-ai-oversight (접속: 2026-06-10). ↩

B6. CSO Online (2026). OpenAI responds to White House executive order on AI governance. https://www.csoonline.com/article/4181294/openai-responds-to-white-house-executive-order-on-ai-governance.html (접속: 2026-06-10).

B7. Open Source Initiative (2025). OSI and Apereo Foundation Respond to White House on AI Action Plan. https://opensource.org/blog/osi-and-apereo-foundation-respond-to-white-house-on-ai-action-plan (접속: 2026-06-10). ↩

C. 업계·보안 커뮤니티

C1. CyberScoop (2026). Anthropic expanding access to Project Glasswing. 2026-06-02. https://cyberscoop.com/anthropic-project-glasswing-expansion-critical-infrastructure-claude-mythos/ (접속: 2026-06-10). ↩

C2. Help Net Security (2026). Anthropic: Claude Mythos identified 10,000+ software flaws. 2026-05-26. https://www.helpnetsecurity.com/2026/05/26/anthropic-project-glasswing-update/ (접속: 2026-06-10). ↩

C3. Schneier, Bruce (2026). On Anthropic’s Mythos Preview and Project Glasswing. Schneier on Security, 2026-04. https://www.schneier.com/blog/archives/2026/04/on-anthropics-mythos-preview-and-project-glasswing.html (접속: 2026-06-10). ↩

C4. HeroDevs (2026). AI Cybersecurity Executive Order 2026: What It Means for EOL Software. https://www.herodevs.com/blog-posts/ai-cybersecurity-executive-order-2026-what-it-means-for-eol-software (접속: 2026-06-10). — 상용 LTS 업체의 글이므로 이해관계를 고려해 인용. ↩

D. 관련 분석 (이 블로그)

D1. EU 사이버 복원력법(CRA) 취약점 보고 의무 — 2026-09-11 시행 대비 조사보고서 (2026-06-09 갱신). ↩

D2. EU 오픈소스 전략: 기술 주권을 위한 오픈소스의 제도화 (2026-06-05). ↩

D3. AI가 만든 코드, 오픈소스 검사를 어디까지 해야 할까 (2026-06-08). ↩

6 - EU 오픈소스 전략: 기술 주권을 위한 오픈소스의 제도화

요약

유럽연합 집행위원회가 2026년 6월 3일 발표한 「유럽 기술 주권에 관한 통신」(COM(2026) 503 final)에는 EU 오픈소스 전략(EU Open Source Strategy)이 첨부되어 있습니다. 오픈소스를 EU 디지털 정책의 중심에 놓은 첫 사례입니다. 전략은 주권을 위한 활용, 생태계 강화, 공공행정의 개방화, 표준과 국제 협력이라는 네 가지 목표를 제시하고, 향후 7년간 오픈소스 관련 조치에 약 20억 유로를 공공과 민간이 동원하도록 합니다. EU가 미국산 독점 IT에 매년 2,640억 유로를 지출하는 의존 구조를 줄이려는 것입니다. 시민사회(FSFE)와 정책 분석가들은 방향을 환영하면서도 재정 충분성, 오픈 표준과 오픈소스의 관계, 오픈 하드웨어 경시, 실무자 스킬 격차를 한계로 지적했습니다. 한국 공공과 기업 실무자에게는 EU 조달 개방화와 오픈소스 스튜어드 규제, EUDI 지갑의 오픈소스 기본값이 직접 지켜볼 지점입니다.

1. 개요

집행위원회는 2026년 6월 3일 브뤼셀에서 기술 주권 패키지(technological sovereignty package)를 발표했습니다. 통신(Communication)은 구속력 있는 입법이 아니라 위원회의 정책 방향과 후속 조치 계획을 담는 문서입니다.A1·A2 패키지는 서로 연결된 네 개의 이니셔티브, 곧 반도체의 칩스법 2.0(Chips Act 2.0), 클라우드·AI 개발법(Cloud and AI Development Act, CADA), 오픈소스 전략, 에너지 부문 디지털화와 AI 로드맵으로 이뤄집니다. 이 보고서가 다루는 범위는 그중 오픈소스 전략(COM 문서 제4장)입니다.A1

전략이 답하려는 문제는 분명합니다. 드라기 보고서(Draghi Report)는 EU가 디지털 제품과 서비스, 인프라, 지식재산의 80% 이상을 비EU 공급자에 의존한다고 지적했습니다.A1 오픈소스 전략은 이 의존을 줄이는 수단으로 오픈소스를 택했습니다. 리눅스(Linux)의 발상지인 유럽에는 300만 명이 넘는 오픈소스 기여자가 있고, 코드 커밋의 절반 가까이가 직원 50명 미만 소기업에서 나옵니다. 활용할 자산은 있지만 확장과 자금에서 구조적 한계를 안고 있습니다.A1

2. 핵심 내용: 네 가지 목표

전략은 두 갈래 조치를 결합합니다. EU 커뮤니티와 기업이 고품질 오픈소스 구성요소를 개발하고 유지보수하도록 돕는 공급측 조치와, 민간과 공공의 도입을 가속하는 수요측 조치입니다. 공공 자금과 시장·수요 주도 조치를 함께 묶었고, 위원회의 증거 수집 요청(call for evidence)에 접수된 1,600건 이상의 의견을 토대로 만들어졌습니다.A1·B3

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 45, 'rankSpacing': 55}} }%%
flowchart TD
    ROOT["EU 오픈소스 전략<br/>COM(2026) 503"]
    O1["목표 (i)<br/>주권을 위한<br/>오픈소스 활용"]
    O2["목표 (ii)<br/>활기찬 생태계<br/>강화·진흥"]
    O3["목표 (iii)<br/>공공행정의<br/>개방·상호운용"]
    O4["목표 (iv)<br/>표준·국제<br/>협력 강화"]
    ROOT --> O1 & O2 & O3 & O4
    O1 --> AC1["오픈 인터넷 스택, EUID/EBW<br/>오픈소스화, 2030년 3,000만 사용자"]
    O2 --> AC2["비즈니스 액셀러레이터, 스튜어드십<br/>툴킷, 오픈소스 유지보수 수단"]
    O3 --> AC3["public money, public code<br/>조달 개혁, OSPO 네트워크 강화"]
    O4 --> AC4["표준화 규정 개정,<br/>Team Europe 국제 협력"]
    style ROOT fill:#e3f2fd,stroke:#1565c0,stroke-width:2px

그림 1. 오픈소스 전략의 4대 목표와 대표 조치 (출처: COM(2026) 503 final 제4장, 2026-06-03)

기술 주권을 위한 활용(목표 i). 위원회는 오픈 인터넷 스택(Open Internet Stack)을 유럽 오픈소스 빌딩블록의 공유 카탈로그로 확장하고, 호라이즌 유럽 2026–2027 작업 프로그램에서 세 건 공모로 4,130만 유로를 동원했습니다.A1 EU 디지털 신원 생태계의 오픈소스화가 핵심 축입니다. EU 디지털 신원 규정(EUDIR)이 EUDI 지갑(Wallet) 응용 구성요소를 오픈소스로 하도록 법적 기본값을 정했고, 이를 토대로 신원 지갑(EUID)과 유럽 비즈니스 지갑(European Business Wallet, EBW)의 참조 구현을 오픈소스로 개발해 그 장기 스튜어드십을 유럽 디지털 공공 인프라 재단으로 이전합니다.A1 회원국과는 디지털 공유재(Digital Commons)에 관한 유럽 디지털 인프라 컨소시엄(EDIC)을 통해 협력하며, 2030년까지 오픈소스 협업과 생산성 도구, 보안 이메일의 활성 사용자 3,000만 명 도달을 목표로 삼습니다.A1

생태계 강화(목표 ii). 오픈소스 빌딩블록은 대부분 재단을 통해 유지되며, 자금의 다수는 미국과 중국 빅테크가 대고 있습니다.A1 사이버 복원력법(Cyber Resilience Act, CRA)이 도입한 오픈소스 소프트웨어 스튜어드(steward) 개념이 이 목표의 규제 축입니다. 위원회는 재단 설립을 돕는 스튜어드십 툴킷(stewardship toolkit)을 개발하고, EU가 자금을 지원한 전략 자산을 단일 거점에서 거버넌스하는 유럽 디지털 공공 인프라 스튜어드 조직 설립을 지원합니다. 핵심 구성요소의 유지와 보안을 위해서는 오픈소스 유지보수 수단(Open Source Maintenance Instrument)을 신설해, 필요할 때 프로젝트를 포크(fork)할 수 있는 유럽 역량을 구축합니다.A1

공공행정의 개방화(목표 iii). “공공 자금, 공공 코드(public money, public code)” 원칙이 전략에 명시적으로 들어왔습니다.A1·B2 위원회는 매트릭스(Matrix) 기반 통신 플랫폼, 오픈데스크(openDesk) 협업 환경, 300개 이상 europa.eu 사이트의 드루팔(Drupal)을 이미 운영하고 있습니다.A1 조달에서는 오픈소스가 독점 솔루션과 경쟁할 수 있도록 입찰 가이드라인을 개편하고, 오픈소스 프로그램 사무소(Open Source Programme Office, OSPO)와 EU 공공부문 OSPO 네트워크를 중심 허브로 강화합니다.A1·B2

표준과 국제 협력(목표 iv). 위원회는 EU 표준화 규정(Standardisation Regulation) 개정에서 오픈소스와 표준화 커뮤니티의 협력을 개선하고, 특정 표준이 오픈소스로 구현되도록 조건을 제공합니다. 팀 유럽(Team Europe) 접근으로 EU 오픈소스 솔루션을 확대 국가와 파트너 국가에 배치합니다.A1

거버넌스 구조

전략은 새 기구를 만들기보다 기존 거버넌스 자산을 엮습니다. 세 축이 맞물립니다.

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 45, 'rankSpacing': 50}} }%%
flowchart TD
    EC["집행위원회 OSPO<br/>(2020 설치)"] --> NET["EU 공공부문 OSPO 네트워크<br/>(11개국 25회원)"]
    EDIC["디지털 공유재 EDIC<br/>(2025-10-29 설립)"] --> FND["유럽 디지털 공공 인프라 재단<br/>(설립 추진)"]
    NET --> FND
    FND --> ASSET["EUID, EBW 등 전략 오픈소스 자산<br/>장기 스튜어드십"]
    style FND fill:#fff3e0,stroke:#ef6c00,stroke-width:2px

그림 2. 오픈소스 전략의 거버넌스 기구 연결 (출처: COM(2026) 503 final 제4장 및 부속서 II, 2026-06-03. OSPO 네트워크 회원 수는 2026-05 기준)

집행위원회 OSPO(2020년 설치)와 11개국 25개 회원의 EU 공공부문 OSPO 네트워크가 공공행정 축을 맡고, 2025년 10월 29일 설립된 디지털 공유재 EDIC이 다국가 협력 축을 맡습니다.A1·A5 이 둘은 설립을 추진 중인 유럽 디지털 공공 인프라 재단으로 수렴하며, 재단이 EUID와 EBW 같은 전략 자산의 장기 스튜어드십을 맡게 됩니다.A1

3. 배경과 맥락

오픈소스 전략은 독립 규제가 아니라 여러 EU 법령 위에 얹힌 정책 우산입니다. 상호운용 유럽법(Interoperable Europe Act, Regulation (EU) 2024/903)이 “오픈소스 라이선스"를 정의하고 공공부문 재사용을 뒷받침하며,A4 CRA(Regulation (EU) 2024/2847)가 스튜어드 규제 범주와 자발적 보안 입증(Article 25)을 제공합니다.A3 AI법(AI Act)은 무료 오픈소스 모델에 비례적 의무를 두고, EUDIR은 EUDI 지갑의 오픈소스 기본값을 정합니다.A1·C1

정책 계보의 분수령은 2020년입니다. 위원회는 2020년 10월 21일 「오픈소스 소프트웨어 전략 2020–2023」(C(2020) 7149 final)을 채택해 “오픈으로 생각하기(think open)” 문화를 도입했고, 그 첫 조치로 집행위원회 OSPO를 설치했습니다.A5 이후 code.europa.eu(2026년 5월 기준 사용자 4,500명, 저장소 1,280개)와 EU 오픈소스 솔루션 카탈로그(2025년 3월 출범, 1,047개 솔루션)가 구축되었습니다.A1 새 전략은 이들을 명시적 토대로 인용합니다.

“공공 자금, 공공 코드” 원칙은 자유소프트웨어재단 유럽(FSFE)이 2017년 시작한 캠페인에서 비롯했습니다. 전략은 캠페인 출범 9년 만에 이 원칙을 받아들였습니다.B4

4. 최신 동향과 일정

발표가 며칠 전이어서, 동향은 발표 직후의 반응과 앞으로 예정된 절차로 모입니다.

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 35, 'rankSpacing': 45}} }%%
flowchart TD
    J["<b>2026-01-12</b> &nbsp; 증거 수집 요청 개시"]
    F["<b>2026-02-03</b> &nbsp; 요청 마감 (1,600건 이상 접수)"]
    P["<b>2026-06-03</b> &nbsp; COM(2026) 503 발표"]
    D["<b>2026-12</b> &nbsp; 국가 로드맵 개정"]
    S["<b>이후</b> &nbsp; 표준화 규정 개정 제안"]
    J --> F --> P --> D --> S
    style P fill:#fff3e0,stroke:#ef6c00,stroke-width:2px

그림 3. EU 오픈소스 전략 추진 일정 (출처: COM(2026) 503 final 및 집행위원회 공지, 2026-06-05 기준)

발표 당일 FSFE는 신중한 환영 입장을 냈습니다. “Public Money? Public Code!” 원칙 수용을 반기면서도, 요하네스 네더(Johannes Näder)는 “위원회는 구체적 목표와 마일스톤, 안전한 자금에서 여전히 미흡하다"고 했고, 루카스 라소타(Lucas Lasota)는 “이제 관건은 이행이며, 확보된 장기 자금과 시민사회의 실질적 참여, 디지털 시장법의 효과적 집행이 필요하다"고 밝혔습니다.B4

TechPolicy.Press의 정책 분석(Gates, Givropoulou, Karhu, 2026-06-03)은 전략을 “유럽의 지금까지 가장 의미 있는 진전"으로 평가하면서 네 가지 공백을 지적했습니다.E1 오픈 표준과 오픈소스의 선후 관계가 아직 정해지지 않았고, 오픈 하드웨어 취급이 RISC-V와 EDA 도구에 머물러 있으며, 7년 20억 유로는 연간 2,640억 유로 의존에 비해 부족하고, 실무자 수준의 기여와 유지, 거버넌스 역량 개발이 약하다는 것입니다. 법무법인 코빙턴(Covington)도 2026년 6월 4일 패키지의 투자 규모와 기업 영향을 정리했습니다.E3

재정의 성격이 불확실성을 키웁니다. 20억 유로는 확정 배정된 예산이 아니라 7년간 공공과 민간이 “동원해야 할” 합산 추정치입니다.A1 오픈소스 유지보수 수단, 유럽 디지털 공공 인프라 재단, 자발적 EU 평가 프레임워크는 모두 “만든다"는 약속 단계에 있어 구체적인 설계와 금액이 정해지지 않았습니다.

예정된 일정으로는 2026년 12월 회원국의 국가 디지털 디케이드 전략 로드맵 개정에 패키지가 반영되고, 표준화 규정 개정 제안과 CADA·칩스법 2.0 입법 절차가 오픈소스 요건을 구체화합니다. 위원회는 디지털 디케이드 위원회에서 매년 진척을 논의하고 3년마다 유럽의회에 보고합니다.A1

5. 시사점과 고려사항

한국 공공기관과 기업에 이 전략이 직접 적용되지는 않지만, 실무에서 지켜볼 지점이 몇 가지 있습니다.

EU 공공조달의 개방화가 가장 현실적인 변수입니다. 입찰 사양이 오픈 표준과 모델을 포함하고 오픈소스가 독점 솔루션과 경쟁하도록 바뀌면, EU 공공시장에 진입하려는 한국 SW 공급사는 오픈소스 친화적인 제안과 라이선스 명확성을 갖춰야 유리합니다.A1·B2 반대로 오픈소스 기반 사업을 하는 한국 기업에는 EU 조달 진입 기회가 넓어집니다.

오픈소스 스튜어드 규제는 CRA 적용을 받는 제품을 EU에 출시하는 기업이 살펴야 할 지점입니다. 오픈소스 구성요소에 의존하는 제품의 보안 입증(CRA Article 25)과 스튜어드의 책임 범위가 전략의 자발적 EU 평가 프레임워크로 구체화될 전망이므로, 소프트웨어 구성요소 목록(Software Bill of Materials, SBOM)과 의존성 관리 체계를 미리 정비해 두는 것이 안전합니다.A1·A3 EUDI 지갑과 유럽 비즈니스 지갑이 오픈소스 참조 구현을 기본값으로 삼는 점은, EU 디지털 신원 연동을 검토하는 한국 핀테크와 인증 사업자가 주시할 사항입니다.A1

한국의 공공 SW 정책 관점에서는 “공공 자금, 공공 코드” 원칙의 제도화 경로와 OSPO 네트워크 거버넌스가 참고할 만한 모델입니다. 다만 EU 스스로 재정 충분성과 실무자 역량을 미해결 과제로 남긴 만큼, 선언과 이행 사이의 간극도 함께 지켜봐야 합니다.B4·E1

6. 참고 자료

A. 법령·규제 원문 (1차)

A1. European Commission (2026). Communication from the Commission on European Tech Sovereignty, accompanied by an EU Open Source Strategy. COM(2026) 503 final, Brussels, 3.6.2026 (본문 및 ANNEXES 1–2). 본 보고서 원본. sources/COM-2026-503-eu-tech-sovereignty.pdf 및 …-annexes.pdf. 다운로드: https://digital-strategy.ec.europa.eu/en/library/communication-european-tech-sovereignty-accompanied-eu-open-source-strategy (접속: 2026-06-05). ↩

A2. European Commission (2026). Strengthening Europe’s tech sovereignty (보도자료). 2026-06-03. https://commission.europa.eu/news-and-media/news/strengthening-europes-tech-sovereignty-2026-06-03_en (접속: 2026-06-05). ↩

A3. European Parliament and Council (2024). Regulation (EU) 2024/2847 — Cyber Resilience Act. Official Journal, OJ L, 2024/2847, 20.11.2024. https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng (접속: 2026-06-05). ↩

A4. European Parliament and Council (2024). Regulation (EU) 2024/903 — Interoperable Europe Act. Official Journal, OJ L, 2024/903, 22.3.2024. https://eur-lex.europa.eu/eli/reg/2024/903/oj/eng (접속: 2026-06-05). ↩

A5. European Commission (2020). Open Source Software Strategy 2020–2023. C(2020) 7149 final, Brussels, 21.10.2020. https://commission.europa.eu/system/files/2023-02/en_ec_open_source_strategy_2020-2023.pdf (접속: 2026-06-05). ↩

B. 발행 기관 공식 문서·정책 페이지

B1. European Commission — Shaping Europe’s digital future (2026). The EU Open Source Strategy (정책 페이지). 2026-06-03 갱신. https://digital-strategy.ec.europa.eu/en/policies/open-source-strategy (접속: 2026-06-05).

B2. European Commission (2026). Commission boosts open and interoperable digital ecosystems for public administrations (보도자료). 2026-06-03. https://commission.europa.eu/news-and-media/news/commission-boosts-open-and-interoperable-digital-ecosystems-public-administrations-2026-06-03_en (접속: 2026-06-05). ↩

B3. European Commission — Shaping Europe’s digital future (2026). Commission opens call for evidence on Open-Source Digital Ecosystems. 2026-01-12(마감 2026-02-03). https://digital-strategy.ec.europa.eu/en/news/commission-opens-call-evidence-open-source-digital-ecosystems (접속: 2026-06-05). ↩

B4. Free Software Foundation Europe (2026). EU Tech Sovereignty: A milestone for Public Code? Now implementation is key. 2026-06-03. https://fsfe.org/news/2026/news-20260603-01.en.html (접속: 2026-06-05). ↩

C. 표준·프레임워크

C1. European Commission (2024). Regulation (EU) 2024/1689 — Artificial Intelligence Act. Official Journal, OJ L, 2024/1689, 12.7.2024. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng (접속: 2026-06-05). ↩

C2. European Parliament and Council (2023). Regulation (EU) 2023/2854 — Data Act. Official Journal, OJ L, 2023/2854, 22.12.2023. https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng (접속: 2026-06-05).

D. 학술·정책 연구

D1. Blind, K. et al. (2021). The impact of Open Source Software and Hardware on technological independence, competitiveness and innovation in the EU economy. European Commission. https://digital-strategy.ec.europa.eu/en/library/study-about-impact-open-source-software-and-hardware-technological-independence-competitiveness-and (접속: 2026-06-05).

E. 업계·법무법인·언론 분석 (보조)

E1. Gates, N., Givropoulou, A., Karhu, J. (2026). How the EU’s Tech Sovereignty Package Finally Puts Open Source to the Test. TechPolicy.Press, 2026-06-03. https://www.techpolicy.press/how-the-eus-tech-sovereignty-package-finally-puts-open-source-to-the-test/ (접속: 2026-06-05). ↩

E2. TechPolicy.Press (2026). EU Unveils Sweeping Tech Sovereignty Push, Balancing Autonomy with Openness. 2026-06-03. https://www.techpolicy.press/eu-unveils-sweeping-tech-sovereignty-push-balancing-autonomy-with-openness/ (접속: 2026-06-05).

E3. Covington & Burling (2026). EU Tech Sovereignty Package. Global Policy Watch, 2026-06-04. https://www.globalpolicywatch.com/2026/06/eu-tech-sovereignty-package/ (접속: 2026-06-05). ↩

E4. Agence Europe (2026). European Commission seeks to harness open source in its tech sovereignty strategy and develop European alternatives. 2026-06. https://agenceurope.eu/en/bulletin/article/13877/4/european-commission-seeks-to-harness-open-source-in-its-tech-sovereignty-strategy-and-develop-european-alternatives (접속: 2026-06-05).

7 - EU 사이버 복원력법(CRA) 취약점 보고 의무 — 2026-09-11 시행 대비 조사보고서

요약

EU 사이버 복원력법(Cyber Resilience Act, CRA — Regulation (EU) 2024/2847)은 EU 시장에 출시되는 모든 “디지털 요소를 가진 제품(product with digital elements, PDE)“에 수평적 사이버보안 의무를 부과하는, EU 역사상 첫 포괄적 제품 보안 규정입니다. 2024년 12월 10일 발효된 이 규정은 단계적으로 적용되며, 2026년 9월 11일부터는 제14조 보고 의무가 발효되어 제조사와 수입사, 유통사가 실제 악용 중인 취약점과 중대한 보안 사고를 24시간, 72시간, 14일의 단계별 시한 안에 ENISA(유럽 사이버보안청)와 회원국 CSIRT에 통지해야 합니다. 이 날짜까지 보고 워크플로우가 가동되지 않으면 최대 1,500만 유로 또는 전 세계 연간 매출 2.5%의 과징금 위험이 생기고, 한국 기업이라도 EU 시장에 제품을 출시하면 즉시 적용 대상이 됩니다. A1, B1, E1

1. 왜 2026-09-11이 한국 기업에 중요한가

오는 2026년 9월 11일은 CRA 제14조 보고 의무의 첫 적용일입니다. 이날 ENISA의 단일 보고 플랫폼(Single Reporting Platform, SRP)도 함께 가동됩니다. A1, B4 CE 마킹과 적합성 평가 등 CRA의 나머지 본질 의무는 2027년 12월 11일이 시한이지만, 보고 워크플로우만큼은 그보다 15개월 앞서 갖춰야 합니다.

한국 기업에 이 날짜가 갖는 무게는 CRA의 법적 성격에서 나옵니다. CRA는 회원국이 국내법으로 옮겨야 하는 지침(Directive)이 아니라 직접 효력을 갖는 규정(Regulation)이어서, 별도의 국내 이행 입법 없이 EU 시장 진입 즉시 적용됩니다. A1 한국에 본사를 두고 EU 법인 없이 직수출하더라도 적용 대상에서 벗어나지 못합니다. 레거시 제품, 곧 이미 EU 시장에 출시된 제품도 포함된다는 점 역시 주의가 필요합니다. E1

2026년 6월 현재 보고 의무 시행까지 약 3개월이 남았습니다. ENISA는 시험 기간(testing period)을 두겠다고 밝혔을 뿐 공식 일정은 아직 내놓지 않았고, 운영 매뉴얼은 2026년 6월 중에 제공하겠다고 예고했습니다. 현 단계에서 SRP 연동 API를 제공하지 않는다는 점도 ENISA가 명시했습니다. B4 자동 연계를 전제했던 기업은 사람이 플랫폼에 직접 제출하는 절차로 보고 체계를 다시 설계해야 합니다.

2. CRA의 구조

2.1 입법 배경과 발효 일정

CRA의 공식 명칭은 Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements입니다. 2021년 9월 우어줄라 폰 데어 라이엔(Ursula von der Leyen) 위원장의 연두교서에서 처음 예고된 뒤, 2022년 9월 15일 유럽위원회(European Commission)가 입법안을 제안했습니다. 유럽의회는 2024년 3월 12일 본회의에서 찬성 517표, 반대 12표로 채택했고, 이사회(Council)가 같은 해 10월 10일 최종 채택해 10월 23일 서명을 거쳐 11월 20일 EU 관보에 게재했습니다. 발효일은 2024년 12월 10일입니다. A1, B1

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 40, 'rankSpacing': 45}} }%%
flowchart TD
    A["<b>2021-09</b> &nbsp; 폰 데어 라이엔 위원장<br/>연두교서에서 CRA 예고"]
    B["<b>2022-09-15</b> &nbsp; 유럽위원회 입법 제안<br/>(COM(2022)454)"]
    C["<b>2023-11-30</b> &nbsp; 잠정 정치적 합의 도달"]
    D["<b>2024-03-12</b> &nbsp; 유럽의회 본회의 채택<br/>(찬성 517, 반대 12)"]
    E["<b>2024-10-10</b> &nbsp; 이사회 최종 채택"]
    F["<b>2024-12-10</b> &nbsp; 발효"]
    G["<b>2026-09-11</b> &nbsp; 제14조 보고 의무<br/>적용 개시, SRP 가동"]
    H["<b>2027-12-11</b> &nbsp; CRA 전면 적용"]
    A --> B --> C --> D --> E --> F --> G --> H
    style G fill:#fff3e0,stroke:#ef6c00,stroke-width:2px

그림 1. CRA 입법·시행 타임라인 (출처: Regulation (EU) 2024/2847, EC 입법 트레인) A1, B1

입법 과정에서는 오픈소스 커뮤니티의 입장 표명이 눈에 띄었습니다. 2022~2023년 초안 단계에서 이클립스 재단(Eclipse Foundation), 오픈소스 이니셔티브(OSI), 도큐먼트 재단 등은 “상업 활동” 정의가 불명확해 자원봉사 개발자에게도 컴플라이언스 부담이 돌아갈 수 있다고 우려했습니다. 2023년 12월 잠정 합의에서 “오픈소스 스튜어드(open-source steward)” 개념과 예외 조항이 도입되면서 우려가 일부 해소됐지만, 소규모 재배포자에 대한 적용 범위 문제는 여전히 논란으로 남아 있습니다. D1

2.2 적용 범위 (Art. 2~3)

CRA는 “디지털 요소를 가진 제품(product with digital elements, PDE)“에 적용됩니다. 장치나 네트워크와 논리적·물리적 데이터 연결이 가능한 하드웨어와 소프트웨어를 포괄하며, 독립적으로 시장에 출시된 소프트웨어 구성요소도 포함합니다. B3

적용 범위에서 빠지는 제품도 있습니다. 상업적 활동 없이 공급되는 자유·오픈소스 소프트웨어, 그리고 의료기기나 자동차처럼 더 엄격한 부문별 사이버보안 규제가 이미 적용되는 제품이 대표적입니다. 다만 기존 사이버보안 규제의 적용 대상이어도 CRA가 “보완적"으로 적용될 여지가 있어 부문별 판단이 필요합니다. A1, E2

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 40, 'rankSpacing': 50}} }%%
flowchart TD
    A["EU 시장에 유통되는 제품인가?"] -->|아니오| Z["적용 외"]
    A -->|예| B["디지털 요소를 가진 제품인가?"]
    B -->|아니오| Z
    B -->|예| C["상업적 활동이 있는가?<br/>(상업적 FOSS 포함)"]
    C -->|아니오| Z2["적용 외 (비상업 FOSS)"]
    C -->|예| D["더 엄격한 부문별 사이버보안 입법이<br/>이미 적용되는가? (예: MDR 의료기기)"]
    D -->|예| Z3["적용 외"]
    D -->|아니오| E["CRA 적용 대상"]
    E --> F["등급 분류:<br/>기본 / 중요 Class I /<br/>중요 Class II / 중대"]

    style E fill:#fce4ec,stroke:#c2185b
    style F fill:#fce4ec,stroke:#c2185b

그림 2. CRA 적용 여부 판단 흐름 (출처: CRA Art. 2~3, 시행규칙 (EU) 2025/2392) A1, A3

2.3 단계적 시행

CRA의 전면 적용은 단일 시점에 이뤄지지 않습니다.

A1, B3

2026년 9월 11일까지 갖춰야 하는 것은 제품 인증이 아니라 취약점·사고 보고 워크플로우입니다. CE 마킹과 적합성 평가의 시한은 그보다 15개월 뒤인 2027년 12월 11일입니다.

3. 제조사 의무 (Art. 13)

3.1 Annex I 본질 요건

제13조는 제조사가 CRA Annex I의 본질적 사이버보안 요건(essential cybersecurity requirements)을 충족하도록 규정합니다. 요건은 크게 두 그룹으로 나뉩니다. A1, B3

Part I — 제품 보안 요건: 알려진 취약점 없는 상태 출시, 기본 비밀번호 금지, 보안 업데이트 제공, 최소 권한 원칙 적용, 데이터 보호, 공격 표면 축소, 사이버 복원력 설계, 개인 데이터 접근·수정 이력 제공.

Part II — 취약점 처리 요건: 취약점 식별·문서화, SBOM 유지, 신속한 패치 제공과 무료 배포, 조정된 취약점 공개(Coordinated Vulnerability Disclosure, CVD) 정책, 악용 취약점·사고 보고(Art. 14), 생애 주기 전반에 걸친 취약점 모니터링.

이 요건들에는 현재 확정된 조화 표준이 없어, CRA 원문의 기능적 요건을 기준으로 직접 이행해야 합니다. ENISA와 JRC가 공동 발간한 CRA Requirements Standards Mapping(2024)이 기존 표준과의 매핑을 제공하며, ISO/IEC 30111(취약점 처리)과 29147(취약점 공시), NIST SP 800-218(SSDF)이 주요 참조점입니다. B5, C1, C2, C6

3.2 지원 기간

제조사는 시장 출시 후 예상 사용 기간 동안, 최소 5년 이상 보안 지원을 제공해야 합니다. 예상 사용 기간이 5년 미만인 제품은 그 기간을 지원 기간으로 삼을 수 있습니다. 지원 기간은 제품에 명시적으로 표시해야 하며, 이 기간 동안 취약점 처리와 보안 업데이트 제공이 의무입니다. A1, B3

3.3 SBOM 요건

CRA Annex I Part II는 소프트웨어 부품 명세서(Software Bill of Materials, SBOM)를 의무화합니다. 출고 버전마다 SBOM을 생성하고, 시장 감시 당국(Market Surveillance Authority)의 요청에 대비해 기계 판독 가능한 형식으로 보관해야 합니다. SBOM을 제3자에게 공개할 의무는 없지만, 시장 감시 당국에는 제출해야 합니다. A1

형식은 SPDX 또는 CycloneDX가 사실상 표준으로 자리잡았습니다. SPDX는 ISO/IEC 5962:2021로 표준화됐고(SPDX v2.2.1 기반, 현행 사양은 v3.0), C3, C4 CycloneDX는 OWASP가 관리하는 사양으로 2025년 12월 10일 ECMA-424 2nd Edition(v1.7 기반)이 발행됐습니다. C5 CRA 차원의 공식 SBOM 스키마 시행규칙은 2026년 6월 현재까지 나오지 않았습니다. 독일 연방정보보안청(Bundesamt für Sicherheit in der Informationstechnik, BSI)이 2025년 8월 발간한 TR-03183-2 v2.1.0이 CRA 정합 SBOM의 필드 매핑을 제공하는 현실적 참조점입니다. G1

4. 보고 의무 (Art. 14) — 2026-09-11 시행

4.1 통지 트리거

제14조는 두 부류의 사건을 제조사의 통지 트리거로 규정합니다. A1, B2

하나는 실제 악용되고 있는 취약점(actively exploited vulnerability)입니다. 취약점이 이론적으로 존재하는 데 그치지 않고 공격자가 실제로 악용한다는 사실이 확인된 시점이 트리거입니다. 다른 하나는 중대한 보안 사고(severe incident)입니다. 제품의 보안에 영향을 미치는 심각한 운영 중단이나 손실, 손해를 일으키거나 일으킬 가능성이 있는 사건을 말합니다.

제조사 외에 수입사와 유통사도 비준수를 발견하거나 사고를 인지하면 해당 정보를 제조사에 통지해야 합니다.

4.2 3단계 시한 (24h/72h/14d)

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 40, 'rankSpacing': 50}} }%%
flowchart TD
    T0["인지 시점<br/>(actively exploited vuln.<br/>또는 severe incident)"]
    T1["24시간 내 — 조기 경보<br/>(Early Warning)"]
    T2["72시간 내 — 본 통지<br/>(Notification)"]
    T3["완화 조치 가용 후 14일 내<br/>최종 보고 (취약점)"]
    T4["통지 후 1개월 내<br/>최종 보고 (사고)"]

    T0 --> T1 --> T2
    T2 --> T3
    T2 --> T4

    style T1 fill:#ffebee,stroke:#c62828
    style T2 fill:#fff3e0,stroke:#ef6c00
    style T3 fill:#e8f5e9,stroke:#2e7d32
    style T4 fill:#e8f5e9,stroke:#2e7d32

그림 3. CRA Article 14 보고 시한 (출처: CRA Art. 14, EC “CRA — Reporting obligations”) A1, B2

단계마다 담아야 할 내용이 다릅니다. A1, B2

24시간 시한이 취약점 분류나 해결 완료까지 요구하지는 않는다는 점을 CRA 원문이 분명히 합니다. 조기 경보로서 존재를 알리는 것이 목적입니다. 마이크로기업과 소기업은 24시간 시한을 지키지 못해도 과징금이 면제될 수 있습니다. A1

4.3 단일 보고 플랫폼 (Art. 16)

제14조 통지는 모두 단일 보고 플랫폼(Single Reporting Platform, SRP)을 거칩니다. ENISA가 운영하며, 제조사가 한 번 제출하면 주 사업장 소재 회원국의 코디네이터 CSIRT(Computer Security Incident Response Team)와 ENISA로 자동 라우팅됩니다. B4, A1

ENISA는 SRP를 조달하면서 NIS2와 DORA의 사고·취약점 보고 체계와 통합할 수 있는 미래지향 아키텍처를 요구했습니다. CRA 의무에 그치지 않고 인접 규제 체계와 연동 가능한 플랫폼이 설계 목표입니다.

%%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 45, 'rankSpacing': 55}} }%%
flowchart TD
    ID["수입사 (Importer) /<br/>유통사 (Distributor)"]
    M["제조사<br/>(Manufacturer)"]
    SRP["ENISA SRP<br/>(단일 보고 플랫폼)"]
    CSIRT["회원국 코디네이터<br/>CSIRT"]
    ENISA["ENISA"]
    OTHER_CSIRT["타 회원국<br/>CSIRT"]
    MSA["시장 감시 당국<br/>(MSA)"]

    ID -->|"비준수 발견 시 통지"| M
    M -->|"Art.14 24h/72h/14d"| SRP
    SRP --> CSIRT
    SRP --> ENISA
    CSIRT -->|"전파<br/>(지연 조건 적용)"| OTHER_CSIRT
    ENISA --> MSA
    MSA -->|"시정·회수 명령"| M

    style M fill:#e3f2fd,stroke:#1565c0
    style SRP fill:#fff3e0,stroke:#ef6c00
    style ENISA fill:#fff3e0,stroke:#ef6c00
    style CSIRT fill:#fff3e0,stroke:#ef6c00

그림 4. CRA 보고 체계의 이해관계자 상호작용 (출처: CRA Art. 13~16, 위임법 (EU) 2026/881) A1, A2

4.4 CSIRT 간 전파 지연 조건 (위임법 2026/881)

2025년 12월 11일 채택된 위임법 (EU) 2026/881(관보 게재 2026-04-20)은 회원국 CSIRT가 단일 보고 플랫폼으로 수신한 통지를 다른 CSIRT에 즉시 전파하지 않아도 되는 조건을 명시했습니다. A2 지연이 허용되는 경우는 통지된 정보의 성격을 평가한 결과 지연이 정당화되는 경우, 수신 CSIRT가 해당 정보의 기밀성을 보장할 수 없는 경우, 단일 보고 플랫폼 자체가 침해되었거나 일시적으로 운영이 불가한 경우입니다. 여기에 더해 트래픽 라이트 프로토콜(Traffic Light Protocol, TLP)이나 정보 접근 프로토콜(Permissible Actions Protocol, PAP) 같은 도구로 위험을 완화할 수 없을 때, “엄격히 필요한 기간"에 한해서만 지연할 수 있습니다.

제조사가 CSIRT에 보내는 24시간 시한은 이 위임법의 영향을 받지 않습니다. 위임법이 손댄 곳은 CSIRT 간의 추가 전파 단계이며, 거기에 보안 사유의 완화 장치를 마련한 것입니다.

4.5 GDPR·NIS2와의 병행 적용

CRA 보고와 다른 규제의 보고 의무가 동시에 발생할 수 있습니다. 취약점이나 사고로 침해된 데이터에 개인정보가 포함된 경우, CRA 통지가 GDPR(General Data Protection Regulation) 제33조의 72시간 감독기관 통지 의무를 대체하지 않습니다. A5 두 통지는 데이터보호당국과 CSIRT/ENISA라는 서로 다른 채널과 수신처로 각각 이뤄져야 합니다.

NIS2 지침(Directive (EU) 2022/2555)의 적용을 받는 필수 서비스·중요 서비스 운영자가 자사 제품에서 취약점이나 사고를 인지한 경우도 마찬가지입니다. CRA 보고와 NIS2 보고가 동시에 필요할 수 있습니다. Digital Omnibus 패키지의 “report once, share many” 모델이 두 보고 의무를 통합하는 방향으로 논의되고 있으나 아직 입법으로 확정되지 않았습니다. A4, E2

5. 적합성 평가와 CE 마킹 (2027-12-11)

적합성 평가는 2027년 12월 11일이 시한입니다. 등급에 따라 경로가 다릅니다. 기본(default) 등급 제품은 자체 평가(self-assessment)로 EU 적합성 선언(EU Declaration of Conformity)을 발행하고 CE 마킹을 부착할 수 있습니다. 중요 Class I 제품은 EU 조화 표준을 적용한 자체 평가를 하거나 제3자 적합성 평가 기관(Conformity Assessment Body, CAB)의 평가를 받을 수 있습니다. 중요 Class II와 중대(critical) 등급 제품은 CAB의 강화된 검사가 필수입니다. A1, B3

ENISA는 2025년 2월 CRA Implementation via EUCC and its Applicable Technical Elements를 발간해, EU 공통 기준(EU Common Criteria, EUCC) 인증을 CRA 적합성 평가에 활용할 수 있는 경로를 분석했습니다. B6

2026년 6월 11일부터는 적합성 평가기관의 통보(notification) 관련 조항이 적용됩니다. 각 회원국은 이 시점까지 통보 당국(notifying authority)을 지정해야 하고, 제3자 적합성 평가를 맡을 통보 기관(notified body)이 2026년 12월 11일까지 충분히 갖춰지도록 공인 절차가 시작됩니다. B3

위반 시 제재는 위반 유형에 따라 달라집니다. 가장 엄중한 위반(본질 요건 미충족, 보고 의무 위반)에는 1,500만 유로 또는 전 세계 연간 매출액의 2.5% 중 큰 금액이 과징금으로 부과될 수 있고, EU 시장에서 제품을 회수하라는 명령도 가능합니다. A1, E1

6. 표준·프레임워크 매핑

CRA는 본질 요건만 규정하고 기술적 세부는 조화 표준에 위임합니다. CEN/CENELEC JTC 13 WG 9가 CRA용 유럽 조화 표준(EN)을 만들고 있으며, 2026년 8월 30일 수평 표준, 2026년 10월 30일 수직 표준 발행이 목표입니다. 수평 표준은 어휘(prEN 40000-1-1), 원칙(prEN 40000-1-2), 취약점 처리(prEN 40000-1-3), 일반 보안 요건(prEN 40000-1-4)으로 구성된 prEN 40000-1 시리즈로 진행됩니다. 최종 인용 표준 목록이 아직 확정되지 않았으므로, 현 시점에는 아래 표를 매핑 후보로 활용할 수 있습니다. B5

C1, C2, C3, C4, C5, C6, G1, C7

유럽 취약점 데이터베이스(European Vulnerability Database, EUVD)는 NIS2 지침 제12조를 이행하는 형태로 ENISA가 2025년 5월 13일 정식 가동했습니다. F1 CRA의 “취약점 모니터링” 요건에서 EUVD를 1차 모니터링 출처로 활용할 수 있습니다. EUVD는 독자적 식별자(EUVD-YYYY-NNNNNN)를 쓰면서 CVE ID와 CVSS 점수를 함께 표기합니다. SRP와는 별개 시스템입니다. SRP는 제조사가 당국에 통지하는 채널이고, EUVD는 공개 데이터베이스입니다. B4, F2

7. 최신 동향 (2025~2026)

2024년 12월 발효 이후 규제 환경은 위임법과 시행규칙, 가이던스 세 방향에서 구체화됐습니다.

시행규칙 (EU) 2025/2392는 2025년 11월 28일 채택돼 12월 21일 발효됐습니다. CRA Annex III와 IV가 가리키는 “중요(important)·중대(critical) 제품"을 28개 범주로 구분해 Class I과 Class II, 중대 세 등급에 배치하는 기술 정의를 확정했습니다. 제조사가 자사 제품의 적합성 평가 경로를 판단할 1차 법적 기준이 이 규칙입니다. A3

위임법 (EU) 2026/881은 2025년 12월 11일 채택돼 2026년 4월 20일 관보에 실렸습니다. CSIRT 간 통지 전파를 지연할 수 있는 조건을 법제화한 것입니다(§4.4 참조). A2

가이던스 문서는 두 단계로 나왔습니다. 2025년 12월 3일 Commission의 첫 공식 FAQ가 발행됐고(12월 19일 업데이트), 위험 평가의 범위와 반복성, “의도된 사용(intended purpose)” 개념을 비구속적이지만 처음으로 풀어냈습니다. 이어 2026년 3월 3일에는 CRA 제26조에 따른 첫 가이던스 초안이 공개됐습니다. 총 75쪽 분량 중 약 4분의 1을 오픈소스 스튜어드 정의에 할애한 이 초안은 원격 데이터 처리 솔루션, 자유·오픈소스 소프트웨어, 지원 기간, 그리고 CRA와 NIS2, DORA 등 타 규정과의 상호관계를 다뤘습니다. 3월 31일 의견수렴이 마감됐으나 최종본은 2026년 6월 현재까지 나오지 않았습니다. E3

오픈소스 커뮤니티의 집단 대응은 2024년 4월 2일 아파치(Apache Software Foundation), 블렌더(Blender Foundation), 이클립스(Eclipse Foundation), OpenSSL, PHP(PHP Foundation), 파이썬(Python Software Foundation), 러스트(Rust Foundation) 등 7개 재단이 안전한 소프트웨어 개발을 위한 공통 표준을 함께 마련하겠다고 발표하면서 가시화됐습니다. 이 작업은 브뤼셀의 이클립스 재단(Eclipse Foundation AISBL)이 주관했고, 같은 해 9월 24일 Open Regulatory Compliance Working Group(ORC WG)으로 발전해 스튜어드의 의무 범위를 정리한 백서를 공개했습니다. OpenSSF는 SBOM 표준 정렬 방향을 2025년 10월 22일 공개했습니다. F3, D1

가장 끈질긴 쟁점은 24시간 통지의 실효성입니다. HackerOne 등 보안 연구자 측은 “패치가 준비되기 전에 취약점 존재 사실이 당국에 통지되면 미완화 취약점이 노출될 위험이 있다"는 주장을 2024년부터 거듭 제기해 왔습니다. E4 위임법 (EU) 2026/881은 CSIRT 간 전파 지연 조건만 신설했을 뿐, 제조사가 CSIRT에 보내는 24시간 시한 자체에는 손대지 않았습니다.

8. 한국 기업 관점 — 약 3개월 안에 해야 할 것

8.1 적용 여부 진단

2026년 9월 11일이 시한인 보고 의무가 자사에 적용되는지부터 확정해야 합니다. EU 시장에 제품이 유통되는가, 그 제품이 디지털 요소를 가진 제품인가, 더 엄격한 부문별 사이버보안 입법이 이미 적용되는가를 차례로 확인합니다. EU 유통에는 직판과 재판매, OEM 공급이 모두 포함되며, EU 법인이 없어도 한국 본사가 직수출하면 적용됩니다. 네트워크나 장치와 데이터 연결이 가능한 소프트웨어나 하드웨어라면 디지털 요소를 가진 제품에 해당합니다. 의료기기나 자동차 안전처럼 더 엄격한 규제가 이미 적용되는 영역이라면 CRA 적용이 배제될 수 있습니다.

레거시 제품도 적용 대상입니다. 이미 EU 시장에 출시된 제품에도 9월 11일부터 보고 의무가 발생한다는 점은 많은 기업이 간과하기 쉬운 부분입니다. E1

8.2 준비 단계

9월 11일까지는 인증서를 갖출 필요가 없습니다. 필요한 것은 보고 워크플로우입니다. 취약점이나 사고를 인지한 순간부터 24시간 안에 조기 경보를 발신할 수 있는 인적 체계와 기술 연결이 있어야 하며, 온콜(on-call) 체계, 의사결정 권한, 외부 커뮤니케이션 담당자를 미리 지정해 두어야 합니다.

모든 출고 버전의 SBOM을 SPDX 또는 CycloneDX 형식으로 자동 생성하고 보관하는 파이프라인도 9월 11일까지 필요합니다. BSI TR-03183-2 v2.1.0의 필드 매핑을 현실적 참조점으로 활용할 수 있습니다. G1

ENISA는 현 단계에서 SRP 연동 API를 제공하지 않는다고 밝힌 상태입니다(2026년 6월 현재). 운영 매뉴얼은 6월 중 제공이 예고됐으므로, 자동 연동을 전제하기보다 사람이 플랫폼에 직접 제출하는 절차를 마련하고 ENISA의 매뉴얼과 시험 기간 공지를 지켜봐야 합니다.

EUVD(https://euvd.enisa.europa.eu)를 자사 제품의 구성 요소와 연계해 모니터링하는 절차도 필요합니다. CVE ID와 EUVD-YYYY-NNNNNN 두 식별자 체계를 처리할 수 있어야 합니다.

2027년 12월 11일까지는 한 단계 더 나아가야 합니다. CE 마킹과 적합성 평가, 자사 제품 등급에 맞는 CAB 선정(Class I 이상이라면), 조화 표준 발행 후 적합성 선언이 필요합니다. CEN/CENELEC의 수평 표준(2026-08-30 목표)과 수직 표준(2026-10-30 목표) 발행을 주시해야 합니다.

8.3 타 관할권 비교

C6, E2

CRA의 두드러진 특징은 IoT와 소프트웨어, 임베디드를 가리지 않는 수평적 적용과 직접 효력입니다. 한국 SW공급망 가이드라인 1.0은 NIST SSDF를 기반으로 30개 점검 항목과 SBOM 절차를 권고하는데, CRA 본질 요건과 SSDF가 기능적으로 정렬되므로 국내 가이드라인을 따라 구축한 체계는 CRA 대응의 출발점이 됩니다. 다만 한국 가이드라인은 권고이고 CRA는 과징금 체계를 갖춘 법적 의무이며, CRA는 그 위에 별도의 보고 의무를 추가합니다.

9. 결론과 권고

2026년 9월 11일은 CRA가 제조사에게 처음으로 실질적인 이행 의무를 부과하는 날입니다. CE 마킹과 적합성 평가는 2027년 12월 11일이 시한이지만, 보고 워크플로우는 그 전에 완성돼 있어야 합니다.

한국 기업이라면 자사 제품이 CRA 적용 대상인지부터 확정하고, 해당한다면 기본과 중요, 중대 가운데 어느 등급인지 시행규칙 (EU) 2025/2392 기준으로 판단하는 일이 우선입니다. 등급에 따라 2027년의 적합성 평가 경로와 거기에 드는 준비 기간이 달라지기 때문입니다.

보고 인프라와 내부 플레이북 구성이 그 다음입니다. SRP 운영 매뉴얼이 아직 나오지 않았지만, 인적 체계와 내부 절차는 그와 무관하게 지금 바로 설계할 수 있습니다. ENISA가 연동 API를 제공하지 않겠다고 밝힌 만큼 자동 연동보다 플랫폼 수동 제출 절차를 갖추고, 매뉴얼과 시험 기간 공지를 지켜봐야 합니다.

SBOM 파이프라인 자동화는 9월 11일까지 끝내야 합니다. 출고 버전마다 SPDX 또는 CycloneDX 형식의 SBOM이 자동 생성·보관되지 않으면, 보고 의무를 이행할 때 필요한 소프트웨어 구성 정보 자체가 없는 상황이 됩니다. A1, B2, E2, E4

참고 자료

A. 법령·규제 원문 (1차)

A1. European Parliament and Council (2024). Regulation (EU) 2024/2847 of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). Official Journal of the European Union, OJ L, 2024/2847, 20.11.2024. https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng (접속: 2026-05-12). ↩

A2. European Commission (2025). Commission Delegated Regulation (EU) 2026/881 of 11 December 2025 supplementing Regulation (EU) 2024/2847 with regard to the conditions for delaying dissemination of notifications of actively exploited vulnerabilities and severe incidents. Published 20 April 2026. https://eur-lex.europa.eu/eli/reg_del/2026/881/oj (접속: 2026-05-12). ↩

A3. European Commission (2025). Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025 laying down technical descriptions of categories of important and critical products with digital elements. OJ L, 2025/2392. https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L_202502392 (접속: 2026-05-12). ↩

A4. European Parliament and Council (2022). Directive (EU) 2022/2555 of 14 December 2022 on measures for a high common level of cybersecurity across the Union (NIS2 Directive). OJ L 333, 27.12.2022. https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng (접속: 2026-05-12). ↩

A5. European Parliament and Council (2016). Regulation (EU) 2016/679 — General Data Protection Regulation (GDPR). OJ L 119, 4.5.2016. https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679 (접속: 2026-05-12). ↩

B. 발행 기관 공식 문서

B1. European Commission, DG CNECT (2026). Cyber Resilience Act — Shaping Europe’s digital future. https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act (접속: 2026-05-12). ↩

B2. European Commission, DG CNECT (2026). Cyber Resilience Act — Reporting obligations. https://digital-strategy.ec.europa.eu/en/policies/cra-reporting (접속: 2026-05-12). ↩

B3. European Commission, DG CNECT (2024). The Cyber Resilience Act — Summary of the legislative text. https://digital-strategy.ec.europa.eu/en/policies/cra-summary (접속: 2026-05-12). ↩

B4. ENISA (2026). Single Reporting Platform (SRP). https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp (접속: 2026-05-12). ↩

B5. ENISA & Joint Research Centre (2024). Cyber Resilience Act Requirements Standards Mapping — Joint Analysis. April 2024. https://www.enisa.europa.eu/publications/cyber-resilience-act-requirements-standards-mapping (접속: 2026-05-12). ↩

B6. ENISA (2025). Cyber Resilience Act implementation via EUCC and its applicable technical elements. 26 February 2025. https://certification.enisa.europa.eu/publications/cyber-resilience-act-implementation-eucc-and-its-applicable-technical-elements_en (접속: 2026-05-12). ↩

C. 표준·프레임워크

C1. ISO/IEC (2019). ISO/IEC 30111:2019 — Information technology — Security techniques — Vulnerability handling processes. Edition 2. https://www.iso.org/standard/69725.html (접속: 2026-05-12). ↩

C2. ISO/IEC (2018). ISO/IEC 29147:2018 — Information technology — Security techniques — Vulnerability disclosure. Edition 2. https://www.iso.org/standard/72311.html (접속: 2026-05-12). ↩

C3. ISO/IEC (2021). ISO/IEC 5962:2021 — Information technology — SPDX® Specification V2.2.1. https://www.iso.org/standard/81870.html (접속: 2026-05-12). ↩

C4. The Linux Foundation / SPDX Project (2024). SPDX Specifications (current: v3.0). https://spdx.dev/specifications/ (접속: 2026-05-12). ↩

C5. OWASP Foundation / Ecma International (2025). CycloneDX Specification v1.7 / ECMA-424, 2nd Edition. ECMA-424 published 2025-12-10. https://cyclonedx.org/specification/overview/ (접속: 2026-05-12). ↩

C6. Souppaya, M., Scarfone, K., Dodson, D. — NIST (2022). Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. NIST SP 800-218. DOI: 10.6028/NIST.SP.800-218. https://csrc.nist.gov/publications/detail/sp/800-218/final (접속: 2026-05-12). ↩

C7. OpenSSF Global Cyber Policy Working Group (2026). CRA Standards Map. https://policy.openssf.org/CRA/standards.html (접속: 2026-06-09). — 용도: CEN/CENELEC JTC 13 WG 9의 prEN 40000-1 시리즈(수평 조화 표준) 번호·진행 현황 확인. ↩

D. 학술·정책 연구

D1. OpenSSF Best Practices WG / Global Cyber Policy WG (2025). Cyber Resilience Act (CRA) Brief Guide for Open Source Software (OSS) Developers. Lead author: David A. Wheeler. https://best.openssf.org/CRA-Brief-Guide-for-OSS-Developers.html (접속: 2026-05-12). ↩

E. 업계·법무법인 분석

E1. Bird & Bird LLP (2026). CRA’s phased entry into application starts in September 2026. Bird & Bird Insights. https://www.twobirds.com/en/insights/2026/cra%E2%80%99s-phased-entry-into-application-starts-in-september-2026 (접속: 2026-05-12). ↩

E2. DLA Piper — Blum, L. & Moylan Burke, L. (2026). Cyber Resilience Act: What you need to know and what you need to be doing. 19 February 2026. https://www.dlapiper.com/en/insights/publications/2026/02/cyber-resilience-act-what-you-need-to-know-and-what-you-need-to-be-doing (접속: 2026-05-12). ↩

E3. DLA Piper (2026). Cyber Resilience Act: Commission unveils draft implementation guidance. Law in Tech. https://www.dlapiper.com/en-us/insights/publications/law-in-tech/2026/cyber-resilience-act (접속: 2026-05-12). ↩

E4. HackerOne — Eldering, B. (2026). EU Cyber Resilience Act: Preparing Your VDP for 2026 Reporting Requirements. https://www.hackerone.com/blog/cyber-resilience-act-vdp-2026-reporting-readiness (접속: 2026-05-12). ↩

F. 언론·공식 발표 (보조)

F1. ENISA (2025). Consult the European Vulnerability Database to enhance your digital security! News release, 13 May 2025. https://www.enisa.europa.eu/news/consult-the-european-vulnerability-database-to-enhance-your-digital-security (접속: 2026-05-12). ↩

F2. European Commission (2025). EU launches a European vulnerability database to boost its digital security. https://digital-strategy.ec.europa.eu/en/news/eu-launches-european-vulnerability-database-boost-its-digital-security (접속: 2026-05-12). ↩

F3. Eclipse Foundation (2024). The Open Source Community is Building Cybersecurity Processes for CRA Compliance. Life at Eclipse, 2 April 2024. https://eclipse-foundation.blog/2024/04/02/open-source-community-cra-compliance/ (접속: 2026-05-29). ↩

G. 회원국 기관 기술 가이드

G1. Bundesamt für Sicherheit in der Informationstechnik (BSI) (2025). Technical Guideline TR-03183-2 v2.1.0 — Cyber Resilience Requirements for Manufacturers and Products, Part 2: Software Bill of Materials (SBOM). August 2025. 요지 정리: Sbomify, EU Cyber Resilience Act (CRA) SBOM Requirements. https://sbomify.com/compliance/eu-cra/ (접속: 2026-05-12). ↩