요약: 유럽연합 사이버복원력법(CRA)의 본체 의무는 2027년 말 시작되지만, 적극 악용된 취약점과 중대한 사고의 보고 의무는 2026년 9월 11일부터 먼저 적용된다. 제조사와 소프트웨어 공급자는 ‘언젠가 보안을 강화하자’가 아니라 발견·판단·통지의 시계를 지금 맞춰야 한다. 이번 규제의 핵심은 취약점 수를 줄이는 데만 있지 않고 누가 어떤 근거로 위험을 분류하고, 어떤 버전을 얼마나 오래 지원할지 증명하는 데 있다.
2027년보다 먼저 오는 2026년의 보고 시계
유럽연합 집행위원회는 CRA가 2024년 12월 발효됐고 주요 의무는 2027년 12월 11일부터, 보고 의무는 2026년 9월 11일부터 적용된다고 명시한다. 연결형 하드웨어와 소프트웨어를 유럽 시장에 공급하는 기업에는 이 시간 차이가 중요하다. 제품 설계와 적합성 평가 준비는 시간이 있지만, 실제 공격에 사용된 취약점이나 중대한 보안 사고를 인지하고 보고하는 조직 능력은 한 달 안에 작동해야 하기 때문이다.
보고 의무는 보안팀만의 체크리스트가 아니다. 고객지원이 이상 징후를 처음 접하고, 클라우드 운영팀이 공격 흔적을 확인하며, 법무팀이 규제 대상인지 판단하고, 제품팀이 영향을 받는 버전을 식별할 수 있다. 이 정보가 서로 다른 티켓과 메신저에 흩어져 있으면 ‘인지 시점’ 자체가 불명확해진다. 기업은 최초 신고가 들어온 때, 기술적으로 악용을 확인한 때, 경영진이 통지 결정을 내린 때를 분리해 기록해야 한다.
새 지침이 풀어준 것과 남겨둔 것
집행위원회가 2026년 7월 27일 공개한 시행지침은 원격 데이터처리 솔루션, 자유·오픈소스 소프트웨어, ‘상당한 변경’, 지원기간, 보고와 위험평가를 67개 사례와 흐름도로 설명한다. 특히 중소기업이 경계선 사례를 이해하는 데 도움이 된다. 그러나 지침은 비구속적이며 모든 제품 조합과 배포 형태를 대신 판단해 주지는 않는다. 같은 코드라도 유료 서비스에 통합되는 방식, 제조사가 통제하는 원격 기능의 범위, 업데이트 뒤 기능 변화에 따라 책임선이 달라질 수 있다.
따라서 규제 대응의 출발점은 법률 문구를 요약하는 문서가 아니라 제품 지도를 만드는 일이다. 판매 주체, 소프트웨어 구성요소, 원격 서비스 의존성, 오픈소스의 상업적 사용, 업데이트 권한, 지원 종료일을 하나의 목록으로 연결해야 한다. ‘오픈소스를 썼으니 제외된다’거나 ‘클라우드라 제품이 아니다’라는 단정은 위험하다. 지침이 바로 이 경계를 별도로 다룬다는 사실은 단순 분류가 어렵다는 뜻이다.
플랫폼 사업자의 병목은 분류 정확도
플랫폼과 앱 생태계에서는 하나의 취약점이 운영체제, 라이브러리, 앱, 클라우드 API에 걸쳐 전파될 수 있다. 모든 경보를 최고 위험으로 올리면 보고 채널이 마비되고, 반대로 공급망 상류의 판단만 기다리면 실제 악용 대응이 늦어진다. 필요한 것은 취약점의 존재, 악용 정황, 고객 영향, 패치 가능성, 완화책을 서로 다른 필드로 관리하는 체계다. 소프트웨어 자재명세서(SBOM)는 구성요소를 찾는 출발점일 뿐, 현재 배포된 버전과 실행 가능 경로까지 자동으로 증명하지는 않는다.
‘지원기간’도 가격표 아래 작은 문구가 아니라 제품 보안의 핵심 조건이 된다. 제조사가 지원 종료일을 짧게 잡으면 비용은 줄지만 고객이 교체하기 어려운 산업·의료·공공 환경에는 잔존 위험이 남는다. 지나치게 긴 지원 약속은 패치 인력과 테스트 환경을 감당하지 못해 형식적 약속이 될 수 있다. 제품의 예상 사용기간, 교체 난도, 위협 노출, 부품 공급기간을 함께 반영한 근거가 필요하다.
한국 기업이 지금 만들 운영 증거
EU에 직접 판매하지 않더라도 한국 기업이 완제품 제조사나 플랫폼의 공급망에 들어가면 취약점 정보와 패치 일정 제공을 계약으로 요구받을 수 있다. 우선 제품별 책임자와 24시간 연락망을 지정하고, 고객 신고·위협정보·내부 탐지의 유입 경로를 하나의 사건번호로 합쳐야 한다. 다음으로 영향을 받는 버전, 판매 지역, 원격 기능, 완화책, 공개 시점을 재현할 수 있는 기록을 남겨야 한다. 마지막으로 법무·보안·개발·홍보가 동일한 사실표를 보고 의사결정하는 모의훈련이 필요하다.
평가 지표도 바뀌어야 한다. 취약점 ‘건수’만 줄이면 경미한 결함을 숨기거나 신고를 늦추는 잘못된 유인이 생긴다. 최초 인지에서 분류까지 걸린 시간, 영향 버전 확인률, 지원 중 제품의 패치 제공률, 고객 통지의 정확성, 사후 정정 횟수를 함께 봐야 한다. 규제 준수와 실제 보안을 연결하는 지점은 바로 이 운영 증거다.
전망: 보고가 제품 경쟁력의 일부가 된다
CRA는 제품의 기획·설계·개발·유지 전 단계에 보안 요구를 적용하고 일부 중요 제품에는 제3자 적합성 평가 가능성도 둔다. 2026년 보고 의무는 2027년 전면 적용을 앞둔 예행연습이 아니다. 실제 사고에서 조직의 책임선과 데이터 품질을 시험하는 첫 규제 시계다. 잘 준비한 기업은 빠른 통지와 명확한 지원기간을 신뢰 자산으로 만들 수 있다. 준비가 부족한 기업은 취약점 자체보다 늦고 모순된 설명 때문에 더 큰 계약·평판 비용을 부담할 수 있다.
향후 확인할 것은 단순 신고 건수보다 단일보고 플랫폼의 실제 작동, 회원국 감독기관의 해석 일관성, 오픈소스와 원격처리 경계에 대한 추가 지침, 중소기업 지원 수단이다. 규정이 공급망 전체의 정보 흐름을 개선하면 보안 효과가 커지지만, 중복 보고와 모호한 책임 전가로 흐르면 작은 공급자에게 비용만 집중될 수 있다. 따라서 비례성은 의무를 없애는 것이 아니라 동일한 위험을 같은 근거로 판단할 수 있게 만드는 방향이어야 한다.
출처
- European Commission, “Commission publishes new guidance to support timely Cyber Resilience Act implementation,” 2026-07-27, 원문 (확인: 2026-08-14 23:16 KST).
- European Commission, “Cyber Resilience Act,” updated 2026-07-27, 원문 (확인: 2026-08-14 23:16 KST).
- European Commission, “Proposal for a Regulation for the EU Cybersecurity Act,” 2026-01-20, updated 2026-01-21, 원문 (확인: 2026-08-14 23:16 KST).
이미지 출처: 본 기사를 위해 제작할 독자적 생성형 그래픽. 기존 게시물에 사용하지 않은 이미지로 등록 예정.
의견을 남겨주세요