온톨로지 다시 보기: 시맨틱 웹 유행 뒤에 남은 것

20년쯤 전, 처음 개발을 배우던 무렵 「온톨로지」라는 말을 들었습니다. 시맨틱 웹이 다음 웹이 된다던 때였고, 저는 그 말이 무슨 뜻인지 제대로 모른 채 지나갔습니다. 그 말을 최근 터미널 매뉴얼 하나를 고치다가 다시 만났습니다.

흔히 온톨로지를 시맨틱 웹과 함께 저문 거창한 기술로 기억합니다. OWL 과 RDF, 추론 엔진, 끝나지 않는 표준 문서 같은 것들입니다. 저도 그렇게 기억하고 있었습니다. 그런데 직접 작게 만들어 보니 핵심은 두 가지뿐이었습니다. 이름이 붙은 관계, 그리고 그 관계를 어긋나지 않게 지키는 규칙입니다. 그 핵심은 사라진 적이 없고, 지금도 검색 엔진 밑에서 돌고 있습니다.

「무엇이 있는가」를 묻던 철학의 이름

온톨로지는 원래 철학의 말입니다. 존재론, 즉 세상에 무엇이 있고 그것들이 어떤 종류로 나뉘는지를 묻는 분야입니다.

출발점으로 흔히 아리스토텔레스의 『범주론』을 꼽습니다. 그는 말로 가리킬 수 있는 것을 실체, 양, 질, 관계, 장소, 시간 같은 열 가지 범주로 나눴습니다. 3세기에 포르피리오스는 이것을 한 줄의 사다리로 세웠습니다. 실체에서 물체, 생물, 동물, 이성적 동물을 거쳐 사람에 이르고, 맨 끝에 소크라테스 같은 개인이 옵니다. 중세 논리학 교과서는 이 그림에 「포르피리오스의 나무」라는 이름을 붙였고, 19세기 말까지 논리학 시간에 가르쳤습니다(Porphyrian tree, Stanford Encyclopedia of Philosophy 의 주석).

ontologia 라는 낱말이 책에 처음 찍힌 것은 1606년입니다. 야코프 로르하르트가 낸 『Ogdoas Scholastica』의 속표지에 「Metaphysices, seu Ontologiae」라고 적혀 있습니다. 다만 본문에는 이 낱말이 거의 나오지 않아서, 1613년 고클레니우스가 철학 사전에 「philosophia de ente」(존재에 관한 철학)라고 풀어 적은 것을 첫 정의로 보는 견해도 있습니다(Jacob Lorhard). 400년 된 낱말이지만 「무엇이 처음인가」부터 출처마다 말이 갈립니다.

1993년, 공학이 빌려 간 정의

이 말을 컴퓨터 쪽으로 데려온 사람이 스탠퍼드의 AI 연구자 톰 그루버입니다. 1993년 논문에서 그는 온톨로지를 「개념화의 명시적 명세(an explicit specification of a conceptualization)」로 정의했습니다(A Translation Approach to Portable Ontology Specifications).

문제의식은 지식을 나눠 쓰는 일이었습니다. AI 시스템 둘이 지식을 주고받으려면 먼저 같은 낱말을 같은 뜻으로 써야 합니다. 그래서 클래스, 관계, 함수를 정의한 공통 어휘가 필요했습니다. 철학이 「무엇이 있는가」를 물었다면, 공학은 「무엇이 있다고 우리끼리 합의할까」를 물은 셈입니다. 저는 이 차이가 이 낱말의 역사에서 가장 중요한 갈림길이라고 봅니다. 공학의 온톨로지는 진리를 말하지 않습니다. 쓰려는 목적에 맞춘 약속일 뿐입니다.

2000년대 시맨틱 웹 붐과 조용한 퇴장

2001년 5월 Scientific American 표지에 팀 버너스리, 제임스 헨들러, 오라 라실라가 쓴 「The Semantic Web」이 실렸습니다(W3C 소식). 웹 페이지에 기계가 읽을 수 있는 뜻을 붙이면 소프트웨어 에이전트가 사람 대신 일을 처리한다는 그림이었습니다. 2004년 2월 W3C 는 RDF 와 OWL 을 권고안으로 냈고, W3C 는 OWL 을 「온톨로지라 부르는 용어 집합을 출판하고 공유하는 수단」이라고 소개했습니다(OWL Web Ontology Language Reference). 제가 그 말을 처음 들은 것도 이 무렵입니다.

그 뒤로 시맨틱 웹이라는 말은 점점 들리지 않게 됐습니다. 이유를 하나로 못 박기는 어렵고, 여기서부터는 제 판단입니다. 웹 전체에 뜻을 달자는 계획은 모델링에 드는 비용을 페이지를 쓰는 사람에게 떠넘겼습니다. 그 비용을 치르고 얻는 것이 당장 보이지 않았습니다. 표준은 정교했지만 그것을 읽고 고칠 수 있는 사람이 적었습니다.

이름을 바꿔 살아남은 쪽, 지식 그래프

2011년 6월 구글, 빙, 야후는 schema.org 를 함께 발표했습니다. 이벤트, 장소, 사람, 상품을 설명하는 공통 어휘입니다(Schema.org). 시맨틱 웹의 원대한 계획은 버리고, 검색 결과에 별점과 가격이 뜬다는 눈에 보이는 보상 하나만 남겼습니다. 이번에는 사람들이 썼습니다.

이듬해 5월 구글은 지식 그래프를 발표하며 「문자열이 아니라 사물(things, not strings)」이라고 했습니다. 「taj mahal」을 두 낱말이 아니라 기념물, 음악가, 카지노 중 하나로 알아보겠다는 것이었고, 발표 당시 5억 개가 넘는 대상과 35억 개가 넘는 사실과 관계를 담고 있었습니다(Introducing the Knowledge Graph). 온톨로지라는 말은 빠졌지만 하는 일은 같았습니다.

요즘 이 말을 다시 듣게 된 데는 Palantir 의 영향이 큽니다. Palantir 는 회사 데이터 위에 객체 타입, 링크 타입, 액션 타입을 얹는 층을 아예 Ontology 라고 부릅니다(Palantir 문서). 문서가 드는 예로는 「공항」이 객체 타입이고, JFK 와 LHR 은 그 타입의 객체입니다. 링크 타입은 두 객체 타입 사이의 관계를, 액션 타입은 객체를 어떻게 바꿀 수 있는지를 정합니다. 20년 전의 온톨로지가 「무엇이 무엇인가」에서 멈췄다면, 여기서는 「그래서 무엇을 할 수 있는가」까지 갑니다.

분류 체계와 갈리는 지점, 이름 붙은 관계

포르피리오스의 나무에는 선이 한 종류뿐입니다. 「~의 일종이다」. 폴더 트리도, 쇼핑몰의 카테고리도 같은 모양입니다. 이것을 분류 체계(taxonomy)라고 부릅니다.

온톨로지가 분류 체계와 갈리는 것은 선마다 이름이 붙는 순간입니다. 「df 는 inode 를 보여 준다」, 「duf 는 df 를 대신한다」, 「스왑을 이해하려면 가상 메모리를 먼저 알아야 한다」. 선에 이름이 있으면 질문을 그 이름으로 거꾸로 던질 수 있습니다. 「inode 를 보여 주는 명령은 무엇인가?」 같은 질문입니다. 노드와 선만 있고 선에 이름이 없으면 그건 그냥 그래프입니다.

나머지 하나는 규칙입니다. OWL 같은 형식 온톨로지는 규칙으로 추론까지 합니다. 적어 둔 사실에서 적지 않은 사실을 끌어내는 것입니다. 저는 처음부터 추론까지 갈 필요는 없다고 봅니다. 「없는 것을 가리키지 않는다」, 「바탕 관계가 돌지 않는다」 정도만 검사해도 데이터가 조금씩 어긋나는 것을 막을 수 있습니다.

터미널 매뉴얼에 붙여 본 작은 온톨로지

DUOLABS OS 는 브라우저 안에서 도는 데스크톱이고, 그 안에 터미널이 있습니다. 저는 이 터미널 안에 명령어 매뉴얼을 하나 만들었습니다. duf, df, du, uptime, xxd, vm_stat, dig, 일곱 장입니다. 페이지마다 실제로 찍은 출력을 싣고, 그 출력의 줄마다 주석을 달았습니다.

일곱 장을 쓰고 나서 「inode 를 보여 주는 명령은 무엇인가」에 답할 수 없다는 것을 알았습니다. 개념 설명이 페이지 안에 글자로만 들어 있었기 때문입니다. df 페이지가 말하는 inode 와 다른 페이지가 말하는 inode 가 같은 것인지 데이터는 몰랐습니다.

그래서 개념 13개를 페이지에서 꺼내 독립된 항목으로 만들었습니다. 페이지는 이제 개념을 id 로 가리킵니다. 개념마다 층을 하나씩 정했습니다. 비트, CPU, 메모리, 저장장치, 네트워크, 코어에서 멀어질수록 느려지는 순서입니다. 「먼저 알아야 하는 것」 관계는 정말 그것 없이 읽을 수 없는 경우에만 여섯 개 걸었습니다. 옮기기 전과 후에 화면에 그려지는 문구를 한 글자씩 대조했고, 13개 모두 같았습니다.

옮기고 나서야 보인 것이 있었습니다. df 페이지의 주석은 APFS 컨테이너와 가상 파일시스템을 길게 설명하고 있는데, 개념 연결은 duf 에만 걸려 있었습니다. 글자로 적혀 있을 때는 아무도 알아채지 못한 빈틈이었습니다. 지금은 두 페이지가 같은 개념 항목을 함께 가리킵니다. 반대로 inode 를 보여 주는 명령은 지금도 df 하나뿐입니다. du 는 블록 이야기만 하고 inode 를 다루지 않으니, 억지로 선을 긋지 않았습니다.

이렇게 바꾸고 나니 화면 셋이 같은 데이터를 읽게 됐습니다. 페이지, 지도, 그리고 낱말로 명령을 찾는 검색입니다. 검색은 이름과 설명에 더해 그 낱말이 걸리는 개념을 보여 주는 명령까지 찾습니다. inode 로 찾으면 df 가 나옵니다.

그래프를 그릴 때 정한 다섯 가지

처음 떠오른 것은 노드끼리 서로 밀어내며 자리를 찾는 힘 기반 그래프였습니다. 노드가 스물여섯 개만 돼도 실타래가 되고, 라이브러리가 하나 따라 들어오고, 폰에서는 쓸 수 없어서 버렸습니다. 대신 층을 띠로 쌓았습니다. 위가 네트워크, 아래가 비트입니다. 바닥이 토대인 모양 그대로입니다. 띠 안의 칩은 폭이 모자라면 다음 줄로 넘어가서, 폰에서는 저절로 세로로 접힙니다.

두 번째는 선을 손으로 긋지 않는 것입니다. 지도에 있는 선 33개는 전부 페이지 데이터에서 나옵니다. 「보여 준다」, 「대신한다」, 「관련」, 「바탕」, 네 종류이고 선의 모양이 종류마다 다릅니다. 페이지를 하나 더하면 지도가 따라 늘어납니다.

세 번째는 빈칸을 보이게 하는 것입니다. 페이지들이 「관련 명령」으로 이름만 가리키고 아직 쓰지 않은 명령이 여섯 개 있었습니다. top, file, hexdump, nslookup, host, curl 입니다. 이것들을 지우지 않고 흐린 점선 칩으로 세웠습니다. 그러면 다음에 무엇을 써야 하는지가 지도에서 보입니다. 제가 보기에 온톨로지의 가장 실용적인 쓸모가 이것입니다.

네 번째는 선을 다 진하게 그리지 않는 것입니다. 평소에는 옅게 두고, 노드를 고르면 그 노드에 닿는 선만 켭니다. 여기서 두 번 틀렸습니다. 흐려진 칩을 반투명하게 만들었더니 뒤의 선이 글자 위로 비쳤습니다. 선을 칩의 한가운데까지 그었더니 화살표 머리가 칩 밑에 숨었습니다. 지금은 칩 바탕을 불투명하게 두고 글자만 흐리며, 선은 칩 테두리에서 멈춥니다.

다섯 번째가 점검 스크립트입니다. 페이지가 없는 개념을 가리키지 않는지, 어느 명령도 가리키지 않는 고아 개념이 없는지, 「바탕」 관계가 돌지 않는지, 모든 노드가 층에 서 있는지를 봅니다. 앞에서 말한 「추론까지는 안 가는 규칙」이 바로 이것입니다.

같은 틀로 만들 수 있는 서비스

필요한 것은 타입이 있는 데이터 파일, 데이터에서 선을 끌어오는 함수, 점검 스크립트, 이렇게 세 가지였습니다. 그래프 데이터베이스도 OWL 도 쓰지 않았습니다. 이 틀로 만들 수 있는 것을 꼽아 보면 생각보다 많습니다.

분야	노드	이름 붙은 관계	거꾸로 던지는 질문
서비스 운영	서비스, 서버, 데이터베이스, 외부 API	올라가 있다, 거친다, 쓴다	이 서버가 멈추면 무엇이 같이 멈추나?
설계 지침	사고, 실패 유형, 원칙, 기법	드러냈다, 막는다, 구현한다	이 실패 유형을 막는 기법이 아직 없는가?
기술 블로그	개념, 글	다룬다, 먼저 알아야 한다	아직 글이 없는 개념은 무엇인가?
견적	기능, 비용 요인	필요로 한다, 늘린다	로그인을 넣으면 무엇이 따라오나?
제조 ERP	제품, 공정, 설비, 금형, 불량	거쳤다, 만들었다	이 불량은 어느 금형에서 나왔나?

저는 견적이 가장 재미있다고 봅니다. 발주하는 쪽은 「로그인 넣어 주세요」라고만 말하지만, 실제로는 회원 데이터, 비밀번호 재설정, 개인정보처리방침이 따라옵니다. 기능 사이의 「필요로 한다」 관계를 적어 두면 견적기가 빠진 것을 먼저 말해 줄 수 있습니다.

서비스 운영 쪽은 가장 실용적입니다. 어느 서비스가 어디를 거쳐 돌아가는지는 보통 문서에 산문으로 흩어져 있고, 사람들은 장애를 한 번 겪고 나서야 그 관계를 압니다. 관계를 데이터로 적어 두면 장애가 나기 전에 「이게 멈추면 같이 멈추는 것」 목록을 볼 수 있습니다.

20년 전에 들은 온톨로지는 웹 전체에 뜻을 달자는 이야기였습니다. 이번에 만든 것은 명령어 일곱 개와 개념 열세 개짜리입니다. 저는 이 크기가 맞다고 봅니다. 거꾸로 묻고 싶은 질문이 하나 생겼을 때, 그 질문에 답할 만큼만 관계에 이름을 붙이면 됩니다.