이 자료는 학교 정컴시간 발표때 이용한 발표 기본 자료입니다. 내용이 부족한 점 사과드립니다. 나의 추천 글입니다.
시맨틱 웹은 무엇으로 이루어져 있는가
팀 버너스 리는 시맨틱 웹을 제안하며 다음과 같은 구조도를 제시했다. 구조도가 2개인 이유는 2002년과 2005년에 발표한 내용이 다르기 때문이다. 우린 여기서 Ontology(존재론)가 OWL(Ontology Web Language)로 대체된 것을 알 수 있고, Proof의 범위가 조금 넓어졌으며 몇가지 새로운 개념이 들어오고 있는 걸을 알아챌 수 있다.


자. 이 구조도를 1층부터 자세히간단히 살펴보자. 1층은 시맨틱 웹의 기반을 나타내는데, 그것은 URI(Universal Resource Identifier;웹사이트의 일반 출처명)와 유니코드 인코딩이다. 이는 여러 인코딩 대신 하나의 인코딩에 거의 모든 언어를 통합함으로써 다국어 지원을 간편히 하려는 의도가 들어있다고 할 수 있다. 유니코드 인코딩 중 가장 널리 쓰이는 것으로는 UTF-8을 들 수 있다.
이제 2층을 보자. 2층은 시맨틱 웹을 구현하는 토대를 나타내는 듯한데, 먼저 시맨틱 웹을 이루는 언어는 XML이다. XHTML은 HTML을 XML로 표현한 것이고, 구조도에도 상당한 양을 차지하고 있는 RDF(Resource Description Framework, 자원 서술 얼개) 기술은 너무나도 확장이 무한하여 컴퓨터가 이해할 수 없을 지경인 XML에서 자원, 속성, 속성값을 묶어 하나의 단위로 취급하는 기술로 자원에 대한 좀 더 세밀한 설명과 관계파악을 쉽게 해주는 기술이다. 이 기술을 사용하면 컴퓨터도 XML 문서를 쉽게 이해할 수 있게 되고, 문서의 자동화 처리가 한결 쉬워진다.
RDF를 조금 더 자세히 보자. RDF 스키마는 ‘숨은 자료(예를 들어, 키워드)’의 무결성을 보증하기 위해 사용하는 메타언어다. 이는 자원과 특성의 집합을 네임스페이스로 표현한다. RDF는 자원, 속성, 속성 값을 묶어 하나의 단위로 취급하며, 의미, 구조, 구문에서 공통 규칙을 이용한다. 또한 RDF는 ‘문장’으로 표현되는데, 이는 Subject(주어), Predicate(서술어), Object(목적어)로 구성된다.
OIL(Ontology Inference Layer)은 RDF로 표현된 숨은 자료에서 필요한 정보를 추론하고 통합하기 위한 도구이며, 이는 DAML(DARPA Agent Markup Language)와 합쳐져 온톨로지를 구축하기 위한 확장 언어로 활용된다.
다시 2층으로 돌아오자. 네임스페이스는 각기 다른 XML문서 타입에 의해 정의된 요소들을 이용하여 다른 문서로 결합시킬 때 요소들(또는 특성들)을 구분할 수 있는 수단으로, 접두어로서 분리하여 하나의 문서에 같은 이름을 가진 요소 및 속성을 효과적으로 표시할 수 있으며 반드시 선언 후에만 사용이 가능하다. 대부분 루트 요소에 선언하고, 일반 요소에서도 선언할 수 있다. 출처
RDF에 관해선 이미 짧게 언급했으므로 그 위층의 OWL(Ontology Web Language; 존재론 웹 언어), 혹은 Ontology(존재론)에 대해 알아보도록 하자. Ontology, 즉 ‘존재론’은 기본적으로 어떤 낱말에 대한 뜻(개념)과 각 낱말 사이의 관계를 잘 설명한 것을 의미한다. 이는 어떠한 사람이 표현한 문장을 다른 사람도 잘 이해할 수 있기 위해서 필요한 것이기도 하다. 시맨틱 웹에서는 온톨로지를 ‘컴퓨터에서 사용하는 모든 개념, 낱말에 대한 뜻과 관계를 정의하는 일, 또 이에 필요한 기술’을 의미한다. 이러한 온톨로지가 잘 이루어지면 기계는 자동으로 일을 처리하기 쉽게 된다.
하지만, 이러한 온톨로지 기술을 구현하는 것은 결코 쉽지 않다. W3C에서도 2004년, 겨우 온톨로지용 언어인 OWL을 제정했을 정도이다. OWL은 DAML+OIL을 기반으로 하는 시맨틱 마크업언어다.
그 위에 있는 Rules는 또 무엇일까? Rules는 한 어플리케이션이 다른 어플리케이션, 다른 룰 엔진에서 공유, 합병, 재사용될 수 있는 규칙 방법을 의미한다. 현재 W3C에서는 RIF(Rule Interchange Format)을 제정한 상태다. 출처
옆에 넓게 퍼져있는 SparQL은 SPARQL Protocol and RDF Query Language의 약자로 아직 진행중인 연구이며, RDF에 대한 질의어들의 장점을 모아 만든 것이다. 출처 1 / 출처 2
Proof, Logic Framework은 자료를 처리하는 데 필요한 기술이다. 컴퓨터는 자료를 ‘논리 과정(Logic Framework)’을 통해 분석하며, 그 분석 과정은 ‘증명(Proof)’에 의해 얻어질 수 있다. Signature는 보안 기술에서 얻어온 기술로, 정보가 오고가는 것이 올바른 통신자끼리 할 수 있도록 하는 메커니즘이다. 코드를 남겨 작성자를 입증하는 방식으로 구현된다. 이 코드는 ‘암호화(encryption)’되어 만들어져 통신자끼리 서로 믿을 수 있는 환경을 만들어준다. 출처
이러한 시맨틱 웹의 목표는 최종적으로 무엇일까? 이 구조도는 시맨틱 웹의 최종 목표를 ‘Trust’, 즉 믿음으로 잡고 있다. 사용자가 믿을 수 있는 웹이 바로 시맨틱 웹의 목표다. 여기선 잠시 시맨틱 웹 카페의 설명을 빌려보자. “우리가 영화를 보기 전에 그 영화를 볼까말까 결정하는데 있어서 가장 큰 결정요인은 우리가 믿는 친구들 중 이미 그 영화를 본 친구들의 의견이다. 어떤 사건에 관한 뉴스와 분석을 찾을 때에 우리는 모든 뉴스를 보고 신문을 읽는 것이 아니라 우리가 평소에 가장 즐겨보고 읽는 몇가지 TV 채널과 신문, 웹사이트를 사용한다. 이와 같이 우리는 어떠한 정보를 원할 때 이 세상에 있는 모든 정보를 다 가져다 분석을 하는 것이 아니라, 우리 주위의 몇 명의 우리가 신뢰하는 사람들 또는 소스들을 본 후 그곳의 의견을 보고 결정을 하게 된다. 우리가 이렇게 신뢰하는 이러한 소스 또한 우리와 같은 방식으로 자기 스스로가 어떤 믿는 소스에서부터 정보를 얻게 된다. 이런 식으로 신뢰하는 소스가 신뢰하는 소스를 찾아가는 방법을 모색한다면 결국 이런 구조는 현재의 링크의 링크를 따라가는 웹의 형태를 띄게 된다. 이런 뜻에서 시맨틱 웹에서 사용하는 신뢰의 구조를 신뢰의 웹 (the Web of Trust)이라고 한다.”
시맨틱 웹은 구체적으로 어떻게 나타나는가
그렇다면, 이러한 개념을 바탕으로 시맨틱 웹은 현재 어떤 수준으로 나타나고 있을까? 사실 시맨틱 웹은 현재 ‘매우 저차원적인 응용’에만 그치고 있는 실정이다. 온톨로지에 대한 개념은 지금도 매우 초보적인 수준이라 ‘시맨틱 웹 전문가’인 전종홍님(블로그 ‘HOLLOBLOG’ 운영 중)마저도 이에 대해 ‘회의론’을 제기할 정도이다. 그렇다면, 현재 ‘온톨로지가 빠진 저차원적인’ 시맨틱 웹은 어디까지 구현되고 있을까?
1. RSS(Really Simple Syndication / RDF Site Summary)
자, 먼저 당신에게 하나 물어보고 싶은 것이 있다. 당신은 정보를 어떻게 얻는가? 신문? 뉴스? 인터넷 뉴스? 그런데, 혹시 그런 뉴스가 조금은 불편하지 않았는가? 뉴스라는 것은 사실 너무나도 방대하니 말이다. 게다가, 뉴스에서만 정보를 얻는 것은 솔직히 한계가 있다. 인터넷을 조금만 돌아다니면 수많은 사람들이 블로그에 그 뉴스에 대한 느낌, 심지어 나름대로 ‘칼럼’을 연재하는 사람들도 많은데, 그런 정보들은 희생하긴 너무 아깝지 않은가?
그리고 혹시 당신은 블로그를 운영하는가? 그런데, 독자들이 블로그에 찾아오는 것을 귀찮게 여긴다고 느낀 적은 없는가? 실로 그 수많은 블로그들을 일일이 찾아다니는 일은 쉬운 일이 아니다. 이런 것을 해결할 방법이 없을까? 나는 그런 사람들에게 주저 없이 RSS 기능을 추천한다. RSS는 RDF Site Summary(RSS 0.91, 1.0, 1.1) 혹은 Really Simple Syndication (RSS 0.92, 0.93, 2.0)의 약자이다. 전자의 경우는 RDF 진영에서 개발한 것이고, 후자의 경우는 반RDF진영에서 개발한 것이다(그래서 RSS는 판올림 순서와 버전 숫자가 일치하지 않는다. 게다가, RSS 내에서도 이렇게 다른 표준이 존재하는 것에서도 모자라, 정보 배포(syndication) 기술론 ATOM, OPML등 수많은 기술이 산재하고 있는 실정이다.). RSS는 XML을 이용하여 웹 사이트끼리 서로 자료를 주고받기 위한 규격이다. 실제로 RSS는 ‘최신 정보’를 요약하여 제공해주는 형태로 응용되고 있으며, RSS는 주로 블로그들이 독자들에게 쉽게 업데이트 정보를 알리거나, 메타 사이트 등에서 블로그의 최신 글을 ‘수집’할 때, 또한 뉴스, 게시판 등의 업데이트 정보를 알리는 데 이용되고 있으며, 최근엔 어떠한 검색 결과가 날이 지남에 따라 업데이트 될 때, 그것을 알려주는 데에도 이용되고 있을 정도로 그 사용은 ‘혁명적’이라고 할 수 있다.
물론 RSS에도 문제점이 있다. 기본적으로 RSS는 해당 사이트에서 지원을 해야 쓸 수 있다는 단점을 가지고 있고, RSS의 수집 시간이 너무 잦아질 경우 사이트의 서버에는 되레 과부하가 갈 수 있다는 것도 문제점이다. 전자의 경우는 해결책이 없지만, 후자의 경우는 해결책이 아주 없는 것은 아니다. 후자의 경우엔 피드버너와 같은 서비스를 이용하여 트래픽을 피드버너에게 ‘대신 떠넘길’ 수 있기도 하다(물론, 피드버너를 이런 기계적인 이유로만 쓰는 것은 아니다. 피드버너의 대표적인 기능 중 하나는 독자 분석 기능인데, 이는 독자가 사용하는 RSS 리더기의 종류, 브라우저, 그리고 독자 수 등을 파악할 수 있게 해준다. 실제로 본인의 블로그를 구독하는 사람 중 피드버너를 통한 RSS를 이용하는 사람은 평균 25~30명 정도로 나타나고 있다. 피드버너로 ‘굽기’ 전의 ‘오리지널 피드’를 사용하는 사람은 몇이나 될 지는 나도 알 수 없다.).
RSS의 또 하나의 문제점은 RSS를 이용할 때, 리더기를 바꾸면 그 주소들을 일일이 다시 등록해야 한다는 것인데, 이는 OPML을 이용하면 개선할 수 있다. OPML은 RSS를 그룹으로 묶어 분류하고 관리할 수 있도록 해주는 형식이다. 이는 파일 형식으로 저장 가능하며, 등록된 RSS 주소들을 OPML 파일로 내보내면 나중에 다시 등록할 때 손쉽게 RSS 주소를 ‘가져올 수’ 있다.
2. 꼬리표(태그, tag)
어떤 것을 분류하고 찾아낸다는 것은 예상 외로 어려운 일이다. 실제로 태그 이전, 우리는 ‘카테고리’를 정해 글을 분류해야 했다. 물론, 이는 ‘제로보드 스킨’과 같은 것을 분류할 때에는 상당히 효과적인 방법이다. ‘제로보드 스킨’의 경우엔 스킨이 ‘게시판’ 용 스킨이면 ‘게시판’ 분류에 넣으면 되었고, ‘외부로그인’ 창을 꾸민 스킨이면 ‘외부로그인’ 분류에 넣으면 되었다. 하지만, 우린 그런 것들로만 모든 것을 분류할 수 있는 건 아니었다. 예를 들어, 어떤 사진을 찍었는데, 그것이 ‘신혼여행’에서 ‘고양이’가 자고 있는데, 그 고양이의 이름이 (수많은 키우는 고양이 중에) ‘야미’였을 땐 어떻게 할까? ‘신혼여행’ 분류에 넣자니 고양이 사진을 찾는 것이 불편하고, ‘고양이’ 분류에 넣자니 ‘야미’의 사진을 찾는 것이 불편하고, 그렇다고 ‘야미’ 분류에 넣자니 ‘신혼여행’에서의 사진을 찾는 것이 불편해질 것이다. 그럴 때 우리는 어떻게 해야 할까? 다중카테고리? 다중카테고리도 좋은 방법이긴 하지만, 카테고리를 추가하는 것이 약간 번거롭다. 그렇다면?
이 때 우리가 쓸 수 있는 방법이 그 사진에 꼬리표(태그, tag)를 다는 것이다. 꼬리표는 간단히 글을 쓰면서, 밑의 ‘태그 넣기’ 등의 칸에 원하는 태그를 적는 것만으로 추가, 분류, 그리고 색인까지 가능하다.
3. AJAX
AJAX는 Asynchronous Javascript + XML의 줄임말로 ‘비동기 자바스크립트 XML’을 의미한다. AJAX는 어떠한 완벽한(PHP 같은 경우는 완벽한 한 언어의 형태로 나타난다) 기술을 의미하는 것은 아니다. AJAX는 여러 기술의 복합체로 XHTML + CSS의 표준 설계에, 동적 표시(DHTML), DOM을 이용한 상호작용, XML과 XSLT를 이용한 자료 교환/조종, XMLHttpRequest를 이용한 비동기 자료 검색(사용자가 자료를 보고 있는 사이에도 다음 자료를 미리 긁어온다), 그리고 이 모든 것을 정리해주는 자바스크립트 등이 섞여있는 기술이다. 이는 기술적으로는 웹 서버와 브라우저 사이에 AJAX 엔진이 끼어 들어가 자료를 ‘중개’해주는 형태로 나타난다.
그런데, AJAX 기술은 이미 대중적으로도 엄청난 인기를 얻고 있다. 왜일까? 왜 유용할까? 먼저 AJAX가 ‘비동기’를 내세운다는 것을 주목하면, AJAX는 비동기적으로 데이터를 불러오므로 페이지를 일일이 불러올 필요가 없다. 그래서 빠르다. 지메일을 보자. 지메일은 맨 처음에 ‘로드 중…’이라는 메시지를 꽤 오래 표시한다. 그건 첫 페이지에 보여줄 방대한 데이터를 미리 읽기 때문이다. 그 다음은? 다음 페이지는 첫 페이지를 보여준 후에 미리 읽어버려 상당히 빨리 로드 가능하다.
또한, JavaScript를 활용하기 때문에 동적인 모습을 보여줄 수 있다. 애니메이션을 주거나, 끌어 당기기 등의 모습을 보여줄 수도 있고, 아예 Google Maps와 같이 지도 자체를 HTML 페이지 상에서 보여줄 수도 있다. 게다가 프로토페이지나 iGoogle과 같이 페이지를 마음대로 재배치를 해도 괜찮다. 이미 로드는 다 끝난 상태니까.
게다가 AJAX는 표준 XHTML + CSS 기반이다. 따라서 ActiveX처럼 무언갈 설치할 필요도 없다. 또 플래시보다 빠르다. 그래서 AJAX는 빠른 속도로 웹계에 ‘번식’하고 있는 중이다.
하지만, AJAX는 단점도 하나 있다. 새로 고침이 무력화되어 무언가를 다시 보고 싶으면 페이지 맨 처음부터 봐야 할 때가 있다는 것이 바로 그것이다. 그리고 ‘어쩔 수 없이’ ActiveX를 쓴다고 주장하는 인터넷 뱅킹 사이트들의 보안 플러그인을 대체하기는 아직 모자라다.
정리하며
지금까지 시맨틱 웹에 대해 알아보았다. 물론 시맨틱 웹은 아직 걸음마 단계이며, 이 기술에 벌써부터 회의적인 반응을 보이는 사람이 많다. 구현하기 어렵고, 개념만 정착된 개념도 많으니까. 하지만, 시맨틱 웹은 구현하기 어려운 만큼 가치 있다. 자동화 처리의 매력은 역사적으로 수없이 느껴왔고, ‘신뢰’를 목표로 잡았다는 것 자체가 우리에겐 상당히 많은 것을 시사하고 있으니까.
이제, 우리도 시맨틱 웹을 준비할 때다.
언급되지 않은 자료 출처
『웹 2.0 시대의 기회 - 시맨틱 웹』 (김중태 지음)
Page 66(hyperlink), 74~76(web), 78~87(semantic web), 90~93(structure), 94~100(ontology), 108~111(RDF, OWL), 142~164(RSS), 172~193(Tag), 196~212(AJAX), 328~341(Web standards, Web accessibility)
What is AJAX (CN)
http://seeand.be/wp/article-57/what-is-ajax