2026

• CISA 2026 SBOM 최소 요소: 데이터 필드 7개에서 17개로, 무엇을 준비할 것인가
• 미국 AI 행정명령(2026-06-02)이 기업 오픈소스 관리자에게 의미하는 것
• EU 오픈소스 전략: 기술 주권을 위한 오픈소스의 제도화
• AI가 만든 코드, 오픈소스 검사를 어디까지 해야 할까
• EU 사이버 복원력법(CRA) 취약점 보고 의무 — 2026-09-11 시행 대비 조사보고서
• Rockchip과 FFmpeg의 라이선스 분쟁 사례

CISA 2026 SBOM 최소 요소: 데이터 필드 7개에서 17개로, 무엇을 준비할 것인가

요약

2026년 7월 29일, 미국 사이버보안·인프라보안국(Cybersecurity and Infrastructure Security Agency, CISA)을 비롯한 18개 기관이 소프트웨어 자재 명세서(Software Bill of Materials, SBOM)가 최소한 담아야 할 요소(Minimum Elements) 개정판을 발행했습니다A2. 2021년 미국 통신정보관리청(National Telecommunications and Information Administration, NTIA)이 만든 기준을 개정한 것이 아니라 대체(replaces)한다고 문서가 직접 밝힙니다.

요구 수준이 눈에 띄게 올라갔습니다. 데이터 필드가 7개에서 17개로 늘었고 운영 원칙 6개가 함께 규정됐습니다. 신규 요소만 10개입니다.

실무에서 중요한 변화는 세 가지입니다.

• 라이선스가 SBOM 최소 기준에 처음 들어왔습니다.
• 의존성은 깊이 제한 없이 전이 의존성까지 전부 기록하라는 요구가 붙었습니다.
• SBOM 문서 자체의 출처와 무결성을 밝히는 필드가 신설됐습니다.

이 문서에는 시행일도 강제력도 없습니다. 그럼에도 준비가 필요한 이유는 각국 규제가 SBOM을 요구하면서 정작 필드 목록은 열거하지 않기 때문입니다. 조달 계약에서 인용할 수 있는 다자 합의 기준이 생겼다는 점이 이 문서의 실질적 의미입니다.

준비의 성격을 오해하기 쉽습니다. 최소 요소를 채우는 일은 도구를 하나 고르는 문제가 아닙니다. 23개 요소 가운데 생성 도구가 혼자 채울 수 있는 것은 절반이 못 됩니다. 나머지는 빌드 파이프라인과 서명 인프라, 그리고 조직이 미리 정해 둔 정책이 채웁니다.

실제 도구가 어디까지 채우는지도 확인했습니다. SK텔레콤이 소프트웨어 공급망 보안을 위해 개발해 오픈소스로 공개한 SBOM 생성·관리 도구 BomLens로 23개 요소를 판정한 결과는 다음과 같습니다.

• 데이터 필드 17개 중 11개를 도구가 직접 값으로 채웁니다.
• 공급사가 보낸 SBOM을 23개 요소 기준으로 검사하고, 조직이 정할 4개는 사람 검토로 분리합니다.
• 나머지가 비는 이유는 도구의 미비가 아니라 실행 주체나 빌드 시점이 정해야 하는 값이기 때문입니다.

판정 화면은 설치 없이 공개 데모에서 바로 확인할 수 있습니다.

1. 무엇이 바뀌었습니까

1.1 요소의 구조

최소 요소는 두 범주로 나뉩니다. SBOM 문서에 실제로 담기는 값이 데이터 필드 17개이고, 조직이 SBOM을 다루는 방식을 규정한 것이 운영 원칙 6개입니다.

그림 1. CISA 2026 SBOM 최소 요소의 구성 (출처: 2026 Minimum Elements for a SBOM, 2026-07-29)

2021년판에는 없던 범주가 SBOM 메타데이터입니다. 예전에는 작성자와 타임스탬프 정도만 물었지만, 이제는 어떤 도구로 언제 어느 단계에서 만들었고 누가 서명했는지를 문서 스스로 밝히도록 요구합니다.

1.2 세 가지 실질적 변화

라이선스가 필수 항목이 됐습니다. 2021년판 데이터 필드 7개에는 라이선스가 없었습니다. 보안과 취약점 관리를 목적으로 한 문서였기 때문입니다. 개정판은 컴포넌트 라이선스를 신규 요소로 추가하면서, 가능하면 SPDX 라이선스 식별자처럼 기계 처리 가능한 형태로 전달하고 독점 라이선스 조건의 존재도 함께 밝히라고 규정합니다. 오픈소스 프로그램 오피스(Open Source Program Office, OSPO)가 다루던 영역이 SBOM 최소 기준의 일부가 된 것입니다.

의존성 해석의 하한이 사라졌습니다. 2021년판의 깊이(Depth) 요소는 최상위 의존성만 요구했습니다. 개정판은 이를 커버리지(Coverage) 요소로 대체하면서 전이 의존성을 포함한 모든 구성요소를 요구하며, 일정 깊이까지만 기록하면 충분하다는 하한을 인정하지 않는다고 명시합니다. 문서는 이 변경의 이유를 솔직하게 적었습니다. 2021년의 기준은 “정보에 근거한 보안 결정에 필요한 정보의 깊이가 아니라 당시 SBOM 도구의 역량을 반영한 것"이었고, 그 사이 도구가 발전했으므로 요구를 올린다는 것입니다.

공급자 이름이 컴포넌트 생산자로 바뀌었습니다. 명칭 변경이 아니라 정의 변경입니다. 문서는 공급자 이름이 “실무에서, 특히 소프트웨어 배포자와 관련하여 모호한 것으로 드러났다"고 밝힙니다. 재배포자를 적어 온 관행을 중단하고 소프트웨어를 최초로 만든 주체를 가리키도록 조정한 것입니다. 오픈소스 프로젝트처럼 생산자가 불분명하면 출처 미상임을 명시하라고 요구합니다.

이 밖에 소프트웨어 식별(SWID) 태그가 인정 형식에서 빠졌습니다. 남은 것은 SPDX와 CycloneDX 둘입니다.

2. OSPO는 무엇을 정해야 합니까

운영 원칙 6개는 도구가 아니라 조직이 답해야 하는 항목입니다. 문서도 “조직은 SBOM을 요구하거나 제공하는 모든 정책·계약·약정에서 이 요소들을 명시적으로 다루어야 한다"고 적습니다.

2.1 어디까지 포함할 것인가

커버리지 요소는 전이 의존성 전부를 요구하되 코드가 아닌 파일은 제외할 수 있다고 합니다. 다만 설정 파일처럼 보안과 관련된 파일은 포함할 수 있다고 덧붙입니다. 어디까지를 보안 관련 파일로 볼지는 조직이 정해야 합니다.

판단 기준은 문서가 제시한 취약점 관리 관점이 유용합니다. SBOM 수신자가 새로 보고된 취약점과 연관된 구성요소가 목록에 없다면 그 취약점이 자신에게 영향을 주지 않는다고 결론 내릴 수 있어야 한다는 것입니다. 이 기준을 통과하지 못하는 범위 설정은 커버리지 요건을 충족하지 못합니다.

하위 구성요소마다 별도 SBOM으로 연결하는 방식도 허용되지만 조건이 붙습니다. 수신자가 연결된 모든 SBOM에 접근할 수 있어야 합니다. 링크만 걸고 접근 권한을 주지 않으면 요건을 채우지 못합니다.

2.2 언제 다시 만들 것인가

주기 요소는 각 소프트웨어 버전이나 갱신마다 대응하는 SBOM을 요구합니다. 새 빌드나 릴리스를 내면 새 SBOM을 만들어야 하고, 여기에는 의존성만 갱신된 빌드도 포함됩니다.

여기에 하나가 더 붙습니다. 기존 SBOM 데이터의 오류를 발견하거나 구성요소에 관한 새로운 사실을 알게 되면 개정판을 발행해야 합니다. 릴리스가 없어도 SBOM을 다시 내야 하는 경우가 생긴다는 뜻이며, 이를 위해서는 이미 배포한 SBOM이 어디로 갔는지 추적하는 수단이 필요합니다.

2.3 모르는 것을 어떻게 적을 것인가

미상 정보의 명시적 식별은 주요 갱신 항목입니다. 요구가 구체적입니다. 값이 없을 때 그 정보가 작성자에게 미상인지, 아니면 작성자가 알면서 보류하는지를 구분해 밝혀야 합니다.

이 구분은 수신자에게 다른 정보를 줍니다. 미상이면 공급망 추적이 거기서 끊겼다는 뜻이고, 보류라면 공급자가 알면서 주지 않는다는 뜻입니다. 문서는 후자의 경우 수신자가 문의할 수 있는 절차를 갖추라고 요구하고, 필수적인 구성요소 데이터를 보류하면 그 SBOM을 불완전한 것으로 볼 수 있다고 덧붙입니다.

실무에서는 표기 규약을 먼저 정해야 합니다. 필드를 그냥 비워 두면 셋 중 어느 경우인지 알 수 없습니다. 값이 없는 것인지, 확인하지 못한 것인지, 밝히지 않기로 한 것인지 구분되지 않습니다.

2.4 어떤 형식을 받을 것인가

기계 처리 가능 데이터 요소는 SPDX와 CycloneDX를 지목하면서, 널리 쓰이고 상호운용 가능한 형식을 수용하라고 합니다. 여기에 조건이 하나 붙습니다. 폐기된 버전으로 생성된 신규 소프트웨어의 SBOM은 받지 말아야 합니다.

이 조건은 수용 기준을 하나 더 만듭니다. 형식 이름만이 아니라 형식 버전까지 봐야 하며, 신규 요소인 SBOM 데이터 형식 이름과 버전이 이 판단의 근거가 됩니다.

2.5 계약에 무엇을 적을 것인가

위 항목들을 계약 문구로 옮기면 다음과 같이 정리됩니다.

• 요구할 형식과 최소 버전
• 전이 의존성을 포함한 커버리지 범위
• 릴리스마다의 제공 의무와 오류 발견 시 개정판 제공 의무
• 미상과 보류의 구분 표기, 그리고 보류된 항목에 대한 문의 절차

문서가 조직에 권하는 세 가지 조치도 같은 방향입니다. 갱신된 최소 요소를 충족하는 SBOM을 요구하고, 도구를 써서 SBOM 데이터를 생성·수집·분석하며, 스스로도 최소 요소를 충족하는 SBOM을 생성하라는 것입니다.

3. 누가 각 요소를 채웁니까

23개 요소를 누가 채우는지 나눠 보면 준비의 성격이 분명해집니다.

그림 2. 최소 요소 23개를 채우는 네 영역 (출처: 원문 요소 정의를 근거로 정리)

생성 도구가 혼자 감당할 수 있는 것은 컴포넌트 데이터 쪽입니다. 나머지는 도구 바깥에서 채워야 합니다.

생성 맥락은 빌드 파이프라인 안에서 기록해야 정확합니다. 소스에서 만든 SBOM은 “빌드 이전”, 바이너리 분석으로 만든 SBOM은 “빌드 이후"에 해당하는데, 이 값은 스캔 대상이 아니라 스캔 시점이 결정합니다.

컴포넌트 해시는 실행 가능한 산출물이 있어야 계산됩니다. 소스 스캔 시점에는 그 산출물이 아직 없으므로 원천적으로 불가능하며, 문서도 이 경우 미상 표시를 규정합니다. 해시를 요구하려면 빌드 이후 단계에서 SBOM을 만들거나 갱신하는 흐름이 필요합니다.

작성자 서명은 키 관리가 전제입니다. 문서는 기존 소프트웨어 서명 인프라와 키 관리를 쓰라고 규정하며, 이는 SBOM 도구의 범위를 벗어납니다.

SBOM 작성자는 도구가 알 수 없는 값입니다. 정의가 “도구를 운영하는 주체"이므로 실행하는 쪽이 넘겨줘야 합니다.

3.1 어떤 형식이 신규 요소를 담습니까

신규 필드 10개를 담는 정도가 형식마다 다르므로, 어떤 형식을 쓸지 자체가 실무에서 따져야 할 결정이 됩니다C3.

표 1. 신규 요소의 형식별 표현 가능 여부 (출처: RunSafe Security 필드 매핑 분석, 2026)

CycloneDX가 신규 메타데이터 쪽에서 유리합니다. 생성 맥락과 서명이 네이티브 필드로 있고, 원문이 예시로 든 수명주기 단계 어휘가 그대로 대응합니다.

반대로 미상 표기에는 SPDX 쪽에 더 나은 수단이 있습니다. NOASSERTION이라는 표준 표지가 있어 “값 없음"과 “확인하지 못함"을 구분할 수 있는데, CycloneDX에는 같은 층위의 표지가 없어 속성이나 주석으로 규약을 따로 정해야 합니다. 그런데 미상 표기는 이번 개정에서 요구가 강화된 항목입니다.

지금 시점의 판단은 이렇습니다. 최소 요소를 가장 온전히 담는 조합은 CycloneDX 1.6이되, 미상 표기 규약을 조직이 정해 두어야 합니다. SPDX를 주 형식으로 쓰는 조직은 2.3에 생성 맥락과 서명을 담을 자리가 없으므로 3.0 이행을 검토할 시점입니다.

4. 규제와의 관계

최소 요소 자체에는 법적 구속력이 없습니다. 면책 조항이 이 간행물은 “컴플라이언스·규제·법률 목적의 조언으로 의도되지 않았다"고 밝힙니다.

실질적인 영향력은 참조 관계에서 생깁니다. 유럽연합 사이버 복원력법(Cyber Resilience Act, 규정 (EU) 2024/2847)은 제조자에게 기술 문서의 일부로 SBOM 제공을 요구하지만 필드 목록을 조문에 열거하지 않습니다A5. 독일 BSI TR-03183-2가 그 공백을 구체적인 기술 요구사항으로 채웠고, 인도 CERT-In과 일본 경제산업성도 각자의 가이드를 냈습니다. 최소 요소는 이들이 공통으로 참조하는 기준입니다. 2026년 9월 11일 시행되는 사이버 복원력법의 취약점 보고 의무는 별도 글에서 다뤘습니다D2.

한 가지 유의할 점이 있습니다. 유럽위원회 통신네트워크·콘텐츠·기술총국(DG CONNECT)이 작성에 기여했지만, 문서 각주는 이 문서가 유럽연합 법을 해석하지 않고 위원회를 구속하지 않으며 모든 요소가 연합 법을 반영하지는 않는다고 밝힙니다. 사이버 복원력법 준수 근거로 이 문서를 그대로 쓸 수는 없습니다.

용어에서 혼동하기 쉬운 부분도 하나 있습니다. 원문 각주는 컴포넌트 생산자의 “생산자(producer)“를 사이버 복원력법의 “제조자(manufacturer)“와 혼동하지 말라고 명시합니다. 모든 제조자는 생산자이지만 모든 생산자가 제조자는 아닙니다. 두 제도를 함께 다루는 문서에서는 용어를 구분해 써야 합니다.

한국은 국가정보원 산하 국가사이버안보센터와 한국인터넷진흥원 두 기관이 공동 저작에 참여했습니다. 이 참여는 국내 조달과 사내 정책에서 이 문서를 인용할 근거가 됩니다. 정부 합동 소프트웨어 공급망 보안 강화 로드맵이 2026년 6월 발표된 직후에 국제 공통 기준이 갱신됐으므로, 국내 제도가 요구 필드를 구체화할 때 참조할 기준이 하나 생긴 셈입니다.

AI 시스템을 다루는 조직은 순서를 기억해 둘 만합니다. 원문은 AI 전용 요소를 도입하지 않고 G7 공동 가이던스에 맡겼습니다A10. 두 문서는 상하 관계이며, 일반 소프트웨어 기준인 이 문서를 먼저 채운 뒤 AI 추가 요소를 더하는 순서입니다.

5. 실제 도구는 지금 어디까지 채웁니까

기준을 읽는 일과 도구가 그 기준을 실제로 채우는지 확인하는 일은 별개입니다. 형식에 자리가 있어도 도구가 값을 넣지 않으면 빈 필드로 남기 때문입니다.

SK텔레콤이 소프트웨어 공급망 보안을 위해 자체 개발해 오픈소스로 공개한 SBOM 생성·관리 도구 BomLens로 23개 요소를 전부 판정해 봤습니다. 추정이 아니라 실제 스캔 산출물과 소스 코드를 근거로 삼았습니다D1. 글쓴이는 이 도구를 개발한 조직에 속해 있으므로, 아래 수치는 판정 근거를 함께 밝히고 채우지 못하는 항목도 그대로 적었습니다.

5.1 도구가 값으로 채우는 항목

데이터 필드 17개 가운데 11개를 도구가 직접 채웁니다.

• SBOM 메타데이터: 데이터 형식 이름과 버전, 생성 맥락, 타임스탬프, 도구 이름, SBOM 버전
• 컴포넌트 데이터: 이름, 버전, 식별자, 라이선스, 의존 관계

이 가운데 세 항목은 채우는 방식이 최소 요소의 요구와 직접 관련되어 있습니다.

• 생성 맥락은 입력 종류로 자동 판별합니다. 소스 스캔은 pre-build, 컨테이너와 바이너리 스캔은 post-build로 기록하므로 사용자가 값을 고를 필요가 없습니다.
• 라이선스는 소스 경로에서 98.4%, 컨테이너 경로에서 94.7%를 채웁니다. 소스 쪽은 패키지 매니페스트에서, 컨테이너 쪽은 운영체제 패키지 데이터베이스에서 읽습니다.
• 도구 이름에는 BomLens 자신과 하위 생성기를 함께 적습니다. 최소 요소가 요구하는 것은 SBOM을 생성하거나 수정한 도구이므로 둘 다 남깁니다.

운영 원칙 6개 중에서는 기계 처리 가능성과 배포·전달을 충족합니다. CycloneDX 1.6을 기본 형식으로 내고 SPDX 2.3 변환을 지원하므로, 최소 요소가 지정한 두 형식을 모두 다룹니다.

5.2 도구가 채울 수 없는 항목

나머지 항목이 비어 있는 이유는 도구의 미비가 아니라 3장에서 정리한 구조 때문입니다.

• SBOM 작성자와 작성자 서명: 실행하는 주체가 값을 넘겨야 합니다. 작성자는 --sbom-author로 받고, 서명은 cosign을 쓰는 별도 옵션입니다.
• 컴포넌트 해시: 소스 스캔 시점에는 해시를 걸 실행 산출물이 존재하지 않습니다. 컨테이너와 펌웨어처럼 산출물이 있는 경로에서는 스캔 대상 자체에 해시를 붙입니다.
• 컴포넌트 생산자: 패키지 메타데이터에 생산자 정보가 있어야 채워집니다. 소스 경로 60.9%, 컨테이너 경로 94.7%입니다.

값이 없을 때의 처리가 최소 요소 관점에서 중요합니다. 이 도구는 작성자를 지정하지 않으면 unknown을 적지 않고 필드를 비운 뒤, 문서 수준에 “비어 있는 필드는 작성자가 확인하지 못한 것"이라는 선언을 남깁니다. 최소 요소가 정의한 작성자는 도구를 운영하는 주체이고 그 주체는 자신이 누구인지 알고 있으므로, 도구가 unknown을 적으면 미상 표기가 아니라 사실과 다른 진술이 되기 때문입니다. 해시도 같은 원칙으로 값을 지어내지 않습니다.

5.3 받은 SBOM을 최소 요소로 판정하는 기능

공급사가 보낸 SBOM을 23개 요소 기준으로 검사하는 기능도 있습니다. 판정 결과는 세 갈래로 나옵니다. 아래는 공개 데모에 담긴 판정 화면으로, 외부에서 받은 CycloneDX 1.6 문서 하나를 검사한 결과입니다.

그림 3. 공개 데모의 적합성 판정 화면. 23개 요소를 모두 판정 대상에 넣고, 도구가 판단할 수 없는 4개는 사람 검토로 분리한다 (BomLens 공개 데모, FlaskDataService 3.2.0 판정 결과)

• 충족 11개 — SBOM 메타데이터 6개(작성자, 데이터 형식 이름과 버전, 타임스탬프, 도구 이름, SBOM 버전), 컴포넌트 데이터 4개(이름, 버전, 해시 알고리즘, 의존 관계), 운영 원칙 1개(기계 처리 가능성)입니다.
• 미달 8개 — 작성자 서명, 생성 맥락, 도구 버전, 컴포넌트 생산자와 식별자, 라이선스, 해시 값, 그리고 미상 표기입니다.
• 사람 검토 4개 — 커버리지, 갱신 반영(Accommodation of Updates to SBOM Data), 배포·전달, 주기입니다. 조직이 정하는 항목이므로 도구가 판정하지 않고 사람에게 넘깁니다.

도구가 판단할 수 없는 것을 통과로 처리하지 않고 따로 분리한다는 점이 실무에서 유용합니다. 사람 검토로 표시된 4개가 곧 2장에서 다룬 조직의 결정 사항과 겹칩니다.

같은 화면을 공개 데모에서 직접 열어볼 수 있습니다. 설치 없이 브라우저에서 바로 볼 수 있고, 요소마다 무엇이 부족한지와 어떻게 채우는지가 항목별로 붙어 있습니다.

5.4 남은 항목

최소 요소를 온전히 채우기까지 남은 것도 있습니다.

• 도구 버전이 릴리스 번호가 아니라 이미지 태그로 기록됩니다. 최소 요소는 특정 코드 전달분을 식별할 수 있는 값을 요구합니다.
• SBOM 버전이 재생성해도 1로 고정되어 개정 관계를 표현하지 못합니다. 갱신 반영 요소와 직접 연결되는 항목인데, 로컬에서 동작하는 도구가 이전 산출물의 위치를 알 수 없다는 제약이 있어 사용자가 지정하는 방식이 현실적인 대안입니다.

6. 결론

최소 요소 개정판이 요구하는 것은 더 많은 필드가 아니라 다른 종류의 준비입니다.

라이선스가 최소 기준에 들어오면서 SBOM은 보안 부서만의 문서가 아니게 됐습니다. 라이선스 식별자를 기계 처리 가능한 형태로 채우고, 독점 조건의 존재를 밝히고, 모르는 경우 모른다고 적는 일은 OSPO의 업무 방식 그대로입니다. 달라진 것은 그 결과가 SBOM이라는 표준 형식으로 나가야 한다는 점입니다.

준비의 상당 부분은 도구를 고르기 전에 끝나야 합니다. 조직이 정해야 하는 항목은 네 가지입니다.

• 어디까지 포함할 것인가
• 언제 다시 만들 것인가
• 모르는 것을 어떻게 표기할 것인가
• 어떤 형식과 버전을 받을 것인가

이 항목들을 정하지 않은 채 도구부터 도입하면 도구가 만들어 주는 기본값이 그대로 조직의 정책이 됩니다.

도구에 요구할 것과 요구할 수 없는 것도 구분해야 합니다. 소스 스캔 도구에 실행 산출물의 해시를 요구할 수는 없고, 어떤 도구도 조직의 이름을 대신 정해 줄 수 없습니다. 채울 수 없는 값을 채우라고 요구하면 도구는 그럴듯한 값을 지어내게 되고, 그것은 최소 요소가 금지하는 방향입니다.

쓰고 있는 도구가 무엇을 채우고 무엇을 비워 두는지는 한 번 확인해 둘 만합니다. 형식 지원 여부와 필드 충족은 다른 문제이고, 그 차이는 산출물을 직접 열어 봐야 드러납니다. 확인해 볼 도구가 마땅치 않다면 5장에서 다룬 BomLens가 출발점이 됩니다. 오픈소스로 공개되어 있어 누구나 내려받아 쓸 수 있고, 생성한 SBOM이 23개 요소를 어디까지 채우는지와 공급사가 보낸 SBOM이 기준을 충족하는지를 같은 화면에서 확인할 수 있습니다.

참고문헌

A2. Cybersecurity and Infrastructure Security Agency 외 17개 기관 (2026). 2026 Minimum Elements for a Software Bill of Materials (SBOM). v2.1, 2026년 7월 29일 발행, TLP:CLEAR. https://www.cisa.gov/sites/default/files/2026-07/2026_cisa_sbom_minimum_elements_508c.pdf. ↩

A5. European Parliament and Council (2024). Regulation (EU) 2024/2847 — Cyber Resilience Act. Official Journal of the European Union, 2024년 10월 23일. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202402847. ↩

A10. G7 Cybersecurity Working Group / CISA 외 (2026). Software Bill of Materials for AI — Minimum Elements. 2026년 5월 12일 발행, TLP:CLEAR. https://www.cisa.gov/resources-tools/resources/software-bill-materials-ai-minimum-elements. ↩

A1. National Telecommunications and Information Administration (2021). The Minimum Elements For a Software Bill of Materials (SBOM). 2021년 7월 12일 발행. https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom.

A3. Federal Register (2025). Request for Comment on 2025 Minimum Elements for a Software Bill of Materials. 2025년 8월 22일 게재, 의견수렴 2025년 10월 3일 마감. https://www.federalregister.gov/documents/2025/08/22/2025-16147/request-for-comment-on-2025-minimum-elements-for-a-software-bill-of-materials.

B1. SPDX. The System Package Data Exchange. https://spdx.dev/. ISO/IEC 5962:2021.

B2. CycloneDX. https://cyclonedx.org/. Ecma International, ECMA-424: CycloneDX Bill of Materials Specification, 2025년 12월.

C3. RunSafe Security (2026). Mapping CISA’s 2026 SBOM Minimum Elements to CycloneDX and SPDX. https://runsafesecurity.com/blog/sbom-minimum-elements-cyclonedx-spdx/. — 본문 표 1의 근거입니다. 형식별 필드 대응은 이 분석을 옮긴 것이며 명세 원문과 직접 대조하지는 않았습니다. ↩

D1. BomLens. SK텔레콤이 소프트웨어 공급망 보안을 위해 개발해 공개한 SBOM 생성·관리 도구, Apache-2.0. https://github.com/sktelecom/bomlens. 5장의 충족 현황은 이 도구 1.10.3으로 실제 스캔한 산출물과 소스 코드를 근거로 판정했습니다. ↩

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

미국 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). ↩

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

[!IMPORTANT] 외부 분석에서 자주 인용되는 “오픈소스 유지보수 수단 3억 5,000만 유로"는 COM(2026) 503 원문에 나오는 수치가 아닙니다. TechPolicy.Press 저자들이 이 수단에 필요하다고 본 자체 추정치이며, 원문은 금액을 붙이지 않았습니다.A1·E1 반면 “RISC-V 약 5억 유로"는 부속서 II에 실제로 기재되어 있지만, 칩스 공동사업(Chips Joint Undertaking) 투자로 표기되며 오픈소스 전략의 20억 유로 예산과는 별개 항목입니다.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).

AI가 만든 코드, 오픈소스 검사를 어디까지 해야 할까

한 가지 먼저 짚을 점

이 질문에 곧바로 “예"나 “아니오"로 답하기는 어렵습니다. 뒤에서 하나씩 짚겠지만, 답을 좌우하는 것은 AI 자체가 아니기 때문입니다. AI 코딩은 패키지로 선언되지 않은 코드 조각의 유입 속도를 높이지만, 라이선스 의무가 생기는 조건 자체를 바꾸지는 않습니다. 그래서 “AI 시대에 스캔이 의미 있나"보다는 “어떤 조건에서 스니펫 단위 검사가 더 중요해지고, 어떤 조건에서 덜 중요해지나"로 나눠 보는 편이 판단에 도움이 됩니다.

스니펫 검사와 SCA는 다른 이야기

먼저 용어를 분리해야 논의가 엉키지 않습니다.

소프트웨어 구성 분석(Software Composition Analysis, SCA)은 코드에 들어온 오픈소스를 식별하고 그 취약점과 라이선스를 관리하는 활동 전반을 가리킵니다. 대부분의 SCA는 위 표의 첫 줄처럼 선언된 의존성을 봅니다. 스니펫 단위 매칭은 그중 일부 상용 도구만 갖춘 별도 기능으로, 소스 코드 본문을 수많은 오픈소스 프로젝트와 대조해 패키지로 선언되지 않은 조각의 출처를 찾습니다. 여기서 다루는 것은 SCA 전체가 아니라 이 스니펫 매칭입니다.

법적 위험은 실제로 얼마나 될까

AI 코드 스니펫이 라이선스 위반 분쟁으로 이어진 사례부터 봅니다.

가장 널리 알려진 사건은 2022년 11월 오픈소스 개발자들이 GitHub, Microsoft, OpenAI를 상대로 제기한 Copilot 집단소송입니다. 2023년 5월 저작권 침해 청구가 구체적 복제 사례 부족으로 기각됐고, 2024년 7월에는 디지털 밀레니엄 저작권법(Digital Millennium Copyright Act, DMCA) 제1202조(b) 위반 주장도 기각됐습니다. 이 조항은 원저작물에 붙은 저작권 표시 정보를 떼어내는 행위를 금지하는데, 법원은 Copilot 출력이 원본과 충분히 동일하지 않다는 이유로 받아들이지 않았습니다 A2. 처음 22개였던 청구 중 남은 것은 두 건, 오픈소스 라이선스 위반과 계약 위반입니다 A2·A3.

여기에는 두 방향으로 읽을 수 있는 사실이 함께 있습니다.

한편으로, 지금까지 분쟁의 피고는 모두 AI 도구를 만든 벤더이고, AI 코드를 가져다 쓴 도입 기업이 그 이유만으로 소송을 당한 사례는 공개적으로 보고된 바가 없습니다 C1. 또 Microsoft는 2023년 9월 Copilot Copyright Commitment를 통해, 유료 상용 고객이 출력물 때문에 제3자 지식재산권 소송을 당하면 방어 비용과 배상금을 부담하겠다고 밝혔습니다. 다만 제품에 내장된 차단 기능을 끄지 않고 침해물을 의도적으로 생성하지 않아야 한다는 조건이 붙습니다 B1·C5.

다른 한편으로, 법적 판단이 확립된 것은 아닙니다. 위 DMCA 쟁점은 1심 판결 전에 특정 쟁점만 상급 법원에서 먼저 다투는 중간항소 형태로 제9순회항소법원에 올라가 있고, 2026년 6월 현재 판결이 나오지 않은 채 1심 절차가 멈춰 있습니다 A1. 보고된 선례가 없다는 것이 위험이 없다는 뜻은 아닙니다.

라이선스 의무는 언제 생길까

여기서 한 가지를 구분해야 합니다. 소송을 당하는가와, 라이선스를 지킬 의무가 있는가는 다른 문제입니다. 아무도 소송을 걸지 않더라도 오픈소스 라이선스를 지킬 의무 자체는 남습니다. 그리고 그 의무가 발동하는 시점이 중요합니다.

소스 공개를 요구하는 GPL 계열의 카피레프트 의무는 소프트웨어를 배포할 때 생깁니다. 사내에서 실행하기만 하는 것은 사용이지 배포가 아니므로 의무가 발생하지 않습니다 C3·C4. 코드를 전달하지 않는 순수 SaaS도 같은 이유로 GPL 의무 바깥에 있습니다. 여기에는 두 가지 단서가 있습니다.

• AGPL은 네트워크 서비스 제공까지 배포로 보는 더 엄격한 라이선스입니다. AGPL이 적용된 구성요소를 쓰면 코드를 직접 전달하지 않고 서비스로만 제공해도 소스 공개 의무가 생깁니다 C3. 이런 구성요소는 사내 정책으로 배제해 관리할 수 있습니다.
• “사내"는 자사 직원만 쓰는 경우라야 하며, 인수합병이나 오픈소스화로 나중에 배포가 일어나면 그 시점에 문제가 됩니다.

짧은 코드의 저작물성도 따져볼 점입니다. 몇 줄짜리 기능적 코드는 복제된 양이 사소해 문제 삼기 어렵거나(de minimis), 표현 방법이 사실상 하나뿐이라 보호 대상에서 빠질 수 있습니다(merger doctrine) A4·A5. 다만 이는 사안별 판단이고, 길고 창의적인 코드 블록은 보호되므로 모든 스니펫이 자유롭다고 보기는 어렵습니다.

실제로 작은 조각이 의무를 달고 들어오는 경우는 흔합니다. 개발자들이 자주 가져다 쓰는 Stack Overflow의 코드는 CC BY-SA 라이선스여서 출처 표시와 동일 조건 공유 의무가 붙는데, 한 연구에 따르면 GitHub 프로젝트에서 이 코드를 라이선스에 맞게 쓴 비율은 최대 1.8%에 불과했습니다 C6. 작은 조각이라도 라이선스 의무를 달 수 있고, 그 의무가 넓게 지켜지지 않는다는 뜻입니다.

표준은 스니펫 검사를 요구할까

오픈소스 라이선스 컴플라이언스의 국제 표준인 OpenChain ISO/IEC 5230은 컴플라이언스 프로세스를 어디에 둘지, 역할과 책임을 어떻게 배분할지, 프로세스를 어떻게 지속할지를 규정하는 데 초점이 있습니다 A6. 무엇을 달성할지를 정하되 구체적 방법은 조직에 맡기는 비규정적 표준이라, 스니펫 스캔 같은 특정 기법을 의무화하지 않습니다 A6·A7. 표준이 요구하는 것은 제3자 컴포넌트를 식별하고 그 목록인 소프트웨어 자재명세서(Software Bill of Materials, SBOM)를 갖추는 일입니다. 표준을 충족하는 데 중요한 것은 어떤 컴포넌트가 코드에 들어왔는지를 파악하는 일이고, 코드 조각 하나하나의 출처까지 분석하라고 요구하지는 않습니다. 실제로 시장에서 널리 쓰이는 SCA 도구 상당수가 스니펫 매칭 없이 의존성 단위로만 동작합니다.

이 사실은 두 가지로 읽힙니다. 표준이 요구하지 않으므로 스니펫 검사 없이도 표준을 충족할 수 있다는 뜻이기도 하고, 동시에 표준이 다루지 않는 영역이 남아 있다는 뜻이기도 합니다. 의존성 단위 검사는 패키지로 선언되지 않은 채 복사되거나 AI가 생성한 조각을 보지 못합니다. 스니펫 매칭은 바로 그 공백을 메우는 기능이며, 일부 조직은 더 철저한 지식재산권 관리를 위해 이를 수행합니다.

어떤 조건에서 더 중요해질까

스니펫 검사의 비중은 회사가 처한 두 가지 조건에 따라 달라집니다.

첫째, 고객에게 코드나 바이너리를 직접 전달하는지입니다. 온프레미스 설치형 제품, 모바일 앱, SDK, 임베디드 기기 펌웨어처럼 코드가 회사 밖으로 나가면 배포에 해당해 카피레프트 의무가 발동할 수 있습니다. 코드를 전달하지 않는 순수 SaaS는 그 부담이 작습니다.

둘째, 외부 검증을 받는지입니다. 인수합병 실사, 대형 고객의 보안 감사, 규제 요건, 스니펫 수준까지 요구하는 SBOM 제출처럼 회사 밖의 누군가가 코드 출처를 실제로 확인하는 상황입니다.

이 둘이 겹칠수록 잠재된 의무가 실제 비용으로 드러날 가능성이 커집니다. 코드를 전달하더라도 검증 계기가 없으면 위험은 잠재 상태에 머물고, 코드를 전달하지 않으면 의무 자체가 잘 생기지 않습니다. 두 조건 모두 AI 사용 여부와는 무관합니다. AI 코딩은 조건이 성립할 때 유입량을 늘리는 요인이지, 조건을 만드는 요인은 아닙니다.

회사 조건별로 본다면

앞의 두 조건을 두 축으로 놓으면 네 갈래가 나옵니다.

그림 1. 두 조건에 따른 스니펫 검사의 비중

오른쪽 위 칸이 부담이 가장 큰 자리입니다. 코드가 회사 밖으로 나가 라이선스 의무가 생기는데, 인수합병 실사나 고객 감사처럼 그 의무를 실제로 들여다보는 계기까지 있는 경우입니다. 왼쪽 위는 의무가 생기더라도 확인할 사람이 없어 잠재 상태에 머뭅니다. 아래 두 칸은 배포 자체가 없어 따질 의무가 잘 생기지 않습니다.

이 그림은 판단의 출발점이지 정답이 아닙니다. 같은 칸에 있더라도 다루는 코드의 성격, 사용하는 라이선스의 종류, 회사의 위험 감수 수준에 따라 선택은 달라질 수 있습니다.

임베디드는 사정이 다릅니다

지금까지는 패키지 매니저로 빌드하는 소프트웨어를 전제로 했습니다. 공유기, 셋톱박스, IoT 기기, 차량용 제어기처럼 임베디드나 펌웨어로 동작하는 소프트웨어는 사정이 다릅니다. 주로 C/C++로 작성되고, 매니페스트 없이 오픈소스를 소스째 복사해 프로젝트에 직접 넣는 경우가 많습니다. 이러면 의존성 SCA가 읽을 매니페스트가 없어 오픈소스를 거의 보지 못합니다.

한 가지는 구분해야 합니다. Linux 커널이나 BusyBox처럼 통째로 가져다 쓰는 큰 구성요소는 회사가 대개 그 사용을 알고 있습니다. 이건 찾아내는 문제가 아니라 소스를 공개하는 의무를 지키느냐의 문제입니다. 스니펫 스캔이 필요한 경우는 다릅니다. 여러 오픈소스에서 조금씩 가져와 넣었지만 아무도 목록에 올리지 않은 작은 코드 조각들입니다. 의존성 SCA가 보지 못하는 이런 조각을 찾아내는 것이 스니펫 스캔의 몫입니다.

그래서 임베디드에서는 스니펫 스캔이 조건부 보조가 아니라, 선언되지 않은 오픈소스 조각을 찾는 기본 수단에 가깝습니다.

코드가 들어오기 전에 거르는 방법

사후 스캔과 별개로, 문제 코드가 들어오기 전에 막는 방법도 있습니다. GitHub Copilot에는 공개 코드와 똑같은 제안을 차단하는 설정이 있습니다. 공개 코드와 일정 길이(평균 약 150자) 이상 그대로 일치하는 제안은 아예 표시하지 않습니다 B2·C2. GitHub는 150자가 넘는 원문 그대로의 복제는 약 1% 수준이라고 밝혔고, 독립 연구에서는 맥락에 따라 그보다 높게 보고되기도 합니다. 어느 쪽이든 0은 아니지만, 이 설정을 켜면 출처가 불분명한 조각의 유입이 줄어듭니다. 비용이 거의 들지 않고, 앞서 본 벤더 면책의 전제 조건이기도 합니다.

이 설정은 사후 스니펫 스캔과 목적이 겹치는 부분이 있습니다. 한쪽은 들어온 뒤에 찾아내고, 다른 한쪽은 들어오기 전에 막습니다. 둘 중 무엇을, 어느 정도로 둘지는 위의 조건과 비용을 함께 보고 정할 문제입니다.

지금까지 나온 유입 경로와 검사 수단을 한자리에 놓으면 이렇습니다.

그림 2. 코드 유입 경로와 이를 잡아내는 수단

의존성 단위 SCA가 보지 못하는 영역이 어디인지, 그 자리를 스니펫 매칭이 어떻게 메우는지가 이 판단의 출발점입니다.

판단을 위한 기준

이 판단이 간단하지 않은 데는 이유가 있습니다. 패키지로 선언되지 않은 채 복사되거나 AI가 만들어 넣은 코드 조각을 찾아내는 방법은 사실상 스니펫 매칭뿐입니다. 의존성 단위 SCA도, 코드를 거르는 설정도 그 조각까지 다 잡아내지는 못합니다. 그래서 스니펫 매칭만이 채워 주는 부분이 작게나마 남습니다. 그런데 많은 회사에서 그 작은 부분이 실제 손실로 이어지는 경우는 드물고, 스니펫 검사에는 도구 비용과 검토 노력이 듭니다. 결국 이 작은 위험을 막으려고 그만한 비용을 들일지 말지를 정하는 일입니다.

판단할 때 살펴볼 점은 네 가지입니다.

• 코드를 외부에 내보내는가 — 내보낼수록 카피레프트 의무가 실제로 생길 여지가 커집니다.
• 외부 검증을 받는가 — 인수합병 실사나 고객 감사가 있으면 그동안 묻혀 있던 의무가 드러날 수 있습니다.
• 라이선스 위험을 어디까지 감수할 것인가 — 보고된 소송 선례는 없지만 법적 판단이 굳어진 것도 아닙니다. 이 불확실성을 어떻게 받아들일지는 회사가 정할 몫입니다.
• 이미 갖춘 다른 점검 수단이 있는가 — 의존성 단위 SCA, 공개 코드와 똑같은 제안을 막는 AI 도구 설정, AGPL 구성요소 배제 정책을 이미 운영하고 있다면 스니펫 검사가 더 잡아낼 몫은 그만큼 줄어듭니다.

한 가지 덧붙일 점이 있습니다. 스니펫 검사는 늘 켜 두거나 아예 안 하거나, 둘 중 하나로만 정할 일이 아닙니다. 외부에서 코드 출처를 실제로 들여다보는 계기는 대체로 정해져 있습니다. 인수합병 실사나 대형 고객의 감사를 받을 때입니다. 그래서 평소에는 의존성 검사와 차단 설정만 운영하다가, 이런 시점이 예상되면 그때 스니펫 검사를 한 번 받는 방법도 있습니다.

위 네 가지와 이런 운영 방식을 자기 회사 상황에 맞춰 보면, 스니펫 검사에 얼마나 비중을 둘지에 대한 답은 회사마다 다르게 나올 것입니다. 단, 매니페스트 없이 빌드하는 임베디드 소프트웨어는 예외입니다. 거기서는 스니펫 스캔이 조건부 보조가 아니라 선언되지 않은 오픈소스 조각을 찾는 기본 수단이 됩니다.

보안 취약점은 별개의 문제입니다

지금까지는 라이선스 이야기였습니다. 보안 취약점은 다른 축이고, 위의 조건부 결론을 그대로 적용하면 안 됩니다. 취약한 오픈소스가 코드에 들어 있으면 배포하든 안 하든, 감사받든 안 받든 위험합니다. 사내 전용이나 순수 SaaS의 백엔드에 있어도 공격에 노출되기 때문입니다. 그래서 취약점 점검은 거의 모든 회사에 폭넓게 필요합니다.

보안 점검을 맡는 도구는 크게 두 가지입니다.

• 의존성 단위 SCA — 선언된 오픈소스 라이브러리의 이름과 버전을 보고, 알려진 취약점(CVE) 목록과 대조합니다 D1. AI가 끌어온 라이브러리의 알려진 취약점은 여기서 잡힙니다.
• SAST(정적 분석) — 코드가 어디서 왔든, 소스 코드 자체의 위험한 작성 방식을 찾습니다. AI 코드의 주된 보안 위험이 여기 있습니다. 한 연구에서는 Copilot이 생성한 프로그램 1,689개 중 약 40%에 취약점이 있었습니다 D2.

복사해 온 코드든 AI가 만든 코드든, 보안 취약점 점검은 다른 코드와 다르지 않습니다. 코드 자체의 위험한 작성 방식은 SAST가, 가져다 쓴 라이브러리의 알려진 취약점은 의존성 SCA가 잡습니다. 스니펫 스캔은 라이선스 출처를 찾는 기능이라, 보안 점검에 쓰는 도구가 아닙니다.

한 가지 예외만 짚자면, 알려진 취약점이 있는 코드를 그대로 복사해 왔는데 SAST의 패턴에도 걸리지 않고 의존성 목록에도 없는 드문 경우입니다. 이걸 잡으려면 라이선스 출처를 찾는 스니펫 기능이 아니라, CVE 패치에서 만든 취약 코드 서명과 내 코드를 직접 대조하는 검사(취약점 코드 클론 탐지)가 필요합니다 D3. 학술 도구와 일부 상용 도구가 이를 제공합니다.

출처

A1. BakerHostetler (2025). Doe v. GitHub, Inc. — The Copilot Litigation. https://www.bakerlaw.com/the-copilot-litigation/ (접속: 2026-06-08). — Copilot 집단소송의 청구별 경과와 제9순회항소법원 계류 상태. ↩

A2. Claburn, T. (2024). Judge dismisses DMCA copyright claim in GitHub Copilot suit. The Register, 2024-07-08. https://www.theregister.com/2024/07/08/github_copilot_dmca/ (접속: 2026-06-08). — DMCA §1202(b) 청구 기각, 22개 중 2개(라이선스 위반, 계약 위반) 잔존. ↩

A3. Pearl Cohen (2024). Copyright Claims Against GitHub, Microsoft, and OpenAI Largely Dismissed. https://www.pearlcohen.com/copyright-claims-against-github-microsoft-and-openai-largely-dismissed/ (접속: 2026-06-08). — 다수 청구 기각과 잔존 청구의 전체 구도. ↩

A4. Goldstein Patent Law. Understanding the Copyright Merger Doctrine. https://www.goldsteinpatentlaw.com/copyright-merger-doctrine/ (접속: 2026-06-08). — 기능적 코드의 저작물성을 부정하는 merger doctrine. ↩

A5. NYU Journal of Intellectual Property & Entertainment Law. Clarifying the De Minimis Doctrine in Copyright Law. https://jipel.law.nyu.edu/clarifying-the-de-minimis-doctrine-in-copyright-law/ (접속: 2026-06-08). — 사소한 복제를 문제 삼지 않는 de minimis 법리. ↩

A6. OpenChain Project. OpenChain ISO/IEC 5230 — License Compliance. https://openchainproject.org/license-compliance (접속: 2026-06-08). — 표준이 프로세스와 역할을 규정하되 스니펫 스캔 같은 특정 기법을 의무화하지 않는다는 점. ↩

A7. ISO. ISO/IEC 5230:2020 — Information technology — OpenChain Specification. https://www.iso.org/standard/81039.html (접속: 2026-06-08). — 표준 원문 서지 정보. ↩

B1. Microsoft (2023-09-07). Microsoft announces new Copilot Copyright Commitment for customers. https://blogs.microsoft.com/on-the-issues/2023/09/07/copilot-copyright-commitment-ai-legal-concerns/ (접속: 2026-06-08). — 유료 상용 고객 지식재산권 면책과 내장 차단 기능 유지 조건. ↩

B2. GitHub. GitHub Copilot (제품 페이지). https://github.com/features/copilot (접속: 2026-06-08). — 공개 코드 일치 차단 설정의 존재와 동작. ↩

C1. TechTarget. AI lawsuits explained: Who’s getting sued?. https://www.techtarget.com/whatis/feature/AI-lawsuits-explained-Whos-getting-sued (접속: 2026-06-08). — 분쟁의 피고가 벤더에 집중돼 있고 도입 기업 피소 사례가 보고되지 않았다는 정황. ↩

C2. Microsoft Community Hub. Demystifying GitHub Copilot Security Controls. https://techcommunity.microsoft.com/blog/azuredevcommunityblog/demystifying-github-copilot-security-controls-easing-concerns-for-organizational/4468193 (접속: 2026-06-08). — 공개 코드 일치 차단 설정의 약 150자 일치 임계와 약 1% 복제율. ↩

C3. Mend.io. The SaaS Loophole In GPL Open Source Licenses. https://www.mend.io/blog/the-saas-loophole-in-gpl-open-source-licenses/ (접속: 2026-06-08). — 카피레프트의 배포 트리거, 사내와 SaaS 비해당, AGPL 제13조 예외. ↩

C4. Revenera. Understanding the SaaS Loophole in GPL. https://www.revenera.com/blog/software-composition-analysis/understanding-the-saas-loophole-in-gpl/ (접속: 2026-06-08). — 배포 트리거와 SaaS 예외 보강. ↩

C5. TechTarget. Microsoft Copilot Copyright Commitment explained. https://www.techtarget.com/searchenterprisedesktop/tip/Microsoft-Copilot-Copyright-Commitment-explained (접속: 2026-06-08). — 면책의 적용 범위와 조건 보강. ↩

C6. Baltes, S. & Diehl, S. (2019). Usage and Attribution of Stack Overflow Code Snippets in GitHub Projects. Empirical Software Engineering, arXiv:1802.02938. https://arxiv.org/abs/1802.02938 (접속: 2026-06-08). — GitHub 프로젝트에서 Stack Overflow 코드(CC BY-SA)를 라이선스에 맞게 사용한 비율이 최대 1.8%에 그쳤다는 실증 연구. ↩

D1. Cycode. What Is Software Composition Analysis (SCA)?. https://cycode.com/blog/what-is-software-composition-analysis-sca/ (접속: 2026-06-08). — SCA가 컴포넌트와 버전을 CVE·NVD에 대조해 취약점을 찾는 방식. ↩

D2. Pearce, H., Ahmad, B., Tan, B., Dolan-Gavitt, B., & Karri, R. (2022). Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions. IEEE S&P 2022, arXiv:2108.09293. https://arxiv.org/abs/2108.09293 (접속: 2026-06-08). — 89개 시나리오로 생성한 1,689개 프로그램 중 약 40%에 취약점. ↩

D3. Kim, S., Woo, S., Lee, H., & Oh, H. (2017). VUDDY: A Scalable Approach for Vulnerable Code Clone Discovery. IEEE S&P 2017. https://seulbae-security.github.io/pubs/vuddy-sp17.pdf (접속: 2026-06-08). — 취약점이 복사된 코드를 통해 전파되고 상류 패치 후에도 복사본이 미패치로 남는 문제와 그 탐지. ↩

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). ↩

Rockchip과 FFmpeg의 라이선스 분쟁 사례

안녕하세요.

임베디드 리눅스 업계에서 화제가 된 Rockchip과 FFmpeg의 라이선스 분쟁을 정리해 보았습니다. 2025년 12월 저장소가 내려간 시점에 처음 썼던 글인데, 그 뒤 Rockchip이 대응에 나서면서 저장소가 복구되었습니다. 경과를 반영해 전면 개정하고, 저장소가 다시 열린 덕분에 확인할 수 있게 된 실제 코드로 근거를 바꿨습니다.

이 사례는 한 기업의 실수에 그치지 않습니다. 하드웨어 벤더가 제공하는 SDK나 BSP를 그대로 가져다 쓸 때 어떤 공급망 위험이 따라오는지, 그리고 라이선스를 잘못 이해하면 간단한 시정이 어떻게 2년짜리 과제로 부풀어 오르는지를 함께 보여줍니다.

1. 사건 개요

2025년 12월, Rockchip의 GitHub 저장소 rockchip-linux/mpp(Media Process Platform)가 비활성화되었습니다. FFmpeg 기여자가 제출한 DMCA(Digital Millennium Copyright Act) 테이크다운 통지에 따른 조치였습니다.

Rockchip은 자사 칩셋(RK3588 등)의 하드웨어 영상 가속을 위해 mpp라는 미들웨어 라이브러리를 제공해 왔습니다. 문제는 이 라이브러리의 스트림 헤더 파서 코드가 FFmpeg의 libavcodec에서 왔다는 것입니다. 단순히 가져다 쓴 것이 문제가 아니라, 세 가지 행위가 겹치면서 컴플라이언스 위반이 되었습니다. 원본의 저작권 고지를 삭제했고, Rockchip이 저작자인 것처럼 헤더를 바꿨으며, LGPL 2.1이던 코드를 Apache-2.0으로 재배포했습니다.

통지서는 이 세 가지를 그대로 적시하면서, 침해 근거로 “코드 구조와 동일한 주석에서 분명히 드러나며, 원래 이름 그대로 주석 처리된 FFmpeg 내부 함수 호출까지 있다"고 밝혔습니다.

경과

그림 1. 분쟁 경과 (출처: DMCA 통지서, MPP 커밋 이력, 이슈 530·73, Internet Archive. 2026-07-23 확인)

저장소가 다시 열린 정확한 날짜는 공개되지 않았습니다. Internet Archive 스냅샷이 2026년 3월 6일까지 HTTP 451(법적 사유로 이용 불가)을 반환하다가, 3월 11일부터 새 포크가 생기기 시작한 것으로 미루어 그 사이로 봅니다. 비활성 기간은 약 10주입니다.

DMCA에 대해 한 가지 짚어둘 것이 있습니다. 통지가 들어오면 정해진 시간 안에 차단해야 한다는 설명이 흔히 돌아다니지만, 미국 저작권법 17 U.S.C. §512(c)(1)(C)에는 “신속히”(expeditiously)라는 표현만 있고 구체적 시한은 없습니다. GitHub은 운영 정책으로 파일을 특정한 통지의 경우 저장소 소유자에게 약 1영업일의 자체 수정 기회를 준 뒤 차단합니다.

2. 무엇이 복사되었나

통지서는 침해 파일 12개를 지목했습니다. AV1 관련 4개, H.265 관련 3개, VP9 관련 5개입니다. 저장소가 복구되면서 침해 지목 시점의 커밋을 직접 받아 FFmpeg 원본과 맞춰볼 수 있게 되었습니다. 아래는 그 대조 결과입니다.

저작권 헤더 교체

FFmpeg libavcodec/vpx_rac.h의 헤더입니다.

/*
 * Copyright (C) 2006  Aurelien Jacobs <aurel@gnuage.org>
 *
 * This file is part of FFmpeg.
 *
 * FFmpeg is free software; you can redistribute it and/or
 * modify it under the terms of the GNU Lesser General Public
 * License as published by the Free Software Foundation; either
 * version 2.1 of the License, or (at your option) any later version.
...
*/

MPP mpp/codec/dec/vp9/vpx_rac.h의 같은 자리입니다.

/*
*
* Copyright 2015 Rockchip Electronics Co. LTD
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
...
*/

원저작자 Aurelien Jacobs의 이름, LGPL 조항, FFmpeg 언급이 모두 사라지고 Rockchip 명의의 Apache-2.0 헤더로 바뀌었습니다. vpx_rac.c의 원저작자 Fiona Glaser, vp9data.h의 원저작자 Ronald S. Bultje와 Clément Bœsch도 마찬가지로 자취를 감췄습니다.

함수 본문의 일치

VP9 범위 부호기(Range Coder)의 핵심 함수를 비교해 보겠습니다.

FFmpeg libavcodec/vpx_rac.h:

static av_always_inline int vpx_rac_get_prob(VPXRangeCoder *c, uint8_t prob)
{
    unsigned int code_word = vpx_rac_renorm(c);
    unsigned int low = 1 + (((c->high - 1) * prob) >> 8);
    unsigned int low_shift = low << 16;
    int bit = code_word >= low_shift;

    c->high = bit ? c->high - low : low;
    c->code_word = bit ? code_word - low_shift : code_word;

    return bit;
}

MPP mpp/codec/dec/vp9/vpx_rac.c(침해 지목 당시 커밋 14667441):

rk_s32 vpx_rac_get_prob(VpxRangeCoder *c, uint8_t prob)
{
    unsigned int code_word = vpx_rac_renorm(c);
    unsigned int low = 1 + (((c->high - 1) * prob) >> 8);
    unsigned int low_shift = low << 16;
    int bit = code_word >= low_shift;

    c->high = bit ? c->high - low : low;
    c->code_word = bit ? code_word - low_shift : code_word;

    return bit;
}

인라인 지정자를 떼고 반환 타입을 int에서 rk_s32로 바꾼 것이 전부입니다. 본문은 공백까지 같고, 매개변수의 uint8_t와 본문의 unsigned int는 FFmpeg 표기 그대로 남았습니다.

코드에 남은 흔적

기능과 무관한 주석이야말로 출처를 드러냅니다. MPP 파일에는 다음 주석들이 그대로 있었습니다.

// branchy variant, to be used where there's a branch based on the bit decoded
// rounding is different than vpx_rac_get, is vpx_rac_get wrong?

앞의 것은 FFmpeg vpx_rac.h와 완전히 일치합니다. 뒤의 것은 FFmpeg 개발자가 스스로에게 던진 질문인데, 원문은 vp56_rac_get을 가리키고 MPP는 함수 이름만 자기 표기로 바꿔 옮겼습니다. 이런 자문형 주석이 독립적으로 작성한 코드에 우연히 같은 문장으로 등장할 수는 없습니다.

파일 상단에는 MPP가 지원하지도 않는 코덱을 가리키는 설명이 남아 있었습니다.

/**
 * vp56 specific range coder implementation
 */

FFmpeg에서는 이 파일이 VP5부터 VP9까지 공용으로 쓰이기 때문에 붙은 설명인데, VP5나 VP6를 다루지 않는 MPP로 그대로 따라온 것입니다. 정렬 매크로를 아무 일도 하지 않도록 재정의해 둔 자리도 있습니다.

#define DECLARE_ALIGNED(n,t,v)      t v

이 매크로 이름은 FFmpeg에도 libvpx에도 있어 그 자체로는 출처가 되지 못합니다. 다만 쓰는 자리가 FFmpeg를 그대로 따라갑니다. FFmpeg vp56.h의 움직임 벡터 구조체가 첫 필드를 DECLARE_ALIGNED(4, int16_t, x);로 선언하는데, MPP의 대응 구조체가 이 줄을 그대로 갖고 있습니다. libvpx의 같은 구조체에는 이 매크로가 쓰이지 않습니다.

이 정도 일치는 저작권법의 실질적 유사성(substantial similarity) 판단을 통과하기 어렵습니다. 타입명이나 매크로를 바꾸는 것만으로는 독립 저작물이 되지 않습니다. 사내 코드베이스에 외부 오픈소스를 흡수할 때 이런 방식을 쓰는 경우가 있는데, 이번 사례가 그 위험을 그대로 보여줍니다.

확률 테이블은 조금 다른 문제입니다

한편 코덱의 확률 테이블은 성급하게 판단하면 안 되는 영역입니다. 이 수치들은 VP9 비트스트림 사양에 정의된 상수이고, 값 옆에 붙은 /* a/l both not split */ 같은 주석도 FFmpeg가 만든 표현이 아닙니다. VP9 참조 구현인 libvpx(Google, BSD 계열)에 같은 문구가 이미 들어 있습니다. FFmpeg 역시 libvpx에서 받아온 것으로 보아야 합니다.

그래서 주석이 같다는 사실만으로는 어디서 가져왔는지 말할 수 없습니다. 세 코드를 나란히 놓으면 갈라지는 지점은 문구가 아니라 서식입니다.

libvpx:

      { 222, 34, 30 },  // a/l both not split

FFmpeg:

            { 222,  34,  30 } /* a/l both not split */,

libvpx는 쉼표를 찍고 // 주석을 붙이지만, FFmpeg는 /* */ 주석을 쉼표 앞에 넣고 숫자를 두 칸으로 정렬합니다. MPP 쪽은 FFmpeg 형태와 바이트 단위로 같습니다. 값과 문구는 libvpx까지 거슬러 올라가되, 실제로 복사한 대상은 FFmpeg 판본이었다고 보는 편이 서식에 맞습니다.

이런 구별이 필요한 이유는 분명합니다. 같은 알고리즘을 구현하면 코드가 비슷해지는 것이 자연스러운 영역에서는 유사성 자체가 침해의 근거가 되지 못합니다. 어느 판본의 어떤 흔적을 따랐는지까지 짚어야 합니다.

3. 왜 22개월이 걸렸나

이 사건에서 가장 배울 점이 많은 대목입니다. 문제가 처음 공개된 것은 2024년 2월 23일입니다. FFmpeg 공식 계정이 X에 지적을 올렸고, 같은 날 ffmpeg-rockchip 포크를 관리하는 개발자가 MPP 저장소에 이슈 530을 열어 전달했습니다. DMCA까지는 그로부터 22개월이 걸렸습니다.

흔히 알려진 것과 달리 Rockchip이 침묵한 것은 아닙니다. 담당자는 2024년 2월 공개 사과를 했고, 그 뒤로도 “지연되고 있다”, “진행 중이다”, “리팩터링은 보류 상태다"라고 계속 답했습니다. 응답은 했으나 시정하지 않은 사안입니다.

지연의 이유는 Rockchip이 나중에 밝혔습니다.

But after studying the license details, we realised that simply restoring
the LGPL headers would convert the entire MPP library to LGPL-licensed code.
While this is acceptable for dynamically linked libraries, it would mandate
that any project statically linking MPP also adopt the LGPL license.
To avoid this mixed-license scenario, we decided to develop a brand-new parser.

LGPL 헤더를 되돌리면 MPP 전체가 LGPL이 되고, MPP를 정적 링크하는 고객 프로젝트까지 LGPL을 따라야 한다고 판단한 것입니다. 그 상황을 피하려고 파서를 새로 만들기로 했는데, 작업량을 과소평가했고 일상 업무에 밀려 진척이 멈췄습니다.

이 판단은 절반만 맞습니다. 앞부분은 근거가 있습니다. MPP에 FFmpeg 코드를 통합했다면 MPP는 LGPL 2.1이 말하는 “라이브러리에 기반한 저작물"이 되고, Section 2(c)가 저작물 전체를 이 라이선스 조건으로 제공하도록 요구합니다.

뒷부분은 다릅니다. Section 6은 정적 링크를 포함한 결합 저작물에 예외를 둡니다.

6. As an exception to the Sections above, you may also combine or
link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work
under terms of your choice, ...

결합 저작물은 원하는 조건으로 배포할 수 있습니다. 고객이 자기 용도로 수정할 수 있게 하고, 디버깅을 위한 리버스 엔지니어링을 허용하며, 재링크가 가능한 형태를 제공하거나 공유 라이브러리 방식을 쓰는 것이 조건입니다. MPP를 정적 링크하는 고객사가 자기 제품을 LGPL로 공개해야 하는 것이 아닙니다.

라이선스 조항을 잘못 읽은 탓에 헤더 복원이면 끝날 일이 파서 전면 재작성이라는 과제로 부풀었고, 그 과제가 무거워서 2년 가까이 방치되었습니다. 그사이에도 위반 상태의 배포는 계속되었습니다. 컴플라이언스 판단이 틀리면 비용이 이런 식으로 불어납니다.

4. Rockchip의 대응과 남은 문제

DMCA 이후 Rockchip은 빠르게 움직였습니다. 통지 열흘 남짓 만에 지목된 12개 파일의 LGPL 헤더를 복원했고, 이어서 VP9, AV1, H.265 파서를 차례로 교체했습니다. 2026년 2월 중순에는 “FFmpeg LGPL 코드를 전부 제거했다"고 밝히며 검토를 요청했습니다.

실제로 상당 부분이 이행되었습니다. 지목된 12개 중 8개가 저장소에서 사라졌고, 범위 부호기는 함수 이름과 구조가 모두 다른 구현으로 바뀌었습니다. 저장소 전체 소스 778개 파일을 훑어 ff_vp9_, av_always_inline, AVCodecContext, libavcodec 같은 FFmpeg 고유 식별자를 찾아봤지만 하나도 나오지 않았습니다. LGPL을 언급하는 소스 파일도 없습니다. 변경 이력 문서에 복원 커밋의 제목이 남아 있는 것이 전부입니다.

다만 몇 가지가 남습니다.

지목된 vp9data.h는 삭제된 것이 아니라 vp9d_codec.c로 이름이 바뀌었습니다. 커밋 기록에서 이 파일의 상태는 삭제가 아니라 이름 변경으로 표시됩니다. 그 과정에서 헤더가 다시 바뀌었습니다. LGPL 복원 커밋이 넣었던 FFmpeg 저작권 표시와 LGPL 조항이 제거되고 Rockchip 단독 저작권에 Apache-2.0 표기로 돌아갔습니다. 두 커밋의 작성 시각은 같은 날 세 시간 차이입니다. 내용은 1,299줄 가운데 1,045줄이 그대로이고, 확률 테이블과 주석도 앞서 본 FFmpeg 서식 그대로 남아 있습니다.

통지서에 나열되지 않은 파일은 손대지 않았습니다. 하드웨어 추상화 계층의 hal_vp9d_com.c에는 앞서 본 VP9 확률 테이블이 FFmpeg 서식 그대로 남아 있습니다. 통지서가 파일 목록 앞에 “(and possibly others)“라는 단서를 달아 둔 부분이 실제로 들어맞은 셈입니다.

이 부분이 침해에 해당하는지는 단정하기 어렵습니다. 값과 주석 문구는 libvpx와 사양 문서까지 거슬러 올라가므로 저작권 보호 범위 자체가 다툼의 대상입니다.

무엇보다 FFmpeg 측이 이 상태를 검토했거나 수용했다는 공개 기록이 없습니다. 이슈 530은 2026년 4월 1일에 닫혔지만, 닫은 사람은 FFmpeg 프로젝트가 아니라 이슈를 열었던 제3자 포크 관리자입니다. 권리자의 면책과는 다릅니다. 이미 배포된 과거 버전에 대한 처리 방침도 어느 쪽에서도 나오지 않았습니다.

5. 라이선스 세탁이 위험한 이유

“Apache-2.0으로 공개된 코드는 안전하다"고 생각하기 쉽습니다. 이번 사례는 저작권 출처가 불투명한 Apache-2.0 코드가 오히려 더 큰 위험이 될 수 있음을 보여줍니다. 표기된 라이선스가 아니라 실제 코드의 출처가 의무를 결정하기 때문입니다.

위반 행위별로 어떤 조항에 걸리는지 정리하면 이렇습니다.

저작자 표시를 허위로 바꾼 행위는 나라에 따라 다르게 다뤄집니다. 한국과 프랑스에서는 저작인격권 중 성명표시권 침해가 성립합니다. 미국 저작권법에는 일반적 저작인격권이 없고, 시각예술저작물권리법(VARA)이 시각예술에 한정해 적용될 뿐입니다.

올바른 구조는 어떤 모습인가

리눅스 커널은 하드웨어 가속을 위해 V4L2(Video for Linux 2)라는 표준 인터페이스를 제공합니다. FFmpeg는 사용자 공간에 수정 없이 두고, 하드웨어 의존 코드는 커널 드라이버로 분리하는 구조입니다.

그림 2. 하드웨어 가속 연동 구조 비교

FFmpeg와 커널 드라이버가 사용자 공간과 커널 공간으로 명확히 나뉘므로, 벤더가 FFmpeg 코드 자체를 뜯어고쳐 배포할 이유가 사라집니다.

이 방향의 진전은 Rockchip이 아니라 Collabora가 이끌었습니다. RK3588의 VDPU381과 RK3576의 VDPU383 디코더 지원이 2026년 2월 메인라인에 병합되어 리눅스 7.0(2026년 4월)에 들어갔습니다. 현재 범위는 H.264와 H.265이며, AV1과 VP9, 멀티코어 디코딩은 후속 과제로 남아 있습니다.

한 가지 주의할 점이 있습니다. Rockchip 하드웨어를 쓰는 개발자들이 흔히 대안으로 거론하는 nyanmisaka/ffmpeg-rockchip 포크는 MPP를 대체하지 않습니다. 이 프로젝트는 MPP와 librga를 호출해 하드웨어 가속을 구현하는 FFmpeg 포크이므로, MPP의 출처 문제를 피해 가지 못합니다. MPP 의존을 벗어나려면 메인라인 V4L2 경로를 써야 합니다.

6. 10년 전 Allwinner 사례

임베디드 칩 벤더가 멀티미디어 코덱 라이선스에서 같은 실수를 반복해 온 역사가 있습니다. 가장 가까운 선례는 2015년 Allwinner의 CedarX입니다.

Allwinner는 2015년 3월 “LGPL 공개"를 내놓았지만 실제로는 폐쇄 바이너리를 감싼 API 계층에 그쳤습니다. 실질적인 결말은 커뮤니티가 리버스 엔지니어링으로 만든 Cedrus 드라이버가 메인라인에 편입된 것이었습니다. 이번 Rockchip 사례에서 V4L2 드라이버 작업이 Collabora 주도로 진행된 것과 구조가 비슷합니다.

라이선스 위반이 실제 금전적 책임으로 이어진 사례도 있습니다. 파리 항소법원은 2024년 2월 14일 Entr’ouvert가 Orange를 상대로 낸 소송에서 배상 80만 유로를 명했습니다. 재산적 손해 50만 유로, 저작인격권 침해 15만 유로, 부당이득 반환 15만 유로이고, 여기에 소송비용 6만 유로가 별도로 더해졌습니다. 2011년 제소 이후 1심과 항소심, 대법원 파기환송을 거쳐 13년 만에 나온 결론이었습니다. 이 판결이 중요한 이유는 오픈소스 라이선스 위반을 계약 위반이 아니라 저작권 침해로 판단했다는 점입니다.

독일에서는 함부르크 지방법원이 2013년 Fantec 사건에서 “공급자가 라이선스를 준수한다고 확약했다는 이유만으로는 면책되지 않으며, 배포자가 스스로 확인해야 한다"고 판시했습니다. SoC 벤더에게서 BSP를 받아 제품에 넣는 기업이라면 그대로 적용되는 이야기입니다.

7. 기업이 점검할 것

벤더가 제공한 SDK나 BSP에 같은 문제가 숨어 있을 수 있습니다. 세 가지를 확인하시기 바랍니다.

첫째, 공급망 라이선스 감사입니다. 벤더가 준 라이브러리가, 특히 멀티미디어나 그래픽, AI 가속 관련 코드가 원저작자의 라이선스를 유지하고 있는지 확인해야 합니다. 벤더가 Apache-2.0이나 MIT를 주장하더라도 내부 코드가 GPL이나 LGPL 프로젝트에서 왔다면 제품 전체가 위험에 노출됩니다. Black Duck이나 FOSSID 같은 소스 코드 분석 도구로 벤더 제공 코드를 스캔하면 내부에 남은 원본 라이선스 고지나 저작권 표시를 찾아낼 수 있습니다. 이번 사례에서 보듯 결정적 단서는 기능과 무관한 주석에 남는 경우가 많습니다.

둘째, 벤더 드라이버가 메인라인 커널에 올라가 있는지 확인하십시오. 메인라인에 병합된 코드는 여러 개발자의 리뷰와 라이선스 검토를 거친 것이라 벤더가 자체 운영하는 저장소보다 신뢰도가 높습니다. 다만 메인라인화 여부와 기능 완성도는 별개이므로 지원 범위를 함께 확인해야 합니다.

셋째, 사내 개발 규칙입니다. 외부 오픈소스를 가져올 때 파일 상단의 저작권 헤더를 지우거나 회사 명의로 바꿔 커밋하는 행위는 허용해서는 안 됩니다. 고의적 침해로 볼 여지가 있고 이후 분쟁에서 불리한 증거가 됩니다. 통합이 필요하다면 링크 방식을 우선하고, 원저작자의 라이선스와 저작권 표시는 반드시 유지하는 것을 표준으로 삼으십시오.

요약

Rockchip 사례는 소스를 공개하는 것과 오픈소스 라이선스를 준수하는 것이 서로 다른 문제임을 보여줍니다. LGPL 코드는 저작권자 동의 없이 Apache-2.0 같은 다른 라이선스로 바꿀 수 없고, 저작권 고지 삭제와 저작자 표시 변경은 그 자체로 침해입니다.

더 실무적인 교훈은 지연의 경위 쪽에 있습니다. 라이선스 조항을 잘못 읽은 탓에 헤더 복원으로 끝날 일이 파서 전면 재작성이라는 과제가 되었고, 그 무게 때문에 2년 가까이 방치되었습니다. 라이선스 판단은 법무나 컴플라이언스 조직과 함께 내려야 하고, 시정 비용이 커 보일수록 그 판단이 맞는지 다시 확인해야 합니다.

벤더가 준 소프트웨어를 그대로 신뢰하기보다는, 소스 코드 분석 도구로 어떤 라이선스와 저작권 고지가 들어 있는지 주기적으로 확인하고, 그 결과를 근거로 벤더와 책임 범위를 정리하는 절차를 갖추는 것이 필요합니다.

참고 자료

• FFmpeg DMCA Notice on GitHub (2025-12-18)
• rockchip-linux/mpp Issue #530 — LGPL license violation reported by upstream FFmpeg
• HermanChen/mpp Issue #73 — Rockchip 측 공식 해명
• rockchip-linux/mpp 저장소
• GNU LGPL 2.1 원문
• 17 U.S.C. §512 (Cornell LII)
• Hackaday: GitHub Disables Rockchip’s Linux MPP Repository After DMCA Request
• Tom’s Hardware: Rockchip Repository Disabled
• Collabora: RK3588 and RK3576 video decoders support merged in the upstream Linux Kernel
• libvpx (VP9 참조 구현)
• CNX Software: Allwinner’s CedarX May Infringe on Open Source Licenses (2015-02-26)
• CNX Software: Allwinner CedarX GPL/LGPL Compliance Update (2015-03-23)
• nyanmisaka/ffmpeg-rockchip

2026년 7월 23일 후속 경과를 반영해 개정했습니다.