온톨로지란? RAG·위키와 다른 기업 지식의 구조

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

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

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

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

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

크게 보기

×확대 이미지 닫기

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

세 ID를 한 판정으로 연결하는 작은 예시

다음 ID와 결과는 의미 연결 과정을 설명하기 위한 가상 데이터입니다.

여기서 관계가 기록되지 않았다는 사실은 열린 세계 의미 모델에서는 곧 ‘관계가 없다’는 뜻이 아닐 수 있습니다. 반면 주문 승인 같은 닫힌 업무 규칙은 유효 계약 근거가 없으면 통과시키지 않아야 합니다. 온톨로지는 이름과 관계의 뜻을 합의하는 층이고, ACL·승인·출고 금지는 검색 시스템과 정책 엔진이 별도로 강제합니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

기업이 온톨로지를 찾는 이유

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

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

같은 개체를 여러 시스템이 반복해서 번역하고, 규정 판정과 행동을 여러 팀이 공유하며, AI가 그 경계를 넘어 작업해야 한다면 온톨로지는 데이터 정리보다 운영 계약에 가까워집니다. 상담 문서 몇백 개에서 답을 찾는 업무처럼 목표가 단순하다면 정돈된 위키와 RAG가 더 빠를 수 있지만, 판단과 실행을 여러 시스템에 일관되게 적용하려면 공통 의미 모델의 중요성이 커집니다.

대표 기업 Palantir가 추구하는 온톨로지

온톨로지를 기업 운영에 적용한 대표적인 회사로는 Palantir가 있습니다. Palantir는 온톨로지를 자사 아키텍처의 중심이자 조직의 운영 층으로 설명합니다. 데이터셋과 모델을 공장·설비·제품·고객 주문 같은 현실의 대상에 연결하고, 조직이 현재 어떤 상태이며 무엇을 할 수 있는지를 디지털로 표현하는 방식입니다.

Palantir의 Ontology 개요에서 객체·속성·링크는 조직의 대상을 나타내는 의미 요소입니다. 여기에 액션과 함수가 붙어 주문을 바꾸거나 공급 계획을 조정하는 행동을 표현하고, 동적 보안과 거버넌스가 누가 어떤 결정을 실행할 수 있는지 통제합니다. Palantir 아키텍처 문서는 이를 데이터·논리·행동·보안의 결합으로 정리합니다. 팔란티어가 추구하는 온톨로지는 ‘뜻을 아는 그래프’에서 멈추지 않고 사람과 AI가 같은 운영 세계를 보며 결정하고, 허용된 행동을 실제 시스템에 반영하게 하는 기반입니다.

크게 보기

×확대 이미지 닫기

다만 Palantir의 Ontology는 W3C가 정의하는 일반적인 온톨로지보다 범위가 넓은 제품 개념입니다. 의미 모델뿐 아니라 실행과 보안까지 포함하기 때문입니다. 온톨로지를 검토할 때는 이름만 볼 것이 아니라 객체와 관계, 업무 규칙, 권한, 쓰기 작업이 어디까지 구현되는지 확인해야 합니다.

FDE는 고객 업무를 운영 시스템으로 옮기는 엔지니어입니다

FDE는 Forward Deployed Engineer의 약자입니다. Palantir에서는 Forward Deployed Software Engineer(FDSE)라고도 씁니다. 고객 조직 가까이에서 데이터와 업무 흐름, 제약을 파악하고 기술 범위를 정한 뒤 설계·구현·배포와 운영 피드백까지 이어 가는 엔지니어입니다.

Palantir의 FDSE 공고는 고객과 함께 중요한 데이터·AI 문제를 이해하고 솔루션을 설계·구축하는 역할을 설명합니다. 현장에서 발견한 ‘고객’, ‘계약’, ‘설비’의 의미와 시스템별 식별자, 상태 전이, 예외, 권한을 재사용 가능한 구조로 남기는 과정에서 FDE와 온톨로지가 만납니다.

이 역할은 다른 AI 기업으로도 확산되고 있습니다. OpenAI의 FDE 공고는 고객의 엔지니어링·도메인 팀과 함께 문제 발견, 기술 범위 설정, 시스템 설계, 구축, 운영 배포를 맡고 현장 피드백을 제품과 모델 로드맵에 돌려보낸다고 설명합니다. OpenAI는 2026년 Deployment Company 출범을 알리며 FDE를 조직에 직접 투입해 핵심 업무와 인프라를 AI 중심으로 재설계하겠다고 밝혔습니다. Anthropic도 공식 채용 페이지에서 고객 업무 흐름 안에 Claude 기반 운영 애플리케이션을 만드는 FDE를 모집하고 있습니다.

FDE의 확대는 기업 AI의 병목이 모델 선택만이 아니라 고객의 언어와 데이터를 실제 운영 구조로 번역하는 일에 있다는 점을 보여 줍니다. Palantir는 이 문제를 Ontology라는 중심 층으로 풀고 있고, OpenAI와 Anthropic은 FDE를 통해 고객 현장에서 같은 문제를 다루고 있습니다. 사용하는 제품명과 구현 방식은 달라도, 조직의 개체·관계·규칙·권한을 AI가 활용할 수 있는 형태로 만드는 일이 기업 AI 도입의 핵심이 되고 있다는 방향은 같습니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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