EU DORA란 무엇일까? – 금융권 보안을 ‘법’으로 만든 규제의 시작

사이버보안은 오랫동안 “기술 영역”으로 취급되어 왔습니다.  
하지만 최근 유럽의 흐름은 다릅니다.  

 

사이버보안은 오랫동안 ‘기술 영역’으로 취급되어 왔습니다.
하지만 최근 유럽에서 나타나는 흐름은 이와 다릅니다.

이제 보안은 더 이상 단순한 기술 문제가 아니라, 금융 서비스의 지속성을 좌우하는 운영 리스크(Operational Risk)로 재정의되고 있습니다.

이 변화의 중심에 있는 것이 바로 EU의 DORA (Digital Operational Resilience Act) 입니다.

이 규제는 단순히 보안을 강화하라는 수준의 요구가 아닙니다.

금융 서비스는 어떠한 상황에서도 중단되어서는 안 되며, IT 장애와 사이버 공격은 동일한 리스크로 간주되어야 한다는 전제를 기반으로 합니다.

결국 DORA는 보안을 ‘보호 수단’이 아니라 운영을 유지하기 위한 필수 조건으로 끌어올린 규제라고 볼 수 있습니다.

---

DORA 개념
DORA는 EU 금융권을 대상으로 한 규제로, ICT(정보통신기술) 기반 서비스의 지속 가능성(Resilience) 을 보장하기 위한 법입니다.  규제 대상: 은행, 보험사, 투자사, 핀테크 등  적용 시점: 2025년 1월부터 적용   적용 범위: 약 2만 개 이상의 금융 및 ICT 서비스 기업 

구분	기존	보안 DORA
목적	공격 방어	서비스 지속성
관점	기술 중심	운영 리스크
범위	내부 시스템	공급망 포함
책임	보안팀	조직 전체
결과	침해 방지	장애 대응 + 복구

핵심 차이 : “침해를 막는 것” → “침해 이후에도 버티는 것”

---

DORA의 핵심 구조 (5대 Pillar) - DORA는 다음 5가지 구조로 구성됩니다.

Pillar	설명
ICT 리스크 관리	모든 IT 자산 및 위험 관리
사고 보고	주요 사고 즉시 보고
복원력 테스트	실제 공격 기반 테스트
제3자 리스크 관리	공급망 전체 통제
정보 공유	위협 정보 협력

---

DORA의 구조를 이해해야 하는 이유

DORA를 단순한 보안 규제로 이해하면 핵심을 놓치게 됩니다.

이 규제는 보안 기능을 추가하는 것이 목적이 아니라, 금융 서비스가 ICT 장애나 사이버 공격 상황에서도 중단 없이 지속될 수 있도록 운영 체계를 재구성하는 데 목적이 있습니다.

실제로 DORA는 금융기관이 ICT 관련 위협과 장애를 식별하고, 대응하며, 복구할 수 있는 능력을 갖추고 이를 지속적으로 증명해야 한다고 요구합니다 

이 요구사항이 의미하는 바는 단순합니다.

사이버 공격과 시스템 장애는 더 이상 다른 문제가 아닙니다.
두 경우 모두 동일하게 금융 서비스 중단이라는 결과를 초래하기 때문입니다.

결국 DORA는 보안을 기술적 대응 영역이 아니라 운영 리스크 관리 체계로 편입시키는 규제입니다.

---

DORA가 등장한 배경 (구조 변화 관점)

DORA는 보안 수준이 부족해서 등장한 규제가 아닙니다.
오히려 기존 보안 모델이 현재 금융 시스템 구조를 감당하지 못하기 때문에 등장했습니다.

현재 금융 시스템은 다음과 같은 구조적 특징을 가지고 있습니다.

• 클라우드 기반 인프라 확대
• 외부 SaaS 및 API 의존 증가
• 오픈소스 중심 소프트웨어 구조
• 공급망 기반 서비스 운영

이러한 구조에서 금융기관은 더 이상 자체 시스템만으로 서비스를 운영하지 않습니다.

유럽 규제기관 역시 이를 명확히 지적합니다.

ICT 의존도 증가로 인해 장애는 금융 서비스 전체에 영향을 줄 수 있다 

즉, 문제는 보안이 약한 것이 아니라 통제 가능한 영역이 줄어든 것입니다.

---

DORA의 핵심 요구사항 (재해석)

DORA는 다양한 규정으로 구성되어 있지만, 실질적으로는 다음 세 가지 요구사항으로 정리할 수 있습니다.

 

1) ICT 리스크의 전면적 식별

금융기관은 단순히 시스템 목록을 관리하는 수준을 넘어

• ICT 자산
• 데이터 흐름
• 외부 서비스 의존성
• 소프트웨어 구성 요소

까지 포함한 전체 구조를 식별하고 관리해야 합니다.

이는 일회성 관리가 아니라 지속적으로 업데이트되는 관리 체계를 의미합니다.

DORA는 이를 위해 통합된 ICT 리스크 관리 프레임워크 구축을 의무화합니다 

 

2) 사고 대응 및 보고 체계

DORA는 사고 대응을 내부 문제로 두지 않습니다.

• 사고 분류
• 보고 기준
• 대응 절차

를 명확히 정의하고, 규제기관 보고까지 포함된 체계를 요구합니다.

특히 주요 사고는 빠른 시간 내 보고가 요구되며 이는 보안 사고가 단순 기술 문제가 아니라 감독 대상 사건이 되었음을 의미합니다 

 

3) 운영 복원력(Resilience) 검증

DORA에서 가장 중요한 개념은 복원력입니다.

단순히 취약점을 제거하는 것이 아니라

• 공격 상황
• 시스템 장애
• 서비스 중단

과 같은 실제 상황에서도 서비스가 유지될 수 있는지를 검증해야 합니다.

즉, 보안의 목표가 “막는 것”이 아니라 “버티고 복구하는 것”으로 확장된 것입니다

---

SBOM이 필요한 이유 (핵심 연결)

여기서 가장 중요한 질문이 등장합니다.

DORA는 금융기관에게 ICT 리스크를 관리하라고 요구합니다.

그렇다면 무엇을 기준으로 리스크를 관리할 것인가

 

현재 조직의 현실

대부분 조직은

• 어떤 오픈소스를 사용하는지 정확히 알지 못하고
• 소프트웨어 내부 구성 구조를 파악하지 못하며
• 취약점 발생 시 영향 범위를 즉시 분석하지 못합니다

이 상태에서는 리스크 관리 자체가 성립할 수 없습니다.

 

DORA 요구사항과의 연결

DORA는

• ICT 구성 요소 식별
• 제3자 소프트웨어 추적
• 지속적인 리스크 평가

를 요구합니다

이 요구사항은 결국 소프트웨어 구성에 대한 가시성 확보를 전제로 합니다

---

SBOM의 역할 (핵심 정리)

SBOM은 단순한 목록이 아닙니다.

소프트웨어 내부 구성 요소를 구조적으로 식별하고, 취약점 영향 범위를 분석하며, 외부 의존성을 추적할 수 있도록 만드는

리스크 관리의 기반 데이터 구조입니다.

DORA는 SBOM이라는 용어를 직접 명시하지는 않지만,

• 소프트웨어 구성 요소 추적
• 공급망 가시성 확보
• 지속적 리스크 관리

와 같은 요구사항은 SBOM을 통해 가장 현실적으로 구현될 수 있습니다 

결론적으로 SBOM이 없는 상태에서는 DORA가 요구하는 수준의 리스크 관리 체계를 구축하기 어렵습니다.

---

DORA는 단순한 보안 규제가 아닙니다.

이 규제는 금융 산업에서 보안을 바라보는 기준 자체를 변화시키고 있습니다.

기술 중심으로 운영되던 보안은 이제 운영 리스크 관리 체계의 일부로 편입되고 있으며, 그 과정에서 가시성 확보, 공급망 통제, 그리고 운영 복원력 확보가 핵심 요소로 자리 잡고 있습니다.

특히 DORA는 단순히 보안 수준을 높이는 것이 아니라, 금융 서비스가 어떠한 상황에서도 중단되지 않도록 하기 위한 운영 구조 자체의 변화를 요구한다는 점에서 의미가 큽니다. 

이러한 요구사항을 실제로 구현하기 위해서는 시스템과 소프트웨어에 대한 구조적 이해가 필수적이며, 그 출발점이 바로 소프트웨어 구성 가시성 확보입니다.

SBOM은 이 가시성을 확보하기 위한 가장 현실적인 방법이며, DORA가 요구하는 ICT 리스크 관리 체계를 기술적으로 뒷받침하는 핵심 요소로 볼 수 있습니다.

결국 DORA는 다음과 같은 방향을 제시합니다.

보안은 기술이 아니라 운영이다
리스크는 내부가 아니라 공급망까지 포함된다
시스템은 보호 대상이 아니라 지속해야 할 서비스다

이 변화는 유럽에 국한된 것이 아니라 향후 글로벌 규제 흐름으로 확장될 가능성이 높다.

따라서 지금 시점에서 DORA를 이해하는 것은 단순한 규제 대응을 넘어,
앞으로의 사이버보안이 어떤 방향으로 진화할지를 이해하는 과정이라고 볼 수 있다.