드론 군집의 의미층은
어떻게 작동하는가

01개요와 핵심 명제#

드론 군집의 진짜 진화는 좌표 공유에서 의미 공유로 옮겨가는 것이다. 그 의미 공유를 실제로 작동시키는 기술 스택이 바로 — 온톨로지 + 룰 엔진 + 통합 데이터베이스 의 결합이다.

본문 에세이가 "왜 의미 공유가 필요한가"의 이야기를 다뤘다면, 이 노트는 그 의미 공유가 *기술적으로* 어떻게 작동하는가의 디테일을 다룬다. 한 번 읽고 잡힐 내용은 아니다. 섹션을 오가며 여러 번 읽기를 권한다.

이 문서가 답하는 질문

• 온톨로지가 정확히 무엇이고, 드론과 어떻게 연결되는가
• 기존 데이터 구조(JSON 스키마, RDB)로는 왜 안 되는가
• TypeDB 같은 새 도구는 무엇이 본질적으로 다른가
• 시나리오와 함수가 데이터베이스에 어떻게 들어가는가
• 트리거가 어떻게 판단을 내리고, 그게 진짜 "추론"인가
• 실제 시스템 한 사이클은 어떻게 세팅되고 어떻게 굴러가는가

이 문서가 다루지 않는 것

• RDF/OWL의 상세한 문법, SPARQL 쿼리
• 머신러닝 모델 학습법
• 드론 비행 제어 알고리즘 자체 (PID, MPC 등)

02언제 필요한가#

안 필요한 경우 (현재 대다수)

• 평창 1,218대 드론쇼 — 전부 인텔 쇼팅스타. 같은 회사가 만들고 같은 컴퓨터가 조종.
• 단일 기업 드론 라이트쇼 — DJI 5대를 한 사람이 조종.
• 농약 살포 드론 한 대 — 자기 논 한 바퀴 돌고 끝.

이 경우들은 자기 회사 안에서만 통하는 데이터 타입으로 충분하다. 옆 드론도 같은 회사 제품이라 같은 단어를 쓰니까.

필요해지는 3가지 상황

(1) 다른 회사 드론들이 같은 하늘에 뜰 때 — UAM

도심 항공교통이 본격화되면 DJI 배송, 삼성 순찰, 응급 의료 드론이 같은 골목 하늘을 난다. 서로를 충돌 회피 대상으로 인식해야 하는데, 회사마다 단어가 다르면 합의가 안 된다. 비행 차선의 의미 합의가 필요해진다.

(2) 다른 기관이 같은 임무에 드론을 보낼 때

소방청 + 군 + 지자체 + 민간 구조단의 드론이 산불 현장에 모인다. 데이터가 중간에서 끊어지지 않으려면 단어와 의미의 표준이 필요하다. 사람이 매번 데이터를 옮겨치는 건 한 번이면 모를까 매 재난마다 못 한다.

(3) 드론 데이터가 다른 분석 시스템으로 흘러갈 때

디지털 트윈, 스마트시티 플랫폼, 감시 시스템 같은 받는 쪽 시스템은 어떤 회사 드론인지 신경 안 쓴다. 그저 "사람 몇 명, 차량 몇 대"를 알고 싶다. 받는 쪽이 모든 드론 회사 어휘를 외울 수 없으므로 표준 사전이 필요하다.

03데이터 타입과 온톨로지의 연결#

데이터 흐름 5단계

↓ 같은 흐름의 자세한 데이터 모양

[1] 센서     카메라 픽셀, 열화상 36.5°C, GPS (37.123, 127.456)
                        ↓
[2] 분류기   드론 안의 작은 AI가 라벨 생성
              { label: "person", confidence: 0.87, bbox: [x,y,w,h] }
                        ↓
[3] 매핑     분류기의 "person" 라벨을 온톨로지의 :Person으로 바꿈
              인스턴스 생성:

                detection_2387:
                  type:        :Person
                  location:    (37.123, 127.456)
                  confidence:  0.87
                  detectedBy:  :Drone_07
                  detectedAt:  2026-05-07T14:23:01Z
                        ↓
[4] 추론     :Person ⊂ :LivingBeing ⊂ :ProtectedEntity
              규칙: Person AND inDisasterArea AND ¬conscious
                    → :SearchTarget
              → 같은 인스턴스가 SearchTarget으로도 자동 분류됨
                        ↓
[5] 송신     옆 드론에게 단 한 줄 (사전 ID로):
              "detection_2387 a :SearchTarget @(37.123, 127.456)"

핵심은 [3] 매핑

드론에는 Person이라는 자기만의 클래스가 있다 (그냥 프로그래밍 데이터 타입). 온톨로지에도 :Person이라는 개념이 있다 (산업 공유 사전). 이 둘을 연결하는 한 줄짜리 선언이 드론 소프트웨어 어딘가에 박혀 있다:

// 드론 소프트웨어 어딘가
register(drone.classes["person"], ontology[":Person"])

이게 다다. 드론이 자기 데이터 타입의 인스턴스를 만들 때마다, 그 인스턴스가 동시에 온톨로지의 인스턴스로도 등록된다.

가장 직관적인 비유 — 온톨로지는 회사 간 공유 타입 시스템

한 회사 안에서만 통하는 타입 시스템 = 그냥 데이터 타입.
여러 회사가 합의해서 공유하면 = 온톨로지.

04기존 데이터 구조의 한계#

기존 도구로 충분한 것

• 메시지 모양 통일 — 드론은 항상 {class, lat, lon} 형식으로 보낸다.
• 공유 어휘 — 회사들이 모여서 단어 목록 합의.
• 버전 관리 — 새 항목 추가되면 스키마 버전 올리고 모두 업데이트.

산불 현장 5대 드론도, 처음부터 같은 JSON 스키마로 합의했다면 온톨로지 없이 풀린다. 실제로 많은 현장이 이렇다.

기존 구조가 막히는 4가지 순간

(1) 단어가 다른데 사후에 합쳐야 할 때

JSON 스키마는 "필드 이름이 다르면 다른 거다." DJI는 "person", 삼성은 "human"이라 이미 코드에 박아놓고 5년 운영했다. 둘을 사후에 합치려면 한쪽이 코드 다 뜯거나, 매번 변환 서비스를 새로 짜야 한다.

온톨로지는 person sameAs human 한 줄을 사전에 추가하면 끝난다. 양쪽 코드는 그대로 둔다.

(2) 받는 쪽이 모든 규칙을 미리 알고 있어야 할 때

JSON 스키마로는 메시지 *모양*만 정의된다. "person 발견 → 충돌 회피 1등급 격상 → 본부 즉시 보고 → 옆 드론 모드 전환" 같은 *행동 규칙*은 받는 드론마다 자기 코드에 박아야 한다. 100대면 100번 박는다. 규칙이 바뀌면 100번 다시 배포한다.

온톨로지는 그 규칙을 사전 안에 한 번만 적는다. 모든 드론이 그 사전 한 권만 읽으면 끝.

(3) 새 개념이 계속 추가되는데 기존을 깨고 싶지 않을 때

JSON 스키마에 새 항목을 추가하면 — 받는 쪽이 그걸 모르면 보통 에러를 뱉거나 무시한다. 온톨로지는 새 개념을 *기존 개념의 하위 종류*로 추가한다. "휴머노이드 로봇은 사람의 한 하위 종류"라고 적으면, 휴머노이드를 모르는 옛날 드론도 그걸 그냥 "사람"으로 받아들여서 처리한다.

(4) 데이터 위에서 자동 추론을 돌리고 싶을 때

"지난 1시간 동안 발견된 모든 *생명체*를 보여줘" 같은 질문. JSON 스키마로는 "사람·개·사슴·휴머노이드는 다 생명체"라는 분류를 받는 쪽 코드에 짜 넣어야 한다. 온톨로지는 그 분류 자체가 사전에 들어 있어 추론기가 알아서 끌어온다.

05TypeDB의 통합 접근#

기존 방식 — 시스템 3개로 쪼개진 그림

[1] 데이터베이스 (PostgreSQL, MySQL ...)
       사실 저장: "Drone-7이 (37.1,127.4)에서 사람 봤다 14:23"
       그냥 줄과 칸. 의미는 모름.

[2] 온톨로지 파일 (OWL/RDF)
       의미 정의: "사람 ⊂ 생명체 ⊂ 보호대상"
       별도 파일.

[3] 추론기 (Pellet, HermiT)
       위 둘을 읽어 추론하는 별도 프로그램.

이 분리가 만드는 세 가지 비용

• 유지보수 지옥 — DB 스키마 바꾸면 온톨로지·추론 규칙도 따라 바꿔야. 셋이 어긋나면 시스템이 거짓말.
• 속도 문제 — 추론마다 DB→추론기→DB 왕복. 실시간 드론 판단에는 너무 느림.
• 두 종족 개발자 필요 — DB 팀과 온톨로지 팀이 따로. 의사소통 비용 큼.

새 방식 — 셋을 하나로

[하나의 시스템]
  스키마(테이블 정의) = 온톨로지
  데이터 저장 시 자동으로 의미·계층까지 같이 알려짐
  추론기가 DB 안에 박혀 있음 (왕복 없음)
  함수(비즈니스 로직)도 DB 안에 박을 수 있음

드론 한 장면으로 차이

06시나리오와 함수의 실체#

오해 — 시나리오를 일일이 박는다고?

"드론 5대 + 사람 1명 + 낮 + 여름 + 강풍" / "드론 4대 + 사람 2명 + 밤 + 겨울 + 비" ... 이런 식으로 박으면 경우의 수가 수천·수만으로 폭발. 새 변수 하나 추가되면 또 곱하기. 6개월 안에 유지보수 불가능.

실제 패턴 — 작은 룰들의 *조합*에서 시나리오가 *발현*

// 산불 대응 — 각 룰은 독립적, 짧음

R1: 발화 가능 열 이상 현상 감지됨 → Mode = FireResponseMode
R2: SearchTarget 발견 → 가장 가까운 드론에게 접근 지시
R3: 드론 배터리 < 20% → 임무 해제, 복귀
R4: 야간이면 → 모든 드론 열화상 모드 활성화
R5: 강풍이면 → 비행 고도 +20m, 안전 마진 +5m
R6: 가용 드론 수 < 3 → 정찰 범위 축소, 핵심 영역 우선
R7: 어떤 임무든 30분 진척 없음 → 인근 지원 자동 호출
... (수십 개)

새벽 3시 강풍에 드론 4대로 산불 대응 시작 → R1·R4·R5·R6이 *동시에* 트리거 → "야간·강풍·소수 드론용 산불 대응" 시나리오가 *자동 합성*된다. 도중에 사람 발견 → R2 추가 → 시나리오 *자동 확장*. 배터리 부족 → R3 → 시나리오 *자동 재구성*.

룰은 30개인데 만들 수 있는 시나리오는 수만 개다.

룰끼리는 어떻게 연결되는가

명시적 연결은 거의 없다. 룰들이 서로를 트리거하는 통로는 공유 어휘(온톨로지) + 공유 상태(DB의 사실)다. R1이 트리거되면 Mode = FireResponseMode가 DB에 적힌다. R6은 그 모드를 읽는다. R6은 R1을 직접 가리키지 않는다 — 같은 데이터 위에 살고 있을 뿐.

예외 — 명시적 시나리오 골격이 필요할 때

순서가 본질적인 절차는 골격으로 명시한다.

SCENARIO: 구조작전
  단계: [접근, 확인, 보고, 응급조치, 후송]
  단계 간 전이 조건: ...

// 각 단계 안은 다시 작은 룰들의 조합에 맡김

위는 골격, 아래는 발현 — 두 층으로 나뉜다. 대부분의 시나리오는 발현되고, 순서가 본질적인 소수만 명시된다.

실무 패턴 정리

1. 공유 어휘(온톨로지) — 단어들의 정의와 관계
2. 작은 룰들 — 수십~수백 개의 독립적 if-then
3. 명시적 시나리오 골격 — 순서가 본질적인 소수 절차
4. 추론 엔진 — 위 셋을 사실 위에서 자동 합성

사람이 미리 적어두는 건 [1][2]가 95%, [3]은 5% 미만. 적어두는 게 아니라 만들어낼 수 있게 해두는 것 — 이게 지식 기반 시스템의 본질이다. 사실 사람의 언어도 똑같이 작동한다(단어 + 문법 + 상황 → 새 문장 합성).

07트리거와 추론의 작동 원리#

포워드 체이닝 — 트리거가 판단을 내리는 메커니즘

1. 새 사실이 들어옴. 예: Drone-7이 (37.1, 127.4)에서 person을 봤다.
2. 룰 엔진이 패턴 매칭을 돈다. "지금 이 새 사실 때문에 조건이 충족되는 룰이 있나?"
3. 조건 충족된 룰 → 새 사실 도출. 예: Person AND inDisasterArea AND consciousness=impaired → SearchTarget이 충족 → "그 person은 사실 SearchTarget이다."
4. 그 새 사실이 또 다른 룰을 트리거. 예: SearchTarget 발견 → 인근 드론을 RescueMode로 전환.
5. 더 트리거될 룰이 없을 때까지 연쇄.

if-else와 결정적으로 다른 점 — 선언적 vs 명령적

두 가지 추론 — "이게 진짜 추론인가" 논쟁의 답

TypeDB의 룰 엔진이 하는 건 명백히 첫 번째 의미의 추론이다. 1960년대부터 "automated reasoning"이라는 학문이 정확히 이걸 다뤘다. 다만 신경망 추론과 비교하면 단순하다 — 학습 안 하고, 확률도 못 다루고, 결정론적이다. 하지만 그건 단점이 아니라 의도된 특성이다.

드론 시스템의 분업 — 두 추론이 같이 일한다

[지각층 - 통계적 추론]
  카메라 픽셀 → 신경망 → "사람 (확률 0.87)"
  * 학습 기반, 적응적, 모호함 잘 다룸
  * 단점: 왜 그렇게 봤는지 못 설명

       ↓ "사람이다" 라는 단언만 넘어옴

[판단층 - 기호적 추론]  ← TypeDB가 이 층
  "사람이다" + 위치 + 임무 정보
  → 룰 엔진이 자동으로 SearchTarget 도출
  → 다른 룰이 RescueMode 전환 도출
  → ...
  * 결정론적, 설명 가능, 감사 가능
  * 단점: 사람이 룰을 미리 박아둬야 함

지각은 신경망에게, 판단은 룰 엔진에게. 이 분업이 지금 드론·자율차·로봇 분야의 정통 아키텍처가 되어가고 있다.

08온톨로지의 5가지 진짜 기여#

예: 분류 계층 자동 상속(서브섬션)

상위에 한 번 적은 룰이 하위 모두에 자동 상속 — 이게 룰 엔진은 못 하고 온톨로지만 할 수 있는 것

업계의 부끄러운 진실: "온톨로지 기반"이라 마케팅하는 시스템의 상당수가 실제로는 위 다섯 중 어느 것도 안 쓰고 그냥 룰 엔진 + 클래스 다이어그램으로 굴러간다. 그러면 그건 잘 정리된 객체지향 코드이지 온톨로지가 아니다.

09실전 예제 — 산불 예방 시스템#

전체 아키텍처

[수치 층 - 통계적]            [기호 층 - 온톨로지/룰]

센서 데이터                          타입 정의 (Region, Risk, Scenario...)
   ↓                                + 룰들 (R-PREV-01 ~ R-PREV-N)
가중치 함수                          + 시나리오 골격 (Stage1~Stage4)
   ↓
위험 점수 (0~100)
   ↓
임계치 검사 ─────트리거────→  RiskAssessment(Critical) 사실 삽입
                                         ↓
                                   룰 R-PREV-01 발화
                                         ↓
                                   PreventionScenario 인스턴스 생성
                                         ↓
                                   단계별 룰들이 자동 연쇄

세팅 7단계

1단계 — 온톨로지에 타입 박기

Region          // 위험 평가 단위 영역
  속성: name, polygon, historicalFireFreq

WeatherSnapshot
  속성: temperature, humidity, windSpeed, rainfall24h, capturedAt

VegetationStatus
  속성: dryness(0-100), lastBurnYear, dominantSpecies

RiskAssessment
  속성: assessedRegion, computedScore, riskLevel, computedAt
  관계: basedOn → WeatherSnapshot, VegetationStatus

RiskLevel = enum { Safe, Caution, Alert, Critical }

PreventionScenario
  속성: triggeredBy → RiskAssessment, currentStage, startedAt
  관계: assignedAssets → DroneAsset[]

DroneAsset
  속성: type, status, batteryLevel, currentLocation
  타입계층: SurveillanceDrone ⊂ DroneAsset
            ThermalDrone ⊂ SurveillanceDrone
            DeliveryDrone ⊂ DroneAsset

하이라이트된 계층 정의가 온톨로지의 (1) 분류 계층 기여를 활용하는 지점이다. 룰을 SurveillanceDrone에 적용하면 자동으로 ThermalDrone에도 적용됨.

2단계 — 가중치 함수 박기 (수치 층)

function calculateRiskScore(region) -> double:
  w := latest WeatherSnapshot for region
  v := latest VegetationStatus for region

  base :=
    normalize(w.temperature, 0, 40)     * 0.20 +
    (100 - w.humidity)                   * 0.25 +
    normalize(w.windSpeed, 0, 30)        * 0.20 +
    v.dryness                            * 0.25 +
    region.historicalFireFreq            * 0.10

  // 최근 강수 보정
  if w.rainfall24h > 5: base := base * 0.5

  return clamp(base, 0, 100)

가중치는 소방청·기상청·산림청 도메인 전문가 합의값. 처음에는 합의로 시작, 점점 데이터로 재조정.

3단계 — 임계치 검사 (수치 → 기호 접합부)

function evaluateRegion(region):
  score := calculateRiskScore(region)

  level :=
    if score >= 80: Critical
    elif score >= 60: Alert
    elif score >= 40: Caution
    else:            Safe

  // ★ 핵심: 점수를 기호 사실로 변환해서 DB에 삽입
  insert RiskAssessment {
    assessedRegion: region,
    computedScore:  score,
    riskLevel:      level,
    computedAt:     now()
  }

이 단 한 줄(insert)이 두 층의 접합부다. 수치 층에서 만든 점수가 여기서 기호 사실로 변환되어 기호 층을 깨운다.

4단계 — 트리거 룰 박기

RULE R-PREV-01: Critical 위험에 시나리오가 없으면 시작
  WHEN
    $a isa RiskAssessment, $a.riskLevel = Critical
    NOT EXISTS $s isa PreventionScenario where
      $s.triggeredBy.assessedRegion = $a.assessedRegion
      AND $s.status = Active
  THEN
    insert PreventionScenario {
      triggeredBy:  $a,
      currentStage: "Stage1_Survey",
      startedAt:    now(),
      status:       Active
    }

새 RiskAssessment가 삽입되는 순간 엔진이 패턴 매칭으로 이 룰을 발화시킴. NOT EXISTS 절이 같은 영역에 시나리오 중복 생성을 막음.

5단계 — 시나리오 골격 박기

SCENARIO: ForestFirePrevention

  Stage1_Survey:
    필요 자원: SurveillanceDrone × 2
    행동:       위험 영역 격자 스캔
    완료 조건:  surveyResult ∈ {clean, hotspot_found}
    제한 시간:  30분

  Stage2_HotspotInvestigation:
    필요 자원: ThermalDrone × 1, SurveillanceDrone × 1
    행동:       의심 지점 정밀 열화상 확인
    완료 조건:  investigationResult ∈ {false_alarm, prefire, ignition}
    제한 시간:  15분

  Stage3_PreventiveAlert:
    행동:       본부 알림, 등산로 출입 통제 권고, 소방 헬기 대기 요청

  Stage4_HandoffToSuppression:
    행동:       FireResponseScenario로 시나리오 핸드오프

6단계 — 단계 전이 룰 (작은 룰들의 조합)

RULE R-PREV-02: Stage1 결과 깨끗 → 시나리오 정상 종료
  WHEN  $s.currentStage = "Stage1_Survey"
        $s.surveyResult = "clean"
  THEN  update $s.status = Closed_AllClear

RULE R-PREV-03: Stage1에서 hotspot 발견 → Stage2 전이
  WHEN  $s.currentStage = "Stage1_Survey"
        $s.surveyResult = "hotspot_found"
  THEN  update $s.currentStage = "Stage2_HotspotInvestigation"

RULE R-PREV-04: Stage2 prefire 판정 → Stage3
  WHEN  $s.currentStage = "Stage2_HotspotInvestigation"
        $s.investigationResult = "prefire"
  THEN  update $s.currentStage = "Stage3_PreventiveAlert"

RULE R-PREV-05: Stage2 실제 발화 → Stage4 핸드오프
  WHEN  $s.currentStage = "Stage2_HotspotInvestigation"
        $s.investigationResult = "ignition"
  THEN  update $s.currentStage = "Stage4_HandoffToSuppression"
        insert FireResponseScenario { handedOffFrom: $s, ... }

RULE R-PREV-06: 자원 부족 → 인근 영역에 지원 요청
  WHEN  $s isa PreventionScenario
        available_drones($s.stage.requiredAssets) < required_count
  THEN  invoke RequestSupport($s, neighbor_regions($s.region))

7단계 — 한 사이클 슬로우모션

15:00:00  센서 갱신 → WeatherSnapshot, VegetationStatus 사실 삽입
          (기온 33도, 습도 22%, 풍속 18m/s, 식생 건조도 88, 강우 0)

15:00:05  evaluateRegion(강원-A) 실행
          → calculateRiskScore = 84.6
          → RiskAssessment(Critical) 삽입

15:00:05  ★ 룰 엔진이 새 사실을 감지하고 R-PREV-01 발화
          → PreventionScenario(Stage1_Survey) 인스턴스 생성

15:00:06  Stage1 정의를 보고 자원 매칭 시도
          → 가용 SurveillanceDrone 2대 배정
          → 드론들에게 격자 스캔 임무 송신

15:23:42  드론 한 대가 의심 지점 보고
          → surveyResult = "hotspot_found" 사실 삽입
          → ★ R-PREV-03 발화 → currentStage = Stage2

15:23:43  Stage2 정의 보고 ThermalDrone 호출, 정밀 확인 시작

15:31:08  열화상 분석 결과 → investigationResult = "prefire"
          → ★ R-PREV-04 발화 → currentStage = Stage3
          → 본부 알림, 등산로 출입 통제 권고, 소방헬기 대기 요청

15:35:12  investigationResult 업데이트 = "ignition"
          → ★ R-PREV-05 발화 → Stage4 → FireResponseScenario 핸드오프
          → 산불 *예방* 시나리오에서 산불 *대응* 시나리오로 전환

전체 사이클에 사람이 한 번도 개입하지 않는다. 가중치도 룰도 시나리오 골격도 미리 박혔고, 시스템은 사실들을 받아 합성할 뿐이다.

10두 층 아키텍처 정리#

이 분업의 우아함

• 가중치를 ML 모델로 바꿀 때 — 수치 층만 갈아끼우면 끝. 기호 층은 한 줄도 안 건드림. "점수 → Critical 사실"이라는 인터페이스만 지키면 됨.
• 시나리오를 바꿀 때 — 룰만 건드리고 가중치는 안 건드림.
• 두 층이 분리되어 있어 각자 진화 가능. 신경망 분류기는 데이터 학습으로, 룰은 도메인 전문가 합의로 — 서로 다른 시계로 발전한다.

지각은 신경망에게, 판단은 룰 엔진에게. 둘이 한 줄(insert)로 연결될 때 시스템 전체가 살아난다.

11용어집#

— 끝 —

← 본문 에세이로 돌아가기