2026

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

미국 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 코딩은 조건이 성립할 때 유입량을 늘리는 요인이지, 조건을 만드는 요인은 아닙니다.

회사 조건별로 본다면

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

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

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

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

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

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

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

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

판단을 위한 기준

이 판단이 간단하지 않은 데는 이유가 있습니다. 패키지로 선언되지 않은 채 복사되거나 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-2026) 사례를 정리해 보았습니다. 이 사례는 단순히 한 기업의 실수가 아니라, 하드웨어 벤더(SoC Vendor)가 제공하는 SDK/BSP를 그대로 사용할 때 발생할 수 있는 공급망 리스크를 보여줍니다.

1. 사건 개요: 2025년 GitHub 리포지토리 강제 중단

2025년 12월, 중국의 대표적인 반도체 기업 Rockchip의 GitHub 리포지토리 중 하나인 rockchip-linux/mpp (Media Process Platform)를 GitHub가 비활성화(disabled)하는 사건이 발생했습니다. 이는 FFmpeg 개발자가 제출한 DMCA(Digital Millennium Copyright Act) Takedown 요청에 따른 조치였습니다.

무엇이 문제였나?

Rockchip은 자사 칩셋(RK3588 등)의 하드웨어 영상 가속을 위해 mpp라는 미들웨어 라이브러리를 제공해 왔습니다. 문제는 이 라이브러리의 소스 코드 중 상당 부분이 FFmpeg의 libavcodec (특히 H.265, AV1, VP9 디코더 관련 코드 수천 줄)을 그대로 복사한 것으로 FFmpeg 측은 주장했습니다.

단순 복사가 문제가 된 것이 아니라, 다음 세 가지 행위가 결합되어 치명적인 컴플라이언스 위반이 되었습니다.

1. 저작권 고지 삭제: 원본 코드(FFmpeg)에 있던 저작권자·저작권 표시를 제거함.
2. 저작자 허위 주장: Rockchip이 해당 코드의 저작자인 것처럼 코멘트·헤더를 변경함.
3. 라이선스 변경: 원래 LGPL 2.1인 코드를 Apache 2.0 라이선스로 재배포함.

FFmpeg 커뮤니티는 2024년 2월 23일 GitHub Issue #530을 통해 이 문제를 공개적으로 제기하며 측면-by-측면(Side-by-Side) 코드 비교 증거까지 첨부했습니다. 그러나 Rockchip은 22개월간 사실상 묵묵부답이었고, 결국 법적 수단인 DMCA Takedown으로 이어졌습니다.

참고: DMCA Takedown이란?
DMCA Takedown의 특성상, 실제 침해 여부가 법원에서 확정되기 전이라도, 호스팅 플랫폼(GitHub)은 요청 접수 후 24~72시간 내에 콘텐츠를 차단해야 합니다. Rockchip MPP 리포지토리는 현재도 비활성화 상태로 남아 있습니다.

2. 코드 레벨 침해 분석: 무엇이 복사되었나?

침해 대상 파일 목록

DMCA 공지(2025-12-18)에는 침해된 파일이 명시되어 있습니다. 아래는 보고된 주요 침해 파일과 FFmpeg 원본 파일의 대응 관계입니다.

침해 패턴 1: 저작권 헤더 교체

가장 직접적인 증거는 파일 상단의 저작권 헤더(Copyright Header)입니다.
FFmpeg의 원본 헤더를 삭제하고 Rockchip 명의로 교체하는 방식으로 이루어졌습니다.

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.
 */

Rockchip MPP (mpp/codec/dec/vp9/vpx_rac.h) — 교체 후:

/*
 * Copyright 2022 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.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 */

저작권자 이름(Aurelien Jacobs), LGPL 2.1 조항, FFmpeg 언급이 사라지고 Rockchip 명의의 Apache-2.0 헤더로 대체되었습니다.

침해 패턴 2: 코드 내부에 남겨진 FFmpeg 흔적

헤더만 바꾸었을 뿐, 코드 내부 로직에는 FFmpeg 함수명이 주석이나 참조 형태로 그대로 남아 있었습니다. DMCA 공지는 이 점을 다음과 같이 명시합니다.

“the code’s origin is evident from identical structures, comments, and even commented-out calls referencing FFmpeg functions by their original names.”

// Rockchip MPP 코드 내부에서 발견된 FFmpeg 흔적 패턴 (보고된 내용 기반)

// ff_hevc_decode_nal_vps 와 동일 구조 참조
static int h265d_decode_nal_vps(H265dContext *s, ...) {
    // ff_get_buffer 대신 mpp_buffer_get 사용
    // av_log → mpp_log 로 교체
    ...
}

• ff_로 시작하는 FFmpeg 고유 함수명이 주석에 잔류
• av_log, av_malloc, AVCodecContext 등 FFmpeg 전용 타입·함수가
  Rockchip 자체 API로 교체되었지만, 교체 흔적(주석)이 코드에 남아 있음

침해 패턴 3: 구조·알고리즘의 완전 일치

아래는 vpx_rac.c (VP9 Range Arithmetic Coder)의 핵심 함수 구조 비교입니다.
이 수준의 일치는 수동 재구현(독립 저작)으로는 나오기 어렵다는 것이 커뮤니티의 공통된 평가입니다.

FFmpeg libavcodec/vpx_rac.c:

static av_always_inline int vpx_rac_get_prob(VPXRangeCoder *c, uint8_t prob)
{
    unsigned int split = (c->range * prob + (256 - prob)) >> 8;
    if (c->value < split) {
        c->range = split;
        return 0;
    } else {
        c->value -= split;
        c->range -= split;
        return 1;
    }
}

Rockchip MPP mpp/codec/dec/vp9/vpx_rac.c (보고된 구조 기반):

static MPP_INLINE RK_S32 vpx_rac_get_prob(VPXRangeCoder *c, RK_U8 prob)
{
    RK_U32 split = (c->range * prob + (256 - prob)) >> 8;
    if (c->value < split) {
        c->range = split;
        return 0;
    } else {
        c->value -= split;
        c->range -= split;
        return 1;
    }
}

변경된 것은 딱 두 가지입니다.

• av_always_inline을 MPP_INLINE(Rockchip 자체 매크로)로 교체
• uint8_t, unsigned int를 RK_U8, RK_U32(Rockchip 자체 타입 정의)로 교체

알고리즘 로직, 변수명, 연산 순서, 비트 연산 방식은 완전히 동일합니다.

법적 시사점: “타입을 바꾼다고 새 코드로 인정되지는 않는다”
이 수준의 수정은 저작권법의 “실질적 유사성(Substantial Similarity)” 평가를 통과하지 못합니다. 알고리즘 구조와 표현이 동일한 경우, 타입명·매크로 치환만으로는 독립 저작물로 인정받을 수 없습니다. 사내 코드베이스에 외부 오픈소스를 “내재화"할 때 이와 같은 방식을 사용하는 경우가 있는데, 이번 사례는 그 위험성을 명확히 보여줍니다.

3가지 침해 행위 요약

flowchart TD
    A["FFmpeg libavcodec(LGPL 2.1)"] -->|"1. 복사(Copy-paste)"| B["Rockchip MPP 내부 파일"]
    B -->|"2. 헤더 교체"| C["저작권 고지 삭제→ Rockchip 명의로 변경"]
    B -->|"3. 재라이선싱"| D["LGPL 2.1 제거→ Apache-2.0 적용"]
    C --> E["GitHub에 공개 배포"]
    D --> E
    style A fill:#ccffcc,stroke:#333
    style E fill:#ffcccc,stroke:#333

3. 왜 ‘라이선스 세탁’이 위험한가?

많은 기업 담당자들이 “Apache 2.0으로 공개된 코드는 안전하다"고 생각하기 쉽습니다.
하지만 이번 사례는 저작권 출처가 불투명한 Apache 2.0 코드가 오히려 큰 법적 리스크가 될 수 있음을 보여줍니다.

Rockchip의 잘못된 접근 방식

flowchart TD
    UserApp[User Application] --> FFmpeg_Fork
    FFmpeg_Fork[Modified FFmpeg - Non-compliant] -- Static Link / Direct Copy --> Rockchip_MPP[Rockchip MPP Library]
    Rockchip_MPP --> Hardware[Rockchip VPU Hardware]
    
    subgraph "License Violation Area"
        FFmpeg_Fork
        Rockchip_MPP
    end

    style FFmpeg_Fork fill:#ffcccc,stroke:#333,stroke-width:2px
    style Rockchip_MPP fill:#ffcccc,stroke:#333,stroke-width:2px

• LGPL 코드를 가져와 수정한 경우, 해당 파생 저작물은 LGPL(또는 양립 가능한 GPL)로 배포해야 합니다.
• 원저작자의 저작권 고지와 라이선스를 삭제하거나, 자신 명의로 바꾸어서는 안 됩니다.

올바른 접근 방식: V4L2 표준 준수

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

flowchart TD
    UserApp[User Application] --> Upstream_FFmpeg
    Upstream_FFmpeg[Upstream FFmpeg - LGPL] -- Standard IOCTL --> V4L2_API[Linux Kernel V4L2 API]
    V4L2_API --> Kernel_Driver[Rockchip Kernel Driver - GPL]
    Kernel_Driver --> Hardware[Rockchip VPU Hardware]

    subgraph "License Compliant Area"
        Upstream_FFmpeg
        Kernel_Driver
    end

    style Upstream_FFmpeg fill:#ccffcc,stroke:#333,stroke-width:2px
    style Kernel_Driver fill:#ccffcc,stroke:#333,stroke-width:2px

• FFmpeg를 수정 없이 사용하고, 하드웨어 가속은 커널의 표준 인터페이스(V4L2 M2M)를 통해 호출합니다.
• FFmpeg와 커널 드라이버가 명확한 User/Kernel 경계로 분리되므로, FFmpeg 코드 자체를 벤더가 뜯어고쳐 배포할 필요가 사라집니다.

현재 커뮤니티는 Rockchip의 mpp 사용자 공간 스택을 걷어내고, 메인라인 리눅스 커널의 V4L2 드라이버 기반으로 전환하려는 움직임을 보이고 있습니다. 당장 Rockchip 하드웨어를 사용하는 개발자라면, 올바른 라이선스로 배포되는 nyanmisaka/ffmpeg-rockchip 포크를 대안으로 고려할 수 있습니다.

4. 과거 사례와의 비교: Allwinner CedarX (2015)

이번 사건은 10년 전 Allwinner 사태와도 매우 유사합니다. 역사적으로 여러 임베디드 칩 벤더들이 멀티미디어 코덱 라이선스 문제에서 반복해서 같은 실수를 저질러 왔습니다.

Allwinner 사례에서도 CedarX 라이브러리 내부에 FFmpeg libavcodec 코드가 섞여 있는 것이 확인되었고, LGPL 의무에 따라 소스를 공개해야 한다는 지적이 있었습니다. Rockchip MPP는 “바이너리 블롭"이 아닌 “공개 소스” 형태였지만, 공개된 코드 안에서 그대로 드러난 위반이라는 점에서 오히려 더 명확하게 문제가 되었습니다.

집행 사례 선례: 2024년 2월, 파리 법원은 Orange의 GPL 위반으로 인해 Entr’ouvert사에 약 86만 유로(약 10억 원)를 배상하라고 판결했습니다. 이는 GPL/LGPL 위반이 실제 법적·재정적 결과로 이어진다는 것을 보여주는 중요한 선례입니다.

5. 기업을 위한 Action Item

여러분이 사용하는 SoC 벤더의 SDK나 BSP가 이와 같은 문제를 안고 있을 수 있습니다.
다음 세 가지 항목을 반드시 점검하십시오.

1) 공급망(Supply Chain) 라이선스 감사

• 벤더가 제공한 “오픈소스” 라이브러리(특히 멀티미디어, 그래픽, AI 가속 관련)가 실제 원저작자의 라이선스를 그대로 유지하고 있는지 확인해야 합니다.
• 벤더가 Apache 2.0이나 MIT 등 “안전해 보이는” 라이선스를 주장하더라도, 내부 코드가 FFmpeg이나 다른 GPL/LGPL 프로젝트에서 복사된 것이라면, 제품 전체가 법적 위험에 노출됩니다.
• Black Duck, FOSSID 등의 소스 코드 분석 도구로 벤더 제공 코드를 스캔하면, 내부에 남아 있는 원본 라이선스 고지나 저작권 표시를 찾아낼 수 있습니다.

2) ‘Upstream First’ 정책 확인

• 벤더가 제공하는 드라이버가 리눅스 메인라인 커널(Upstream)에 병합되어 있는지 확인하십시오.
• 메인라인에 병합된 코드는 전 세계 개발자가 코드 리뷰와 라이선스 검토를 거친 것이므로, 벤더가 자체적으로 운영하는 GitHub 리포지토리보다 상대적으로 신뢰도가 높습니다.

3) 내부 개발팀 가이드: “복사 붙여넣기” 금지

• 사내 개발자가 외부 오픈소스 코드를 가져올 때, 파일 상단의 저작권 헤더를 삭제하거나 회사 명의로 바꿔서 커밋하는 행위는 절대 허용해서는 안 됩니다. 이는 고의적인 저작권 침해로 간주될 수 있으며, 이후 분쟁에서 치명적인 증거가 됩니다.
• 코드 통합이 필요한 경우, 가능한 한 라이브러리 링크 방식으로 사용하고, 원저작자의 라이선스와 저작권 표시는 반드시 유지하는 것을 표준으로 삼으십시오.

요약

Rockchip 사례는 “소스 코드를 공개하는 것"과 “오픈소스 라이선스를 준수하는 것"이 전혀 다른 문제임을 명확히 보여줍니다. LGPL 코드는 저작권자 동의 없이 Apache 2.0 등 다른 라이선스로 재라이선싱할 수 없으며, 저작권 고지 삭제와 저작자 위조는 그 자체로 심각한 침해 행위입니다.

SoC 벤더가 제공하는 소프트웨어를 그대로 신뢰하기보다는, Black Duck, FOSSID 등의 소스 코드 분석 도구를 활용해 벤더 제공 코드 안에 어떤 라이선스와 저작권 고지가 포함되어 있는지를 주기적으로 스캔하고, 결과를 바탕으로 벤더와 책임 범위를 명확히 하는 프로세스를 구축하는 것이 필요합니다.

참고 자료

• FFmpeg DMCA Notice on GitHub (2025-12-18)
• Hackaday: GitHub Disables Rockchip’s Linux MPP Repository After DMCA Request
• Byteiota: FFmpeg Files DMCA Against Rockchip
• Tom’s Hardware: Rockchip Repository Disabled
• CNX Software: Allwinner CedarX May Infringe on Open Source Licenses (2015)
• linux-sunxi.org: GPL Violations
• nyanmisaka/ffmpeg-rockchip (라이선스 준수 대안)