온톨로지에도 종류가 있다고? 지금까지 한 건 절반짜리였다
온톨로지는 하나인 줄 알았다
지식그래프를 만들면서 온톨로지를 계속 다루고 있었습니다.
이메일에서 사람·조직·시스템을 뽑고, 문서에서 개념과 관계를 추출하고, 스키마를 설계하고 거버넌스를 구축했습니다.
그런데 모니터링 쪽을 보기 시작하면서 이상한 느낌이 들더라고요.
서버 상태 로그나 장애 이력 같은 건 이미 데이터가 있는데, 여기서 뭘 "추출"하지?
지금까지 해온 건 비정형 데이터에서 엔티티를 만들어내는 작업이었거든요.
그런데 모니터링 데이터는 이미 구조화된 데이터셋입니다. 테이블이 있고, 컬럼이 있고, 값이 들어 있어요.
같은 "온톨로지"라는 이름을 쓰는데, 접근 방식이 완전히 달라야 하는 거 아닌가 싶었습니다.
찾아보니까, 종류가 있더라
온톨로지를 분류하는 방식은 학술적으로 크게 4가지로 나뉘더라고요.
유형 | 역할 | 비유 |
|---|---|---|
상위(Upper) 온톨로지 | 도메인 상관없이 쓰는 범용 개념 정의 | 모든 사전의 "명사, 동사, 형용사" 같은 기초 품사 |
도메인(Domain) 온톨로지 | 특정 분야의 개념과 관계 정의 | 의학 사전, 법률 사전처럼 해당 분야 전문 용어집 |
태스크(Task) 온톨로지 | 특정 작업이나 프로세스 정의 | "진단하기", "배송 스케줄링" 같은 행동 매뉴얼 |
애플리케이션(Application) 온톨로지 | 특정 시스템에 특화된 도메인+태스크 조합 | 우리 회사 물류 시스템 전용 설계도 |
상위 온톨로지는 "객체", "관계", "이벤트" 같은 아주 추상적인 개념이라 일반적인 프로젝트에서 직접 만들 일은 거의 없습니다. 이미 만들어진 표준을 가져다 쓰는 수준이에요.
실무에서 실제로 마주치는 건 나머지 세 가지인데, 여기서 한 가지 의문이 생겼습니다.
"그러면 내가 지금까지 한 건 이 중에 뭐지?"
지금까지 한 건 도메인 온톨로지였다
이메일에서 "누가 누구에게 뭘 보냈는지" 뽑고, PPT에서 "어떤 시스템이 어떤 시스템과 연결되는지" 추출하고, 그 관계들의 타입을 정의하고 스키마로 관리한 것.
이건 전형적인 도메인 온톨로지 작업이었습니다.
도메인 온톨로지의 특징을 정리하면 이렇습니다.
입력이 비정형 데이터: 이메일, 문서, PPT, 회의록 같은 텍스트
핵심 작업은 "추출": LLM이나 파서로 엔티티와 관계를 뽑아낸다
결과물은 지식그래프: Neo4j 같은 그래프DB에 노드와 엣지로 저장
목적은 "이해": 조직 내 관계, 개념 구조, 숨겨진 연결을 파악
스키마 거버넌스를 만들고, 유사 타입을 병합하고, 도메인별로 태깅한 것도 전부 이 도메인 온톨로지를 더 정확하게 만들기 위한 작업이었던 거죠.
그런데 모니터링은 성격이 다르다
모니터링 데이터를 보면서 "이건 좀 다른데?" 싶었던 게, 데이터의 출발점 자체가 다르거든요.
도메인 온톨로지에서는 데이터가 없는 상태에서 시작합니다.
이메일 텍스트를 분석해서 "이 사람은 물류팀이고, 이 시스템은 결제팀 소속이다"를 처음 만들어내는 거예요.
그래프에 노드가 하나도 없는 상태에서 하나씩 채워가는 방식입니다.
그런데 모니터링은 데이터가 이미 있는 상태에서 시작합니다.
서버 로그 테이블에는 timestamp, server_id, cpu_usage, memory_usage가 이미 쌓여 있고, 장애 이력 테이블에는 incident_id, severity, affected_service, resolved_at이 들어 있어요.
여기서 필요한 건 엔티티를 "추출"하는 게 아니라, 이미 있는 데이터에 의미를 부여하는 것입니다.
server_id가 그냥 문자열이 아니라 "서버"라는 객체이고, 그 서버가 "서비스 A"를 호스팅하고 있고, 장애가 나면 "담당팀 B"에 알림이 가야 한다는 관계를 정의하는 거죠.
팔란티어가 하는 게 바로 "올리는" 쪽이었다
이 구분이 머릿속에 잡히고 나서 팔란티어 Foundry 문서를 다시 보니까, 그동안 읽어도 와닿지 않던 문장이 이해되더라고요.
팔란티어는 자기네 온톨로지를 "operational layer"라고 부릅니다.
기존 데이터셋(DB, 로그, API, CSV) 위에 온톨로지를 올려서, 데이터를 현실 세계의 객체로 매핑하는 거죠.
핵심은 이거였습니다 — 팔란티어는 데이터를 새로 만들지 않습니다.
이미 있는 데이터셋 위에 "이 row는 서버고, 이 서버는 이 서비스를 운영하고, 이 서비스에 장애가 나면 이 팀이 대응한다"는 의미 계층(semantic layer)을 올리는 거예요.
그리고 여기서 한 단계 더 나갑니다.
팔란티어 온톨로지에는 시맨틱(semantic) 요소만 있는 게 아니라 키네틱(kinetic) 요소도 있거든요.
시맨틱: 객체(objects), 속성(properties), 관계(links) → "이건 뭐고, 저건 뭐다"
키네틱: 액션(actions), 함수(functions) → "이 상황이면 이걸 실행해라"
도메인 온톨로지가 "세계를 설명하는" 데 그친다면, 팔란티어 방식은 "설명하고, 거기서 행동까지 연결하는" 구조인 겁니다. 그래서 팔란티어가 자기네 온톨로지를 "조직의 디지털 트윈"이라고 부르더라고요.
그래서 앞으로 뭘 다르게 해야 하나
정리하면, 온톨로지를 다루는 방식이 크게 두 갈래라는 걸 이제 알게 됐습니다.
도메인 온톨로지 (지금까지) | 데이터 위 온톨로지 (앞으로) | |
|---|---|---|
입력 | 비정형 (이메일, 문서) | 구조화 데이터셋 (로그, 메트릭, DB) |
핵심 작업 | 엔티티·관계 추출 | 의미 계층 정의, 객체 매핑 |
데이터 생성 | 새로 만든다 | 이미 있는 걸 연결한다 |
결과물 | 지식그래프 | 운영 레이어 (디지털 트윈) |
목적 | 이해·분석 | 모니터링·의사결정·자동화 |
지금까지는 첫 번째만 해왔거든요.
이메일을 분석하고, 문서를 파싱하고, LLM으로 엔티티를 뽑아서 Neo4j에 넣는 작업.
이건 이대로 가치가 있지만, 모니터링처럼 이미 데이터가 있는 영역에는 맞지 않는 접근이었습니다.
다음 글에서는 팔란티어가 온톨로지 위에 어떤 구조를 올리는지, 시맨틱과 키네틱 레이어를 좀 더 뜯어보겠습니다.
그 구조를 이해하면 모니터링 데이터에 온톨로지를 올리는 그림이 구체적으로 나올 수 있을 것 같습니다.
