앞선 장들은 WIA-ENE-033 시스템이 무엇을 주고받는지(관측·예측·경보 객체), 어떻게 호출되는지(/api/v1/... 인터페이스), 그리고 어떻게 판단하는지(예측·경보 프로토콜)를 다루었다. 이 장은 그 구성 요소들이 어디에서 실행되고 누구와 연결되는지를 다룬다. PHASE-4가 제시하는 세 가지 통합 패턴, PHASE-2 §12.1의 외부 시스템, Annex J의 네 가지 참조 토폴로지, 그리고 홍수 경보 서비스가 실제 하천을 맡기 전에 갖추어야 할 보안·개인정보·가용성 대책이 그 내용이다.
홍수 예측 시스템은 단일 애플리케이션인 경우가 거의 없다. 수위계와 댐을 소유한 기관, 강우 레이더와 수치예보를 소유한 기상 기관, 대국민 경보의 법적 권한을 가진 재난관리 기관, 배수 펌프·대피소·도로 통제를 소유한 지자체 사이에 놓인다. 따라서 통합 설계가 시스템의 실제 가치를 상당 부분 결정한다. 예측은 정확했으나 경보 담당자에게 20분 늦게 도착하거나, 경보는 발령되었으나 진위를 검증할 수 없다면, 시스템은 가장 중요한 순간에 실패한 것이다. 이 장의 모든 절은 이러한 종단 간 관점을 전제로 한다.
PHASE-4는 세 가지 통합 패턴을 제시하며, 각 패턴이 PHASE-1에 기술된 매니페스트 메커니즘과 Annex I의 상호운용 프로필로 뒷받침된다고 밝힌다. 세 패턴의 차이는 기술보다는 운영 주체가 물과 정보의 흐름 속에서 차지하는 위치에 있다.
첫 번째 패턴에서는 단일 국가 운영 주체가 예측 서비스를 운영하고 광역·지역 수위 관측망을 연합(federation)한다. 광역 관측망은 관측소 소유권과 현장 유지보수를 그대로 가지며, 국가 노드는 그 관측값을 받아 유역 단위 및 전국 모델을 실행하고 예측을 공표한다. 주요 통합 과제는 이질성과 거버넌스이다. 이질성은 수십 년간 따로 조달된 탓에 관측소 제조사, 기록 간격, 수위 기준면(datum)이 제각각이라는 문제이고, 거버넌스는 국가 노드가 소유하지 않은 관측소의 RiverLevelData.levels 기준 수위를 누가 변경할 수 있느냐는 문제이다. 이 패턴의 구현은 대개 PHASE-2의 다섯 가지 오퍼레이션 그룹 gaugeIngest, forecastQuery, warningPublish, simulationSubmit, evacuationRoute를 모두 지원한다.
두 번째 패턴은 행정 구역이 아니라 유역을 단위로 조직된 지역 운영 주체이다. 이 주체는 여러 상류 소유자(국가 관측망, 댐 운영자, 광역 관측소)의 관측을 모으고, 유역 예측 노드를 운영하며, 하류 지자체에 예측과 경보를 공표한다. 물은 행정 경계를 따르지 않으므로 하천 예측에는 이 패턴이 가장 자연스러운 단위인 경우가 많다. 상류 관측소에서 하류 도시까지의 도달 시간은 유역의 속성이며, 댐 방류 계획(DamStatusData.dischargePlan)이 하류 수위에 미치는 영향 역시 마찬가지이다.
다음 그림은 유역 관리 기관 패턴을 나타내며, 각 구간을 규율하는 ENE-033 오퍼레이션 그룹을 함께 표시한다.
상류 소유자 유역 관리 기관 하류
─────────── ───────────── ────
관측망 A ──┐
(RiverLevelData) │ gaugeIngest
관측망 B ──┼──────────▶ ┌──────────────────────┐
│ │ 유역 예측 노드 │ forecastQuery
댐 운영자 ──┤ │ - 수집 / 품질관리 │ ─────────────────▶ 지자체 1
(DamStatusData) │ │ - 1D / 2D / AI 모델 │ (도시 조기경보)
│ │ - 앙상블 │
기상 기관 ──┘ └──────────┬───────────┘ warningPublish
(PrecipitationData, │ ─────────────────▶ 지자체 2
레이더) ▼ CAP 1.2 피드 +
┌──────────────────────┐ WIA 고유 봉투
│ 경보 발행기 │
│ (FloodAlert, CAP 1.2)│ ─────────────────▶ 국가 대국민
└──────────────────────┘ 경보 채널이 패턴에서는 두 가지 성질에 주의해야 한다. 첫째, 유역 기관은 소비자(통제하지 못하는 상류 데이터의)이자 생산자(다른 기관이 의존하는 예측의)이다. 따라서 상호운용 프로필에 양방향을 모두 정직하게 선언해야 한다. 둘째, 경보 피드는 하류 지자체와의 계약이다. PHASE-2는 warningPublish가 WIA 고유 봉투(envelope)와 함께 CAP 1.2 형식을 반드시 내보내도록 요구한다. 이미 CAP을 이해하는 대국민 경보 시스템을 가진 지자체라면 별도 어댑터 없이 유역 기관의 경보를 받을 수 있다.
세 번째 패턴은 기초 지자체 운영 주체이다. 상류(국가 기관 또는 유역 기관)의 예측을 구독하고, 여기에 도시 침수(내수 침수) 모델을 더한다. 도시 침수는 하천이 넘치기 전에 하수관과 펌프의 처리 능력을 넘는 강우로 발생한다. 이 패턴에서는 도시가 소유한 자산이 가장 중요하다. 펌프장·하수관·저류지의 DrainageData, EvacuationShelter와 EvacuationRoute 데이터, 그리고 교통 통제와의 연계가 그것이다. 도시 시스템은 큰 하천에 대해서는 gaugeIngest가 거의 필요 없지만, 자체 하수관 수위계와 저류지 센서에는 필요하다.
| 항목 | 국가 수문 기관 | 유역 관리 기관 | 도시 단위 조기경보 |
|---|---|---|---|
| 운영 범위 | 전국, 광역 관측망 연합 | 여러 행정 구역에 걸친 하나의 유역 | 하나의 기초 지자체 |
| 주요 입력 | 광역 관측망, 국가 레이더, 댐 | 상류 관측소, 댐 방류 계획, 기상 예보 | 상류 예측, 지역 강우, 배수 센서 |
| 주요 출력 | 국가 예측과 경보 | 유역 예측, 지자체용 CAP 경보 피드 | 지역 경보, 대피소·대피 경로 상태 |
| 주된 홍수 유형 | 하천, 돌발 | 하천(댐 영향 포함) | 도시(내수), 해당 시 하천 |
| 대표 오퍼레이션 그룹 | 다섯 가지 전부 | gaugeIngest, forecastQuery, warningPublish, simulationSubmit | forecastQuery(클라이언트로서), warningPublish, evacuationRoute |
| 어울리는 Annex J 토폴로지 | 연합 메시 또는 멀티테넌트 게이트웨이 | 연합 메시 | 단일 테넌트 엣지 |
마지막 행은 출발점일 뿐 규칙이 아니다. Annex J는 자신이 제시하는 토폴로지가 비규범적이며 다른 토폴로지를 배제하지 않는다고 명시한다. 소규모 유역 기관이 단일 테넌트 엣지로 배포하고 인접 기관과는 구독 방식으로 데이터를 교환하는 것도 충분히 타당하다.
PHASE-2 §12.1은 외부 연동을 SystemIntegration이라는 TypeScript 인터페이스로 기술한다. v1.0에서 배포가 연결해야 할 외부 시스템의 종류를 열거한 곳은 이곳뿐이므로 그대로 옮긴다.
interface SystemIntegration {
weatherService: {
apiEndpoint: string;
dataTypes: ['precipitation', 'forecast', 'radar'];
updateInterval: number; // minutes
};
hydrologicalNetwork: {
stations: number;
protocols: ['MQTT', 'HTTP', 'WebSocket'];
dataFormats: ['JSON', 'XML', 'CSV'];
};
emergencySystem: {
alertBroadcast: boolean;
situationRoom: boolean;
resourceManagement: boolean;
};
smartCity: {
trafficControl: boolean;
infrastructureMonitoring: boolean;
citizenServices: boolean;
};
}문자 그대로 읽으면 ['MQTT', 'HTTP', 'WebSocket'] 같은 배열 멤버는 TypeScript 튜플 타입이며, 모든 배포가 세 프로토콜을 이 순서대로 나열해야 한다는 뜻이 된다. 이것이 의도였을 가능성은 거의 없다. 이 책은 이를 허용 값의 집합으로 해석한다. 즉 배포는 실제로 지원하는 부분집합만 선언한다. 예를 들어 MQTT와 CSV만 받는 수문 관측망이 그러하다. 통합 명세를 기계 판독형으로 만들 때에는 튜플이 아니라 열거형으로 표현해야 한다.
기상 기관은 관측·예측 강수와 레이더 산출물을 제공한다. ENE-033에서 이 데이터는 PrecipitationData의 observed 누적 강우량, forecast 예측 강우량, 선택 항목인 radar 블록에 담긴다. updateInterval(분) 필드는 두 가지 이유로 중요하다. 예측의 최신성 상한을 정하며, 예측 노드가 피드 정지를 감지할 근거가 된다. 예컨대 선언된 간격의 두 배 안에 새 강수 산출물이 도착하지 않으면, 노드는 직전 산출물을 조용히 재사용할 것이 아니라 입력 품질 저하를 표시해야 한다. 여기서 두 배라는 값은 설명을 위한 예시이며 명세의 값이 아니다.
수문 관측망은 수위 관측값을 전달한다. PHASE-2는 전송 방식으로 MQTT·HTTP·WebSocket을, 형식으로 JSON·XML·CSV를 든다. 실제로는 국가 자료 저장소에서 OGC WaterML 2.0 XML을, 오래된 데이터로거에서 CSV를, 새 원격측정 장비에서 JSON이나 MQTT 페이로드를 받는 경우가 흔하다. 통합 계층의 역할은 이 모두를 제2장에서 설명한 대로 단위가 명시되고 UTC 타임스탬프를 갖는 RiverLevelData와 DamStatusData로 정규화하는 것이다.
한 가지 공백은 분명히 밝혀 둔다. PHASE-2는 gaugeIngest 오퍼레이션 그룹을 정의하지만, 참조 TypeScript SDK에는 수집 엔드포인트가 없고 모니터링 메서드는 데이터를 읽기만 한다. 따라서 제3자 소유자의 관측을 받아야 하는 배포는 수집 어댑터를 직접 구축해야 한다. 이 어댑터는 수락 전에 페이로드를 제2장의 스키마로 검증하고, 출처·도착 시각·적용한 단위 변환을 기록하는 것이 바람직하다.
emergencySystem 블록에는 세 개의 불리언이 있다. alertBroadcast(경보를 대국민 방송 채널로 넘길 수 있는가), situationRoom(재난 상황실에 정보를 공급하는가), resourceManagement(대피소·펌프·인력 같은 자원 정보를 교환하는가)이다. 이 가운데 방송 연계는 시스템 전체에서 가장 민감한 연동이다. 소프트웨어의 판단 하나가 수많은 휴대전화의 메시지로 바뀌기 때문이다. 이를 보호하는 방법은 6.5절에서 다룬다.
한국에서 홍수특보는 홍수통제소가 발령하며, 국가 재난 위기경보 단계는 별도의 체계를 따른다. 이러한 채널과 연결되는 ENE-033 시스템은 의사결정 지원·전달 구성 요소로 동작하며, 공식 특보 발령의 법적 권한을 대신하지 않는다. 경보 객체에는 발령 주체(FloodAlert.issuer의 organizationId, name, authorityLevel)가 담겨야 하며, 그래야 수신자가 누구의 경보인지 알 수 있다.
smartCity 블록은 교통 통제, 기반시설 모니터링, 시민 서비스를 포괄한다. 가장 강력한 활용 사례는 대피 경로이다. 도로 구간이 침수되면 도시의 교통 시스템과 ENE-033의 EvacuationRoute 객체(FloodedSegment, RouteStatus 포함)가 같은 상태를 가리켜야 한다. 경보가 이용하라고 안내한 경로를 교통 통제가 이미 막아 두었다면, 이는 경로가 없는 것보다 나쁘다.
| 외부 시스템 | 방향 | 관련 ENE-033 객체 | 대표 전송 방식과 형식 |
|---|---|---|---|
| 기상 기관 | 입력 | PrecipitationData(관측, 예측, 레이더) | HTTP 풀 방식; 격자 또는 JSON 산출물 |
| 수문 관측망 | 입력 | RiverLevelData, DamStatusData | MQTT 또는 HTTP; JSON, WaterML 2.0 XML, CSV |
| 지자체 배수 SCADA | 입력 | DrainageData | 게이트웨이 내보내기; JSON 또는 CSV |
| 재난 안전 시스템 | 출력(전달 상태는 회신) | FloodAlert, CAP 1.2, 전달 집계 | HTTP 상의 CAP 1.2 XML; WIA 고유 JSON |
| 스마트시티 플랫폼 | 양방향 | EvacuationRoute, EvacuationShelter, MonitoringDashboard | HTTP 또는 WebSocket; JSON |
도시 단위 시스템이 연동 구성을 선언한다면 다음과 같은 모습이 될 수 있다. 엔드포인트와 수치는 예시일 뿐이다.
{
"weatherService": {
"apiEndpoint": "https://met.example.org/api/precip",
"dataTypes": ["precipitation", "forecast", "radar"],
"updateInterval": 10
},
"hydrologicalNetwork": {
"stations": 42,
"protocols": ["MQTT", "HTTP"],
"dataFormats": ["JSON", "CSV"]
},
"emergencySystem": {
"alertBroadcast": true,
"situationRoom": true,
"resourceManagement": false
},
"smartCity": {
"trafficControl": true,
"infrastructureMonitoring": true,
"citizenServices": false
}
}Annex J(네 PHASE 문서 모두에 같은 내용으로 실려 있다)는 작업반이 시험 벡터를 검증할 때 사용한 네 가지 참조 토폴로지를 기술한다. 이는 통합 패턴과 다른 질문에 답한다. 누구와 연결하는가가 아니라, 런타임·테넌트·적합성 매니페스트를 어떻게 배치하는가이다.
| 토폴로지 | 형태 | 매니페스트와 서명 | 적합한 경우 | 주의점 |
|---|---|---|---|---|
| 단일 테넌트 엣지 | 기관마다 런타임 하나, 공유 상태 없음 | 기관이 자체 매니페스트에 서명, 증거는 수동 공개 | 시범 사업, 단일 도시나 소규모 유역 | 수동 증거는 쉽게 낡는다. 이중화하지 않으면 단일 장애점 |
| 멀티테넌트 게이트웨이 | 공유 런타임 하나, 속도 제한 게이트웨이(예: Envoy, NGINX)와 공유 ID 제공자 뒤에서 헤더로 테넌트 격리 | 테넌트별 매니페스트와 이를 집계한 연합 매니페스트 | 광역을 수용하는 국가 기관, 여러 도시를 호스팅하는 공급사 | 테넌트 식별은 검증된 토큰에서 도출해야 하며, 클라이언트가 설정한 헤더를 믿어서는 안 된다 |
| 연합 메시 | 여러 런타임이 상호 연결하고 디렉터리 서비스에 매니페스트를 게시 | 각 피어가 자기 매니페스트에 서명, 디렉터리가 집계 색인에 서명 | 유역 기관, 기관 간 교환 | 피어 간 프로필 불일치, 디렉터리 가용성 |
| 에어갭 배치 | 런타임과 디렉터리 사이에 실시간 연결 없음, 서명된 증거 패키지를 대역 외로 전달 | 배치마다 서명된 패키지 | 실시간 연결을 금지하는 규제 기관·시설 | 증거·기록 보관에는 맞지만 실시간 경보에는 맞지 않는다 |
홍수 분야에서 이 토폴로지들을 올바르게 적용하려면 다음 세 가지를 유념해야 한다.
Annex J는 멀티테넌트 게이트웨이의 구성 요소로 "OAuth 2.1 ID 제공자"를 언급한다. 이 글을 쓰는 시점에 OAuth 2.1은 OAuth 2.0과 그 보안 모범 사례를 통합하는 IETF 초안이며, 아직 RFC로 발행되지 않았다. 이 점은 6.5절에서 다시 다룬다.
README는 네 단계의 구축 과정을 제시한다. 여기에 적힌 기간(1~2개월, 2~3개월, 1~2개월, 이후 지속)은 참고치일 뿐이다. 실제 일정은 기존 관측소 규모, 과거 자료의 정제 상태, 데이터 소유자와의 조달·법적 합의에 걸리는 시간에 좌우된다. 각 단계를 완료 기준의 묶음으로 다루는 편이 더 유용하다.
| 단계 | 작업 항목(README) | 권장 완료 기준 |
|---|---|---|
| 1. 데이터 수집 인프라 | 수위 센서 설치·연동, 강우 레이더 연동, 댐 관리 시스템 연동, 실시간 데이터 파이프라인 구축 | 모든 관측소의 기준면·단위·시각 출처가 문서화되어 있다. 페이로드가 제2장 스키마로 검증된다. 결측은 0이 아니라 결측으로 기록된다. 데이터 소유자와 이용 협약이 체결되어 있다 |
| 2. 예측 모델 개발 | 과거 홍수 자료 수집, AI 예측 모델 학습, 침수 시뮬레이션 구축, 정확도 검증·조정 | 학습에서 제외한 사례로 재현 예측(hindcast)을 평가하고 POD·FAR·CSI(제5장)로 보고한다. 모델 버전이 기록된다. 보관된 입력으로 결과를 재현할 수 있다 |
| 3. 경보 시스템 | 위험 단계별 알림 기준 설정, 다채널 알림(SMS, 앱, 사이렌), 대피 경로 최적화, 긴급 대응 프로토콜 연동 | CAP 1.2 출력이 검증을 통과한다. 역할 분리(6.5절)가 적용되어 있다. 예측부터 시험 수신 그룹까지 종단 간 시험을 마쳤다. 해제 경로도 시험했다 |
| 4. 운영 및 개선 | 실시간 모니터링·대응, 예측 정확도 지속 개선, 주민 대피 훈련, 확장 | 월간 오류 예산 보고(6.7절). 사후 검토가 FloodResponseReport에 기록된다. 증거 패키지를 분기마다 재공개한다(제7장) |
이 책은 두 가지 순서 원칙을 권장한다. 첫째, 1단계 완료 기준을 충족하기 전에는 3단계를 시작하지 않는다. 신뢰할 수 없는 데이터 위에 만든 경보 시스템은 주민에게 경보를 무시하는 법을 가르친다. 둘째, 대국민 채널을 연결하기 전에 경보를 직원에게만 전달하는 섀도 모드로 적어도 한 번의 우기를 거친다. 섀도 기간의 길이는 현지에서 정할 사항이며 명세가 정하지 않는다.
PHASE-4 §13.1은 네 가지 보안 대책을 든다. 전송 구간은 TLS 1.3, 저장 데이터는 AES-256으로 암호화하고, 역할 기반 접근 제어(RBAC)를 적용하며, OAuth 2.0과 다중 인증(MFA)으로 인증하고, 모든 중요 작업을 감사 로그로 기록한다. 관리 체계의 맥락으로는 ISO/IEC 27001:2022(정보보호 경영시스템)와 ISO/IEC 27018:2019(개인정보 처리자로서의 퍼블릭 클라우드에서의 개인정보 보호)를 참조한다. 합리적인 기준선이지만, 홍수 경보 시스템에는 보다 구체적으로 다루어야 할 위협 특성이 있다.
v1.0은 인증을 세 가지로 서술한다. PHASE-2는 OAuth 2.1과 기관 호출자용 mTLS를 제시하며 RFC 9700을 인용하는데, RFC 9700은 실제로는 OAuth 2.1 규격이 아니라 OAuth 2.0 보안 모범 사례(Security Best Current Practice)이다. PHASE-4는 OAuth 2.0과 MFA를 제시한다. 참조 SDK는 Authorization 헤더에 고정 Bearer API 키를 담고, X-WIA-Standard: ENE-033과 X-WIA-Version: 1.0.0 헤더를 함께 보낸다.
이 책이 권장하는 일관된 해석은 다음과 같다. 기관 간 기계 호출(유역 노드가 국가 노드에서 데이터를 가져오거나, 지자체가 경보 피드를 구독하는 경우)은 상호 TLS와 RFC 9700 모범 사례를 따르는 OAuth 2.0 클라이언트 자격증명 방식을 쓴다. 사람인 운영자는 ID 제공자를 통해 MFA로 로그인한다. 고정 API 키는 공개 대시보드처럼 읽기 전용의 저위험 클라이언트에만 허용하고, 경보를 게시할 수 있는 역할에는 절대 쓰지 않는다.
PHASE-4는 RBAC를 요구하지만 역할을 정의하지는 않는다. 다음 역할 구성은 예측에서 경보에 이르는 사슬의 직무 분리를 따른 제안이다. 엔드포인트 경로는 참조 SDK의 경로이다(제4장).
| 역할 | 목적 | 허용 | 불허 |
|---|---|---|---|
| 관찰자(observer) | 상황 인식을 위한 상태 조회(협력 기관, 공개 대시보드 백엔드) | GET /monitoring/*, GET /alert/active, GET /alert/{id} | 모든 쓰기, 수신자 목록 접근 |
| 예보관(forecaster) | 예측과 시뮬레이션의 실행·검토 | 관찰자 권한, POST /flood/predict, POST /flood/simulation, GET /flood/* | POST /alert/create, 경보 갱신·해제 |
| 경보 담당관(warning officer) | 운영 기관의 법적 권한 범위에서 경보 발령·갱신·해제 | 관찰자 권한, POST /alert/create, PUT /alert/{id}/update, POST /alert/{id}/cancel, 대피소 상태 갱신 | 모델 설정이나 관측소 기준 수위 변경 |
| 감사자(auditor) | 사후 검증 | 감사 로그, /analytics/*, 증거 패키지 읽기 전용 | 모든 운영상 쓰기 |
| 연동 서비스(기계) | 특정 데이터 소유자의 관측 수집 | 자기 관측소에 대한 수집만 | 다른 소유자의 원자료 조회, 경보 엔드포인트 |
예보관과 경보 담당관을 나눈 것은 의도적이다. 이는 제5장에서 설명한 AlertCriteria의 manualReview 분기와 대응한다. 불확실성이 크거나, 핵심 기반시설이 관련되거나, 역사적으로 중대한 사건일 때에는 권한을 가진 사람이 결정한다. 그 권한은 예측 소프트웨어가 스스로 취할 수 없는 별도의 역할이어야 한다.
홍수 경보 시스템에 가장 치명적인 공격은 데이터 탈취가 아니라 거짓 경보나 경보 억제이다. 위조된 "즉시 대피" 경보는 혼란을 일으키고 신뢰를 무너뜨리며, 억제되거나 조용히 해제된 경보는 인명 피해로 이어진다. 다음 통제는 이 위험을 직접 겨냥한다.
/alert/create, /alert/{id}/update, /alert/{id}/cancel은 MFA로 인증한 경보 담당관 역할, 또는 승인된 자동 경로의 경우 mTLS로 인증한 주체만 호출할 수 있다. AlertCriteria.automatic에 따른 자동 발령은 전용 서비스 신원으로 실행하고, 그 행위를 사람의 행위와 똑같이 기록한다.FloodAlert.issuer에 적힌 발령 주체에게서 왔는지 검증할 수 있다.SensorStatus에서 오프라인으로 보고된 관측소의 값은 표시해야 한다.경보 조치에 대한 감사 기록은 다음과 같은 필드를 담을 수 있다. 구성은 예시이며, PHASE-4는 중요 작업을 기록하라는 것만 요구한다.
{
"eventId": "AUD-2026-000317",
"timestamp": "2026-07-14T05:42:10Z",
"actor": { "subject": "officer-0192", "role": "warning-officer", "mfa": true },
"action": "alert.create",
"target": { "alertId": "ALERT-2026-000041", "level": "LEVEL-3" },
"basis": { "predictionId": "PRED-2026-000118", "decision": "manualReview" },
"clientCert": "sha256:9f2c...e1",
"result": "accepted"
}PHASE-4 §13.2는 GDPR과 한국 개인정보 보호법 준수, 최소 수집, 목적 외 이용 금지, 보유 기간 제한을 약속한다. ENE-033 객체 자체에는 개인정보가 거의 없지만, 그 주변 시스템에는 있다. 다음 표는 개인정보가 들어오는 지점을 정리한 것이다.
| 데이터 요소 | 개인정보 여부 | 최소화 방안 |
|---|---|---|
inundationArea.affectedPopulation, AffectedAreas.population | 집계 인원수로 산출하면 아니다 | 인구 격자나 구역 합계로 계산하고, 수치 뒤의 개인 목록은 저장하지 않는다 |
AlertDistribution.recipients(highRisk, vulnerable, firstResponders, publicOfficials, general) | 그렇다(전화번호, 기기 토큰, 전자우편 주소) | 전달 서비스 안에만 두고 ENE-033 객체에서는 그룹 ID로 참조한다. vulnerable 그룹은 민감한 사정을 드러내므로 가장 엄격한 접근 통제가 필요하다 |
대피소 수용 현황(EvacuationShelter 수용력·상태) | 인원수는 아니다. 입소 명부를 두면 그렇다 | 인원수만 공개하고, 명부는 대피소 관리 시스템에 별도 보유 기간으로 둔다 |
RegionStatus.evacuationProgress | 아니다(백분율) | 집계에서 도출하고, 이를 계산하려고 개별 기기를 추적하지 않는다 |
| 감사 로그 | 그렇다(운영자 신원) | 감사자 역할로 접근을 제한하고, 현지 법령에 따라 보유한다 |
보유 기간에 관하여, 네 PHASE 문서에 공통으로 실린 Annex E는 7년 보유가 "대부분의 관할에서 ISO/IEC 17065:2012 감사 기대를 충족한다"고 적고 있다. ISO/IEC 17065는 제품·공정·서비스 인증기관에 대한 요구사항이며, 7년이라는 기간을 규정하지 않는다. 보유 기간은 적용 법령과 운영 기관의 기록 관리 방침에 따라 정해야 하며, 운영자 감사 로그(사후 조사보다 오래 남아야 한다)와 수신자 연락처(구독 기간보다 오래 두지 않아야 한다)는 서로 다를 수밖에 없다.
유용한 설계 원칙은 개인정보가 예측에는 필요 없고 전달에만 필요하다는 것이다. 예측 노드가 수신자 데이터를 전혀 갖지 않도록 이 경계를 아키텍처에 반영하면, 개인정보 위험과 유출 시 영향 범위가 함께 줄어든다.
README는 네 가지 안정성 대책(이중화 서버, 자동 장애 복구, 백업 전원, 재난 복구 계획)과 네 가지 경보 신뢰성 대책(다채널 발송, 전달 확인, 우선순위 기반 전송, 오프라인 백업 시스템)을 든다. 홍수 경보 서비스의 가용성 특성은 독특하다. 수요가 최고조에 이르는 시점이 정전, 전산실 침수, 이동통신망 혼잡처럼 시스템이 가장 망가지기 쉬운 조건과 겹친다.
inundationArea를 활용하여, 주 시스템의 모의 침수 범위 밖에 장애 조치 사이트를 둔다.SensorStatus.offline) 예측 노드는 멈추지 말고 신뢰도를 낮추어 계속 동작해야 한다. 예측 노드가 중단되어도 경보 담당관은 경보 발행기를 통해 수동 경보를 낼 수 있어야 한다. 발행기마저 중단되면 방송 당국과의 직접 절차처럼 사전에 합의한 오프라인 백업이 이어받는다.AlertDistribution.status는 sent, delivered, failed, confirmed를 센다. 사건 중 특정 채널의 실패 건수가 늘어나면, 다른 채널(사이렌, 라디오, TV)로 우선순위를 옮기라는 운영 신호로 받아들인다.모든 관측·예측·경보는 ISO 8601 UTC 타임스탬프를 가지며, 제5장의 월류까지 시간과 선행 시간 계산은 타임스탬프 간의 차이이다. Annex E는 대부분의 기한에는 stratum-2 서버에 대한 NTPv4 동기화로 충분하고, 결정론적 인터록이 필요한 곳에는 정밀 시간 프로토콜(PTP, IEEE 1588)을 권장한다고 적고 있다. NTP를 상시 실행할 수 없는 현장 데이터로거는 동기화할 때마다 시계 오차를 기록해 두어, 수집 계층이 드리프트를 보정하거나 표시할 수 있게 해야 한다.
README는 시스템 가용성 99.9% 이상을 설계 목표로 제시한다. 이런 목표는 분 단위로 환산해 보는 것이 좋다. 30일 기준 한 달에서 0.1%의 비가용 시간은 43.2분이다. 이 예산이 허용 가능한지는 그 시간이 언제 소진되는가에 달려 있다. 같은 중단이라도 마른 주간에는 무해하지만 폭우 중에는 심각하다. 따라서 운영 기관은 가용성을 전체 기간과, 어느 지역이든 LEVEL-2 이상이던 기간으로 나누어 보고해야 한다.
Annex E는 p95 지연시간, 오류율, 위반 시간을 담은 월간 오류 예산 요약을 테넌트별 데이터 없이 공개하도록 권장한다. 보고서는 다음과 같은 모습일 수 있으며, 수치는 예시이다.
{
"period": "2026-07",
"service": "basin-forecast-node",
"availability": { "overall": 99.95, "duringLevel2Plus": 99.99 },
"latencyP95Ms": { "forecastQuery": 420, "alertCreate": 180 },
"errorRate": 0.0021,
"violationHours": 0.5,
"notes": "30-minute radar feed gap on 2026-07-14; forecasts ran with reduced confidence"
}이 보고서의 실시간 대응물은 MonitoringDashboard.system 블록(uptime, latency, dataQuality, errors)과 sensors 블록(total, active, offline, maintenance)이다. 월간 보고서와 제7장의 적합성 증거는 외부 감사자가 읽게 될 두 가지 관점이므로, 서로 어긋나지 않도록 같은 로그에서 생성해야 한다.
README의 운영 작업 항목에는 주민 대피 훈련이 있다. 기술 시스템도 이 훈련에 참여해야 한다. 시험용임이 분명히 표시된 채널로 훈련 경보를 종단 간 흘려보내고, 결정부터 전달까지의 시간을 측정하며, 적어도 하나의 장애 조치 경로를 실제로 가동해 본다. 한 번도 가동해 보지 않은 장애 조치 경로는 가용하다고 셈하지 않아야 한다.
gaugeIngest는 배포 측에서 구축해야 한다.제7장에서는 이 모든 것을 다른 이에게 입증하는 방법, 곧 시험 벡터, 증거 패키지, 상호운용 프로필, 그리고 v1.0에 공존하는 두 가지 적합성 어휘를 다룬다.