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

JSON은 인터넷을 통해 응용프로그램간 데이터를 주고 받는 규칙 즉 데이터 포맷을 일컫는다

'제이슨' 이라고 발음하는데 우연찮게도 '13일 밤의 금요일' 의 누군가와 이름이 같다 ㅎㅎ
당연하겠지만, 그 제이슨과는 아무런 연관이 없으며 데이터 포맷을 위한 표기법이 자바스크립트 객체 표기
방식에 근거를 두어 전체 이름이 JavaScript Object Notation 며 그 약자가 JSON 이다

JSON 은 Douglas Crockford 라는 미국의 개발자에 의해 탄생했으며 JSON 을 가장 잘 설명해 놓은 곳은 역시 JSON 공식 웹 사이트이다. 다음의 JSON 사이트에서 JSON의 모든 것을 알 수 있다
=> http://www.json.org/ (한글판: http://json.org/json-ko.html)

그리고 위키백과에도 JSON 을 꽤 적절하게 잘 설명하고 있다
=> http://ko.wikipedia.org/wiki/JSON

인터넷을 통한 원격 통신간 데이터 교환 포맷인, JSON 은 요즘 뜨는 최신 기술이 아니다.
이미 수 년전부터 곳곳에서 이를 이용해 왔으며 나의 경우 3년전인 2007년경에 처음 접하게 되었다
웹의 비동기 통신기법인 Ajax 의 등장시기와 유사한 2005년경에 본격적으로 이름이 알려지기 시작한 것 같으며 현재 트위터와, 오픈 API 와 같은 경량성, 상호연동성, 쉽고 편리한 API를 중시하는 서비스들에 많이 적용되고 있는 추세이다

그리고 JSON 이 비록 자바스크립트 구문형식을 따르기는 하지만 그 자체로 하나의 독립적인 체계로써 특정
언어나 플랫폼에 종속되지 않으며 C#, Java, ASP, PHP, C, C++ 등의 다양한 언어에서 JSON 포맷을 위한 파서들이 제공되고 있다. 

인터넷 데이터 교환 포맷
인터넷 특히 웹을 통한 데이터 교환은 JSON 이전에도 존재했었다.
가장 원시적인 방법이 일반 텍스트를 이용하는 것이었다. 단일 값은 물론 복수의 값도 전달가능 일반 텍스트로 전달하곤 했었는데, 대체로 다음과 같이 구분자를 기준으로 텍스트 포맷을 주고 받는 형태였다

일반 텍스트 포맷: "name=박종명 || email=mkex@naver.com || age=36"
전체 구분자로 '||'를 이용하고 키,값 구분자로 '=' 를 이용하여 데이터를 정의했으며 수신하는 측에서는 구분자를 기준으로 문자열을 분리하여 그 의미를 해석하곤 했다

척박한 당시 상황에서는 일반텍스트 포맷은 꽤 많은 곳에서 이용되었으며 대략 만족하기도 했었다
그러나 구분자 역시 문자이기 때문에 전달하고자 하는 데이터 자체와 충돌할 수 있었고 배열 형태와 같은
복수 집합 자료를 정의하기에는 어울리지 않는 포맷이었다
---

다음으로 각광 받은 포맷이 XML 이다. XML 자체가 데이터 정의에 매우 적합한 언어이기에 아주 훌륭한 포맷이었다. 다음에서 보는바와 같이 각 요소는 정확한 의미의 태그와 연결될 수 있으며 집합자료정의도 쉽게 할 수 있다. 또한 요소의 attribute 를 이용하면 데이터 타입이나 제약사항과 같은 같은 추가 정보도 얼마던지 정의할 수 있어 데이터 정의에 매우 적합한 형태이다
<user>
  <name>박종명</name><email>mkex@naver.com</email>
  <name>홍길동</name><email>xxxxxxx@naver.com</email>
  ...
</user>

이와같이 XML은 데이터에 의미를 부여하기 위해서는 그 어떤 포맷보다 훌륭하지만 매번 열고 닫아야 하는 태그 쌍은 데이터의 크기를 증가시키는 원인이 되기도 하며 XML을 파싱할 때 브라우저 호환성도 신경쓰이 부분이었다
--

이제 JSON의 등장이다. JSON 공식 사이트에서 JSON을 소개하는 문구를 가져와 본다
JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write

JSON은 텍스트 포맷보다 훨씬 효과적으로 데이터를 구조화 할 수 있다
JSON은 XML 포맷보다 가볍다. 그리고 가독성이 좋다
바꿔 말하면, JSON 은 텍스트만큼 가볍고 XML만큼 구조적이다
그리고 JSON 은 자바스크립트에 근간하기 때문에 웹 환경에 더욱 적합하다

Ajax, 웹 Open API 등 웹 환경에 JSON 이 대세인 이유가 조금은 설명되었을 것이다


JSON 사용하기
JSON 은 그 장점에 비해 사용법은 매우 심플하다
기본적으로 알아 둬야 할 것은 JSON은 (규칙이 있는) 텍스트 포맷이며 유니코드 인코딩이란 점이다

그리고 가장 기본적인 형태는 중괄호 안에 정의된 키:값 형태이다.
다수의 객체를 정의하기 위해서는[](대괄호)를 사용하며 배열요소는 ,(꼼마)로 구분한다.
JSON으로 숫자, 문자, 참/거짓, null, 객체, 배열등을 표현할 수 있다

다음의 코드는 id, age, blog 라는 속성을 가진 회원(user) 정보를 JSON 포맷으로 단일 객체와 객체 배열로
정의하고 자바스크립트로 핸들링 하는 예이다

그리고 JSON이 자바스크립트 구문에 근간하기 때문에 다음과 같이 eval 을 통해 일반 문자열을 JSON 객체로 변환할 수 있다. 대부분 시나리오에서 JSON 객체를 문자열로 전송하고 수신측에서는 이를 JSON객체로 변환
하여 사용하게 된다

 
마이크로소프트 닷넷과 JSON
여러 언어들에서 JSON 포맷을 지원하기 위한 API들이 제공된다
닷넷을 사랑(?)하는 필자가 가장 먼저 언급할 것 역시 닷넷의 JSON 지원이다
닷넷 프레임워크에서는 System.Runtime.Serialization.Json.DataContractJsonSerializer 라는 클래스를 통해
닷넷 객체를 JSON 객체로 변환하거나 JSON 객체를 닷넷 객체로의 변환을 지원한다

다음의 블로그에서 자세한 정보를 얻을 수 있으니 참고 바란다
http://blog.naver.com/dotnethelper/60103536438

그리고 Json.NET 라이브러리도 있으니 참고 바란다

다양한 언어들을 위한 JSON 파서
JSON이 워낙 유명(?)하기에, 닷넷과 같이 프레임워크 차원에서 JSON 을 지원하는 경우도 있고 Json.NET과
같이 외부 라이브러리로 존재하기도 한다

http://www.json.org 에서는 각종 언어별로 제공되는 JSON 파서의 링크를 제공해 준다
상황에 맞는 라이브러리를 참고하기 바란다

참고로 자바스크립트의 eval 을 통한 변환은 예기치 않은 보안 문제가 발생할 수 있으므로
이들 파서의 사용은 더욱 권장된다

마이크로소프트의 닷넷을 기반으로 웹 응용프로그램을 개발할 땐 비주얼스튜디오만 있으면 된다
개인적으로 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

코드를 알아 보기 힘들게 만드는 것을 '코드 난독화' 라고 한다
닷넷이나 자바와 가은 가상머신 기반의 프로그램은 컴퓨터가 직접 해석할 수 있는 네이티브 코드 생성 이전에 중간언어과정을 거치게 되어 있다

이러한 중간언어는 '디스어셈블러' 같은 툴로 다시 원 코드로 복원시킬 수 있다
이렇게 되면 배포된 프로그램의 소스를 쉽게 읽을 수 있기 때문에 코드 낙독 처리를 통해 소스의 가독성을 떨어뜨려 소스를 보호하게 된다

특히나 웹의 경우 소스는 여지없이 공개되는 구조이다
HTML, CSS 는 물론이고 자바스크립트 코드도 모두 공개되는 구조이다

자바스크립트 패킹은 일종의 소스 보호 차원에서 스크립트 코드를 난독화하고 더불어 소스를 압축 및 최소화하여 다운로드 속도도 향상시켜 주기 때문에 많은 곳에서 적용하고 있다

이 블로그에서 소개한 Raphale 과 같은 라이브러리도 아래와 같이 패킹되어 있다

확실히 웹 기술을 둘러싼 주변 환경은 변화하고 발전하고 있음을 느낀다
훌륭한 오픈소스 라이브러리가 속속 등장하는 것만 봐도 실감할 수 있다

지금 소개할 Raphael 역시 MIT라이센스를 따르는 자바스크립트 벡터 라이브러리이다
http://raphaeljs.com/

SVG와 VML을 이용하여 웹에서 벡터그래픽을 표현한다
객체 및 함수로 추상화가 되어 있어 사용법을 익혀 쉽게 이용할 수 있다

Raphale 라이브러리는 문서화가 잘 되어 있어 사용법을 익히는데 큰 도움이 된다
사이트의 문서를 보면 각 그래픽 요소에 따른 설명과 사용법, 결과 화면등이 체계적으로 제공되어 학습 및 적용하기에 매우 편리하다

Raphale 사이트에서 모든 정보를 얻을 수 있다
중요한 것은 이제 웹에서 벡터 그래픽을 보다 쉽게 그리고 안정적으로 (그리고 무료로) 구현할 수 있게 되었다는 것이다

참고로 IE (6이상) 를 포함한 대부분의 브라우저를 지원한다는 것도 큰 장점이다

아이폰에서 플래시가 구동되지 않는 것은 꽤 오래된 이슈이다
지금 소개하는 Gardon이라는 라이브러리 역시 공개된지 꽤 되었다

Tobias Schneider 라는 외국의 한 개발자가 만든 이 라이브러리는
플래시런타임 없이 순수 자바스크립트(& SVG) 만으로 플래시를 구동시켜 주는 오픈소스 라이브러리이다

플래시런타임에 비해 기능이나 실행 속도면에서 부족한 면이 있지만,
아이폰과 같이 플래시를 지원하지 않는 환경에서 플래시를 구동시키기 위한 훌륭한 대안이 될 수 있다

다음의 github 사이트를 통해 라이브러리의 소스가 제공된다
http://github.com/tobeytailor/gordon

그리고 이 라이브러리를 이용해 플래시를 구동시키는 데모는 아래 사이트에서 확인할 수 있다
http://paulirish.com/work/gordon/demos/

벡터 그래픽 기반인 플래시의 표현을 위해 SVG가 이용되었으며 플래시파일인 swf 파일을 전달하면 Gordon 라이브러리를 통해 자동 분석, 변환된다. 이때 큰 swf 파일의 분석시 실행 성능과 멈춤현상을 없애기 위해 HTML5의 Web Worker 기술을 사용했다고 한다

소스만 봐도 대략 사용법을 쉽게 알 수 있는데,
더 자세한 사용법과 Gardon의 특징을 보려면 다음의 링크를 확인해 보기 바란다
http://wiki.github.com/tobeytailor/gordon/


브라우저 지원 현황과 플래시 지원 범위
Gardon을 실무에 적용하기 위해서 먼저 점검해 봐야 할 것이 이 두가지이다
어떤 브라우저에서 그리고 플래시의 어디까지를 지원하는지 체크하는 것이 중요하다

우선 Gardon 은 모든 플래시 기능을 다 지원하지는 않는다
swf 버전 1 기능 위주로 지원이 되며 swf 버전 2 ~ 10까지의 플래시 기능은 일부만 지원된다
아래의 링크에서 Gardon이 지원하는 swf 태그를 확인하도록 하자
http://github.com/tobeytailor/gordon/wiki/swf-tag-support-table

그리고 브라우저 지원현황은 아래 링크를 확인하자
http://wiki.github.com/tobeytailor/gordon/browser-support-table

대략 테스트를 해보니,IE(8)를 제외한 사파리,크롬,파이어폭스,오페라 최신 버전에서 정상 동작한다

참고로 이 라이브러리는 MIT 라이센스로, 사용상의 문제만 책임진다면 자유롭게 이용할 수 있다

드롭 이벤트에서(onDrop)에서 외부 파일을 드롭했을 때 그 정보를 취득하기 위한
다음의 코드가 사용되며  event.dataTransfer.files[0],

이렇게 전달된 파일 데이터를 읽기 위해 FileReader(File API 중 파일을 읽기 위한 객체)를 사용했다
FileReader의 Load 이벤트에서 드롭으로 전달된 파일정보를 읽어 들여 이미지 혹은 텍스트를 DIV 에 출력하는 것이다
> 이미지 읽기: reader.readAsDataURL(file);
> 텍스트 읽기: reader.readAsText(file,"EUC-KR");

아래 그림은 데모를 실행한 결과모습인데, 텍스트 파일과 이미지 파일을 드롭한 후 또 다른 이미지 파일을 드롭하기 위해 웹페이지로 옮기는 모습니다. 전체 코드이기에 직접 실행해 보기 바란다.
소스나 기능이 최적화 되지는 않았지만 응용을 위한 기본자료로써는 충분할 것이다

이전 글에서 소개한 RGraph 와 유사한 라이브러리를 소개한다
jQuery 의 플러그인 형태로 제공되는 Visualize 라이브러리 이다

HTML5 그래픽 관련 툴을 찾던 중 알게 된 이들 라이브러리는 아주 유용하며 안정감 마저 든다
아직 표준안이 완성되지 않은 기술에 기반 라이브러리가 먼저 등장하는 점은 HTML5를 선호하는 사람에게는 매우 고무적이라 볼 수 있겠다

Visualize 역시 HTML5 의 Canvas 를 통해 차트를 표현하며 jQuery 기반으로 동작한다

RGraph 가 그래프 및 차트에 이용되는 데이터를 스크립트를 통해 RGraph 객체로 정의하는 반면,
Visualize 는 HTML 테이블에 정의된 데이터를 자동으로 분석해서 차트로 변환해 주는 특징이 있다
또한 RGraph 처럼 브라우저 호환성을 위한 장치가 마련되어 있다

직접 테이블의 데이터를 수정하면서 차트의 변화를 확인할 수 있는 다음의 링크로 이동해 보자
http://www.filamentgroup.com/examples/charting_v2/

그리고 라이브러리 소개 페이지이다
http://www.filamentgroup.com/lab/
update_to_jquery_visualize_accessible_charts_with_html5_from_designing_with/

HTML5 의 Canvas 를 이용해서 각종 그래프를 만들어 주는 라이브러리이다

비 상업적 사이트일 경우 무료로 사용 가능하다
(상업적 사이트일 경우 소정의 수수료를 요구하는 것 같다)

바차트, 도넛차트, 파이차트, 간트차트, 로즈차트 등 다양한 형태의 차트를 지원하며 도움말이 충실히 제공되어 쉽게 사용할 수 있다. 그래프 표현 뿐만 아니라 줌기능, 컨텍스트 메뉴 등록, 비동기 출력, 애니메이션 효과 등 2D 그래픽과 관련한 유용한 기능들도 구현되어 있다

그리고 예제를 보면 Canvas를 지원하지 않는 브라우저를 위한 코드 즉 IE8 의 Canvas 적용을 위한 ExplorerCanvas 와 구글 프레임을 적용하는 등 브라우저 호환성을 신경 쓴 모습이다
 
이 사이트에서 공식적으로 소개하는 브라우저 지원 목록은 아래와 같다
- Mozilla Firefox 3.0+
- Google Chrome 1+
- Apple Safari 3+
- Opera 9.5+
- Microsoft Internet Explorer 8+ (see note)

현재 시점에서(2010.09.14) 최종 릴리즈 버전으로 2010.08.28일자가 등록되어 있으며 최종 베타버전으로는 2010.09.11자가 올라와 있다.

캔버스기반의 그래프라이브러리로 훌륭한 선택이 될 수 있을것 같으며 꼭 적용하지 않더라도 캔버스를 이용한 그래픽 작업을 하는데 있어 좋은 학습 자료가 될 수 있을 것 같다
아래의 사이트에서 자세히 확인해 보도록 하자
http://www.rgraph.net/

크로스 브라우저 스토로지 (크로스 브라우저 쿠키)
HTML5 에 새로 추가된 Web Storage 는 쿠키와 유사하지만 조금 더 진보된 형태의 클라이언트 저장소를 지원한다. Web Storage 는 영구데이터를 위한 localStorage 와 세션 범위의 SessionStorage 로 나뉘어진다. 자세한 내용은 다음의 글을 참고 바란다
=> [HTML5] Web Storage

localStorage 에 관련한 다음의 질문에 답해 보기 바란다

'크롬 브라우저에서 저장한 localStorage의 값을 사파리 브라우저에서 조회할 수 있는가?'

금방 답 할 수 있으면 일단 다행(?)이다. 그럼 이 질문은 어떤가?

'IE 브라우저에서 저장한 쿠키(Cookie)를 크롬 브라우저에서 조회할 수 있는가?'

이 두 질문은 동일한 이슈를 다루고 있다. 즉 '크로스브라우저(Cross Browser)' 이슈이다
크로스 브라우저는 각기 다른 브라우저 환경을 말하며, '크로스 브라우저 가능' 이라는 말은 브라우저가 달라도 기술의 구현이나 사용은 동일(일관)하다는 의미로 해석된다

다시 질문으로 돌아가 보자
HTML5의 localStorage 까지 갈 것도 없이, 쿠키(Cookie)의 크로스 브라우저 문제를 생각해 보자. 
'각기 다른 브라우저(크롬,사파리,파이어폭스,오페라 등)에서 쿠키의 공유가 가능한가?' 하는 문제이다

좀 더 현실적인 예로 다시 풀어 보면,
'쿠키로 사용자 인증 처리를 하는 사이트의 경우 IE에서 로그인한 사용자가 크롬에서 해당 사이트에 접근했을 때 로그인이 유지되는가?' 하는 문제이다

이전에 한번이라도 이와 유사한 이슈를 경험해 본 사람은 쉽게 답할 수 있을 것이다
그러나 모르긴 몰라도 꽤 많은 사람이 헷갈려 하지 않나 싶다(이 글을 쓰는 나 역시 헷갈렸다 ㅡ.ㅡ)


크로스브라우저 쿠키의 착각, IE 의존성이 가져온 결과?
고민(?)의 발단은 이러했다
HTML5의 localStorage 를 위한 저장소는 각 브라우저별로 서로 다른, 즉 자신만의 위치에 데이터를 저장하기 때문에 '크로스 브라우저 스토로지'가 지원되지 않는다는 자연스러운(?) 결론에 이르게 되었다

그러나 한편 생각해 보면 여러 브라우저를 사용하는 사람에게는 꽤 문제가 될 수 있지 않나 싶었다
기껏 유용한(또는 주요한) 정보를 localStorage 에 저장해 뒀는데 다른 브라우저로 접근하면 사용할 수 없다는 것은 사이트 개발자는 물론 사용자의 불편을 야기시킬 수 있기 때문이다

이즈음 든 생각은, '그럼 쿠키는?' 이었다
여기서 나의 착각이 시작되었다. 순간 당연히 쿠키는 크로스 브라우저가 된다고 생각한 것이다
'쿠키는 크로스브라우저가 가능한데 쿠키의 개선 버전이라는 localStroage 가 안되다니?'
'이건 뭐 제약사항이 하나 더 늘었구만!!' 하는 어처구니 없는 착각 ^^;

하지만 웹 실무를 벗어난지 꽤 오랜 시간 되었고 이건 착각일 수도 있겠다라는 의문이 들어 테스트를 해 보기로 했다.

테스트 결과, 당연히 될 줄로만 알았던 '크로스 브라우저 쿠키'가 안되는 것이었다
음.. 이건 뭥미? 하며 잠시 멍 때린 후, 생각을 정리하기로 했다

'그래, 쿠키가 표준이지 쿠키 저장소가 표준은 아니다' 라는 것이다

즉 웹을 위한 클라이언트 측 데이터 저장소로써 쿠키라는 개념이 통용되지만 그 저장 위치는 정해져 있지 않다는 것이다. 곰곰히 생각해 보면 저장 위치를 딱 한 곳으로 표준화 할 수도 없다는 것이다

이러한 나의 착각은 어디에서 비롯되었을까? 하고 생각해 봤더니, 'IE 의존적인 개발로 인한 착각' 이라는 생각이 들었다.(물론 제대로 알지 못한 나 자신이 1차 문제인건 안다 ㅡ.ㅡ)

내가 한참 웹 개발 실무를 디테일하게 수행했던 시기는 2000년대 초반이었으며 그 당시에는 지금보다 훨씬 더 IE 의존적인 환경이었다. 웹 2.0 이라는 트랜드도 낯설었거니와 몇몇 독특한 사람을 제외하고는 거의 대부분의 사람이 IE를 사용하고 있었으며 웹 표준이라는 개념 역시 지금처럼 일반화되지 않는 시기였다. 따라서 대부분의 웹 개발은 IE 를 기준으로 작성되었으며 크로스브라우저 테스트는 거의 해 보지 않았다는 것이다. (간혹 여러개의 브라우저를 띄워서 데이터 공유가 되는가.. 하는 등의 테스트는 해 보았지만, 이것 역시 IE를 여러개 띄운 테스트가 대부분이었다)

결국 IE 의존적인 개발은, IE 에 한정된 테스트 환경에 그쳤으며 IE 적 개념이 점차 정립된 것이다
'크로스브라우저 쿠키의 착각'도 이러한 IE 의존성에서 비롯되었다라고 해도 과언은 아닐 듯 싶다
(물론 제대로 된 조직 및 개인은 그 당시에도 크로스 브라우저 테스트및 개념이 있었겠죠?
 이 글은 저의 경우, 저의 착각에 한해 예기 하는 것이니 오해 사절 입니다)

지금에야 아이폰을 필두로 한 모바일 웹의 급 부상, 이미 오래된 웹 2.0 트랜드, 웹 표준 이슈, HTML5 등장, 과거와는 다른 브라우저간 경쟁 및 발전으로 IE 의존성이 점차 해소되는 분위기이며 특히 개발자들은 더욱 다양한 브라우저를 체험하고 있다. 

사실  나 역시 모바일 웹, HTML5에 관심을 두기 전에는 거의 IE만 사용했었다
근래 들어 크롬, 사파리, 파이어폭스, 오페라와 같은 브라우저를 동시에 사용하고 있다. 
이 글 역시 여러 브라우저를 동시에 사용했기에 든 의문이며 그렇지 않다면 꽤 오랜시간 착각과 망각속에 살지 않았겠나.. 싶다


크로스 브라우저 쿠키, 크로스 브라우저 스토로지, 가능한 시나리오는 없는가?
브라우저를 넘나드는 클라이언트 데이터 저장소의 실현을 고민해 보자

크로스 환경이 필요한가를 먼저 따지자
우선 원론적인 질문을 해 보자. '브라우저 경계를 넘어서는 데이터 공유가 필요한가?' 이다
다시 말해 IE에서 저장한 데이터를 크롬에서 불어와야 되는가? 하는 것이다
예를 들어 IE에서 로그인한 사용자가 크롬에서도 여전히 로그인이 되어 있어야 하는가? 이다
매우 크리티컬한 이슈가 아니라면 적당히 양보(?)할 수도 있을 것이다
크로스 브라우저가 정말로 필요한지? 서버측 데이터 공유로 풀어도 되지 않는지? 하는 원론적인 고민을 해 보고 반드시 그럴 필요가 없다면 굳이 크로스 환경을 지원하지 않아도 된다는 말이다
그러나 반드시 크로스 환경이 보장되어야 한다면 다음 글로 넘어가자

브라우저마다 각각 저장하자
불편하기는 하지만 가장 심플한 해결책이다
매번 브라우저에서 쿠키가 존재하는지 검사하고 없다면 쿠키를 기록하는 것이다
예를 들어 IE에서 쿠키를 저장하고 크롬에서 쿠키를 읽어 올때 존재하지 않는다면 다시 쿠키를 기록하도록 하는 것이다. 다른 브라우저도 마찬가지로.
사용자 인증 시나리오에서 이 기법이 적용된다면 사용자는 브라우저를 교체할 때 로그인을 다시 해야 하는 불편은 감수해야 한다. 그러나 용납할 만한 수준이지 않는가
(이 시나리오는 HTML5 localStorage에도 그대로 적용된다)

플래시의 Shared Object 를 이용하라
플래시에는 클라이언트 측 데이터 저장과 공유를 위한 Shared Object 라는것이 존재한다
플래시 런타임은 브라우저와는 별도의 플러그인 환경이기 때문에 브라우저가 달라진다고 해서 문제될 것이 없다. 다만 플래시 런타임이 브라우저에 설치되어 있어야 한다는 문제가 있다
웹 표준, 특히 아이폰과 같은 모바일 환경에서는 무리수 일 수 있다는 것이다

PersistJS 라이브러리를 이용하라
Paul Duncan 이라는 사람이 만든 라이브러리이다. 클라이언트 측 자바스크립트 영구 저장소를 구현한 것이다. 플래시 플레이어와 같은 별도의 플러그인이 필요 없으며 크로스 브라우저를 지원하는 API가 제공된다. 이 라이브러리를 직접 이용해 보진 않았지만 아마 locaStroage나 Shared Object 와 같은 기존 스토로지 솔루션에 기반하여 데이터를 저장하며 크로스 브라우저를 위한 자동화된 처리가 포함된 듯 하다. 관심 있는 자 테스트 해 보기 바란다. 아래 주소에서 라이브러리 다운로드 및 확인이 가능하다.
http://pablotron.org/?cid=1557