내년에 맡을 사업 중에 온톨로지 기반 지능형 플랫폼 구축 사업이 있다. 그런데 사실 온톨로지는 용어만 들어 봤지, 개념이 뭔지, 늘 하던 관계형 DB(RDB) 설계와 뭐가 다른지 잘 몰랐다.
그래서 지난주 관련 세미나에 다녀왔다. 실무자 입장에서는 그중 직접 온톨로지를 만들어 보는 시간과 의미 기반 인프라를 다룬 시간이 이해에 도움이 됐다. 내용이 추상적이긴 했지만 감은 잡혔다. 들은 내용과 검색한 자료를 더해서, 나 같은 입장의 사람이 읽을 수 있게 정리해 둔다.
온톨로지를 한 줄로 말하면
"우리 데이터에 나오는 것들이 무엇이고, 서로 어떤 관계인지를 사람과 기계가 똑같이 이해하도록 정의한 지식 지도"다.
핵심은 새 데이터를 만드는 게 아니라는 점이다. 이미 있는 데이터에 공통의 의미와 관계를 붙이는 작업이다. 예를 들어 이런 것들을 정해 두는 거다.
- '직원', '사원', 'Employee'는 같은 개념이다.
- '팀장'은 '직원'의 한 종류다.
- 직원은 프로젝트에 '참여한다'. 그중 PM은 프로젝트를 '관리한다'.
RDB 설계와 뭐가 다른가
제일 궁금했던 부분이다. 회사 프로젝트와 인력 데이터로 비교해 보면 이해가 쉽다.
RDB로 설계하면 이런 테이블이 생긴다.
직원(직원ID, 이름, 부서코드) 프로젝트(프로젝트ID, 이름, 상태코드) 참여(직원ID, 프로젝트ID, 역할코드) ← 역할코드 R01 = PM, R02 = 개발 보유기술(직원ID, 기술코드)
여기서 "R01이 PM"이라는 의미는 코드표나 개발자 머릿속에 있다. 그리고 "Python을 다룰 줄 아는 사람이 PM인, 지금 진행 중인 프로젝트는?" 같은 질문이 오면 테이블 네 개를 JOIN하는 SQL을 새로 짜야 한다. 질문이 바뀌면 SQL도 다시 짠다.
온톨로지로 표현하면 관계에 이름이 붙은 문장이 된다. 주어-서술어-목적어 세 덩어리라서 이걸 트리플이라고 부른다.
김OO —관리한다→ 프로젝트A 김OO —보유한다→ Python 프로젝트A —상태→ 진행중 관리한다 ⊂ 참여한다 (관리하는 사람은 참여자이기도 하다)
마지막 줄이 재밌는 부분이다. "관리한다는 참여한다의 한 종류"라고 규칙을 정의해 두면, PM으로만 등록된 사람도 시스템이 참여자로 스스로 알아낸다. 이걸 추론이라고 한다.
| 구분 | RDB | 온톨로지 |
|---|---|---|
| 중심 | 테이블과 행 | 개념(클래스)과 관계 |
| 관계의 의미 | 외래키·코드값·JOIN 속에 숨어 있음 | '관리한다'처럼 이름 붙은 관계로 드러남 |
| 새로운 사실 | 저장한 것만 조회 | 규칙으로 새로운 사실을 추론 |
| 없는 데이터 | 없으면 '아니다' (닫힌 세계) | 없으면 '모른다' (열린 세계) |
| 구조 변경 | 스키마 변경 부담이 큼 | 개념·관계를 비교적 유연하게 추가 |
| 잘하는 일 | 정확한 거래·집계 처리 | 여러 데이터를 엮은 의미 탐색, 근거 설명 |
| 대표 기술 | SQL | RDF, OWL, SPARQL, 그래프 DB |
정리하면 온톨로지는 RDB를 갈아엎는 게 아니라, RDB 위에 얹는 '의미 층'에 가깝다. 거래와 원장은 여전히 RDB가 맡고, 여러 시스템에 흩어진 데이터를 의미로 연결하는 일을 온톨로지가 맡는 구조다.
용어 네 가지만 알면 된다
| 용어 | 뜻 | 예시 |
|---|---|---|
| 클래스 (Class) | 개념, 종류. RDB의 테이블과 비슷하다. | 직원, 프로젝트, 기술 |
| 속성 (Property) | 관계나 특성. RDB의 컬럼·외래키와 비슷하지만 의미가 붙는다. | 참여한다, 관리한다, 입사일 |
| 인스턴스 (Instance) | 실제 데이터 하나하나. RDB의 행과 비슷하다. | 김OO, 프로젝트A |
| 제약 (Restriction) | 지켜야 할 규칙 | "프로젝트의 PM은 1명", "참여한다의 대상은 프로젝트" |
함께 나오는 기술 용어도 한 줄씩만 정리하면 이렇다.
- RDF: 트리플(주어-서술어-목적어)로 데이터를 표현하는 W3C 표준
- OWL: 클래스, 관계, 제약, 추론 규칙까지 표현하는 온톨로지 언어 (W3C 표준)
- SPARQL: RDF 데이터를 조회하는 질의 언어. RDB의 SQL 역할
- 지식그래프: 온톨로지라는 설계도에 실제 데이터를 채워 넣은 결과물
온톨로지는 어디에 저장하나: RDF 방식과 LPG 방식
세미나에서도 RDF 방식과 LPG 방식이라는 말이 나왔다. 온톨로지와 지식그래프를 담는 DB가 크게 이 두 갈래다.
- RDF 방식: 모든 사실을 트리플(주어-서술어-목적어) 한 줄씩으로 쪼개 저장한다. W3C 표준이라 OWL 온톨로지와 추론을 그대로 쓸 수 있다.
- LPG 방식 (Labeled Property Graph, 라벨 속성 그래프): 점(노드)과 선(관계)에 라벨을 붙이고, 그 안에 속성을 바로 담는다. 사람이 보기에 직관적이고 그래프 탐색이 빠르다.
같은 사실 "김OO가 2025년 3월부터 프로젝트A의 PM이다"를 두 방식으로 쓰면 차이가 보인다.
[RDF 방식] 관계에 붙은 정보(시작일)를 넣으려면 관계 자체를 하나의 대상으로 다시 풀어야 한다
김OO —관리한다→ 프로젝트A
참여기록1 —담당자→ 김OO
참여기록1 —대상→ 프로젝트A
참여기록1 —시작일→ 2025-03
[LPG 방식] 관계 선에 속성을 바로 붙인다
(김OO:직원) —[관리한다 {시작일: 2025-03}]→ (프로젝트A:프로젝트)
| 구분 | RDF 방식 (트리플 스토어) | LPG 방식 (속성 그래프 DB) |
|---|---|---|
| 저장 단위 | 트리플 | 노드 + 관계 + 속성 |
| 표준 | W3C 표준 (RDF, OWL, SPARQL) | 제품 중심, 질의 언어는 Cypher·GQL |
| 강점 | 표준 기반 데이터 교환, 온톨로지 추론 | 직관적 모델링, 빠른 탐색, AI 연동 예제가 많음 |
| 대표 제품 | GraphDB, Virtuoso, Apache Jena, Stardog | Neo4j, Memgraph, TigerGraph |
둘 다 지원하는 Amazon Neptune 같은 제품도 있다. 많이 쓰이는 걸로 치면 DB 인기 순위 사이트 DB-Engines에서 그래프 DB 1위는 LPG 방식의 Neo4j다. RDF 쪽에서는 Virtuoso, GraphDB, Apache Jena 등이 상위권이다.
사업 관점에서 거칠게 나누면, 표준과 상호운용, 규칙 기반 추론이 중요하면 RDF 방식, 빠른 탐색과 LLM 연동이 중요하면 LPG 방식을 먼저 검토하게 된다. 실제로는 둘을 섞어 쓰거나, LPG DB에 온톨로지 기능을 덧붙이는 경우도 있다.
그런데 왜 지금 다시 온톨로지인가
온톨로지는 새 기술이 아니다. 그런데 요즘 다시 불려 나오는 이유는 생성형 AI 때문이다.
- LLM은 우리 회사 데이터를 모른다. 그래서 사내 문서를 찾아서 같이 넣어 주는 RAG(검색 증강 생성)를 많이 쓴다.
- 그런데 RAG는 비슷한 문서 조각을 찾는 방식이라, 위의 "Python 다루는 PM의 진행 중 프로젝트"처럼 관계를 여러 번 따라가야 하는 질문에 약하다.
- 여기에 온톨로지·지식그래프를 붙이면 AI가 관계를 따라가며 답하고, 왜 그런 답이 나왔는지 근거까지 보여 줄 수 있다. 마이크로소프트가 2024년에 공개한 GraphRAG도 이런 흐름이다.
- 요즘 말하는 에이전틱 AI(스스로 판단하고 일을 처리하는 AI)로 가려면 더 중요해진다. AI가 업무를 대신하려면 우리 조직의 대상과 관계와 규칙을 담은 공통 지도가 필요하기 때문이다.
온톨로지 구축 7단계
구축 순서는 스탠퍼드에서 공개한 입문 가이드 「Ontology Development 101」(Noy & McGuinness, 2001)의 7단계가 지금도 기본 틀로 많이 쓰인다. 위의 프로젝트·인력 예시로 옮겨 보면 이렇다.
| 단계 | 할 일 | 예시 |
|---|---|---|
| 1. 도메인과 범위 정하기 | 무엇을 위한 온톨로지인지, 어떤 질문에 답할지 먼저 적는다. | "이 기술을 가진 사람 중 투입 가능한 사람은?" |
| 2. 기존 온톨로지 재사용 검토 | 이미 있는 표준 어휘를 먼저 찾는다. | 사람·조직 표현은 공개 표준 어휘 활용 |
| 3. 핵심 용어 나열 | 중요한 개념과 관계를 일단 다 적는다. | 직원, 부서, 프로젝트, 기술, 참여, 관리 |
| 4. 클래스와 계층 정의 | 개념을 묶고 상·하위 관계를 만든다. | 팀장 ⊂ 직원 |
| 5. 속성(관계) 정의 | 클래스가 갖는 특성과 관계를 정한다. | 직원 —참여한다→ 프로젝트 |
| 6. 속성의 제약 정의 | 값의 종류, 개수, 대상 범위를 정한다. | PM은 프로젝트당 1명 |
| 7. 인스턴스 생성 | 실제 데이터를 연결한다. | 인사·프로젝트 DB의 실제 데이터 연결 |
이 가이드도 강조하는 점이 있다. 정답인 설계는 하나가 아니고, 한 번에 완성하는 것도 아니다. 답할 질문 몇 개 분량만 먼저 만들고, 실제 데이터를 넣어 보며 고쳐서 넓혀 가는 반복 작업이다.
사업을 준비하는 입장에서 짚어 볼 질문
정리하다 보니, 온톨로지 사업을 기획하거나 제안서를 읽을 때 이런 질문을 던져 보면 좋겠다는 생각이 들었다.
- 어떤 질문에 답하려는가? "지능형 플랫폼"이 아니라, 답해야 할 업무 질문 목록이 먼저 있어야 한다.
- 범위가 적당한가? 처음부터 전사 온톨로지는 무리다. 한 업무에서 시작해 넓히는 계획인지 본다.
- 재사용할 표준이 있는가? 같은 분야에 이미 쓰이는 어휘나 모델을 검토했는지 본다.
- 원천 데이터와 어떻게 연결되는가? 기존 DB가 바뀔 때 온톨로지 쪽 데이터가 어떻게 따라 바뀌는지 본다.
- 누가 운영하고 고치는가? 만든 뒤 개념과 관계를 계속 손볼 사람과 절차가 있는지 본다.
- AI와 어떻게 붙는가? LLM·RAG·에이전트가 온톨로지를 실제로 어떻게 쓰는지 화면 수준에서 설명되는지 본다.
온톨로지는 결국 "우리 데이터가 무슨 뜻인지 합의해서 기계도 알게 만드는 일"이다. 기술만큼이나 업무를 아는 사람의 몫이 크다.
이상 RDB만 알던 실무자의 온톨로지 기초 정리 끝!
참고: Noy & McGuinness, 「Ontology Development 101: A Guide to Creating Your First Ontology」(Stanford, 2001), W3C OWL 2 Overview, Microsoft GraphRAG, DB-Engines 랭킹. 세미나 「에이전틱 AI를 위한 기업 온톨로지 구축 실전 로드맵」(2026.10.7)을 듣고 개인적으로 정리한 글이며, 예시는 이해를 돕기 위해 새로 만든 것이다.
댓글
댓글 쓰기