와이즈스톤 와이즈스톤

기술인사이트

기술리포트

왜 지금 ‘사이버 복원력법’인가?
  • 작성자
    와이즈스톤 김홍기 이사
  • 작성일
    2025-10-24

디지털 기술이 모든 산업에 스며들면서, 한 번의 보안 사고가 국가 인프라를 멈추게 할 수 있는 시대가 되었습니다.
EU는 이러한 리스크에 대응하기 위해 “예방 중심의 보안 → 복원력 중심의 보안”으로 패러다임을 전환하고 있습니다.
CRA·NIS2·DORA는 그 전환의 3대 축으로, 제품·서비스·운영 전반을 포괄하는 EU 사이버보안 규제의 완성형 세트입니다.

▯CRA (Cyber Resilience Act) → 제품(하드웨어·소프트웨어) 보안 의무
▯NIS2 Directive → 조직·서비스 운영의 보안 및 보고체계 강화
▯DORA (Digital Operational Resilience Act) → 금융권 운영 복원성 규정

▮ CRA - 제품 보안의 새로운 기본선
○ 제품(하드웨어·소프트웨어) 보안 요건의 기술적 내용

CRA는 “디지털 요소를 가진 제품(Products with Digital Elements, PDEs)”에 대하여 설계·개발·출시·지원 종료까지의 전체 생애주기(lifecycle) 관점에서 사이버보안 요건을 규정했습니다.

▯CRA (Cyber Resilience Act) → 제품(하드웨어·소프트웨어) 보안 의무
▯NIS2 Directive → 조직·서비스 운영의 보안 및 보고체계 강화
▯DORA (Digital Operational Resilience Act) → 금융권 운영 복원성 규정
 
① 적용 대상과 구조
CRA가 적용되는 제품은 논리적이든 물리적이든 네트워크 또는 다른 장치와의 데이터 연결이 예정되거나 예측할 수 있는 제품을 말합니다.
즉, 단독형 가전제품이라도 미래에 네트워크 연결이 가능하다면 적용 대상이 될 수 있습니다.

이 법은 하드웨어·소프트웨어 모두를 포함하며, 소프트웨어만 존재하는 디지털 서비스도 ‘디지털 요소’가 있다면 대상이 될 수 있다는 해석이 나와 있습니다.

제조자(Manufacturer), 수입자(Importer), 유통업자(Distributor) 등 경제주체(Economic Operators)에게 각자의 책임이 부과됩니다.

② 주요 기술 요건
CRA의 부속서(Annex I)에는 “Essential Cybersecurity Requirements”가 구체적으로 명시되어 있습니다.
주요 항목을 기술적으로 풀어보면 다음과 같습니다. 


제품은 “알려진 이용 가능 취약점(exploitable vulnerabilities)” 없이 시장에 제공되어야 합니다.
설계 시 취약점이 이미 존재하는 상태로 출하해서는 안 됩니다.

기본 구성(default configuration)은 안전하게 설정된 상태(secure by default) 여야 하며, 사용자가 원하지 않으면 보안 설정을 해제할 수 없게 해야 한다는 원칙이 포함됩니다.

취약점 대응을 위한 보안 업데이트(security updates)를 제공해야 하며, 가능하면 자동 설치(automatic updates)가 기본 설정돼야 하고, 사용자가 꺼도 되도록 선택 옵션(opt-out)을 제공해야 합니다.

인증(Authentication) · 접근제어(Access Management) 등의 부적절한 접근 방지 제어를 갖춰야 합니다.

저장된 데이터·전송 중인 데이터에 대해 기밀성(confidentiality) 보장(예: 암호화)과 무결성(integrity) 및 가용성(availability)도 기술적으로 확보해야 합니다.
예컨대 암호화(encryption at rest & in transit) 등의 조치가 요구됩니다.
​
데이터 최소화(data minimisation) 원칙이 포함되어 있어, 제품이 처리하는 데이터는 “목적에 필요한 만큼만 adequate, relevant & limited” 해야 합니다.
제품은 서비스·네트워크에 부정적 영향을 미치지 않도록 설계돼야 하며, 예컨대 서비스 거부(DoS) 공격 등에도 필수 기능이 유지될 수 있도록(resilience & mitigation) 대비해야 합니다.

공격 표면(attack surface)을 최소화할 수 있도록 외부 인터페이스(external interfaces), 디버그 포트, 불필요한 기능 등을 줄이도록 설계돼야 합니다.
제품 내부적으로 행위(활동) 기록 및 모니터링(logging & monitoring)을 제공해야 하며, 사용자가 기록을 중지하고 싶을 때 옵션을 제공해야 한다는 조항도 있습니다.

사용자가 원할 경우 제품에 저장된 데이터 및 설정을 영구 삭제(remove permanently) 할 수 있어야 하며, 다른 시스템이나 제품으로 이전할 때도 안전한 이전(secure transfer)이 가능해야 합니다.

③ 기술 문서화 및 증빙
제조자는 제품이 법령의 요구사항을 충족함을 입증하기 위해 기술문서(Technical Documentation) 를 마련해야 합니다.
CRA에서는 Annex VII가 이 문서에 포함되어야 할 내용을 구체화하고 있습니다.
예컨대 제품 일반설명, 설계·개발·생산 과정, 위험평가 결과, 테스트 결과, 지원기간 산정 근거 등이 포함됩니다.
또한, 제조자는 EU 적합성 선언서 (Declaration of Conformity, DoC) 를 제공해야 합니다.
제품이 해당 규제 요건을 충족함을 문서로 선언하는 방식입니다.
기술문서는 제품이 시장에 출시되기 전부터 준비되어야 하며, 지원 기간 지속해서 업데이트되어야 합니다.

④ 취약점·사고 보고 기술 요건
제조자는 취약점 공개(Coordined Vulnerability Disclosure, CVD) 정책을 마련해야 하며, 사용자가 또는 제3자가 취약점을 보고할 수 있는 메커니즘을 제공해야 합니다.
또한 제품이 판매된 이후에도 시장 감시(Post-market monitoring) 체계를 갖춰야 하며, 알려진 취약점이 있는 경우 시정조치(remediation)를 신속히 해야 합니다.

⑤ 기술적 설계 대비 전략
제조·설계 단계에서 보안 설계(Security by Design)와 보안 기본값(Security by Default) 원칙을 제품 아키텍처에 반영해야 합니다.
이는 단순 UI 보안뿐 아니라 내부 취약점·공격노출면(attack surface) 최소화·방어계층(defence-in-depth) 설계까지 포함됩니다.
예를 들어, 제품 내부에는 최소 권한 원칙(least privilege) 적용, 불필요한 서비스·포트 비활성화, 업데이트 기능 암호화, 로그·감사(audit) 기능 내장 등이 고려돼야 합니다.

또한, 소프트웨어 구성 목록(SBOM, software bill of materials) 등 제품 내 포함된 오픈소스·서드파티 컴포넌트에 대한 투명성이 더욱 중요하다는 학계 지적도 있습니다.

⑥ 지원 기간·업데이트 체계
앞서 설명했듯이, 제품은 적합성 선언 시점부터 제조사가 산정한 지원 기간 동안 보안 업데이트를 제공해야 합니다.
이 기간은 최소 5년이며, 지원 기간 동안 배포된 업데이트 자료는 최소 10년간 접근할 수 있게 유지되어야 합니다.

업데이트 체계는 자동 또는 반자동이어야 하며, 사용자가 수동으로 업데이트하도록 요구해서는 안 됩니다. (다만, 사용자가 자동업데이트를 원치 않을 경우 옵트-아웃 가능)

▮ NIS2 Directive- 조직과 서비스의 복원력
○ 조직·서비스 운영의 기술적·절차적 강화
 NIS2는 조직과 운영체계 중심의 보안·복원성 강화를 목표로 합니다.
기술적 요건도 상당히 구체적이며, 특히 보고 체계·거버넌스·감독 인프라 구축이 중요합니다.
NIS2는 사고 보고 체계를 구체적으로, 3단계로 나누었습니다.


① 적용 대상 및 분류
회원국은 각국 법으로 조직을 “Essential 엔터티” 또는 “Important 엔터티”로 분류해야 하며, 이 분류에 따라 감독 수준·보고 요건이 달라집니다.
조직 내부에서는 사이버보안 거버넌스 구조를 마련해야 합니다.
최고경영진(CEO) 또는 이사회 책임, CSIRT 조직, 보안 책임자(CISO) 지정 등이 기술 요건으로 제시됩니다.

② 사고 보고 체계 및 기술 요건
기술적으로 조직은 발생 가능한 사건·사고(예: 서비스 거부, 데이터 유출, 시스템 침해)를 24시간 이내 Early Warning → 72시간 이내 Incident Notification → 1개월 내 최종 보고 구조로 대응 체계를 갖춰야 합니다.

보고 시 포함돼야 하는 기술 정보로는 다음과 같은 항목이 권고됩니다.
ⓐ 사고의 원인 및 공격벡터(attack vector)
ⓑ 영향을 받은 자산(assets) 및 시스템
ⓒ 복구 조치 및 현재 진행 중인 대응
ⓓ 확산 가능성 및 재발 방지 대책
보고 체계는 자동화된 모니터링 시스템, 로그 분석 솔루션, 이벤트 관리(EV/IR) 플랫폼과 연동돼야 합니다.
​
③ 거버넌스 및 기술 절차
조직은 내부 보안 정책, 사고 대응 매뉴얼, 복구계획(Business Continuity Plan, BCP) 및 재난 복구(Disaster Recovery, DR) 계획을 갖춰야 합니다.
또한 공급망(supply chain) 및 하도급(sub-contractor) 리스크도 평가하고, 서비스 제공자나 외주업체에 대한 보안 요건을 계약(SLA) 형태로 포함해야 합니다.

조직 내부는 보안 훈련·모의훈련(table-top exercise)을 주기적으로 시행하며, 로그·모니터링·침입탐지(IDS/IPS) 체계를 운영해야 합니다.

④ 기술감독 및 인증 연계
회원국 감독기관은 조직에 대해 현장검사, 자산·시스템 감사(IT audit), 보안테스트(penetration test) 등을 수행할 수 있으며, 조직은 실시간 위협대응체계(Security Operation Center, SOC)를 갖추는 것이 권장됩니다.
또한, 조직은 보안인증(예: ISO/IEC 27001, IEC 62443) 및 표준(예: NIST CSF)과 연계해 기술체계를 구축하면 감독 기관 평가 시 유리합니다.
​
▮ DORA - 금융권의 디지털 운영 복원성
○ 금융권의 디지털 운영 복원성, 기술적 구현 관점
DORA는 금융기관과 그들이 의존하는 ICT 제공업체에 대해 운영 복원성(Operational Resilience)을 기술·절차·거버넌스 전반에 걸쳐 규정한 법입니다. 


① ICT 위험 관리 프레임워크
Article 5~16에 따라 금융기관은 ICT 리스크에 대한 정형화된 프레임워크(ICT Risk Management Framework, IRMF)를 수립해야 합니다.
기술 요건 중 핵심은 다음과 같습니다.

ⓐ 거버넌스 구조: 이사회(Board) 및 경영진(Senior Management)이 ICT 리스크 전략을 승인하고, 정기적으로 보고받아야 한다는 책임이 있습니다.

ⓑ 자산 및 의존성 레지스터: 어떤 ICT 자산이 핵심 기능을 지원하는지, 외부 서비스·프로바이더에 대한 의존성이 무엇인지 문서화해야 합니다.

ⓒ 위험 평가 및 통제 메커니즘: 위협·취약점·시나리오 분석을 통해 리스크를 식별하고, 이에 대한 기술적·조직적 통제를 적용해야 합니다. 예컨대 침입탐지, 데이터 암호화, 접근제어, 로그모니터링 등이 포함됩니다.

ⓓ 지속모니터링(Continuous Monitoring): 실시간 또는 준실시간 방식으로 ICT 환경을 모니터링하고 이상징후를 탐지·대응할 수 있어야 합니다.

② 사고 관리 및 보고
DORA는 금융기관이 겪는 ICT 사고(major ICT-related incidents)에 대해 분류(classification) 및 보고(reporting) 체계를 규정하고 있습니다.
기술적으로 조직은 사고 탐지·분석·통지·복구·근본 원인 분석(root-cause analysis) 등을 포함하는 사고 관리(IR/Incident Response) 절차를 갖춰야 합니다.
또한, 금융기관은 정보 공유(Information Sharing) 플랫폼에 참여하거나 내부적으로 위협 정보(TI/Threat Intelligence)를 수집하고 활용해야 합니다.

③ 디지털 복원성 테스트
DORA는 디지털 복원성 테스트(digital operational resilience testing)를 요구하며, 여기에는 침투 테스트(penetration testing), 레드팀(red-teaming), 시나리오 기반 모의훈련 등이 포함됩니다.
기술적으로 조직은 테스트 결과를 문서화하고, 발견된 약점에 대한 시정조치(remediation) 및 반복 검증(re-testing)을 수행해야 합니다.

④ 제3 자 ICT 서비스 제공자 관리
금융기관은 클라우드·데이터센터·핀테크 서비스 등 외부 ICT 공급자(Third-Party ICT Service Providers, TTPs)를 계약·감독·평가해야 합니다.
기술 요건으로는 공급자 리스크 평가(risk assessment), SLA(Service Level Agreement) 보안 조항 포함, 모니터링·감사권(audit rights) 확보, 종료 전환(exit plan) 등이 있습니다.
EU-차원에서는 중요 ICT 제3자(Critical ICT Third-Party Providers, CTPPs)에 대해서는 감독 체계(Oversight Framework)가 적용됩니다.

e) 기술 문서화 및 증빙
DORA 하위에는 여러 Regulatory Technical Standards(RTS) 및 Implementing Technical Standards(ITS)가 마련돼 있으며, 이들 문서에는 기술적 요소(모든 ICT 리스크관리 요소, 사고 분류 템플릿, 제3 자 평가 모델 등)가 포함되어 있습니다.
금융기관은 이러한 표준요건을 반영해 실무문서(정책, 프로세스, 기술매뉴얼)를 준비해야 하며, 감독 당국이 검토할 수 있도록 증빙자료를 유지해야 합니다.

4) 기술 강화·통합 관점에서 세 법안 비교 & 시사점
지금까지의 설명을 종합하자면 세 법안 모두 기술적·절차적 요건을 갖추라고 요구하지만, 핵심 포인트가 약간씩 다릅니다.


CRA는 제품 보안 설계·구현·지원이 중심이며, 제조사·개발사가 기술적으로 “무 취약 제품 출시 + 자동 업데이트 지원 기간 확보”라는 과제를 갖습니다.

NIS2는 운영 조직의 보안·보고·거버넌스가 중심이며, 기술적 차원에서는 로그·모니터링·사고 관리·공급망 보안 등이 핵심입니다.

DORA는 금융권 운영 복원성이라는 맥락에서 ICT 리스크관리, 테스트, 제3 자 리스크, 보고 체계 등 기술·절차·관리 요건이 통합되어 있습니다.

이들을 통합적으로 준비하는 조직이라면, 아래 기술적 요소들도 고려하여야 합니다.

제품 개발팀부터 운영·유지보수팀까지 연계된 보안라이프사이클(Security Lifecycle) 구축

조직 내부 및 공급망 전반에 위험 식별(risk identification) → 통제(control) → 모니터링(monitoring) → 복구(recovery)가 가능한 체계 마련

자동화 가능한 기술 요소(자동업데이트, 실시간 로그 분석, 위협탐지) 도입 및 구현

문서화·증빙 가능한 정책·절차 매뉴얼 및 기술 기록(테스트 결과, 감사로그 등) 확보

외부 공급자 및 하도급 리스크를 계약, 평가, 감독하는 공급망 보안 거버넌스 구축

결론 — 복원력은 규제가 아니라 경쟁력이다.

EU의 CRA, NIS2, DORA는 단순한 법률 조항이 아니라, 디지털 사회의 신뢰를 유지하기 위한 새로운 기술 표준이자 기업 경쟁력의 기준선입니다.

사이버 복원력은 더 이상 선택적인 보안 항목이 아니라, 제품 설계와 운영 프로세스, 그리고 조직 문화 전반에 내재되어야 하는 기본 요소입니다.

와이즈스톤에서는 이러한 세계적 추세에 발맞춰 CRA의 사이버 복원력과 관련된 시험 방법 연구 및 서비스를 지속적으로 준비하고 있습니다.
​
이제 보안은 선택이 아닌 필수의 요소로 자리 잡고 있으며, 그 범위는 제품을 넘어 조직과 프로세스 전반으로 확장되고 있습니다.

앞으로도 와이즈스톤은 국제 기준에 부합하는 보안 시험·검증 기술을 통해 기업들이 글로벌 시장에서 신뢰받는 디지털 제품과 서비스를 제공할 수 있도록 꾸준히 지원하고, 함께 성장해 나갈 것입니다.

💡 “복원력(Resilience)은 생존의 조건이며, 신뢰는 그 결과입니다.” 지금이 바로, 보안을 경쟁력으로 전환할 때입니다.

🔗 참고 출처 (References)
1. Regulation (EU) 2024/2847 – Cyber Resilience Act, Official Journal of the European Union, L 2024/2847.
2. Directive (EU) 2022/2555 – NIS2 Directive, EUR-Lex Document 32022L2555.
3. Regulation (EU) 2022/2554 – Digital Operational Resilience Act (DORA).
4. European Commission Press Corner, “Cyber Resilience Act Q&A” (2024).
5. ENISA (2023–2024) Implementation Guidelines for NIS2 Directive.
6. EBA/EIOPA/ESMA Joint Final Report on DORA RTS & ITS (2024).
7. Clifford Chance, The EU Cyber Resilience Act: Legal and Technical Overview (2024).
8. Schellman & Co., Overview of the EU Cyber Resiliency Act (2024).
9. European Central Bank (2025 Q1) FinTech Supervision Note – Operational Resilience.
10. arXiv Preprint (2025-03) “Analyzing the EU Cyber Resilience Act from a Security Engineering Perspective”

​