1990년~ 2008년 세계 인터넷 사용자수[WorldBank]
웹에서 사용되는 언어인 HTML(HyperText Markup Language)의 기본 기능은 ‘(1) 스타일(예: 밑줄, 굵게)이 있는 문서+ (2) 문서간 링크’ 라고 생각하시면 큰 무리가 없을 것 같습니다. 그렇다면, 문서에 스타일이나 링크를 어떻게 저장하는 것일까요? 옷을 사면 옷에 태그(꼬리표, Tag)를 붙여서 태그에 옷의 크기, 가격 등을 따로 표시하는 것과 같이, HTML도 태그라는 방법을 통해 필요한 정보를 표시합니다. 아래 그림에서 <B>, <U>와 같이 텍스트에 따로 정보를 표시해준 부분을 태그라고 부릅니다. HTML은 미리 약속된 태그의 정보를 통해 스타일 및 링크를 표현합니다.
인터넷 익스플로러나 파이어 폭스와 같은 웹 브라우저를 통해 코드부분을 불러오면, 위의 그림과 같이 태그의 내용을 ‘해석(Interpret)’해서 보여줍니다. 기본적인 웹 브라우저의 기능은 인터넷에 있는 HTML 문서를 받아온 후 위의 그림과 같이 해석해서 보여주는 것입니다. 이러한 태그들의 사용 방법은 표준으로 미리 약속되어 있습니다. 예를 들면 <B>는 굵게, <U>는 밑줄 이런 식으로 미리 정해져 있는 것이지요. 어떤 사람이 <B>가 아니라 <BOLD>를 쓰고 싶더라도, 미리 약속된 표준들을 지키지 않으면 브라우저에서 이를 해석할 수 없게 됩니다. 국제기관에서는 이에 대해서 표준안(RFC: Request for Comments)을 만들었는데, HTML의 경우 RFC 1866이라는 문서를 통해 사용법을 명시하고 있습니다. [2] 표준이라고 말하면, 뭔가 대단해 보이지만, 사실 설명한 것과 같이 “<B>라고 하면 굵게 표시하기로 한다” 와 같은 정해진 약속이나, “어떻게 표시하면 문제 생길 수 있으니 웬만하면 하지 말 것(Recommendation)”, “이건 꼭 적어줘야 함(Mandatory)” 뭐 이런 내용들의 리스트랍니다. 사실, 태그 등은 표준에서 지원하지 않는 방법으로 작성 하더라도, 브라우저에서 지원한다면 기술적으로는 문제가 없습니다. 그러나, 편의성 측면에서는 문제가 생길 수 있습니다. 예를 들면 초창기의 브라우저들은 표준에 없는 태그들을 지원해서, 익스플로러에서 보이는 페이지가 넷스케이프 (파이어폭스의 전신입니다)에서 잘 안보이거나, 그 반대의 현상이 나타나기도 했습니다.
인터넷과 프로토콜
HTML은 텍스트(HyperText)를 태그(Tag)를 이용해서 정보(스타일, 링크 등)를 저장한 언어입니다. 그러나, 인터넷 상에서 HTML을 주고 받기 위해서는 정해진 규칙이 필요합니다. 프로토콜(Protocol)의 의미는 인터넷 상에서 미리 정해진 통신 규약을 의미하는데, 대단한 건 아니고, 미리 약속해 놓은 규칙입니다. 예를 들면, 철수라는 사람이 중국집 컴퓨터에 접속해서 “BBB”라고 보내면, 중국집에서는 “배고파”라고 해석하고, “볶음밥”이라는 응답을 보내기로 미리 규칙을 만들었다고 생각해봅시다, 이것도 일종의 프로토콜입니다. 프로토콜은 실제로 약속을 정하기 나름입니다. 표준을 만드는 사람들은 HTML 문서를 인터넷 상에서 주고 받는 방식에 대해서도 표준 규약을 만들었는데, 이를 HTTP(HyperText Transfer Protocol)라고 부릅니다. [3] 풀어 이야기하면 “정보가 들어간 텍스트(HyperText)를 전송하는 프로토콜(규칙)”이라는 뜻입니다. 웹 브라우저에 주소 창에서 자동으로 HTTP라고 붙게 되는 것을 많이들 보셨을 텐데요, 바로 그겁니다! :)
이 HTTP 프로토콜의 기본은 의외로 간단합니다. 내 컴퓨터를 클라이언트(Client)라고 부르고, 우리가 접속하는 컴퓨터(예를 들면 구글에서 서비스를 제공하는 컴퓨터)를 서버(Server)라고 부르겠습니다. HTML은 철저하게 다음과 같은 절차로 움직입니다. 주1)
(1) 클라이언트는 서버에게 HTML 페이지를 달라고 요청합니다. (용어로는 Request라고 합니다.)
(2) 서버는 클라이언트에 HTML 페이지를 넘겨줍니다. (용어로는 Response라고 합니다)
클라이언트는 무조건 능동적으로 요청하고, 서버는 무조건 수동적으로 1회 응답하는 것이 두 컴퓨터의 역할입니다. 메시지를 서로 주고 받는 것은 우리가 메신저나 카카오톡 같은 곳에서 메시지를 주고 받는 것으로 생각하면 무난합니다. (서버는 절대 먼저 나에게 말을 걸지 않습니다. 내가 말하면 대꾸할 뿐입니다! 그것도 말 걸 때마다 딱 한번씩만 대꾸합니다) 아래는 전송되는 메시지의 예입니다.
좀 더 쉽게 해석하면 아래와 같은 말이지요
클라이언트는 필요한 페이지나 이미지 등이 있을 때마다, 위와 같은 방법으로 매번 일일이 서버에게 요청합니다. 다음은 실제로 메시지를 주고 받는 것을 캡춰한 것입니다. 주2)
위의 예는 텍스트를 통해 서버와 클라이언트 간의 Request와 Response 메시지의 전송을 보여주고 있습니다. 이러한 Request/Response 방식의 전송 방식은 단순하기 때문에, 본래의 목적인 문서를 전송하는 데에 최적화 되어 있습니다. 즉, 다시 말하면 HTTP가 제공할 수 있는 서비스의 한계는 분명합니다. 왜냐하면 서버는 무조건 클라이언트의 요청에 수동적으로 응답해야 하기 때문입니다. 서버는 클라이언트로 데이터를 직접 전송해 줄 수 없습니다. 예를 들어 웹으로 체스 게임 서비스를 만든다고 생각해보겠습니다.
(1) 사람1이 말을 움직여 움직인 위치를 서버로 보냅니다. (사람1 --> 서버)
(2) 서버는 사람1에게 잘 옮겼다고 응답합니다.
(3) 그러나 사람2는 내 차례가 진행되었는지 아닌지를 알 수 없습니다. 왜냐하면, 서버는 클라이언트로 직접 내용을 보낼 수 없기 때문입니다. (말씀 드렸듯이 HTTP에서 서버는 클라이언트의 요청에 대해서만 수동적으로 대답합니다)
이러한 명확한 한계는 웹을 통해 다양한 서비스(증권, 게임 등등)와 요구사항을 제공해야 하는, 현대의 웹 환경에서 액티브엑스(ActiveX)나 플래시(Flash) 등을 필요로 하게 되는 배경이 되기도 합니다.
다음 이야기에서는 고정된 문서인 HTML 문서로 어떻게 웹 서비스를 할 수 있는지, CGI(Common Gateway Interface) 패러다임에 대해서 살펴보겠습니다.
주1) 실제의 HTTP 프로토콜의 규약은 문서를 저장하는 PUT, 문서를 지우는 DELETE 등의 여러 가지 액션을 가지지만, 일반적으로는 GET과 POST 명령이 사용됩니다.
주2) 윈도우의 command (cmd)에서 ‘telnet google.com 80’을 누르고 위의 Request 메시지를 입력 후 엔터 키를 두 번 누르시면 동일한 화면을 볼 수 있습니다.
[1] http://ko.wikipedia.org/wiki/HTML
[2] RFC 1866, HTML 2.0, http://www.rfc-editor.org/rfc/rfc1866.txt
[3] RFC 2616, HTTP 1.1, http://www.w3.org/Protocols/rfc2616/rfc2616.html
