(원본포스트링크: 댓글과 트랙백은 여기로 부탁드립니다.)

"차세대 웹기술과 컨버전스"
수업의 첫 시간입니다.
첫 시간이라 수업 소개와 교수소개, 그리고 학생들 소개로 대부분의 시간이 갔군요.
하지만 서로를 잘 알 수 있게 된 유익한 시간이었던 것 같습니다.
그러면 남은 시간동안 간단하게 나마 웹을 이루고 있는 기본적인 기술요소에 대해 간략히 살펴 봅시다.
아주 기초적인 내용이니 웹 기술에 대해 좀 알고 있다 생각하는 분은 그냥 한번 훓어보시기만 해도 될겁니다.
(발표자료는 첨부파일을 참고)



Tim Berners-Lee라는 분께서 처음으로 웹을 만드셨죠. CERN의 물리학자들이 서로 정보를 공유할 수 있는 환경을 제공해 주기 위해 제안한 것이죠. 최초의 웹페이지를 보시면 격세지감을 느끼실지도... ^^ 팀버너스리가 처음 웹을 만들 때 세 가지 요소기술을 제안하였습니다.

사용자 삽입 이미지

1. URL (Uniform Resource Locator): Addressing
웹브라우저의 주소창에 쓰는 주소로 웹에서 문서나 자원의 위치를 지정하기 위한 주소 체계입니다. 처음에는 웹 문서를 지정하기 위해 사용되었지만 웹이 발전하면서 텍스트 문서 외에 다양한 멀티미디어 자원들을 가리키기 위해 사용되기 시작했고 최근에는 문서나 파일뿐 아니라 웹 서비스도 URL을 통해 접근합니다.  

2. HTML (HyperText Markup Language): Document
웹 문서를 만드는데 사용되는 마크업 언어입니다. 여기서 중요한 것은 "HyperText"라는 특징으로 링크를 따라 다른 문서로 이동할 수 있습니다. 현대는 웹이 너무나 일상화 되어 이러한 기능이 당연하게 느껴지겠지만 웹이 처음 만들어졌을 때는 그렇게 일반적인 기술은 아니었습니다. 웹 문서가 기본적으로 Hypermedia 방식을 채택함으로써 문서들은 링크를 통해 복잡하게 얽히고 설킨 웹페이지들의 네트워크를 형성했고 사람들은 이 네트워크의 바다에서 이 페이지 저 페이지 건너뛰면서 Hyper-reading을 하기 시작했습니다. 이러한 읽기방식의 변화는 현대 사회에 어떤 영향을 주고 있을까요? 사람들이 집중력을 유지하는 시간이 점점 짧아지고 있는 현상도 이것 때문일까요? 1시간만 머리 싸매고 고민하면 풀 수 있는 문제를 인터넷에서 해결책을 찾겠다고 몇 시간을 헤맨적은 없나요? 가끔씩 현재 보고 있는 웹싸이트를 왜 찾아왔는지 이유를 모를때가 있지 않나요? 여러분은 웹을 통해서 어떤 변화를 겪으셨나요? 그리고 이런 변화들이 어떻게 우리 사회와 문화에 영향을 끼치고 있을까요? 한번 머리 맞대고 논의해 볼 만한 주제입니다.    

3. HTTP (HyperText Tranfer Protocol): Communication
엔지니어가 아닌 이상 웹 기술에서 가장 익숙치 않은 부분이 아마도 HTTP가 아닌가 싶습니다. 이것은 브라우저와 웹서버가 대화하기 위해 정한 약속(프로토콜)입니다. 복잡한 내용은 다 버리고 딱 두가지 사실만 알아 두시면 됩니다.
1) HTTP는 철저히 Request-Response 방식의 통신입니다.
즉, 요청하기 전에는 서버쪽에서 절대로 아무 것도 보내주지 않는다는 것입니다. 이와 반대되는 방식은 Event-Driven 방식의 통신입니다. 온라인 주식거래에 많이 쓰이는 HTS 시스템이 대표적이죠. 주가정보는 사용자가 요청하지 않아도 매번 업데이트가 되어야 하잖아요? 주가 변경 이벤트가 발생하면 서버가 사용자 PC에게 자동으로 보내주는 것입니다. 만약 웹이 처음부터 이런 기능이 있었다면 많은 부분이 달라졌을겁니다. 새로운 뉴스가 있는지 알기 위해 굳이 뉴스싸이트를 방문할 필요가 없겠죠? 뭐라고요? 벌써 이렇게 쓰고 있다고요? 아, RSS를 얘기하시는거군요? 맞습니다. RSS가 똑같은 기능을 해 줍니다. 하지만 RSS의 동작원리를 자세히 살펴보면 저절로 새로운 뉴스가 오는게 아니란걸 알 수 있습니다. RSS 클라이언트가 주기적으로 서버에 새로운 뉴스가 있는지 물어보는 겁니다. 하지만 사용자 입장에서는 RSS 클라이언트의 그런 수고스런 노력을 알 필요가 없는 것이죠. RSS가 웹 2.0의 대표 기술의 하나로 인정받을 수 있었던 것도 바로 HTTP 통신 방식의 한계를 일정부분 극복했다는 점이 크게 작용한 것이죠.
2) HTTP는 상태를 저장하지 않습니다.
즉, 웹서버는 웹브라우저의 요청을 받고 처리를 해 주고 나면 그 사실을 까맣게 잊습니다. 다음번에 다시 요청하면 마치 처음 받는 요청인양 다시 처리해 줍니다. 예를들어 인터넷 서점에서 해리포터를 한권 주문하는 요청을 한 다음 장바구니를 확인하는 요청을 하면 텅비어 있는 것이죠. 기본적으로 웹은 이렇게 돌아가도록 설계되었습니다. 하지만 현재 인터넷 서점에선 장바구니가 비어있으면 망하는거죠. 이것은 "쿠키"라는 기술을 고안하면서 가능하게 된 것입니다. 웹서버가 기억을 못하니 응답 메세지에 자신이 기억해야 할 내용(쿠키)을 적어서 보내는 것이죠. 그러면 웹브라우저는 다음번 요청에 그 내용을 다시 실어서 웹서버에 보냅니다. 쿠키를 이용해 사용자는 한번 로그인 후에는 다시 로그인 하지 않아도 되고 장바구니도 유지되게 되는 것입니다.

HTTP가 이렇게 많은 제약을 가지게 된 것은 심플한 프로토콜을 지향했기 때문입니다. 몇 가지 편리한 기능을 버리는 대신에 오로지 문서를 요청하고 받는 기본에 충실한 것이죠. 그 덕분에 쉽게 구현이 가능했고 많이 쓰일 수 있게 되었죠. 새로운 기술을 만들 때 어느 정도까지 편이성을 제공해 줄 것이냐를 잘 고려해야 하겠죠. 그것이 바로 기술의 복잡도를 결정하게 되고 결국 기술이 쉽게 파급될 수 있느냐 마느냐를 결정합니다. 너무 많은 것을 끌어안으려다 사람들에게 외면 당한 기술들이 많죠~ 웹 2.0 기술이 각광 받는 것도 이해하기 그리 어렵지 않기 때문일 수도 있지 않을까요? ^^

지금까지 설명드린 웹을 구성하는 세가지 기술요소는 처음 제안했을 때부터 지금까지 크게 변하지 않고 사용되고 있습니다. (HTML은 예외적으로 많은 발전을 했습니다.) 팀버너스리경께서 처음부터 웹을 멋지게 잘 설계해서 그렇기도 하겠지만 더 중요한 요인은 이젠 바꾸기엔 웹이 너무 커져버렸다는 것입니다. 세 가지 요소에 약간만 변경을 해도 기존에 잘 돌아가고 있는 웹싸이트들과 웹브라우저 등이 모두 그 변경에 따라 수정이 되어야 됩니다. 웹이 분산구조이기 때문에 가지는 단점입니다. 기술의 진화속도가 늦죠. 하지만 HTML을 비롯한 컨텐츠 저작 기술이 빠른 속도로 계속 진화하고 있는 것은 컨텐츠와 서비스를 표현하는 부분이기 때문에 사용자와 시장의 니즈를 항상 만족시키기 위한 방향으로 발전하는 것이죠.

사용자 삽입 이미지

하지만 웹 기술은 느리긴 하지만 꾸준히 진화하고 있습니다. 그리고 그 진화는 세 가지 기술요소를 이용하여, 새로운 니즈를 충족시켜주는 방향으로 가고 있습니다. 이들이 웹 2.0 기술이라고도 불리고 차세대 웹기술이라고도 불리는 것들입니다. 여기에 대해서는 다음 시간에 자세히 다루도록 하고 오늘은 약간만 맛보기를 하겠습니다.

예전에 웹을 돌아다니다 보면 깨진 링크를 많이 보셨을 겁니다. "404 Not Found"라는 유쾌하지 않은 메세지가 자주 보였지요. 웹싸이트의 컨텐츠가 점점 증가하다보니 이들의 관리는 점점 힘들어지고 링크변경이라든지 컨텐츠 삭제 등으로 Missing link가 늘어나게 되었습니다. 그래서 블로그스피어를 중심으로 링크를 변하지 않게 고정되게 만들어보자는 움직임이 일었고 Permanent link, 즉 permalink가 생겨난 것이죠. 블로그 포스트 단위로 혹은 웹페이지 단위로 유일하고 변하지 않는 permalink를 가집니다. 이것은 URL 자체의 변화가 생긴 것도 아니고 기술이 추가된 것도 아니죠. 다만 URL을 이용하는 방식이 바뀐 것입니다. 이것이 웹을 어떻게 바꿨을까요? 잠시 생각해 보세요~ 블로그 포스트와 같은 개별 컨텐츠의 링크가 변하지 않는다는 것이 보장되니 외부에서 컨텐츠의 링크를 사용하는데 전혀 불안하지 않게 된 것입니다. 여기에 블로그 등을 통해 개별 컨텐츠의 제작과 관리가 용이해지면서 점점 개별 컨텐츠 단위의 정보 유통이 쉬워지게 되었죠. 다양한 소스에서 양질의 개별 컨텐츠를 모아 "컨텐츠 믹싱"하는 새로운 웹 2.0 서비스들이 이런 배경에서 탄생하고 있는 것입니다. 물론 RSS, Trackback 등과 같은 기술도 이런 흐름에 한몫을 했습니다. 자세한 얘기들은 다음 시간에 하기로 하죠.

본 수업은 각각의 주제에 대해 이와 같은 흐름으로 진행할 것입니다. permalink가 무엇이고 어떻게 사용하는지도 얘기하겠지만 왜 등장하게 되었는지, 어떤 기술적 변화가 있었는지, 그리고 이것이 다른 것들과 어떻게 결합하여 어떤 효과를 내는지 더 밀도있게 다룰 것입니다. 또한 서비스나 비즈니스가 어떻게 영향을 받는지 그리고 궁극적으로 사용자에게 어떤 가치를 주고 세상을 어떻게 바꾸는지 토의할 것입니다. 

사용자 삽입 이미지

자, 그럼 이제 마지막으로 웹을 움직이게 만들어 주는 인프라스트럭쳐에 대해 알아보겠습니다. URL, HTML, HTTP만 있다고 웹이 돌아가는게 아니죠~ ^^ 그들을 구현해서 서로 통신할 수 있도록 만들어 주어야 합니다. 여기에 필요한 것들이 위 슬라이드에 나와 있는 것들입니다. 웹브라우저는 Internet Explorer나 Firefox와 같은 소프트웨어를 말하고 웹 클라이언트는 PC부터 노트북, PDA, 휴대폰 등 웹브라우저가 실행될 수 있는 모든 단말을 말합니다. 반대편에는 웹페이지들을 저장하고 있는 웹서버가 있겠죠. 그리고 그 사이에 둘을 연결해 주는 인터넷이 있습니다. 이 정도까지는 대부분 아시는 얘기일테고, 좀 생소할 수 있는 것이 DNS와 Web Cache입니다. (시간 관계상 DNS만 설명하도록 하겠습니다.)

DNS는 Domain Name System의 약자로 도메인 네임을 관리해 주는 시스템입니다. 도메인 네임은 www.wikipedia.org와 같이 웹서버를 가리키는 주소입니다. 하지만 실제로 웹 클라이언트가 인터넷을 통해 웹서버에게 요청을 보낼 때는 IP 주소라는 숫자로 이루어진 주소를 사용합니다. (예. 203.212.189.253) 이 주소는 사람이 외우기 쉽지 않지요. 그래서 대신 도메인 네임을 사용하고 DNS가 그것을 IP 주소로 바꿔줍니다. 네임서버는 도메인 네임과 IP 주소 맵핑을 기록 및 관리합니다. 각 기관은 자신이 가지고 있는 도메인 네임에 대한 IP 주소 맵핑을 책임져야 합니다. 즉, 자신의 네임서버를 가지고 맵핑 관계를 기록하고 있어야 하는거죠. 이 때 다음과 같은 과정으로 도메인 네임에 해당하는 IP 주소를 알아냅니다. (www.wikipedia.org)

1. 루트 네임서버에 org 도메인을 관리하고 있는 네임서버 리스트를 요청합니다.
루트 네임서버는 최상위 도메인 (com, edu, org, kr 등)을 관리하는 네임서버들의 리스트를 관리하고 있습니다. 전 세계적으로 13대가 있습니다.
2. org 도메인 네임서버에게 org.wikipedia 도메인을 관리하는 네임서버의 리스트를 요청합니다.
최상위 도메인의 네임서버는 그 하위의 도메인 네임에 대한 네임서버들의 리스트를 가지고 있습니다.
3. org.wikipedia 도메인의 네임서버에게 org.wikipedia.www 도메인 네임에 대한 IP 주소를 요청합니다.
org.wikipedia 도메인의 네임서버는 하위의 모든 도메인 네임의 IP 주소 맵핑을 관리합니다.

오늘 강의 중에 가장~ 기술적인 내용이고 앞으로 8주 동안의 강의에서도 가장 기술적인 내용일 것입니다. (그러니 너무 좌절하지 마시길...) 제가 이렇게까지 기술적인 얘기를 하면서까지 DNS를 설명하는 이유는 한가지 꼭 말씀드리고 싶은게 있어서 입니다. DNS는 지금까지 인터넷을 구성하는 시스템 중에 가장 성공한 시스템 중 하나입니다. URL이 거의 모든 서비스의 공통 주소 체계로 사용되고 문제없이 돌아가는 것을 보면 아실겁니다. 자, 그럼 제가 질문 하나 하죠. DNS가 어떻게 성공할 수 있었던 것일까요?

도메인 네임을 IP 주소로 바꿔주는 일은 이렇게 복잡한 방법을 쓰지 않아도 할 수 있습니다. 어떻게? 네... 그냥 전 세계에 모든 도메인 네임-IP 주소 매핑을 몇 개의 서버가 관리를 하는 것이죠. 이것이 기술적으로 가장 쉬운 해결책입니다. 하지만 이렇게 되면 중앙집중형 방식으로 부하가 집중됩니다. 거기에 비해 DNS는 계층구조로 부하를 적절히 분산시킵니다. 그러나 제가 생각하기에 더 중요한 요인은 DNS를 이루는 네임서버들을 도메인 네임을 필요로하는 기관들이 직접 설치하고 운영하게 했다는 점입니다. 바로 분산과 권한이양입니다. 당연한 얘기같지만 DNS가 처음 등장했을 때는 중앙집중형이 더 일반적인 방법이었습니다. 만약 그렇게 했더라면 설치나 확장 등에 매우 큰 어려움이 있었을겁니다. 기관에게 자신의 도메인 네임-IP 주소 맵핑은 자신이 관리하도록 역할을 넘겨 줌으로써 각 기관의 자발적인 참여로 전체 DNS 시스템이 운영되도록 만든 것입니다. 어디서 많이 듣던 얘기 아닌가요? 네, 맞습니다. 웹 2.0에서 얘기하는 참여와 이를 통한 집단지성입니다. 웹 2.0이 등장하기 십수년 전부터 인터넷 기술들은 그러한 철학하에서 설계가 되어 왔던 것입니다. 인터넷 자체가 그렇게 만들어졌고 웹, 메일 등이 동일한 철학으로 운영됩니다. 차이라고 한다면 인터넷 시스템들이 각 기관의 자발적인(필요에의해) 참여를 통해 완성되었다면 웹 2.0은 개인들에 그 초첨이 맞추어져 있다는 것입니다. 여기서 우리는 한가지 교훈을 얻을 수 있습니다. 웹 2.0 하면 사용자를 참여시키는 방법에만 관심을 가지는데 그 관심을 약간만 돌려 서비스의 구조적인 부분에서 분산과 참여, 권한이양 등의 철학을 고민해 본다면 완전히 새로운 접근방법이 나올 수도 있습니다. 웹 2.0의 철학이나 접근방법을 똑같은 방식으로만 적용할 필요는 없습니다. 이미 세상이 웹 2.0 스럽게 돌아가고 있기 때문입니다.

자, 수업 듣느라고 수고 많으셨습니다. 다음 주부터는 본격적으로 웹 2.0을 포함한 차세대 기술과 문화, 서비스, 비즈니스에 대한 강의에 들어가겠습니다. 감사합니다.  
크리에이티브 커먼즈 라이센스
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 한재선