팔란티어 온톨로지의 시맨틱과 키네틱, 명사와 동사가 한 시스템에 있었습니다
온톨로지에 종류가 있다는 건 알겠는데
이전 글에서 온톨로지에 종류가 있다는 걸 정리했거든요. 지금까지 해온 건 비정형 데이터에서 엔티티를 뽑아내는 "도메인 온톨로지"였고, 이미 있는 데이터셋 위에 의미를 올리는 방식도 있다는 걸 알게 됐습니다. 팔란티어의 방식은 후자였고요.
그런데 "데이터 위에 의미를 올린다"는 말이 아직 추상적이었거든요. 구체적으로 뭘 올린다는 건지, 올리면 뭐가 달라지는 건지가 안 잡혔습니다. 그래서 팔란티어 Foundry의 온톨로지 문서를 뜯어봤어요.
시맨틱 레이어 — "이건 뭐고, 저건 뭐다"
팔란티어 온톨로지의 첫 번째 층은 시맨틱 레이어입니다. 세상을 설명하는 "명사"에 해당하는 거예요. 세 가지 요소로 구성돼 있습니다.
Object Type은 현실 세계의 엔티티를 정의합니다. 서버, 서비스, 주문, 직원 같은 것들이에요. Neo4j의 노드 라벨과 비슷한 개념인데, 차이가 있습니다. 팔란티어의 Object Type은 기존 데이터셋의 테이블에 매핑되거든요. "이 테이블의 한 row가 하나의 서버 객체다"라고 선언하는 거예요. 데이터를 새로 만드는 게 아니라, 이미 있는 데이터에 "이건 서버야"라는 의미를 붙이는 겁니다.
Property는 Object Type의 속성입니다. 서버라면 IP, OS, 담당팀 같은 것들이에요. 이것도 테이블의 컬럼에 매핑됩니다. 기존 컬럼 이름이 srv_ip였다면, Property에서는 "서버 IP 주소"라는 사람이 이해할 수 있는 이름을 붙여주는 거예요.
Link Type은 Object Type 간의 관계를 정의합니다. "서버가 서비스를 운영한다", "서비스에 담당팀이 있다" 같은 연결이요. Neo4j의 관계(Relationship)와 거의 같은 개념입니다.
여기까지만 보면 우리가 Neo4j에서 해온 것과 크게 다르지 않습니다. 노드 타입 정의하고, 속성 넣고, 관계 연결하는 거니까요. 차이는 데이터의 출발점이에요. 우리는 이메일에서 엔티티를 "추출"해서 Neo4j에 "생성"했고, 팔란티어는 기존 테이블 위에 의미를 "선언"합니다.
키네틱 레이어 — "이 상황이면 이걸 해라"
시맨틱 레이어가 명사라면, 키네틱 레이어는 동사입니다. 여기가 팔란티어 온톨로지의 진짜 차별점이에요.
Action Type은 객체를 어떻게 변경할 수 있는지를 정의합니다. "주문 상태를 '배송중'으로 변경한다", "서버 점검을 시작한다", "담당자를 재배정한다" 같은 동작이에요. 단순히 DB를 업데이트하는 게 아니라, 누가 어떤 조건에서 어떤 변경을 할 수 있는지를 규칙으로 정의하는 거거든요.
예를 들어 "서버 점검 시작" 액션은 이런 식입니다. 서버 객체의 상태를 "점검중"으로 바꾸고, 해당 서버에 연결된 서비스들의 상태도 자동으로 "영향받음"으로 변경하고, 담당팀에 알림을 보내는 것까지 하나의 액션으로 묶여 있어요. 사용자는 "서버 점검 시작" 버튼 하나만 누르면 이 모든 게 트랜잭션으로 처리됩니다.
Function은 비즈니스 로직을 코드로 작성하는 영역입니다. "이 서버에 연결된 서비스 중 SLA가 99.9% 이상인 것만 필터링해줘" 같은 복잡한 계산이 여기에 들어갑니다. 온톨로지의 객체와 관계를 직접 참조할 수 있어서, 쿼리가 아니라 비즈니스 맥락으로 로직을 작성할 수 있어요.
명사만 있는 온톨로지 vs 명사+동사가 있는 온톨로지
이 구분을 이해하고 나서 우리 시스템을 돌아봤거든요.
지금까지 Neo4j에 만든 건 시맨틱 레이어에 해당합니다. 서버, 서비스, 담당자 같은 객체를 정의하고, 관계를 연결하고, 온톨로지 거버넌스로 스키마를 관리하고 있으니까요. "세계를 설명하는" 부분은 꽤 잘 만들어둔 셈이에요.
그런데 키네틱 레이어는 거의 없었습니다. "이 서버에 장애가 나면 어떻게 해야 하는지"는 온톨로지에 정의되어 있지 않거든요. 그래프를 보면 서버와 서비스의 연결은 보이는데, "장애 시 이 순서로 대응한다"는 행동 규칙은 사람의 머릿속에만 있었습니다.
우리 시스템 (현재) | 팔란티어 | |
|---|---|---|
시맨틱 | ✅ Object Type, Property, Link 있음 (Neo4j) | ✅ 동일 |
키네틱 | ⚠️ Action Registry를 만들기 시작함 | ✅ Action Type, Function 체계화 |
데이터 소스 | 비정형에서 추출 (이메일, 문서) | 기존 데이터셋에 매핑 |
사실 이전 글에서 소개한 Action Registry가 키네틱 레이어의 시작이었더라고요. "영향도 분석", "복구 플랜 생성" 같은 액션을 정의하고 UI 버튼으로 실행하는 구조를 만들었거든요. 그때는 "UI에서 자연어 채팅 대신 구조화된 버튼을 제공한다"는 관점으로 접근했는데, 팔란티어 문서를 읽고 나니 그게 키네틱 레이어의 원시적인 형태였다는 걸 알게 됐습니다.
팔란티어가 "디지털 트윈"이라고 부르는 이유
팔란티어는 자기네 온톨로지를 "조직의 디지털 트윈"이라고 부릅니다. 처음에는 마케팅 용어 같았는데, 구조를 뜯어보니 이유가 있었어요.
디지털 트윈이 되려면 두 가지가 필요합니다. 현실 세계의 상태를 반영하는 것, 그리고 현실 세계에 변경을 가할 수 있는 것. 시맨틱 레이어가 전자고, 키네틱 레이어가 후자예요. 읽기만 가능한 모델은 "대시보드"지 "트윈"이 아니거든요. 트윈이 되려면 액션이 양방향으로 흘러야 합니다.
팔란티어는 여기에 한 층을 더 올립니다. 다이나믹 레이어라고 부르는 건데, 시뮬레이션과 AI 모델이 온톨로지 위에서 실행되는 구조입니다. "서버 A를 점검하면 서비스 B, C, D에 어떤 영향이 있는지"를 온톨로지의 관계를 따라가며 시뮬레이션하는 거예요. 우리가 37번 글에서 BFS로 영향도 분석을 만든 것과 비슷한 방향이지만, 팔란티어는 이걸 온톨로지 레벨에서 체계화한 거였습니다.
정리하면 팔란티어 온톨로지는 3개 층으로 구성돼 있어요.
층 | 역할 | 핵심 개념 | 비유 |
|---|---|---|---|
시맨틱 | 세계를 설명한다 | Object, Property, Link | 명사 |
키네틱 | 세계를 변경한다 | Action, Function | 동사 |
다이나믹 | 변경의 결과를 예측한다 | Simulation, AI Model | 가정법 |
우리 시스템에 적용한다면
팔란티어 구조를 그대로 따라할 수는 없지만, 방향은 잡을 수 있었습니다.
시맨틱 레이어는 이미 있으니까, 다음 단계는 키네틱 레이어를 체계화하는 거예요. Action Registry를 확장해서 각 액션이 온톨로지의 어떤 객체를 대상으로 하는지, 어떤 관계를 따라가는지를 명시적으로 정의하면 됩니다. 지금은 액션 목록이 코드에 하드코딩되어 있는데, 이걸 온톨로지 레벨에서 관리할 수 있으면 새 액션을 추가할 때마다 코드를 고칠 필요가 없어지거든요.
다이나믹 레이어는 아직 먼 이야기지만, 영향도 분석(BFS + PageRank)이 이미 원시적인 형태로 동작하고 있습니다. 이걸 온톨로지 메타데이터와 연결하면, "이 타입의 노드를 점검할 때는 이 관계를 따라가면서 영향을 체크한다"는 규칙을 온톨로지에 정의할 수 있게 됩니다.
다음 글에서는 이 구조를 모니터링 데이터에 실제로 올려보겠습니다. 서버 상태 로그와 장애 이력 같은 이미 있는 데이터셋에 시맨틱 레이어를 정의하고, 거기에 액션까지 연결하면 어떤 그림이 나오는지 정리하겠습니다.
