Comad.J

우주를 유영하는 기록입니다

4 분 소요

온톨로지(Ontology): 기계가 세상을 이해하는 법

저번 포스팅에서 AI 시스템의 큰 그림(온톨로지 → 토폴로지 → RAG → LangGraph)을 그려봤는데, 오늘은 그 시작점인 온톨로지(Ontology)에 대해 더 깊이 파고들어 보려고 한다.

단순히 “단어들의 관계”라고 퉁치고 넘어가기엔, 이 개념이 가진 공학적 무게가 꽤 무겁다. 특히 Knowledge Graph나 진정한 의미의 AI 에이전트를 설계하려면, 1993년 톰 그루버(Tom Gruber)가 정립한 온톨로지의 정의를 제대로 짚고 넘어갈 필요가 있다.

이 글은 톰 그루버의 논문 A Translation Approach to Portable Ontology Specifications의 내용을 바탕으로 정리한 복습 노트다.

1. 정의: “Ontology is a specification of a conceptualization”

온톨로지를 한 문장으로 정의하면 위와 같다. “개념화(Conceptualization)의 명세(Specification)”.

이 짧은 문장에 담겨있는 두 가지 핵심 축을 제대로 이해하는 게 중요하다.

1) 개념화 (Conceptualization): “세상을 어떻게 추상화할 것인가?”

우리가 세상을 바라보는 추상적인 관점이다. 세상은 무수한 객체(Objects)와 그들 사이의 관계(Relationships)로 이루어져 있지만, 우리는 모든 것을 인지하지 않는다. 특정 목적을 위해 관심 있는 대상만 뽑아내서 머릿속에 모델을 만든다.

예시: ‘책(Book)’이라는 대상을 볼 때

  • 도서관 사서의 개념화: ISBN 코드, 저자, 출판사, 대출 가능 여부 (정보적 관점)
  • 택배 기사의 개념화: 가로/세로/높이, 무게, 깨짐 주의 여부 (물리적 관점)
  • AI 에이전트의 개념화: 위키백과 링크, 주제(Topic), 관련 논문 (지식적 관점)

Conceptualization은 “이 도메인(Domain)에서 존재하는 것들을 어떤 관점으로 바라볼 것인가?”에 대한 추상적인 약속이다.

2) 명세 (Specification): “어떻게 기술할 것인가?”

그 추상적인 개념 모델을 구체적인 언어나 기호로 기록한 것이다. 내 머릿속에만 있는 개념은 공유될 수 없다. 이걸 컴퓨터가 읽을 수 있는 형태로, 약속된 문법에 따라 명시적으로(Explicit) 기술해야 비로소 온톨로지가 된다.

예시:

  • 자연어: “책은 저자가 쓴 저작물이다.” (모호함)
  • 논리식(First-order Logic): $\forall x (Book(x) \rightarrow \exists y (Author(y) \wedge wrote(y, x)))$ (명확함)
  • 코드(Class): class Book { Author author; } (구현 종속적)

결론: 온톨로지란 특정 도메인의 지식(개념화)을 컴퓨터가 이해하고 처리할 수 있도록 명확하게 기술(명세)한 체계다.

2. 왜 DB 스키마랑 다른가? (Knowledge Sharing)

“그거 그냥 데이터베이스 스키마(Schema) 아니야?”라고 물을 수 있다. 근데 핵심 목적이 다르다.

  • DB 스키마: 데이터의 저장과 효율성에 초점. “이 데이터를 어떻게 최적화해서 저장할까?”
  • 온톨로지: 지식의 공유와 재사용(Knowledge Sharing & Reuse)에 초점. “이 지식을 어떻게 다른 에이전트나 시스템이 오해 없이 이해하게 할까?”

톰 그루버는 논문에서 “Translation Approach”를 강조한다. 서로 다른 시스템(A, B)이 서로 대화하려면, 각자의 내부 포맷을 몰라도 소통할 수 있는 공통의 언어(Inter-lingua)가 필요하다. 온톨로지가 바로 그 역할을 한다. 지식을 이동 가능(Portable)하게 만드는 것이다.

3. 온톨로지 설계의 5가지 원칙 (Design Criteria)

톰 그루버는 좋은 온톨로지를 만들기 위해 5가지 원칙을 제시했다. 이건 단순히 이론적인 이야기가 아니라, 실제로 RAG나 지식 그래프를 구축할 때 마주치는 실무적인 가이드라인이다.

1) 명확성 (Clarity)

정의는 모호하지 않고 객관적이어야 한다(Objective). 가능하다면 자연어 설명뿐만 아니라 논리적인 공리(Axioms)로 제약 조건을 걸어야 한다.

  • Bad (주관적): “고성능 컴퓨터” (무엇이 고성능인가?)
  • Good (객관적): “연산 속도가 100 TFLOPS 이상인 컴퓨터”
  • Why?: 주관적인 정의는 시스템 간 통신에서 오해를 낳는다. ‘고성능’의 기준이 시스템마다 다르기 때문이다.

2) 일관성 (Coherence)

정의된 내용들끼리 논리적 모순이 없어야 한다. 문장에서 추론된 사실이 정의와 충돌하면 안 된다.

  • Bad (모순 발생):
    1. 정의: “모든 포유류는 새끼를 낳는다.”
    2. 정의: “오리너구리는 포유류다.”
    3. 사실: “오리너구리는 알을 낳는다.” → 시스템 붕괴 (Inconsistent)
  • Good: “대부분의 포유류는 태생이지만, 단공류(오리너구리 등)는 난생이다”라는 예외 처리가 가능한 구조여야 한다.

3) 확장성 (Extensibility)

나중에 새로운 개념을 추가할 때, 기존 정의를 다 뜯어고치지 않아도 되어야 한다. 기존 어휘(Vocabulary)를 바탕으로 새로운 용어를 정의할 수 있어야 한다.

  • Scenario: ‘전기차(EV)’라는 새로운 개념이 등장했다.
  • Good: 기존 ‘자동차’ 클래스에 FuelType 속성만 추가해서 확장.
  • Bad: ‘자동차’ 정의 자체가 “내연기관을 가진 탈것”으로 되어 있어서, ‘전기차’를 정의하려면 ‘자동차’의 정의부터 수정해야 함.

4) 인코딩 편향 최소화 (Minimal Encoding Bias)

이게 정말 중요하다. 지식의 내용(Content)과 구현(Representation)을 분리해야 한다. 특정한 구현 방식(비트 수준의 표현, 특정 언어의 문법)에 의존하면 안 된다.

  • Bad: “날짜는 YYYYMMDD 형식의 8자리 정수로 표현한다.” (구현 종속적)
  • Good: “날짜는 시점(Time Point)을 나타낸다.” (개념적 정의)
  • Why?: 어떤 시스템은 날짜를 Unix Timestamp로 쓸 수도 있고, 문자열로 쓸 수도 있다. 온톨로지가 특정 포맷을 강제하면 공유가 불가능해진다.

5) 최소한의 온톨로지 약속 (Minimal Ontological Commitment)

“꼭 필요한 것만 정의하라.”

가장 뼈대가 되는 약속만 하고, 나머지는 각 시스템이 자유롭게 특수화(Specialize)해서 쓰도록 놔두라는 것이다.

  • Bad (Over-commitment): “모든 ‘사람’ 클래스는 반드시 주민등록번호, 여권번호, 운전면허번호를 가져야 한다.”
  • Good: “모든 ‘사람’은 식별자(Identifier)를 가질 수 있다.”
  • Why?: 너무 빡빡하게 정의하면(Thick Ontology), 주민등록번호가 없는 외국인이나 면허가 없는 미성년자를 다루는 시스템은 이 온톨로지를 사용할 수 없게 된다. 공유를 위해서는 최소한의 교집합만 잡아야 한다.

4. 온톨로지의 구성 요소 (Components)

실제로 코드로(혹은 OWL/Turtle로) 구현할 때 다루게 되는 재료들이다.

  1. 클래스 (Classes / Concepts): 세상에 존재하는 객체들의 집합. 논리적으로는 단항 서술어(Unary Predicate)다.
    • 예: Person(x) - “x는 사람이다”
  2. 관계 (Relations): 객체 간의 상호작용. 이항 서술어(Binary Predicate)다.
    • 예: ParentOf(x, y) - “x는 y의 부모다”
  3. 함수 (Functions): 관계의 특수한 형태. $N$개의 입력에 대해 하나의 값을 반환한다.
    • 예: PriceOf(Car) → Number (가격은 하나만 존재함)
  4. 공리 (Axioms): 항상 참으로 간주되는 규칙. 지식의 ‘제약 조건’이자 ‘추론 규칙’이 된다.
    • 예: forall x, y (ParentOf(x, y) -> AncestorOf(x, y)) (부모면 조상이다)
  5. 인스턴스 (Instances): 실제 데이터 (Ground Level).
    • 예: TomGruber, iPhone15

5. Modern AI에서의 의미

LLM(거대언어모델) 시대에 온톨로지는 낡은 기술처럼 보일 수도 있다. 근데 RAG(Retrieval Augmented Generation) 시스템을 구축하다 보면 다시 이 원칙들로 돌아오게 된다.

LLM이 아무리 똑똑해도, 회사 내부의 복잡한 업무 규정이나 부품 간의 호환성 관계를 그냥 텍스트 덩어리로 던져주면(Chunking) 제대로 이해하지 못한다. 지식 그래프 형태로 명확하게(Clarity) 구조화하고, 모순 없이(Coherence) 연결해 줘야 비로소 정확한 답변을 내놓을 수 있다.

특히 Minimal Ontological Commitment 원칙은 마이크로서비스(MSA) 환경의 AI 에이전트 간 통신 프로토콜을 설계할 때 뼈저리게 와닿는 조언이다.

“데이터를 어떻게 저장할까”가 아니라 “데이터의 의미를 기계에게 어떻게 가르칠까”를 고민하는 것. 그게 온톨로지 공부의 핵심인 것 같다.

참고 자료

댓글남기기

참고