주제 탐구 · 2026-11-04 · 심화 · 작성자 bombong

온톨로지의 허와 실: 해자인가 유행인가, 도입 전에 따질 것

온톨로지는 대형 데이터 플랫폼의 기본 기능이 되어 가고 있어서, 개념 자체는 더 이상 차별점이 되지 못한다. 이 결론편은 과장과 실제 가치를 나누고, 시맨틱 레이어·지식 그래프·플랫폼 온톨로지를 비교한 뒤, 작게 시작하기 위한 점검 기준을 정리한다.

시리즈를 마치며: 1~3편이 남긴 질문
경쟁 구도: 온톨로지가 기본 기능이 될 때
비교: 시맨틱 레이어·지식 그래프·플랫폼 온톨로지
'허': 과장된 기대 네 가지
'실': 남는 가치 세 가지
실패 패턴과 대응
도입 판단 점검 목록과 90일 시작 순서
더 공부하려면

핵심 정리

Microsoft Fabric IQ는 온톨로지(미리 보기)를 기본 항목으로 넣었고, dbt 시맨틱 레이어는 MCP 서버로 AI 도구에 지표를 연결한다. 그래서 온톨로지라는 개념보다 정의를 누가 맡아 최신으로 유지하느냐가 차별점으로 남는다.
'허'는 온톨로지만 만들면 에이전트가 알아서 옳게 행동한다는 기대, 전사 단일 모델, 그리고 유지 비용('온톨로지 세금')을 계산에서 빼는 습관이다.
'실'은 업무 용어를 한 번만 정의하는 것, 에이전트에게 규칙과 맥락을 주는 것, 규제가 요구하는 데이터 리니지를 계속 최신으로 유지하는 것이다. 다만 규칙을 실제로 지키게 하는 일은 결정론적 실행 계층의 몫이다.
실패는 보통 구축 단계가 아니라 그 뒤에 온다. 소유자가 없는 그래프, 전사로 범위를 넓히는 욕심, 한 번 만들고 방치한 정적 산출물이 대표적인 패턴이다.
유스케이스 하나와 답해야 할 질문 목록으로 시작한다. 정의가 안정적이고 소유자가 분명한 엔터티만 공개하고, 처음부터 갱신 주기를 정해 둔다.

시리즈를 마치며: 1~3편이 남긴 질문

이 글은 '온톨로지의 허와 실' 시리즈의 4편이자 마지막 편이다. 앞선 세 편에서 온톨로지가 무엇인지, 기업이 왜 찾는지, 금융권처럼 규제가 무거운 곳에서 어떤 쓸모와 비용이 생기는지를 살폈다. 3편의 결론은 이렇게 요약된다. 시스템마다 다르게 정의된 고객·상품을 공통 개념으로 묶으면 분명한 효과가 있다. 하지만 그 효과는 매핑·용어 관리·책임 체계라는 비용을 치른 만큼만 나온다. 그래서 한 업무, 한 보고서에서 작게 시작하는 편이 낫다.

이번 편은 그 결론을 일반화한다. 질문은 세 가지다. 첫째, 팔란티어의 상징처럼 여겨지던 온톨로지가 범용 데이터 플랫폼의 기본 기능이 되면 무엇이 차별점으로 남나. 둘째, 온톨로지를 둘러싼 기대 가운데 무엇이 과장('허')이고 무엇이 실제 가치('실')인가. 셋째, 우리 조직은 도입해야 하나, 한다면 어디서부터 시작하나.

특정 제품을 추천하려는 글이 아니다. 아래 비교와 점검 목록은 어느 플랫폼을 고르든 똑같이 따져야 할 기준이다.

경쟁 구도: 온톨로지가 기본 기능이 될 때

Microsoft는 Fabric IQ를 '기업 인텔리전스 계층'의 일부로 소개한다. Fabric IQ는 두 핵심 항목으로 구성된다. 하나는 온톨로지(ontology, 문서 표기상 preview 단계)이고 다른 하나는 Power BI 시맨틱 모델이다글. 문서에 따르면 온톨로지는 엔터티 유형·속성·관계·규칙·지표를 정의하고 실제 기업 데이터에 바인딩한다. 그러면 사람, 애플리케이션, AI 에이전트가 같은 어휘를 쓰게 된다글 글. 온톨로지는 별도의 데이터 저장소가 아니다. 정의와 바인딩만 보관하는 '가상의 맥락 계층'이고, 실제 쿼리는 원천 데이터 시스템에서 실행된다글. 또한 기존 시맨틱 모델에서 온톨로지를 만들 수 있고, RDF·OWL 같은 개방 표준을 가져올 수도 있다글. 구 버전 온톨로지 경험은 2027년 1월 31일에 종료된다고 공지돼 있다글. 기능이 아직 빠르게 바뀌는 중이라는 뜻이다.

시맨틱 레이어 쪽에서도 같은 흐름이 보인다. dbt 문서는 지표 정의를 BI 도구에서 모델링 계층으로 옮겨 부서마다 같은 정의를 쓰게 한다고 설명한다. 또 Claude·ChatGPT 같은 AI 도구가 dbt MCP 서버로 시맨틱 레이어에 연결되면, 원본 테이블을 짐작하는 대신 관리되는 지표를 쓰게 된다고 밝혔다글. '에이전트에게 업무 의미를 준다'는 약속을 이제 여러 계층의 제품이 함께 내세우는 셈이다.

이렇게 되면 온톨로지라는 개념만으로는 해자가 생기지 않는다. 데이터베이스 엔지니어 Vonng의 블로그 글글은 더 강하게 주장한다. 팔란티어의 Ontology는 기술적으로 데이터베이스 모델링이고(객체 유형=테이블, 링크=외래 키), 실제 해자는 정치적 관계망·보안 인가·현장 파견 엔지니어(FDE) 같은 다른 데서 나온다는 것이다. 이는 한 비평가의 주장으로 읽어야 한다. 그래도 실무에 주는 시사점은 분명하다. 개념이 범용이 되면 남는 차별점은 정의를 실제로 합의하고 유지하는 조직의 능력, 원천 시스템과의 연결 품질, 그리고 그 일을 해 주는 사람이다.

플랫폼 온톨로지의 자리 Fabric 문서 기준으로 그린 구조다. 온톨로지는 데이터를 복사하지 않고 정의·바인딩만 보관한다. 실제 쿼리는 원천 시스템에서 실행된다.

비교: 시맨틱 레이어·지식 그래프·플랫폼 온톨로지

Thoughtworks 글글은 스키마, 통제 어휘, 시맨틱 레이어, 온톨로지, 지식 그래프를 하나의 연속선으로 본다. 위 단계로 갈수록 표현력은 커진다. 대신 비용과 거버넌스 부담이 늘고, 누군가 적극적으로 맡아야 한다. 이 글은 온톨로지를 '설계도(클래스·관계·규칙)'로, 지식 그래프를 '그 설계도에 실제 데이터를 채운 것, 에이전트가 실제로 질의하는 대상'으로 구분한다.

목적부터 보면 차이가 뚜렷하다. 시맨틱 레이어는 지표와 정의를 표준화하는 데 강하다. 반면 에이전트가 따라갈 관계나 논리를 담는 데는 한계가 있다글. 구축 비용이 비교적 낮고, 유지는 보통 데이터 팀이 모델링 코드로 맡는다. 에이전트 연결도 dbt처럼 MCP 서버를 통하는 방식이 이미 있다글. 지식 그래프는 다단계 관계 추론에 강하다. 하지만 Entity Resolution(같은 대상 찾아 합치기)과 관계 추출을 실데이터에 대해 계속 해야 하므로 유지 부담이 가장 크다글 글. 플랫폼 온톨로지(팔란티어형, Fabric IQ)는 정의·규칙·지표·바인딩·그래프를 한 플랫폼 안에 묶는다. 시작은 쉽지만 그 플랫폼의 데이터 기반을 전제로 한다. Microsoft 문서글도 통합 데이터 기반 없이는 IQ 계층에서 시작할 수 없다고 적고 있다.

고착 위험은 따로 따져야 한다. Vonng의 글글은 2017년 뉴욕시경이 팔란티어와 관계를 끝낼 때, 분석 결과를 이식 가능한 형식으로 받지 못했다고 공개적으로 문제 삼은 사례를 든다. 반면 Fabric 문서는 RDF·OWL 같은 개방 표준을 가져올 수 있다고 밝힌다글. 따라서 정의를 표준 형식으로 내보낼 수 있는지, 규칙과 지표가 특정 엔진 안에만 갇히는지를 계약 전에 확인해야 한다. Thoughtworks글는 그래프 DB, 데이터 카탈로그, 마스터 데이터 도구, 시맨틱 레이어 플랫폼이 이미 이 영역의 일부를 다루고 있으니, '직접 모델링이 이미 가진 도구의 설정보다 나은 곳이 어디인가'를 의도적으로 판단하라고 권한다.

'허': 과장된 기대 네 가지

첫째, '온톨로지만 만들면 AI가 알아서 일한다'는 기대다. Thoughtworks글는 온톨로지가 에이전트에게 행동 전에 무엇이 허용되는지 알려 주긴 하지만 그것은 지식일 뿐 강제가 아니라고 선을 긋는다. 규칙은 결정론적 런타임이 검사하고 그 결과를 따르며, 검사했다는 사실을 보일 수 있을 때만 구속력이 생긴다. 많은 운영 규칙은 정책 엔진에 두는 편이 맞다는 것이다. 검색 품질도 마찬가지다. 가치는 스키마가 아니라 실데이터로 채운 그래프에서 나온다. 설계도는 비교적 쉬운 부분이다.

둘째, 전사 단일 모델이다. Thoughtworks글는 전사 마스터 모델을 '바다를 끓이려는 함정에 깔끔한 이름을 붙인 것'이라고 부른다. 현실 전체를 모델링하려는 프로젝트는 대개 1년쯤 지나 가치를 보이지 못하고 끝난다고 지적한다. Atlan 글글도 '비즈니스 전체'를 추상적으로 표현하려는 그래프에는 멈출 지점도, 분명한 소유자도 없다고 쓴다.

셋째, 유지 비용을 빼고 계산하는 습관이다. Atlan글은 계속 스키마를 관리하는 비용을 '온톨로지 세금(ontology tax)'이라고 부른다. 또 Improvado의 2026년 종합 자료를 인용해 기업 지식 그래프 프로젝트 가운데 파일럿 단계를 넘는 비율이 15%에 못 미친다고 전한다. 넷째, 이름만 바꾼 데이터 모델링 마케팅이다. Vonng글이 지적하듯 데이터 모델링과 시스템 통합은 진짜 가치 있는 일이다. 문제는 그 가치를 '온톨로지'라는 단어에 돌리는 것이다. 공급사가 '온톨로지'라고 부르는 기능이 기존 스키마·시맨틱 모델과 무엇이 다른지 구체적으로 묻는 것이 첫 번째 방어선이다.

'실': 남는 가치 세 가지

첫째는 업무 용어의 단일 정의다. Microsoft 교육 자료글의 예가 이해하기 쉽다. 영업팀의 '고객'에는 리셀러가 포함되고 서비스팀의 '고객'은 직접 구매자만 뜻한다. 이러면 두 모델을 함께 질의하는 데이터 에이전트는 어느 정의를 써야 할지 알 수 없다. 온톨로지는 모든 시맨틱 모델이 따를 합의된 정의를 하나 선언해 이 문제를 푼다. 날짜 필터나 계산 열처럼 보고서 안에서만 의미 있는 것은 시맨틱 모델에 그대로 둔다. Thoughtworks글는 이 가치가 매핑 자체보다 그 뒤의 합의와, 의미가 바뀔 때 계속 갱신하는 소유권에서 나온다고 강조한다.

둘째는 에이전트가 행동할 때 필요한 규칙·지표·권한·감사의 맥락이다. Fabric 문서글에 따르면 규칙을 자연어로 담아 엔터티에 연결할 수 있다. 그러면 같은 업무 지시를 프롬프트·에이전트·앱마다 복사하지 않아도 된다. 지표는 원천 시맨틱 모델이 계속 소유한 채 가져와서, 에이전트가 계산식을 새로 만들지 않고 조직이 정의한 계산을 쓰게 한다. 권한과 수명 주기는 Fabric 권한 체계로 관리한다. 온톨로지 에이전트의 변경은 '제안 먼저(proposal-first)' 방식이어서 사람이 검토한 뒤 반영된다글 글. 다만 앞 절에서 본 것처럼, 실제 실행을 막고 기록하는 장치는 따로 둬야 한다글.

셋째는 규제 대응용 데이터 리니지(데이터 계보)다. DataHub 글글은 바젤위원회의 2023년 11월 점검 보고서를 인용한다. 평가 대상 G-SIB(글로벌 시스템적 중요 은행) 31곳 가운데 BCBS 239의 14개 원칙을 모두 충족한 곳은 2곳뿐이었다. 보고서는 여러 은행에 공통 분류 체계와 완전한 데이터 리니지가 아직 없다고 지적했다. 이 글은 또 유럽중앙은행이 2024년 5월 리스크 데이터 집계·보고(RDARR) 지침을 확정했다고 전한다. 이 글이 짚는 핵심은 감사 대응용으로 한 번 그린 리니지 도면이 다음 점검 전에 낡는다는 점이다. 리니지가 실제 운영 메타데이터에서 계속 갱신돼야 감사 증거로 쓸 수 있다. 이 글은 같은 리니지 기반이 AI 에이전트 거버넌스에도 쓰인다고 주장하는데, 이는 리니지 도구 공급사의 관점이라는 점을 감안해서 읽는다.

실패 패턴과 대응

Atlan글은 기업 지식 그래프가 구축 단계에서 실패하는 경우는 드물고, 그 뒤 세 갈래가 겹치며 무너진다고 정리한다. 조직 측면에서는 소유자·범위·후원이 없고, 기술 측면에서는 온톨로지 드리프트·스키마 경직·Entity Resolution 실패가 생기며, 경제 측면에서는 온톨로지 세금이 문제가 된다. 공통 원인은 그래프를 거버넌스가 적용된 메타데이터 위에서 계속 갱신되는 계층으로 두지 않고 사람이 손으로 채우는 정적 산출물로 방치한 것이다. 이 글이 인용한 2025년 설문에서는 중단된 프로젝트의 67%가 내부 그래프 전문성 부족을 주된 원인으로 꼽았다. 이 글은 이를 '기술이 없었다기보다 그래프를 계속 채울 사람을 배정하지 않았다'는 뜻으로 해석한다.

소유자 없는 그래프에 대한 처방은 소유권을 제품처럼 다루는 것이다. Thoughtworks글는 온톨로지를 '프로젝트가 아닌 제품'으로 다루라고 권한다. 논쟁이 되는 용어에 대한 결정권, 버전 관리, 기록 시스템과 맞춰 보는 정해진 주기, 쓸모없어진 개념을 없애는 절차가 필요하다는 것이다. 관리자와 정기적인 맞춤 작업이 없으면 모델은 두 분기 안에 낡는다고 경고한다.

범위 확장에는 유스케이스 하나로 범위를 묶어 대응한다. Thoughtworks글는 전사 모델을 한 번에 만드는 기존 방식이 가치를 내기까지 12~24개월이 걸린다고 본다. 반면 고수익 유스케이스 하나에서 시작하는 제품 방식은 반복 한 번에 4~8주가 걸린다고 비교한다. Atlan글은 원천 시스템이 10~15개를 넘으면 엔터티 중복과 스키마 불일치로 통합이 취약해지는 손익분기점이 온다는 실무자 보고를 전한다. 정적 산출물로 방치되는 문제에는 드리프트를 잡는 갱신 주기와 담당자를 정해 대응한다. 테이블 이름이 바뀌거나 CRM에서 고객이 병합돼도 오류는 나지 않는다. 그래서 정해진 검증이 없으면 그래프는 조용히 틀린 사실을 내놓는다글.

도입 판단 점검 목록과 90일 시작 순서

도입 여부를 판단하는 첫 질문은 Thoughtworks글의 표현대로 '온톨로지를 원하나'가 아니라 '눈앞의 문제를 푸는 최소한의 의미 구조는 무엇인가'다. 이 글은 분석과 검색에 필요한 가치의 상당 부분을 잘 관리된 시맨틱 레이어와 꼼꼼한 메타데이터가 이미 제공한다고 본다. 온톨로지가 비용을 정당화하는 영역으로는 다단계 추론, 제약 조건 자동 검사, 영역 간 통합을 든다. 따라서 지금의 문제가 '부서마다 매출 숫자가 다르다'라면 시맨틱 레이어부터 보는 게 맞다. '주문→배송→온도 센서→콜드체인 이탈'처럼 관계를 따라가야 답이 나오는 질문(w1의 예)이라면 그래프와 온톨로지를 검토할 만하다.

작게 시작하는 순서는 다음과 같다. 이 글은 첫 90일을 하나의 확인 구간으로 잡는다. 1) 업무 유스케이스 하나를 고르고, 지금 시스템이 답하지 못하는 질문을 현업이 직접 적게 한다. Thoughtworks글는 이를 예산 승인 조건으로 삼고, 각 질문을 의사결정이나 금액에 연결하라고 권한다. 질문을 못 내놓으면 의미 구조가 없는 게 아니라 가치가 불분명한 것이다. 2) 엔터티를 고른다. 정의가 안정적이고 여러 팀이 필요로 하며 소유자가 분명한 것만 공개한다글. 3) 기존 스키마·시맨틱 모델·위키에서 LLM으로 초안을 뽑고 전문가는 검토만 한다글. 자동 생성된 결과는 이름·키·관계 방향을 사람이 확인해야 한다글. 4) 원천 데이터에 바인딩하고 실제 질문으로 답을 시험한다. Fabric처럼 제품마다 데이터 바인딩 조건이 따로 있으니 미리 확인한다. 교육 자료글에 따르면 바운드 데이터로 직접 답하려면 Direct Lake 모드가 필요하고, Import·DirectQuery 모드는 정의만 지원한다. 5) 갱신 주기와 드리프트 점검 담당자를 정하고 첫 정기 점검까지 돌려 본다.

90일이 끝날 때 확인할 것은 세 가지다. 처음 적은 질문 가운데 실제로 답하게 된 것이 몇 개인가. 같은 용어에 대한 부서 간 숫자 불일치가 줄었는가. 원천 시스템이 바뀌었을 때 누가 며칠 안에 정의를 고쳤는가. 세 번째 질문에 답할 사람이 없다면 범위를 넓히기 전에 소유 체계부터 다시 세워야 한다.

90일 시작 순서

1
질문 목록지금 답 못 하는 질문을 현업이 직접
2
엔터티 선정정의가 안정적이고 소유자가 분명한 것만
3
초안 생성·검토LLM 초안, 전문가 검토
4
바인딩·시험실제 질문으로 답 확인
5
갱신 주기드리프트 점검 담당자 지정

유스케이스 하나로 시작해 갱신 주기까지 한 번 돌려 보는 순서다.

도입 전 점검

필요성

관계를 따라가야 풀리는 질문인가
시맨틱 레이어로 충분하지 않은가
질문마다 결정·금액이 연결되는가

소유

용어마다 정의 소유자가 있는가
논쟁 용어의 결정권이 정해졌는가
갱신 주기와 담당자가 있는가

통제·이식성

규칙을 강제하는 실행 계층이 따로 있는가
변경을 사람이 검토하는가
정의를 개방 표준으로 내보낼 수 있는가

어떤 플랫폼을 고르든 똑같이 확인할 항목이다.

더 공부하려면

개념의 지도를 먼저 잡으려면 Thoughtworks 글글이 가장 좋다. 스키마부터 지식 그래프까지의 연속선, 실패 원인 세 가지, 제품 방식의 다섯 원칙이 한 글에 정리돼 있다. 그다음 Atlan 글글로 구축 이후에 무엇이 무너지는지를 조직·기술·경제의 세 갈래로 확인한다.

플랫폼 온톨로지가 실제로 무엇을 하는지는 Microsoft Learn의 Fabric IQ 개요글와 온톨로지 개요글에서 볼 수 있다. 무엇을 온톨로지에 올리고 무엇을 시맨틱 모델에 남길지는 교육 모듈글이 짧게 다룬다. 비교 대상으로 dbt 시맨틱 레이어 문서글를 함께 읽으면 두 계층의 역할이 구분된다.

비판적 관점은 Vonng의 글글에서, 규제 관점의 리니지 요구는 DataHub 글글에서 볼 수 있다. 둘 다 저자의 입장(비평가, 도구 공급사)이 분명한 글이니 주장과 인용된 사실을 나눠 읽기를 권한다. 이것으로 '온톨로지의 허와 실' 시리즈를 마친다. 한 문장으로 줄이면, 온톨로지의 가치는 단어가 아니라 정의를 지키는 사람과 절차에서 나온다.

참고 문헌

참고 자료(공식 문서·엔지니어링 글)

AI가 참고 문헌을 바탕으로 작성하고 검수를 거친 해설입니다. 정확한 내용은 원문을 확인해 주세요.