위성은 디포가 침수되었다고 보고했습니다. 그러나 그것은 구름 그림자였고, 파라메트릭 트리거는 $1.2M의 자동 지급을 단 한 번의 클릭만 남겨두고 있었습니다.

위성이 Mesa Junction Depot을 관측했을 때 마른 땅이어야 할 곳에서 어두운 영역을 발견하고 해당 위치를 홍수로 분류했습니다. 파라메트릭 홍수 보험 정책은 이 트리거를 사실로 받아들여 손해사정사도, 전화 한 통도, 재검토도 없이 $1.2M의 보험금이 자동으로 지급되도록 준비했습니다. 하지만 그 어두운 영역은 구름 그림자였습니다. 6일 후 위성 영상에서는 사라졌고, 그 아래 지면은 한 번도 젖은 적이 없었습니다.

단일 위성 프레임으로는 절대 잡아낼 수 없는 사례이기에, 저는 의도적으로 바로 그 사례를 구축했습니다. 저는 Ashutosh이며 Veriprajna를 이끌고 있습니다. TriggerProof는 파라메트릭 홍수 보험에서 위험한 순간은 감지가 아니라 지급 결정이라는 구체적인 주장을 증명하기 위해 제가 만든 데모입니다. 이 데모에 포함된 모든 위치, 타일, 하천 수위계, 현장 보고서는 장애 모드를 명확히 재현할 수 있도록 물리적 충실도를 반영해 제가 직접 작성한 합성 대리 데이터입니다. 다음 주소에서 직접 열어보고 전체 시스템을 작동해 볼 수 있습니다: veriprajna.com/ko/demos/satellite-flood-intelligence. Mesa Junction Depot은 제가 실제로 무엇을 구축하고 있는지 깨닫게 해 준 사례이므로, 여기서부터 이야기를 시작하고자 합니다.

서로 다른 네 가지 요인이 동일한 픽셀을 어둡게 만듭니다

합성 영상을 생성하기 위해 앉아서 한 프레임 안에 네 가지 요소를 동일하게 보이도록 만들어야 했을 때에야 저는 진정한 문제를 실감했습니다. 파라메트릭 홍수 보험은 손해사정사를 트리거로 대체했습니다. 위성이 특정 위치가 침수되었다고 보고하면 자금이 이동하는 구조입니다. 문제는 단일 광학 영상이나 한 번의 레이더 통과 관측에서 실제 홍수 침수수, 구름 그림자, 레이더 또는 지형 그림자, 영구 저수지가 모두 동일한 방식으로 어둡게 나타난다는 점입니다. 이들을 구분하는 정보가 단일 프레임 내에는 존재하지 않기 때문에 단일 프레임만으로는 이들을 분별할 수 없습니다.

이는 제게 데모 전체의 관점을 바꾸어 놓았습니다. 이 비즈니스에서 치명적인 오류는 트리거가 놓치는 홍수가 아닙니다. 바로 트리거가 만들어내는 가짜 홍수입니다, 1년 뒤 재보험사가 문의했을 때 해당 결정을 변호할 증거 기록도 없이 그림자에 대해 확신을 갖고 $2M을 지급하는 일 말입니다. TriggerProof는 홍수를 감지하지 않으며 위성 데이터를 생성하지도 않습니다. 이미 발동된 트리거를 가져와 실제로 지급해야 하는지 여부를 판정합니다.

한 프레임은 홍수라고 했지만, 다음 프레임은 지면이 결코 젖지 않았음을 보여주었습니다

Mesa Junction 필름스트립이 처음으로 제대로 렌더링되었을 때 한 단계씩 넘겨보던 순간이 아직도 생생합니다. 인터페이스를 통해 플래그가 지정된 위치를 열고 광학 영상을 상단에, 레이더 영상을 하단에 두고 관측 프레임을 하나씩 살펴볼 수 있습니다. 트리거 프레임에는 경보를 울렸던 바로 그 원인인 수분 신호 녹색의 어두운 영역이 그대로 나타납니다. 다음 관측 단계로 넘어가면 그 영역은 사라집니다. 뒤로 돌아가 확인해 보면 동일한 영역 아래의 레이더 후방산란은 모든 프레임에서 정상 수치를 나타내는데, 레이더는 내내 구름을 뚫고 마른 땅을 똑바로 관측했기 때문입니다.

그림자는 이동했지만, 물이었다면 그대로 남아 있었을 것입니다. 이는 시간 경과와 여러 센서를 교차 비교해야만 확인할 수 있으며, 트리거를 발동시킨 단일 프레임만으로는 절대 볼 수 없습니다.

프레임들을 나란히 놓고 보면 물리적 원리는 결코 모호하지 않습니다. 구름 그림자는 일시적이며 구름의 속도로 이동하므로 한 관측에서는 어둡게 나타나지만 다음 관측에서는 사라집니다. 실제 홍수 침수수는 여러 관측에 걸쳐 지속되며 광학 영상에서 어둡게 나타남과 동시에 레이더에서도 낮은 수치를 기록합니다. 시간 지속성과 레이더-광학 일치성이라는 두 가지 규칙이 바로 이를 정확히 인코딩합니다. Mesa Junction의 경우 두 규칙 모두 불합격(FAIL)으로 판정되어 분류기는 1.00의 신뢰도로 구름 그림자라는 결론을 내립니다. $1.2M는 결코 지급 대기열에 들어가서는 안 되었습니다.

결정은 언어 모델이 아니라 다섯 가지 규칙이 내립니다

초기에는 언어 모델에 이 판정을 맡겨보려 시도했었는데, 매우 교훈적인 방식으로 실패했기 때문에 그렇게 시도하길 정말 잘했다고 생각합니다. 동일한 증거를 읽는 에이전트를 두고 해당 위치가 실제로 침수되었는지 사실상 물어보았습니다. 모호한 사례에서 모델은 홍수가 맞다고 주장하는 유창하고 확신에 찬 문단을 작성했으나 이는 틀렸고, 모델의 어조에서는 오류를 암시하는 어떠한 기미도 없었습니다. 그날 오후에 내린 설계 결정은 지금까지 한 번도 다시 번복되지 않았습니다.

따라서 결정 로직은 자금이 이동하는 경로 상에 모델이 전혀 개입하지 않는 상태로, 검사 가능한 5가지 판별기를 통해 순수 파이썬(Python) 코드로 구현되어 있습니다. 시간 지속성(R1)은 홍수와 일시적인 구름 그림자를 분리합니다. 레이더-광학 일치성(R2)은 홍수를 구름 그림자 및 레이더 그림자 모두와 분리합니다. DEM 경사도(R3)는 가파른 지형에 고여 있어야만 하는 물을 기각합니다. 영구 수역 마스크(R4)는 알려진 저수지를 제외합니다. 수문학적 연계성(R5)은 침수 구역이 실제로 배수망과 연결되는지 확인합니다. 검증기가 결정하고, 언어 모델은 조언만 할 뿐입니다. 이 자문 에이전트는 Pydantic AI를 기반으로 구축되었으며 모델 교체가 가능하고 기본값은 claude-opus-4-8이며, 물리적 판정 결과를 독립적인 지상 신호와 대조하여 확증(corroborates), 모순(contradicts) 또는 결론 불가(inconclusive)를 반환합니다. 에이전트의 판단은 기각될 수 있으며, API 키를 빼면 데모는 결정론적 폴백을 통해 완전 오프라인으로 실행됩니다. 지급 결정에 있어 신뢰할 수 있는 부분은 확신에 찬 문단을 읊는 모델이 되어서는 안 되기 때문입니다.

물리적 신호 자체에 확신이 없을 때, 시스템은 추측하는 대신 담당자에게 이관합니다

저는 명확하게 판별된 사례보다 시스템이 "알 수 없음"이라고 판단하는 사례에 더 주목합니다. Canal Street Hub가 바로 그러한 사례입니다. 광학 및 레이더 특성 신호가 경계선상에 걸쳐 있고 홍수 신호는 3개 프레임 중 2개에서 지속되었으나, 독립적인 하천 수위계는 범람 수위를 결코 넘지 않았습니다. 증거가 명백히 충돌한 것입니다. 산출된 신뢰도는 0.151로 라벨링된 데이터셋을 기반으로 설정한 자동화 기준선인 0.65에 훨씬 미치지 못했으며, 지상 에이전트는 위성 분류 결과와 정면으로 배치되었습니다.

정책 게이트는 동전을 던져놓고 이를 자동화라 부르는 대신, "입증 필요" 표시와 함께 모든 증거를 첨부하여 해당 $0.8M 건을 담당자에게 전달합니다. 진정으로 모호한 사례를 담당자에게 이관하는 홍수 트리거를 일부 구매자는 더 열등한 제품으로 볼 수도 있습니다. 하지만 저는 다르게 봅니다. 이것이야말로 무인 상태로 운영되도록 맡길 수 있는 유일한 버전입니다, 여기서 이관을 하지 않는 대안이란 실제 돈을 걸고 결정을 가장한 성급한 추측을 내리는 것에 불과하기 때문입니다.

제가 계속해서 되돌아보게 되는 포트폴리오 수치

제가 8개 위치로 구성된 포트폴리오를 계속 확인하는 이유는 개별 사례로는 보여줄 수 없는 방식으로 위험 규모를 구체화해 주기 때문입니다. 폭풍이 8개 지역 포트폴리오를 지나갑니다. 기존의 단일 프레임 트리거는 그중 6개 지역에 발동하여 $8.0M의 자동 지급 대기열을 생성합니다. TriggerProof는 이 포트폴리오를 심사합니다. 2건의 실제 홍수를 확인하여 $4.0M를 지급하고, 3건의 오탐(구름 그림자 $1.2M, 레이더 그림자 $1.0M, 영구 저수지 $1.0M)을 차단하여 $3.2M의 지급을 보류하며, 1건의 모호한 사례($0.8M)는 담당자에게 이관합니다.

기존 트리거가 지급했을 금액의 절반인 $8.0M 중 $4.0M가 차단되거나 증빙을 위해 보류되었습니다. 바로 이것이 그 수치이며, 그 범위에 대해 명확히 말씀드리고자 합니다. 이는 실제 청구 포트폴리오가 아니라 물리적으로 충실하도록 제가 제작한 8개 사례의 데모용 합성 포트폴리오입니다. 메커니즘은 실제이며 검사 가능합니다. 메커니즘이 작동하는 모습을 직접 확인할 수 있도록 청구 사례를 구성한 것입니다.

위험한 결정 0건, 그리고 결코 빠뜨릴 수 없는 주의 사항

8개 사례의 포트폴리오는 이야기에 불과하며 증거가 아니기 때문에 저는 적절한 벤치마크를 실행했습니다. 테스트 하네스는 명확한 특성 신호부터 임계값에 근접한 노이즈에 이르는 60개의 라벨링된 사례를 평가합니다. 핵심 결과는 정확도 점수가 아니라 안전 횟수입니다: 플래그가 지정된 모든 사례를 지급하는 단일 프레임 기준선(baseline)의 48건 대비 위험한 자동 결정 0건이라는 수치입니다. 전체 사례의 80%는 자동 해결되고 불확실한 20%는 이관됩니다. 자동 해결된 사례 중 오탐 차단율은 36건 중 36건, 홍수 재현율은 12건 중 12건이며, 진정으로 모호한 12건의 사례는 모두 자동 결정되지 않고 담당자에게 이관됩니다.

제 자체 테스트 세트에서 완벽한 점수를 얻는 것은 애초에 목적이 아니었습니다. 요점은 시스템이 위험한 자동 결정을 결코 내리지 않는다는 점입니다. 확신이 없을 때 시스템은 담당자에게 이관합니다.

이러한 모든 수치에는 주의 사항이 항상 수반되며, 저는 이를 결코 누락시키지 않을 것입니다. 이 수치들은 물리적으로 충실하게 제작된 60개의 합성 라벨링 데이터셋에서 측정된 것이지 오픈 월드에 대한 보증이나 실제 현장 결과가 아닙니다. 솔직한 다음 단계는 더 과장된 주장이 아니라 Sen1Floods11과 같은 실제 아카이브 및 실제 Sentinel 장면에 대한 검증이며, 이는 실제 프로젝트 계약을 통해 제공될 첫 번째 과제이지 본 데모에서 수행된 작업이 아닙니다. 이를 솔직하게 밝히는 것이야말로 나머지 수치들을 당당하게 지지할 수 있는 근거입니다.

나중에 정당성을 입증할 수 없는 지급금은, 설령 맞았더라도 부채입니다

처음부터 증거 기록을 핵심으로 삼으려던 것은 아니었지만, 결국에는 보험사가 진정으로 신뢰하고 의지할 수 있는 부분이라는 확신을 갖게 되었습니다. 나중에 재구성할 수 없는 올바른 지급금은 여전히 부채입니다. "위성이 그렇게 말했다"는 재보험사나 감사관이 수용할 수 있는 방어 논리가 아니기 때문입니다. 따라서 지급이든 차단이든 모든 결정은 포렌식 서류철을 생성합니다. 여기에는 모든 프레임의 데이터 계보(data lineage), 각 판별기의 측정값이 포함된 규칙별 증거, 오탐 제거 로그, 독립적인 지상 데이터 교차 참조, 그리고 해당 결정의 SHA-256 출처(provenance) 해시가 포함됩니다.

저는 해당 해시가 무엇이고 무엇이 아닌지에 대해 신중하게 짚고 넘어가고자 합니다. 이는 기록의 위변조를 방지(tamper-evident)하는 콘텐츠 해시로, 누구나 이를 다시 계산하여 사후에 결정이 변경되지 않았는지 확인할 수 있습니다. 이는 PKI 전자 서명이 아니며 위성 데이터 검색, SAR 태스킹, 지상 데이터 피드, 보험금 청구 플랫폼 통합은 모두 본 데모에서 스텁(stub)으로 처리되어 제 노트북에서 전체가 작동하도록 시뮬레이션되었습니다. 실제 존재하는 것은 바로 그 기록의 구조입니다: 모든 자동 지급 결정에 대해 정확히 어떤 물리적 원리가 어떤 신뢰도로 무엇을 나타냈는지, 그리고 어떤 독립적인 신호와 교차 검증되었는지를 명시하는 구조입니다.

파라메트릭 보험은 손해사정사를 포기하는 대신 즉각적이고 분쟁 없는 지급을 가능케 하는 실질적인 절충(trade-off)을 택했습니다. 하지만 그 결과 단일 프레임으로는 간파할 수 없는 물리적 문제를 떠안게 되었으며, 이러한 절충으로 인해 노출되는 장애는 바로 그림자에 대해 신속하고 확신에 찬 지급을 실행하는 것입니다. 지속 가능한 해결책은 모델 외부에 존재합니다. 시간과 센서를 교차하여 유사한 현상을 구별하는 결정론적 규칙, 모호한 사례를 사람에게 이관하는 게이트, 각 결정을 방어할 수 있도록 만드는 기록입니다. 더 선명한 위성도 판정 문제를 해결하지는 못하며, 이것은 본질적으로 판정의 문제입니다.

글로 된 설명을 읽기보다 직접 확인하고 싶으시다면, 전체 시스템이 처음부터 끝까지 실행되는 모습을 아래에서 보실 수 있습니다.

Mesa Junction은 제가 계속해서 언급하게 되는 사례입니다. 두 번째 관측만이 그림자와 홍수의 차이를 알고 있었으나 트리거는 두 번째 관측 데이터가 도착하기도 전에 발동되었습니다. 다음 주소에서 해당 필름스트립을 직접 단계별로 확인하고, 트리거가 발동되었어야 한다고 생각했던 지급 건을 검증해 볼 수 있습니다: veriprajna.com/ko/demos/satellite-flood-intelligence. 지난 시즌 귀하가 자동 지급한 트리거 중 그림자가 아닌 실제 침수였음을 지금도 입증할 수 있는 건은 과연 몇 건이나 됩니까? 자동화된 홍수 포트폴리오를 운영하는 모든 분께 드리고 싶은 질문은 바로 이 명확하고 답할 수 있는 질문입니다.