온톨로지란 무엇인가: RAG·위키와 다른 기업 지식의 설계도

온톨로지를 한 문장으로 줄이면 사람과 시스템이 같은 대상을 같은 뜻으로 다루게 만드는 명시적 의미 모델입니다. 문서를 많이 모은 저장소도, 검색을 잘하는 RAG도, 노드와 선을 그린 그래프도 그 자체로는 온톨로지가 아닙니다. 핵심은 “고객이 무엇인지”, “계약과 고객은 어떤 관계인지”, “어떤 조건이면 활성 고객으로 판단할 수 있는지”를 공동의 약속으로 만드는 데 있습니다.

기업이 궁극적으로 원하는 것도 온톨로지라는 산출물 자체는 아닙니다. 원하는 것은 서로 다른 부서와 시스템이 같은 사실을 놓고 다시 번역하지 않아도 되는 상태, AI가 근거를 찾고도 대상을 혼동하지 않는 상태, 사람이 승인한 규칙 안에서 분석이 실제 행동으로 이어지는 상태입니다. 온톨로지는 그 상태를 만드는 유력한 수단이지만 모든 회사의 필수 종착지는 아닙니다.

같은 회사가 세 시스템에서 세 존재가 되는 문제

가상의 제조 기업을 보겠습니다. 영업 시스템에는 ‘고객사’, 고객지원에는 ‘문의 조직’, 회계에는 ‘거래처’가 있습니다. 세 레코드는 모두 주식회사 새봄을 가리키지만 식별자는 다릅니다. 영업은 계약을 맺은 법인을 고객으로 보고, 지원팀은 문의를 보낸 조직을 고객으로 보며, 회계는 세금계산서를 받는 사업자를 거래처로 봅니다.

여기에 “새봄의 납기 지연 위험을 알려 줘”라는 질문이 들어오면 단순 검색만으로는 부족합니다. 어느 새봄인지, 자회사까지 포함하는지, 주문과 출하 중 무엇의 지연을 말하는지, 취소된 계약을 제외할지 결정해야 합니다. 문서는 각각 맞는 말을 하고 있어도 대상과 관계의 기준이 다르면 하나의 답으로 합치는 순간 충돌합니다.

온톨로지는 이때 ‘고객’이라는 단어 하나를 강제로 통일하는 사전이 아닙니다. 법인, 사업자, 계약 당사자, 문의 조직을 서로 다른 개념으로 남기고, 어떤 관계로 같은 현실의 조직을 가리키는지 정의합니다. 차이를 지우는 대신 차이를 설명할 수 있는 구조를 만드는 쪽에 가깝습니다.

온톨로지 안에는 무엇이 들어가는가

W3C의 OWL 2 개요는 온톨로지를 공동체가 공유하는, 흔히 특정 영역을 다루는 형식화된 용어 체계로 설명합니다. 실무에서는 다음 요소를 함께 봐야 합니다.

• 개념 또는 클래스: 고객, 계약, 제품, 주문, 설비처럼 무엇의 종류를 말하는지 정합니다.
• 개체: ‘새봄 주식회사’나 ‘주문 SO-1042’처럼 실제 대상을 식별합니다.
• 속성과 관계: 계약 시작일 같은 값뿐 아니라 고객이 계약의 당사자이고 주문이 제품을 요구한다는 연결을 표현합니다.
• 제약과 공리: 모든 계약에는 당사자가 있어야 한다거나, 자회사는 조직의 한 종류라는 식으로 허용되는 구조와 의미를 정합니다.
• 식별·출처·시간: 같은 이름의 대상을 구분하고, 어느 시스템의 어느 시점 사실인지 추적합니다. 이 부분이 없으면 그래프는 금세 모순된 최신값의 집합이 됩니다.

RDF 1.1은 정보를 주어·술어·목적어의 진술로 표현할 수 있는 그래프 데이터 모델입니다. 예를 들어 ‘주문 1042 — 고객 — 새봄’은 하나의 트리플입니다. 그러나 트리플을 많이 저장했다고 곧 온톨로지가 생기지는 않습니다. ‘고객’ 관계의 범위, 법인과 조직의 구분, 충돌 처리 규칙까지 명시해야 기계가 그 연결을 같은 뜻으로 해석할 수 있습니다.

이 차이 때문에 지식 그래프는 사실의 연결망, 온톨로지는 그 연결망이 어떤 의미와 규칙을 갖는지 설명하는 모델이라고 구분하면 이해가 쉽습니다. 실제 제품에서는 둘을 묶어 ‘온톨로지’나 ‘엔터프라이즈 지식 그래프’라고 부르기도 하므로 이름보다 어떤 규칙이 실제로 구현됐는지를 확인해야 합니다.

위키, RAG, 지식 그래프와 무엇이 다른가

위키·RAG·온톨로지는 경쟁 제품 세 종류가 아닙니다. 서로 다른 층의 문제를 해결하며 함께 쓸 수 있습니다.

위키는 설명에 강하고 온톨로지는 판정에 강합니다

MediaWiki의 설명처럼 위키는 여러 사람이 페이지를 빠르게 만들고 연결하는 협업 방식입니다. “반품 예외를 누가 승인하는가” 같은 서술과 사례는 위키가 자연스럽습니다. 반면 “이 요청이 반품 예외 대상인가”를 여러 시스템이 같은 조건으로 판정하려면 구조화된 개념과 관계가 필요합니다.

위키도 구조화될 수 있습니다. Wikidata 데이터 모델은 개체·속성·진술·한정자를 사용하고, 일부 상속 의미와 제약도 다룹니다. 따라서 ‘위키는 비정형, 온톨로지는 구조적’이라고 단순하게 가르면 틀립니다. 핵심 차이는 화면 형식이 아니라 어떤 의미 계약을 얼마나 명시적으로 운영하느냐입니다.

RAG는 온톨로지를 대체하지 않고 활용할 수 있습니다

RAG의 원 논문은 외부의 비매개 지식을 검색해 생성 모델의 입력에 결합하는 구조를 제안했습니다. 지금의 기업 RAG는 훨씬 다양한 검색기와 필터, 재순위화를 쓰지만 기본 질문은 같습니다. “이 질문에 어떤 근거를 가져올 것인가”입니다. 자세한 구현 흐름은 RAG 구축 가이드에서 이어서 볼 수 있습니다.

온톨로지가 붙으면 검색 전에 질문의 대상을 정규화하고, 관계를 따라 후보를 넓히며, 권한·유효 기간·법인 범위를 필터로 사용할 수 있습니다. 예를 들어 ‘새봄의 문제’를 검색할 때 새봄의 자회사, 유효 계약, 해당 계약의 주문까지 관계를 따라간 뒤 관련 문서를 찾을 수 있습니다. 그래도 최종 문서의 최신성, 검색 누락, 생성 오류를 별도로 평가해야 합니다. 온톨로지가 있다고 RAG의 청킹과 검색 평가가 사라지지는 않습니다.

온톨로지는 정말 도메인 특화인가

짧은 답은 기업에서 가치가 생기는 부분은 대체로 도메인 특화지만, 모든 온톨로지가 도메인 전용인 것은 아니다입니다.

Stanford의 Ontology Development 101은 시작 단계에서 영역과 범위를 먼저 정하고, 온톨로지가 답해야 할 질문을 적도록 권합니다. 의료의 환자·진단·처방, 제조의 설비·공정·불량, 보험의 계약·담보·사고는 관계와 예외가 다르므로 도메인 모델이 필요합니다. 같은 제조업이라도 회사마다 ‘가동 중’이나 ‘납기 위험’의 운영 정의가 다를 수 있습니다.

동시에 사람·장소·시간·사건처럼 여러 영역이 재사용하는 상위 또는 기반 온톨로지, 특정 업무를 설명하는 태스크 온톨로지, 한 애플리케이션의 요구에 맞춘 응용 온톨로지도 있습니다. W3C의 SKOS Primer는 분류 체계와 시소러스를 비교적 가볍게 기계가 읽을 수 있게 표현하는 방법을 제공합니다. 모든 문제에 OWL의 강한 논리 표현력이 필요한 것도 아닙니다.

실무에서는 재사용 가능한 상위 개념을 조금 빌리고, 성과를 내야 하는 업무의 도메인 개념을 구체화하는 조합이 현실적입니다. 범용 온톨로지만 가져오면 회사의 예외를 설명하지 못하고, 회사 내부 용어만 쌓으면 외부 표준이나 다른 조직과 연결하기 어려워집니다.

기업이 원하는 것은 온톨로지인가

기업이 원하는 결과를 먼저 나누면 답이 선명해집니다.

1. 찾기: 흩어진 문서에서 근거를 빨리 찾고 싶다면 검색과 RAG가 먼저입니다.
2. 알아보기: 같은 고객·제품·사건을 시스템 간에 연결하고 싶다면 식별 체계와 지식 그래프가 필요해집니다.
3. 같이 판단하기: 부서마다 다른 기준을 공통 규칙으로 쓰려면 온톨로지의 가치가 커집니다.
4. 안전하게 행동하기: AI나 애플리케이션이 주문 변경·승인 요청 같은 동작까지 하려면 권한, 업무 규칙, 감사 기록이 추가돼야 합니다.

Palantir의 Ontology 문서는 객체·속성·링크 같은 의미 요소뿐 아니라 액션·함수·동적 보안까지 운영 층에 묶습니다. 이는 한 벤더의 제품 정의이며 W3C 온톨로지의 보편적 정의와 같지는 않습니다. 다만 기업이 ‘뜻을 아는 그래프’에서 멈추지 않고 결정과 쓰기 작업까지 연결하려 한다는 흐름을 잘 보여 줍니다.

따라서 “기업의 최종 데이터 구조는 모두 온톨로지가 된다”는 주장은 과합니다. 상담 문서 몇백 개에서 답을 찾는 업무라면 정돈된 위키와 RAG가 더 싸고 빠를 수 있습니다. 반대로 같은 개체를 여러 시스템이 반복해서 번역하고, 규정 판정과 행동을 여러 팀이 공유하며, AI가 그 경계를 넘어 작업해야 한다면 온톨로지는 데이터 프로젝트가 아니라 운영 계약에 가까워집니다.

온톨로지가 필요한 신호와 과한 신호

다음 문제가 반복되면 검토할 가치가 있습니다.

• ‘고객’, ‘매출’, ‘활성’, ‘장애’의 뜻이 부서마다 달라 회의 때마다 다시 합의합니다.
• 한 질문에 답하려면 여러 시스템의 ID를 사람이 수작업으로 이어 붙입니다.
• 규정과 예외가 문서에만 있어 애플리케이션마다 다른 코드로 재작성됩니다.
• AI가 문서를 찾은 뒤에도 대상, 권한, 시점 범위를 자주 혼동합니다.
• 분석 결과를 실제 업무에 반영하려면 누가 무엇을 바꿀 수 있는지 공통 모델이 필요합니다.

반대로 데이터 원천이 하나이고 용어 충돌이 거의 없으며, 목표가 단순 문서 검색이라면 온톨로지부터 만들 이유가 약합니다. 모델을 유지할 도메인 담당자가 없거나, 성과 질문 없이 “전사 지식을 모두 연결하자”로 시작하는 경우도 중단 신호입니다. 연결 수가 늘수록 가치가 자동으로 커지는 것이 아니라 잘못된 관계의 수정 비용도 함께 커집니다.

전사 모델보다 답해야 할 질문 하나에서 시작합니다

온톨로지 설계에서 자주 쓰는 출발점은 competency question, 즉 이 모델이 답해야 하는 업무 질문입니다. “우리 회사의 모든 지식을 표현하자”가 아니라 “유효한 유지보수 계약이 있는 설비 중 이번 주 점검이 필요한 것은 무엇인가”처럼 판정 가능한 질문을 고릅니다.

1. 업무 질문결정하거나 찾아야 할 질문과 틀리면 생기는 비용을 한 문장으로 고정합니다.
2. 최소 개념질문에 필요한 개체·관계·시간·상태만 정의하고 동의어와 충돌 용어를 기록합니다.
3. 원천 매핑각 개념이 어느 시스템의 어떤 식별자와 필드에서 오는지, 누가 소유하는지 연결합니다.
4. 검증 사례정상·경계·예외·알 수 없음 사례로 질의와 추론 결과를 확인합니다.
5. 운영 지표수작업 매핑, 충돌, 근거 추적, 승인된 행동 성공률이 실제로 나아지는지 측정합니다.

좋은 첫 범위는 한 팀의 한 결정입니다. 고객 전체 모델보다 ‘계약 해지 문의 라우팅’, 제조 전사 모델보다 ‘점검 대상 설비 판정’이 낫습니다. 이름을 정하는 워크숍만 하지 말고 실제 질의와 실패 사례를 함께 돌려야 합니다.

실패하는 온톨로지는 기술보다 운영에서 무너집니다

첫째, 중앙 데이터팀이 정의를 만들고 현업이 서명만 하면 실제 예외가 빠집니다. 개념마다 결정 권한이 있는 소유자와 변경 절차가 필요합니다. 둘째, 현실 데이터가 바뀌는데 모델 버전과 매핑을 함께 관리하지 않으면 ‘정확한 정의 위의 오래된 사실’이 됩니다.

셋째, 열린 세계 가정과 닫힌 세계 업무 규칙을 혼동하면 사고가 납니다. OWL 계열 추론에서 사실이 없다는 것은 거짓이라는 뜻이 아닐 수 있습니다. 그러나 “승인 기록이 없으면 출고 금지” 같은 업무 규칙은 누락을 금지로 취급해야 합니다. 의미 추론과 운영 정책 엔진의 경계를 설계해야 합니다.

넷째, 생성형 AI가 문서에서 개체와 관계를 자동 추출했다고 곧 온톨로지가 완성되는 것은 아닙니다. 자동 추출은 초안 비용을 줄일 수 있지만, 같은 이름의 다른 대상을 합치거나 문맥의 추정을 사실로 굳힐 수 있습니다. 모델 버전, 검토자, 원문 근거, 되돌리기 경로가 없으면 빠르게 만든 만큼 빠르게 신뢰를 잃습니다.

결론: 온톨로지는 목적지가 아니라 공통 판단의 기반입니다

위키는 사람이 설명을 축적하는 데 강하고, RAG는 질문에 맞는 근거를 가져오는 데 강합니다. 지식 그래프는 사실의 연결을 탐색하게 하고, 온톨로지는 그 연결의 뜻과 허용 범위를 합의합니다. 기업은 필요에 따라 이 네 가지를 겹쳐 씁니다.

도입 여부와 기술 선택은 “온톨로지가 미래 기술인가”가 아니라 다음 세 질문으로 판단할 수 있습니다. 같은 대상을 여러 시스템이 다르게 부르는 비용이 큰가, 공통 규칙으로 반복 판정을 해야 하는가, 그 판정이 권한 있는 행동까지 이어지는가. 세 질문에 연속으로 ‘예’라면 작은 도메인 온톨로지를 만들 이유가 충분합니다. 아니라면 문서 정리와 검색 품질부터 해결하는 편이 낫습니다.

공식 출처

• OWL 2 Web Ontology Language Document Overview, W3C
• RDF 1.1 Concepts and Abstract Syntax, W3C
• SKOS Simple Knowledge Organization System Primer, W3C
• Ontology Development 101, Stanford University
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020
• Wikidata: Data model, Wikidata
• Ontology overview, Palantir