박종명의 아름다운 개발 since 2010.06

오늘 연속적으로 기사만 두 건 포스팅하네..
W3C가 HTML5 행보에 찬물을 끼얹는 발언을 했구나!
이건 뭐.. 주최측이라고는 하지만.. 달라도 너무 다른거 아닌가...

기사원문: W3C "HTML5, 도입 이르다"... 브라우저 업체와 노선차이

사실 현재시점에 어느 누가 HTML5를 전면 도입 가능하다고 생각하고 있을까?

Mark Pilgrim 이 언급했듯이 HTML5는 한 덩어리의 기술이 아니다
HTML5는 여러 기술 스펙의 조합이며 최신 브라우저에서는 이미 많은 부분 적용되어 있는것이 현실이다

물론 아직 표준화가 완료되지 않아서 브라우저간 조금씩 상이한 구현과 향후 변경 가능성을 내포하고 있어 불완전하다는 측면은 분명 존재한다.

W3C의 발언이 이런 우려를 내비친 보수적인 입장이라는 점은 이해하지만 표준화를 주도하는 입장에서 굳이 이런 발언을 할 필요가 있나 싶다. HTML5 의 가능성과 빠른 표준화를 공표하고 그사이 발생할 수 있는 호환성 문제를 조심스레 제기하는 수준이라면 모를까... 마치 찬물을 끼얹는 듯한 발언에 아쉬움이 든다

기사 중 다음의 글에 공감한다

일부 웹 전문가들은 기술이 표준화되기 이전에 이미 업계에 널리 확산돼 실용성을 검증받는 과정이 자연스러운 수순이라는 입장이다

마이크로소프트의 닷넷을 기반으로 웹 응용프로그램을 개발할 땐 비주얼스튜디오만 있으면 된다
개인적으로 MS 진영의 개발툴은 그 어떤 것보다 강력하다고 생각한다
(완벽에 가까운 한글 지원을 포함하여...)

윈도우 응용프로그램, 웹 응용프로그램, 웹 서비스, 라이브러리 등 닷넷과 관련한 모든 개발은 비주얼스튜디오 하나로 다 해결할 수 있다. 물론 ASP.NET 기반의 웹 개발을 위한 도구인 Visual Web Developer 가 존재하지만 이것은 통합 개발환경인 비주얼스튜디오의 서브도구 개념이기 때문에 특수한 경우가 아니라면 비주얼스튜디오만으로도 충분하다.

그리고 과거 ASP나 PHP로 웹 사이트를 개발할 때 특별한 툴을 이용하지는 않았다
한때 asp개발을 위해 비주얼인터데브를 사용한 적이 있으나 프로그래밍 모델이 복잡하지 않은 asp 개발에 오히려 복잡성을 증가시키는 것 같아 Acroedit 와 같은 심플한 텍스트 에디터를 사용했었다
(Acroedit 는 필자가 거의 10년 가까이 사용하고 있는 애착(?)이 가는 무료 에디터이다)
그리고 간혹 웹 디자이너나 퍼블리셔들이 사용하던 드림위버(혹은 나모웹에디터) 라는 툴도 듬성듬성 사용했었다

그러나 요즘 HTML5 기반 응용프로그램을 개발하려다 보니 개발툴의 절실함을 많이 느낀다
Acroedit 는 웹 개발을 위해 FTP 기능, 언어 예약어 하이라이트 기능, 책갈피 기능 등 에디터로써 유용한 기능들이 많이 포함되어 있지만 비주얼스튜디오와 같은 인텔리전스 기능은 가지고 있지 않다

HTML5 개발은 HTML 태그와 더불어 자바스크립트를 사용하는 경우가 많기 때문에 언어 하이라이트는 필수라 할 수 있으며 객체에 정의되어 있는 함수나 속성을 자동으로 띄워주는 인텔리전스 기능이 매우 목마르다. 물론 HTML5 이전의 웹 개발환경에도 자바스크립트의 비중이 적다고는 할 수 없지만 개인적으로 그 당시에는 클라이언트 스크립트를 요즘과 같이 관심있게 들여다 본적이 없었기 때문에 필요성도 덜 느꼈었다.

이번에 소개할 Aptana 는 웹, 특히 자바스크립트나 HTML, CSS와 같은 클라이언트 단 웹 개발을 돕는 개발 툴로 이미 꽤 유명세를 타고 있는 툴인 것 같다

나의 경우 HTML5, CSS3 에 관심을 두기 시작하면서 알게 된 툴이다
툴을 직접 깔아보니 자바 개발툴인 이클립스와 매우 유사한 UI 및 프로세스를 지니고 있다
알고 보니 이클립스를 통해 웹 개발을 돕는 플러그인 형태로 제공되던 툴인데 현재 독립 실행형으로도 배포되고 있는 듯 하다

Aptana Studio 버전 3 부터는 HTML5, CSS3 를 지원하며 현재 베타버전으로 다음의 링크를 통해 다운받을 수 있다 => http://aptana.com/products/studio3

듣기로 현재(2010.09.30) W3C의 HTML5 표준화 프로세스는 Working Draft 단계에 있는 것으로 알고 있다. 2009년 10월에 WHATWG 에 의해 Last Call이 선언되어 W3C로 사양이 제출되었다
이제 W3C에서도 Last Call 프로세스를 진행하기로 했다는 소식이다

Last Call 은 표준을 위한 권고안이 되기 전에 최종 검토하는 기간이다
ETRI 이원석님의 블로그에 향후 일정이 상세히 설명되어 있으니 참고 바란다
=> W3C, HTML5 표준 초안 Last Call 예정

글에 따르면 2011년 5월에 Last Call 이 종료된다고 한다
이후 권고 후보, 권고안, 권고 과정을 거치면 드디어 표준화가 완성된다

사실 권고안만 되면 거의 게임 끝났다고 볼 수 있다
한 때 HTML5 의 표준화 완성이나 보편화가 최소 10년 후, 먼 미래가 될 것이라는 일부 부정적 시각이 있었으나 현재 분위기로 봐서는 2012년 정도에는 뚜렷한 윤곽이 나오지 않을까 싶다

실시간 (양방향) 통신을 위한 웹의 노력
개인적인 생각으로 HTML5의 새로운 스펙중에 사용자가 가장 흥미로워 한 것이 Canvas 라면
개발자가 가장 흥미로워 한 것은 바로 웹 소켓(Web Socket)이지 않나 싶다

필자 역시 순수 웹 환경에서 연결 지향 양방향 통신을 지원하는 웹 소켓이 가장 눈에 띄는 것 중 하나였다. 과거 순수 웹 환경에서 채팅과 같은 실시간 응용프로그램을 위한 얼마나 많은 시도들이 있었던가...

이제 박물관(?)에서나 볼 법한 숨긴 frame(or iframe) 을 통한 반복적인 재요청은 당시만 해도 웹에서 실시간 효과를 낼 수 있는 참신한 아이디어로 부상한 적이 있었다

이후 Ajax의 등장으로 비동기로 반복 요청을 할 수 있어 그나마 조금은 개선 되었다
그러나 여전히 클라이언트의 비 효율적인 재요청을 피할 수는 없었다

그리고 이후 Comet 의 등장으로 서버 데이터 수신 후 재 요청이 가능해져 불필요한 반복 요청의 비효율성은 개선되었다.

그러나 이 모든 것은 '폴링(polling)' 방식이다
즉 데이터 수신을 위해 서버가 클라이언트에게 전송해 주는 푸시(push)방식이 아니라 클라이언트가 서버에에게 요청하는 폴링(polling) 방식이었다

비교적 최적의 대안이었던 Comet 역시 무의미한 반복 요청을 피하기 위한 연결유지 기법이 적용되었지만 일정 시간 이후에는 연결을 종료하고 다시 연결해야 한다. 그래서 Comet을 Long-Polling 라 한다

참고: [HTML5] Server-Sent Events

웹의 진정한 실시간 (양방향) 통신, 웹 소켓(Web Socket)의 등장
초기 웹의 탄생 목적은 문서 전달과 하이퍼링크를 통한 문서 연결이었다
웹을 위한 HTTP 프로토콜은 이러한 목적에 매우 부합하는 모델이다
그러나 시대가 변하고 환경이 발전할 수록 웹이 더 이상 문서공유에만 집중할 수 없었다
갈수록 동적인 표현과 뛰어난 상호작용이 요구되었고 이로 인해 여러 새로운 기술이 탄생되었다

플래시(플렉스), 자바애플릿(자바FX), ActiveX , 실버라이트 등을 들 수 있다
하지만 이들은 웹에서 화려한 동작과 뛰어난 상호작용을 보장하지만 순수 웹 환경이 아니라 별도의 런타임을 플러그 인 형태로 브라우저에 설치해야 사용 가능하다

HTML5는 그 주요 목적 중 하나인, 플러그 인 없는 일관되고 표준화된 웹 응용 환경이라는 기치하에 많은 참신한 스펙들이 개발되었다.

그 중 순수 웹 환경에서 실시간 양방향 통신을 위한 스펙이 바로 '웹 소켓(Web Socket)' 이다
웹 소켓은 웹 서버와 웹 브라우저가 지속적으로 연결된 TCP 라인을 통해 실시간으로 데이터를 주고 받을 수 있도록 하는 HTML5의 새로운 사양이다. 따라서 웹 소켓을 이용하면 일반적인 TCP소켓과 같이 연결지향 양방향 전이중 통신이 가능하다

이와 같은 특징으로 웹에서도 채팅이나 게임, 실시간 주식 차트와 같은 실시간이 요구되는 응용프로그램의 개발을 한층 효과적으로 구현할 수 있게 되었다

웹 소켓과 Ajax 속도 비교
한 일본 사이트에서 웹 소켓과 (Ajax의 통신 객체인) XMLHttpRequest 의 속도 비교를 확인할 수 있는 페이지를 제공하고 있어 화제가 되고 있다
=> http://bloga.jp/ws/jq/wakachi/mecab/wakachi.html (크롬 or 사파리에서 실행)

서버에 존재하는 1,981(공백포함) 길이의 일본문자를 132개로 끊어서 가져오는 데모인데, 각각 웹 소켓과 여러개의 Ajax(병렬 Ajax)를 이용해 각각 호출해서 실행 속도를 비교했다

테스트 할 때마다 실행 속도의 차이가 조금씩 나지만 웹 소켓이 대략 50배 이상 좋은 성능을 보이고 있다


물론 이 사이트의 테스트 시나리오에 따르면, 한번에 모든 문자를 가져오는 것이 아니라 132개로 나눠진 단락들을 가져오는 것이다 보니 한번 연결된 통신 라인으로 데이터만 가져오는 웹 소켓에 비해 매번 헤더정보를 실어서 새로 요청 하는 Ajax가 더욱 느리게 느껴질 수 있다

하지만 이것은 '수 차례 송/수신을 하는 시나리오' 를 가정한 만큼 테스트 시나리오에 문제 제기를 할 필요는 없어 보인다. 웹 소켓을 사용하는 환경의 거의 대부분이 이런 시나리오이기 때문에 더욱 그렇다

어쨋던 확실히 실시간 통신환경에서는 Ajax 보다는 웹 소켓이 월등하다는 것을 알 수 있다

웹 소켓이 필요한 다섯가지 징후?
Peter Lubbers 라는 개발자가 'Five Signs You Need HTML5 WebSockets' 이라는 글을 포스팅 했다
HTML5의 웹 소켓을 이용하면 좋을 5가지 경우를 조목조목 설명하고 있다
뭐.. 결론은 웹 소켓 좋다는 거다 ^^ . 글에서 상단의 Summary 만 가져와 본다

1. Your web application has data that must flow bi-directional simultaneously.
2. Your web application must scale to large numbers of concurrent users.
3. Your web application must extend TCP-based protocols to the browser.
4. Your web application developers need an API that is easy to use.
5. Your web application must extend SOA over the Web and in the Cloud.

대략 난잡번역 해 보면,
1. 실시간 양방향 데이터 통신이 필요한 경우
2. 많은 수의 동시 접속자를 수용해야 하는 경우
3. 브라우저에서 TCP 기반의 통신으로 확장해야 하는 경우
4. 개발자에게 사용하기 쉬운 API가 필요할 경우
5. 클라우드 환경이나 웹을 넘어 SOA 로 확장해야 하는 경우

그리고 각 경우에 대한 설명이 자세히 나열되어 있으니 스스로 번역해서 음미 바란다
(누가 좀 안해주나 ^^;)


지원되는 브라우저 현황
IE와 오페라를 제외한 사파리,크롬,파이어폭스 최신버전에서 웹 소켓을 지원한다

보는 바와 같이, 소켓 통신을 위한 클라이언트 측 코드는 매우 심플하며 직관적이다. 하지만 말했듯이 클라이언트 코드 만으로 데모는 실행되지 않는다. 클라이언트와 통신하는 서버가 존재해야 하는데 아래에 계속 이어진다

웹 소켓 서버
웹 소켓은 일반적인 TCP 소켓과는 다른 프로토콜로 설계되었다. 따라서 기존 TCP 서버를 그대로 이용할 수 없고 새로 구현해야 하는데 웹 소켓 서버 사양에 맞도록 구현해야 한다.

웹 소켓 서버를 위한 다양한 오픈소스가 온라인에서 제공되고 있는데,
pywebsocket , phpwebsocket, jWebSocket, web-socket-ruby, Socket.IO-node 와 같은 모듈을 이용하면 웹 소켓 서버를 쉽게 구축할 수 있다

이 글에서는 jWebSocket을 이용해서 웹 소켓 서버를 구축하고 제공되는 데모를 실행해 보도록 하자

jWebSocket 라이브러리는 http://jwebsocket.org/ 사이트를 통해 다운로드 받을 수 있는데
자바로 구현된 웹 소켓 서버모듈인 jWebSocketServer와 자바스크립트로 구현된 웹 소켓 클라이언트 데모인 jWebSocketClient 을 다운받으면 된다. 참고로 jWebSocket 라이브러리의 전체 소스코드는 jWebSocketFullSource를 다운받아 볼 수 있다

jWebSocketServer 구동
우선 웹 소켓 서버를 구동 시켜야 하는데, 아파치 웹서버나 톰켓을 이용하여 구동하거나 Stand-Alone 으로도 구동시킬 수 있다. 이 글에서는 간단한 테스트를 위해 Stand-Alone로 구동시켜 보도록 하자

jWebSocketServer 가 자바로 구현되었기 때문에 자바 가상 머신이 설치되어 있어야 한다
서버에 최소 1.5 버전 이상의 자바런타임을 설치하도록 하자
그리고 기본적인 자바 환경 변수인 JAVA_HOME 과 java.exe를 Path에 등록한다

이제 자바를 위한 기본 설정이 마무리 되었으니 jWebSocketServer를 구동시키면 된다
Stand-Alone로 구동시키기 때문에 별도의 웹 서버는 필요하지 않고 배치파일을 실행하는 것으로 대신할 수 있다. 다운받는 jWebSocketServer을 압축해제 하고 bin 폴더에 있는 jWebSocketServer.bat 파일을 명령프롬프트에서 실행하도록 하자. 배치파일을 실행하면 설정을 위한 일련의 작업들이 진행되고 최종적으로 다음과 같은 모습으로 웹 소켓 서버의 구동이 시작된다


이후 웹 소켓 서버와의 통신로그와 디버그 메세지들이 이 창에 계속 기록된다
배치파일을 실행하는 동안 서버가 구동되는 것이기 때문에 실행창을 닫으면 서버도 종료됨을 기억하자

다음의 퀵스타트를 참고 하자
http://code.google.com/p/jwebsocket/wiki/QuickStart

jWebSocketClient 데모 테스트 하기
서버가 준비되었으니 웹 소켓 통신을 수행하는 클라이언트 데모를 확인해 보자
jWebSocketClient 를 다운받아서 압축해제 하면 다양한 데모가 미리 준비되어 있다
우리는 여기서 채팅데모인 chat.htm 을 실행해 보자

웹 소켓을 지원하는 브라우저를 두 개 띄우고 chat.html을 실행한다. 아래 그림은 크롬 브라우저의 실행 모습이다. 두 개의 브라우저에서 각각 로그인 한 뒤, 채팅하는 모습이다


채팅 외에도 다양한 데모가 있으니 참고 바라며 웹 소켓서버 통신의 기술적 구현을 배우기 위해 코드를 꼼꼼히 살펴보는 것도 좋을 것이다.

참고로 jWebSocket 에서 서버 연결을 위해 다음과 같은 url을 정의하고 있다
var lURL = jws.JWS_SERVER_URL + "/;prot=json,timeout=360000";
...
JWS_SERVER_URL: "ws://" + ( self.location.hostname ? self.location.hostname : "localhost" ) + ":8787"

ws 프토토콜로 localhost, 8787포트로 연결하며 추가로 json 포맷과 타임아웃이 설정되었다

마지막으로 WebSocket 은 다른 HTML5 사양보다 프로그램적인 성격이 강하다.
특히 클라이언트 코드만으로 해결될 수 있는 것이 아니라 좀 더 복잡해 보일 수 있다.
또한 많은 수의 클라이언트를 수용하기 위해서는 소켓 서버의 성능과 가용성이 확보되어야 하기 때문에 보다 신중한 접근이 필요하다 하겠다. 글에서 소개한 웹 소켓 서버 라이브러리를 적절히 이용하거나 오픈 소스를 분석해서 내공을 키우기 바란다

2016.07.15 추가>
- Node.js기반 socket.io 라이브러리를 이용해 간단한 웹 채팅을 구현한 다음 포시팅도 참고하기 바란다.
- [NodeJS] socket.io를 활용한 웹채팅 구현


참고>
Firefox의 웹소켓(WebSocket) 기능
http://code.google.com/p/websocket-sample/
http://dev.w3.org/html5/websockets/
http://www.websockets.org/about.html
http://www.codeproject.com/KB/webservices/c_sharp_web_socket_server.aspx