IT/모바일
저자: 딘 잭슨(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와 똑같은 그래픽과 애니메이션 기능을 제공할 뿐만 아니라 덤으로 다른 이점도 얻을 수 있다.
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)에 어떻게 적합한지 살펴보는 것도 중요하다고 생각한다. 그래서 이에 대해 좀더 자세하게 살펴보겠다.
마지막 생각 (인가, 아니면
SVG는 기존 테크놀러지를 모두 대체하기 위하여 디자인 되었다. SVG는 웹상에서 벡터 그래픽을 위한 최상의 해결책이 되도록 디자인 되었다. SVG는 표준적인 대중의 의견과 그 특징을 구현해 본 경험에서 우러나온 요구조건을 반영하여 만들어졌으며, 종종 서로 경쟁하면서 그래픽 테크놀러지의 개발을 선도하는 기구와 회사들이 참여하고 있으므로 투자한다면 반드시 긍적적인 결과를 얻을 수 있을 것이다. 나는 SVG의 시대가 이미 도래했다고 생각한다.
SWF는 아주 인기 있는 독점 포맷으로 수 년간 널리 보급된 인기 있는 저작 도구이다. SVG는 새로 탄생한 개방된 XML 포맷이며 아직 인기면에서 똑같은 수준에 도달하지 못했지만 기술적으로 우월하다고 일반적으로 인정된다. 그러나 현재 SVG 컨텐츠를 개발하고 있는 사람들이 보여준 열정과 산업계의 전폭적인 지원, 오픈 소스 개발자들의 강력한 성원으로 머지 않아 SVG가 저작도구와 시장점유율을 확보하고 우세한 웹 포맷이 되리라 생각한다.
딘 잭슨(Dean Jackson)은 SVG 작업 그룹의 회원이다.
편집자 주 - 오라일리의 웹 개발센터에서 추구하는 목표는 (오픈 소스와 독점 테크놀러지 모두에 대해) 독자에게 가치 있는 웹 테크놀러지에 대한 균형잡힌 시각을 제공하는 것이다. 점점 더 오픈 소스와 독점 테크놀러지 사이의 경계선이 모호해지고 있다. 이는 어도비 고라이브(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 | ||
|
||
|
|
|
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에 사용되어 잘 증명된 산업계가 인정한 그래픽 원리 위에 구축된 모든 것.
마지막 생각 (인가, 아니면
SVG는 기존 테크놀러지를 모두 대체하기 위하여 디자인 되었다. SVG는 웹상에서 벡터 그래픽을 위한 최상의 해결책이 되도록 디자인 되었다. SVG는 표준적인 대중의 의견과 그 특징을 구현해 본 경험에서 우러나온 요구조건을 반영하여 만들어졌으며, 종종 서로 경쟁하면서 그래픽 테크놀러지의 개발을 선도하는 기구와 회사들이 참여하고 있으므로 투자한다면 반드시 긍적적인 결과를 얻을 수 있을 것이다. 나는 SVG의 시대가 이미 도래했다고 생각한다.
SWF는 아주 인기 있는 독점 포맷으로 수 년간 널리 보급된 인기 있는 저작 도구이다. SVG는 새로 탄생한 개방된 XML 포맷이며 아직 인기면에서 똑같은 수준에 도달하지 못했지만 기술적으로 우월하다고 일반적으로 인정된다. 그러나 현재 SVG 컨텐츠를 개발하고 있는 사람들이 보여준 열정과 산업계의 전폭적인 지원, 오픈 소스 개발자들의 강력한 성원으로 머지 않아 SVG가 저작도구와 시장점유율을 확보하고 우세한 웹 포맷이 되리라 생각한다.
딘 잭슨(Dean Jackson)은 SVG 작업 그룹의 회원이다.
TAG :
이전 글 : X-윈도우 모질라 공격
최신 콘텐츠