2006년 05월 31일
웹 문서의 집합적 처리
과연 마크업 언어(XHTML, RSS 등)가 자바나 플래시보다 나은 점이 무엇일까? 두 가지 모두 표준, 플랫폼 중립성, 벤더, 개발자수 등에서 큰 차이를 보이지 않는다. 굳이 차이점을 찾는다면 웹 쪽이 약간 저작이 쉬운 편이며 자바 쪽이 조금 더 자유도가 높은 편이다. 하지만 결국 사람들은 최종 결과물을 보게 마련이다. 만약 웹 vs 자바나 웹 vs 플래시로 특정 응용프로그램을 만들어서 시연한다고 해보자. 비슷한 수준의 능력을 가진 사람이 만들었다고 한다면 아마 백이면 백 자바나 플래시로 짠 응용프로그램이 낫다고 판단할 것이다.
하지만 인터넷에서 가장 널리 쓰이는 언어는 플래시나 자바가 아닌 마크업 언어들이다. 플래시나 자바는 대부분 마크업 언어의 플러그인 형식으로만 쓰이고 있다. 왜 그럴까? 가장 큰 이유는 집합적 처리에 있다. 집합적 처리란 한 개의 문서나 응용 프로그램이 아니라 수많은 문서나 응용프로그램에서 유용한 정보를 이끌어 내는 과정을 말한다. 검색이 대표적인 예로 전세계에 수십 억개가 넘는 문서 중 자기가 원하는 정보를 찾아내는 처리 과정이다. 검색 뿐만 아니라 RSS를 이용한 정보의 통합(Aggregation)도 아주 좋은 예이다.
왜 인터넷에서 집합적 처리가 중요할까? 답은 아주 간단하다. 인터넷의 크기가 매우 크기 때문이다. 인터넷의 크기는 인간이 처리할 수 있는 크기는 당연히 옛날에 넘었고, 왠만한 컴퓨터가 처리하기에도 이미 너무 크다. 10억개의 웹문서만 존재한다고 쳐도 각 페이지를 한번 방문하는데 걸리는 시간이 0.01초라고 한다면 무려 115일이 넘게 걸린다. 하지만 이미 웹 문서는 100억개 이상이라고 추측되고 있다. 이러한 엄청난 크기의 정보를 효율적으로 처리할 수 없다면 인터넷에서 효율적으로 사용될 수 없는 것이다.
집합적 처리에 적합한 언어는 구조적(Structural)인 특성과 빠른 처리 속도를 지녀야 한다. 구조적인 특성이란 컴퓨터가 알아들을 수 있는 형태를 말한다. 예를들어 XHTML문서에서 URL을 이용한 링크는 한글의 "이것, 저것"같은 대명사와는 달리 컴퓨터가 어느 문서를 가르키는지를 알아낼 수 있으며 RSS를 이용하면 웹 사이트에 어떤 내용들이 새로 올라왔는지를 컴퓨터가 판단할 수 있다. RDF나 OWL등을 사용할 경우 이것보다 훨씬 상세한 내용을 컴퓨터에게 알려줄 수가 있다. 하지만 문제는 빠른 처리 속도를 지녀야 한다는 것이다. 위에서도 말했듯이 인터넷의 크기는 엄청나게 크며 최소한 이의 상당부분을 대상으로 집합적 처리를 할 수 없다면 그 기술은 인터넷에서 성공하기 힘들다. 링크를 이용한 HTML이나 이름 그대로 아주 간단한 구조를 지닌 RSS가 성공한 이유는 바로 수억, 수십억개의 문서에서도 집합적인 처리를 할 수 있는 빠른 처리 속도를 지녔기 때문이다. 현재 Open API로 SOAP보다 REST가 더 많이 쓰이는 이유도 같은 이유라고 볼 수 있다.
하지만 빠른 처리 속도를 위해 단순화된 구조적인 특성은 분명 한계가 있다. 구글이 제 아무리 좋은 검색 기술을 이용해 결과를 만들어내도 아직은 많이 부족한 것이 현실이다. 거북이아찌님 말처럼 온 세상이 온톨로지로 뒤덮이는 날은 안올지도 모르지만 이를 이용한 조금 더 구조적인 메타데이터를 기존 사이트에 더하면 더 나은 결과를 만들어 낼 수 있음은 분명하다. 하지만 이러한 데이터를 추가함으로써 더해지는 처리 용량은 아직은 인터넷에 적용하기에는 너무 크다. 이러한 온톨로지를 저작하는 비용은 둘째 치고 이를 이용해 유용한 결과를 만들어내는 추론 과정 등은 아직은 수십만개의 문서에 적용하기에도 벅차다.
물론 단순히 처리 용량이 많다고 이를 배제하는 것은 적어도 그동안의 컴퓨터 발전의 역사를 본다면 바보짓이다. 1950년대~1960년대만 하더라도 많은 사람들이 C/C++같은 고수준 언어를 사용하는 것은 미친짓이라고들 했지만 얼마 안 있어서 가장 많이 쓰이는 언어가 되었다. Microsoft의 빌 게이츠가 "640킬로바이트 메모리면 일반 이용자들 에게 충분할 것이다"라고 한 것이나 IBM의 창업자인 톰 왓슨이 "전 세계에서 컴퓨터는 5대면 충분하다"라고 한 것도 유명한 일화이다.
따라서 향후의 웹 문서의 발전 방향을 현재의 처리 용량을 가지고 판단하는 것은 잘못된 것이다. 결국 웹 문서의 개수의 증가속도와 컴퓨터 처리 용량의 증가속도 중 어느 것이 더 빠르냐에 따라 달렸다고 볼 수 있다. 분명 웹 문서의 개수는 경이적인 속도로 빠르게 증가하였으며 따라서 컴퓨터가 처리하기에 가장 간단한 문서가 가장 널리 쓰이게 되었다. 그러나 앞으로도 이러하 추세가 이어질런지는 두고 봐야할 일이다. 빠른 시일 내(5년? 10년?)에 정보의 생산 속도보다 처리 용량이 빠르게 늘어날 것 같지는 않다. 아직 인터넷 사용자는 전세계 인구의 일부일 뿐이며 인터넷 사용자 수는 매우 빠르게 늘고 있다. 이들이 생산하는 정보의 양도 매우 빠르게 증가하고 있다. 아마 인터넷 사용자의 증가가 한계에 이를 때 큰 변화가 올 것이다. 여전히 정보의 생산은 인간의 몫이겠지만 처리 용량의 증가는 계속 18개월 마다 2배씩 혹은 더 빠르게 지속적으로 늘어날 것이기 때문이다. 남는 처리 용량이 있다면 이를 더 유익한 정보의 생산에 쏟아야만 한다.
덧1: 대세는 분명 위와 같지만 생각보다 XHTML은 더 구조적이면서도 빠른 처리를 할 수 있는 언어이다. 조금만 더 XHTML의 의도에 맞게 사용을 한다면 현재의 처리용량으로도 큰 변화를 가져올 수 있다.
덧2: 만약 마크업 언어와 프로그래밍 언어를 단순히 기능으로만 비교한다면 큰 오산이다. 큰 그림을 생각해야한다. (사실 이 부분은 다양한 기기에 웹을 적용하고자 할 때 처음 듣게 되는 질문이다. 지금 기기에 있는 프로그래밍 언어로도 필요한 기능을 다 제공할 수 있는데 왜 웹을 도입해야 하는지...)
하지만 인터넷에서 가장 널리 쓰이는 언어는 플래시나 자바가 아닌 마크업 언어들이다. 플래시나 자바는 대부분 마크업 언어의 플러그인 형식으로만 쓰이고 있다. 왜 그럴까? 가장 큰 이유는 집합적 처리에 있다. 집합적 처리란 한 개의 문서나 응용 프로그램이 아니라 수많은 문서나 응용프로그램에서 유용한 정보를 이끌어 내는 과정을 말한다. 검색이 대표적인 예로 전세계에 수십 억개가 넘는 문서 중 자기가 원하는 정보를 찾아내는 처리 과정이다. 검색 뿐만 아니라 RSS를 이용한 정보의 통합(Aggregation)도 아주 좋은 예이다.
왜 인터넷에서 집합적 처리가 중요할까? 답은 아주 간단하다. 인터넷의 크기가 매우 크기 때문이다. 인터넷의 크기는 인간이 처리할 수 있는 크기는 당연히 옛날에 넘었고, 왠만한 컴퓨터가 처리하기에도 이미 너무 크다. 10억개의 웹문서만 존재한다고 쳐도 각 페이지를 한번 방문하는데 걸리는 시간이 0.01초라고 한다면 무려 115일이 넘게 걸린다. 하지만 이미 웹 문서는 100억개 이상이라고 추측되고 있다. 이러한 엄청난 크기의 정보를 효율적으로 처리할 수 없다면 인터넷에서 효율적으로 사용될 수 없는 것이다.
집합적 처리에 적합한 언어는 구조적(Structural)인 특성과 빠른 처리 속도를 지녀야 한다. 구조적인 특성이란 컴퓨터가 알아들을 수 있는 형태를 말한다. 예를들어 XHTML문서에서 URL을 이용한 링크는 한글의 "이것, 저것"같은 대명사와는 달리 컴퓨터가 어느 문서를 가르키는지를 알아낼 수 있으며 RSS를 이용하면 웹 사이트에 어떤 내용들이 새로 올라왔는지를 컴퓨터가 판단할 수 있다. RDF나 OWL등을 사용할 경우 이것보다 훨씬 상세한 내용을 컴퓨터에게 알려줄 수가 있다. 하지만 문제는 빠른 처리 속도를 지녀야 한다는 것이다. 위에서도 말했듯이 인터넷의 크기는 엄청나게 크며 최소한 이의 상당부분을 대상으로 집합적 처리를 할 수 없다면 그 기술은 인터넷에서 성공하기 힘들다. 링크를 이용한 HTML이나 이름 그대로 아주 간단한 구조를 지닌 RSS가 성공한 이유는 바로 수억, 수십억개의 문서에서도 집합적인 처리를 할 수 있는 빠른 처리 속도를 지녔기 때문이다. 현재 Open API로 SOAP보다 REST가 더 많이 쓰이는 이유도 같은 이유라고 볼 수 있다.
하지만 빠른 처리 속도를 위해 단순화된 구조적인 특성은 분명 한계가 있다. 구글이 제 아무리 좋은 검색 기술을 이용해 결과를 만들어내도 아직은 많이 부족한 것이 현실이다. 거북이아찌님 말처럼 온 세상이 온톨로지로 뒤덮이는 날은 안올지도 모르지만 이를 이용한 조금 더 구조적인 메타데이터를 기존 사이트에 더하면 더 나은 결과를 만들어 낼 수 있음은 분명하다. 하지만 이러한 데이터를 추가함으로써 더해지는 처리 용량은 아직은 인터넷에 적용하기에는 너무 크다. 이러한 온톨로지를 저작하는 비용은 둘째 치고 이를 이용해 유용한 결과를 만들어내는 추론 과정 등은 아직은 수십만개의 문서에 적용하기에도 벅차다.
물론 단순히 처리 용량이 많다고 이를 배제하는 것은 적어도 그동안의 컴퓨터 발전의 역사를 본다면 바보짓이다. 1950년대~1960년대만 하더라도 많은 사람들이 C/C++같은 고수준 언어를 사용하는 것은 미친짓이라고들 했지만 얼마 안 있어서 가장 많이 쓰이는 언어가 되었다. Microsoft의 빌 게이츠가 "640킬로바이트 메모리면 일반 이용자들 에게 충분할 것이다"라고 한 것이나 IBM의 창업자인 톰 왓슨이 "전 세계에서 컴퓨터는 5대면 충분하다"라고 한 것도 유명한 일화이다.
따라서 향후의 웹 문서의 발전 방향을 현재의 처리 용량을 가지고 판단하는 것은 잘못된 것이다. 결국 웹 문서의 개수의 증가속도와 컴퓨터 처리 용량의 증가속도 중 어느 것이 더 빠르냐에 따라 달렸다고 볼 수 있다. 분명 웹 문서의 개수는 경이적인 속도로 빠르게 증가하였으며 따라서 컴퓨터가 처리하기에 가장 간단한 문서가 가장 널리 쓰이게 되었다. 그러나 앞으로도 이러하 추세가 이어질런지는 두고 봐야할 일이다. 빠른 시일 내(5년? 10년?)에 정보의 생산 속도보다 처리 용량이 빠르게 늘어날 것 같지는 않다. 아직 인터넷 사용자는 전세계 인구의 일부일 뿐이며 인터넷 사용자 수는 매우 빠르게 늘고 있다. 이들이 생산하는 정보의 양도 매우 빠르게 증가하고 있다. 아마 인터넷 사용자의 증가가 한계에 이를 때 큰 변화가 올 것이다. 여전히 정보의 생산은 인간의 몫이겠지만 처리 용량의 증가는 계속 18개월 마다 2배씩 혹은 더 빠르게 지속적으로 늘어날 것이기 때문이다. 남는 처리 용량이 있다면 이를 더 유익한 정보의 생산에 쏟아야만 한다.
덧1: 대세는 분명 위와 같지만 생각보다 XHTML은 더 구조적이면서도 빠른 처리를 할 수 있는 언어이다. 조금만 더 XHTML의 의도에 맞게 사용을 한다면 현재의 처리용량으로도 큰 변화를 가져올 수 있다.
덧2: 만약 마크업 언어와 프로그래밍 언어를 단순히 기능으로만 비교한다면 큰 오산이다. 큰 그림을 생각해야한다. (사실 이 부분은 다양한 기기에 웹을 적용하고자 할 때 처음 듣게 되는 질문이다. 지금 기기에 있는 프로그래밍 언어로도 필요한 기능을 다 제공할 수 있는데 왜 웹을 도입해야 하는지...)
# by | 2006/05/31 22:00 | 트랙백 | 덧글(0)
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]