삼성·LG 협력사를 위한 EU CRA 대응 전략: 스마트 가전·TV·IoT 부품 공급업체가 알아야 할 7가지 계약 요구사항

삼성전자와 LG전자는 EU 스마트 TV와 커넥티드 가전 시장에서 상당한 점유율을 확보한 브랜드 제조업체입니다. 두 회사 모두 자체적으로 CRA 의무를 내부에서 처리할 역량이 있습니다. 그러나 두 회사 어느 쪽도 자사 공급망 전체를 대신 인증할 수는 없습니다.

이 구조가 한국 협력사에 의미하는 바는 분명합니다. 삼성과 LG는 EU 시장에 제품을 출시하기 위해, 부품과 펌웨어를 공급하는 ODM·모듈·반도체 협력사에 CRA 대응 조건을 계약서에 반영하기 시작합니다. EU 규제가 한국 협력사에 먼저 도달하는 경로는 규제 당국이 아니라 구매 계약입니다. 이 가이드는 삼성·LG 생태계의 한국 협력사가 2027년 12월 11일 전면 적용일 이전에 실제로 준비해야 할 계약 조항과 기술 역량을 다룹니다.

삼성·LG가 협력사에 CRA 요건을 요구하기 시작하는 시점

CRA 전면 적용일은 2027년 12월 11일입니다. 그러나 EU 브랜드 제조업체가 협력사 계약에 CRA 조건을 반영하는 실제 시점은 이보다 앞섭니다.

시간표를 구체적으로 보면 다음과 같습니다.

• 2026년 9월 11일: CRA 제14조에 따른 ENISA 신고 의무가 발효됩니다. 삼성·LG가 24시간 이내에 ENISA에 조기 경보를 제출하려면, 협력사로부터 먼저 정보를 받아야 합니다. 이 시점부터 12시간 이내 취약점 통보 SLA가 협력사 계약에 본격적으로 반영됩니다.
• 2026년 하반기: 삼성·LG가 EU 출시 예정 신제품에 대해 펌웨어 SBOM, CVD 정책, 보안 업데이트 지원 기간을 협력사 요구사항으로 명시합니다. 기존 계약 갱신 시점에 조항이 추가되는 형태가 일반적입니다.
• 2027년 상반기: EU 적합성 선언(EU DoC) 작성을 위한 기술 문서 요구가 협력사에 전달됩니다. 부속서 VII 형식의 기술 문서 항목(위험 평가, SBOM, 보안 업데이트 정책)을 협력사 몫으로 분담하는 구조가 일반화됩니다.
• 2027년 12월 11일: CRA 전면 적용. 이 시점에 EU 시장에 출고되는 모든 신제품은 CE 마킹과 EU DoC를 갖추고 있어야 합니다.

한국반도체산업협회와 한국전자정보통신산업진흥회가 2026년 중 관련 가이드라인을 발표할 것으로 예상되지만, 협력사의 실무 대응은 협회 발표보다 구매사 계약서가 먼저 요구합니다.

어떤 부품 공급업체가 직접 CRA 의무를 지는가

CRA에서 "제조업체(manufacturer)"는 자사 이름·상표로 제품을 EU 시장에 출시하는 주체입니다. 이 정의에 따라 한국 협력사의 법적 지위가 갈립니다.

세 가지 시나리오를 구분해야 합니다.

시나리오 1: 순수 ODM·부품 공급

• 삼성·LG 브랜드로 EU에 출고되는 제품의 부품·모듈·펌웨어를 공급하는 경우
• CRA 직접 의무는 삼성·LG가 집니다
• 협력사는 B2B 계약을 통해 CRA 관련 증빙과 프로세스를 이행합니다

시나리오 2: 자사 브랜드로 EU 직판

• 코웨이·위니아처럼 자사 브랜드로 EU 시장에 커넥티드 제품을 출시하는 경우
• 협력사가 아니라 제조업체입니다. CRA 전체 의무를 직접 집니다
• CE 마킹, EU 적합성 선언, 기술 문서, ENISA 신고가 모두 자사 책임

시나리오 3: 자사 부품을 EU 유통사에 직접 판매

• 예: Wi-Fi 모듈을 EU의 세트 메이커에 직접 판매하는 LG이노텍
• 해당 모듈이 "디지털 요소를 포함한 제품(product with digital elements)"에 해당하면 CRA 제조업체 지위입니다
• 모듈이 단독으로는 CRA 범위 외이고 완제품에 통합될 때만 의미가 있다면, 세트 메이커가 CRA 의무를 집니다

실무적으로 다수 한국 협력사는 시나리오 1과 시나리오 3을 동시에 경험합니다. 삼성 프로젝트에서는 ODM이지만, 유럽 중소 가전 브랜드와는 직거래를 하는 경우입니다. 이 경우 제품 라인별로 CRA 지위를 구분 관리해야 합니다.

협력사가 받게 될 7가지 계약 요구사항

삼성·LG가 협력사에 요구할 계약 조항은 이미 EU 완성차 업계의 ISO/SAE 21434 공급망 요구와 유사한 구조를 따릅니다. 실제 협력사 계약서에 반영될 7가지 조항은 다음과 같습니다.

1. 펌웨어 SBOM 제공 (CycloneDX 또는 SPDX)

• 무엇을: 공급 펌웨어의 전체 소프트웨어 구성 요소 목록(CycloneDX 또는 SPDX 형식)
• 왜 필요한가: 취약점 공개 시 영향 범위를 삼성·LG가 신속히 판정하기 위함. SBOM이 없으면 Log4Shell·XZ Utils 같은 공급망 취약점 발생 시 삼성·LG가 ENISA에 24시간 이내 신고할 수 없습니다
• 이행 실패 시: EU 출시 일정 지연, 대체 협력사로 전환 근거

2. 협조적 취약점 공개(CVD) 정책 운영

• 무엇을: 외부 연구자·보안 커뮤니티의 취약점 제보를 접수하는 공식 채널과 처리 SLA 정의
• 왜 필요한가: CRA 제13조는 제조업체에 CVD 정책을 의무화합니다. 삼성·LG의 CVD는 협력사 컴포넌트까지 확장되어야 성립합니다
• 이행 실패 시: 브랜드 제조업체의 CVD가 공급망 깊이까지 도달하지 못하여 규제 위반 위험 발생

3. security.txt 파일 게시 (RFC 9116)

• 무엇을: 공식 웹사이트 /.well-known/security.txt 경로에 RFC 9116 형식의 연락처 파일 게시
• 왜 필요한가: 보안 연구자가 협력사에 직접 취약점을 제보할 수 있는 표준 경로. 삼성·LG가 자사 security.txt만으로 모든 공급망 컴포넌트를 대응할 수 없습니다
• 이행 실패 시: 제3자 취약점 제보가 삼성·LG에 먼저 도달하여 협력사가 후속 대응 압박을 받습니다

4. 12시간 이내 취약점 통보

• 무엇을: 협력사가 자사 펌웨어·부품에서 적극적으로 악용되는 취약점을 인지한 후 12시간 이내 삼성·LG 보안팀에 통보
• 왜 필요한가: 브랜드 제조업체는 ENISA에 24시간 이내 조기 경보를 제출해야 합니다. 협력사 통보 시한이 ENISA 시한보다 짧아야 브랜드가 여유를 가집니다
• 이행 실패 시: 브랜드가 ENISA 기한을 놓칠 경우 CRA 제64조 위반으로 과징금 대상. 협력사 배상 책임 조항이 발동됩니다

5. 5년 이상 보안 업데이트 지원

• 무엇을: 공급 부품·펌웨어에 대해 EU 출시 시점부터 최소 5년간 보안 패치 제공
• 왜 필요한가: CRA 제13조는 제품 지원 기간 중 무상 보안 업데이트 의무를 규정합니다. 브랜드 제조업체가 이 기간을 지키려면 협력사의 패치 공급이 전제됩니다
• 이행 실패 시: 브랜드가 단독으로 역공학을 통해 패치를 만들 수 없는 경우 제품 리콜·출시 중단

6. 부속서 VII 기술 문서 협조

• 무엇을: 협력사 컴포넌트의 위험 평가, 보안 설계 문서, 적합성 평가 증빙을 브랜드 제조업체의 기술 문서에 포함할 수 있는 형태로 제공
• 왜 필요한가: EU DoC 작성 시 브랜드가 기술 문서를 10년간 보관해야 합니다. 협력사 증빙이 없으면 기술 문서가 완성되지 않습니다
• 이행 실패 시: 시장 감시 기관의 기술 문서 제출 요청 시 협력사 부분 공란 발생

7. EU 적합성 선언(EU DoC) 협조

• 무엇을: EU DoC에 기재할 협력사 컴포넌트 정보(모델명, 버전, 적용 표준) 서면 확인
• 왜 필요한가: EU DoC는 브랜드 제조업체 법적 서명 문서입니다. 협력사 컴포넌트의 사양 변경이 있을 경우 DoC 갱신이 필요하고, 이때 협력사의 서면 확인이 증빙 근거가 됩니다
• 이행 실패 시: DoC 갱신 지연으로 신규 펌웨어 배포 차단

각 조항은 EU의 적합성 평가 프레임워크와 직접 연결됩니다. 협력사가 이 중 하나라도 이행하지 못하면, 삼성·LG의 EU 출시 일정 자체가 흔들립니다. 이것이 협력사 계약에 이 조항들이 반드시 반영되는 구조적 이유입니다.

스마트 가전·TV의 CRA 제품 분류 실전 가이드

삼성·LG 제품 라인을 CRA 분류에 매핑하면 협력사 증빙 요구 수준이 달라집니다.

SmartThings·ThinQ IoT 허브가 Class I로 분류되는 이유는 부속서 III에 "스마트 홈 범용 기기" 및 "네트워크 관리 시스템"이 명시되어 있기 때문입니다. 허브 펌웨어를 공급하는 협력사는 브랜드가 요구하는 증빙 수준이 TV·세탁기 협력사보다 한 단계 높다는 점을 전제해야 합니다.

SBOM: 펌웨어 공급업체가 직접 만들어야 하는 이유

협력사가 흔히 하는 오해가 있습니다. "삼성·LG가 완제품 SBOM을 자체적으로 생성할 수 있지 않느냐"는 질문입니다. 기술적으로 불가능합니다.

완제품 SBOM은 각 컴포넌트 SBOM의 합산입니다. 삼성이 LG이노텍 Wi-Fi 모듈 펌웨어의 내부 오픈소스 구성 요소를 역공학으로 스캔하는 것은 현실적이지 않고, 결과의 완전성도 보장할 수 없습니다. 따라서 CRA는 각 컴포넌트 공급자가 자신의 SBOM을 제공하고, 브랜드 제조업체가 이를 통합하는 구조를 전제합니다.

실무적 SBOM 생성 방법은 다음과 같습니다.

• 빌드 시점 통합: Syft(Anchore)·cdxgen(OWASP) 같은 도구를 CI 파이프라인에 통합하여 빌드마다 CycloneDX SBOM을 자동 생성
• 펌웨어 이미지 스캔: 빌드 시스템이 접근 불가능한 경우, 최종 펌웨어 이미지에서 Syft로 SBOM 추출. 완전성은 빌드 시점 통합 대비 낮음
• 서드파티 라이브러리 추적: 오픈소스 라이선스 관리 도구(FOSSA, Black Duck)와 SBOM 도구를 함께 운용
• 업데이트마다 재생성: 패치·기능 추가 시 SBOM 재생성 및 브랜드 제조업체에 재제출

KISA가 2024년 발표한 「SW 공급망 보안 가이드라인 1.0」은 SBOM 생성 원칙의 좋은 출발점입니다. 그러나 KISA 가이드라인은 주로 국내 소프트웨어 제품을 대상으로 하며, 임베디드 펌웨어와 하드웨어 컴포넌트까지 포괄하지는 않습니다. CRA 펌웨어 SBOM은 이보다 범위가 넓습니다.

flowchart LR
    SRC["소스 코드\n오픈소스 라이브러리"] --> BUILD["빌드 파이프라인"]
    BUILD --> SYFT["Syft / cdxgen\nSBOM 생성"]
    SYFT --> CDX["CycloneDX JSON"]
    BUILD --> FW["펌웨어 이미지"]
    CDX --> BRAND["브랜드 제조업체\n삼성·LG"]
    FW --> BRAND
    BRAND --> DOC["부속서 VII\n기술 문서"]
    DOC --> ENISA["ENISA 신고\n(취약점 발생 시)"]

KISA SBOM 가이드라인과 CRA의 차이점

KISA가 발표한 「SW 공급망 보안 가이드라인 1.0」과 CRA 요구사항은 출발점은 같지만 적용 범위가 다릅니다. 협력사가 KISA 가이드라인만 준수한다고 해서 CRA가 자동으로 충족되지는 않습니다.

KISA 가이드라인을 이미 운영 중인 협력사는 SBOM 생성 역량과 CVD 프로세스의 기초를 갖춘 상태입니다. 이 기반 위에 CRA 특화 요구사항(기계 판독 형식, 지속 업데이트, ENISA 연계)을 추가하는 작업이 실질적인 준비입니다.

삼성 GSMA IoT 보안 가이드라인과 CRA의 관계

삼성은 SmartThings 플랫폼에 GSMA IoT Security Guidelines를 적용해 왔습니다. 이 프레임워크는 IoT 기기의 인증·암호화·펌웨어 무결성 검증 같은 기본 요구사항을 정의합니다. CRA 부속서 I의 보안 요구사항과 일부 중첩됩니다.

다만 GSMA 가이드라인은 CRA의 전체 대체재가 아닙니다. 중요한 차이점은 다음과 같습니다.

• GSMA는 기기 설계의 보안 기준을 제시하지만, EU DoC 같은 법적 문서는 요구하지 않습니다
• GSMA에는 ENISA 24시간 신고 같은 당국 보고 메커니즘이 없습니다
• GSMA에는 시장 감시 기관의 기술 문서 제출 요청 같은 공식 집행 장치가 없습니다

따라서 SmartThings 생태계 협력사가 GSMA 가이드라인을 준수한다는 것은 CRA 준비의 토대일 뿐, 완결은 아닙니다. CRA 특화 문서·프로세스·통보 체계를 별도로 구축해야 합니다.

준비 로드맵 (지금 ~ 2027년 12월)

flowchart LR
    NOW["2026년 4월\n현재"] --> M1["2026년 5-7월\n제품 CRA 분류\nSBOM 파이프라인 설계\nCVD 정책 초안"]
    M1 --> M2["2026년 8월\nsecurity.txt 게시\n취약점 통보 SOP\n브랜드사 SLA 합의"]
    M2 --> SEP["2026년 9월 11일\nENISA 신고 의무 발효\n12시간 통보 SLA 가동"]
    SEP --> M3["2026년 Q4\nSBOM 형식 브랜드사 합의\n기술 문서 템플릿 확정"]
    M3 --> M4["2027년 상반기\n신규 프로젝트부터\nCRA 조항 계약 반영\n5년 보안 업데이트 약정"]
    M4 --> DEC["2027년 12월 11일\nCRA 전면 적용\nCE 마킹 완제품\nEU DoC 완비"]

KC 인증과 CE 마킹, 그리고 CRA가 추가로 요구하는 것

국내 출시 제품에 적용되는 KC 인증과 EU 출시에 필요한 CE 마킹은 대상 시장과 범위가 다릅니다. CRA는 CE 마킹 체계 위에 사이버보안 요구사항을 덧붙이는 구조입니다.

협력사 실무에서 자주 발생하는 혼동은 "KC 인증을 이미 받았으니 CRA도 충족된다"는 오해입니다. KC 인증은 전기 안전·EMC 중심이며 사이버보안을 다루지 않습니다. 반면 CRA는 전기 안전을 전혀 다루지 않고 사이버보안만 다룹니다. 두 체계는 서로를 대체하지 않습니다.

RED(무선 기기 지침) 제3조(3) 사이버보안 위임 규정은 2025년 8월 1일 발효되어 Wi-Fi·블루투스 기기에 기본 사이버보안 요구를 먼저 적용합니다. CRA는 이보다 넓은 제품 범위에 더 상세한 요구사항을 부과하므로, 2027년 12월 이후에는 CRA가 실질적 기준이 됩니다.

중요 제품 Class I 분류가 협력사에 주는 부담: SmartThings 허브 사례

부속서 III에 포함된 "네트워크 관리 시스템"과 "스마트 홈 범용 기기"는 협력사 증빙 요구 수준을 한 단계 끌어올립니다. SmartThings 허브가 대표적입니다.

일반 제품 분류에서는 제조업체의 자체 평가로 EU DoC를 발행할 수 있습니다. 중요 제품 Class I에서는 EU 조화표준이 발효되기 전까지 다음 중 하나를 선택해야 합니다.

• 공고 기관(Notified Body)을 통한 제3자 적합성 평가
• EUCC(EU 사이버보안 인증 체계) 인증
• 조화표준 발효 대기: 실무적으로 2027년 12월까지 발효되지 않을 가능성이 있습니다

2026년 4월 기준, CEN/CENELEC에서 CRA 조화표준이 제정 중이지만 발효 일정은 확정되지 않았습니다. 조화표준이 없는 상태에서 Class I 제품을 EU에 출시하려면 제3자 평가 경로가 사실상 유일합니다.

SmartThings 허브에 펌웨어·모듈을 공급하는 협력사는 다음을 준비해야 합니다.

• 공고 기관 심사에 제출할 수 있는 형태의 펌웨어 SBOM
• 보안 설계 문서: 암호 키 관리, 펌웨어 서명 검증, 보안 업데이트 메커니즘, 접근 제어 설계
• 취약점 관리 기록: 최근 24개월 취약점 공개 이력, 대응 시간, 재발 방지 조치
• 제3자 보안 평가 결과: 침투 시험 보고서, 정적 분석 결과

이 수준의 증빙은 일반 제품 협력사가 준비하는 증빙보다 분량과 품질이 모두 높습니다. Class I 제품 공급 기회는 매출 규모가 크지만, 증빙 요구 수준도 비례하여 높아집니다.

자주 발생하는 실무 오해

협력사 현장에서 반복되는 오해를 정리합니다.

오해 1: "삼성·LG가 CRA를 하니까 우리는 할 일이 없다"

사실은 반대입니다. 브랜드 제조업체가 CRA 의무를 이행하려면 협력사 증빙이 전제됩니다. 협력사가 SBOM을 공급하지 못하면 브랜드사의 기술 문서가 완성되지 않습니다. 협력사가 12시간 통보 SLA를 지키지 못하면 브랜드사는 ENISA 24시간 기한을 놓칩니다.

오해 2: "국내 KISA 가이드라인을 준수하면 CRA도 자동 충족된다"

KISA 「SW 공급망 보안 가이드라인 1.0」은 CRA 요구사항과 기반이 중첩되지만 완전 동치는 아닙니다. 기계 판독 형식, 지속 업데이트 의무, ENISA 신고 연계 등 CRA 특화 요구가 별도로 존재합니다.

오해 3: "소프트웨어 SBOM만 있으면 된다"

CRA는 디지털 요소를 포함한 제품 전체를 대상으로 합니다. 소프트웨어 SBOM뿐 아니라 펌웨어·내장 라이브러리·제3자 컴포넌트까지 포괄해야 합니다. Wi-Fi 모듈·MCU 펌웨어 같은 임베디드 영역이 누락되면 SBOM으로서 불완전합니다.

오해 4: "취약점이 발견돼도 조용히 처리하면 된다"

CRA 제14조는 적극적으로 악용되는 취약점에 대한 ENISA 신고를 의무화합니다. 브랜드 제조업체가 ENISA 신고를 하면 협력사 컴포넌트 정보가 포함됩니다. 협력사가 이를 숨기거나 지연하면 계약 위반이자 브랜드사와의 공동 법적 책임 문제가 발생합니다.

오해 5: "2027년 12월이 되면 그때 준비하면 된다"

2026년 9월 11일 ENISA 신고 의무가 먼저 발효됩니다. 2026년 하반기부터 신규 계약에 CRA 조항이 반영됩니다. 실무 준비의 실제 데드라인은 2026년 중반입니다.

협력사 예산 계획 가이드

CRA 대응 비용은 제품 라인과 조직 규모에 따라 차이가 크지만, 일반적인 비용 항목은 다음과 같습니다.

오픈소스 도구를 최대한 활용하면 소프트웨어 비용은 최소화할 수 있습니다. 실질적 비용의 대부분은 인력 공수와 체계 구축에 집중됩니다. 제3자 평가는 Class I 제품에만 필요하며 규모가 크므로, 사전에 제품 분류를 정확히 판정하는 것이 비용 최적화의 출발점입니다.

다음 단계

협력사 입장에서 CRA 대응은 분류 합의, 증빙 자동화, 통보 SOP, 계약 조항이라는 네 축으로 구성됩니다. 다음 단계는 ODM·모듈·펌웨어 협력사가 즉시 착수해야 하는 실무 작업입니다.

본 문서는 정보 제공 목적이며 법률 자문을 구성하지 않습니다. 구체적인 규제 준수 사항은 EU 규제에 정통한 법률 전문가와 상의하십시오.