HTML5는 단지 웹의 변화만을 요구하는 것은 아니다. 모바일의 중심 아키텍처가 되어 새로운 변화와 방향을 주도하고 있으며 나아가 서버 애플리케이션마저도 변화를 요구하고 있다. 또한 이런 요구는 궁극적으로 서비스 생태계 방향의 재정립을 요구하고 있으며 이에 발맞춰 나가지 않으면 무인도에서 홀로 사는 모습이 될 수 있다. 눈 덮인 히말라야 산 골짜기에서 혼자만의 외침이 될 수 있다.
김영보 www.corechain.com｜자바스크립트 라이브러리 CoreChain 개발자이면서 『HTML5 차세대 웹 표준, 기술』의 저자다.
필자는 이 글을 통해 태풍처럼 밀려오는 HTML5의 거대한 요구를 서비스 생태계와 연계해 어떻게 대처할 것인가를 생각해 보려고 한다. 이 글은 어쩌면 필자 자신의 독백이 될 수 있으며 소프트웨어 개발자인 필자 자신의 지침이 될 수도 있다. 한편 그릇된 점도 있을 수 있으며 뒤처지거나 훨씬 미래에 발생할 수도 있다. 이 글을 읽는 독자의 환경에 따라 생각의 척도가 다를 수 있으므로 판단은 독자의 몫으로 남기려 한다.
서비스 중심에 콘텐츠가 있다
우리 개발자들이 밤낮으로 고생해서 만드는 최종적인 결과물은 콘텐츠이며 이를 인간에게 제공하는 것이 궁극적인 목적이다. 인간에게 제공하지 못하는, 인간이 사용하지 않는, 사용의 필요성이 없는 콘텐츠를 개발하는 것은 의미가 없다. 서버의 블랙박스 안에 들어가는 제어용 프로그램도 개발하지만 이 또한 간접적으로 인간에게 콘텐츠를 제공하게 된다.
우리가 만든 콘텐츠는 인간에게 제공될 때 비로소 가치를 인정받게 되며 소정의 목적을 달성할 수 있다. 인간이 사용하지 않는 프로그램을 개발한들 소용이 없다. 기술 중심의 마인드를 가진 개발자들이 실수하는 가장 큰 이유 중의 하나가 이 점을 염두에 두지 않고 기술적으로 접근하기 때문이다. 기술과 프로그램은 콘텐츠를 제공하기 위한 바탕이지만 여기에 너무 치우치면 사용자에게 외면 받는 소프트웨어가 될 수 있다. 사용자는 기술이 아닌 콘텐츠를 보고 사용 여부를 결정하기 때문이다. 기술적인 측면을 고려하는 것은 한참 지난 후이며 그나마도 뜻 있는 일부 사용자가 한다.
HTML5는 서비스 지향 아키텍처다!
HTML5는 단지 HTML4에서 HTML5로 숫자가 바뀐 것이 아니므로 웹 페이지를 표현하는 태그 중심 개념으로 접근해서는 곤란하다. 그러면 아무것도 보이지 않으며 느낄 수도 없다. HTML5는 서비스 지향 아키텍처다.
그 동안의 HTML4 개념에서 보면 브라우저에 탑재된 하나의 언어인 것을 아키텍처라고 표현한 것에 대해 받아들이기가 어려울 수 있으며 논리에 맞지 않다고 생각할 수도 있다. 필자 또한 이 점에 동의한다. 하지만 브라우저 관점이 아닌 HTML5 밑바탕에 깔려있는 근본적인 모습을 보면 아키텍처라고 해도 틀림이 없다.
HTML5는 기능이 아니라 사상이라고 필자는 생각한다. HTML5라고 명명되어 한정된 느낌이 들게 하지만 현재 HTML5에 포함된 기능과 앞으로 전개될 기능을 고려하면 기능이 아니라 사상이다. 인간에게 콘텐츠를 제공하기 위한 근본적인 아키텍처다.
<그림 1> HTML5 분류
<그림 1>의 HTML5 분류에서 볼 수 있듯이 HTML5는 크게 엘리먼트(Element)를 통해 콘텐츠를 표현하는 마크업 부분과 다양한 기능을 제공하는 API 부분으로 나눌 수 있다. 한편 HTML5라고 표기하고 있는 관계로 인해 마크업 기능만을 가진 것으로 착각할 수 있으며 API 단어만을 보고 기능을 제공하기 위한 인터페이스로 한정 지을 수 있다.
여기서 중요하게 생각할 것은 마크업도 콘텐츠를 제공하기 위한 것이고 API도 콘텐츠를 제공하기 위한 것이라는 점이다. 즉, 인간에게 콘텐츠를 제공하기 위한 아키텍처를 구비한 것이다.
마크업은 HTML5에 추가된 엘리먼트 부분과 엘리먼트 기능을 다시 정의한 부분으로 나눌 수 있다. 추가 부분에서 첫째, 콘텐츠를 구성하는 모델 개념이 도입되었다. 엘리먼트를 구조적으로 나열해서 콘텐츠를 구성하는 것이 아니라 데이터베이스 모델링, 비즈니스 모델링, 도메인 모델링 등의 모델링을 하듯이 콘텐츠를 모델링하는 개념이다. 모델링의 최종 목적은 최적화라고 할 수 있다. 즉, 콘텐츠 모델링을 통해 인간에게 최적화된 콘텐츠를 제공하기 위한 것이다. 또한 모델링하는 사람을 모델러라고 하듯이 웹 퍼불리셔를 콘텐츠 모델러라고 불러야 한다.
둘째, <video><section>과 같은 엘리먼트의 추가다. 애플이 플래시를 지원하지 않겠다고 해서 큰 파란이 일었던 기술적인 배경은 하나의 엘리먼트를 지원하지 않은 것에서 발생했다. 이와 같이 엘리먼트 지원 여부에 따라 동반되는 기술에 영향을 미치게 된다. <video><audio>도 마찬가지다. 이 엘리먼트를 지원하게 됨에 따라 비디오, 오디오를 지원하는 체계의 변화가 생겼다. 어떤 회사는 이를 위해 기술력을 가진 회사를 인수하기도 했다. 이렇게 HTML5는 기능이 아닌 서비스 생태계를 변화시키는 아키텍처를 갖고 있다.
API는 <canvas>, <svg>와 같이 엘리먼트에 직접 콘텐츠를 표현하는 API와 Web Sockets, Database와 같이 간접적으로 콘텐츠를 제공하는 API로 나눌 수 있다. 또한 앞으로 어떤 API가 HTML5에 포함될지 모른다. TV에 브라우저가 탑재되듯이 HTML5에는 각종 디바이스(Device)에 브라우저가 탑재될 수 있는 아키텍처가 준비되어 있다.
바로 이 점이 HTML5를 다시 보고 생각해야 하는 이유다. 이미 브라우저를 지원하는 TV가 출시되고 있으며 향후 오디오로, 냉장고로 무한대의 발전이 예상되고 있다. 디바이스에 브라우저가 탑재되면 모바일, PC를 통해 이를 제어할 수 있게 된다. 즉, 이런 모든 제어를 위한 아키텍처를 HTML5가 제공하게 된다. 그래서 HTML5는 아키텍처다.
Web SocketsWeb Sockets는 클라이언트와 서버 간의 양방향 동시 통신을 규정한 API다. 일반적으로 클라이언트에서 서버의 애플리케이션을 호출하면 서버에서 요청한 클라이언트로 데이터를 전송하게 된다. 즉 클라이언트에서 요청이 있어야 한다는 전제 조건이 있으며 그때서야 서버 애플리케이션이 실행되어 데이터를 전송하게 된다. 하지만 Web Sockets는 한 번만 클라이언트에서 서버와 통신 경로를 열어두면 클라이언트의 요청이 없더라도 서버에서 클라이언트로 데이터를 전송할 수 있다. 물론 클라이언트에서 서버로 데이터를 전송할 수도 있다.
필자가 개발했던 간이 빙고 게임 프로그램의 시나리오를 통해 Web Sockets 형태를 살펴본다. 전반적인 처리 흐름과 기능을 살펴보는 것이 목적이다.
<화면 1> 빙고 게임
<화면 1>에서 보는 빙고 게임의 실행 환경은 클라이언트에 웹 소켓 서버를 설정했으며 Java로 서버용 애플리케이션을 작성했다. 왼쪽의 빙고 보드는 크롬 브라우저에서 실행한 것이고 오른쪽의 빙고 보드는 사파리 브라우저에서 실행한 것이다. 원고를 쓰는 시점에 두 브라우저에서 웹 소켓을 지원한다. 개략적인 시나리오는 오른쪽 빙고 보드의 숫자를 마우스로 클릭하면 값이 서버로 전송되고 서버 애플리케이션은 빙고 게임이 연결된 클라이언트로 데이터를 전송한다. 그리고 각 클라이언트에서 이 값을 받아 값과 일치하는 번호에 파란색을 칠한다. 전형적인 빙고 게임과 조금 차이가 있는 것은 의도적으로 웹 소켓 흐름 파악에 중점을 두었기 때문이다. 아래 시나리오에서 클라이언트는 HTML5, CSS, 자바스크립트, 캔버스를 의미한다.
● 시나리오
1. 사용자가 브라우저를 통해 빙고 게임을 실행한다.
1.1. 클라이언트는 랜덤으로 숫자를 추출해서 빙고 보드에 표시한다.
1.2. 클라이언트는 웹 소켓 오브젝트를 생성해 서버와 통신 경로를 개설한다.
2. 사용자가 오른쪽 빙고 보드에서 마우스로 숫자를 선택한다.
2.1. 클라이언트는 입력한 값을 서버로 전송한다.
2.2. 서버는 연결된 모든 클라이언트에 값을 다시 전송한다.
3. 클라이언트는 서버에서 데이터가 전송된 것을 인식한다.
3.1. {메모} 이벤트 핸들러가 웹 소켓 오브젝트에 설정된 상태이므로 이벤트가 발생하면 자동으로 핸들러 함수가 실행된다.
3.2. {메모} 이를 메시징 방법이라고 한다.
3.3. 빙고 보드에서 일치하는 번호를 찾아 바탕색을 파란색으로 칠한다.
웹 소켓은 클라이언트에서 var obj = new WebSocket(‘http ://www.corechain.com/socket’)과 같이 생성자 함수의 파라미터에 애플리케이션을 지정하면 통신이 개설된다. 그리고 생성한 오브젝트인 obj에 obj.onmessage = this._onmessage와 같이 onmessage 이벤트가 발생했을 때 실행할 이벤트 핸들러 함수를 지정한다. 그러면 서버에서 웹 소켓을 통해 데이터를 전송하면 자동으로 this._onmessage 함수가 실행된다. 이와 같이 간단하고 쉽게 통신을 행할 수 있다.
여기서 중요한 것은 HTTP 통신을 하게 되면 Header 정보가 통신할 때마다 전송되지만 웹 소켓 통신은 처음 한 번만 전송되고 두 번째부터는 header 정보는 전송하지 않고 데이터만 전송한다는 점이다. 그러니 당연히 처리 속도가 빠르다.
또한, 메시징 기법을 다른 API에도 적용했다는 점이다. 예를 들면 클라이언트의 데이터베이스에서 데이터를 추출할 때 조건을 지정해 데이터베이스의 메소드를 호출하면, 데이터 추출을 완료한 후 이벤트를 발생시키므로 자동으로 이벤트 핸들러 함수가 실행된다. 이와 같이 HTML5는 같은 메커니즘을 갖고 있다.
Canvas
캔버스(Canvas)는 동적으로 2차원 그래픽을 구현할 수 있는 API다. 여기서 동적으로 그래픽을 구현한다는 점이 특징이다. 또한, <canvas> 엘리먼트에 직접 그래픽을 표현할 수 있다. 동적이 아닌 정적인 그래픽은 HTML4의 <img><object> 엘리먼트를 사용해서 표현할 수 있다.
그래픽을 표현하기 위한 요소로는 위치를 나타내는 X/Y 좌표, 도형/선을 그리는 형태와 색상을 들 수 있다. 즉, 캔버스는 이를 위한 메소드와 프로퍼티를 제공한다. 또한 자바스크립트 프로그램으로 캔버스의 메소드와 프로퍼티를 조합해 그래픽을 표현하게 된다.
<화면 2>의 캔버스 도형에서 볼 수 있듯이 바탕색이 다른 원이 5개 그려졌다. 또한 다음은 이를 그린 코드다.
<화면 2> 캔버스 도형
var context = document.getElementById(‘idOne’).getContext (‘2d’);
var arcFill = function(x, y, r, g, b, radius){
context.beginPath();
context.fillStyle = ‘rgba(‘ + r + ‘, ‘ + g + ‘, ‘ + b + ‘, 0.7)’;
context.arc(x + 650, y + 180, radius, 0, Math.PI * 2, false);
context.fill();
}
arcFill(50, 40, 255, 130, 130, 30);
arcFill(50, 90, 43, 255, 40, 30);
arcFill(100, 40, 64, 161, 255, 30);
arcFill(100, 90, 158, 64, 255, 30);
arcFill(75, 65, 255, 255, 223, 25);
첫 번째 줄에서 도큐먼트에 작성된 <canvas> 엘리먼트를 엘리먼트 오브젝트로 생성하면 오브젝트에 getContext()가 설정되어 있으므로 이를 호출할 수 있다. getContext()는 캔버스 오브젝트를 반환하는 생성자 함수다. 캔버스가 API이므로 new 연산자를 사용해서 오브젝트를 생성해야 하나 new 연산자를 사용하지 않고 생성자 함수를 불러 오브젝트를 생성한다. 또한, 캔버스를 표현할 수 있는 메소드와 프로퍼티가 캔버스 오브젝트에 설정되어 있으므로 이를 사용할 수 있다.
아래의 arcFill()의 파라미터에 원이 표시될 X/Y 좌표, 바탕색의 RGB 값, 원의 반지름을 지정해 호출하면 원을 그리게 된다. 단순한 것 같으므로 하나 더 살펴본다.
<화면 3> 캔버스 차트
<화면 3>은 캔버스로 그린 차트다. 서버에서 데이터를 받아와서 차트를 그릴 수 있으며 직접 데이터를 지정해 그릴 수도 있다. 여기서 중요한 것은 동적 그래프라는 점이다. 만약 주식 동향 그래프를 제공한다고 할 때 고정된 그래프가 아닌 동적으로 서버에서 데이터를 받아와 그려야 하며 데이터 값에 의해 그래프가 그려져야 한다. 또한 프로그램도 데이터에 따라 움직여야 하므로 고정 값을 지정한 형태가 아닌 옵션을 지정해 프로그램이 수행되는 형태가 되어야 한다. 이와 같이 Canvas API는 동적으로 그래프를 그리는 데 유용하다.
최근의 동향을 보면 모바일에서 웹 페이지를 쉽게 볼 수 있도록 하기 위해 되도록이면 이미지 파일을 사용하지 않으려는 경향이 있다. 캔버스를 사용해서 이미지를 표현하면 모바일에 탑재된 모든 브라우저에서 캔버스 API를 지원하므로 웹과 모바일 모두 통용될 수 있다. 이미지 파일이 다운로드될 때까지 기다리지 않아도 된다.
이미지 파일을 되도록 사용하지 않으려는 또 하나의 이유는 통신이 연결되지 않은 오프라인 상태에서도 모바일은 애플리케이션을 실행할 수 있다는 점 때문이다. 이때 <html> 태그에 실행할 파일과 이미지 파일의 URL을 지정한다. 그런데 캔버스로 이미지를 표현하면 이미지 파일이 필요 없으므로 지정하지 않게 된다. 물론, 지정하는 것이 어려운 것은 아니지만 이미지 파일의 URL이 변경되거나 동적으로 이미지를 표현해야 하는 경우에는 부담이 될 수 있다. 즉 유지보수의 어려움이 있다. 하지만 캔버스로 이미지를 표현하면 동적으로 이미지를 표현할 수 있으며 프로그램만 수정하면 자동으로 반영되므로 이미지 파일의 URL을 바꾸지 않아도 된다.
또 다른 방법으로 CSS3를 사용하는 것을 생각할 수 있는데, 모바일의 브라우저는 지원하지만 IE 6/7/8에서 지원하지 않으므로 웹 페이지에 적용하기에는 어려움이 있다. 물론 Canvas도 IE 6/7/8에서 지원하지 않지만 구글에서 개발한 캔버스 라이브러리를 사용하면 네이티브가 아니므로 다소 처리 속도가 떨어지더라도 이미지를 그릴 수 있다. 필자가 이를 제시하는 것은 대안, 다른 방법을 제시하기 위한 것이며 이렇게 해야 한다는 것은 아니다.
Web Storage
웹 스토리지(Web Storage)는 클라이언트에 데이터를 저장하기 위한 API다. 쿠키를 사용해서 데이터를 저장할 수도 있지만 용도와 방법이 다르다. 쿠키는 쿠키에 접근할 때마다 서버로 전송하지만 웹 스토리지는 전송하지 않는다. 또한 쿠키는 크기(4 KB)에 제한이 있지만 웹 스토리지는 사이트 단위로 5MB를 HTML5 스펙에서 권장하고 있다. 하지만 이는 권고이며 확정된 것은 아니다. 쿠키는 유효 기간을 설정할 수 있으며 이 기간이 지나면 자동으로 지워지지만 웹 스토리지는 유효 기간이 없으며 사용자가 의도적으로 지우지 않으면 영구 보관된다.
웹 스토리지는 키와 값 형태로 저장된다. 일명 Hash로 {key : value} 형태다. 현재 문자열을 지원하는 브라우저가 있을 수 있는데, 이는 이전 스펙에서는 문자열로 지원하도록 되어 있기 때문이며 최근 스펙에서 변경되었다.
웹 스토리지는 두 가지 유형의 로컬 스토리지와 세션 스토리지를 제공한다. 로컬 스토리지는 사이트 단위를 지원하며 세션 스토리지는 브라우징 콘텍스트 단위로 지원한다. 브라우징 콘텍스트란 브라우저에서 다수의 탭을 사용할 때 각각의 탭을 의미한다. 로컬 스토리지 값은 영구 보관되며 세션 스토리지는 브라우저를 닫으면 자동으로 지워진다.
여기서 하나 생각할 것은 왜 이런 메커니즘을 갖느냐는 것이다. 필자가 웹 스토리지 API를 개발한 것이 아니므로 바로 이것이라고 단언할 수는 없지만 우선 생각할 수 있는 것은 통신을 최소화할 수 있다는 점이다. 같은 데이터를 매번 서버에서 가져오지 않고 웹 스토리지에 저장된 데이터를 사용하면 속도도 훨씬 빠를 뿐 아니라 서버의 부하도 줄일 수 있다. 특히 통신이 끊긴 오프라인 상태에서 실행되는 모바일에서 더욱 진가를 발휘할 수 있다.
예를 들어 고객과 상담 중에 주문을 받았다고 했을 때 그 자리에서 주문을 모바일에 입력할 수 있다. 이때 웹 스토리지에 주문 입력을 위한 기본 데이터가 저장되어 있다면 서버와 연결하지 않아도 된다. 고객과 같이 모바일을 보면서 주문 내용을 입력할 수 있다. 또한 이어서 다루고 있지만 입력한 데이터를 데이터베이스 API를 사용해서 모바일에 저장할 수 있다.
여기서 중요한 것은 통신이 끊긴 상태에서도 처리할 수 있다는 점이다. 오프라인 상태에서 웹 스토리지 또는 데이터베이스에 데이터를 저장하고 필요한 시점에 서버와 연결해 저장된 데이터를 전송한다. 이와 같이 HTML5는 통신이 끊어진 오프라인 상태에서도 처리할 수 있는 아키텍처와 메커니즘을 제공한다.
Database
HTML5는 두 가지 유형의 Web SQL Database와 Indexed Database를 제공한다. Web SQL 데이터베이스는 ‘select * from table_name’과 같이 일반적으로 알려진 SQL을 사용해서 데이터를 저장/추출할 수 있으며 Indexed 데이터베이스는 인덱스를 사용해서 데이터를 저장/추출할 수 있다. 그런데 Web SQL 데이터베이스는 개발이 중단되었으며 Indexed 데이터베이스가 표준으로 채택될 가능성이 높다.
Indexed 데이터베이스는 {key: value} 형태에 인덱스를 부여해 데이터를 저장한다. 따라서 key 또는 인덱스로 데이터를 저장/추출할 수 있다. 물론, 처리 속도가 떨어질 수 있지만 value로도 추출할 수도 있다. 인덱스는 데이터베이스에서 자동으로 설정한다.
여기서 {key: value} 형태는 앞서 다뤘던 웹 스토리지와 같다. 다만 Indexed 데이터베이스는 인덱스를 부여하며 저장하므로 key가 중복되더라도 값을 저장할 수 있다. 예를 들어 회원번호를 가진 회원이 다수의 주문을 한다고 할 때 주문번호가 아닌 회원번호를 사용해서 데이터를 저장할 수 있다. 또한 데이터베이스에서 지원하는 커서(cursor) 기능을 제공하므로 데이터를 보다 빠르게 추출할 수 있다.
서버에서 모든 것을 하던 시대는 끝났다
HTML5에는 지금까지 살펴본 것 이외에도 다수의 API가 있다. 하지만 지면 관계도 있고 본 내용이 API를 소개하는 것이 목적이 아니므로 전체를 다루지 않았다.
그럼 지금까지 살펴본 API의 핵심은 무엇일까? 우선 모든 API가 브라우저에 탑재되어 있으며 클라이언트에서 실행된다는 점이다. 따라서 브라우저가 실행될 수 있는 환경이면 어디서든지 HTML5를 제공할 수 있으며 이의 궁극적인 목적은 인간에게 콘텐츠를 제공하는 데 있다.
30년 전 필자가 처음 프로그램을 개발할 때는 모든 것이 메인 컴퓨터에 있었다. 그리고 어느 정도 시간이 흐른 후 클라이언트/서버 시대가 도래했다. 메인 컴퓨터에서 실행되던 프로그램이 클라이언트에서 실행되는 형태로 유저 인터페이스와 관련된 프로그램이 클라이언트에서 실행되었다.
한편 이 무렵에 웹이 태동했으며 브라우저가 클라이언트 프로그램 역할을 하게 되었다. 하지만 이때의 브라우저는 HTML5가 탑재된 현재의 브라우저하고는 기능도 다르고 처리 방법, 범위도 달랐다. 웹 페이지를 표현하는 것이 주된 기능이다.
브라우저를 사용해서 데이터를 표현하려면 반드시 서버용 애플리케이션이 있어야 한다. 서버용 애플리케이션에서 보내준 데이터를 받아 이를 표현하는 형태로 동기 또는 비동기 방식으로 데이터를 주고 받는다. 이런 환경으로 인해 서버용 애플리케이션은 데이터를 제공하는 형태로, 브라우저는 유저 인터페이스 중심으로 데이터를 표현하는 형태로 발전되었다.
하지만 이런 구조는 사용자의 다양한 요구를 만족시키기에 한계가 있으며 특히 모바일과 다양한 디바이스 환경의 사용자 요구를 만족시키기에 더욱 한계가 있다. 이에 대처할 방법이 바로 HTML5인 것이다. 지금까지 살펴봤듯이 HTML5는 서비스 지향 아키텍처이며 메커니즘을 제공한다.
HTML5는 브라우저만으로 PC, 모바일, 디바이스에서 서버 기능의 대부분을 단독으로 처리할 수 있다. 다른 프로그램이 필요한 것도 아니며 OS가 다른 디바이스 환경에 제약을 받는 것도 아니다. 데이터를 저장할 수 있는 데이터베이스도 있으며 클라이언트의 파일을 읽거나 쓸 수도 있으며 그래프를 표현할 수도 있으며 필요할 시점에 매우 빠르게 다른 디바이스와 통신할 수도 있다. 간단한 애플리케이션이라면 서버와 연결하지 않고 단독으로 처리할 수 있다. 비록 지금은 작은 애플리케이션이지만 가까운 미래에 디바이스 용량이 커지면 큰 애플리케이션도 실행할 수 있게 된다. 이는 하드웨어적인 면으로 지금까지의 경험으로 볼 때 그야말로 눈 깜짝할 사이에 실현될 것이다.
이제, 클라이언트와 서버가 브라우저에 통합되어 손바닥 안에서 실행하게 된다. 손바닥 위에서 무릎 위에서 손가락으로 콘텐츠를 보고 생성하는 시대가 도래한 것이다. 서버와 연결하지 않고도 유려한 인터페이스를 사용해서 보다 인간적으로 친근하게 콘텐츠를 처리할 수 있다. 이제 서버에서 모든 것을 제공하던 시대는 끝났다. 이제 남은 것은 서버와 클라이언트가 융합해 보다 나은 콘텐츠를 어떻게 사용자에게 제공할 것인가를 생각하고 행동하는 것이다. 그리고 그 중심에 HTML5가 있다. 인간에게 선택 받지 못한 콘텐츠는 더 이상 존재 가치가 없다는 점을 상기해 보며 글을 마친다.
출처: http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=36440
