TABLE 태그가 DIV 태그로 바뀌었다고해서 일단 당장 보이는 변화는 없다. 그도 그럴 것이 이전의 스킨 모습을 그대로 재현했으니 똑같아 보일 수 밖에. 스킨을 만든 사람이야 뭔가 변한 걸 알겠지만 보는 사람은 그게 변했는지도 모를 그런 작업이었다.

무엇이 변했는가를 살펴보기 위해 하나의 예를 들어보자.

디자이너 김양은 쇼핑몰 홈페이지를 만들고 있다. 의뢰인 홍씨와 이런 저런 대화를 나누고 나서 상품에 대해 다음과 같이 정리했다.


상품은 이름과 이미지, 분류 그리고 가격으로 구성된다.


디자이너 김양은 곧바로 디자인을 시작했다. 많은 정보를 효과적으로 보여주기에는 표가 좋을 것 같다고 생각했다. 그래서 TABLE 태그로 2행 2열의 표를 표현하고 각각의 열에 상품의 이름, 이미지, 분류, 가격을 배치했다. 일을 마친 김양은 느긋하게 담배 한 대 피우고 나서 홍씨에게 연락했다.

김양: 홍씨~ 다 했어, 돈 내놔~

의뢰인 홍씨는 완성된 웹페이지를 받고 다소 마음에 들지 않는 눈치이다.

홍씨: 음... 차라리 그냥 밑으로 쭈욱 나열되는게 더 좋겠구만. 좀 해줘.

디자이너 김양은 오는길에 담배 한 갑을 더 샀다. TABLE 태그를 싸그리 지우고 다시 작업을 시작한다. 이번엔 4행 1열의 표를 표현하고 각 행에 정보를 적어 내려간다. 디자인이 바뀔 때마다 매번 새 페이지를 만들어야하는 건 정말 짜증나는 일이라고 김양은 생각한다.

TABLE 태그는 디자인 요소를 포함한다. (2행 2열의 표 자체가 디자인이다) 웹페이지가 디자인 요소를 직접 포함하으로 웹페이지는 오직 하나의 뷰 view 를 갖는다. 하나의 뷰를 갖는다는 것은 언제나 그 웹페이지가 똑같은 모습으로 보인다는 것을 말한다. 그렇기 때문에 다른 뷰를 갖기 위해서는 웹페이지를 직접 수정해야 한다.

문제는 TABLE 태그가 디자인 요소를 포함한다는 데에 있다. 웹페이지가 컨텐츠와 디자인을 혼합하고 있기 때문에 디자인의 변경이 웹페이지의 직접적인 변경을 초래한다.



컨텐츠와 디자인의 분리

DIV 태그는 디자인 요소를 분리한다. 따라서 이 태그는 디자인 보다는 컨텐츠의 구성에 중점을 둔다. 위의 예에서 컨텐츠는 상품이며 상품은 이름과 이미지, 분류, 가격으로 구성된다. 따라서 상품을 나타내는 DIV 태그와 그 안에 각각의 정보를 포함하는 DIV 태그로 구성할 수 있다. 이 때 이것이 어떻게 보여지는가보다는 컨텐츠가 어떻게 구성되는가에 신경을 써야한다.

DIV-상품 = { DIV-이름, DIV-이미지, DIV-분류, DIV-가격 }

정보의 구성이 완료되면 이제 뷰를 생각할 차례이다. 뷰는 각각의 DIV 태그에 스타일시트 Style Sheet 를 적용한다. 2행 2열을 표현하기 위해 DIV-이름과 DIV-이미지에 float:left, float:right 등을 적용하여 위치를 조정한다. 스타일시트는 별도의 CSS 파일로 저장하고 웹페이지가 이 CSS 를 참조하도록 한다. 컨텐츠와 디자인의 분리는 다음과 같은 장점이 있다.
  • 디자인의 변경은 오직 CSS 에만 적용된다. 따라서 컨텐츠의 구성이 바뀌지 않는한 웹페이지를 직접 변경할 필요가 없다. 웹페이지 전체를 수정하지 않고 디자인 요소만을 수정하기 때문에 작업량은 훨씬 줄어든다. 위의 예에서 각각의 정보를 밑으로 나열하기 위해 CSS 에서 float:left 속성을 clear:both 로 변경하는 것으로 작업이 마무리된다.

  • 웹페이지가 다수의 뷰를 가질 수 있다. 참조하는 CSS 의 변경만으로 다른 뷰를 보여줄 수 있다. 현재의 웹 기술은 동적으로 CSS 를 변경할 수 있으므로 웹페이지가 열린 상태에서 간단한 조작을 통해 다른 디자인으로 변경할 수 있다.

  • 다수의 뷰를 제공하여 사용자에게 선택권을 부여할 수 있다. 하나의 절대적인 뷰를 제공하여 사용자를 강요하는 것이 아닌, 다수의 뷰를 제공하고 이들 중에서 사용자가 취향에 맞는 뷰를 선택하여 웹페이지를 볼 수 있게 할 수 있다. 이는 사용자 중심의, 사용자 요구에 반응하는 웹페이지를 가능하게 한다.

컨셉에 대한 명시적인 명세 - 온톨로지

웹페이지는 이제 디자인 요소를 포함하여 온갖 컨텐츠가 산재되어있던 지난 웹페이지와는 달리 체계적으로 컨텐츠를 조직하고 구성한다. 이 정보는 웹페이지를 통해 명시적으로 나타난다. 명시적이라는 말에 주목하자. 정보를 구성하고 명시적으로 뽑아내었다는 것은 어떤 의미를 갖는가?

명시적으로 정보의 구성을 뽑아내면 기계가 이것을 활용할 수 있다. 검색 엔진을 예로 들어보자. 현재의 검색 엔진은 간단한 텍스트 매칭의 결과를 출력한다. 이는 검색어가 어떤 의미를 갖는지, 질의 결과가 어떤 의미를 갖는지 확인할 방법이 없기 때문이다. 명시적인 정보의 구성을 활용하면 이러한 문제를 해결할 수 있다. '가장 싼 LCD를 판매하는 쇼핑몰 URL을 출력하라' 는 질의 query 가 가능해진다. 이에 검색 엔진은 '상품'을 포함하는 컨텐츠를 검색하고 그것이 포함하는 '종류'와 '가격'을 살핀다. 질의 결과로 얻은 '가격' 정보로부터 가장 낮은 가격을 찾아내어 해당 쇼핑몰의 URL을 결과로 반환할 것이다. 물론 이것은 웹페이지가 다음과 같이 정보를 구성되고 검색 엔진이 이것을 활용했을 때 가능해진다.

쇼핑몰 온톨로지
  • 쇼핑몰 = { 상품... }
  • 상품 = { 이름, 종류, 가격 }

컨셉에 대한 명시적인 명세, 이것을 온톨로지 ontology 라고 부른다. 온톨리지는 각각의 도메인 domain 에 맞게 별도로 제작되지만 명시적이기 때문에 서로 활용이 가능하다. 따라서 두 개의 다른 도메인에서 표현한 온톨로지를 잇는 새로운 온톨로지를 생성하는 것이 가능하다. 한국의 쇼핑몰 온톨로지와 미국의 쇼핑몰 온톨로지를 잇기 위해 '상품 is same as PRODUCT' 라는 새로운 온톨로지를 추가할 수 있다는 것이다.

검색 엔진에 추가된 온톨로지
  • 쇼핑몰 is same as SHOPPING-MALL
  • 상품 is same as PRODUCT
  • 상품.이름 is same as PRODUCT.NAME
  • ...

이제 검색 엔진은 외국 쇼핑몰의 검색 결과도 함께 보여줄 수 있을 것이다. 이것이 불가능하다고 생각하는가? 이미 이러한 작업은 진행 중이며 이것이 바로 시멘틱 웹 semantic web 이다.

온톨로지는 여러 용도로 활용될 수 있다. 검색 엔진 뿐만 아니라 기업의 엔터프라이즈급 소프트웨어의 통합에도 활용할 수 있다. 엔터프라이즈급 소프트웨어는 수 많은 서브 시스템을 통합한다. 이러한 서브 시스템은 기업의 내부 자료를 활용하여 새로운 정보를 생산하는데 각각의 서브 시스템은 별도로 개발되기 일쑤다. 따라서 일반적으로 서브 시스템은 독자적인 자료 구조를 유지하며 이것을 다른 서브 시스템과 연계하기 위해 point to point 방식으로 통합된다. 이러한 개발 과정은 새로운 서브 시스템의 통합을 늘 방해한다. 온톨로지는 공유되는 정보에 대한 명시적인 명세를 제공함과 동시에 그 의미를 부여할 수 있으므로 (예: is same as)  시스템 통합을 한결 수월하게 하며 유지 보수에 있어서도 탁월한 효과를 발휘한다.



마치며...

스킨 조금 수정했다고 이렇게 구구절절 나불거리는 내가 좀 우습기도 하다. 며칠이나 노가다를 뛰었더니 오기가 발동했나보다. 내가 한 작업은 의미 있는 작업이었어! 라고 말하고 싶었던 건지도 모른다.

온톨로지와 시멘틱 웹은 사실 오래전부터 이슈가 되어왔다. 하지만 그동안 인공 지능 분야에 선 학식있는 사람들 사이에서만 논의 되어 왔다. 기계가 이해할 수 있게 하라! 풀리지 않는 신비로운 문제들은 모두 인공 지능이라는 분야로 분류되고 소수에 의해 갈고 닦이지만 대부분의 사람들은 뻘짓이라고 생각하며 실제로도 많은 뻘짓이 이루어지고 있다. 추구하는 결과과 있고 그 결과에 모두가 동의하지만 늘 그것의 발끝에도 미치지 못하는 결과를 보이는 것이 인공 지능이라는 분야인 것 같다.

온톨로지와 시멘틱 웹은 오랜 기간 잠복해 있다가 이제야 슬슬 고개를 내밀고 있다. 아마도 많은 사람들이, 특히 인공 지능과 관계 없는 사람들이 이 문제에 대해 공감하기 시작했기 때문이 아닐까 생각한다.

하지만 아직 멀었다. 지금쯤이면 시멘틱 웹이 세상에 널리 퍼졌을거라 외친 어느 유명 인사의 주장도 현실이 되지 못했다. 보이지 않는 곳에서 여전히 노력 중이고 보이는 곳에서 결과를 나타내는 곳이 몇몇 존재하지만 일반인까지 감동시키기엔 아직 멀었다.

이제는 공감대 형성을 지나서 그것이 반드시 필요하다는 인식도 조금씩 생겨나고 있다. 아직은 멀었지만 이러한 분위기라면 온톨로지와 시멘틱 웹을 개발하는 사람들이 조금은 힘이 나지 않을까?
이 글의 트랙백 주소는 http://semix2.tistory.com/trackback/245 입니다
  1. 2006/11/10 22:18 댓글주소 수정/삭제 댓글쓰기

    앞으로 어떻게 될지는 모르지만 확실히 알아둬야 할것이긴 한거 같아요 시멘틱 웹..

    1. semix2 2006/11/11 00:13 댓글주소 수정/삭제

      확실히 알아둬서 나쁠건 없지. 근데 온톨로지 모델링이라는게 그리 만만한 일도 아니고, 그것을 어떻게 활용할 수 있는가에 대해서도 사실 뜬구름 이야기가 많아. 또한 레거시 시스템에 대한 호환성까지 고려하면 암담하기도 하지.

      시멘틱 웹이 제대로 운영되려면 기존의 웹이 그것을 지원하도록 수정해야하는데 그게 과연 얼마나 될런지. 쉽지 않은 일이지.

      연구실 화이트보드에 적어놓은 아티클이나 좀 읽어봐. 일단 긍정적인 이야기들을 쉽게 써 놓은 글들이니까.

  2. 붕탱구 2007/01/15 08:00 댓글주소 수정/삭제 댓글쓰기

    저도 스킨 좀 바꿔 볼라고 애를 많이 썼는뎅.. 그게 쉽지 않더라구요.나름 전공이 컴공이고, 군대에서는 홈페이지만드는거 하느라 좀 안다고 생각했는데..너무나 어렵고 힘들어서 사이드바 메뉴만 오른쪽에서 왼쪽으로 바꾸는 것 밖에 못했습니다. 스킨 바꾸는게 며칠은 걸리는 작업이군요..한 반나절쯤 하면 될라나 생각했는뎅.. 좋은 글 잘 읽고 갑니다. ^^:

    1. semix2 2007/01/15 14:11 댓글주소 수정/삭제

      네, 스킨은 손이 많이 가는 작업이더라구요. 하지만 처음 잘 만들어 놓으면 그 다음은 수월한 듯 합니다. 이 글을 쓴 이후로도 스킨을 조금씩 몇 번 고쳤는데 아무래도 디자인과 분리되어있다보니 훨씬 빠르게 끝나더라구요. CSS와 좀 더 친숙해져야 할 것 같습니다. 요즘은 자바 스크립트와 DHTML을 함께 써서 꽤 화려한 웹페이지도 가능하더라구요. ^^