DORA와 NIS2 인시던트 보고: 시간이 다 가기 전에 전화를 받으세요

보고 기한이 실제로 요구하는 것
보고 기한이 사실은 깨우기 문제인 이유
주말은 시간을 더 벌어 주나요?
보고 절차 앞에 울리는 전화를 두는 방법
1단계 — 보고 대상 인시던트 전용 전화 채널 만들기
2단계 — 탐지 스택을 그 Webhook으로 연결하기
3단계 — 조건을 사용해 그럴듯한 후보만 울리게 하기
4단계 — 이메일만 보내는 시스템 챙기기
5단계 — 기한을 책임지는 사람들을 같은 채널에 두기
6단계 — 방해 금지를 켠 상태로 테스트하기
Echobell이 하지 않는 일
FAQ
Echobell을 쓰면 DORA나 NIS2를 준수하게 되나요?
DORA의 4시간 시계는 정확히 언제 시작되나요?
NIS2 조기 경보에 인시던트의 전체 내용을 담아야 하나요?
저희 모니터링은 이미 온콜 엔지니어에게 이메일을 보냅니다. 그걸로 충분하지 않나요?
컴플라이언스와 엔지니어링이 같은 알림을 받을 수 있나요?
전화가 정말로 방해 금지를 뚫고 오나요?
iOS 전용인가요?
Webhook 페이로드에는 어떤 데이터를 담아야 하나요?
관련 글

EU의 인시던트 보고 기한은 모두 기계가 무언가를 감지한 순간부터 세기 시작하고, 팀이 잠든 동안에도 계속 흘러갑니다. 시계를 시작시킨 그 알림이 일요일 새벽 2시 40분에 조용한 푸시 알림으로 도착한다면, 사람이 한 명이라도 그것을 읽기 전에 이미 DORA 보고 기한의 4분의 1을 태워 버린 셈입니다. 이 가이드는 Echobell로 실제로 울리는 전화를 보고 절차 앞에 두는 방법을 보여 줍니다. 시계와 여러분의 대응이 거의 같은 시각에 출발하도록 말입니다.

이 문제의 규모는 이제 추측이 아니라 측정된 값입니다. 2026년 6월 3일, 세 곳의 유럽 감독 당국은 DORA에 따라 보고된 중대한 ICT 관련 인시던트에 대한 첫 EU 전역 개관을 발표했습니다. 2025년 한 해 중대 인시던트 3,383건, 적용 대상 금융기관당 평균 0.18건, 그중 약 3분의 1이 국경을 넘는 영향을 미쳤습니다 (EBA, ESMA). 알림 설계에 반영해야 할 대목은 이것입니다. 이 가운데 10%만이 사이버 보안과 관련된 것이었습니다. 주된 원인은 시스템 장애와 외부 사건이었습니다.

달리 말하면, 규제 시계를 시작시키는 사건은 압도적으로 평범한 것들입니다. 실패한 배포, 죽은 의존성, 공급자 장애 같은 것들이죠. 여러분의 모니터링이 이미 새벽 3시에 잡아내어, 방해 금지가 켜진 휴대폰으로 보내고 있는 바로 그것들입니다.

보고 기한이 실제로 요구하는 것

세 가지 제도, 세 가지 서로 다른 출발 신호 — 그리고 셋 모두 실시간으로 흘러갑니다. 현행 조문이 말하는 내용은 다음과 같습니다.

제도	첫 기한	그다음	마지막
DORA (EU 금융기관)	인시던트를 중대한 것으로 분류한 뒤 4시간 이내, 늦어도 인지 시점부터 24시간 이내에 최초 통지	최초 통지 후 늦어도 72시간 이내에 중간 보고서	(마지막) 중간 보고서 후 늦어도 1개월 이내에 최종 보고서
NIS2 (EU 필수 기관 및 중요 기관)	부당한 지체 없이, 어떠한 경우에도 상당한 인시던트를 인지한 뒤 24시간 이내에 조기 경보	인지 후 72시간 이내에 인시던트 통지	인시던트 통지 후 늦어도 1개월 이내에 최종 보고서
SEC Item 1.05 (미국 상장기업)	인시던트가 중요하다고 판단한 뒤 일반적으로 영업일 4일 이내에 Form 8-K 제출	—	—

DORA의 기한은 인시던트 보고의 내용과 시한을 정한 규제기술표준인 위임규정 (EU) 2025/301에서 나옵니다. 이 규정은 2025년 2월 20일에 공표되었으며 규정 (EU) 2022/2554를 보충합니다 (유럽연합 집행위원회, 제5조 조문). DORA 자체는 2025년 1월 17일부터 적용되고 있습니다 (ESMA).

NIS2의 기한은 지침 (EU) 2022/2555 제23조 제4항에 있습니다. 회원국은 2024년 10월 17일까지 이를 국내법으로 전환해야 했습니다 (유럽연합 집행위원회). SEC 기한은 2023년 7월 26일에 채택된 사이버 보안 공시 규칙에서 나옵니다 (SEC).

보고 기한이 사실은 깨우기 문제인 이유

어느 시계도 여러분의 근무 시간에 매여 있지 않기 때문입니다. DORA는 분류 시점과 기관이 인지한 시점부터 잽니다. NIS2는 기관이 인지한 시점부터 잽니다. SEC는 중요성 판단 시점부터 잽니다. 특정 순간이 “인지”에 해당하는지는 컴플라이언스 부서가 내리는 법적 판단입니다. 그러나 이들 조문 어디에도 알림을 처음 본 사람이 마침 자고 있었다는 이유로 계산을 다시 시작한다는 내용은 없습니다.

DORA에서 가장 빡빡한 경로를 거꾸로 계산해 보십시오. 인시던트가 중대한 것으로 분류된 순간부터 4시간이 주어지는데, 분류는 사람이 들여다보기 전에는 이루어질 수 없습니다. 탐지가 새벽 2시 40분에 이루어지고, 아무도 오전 8시까지 확인하지 않으며, 분류에 90분의 조사가 더 든다면, 최초 통지는 오전 11시쯤 제출하게 됩니다. 24시간이라는 바깥 한계 안이기는 하지만, 24시간 상한 가운데 여덟 시간 넘게를 순전히 잠으로 써 버린 것입니다. 확인까지의 간격을 줄이면 그 뒤의 모든 단계가 숨 쉴 여유를 얻습니다.

더 많은 것에 대해 알림을 울리자는 이야기가 아닙니다. 아주 좁은 한 부류의 알림, 즉 보고 대상이 될 여지가 있는 알림만큼은 물리적으로 자면서 놓칠 수 없게 만들자는 이야기입니다. 나머지는 조용해야 합니다. (팀이 이미 알림에 파묻혀 있다면, 더 시끄러운 채널을 추가하기 전에 알림 피로 해결부터 시작하세요.)

주말은 시간을 더 벌어 주나요?

DORA에서는 조금 벌어 줍니다. 다만 여러분에게는 해당되지 않을 가능성이 큽니다. 위임규정 (EU) 2025/301은 기한이 주말이나 소속 회원국의 공휴일에 걸리는 금융기관에 대해 다음 영업일 정오까지 제출할 수 있도록 허용합니다. 그러나 같은 조문은 신용기관, 중앙청산소, 거래소 운영자, 그리고 NIS2상 필수 기관이나 중요 기관에는 이 연장을 허용하지 않습니다. 소관 당국은 시스템적으로 중요한 다른 기관에 대해서도 이를 배제할 수 있습니다 (제5조, Advisera 요약).

결국 일요일 밤에 인시던트가 발생할 가능성이 가장 높은 조직이야말로 주말 완화를 받지 못하는 쪽입니다. NIS2 제23조에는 주말 연장 규정이 아예 없습니다. 시계가 화요일과 똑같이 토요일에도 흘러간다는 전제로 계획하고, 자격이 되는 연장은 완충 장치가 아니라 덤으로 여기시기 바랍니다.

보고 절차 앞에 울리는 전화를 두는 방법

Echobell은 한 가지 일을 합니다. Webhook 호출이나 이메일을 전화로 바꾸는 것입니다. 가족에게서 걸려 온 전화가 그렇듯 iOS의 집중 모드와 방해 금지를 뚫고 실제로 울리고 진동하는 전화입니다 (중요한 알림을 위해 iOS 집중 모드 우회하기 참고). Echobell은 인시던트를 탐지하는 시스템과 시계를 시작시켜야 하는 사람 사이에 놓입니다.

1단계 — 보고 대상 인시던트 전용 전화 채널 만들기

Echobell에서 채널을 만들고 알림 유형을 전화(Calling)로 설정하세요. 조용한 푸시를 보내는 대신 휴대폰을 울리게 하는 것이 바로 이 설정입니다 (알림 유형). “보고 대상 인시던트 — 일어나세요”처럼 오해의 여지가 없는 이름을 붙이고, 다른 용도로는 쓰지 마세요. 채널 상세에서 채널의 Webhook URL을 복사하세요. https://hook.echobell.one/t/<channel-token> 형태입니다. 이 URL은 비밀로 취급해야 합니다.

2단계 — 탐지 스택을 그 Webhook으로 연결하기

인시던트를 감지하는 것이 무엇이든, 그 시스템이 채널 URL로 HTTP 요청을 보내면 됩니다. Echobell에는 Grafana, Prometheus Alertmanager, Uptime Kuma, UptimeRobot용 전용 가이드가 있고, JSON을 POST할 수 있는 그 밖의 모든 것은 Webhook 가이드를 통해 연동됩니다. 쓸모 있는 페이로드라면 노트북을 열지 않고도 첫 분류 판단을 내릴 만큼의 정보를 담고 있어야 합니다.

{
  "title": "보고 대상 후보: {{service}}",
  "message": "{{service}} 장애 시작 {{started_at}} — 고객 영향: {{client_impact}}",
  "externalLink": "https://status.internal.example/incident/{{id}}"
}

externalLink 변수는 알림 기록에서 클릭 가능한 링크가 되므로, 전화를 받은 사람은 곧바로 해당 인시던트로 이동합니다.

3단계 — 조건을 사용해 그럴듯한 후보만 울리게 하기

모든 경고마다 울리는 전화는 더 이상 전화가 아니라 배경 소음이 됩니다. Echobell의 조건은 AND/OR 논리로 변수 값을 걸러 내므로, 예를 들어 채널이 누군가에게 전화를 걸기 전에 severity == "critical" 그리고 client_impact == true를 모두 요구할 수 있습니다. 그 기준에 못 미치는 것은 전부 별도의 긴급 채널이나 일반 채널로 보내세요. 보고 대상 인시던트 채널은 매주가 아니라 1년에 몇 번만 울려야 합니다.

4단계 — 이메일만 보내는 시스템 챙기기

많은 공급업체의 상태 피드와 이상거래 탐지 도구, 제3자 제공업체는 오직 이메일로만 알립니다. 공급자 측 장애가 명백히 적용 범위에 들어가는 DORA에서는 특히 중요한 대목입니다. Echobell의 모든 채널은 각자의 주소를 가질 수 있으므로, 전달 규칙 하나면 그런 메시지가 전화로 바뀝니다 (이메일 트리거, 이메일을 전화로 연결하기).

5단계 — 기한을 책임지는 사람들을 같은 채널에 두기

인시던트를 찾아내는 것은 엔지니어링이지만, 기한을 책임지는 것은 컴플라이언스나 당직자, 또는 DPO입니다. 채널을 공유하면 구독자마다 각자의 긴급도를 고르므로, 온콜 엔지니어는 전화를 받고 두 번째 대응자는 긴급 알림을 받게 할 수 있습니다. 실패한 통화 재시도를 켜 두면 집중 모드에 막힌 전화를 다시 시도합니다.

6단계 — 방해 금지를 켠 상태로 테스트하기

적어도 분기에 한 번은, 중요한 모든 휴대폰에서 방해 금지를 켠 상태로 테스트 Webhook을 보내 보세요. 테스트하지 않은 에스컬레이션 경로는 가정일 뿐이고, 사후 검토는 바로 그런 가정들로 채워집니다.

Echobell이 하지 않는 일

규제를 받는 절차에서는 이 부분을 정확하게 말하는 것이 다른 어디에서보다 중요합니다.

Echobell이 하는 일: Webhook 호출이나 이메일을 울리는 전화, 긴급 알림, 또는 일반 푸시로 바꿉니다. 전화 알림에 대해서는 iOS의 집중 모드와 방해 금지를 뚫습니다. 조건과 템플릿으로 걸러 냅니다. 같은 알림을 공유된 팀 채널로 전달합니다.

Echobell이 하지 않는 일:

인시던트를 분류하지 않습니다. 어떤 사건이 DORA의 “중대한(major)” 인시던트인지, NIS2의 “상당한(significant)” 인시던트인지, SEC 규칙의 “중요한(material)” 사항인지에 대해 아무런 견해도 갖고 있지 않습니다. 그것은 관련 조문의 기준에 비추어 여러분의 사람들이 내리는 판단입니다.
어디에도 무언가를 제출하지 않습니다. 소관 당국이나 CSIRT, SEC에 신고하지 않습니다. 사람이 신고할 수 있는 지점까지 데려다 놓을 뿐입니다.
기록 보관 시스템이나 GRC 시스템 역할을 하지 않습니다. 이들 제도는 알림 앱이 만들어 내지 못하는 문서와 등록부, 증거를 요구합니다. Echobell은 의도적으로 알림 내용과 기록을 기기에만 저장하고 서버에는 계정과 채널, 구독만 둡니다 (개인정보 모델). 데이터 최소화에는 좋지만 감사 추적으로는 쓸모가 없습니다.
컴플라이언스 증명을 제공하지 않습니다. 인증서도, 감사 보고서도, 계약상 SLA도 딸려 오지 않습니다. 규제를 받는 절차에 도입한다면 다른 도구와 마찬가지로 자체 ICT 제3자 위험 관리 절차를 거치게 하고, 여기에 의존하지 않는 경로도 하나 남겨 두세요.
전달을 보장하지 않습니다. 전화는 푸시 인프라와 네트워크, 충전된 휴대폰에 달려 있습니다. 감사에서 가리킬 수 있는 통제 수단이 아니라, 확인까지 걸리는 시간을 크게 줄여 주는 계층으로 여기시기 바랍니다.

솔직하게 정리하면 이렇습니다. 어떤 앱이 여러분의 휴대폰을 울리든 규제상 의무는 달라지지 않습니다. 전화가 바꾸는 것은 기계가 무언가를 감지한 순간과 사람이 판단을 내리는 순간 사이의 시간입니다. 그리고 4시간짜리 시계 아래에서 그 시간은 전체 예산의 대부분을 차지합니다.

FAQ

Echobell을 쓰면 DORA나 NIS2를 준수하게 되나요?

아닙니다. 컴플라이언스는 거버넌스와 분류 절차, 문서화, 그리고 소관 당국이나 CSIRT에 대한 실제 제출에 달려 있습니다. Echobell은 탐지와 사람의 확인 사이의 간격을 줄일 뿐입니다. 절차 그 자체가 아니라 절차에 들어가는 하나의 입력입니다.

DORA의 4시간 시계는 정확히 언제 시작되나요?

분류 시점입니다. 위임규정 (EU) 2025/301에 따르면 최초 통지는 인시던트를 중대한 것으로 분류한 뒤 4시간 이내에, 그리고 어떠한 경우에도 기관이 이를 인지한 순간부터 24시간 이내에 이루어져야 합니다. 이 둘은 별개의 요건이고 양쪽을 모두 충족해야 합니다. 빠른 알림만큼이나 빠른 분류 판단이 중요한 이유가 여기에 있습니다.

NIS2 조기 경보에 인시던트의 전체 내용을 담아야 하나요?

아닙니다. 지침 (EU) 2022/2555 제23조 제4항은 24시간 조기 경보를 의도적으로 잠정적인 것으로 두었습니다. 인시던트가 불법 행위나 악의적 행위로 인한 것으로 의심되는지, 그리고 국경을 넘는 영향을 미칠 수 있는지만 밝히면 됩니다. 더 자세한 그림은 72시간 통지의 몫이고, 근본 원인 분석은 한 달 뒤 최종 보고서의 몫입니다.

저희 모니터링은 이미 온콜 엔지니어에게 이메일을 보냅니다. 그걸로 충분하지 않나요?

누군가 깨어서 보고 있다면 충분합니다. 이메일과 일반 푸시 알림은 집중 모드와 방해 금지, 수면 일정에 의해 무음 처리됩니다. 시계가 가장 인정사정없는 밤과 주말이 바로 그 조건에 해당합니다. 문제는 탐지가 아니라 확인입니다.

컴플라이언스와 엔지니어링이 같은 알림을 받을 수 있나요?

네. 채널을 공유하면 구독한 모든 사람이 트리거를 받고, 각자 알림 유형을 고릅니다. 흔한 구성은 이렇습니다. 온콜 엔지니어는 전화(Calling)로 구독하고, 당직 컴플라이언스 담당자는 보고 대상 인시던트 채널만 전화(Calling)로, 나머지는 긴급(Time Sensitive)으로 구독합니다.

전화가 정말로 방해 금지를 뚫고 오나요?

Echobell의 전화(Calling) 알림 유형은 iOS의 집중 모드와 방해 금지를 뚫고 울리도록 설계되어 있고, 실패한 통화 재시도 설정은 집중 모드에 막힌 전화를 다시 시도합니다. 의존하기 전에 대응자 각자의 실제 기기에서 확인하세요. OS 설정과 버전에 따라 동작이 다릅니다.

iOS 전용인가요?

아닙니다. Echobell은 iOS와 Google Play를 통한 Android에서 모두 쓸 수 있습니다 (Android 출시 소식 참고). 통화 형태 알림의 동작은 플랫폼마다 다르므로, 대응자가 실제로 들고 다니는 기기에서 테스트하세요.

Webhook 페이로드에는 어떤 데이터를 담아야 하나요?

가능한 한 적게 담으세요. 고객 정보나 인시던트의 구체적 내용 대신 식별자와 링크를 보내세요. externalLink 변수로 그런 정보를 담기 위해 만들어진 시스템에 놓인 인시던트 기록을 가리키면 됩니다. 알림의 역할은 누군가를 깨우는 것이지, 브리핑하는 것이 아닙니다.