앞의 일곱 장은 버전 1.0 시점의 WIA-ENE-033을 설명했다. 무엇을 모델링하는지, 어떻게 호출하는지, 어떻게 판단하는지, 어떻게 배포하는지, 그리고 적합성을 어떻게 입증하는지가 그 내용이었다. 마지막 장은 앞을 내다본다. 표준 문서가 다음 버전에 대해 실제로 약속한 것과 홍수 예측 분야 전반이 움직이는 방향을 구분하고, 도입자가 늘 염두에 두어야 할 한계, 곧 자동화 자체의 한계까지 분명히 짚는다.
"미래"를 다루는 장은 누구도 검증할 수 없는 전망으로 채워지기 쉽다. 이 장은 의도적으로 그것을 피한다. 여기에서 인용하는 향후 약속은 릴리스 노트와 네 PHASE 문서의 Annex F(도입 로드맵)에 적힌 것뿐이다. 나머지는 모두 분야의 동향, v1.0에서 관찰되는 공백, 또는 이 책의 권고 중 하나로 표시한다. 이 구분은 중요하다. 어떤 기능을 전제로 조달을 계획하는 구현자는 그 기능이 약속된 것인지, 그럴듯한 것에 불과한지, 단지 제안된 것인지를 알아야 하기 때문이다.
v1.0(상태: Stable)의 릴리스 노트는 알려진 한계를 정확히 두 가지 적고 있다. 첫째, 수평 해상도가 1 m보다 세밀한 라이다(lidar) 기반 수치표고모델(DEM)에 의존하는 침수 모델은 범위 밖이다. 둘째, 폭풍해일 결합은 "v1.1 로드맵 항목으로 문서화되어 있다". 공표된 기술 로드맵은 이 두 문장이 전부이다. 둘 사이의 비대칭에 주의해야 한다. 폭풍해일 결합은 v1.1로 명시적으로 예정되어 있지만, 1 m 미만 침수 모델은 범위 밖이라고만 선언되었을 뿐 어느 버전에서 다룰지는 적혀 있지 않다. 도입자는 두 항목이 함께 도착한다고 가정해서는 안 된다.
FloodEventType 열거형에는 이미 coastal-flood가 있고, FloodAlert는 event.type: "coastal-flood"를 담을 수 있다. v1.0에 없는 것은 바다를 예측에 끌어들이는 프로토콜이다. 제2장의 관측 모델에는 강우·하천·댐·배수 객체가 있지만 조위 관측소, 천문조 예측, 해일고를 위한 객체는 없다. 제5장의 예측 프로토콜은 강우로 구동되는 1D 하천 모델과 2D 침수 모델을 기술하지만, 두 모델 모두 하천이 바다와 만나는 하류 경계를 다루지 않는다. 실무적으로 말하면, v1.0 배포는 해안 홍수 경보를 발행할 수는 있으나 그 근거는 표준 밖에서 가져와야 한다.
v1.1이 결합을 추가하려면 적어도 세 가지 질문에 답해야 한다. 해수면 관측과 해일 예측을 어떻게 표현할 것인가(RiverLevelData와 나란히 놓이는 새 관측 객체가 자연스러운 형태이다), 조석 경계 조건을 하천·침수 모델에 어떻게 넘길 것인가, 그리고 높은 하천 유량과 높은 해수면이 동시에 나타날 결합 확률을 FloodPredictionResult에 어떻게 표현할 것인가이다. 그때까지 해안 대응 능력을 정직하게 선언하는 방법은 제7장의 상호운용 프로필이다. 열거형 값이 프로토콜에 정의되지도 않은 능력을 암시하게 두지 말고, 해당 요구사항을 사유와 함께 partial 또는 excluded로 표시해야 한다.
도시 침수 심도는 짧은 거리 안에서도 크게 달라진다. 연석 하나, 지하차도 입구, 지하주차장 경사로가 물이 건물로 들어가느냐를 가른다. 물길을 바꾸는 지형 요소보다 거친 DEM으로 만든 모델은 바로 그 세부를 뭉개 버린다. v1.0이 1 m 미만 라이다 침수 모델을 범위 밖에 둔 것은 그런 모델이 틀렸다는 뜻이 아니라, 그 산출물을 어떻게 교환하고 검증할지 표준이 아직 정의하지 않았다는 뜻이다. FloodPredictionRequest의 resolution 매개변수는 정성적 값(coarse, medium, fine)이며 격자 크기를 담지 않는다. 고해상도 침수를 범위 안으로 들이는 향후 개정은 최소한 결과에 DEM 출처와 격자 간격을 적는 방법을 갖추어야 한다. 1 m 해상도의 maxDepth 0.4 m와 30 m 해상도의 0.4 m는 의미가 다르기 때문이다.
v1.0 문서가 참조하지만 공개 패키지에는 없는 산출물이 여럿 있다. 통합 명세서 spec/WIA-ENE-033-v1.0.md, OpenAPI 문서 api/openapi.yaml, tests/phase-vectors/ 아래의 시험 벡터, 그리고 릴리스 노트가 적합성 등급의 근거로 지목한 Annex A가 그것이다. 제4장과 제7장은 이 공백을 우회하는 방법을 다루었다. 여기서 이들을 로드맵 항목으로 다시 드는 이유는 이들이 다른 모든 것의 전제 조건이기 때문이다. 특히 시험 벡터는 서로 독립적인 두 구현이 자신들의 해석이 어긋난다는 사실을 발견하는 수단이다. 시험 벡터가 존재하기 전까지 적합성 주장은 자기 서술에 기대게 된다.
다음 표는 향후 과제를 한데 모은 것이다. "공표된 의도" 열에는 v1.0 문서에 적힌 내용만 옮겼다. 마지막 열은 이 책의 권고이며 규범적 지위가 없다.
| 항목 | v1.0 현황 | 공표된 의도 | 도입자를 위한 권고 |
|---|---|---|---|
| 폭풍해일 결합 | 이벤트 유형 coastal-flood는 존재, 해수면 객체와 결합 프로토콜은 없음 | v1.1 로드맵 항목(릴리스 노트) | 프로필 매니페스트에 해안 대응 능력을 partial/excluded로 선언 |
| 1 m 미만 DEM 기반 침수 | 범위 밖 | 버전 명시 없음 | 배포 문서에 DEM 출처와 격자 간격 기록 |
| OpenAPI 문서 | 참조되었으나 미공개 | 오퍼레이션 그룹을 기술하는 문서로 참조됨 | 자체 배포에서 생성해 증거 패키지에 포함 |
시험 벡터(tests/phase-vectors/) | 참조되었으나 미공개 | Annex G: 규범 요구사항마다 긍정·부정 벡터 | 자체 벡터를 유지하고 상류 저장소에 기여 |
| Annex A(적합성 등급) | 참조되었으나 미공개, 두 가지 어휘 병존 | 명시 없음 | 제7장의 해석을 채택하고 그 사실을 명시 |
| SDK의 관측 수집 | gaugeIngest 그룹은 정의, SDK 엔드포인트는 없음 | 명시 없음 | 배포 측에서 수집 기능을 구축하고 다른 쓰기 작업과 같은 인증 뒤에 둠 |
| SDK 재시도 동작 | retries 설정은 있으나 미구현 | SDK는 "Reference" 계층으로 문서와 별도 버전 관리(Annex F) | 호출 측에서 멱등 조회에 한해 백오프 재시도 구현 |
| 폐기 유예 기간 | Annex F는 최소 90일 병행, Annex H는 최소 180일 | 미조정 | 정오표로 정리될 때까지 더 긴 기간을 기준으로 계획 |
각 PHASE 문서의 Annex F는 내용을 세 가지 안정성 계층으로도 나눈다. Stable(규범적 MUST/MUST NOT 문장, 시맨틱 버저닝 적용), Provisional(Annex F 자체와 Annex D의 항목으로, 메이저 버전 변경 없이 규범으로 승격될 수 있음), Reference(시험 벡터, 시뮬레이터 동작, TypeScript SDK로, 문서와 독립적으로 버전 관리)가 그것이다. 로드맵을 읽는 실질적인 열쇠가 이 분류이다. warningPublish에 CAP 1.2 송출을 의무화한 MUST를 없애는 것은 호환성을 깨는 Stable 변경이므로 메이저 버전이 필요하지만, SDK에 빠진 재시도 루프를 고치는 것은 Reference 변경이므로 언제든 배포할 수 있다.
제1장은 네 가지 홍수 유형을 서로 떨어진 것처럼 소개했다. 그러나 피해가 가장 큰 사건은 대개 그렇지 않다. 복합 홍수란 둘 이상의 요인이 겹쳐 그 결합 효과가 각 요인 단독의 효과를 넘어서는 홍수를 말한다. 전형적인 조합은 다음과 같다. 폭풍해일로 해수면이 높게 유지되는 동안 해안 도시에 호우가 내려 하천과 배수로가 물을 내보내지 못하는 경우, 하천 수위가 이미 제방 높이에 가까운데 상류 저수지가 댐 보호를 위해 방류량을 늘려야 하는 경우, 도시에 집중호우가 쏟아져 배수 용량을 넘는 바로 그때 방류 대상 하천의 수위가 너무 높아 배수문이나 펌프가 물을 내보내지 못하는 경우이다.
┌──────────────────────────┐
강우 ─────────────▶│ │
(PrecipitationData)│ │
│ 관심 지점의 │
상류 유량 ────────▶│ 국지 수위 │──▶ 침수
(RiverLevelData) │ │ (inundationArea)
│ 요인이 겹치면 │
댐 방류 ──────────▶│ 결합 효과 ≥ │
(DamStatusData. │ 개별 효과의 합 │
dischargePlan) │ │
│ │
해수면 / 해일 ────▶│ (v1.0 객체 없음, │
(조석 + 해일) │ v1.1 로드맵) │
└────────────▲─────────────┘
│
배수 능력 ──────────────┘ (DrainageData: 방류 대상 수위가
(도시에서 물이 빠지는 너무 높으면 펌프와 배수문이
속도를 제한) 제 기능을 못함)이 그림의 요인 가운데 셋은 이미 ENE-033 객체를 갖고 있다. 이것은 v1.0의 실질적인 강점이다. PrecipitationData, RiverLevelData, DamStatusData, DrainageData를 한 스키마 계열로 받아들이는 예측 노드는 이 요인들의 동시 발생을 따져 볼 수 있다. 표준이 아직 표현하지 못하는 것은 의존성이다. FloodPredictionResult.contributingFactors는 요인들을 나란히 나열할 뿐, 결과가 각 요인을 따로 본 것이 아니라 그들의 결합 거동에서 계산되었다는 사실을 밝힐 방법이 없다. 복합 사건에서는 바로 이 구분이 핵심이다. 서로 의존하는 요인을 독립으로 취급하면 동시 발생 빈도를 과소평가하기 쉽기 때문이다.
표준이 이 문제를 다루기 전까지 두 가지 관행이 도움이 된다. 첫째, 예측 담당자는 댐 방류 계획을 사후 관측값이 아니라 예측 입력으로 다루어야 한다. dischargePlan은 물이 하류에 닿기 전에 알 수 있는 정보이며, 이를 수위 관측과 같은 파이프라인으로 공표하는 것은 제6장 유역 관리 기관 패턴이 주는 가장 구체적인 이점 가운데 하나이다. 둘째, FloodPredictionResult의 scenarios 블록(최선·최악·최빈 시나리오)은 복합 조합을 명시적으로 보여 주기에 알맞은 자리이다. 예를 들어 계획된 방류가 예측 강우 정점과 겹치는 경우를 최악 시나리오로 둘 수 있다.
PrecipitationData.statistics는 returnPeriod(년), percentile, isExtreme을 담는다. 재현 주기를 추정하는 고전적 방법은 정상성(stationarity), 곧 과거 기록의 통계가 미래를 대표한다는 가정을 전제한다. 기후 온난화는 이 가정을 흔든다. 물리적 이유는 잘 확립되어 있다. 포화 공기가 품을 수 있는 수증기량은 기온이 1 °C 오를 때마다 약 7 %씩 늘어나며(클라우지우스–클라페이롱 관계), 그만큼 호우에 쓰일 수 있는 수분이 많아진다. 토지 이용 변화는 또 하나의 비정상성을 더한다. 불투수면이 늘수록 같은 강우에서 빠른 유출로 바뀌는 비율이 커진다.
데이터 표준에 주는 함의는 간단하다. "returnPeriod": 100 같은 값은 어떤 기록과 어떤 방법으로 산출했는지 모르면 의미가 없다. 예를 들어 과거 기록으로는 100년 빈도로 분류된 강우의 연 초과 확률이 이제 1 %가 아니라 2 %라고 하자. 그러면 그 사건은 사실상 50년 빈도이다. 제1장의 공식을 30년 기간에 적용하면 이런 사건이 한 번 이상 일어날 확률은 약 26 %에서 약 45 %로 높아진다. 그런데도 분석을 아무도 갱신하지 않았다면 필드 값은 여전히 100을 가리킬 것이다.
v1.0에는 기준 기간이나 추정 방법을 적는 필드가 없다. Annex E는 새 선택 필드 같은 추가적 변경은 호환성을 깨지 않는다고 밝히므로, 배포 측은 소비자를 깨뜨리지 않고 이런 필드를 더할 수 있다. 다음은 이 책의 제안이며 v1.0의 일부가 아니다.
"statistics": {
"returnPeriod": 100,
"percentile": 99.2,
"isExtreme": true,
"x-referencePeriod": { "start": "1981-01-01", "end": "2020-12-31" },
"x-method": "annual-maxima, GEV fit",
"x-stationarity": "stationary-assumed"
}x- 접두어는 이들이 지역 확장 필드임을 표시하여, 향후 버전이 표준화할 수 있는 이름과 충돌하지 않게 한다. 이 필드를 이해하지 못하는 소비자는 무시하면 되고, 감사자는 100년 빈도라는 표시가 정상성 가정 아래 분석한 40년 기록에 근거한다는 사실을 한눈에 알 수 있다. 표시된 값은 예시이다.
PHASE-3는 시계열용 LSTM 계층, 공간 패턴용 CNN 계층, 어텐션 메커니즘으로 이루어진 AI 모델을 기술하고, 이를 수리 모델(Saint-Venant 방정식과 천수 방정식) 및 통계 모델과 함께 EnsemblePrediction 안에 둔다. 이는 분야의 실제 흐름을 반영한다. 데이터 기반 모델, 특히 여러 유역의 자료로 학습한 순환 신경망은 강우–유출 예측에서 경쟁력을 보여 왔다. 반면 물리 기반 모델은 자료가 부족한 곳, 조건이 학습 기록의 범위를 벗어나는 곳, 산출물이 질량 보존을 지키는 공간 심도 지도여야 하는 곳에서 여전히 필수적이다.
연구의 최전선은 둘 중 하나를 고르는 문제라기보다 둘을 결합하는 문제에 가깝다. 물리 기반 모의로 희귀 사건의 학습 자료를 만들거나, 학습 모델에 물수지 제약을 걸거나, 기계학습으로 물리 모델의 체계적 오차를 보정하는 방식이다. ENE-033의 앙상블 구조는 이미 이를 수용한다. 구성원이 어떤 방식으로 만들어졌든 일반 FloodPredictionResult 객체로 교환되기 때문이다. 아직 담지 못하는 것은 출처 정보(provenance)이다. 어느 모델 버전, 어느 학습 기간, 어느 입력 자료가 그 구성원을 만들었는지 기록하는 필드가 없다. 학습 모델은 물리 모델이 재보정되는 것보다 훨씬 자주 재학습되므로 이 공백의 중요성은 커질 것이다. 버전을 기록하지 않으면 재학습 뒤에 예측 성능이 달라져도 드러나지 않는다.
README는 단기 예측(1–6시간)을 실시간 강우 레이더에 배정한다. 돌발 홍수와 도시 침수에서 가장 가치 있는 선행 시간은 수 분에서 수 시간 사이인 경우가 많고, 이 구간의 주된 기법은 초단기 예측(nowcasting), 곧 관측된 레이더 에코의 이동과 변화를 외삽하는 방법이다. 초단기 예측의 성능은 선행 시간이 길어질수록 빠르게 떨어진다. 새로 생겨나는 대류 세포를 내다볼 수 없기 때문이다. 더 긴 구간은 수치 예보 모델이 맡으며, 둘을 혼합하는 것이 현업 기관의 표준적인 관행이다.
v1.0에서 PrecipitationData.radar는 영상에 대한 참조(imageUrl, km 단위의 coverage, lastUpdate)이다. 화면 표시에는 충분하지만 계산에는 부족하다. 모델은 그림 URL을 강우장으로 받아들일 수 없다. 자연스러운 발전 방향은 격자 강우 객체, 또는 인정된 형식의 격자 자료에 대한 참조로서 격자 간격·시간 간격·단위를 명시하는 것이다. 기상 기관이 이미 격자 초단기 예측을 제공하고 있다면 배포 측은 그 산출물을 직접 소비하고, ENE-033은 거기서 파생된 지점·유역 시계열에 쓰는 것이 좋다.
ENE-033의 핵심은 확률적이다. FloodPredictionResult는 probability와 confidence를 함께 담고, 앙상블은 평균·중앙값·불확실성을 보고한다. 그러나 대국민 경보는 범주형이다. CAP 메시지에는 severity, urgency, certainty가 각각 하나씩만 있다. 확률 분포를 하나의 범주로 옮기는 지점에서 전달 실패가 가장 많이 일어난다. 경보에 대한 사람들의 반응을 다룬 연구는 오래전부터, 행동 여부가 메시지가 무엇을 하라고 분명히 말하는지, 그리고 그것이 수신자 자신의 위치와 관련되는지에 크게 좌우된다는 점을 강조해 왔다. 확률 숫자만으로는 그런 정보가 전달되지 않는다.
여기서 두 가지 실무적 결론이 나온다. instructions.actions 배열은 위험 단계만큼, 어쩌면 그 이상으로 중요하며, 위험을 묘사하는 문장이 아니라 "지하주차장의 차량을 옮기십시오"처럼 구체적인 행동으로 써야 한다. 그리고 CAP로 보내는 certainty 값은 그날 예보관의 감이 아니라 앙상블과 연결된 문서화된 규칙에서 나와야 한다. 제3장은 FloodAlert 필드를 CAP로 옮기는 방법을 다루었다. 앞으로를 위해 덧붙일 점은, 그 매핑 규칙 자체를 배포 측의 공개 문서에 담아 수신자가 여러 사건에 걸쳐 "Likely"를 일관되게 해석할 수 있게 해야 한다는 것이다.
PHASE-2 §12.1은 외부 시스템 가운데 하나로 스마트시티 플랫폼을 들고, trafficControl, infrastructureMonitoring, citizenServices 세 가지 기능을 적는다. v1.0에서 이들은 불리언 값이다. 연동이 존재한다는 사실만 말할 뿐 무엇을 주고받는지는 말하지 않는다. 많은 도시가 움직이는 방향은 도시 디지털 트윈이다. 건물·도로·배수 시설·센서를 지속적으로 갱신하는 도시 모델로, 예측을 시설 하나하나에 대해 평가할 수 있게 해 준다.
홍수 대응에서 가장 가치 있는 연결은 침수 예측과 경로 안내 사이에 있다. EvacuationRoute.hazards.floodedSegments는 이미 시작점·끝점과 m 단위 수심(depth)을 가진 구간을 담고 있고, RouteStatus는 clear, caution, blocked를 구분한다. 이 구간을 최신 inundationArea와 도로 단위 센서로 갱신하면 대피 API는 정적인 목록이 아니라 실시간 경로 안내 서비스가 된다. 다음 코드는 그 발상을 보여 준다. 수심 기준값은 자리표시자일 뿐 안전 지침이 아니다. 도로를 통제해야 하는 수심은 차종, 유속, 지역 도로 관리 규정에 따라 다르며 책임 기관이 정해야 한다.
import { FloodedSegment, RouteStatus } from './types';
// 자리표시자 값(m). 도로 관리 기관이 정한 값으로 바꿀 것.
const CAUTION_DEPTH_M = 0.05;
const BLOCK_DEPTH_M = 0.15;
function segmentStatus(seg: FloodedSegment): RouteStatus {
if (seg.depth >= BLOCK_DEPTH_M) return RouteStatus.BLOCKED;
if (seg.depth >= CAUTION_DEPTH_M) return RouteStatus.CAUTION;
return RouteStatus.CLEAR;
}
// 경로의 통행 가능성은 가장 나쁜 구간이 결정한다.
function routeStatus(segments: FloodedSegment[]): RouteStatus {
const order = [RouteStatus.CLEAR, RouteStatus.CAUTION, RouteStatus.BLOCKED];
return segments
.map(segmentStatus)
.reduce((worst, s) => (order.indexOf(s) > order.indexOf(worst) ? s : worst),
RouteStatus.CLEAR);
}명시적인 순서 배열에 주목하라. 제5장에서 RiskLevel에 대해 한 권고와 같은 원칙이다. 문자열 열거형 값의 사전식 순서에 기대어 심각도를 매겨서는 안 된다.
디지털 트윈 연계에는 세 가지 주의점이 있다. 첫째, 트윈의 최신성은 가장 느린 입력이 결정한다. 수심 센서가 끊겨서 도로를 "통행 가능"으로 보여 주는 경로 서비스는 "알 수 없음"으로 보여 주는 서비스보다 나쁘다. v1.0의 RouteStatus에는 unknown 값이 없으므로, 배포 측은 오래된 자료를 기껏해야 caution으로 취급해야 한다. 둘째, 트윈은 안전과 직결된 상태에 쓸 수 있는 시스템의 수를 늘린다. 제6장의 RBAC 원칙을 트윈까지 넓혀야 한다. 셋째, 건물과 지형 형상을 교환하기 위한 개방형 도시 모델 표준이 이미 있다(가장 널리 알려진 것은 OGC CityGML이다). 홍수 배포는 자체 형상 포맷을 만들기보다 이런 표준을 소비해야 한다.
PHASE-4는 2015년 유엔 회원국이 채택한 「센다이 재해위험경감 프레임워크 2015–2030」을 참조한다. 이 프레임워크의 일곱 가지 전 지구 목표 가운데 목표 G는 2030년까지 다중 재해 조기경보 체계와 재해 위험 정보의 가용성과 접근성을 크게 높이는 것이다. 2022년 유엔 사무총장은 「모두를 위한 조기경보(Early Warnings for All)」 이니셔티브를 발표했다. WMO가 이끌고 UNDRR, ITU, IFRC가 각각 한 축을 맡는 이 이니셔티브는 2027년 말까지 지구상의 모든 사람을 조기경보 체계로 보호하는 것을 목표로 한다. 이니셔티브의 네 축은 제1장에서 설명한 사슬과 대응한다. 재해 위험 지식, 관측과 예측, 경보 전파와 소통, 대응 준비가 그것이다.
이 프레임워크들은 정책적 맥락일 뿐 ENE-033의 요구사항이 아니며, ENE-033 적합성이 곧 센다이 보고를 의미하지도 않는다. 그럼에도 이들이 중요한 이유는 성공을 모델을 얼마나 돌렸느냐가 아니라 사람에게 얼마나 닿았느냐로 정의하기 때문이다. 이 관점은 사슬의 마지막 구간으로 관심을 옮기며, 표준은 그 구간에 구체적인 기능과 구체적인 공백을 함께 갖고 있다.
FloodAlert.instructions에는 ko와 en 두 개의 텍스트 필드만 있다. 한국어와 영어 사용자는 포괄하지만, 이주 노동자, 관광객, 모국어가 다른 주민은 포괄하지 못한다. CAP 1.2는 메시지 수준에서 이미 이 문제를 해결한다. 하나의 <alert>에 여러 <info> 블록을 넣을 수 있고, 블록마다 자체 <language> 코드를 가진다. 따라서 발행자는 자체 스키마에는 v1.0의 두 필드를 유지하고, 추가 언어는 CAP 출력에만 내보낼 수 있다. 다음은 그 예시 조각이다(식별자, 시각, 지명은 예시이다).
<alert xmlns="urn:oasis:names:tc:emergency:cap:1.2">
<identifier>example-basin-2026-0001</identifier>
<sender>warnings@basin.example.org</sender>
<sent>2026-07-15T14:00:00+09:00</sent>
<status>Actual</status>
<msgType>Alert</msgType>
<scope>Public</scope>
<info>
<language>ko-KR</language>
<category>Met</category>
<event>하천 홍수</event>
<urgency>Expected</urgency>
<severity>Severe</severity>
<certainty>Likely</certainty>
<instruction>하천변 저지대 주민은 지정 대피소로 이동하십시오.</instruction>
<area><areaDesc>예시 하천 하류 저지대</areaDesc></area>
</info>
<info>
<language>en-US</language>
<category>Met</category>
<event>River flood</event>
<urgency>Expected</urgency>
<severity>Severe</severity>
<certainty>Likely</certainty>
<instruction>Residents of low-lying riverside areas: go to your designated shelter.</instruction>
<area><areaDesc>Low-lying area, lower reach of example river</areaDesc></area>
</info>
<info>
<language>vi-VN</language>
<!-- 같은 구조, 미리 준비한 번역문 -->
</info>
</alert>실무적 교훈은 번역이 재난 도중에 이루어질 수 없다는 것이다. 지원하는 각 언어의 행동 요령 템플릿을 미리 작성하고 원어민 검토를 거쳐 저장해 두어야 하며, 발령 시점에는 지명과 시각만 채워 넣어야 한다.
AlertDistribution.recipients에는 고위험 지역 주민, 재난 대응 인력, 공무원, 일반 주민과 나란히 vulnerable(취약 계층) 그룹이 있고, 채널 목록에는 SMS와 푸시뿐 아니라 사이렌, 라디오, TV도 있다. 올바른 구조이다. 사이렌을 듣지 못하는 사람, 휴대전화의 작은 글씨를 읽지 못하는 사람, 도움 없이는 대피할 수 없는 사람에게는 다른 채널과 더 이른 통지가 필요하다. EvacuationShelter.accessibility는 대피소가 이들을 수용할 수 있는지를 기록한다. 개선할 만한 점은 두 가지이다. 경보 웹 페이지와 앱은 W3C WCAG 2.x 같은 공인 웹 접근성 지침을 충족해야 한다. 그리고 취약 계층 그룹에 통지를 보내는 선행 시간은 일반 주민보다 길어야 한다. 그들의 대피에 더 오랜 시간이 걸리기 때문이다. 둘 다 v1.0의 요구사항은 아니다. 또한 취약 계층을 대상으로 삼는 데 필요한 자료는 개인정보이므로 제6장의 최소 수집 원칙이 그대로 적용된다.
PHASE-3의 AlertCriteria는 두 부분으로 되어 있다. automatic 부분은 사람을 기다리지 않고 경보를 올릴 수 있는 조건(위험 단계 LEVEL-2 이상, 확률 60 % 이상, 최소 선행 시간, 최소 영향 인구)을 정의한다. manualReview 부분은 사람이 반드시 검토해야 하는 조건, 곧 높은 불확실성, 핵심 기반시설, 역사적 중요성을 명시한다. 제5장에서 설명했듯이 이 수치 기본값은 참조 구현의 값이지 검증된 임계값이 아니다.
README의 장기 비전에는 "AI 자율 대응: 완전 자동화"가 들어 있다. 이 책은 그 목표를 지지하지 않으며, 이유는 세 가지이다. 첫째, 법적 권한이다. 한국을 포함한 대부분의 나라에서 공식 홍수 예보를 발표하고 대피를 명령할 권한은 법으로 특정 공공기관에 부여되어 있으며, 소프트웨어 시스템은 그 권한을 가질 수 없다. 제1장에서 강조했듯이 홍수통제소가 발표하는 공식 용어(홍수주의보, 홍수경보)는 ENE-033의 LEVEL 척도와 별개이다. 둘째, 책임성이다. 경보가 틀렸을 때 누군가는 그 경보가 왜, 어떤 근거로 발령되었는지 설명할 수 있어야 하며, 이를 위해서는 적어도 결과가 중대한 경보 부류에 사람의 결정 지점이 있어야 한다. 셋째, 제5장에서 다룬 희귀 사건 문제이다. 극한 사건은 학습 기록에 드물기 때문에, 모델은 홍수가 가장 극단적인 바로 그 지점에서 가장 약하다.
방어 가능한 설계는 자동화를 판단을 없애는 수단이 아니라 시간을 버는 수단으로 다룬다. 자동 발령은 좁게 정의되고 사전에 승인된 경우로 한정한다. 예를 들어 관측된 수위 상승률이 문서화된 임계값을 넘을 때 공무원에게 LEVEL-1 또는 LEVEL-2 통보를 보내는 경우이다. 반면 대피로 이어지는 모든 경보는 manualReview를 거친다. 시스템의 역할은 근거를 제시하고, CAP 메시지 초안을 작성하고, 시계를 작동시키는 것이다. 그래야 사람의 결정이 한 시간이 아니라 몇 분 안에 이루어진다.
v1.0의 FloodAlert는 발령 주체는 기록하지만 결정의 근거는 기록하지 않는다. 사후 검토와 책임 문제를 위해 모든 경보에 대해 다음 정보를 찾아볼 수 있어야 한다. 경보의 근거가 된 예측 ID, 앙상블에 쓰인 모델 버전, 자동 발령인지 검토 후 발령인지 여부, 승인한 사람이다. 이 정보가 공개 CAP 메시지에 들어갈 필요는 없다. 제6장에서 설명한 감사 로그에 두고 alertId로 연결하면 된다. 향후 버전이 이를 스키마에 추가한다면 공개 페이로드가 아니라 내부 봉투에 넣어야 한다.
모든 경보 체계는 허위 경보와 놓친 사건을 맞바꾼다. 임계값을 낮추면 더 많은 홍수를 잡아내지만 불필요했던 것으로 드러나는 경보도 늘어나고, 임계값을 높이면 그 반대가 된다. 불필요한 경보가 되풀이되면 대중의 반응이 무뎌질 수 있으며 이를 흔히 경보 피로라고 부른다. 다만 일부 연구는 그 효과가 흔히 생각하는 것보다 약하며, 경보가 왜 현실화되지 않았는지 설명하는 것이 신뢰 유지에 도움이 된다고 제시한다. 명세의 설계 목표(허위 경보율 15 % 이하와 높은 재현율)는 의도를 밝힌 것이지 입증이 아니다. 제5장은 이 지표들이 분할표 위에서 정의되기 전에는 의미가 없다는 점을 보였다. 앞으로를 위한 권고는 놓친 사건을 포함한 검증 통계를 계절마다 공개하고, 그에 비추어 AlertCriteria의 임계값을 재검토하는 것이다. 결과에 비추어 한 번도 다시 살펴보지 않은 임계값은 아무리 정밀해 보여도 추측에 불과하다.
| 결정 부류 | 제안하는 방식 | 근거 |
|---|---|---|
| 당직 예보관에게 보내는 내부 알림 | 완전 자동 | 대외적 결과가 없고 속도가 가장 중요함 |
| 공무원·대응 인력에 대한 LEVEL-1/LEVEL-2 통보 | 사전 승인된 규칙에 따라 자동, 담당자에게 통지 | 준비 시간을 벌어 주며 되돌릴 수 있음 |
| LEVEL-3 이상 대국민 경보 | 자동으로 초안 작성, 사람의 승인 후 발령 | 법적 권한과 책임성 |
| 대피 명령 | 법적 권한을 가진 기관의 사람이 결정 | 결과가 가장 중대함, 시스템은 근거만 제공 |
| 해제 또는 하향 | 발령과 같은 검토를 거친 사람의 결정 | 섣부른 해제는 늦은 경보만큼 해로울 수 있음 |
이 표는 이 책의 제안이며 ENE-033의 요구사항이 아니다. AlertCriteria의 두 부분, 그리고 시스템은 근거를 제공하고 법적 책임을 지는 사람이 결정한다는 원칙과 일관되도록 작성했다.
README는 네 가지 기여를 요청한다. GitHub 이슈를 통한 기술 피드백, 구현 경험을 담은 사례 연구, 번역, 그리고 데이터 포맷이나 API 개선 제안이다. 각 PHASE 문서의 Annex F는 로드맵에 대한 의견을 GitHub의 WIA-Official 조직 이슈 트래커로 받는다고 덧붙이고, 구현자에게 릴리스 알림을 구독해 Stable·Provisional·Reference 계층 사이의 승격을 추적하라고 권고한다. 이 장의 참조에 연결된 공개 저장소가 출발점이다.
가장 유용한 기여는 8.1절에 나열한 공백을 메우는 것이다. 실제 배포에서 도출한 시험 벡터(개인정보 제거), 두 가지 폐기 유예 기간이나 두 가지 적합성 어휘 같은 불일치의 정정, 그리고 ENE-033 객체와 기관이 이미 쓰는 형식 사이의 매핑 사례가 그렇다. 표준이 운영에 필요한 것을 표현하지 못했던 지점을 알리는 부정적 결과 보고도 기능을 추가하는 기여만큼 가치가 있다.
README는 관련 WIA 표준 다섯 가지를 든다. WIA-ENE-001(기후 변화 관리), WIA-ENE-012(수질 모니터링), WIA-ENE-019(대기질 모니터링), WIA-ENE-029(생태계 모니터링), WIA-CITY(스마트시티 통합)이다. 이 가운데 WIA-CITY는 8.4절의 디지털 트윈 작업에, WIA-ENE-001은 8.2절의 기후 문제에 가장 가까운 짝이다. ENE-033은 WIA 문서가 아닌 외부 표준에도 기대고 있다. 관측에는 OGC WaterML 2.0, 경보에는 OASIS CAP 1.2, 수문 실무에는 WMO HOMS 구성요소가 대표적이다. ENE-033은 이러한 국제 표준을 참조하는 WIA 표준이며, 그 자체가 ISO, IEC, WMO 표준은 아니다. 그렇게 소개해서도 안 된다.
ENE-033 도입을 검토하는 기관이라면 다음 순서로 이 책의 내용을 실행에 옮길 수 있다. 순서는 달력이 아니라 의존 관계에 따른 것이다.
| 단계 | 할 일 | 관련 장 |
|---|---|---|
| 1 | 수위계, 우량계, 댐, 배수 시설을 목록화하고 기준면·단위·시각 출처를 기록 | 2 |
| 2 | 기준 수위와 LEVEL-0..4를 기관의 공식 예보·위기 용어에 대응시키는 명시적 규칙 작성 | 1, 3 |
| 3 | 통합 패턴과 토폴로지를 선택하고 /alert/create 호출 권한자를 결정 | 6 |
| 4 | 수집 기능과 예측 API를 구축하고 샘플 객체를 스키마로 검증 | 2, 4 |
| 5 | 앙상블 구성원을 최소 두 개 운영하고 첫날부터 검증 통계를 축적 | 5 |
| 6 | 고유 경보와 함께 CAP 1.2를 발행하고 다국어 행동 요령 템플릿을 준비 | 3, 8 |
| 7 | partial·excluded 요구사항을 정직하게 표시한 프로필 매니페스트를 공개 | 7 |
| 8 | 훈련으로 종단 간 리허설을 한 뒤 결과에 비추어 임계값을 재검토 | 6, 8 |
x- 필드로 소비자를 깨뜨리지 않고 이를 기록할 수 있다.floodedSegments를 실시간 경로 안내로 바꿀 수 있다. 단, 오래된 자료를 "통행 가능"으로 보여서는 안 된다.<info> 블록과 vulnerable 수신자 그룹이 그 도구이다.홍수는 표준이 개정되는 속도보다 빠르게 변할 것이다. 공유 표준의 가치는 어느 한 버전에 있기보다, 수문학자·예보관·재난 관리자·소프트웨어 공급자가 표준의 공백을 함께 찾아 메울 수 있는 공통 어휘를 제공하는 데 있다.