온톨로지 구축 방법: 질문에서 시작해 관계를 검증하기
자료에 ‘학습법’이라는 태그를 붙이는 일은 쉽다. 하지만 “어떤 학습법이 기억을 꺼내는 연습이고, 관련 글은 무엇인가?”라는 질문에 답하려면 태그만으로는 부족하다. 온톨로지는 다루는 대상의 종류, 관계, 의미와 규칙을 명시해 여러 사람이 같은 방식으로 데이터를 해석하도록 돕는 모델이다. 처음부터 방대한 개념 지도를 그리기보다, 실제로 답해야 할 질문 하나에서 시작하는 편이 관리하기 쉽다.
1. 먼저 답할 질문과 경계를 적는다
예를 들어 학습 자료 사이트라면 “인출 연습에 해당하는 방법은 무엇인가?”, “각 방법을 설명하는 글은 무엇인가?”, “비슷한 이름으로 불리는 방법은 같은 개념인가?”를 목표 질문으로 잡을 수 있다. 이런 질문을 온톨로지 설계에서는 흔히 역량 질문이라고 부른다. 질문이 있으면 필요한 개념만 만들 수 있고, 완성 후에도 답을 얻는지 시험할 수 있다.
처음 버전의 범위는 글, 학습법, 학습 목표 세 종류로 한정해 보자. 저자, 출판 이력, 모든 뇌 영역까지 한 번에 넣을 이유는 없다. 범위 밖 항목은 기록해 두되, 실제 질문이 생길 때 추가한다.
2. 이름보다 개념의 뜻과 관계를 먼저 고정한다
‘인출 연습’은 방법인가, 글의 제목인가? 둘을 구분하지 않으면 “글이 학습법의 하위 종류다” 같은 이상한 연결이 생긴다. 아래 표처럼 종류와 관계의 방향을 짧은 문장으로 적는다.
| 요소 | 정의와 예시 | 확인할 점 |
|---|---|---|
| 학습법 | 학습자가 수행하는 방법. 예: 인출 연습 | 글이나 도구와 같은 것으로 취급하지 않는다 |
| 글 | 방법을 설명하는 발행 자료. 예: 인출 연습 안내 글 | 한 글이 여러 방법을 설명할 수 있다 |
| 설명한다 | 글 → 학습법 | 관계의 시작과 끝을 고정한다 |
| 도움이 된다 | 학습법 → 학습 목표 | 주장을 뒷받침할 근거의 범위를 기록한다 |
‘관련 있다’라는 관계만 반복하면 무엇이 어떻게 연결되는지 알기 어렵다. 한편 관계를 지나치게 세분화하면 실제 데이터 입력이 어려워진다. 먼저 자주 묻는 질문에 필요한 관계 두세 개만 정의한다. 비슷한 말을 한 개념으로 합칠지, 서로 다른 개념으로 남길지도 예시와 반례로 합의한다.
3. 작은 데이터 세트로 모델을 시험한다
RDF의 기본 단위는 주어·술어·목적어로 이루어진 문장이다. 아래는 구현 예시를 읽기 쉽게 줄인 것이다. `brainia:`로 시작하는 식별자는 예시용이며 실제 서비스에서는 지속해서 사용할 수 있는 주소 체계를 정해야 한다.
| 주어 | 관계 | 목적어 |
|---|---|---|
| brainia:post8 | brainia:explains | brainia:retrievalPractice |
| brainia:retrievalPractice | brainia:supportsGoal | brainia:longTermRecall |
| brainia:post15 | brainia:explains | brainia:retrievalPractice |
첫 질문인 “인출 연습을 설명하는 글은?”에는 post8과 post15가 답이 된다. 그러나 “효과가 입증된 글은?”은 이 세 문장만으로 답할 수 없다. 효과의 근거 자료와 적용 대상을 따로 연결해야 한다. 이렇게 실제 질문을 다시 실행하면 빠진 관계와 과한 추론이 드러난다.
4. 필요한 표준만 선택한다
도구 이름부터 정할 필요는 없다. 목적에 따라 표준의 역할이 다르다.
- RDF: 대상을 식별하고 주어·술어·목적어 관계로 데이터를 표현한다. 관계를 교환하거나 연결할 때 기본이 된다. W3C RDF 1.1
- SKOS: 주제어 목록의 대표 이름, 다른 이름, 넓은·좁은 개념 관계를 정리할 때 유용하다. ‘시험 대비’와 ‘수험 공부’를 검색어로 연결하고 싶다면 검토할 수 있다. W3C SKOS 입문서
- OWL: 클래스와 속성에 더 정교한 의미를 부여하고, 명시하지 않은 관계를 추론해야 할 때 쓴다. OWL은 열린 세계 가정에 기반하므로 어떤 값이 없다는 사실만으로 그 값이 존재하지 않는다고 단정하지 않는다. W3C OWL 2 입문서
- SHACL: 실제 데이터가 정한 형태를 지키는지 검사한다. 예를 들어 모든 글에 제목이 있고 `explains` 관계의 목적어가 학습법인지 확인할 수 있다. OWL의 추론과 SHACL의 데이터 검사는 목적이 다르다. W3C SHACL 명세
작은 내부 용어집이라면 표와 명확한 정의만으로 시작할 수 있다. 서로 다른 시스템에서 관계를 공유해야 하면 RDF를, 동의어와 분류 체계를 관리해야 하면 SKOS를 고려한다. 추론이 정말 필요한 경우에 OWL을 추가하고, 입력 데이터의 누락과 형식 오류는 SHACL 같은 검증 규칙으로 다룬다.
5. 운영 규칙과 변경 절차를 만든다
온톨로지는 한 번 그린 뒤 보관하는 문서가 아니다. 새 개념을 추가할 때는 이름, 한 문장 정의, 포함·제외 예시, 기존 개념과의 관계, 담당 검토자를 기록한다. 이미 쓰는 식별자의 뜻을 바꾸면 기존 데이터가 달리 해석될 수 있으므로 변경 이력과 영향받는 질문도 남긴다.
품질 검사는 세 층으로 나눌 수 있다. 첫째, 문법과 필수값 같은 구조를 검사한다. 둘째, 역량 질문에 실제 데이터로 답할 수 있는지 시험한다. 셋째, 해당 분야를 아는 사람이 관계의 의미를 검토한다. 자동 검증이 통과해도 ‘도움이 된다’라는 주장 자체가 사실인지는 별도로 확인해야 한다.
작게 시작하는 체크리스트
- 이 모델로 답할 질문을 세 개 이내로 적었는가?
- 개념의 뜻과 관계의 방향을 예시와 반례로 설명할 수 있는가?
- 서로 다른 대상에 같은 이름을 붙이지 않았는가?
- 실제 데이터 몇 건으로 질문에 답해 보았는가?
- 추론 규칙과 데이터 검증 규칙을 구분했는가?
- 새 개념의 추가·변경·폐기 책임자를 정했는가?
결론: 연결의 의미를 시험할 수 있어야 한다
온톨로지의 가치는 개념 상자의 수가 아니라 같은 질문에 일관되게 답할 수 있는 데 있다. 먼저 질문 하나를 정하고, 세 종류의 대상과 몇 개의 관계만 정의해 보자. 작은 데이터로 답을 확인한 다음, 빠진 의미와 검증 규칙을 보강하면 된다.