이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

프로젝트의 특성상 한참을 프레임워크에 매달려오다가, 정말 최근에 들어서야 시선이 넓어지기 시작했다. 그동안 웹 2.0이니 뭐니 하는 그런 추세들을 모르는 척 한 건 아니지만, 뭔가 절실하고 구체적으로 그림이 그려질랑말랑하는, 그런 말랑말랑한 생각들이 이제야 들기 시작한 것이다. 말랑말랑, 어감이 좋은데?

그런고로, 생각을 정리하는 차원에서 3부에 걸쳐 이런 저런 이야기를 풀어볼까 한다. 어렵게 생각하면 어렵고, 쉽게 생각하면 쉬우니까 글이 길어도 부담 갖지 말고 그냥 쭈욱 읽어 내려가자. 혹시나 문서 끝까지 읽은 사람이 있으면 질문을 던져도 좋다. 피터지게 공부해서 답해줄 생각이다. (나도 잘 모르거든, 그래서 공부해야 답할 수 있다) 잘못된 부분에 대한 지적은 다소 부드러운 어조로 해줬으면 좋겠다. (나는 섬세하니까)

아주 오래전부터 온톨로지라는 영역이 연구되어왔다. 존재론 쯤으로 해석하면 이건 뭐 돈 많고 시간이 남아돌던 부르조아 시대까지 거슬러 올라가겠지만, 컴퓨터 영역으로 한정하면 그렇게까지 거슬러 올라갈 필요는 없을 듯 싶다. 1913년, Webster's Revised Unabridged Dictionary는 온톨로지를 다음과 같이 정의했다.

철학적으로 접근한 이러한 정의는 이후 knowledge engineering, natural-language processing과 같은 인공지능 분야에서 채용하였고 1990년 후반에 들어서면서 intelligent information integration, information retrieval on the Internet, knowledge management 등으로 그 영역이 확장되었다.

인공지능 분야에서 온톨로지는 지식의 공유와 재사용을 목적으로 만들어진다. 이 분야에서 온톨로지는 여러 사람에 의해 다양하게 정의되었는데, 특히 Gruber는 온톨로지를 다음과 같이 소개했다.


온톨로지는 공유되는 개념에 대한 형식적이고 명시적인 명세이다. 공유를 목적으로 하기 때문에 그것은 밖으로 도출(explicit)되어야 하고, 그것을 알아보려면 어떤 형식(formal)을 갖추어야 한다. 그러한 명세(specification)를 온톨로지라고 부른다. 다음은 간단한 온톨로지의 예이다.

온톨로지는 스키마와 인스턴스로 구분해서 생각해 볼 수 있다. 스키마는 위의 그림에서 동그라미로 정의된 어떤 '체계'를 정의한다. 인스턴스는 이렇게 정의된 체계 내에서 실제로 존재하는 '무엇'을 나타낸다. 위의 그림에서 네모로 그려진 [Peter]는 Peter라는 사람을 정의하고 있다. [Peter]는 단순한 데이터에 불과하다. 그러나 이것이 스키마와 결합되면 Peter는 'PhD-Student이고, Student이면서 Reseacher이고, Person이다'라는 정보를 추론할 수 있다. 단지 Peter에 대해 서술한 데이터로부터 (그 자체만으로는 고작 Peter의 나이나 주소 쯤 적혀있었을텐데) 스키마를 통해 명시적으로 서술하지 않은 정보를 얻어냈다. 이것을 추론(inference)이라고 한다.

그래, 그래서 어쩌라고?

좋은 질문이다. 수많은 어플리케이션은 자체적으로 데이터를 관리한다. 데이터베이스를 이용하든, 파일을 이용하든, 메모리를 이용하든, 어떤 방법으로 간에 그것들은 자체적으로 데이터를 관리한다. 문제는 어플리케이션들이 자체적으로 관리하는 데이터가 상호 호환성이 전혀 없다는 것이다. 엔터프라이즈 환경에서 규모가 꽤 큰 쇼핑몰 두 곳을 통합하려할 때, 상호간의 호환성이 전혀 없기에 개발자는 아주 미친듯이 둘 사이를 이어주려고 막코딩을 하거나 데이터베이스를 다시 설계해서 두 곳의 데이터를 통합하려 들 것이다. 어느 세월에...

만약 두 어플리케이션이 (사람)이라는 개념을 정의하고 그에 대한 인스턴스로 고객을 관리했다면 어떨까? 분명 A 쇼핑몰과 B 쇼핑몰은 (사람)이라는 개념을 다르게 표현할 수도 있다. 그래도 같은 개념을 정의한 것이므로 두 개념간의 관계를 정의하면 상호 데이터는 호환이 가능해진다. 예를 들어보자.


애초에 두 쇼핑몰이 잘 정의된 (사람)이라는 개념을 채용했다면 통합은 훨씬 수월했을 것이다. 그러나 그렇지 않은 경우라도 두 개념 사이를 잇는 스키마를 추가하는 것으로 데이터의 통합을 이룰 수 있다. 예를 하나 더 들어보자.


어째 고객을 대상으로하는 데이터를 예로 들다보니 'explicit'을 설명하기 꺼려진다. 'explicit' 하다는 것은, 데이터를 시스템 내부에 꽁꽁 숨겨두는 대신, 겉으로 드러내겠다는 것이다. 하지만 이것은 누구나 데이터를 열람할 수 있다는 것을 의미하지는 않는다. 다만, 열람 권한이 있는 대상이 이 데이터에 접근할 수 있고, 그 데이터를 해석할 수 있음을 뜻한다. 해석을 위해서는 서로 이해할 수 있는 잘 정의된 문법 체계를 갖추어야 하며, 그래서 온톨로지의 정의가 'formal'을 포함하는 것이다.

온톨로지를 정의하기 위한 formal한 방법은 여러가지가 있는데 대표적으로 RDF(http://www.w3.org/RDF)와 OWL(http://www.w3.org/2004/OWL)이 있다. 웹 2.0에 관심이 많은 사람이라면 RDF 정도는 들어봤을 듯 싶다. RSS 1.0 스펙이 RDF를 기반으로 작성됐으며, 내 블로그는 안타깝게도 RSS 2.0을 지원하므로 볼 수 없지만 네이버 블로그 같은 곳에 잘 찾아보면 RSS 1.0 버튼이 있을 것이다. 클릭해서 소스를 봐라. (블로그)라는 개념이 어떻게 정의되는지 한 번 보는 것도 그리 나쁘지 않을 것이다.


참고문헌: Jos de Bruijin, Using Ontologies, DERI