엔터프라이즈 온톨로지 플랫폼, 무엇으로 고를 것인가

지난 1년 사이 받은 데이터 플랫폼 제안서를 나란히 펼쳐 보면 같은 단어가 반복됩니다. 온톨로지. Palantir도 쓰고, Databricks도 쓰고, Snowflake도 쓰고, Microsoft도 씁니다. 2년 전만 해도 이 단어를 앞세우는 회사는 손에 꼽았습니다.

선택이 쉬워졌을 것 같지만 반대입니다. 모두가 같은 답을 내놓으면 그 답은 더 이상 기준이 되지 못합니다. "온톨로지를 지원하는가"는 이제 변별력이 없는 질문입니다.

15개월 동안 무슨 일이 있었나

2025년 3월 13일. Palantir와 Databricks가 제품 제휴를 발표했습니다. Palantir는 Ontology System을, Databricks는 Unity Catalog와 Delta Sharing 기반의 처리 규모를 맡는 구조입니다. 양사는 국방부, 재무부, HHS, bp 등이 이미 이 통합을 쓰고 있다고 밝혔습니다.

2025년 10월 16일. Snowflake와 Palantir가 제휴했습니다. Snowflake의 AI Data Cloud에 Palantir Foundry와 AIP를 연결하는 방식입니다.

2025년 11월. Microsoft가 Ignite에서 Fabric IQ를 공개했습니다. 핵심은 새로 도입한 Ontology 항목입니다. 사람, 프로세스, 시스템, 액션, 규칙, 데이터를 하나의 온톨로지로 연결한다는 설명입니다. 기존 시맨틱 모델을 출발점으로 삼아 몇 번의 클릭으로 온톨로지를 시작할 수 있게 했습니다. 데이터 플랫폼을 인텔리전스 플랫폼으로 옮기겠다는 선언입니다.

2026년 6월 16일. Databricks가 Data + AI Summit에서 Genie One과 Genie Ontology를 내놨습니다. Genie Ontology를 "조직 내 모든 지식의 웹"이자 "자체 개선되는 컨텍스트 레이어"로 정의했습니다. Genie One과 Genie Agents, Genie Code는 정식 출시됐습니다.

15개월 만에 주요 데이터 플랫폼 네 곳이 전부 온톨로지 계층을 갖췄습니다. 누가 먼저였느냐는 이제 중요하지 않습니다. 한 회사의 전략이라기보다, 업계 전체가 같은 문제를 겪고 있다는 신호로 보는 편이 맞습니다.

왜 전부 같은 방향으로 갔나

AI 에이전트 때문입니다.

대시보드를 만들 때는 데이터가 어디에 어떤 이름으로 있는지 사람이 알고 있으면 됐습니다. 사람이 해석하고 사람이 판단했으니까요. 에이전트에게 일을 맡기는 순간 이 전제가 깨집니다. 에이전트는 "이 주문이 지금 출고 가능한가"를 판단하려면 주문과 재고와 결제 상태가 어떤 관계로 묶여 있는지, 어떤 규칙이 반드시 성립해야 하는지를 알아야 합니다. 테이블과 컬럼만 던져주면 그럴듯한 문장을 만들 뿐 답을 보증하지 못합니다.

그래서 각 플랫폼이 낸 결론이 같습니다. 모델과 별도로, 데이터의 의미를 정의하는 계층이 하나 더 있어야 한다는 것입니다.

Databricks는 Genie Ontology의 효과로 정확도 향상과 지연시간 감소, 비용 절감을 내세웠고, 토큰 비용도 명시적으로 언급했습니다. 저희가 2026년 2월 Ground Truth와 온톨로지 글에서 온톨로지의 부수 효과로 짚었던 지점과 같습니다. 출발점이 다른 두 곳이 같은 결론을 낸 셈이라, 특정 벤더의 마케팅 문구로만 보기는 어렵습니다.

그래서 무엇으로 고를 것인가

"온톨로지가 있는가"가 변별력을 잃었으니 질문을 바꿔야 합니다. 아래 기준을 봅니다.

온톨로지의 소유권은 누구에게 있는가

가장 먼저 물어야 할 질문입니다. 우리 회사의 업무 구조를 정의한 그 모델이 플랫폼을 떠날 때 함께 나올 수 있는지요.

온톨로지를 한번 정의해 두면 업무 프로세스와 권한 체계, 자동화 워크플로우가 그 정의를 기준으로 만들어집니다. 데이터는 옮길 수 있어도 그 정의를 기준으로 만든 구조는 옮기기 어렵습니다. 플랫폼 교체 비용의 대부분이 여기서 발생합니다. 표준 포맷으로 내보낼 수 있는지, 정의가 벤더 고유 형식에 묶이는지를 계약 전에 확인해야 합니다.

규칙이 바뀔 때 무슨 일이 일어나는가

온톨로지를 만드는 것보다 유지하는 것이 훨씬 어렵습니다. 기업의 규칙은 계속 바뀝니다. 할인 정책이 바뀌고 공정이 추가되고 조직이 개편됩니다.

규칙 하나를 바꿨을 때 영향을 받는 범위를 시스템이 알려주는지, 변경 이력이 남는지, 과거 시점의 정의로 답을 재현할 수 있는지 물어야 합니다. 감사나 분쟁이 생겼을 때 "그때는 이 규칙이었다"를 증명하지 못하면 공공과 금융, 제조 어느 쪽에서도 쓰기 어렵습니다.

데이터가 어디에 있어야 하는가

네 플랫폼 모두 클라우드를 전제로 설계됐습니다. 국내 제조와 공공, 국방 현장에서는 이 전제가 자주 깨집니다. 망분리 환경이거나, 설계 도면과 원가 정보를 외부로 내보낼 수 없거나, 규정상 특정 등급 이상의 데이터는 반출 자체가 금지됩니다.

온프레미스와 하이브리드 배포가 실제로 가능한지, 가능하다면 기능 제약이 무엇인지를 초기에 확인해야 합니다. PoC는 클라우드에서 잘 돌았는데 본사업에서는 쓸 수 없는 경우가 드물지 않습니다.

누가 정의하는가

기술보다 조직의 문제입니다. 온톨로지에 들어갈 지식은 대부분 현장에 있습니다. 베테랑 엔지니어의 머릿속, 부서마다 다르게 쓰는 용어, 문서화된 적 없는 예외 규칙.

도구가 좋아도 이 지식을 정리할 사람과 절차가 없으면 온톨로지에 채울 내용이 없습니다. 도입 검토 단계에서 "누가, 얼마의 시간을 들여, 어떤 방식으로 정의할 것인가"에 답이 없다면 도구 비교는 아직 이른 단계입니다.

자주 생기는 문제

데이터 모델링 프로젝트로 취급하는 경우

온톨로지는 스키마 설계보다 업무 규칙을 문서로 정하는 일에 가깝습니다. 데이터팀만 투입해서 끝내면 현업이 쓰지 않는 구조가 나옵니다.

완성한 뒤 방치하는 경우

문서화하고 손을 떼는 순간 낡기 시작합니다. 6개월 뒤 현장 규칙과 어긋난 온톨로지는 없느니만 못합니다. 틀린 답에 근거까지 붙어 나오기 때문입니다.

도구부터 고르는 경우

우리 업무에서 반드시 같은 답이 나와야 하는 질문이 무엇인지 먼저 적어야 합니다. 그 목록이 없으면 어떤 플랫폼을 골라도 무엇을 만들어야 할지 모른 채 시작하게 됩니다.

하이퍼이지가 이 문제를 푸는 방식

저희가 Skein OS를 만들면서 온톨로지 옆에 지식 사전(Knowledge Dictionary)이라는 레이어를 따로 둔 이유가 위의 규칙 변경, 정의 주체 기준에 있습니다.

현장에서 쓰는 용어와 온톨로지 엔티티를 매핑해 두면 부서마다 다르게 부르던 개념이 하나의 정의로 정리됩니다. 규칙 변경 이력을 자동으로 추적하면 "언제부터 이 규칙이었는지"를 증명할 수 있습니다. 도구를 먼저 정하고 조직을 맞추는 대신, 조직이 이미 쓰는 말부터 정리하는 방식입니다.

배포도 같은 맥락입니다. 민감 데이터를 외부로 반출할 수 없는 고객을 위해 온프레미스와 하이브리드 구성을 제공합니다. 공공과 국방, 제조 현장에서 반복해서 요구받은 조건입니다.

온톨로지가 특별한 기술이던 시기는 지났습니다. 네 플랫폼이 15개월에 걸쳐 같은 결론에 도달하면서 이제는 기업 AI의 기본 계층에 가까워졌습니다.

이제는 온톨로지를 쓸지보다, 우리 업무의 기준이 되는 사실을 누가 정의하고 누가 소유하며 어떻게 유지할지를 먼저 정해야 합니다. 도구는 그다음에 고르면 됩니다.