서비스를 실제로 만들고, 쓰고, 신뢰받기 위해
반드시 해결해야 하는 질문들의 지도
"이게 POC 수준 맞아?"
핵심 아이디어 증명은 됐다. 온톨로지 추론으로 구조 우선순위를 자동 산출하고,
돌발상황 팝업과 이벤트 재계획까지 시각화했다.
그러나 POC의 한계도 명확하다. 실제 소방관이 써본 적 없고,
하드코딩 데이터로만 돌아간다.
"서비스가 되려면 뭘 풀어야 해?"
두 가지로 시작했지만 다섯 가지로 확장됐다.
소방관 경험을 규칙으로 변환하는 방법이 없다
기존 규칙과 충돌하는 상황을 어떻게 처리하나
AI가 틀렸을 때 누가 책임지는가 — 법제도 미비
주민 이사·사망 등 실시간 반영 파이프라인 없음
화재 종료 후 결과를 시스템에 반영하는 구조 없음
"팔란티어는 이 문제를 어떻게 풀어?"
알고리즘이 아니라 운영 모델로 푼다.
엔지니어가 수개월간 소방관 옆에서 일하며 암묵지를 직접 추출한다
모든 추천의 근거를 기록. "AI가 추천, 사람이 승인"이라는 책임 체계 구축
AI는 옵션을 좁혀줄 뿐. 지휘관이 최종 승인. 완전 자동화를 의도적으로 안 한다
핵심 인사이트: 팔란티어가 비싼 이유는 소프트웨어가 아니라 소프트웨어 + FDE + 운영체계를 같이 파는 것이기 때문이다. PATOS가 실제 서비스가 되려면 기술 완성도보다 "누가 소방서에 들어가서 같이 일할 것인가"가 더 중요한 질문이다.
"실제 소방관은 이걸 쓰고 싶어할까?"
오늘 대화의 모든 질문이 만드는 사람 시점이었다. 기술적으로 얼마나 정교한지와 별개로, 현장에서 "이 화면 보면서 판단 내릴 수 있겠다"는 피드백이 없으면 다음 단계로 갈 수 없다.
화재 현장의 소방관은 스트레스 극한 상황에서 판단한다. UI/UX, 정보 밀도, 응답 속도 — 모두 현장에서 검증돼야 한다.
실제 소방관이 한 번도 써본 적 없음
"에이전트 군집으로 바꾸면 더 강력하지 않아?"
TypeDB 중심 구조 vs. LLM Agent 군집 구조 — 근본적인 아키텍처 질문
PATOS의 답: 화재 대응은 생명이 걸린 시스템이다.
TypeDB 규칙이 안전핀이고, Agent가 유연성을 더한다.
정상 상황 → TypeDB, 규칙 밖 돌발상황 → Agent 옵션 제시 → 지휘관 최종 결정.
항공기 자동조종 구조와 같다.
"프롬프트도 규칙도 결국 사람이 설계하면 수렴하는 거 아냐?"
TypeDB 규칙이든 Agent 시스템 프롬프트든 — 설계자의 지식 수준이 천장이다.
사람이 TQL 규칙을 수동 작성
→ 명시한 것만 처리
사람이 시스템 프롬프트 설계
→ 기준 밖은 LLM이 일반화
형식만 다를 뿐
설계자 지식이 한계
수동 설계의 한계를 넘으려면 실제 출동 데이터 + 결과 피드백으로 시스템이 스스로 가중치를 학습해야 한다.
그러나 PATOS는 화재 데이터가 희소하고 결과 측정이 어렵다.
→ 학습 루프 구현이 v5의 가장 어려운 과제이자, 상용화의 진짜 열쇠다.
여섯 개의 질문이 하나의 결론으로 수렴한다
"사람이 설계하는 한계를 어떻게 넘는가"
→ 학습 루프가 답이고, 그게 상용화의 마지막 관문이다.
PATOS v4.4 — Predictive Agentic Triage OS · 소록마을 화재 대응