Predictive Agentic Triage OS — 지능형 재난 대응 데이터 흐름도
FIRE-2026-001 기준 · 베테랑 소방관의 판단이 목표 기준선
| 시간 | 상황 | 베테랑 소방관 | 1단계 POC | 2단계 TypeDB | 3단계 LLM |
|---|---|---|---|---|---|
| T+0 | 신고 접수 | "마 씨 집이면 23-7번지. 샌드위치 패널이고 골목이 좁아." | '마 노인네' 텍스트 매칭 시도. 주소 인식 실패 가능 | '마 노인네' → 주민 DB 그래프 검색 → 자동 매핑 | "귀가 어두우셔서"가 난청 플래그임을 문맥으로 인식 |
| T+7초 | 건물 조회 | "접근로 1.8m. 소방차 절대 못 들어가. 도보로 들어가야 해." | ✓ 1.8m < 3m → 도보선발대 플래그 | ✓ 소방차 진입 불가 관계 자동 생성 | ✓ "1.8m이면 들것도 힘들다" 추가 판단 |
| T+10초 | 거주자 확인 | "84세 귀 어두우시고 혼자. 서울 자녀 연락은 소용없어." | ✗ 서울 비상연락처에도 자동 발송 | △ 서울(150km) 관계 인식, 판단은 불가 | ✓ "이장 직접 연락으로 대체" 자동 판단 |
| T+13초 | 화재 계산 | "바람 세고 건조. 샌드위치 패널이면 2~3분이면 끝나." | ✓ 플래시오버 2.5분 계산 | ✓ 인접 건물 거리 관계 포함 | ✓ "지금 바로 발령 안 하면 늦는다" 긴박성 표현 |
| T+15초 | 인접 위험 | "바람이 BLDG-006 방향. 조만수 씨도 귀 어두우신데." | ✗ 인접 건물 위험 계산 없음 | △ 이웃 관계 존재, 풍향 없으면 방향 판단 불가 | ✓ 조만수(81세, 난청) 동시 경보 발령 |
| T+2분 | 이장 위치 | "이장이 마을 안에 있나? 없으면 자율방재단 먼저." | △ 위치 모름. 항상 이장 ARS 발송 | △ 실시간 위치 연동 없으면 판단 불가 | ✓ "응답 없으면 3분 후 자율방재단으로 전환" |
| T+2분30초 | 플래시오버 | "이 시간이면 비닐 다 탔어. 진입 강행하면 선발대 위험." | △ 경고 메시지만 출력 | △ 이벤트 → 노드 상태 업데이트 | ✓ "진입 전 구조물 안전 확인 필요" 경고 |
| T+5분 | 이장 도착 | "어두워서 손전등 없으면 못 들어가." | ✗ 현장 이후 추적 없음 | △ GPS 연동 시 도착 확인 가능 | ✓ 손전등 지참 여부, 진입 동선 안내 |
| T+12분 | 소방차 도착 | "이미 이장이 할머니 데리고 나왔으면 진압만 하면 돼." | △ 도착 시각 계산만 함 | △ 자원 노드 → 도착 이벤트 업데이트 | ✓ 구조 성공 시 진압 모드, 실패 시 구조 우선 |
기술보다 이 두 가지가 더 오래 걸린다
수행일지에는 "결과"만 기록된다. "03:14 신고접수 → 03:27 현장도착" — 왜 이장한테 먼저 전화했는지, 차를 어디 세웠는지는 없다.
20년 경력의 판단은 기록되지 않는다. 몸이 기억하는 것, 눈으로 읽는 것은 문서화가 안 돼 있다.
PATOS 현실적 접근: 고흥소방서 1개소, 소록마을 한정. 소방관 1~2명 인터뷰 3회. 질문은 하나 — "이 마을에서 밤에 불 났을 때 가장 먼저 하는 게 뭐예요? 왜요?"
관계 그래프 전체를 연쇄 재계산할 수 있다.
한계: 분기를 설계자가 미리 전부 정의해야 함. 돌발 조합이 늘면 기하급수적으로 복잡해짐.
사전 정의 없이 맥락으로 판단한다.
한계: 정상 흐름에 쓰기엔 느리고 비용이 있음. 돌발 상황에만 쓰는 게 효율적.
이 분기 자체를 시스템이 판단하게 하면 TypeDB 구현 범위를 "정상 케이스만"으로 좁힐 수 있다.
플랫폼이 되면: 고흥소방서가 올린 암묵지, 여수소방서가 올린 암묵지가 각각 다른 레이어로 쌓인다. 코어는 하나, 현장 지식은 무한히 추가된다. 이게 Palantir의 사업 모델이고 PATOS가 전국으로 확장되는 경로다.
고흥소방서 1~2명, 3회. 질문은 하나만 — "이 마을에서 밤에 불 났을 때 가장 먼저 하는 게 뭐예요? 왜요?"
TypeDB 없이 goheung_dataset.json + Claude API 직접 연결. "서울 자녀 연락이 의미없다"는 판단을 시스템이 스스로 하는지 검증.
고흥군청 또는 소방서 한 곳에서 "써보고 싶다"는 말 한 마디. 거기서부터 예산과 사람이 붙는다.
PATOS의 현재 역할 — "이 문제가 실재한다"는 것을 보여주는 것. 완성품이 아니라 대화의 시작점이다.
지금 풀어야 하는 것과 나중에 풀면 되는 것
팔란티어가 군사 시스템에서 가장 집착하는 것이 이 두 가지다. 모든 판단에 reasoning_chain을 저장하는 이유.
이슈 1·2를 Claude API 연동으로 빠르게 검증한다.
TypeDB 없이 goheung_dataset.json + Claude API — "서울 자녀 연락이 의미없다"는 판단을 시스템이 스스로 하는지 확인. 이게 되면 나머지는 서비스화 단계에서 하나씩 붙인다.
PATOS 설계 철학 · Palantir FDE 방법론 기반
재난 상황을 모니터링하는 웹 브라우저 기반 SPA (Single Page Application).
마을 지도, 4단계 대응 시퀀스, 우선 구조 대상자 카드를 실시간 시각화합니다.
전체 논리 연산을 제어하는 두뇌 서버. 데이터를 수집하고 최적의 지시서를 생성합니다.
인지 취약성과 물리적 고립성을 종합해 100점 만점으로 대상을 평가합니다.
건축 자재와 실시간 기상을 결합하여 플래시오버(전소) 시간을 계산합니다.
거주자와 건물, 규칙 간의 복잡한 논리 관계를 연결하는 DB입니다.
판단의 근거가 되는 고흥군 내부 건물 및 주민 정적 데이터입니다.
화재 확산 연산에 필요한 실시간 풍속, 습도, 기온을 수집합니다.