7월 말 커뮤니티에 Ontology Playground라는 사이트가 돌았다. Microsoft org 아래의 오픈소스 웹앱인데, 하는 일이 특이하다. 온톨로지를 그래프로 탐색하고, 비주얼 편집기로 만들어보고, 퀴즈 달린 강좌로 배운다. 백엔드 없는 정적 사이트에 MIT 라이선스, 스타 2.3k. 요컨대 온톨로지 학습 놀이터다.
장난감처럼 보이는데, 이 장난감이 가리키는 방향이 흥미롭다. #43에서 graph engineering의 두 번째 갈래(아는 것을 담는 지식 그래프)를 다뤘는데, 그 갈래의 다음 장이 이미 제품 전쟁으로 넘어가 있었다. 전장의 이름은 25년 묵은 단어, 온톨로지. 이번 글의 테제는 한 문장이다. 온톨로지는 새 기술이 아니라 이제야 임자를 만난 기술이다. 그리고 이번 사이클에서 진짜 비용은 만드는 쪽에서 유지하는 쪽으로 옮겨갔다.
임자가 이제야 왔다
2001년 Tim Berners-Lee가 Scientific American에 쓴 “The Semantic Web”을 다시 읽어보면 뜻밖의 사실이 나온다. RDF와 OWL로 웹에 의미를 심자던 그 비전이 상정한 최종 사용자는 사람이 아니라 “복잡한 과제를 대신 수행하는 지능형 에이전트”였다. 온톨로지는 처음부터 에이전트를 위해 설계된 기술이다. 다만 25년 일찍 만들어졌을 뿐이다.
왜 실패했는지도 지금 보면 선명하다. 시맨틱 웹으로 박사를 하고 지금은 Confluent에서 AI를 하는 Sean Falconer가 작년에 쓴 회고의 표현을 빌리면, 그 설계는 “웹 페이지를 쓰는 수백만 명이 정교한 구조를 수작업으로 만들고, 주석을 달고, 합의할 것”을 요구했다. 기계에게 읽기를 가르치는 대신 사람에게 기계의 언어로 쓰기를 시킨 것이고, 그건 스케일이 안 됐다. 머신러닝은 정반대 경로, 비정형 카오스에서 통계적으로 배우는 쪽으로 이겼다.
그런데 LLM이 “읽는 쪽” 문제를 풀어버리자 병목이 이동했다. 모델은 이제 어떤 테이블 스키마든 읽는다. 그런데 스키마에는 의미가 없다. revenue라는 컬럼이 세전인지 세후인지, “활성 고객”이 마지막 주문 기준 30일인지 90일인지, Orders 테이블과 Shipments 테이블을 어느 키로 이어야 비즈니스가 말하는 “배송 지연”이 되는지 — 스키마는 말해주지 않는다. 그 암묵지는 지금까지 사람 분석가의 머릿속에 있었고, 에이전트에게는 그 머릿속이 없다.
이 격차는 수치로 나와 있다. 학술 벤치마크 Spider 1.0에서 91.2%를 찍던 프런티어 모델들이, 실제 기업 데이터 웨어하우스 워크플로로 만든 Spider 2.0(ICLR 2025)에서는 17~21%로 추락했다. 반대 방향의 수치도 있다. dbt의 2026년 벤치마크에서 시맨틱 레이어를 얹으면 같은 모델의 정확도가 90.0%에서 98.2%로 올라간다(벤더 자체 벤치마크라는 단서는 달아둔다). 더 중요한 건 실패의 질이다 — 시맨틱 레이어의 실패는 “답할 수 없음”으로 나타나고, 맨 스키마 위 text-to-SQL의 실패는 자신만만한 틀린 숫자로 나타난다. 에이전트가 그 숫자로 행동까지 하는 시대에는 후자가 훨씬 비싸다.
판이 일제히 움직였다 — Palantir의 20년과 2026년의 수렴
이 판에서 제일 오래 버틴 회사는 Palantir다. “dynamic ontology” 특허의 우선일은 2006년 — 이 단어를 제품 개념으로 20년 써온 셈이다. Foundry의 온톨로지는 객체(Objects)와 관계(Links)에 더해 권한과 감사가 붙은 실행 가능한 액션(Actions)까지 포함한다 — 데이터 모델이 아니라 “조직의 디지털 트윈 위에서 의사결정을 표현하는 층”이라는 게 그들의 오랜 주장이다. 에이전트 시대가 열리자 이 주장은 갑자기 선견지명이 됐다. Forbes가 “Agentic AI가 왔다. Palantir는 20년 전부터 준비돼 있었다”는 글을 실었고, 2025년 4분기 미국 상업 매출은 전년 대비 137% 늘어난 5억 달러를 찍었다. 한국도 이 흐름 밖이 아니다 — LG CNS가 올해 3월 Palantir와 전략적 파트너십을 맺고 전담 조직까지 만들었다.
그리고 지난 1년 사이 데이터 플랫폼 진영이 일제히 같은 방향으로 움직였다. Snowflake는 Semantic Views를 밀면서 2025년 9월 시맨틱 모델의 벤더 중립 교환 표준인 **Open Semantic Interchange(OSI)**를 주도해 dbt, Salesforce(Tableau), Cube 등 30여 파트너를 모았다. dbt는 10월에 시맨틱 레이어 엔진 MetricFlow를 Apache 2.0으로 풀었다. Databricks는 Unity Catalog에 Business Semantics를 얹어 올해 4월 GA했다. BI 시대에 LookML이 지표 정의를 한 곳에 모으라고 요구했다면, 이번에는 에이전트가 읽을 비즈니스 의미를 한 곳에 모으라는 요구다. 애널리스트 Sanjeev Mohan의 전망대로 “온톨로지가 2026년 아키텍처 논쟁을 지배할 것”이라는 말이 과장으로 들리지 않는 지형이다.
Microsoft의 참전작이 Ignite 2025에서 발표된 Fabric IQ다. Work IQ(M365 업무 맥락), Foundry IQ(문서·지식 그라운딩), Web IQ(웹)와 함께 묶인 “IQ” 4형제 중 비즈니스 데이터 담당이다. 그 중심 아이템이 ontology(preview)다.
Microsoft의 답 — Fabric IQ Ontology의 실체
공식 문서 기준으로, 엔티티 타입(Customer), 프로퍼티(name, email), 관계(Customer places Order)로 기업의 어휘를 정의하고, 이 정의를 OneLake의 실제 데이터(lakehouse 테이블, 실시간 스트림, Power BI 시맨틱 모델)에 바인딩한다. 바인딩이 끝나면 쿼리 가능한 인스턴스 그래프가 생기고, 질의는 엔진별로 자동 라우팅된다(그래프는 GQL, 시계열은 KQL). 에이전트 소비 경로가 핵심인데, Fabric 안의 data agent뿐 아니라 MCP 엔드포인트로도 노출돼서 Azure AI Foundry의 에이전트나 (로드맵상으로는) Microsoft 생태계 밖 에이전트도 이 온톨로지를 그라운딩으로 쓸 수 있다. 여기에 Activator 연동 룰이 붙는다. “냉동고 온도가 임계치를 넘으면 해당 배송의 고객에게 선제 통지” 같은 조건·액션을 raw 테이블이 아니라 비즈니스 엔티티 위에 거는 기능이다.
온보딩 설계가 영리하다. 이미 프로덕션에 있는 Power BI 시맨틱 모델에서 온톨로지를 자동 생성한다 — 테이블이 엔티티 타입으로, 컬럼이 프로퍼티와 바인딩으로, 모델 관계가 관계 타입으로. “온톨로지는 저절로 만들어지지 않는다”(Constellation Research의 Michael Ni)는 도입 장벽에 대한 Microsoft의 답이 “이미 만들어둔 시맨틱 모델에서 뽑아주겠다”인 셈이다.
제약도 그대로 적어둔다. 2026년 7월 현재 온톨로지 아이템은 여전히 preview고(워크로드의 다른 구성요소는 Build 2026에서 GA됐다는 보도가 있다), 시맨틱 모델 바인딩은 Direct Lake 모드만 지원한다. 실무자 Teo Lachev는 신랄한 첫인상 리뷰에서 이 제약이 기존 Import/DirectQuery 모델 대부분을 배제한다고 지적했고, 외부 데이터를 OneLake로 모아야 하는 구조도 비판했다. Decimal 타입이 아직 지원되지 않아 전부 null로 반환되는 known issue(금액 컬럼에 치명적이다), 업스트림 데이터 변경을 수동 refresh해야 하는 제약도 있다. 그리고 애널리스트들의 공통 경고 — “이 시맨틱 레이어 위에 쌓을수록 그 로직을 다른 곳으로 옮기기 어려워진다”(Moor Insights의 Robert Kramer). 온톨로지가 남는 자산이 되려면 이식 가능해야 하는데, 그 열쇠를 쥔 것이 OSI 같은 교환 표준이다. Microsoft는 아직 OSI 창립 멤버 명단에 없다.
놀이터의 정체 — Copilot이 만들고 사람이 감독했다
다시 처음의 놀이터로 돌아가자. repo를 까보면 이건 제품팀의 공식 출시물이 아니다. 커밋 390개 중 77%를 Microsoft 취리히의 Alvaro Videla — RabbitMQ 코어 개발자 출신, 『RabbitMQ in Action』 공저자 — 혼자 썼고, 1월 말 개인 MVP로 시작해 2월에 microsoft org로 이식됐다. 앱 푸터의 크레딧 구조가 이 프로젝트의 정체성을 요약한다. “Built with GitHub Copilot · Supervised by videlalvaro.” 만든 주체가 Copilot이고 사람이 감독자다.
그런데 이 AI 보조 개발의 운영 방식이 본체만큼 흥미롭다. AI가 생성한 강좌에는 reviewStatus: under-human-review 마커가 붙고 UI가 “아직 사람이 검수하지 않음” 배지를 사용자에게 그대로 노출한다. AI에게는 예제 속 사람 이름을 발명하는 것이 금지돼 있고, 승인된 가상 인명 CSV 250개만 쓰도록 스킬 문서에 못박혀 있다. 한편 “문서를 코드와 함께 갱신하라”는 규약 파일이 버젓이 있는데도 README는 강좌 수를 9개로 적어둔 채 뒤처져 있다(실제로는 13개 강좌 61개 아티클이다). AI 보조 개발의 거버넌스가 어디까지 작동하고 어디서 새는지가 한 repo 안에 다 들어 있다.
콘텐츠는 학습 사다리로서 잘 설계돼 있다. 백미는 IQ Lab — 리테일 공급망 온톨로지를 엔티티 3개(Customer, Order, Product)에서 시작해 7단계에 걸쳐 15개까지 키우는 점진 실습이다. 단계마다 앞 단계와의 diff가 그래프에 하이라이트된다. 온톨로지 교육이 대개 철학 강의처럼 흐르는 걸 생각하면, “작게 시작해서 자라는 걸 눈으로 본다”는 이 설계 하나가 이 사이트의 존재 이유다. 정직한 구석도 있다 — “자연어 질의 실험실”에는 LLM이 한 줄도 없다. 281줄짜리 결정론적 문자열 매칭이다. 답변마다 “실제 배포라면 데이터 플랫폼을 질의했을 것”이라는 단서가 박혀 있다. 데모가 데모임을 스스로 밝히는 드문 사례다.
실전: 필요한지부터 가리고, 작게 시작한다
붐이 온다고 다 올라탈 일은 아니다. 회의론의 근거가 구체적이다. 한 조사 기준 지식 그래프의 프로덕션 채택률은 2024년 26%에서 2025년 말 27%로 사실상 제자리다. 시맨틱 스튜어드 운영 비용이 엔티티 타입 50~100개당 1 FTE로 잡히고, 폐기된 엔터프라이즈 지식 그래프 프로젝트의 3분의 2가 내부 전문성 부족을 실패 원인으로 꼽았다. 그리고 구축보다 무서운 게 온톨로지 드리프트다 — 조직과 현실은 계속 바뀌는데 온톨로지가 그걸 못 따라가면서 서서히 어긋나는 것. #43에서 “영원히 자라기만 하는 그래프는 자산이 아니라 부채”라고 했던 것과 같은 병이다. 20년 전 Clay Shirky가 “Ontology is Overrated”에서 톱다운 분류 체계를 비판했을 때 지적한 유지보수 문제는, LLM이 와도 사라지지 않았다.
그래서 순서가 중요하다. #43에서 지식 그래프의 판별 질문이 “벡터로 안 되는 질문이 내 워크로드에 진짜 있는가”였다면, 온톨로지의 판별 질문은 이거다. “스키마만으로 안 통하는 질문이 에이전트에게 실제로 들어오는가.” 구체적으로 — 같은 지표를 두 팀이 다르게 계산해서 회의가 숫자 맞추기로 새는가, 에이전트나 신입이 “이 컬럼이 무슨 뜻이냐”를 사람에게 물어야 하는가, 용어 정의가 위키·YAML·머릿속에 세 벌로 흩어져 있는가. 셋 다 아니면 아직 아니다.
맞다면 작게 시작한다. 개념은 놀이터에서 잡는 게 제일 싸다 — Ontology Playground의 IQ Lab을 한 시간 따라가면 엔티티·관계·바인딩이 감으로 잡히고, 설치도 계정도 필요 없다. 첫 실물은 자기 도메인의 미니 온톨로지다. IQ Lab이 보여준 그대로 핵심 엔티티 15개 이하로 시작해서 실제 질문이 요구할 때만 키운다. 처음부터 전사 온톨로지를 그리는 순간 앞 문단의 실패 통계에 합류한다(“부서 단위 quick win부터”는 Directions on Microsoft의 CIO 조언이기도 하다). 도구는 새로 들일 필요 없다. Fabric을 쓰는 조직이면 Power BI 시맨틱 모델에서 자동 생성해 검토·보정하는 게 최단 경로다. 아니면 dbt 시맨틱 레이어처럼 이미 깔린 층을 에이전트에 노출하는 쪽이 먼저다. 어느 쪽이든 정의를 특정 플랫폼 포맷으로만 갖고 있지 말 것 — OSI가 자리 잡으면 이식성이 곧 협상력이 된다.
관전 포인트
#44에서 모델은 빌린 것이고 eval은 내 것이라고 정리했는데, 온톨로지는 명백히 “내 것” 계열의 자산이다. 우리 회사에서 “활성 고객”이 무슨 뜻인지는 어떤 프런티어 모델도 대신 알아낼 수 없고, 한 번 적어두면 모델을 갈아타도 남는다. 다만 eval과 달리 온톨로지는 방치하면 썩는다 — 드리프트를 감당할 소유자 없이 시작하면 상속받는 건 부채다.
지켜볼 지점은 둘이다. 하나는 표준 전쟁 — OSI가 진짜 교환 표준으로 서면 “어느 플랫폼에 온톨로지를 두는가”는 락인에서 선택으로 바뀐다. 그 순간 이 판의 승부처는 저장에서 도구와 에이전트 연동 품질로 내려온다. Microsoft가 MCP 엔드포인트를 여는 것과 OSI에 이름을 올리지 않은 것 사이의 긴장이 여기 있다. 다른 하나는 누가 온톨로지를 계속 참이게 유지하는가 — 25년 전에는 이 일을 시킬 사람이 없어서 실패했다. 이번에는 LLM이 초안을 만들고 드리프트를 감지하는 보조자로 투입된다는 게 다르다. 그 보조가 1 FTE를 0.1 FTE로 줄여주는지가, 이 재회가 이번에는 성사되는지를 가를 것이다.
25년 전 시맨틱 웹은 사람에게 기계의 언어로 쓰라고 요구하다 실패했다. 이제 기계가 사람의 언어를 배웠다. 우리 회사의 언어를 한 번 적어두는 일만 남았다.