그래서 온톨로지가 뭔데?

한 팀에서는 완료가 초안을 올렸다는 뜻이고, 다른 팀에서는 검토와 승인이 끝났다는 뜻이라고 해보겠습니다. 두 시스템이 이 기록을 합치면 같은 단어가 서로 다른 상태를 가리킵니다. 반대로 두 항목이 링크로 연결돼 있어도 그 연결이 작성했다인지, 참고했다인지, 대체했다인지 이름이 없으면 사람도 시스템도 본문을 다시 읽어야 합니다.

문제는 단어 수가 아닙니다. 무엇을 어떤 이름으로 부르고 서로 어떤 관계로 연결할지 분명히 정해야 합니다.

온톨로지는 특정 영역에서 어떤 종류의 대상이 있고, 그 대상의 속성·관계·제약이 무엇인지 명시해 사람과 시스템이 같은 뜻으로 해석하도록 만든 표현 체계입니다.

공통 단어 몇 개에 합의했다고 모두 온톨로지가 되는 것은 아닙니다. 용어 목록이나 분류만으로도 충분한 일이 있습니다. 온톨로지는 대상의 종류뿐 아니라 관계의 뜻과 적용 범위, 필요한 규칙까지 명시해야 할 때 등장합니다. 형식 언어로 구현하면 시스템이 그 의미를 바탕으로 일관성을 검사하거나 새로운 결론을 이끌 수도 있습니다.

1. 완성된 기록 한 건에서 시작해 봅시다

먼저 도서관 대출 카드 한 건을 보겠습니다.

자료 종류: 책
자료명: 별빛 지도
소장처: 중앙도서관
대출 상태: 대출 중
대출자: 김민지
대출자 유형: 성인 회원
적용 규칙: 대출 중인 책은 반납 대상이다

이 카드는 어려운 표기법 없이도 읽힙니다. 여러 카드가 같은 칸 이름을 같은 뜻으로 쓰면 “중앙도서관에 있는 책”, “현재 대출 중인 자료”, “김민지가 빌린 자료”를 같은 기준으로 찾을 수 있습니다.

이 카드 한 장에 온톨로지의 핵심 요소가 차례로 들어 있습니다.

1. 범주 또는 종류: 책, 회원처럼 비슷한 대상을 묶는 이름입니다. 정식 용어는 클래스(class)입니다.

2. 실제 항목 하나: 별빛 지도, 김민지처럼 현실의 구체적인 대상을 가리킵니다. 개체 또는 개별 대상(individual, instance)이라고 부릅니다.

3. 정보 칸: 자료명, 대출 상태, 대출자 유형처럼 한 대상의 값을 적는 칸입니다. 속성(property, attribute)입니다.

4. 이름 붙은 연결: 김민지가 별빛 지도를 빌렸다, 별빛 지도가 중앙도서관에 소장돼 있다처럼 두 대상을 잇는 뜻 있는 연결입니다. 관계(relation)입니다.

5. 규칙과 제약: 대출 중인 책은 반납 대상이다, 한 대출 기록에는 대출자가 한 명이어야 한다처럼 허용 범위나 의미를 정합니다. 형식 온톨로지에서는 공리 또는 제약(axiom, constraint)이라고 합니다.

6. 따라 나오는 결론: 별빛 지도는 책이고 현재 대출 중이므로 반납 대상이라고 결론 낼 수 있습니다. 이미 적힌 사실과 규칙에서 새 결론을 얻는 일을 추론(inference)이라고 합니다.

여기서 정보 칸과 관계는 비슷해 보여도 쓰임이 다릅니다. 대출 상태: 대출 중은 한 대상의 값이고, 김민지가 별빛 지도를 빌렸다는 두 대상을 잇는 연결입니다. 공리와 제약도 단순한 값이 아니라 어떤 문장이 성립하는지, 어떤 조합을 허용하거나 배제하는지 설명합니다.

한 가지 주의할 점도 있습니다. 카드에 훼손 여부가 적혀 있지 않다고 해서 “훼손되지 않았다”라고 자동 판단하면 안 됩니다. OWL 같은 형식 온톨로지는 흔히 열린 세계 가정(open-world assumption)을 따릅니다. 기록에 없는 사실은 거짓으로 확정된 것이 아니라 아직 모를 수 있다는 뜻입니다. 데이터베이스의 입력 검증처럼 빈칸을 곧바로 오류나 거짓으로 처리하려면 별도의 규칙과 검증 절차를 함께 설계해야 합니다.

2. 철학의 질문이 지식 표현의 도구가 되기까지

온톨로지라는 말은 컴퓨터보다 철학에서 먼저 쓰였습니다. Stanford Encyclopedia of Philosophy의 「Logic and Ontology」는 철학적 온톨로지를 우선 “무엇이 존재하는가”를 연구하는 분야로 설명하고, 존재하는 것들의 가장 일반적인 특징과 관계도 함께 묻는다고 정리합니다. 사람, 사건, 숫자, 속성, 관계 같은 것이 어떤 방식으로 존재한다고 볼 것인지가 철학의 질문입니다.

지식 표현과 인공지능 분야는 이 문제의식을 그대로 복제하지 않았습니다. 특정 업무 영역을 사람이 공유하고 컴퓨터가 처리할 수 있는 형태로 옮기는 데 초점을 맞췄습니다. Thomas R. Gruber는 1993년 Knowledge Acquisition 5권 2호에 실린 「A Translation Approach to Portable Ontology Specifications」에서 온톨로지를 “an explicit specification of a conceptualization”이라고 정의했습니다.

여기서 conceptualization은 구체적인 데이터 한 묶음이 아닙니다. 어떤 목적을 위해 세계를 추상화한 관점입니다. 도서관을 예로 들면 책, 회원, 대출을 중요한 대상으로 보고, 무엇이 무엇을 빌렸는지와 어떤 규칙이 적용되는지를 선택한 관점이 conceptualization입니다. 온톨로지는 그 관점을 클래스, 관계, 함수, 제약 같은 표현으로 명시한 것입니다. 실제 대출 카드 수천 건은 그 관점에 따라 기록된 데이터입니다.

따라서 두 전통은 연결돼 있지만 같지는 않습니다. 철학은 어떤 종류의 것이 존재하고 서로 어떻게 관계하는지 묻습니다. 계산 온톨로지 또는 지식 표현 온톨로지는 한 영역에서 사용할 개념, 관계, 제약을 명시해 공유·교환·추론할 수 있게 만듭니다.

W3C의 OWL 2 Primer도 OWL 2 온톨로지를 관심 영역에 관한 정밀한 서술문 집합으로 설명합니다. OWL 2는 클래스, 속성과 관계, 개별 대상, 공리를 표현하는 지식 표현 언어입니다. 선언된 의미를 바탕으로 추론기가 이미 적힌 문장들의 논리적 결과를 계산할 수 있습니다. 다만 모든 온톨로지가 OWL로 작성돼야 하는 것은 아닙니다. 이 글의 카드와 표는 개념을 이해하고 작은 구조를 설계하기 위한 경량 표현이며, 엄밀한 자동 추론이나 시스템 간 상호운용이 필요할 때 형식 언어의 가치가 커집니다.

3. 분류체계, 스키마, 데이터베이스, 지식 그래프와 무엇이 다를까

이 용어들은 실제 프로젝트에서 겹쳐 쓰입니다. 아래 표는 절대적인 표준 경계가 아니라, 어떤 문제를 먼저 해결하는지 살피기 위한 실무적 구분입니다.

Hogan 등은 2021년 지식 그래프 조사 논문에서 지식 그래프의 정의 자체가 하나로 합의되지 않았다고 지적한 뒤, 현실의 지식을 전달하려는 데이터 그래프로 넓게 정의합니다. 단순 사실은 노드와 간선으로 쌓을 수 있고, “모든 수도는 도시다” 같은 일반 규칙과 그에 따른 추론까지 담으려면 온톨로지나 규칙처럼 더 표현력 있는 구조가 필요하다고 설명합니다.

온톨로지와 지식 그래프는 서로 맞물리지만 같은 것은 아닙니다. 온톨로지는 데이터가 따라야 할 의미와 규칙을 먼저 정의할 수 있고, 지식 그래프는 실제 대상을 연결한 데이터에서 시작할 수 있습니다. 둘을 결합하면 별빛 지도 같은 실제 개체가 어떤 종류이며 누구와 어떤 관계에 있고 어떤 결론을 이끌 수 있는지 같은 문법으로 다룰 수 있습니다.

4. 온톨로지가 해결하는 일과 과한 경우

온톨로지가 특히 유용한 때는 여러 사람이 같은 말을 다르게 쓰거나, 서로 다른 자료를 합쳐야 하거나, 링크의 뜻을 기계가 구분해야 할 때입니다.

• 공유 의미: W3C가 설명하듯 용어와 관계의 뜻을 정밀하게 고정하면 사람 사이의 오해를 줄이고 소프트웨어가 같은 표현을 일관되게 처리할 기반이 생깁니다.

• 자료 통합: 한 시스템의 작성자와 다른 시스템의 저자가 같은 관계인지, 프로젝트가 작업 단위인지 계약 단위인지 명시하면 서로 다른 자료를 합칠 때 대응 관계를 검토할 수 있습니다.

• 검색: 이름 없는 링크 대신 작성했다, 참고했다, 대체했다를 구분하면 단순히 연결된 항목이 아니라 원하는 관계만 조회할 수 있습니다.

• 검증: 값의 허용 범위, 관계의 방향, 서로 함께 성립할 수 없는 조건을 명시하면 누락과 모순을 점검할 기준이 생깁니다. OWL의 일관성 검사와 데이터 입력의 필수값 검사는 같은 일이 아니므로 목적에 맞는 검증기를 따로 골라야 합니다.

• 추론: 대출 중인 책은 반납 대상이다와 별빛 지도는 대출 중이다에서 별빛 지도는 반납 대상이다를 얻는 것처럼, 선언된 사실과 규칙에서 새 결론을 계산할 수 있습니다.

반대로 한 사람이 관리하는 작은 목록이고, 필드 몇 개로 검색하면 충분하며, 다른 시스템과 뜻을 맞추거나 추론할 필요가 없다면 온톨로지는 과할 수 있습니다. 단순한 태그, 분류체계, 표 스키마, 데이터베이스 제약이 더 싸고 명확한 선택일 수 있습니다. 관계의 의미가 반복해서 흔들리거나 통합·검증·추론 요구가 생길 때 온톨로지를 도입해도 늦지 않습니다.

5. 질문에서 시작하는 여섯 단계

Noy와 McGuinness의 Ontology Development 101은 하나의 정답 방법론이 없다고 밝힙니다. 좋은 모델은 사용 목적과 예상 확장에 따라 달라지며, 첫 버전을 실제 문제에 써보고 고치는 반복 과정에서 만들어집니다. 특히 온톨로지가 답해야 할 질문을 competency questions로 적어 범위를 정하고, 나중에 그 질문에 답할 정보가 충분한지 시험하라고 제안합니다.

이를 초보자가 실행할 수 있는 여섯 단계로 옮기면 다음과 같습니다.

1단계. 반복해서 답해야 할 질문 하나를 씁니다

4주차에 어떤 사례글이 제출됐나?, 센서 입력이 어느 도구를 거쳐 최종 화면으로 나가는가?처럼 실제 조회 문장으로 씁니다. 분야 전체를 설명하려 하지 말고, 지금 구조가 답해야 할 질문의 범위를 정합니다.

2단계. 답의 근거가 될 자료와 실제 사례를 모읍니다

프로젝트 기록, 공식 문서, 작업 카드처럼 질문에 직접 관련된 자료를 작은 묶음으로 준비합니다. 각 용어와 관계가 어느 문장이나 기록에서 나왔는지 표시합니다. 자료에 없는 항목은 상식으로 메우지 않고 확인 필요로 남깁니다.

3단계. 반복되는 대상을 종류와 실제 항목으로 나눕니다

질문의 명사에서 후보를 찾되 모든 명사를 종류로 만들지는 않습니다. 여러 항목을 묶어 찾거나 같은 규칙을 적용할 필요가 있는 것은 종류로 두고, 별빛 지도 같은 구체적인 것은 실제 항목으로 둡니다.

4단계. 정보 칸, 이름 붙은 관계, 필요한 규칙을 정합니다

한 대상의 값은 정보 칸으로, 두 대상을 잇는 동사는 관계로 적습니다. 관계의 방향도 완전한 문장으로 읽어 봅니다. 질문에 답하거나 오류를 막는 데 필요한 제약만 추가하고, 아직 일어나지 않은 모든 예외를 미리 막으려 하지는 않습니다.

5단계. 승인된 구조를 실제 사례에 적용하고 근거를 붙입니다

몇 건의 실제 기록을 넣으면 같은 대상을 중복으로 만들었는지, 관계 방향이 뒤집혔는지, 필요한 칸이 빠졌는지 드러납니다. 각 사실은 원문, 공식 문서, 확인 기록처럼 다시 찾아갈 수 있는 근거와 연결합니다.

6단계. 처음 질문과 간단한 추론을 시험하고 사람이 승인합니다

처음 질문을 다시 던져 답과 근거가 함께 나오는지 확인합니다. 규칙을 넣었다면 예상한 결론이 나오고 모순이 생기지 않는지도 봅니다. 분야를 아는 사람이 용어의 뜻, 합칠 항목, 관계 방향, 제약을 승인한 뒤 다음 사례에서 발견된 누락만 고칩니다.

6. 크리에이티브 테크 도구 온톨로지는 이렇게 구성했습니다

크리에이티브 테크 도구 지도는 도구 이름을 많이 모으는 백과사전으로 시작하지 않았습니다. 이 글은 정본 운영 지도가 뒷받침하는 구성 요소와 원칙을 초보자가 따라가기 쉬운 질문 → 역할 종류 → 반복 관계 → 실제 도구 → 근거 → 점진적 확장 순서로 재구성했습니다.

질문

먼저 제작 과정에서 반복되는 질문을 골랐습니다.

• 어떤 입력이 어느 도구로 들어오는가?

• 무엇이 무엇을 제어하거나 변환하는가?

• 결과는 어디로 출력되는가?

• 어떤 공식 문서나 확인 기록이 이 연결을 뒷받침하는가?

역할 종류

질문에 답하기 위해 대상을 최소 작업 단위(object), 도구 내부 구조(system), 제작 흐름(workflow), 도구 사이 연결(bridge), 결과(output), 선택 기준(decision), 검증과 출처 관리(governance)로 나눴습니다. 이 구분은 모든 온톨로지의 보편 분류가 아니라 크리에이티브 테크 지도를 운영하기 위한 로컬 설계입니다.

반복 관계

프로젝트에서 반복되는 동사에는 다음 관계 이름을 붙였습니다.

• 안에서 실행된다: runsIn

• 입력받는다: inputsFrom

• 제어한다: controls

• 변환한다: convertsTo

• 출력한다: outputsTo

• 도구 사이를 잇는다: bridgesTo

• 자료로 검증된다: verifiedBy

실제 도구와 근거

정본 지도에는 다음과 같은 구현 예시가 들어 있습니다.

• .amxd 파일은 Ableton Live 안에서 실행됩니다. 관계는 runsIn입니다.

• OSC 컨트롤 표면은 TouchDesigner 파라미터를 제어합니다. 관계는 controls입니다.

• TDAbleton은 TouchDesigner와 Ableton을 연결합니다. 관계는 bridgesTo입니다.

• 공식 문서, coverage matrix, spot-check 같은 자료는 관계와 주장을 검증합니다. 관계는 verifiedBy입니다.

TouchDesigner와 Ableton Live가 관련 있다는 링크만 있을 때보다 무엇이 어디에서 실행되고, 무엇이 무엇을 제어하며, 어떤 자료로 확인했는지가 선명해집니다. 처음부터 전체 관계 목록을 모든 노트에 강제하지도 않았습니다. 실제 질문에 필요한 핵심 관계를 먼저 쓰고, 새 도구나 실패 사례가 요구할 때 근거와 함께 확장하는 방식입니다.

7. AI와 함께 내 분야의 첫 온톨로지를 만드는 법

AI에게 “내 분야 온톨로지를 만들어 줘”라고만 말하면 자료에 없는 분류와 관계까지 그럴듯하게 채울 수 있습니다. AI에게는 제공된 자료에서 후보와 근거를 정리하는 일만 맡깁니다. 최종 의미는 해당 분야를 아는 사람이 정해야 합니다.

외부 AI에 자료를 넣기 전에는 개인정보, 비공개 정보, 계정값, 내부 식별자를 제거합니다. 아래의 자료 수와 사례 수는 작은 실습을 위한 범위일 뿐 보편 표준이 아닙니다.

1. 질문 하나와 자료 몇 개를 준비합니다

크리에이티브 테크 사례라면 다음 질문으로 시작할 수 있습니다.

센서 입력이 어느 도구와 프로토콜을 거쳐 최종 화면으로 나가는가?

이 질문과 직접 관련된 제작 노트, 도구 설명, 작업 순서, 공식 문서 메모를 5개 안팎으로 고릅니다. 각 자료에는 제목이나 문단 번호처럼 다시 찾을 수 있는 위치 표시가 있어야 합니다.

2. 첫 대화에서는 후보와 근거만 요청합니다

나는 “센서 입력이 어느 도구와 프로토콜을 거쳐 최종 화면으로 나가는가?”라는 질문에 답할 수 있는 작은 온톨로지를 만들고 싶습니다.

아래에 실제 제작 노트 5개를 붙이겠습니다. 이 자료만 사용해 반복해서 등장하는 대상, 정보 칸, 관계, 규칙 후보를 찾아 주세요.

1. 대상 후보는 사람·도구·파일·프로토콜·출력처럼 이해하기 쉬운 이름으로 정리합니다.
2. 관계 후보는 “입력받는다”, “제어한다”, “변환한다”, “출력한다”, “자료로 검증된다”처럼 방향이 보이는 문장으로 적습니다.
3. 각 후보 옆에 근거가 된 자료명과 문장 또는 문단 위치를 표시합니다.
4. 자료에 없는 내용은 추측하지 말고 “확인 필요”로 남깁니다.
5. 아직 표준안으로 확정하지 말고 사람이 검토할 후보 목록만 만듭니다.

3. 분야를 아는 사람이 뜻을 승인합니다

AI가 뽑은 명사와 동사를 모두 채택하지 않습니다. 같은 뜻은 합치고, 모호한 이름은 고치고, 질문에 필요 없는 항목은 지웁니다. OSC 컨트롤 표면이 TouchDesigner 파라미터를 제어한다처럼 완전한 문장으로 읽어 관계의 방향을 확인합니다. 자료와 어긋나는 후보는 거절하고, 근거가 부족한 후보는 계속 확인 필요로 둡니다.

4. 실제 사례로 다시 질문합니다

승인된 구조를 실제 사례 3개 안팎에 적용합니다. AI에 처음 질문을 다시 묻고, 답의 각 부분이 어느 자료에서 나왔는지 표시하게 합니다. 답이 나오지 않으면 종류, 정보 칸, 관계, 규칙, 자료 가운데 무엇이 부족한지 나누어 확인합니다. 예상하지 않은 추론이 나오면 규칙의 범위와 방향부터 다시 봅니다.

질문 하나에 근거를 따라가며 답할 수 있고, 분야 담당자가 관계와 규칙을 승인했다면 첫 버전으로 충분합니다. 새 사례가 실제로 요구할 때만 다음 항목을 보탭니다.

마무리

온톨로지는 거대한 분류표의 다른 이름이 아닙니다. 같은 단어가 다른 뜻으로 쓰이고, 연결은 많지만 관계의 의미가 보이지 않으며, 여러 자료를 합쳐 검증하거나 추론해야 할 때 필요한 명시적인 의미 체계입니다.

처음부터 완벽한 클래스 계층이나 OWL 파일을 만들 필요는 없습니다. 실제 질문 하나를 고르고, 근거 자료와 사례를 모으고, 종류·정보 칸·관계·규칙을 작은 범위에서 명시합니다. AI는 후보와 근거를 정리하고, 분야를 아는 사람이 뜻을 승인합니다. 같은 질문을 다시 던져 답과 근거, 예상한 결론을 확인하면 자기 분야 온톨로지의 첫 버전을 만들 수 있습니다.

공개 참고 자료

• W3C, OWL 2 Web Ontology Language Primer (Second Edition): https://www.w3.org/TR/owl2-primer/

• Natalya F. Noy and Deborah L. McGuinness, Ontology Development 101: A Guide to Creating Your First Ontology: https://protege.stanford.edu/publications/ontology_development/ontology101.pdf

• Thomas R. Gruber, “A Translation Approach to Portable Ontology Specifications,” Knowledge Acquisition 5(2), 1993, pp. 199–220: https://tomgruber.org/writing/ontolingua-kaj-1993/

• Thomas Hofweber, “Logic and Ontology,” Stanford Encyclopedia of Philosophy, 2023 revision: https://plato.stanford.edu/entries/logic-ontology/

• Aidan Hogan et al., “Knowledge Graphs,” ACM Computing Surveys 54(4), 2021, arXiv version: https://arxiv.org/pdf/2003.02320