2006년도에는 그동안 주요포탈과 전문인터넷만화사이트를 중심으로 형성되던 인터넷만화유통채널이 다양화되기 시작한다.

그래서 조선일보나 동아일보, SBSi 같은 미디어포탈, 소리바다, 버디버디, pdbox, 프리첼 등과 같은 커뮤니티사이트에서도 활발히 인터넷만화가 유통되기 시작했다. 물론 종전에도 회원들에 대한 서비스차원에서 만화콘텐츠가 제공되기는 하였으나, 2006년이 본격적인 만화콘텐츠 유통에 나서는 원년이라고 할 수 있을 것이다.

특히 게임포탈들 중에서 넷마블과 같은 대형게임포탈들에서 본격적인 인터넷만화서비스를 하게 되었다.

사실 우리 회사의 만화전용뷰어는 만화전용압축프로그램을 사용하기 때문에, 위와 같이 본래의 기능에 부가되어 서비스되는 솔루션으로서 적합한 장점이 있었다. 왜냐하면 게임도 하고 음악도 들으면서 만화도 볼수 있기 위해서는 빠르고 가벼운 뷰어만이 가능하기 때문이다.

덕분에 우리 만화전용뷰어는 빠르게 미디어 및 엔터테인먼트 포탈의 주요만화뷰어로서 자리잡게 되는 계기가 되었다.

이와 같이 만화유통채널이 다양화되면서, 솔루션을 공급하는 회사나 유통회사 모두 다양한 시장현상을 접하게 되는 계기가 되기도 한다. 약 1-2년 뒤에 나타날 일들이지만, 만화의 성격에 따라서 독자층의 확보가 차별화 되는 현상이 생기게 된 것이다.

결국 인타넷만화의 유통이 급격히 주요포탈로 집중되다가, 다양한 채널로 옮겨 가는 계기가 되는 시발점이 우리 뷰어솔루션의 간편하고 빠른 기능때문이라고 자부하는 이유이다.  

북한에서 인공위성이니 미사일이니 하는 것을 쏜다고 난리를 쳐도, 우리는 그저 박모라는 기업인이 뿌린 돈을 어느 정치인이 얼마 받았는지만이 주요 관심사다.

사실 북한 정도의 소규모 국가가 아무리 미사일 아니라 핵폭탄을 가지고 있다고 한들 대세에는 큰 문제가 없다고 판단할 수 있으니 그럴만도 하다. 물론 죽기살기로 덤빌 경우의 리스크는 만만치 않겠지만, 그럴 경우 받는 강도는 우리보다는 북쪽이 심할 것이니, 최소한 전략적으로는 그리 큰 위험이 되지 않는다고 판단하는 것이 맞을듯 싶다.

그래서 그런지 국가의 안위를 다루는 문제보다는, 우리 정치인들의 타락상을 들춰 내는 것이 우리의 주요관심사가 되고 있으니, 한번 봐 달라고 안달복달하는 북한아이들의 입장에서는 어의가 없을 법도 하다.

그런데 이번에 정치자금스켄들에는 어느 정도 종전과 다른 측면이 있다.

우선 그전에는 사실 구체적인 의도와 목적을 가지고 검은 돈을 주고 받았다고 봐야 한다. 그래서 부도덕한 것이 문제가 아니고, 불법이 문제였던 것이다.

하지만, 이번 사례는 말 그대로 불특정 다수에게 그냥 뿌린 편에 속하고, 받는 사람 역시 그냥 받았다고 봐야하는 측면이 있다. 물론 전혀 의도가 없었던 것은 아니지만, 그 강도와 방향이 그리 명확하지 않은 포괄적인 향음이었다는 측면이 강하다.

말 그대로 낚시 하기 전에 습관적으로 물에다가 밀밥을 뿌리는 것과 같은 식이다. 내가 구체적으로 어느 물고기를 잡기 위한 것이 아니고, 그저 물고기를 잡기 위한 예비동작 쯤이라는 것이다.

또 다른 표현을 하면, 마치 돼지 우리에서 돼지 들에게 그냥 습관적으로 사료를 뿌리는 것과 똑같다. 그래서 나는 이번 사태를 사육당하는 정치인이라고 표현하는 것이 적합하다고 판단하는 것이다.

따라서 받는 사람들 역시 그냥 정치적인 의도가 있기는 하지만, 통상적인 후원금보다 조금 신경쓰이는 정도로 생각했을 가능성이 컷을 것이다.

그런데 문제는 여기서 생긴다. 정해진 통로를 통해서 들어오는 정치자금은 그나마 정치적 행위에 소요될 것으로 판단된다. 그러나 이와 같은 돈은 그냥 꿀꺽하는 돈일 가능성이 크다. 그렇기  때문에 물고기가 밀밥에 꼬여 모이듯, 돼지가 특별사료의 향기에 꼬여 꿀꺽하듯, 아마도 아무 생각없이 먹어 치웠을 것이다.

그 많은 돈들은 그들이 밀밥이든, 미끼든 그들이 정치인이기 때문에 던졌다는 것으로 생각할 수 있다. 그렇기 때문에 정치자금이고, 이 불법자금들이 오히려 정식 정치자금보다는 더 영양가 있었다고 생각할 수도 있었을 것이다.

사육 당하는 것이 아니고, 교활하게 사육당하길 원하는 것이다. 우리 정치인 들이 그렇게 돈에 궁하도록 형편이 어렵게 만들었다면 고칠일이지만, 그렇지 않다면 반드시 초기에 엄격하게 고칠 필요가 있는 이유이다.

그래도 최소한 공명심과 명예 때문에 돈을 받고 정치하는 것을 부끄러워 하는 것이 상례다. 그래서 돈에 얼키는 것을 가장 부끄럽게 생각한던 정치인들이다. 한마디로 부도덕하다고 생각했기 때문이다.

그런데 최근 양상은 전혀 틀리게 전개 되고 있음을 알게 된 것이다.

즉 정치인들의 생태계가 사육당하기를 은근히 바라는 교활한 세상으로 바껴 가고 있기 때문이다. 니편 네편, 이것 저것 가리지 않고 무차별 살포하고 무차별로 받아 먹는 혼돈의 마당으로 바꿔 가고 있는 것이다.

스스로 자기네들 모두를 수렁텅이로 몰고 가서, 너도 진흙 묻었고, 나도 흙탕물을 입히는 자해의 현장, 그것이 지금 정치인들의 막가파식 생존방식인 것이다.

이 먹이와 사료만 쫒는 돼지 같은 자식들을 어떻게 해야 할 까요.

Flash CS3가 나온 기념으로 얼마전 새 이름을 가진 SilverLight(=WPF/E)도 요즘 열심히 뽐뿌질 중입니다.
뭐 RIA에서 Adobe와 MS가 충돌할 분야가 꽤 여러분야지만 일단 가장 먼저 충돌할 것으로 예상되는 웹브라우저 환경에서의 RIA... 특히 Flex와 WPF를 비교해보렵니다.

Flex는 릴리즈된지도 꽤 됐고 많이 알려졌으므로 Flex를 기준으로 WPF가 다른점을 설명해보도록 하겠습니다.

1. Publishing이 필요없습니다.
   아시다시피 Flash(Flex)는 MXML이나 FLA소스파일이 SWF라는 바이트코드로 퍼블리싱되어 플레이어가 실행하는 방식입니다.(뭐 FDS라는 2천만원짜리 서버를 도입하면 가능하죠..--;;) 하지만 SilverLight는 Javascript　로 직접제어가 가능합니다. 뭐 물론 XBAP같은건 컴파일도 해야하고.. Flash로도 ExternalInterface로 연동 인터페이스 같은거 만들어주면 JScript　 연동이 가능하지만.. SilverLight는 더욱 직관적으로 코딩 가능하다는 점이 다릅니다. 따라서 기존 개발자들이 접근하기 쉬우며 기존 서드파티 Jscript　 개발툴로도 개발가능하며 일일히 Publish할필요가 없으므로 디버깅이 쉽다는 장점이 있습니다.
   
2. 도입 가격이 쌉니다.
   Flex의 뛰어난 기능을 더욱 활용하려면 FDS를 도입해야하는데 2천만원이 넘죠.. FDS와 비슷한 거라면 .NET 3.0의 WCF를 들 수 있는데.. 아시다시피 .NET 3.0은 무료입니다. 다만 .NET개발툴(VS.NET)이 비싼것이 문제인데, 따지고 보면 Flex를 도입하려는게 서버데이터 연동이 큰 이유일텐데 서버를 닷넷으로 구현하면 어짜피 구매해야할 VS.NET이죠.. 하지만 서버를 Java로 구현한다면 FDS도입도 좋은 선택일것 같습니다.
   
3. 개발 생산성에 이점이 있습니다.
   예를들어 WPF(Windows Application)나 XBAP이나 SilverLight는 XAML과 C#만 알아도 모두 개발 가능합니다. 하지만 Apollo나 Flex나 Flash를 개발하려면 MXML AS3.0 Java를 모두 알아야 합니다. 즉 엔터프라이즈 급 프로젝트에서 인력확보가 용이할 수도 있다는 것은 큰 장점일것 같습니다.
   
4. 마우스 오른쪽 버튼 활용이 가능합니다.
   좀 쌩뚱맞은 생각이지만 RIA환경에서 마우스 오른쪽 버튼의 활용가치는 참으로 무궁무진 하지만 Flash는 마우스 오른쪽 버튼의 기능을 ContextMenu를 활용하는것 외엔 원천적으로 봉쇄했습니다. 하지만 WPF(SilverLight제외)에선 마우스 오른쪽 버튼도 활용가능합니다.

이상 개인적으로 느낀 Flex에 비해 WPF의 대표적인 장점입니다.. 
단점은 솔직히 Flash라는게 고유명사화 될정도로 익숙해진 프로그램이라는 것인데 (심지어 Flash도 ActiveX라는걸 종종 까먹을 정도...) 이러한 홍보로 인한 단점정도는 MS의 파워로 봐선 우스울 것으로 보입니다.
그 외에 WPF의 가장 큰 단점으로는 디자이너를 위한 툴(blend, interactive Designer 등)이 너무 허접했으므로 디자이너 인력확보를 어떻게 할거냐고 데브피아에 혹평한 적도 있습니다만.. AI to XAML이나 SWF to XAML 같은 프로그램들이 홀랑 나와버려서 디자이너가 새로운 툴을 구매하거나 공부할필요도 없어져버렸습니다..

하여간 뭐 논란이야 어쨌든 애니메이션 업계는 Flash가 독점할것은 확실해 보이고...(Silverlight가 아직 릴리즈 되진 않았지만.. Flash에 비해 한~~참 딸리더군요..) Flex가 열심히 파이를 키워놓은 RIA시장을 과연 얼마나 뺏어먹을것인가 점점 궁금해 집니다..

.net과 flash를 둘 다 쓰는 저로선.. 개인적으로 WPF가 당연히 좋아보입니다. 위에 언급한 4가지 장점은 말할것도 없거니와... WPF에선 Flash9.ocx를 참조해서 Flash컨트롤 까지 쉽게 가능하니까 뭐 말 다했죠...ㅎㅎ

참고로 .NET 3.0의 WPF에 대해 잘모르시는 분들을 위해 비슷한 것들을 비교한다면..
WPF의 Windows Application 는 Java Application or Apollo와 비슷하다 할 수 있고...
WPF의 XBAP(XAML Browser Application)은 Java Applet or ActiveX와 비슷하다 할 수 있고...
WPF의 Silverlight는 Flash(특히 벡터그래픽 구현부분만)나 SVG와 비슷하다 할 수 있을것 같네요..

이 글과 관련있는 글을 자동검색한 결과입니다 [?]

• 편파비교 WPF/Sliverlight vs Flash/FLEX 라니.. by 꼬출든남자
• 윈도우 비스타에서의 WPF (야후메신저) by 미니
• wpf/e 드디어 이름을 얻다. silverlight by 김명신
• Flash CS3 5분 사용기 by 귀뫄뉘
• Microsoft SilverLight은 Flash의 대항마일까? by NoPD

이 글은, 웹 창시자인 팀 버너스리가 IE8에서 SVG를 지원하지 않는다고 불평한 것에 대해 SVG를 지원하지 않음으로 사용자에게 큰 불편을 끼치고 있다고 말하는 디자인로그의 포스트에 대한 반박글 입니다.

SVG에 대해서는 차니님의 글에서 자세하게 다루어진 바가 있습니다.

IE8이 어도비에 너무 의존한 나머지 SVG 기술을 자체적으로 지원하지 않아서 IE의 그래픽 처리 기술이 가장 뒤떨어 진다는 것처럼 말하고 있지만... 플래시나 실버라이트, 자바 애플릿 등의 주요 RIA 및 그래픽 처리 기술은 플러그인 기반으로 크로스 브라우징을 기본적으로 지원하도록 제공되기 때문에 브라우저간 그래픽 처리 기술이 특정 기술 지원 여부에 따라서 평가 하는 것은 잘못된 처사라고 생각합니다.

제가 최근 몇 년간 현업에서 웹 개발자들과 일하면서 느낀 바로는 SVG가 죽은 기술이라고 말할 정도로 점점 더 무대 뒤로 사라지고 있다는 점입니다. SVG에 일부 포함된 스펙(PGML)을 개발했던 어도비에서조차 앞으로 SVG 플러그인의 지원을 하지 않는다고 하는 상황입니다.

이러한 SVG의 지원 문제는 브라우저의 탑재 문제라기 보다는 SVG 기술 자체의 생태계와 더 밀접한 연관이 있습니다. SVG와 마찬가지로 플래시도 플러그인 형태이기 때문에 IE8에서는 설치를 해야 함에도 불구하고 SVG와는 설치율에서 극명한 차이를 보이는 것은 왜 그럴까요?

그 이유는 플래시 개발자와 디자이너 들이 현업에서 새로운 웹 플랫폼을 받아들이고 전파하기 위해서 수많은 노력을 해왔기 때문입니다. 지속적인 플러그인 버전 관리와 생산성을 높이는 저작툴의 개발 및 교육도 필요하지요. 실버라이트를 전파하기 위해 IE8나 윈도에 강제로 탑재하지 않는 것도 기술이 스스로 살아남을 수 있는 기반 생태계(ecosystem)를 중요하게 생각하기 때문입니다.

SVG에 비해 덜 개방적인 플래시 컨텐츠는 그 동안 오랫동안 문제점으로 제기되어 왔는데 실버라이트의 XAML과 같은 구조는 XML 기반으로 컨텐츠 내용이 코드 형태로 공개되는 SVG의 개방적인 특징도 가지고 있습니다.

마지막으로 해당 포스트는 아시아 경제의 기사 내용과도 너무 흡사하네요. 작성 시간도 2시간 밖에 차이가 나지 않고 짜집기 한 것이 아닐까 싶을 정도로 같은 말을 순서만 바꾼 것에 지나지 않고요. 원본의 출처도 밝히지 않고 자신의 생각이나 의견인 것처럼 말하는 블로그 운영은 문제가 있다고 생각합니다.

저자: 딘 잭슨(Dean Jackson), 역 전순재

편집자 주 - 오라일리의 웹 개발센터에서 추구하는 목표는 (오픈 소스와 독점 테크놀러지 모두에 대해) 독자에게 가치 있는 웹 테크놀러지에 대한 균형잡힌 시각을 제공하는 것이다. 점점 더 오픈 소스와 독점 테크놀러지 사이의 경계선이 모호해지고 있다. 이는 어도비 고라이브(Adobe GoLive)와 같이 압축 포장된 애플리케이션들이 아파치나 PHP 같은 오픈 소스 도구들을 합체하고 있기 때문이다.

최근들어 「SWF는 플래시가 아니다」라는 기사에서 우리는 매크로미디어(Macromedia)사의 제품인 플래시(Flash) 테크놀러지의 장점을 부각시켰다. 이에 대해 XML 공동체는 위 기사에 대한 답변으로 SVG의 강점을 기술한 본 기사를 신중하게 내놓았다. 모쪼록 기분좋게 즐기기를 바라며 벡터 그래픽과 관련하여 진행중인 이 대화에 계속 참여하기 바란다.

SVG - 미래의 벡터 그래픽 (미래는 지금 현재이다)

제이섹 아트미액(Jacek Artymiak)의 기사인 「SWF는 플래시가 아니다」는 플래시와 그 파일 포맷인 SWF에 관한 오해를 불식하기 위한 시도였다. 이 기사는 계속해서 웹 상에서의 벡터 그래픽을 위한 포맷에 대한 논의를 SVG를 중심으로 진행했다. 사용자 중개자(user agents)의 지원, 저작 도구, 다른 표준과의 통합과 같이 어떤 그래픽 포맷을 사용해야 하는지와 관련해서 사람들이 자주 묻는 질문들을 조사해 볼 것이다.

이 방법과 함께 제이섹(Jacek)이 제기한 몇몇 논점들을 확대하여 명확하게 이해되지 못한 SVG의 측면을 설명하는 기회를 가져 보겠다. 그리고 제이섹(Jacek)이 SWF에 대한 편견을 인정한 것과 마찬가지로, 나 역시 SVG 작업 그룹에 몸담고 있으므로 틀림없이 SVG를 옹호하는 입장에 서게 될 것이다.

SVG의 짧은 역사

시작하기 전에 보다 높은 수준에서 웹 상에서의 벡터 그래픽의 세계를 바라보고 싶다. 지난 몇 년간 웹은 벡터 그래픽과 애니메이션에 관심이 있었다. 1999년 월드 와이드 웹 컨소시엄(W3C, World Wide Web Consortium)은 신축적인 벡터 그래픽(SVG, Scalable Vector Graphics)이라고 부르는 개방된 포맷을 개발하기 시작하였다. W3C가 2001년 9월에 발표한 SVG 1.0 스펙은 매크로미디어(Macromedia)의 SWF와 똑같은 그래픽과 애니메이션 기능을 제공할 뿐만 아니라 덤으로 다른 이점도 얻을 수 있다.

		SVG Essentials

XML 어플리케이션으로서 SVG 1.0은 SWF보다 다른 웹 테크놀러지와 더 잘 통합된다. SVG 1.0 권장안은 각 업계로부터 상당한 지지를 얻었다(Adobe, Apple, Canon, Corel, Hewlett-Packard, Macromedia, Microsoft, Kodak, Sun 그리고 다른 많은 회사들이 규격에 공헌하였다).

SVG 작업 그룹은 계속해서 SVG를 개선하고 있다. 웹 공동체의 요구에 맞추어 새로운 특징을 개발하고, 개발자들을 도와 테스트 모음(test suites)을 배포하고 모바일 장치를 위한 프로파일(profiles)을 개발하고 있다.

SVG의 인기가 상승함에 따라 SVG와 SWF를 포함한 다른 포맷들 사이에 선택의 기로에 서게 될 수도 있다. 이 기사에서 지금부터는 더욱 자세히 들어가 SVG의 특징들을 논의하고, 뿐만 아니라 저작도구와 사용자 중개자의 지원에 관한 현재 진행 상태에 대해서도 논의하겠다.

SVG는 어디에서나 친구를 사귀고 있다

종종 필자는 SVG를 사용하기 시작한 개발자들이 보내준 긍정적인 피드백(feedback)의 수준에 놀라움을 금하지 못한다. 몇몇 이유들, 예를 들어 다른 표준과의 통합 및 순응에 대해서는 나중에 설명하겠다. 단지 개발자들만 감동 받은 것은 아니다. 산업계의 주자들(industry players)도 표준화 작업과 소프트웨어 개발, SVG 컨텐츠의 배포에 적극적으로 참여함으로써 자신들의 지원 의지를 보여 주었다. 그렇지만 제이섹(Jacek)은 아직까진느 SVG가 널리 인정받기를 기다리고 있는 입장에 있다고 말했다(현재 모든 주요 브라우저가 기본으로 지원하고 있지만 말이다). 나는 이점에 대해 다음과 같이 세 가지 방식으로 접근해 보고자 한다.

첫째, SVG 표준 자체가 승인되었다. W3C 구성원들은 투표를 통해 SVG를 W3C 권장안으로 선언했다(업계 거물들이 점차적으로 추천하고 있으며 예전 추천 역시 읽어 보면 흥미롭다).

표준 승인에 도달하기까지 SVG는 완벽한 구현 테스트를 거쳐야 했으며(즉, SVG의 면모 하나하나가 모두 뷰어(viewer)에 구현되어야 했다), 수 많은 대중들로부터 피드백 요청을 받아야 했다. 경쟁관계에 있는 회사들이 모두가 서로 동의할 수 있는 표준을 만드는데 합의하고 있다면 그 표준은 누구에게나 개방되어야 하며 서로 경쟁적으로 그 표준을 제품으로 구현해야만 비로서 인정 받을 수 있다.

둘째, 사람들은 SVG 컨텐츠를 볼 수 있으며 직접 보고 있다. 다양한 SVG 뷰어가 구현되어 있기 때문이다. 가장 인기 있는 뷰어는 어도비(Adobe)사의 브라우저 플러그-인/ActiveX 콘트롤이다. 어도비는 마이크로소프트사가 지원하는 모든 윈도우 버전(98, 2000, Millennium, 그리고 XP)은 물론이고 매킨토시 OS 버전 8.5 에서 X까지, 리눅스, 솔라리스에 자사의 뷰어를 배포했다. 어도비 뷰어는 인터넷 익스플로러, 넷스케이프, 모질라, 오페라를 포함한 많은 브라우저에서 실행된다.

다른 구현에 대해 설명하자면 이미 SVG를 브라우저의 일부로 구현하려는 모질라 프로젝트가 있다. 내가 아는 한 브라우저가 지원하는 유일하게 인기 있는 벡터 포맷은 SVG뿐이다. 상당히 완성된 구현으로 아파치 배틱(Apache Batik) 프로젝트가 있다. 이 프로젝트는 오픈 소스이다. 뷰어의 구현이라는 주제와 관련하여 더 자세한 정보가 필요하면 앤토인 퀸트(Antoine Quint)의 기사 「SVG: Where Are We Now?」를 보면 알 수 있다. 물론 그 기사가 좀 오래된 기사이기는 하지만 말이다. 이처럼 역사는 끊임없이 진화해 가는 것이다.

배포 상황은 어떤가? 어도비는 자사의 SVG 뷰어 배포가 1억 5000만부를 넘어섰다고 공식 발표를 하였다. 그리고 이것은 오늘날 구현되는 수 많은 SVG 중에 단지 한가지 구현일 뿐이다. 참고로 어도비 SVG 뷰어는 어도비 아크로뱃 리더(Adobe Acrobat Reader)에 포함되어 있다. 그리고 조만간 리얼 플레이어(Real Player)에도 포함될 것이다.

셋째, 저작 도구들을 사용할 수 있다. 이미 SVG를 저작하거나 익스포트 수 있는 훌륭한 데스크탑 도구들이 나와있다. 여기에는 어도비 일러스트레이터(Adobe Illustrator), Jasc WebDraw, CorelDraw!, ILOG Jviews; MayuraDraw가 있으며 이러한 도구 목록은 나날이 늘어가고 있다. 그렇지만 공정히 말해 아직까지는 어느 도구도 매크로미디어 플래시의 인기에 필적하지 못한다. 표준이 이제 널리 알려졌기 때문에 오히려 이 사실은 도구 개발자들에게 커다란 기회를 뜻할 수도 있다. 그리고 다양한 벤더로부터 터져 나올 SVG 저작 도구의 홍수를 기대할 수 있는 가능성도 더욱 높다. 여담이지만, 만약 매크로미디어 플래시가 오늘날 SVG를 엑스포트했다면 플래시는 가장 훌륭한 SVG 저작도구중의 하나가 되었을 수도 있다.

이 분야가 바로 SVG가 절실히 지원을 필요로 하는 영역이다. 하지만 한편으로는 성장하는데 많은 시간이 걸리는 전형적인 분야이기도 하다. 또한 일상적으로 사용하는 텍스트 편집기를 기억하자. 이미 노트패드(Notepad), 이막스(emacs), vi와 같은 편집기는 SVG 저작 도구가 되었다. 또한 선택적으로 XML 편집기를 사용하여 SVG를 편집할 수도 있으며 그렇게 할 경우 이미지가 잘 형성된(well-formed) XML임을 확신할 수 있다.

서버 쪽에서는 SVG 컨텐츠를 만들어 내는 애플리케이션이 빠르게 성장하고 있다. 어도비 얼터캐스트(Adobe AlterCast), 아파치 배틱(Apache Batik, 자유이며 오픈소스), 코렐 딥화이트(Corel deepwhite)가 바로 그 예이다.

웹 공동체는 어떤가? SVG 공동체가 이미 형성되어 점점 성장하고 있다. 만약 SVG를 논의하는 저명한 포럼을 찾고 있다면, 야후! 그룹의 svg-개발자 리스트를 권한다. 7월에는 거기에서 SVG 컨퍼런스도 있다. 이는 승인의 또다른 표시이다. SVG의 인기는 날로 성장하고 있으며, 새로운 구현이 나올 때마다 점점 더 인기가 치솟는다.

인간의 판독가능성은 개발자들에게 쓸모가 있다

제이섹(Jacek)이 주장대로라면 인간이 꼭 그래픽을 읽을 수 있어야 하는 건 아니라고 한다. 이 주제에 관한 나의 의견은 아주 간단하다. 인간이 그래픽을 읽을 수 있다는 것은 정말 좋은 점 중에 하나이다. 그리고 이것이야말로 SVG가 가지는 가장 훌륭한 특징중의 하나이다. 왜인가? 만약 개발자들이 HTML 페이지를 볼 수 없고 그 결과를 읽을 수 없었다면 오늘날 웹이 어디 흥미 근처에나 갔었겠는가?

아주 초기부터 개발자들은 기존의 HTML과 자바스크립트를 분석해오면서 새로운 컨텐츠 작성법을 배우고, 기존 컨텐츠를 개선하여 더 좋은 웹을 개발해오고 있다. 그리고 SVG는 의도적으로 같은 모델을 따르고 있다.

플래시 디자이너인 Praystation.com의 조슈아 데이비스(Joshua Davies)는 자신의 소스 코드를 배포한 것으로 유명하다. 그리고 전세계의 개발자들이 그의 용감한 행동에 기뻐했다(그 결과들은 판독할 수 있으며, 비인간적이지만 이진 포맷으로 전달됨). 의도적으로 모든 SVG 그래픽은 자신의 소스를 볼 수 있게 해놓았고 사람들이 그 소스를 읽을 수 있도록 해놓았다. '소스 보기'를 통해 개발자들에게 힘을 실어넣은 것이다.

인간의 판독가능성은 컨텐츠 창조자나 개발자에게 뿐만 아니라 접근가능성에도 수 많은 혜택을 준다. 제이섹(Jacek)은 이렇게 묻는다 "SVG 코드를 뚫어지게 째려 보면 이미지가 가지고 있는 메시지를 더 이해하기 쉬운가?" 그 대답은 확실히 말해 '그렇다'이다! SVG 이미지 안에 있는 텍스트는 이것이다. 바로 텍스트이다.

누구든지 텍스트를 읽을 수 있으며, 어디에 있는지, 어떻게 렌더링 될 것인지는 그저 소스 코드를 쳐다보기만 해도 알 수 있다. 네 개의 바퀴, 몸체, 문 몇 개, 그리고 좌석으로 기술되는 이미지는 아마도 운송수단을 떠오르게 한다. 어느 이유에서든 그 이미지를 보는데 문제가 있는 사람은 그 소스만 읽어 보아도 그 의미를 알아볼 기회를 얻을 수 있다. 또 다른 예로 사용자 스타일시트를 들 수 있다. 사용자가 색맹이기 때문에 그래픽을 볼 수 없다고 하자. 그들은 소스를 읽을 수 있기 때문에 사용자 스타일 시트를 작성하여 그래픽에 있는 색깔을 쉽게 덮어쓸 수 있다.

XML-파워 그래픽은 의미가 있다

이제 XML이 세상의 모든 문제들을 해결할 수 있다는 것은 누구나 알고 있다! 솔직히 XML을 사용하여 그래픽을 조판(mark up) 하는 것은 XML을 사용하여 텍스트 데이터를 조판할 때 얻는 혜택과 거의 같다. 그 혜택이란 의미구조(semantics)에 관한 것이다. 그래픽 또는 그 그래픽 안에 존재하는 조각들 역시 다른 어떤 문서와 마찬가지로 의미구조적 의미를 똑같이 가질 수 있다.

물론 그 이미지를 (예를 들어, 원, 선, 사각형과 같은) 그래픽적인 원자성분으로 조판한다면 의미구조를 언제나 그 정도로 부여할 수 없을지도 모르겠지만 그래도 무언가를 덧붙일 수 있다. 의미구조(semantics)를 가진 구조는 접근가능성을 높여준다. 그리고 XML이 지금현재 웹을 점령한 구조화된 포맷이기 때문에 엄청나게 많은 도구들을 얻을 수 있기 때문에 무상으로 그 구조를 다룰 수 있다.

SVG가 XML이기 때문에 훨씬 더 쉽게 의미구조적 의미(semantic meaning)를 부가할 수 있는 기회가 있다. RDF나 다른 XML 메타데이터 포맷을 사용하면 이미지를 부분별로 기술할 수 있으며 각 부분에 대하여 XHTML 설명을 포함시킬 수 있다.

이 외에도 여러분 소유의 맞춤 네임스페이스(custom namespace)에 데이터를 추가하여 원하는 것은 무엇이든지 기술할 수 있다. 메타데이터가 더 있는지 없는지, 그래픽을 원래의 데이터 표현으로 되돌리는 세부 방법이나 이 그래픽에서 저 그래픽으로 변환하는데 사용될 수 있는 데이터가 무엇이든지 간에 자세히 기술할 수 있다. 제이섹(Jacek)이 말했던 것처럼 이미지에 대한 '막다른 종착역'은 아니다. XML의 도움을 받아 풍부한 컨텐츠가 사용자에게 정확하게 모두 배달된다는 것을 확신할 수 있기 때문에 XML은 그래픽용으로 훌륭하다. 그것은 독점적인 블랙 박스에 데이터를 잃어버리지 않는 것과 관련된 문제로 진정으로 재사용할 수 있고 재생할 수 있는 정보에 관한 것이다.

그 결과 XML 구문을 사용하면 SVG 그래픽은 항상 구조화되고 더 많은 의미구조를 내장할 수 있기 때문에 이는 대단히 좋은 일이라고 생각된다. 그리고 XML이 제공하는 구조로부터 얻을 수 있는 혜택은 단지 재무 데이터와 의료 기록 등과 같은 것들에 그치는 것은 않는다. 지도, 로고, 사용자 인터페이스, 애니메이션과 일러스트레이션과 같은 그래픽은 모두 구조(structure)와 의미구조(semantics)에 의해서 개선된다.

XML로 지금 당장 통합이라는 혜택을 얻을 수 있다. 방대한 범위의 서버측 XML 도구와 작업할 수 있으며 그래픽을 위해 XML을 사용할 경우 XML 작업흐름도(workflows)와 비교해 볼 때 현재의 모델에 가장 적합하다고 볼 수 있기 때문이다. 이런 식으로 다른 모든 XML 테크놀러지를 철저히 이용하고 상호운용할 수 있다. DOM과 XSLT과 같은 표준을 비롯하여, JSP, ASP, 그리고 PHP와 같은 XML 라이브러리를 가진 도구들을 이용할 수 있다는 말이다.

이런 통합의 힘은 업무 카드나 우편 엽서처럼 맞춤 그래픽을 보여주는 간단한 예에서 참고할 수 있다. 개발자는 그 그래픽을 위해 SVG 주형틀(template)을 만들고 변형(transformations)과 같은 서버쪽 도구를 사용하면 최종 사용자의 요구에 맞추어 재단할 수 있다. 게다가 현대 프로그래밍 언어는 거의 모두 XML을 지원한다. 데이터가 XML로 작성되어 있고 도구 모둠이 XML과 작업할 수 있다면 그래픽 표현이 XML이라는 것은 의미가 있다.

SVG는 이미 단일 플랫폼이다

제이섹(Jacek)은 단일 플랫폼을 확보하는 것이 이점이 있다고 말했다. SVG는 단일 플랫폼을 가지는데 이는 소위 SVG 규격이라고 불린다. 수 많은 SVG 구현에는 뷰어(viewers), 편집기(editors), 그리고 컨텐츠 생성을 위한 서버쪽 도구가 포함된다. 이런 모든 구현은 그 규격을 준수해야 아며 만약 규격을 따르지 않을 경우 개발자들이 규격을 준수하는 구현을 사용할 것이기 때문이다.

개발자들은 구현물의 문서를 점검하여 그것이 규격에서 얼마나 벗어나는지 살펴 보는데 질려버렸다. 그리고 SVG 구현자들은 이점을 간파하였다. 게다가 완벽하게 규격을 준수하는 SVG 뷰어가 아파치 배틱(Apache Batik)에 있는데 이 뷰어는 오픈 소스 라이센스 하에서 사용할 수 있다. 이와 같이 자유롭게 사용할 수 있고 완벽한 오픈 소스 해결책을 사용하면 단일한 플랫폼을 유지하는데 도움이 된다. 게다가 이러한 오픈 소스 해결책은 폐쇄 소스 구현들을 정직하게 만들고 폐쇄 소스 구현들에게 무엇인가 비교할 만한 것을 제공하며(그리고 심지어 라이센스 조항이 허락한다면 소스를 비교하는 것까지도 가능), 개발자들에게 단일 플랫폼을 보증할 탄약을 공급한다.

그래서 나는 제이섹(Jacek)의 의견에 동의한다. 단일 플랫폼은 좋은 것이다. 그리고 SVG에서 처음으로 단일 플랫폼을 시작하게 되어 기쁘다.

SVG 파일은 대역폭 친화적이다(bandwidth-friendly)

제이섹(Jacek)은 SVG를 대역폭 호그(bandwidth hog)라고 부른다. 그렇지만 이 점에 대해 나는 다음과 같은 두 가지 이유로 동의하지 않는다. 첫째, 많은 경우(예를 들어 이 모양을 지점 A에서 지점 B로 10초에 걸쳐서 이동시키고, 그 동안 청색에서 적색으로 서서히 변화시키는 방식의)에 SVG가 사용하는 선언적 애니메이션 구문이 프레임 기반의 접근법보다 훨씬 더 효율적이다(예를 들어 여러 프레임(틀) 그리고 각 프레임에서의 모양은 약간씩 다른 위치와 색상을 가진다. 즉, 수 많은 정적인 이미지들이 하나씩 연이어 보여진다).

그리고 크기에 있어서의 이러한 이점은 애니메이션이 길어질 수록 더욱 분명해진다. 물론 선언적 접근법과 프레임 기반의 접근법 사이의 크기 차이는 애니메이션 그 자체에도 상당히 의존하지만 SVG 애니메이션은 대역폭을 좀 더 효과적으로 사용한다. 상호작용적인 SVG 애니메이션이 동등한 기능의 SWF보다 크기가 더 작은 한 예로 나는 앤토인(Antoine)의 재치가 돋보이는 기사인 Sacre SVG! 칼럼을 예로 들겠다. 그리고 그것은 아주 작은 애니메이션을 위한 것이다.

둘째, SVG 작업 그룹이 특별히 gzip 압축을 사용하기로 결정하였다는 것도 주목할 가치가 있다. gzip은 환상적으로 SVG 파일 압축 작업을 해낸다. 나는 압축 전문가를 전적으로 신뢰한다! 모든 SVG 뷰어(viewer)는 gzip로 압축된 SVG 파일을 지원해야 한다. 뿐만 아니라 gzip 압축은 많은 시스템 라이브러리에 포함되어 있다. 그 의미는 구현을 위해 다시 자취를 남길 필요가 없다는 뜻이다. SVG 파일 크기는 작업 그룹의 주요 관심사였고 진지하게 그 문제에 접근했다고 생각한다. 나는 SVG 파일이 너무 길다는 오해가 불식되기를 바란다.

모바일(mobile) 공동체는 SVG를 선택하였다

대략 SVG가 W3C의 권장안이 될 시기에, 모바일 디바이스(Mobile Device) 공동체는 SVG를 채택하였다. 노키아, 에릭슨, 오픈웨이브와 같은 모바일 업체들이 SVG 작업 그룹에 합류하였다. 그들은 제 3세대 이동전화기에 사용할 벡터 그래픽용 포맷이 필요했다. 그들은 그 포맷이 개방되고, XML 기반이며, 모듈화되고, 분석가능한(profilable) 기술이 되어 자신들의 기반구조(architectural) 계획에 적합하게 되어 주었으면 하는 바람이 있었다. 그들의 기반구조 계획에는 XHTML Basic, CSS, SMIL이 포함된다. 그들은 SVG를 선택하였고 그 작업 결과는 모바일 SVG 분석표에서 볼 수 있다.

모바일 표준 기구인 3GPP는 미국과 유럽에서 사용할 차세대 이동전화를 위한 플랫폼을 정의하고 있다. 3GPP는 SVG Tiny를 멀티미디어 메시징(Multimedia Messaging)에 필수적인 포맷으로 채택하였다(SVG Basic이 권장됨). (비록 75x25 화소에 흑백 화면이지만) 이미 미국에서 사용되는 이동전화에는 SVG가 구현되어 있을 뿐만 아니라 Palm Pilots, PocketPC 장치, PDA, 전자 책, 일제 이동전화(샤프가 SVG를 사용할 수 있는 전화를 일본에서 시판하고 있음)를 비롯하여 자동차 항법시스템 등에도 SVG가 구현되어 있다.

내가 한때 걱정했던 것은 SVG의 완벽함이 어쩌면 구현자들에게 너무 큰 부담이 될지도 모른다는 것이었다. 그렇지만 이제 그런 걱정은 더 이상 하지 않아도 된다. 수 많은 벤더들이 만든 수 많은 구현들이 수 많은 장치에서 서로 상호운용 할 수 있다. 최근 SVG가 모듈화되고 최적화되어 SVG Basic과 SVG Tiny 내부으로 들어갔으므로 미래의 구현자들을 도와줄 수 있다.

어째서 SVG가 웹에 적합한가?

웹 개발 포럼이므로 SVG가 웹의 전반적인 기반구조(architecture)에 어떻게 적합한지 살펴보는 것도 중요하다고 생각한다. 그래서 이에 대해 좀더 자세하게 살펴보겠다.

• XML 구문: 언급할 만한 가치가 있는 점들이 여럿 있기는 하지만 XML 문서가 되면 얻을 수 있는 혜택을 굳이 넘어설 필요는 없다고 생각한다. XML 구문으로 SVG는 다른 XML 문서와 통합될 수 있다. 예를 들어 SVG 인라인(inline)을 XHTML 파일 안에 내장하기, SVG를 MathML과 결합하여 수학 공식의 그래픽적인 표현을 만드는 것 등이 그 예이다. 앤토인(Antoine)의 최근 기사는 SVG를 확장하여 Xforms을 지원하는 법을 보여준다. XForms는 HTML의 폼을 대체하는 기술이다.
  
  
• 웹 서비스: SVG는 웹 서비스에 있는 그래픽과 완벽하게 부합한다. 이것은 다른 XML 테크놀로지와의 통합과 상호운용성에 관한 것이다. XML이기 때문에 SVG 다이어그램이나 애니메이션은 쉽게 SOAP 메시지로 캡슐화 될 수 있다. 또한 SVG의 상호작용과 프로그램가능성은 곧 SVG가 웹 서비스에 대하여 더욱 복잡한 그래픽 사용자 인터페이스를 구축하는데 사용될 수 있다는 것을 뜻한다.
  
  
• CSS로 스타일 바꾸기: SVG는 CSS를 사용하면 HTML과 똑같은 방식으로 스타일을 바꿀 수 있다. 스타일 속성, "클래스"와 같은 선택자, 내부 스타일시트, 참조된 스타일시트, 그리고 사용자 스타일시트 등등을 사용할 수 있다. 이미 그 유명한 주문(mantra)을 알고 있을지도 모르겠다: 표현으로부터 구조/내용을 분리하는 것이 그것이다. 또한 이러한 접근법으로 얻을 수 있는 혜택도 알고 있다. 이런 것은 처음부터 SVG 안에 구축되어 있다.
  
  
• SMIL로 하는 애미메이션: SVG는 SMIL 애니메이션 구문을 사용한다. 이 구문은 독립적 SVG 파일에 유용할 뿐만 아니라 SVG 문서가 멀티미디어 SMIL 표현에 내장될 수 있도록 해주어 오디오 컴포넌트와 비디오 컴포넌트가 벡터 그래픽 애니메이션과 겹치도록 해준다.
  
  
• 스크립팅: SVG는 (예를 들어 펄, 파이썬, 심지어 자바까지) 어떤 언어로든지 스크립팅 할수 있다. 그렇지만 SVG 사용자 중개자(user agents)가 스크립팅을 지원하려면 적어도 완전하게 ECMAScript(즉, 자바스크립트)를 지원해야 한다. SVG 문서 안에 존재하는 모든 요소, 특성, 속성이 변경될 수 있다. 뿐만 아니라 어떠한 SVG 요소라도 만들어서 그 요소를 문서 안에 삽입하여 렌더링할 수 있다. 자바스크립트에 익숙한 수 백만의 프로그래머들이 강력한 SVG 스크립팅 지원에 쉽게 전환할 수 있다.
  
  
• DOM: XML이기 때문에 SVG는 DOM Core와 DOM Events를 포함하여 완전한 XML DOM을 보유한다. 이는 개발자들이 SVG로 작업하기 위해 기타 다른 프로그래밍 인터페이스를 배울 필요가 없다는 것을 의미한다. 그리고 개발자들은 즉시 친숙한 DOM 인터페이스 덕분에 SVG 문서 안에 존재하는 그래픽들을 완전하게 통제할 수 있다는 것을 깨닫게 될 것이다. SVG는 자신만의 확장된 DOM을 보유하기도 하는데 이 확장 DOM은 행렬 곱셈 같은 보편적인 작업을 위한 편리한 기능들을 포함하여 프로그래머들에게는 대단히 완전한 그래픽적 모델을 제공한다.
  
  
• 기타 등등: JPEG 그리고 PNG 같은 레스터(raster) 이미지들을 위한 표준, XSLT를 이용한 SVG의 상호 변환, SMIL을 사용한 애니메이션, ICC 칼라 프로파일을 사용한 색상 관리, 그리고 유니코드를 사용하는 국제적인 텍스트. Postscript, PDF, Java2D, Mac OS X Quartz에 사용되어 잘 증명된 산업계가 인정한 그래픽 원리 위에 구축된 모든 것.