저자: 딘 잭슨(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에 사용되어 잘 증명된 산업계가 인정한 그래픽 원리 위에 구축된 모든 것.

B2B 환경의 기업용 솔루션 개발에 Flex의 적용이 확대됨에 따라 기존의 비주얼 중심의 UI에 대한 관점이 사용자의 경험(User experience)를 높이기 위한 방향으로 한 단계 성숙되고 있다. 한국어도비는 UI 컨설팅 시장 자체가 아직 초기 진입 단계로, 전문적인 그룹이 형성되지 않은 상태인 점을 감안하여, 웹 에이전시가 Flex UI 컨설팅으로 서비스 영역을 확대할 수 있는 역량을 갖출 수 있도록 발빠른 지원에 나섰다.

어도비는 지난 2월부터 웹 에이전시를 투어하며 B2C 시장을 넘어 B2B 시장에서의 요구와 기회가 어떻게 증가하고 있는지를 설명하고, 이를 위해 웹 에이전시가 시장 진입을 위해 준비할 수 있는 교육 및 기술 지원 인프라를 최대한 제공할 수 있도록 노력중임을 공감하는 자리를 마련했다.

각 웹 에이전시의 Flash 개발자/디자이너를 대상으로 한 투어는 교육형식으로 진행되었으며, Flex의 특징 및 UI 측면에서 Flex가 갖는 장점에 대한 내용을 사례를 통해 세부적으로 설명하였다. 강사로는 어도비의 Flex 기술지원 담당 옥상훈 차장, Flex UI 컨설팅 프로젝트 경험을 갖고 있는 디지털웍스의 최민아 실장 등이 진행하였다.

Flash가 수년간 디자이너의 전유물처럼 느껴졌다면, 반대로 Flex는 개발자들이 사용하는 ’개발환경’으로 인식되어 온 것이 사실이다. 어도비의 옥상훈 차장은 Flex에 대한 이러한 편견을 지적하며 Flex Builder를 통해 UI 디자이너와 개발자가 쉽게 소통할 수 있을 뿐만 아니라 Flex Builder 사용법이 직관적이기 때문에 UI 디자이너들이 쉽게 진입할 수 있다고 강조했다. 또한 Flex는 Flash Player 상에서 동작하기 때문에 추가 설치가 필요 없을 뿐 아니라, Flex 개발을 위한 Flex 2 SDK(Software Development Kit)를 무료 보급하고 있다고 설명했다. 실제 프로젝트 사례로는 GS eShop, 신한은행 거래내역 조회, 국민은행 카드조회신청 등을 시연하였다.

디지털웍스의 최민아 실장은 UI 디자이너 입장에서 Flex 개발 시장을 새로운 블루오션(Blue Ocean)에 비유해 경쟁력을 강조했다. 국내의 3000여 웹 에이전시들이 모두 Flash 시장에서 경쟁하고 있는 만큼 가격 경쟁이 매우 심각한 것이 현실인데 반해, Flex는 기하급수적인 성장세를 이루고 있다는 것이다. 최민아 실장은 Flex 시장으로 진입해야 할 이유로 클라이언트에게 제안할 수 있는 범위가 확장되고 일반 사용자의 가장 빈번한 UI 이슈를 해결할 수 있을 뿐만 아니라 전달할 수 있는 컨텐츠가 풍부하다는 점을 꼽았다.

어도비와 Flex 교육을 진행한 프람트의 주현선 부사장은 “기존의 Flash 개발 환경에서는 디자이너와 개발자와 완벽하게 나뉘었을 뿐만 아니라, 디자이너들도 역할에 따라 세분화 되어 있다. 반면 Flex 환경에서는 디자이너와 개발자의 역할이 일정 수준 컨버전스를 일으킬 수 있을 것으로 판단된다. 따라서 Flex UI 컨설팅 시장에 진입하기 위해서는 초기 단계에서는 Flex 개발 환경에 맞는 개발 프로세스와 역할 정립을 해나가는 것이 필요할 것으로 생각된다”고 교육 소감을 밝혔다.

어도비는 웹 에이전시 투어를 통해 Flex 공식 UI 컨설팅

윤석찬
http://channy.creation.net/blog

작성일:2006년 9월 7일 사용자 수준:모두 사용자 경험을 중요시하는 서비스 플랫폼 '웹 2.0'이 새로운 기술 트렌드로 주목되면서 동적인 유저 인터페이스가 보다 중요해지고 있습니다. 이 중심에 가장 대표적인 웹 애플리케이션 기술인 Flex와 Ajax가 있습니다. 언뜻 보면 경쟁관계에 있는 듯한 이 두 기술은 최근 구글 등을 통해 성공적으로 결합된 서비스가 소개되면서 특히 주목받고 있습니다. Flex와 Ajax가 갖는 기술 특징과 두 기술의 결합이 갖는 의미 등을 짚어봤습니다.

월드와이드웹은 하이퍼 링크 구조를 기반으로 하는 문서 형태의 정보 표현을 위해 출발하였습니다. 초창기 웹은 매우 정적이었고 사용자와의 상호작용(interaction)은 특정 주소의 문서를 읽고 쓰는 정도에 머물고 있었습니다. 정적 웹 구조에서 양식(Form)을 통해 사용자의 정보를 읽고 쓰는 CGI 기술의 탄생과 브라우저 전쟁 기간 중에 일어난 기술 혁신은 웹을 소프트웨어로 인식할 수 있는 발상의 전환을 가져왔습니다.

1995년 넷스케이프가 웹 브라우저와 외부 프로그램과의 통신에 보다 동적인 인터넷 경험을 제공하기 위해 플러그인(Plugin) 기술을 선보였습니다. 임베딩을 기본으로 하는 웹 S/W 플랫폼을 장악한 것은 ActiveX나 NSPlugin이 아닌 이들 위에서 브라우저 독립성과 개발 편의성을 동시에 보장해 준 플래시(Flash)였습니다. 플래시는 풍부한 유저 인터페이스를 선보였고 웹의 정적인 면을 보강해 주는 최적의 솔루션으로 인정받았다. 하지만 웹의 근본 속성을 제대로 반영해 주지는 못했습니다. DHTML이라는 기술이 반짝 인기를 끌었지만 2000년대 중반까지 이렇다 할 웹 기술의 혁신은 이뤄지지 않았습니다.

닷컴 거품 이후에 성공한 비즈니스 모델인 아마존, 구글, 이베이 등을 중심으로 사용자가 만든 정보라는 매개체를 활용해 이를 자유롭게 이용할 수 있는 서비스 플랫폼이 각광받기 시작했으며 이러한 특징을 웹2.0이라고 명명하면서 기술적 붐업이 시작되었습니다. 특히 플랫폼으로서 웹은 웹 자체를 서비스 혹은 S/W로 인식하게 함으로써 점점 데스크톱과 인터넷의 경계가 사라지게 하고 있습니다. 따라서 웹의 어플리케이션을 사용하는 사람들을 위해 동적인 유저 인터페이스가 점점 더 중요해지면서 여기에 따르는 다양한 기술 역시 수면 위에 떠 오르고 있습니다. 이것이 바로 웹 애플리케이션 기술입니다.

웹2.0의 첨병, Flex와 Ajax
웹 애플리케이션의 최전선에 있는 기술이 바로 Ajax입니다. Ajax(Asynchronous JavaScript　 and XML)는 대화식 웹 어플리케이션의 제작을 위해 다양한 기술 조합을 이용하는 웹 개발 기법이자 트렌드입니다. 이 기술은 Google이 Gmail과 Google Maps를 만들면서 널리 알려졌습니다. 사실 이 기술은 과거 DHTML이나 Remote Scripting이라고 불리는 동적 웹 개발 방식과 크게 다르지 않습니다. 그러나 여기에 좀 더 다른 몇 가지 특징이 있습니다.

데이터 표현 정보를 위한 HTML(또는 XHTML)과 CSS 동적인 화면 출력 및 표시 정보와의 상호작용을 위한 DOM, 자바 스크립트 웹 서버와 비동기적으로 데이터를 교환하고 조작하기 위한 XML, XSLT, XMLHttpRequest 등을 사용합니다. 이 기술은 거의 웹 표준에 준하는 기술 방식만을 사용해 만들어졌습니다. 따라서 브라우저나 운영 체제에 관계없이 동작합니다.

여기 또 하나의 대안인 Flex가 있습니다. Flex는 기존의 Flash라는 플러그인 플랫폼을 무기로 Adobe에서 야심차게 개발한 서버와 클라이언트의 중간 개념인 미들티어(middle-Tier) 플랫폼입니다. Flex는 리치 인터넷 어플리케이션(RIA)나 온라인 프리젠테이션을 쉽고 간단하게 만들고자 하는 서버 쪽 개발자를 위한 맞춤복 같은 솔루션입니다.

Flex는 웹 표준에 기반한 ActionScript와 MXML(XML) 및 DOM3를 사용하므로 기존 자바스크립트 개발자나 ASP/JSP 등의 서버 개발자가 Flash를 사용하지 않고도 화면 구성을 제어할 수 있습니다. Flash는 그 스스로 웹 표준은 아니지만 웹 브라우저와 운영 체제에 종속적이지 않는 개발 플랫폼을 제공하고 있다는 점에서 중요한 기술 중 하나입니다.

특히 Flex는 Ajax가 가지고 있는 비동기 XML 통신 및 스크립트 핸들링의 기능을 그대로 보유하면서도 다양한 기능을 가진 Flash의 미려한 유저 인터페이스를 그대로 사용할 수 있다는 점에서 매우 뛰어난 플랫폼이라 할 수 있습니다. Ajax가 기술 트렌드이기 때문에 가지는 한계점, 즉 통합 개발 도구(IDE)의 남발 혹은 낮은 완성도에 비하면 Flex는 개발 비용 절감 및 편리성 강화에서 좋은 점수를 얻고 있습니다.

Flex와 Ajax, 공존 가능한가?
Flex와 Ajax는 사용되는 기술 스펙이나 구조 및 개발 방법론 등 많은 부분에서 닮아 있습니다. Flex의 장점이라고 할 수 있는 풍부한 UI는 결국 Flash의 장점인데 이것은 또한 바이너리 형식이라는 점에서 Ajax에 비해 상호 운용성 측면의 제약을 갖는다는 단점이 있습니다. Flash는 멀티미디어 데이터를 압축 저장하는 목표로 만들어진 것이기 때문에 웹 상의 정보 표현이라는 기본 목표에 충실하기는 어렵습니다. 이에 반해 Ajax는 웹 상에서 사용자 경험을 한층 높여 주면서도 웹 표준에 입각한 데이터 교환 및 문서 내 데이터를 쉽게 사용할 수 있는 장점을 가지고 있습니다. 물론 Flex 만큼의 강력한 인터페이스를 제공하기는 어렵습니다.

이러한 서로의 장단점을 보완해 주는 서비스들이 계속 나오고 있습니다. 이러한 방법론의 물꼬를 튼 것이 바로 MeasureMap입니다. Measuremap.com은 유명한 웹 디자이너인 제프리 빈이 만든 블로그 통계 서비스입니다.

이 서비스를 보면 특정 블로그를 방문한 통계 수치들을 웹에서 보여주는데 이 때 미려한 UI를 가진 Flash에서 선택한 조건에 따라 웹 페이지를 로딩해 눕니다. 즉 차트나 다이어그램 같은 것은 Flash를 쓰고 기타 통계 수치는 웹 페이지로 제공해 주는 것입니다. Measuremap은 아이디어의 우수성 때문에 Google에 인수되었습니다.



그림 1. Ajax와 Flash가 적절히 조화된 최초의 웹 서비스 MeasureMap. 차트와 웹 페이지 데이터가 상호 연동됩니다.

Google은 Flex와 Ajax를 조합한 새로운 서비스를 내 놓았는데 바로 Google Finance입니다. 이 서비스에서는 구글 뉴스, 구글 그룹스, 블로그 검색, 웹 검색을 비롯해서 AMEX와 NYSE 주가 데이터, 로이터의 상장사 데이터 등을 종합적이고 유기적으로 보여주는 간결하면서도 직관적인 인터페이스를 구현했습니다. 특히 Flash로 제공되는 차트에서 드래그앤드랍과 시간별 스크롤링 기능이 제공되고 이에 맞는 필터링 된 뉴스 기사를 오른쪽에 보여주는 방법을 사용합니다. 뿐만 아니라 관련 기사나 인물 정보를 표현할 때도 상세 정보를 Ajax와 DOM Scripting을 적절히 이용해서 보여 주고 있습니다.



그림 2. Google Finance 화면. Flash 차트를 선택하면 Ajax로 데이터를 가져온다. 웹 데이터를 선택해도 Flash 차트에 표시됩니다.

실제 이러한 사례들이 Flex만 혹은 Ajax만 쓰는 서비스에 비해 훨씬 고객 만족도가 높습니다. 이러한 흐름 때문인지 Flex 2에서는 Ajax의 연동을 공식 지원하고 있으며, 이를 장점으로 내세우고 있습니다. 특히 얼마 전 Adobe Labs에서 공개한 FABridge(Flex AJAX Bridge)와 ACFDS(AJAX Client for Flex Data Services) 등의 오픈 기술은 주목할 만합니다. FABridge는 Flex와 Ajax를 연동할 수 있는 오픈소스 프레임워크로, 간단한 자바스크립트로 액션스크립트 객체 조정이 가능하며 오픈API 방식으로 FABridge 사이트에 공개돼 있습니다.

ACFDS는 Ajax에서 새로 나올 Flex 2.0이 제공하는 데이터 서비스를 조정할 수 있도록 하는 기술로서 Ajax에서는 다소 어려운 메시징 서비스나 실시간 데이터 스트리밍 등의 서비스를 Ajax에서 쉽게 불러서 쓸 수 있습니다.

기술 선택의 요건 1순위 '미래 지향성'
현재 다양한 웹 애플리케이션 기술이 나와 있습니다. 기술을 선택할 때 가장 중요시 해야 되는 것은 바로 사용자 접근성입니다. 웹 브라우저 지원 범위와 운영 체제, 기타 디바이스 지원에 대한 것을 따지는 것이 중요합니다. 그 다음으로 드래그앤드롭, 자동 저장 등 풍부한 UI 경험 제공 여부도 빼 놓을 수 없습니다.

특히 웹 브라우저 기능과 연관성(Back/Forward, History 동작 여부), 유지 보수 용이성, 프로그램 수행에 대한 지표들 즉, 다운로드 크기 및 수행 속도, 통신 방법, 서버 데이터에 대한 UI 변경 방법 등도 고려할 요소입니다. 개발에 있어서 손쉬운 플랫폼을 사용하는지, 통합 개발 도구(IDE)가 있는지도 고려 해야 합니다.

무엇보다 가장 중요한 것은 미래 지향성입니다. 독특한 기능적 특징뿐만 아니라 향후 표준으로서 가능성이 있는가 하는 점입니다. 이런 점에서 Ajax와 Flex는 웹 서비스 회사 및 SOA를 제공하는 기업에서 가장 각광 받는 대안입니다. 특히 이들 둘은 서로의 장단점을 보완해 줄 수 있고 결합해서 사용되었을 때 강력한 시너지를 냅니다.

웹 2.0의 경험적 요소 중에는 웹을 더욱 동적으로 만들고 풍부한 UI를 선보이고 있다는 특징이 있습니다. 이것은 자사의 웹 서비스와 데스크톱 애플리케이션과의 경계를 모호하게 해서 웹 S/W나 애플리케이션으로 진화하도록 해 플랫폼 효과를 누리고자 하기 때문입니다. 웹의 근본 속성을 지키면서 이러한 목적을 달성할 수 있는 현재 최적의 조합은 Flex와 Ajax라고 볼 수 있습니다. 이들은 현재 웹의 문서 구조와 쉽게 연결될 뿐만 아니라 실제 많이 닮아 있기 때문입니다.

저자 소개
윤석찬은 (주)다음커뮤니케이션 R&D센터에 근무중이며 한국 모질라 커뮤니티(www.mozilla.or.kr) 리더로 파이어폭스 개발에 관여해 왔다. 오픈 소스, 웹 표준 관련 활동을 지속적으로 해 왔기 때문에 최근 부각되는 웹2.0과 웹 어플리케이션 기술에 대한 관심 또한 높다. ZDNet 컬럼니스트로 활동하고 있으며 개인 블로그(http://channy.creation.net/blog)를 운영하고 있다.

2008년 웹쪽에서의 트렌드는 아무래도 작년부터 화자되었던 웹 2.0이 아닌가 싶다.

web 2.0을 기술적으로 구현하는데 있어서 가장 많이 눈에 뛰는 단어는 Ajax였다. Ajax의 산출물은 어떠한 클라이언트, 브라우저, 운영체제, 디바이스등에 독립적으로 RIA를 구현할 수 있게된다.
Ria는 IT word에 포스팅 했으므로 추가 설명하지는 않겠다.

Ajax는 차세대 웹 어플리케이션을 위한 최선의 대책이라 이야기 되어 왔지만 개발자들이 귀찮아 하는 베스트 3에 빠지지 않는 Javascript　를 사용함으로서 개발자와의 거리를 두었는지 모르겠다. 이는 실버라이트 1.0과 상황이 비슷하다고 판단되어진다. 그런 반면 Flash 수준의 화려한 UI를 보여주는 최선의 대안으로 Flex가 등장하였다.

그렇다고 Javascript　나 Ajax를 깍아내리는 것은 아니다. 지구상 곳곳에 쓰이고 있는 언어가 Javascript　라고 필자는 생각하니 말이다. 단지 Flex는 Ajax의 단점을 장점으로 가졌다랄까?

Flex(Flex Presentation Server)??
web 2.0의 RIA를 구현을 쉽게 해주는 스크립트 언어이다. Flash 기술로부터 탄생하였기 때문에 두 기술로 구축된 사이트는 비슷한 UI를 가진다. Flash는 각종 도형과 컴포넌트들을 마우스로서 디자인 하는 반면 Flex는 그런 Flash 컴포넌트들을 XML 태그 스크립트를 이용하여 코딩한다.

Flex.. 어떤 기술이.??
개발언어 측면에서 플렉스는 XML, EXMAScript, CSS, UTF-8 기술 요소를 사용한다.

플렉스의 mxml은 'mx'라는 XML 네임스페이스를 사용하여 XML 문법을 따르며 ECMAScript는 플렉스 앤션스크립트가 준수하는 표준으로 자바스크립트와 유사하다. 또한 MXML 스타일은 CSS문법을 지원하고, 파일은 UTF-8로 작성 및 저장되어 서버에서 처리된다.

서버 서비스 측면에서 DOM 레벨 3 이벤트 모델은 플렉스의 이벤트 모델로 사용되며 DOM 트리 구조를 통해 이벤트를 전달한다. 플렉스 애플리케이션은 HTTP 통신 뿐 아니라 XML 통신 프로토콜인 SOAP 메세지로 데이터를 송수신할 수 있다. 이외에 플렉스는 자바 애플리케이션 서버에서 작동되며 플렉스에서 자바진즈 컴포넌트의 메쏘드를 호출하여 결과를 받을 수 가 있다.

Flex 서버의 구성!?
Flex는 국제 표준에 기반하여 구성되었고 ActionScript(Javascript　), MXML(XML), DOM3 등의 표준위에 Adobe의 API와 클래스 라이브러리가 추가된 형태이다. Javascript　의 언어적인 단점을 보완한 ActrionScript는 강력한 객체지향 언어로 거듭났을 뿐만아니라 Flash의 기존 버전에서 검증되었던 강력한 라이브러리들을 Flash보다 편리하고 쉽게 이용할 수 있게 해준다.




[그림] Flex 서버 아키텍쳐



Flex의 구동 원리..
사용자가 플렉스로 구현된 사이트로 접속하면 웹애플리케이션 서버에 설치된 플렉스 서버는 MXML 코드를 SWF(플래시 실행파일)로 컴파일해서 사용자 PC에 전송되어 플래시 플레이어가 이를 보여준다.



[그림2] Flex 구동절차



이러한 Flex로 구축하였을 때에 제일 큰 장점은 플레시 플레이어로 작동이 되기때문여 여타 플랫폼이나 운영체제로 부터 독립적으로 동일한 결과물을 얻을 수 있다는 것이다. 또한 한번 로딩이 되면 서버로부터 실행코드를 받을 필요가 없어 속도가 빠르며 서버의 부하가 적다. 개발자 측면에서도 XML태그와 액션스크립트로 코딩되므로 Html코딩을 이해하는 수준정도로도 쉽게 배울수 있는 장점이 있다.
무엇보다 컴포넌트를 다양한 방법으로 만들어 코드 재사용이 높아 개발속도가 향상이 된다. 다른 시스템과 다른 애플리케이션과 연동할 수 있는 다양한 방법도 제공을 한다.

<<참고사이트>>
1. http://blog.naver.com/cache798

위키백과 ― 우리 모두의 백과사전.
(Adobe Flex에서 넘어옴)
Jump to: navigation, 찾기
어도비 플렉스(Adobe Flex) 는 2004년 3월 매크로미디어에 의하여 만들어진 소프트웨어 개발 키트(Software development kit|software development kit) 와 개발자들을 위한 IDE 이다. (다만 현재는 어도비 시스템즈에서 개발되고 있다.) 그들이 가지고 있는 어도비 시스템즈 플래시 플랫폼 기반으로 리치 인터넷 어플리케이션을 크로스플랫폼에서 개발하고 배포할 수 있도록 지원한다.

2007년 4월 어도비는 플렉스 3 SDK 에 대한 플렉스 오픈소스 계획을 발표했다. 하지만 실행 환경에서 플렉스 응용 프로그램을 보기 위한 어도비 플래시 플레이어와 플렉스 응용 프로그램을 개발하기 위한 IDE 인 플렉스 빌더는 여전히 독점적이고 상업적으로 남아 있다.

목차 [숨기기]
1 개요
2 초기 버전 (플렉스 서버 1.0, 1.5)
3 어도비 플렉스 2
4 어도비 Flex 3 (베타)
5 라이브사이클 데이터 서비스
6 플렉스 응용 프로그램 개발 과정
7 개발 이력
8 국내 플렉스 적용 사례
9 같이 보기
10 바깥 고리
10.1 커뮤니티 사이트
10.2 블로그



[편집] 개요
전통적인 응용 프로그램 개발자들이 플래시 플랫폼으로 만드는 애니메이션을 적용하기에는 어려움이 있었다. 플렉스는 이러한 과정의 어려움을 최소화하고 응용 프로그램 개발자들에게 익숙한 개발 모델을 제시하였다.

플렉스는 초기에는 J2EE 응용 프로그램 또는 JSP 태그 라이브러리를 통해서 동적으로 MXML 과 액션스크립트(ActionScript) 코드를 플래시 응용 프로그램(SWF 파일)으로 컴파일하는 것만 가능하였다. 그리고 이후 버전부터 서버 라이선스 없이 프로그램 코딩 후 파일을 컴파일 할 수 있도록 하고 온라인에 배포 할 수 있도록 지원하기 시작한다.

플렉스의 목적은 응용 프로그램 개발자들에게 빠르고 쉽게 리치 인터넷 응용 프로그램을 개발할 수 있도록 하는 것이다. n계층모델에서 플렉스 응용은 프레젠테이션 계층을 제공한다.

플렉스의 특징은 MXML 이라고 불리우는 XML 기반 언어를 사용하여 GUI 개발을 가능하게 한다. 이것은 웹서비스, 원격객체, 드래그 앤 드롭, 컬럼 정렬, 챠트, 그래픽 객체, 애니메이션 효과 등을 구현하기 위한 다양한 구성요소와 기능들로 이루어져 있다. 그리고 이들의 상호 간의 통신 또한 간단하게 구성할 수 있다. 사용자가 한번 호출하면 작업마다 서버에서 템플릿을 실행하는 것을 요청하는 versus HTML, 기반의 응용(PHP,ASP,JSP,CFMX)보다 훨씬 향상된 응용 작업 흐름을 플렉스의 언어와 파일 구조는 디자인으로부터 응용 로직을 분리하도록 이루어져 있다.

플렉스 서버는 또한 사용자가 XML 웹서비스와 원격 객체(CFCs 나 Class 그리고 AMF 를 지원하는 그 밖의 다른 객체)를 가지고 통신하는 것을 허용하는 게이트웨이로 동작한다.

일반적으로 플렉스를 대체하는 것들을 언급할 때 오픈라즐로, Ajax, XUL, JavaFX 그리고 실버라이트와 같은 WPF 기술을 이야기한다.


[편집] 초기 버전 (플렉스 서버 1.0, 1.5)
플렉스는 처음에는 기업용 응용 프로그램 개발시장을 목표로 만들어졌다. 그리고 CPU 당 15000달러에 판매되었다. 각 라이선스는 5개의 플렉스 빌더 라이선스를 포함하고 있었다. 순수 개발자의 경우 액션 스크립팅을 사용하는 게 낫다.


[편집] 어도비 플렉스 2
플렉스 2 에 와서는 라이선스 모델이 변화되었다. "플렉스 2 SDK" 라고 불리우는 무료 버전의 SDK 를 배포하였다.

새로운 플렉스 빌더 2 는 이클립스 IDE 기반으로 만들어졌다. 데이터를 동기화하고 데이터 push, publish-subscribe, 자동화된 테스트를 제공하는 기업대상의 서비스도 FDS 2 를 통하여 가능하게 된다.

플렉스 2는 액션스크립트 3 라고 불리우는 새로운 버전의 액션스크립트 스크립팅 언어를 소개한다. 최신의 ECMA스크립트 특징을 반영하고 있고 플래시 플레이어 9 또는 그 이후 버전이 필요하다.

플렉스는 매크로미디어 제품군에서 어도비로 명칭이 바뀐 첫 번째 제품이다.


[편집] 어도비 Flex 3 (베타)
어도비는 플렉스 3의 첫 번째 베타버전을 2007년 6월 릴리즈하였다. 주된 특징은 새로운 버전의 CS 제품군과의 통합이고 AIR 를 지원하는 것이다. 추가적으로 플렉스 빌더 IDE 에서 프로파일링과 리팩토링이 가능하다. 더 많은 특징과 다운로드는 http://labs.adobe.com/technologies/flex/flexbuilder3/ Adobe Labs] site 에서 제공한다.

2007년 10월 어도비에서는 플렉스 3 의 두번째 베타를 공개하였습니다.


[편집] 라이브사이클 데이터 서비스
LiveCycle Data Services (이전에는 플렉스 데이터서비스(FDS) 였음) 는 플렉스 SDK 와 플렉스빌더와 함께 플렉스 제품군 중 하나로 서버측 지원을 담당한다. 자바 엔터프라이즈 응용으로 배치될 때 LDS 는 플렉스 응용 프로그램에 추가적인 기능을 지원한다.

리모팅, 플렉스클라이언트 응용 프로그램이 직접 자바 서버 객체와 연결될 수 있도록 한다. 마치 RMI(Java remote method invocation)와 비슷한 기능이다. 원격에서 데이터 마샬링을 자동으로 다룰 수 있고 이진 데이터를 전송 포맷으로 사용한다.
메시징에서 구독/배포의 디자인패턴의 목적으로 배포를 제공한다. 플래시 클라이언트는 서버에서 설정한 배포 이벤트에 대하여 메시지 서비스로부터 배포되는 이벤트를 구독할 수 있다. 대표적인 예가 금융 데이터 또는 시스템 상태 정보와 같은 실시간 데이터 스트리밍이다.
플렉스 클라이언트로 다운로드된 데이터를 자동적으로 관리하는 개발 모델을 제공하는 데이터 관리 서비스이다. 서버로부터 데이터가 한 번 로드된 뒤에 변경되는 사항은 자동적으로 검사가 되고 응용 프로그램의 요청으로 서버와 동기화된다. 클라이언트는 또한 서버 측에서 데이터가 변경되는 것을 바로 확인할 수 있다.
서버에 특정 위치에 저장된 클라이언트 데이터 또는 이미지와 함께 PDF 문서를 만들어낼 수 있는 API 를 제공합니다.
오픈소스 리모팅 기능으로 PHP 를 사용한다면 AMFPHP 를 대신 사용할 수 있다.


[편집] 플렉스 응용 프로그램 개발 과정
아래의 자료들은 플렉스 2 베타 3 도움말에서 가져온 내용이다.

UI 컴포넌트(폼, 버튼 등)을 사용하여 어플리케이션 양식의 태그를 정의한다.
사용자 인터페이스 디자인안에 정의된 컴포넌트를 사용한다.
시각적 디자인을 정의하기 위하여 스타일나 테마를 사용한다.
동적인 행동을 추가한다.(응용 프로그램이 다른 요소들과 상호작용)
필요에 따라 데이터 서비스와 연결하는 부분을 정의한다.
소스코드를 빌드하고 플래시 플레이어에서 작동할 수 있도록 SWF 파일을 만든다.

[편집] 개발 이력
플렉스 1.0 - 2004년 3월
플렉스 1.5 - 2004년 10월
플렉스 2.0 (알파) - 2005년 10월
플렉스 2.0 베타 1 - 2006년 2월
플렉스 2.0 베타 2 - 2006년 3월
플렉스 2.0 베타 3 - 2006년 5월
플렉스 2.0 최종 - 2006년 6월 28일
플렉스 2.0.1 - 2007년 1월 5일
플렉스 2.0.1 오픈소스 공개 2007년 4월 26일
플렉스 3.0 베타 1[Moxie] - 2007년 7월 11일
플렉스 3.0 베타 2 - 2007년 10월 1일

[편집] 국내 플렉스 적용 사례
국내 플렉스 적용 사례(내부 시스템 제외):

공공기관

국가지리정보유통망
금융

네이버 증권
신한은행
KB국민카드
농협 X-Bank
쇼핑

GS이숍
Yes24영화
엔터테인먼트

발툰닷컴
사진공유SNS-포토바다
FxUG Flex Live-Chat
the Flex Showcase

the Flex Showcase.