CRA의 24시간 시계는 2026년 9월 11일에 시작됩니다: 반드시 누군가 받게 하세요

2026년 9월 11일에 정확히 무엇이 시작되나요?
실제로 의무를 지는 주체는 누구인가요?
24시간 기한은 왜 알림 문제인가요?
24시간 조기 경보에는 실제로 무엇이 들어가나요?
24시간 시계 앞에 울리는 전화를 어떻게 두나요?
1단계 — CRA 후보 전용 전화 채널 만들기
2단계 — 탐지 경로를 채널로 연결하기
3단계 — 조건을 사용해 그럴듯한 후보만 울리게 하기
4단계 — 이메일만 보내는 시스템 챙기기
5단계 — 등록된 대표자를 모두 채널에 넣기
6단계 — 9월 11일 이후가 아니라 그 전에 예행연습하기
Echobell이 하지 않는 일
FAQ
Echobell을 쓰면 CRA를 준수하게 되나요?
24시간 시계는 정확히 언제 시작되나요?
저희는 작은 회사입니다. 면제되나요?
저희 보안 메일함은 업무 시간에 모니터링합니다. 그걸로 충분하지 않나요?
컴플라이언스, 법무, 엔지니어링이 같은 알림을 받을 수 있나요?
제14조 제8항의 이용자 통지 의무에도 도움이 되나요?
저희는 이미 NIS2나 DORA에 따라 보고하고 있습니다. 같은 건가요?
전화가 정말로 방해 금지를 뚫고 오나요?
iOS 전용인가요?
Webhook 페이로드에는 무엇을 담아야 하나요?
관련 글

2026년 9월 11일, EU 사이버 복원력법(Cyber Resilience Act, CRA)의 보고 의무가 적용되기 시작합니다. 이날부터 디지털 요소를 갖춘 제품에서 실제로 악용되고 있는 취약점을, 또는 그러한 제품에 영향을 미치는 심각한 인시던트를 인지한 제조자는 24시간 안에 조정 CSIRT와 ENISA에 조기 경보를 보내야 합니다 (유럽연합 집행위원회, 규정 (EU) 2024/2847).

이 기한에는 다른 컴플라이언스 기한 대부분에 없는 성질이 하나 있습니다. 벽시계 시간으로 흘러간다는 점입니다. 영업일 예외도, 주말 중단도, 보고 담당자가 비행기에 타고 있는 동안의 유예도 없습니다. 게다가 제출 창구인 ENISA의 Single Reporting Platform은 웹 양식입니다. “현 단계에서는 어떠한 응용 프로그램 인터페이스도 제공되지 않습니다”(ENISA FAQ). 지정된 사람이 직접 로그인해 제출해야 합니다.

그래서 24시간 규칙은 서류 문제이기 이전에 알림 문제입니다. 이 가이드는 인지한 그 순간을 Echobell로 울리는 전화까지 연결하는 방법을 보여 주고, 어떤 알림 도구도 건드리지 못하는 CRA 준비의 큰 부분에 대해서도 솔직하게 짚습니다.

2026년 9월 11일에 정확히 무엇이 시작되나요?

디지털 요소를 갖춘 제품의 제조자는 실제로 악용되는 취약점과 심각한 인시던트를 하나의 EU 플랫폼을 통해, 인지한 순간부터 흘러가는 단계별 시계에 맞춰 보고해야 합니다. CRA의 나머지 부분, 즉 CE 마킹과 부속서 I의 필수 요구사항, 적합성 평가는 2027년 12월 11일부터 적용됩니다. 보고 의무는 그보다 열다섯 달 먼저 도래하고, 기준일 이후에 출시하는 제품뿐 아니라 이미 시장에 나와 있는 제품에도 적용됩니다 (cyberresilienceact.eu).

제14조는 형태가 같은 두 갈래를 병렬로 정의합니다.

단계	실제로 악용되는 취약점 — 제14조 제2항	심각한 인시던트 — 제14조 제4항
조기 경보	인지 후 24시간 이내	인지 후 24시간 이내
통지	인지 후 72시간 이내	인지 후 72시간 이내
최종 보고서	시정 또는 완화 조치가 마련된 뒤 늦어도 14일 이내	72시간 통지 후 1개월 이내

조문의 표현은 “부당한 지체 없이, 어떠한 경우에도 제조자가 이를 인지한 때로부터 24시간 이내”입니다 (제14조). 24시간은 상한이지 목표가 아닙니다.

제14조 제5항은 “심각한”의 기준을 정합니다. 민감하거나 중요한 데이터 또는 기능의 가용성, 진정성, 무결성, 기밀성을 보호하는 제품의 능력에 부정적인 영향을 미치거나 미칠 수 있는 경우, 또는 악성 코드의 유입이나 실행으로 이어졌거나 이어질 수 있는 경우가 여기에 해당합니다. “~할 수 있는”이라는 표현이 중요합니다. 고객에게 실제로 문제가 생기기 전에도 보고 의무가 발생할 수 있기 때문입니다.

제14조 제8항은 병렬로 진행되는 두 번째 의무를 더합니다. 영향을 받는 제품 이용자에게도 해당 취약점이나 인시던트를, 그리고 필요한 경우 이용자가 취할 수 있는 시정 조치를 알려야 한다는 것입니다. CSIRT와는 다른 대상이며, 별도의 경로를 탑니다.

실제로 의무를 지는 주체는 누구인가요?

설립지와 무관하게 디지털 요소를 갖춘 제품의 제조자, 그리고 더 좁은 범위에서 오픈소스 소프트웨어 스튜어드입니다. EU 밖에 있는 기업이라도 역내에 판매한다면 의무를 피할 수 없습니다. 규정은 관련 의무를 책임지는 경제 운영자가 EU 안에 있을 것을 전제합니다 (cyberresilienceact.eu).

보고는 역내 주된 사업장이 있는 회원국에서 조정자로 지정된 CSIRT와 ENISA에 동시에 이루어지지만, 제출은 Single Reporting Platform을 통해 한 번만 하면 되고 플랫폼이 양쪽으로 전달합니다 (유럽연합 집행위원회).

오픈소스 소프트웨어 스튜어드는 명확히 한정된 범위에서만 적용 대상입니다. 제14조 제1항의 의무는 이들이 디지털 요소를 갖춘 제품의 개발에 관여하는 범위에서 적용되고, 제14조 제3항과 제8항은 심각한 인시던트가 그 개발을 위해 이들이 제공하는 네트워크·정보 시스템에 영향을 미치는 범위에서 적용됩니다. 널리 쓰이는 프로젝트를 관리하고 있다면 양극단 중 하나를 넘겨짚기보다 제24조를 제14조와 함께 읽어 보시기 바랍니다.

제15조는 제조자를 비롯한 누구든 취약점, 사이버 위협, 인시던트, 아차 사고를 자발적으로 신고할 수 있도록 허용합니다. 자발적 신고가 새로운 의무를 만들지는 않지만, 플랫폼은 같고 “누군가는 깨어 있어야 한다”는 문제도 똑같이 따라옵니다.

24시간 기한은 왜 알림 문제인가요?

인지한 시점에 시계가 시작되는데, 인지는 좀처럼 업무 시간에 찾아오지 않기 때문입니다. 트리거는 조직이 내리는 결정이 아니라 조직에 도달하는 사실입니다.

그 사실이 대개 어디에서 오는지 보십시오. 토요일 밤 23시 40분에 보안 연구자가 security@로 메일을 보냅니다. 하위 고객이 악용 정황을 설명하는 지원 티켓을 엽니다. 여러분이 출하하는 구성 요소를 두고 CVE나 KEV 피드에 불이 들어옵니다. 자체 EDR이 빌드 시스템에서의 코드 실행을 탐지합니다. DLA Piper의 준비 자료는 이 문제의 공급망 버전을 특히 짚습니다. 제조자가 가장 먼저 알게 되는 경우는 오히려 드물고, 정보는 수입업자와 유통업자, 연구자, 부품 공급업체를 통해 들어온다는 것입니다 (DLA Piper).

이 모든 경로는 지금의 설정이라면 십중팔구 조용히 전달되는 알림으로 끝납니다. 공용 메일함에 쌓이는 이메일, 밤새 아무도 보지 않는 채널의 Slack 메시지, 월요일에야 분류되는 대기열의 티켓처럼 말입니다. 어느 하나도 실패하지 않습니다. 모두 정확하게 전달됩니다. 아무에게도 닿지 않을 뿐입니다.

세 가지 세부 사항이 이 간극을 보기보다 더 크게 만듭니다.

API가 없습니다. ENISA는 현 단계에서 보고용 API를 제공하지 않는다고 분명히 밝혔습니다. 모두가 자는 동안 스크립트가 대신 조기 경보를 제출하게 할 수는 없습니다.
접근 권한은 사람 단위로, 미리 준비해 두어야 합니다. 권한을 위임받은 대표자는 EU Login 계정으로 등록하고, 지정된 조정 CSIRT가 최초 접속 이후 그 권한을 검증합니다. 주 대표자와 예비 대표자를 두는데, 예비 대표자에게 보낸 초대는 7일이 지나면 만료됩니다 (ENISA FAQ, cyberresilienceact.eu). 제출할 수 있는 유일한 사람과 연락이 닿지 않아도 기한은 기다려 주지 않습니다.
과징금 구간은 가장 높은 쪽입니다. 제64조는 제13조와 제14조의 의무 위반을 “1,500만 유로 또는, 위반자가 사업체인 경우 직전 회계연도 전 세계 연간 총매출의 2.5% 중 더 높은 금액까지”의 행정 과징금 구간에 넣습니다 (제64조).

마지막 항목에는 작은 팀이라면 계산이 달라질 만한 솔직한 단서가 하나 붙습니다. 제64조는 영세기업이나 소기업에 해당하는 제조자를 제14조 제2항 (a)호나 제14조 제4항 (a)호의 기한 미준수에 따른 행정 과징금에서 제외합니다. 다시 말해 24시간 조기 경보에 한정된 이야기입니다. 보고 의무 자체는 그대로 남고, 이 면제는 72시간 통지나 제14조의 나머지 부분까지 확장되지 않습니다. 우리 회사가 어디에 해당하는지는 블로그 글의 말을 믿기보다 조문을 직접 읽고 자문을 구하시기 바랍니다.

24시간 조기 경보에는 실제로 무엇이 들어가나요?

아주 적습니다. 그리고 그것이 핵심입니다. ENISA의 안내는 조기 경보 단계의 필수 항목을 작게 잡고 있습니다. 신고 유형(취약점 또는 인시던트), 신고 수준, 신고 시각, 신고자 정보, 제조자 또는 스튜어드 이름, 제품, 제목, 그리고 인시던트의 경우 불법 행위나 악의적 행위가 의심되는지 여부입니다. 이 단계의 선택 항목으로는 CVE ID나 EUVD ID가 있습니다.

더 자세한 기술적 그림, 즉 취약점이나 익스플로잇의 일반적 성격과 초기 평가, 시정 및 완화 조치는 첫 24시간이 아니라 72시간 통지의 몫입니다.

그러니 조기 경보는 연구 과제가 아닙니다. 준비된 사람이라면 몇 분 만에 제출할 수 있는 짧은 양식입니다. 발목을 잡는 것은 양식이 아닙니다. 등록되어 있고 권한이 있으며 깨어 있는 사람이 제때 그 사실을 알게 되는지가 관건입니다. 이는 알림 라우팅 문제이고, 오늘 당장 해결할 수 있습니다.

24시간 시계 앞에 울리는 전화를 어떻게 두나요?

Echobell은 Webhook 호출이나 이메일을 걸려 오는 전화처럼 울리고 진동하는 알림으로 바꿔 줍니다. 그래서 iOS의 집중 모드와 방해 금지를 뚫고 들어갑니다(iOS 집중 모드 우회하기 참고). 아래 설정은 이미 운영 중인 티켓 및 PSIRT 프로세스와 나란히 놓이는 것이지, 그것을 대체하지 않습니다.

1단계 — CRA 후보 전용 전화 채널 만들기

앱에서 채널을 만들고 알림 유형을 **전화(Calling)**로 설정하세요(알림 유형). 데이터 출처가 아니라 이 채널이 촉발하는 결정을 기준으로 이름을 붙이십시오. “보안 알림”보다 “CRA — 24시간 시계가 시작됐을 수 있음”이 낫습니다.

이 채널은 조용해야 합니다. 모든 권고문, 실패한 스캔, 의존성 업데이트마다 울린다면 사람들은 더 이상 받지 않게 되고, 단 하나뿐인 시끄러운 채널을 잡음에 써 버리게 됩니다. 그런 것들은 다른 곳으로 보내세요. 분리 방법은 알림 피로 해결 가이드에서 다룹니다.

채널 상세에서 Webhook URL을 복사하세요. https://hook.echobell.one/t/<channel-token> 형태입니다. 이 URL을 가진 사람은 누구나 팀의 전화를 울릴 수 있으므로 비밀로 취급해야 합니다(Webhook 가이드).

새벽 2시에 반쯤 잠든 사람이 잠금 화면에서 읽을 수 있는 템플릿을 설정하세요.

제목: CRA 보고 가능성 — {{product}}
본문: {{kind}} — {{summary}} ({{time}} UTC부터 인지)

{{time}}, {{date}}, {{hour}}을 비롯한 시스템 시간 변수는 항상 UTC로 주입되므로, 보내는 쪽이 시각을 빠뜨려도 알림에는 타임스탬프가 남습니다. 이 타임스탬프가 인지 시점을 입증하는 법적 증거는 아니지만, 나중에 타임라인을 재구성할 때 유용한 기준점이 됩니다.

2단계 — 탐지 경로를 채널로 연결하기

Webhook을 호출할 수 있는 시스템이라면 무엇이든 채널을 트리거할 수 있습니다. 보낸 필드는 그대로 템플릿 변수가 됩니다.

curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H "Content-Type: application/json" \
  -d '{
    "product": "Acme Gateway 4.x",
    "kind": "실제로 악용되고 있는 취약점",
    "summary": "연구자 보고, 동작하는 익스플로잇 첨부",
    "craCandidate": true,
    "externalLink": "https://issues.internal.example/PSIRT-4412"
  }'

externalLink 특수 변수는 알림 기록에서 클릭 가능한 링크가 되므로, 전화를 받은 사람은 한 번의 탭으로 세부 내용이 담긴 티켓에 도달합니다.

첫 신호가 되는 빈도가 높은 순서대로, 연결해 둘 만한 것들은 다음과 같습니다.

PSIRT 또는 보안 접수 대기열 — 이슈가 CRA 후보로 표시될 때 보내는 Webhook.
출시 제품을 빌드하는 저장소의 GitHub 보안 권고와 Dependabot 알림 (GitHub 연동).
빌드·릴리스·서명 인프라에 대한 탐지를 위한 SIEM, EDR, WAF — 제14조 제5항은 악성 코드 유입으로 이어질 수 있는 인시던트를 명시적으로 포함합니다.
이미 구독 중인 취약점 인텔리전스 피드를 자체 SBOM에 등장하는 구성 요소로 필터링한 것.

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

채널의 신뢰를 지키는 단계입니다. Echobell의 조건은 템플릿에서 쓰는 것과 같은 변수와 HTTP 헤더를 평가하며, 표현식이 참일 때만 채널이 실행됩니다.

craCandidate == true && confirmed == true

보내는 쪽 시스템이 본문을 원하는 형태로 만들 수 없다면 헤더로 걸러도 됩니다.

header["x-cra-severity"] == "reportable"

임계값은 “이건 확실히 보고 대상이다”가 아니라 “역량 있는 사람이 한 시간 안에 살펴봐야 한다”에 맞추세요. 제14조가 적용되는지 판단하는 일은 사실관계를 쥔 사람이 해야 하는 판단이고, 채널의 역할은 그 사람을 사실관계 앞에 빨리 데려다 놓는 것입니다. 여기서는 지나치게 걸러 내는 쪽이 비싼 실수입니다. 굳이 필요하지 않았던 전화 한 통보다 아예 시작조차 못 한 보고가 더 나쁘기 때문입니다.

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

회사 밖에서 오는 첫 연락은 대개 이메일입니다. 연구자도, 고객도, 국가 CSIRT도, 부품 공급업체도 그렇습니다. Echobell의 모든 채널은 각자의 주소를 가질 수 있으므로, security@에 전달 규칙 하나만 걸어 두면 그런 메시지가 전화로 바뀝니다(이메일 트리거).

이메일 트리거는 from, to, subject, text, html을 변수로 제공하므로 따로 파싱하지 않고도 필터링할 수 있습니다.

subject != "" && (from == "cert@vendor.example" || subject == "[EXPLOITED]")

정기적으로 제보하는 상대와 주요 공급업체에 합의된 제목 표시를 사용해 달라고 요청한 뒤 그것으로 매칭하세요. 구조화되지 않은 메일함을 라우팅 가능한 신호로 바꾸는 작은 계약상의 디테일입니다.

5단계 — 등록된 대표자를 모두 채널에 넣기

실제로 제출할 수 있는 모든 사람과 채널을 공유하세요. 주 권한 대표자, 예비 대표자, 그리고 제14조 판단을 내릴 수 있는 보안 책임자입니다. 구독자는 각자 알림 유형을 고르므로, 당번인 사람은 **전화(Calling)**로 두고 나머지 인원은 **긴급(Time Sensitive)**으로 받을 수 있습니다.

이것이 이 작업의 핵심입니다. SRP는 등록되고 검증된 사람을 요구합니다. 회사에서 등록된 사람이 정확히 한 명이라면, 여러분의 24시간 기한은 휴대폰 배터리에 달린 단일 장애점을 갖게 됩니다.

6단계 — 9월 11일 이후가 아니라 그 전에 예행연습하기

이번 달에 해 볼 만한 예행연습 두 가지입니다.

알림 경로. 실제로 누군가의 머리맡에 놓일 그 휴대폰에서 방해 금지를 진짜로 켠 상태로 위의 curl을 실행해 보세요. 앱에서 실패한 통화 재시도를 켜 두면 한 번 실패한 전화를 다시 시도합니다. 테스트하지 않은 에스컬레이션 경로는 가정일 뿐입니다.
제출 경로. 2026년 8월까지 갱신된 ENISA의 단계별 등록·제출 안내를 따라가며 보고서를 종이 위에서 한 번 훑어보세요(ENISA SRP). EU Login 계정은 지금 만들고, 어느 CSIRT가 조정자인지 확인하고, 예비 대표자 초대는 일찍 보내세요. 7일이 지나면 만료됩니다.

두 번째 예행연습에는 알아 둘 만한 걸림돌이 있습니다. ENISA의 7월 안내 기준으로 플랫폼의 공개 URL은 여전히 “출시 시 제공 예정”으로 표기되어 있어서, 실제 종단 간 테스트는 아직 불가능했습니다(cyberresilienceact.eu). ENISA는 2026년 9월 11일까지 플랫폼을 가동하겠다고 약속했습니다. 통제할 수 있는 부분은 모두 예행연습하고, 플랫폼의 준비 상태를 여러분 자신의 준비를 미룰 이유로 삼지 마세요.

Echobell이 하지 않는 일

주제가 규제인 만큼 여기서는 평소보다 더 정확하게 말하는 것이 중요합니다.

컴플라이언스를 대신 충족해 주지 않습니다. Echobell은 알림 채널입니다. 제품 범위를 정하고, 취약점 처리 프로세스를 운영하고, 제14조가 적용되는지 판단하고, SRP에 등록하고, 기한 안에 제출하는 일은 전부 여러분의 몫입니다. 어떤 알림 도구도 보고 의무를 대신 이행한 적은 없습니다.
아무것도 제출하지 않습니다. 제출할 API 자체가 없고, 설령 있더라도 그것을 호출하는 주체가 Echobell은 아닐 것입니다. Echobell은 전화를 울릴 뿐이고, 나머지는 등록된 사람이 합니다.
법적 타임스탬프가 아닙니다. {{time}} 변수는 트리거가 Echobell에 도달한 시각을 UTC로 기록합니다. “인지”가 언제 시작되었는지는 조직에 관한 사실관계 문제이며, 그것을 문서화하는 것은 푸시 알림이 아니라 여러분의 인시던트 기록입니다.
에스컬레이션 정책도, 확인 응답도 없습니다. “10분 안에 아무도 받지 않으면 다음 사람에게 전화” 같은 동작도, 순번 교대도, 누가 무엇을 확인했는지에 대한 감사 추적도 없습니다. 그런 것이 필요하다면 인시던트 플랫폼을 쓰셔야 합니다. Opsgenie 대안을 참고하세요.
전달을 보장하지 못합니다. 전화는 푸시 인프라와 네트워크, 충전된 휴대폰에 달려 있습니다. 감사에서 가리킬 수 있는 통제 수단이 아니라, 사실이 도착한 순간과 사람이 그것을 아는 순간 사이의 간격을 줄여 주는 계층으로 여기시기 바랍니다.
현지 시간을 다루지 않습니다. 내장 시간 변수는 UTC 전용이며 서머타임을 따르지 않습니다. 시간 구간을 거는 조건은 1년에 두 번 수동으로 조정해야 합니다.

FAQ

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

아닙니다. CRA는 제조자에게 의무를 부과하며, 어떤 알림 앱도 그 의무를 대신 이행할 수 없습니다. Echobell이 다루는 것은 한 가지 구체적인 실패 양상입니다. 제출할 수 있었던 사람이 다음 근무일이 되어서야 알게 되어 24시간 조기 경보를 놓치는 경우 말입니다. 실제로 자주 일어나는 실패 양상이지만, 훨씬 큰 컴플라이언스 프로그램의 한 조각일 뿐입니다.

24시간 시계는 정확히 언제 시작되나요?

제조자가 실제로 악용되는 취약점이나 심각한 인시던트를 인지한 때입니다. 규정은 정확한 시점을 정의하지 않으며, 인지 여부는 사실관계와 그것을 얼마나 빨리 확정할 수 있는지에 달려 있습니다 (DLA Piper). 실무적으로는 빠르고 문서화된 분류 절차를 갖추라는 뜻이 됩니다. 신호가 도착한 시점과 누군가 그것을 평가한 시점 사이가 벌어질수록 나중에 설명하기 어려워집니다.

저희는 작은 회사입니다. 면제되나요?

보고 의무에서는 아닙니다. 제64조는 제14조 제2항 (a)호나 제14조 제4항 (a)호의 24시간 기한을 놓친 데 대해서만 영세기업과 소기업을 행정 과징금에서 제외합니다. 보고 의무는 그대로 남고, 72시간 통지와 최종 보고서는 영향을 받지 않으며, 영세기업과 소기업의 정의도 임의로 넘겨짚을 문제가 아닙니다. 좁은 범위의 완화 조치로 보아야지 면죄부로 보아서는 안 됩니다.

저희 보안 메일함은 업무 시간에 모니터링합니다. 그걸로 충분하지 않나요?

평범한 주말에 주어진 시간의 최대 3분의 2를 잃을 각오가 되어 있다면 충분합니다. 금요일 18시에 도착한 제보는 토요일 18시가 기한입니다. 업무 시간 모니터링은 다른 대부분의 일에 대해서는 합리적인 기본값이지만, 24시간 시계는 바로 그 방식이 감당하지 못하는 경우입니다.

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

받을 수 있고, 받아야 합니다. 채널 하나를 공유하면 같은 트리거로 모든 구독자에게 알림이 가고, 각자 긴급도는 스스로 고릅니다. 악용 사실을 확인하는 엔지니어와 양식을 제출할 사람은 순차적으로가 아니라 같은 시각에 시작해야 합니다.

제14조 제8항의 이용자 통지 의무에도 도움이 되나요?

간접적으로 그렇습니다. 제14조 제8항은 영향을 받는 이용자에게 취약점이나 인시던트를, 그리고 필요한 경우 시정 조치를 알리도록 요구합니다. 이는 고객 커뮤니케이션이며 여러분 자신의 채널이 필요합니다. Echobell은 제출을 책임지는 사람들과 동시에 그 커뮤니케이션을 책임지는 사람들을 깨울 수 있어, 두 갈래 작업이 함께 출발하게 해 줍니다.

저희는 이미 NIS2나 DORA에 따라 보고하고 있습니다. 같은 건가요?

아닙니다. 모양이 비슷할 뿐입니다. NIS2와 DORA는 부문과 중요도를 기준으로 기관에 의무를 지우고, CRA는 EU 시장에 출시하는 제품을 기준으로 제조자에게 의무를 지웁니다. 한 조직이 세 가지 모두의 적용을 받을 수 있으며, 시계도 수신처도 서로 다릅니다. 이 제도들도 함께 적용된다면 DORA와 NIS2 인시던트 보고 알림을 참고하세요. 의무는 공유되지 않아도 알림 계층은 공유할 수 있습니다.

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

전화 알림은 통화 형태의 알림으로 전달되며, 그래서 iOS의 집중 모드를 뚫을 수 있습니다. 마법은 아닙니다. 여전히 OS 설정과 네트워크, 충전된 휴대폰에 달려 있습니다. 의존하기 전에 집중 모드를 실제로 켠 상태에서 실제 기기로 테스트하시고, 실패한 통화 재시도도 켜 두세요.

iOS 전용인가요?

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

Webhook 페이로드에는 무엇을 담아야 하나요?

자리에서 일어날지 판단하는 데 필요한 최소한입니다. 제품, 신호의 종류, 한 줄짜리 맥락, 그리고 세부 내용이 담긴 티켓으로 가는 externalLink입니다. Echobell은 알림 내용과 기록을 기기에 보관하고 서버에는 계정과 채널, 구독만 저장하지만(개인정보 모델), 보안에 민감한 자료를 다룰 때의 올바른 습관은 여전히 내용 자체가 아니라 그것을 가리키는 포인터를 보내는 것입니다.