Data Eng Wiki

The Evolution of Ontology

18 min read

The Evolution of Ontology: From Formal Semantics to Knowledge Graphs, Decisions and AI Agents

Author: Fanghua (Joshua) Yu | Source: Medium | Published: 2026-08-16

한 줄 요약

여러 팀이 모두 “온톨로지를 만든다”고 말하면서 매우 다른 워크로드를 최적화하고 있고, 그 진화를 Meaning → Traversal → Reasoning → Action으로 보면 왜 하나의 완벽한 기업 온톨로지가 더 이상 답이 아닌지가 보인다.

핵심 주장/내용

  • 핵심 관찰 — 같은 단어, 다른 문제: 한 팀은 Smartphone ⊆ ElectronicProduct를 신중히 정의하고, 다른 팀은 추천 앱이 Customer → purchased → Product → belongsTo → Category를 효율적으로 순회하도록 지식 그래프를 설계하고, 세 번째 팀은 “Gold 고객이 $100 넘게 쓰고 주문에 초대형 품목이 없으면 무료 특급 배송” 같은 비즈니스 로직을 모델링하고, AI 팀은 에이전트에게 “Order란 무엇인가? 어디서 가져오나? 어떤 도구가 그것을 조작할 수 있나? 환불 전에 어떤 조건이 만족되어야 하나? 그리고 나는 실제로 환불을 발행할 권한이 있나?” 를 알려줄 시맨틱을 원한다
    • 온톨로지가 주로 의미의 형식 모델이던 것에서 지식 그래프·의사결정 시스템·AI 에이전트의 점점 운영적인 컴포넌트로 진화하고 있다
  • 4단계 진화 (서로를 대체하지 않고 각 단계가 이전 위에 새 요구를 더한다. 요구가 누적되면서 “좋은 온톨로지”의 정의가 바뀌기 시작한다):
    • Formal Semantics — Meaning: 기초에서 온톨로지는 의미를 명시적으로 만드는 것이다. 그런데 온톨로지 공학은 택소노미 만들기보다 금세 흥미로워진다
      • Customer는 Person의 일종인가? 반드시 그렇지 않다. 고객이 조직일 수 있고, 개인이라 해도 “customer”는 Person이 비즈니스에 대해 수행하는 역할로 이해하는 게 나을 수 있다
      • SKU는 Product인가? 아니면 특정 판매 가능 Product Variant의 식별자(속성) 인가?
      • Product Offering은 Product 자체와 같은 것인가? 아마 아니다 — 같은 기저 제품이 다른 가격, 다른 채널, 다른 계약 조건으로 제공될 수 있다
      • Premium Customer는 진짜로 Customer의 서브클래스인가? 아니면 “premium”은 멤버십·지출·재직 기간 같은 변하는 조건으로 결정되는 status인가?
      • 최적화 대상은 시맨틱 정밀성, 논리적 일관성, 추론, 상호운용성
    • Knowledge Graphs — Traversal을 1급 관심사로: 온톨로지가 운영 지식 그래프 뒤의 스키마가 되면 “이 지식을 어떻게 연결해야 애플리케이션이 필요한 것을 효율적으로 찾을 수 있나” 가 똑같이 중요해진다
      • 시맨틱하게 상세한 그래프는 구매를 Customer → placed → Order → contains → OrderItem → refersTo → Product로 표현할 수 있고, 그것은 합리적이며 트랜잭션 구조를 보존해 수량·가격·날짜에 접근하게 해준다. 하지만 추천 워크로드는 더 단순한 순회 Customer → purchased → Product를 반복적으로 필요로 할 수 있다. purchased 관계는 기술적으로 긴 경로에서 유도 가능하고 순수하게 형식적 관점에서는 저장하는 것이 중복으로 보일 수 있지만, 운영 그래프 관점에서는 극도로 유용할 수 있다
      • 이제 온톨로지 설계가 이런 질문을 포함한다: 어떤 관계를 명시적으로 만들어야 하나? 어떤 중간 엔티티가 필요한가? 어떤 경로가 자주 순회되나? 어떤 추론된 관계를 materialize해야 하나? 흔한 질문이 몇 hop을 요구해야 하나? 관계는 어느 방향이어야 하나? GraphRAG나 검색 시스템이 어떤 그래프 패턴을 검색해야 하나?
      • 지식 그래프가 온톨로지를 의미의 모델에서 내비게이션을 위한 아키텍처로 바꾼다. 그리고 여기서 하나의 보편적으로 “최선”인 온톨로지라는 발상이 방어하기 어려워진다
      • 의미가 먼저인가 운영이 먼저인가: 가장 널리 채택된 그래프 시스템 다수가 형식 온톨로지에서 시작하지 않았고 훨씬 실용적 요구에서 자랐다 — “고도로 연결된 데이터가 있다. 그 연결을 어떻게 효율적으로 질의·순회·분석하나?” 이것이 property graph(LPG), 그래프 DB, 그래프 알고리즘, 이벤트 유래 그래프, 네트워크 분석으로 자연히 이어진다. 두 세계가 점점 수렴했고, 그 수렴이 “knowledge graph”라는 용어가 사람마다 꽤 다른 것을 의미할 수 있는 이유 중 하나
      • 온톨로지가 의미와 운영 둘 다를 서빙해야 하면 새로운 설계 타협이 나타난다. 시맨틱하게 정밀한 모델은 추론에는 유용하지만 그래프 순회와 앱 쿼리에는 번거로운 추상·중간 개념·긴 관계 경로를 도입할 수 있고, 반대로 성능에 최적화된 그래프 모델은 구분을 평탄화하고 파생 관계를 중복시키고 운영적으로는 편하지만 시맨틱하게는 덜 우아한 지름길을 도입할 수 있다
      • 진짜 설계 딜레마: 모델이 주로 도메인을 가능한 정확히 표현해야 하나, 애플리케이션이 사용해야 하는 방식으로 표현해야 하나? 실무의 답은 점점 어느 극단도 아니다 — 시맨틱 충실도를 순회 유용성·쿼리 단순성·워크로드 성능과 균형 잡되, 어떤 구조가 핵심 도메인 의미를 나타내고 어떤 것이 주로 운영 편의를 위해 존재하는지 명확히 하는 것
    • Decision Intelligence — Reasoning: 온톨로지는 수십 년간 추론 능력을 가졌고 OWL 같은 언어로 reasoner가 명시적 시맨틱에서 암묵적 지식을 유도하고 불일치를 탐지할 수 있었다. 현대 비즈니스 시스템은 더 넓은 질문에 답해야 한다 — 우리가 아는 것을 감안할 때 어떤 로직이 적용되고, 왜 이런 일이 일어났고, 다음에 무슨 일이 일어날 수 있고, 우리는 무엇을 해야 하나?
      • 논리적 추론: 무료 특급 배송 결정에서 온톨로지는 PremiumCustomer·Order·OversizedProduct·ExpressDelivery가 무엇을 의미하는지 확립할 수 있지만, 결정은 현재 주문 가치·위치·프로모션 상태·배송 제약에도 달려 있다. 온톨로지가 시맨틱 기반을 제공하되 결과는 시맨틱 + 현재 사실 + 비즈니스 로직 + 컨텍스트에 달려 있다
      • 인과 추론: 반품률 상승을 관측하면 지식 그래프가 반품이 배송 지연·특정 공급자·특정 카테고리와 상관됨을 드러낼 수 있지만 비즈니스는 상관 이상을 원한다 — “왜 반품이 늘고 있나?” 그리고 더 중요하게 “공급자를 바꾸거나 배송 시간을 개선하거나 제품 설명을 바꾸면 반품률이 실제로 줄어들까?” 온톨로지가 Supplier·ProductDefect·DeliveryDelay·Return·CustomerSatisfaction 같은 개념을 정의하고 인과 모델이 SupplierQuality → ProductDefectRate → ProductReturnRate 같은 방향적 관계를 표현한다. 온톨로지가 그 변수들에 공유된 의미를 주고 인과 모델이 하나를 바꾸면 다른 것에 어떤 영향이 있는지 설명하도록 돕는다
      • 더 유용한 분리: 온톨로지는 상대적으로 안정적인 의미를 포착 / 규칙은 운영 로직과 정책 / 인과 모델은 원인·효과·개입에 대한 가설 / 의사결정 모델은 증거와 대안을 결합해 어떤 행동을 취할지 결정
      • 온톨로지가 모든 형태의 추론이 그 안에 인코딩되어야 하는 곳이 아니라, 여러 형태의 추론을 위한 시맨틱 기반이 되어가고 있다
    • AI Agents — Action: 에이전트는 단순히 또 하나의 추론 능력을 더하는 것보다 근본적인 전환을 도입한다. 전통 정보 시스템과 많은 생성형 AI 앱은 주로 정보를 읽고 검색하고 요약하고 설명하지만, AI 에이전트는 행동하기 위해 정보를 해석할 것을 기대받는다
      • “지난주에 산 헤드폰이 불량이야. 신형으로 교체해줘” 에 대해 에이전트는 주문을 찾고, 해당 품목을 식별하고, 어떤 정책이 적용되는지 판단하고, 교체 재고를 확인하고, 가격 차이를 계산하고, 교체 주문을 만들고, 반품 라벨을 생성하고, 환불을 발행하거나 요청해야 할 수 있다
      • 그 지점에서 개념을 오해하는 것은 더 이상 정보 품질 문제가 아니라 잘못된 행동이 될 수 있다. 리포트를 읽는 사람에게는 약간의 모호함이 허용될 수 있지만, 환불이나 교체 트랜잭션을 만드는 에이전트에게는 아닐 수 있다
      • 에이전트는 capability에 대한 시맨틱도 필요하다: 전통 온톨로지가 주로 도메인의 사물을 기술하는 반면, 에이전트는 checkReturnEligibility(), reserveInventory(), createReplacementOrder(), issueRefund() 같은 것에 대해 이 연산이 어떤 비즈니스 엔티티에 작용하나? 어떤 입력을 요구하나? 어떤 조건이 이미 성립해야 하나? 어떤 효과를 낼까? 어느 시스템이 결과 변경을 소유하나? 행동이 되돌릴 수 있나? 사람 승인이 필요한가? 어떤 증거가 그것을 정당화해야 하나? 를 이해해야 한다
      • 전통 온톨로지는 무엇이 존재하는지를 기술한다. 에이전틱 시맨틱은 점점 존재하는 것으로 무엇을 할 수 있는지를 기술해야 한다
      • operational semantic contract — 에이전트가 필요로 하는 것은 “에이전트를 위한 온톨로지”보다 넓다. 개념(Order·Refund·ProductVariant는 무엇을 의미하나) + 관계 + authoritative 데이터(에이전트가 현재 상태를 어디서 얻어야 하나) + capability(어떤 연산이 가용한가) + precondition(연산이 유효하려면 무엇이 참이어야 하나) + 정책(에이전트가 무엇을 하도록 허용되나) + 증거(행동 전에 무엇이 확립되어야 하나) + 효과(행동이 성공하면 무엇이 바뀌나)를 연결한다
      • 이 계약이 에이전트가 “요청을 이해한다” → “이 요청이 이 기업에서 무엇을 의미하는지 이해한다” → “내가 안전하게 실행할 수 있는 행동이 무엇인지 안다” 로 안정적으로 이동하게 해준다
      • 시맨틱 모호성의 비용이 달라진다: 전통 시스템에서 나쁜 시맨틱 → 나쁜 이해였다면, 자율 시스템에서는 나쁜 시맨틱 → 나쁜 결정 → 잠재적으로 잘못된 행동

주요 수치 / 사실

  • 진화의 궤적: 지식 표현 → Semantic Web → 구조화된 웹 데이터 → 지식 그래프 → 기업 시맨틱 → 생성형 AI와 AI 에이전트
  • Semantic Web은 초기 비전이 시사하던 방식으로 웹 전체를 변형하지 않았지만 시맨틱 모델링이 사라지지도 않았다 — 많은 아이디어가 더 실용적 형태로 embedded되었다. Schema.org가 검색 엔진과 앱이 쓰는 구조화 데이터의 공유 어휘를 개발했고 엄격한 형식 준수를 요구하기보다 실용적이고 유연한 접근을 의도적으로 취했다. Google이 2012년 Knowledge Graph를 소개하며 그 전환을 “things, not strings” 로 기억에 남게 기술했다
  • 최종 정리: Formal semantics: 이것은 무엇을 의미하나? / Knowledge graphs: 어떻게 연결되어 있나? / Decision intelligence: 우리는 무엇을 해야 하나? / AI agents: 내가 안전하게 행동할 수 있을 만큼 이것이 무엇을 의미하나?
  • 미래는 아마 하나의 완벽한 기업 온톨로지를 만드는 것이 아니다. 온톨로지·그래프·규칙·의사결정 모델·에이전트 harness가 함께 작동하는 일관된 시맨틱 아키텍처(또는 시맨틱 레이어)를 만드는 것이다. 그리고 그렇게 되면서 온톨로지 공학이 넓어진다 — 전문 온톨로지스트는 여전히 중요하지만 시맨틱 모델링이 점점 그래프 엔지니어·의사결정 엔지니어·AI 아키텍트·도메인 전문가에 걸친 공유 역량이 된다

관련 위키

Source: 원문 보기

그래프 뷰

백링크