온톨로지 개론

지식 표현의 설계 사상: 정의, 구조, 설계 방법론, 구현 기술

온톨로지는 특정 도메인의 개념, 관계, 제약을 형식적으로 정의한 지식 표현 모델이다. 이 글에서는 온톨로지의 정의와 수준 체계, 데이터 모델과의 핵심 차이, 설계 방법론(METHONTOLOGY, 역량 질문, 설계 패턴), 구현 기술(OWL, Property Graph, RDB), 평가 기준까지를 6개 교재를 종합하여 정리한다.

Data Governance
Data Engineering
AI
Agent
저자

Kwangmin Kim

공개

2026년 03월 24일

1 온톨로지란 무엇인가

온톨로지(Ontology)는 특정 도메인의 개념(class), 관계(relation), 속성(property), 제약(axiom) 을 기계가 해석할 수 있는 형태로 정의한 지식 표현 모델이다 (Keet, 2020, Part 1).

원래 철학에서 “존재하는 것은 무엇인가”를 탐구하는 존재론(形而上學)이었으나, 정보과학에서는 도메인 지식을 형식적으로 명세하여 기계가 데이터의 의미(semantics) 를 이해하고 추론할 수 있게 하는 것을 뜻한다.

직관적 이해

온톨로지는 “이 세계에 어떤 종류의 것들이 존재하고, 그것들이 어떻게 연결되는가” 를 정의하는 설계도이다. 건축에서 도면이 건물의 구조를 정의하듯, 온톨로지는 데이터의 구조와 의미 를 정의한다. 도면 없이 건물을 짓는 것이 가능하지만 결과물이 임의적이 되듯, 온톨로지 없이 데이터베이스를 설계하면 도메인 의미가 유실되고 스키마가 임의적으로 된다.

1.1 지식 표현의 다섯 가지 역할

Brachman & Levesque (2004)는 지식 표현이 동시에 다섯 가지 역할을 수행해야 한다고 정의한다. 온톨로지는 이 다섯 역할을 모두 만족하는 형식 체계이다.

역할 설명 온톨로지에서의 구현
대리자 (Surrogate) 실세계 대상을 대신하는 기호 클래스·인스턴스 노드가 실제 개체를 대리
존재론적 약속 (Ontological Commitment) 세계를 어떤 범주로 나눌 것인가 클래스 계층이 도메인의 분류 체계를 정의
단편적 이론 (Fragmentary Theory) 세계의 일부를 불완전하게 표현 모든 지식을 포착하지 않고 선택적으로 모델링
효율적 계산의 매체 추론이 가능한 형태 기술 논리(Description Logic) 기반 자동 추론
인간 표현의 매체 사람이 이해하고 소통할 수 있는 형태 그래프 시각화, 자연어 레이블

이 중 “존재론적 약속”이 핵심이다. 어떤 범주를 정의하느냐에 따라 이후의 모든 쿼리와 추론의 범위가 결정되기 때문이다. 코드베이스를 예로 들면, Module, Function, Class, Config 라는 범주를 정의하는 순간 “이 도메인은 이런 종류의 것들로 구성되어 있다”고 약속하는 것이다.

2 온톨로지의 수준 체계

온톨로지는 추상화 수준에 따라 네 단계로 분류된다 (Keet, 2020, Part 1).

수준 설명 예시
상위 온톨로지 (Upper) 도메인 독립적 최상위 범주 Entity, Process, Relation, Quality
도메인 온톨로지 (Domain) 특정 분야의 개념 체계 의료: Disease, Symptom, Treatment
태스크 온톨로지 (Task) 특정 작업을 위한 개념 영향도 분석: ImpactAnalysis, DependencyTrace
응용 온톨로지 (Application) 특정 시스템 전용 CodebaseAnalyzerOntology
왜 수준을 나누는가

상위 온톨로지에서 정의한 범주(Entity, Process 등)를 도메인 온톨로지가 상속하고, 태스크 온톨로지가 이를 특화하는 구조이다. 이렇게 하면 서로 다른 도메인 온톨로지가 같은 상위 온톨로지를 공유하여 상호운용성(interoperability) 을 확보할 수 있다. 예를 들어 의료 온톨로지와 제약 온톨로지가 같은 상위 온톨로지의 Substance 클래스를 공유하면, 두 도메인 간 데이터 통합이 가능해진다.

3 온톨로지의 구성 요소

구성 요소 정의 형식적 표현 예시
클래스 (Class) 개념의 집합 \(C\) Disease, Module, Function
속성 (Property) 개념의 특징 \(a: C \rightarrow V\) name, file_path, severity
관계 (Relation) 개념 간 연결 \(R \subseteq C_1 \times C_2\) has_symptom, imports, calls
인스턴스 (Instance) 구체적 개체 \(i \in C\) 폐렴, auth_service.py
공리 (Axiom) 제약 조건 논리식 “모든 Function은 정확히 하나의 Module에 속한다”

3.1 관계의 속성

관계에는 수학적 속성이 부여될 수 있으며, 이것이 자동 추론의 기반이 된다.

속성 의미 예시
전이적 (Transitive) \(R(a,b) \wedge R(b,c) \rightarrow R(a,c)\) depends_on: A가 B에, B가 C에 의존하면 A는 C에 의존
대칭적 (Symmetric) \(R(a,b) \rightarrow R(b,a)\) co_changes_with: A와 B가 함께 변경되면 B와 A도 함께 변경
반사적 (Reflexive) \(R(a,a)\) is_compatible_with: 자기 자신과 호환
역관계 (Inverse) \(R(a,b) \leftrightarrow R^{-1}(b,a)\) imports ↔︎ imported_by

전이적 관계를 정의하면 명시적으로 저장하지 않은 간접 관계를 추론기가 자동으로 도출한다. 예를 들어 imports 를 전이적으로 정의하면, A→B→C 경로에서 A→C 의존성을 자동 추론한다 (Brachman & Levesque, 2004, Part 7).

4 온톨로지 vs 데이터 모델

온톨로지와 데이터 모델(DB 스키마)은 비슷해 보이지만 근본적인 차이가 있다 (Keet, 2020, Part 1).

항목 데이터 모델 (DB 스키마) 온톨로지
목적 데이터 저장 효율 지식 표현 & 추론
의미 암묵적 (개발자 머릿속) 명시적 (기계 해석 가능)
세계 가정 폐쇄 세계 (CWA) 개방 세계 (OWA, 기본)
추론 없음 내장 (분류, 일관성 검증)
진화 마이그레이션 필요 유연한 확장
표현력 테이블, FK, 제약 클래스 계층, 공리, 논리식
폐쇄 세계 vs 개방 세계: 왜 이것이 중요한가

폐쇄 세계 가정 (CWA): DB에 없으면 거짓이다. SELECT로 결과가 없으면 “해당 데이터는 존재하지 않는다.” 개방 세계 가정 (OWA): 알려지지 않은 것은 참일 수도 거짓일 수도 있다. 정보가 없으면 “아직 모른다.”

이 차이가 실무에서 중요한 이유: 코드 정적 분석에서 함수 A가 함수 B를 호출한다는 관계가 추출되지 않았을 때, CWA에서는 “A는 B를 호출하지 않는다”로 결론짓지만, OWA에서는 “A가 B를 호출하는지 아직 모른다 (리플렉션, 동적 호출 가능성)”로 남긴다. 어떤 가정을 채택하느냐에 따라 영향도 분석의 정확도가 달라진다 (Brachman & Levesque, 2004, Part 3).

핵심 구분: 잘 설계된 RDB 스키마 자체가 일종의 온톨로지 구현 이다. 그러나 RDB 스키마에는 추론 능력과 명시적 의미론이 없다. 온톨로지는 스키마 위에 “왜 이 구조인가” 라는 의미 레이어를 추가한 것이다.

5 설계 방법론

5.1 METHONTOLOGY (7단계)

온톨로지 공학에서 가장 널리 알려진 방법론이다 (Keet, 2020, Part 2).

단계 활동 산출물
명세 목적, 범위, 사용자 정의 범위 정의서
지식 획득 도메인 지식 수집 용어집, 전문가 인터뷰
개념화 핵심 개념/관계 식별 개념 모델 (그래프)
통합 기존 온톨로지 재사용 재사용 매핑
구현 형식 언어로 인코딩 OWL 파일 또는 Property Graph 스키마
평가 품질 검증 역량 질문 테스트 결과
문서화 온톨로지 문서 작성 스키마 문서, 사용 가이드

5.2 역량 질문 (Competency Questions)

온톨로지 설계의 출발점은 “이 온톨로지가 답할 수 있어야 하는 질문” 을 먼저 정의하는 것이다 (Keet, 2020, Part 2; Kejriwal et al., 2021, Part 2).

CQ1: 모듈 X를 변경하면 영향받는 모든 모듈은?
CQ2: 함수 f를 호출하는 모든 함수의 호출 체인은?
CQ3: 순환 의존성이 있는 모듈 그룹은?
CQ4: 설정값 C를 읽는 모든 함수는?
CQ5: 가장 많이 의존되는(critical) 모듈 Top 10은?

각 역량 질문이 온톨로지의 클래스/관계로 표현 가능한지 검증한다. CQ에 답할 수 없는 온톨로지는 설계가 불완전한 것이다.

역량 질문의 가치

역량 질문은 온톨로지의 요구사항 명세서 역할을 한다. 소프트웨어 개발에서 테스트 케이스를 먼저 작성하는 TDD(Test-Driven Development)와 같은 원리이다. “이 질문에 답할 수 있는가?”를 기준으로 설계를 검증하면, 불필요한 클래스는 줄이고 필요한 관계는 빠뜨리지 않게 된다.

5.3 설계 원칙

Kejriwal et al. (2021, Part 2)은 온톨로지 설계의 핵심 원칙을 다음과 같이 정리한다:

  • 명확한 범위 정의: 온톨로지가 답해야 할 질문(역량 질문)을 먼저 정의한다
  • 재사용: 기존 온톨로지(Schema.org, Dublin Core, DCAT 등)를 활용한다. 처음부터 만들지 않는다
  • 열거 vs 정의: 인스턴스를 나열하는 접근(bottom-up)과 클래스 특성으로 멤버십을 결정하는 접근(top-down)을 구분한다

6 설계 패턴 (Ontology Design Patterns)

재사용 가능한 온톨로지 설계의 모듈식 조각이다 (Keet, 2020, Part 3).

6.1 Part-Whole (부분-전체)

Repository --hasPart--> Module --hasPart--> Class --hasPart--> Method

전이성을 가진다: Repository가 Method를 간접적으로 포함한다. 코드, 문서, 조직 구조 등 계층 구조를 표현하는 데 광범위하게 사용된다.

6.2 Classification (분류)

CodeEntity
├── ExecutableEntity
│   ├── Function
│   ├── Method
│   └── Lambda
├── DeclarativeEntity
│   ├── Class
│   ├── Interface
│   └── TypeAlias
└── ConfigEntity
    ├── EnvironmentVariable
    ├── ConfigFile
    └── Secret

is-a 관계로 계층을 구성한다. 상위 클래스의 속성이 하위 클래스에 상속된다.

6.3 Participation (참여)

Function --participatesIn--> Process
(validate_token) --participatesIn--> (Authentication)
(encrypt_data) --participatesIn--> (DataProtection)

순수 구조적 관계를 넘어 의미적 맥락 을 추가한다. “이 함수가 어떤 비즈니스 프로세스에 참여하는가”를 표현하여, 구조만으로는 알 수 없는 도메인 지식을 포착한다.

6.4 N-ary Relation (N항 관계)

이항 관계로 표현하기 어려운 복합 관계를 중간 노드로 표현한다:

# "함수 A가 조건 C 하에서 함수 B를 호출한다"
CallEvent
  - caller: Function_A
  - callee: Function_B
  - condition: "if config.DEBUG"
  - frequency: "always" | "conditional"

6.5 Time-Indexed (시간 인덱스)

# "모듈 A가 시점 T에 모듈 B에 의존했다"
DependencyAtTime
  - source: Module_A
  - target: Module_B
  - valid_from: "2026-01-01"
  - valid_to: "2026-03-15"

코드 진화를 추적할 때 유용하다. Git 이력과 연동하여 시간별 의존성 변화를 분석할 수 있다.

7 지식 표현의 형식 체계

7.1 의미망 (Semantic Networks)

엔티티를 노드로, 관계를 엣지로 표현하는 가장 직관적인 형태이다 (Brachman & Levesque, 2004, Part 4).

[Module_A] --imports--> [Module_B]
[Function_X] --calls--> [Function_Y]
[Class_P] --is_a--> [AbstractBase]

관계 유형에는 is-a(상속, 전이적), part-of(구성, 전이적), has-a(소유, 비전이적), uses(사용, 비전이적) 등이 있다. 의미망의 핵심은 상속과 속성 전파 이다: UserController --inherits_from--> BaseController 관계가 있으면, BaseController의 모든 메서드가 UserController에 상속된다.

7.2 프레임 (Frames)

구조화된 지식 표현 단위이다. 슬롯(slot)에 값을 채우는 형태로, 노드의 풍부한 속성을 표현하는 데 적합하다 (Brachman & Levesque, 2004, Part 5).

Frame: Function
  Slots:
    - name: "validate_token"
    - module: "auth_service"
    - parameters: [(token, str), (secret, str)]
    - return_type: bool
    - calls: [decode_jwt, check_expiry]
    - called_by: [login, refresh_token]
    - complexity: 12
    - last_modified: "2026-03-15"

프레임은 디폴트 값을 지원한다. 예를 들어 PythonFunction의 기본 visibility는 public이지만, _internal_helper는 private으로 오버라이드한다. 현대의 Property Graph 모델(Neo4j)은 사실상 프레임의 구현이다. 노드에 임의의 속성(키-값)을 부여하는 구조가 프레임의 슬롯과 동일하다.

7.3 기술 논리 (Description Logic)

OWL(Web Ontology Language)의 수학적 기반이다. 온톨로지의 표현력과 추론 복잡도 사이의 트레이드오프 를 다룬다 (Brachman & Levesque, 2004, Part 6).

핵심 구성자:

구성자 의미 예시
\(\sqcap\) (intersection) AND PublicFunction \(\sqcap\) AsyncFunction
\(\sqcup\) (union) OR PythonModule \(\sqcup\) JavaScriptModule
\(\lnot\) (negation) NOT \(\lnot\) Deprecated
\(\exists R.C\) (existential) R로 C에 연결된 것 존재 \(\exists\) calls.ExternalAPI
\(\forall R.C\) (universal) R의 모든 대상이 C \(\forall\) imports.InternalModule
\(\leq n\ R\) (cardinality) R 관계 최대 n개 \(\leq 3\) has_parameter

표현력이 높을수록 추론이 느려진다:

DL 언어 표현력 추론 복잡도 대응 OWL
EL++ \(\sqcap\), \(\exists\) 만 PTIME OWL 2 EL
ALC 기본 (\(\sqcap\), \(\sqcup\), \(\lnot\), \(\exists\), \(\forall\)) EXPTIME OWL DL
SROIQ 전체 2NEXPTIME OWL 2 DL
실무 권장

대부분의 도메인 온톨로지는 EL++ 수준이면 충분 하다 (Keet, 2020, Part 4). 교차(\(\sqcap\))와 존재 양화(\(\exists\))만으로 구조적 관계를 표현할 수 있고, 추론 복잡도를 PTIME으로 유지할 수 있다. 부정(\(\lnot\))이나 전칭 양화(\(\forall\))가 필수적인 경우는 실무에서 드물다.

8 구현 기술

동일한 온톨로지를 여러 기술로 구현할 수 있다.

8.1 OWL/RDF (트리플 스토어)

온톨로지 구현의 가장 정통적인 방식이다. 주어-술어-목적어(Subject-Predicate-Object) 트리플로 지식을 표현한다.

(auth_service, depends_on, database_module)
(login_function, has_parameter, username:string)
(UserController, inherits_from, BaseController)
  • 장점: 추론 엔진 내장, W3C 표준, 스키마 유연
  • 단점: 쿼리 성능(SPARQL), 학습 비용, 생태계가 상대적으로 작음
  • 도구: Protégé(편집), Jena/RDFLib(처리), Stardog/GraphDB(저장)

8.2 Property Graph (Neo4j)

노드와 엣지에 속성(키-값)을 부여하는 그래프 모델이다 (Robinson et al., 2015).

CREATE (m:Module {name: 'auth_service', language: 'python', loc: 450})
CREATE (f:Function {name: 'validate_token', complexity: 12})
CREATE (m)-[:HAS_METHOD]->(f)
CREATE (f)-[:CALLS]->(:Function {name: 'decode_jwt'})
  • 장점: 쿼리 성능(Cypher), 속성이 풍부한 노드/엣지, 직관적 모델링
  • 단점: 추론 능력 없음(쿼리로 구현), 표준화 부족
  • 적합: 실시간 쿼리가 중요한 운영 환경

Robinson et al. (2015)이 강조하는 Property Graph의 세 가지 강점:

강점 설명
성능 연결된 데이터 쿼리 시 그래프 크기가 아닌 탐색 범위에 비례하는 실행 시간 (인덱스-프리 인접)
유연성 스키마 변경 없이 새 노드·관계 추가 가능
민첩성 화이트보드 스케치가 곧 데이터베이스 모델이 되어 개념-물리 모델 간 간극이 거의 없음

8.3 RDB (관계형 데이터베이스)

테이블, 컬럼, FK로 온톨로지를 구현한다. 자세한 비교는 온톨로지와 메타데이터 저장소 설계를 참조한다.

  • 장점: 인프라 보유, SQL 숙련도, DBA 지원
  • 단점: 추론 없음, 깊은 관계 탐색 시 JOIN 폭발, 스키마 변경 부담
  • 적합: 관계가 2~3단계로 명확하고, 기존 인프라를 활용해야 하는 경우

8.4 구현 기술 선택 기준

기준 OWL/RDF Property Graph RDB
추론 필요 최적 쿼리로 구현 앱 레벨로 구현
실시간 쿼리 성능 보통 최적 보통
기존 인프라 활용 낮음 낮음 최적
스키마 유연성 높음 높음 낮음
학습 비용 높음 중간 낮음
실무 권장 패턴

설계 단계에서 OWL로 스키마를 정의하고 추론기로 일관성을 검증한 후, 운영은 Property Graph(Neo4j)로 한다 (Keet, 2020, Part 4). OWL의 추론 능력은 스키마 검증에만 사용하고, 실시간 쿼리는 Cypher로 수행한다. 기존 인프라 활용이 필수인 환경에서는 RDB로 시작하고, 관계 탐색이 복잡해지는 시점에 GraphDB를 검토한다.

9 추론

온톨로지의 핵심 가치 중 하나는 명시적으로 저장하지 않은 사실을 자동으로 도출 하는 능력이다 (Brachman & Levesque, 2004, Part 7).

9.1 전방 추론 (Forward Chaining)

알려진 사실에서 출발하여 규칙을 적용하고 새로운 사실을 도출한다:

사실: imports(A, B), imports(B, C)
규칙: imports(x,y) ∧ imports(y,z) → depends_on(x,z)
추론: depends_on(A, C)  ← 새로 도출

CI/CD 파이프라인에서 그래프를 갱신할 때, 전방 추론으로 전이적 관계를 사전 계산한다.

9.2 후방 추론 (Backward Chaining)

목표에서 출발하여 필요한 사실을 역추적한다:

목표: "module_97이 module_3에 의존하는가?"
역추적: depends_on(97, 3)?
  ← imports(97, X) ∧ depends_on(X, 3)?
    ← imports(97, 50) ∧ depends_on(50, 3)?
      ← imports(50, 3) → 참!
경로: 97 → 50 → 3

사용자 질문에 대해 동적으로 경로를 탐색할 때 사용한다.

9.3 규칙 기반 추론

# 전이적 의존성
∀x,y,z: imports(x,y) ∧ imports(y,z) → depends_on(x,z)

# 변경 영향 전파
∀x,y: depends_on(x,y) ∧ changed(y) → potentially_affected(x)

# 순환 의존성 경고
∀x,y: depends_on(x,y) ∧ depends_on(y,x) → circular_dependency(x,y)

# 미사용 함수 탐지
∀f: function(f) ∧ ¬∃g: calls(g,f) → unused(f)

10 온톨로지 평가

온톨로지의 품질은 다음 차원으로 평가한다 (Keet, 2020, Part 5).

차원 기준 검증 방법
정확성 개념/관계가 실세계를 올바르게 반영 도메인 전문가 리뷰
완전성 역량 질문에 모두 답할 수 있음 CQ 기반 테스트
일관성 논리적 모순 없음 추론기(Reasoner)로 자동 검증
간결성 불필요한 중복 없음 중복 클래스/관계 탐지
확장성 새 개념 추가가 기존 구조를 깨지 않음 확장 시나리오 테스트
적응성 도메인 변화에 대응 가능 버전 관리, 모듈성 검토
평가의 핵심

완전성 과 일관성 이 가장 중요하다. 완전성은 역량 질문으로 검증하고, 일관성은 추론기가 자동으로 검증한다. 이 두 가지가 충족되지 않으면 나머지 차원은 의미가 없다.

11 온톨로지 유지보수와 진화

온톨로지는 정적 산출물이 아니라 도메인과 함께 진화한다 (Keet, 2020, Part 6).

11.1 변경 유형

변경 설명 위험도
인스턴스 변경 개별 엔티티 추가/삭제/수정 낮음 (자동화 가능)
스키마 변경 클래스/관계 추가/수정 중간 (하위 호환 주의)
의미 변경 기존 개념의 의미 재정의 높음 (전파 영향 큼)

11.2 버전 관리

v1.0: Module, Function, Class, imports, calls
v1.1: + ConfigValue, reads_config (설정 의존성 추가)
v1.2: + Repository, belongs_to (리포 단위 추적 추가)
v2.0: Function → SyncFunction/AsyncFunction 분화 (breaking change)
  • Minor 변경: 하위 호환 유지 (클래스/관계 추가)
  • Major 변경: 하위 호환 깨짐 (기존 클래스 분화/병합)

11.3 온톨로지 드리프트 방지

  • 정기적 역량 질문 검증 (온톨로지가 여전히 CQ에 답하는지)
  • 도메인 변화와 온톨로지 스키마의 정합성 모니터링
  • 사용되지 않는 클래스/관계 정리 (온톨로지 부채)

12 메타데이터 관리에서의 온톨로지

DAMA DMBOK (Ch.12)에서 메타데이터 관리는 조직의 데이터 자산에 대한 “데이터에 대한 데이터” 를 체계적으로 정의하고 관리하는 활동이다. 온톨로지는 이 메타데이터의 의미적 구조 를 정의하는 역할을 한다.

DMBOK 활동 온톨로지의 역할
메타데이터 전략 정의 도메인 개념과 관계의 범위 설정
메타데이터 아키텍처 클래스 계층과 관계 스키마 설계
데이터 리니지 추적 derives_from, transforms_to 관계 정의
영향 분석 depends_on 전이적 관계 기반 자동 추론

온톨로지와 메타데이터 저장소 설계의 구체적 사례는 다음 글에서 다룬다.

13 관련 주제

카테고리 내 연결

선행 지식

다른 카테고리 연결

14 참고 문헌

  • Keet, C.M. (2020). An Introduction to Ontology Engineering
  • Brachman, R. & Levesque, H. (2004/2022). Knowledge Representation and Reasoning
  • Kejriwal, M., Knoblock, C. & Szekely, P. (2021). Knowledge Graphs: Fundamentals, Techniques, and Applications
  • Robinson, I., Webber, J. & Eifrem, E. (2015). Graph Databases, 2nd Edition
  • DAMA International (2017). DAMA-DMBOK: Data Management Body of Knowledge, 2nd Edition

Subscribe

Enjoy this blog? Get notified of new posts by email: