전라남도는 대한민국에서 가장 독특한 지형 조건을 가진 지역 중 하나입니다. 22개 시군 가운데 신안군·완도군·진도군은 섬으로 이루어져 있거나 반도 끝에 위치해 있고, 고흥군·해남군·보성군 등은 산림과 직접 맞닿아 있습니다. 도시 기준으로 생각하면 평범해 보이는 조건들이 이 지역에서는 전혀 다른 의미를 가집니다.

화재가 발생하고 소방차가 도착하는 데 31분이 걸린다면 어떻게 될까요. 일반적인 목조 단독주택은 화재 발생 후 5~10분이면 전소에 가까워집니다. 아파트나 콘크리트 건물은 그보다 느리지만, 노후 건물이 밀집한 농촌 마을에서는 불씨가 옆 건물로 옮겨붙는 데 그리 오랜 시간이 걸리지 않습니다. 31분이라는 출동시간은 단순한 지연이 아니라, 초기 진압 가능성 자체가 사라진다는 의미입니다.

여기에 바람이 더해지면 상황은 더 나빠집니다. 전라남도는 해안과 인접해 있어 풍속이 강한 날이 많습니다. 산림 인접 지역에서 화재가 나고 풍속이 6~8m/s 이상이면, 불이 산으로 번지는 속도는 사람이 걸어서 피하기 어려운 수준이 됩니다.

우리가 이 문제를 선택한 이유는 여기에 있습니다. 잘 보이는 위험이 아니라, 구조 속에 숨어 있는 위험을 미리 발견하고 대비할 수 있다면 실질적인 피해를 줄일 수 있다는 판단이었습니다. 그리고 그 '구조 속 위험'을 찾으려면 숫자만으로는 부족하다는 것도 이미 알고 있었습니다.

가장 먼저 한 건 취약도 점수를 만드는 것이었습니다. 노후건물 비율, 출동시간, 화재 발생 이력, 도서지역 여부, 산림 인접 여부. 다섯 가지 지표에 가중치를 곱해서 0에서 1 사이의 숫자로 정렬했습니다.

취약도 = 0.30 × 노후건물비율
       + 0.30 × 평균출동시간(정규화)
       + 0.15 × 화재밀도(5년/km²)
       + 0.15 × 도서지역여부(0 or 1)
       + 0.10 × 산림인접여부(0 or 1)

결과: 신안군 0.751 · 완도군 0.711 · 진도군 0.703
      고흥군 0.533 · 해남군 0.523

이 점수는 분명 유용합니다. 어느 지역이 상대적으로 더 위험한지는 잘 보여줍니다. 하지만 이 숫자를 들고 "그럼 신안군에 자원을 더 배치하면 되겠네"라고 결론을 내리기엔 결정적으로 빠진 정보가 있습니다.

통계 모델은 개별 지표를 잘 처리하지만 관계와 구조를 이해하지 못합니다. 소방서가 어디를 담당하는지, 섬이라는 물리적 고립이 어떤 의미인지, 인접 지역이 지원 가능한지 여부. 이런 것들은 숫자 하나로 표현되지 않는 맥락입니다. 이 맥락을 담는 방법이 필요했고, 그게 온톨로지였습니다.

온톨로지(Ontology)는 원래 철학에서 온 단어입니다. "존재하는 것들의 체계와 구조"를 다루는 학문이죠. 컴퓨터 과학에서는 이 개념을 빌려와서, 특정 도메인에서 무엇이 존재하고 그것들이 어떤 관계를 맺는지를 형식적으로 정의하는 방법으로 씁니다.

일반 데이터베이스와의 차이를 구체적으로 보면 이렇습니다.

온톨로지의 진짜 힘은 추론 규칙(Inference Rule)에 있습니다. 관계들을 정의해두면, 명시적으로 입력하지 않아도 시스템이 스스로 새로운 사실을 도출합니다.

이것이 데이터베이스와 온톨로지의 핵심 차이입니다. 데이터베이스는 우리가 넣은 것만 알고 있습니다. 온톨로지는 관계와 규칙을 통해 우리가 직접 입력하지 않은 것도 추론합니다.

그런데 이 온톨로지 개념을 실제 기업 운영에 적용하는 방식으로 재해석한 회사가 있습니다. 팔란티어입니다. 다음 챕터에서 팔란티어가 온톨로지를 어떻게 다르게 봤는지, 그리고 PATOS가 그 방식에서 무엇을 배웠는지를 살펴봅니다.

앞 챕터에서 온톨로지가 관계와 규칙을 통해 추론한다는 개념을 살펴봤습니다. 그런데 이 개념을 학술적 도구에 머물지 않고, 기업이 실시간으로 운영되는 살아있는 레이어로 만든 회사가 있습니다. 팔란티어(Palantir)입니다.

팔란티어는 2003년 설립된 미국의 데이터 분석 플랫폼 기업입니다. 처음에는 CIA 등 정보기관 수요로 시작했지만, 지금은 Foundry라는 제품을 통해 제조·금융·헬스케어 등 민간 기업에도 플랫폼을 제공합니다. 팔란티어를 이해하는 핵심 키워드가 바로 Ontology as Operating Layer, 즉 운영 레이어로서의 온톨로지입니다. PATOS는 이 구조에서 영감을 받아 설계됐습니다.

팔란티어 Foundry의 온톨로지는 세 개의 레이어로 구성됩니다.

팔란티어 구조에서 가장 중요한 점은, AI가 온톨로지 없이는 작동하지 않는다는 겁니다. AI가 볼 수 있는 세계는 온톨로지가 정의한 범위 안에 있습니다. 이게 AI를 신뢰할 수 있게 만드는 구조적 장치입니다. AI가 틀려도, 온톨로지 규칙의 범위 안에서만 틀립니다.

PATOS는 팔란티어와 동일한 3레이어 구조를 따르되, 팔란티어의 독점 플랫폼 대신 TypeDB + Python + Claude Code 조합으로 구현했습니다. 도구는 달라도 아키텍처 철학은 같습니다.

define
  region sub entity,
    owns region-id, owns region-name,
    owns old-bldg-ratio, owns avg-response,
    owns island-yn, owns forest-yn,
    plays jurisdiction:area,
    plays adjacency:neighbor;

  fire-station sub entity,
    owns station-id, owns truck-count,
    plays jurisdiction:station;

  jurisdiction sub relation,
    relates station, relates area;
  adjacency sub relation,
    relates neighbor;

WEIGHTS = {
  "old_building" : 0.30,
  "response_time": 0.30,
  "fire_density" : 0.15,
  "island"       : 0.15,
  "forest"       : 0.10,
}

# 상위 5개 지역 컨텍스트 조립
for region in ranked[:5]:
  context = build_fire_context(region, data)
  # 기상·소방 자원·인접 지원 가능성 자동 포함

# judgment_prompt.txt 구성 요소
1. TypeDB 추론 규칙 5개 (참조 컨텍스트)
2. 에스컬레이션 기준
   (취약도 0.6↑ + 차량 2대↓ + 도서/산림)
3. 5개 지역 조립된 컨텍스트 (기상/자원/인접)

# Claude Code → 판단 출력
→ 위험등급 · 추론_체인 · 에스컬레이션_여부
→ judgment_result.json 저장

세 레이어가 조립되면 파이프라인이 됩니다. python poc_judgment.py를 실행하는 순간 데이터 로드 → 취약도 산출 → 컨텍스트 조립 → Claude Code 판단 요청의 전체 흐름이 한 번에 실행됩니다. 결과는 judgment_result.json에 저장되고, 이 대시보드의 AI 판단 엔진 메뉴에서 볼 수 있습니다.

많은 AI 서비스가 "AI가 분석합니다"라고 말합니다. 하지만 어떤 맥락에서, 어떤 규칙을 근거로, 왜 그런 결론을 냈는지는 블랙박스입니다. 소방 대응 같은 공공안전 분야에서 설명할 수 없는 판단은 신뢰받을 수 없습니다.

PATOS는 이 문제를 온톨로지 규칙의 명시적 포함으로 해결합니다. Claude Code가 받는 판단 프롬프트 안에는 TypeDB 추론 규칙 5개가 그대로 적혀 있습니다. AI는 그 규칙들을 참조해서 판단을 내리고, 어떤 규칙이 발동됐는지를 판단 결과 안에 반드시 기록합니다.

취약도만 봤다면 진도군(0.703)은 완도군(0.711)보다 낮은 순위입니다. 하지만 온톨로지 추론을 거치면 진도군이 구조적으로 더 복잡하고 위험한 상황임을 알 수 있습니다. 이중 관할 문제는 어떤 통계 지표로도 표현되지 않는 관계적 정보입니다. 온톨로지가 없었다면 AI는 이걸 알 방법이 없었습니다.

이것이 온톨로지 기반 AI 판단의 핵심입니다. AI가 잘 추론하는 게 목표가 아닙니다. AI가 맞는 것을 보고 추론하게 만드는 것이 목표입니다. 온톨로지는 AI한테 세계를 보여주는 방식입니다.

현재 PATOS POC를 구성하는 것들을 정직하게 나열하면 이렇습니다.

POC를 만들면서 가장 신경 쓴 것이 솔직함이었습니다. 파이프라인이 돌아갔다고 해서 그게 곧 검증이 되는 건 아닙니다. 이 시스템이 말할 수 없는 것들을 정확히 짚어두는 게 오히려 더 중요합니다.

팔란티어 수준의 범용 플랫폼을 만드는 건 현실적인 목표가 아닙니다. 팔란티어는 20년, 3,500명, 수조 원의 인프라 위에 서 있습니다. 하지만 팔란티어가 하는 방식으로, 특정 도메인의 특정 문제를 푸는 것은 가능합니다. 그리고 그게 오히려 더 의미 있는 목표일 수 있습니다.

PATOS의 다음 단계는 명확합니다. 우선순위 순으로 정리하면 이렇습니다.