온톨로지 만들기, 개발자를 위한 7단계 설계 절차와 도구
온톨로지는 개념과 관계를 기계가 해석하도록 정의한 명세다. 스탠퍼드의 Ontology Development 101 7단계 절차와 W3C의 OWL 표준, Protégé 도구로 처음 만드는 법을 정리했다.
목차
온톨로지를 만든다는 건 어떤 분야의 개념과 그 개념들 사이의 관계를 기계가 해석할 수 있는 형식으로 정의하는 작업이다. 스탠퍼드의 나타샤 노이와 데버라 맥기니스가 쓴 Ontology Development 101은 이 과정을 도메인 범위 정하기부터 인스턴스 만들기까지 7단계로 정리한다. 2026년 7월 기준 W3C가 권고하는 표현 표준은 OWL 2이고, 이를 편집하는 대표 도구인 Protégé는 스탠퍼드 대학이 무료 오픈소스로 배포한다. 이 글은 시맨틱 웹이나 지식그래프를 처음 접하는 개발자가 작은 온톨로지 하나를 직접 설계해 보는 것을 기준으로 하며, 대규모 온톨로지 정렬이나 추론 성능 튜닝은 다루지 않는다.
온톨로지란 무엇이고 왜 만드나
온톨로지의 고전적 정의는 톰 그루버가 1993년에 제시한 “공유된 개념화에 대한 형식적이고 명시적인 명세”다. 말은 어렵지만 뜻은 단순하다. 어떤 분야에서 쓰는 용어와 그 용어들의 관계를, 사람이 아니라 프로그램이 읽고 따질 수 있게 못 박아 둔 사전이라고 보면 된다.
표현의 바탕은 RDF(Resource Description Framework, 자원을 URI로 지칭해 연결하는 그래프 데이터 모델)다. W3C가 표준으로 정한 이 모델은 모든 사실을 ‘주어-서술어-목적어’ 세 토막, 곧 트리플로 적는다. 이를테면 ‘이 글(주어)-작성자(서술어)-김데브(목적어)’ 하나가 트리플이다. 온톨로지는 여기에 클래스(개념 분류), 속성(관계), 인스턴스(실제 개체)를 정의해 의미를 얹는다.
관계형 데이터베이스 스키마와 헷갈리기 쉬운데, 차이는 추론이다. 스키마는 저장 구조만 규정하지만 온톨로지는 ‘작성자는 사람이다’, ‘사람은 조직이 아니다’ 같은 규칙을 명시해 기계가 적지 않은 사실을 끌어내거나 모순을 잡아내게 한다.
온톨로지는 언제 필요한가?
여러 시스템이 데이터를 공유하고 기계가 의미를 추론해야 할 때 필요하다. 앱 하나가 자기 내부 데이터만 다룬다면 관계형 스키마로 충분하고, 온톨로지는 오히려 과한 도구다.
판단 기준은 세 가지로 잡으면 된다. 서로 다른 출처의 데이터를 하나로 통합해야 하는가, 검색이나 질의에서 문자열 매칭을 넘어 의미 기반 연결이 필요한가, 명시하지 않은 사실을 규칙으로 추론해야 하는가. 하나라도 해당하면 온톨로지가 값을 한다.
실제 사례가 감을 잡는 데 도움이 된다. 검색엔진들이 함께 만든 어휘집 schema.org는 웹페이지에 ‘이건 상품, 이건 리뷰, 이건 저자’라는 의미를 붙여 검색 결과의 리치 스니펫을 만든다. 생명과학 쪽 Gene Ontology는 유전자 기능을 표준 용어로 정리해 전 세계 연구 데이터를 같은 언어로 묶는다. 둘 다 ‘여러 주체가 같은 의미 체계를 공유한다’는 온톨로지의 목적을 그대로 보여 준다.
온톨로지 만드는 7단계 절차
노이와 맥기니스가 제안하는 순서는 다음과 같다. 순서를 외우기보다 각 단계가 답하는 질문을 이해하는 편이 낫다.
- 1단계, 도메인과 범위 정하기: 무엇을 다루고 무엇을 뺄지 경계를 긋는다.
- 2단계, 기존 온톨로지 재사용 검토: 바닥부터 만들지 말고 schema.org, Dublin Core처럼 이미 있는 어휘를 먼저 찾는다.
- 3단계, 주요 용어 나열: 도메인에서 쓰는 명사와 동사를 일단 다 적는다.
- 4단계, 클래스와 계층 정의: 용어를 개념(클래스)으로 묶고 상위-하위 관계로 정리한다.
- 5단계, 클래스의 속성 정의: 클래스가 가지는 성질과 다른 클래스와의 관계를 붙인다.
- 6단계, 속성의 제약 정의: 값의 타입, 개수, 필수 여부 같은 조건을 건다.
- 7단계, 인스턴스 생성: 실제 개체를 클래스에 채워 넣는다.
이 절차에서 가장 실무적으로 쓸모 있는 도구가 역량 질문(competency question)이다. 완성된 온톨로지가 답할 수 있어야 하는 질문들을 미리 목록으로 적어 두는 것을 말한다. 블로그 온톨로지라면 ‘이 저자가 쓴 글은?’, ‘한 주제에 묶인 글 목록은?’ 같은 질문이 여기 해당한다. 이 목록이 범위를 정하는 리트머스지가 된다. 어떤 클래스나 속성이 이 질문에 답하는 데 안 쓰이면 범위 밖일 공산이 크다.
OWL과 Turtle로 스키마 표현하기
설계를 마쳤으면 표준 문법으로 적는다. W3C 표준은 RDF 위에 RDFS와 OWL이 층을 이루는 구조다. 셋의 역할이 자주 헷갈리므로 표로 정리한다.
| 표준 | 역할 | 표현하는 것 |
|---|---|---|
| RDF | 그래프 데이터 모델 | 주어-서술어-목적어 트리플 |
| RDFS | RDF에 기본 어휘 추가 | 클래스·속성 계층, domain·range |
| OWL | 논리 기반 표현 확장 | 클래스 배타·개수 제약·복합 관계 |
W3C 공식 문서 기준 현재 온톨로지 표준은 OWL 2이고, 직렬화 문법으로는 사람이 읽기 편한 Turtle을 많이 쓴다. 아래는 앞서 든 블로그 예시를 Turtle로 적은 조각이다. Post 클래스가 Article의 하위 클래스이고, writtenBy 속성이 Article을 Author에 잇는다는 뜻이다.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix ex: <http://example.org/blog#> .
ex:Author a owl:Class .
ex:Article a owl:Class .
ex:Post a owl:Class ;
rdfs:subClassOf ex:Article .
ex:writtenBy a owl:ObjectProperty ;
rdfs:domain ex:Article ;
rdfs:range ex:Author .여기서 a는 rdf:type의 약어로 ‘~는 ~의 인스턴스’라는 뜻이고, rdfs:subClassOf는 상위-하위 관계, owl:ObjectProperty는 개체와 개체를 잇는 속성이다. domain과 range는 그 속성이 어떤 클래스에서 시작해 어떤 클래스로 향하는지를 못 박는다. 표준 문법 정의는 W3C의 OWL 표준 페이지에 정리돼 있다.
어떤 도구로 만드나?
가장 널리 쓰는 편집기는 스탠퍼드 대학이 무료 오픈소스로 배포하는 Protégé다. 설치형 데스크톱 버전과 브라우저에서 협업 편집하는 WebProtégé 두 갈래가 있고, 둘 다 OWL 2를 지원한다.
Turtle을 손으로 적기 전에 Protégé를 먼저 권하는 이유는 추론기(reasoner) 때문이다. 클래스와 제약을 정의해 두면 추론기가 논리적 모순을 자동으로 찾아 준다. 이를테면 ‘사람’과 ‘조직’을 서로 배타로 선언해 놓고 한 개체를 둘 다로 지정하면 그 자리에서 오류를 띄운다. 손으로 관리하면 놓치기 쉬운 일관성 검사를 도구가 대신하는 셈이다.
완성된 온톨로지에서 데이터를 꺼낼 때는 W3C 표준 질의 언어인 SPARQL을 쓴다. 관계형 DB의 SQL에 해당하는 자리로, 그래프에서 원하는 패턴을 매칭해 결과를 뽑는다. Protégé 내려받기와 사용법은 스탠퍼드 Protégé 공식 사이트에서 확인할 수 있다.
브라우저에서 바로 그려 보기 — 마이크로소프트 온톨로지 플레이그라운드
글로만 익히기 답답하다면, 마이크로소프트가 2026년 공개한 오픈소스 웹앱 온톨로지 플레이그라운드(Ontology Playground)로 직접 그려 볼 수 있다. 설치 없이 브라우저에서 도는 정적 사이트(백엔드 없음)이고 MIT 라이선스로 공개돼 있으며, 라이브 데모는 microsoft.github.io/Ontology-Playground에서 바로 열린다. 온톨로지 학습과 마이크로소프트 Fabric IQ 입문을 함께 겨냥한 도구다.
핵심은 시각 디자이너다. 엔티티 타입에 속성을 붙이고 관계에 카디널리티를 지정하면 그래프 미리보기가 실시간으로 갱신되고, 50단계 실행 취소와 즉석 검증이 붙어 있다. 완성한 스키마는 RDF/XML·OWL로 내보낼 수 있는데, Fabric IQ가 기대하는 형식 그대로 왕복 변환(import·export)을 지원한다. 여기에 여섯 개 도메인(리테일·이커머스·의료·금융·제조·교육)의 예제 온톨로지 카탈로그, 아홉 개 강좌로 짜인 온톨로지 스쿨, 자연어 질문을 엔티티·관계로 매핑해 보여 주는 NL2Ontology 프리뷰가 더해진다. 코드와 이슈는 깃허브 저장소에서 볼 수 있다.
처음 만들 때 자주 하는 실수
범위를 안 정하고 시작하는 게 첫 번째 함정이다. 역량 질문 없이 용어부터 늘어놓으면 온톨로지가 끝없이 커지고, 어디까지가 이 프로젝트의 몫인지 흐려진다. 질문 목록을 먼저 고정하면 클래스 하나를 추가할 때마다 ‘이게 어떤 질문에 답하나’를 자문하게 된다.
두 번째는 이미 있는 어휘를 두고 새로 만드는 것이다. ‘저자’, ‘글’, ‘날짜’ 같은 개념은 schema.org나 Dublin Core에 이미 표준 용어가 있다. 남의 어휘를 재사용하면 다른 시스템과 데이터를 주고받을 때 번역 비용이 사라진다. 노이와 맥기니스도 2단계에서 재사용을 먼저 검토하라고 못 박는다.
세 번째는 클래스와 인스턴스를 헷갈리는 것이다. ‘블로그 글’은 클래스지만 ‘오늘 발행한 3번 글’은 인스턴스다. 이 경계가 무너지면 계층 구조가 뒤엉킨다. 헷갈릴 때는 ‘이걸 또 여러 개로 나눌 수 있나’를 물어 보면 된다. 나눌 수 있으면 클래스, 더는 못 나누는 낱개면 인스턴스에 가깝다.
