마이크로소프트가 어도비가 갖고 있는 웹 디자이너 전용 툴 시장에 야심찬 도전장을 내밀었다.

4년의 개발 준비기간을 거친 마이크로소프트의 야심작은 ‘익스프레션 스튜디오(Expression Studio)’이다. 익스프레션 스튜디오는 개발자를 위한 비주얼 스튜디오의 연속선상에 놓여있다. 왜냐하면 MS는 익스프레션 스튜디오가 개발자와 디자이너의 협업을 최적화하고, 프로젝트 시간을 혁신할 수 있다는 점에 초점을 맞추고 있기 때문이다.


마이크로소프트의 UX 담당 포레스트 키(Forest Key) 총괄 책임 이사는 “현재의 프로젝트의 워크플로우를 보면 디자이너가 디자인한 비주얼이 개발자에게 전달되어 작업이 진행되면 최종 결과물이 디자이너의 비주얼을 그대로 나타내지 못하는 경우가 매우 많았다”면서 “이것은 상호간의 협업을 방해하고, 개발 기간을 늘리는 결과를 초래해 프로젝트 전체에 큰 압박을 주었다”고 지적했다.

익스프레션 스튜디오는 이런 문제를 해결하는 최적의 통합 패키지라는 것. MS가 제시하는 해결 방안의 핵심 기술은 XAML(eXtensible Application Markup Language)과 WPF(Windows Presentation Foundation)이다.

XAML이 핵심 기술인 것은 기존에는 디자이너의 디자인 작업 결과를 개발자에게 넘겨 주면 비주얼을 보고 그에 해당하는 개발 과정을 진행하는 방식이었다. 하지만 익스프레션 스튜디오를 이용하면 디자인 결과물이 바로 XAML 코드로 곧바로 생성되기 때문에 개발자는 이 코드를 그대로 전달받아 개발 작업을 진행하면 된다는 것이다.

익스프레션 스튜디오 패키지의 하나인 익스프레션 블렌드(Expression Blend)가 바로 이런 작업을 수행하는 툴로 풍부한 UX를 제공하는 인터랙티브 디자인을 가능하게 한다는 것.

WPF는 익스프레션 스튜디오를 위한 기술은 아니지만 .NET 프레임워크에 포함되는 것으로 그래픽 엔진의 일종이다. WPF에 대응하는 애플리케이션은 기존 기술과 다른 발전된 UX를 경험할 수 있게 해주는 기반이 될 것으로 기대되고 있다.

포레스트 키 이사는 익스프레션 스튜디오를 발표하는 자리에서 WPF 기반으로 개발된 뉴욕타임즈의 웹 사이트를 시연해 보였다.

익스프레션 스튜디오는 익스프레션 웹(Expression Web), 익스프레션 블렌드(Expression Blend), 익스프레션 디자인(Expression Design), 익스프레션 미디어(Expression Media)로 구성된 통합 패키지의 총칭이다.

익스프레션 웹은 위지윅(WYSIWYG) 툴로 XML, HTML 등 표준화된 웹 사이트 구축 전문 툴로 프런트페이지의 상위 버전 격이다.

익스프레션 블렌드도 역시 위지윅 툴이고, XAML을 지원해 디자이너와 개발자의 공동 작업용 툴이다.

익스프레션 디자인은 그래픽 전용 툴로 벡터와 비트맵을 동시에 지원한다. 퓨처하우스 익스프레션이라는 기업을 인수하면서 내놓게 된 제품이다.

익스프레션 미디어는 디지털 자산관리 및 인코딩 툴이다. 이것도 역시 영국의 작은 기업을 인수해 내놓은 제품이다.

어도비와의 경쟁 불가피
원하든 원하지 않든 MS는 익스프레션 스튜디오를 내놓음으로써 어도비와 경쟁할 수밖에 없는 입장에 놓이게 되었다.

양사의 경쟁은 풍부한 UX를 위한 사용자의 선택을 가져오게 됐고, 결과적으로는 더 풍부한 UX 즉, RIA(Rich Internet Application)의 개발을 유도하게 될 것으로 예상된다.

경쟁의 포인트는 개발자에게 취약점을 갖고 있는 어도비와 디자이너에게는 이제 새롭게 선보이는 MS의 익스프레션 스튜디오가 어떻게 상호간의 취약점을 극복하느냐에 있다.

어도비 역시 이런 문제를 극복하기 위해 플렉스, 아폴로 등 새로운 기술과 비전을 발표하고 나섰기 때문에 경쟁의 양상은 더욱 흥미롭게 전개되고 있다.

이에 대해 포레스트 키 이사는 “디자이너와 개발자가 원하는 가치를 제공하겠다. 성공하기 위해서는 디자이너를 위한 성공적인 성능을 제공해야 할 것인데, 어도비가 현재 그렇다고 말할 수는 없다. 이제부터 시작이다. “라고 말했다.

현재 익스프레션 웹은 이미 출시된 상태로 제품 구입이 가능하며, 나머지 제품은 5월 28일 발표될 예정이다. 익스프레션 스튜디오 통합 패키지의 가격은 60만원 대로 알려졌으며, 개별 제품으로 구입하면 익스프레션 웹은 30만원대(프런트페이지를 보유한 경우 10만원대), 익프레션 블렌드, 익스프레션 미디어는 각각 50만원대, 30만원 대이다. @

한국후지필름은 디지털 렌즈 교환식 카메라(DSLR) ‘파인픽스 S5Pro’를 출시한다고 5일 밝혔다.

한국후지필름 관계자는 “파인픽스 S5Pro는 파인픽스S3Pro을 선보인 이후 2년 만에 내놓은 제품으로 총 1,234만 유효화소를 지원하며, ISO 3200의 고감도에서도 해상력 손실 없이 노이즈가 최대한 억제된 고화질 사진을 촬영할 수 있다.”고 설명했다.



파인픽스 S3Pro부터 400%까지 지원해온 다이나믹 레인지는 S5Pro에서는 네거티브 필름에 육박하는 관용도를 지원해, 기존의 3단계에서 7단계로 세분화된 설정 모드로 늘렸다.

이 제품의 이색적인 기능은 바로 ‘필름 시뮬레이션 모드’. 필름과 같은 이미지 촬영을 지원하는 이 기능은 사용자의 촬영 의도에 맞춰 특수한 필름을 선택해 촬영하는 것과 같은 연출이 가능하다. 파인픽스 S5Pro의 판매가는 198만원@

편집자주: - 23.0mm × 15.5mm 허니컴 SuperCCD SR Pro 탑재 - 5가지의 필름 시뮬레이션 모드 - S화소 617만, R화소 617만 화소 등 총 1234만 유효화소 - ISO3200 초고감도 지원 - 페이스 줌인 기능 - RAW/JPEG 동시 기록 - XD 메모리카드/CF Type 1,2 지원 - 11점 측거 AF 모듈 - 0.94배율의 넓은 파인더 - 2.5인치, 23만 컬러의 LCD 모니터 - 경량 마그네슘 합금 바디 - 고속 동조 가능 - i-ttl 가능한 조광 시스템 - Face Detection(얼짱나비) / Wireless Lan 전송 / 컬러 라이브뷰 가능

마이크로소프트(MS)는 자체 개발한 이미지 포맷으로 어느 곳에서나 사용되고 있는 JPEG을 밀어내려고 하고 있으며, 윈도우 비스타 출시가 그렇게 하는 데 도움이 될 것으로 기대하고 있다.

지난해 MS는 자체 개발한 이미지 표준을 홍보하기 시작했다. 이 표준은 윈도우 미디어 포토(Windows Media Photo)라 고 불리다가 지난해 11월에 HD 포토(HD Photo)로 이름을 바꿨다. MS의 야망은 노골적이다. MS의 디지털 이미징 홍보 담당 이사인 조시 와이즈버그(Josh Weisberg)는 “궁극적인 목표는 이 포맷이 디지털 사진에서 사용하는 사실상의 표준이 되게 하는 것”이라고 말했다.

사실「HD」는「고해상도(high definition)」를 의미한다기보다는 HDTV처럼 「더 좋은 품질의 이미지」라는 느낌을 전달하기 위한 용어다.

이 포맷 개발에 참여한 마이크로소프트 리서치(Microsoft Research)의 이사인 리코 말바(Rico Malvar)는 HD 포토는 JPEG에 비해 디테일이 훨씬 섬세하며 컬러도 더 풍부한 반면 같은 품질의 이미지를 저장하기 위해 필요한 공간은 절반에 불과하다고 말했다.

새 이미지 포맷이 널리 퍼지게 하는 것은 어려운 일이며 이미 자리잡은 표준을 밀어내는 것은 훨씬 더 어려운 일이지만 MS는 든든하게 밀어 주는 두 가지 힘을 믿고 있다.

제공: Microsoft

이 비교 자료는 JPEG, JPEG 2000 그리고 MS의 HD 포토(이전의 윈도우 미디어 포토)가 왼쪽 상단에 있는 이미지를 압축하면 어떻게 되는지 보여준다.

표시되는 컬러가 더 많을수록 압축된 이미지는 원본 이미지와 더 많이 차이가 난다. 완전히 검정색이라면 완벽하게 압축이 될 것이다. 압축된 각 이미지는 원본 이미지 파일 크기의 8분의 1이다.

우선 MS는 23일(미국시간)부터 일반 소비자 판매가 시작되는 윈도우 비스타에 HD 포토 지원 기능을 내장했다. 이것은 고객이 컴퓨터로 이미지를 업로드할 때 HD 포토를 지원하는 것을 고려할 카메라 제조업체들이 늘어날 것이며 웹 브라우저와 같은 소프트웨어가 HD 포토 이미지를 화면에 표시하고 저장할 수 있게 될 것임을 의미한다.

와이즈버그는 “이것은 분명히 이 포맷이 널리 퍼지도록 돕기 위한 것”이라며 “이 포맷을 윈도우에서 사용하게 하면 이 포맷을 사용하는 사용자 기반이 이미 상당히 확보되는 것”이라고 말했다.

그 다음에 어도비의 제품 관리 담당 선임 이사인 케빈 코너(Kevin Connor)는 가장 영향력 있는 이미지 편집 소프트웨어인 포토샵 제품군으로 유명한 어도비시스템즈가 HD 포토 지원에 일조할 것이라고 말했다.

어도비가 곧 내놓을 포토샵 CS3 버전에서는 「타이밍이 맞지 않아」 HD 포토 포맷을 지원하지 않지만 어도비는 윈도우용 포토샵과 맥 OS X용 포토샵 사용자들이 HD 포토 파일을 열어서 저장할 수 있게 하겠다는 목표로 MS와 협력해 플러그인을 만들고 있다.

코너는 “HD 포토의 좋은 점은 디지털 사진 사용의 발전 과정을 잘 파악해 디지털 사진에 맞춰 특별히 설계됐다는 점”이라며 “HD 포토를 JPEG만큼 널리 사용하게 되려면 분명히 시간이 걸리겠지만 지금 당장 소비자들이 HD 포토 사용을 선호할만한 이유가 있을 수도 있다”라고 덧붙였다.

「만만치 않은」 과제
뛰어난 이미지 포맷 기술이라고 해서 반드시 성공이 보장되는 것은 아니다. JPEG 2000(JPEG은 이 포맷을 만든 공동 사진 전문가 모임(Joint Photographic Experts Group)의 약자를 딴 이름임)은 JPEG보다 압축 품질이 더 뛰어나지만 실패작이었다.

마찬가지로 PNG(Portable Network Graphics) 포맷은 GIF(Graphics Interchange Format)의 문제점을 해결했지만 GIF를 밀어내지 못했다.

그렇기 때문에 카메라 제조사들은 제품에 포맷 지원을 내장할 때 매우 신중하다.

올림푸스 이미징 아메리카(Olympus Imaging America)의 제품 담당 매니저인 샐리 스미스 클레멘스(Sally Smith Clemens)는 “JPEG은 아키텍처 내에서 다양한 수준의 품질을 구현하는 업계 표준”이라며 “대체 포맷은 하드웨어와 소프트웨어 분야의 많은 개발자들이 매우 폭넓게 지원을 해야 실제적이거나 고려할 만한 것이 된다”고 덧붙였다.

JPEG에 불만을 가지고 있으며 HD 포토의 가치를 인정해 줄 가능성이 가장 높은 열성 팬들이 이미 이 대안, 즉 카메라의 이미지 센서에서 처리되지 않은 디테일 데이터를 곧바로 가져올 수 있는 원시 이미지 포맷을 환영하고 있음을 암시하는 증거는 더 많이 있다.

어도비는 자체 개발한 DNG(Digital Negative) 포맷을 통해 혼란스러울 정도로 다양한 원시 포맷들을 표준화하려고 시도하고 있다.

	JPEG를 밀어내는 것은 결코 만만치 않은 과제다.   - 케빈 코너, 어도비 시스템즈제품 관리 담당 선임 이사

하지만 아마 가장 큰 장애물은 JPEG의 저력이 될 것이다. 설사 MS가 HD 포토 포맷이 널리 사용되게 만든다 해도, JPEG을 밀어내는 것은 또 하나의 힘든 과제다.

코너는 “JPEG를 밀어내는 것은 결코 만만치 않은 과제다. 사실 JPEG은 사람들이 사용하는 데 아무 문제가 없기 때문이다. JPEG는 장치, 브라우저, 워크플로 등을 가리지 않고 어디서든 지원하는 개방형 표준이다”라고 말했다.

하지만 디지털 이미지 편집에 관한 다수의 저서를 집필한 에디 탭(Eddie Tapp)은 일반 사진가들은 HD 포토에 관심을 가질 것이라고 생각한다. 자동 카메라를 사용하는 대중들까지도 이미지 품질을 중요시하며 특히 오래된 사진을 다시 열어 보는 경우에 그러하다는 것이다.

에디 탭은 “누군가가 「아무개 산에서 찍은 사진 있잖아. 크게 복사해 주면 안될까?」하고 말하는 날이 올 것”이라며 “사람들은 찍어 놓은 이미지를 다시 보게 되면 「카메라 해상도가 더 높았으면 좋았을 텐데」하고 생각한다”고 덧붙였다.

MS는 이미 HD 포토를 개발하는 데 6년 이상 몰두했으며 앞으로도 몇 년 더 작업해야 한다는 것을 인정한다. 와이즈버그는 “이것이 채택되려면 시간이 좀 걸릴 것”이라고 말했다.

지원군 확보
MS는 이 포맷을 위한 사업 파트너들을 끌어들이기 위해서도 열심히 노력하고 있다. MS가 「윈도우 미디어 포토」라는 이름을 버린 것은 단순히 HD 포토라는 이름이 더 정확해서가 아니라 파트너들이 이의를 제기하기 때문이었다.

와이즈버그는 “윈도우와 관련된 무언가와 경쟁할 수도 있는 제품을 제조하는 회사들은 「윈도우」라는 브랜드에 속해 있는 것을 자기 제품에 포함시키는 것을 싫어했다”며 “업계에서 「MS가 윈도우 어쩌고 하는 걸 또 내놓고는 우리보고 사용하라고 하네」하는 식으로 반발하는 것은 별로 좋은 일이 아니다”라고 덧붙였다.

MS는 포맷 채택이 빨라지도록 라이선싱 장벽도 낮췄다. 와이즈버그는 “라이선스 조건을 보면 알겠지만 이 포맷은 과거처럼 「이걸로 수십억달러를 벌어보자」하는 그런 것이 아니다”라고 말했다. 라이선스를 받은 경우 HD 포토 이미지 호환성만 유지하면 된다.

와이즈버그는 MS가 이 기술의 특허를 보유하고는 있지만 오픈 소스 소프트웨어도 HD 포토를 지원할 수 있다고 말했다. HD 포토 기술에는 MS가 특허권을 주장하지 않기로 약속한 계약인 OSP(Open Specification Promise)가 적용된다.

그는 “우리가 살고 있는 세계는 MS의 에코시스템 내에서만 살 수 있는 그런 세계가 아니라는 것을 잘 안다”며 “우리는 HD 포토를 사용하거나 만들고 싶은 사람이라면 누구나 현실적인 부담을 지지 않고 그렇게 할 수 있게 하고 싶었다”라고 말했다.

MS는 소프트웨어 영역 밖에서도 어느 정도 지원을 받아냈다. 와이즈버그는 “HD 포토를 인식하는 실리콘(칩) 출하를 이미 시작했거나 곧 시작할 제조업체들이 여럿 있지만 시간은 좀 걸릴 것”이라고 말했다. 이것은 카메라에서 지원 기능을 내장하는 데 꼭 필요한 단계다.

하지만 이 포맷은 아직 MS 표준에 불과하다. 즉 다른 당사자들의 이익까지도 대변하는 중립 컨소시엄에서 관리하는 업계 표준이 아니다. 이것은 문제가 될 수 있다. 애플은 그 동안 어도비의 DNG가 업계 표준이길 바랐었다.

HD 포토 관련 문제에 대해 장황하게 설명하던 와이즈버그도 표준화 문제에 대해서만큼은 확실하게 침묵을 지키면서 “항상 주시하고 있는 문제”라고만 답변했다.

HD 포토의 장점
HD 포토가 JPEG보다 더 나은 점은 정확하게 무엇인가? 말바와 와이즈버그는 여러 가지 장점을 설명해줬다.

• 각 픽셀을 기준으로 HD 포토는 각 컬러에 대해 최소 16비트의 데이터를 저장하는데 JPEG은 8비트만 저장한다. 이것은 편집이나 인쇄 과정을 거쳐도 그림자 영역이나 밝은 영역의 미묘한 색조 차이를 그대로 보존할 수 있음을 의미한다. 극단적인 경우 컬러 당 32비트를 저장할 수도 있다. 이것은 여러 장의 사진을 결합해 가장 어두운 부분과 가장 밝은 부분을 모두 표현하는 「매우 역동적인」 이미지로 만드는 데 쓸모가 있다.

• HD 포토의 압축 알고리즘은 파일 크기가 같은 경우 JPEG에 비해 2배로 높은 품질의 이미지(품질이 같다면 파일 크기는 절반)를 표현할 수 있다. 이 알고리즘은 카메라의 이미지 처리 칩에 비교적 쉽게 내장할 수 있는 간단한 명령어를 사용한다.

• HD 포토는 보다 작은 「축소」 이미지를 만들기 때문에 작은 크기의 파일을 빨리 열 수 있다. 이에 비해 JPEG 축소 이미지는 컴퓨터 운영 체제에서 생성해야 한다.

• 가장 높은 표준으로 설정된 엔코딩 알고리즘은「손실이 없다」. 즉 품질 손실 없이 모든 이미지 데이터를 보존한다. 하지만, JPEG는「손실이 있다」. JPEG 2000도 손실이 없기는 하지만 별도의 알고리즘을 사용해야 하기 때문에 카메라 칩을 기준으로 보면 회로가 더 필요하다.

• HD 포토는 MS의 scRGB 색공간을 사용한다. 이 색공간은 흔히 사용하면서도 비웃음의 대상이 되는 sRGB 방식에 비해 가능한 컬러 영역이 훨씬 더 넓다. 코너는 “HD 포토는 더 높은 영역의 컬러도 지원한다. 이것은 점점 더 중요해지고 있다”라고 말했다.

카메라와 컴퓨터는 일반적으로 컬러를 RGB 방식, 즉 빨강, 초록, 파랑의 양으로 표현하지만 HD 포토는 청록, 진홍, 노랑, 검정을 사용하는 CMYK 방식도 사용할 수 있다. 이것은 CMYK 잉크를 사용하는 프린터로 이미지를 보낼 때 유용하다.

• 이 알고리즘은 HD 포토 이미지의 전체가 아니라 화면에 표시할 부분만 선택해 디코딩할 수 있다. 따라서 필요한 메모리가 줄어들며 처리 속도는 빨라진다. 또한 전체 이미지를 메모리에 올리지 않고 덩어리 단위로 인코딩할 수도 있다.

• HD 포토는 90도 단위로 쉽게 회전시킬 수 있다. JPEG 이미지는 디코딩과 인코딩을 반복해야 하며 매번 품질이 조금씩 저하된다.

• 압축된 이미지 크기가 32GB를 초과하지만 않으면 HD 포토 이미지를 어마어마하게 크게 만들 수도 있다.(최대 2억6,200만픽셀, 즉 총 68.6테라픽셀)

MS는 HD 포토 포맷을 윈도우 밖으로 내보내 전체 디지털 사진 세계로 확대하려면 전력투구해야 할 것임을 알고 있다.

말바는 “카메라 제조업체들은 「옆에 있는 문방구에서 인쇄할 수 없다면 JPEG를 그대로 사용하는 것이 더 좋다」고 생각한다”며 “그런 변화가 일어나기를 원하지만 전체 에코시스템이 형성되려면 시간이 좀 걸릴 것이라고 보는 것이 현실적”이라고 덧붙였다. @

출처 : ZDNet Korea

이달 31일 출시를 앞두고 있는 비스타, 이를 두고 네티즌 사이에서 액티브X 논란이 가열되고 있다.

새로게 출시되는 OS 윈도비스타선 사용자계정콘트롤(UAC)과 액티브X 설치를 막는 강력한 보안 기능으로 액티브X 사용에 제약이 있다. 하지만 우리나라의 경우 정부의 정책을 통해 SEED 알고리즘을 사용하면서 액티브X 사용이라는 고립의 길을 걷게 됐다는 비판과 함께 액티브X에 대한 가열찬 논란이 벌어지고 있다.

김국현 IT칼럼리스트는 ZDNet 칼럼을 통해 "은행 일이라도 한번 보려면 여러 개의 컨트롤을 일단 깔아댄다. 내 PC를 유린하듯 설치되는 컨트롤의 면모는 살펴 보니 하나 같이 '보안 모듈'"이라면서 "외국 굴지의 은행들은 브라우저만으로 인터넷 뱅킹을 무리 없이 수행하고 있으며 IE와 파이어폭스 모두 필요 충분한 수준의 암호화 기능은 물론 인증서 관리 기능도 들어 있다. 왜 보안을 웹의 외부 기능에 의존해야 하는 것인지 의문이 든다"고 전했다.

액티브X 논란「극과 극」
이에 대해 국내 공인인증시스템 개발/도입 당시부터 깊게 관여했던 사람이라고 밝힌 네티즌은 "당시 SEED를 강요함으로써 국내 업체만이 시장에 진입할 수 있도록 한 것은 사실이나 당시의 분위기는 각 국가별 독자 알고리즘 활성화가 당연했었던 상황"이었다고 전했다.

이어 "SEED가 아니더라도 브라우저의 SSL(서버인증서만의) 만으로는 사용자 인증 및 전자서명이 불가능했고, 사용자 인증서를 사용한다고 했다면 유료로 인한 문제 및 발급절차 자체의 어려움을 감당할 수 있었을까"라고 꼬집었다.

반면 다른 네티즌은 "문제는 왜 액티브X 이어야만 했는가이며, 중요한 것은 현재 우리나라의 공인인증서는 특정OS의 특정 브라우저만 지원한다는 것"이라며 "개발자들의 허접함과 관계부처의 안일한 태도가 오늘의 문제를 만든건 아닌지 생각해 봐야한다"고 비판했다.

네티즌 "엔지니어" 역시 "보안을 위한 샌드박스도 없이 인증만 믿고 설치하는 순간 PC에 대한 제어권을 가지게 되는 기술로 MS가 급조해낸 것이 액티브X"라며 "지금 포털과 정부는 비스타 출시 후 그냥 보안레벨을 낮춰서 우회하도록 유도하고 있다. 보안을 강화시켜놓으니 그 보안을 낮추도록 해서 일단 급한 불 끄고 보자는 근시안적인 대책으로 일관하고 있는 것에 한숨만 나온다"고 전했다.

한국MS「액티브X 사용 무리 없어」
한편 23일 한국마이크로소프트(이하 한국MS)는 정통부-국정원-금감원 등을 주축으로 한 보안 관련 협의 내용에 대해 발표할 예정이다.

한국MS 조원영 보안총괄 이사는 "윈도비스타로 인해 액티브X를 전면 못쓰게 된다고 생각하는 것은 잘못된 생각"이라고 꼬집으며 "액티브X를 통한 해킹 위험이 많이 있어, 이를 위한 시스템 파일만 못 건드리도록 설정돼 있는 것이므로 액티브X만 안전하게 변경하면 웹페이지를 문제없이 사용할 수 있다"고 전했다.

그는 이어 "대부분의 은행권과 메이저 포털들의 경우 거의 대부분 이러한 변경작업이 완료된 것으로 알고 있으며, 게임이나 온라인 쇼핑 등의 다른 온라인 사이트들도 늦어도 2월 말까지는 변경 작업이 모두 완료돼 불편 없이 사용할 수 있다"고 강조했다.

금융보안연구원 보안기술팀 성재모 팀장도 "일부에서 윈도XP 수준으로 보안이 떨어지는 것이 아니냐는 우려도 있었지만, 대부분의 보안 업체들이 비스타 버전으로 보안 솔루션을 개발한 상태로 1~2주 안으로 적용테스트를 끝내 빠르면 2월 초에 적용이 가능할 것으로 보인다"고 전했다.

또한 "하지만 IE7과의 호환성 문제가 남아있는 문제도 있어 이를 자체적 수정하기 위해선 시간이 조금 걸릴수도 있으나 2월 말경에는 모든 은행에서 문제가 해결될 수 있을 것으로 전망된다"고 말했다. @

요즈음 ActiveX, 정확히는 'ActiveX 컨트롤'이란 기술이 시끄럽다. 브라우저 밑으로 손을 뻗어 그 밑에 깔린 시스템의 기능을 만지작거릴 수 있게 하는 요물. 웹은 웹이로되 PC가 할 수 있는 모든 일을 하게끔 하는, 웹을 웹 이상으로 조작하기 위한 '만능 컨트롤' 도구, ActiveX. 90년대의 프로그래머들은 ActiveX가 포함된 COM이라는 테크놀로지 조합으로 PC 전성기를 풍미했다.

그런데 새 버전의 인터넷 익스플로러와 새 OS 윈도우 비스타는 자신들의 기술 ActiveX를 유리 상자 안에 가둬 버리고 만다. ActiveX란 뭐든지 만들 수 있지만, 뭐든지 망칠 수도 있는 양날의 검이었다. 새 플랫폼이 ActiveX에 거리를 두는 이유는 '시스템의 기능을 만지작거리는 일'이 악인에 의해서도 자행될 수 있다는 자각 때문이다. ActiveX는 모두가 순박했던 목가적 시절에나 어울리는 기술이었던 것이다.

게다가 이미 업계는 웹을 임의로 '컨트롤'하여 변경하는 일이 그리 바람직한 일도 아님을 공감하고 있다. 웹 표준 운동도 그 일환이다. ActiveX같은 로우레벨 아키텍처에 의존한 플랫폼을 만드는 일이란 플래시 수준의 입지를 지닌 플랫폼 제공자가 아니라면 비즈니스적으로도 별 의미가 없다는 것을 깨달았다. 마치 고급 언어를 배운 이래 어셈블리어를 만질 필요가 없듯, 굳이 웹을 개선한다는 목적만으로는 ActiveX라는 위험한 칼을 만질 이유가 없는 것이다.

물론 아이디어란 표준으로 묶어 놓기에는 너무나 자유분방한 것이기에, 올해도 내년에도 웹의 확장은 일어날 것이다. 그렇기에 웹을 초월한 무언가를 덧붙이려는 확장 욕구는 건전한 것이다. 브라우저로 하지 못하는 일을 새로운 아이디어로 '확장'하려는 욕망은 멈추기 힘들고, 이 점을 강조하기 위해서 일까? 파이어폭스가 ActiveX '컨트롤(Controls)'을 금지하고 대신 파이어폭스 '확장(Extension)'이란 개념을 도입한 의도는 그 용어에 잘 나타나 있다. 마이크로소프트도 이미 닷넷을 중심으로 기술 구조를 재편한지 오래다. ActiveX를 위시한 Win32의 리거시 기술들은 배후로 밀려나고, 웹의 확장 기능도 ActiveX라는 칼을 직접 만지지 않도록 유도하고 있다. 더 편하고 더 쉬운 확장을 할 수 있는 방안과 로드맵이 따로 있는 것이다.

그러나 우리는 유난히 ActiveX라는 날카로운 칼을 좋아했다. 그리고 무척이나 잘 드는 이 칼로 웹을 확장한 것이 아니라 오히려 웹의 여기저기를 도려내며 우리만의 아키텍처를 만들었다. 대한민국의 웹을 서핑하다 만나게 되는 수 없는 경고창들, 칼을 조심하라는 시스템의 경고지만 개의치 않는다. 수저가 필요한 곳에 칼이 놓이고 있다. 손잡이가 필요한 곳에 날이 서 있다.

칼날이 난무한다. 특히 은행 일이라도 한번 보려면 여러 개의 컨트롤을 일단 깔아댄다. 뭐가 뭔지 도무지 모르겠지만, 여하튼 설치하지 않으면 아무 것도 못하니 방법이 없다. 게다가 왜 이렇게 회사마다 종류가 골고루인지. 그렇게 내 PC를 유린하듯 설치되는 컨트롤의 면모는 살펴 보니 하나 같이 '보안 모듈'.

여기에서 의문이 생긴다. 왜 보안을 웹의 외부 기능에 의존해야 하는 것인가? 사실을 말하자면, 한국 수준의 보안은 모르겠으나 적어도 세계 수준의 보안은 브라우저 만으로도 얼마든지 확보할 수 있다. 외국 굴지의 은행들은 브라우저만으로 인터넷 뱅킹을 무리 없이 수행하고 있다. IE와 파이어폭스 모두 필요 충분한 수준의 암호화 기능은 물론 인증서 관리 기능도 들어 있다.


그런데 한국은 세계에서 통용되는 이러한 표준 기능은 활용하지 않은 채, 보안을 웹의 외부 기능으로 빼내어 독자적으로 처리하고 있다. 놀라운 기술 독립이다. 마이크로소프트도 모질라 재단도 놀라고 있는 일이다. 그들은 이해를 못하는 일이다.

왜? 도대체 왜 이 상황이 된 것일까?

여러 가지 도시 전설이 횡행하지만, ① 당시 미국의 128비트 암호화 수출 금지 조항에 맞선 독자 기술(SEED)의 개발과 적용 지도, ② 한국의 특수 상황이 발생시킨 정보 기관의 지침(보안 적합성 검증), ③ 독자적 최상위 인증 기관 운영 욕구, ④ 해킹 피해 발생 보도에 대한 과민 반응. 등이 복합적으로 작용했다는 설이다. 인터넷이 너무 일찍 퍼진 한국은 너무 급했고 너무 불안했던 것이다.

이 과정에서 얻은 일도 있을 것이다. 내수 보안 산업이 자생적 생태계를 꾸릴 수 있었다. 척박한 국내 IT 시장에서 나름대로 고용을 창출하고 기술을 연마해 온 그들에게 과연 “당신들의 존재 자체가 틀렸어!”라고 감히 말할 수 있을까? 누구도 그럴 용기가 없다. 완전한 기술 쇄국을 이끈 정부도 금융권도 IT 업계도 국민도 어느 누구도.

그러나 잠시 스스로를 돌아 볼 때다. 우리는 정말 세계 어느 나라보다 안전할까? 인증서 파일을 PC에서 PC로 옮겨 들고 다니는 일이 과연 최고의 보안 솔루션일까? 다른 나라처럼 암호 발생 카드나 암호 발생 열쇠고리를 사용하는 것이 차라리 안전하지 않을까? 전세계적으로 테스트되고 사용되고 있는 브라우저 들의 내부 보안 기능보다, 버그가 있을 수 있는 개별 기업의 외부 보안 솔루션이 더 안전하다고 우리는 진정 믿을 수 있을까? 우리에게는 잠시 쉬어가며 백지에서 다시 생각해 볼 여유가 필요한 것이다.

ActiveX의 문제란 결국 독자 기술의 꿈이 불러 온 기술 쇄국의 딜레마였던 것이다.

사실 아무 일도 아닐 수도 있다. 쇄국의 아키텍처를 끝까지 고수하며 업체를 압박한다면 어떻게든 솔루션은 생길지 모른다. 그러나 언제까지 그렇게 아슬아슬한 아키텍처를 우리는 가져갈 수 있을까? 새로운 OS가 등장할 때마다, 새로운 브라우저가 등장할 때마다 우리는 '우리의 실정'을 부르짖어야 할 테니까.

기술은 도구인 이상, 양날의 검이다. 잘 쓰면 유용한 도구이지만 목적을 잊은 채 수없이 주머니에 품고 있기에는 거북한 존재인 것이다. 잘못 들어가 있는 칼은 서서히 걷어내야 한다. 그리고 그 칼의 사용은, 그리고 더군다나 민생에 직결되는 서비스에서의 사용은 더 신중히 논의되어야 하는 것이다.

칼을 드는 순간, 내 스스로 누군가를 소외시키지는 않는지, 그리고 그 칼을 드는 순간 내가 세상으로부터 소외되지는 않은지 생각해 봐야 한다. 도구의 의미를 생각하지 않은 채, 용도를 숙고하지 않은 채, 도구의 방향을 관찰하지 않은 채, 도구를 본래의 취지와 맞지 않게 남용하는 것이 얼마나 무모한지 우리 사회는 그리고 업계는 어쩌면 매우 비싼 값을 치르며 배우고 있는 것인지도 모른다.

하루가 다르게 신기술이 쏟아진다. 시시각각 변화하는 IT 환경을 보고 있자면 문득 스펜서 존슨의 「누가 내 치즈를 옮겼을까」라는 책이 떠오른다. 사람들은 변화를 진행하고 있는 일의 일부라고 생각할 뿐 생활의 일부로 받아들이지 않는다. 자신이 하고 있는 일이 언제까지 계속 안정적으로 지속될 수 있을 것인가? 우리는 언제나 변화하고 있는 환경에 대처하는 준비가 필요하다. X인터넷의 활용 가치가 부각되는 요즘 관련 기술들에 대해 조금만 더 귀를 기울여 보자. 준비가 되었다면 지금부터 새로운 치즈인 ‘플렉스’를 향한 여행을 시작해 보자.

플렉스의 설치
플렉스의 탄생과 그 특성에 대해서는 각각 1, 2부에서 살펴봤다. 이 글에서는 플렉스의 설치에 관한 내용부터 접근해 보겠다. 여기서 설치하는 플렉스는 윈도우용 버전이며, 설치 파일은 .exe 파일로 제공되어 더블클릭만으로 쉽게 설치할 수 있다(만약 자바 애플리케이션 서버가 설치되어 있는 상태에서 플렉스를 설치한다면 설치 완료 후 해당 디렉토리에 war 파일의 압축을 풀어 배포하면 된다). 설치 도중 인스톨 옵션을 선택하는 항목이 나타나는데, 기존 자바 애플리케이션 서버가 설치되어 있는 곳에 플렉스를 설치할 것인지 또는 JRun4와 통합된 플렉스를 설치할 것인지를 선택해야 한다. 필자는 JRun4와 통합되어 있는 설치를 선택했다. JRun4와 통합된 플렉스를 설치하면 다음과 같은 폴더가 구성된다.

JRun4와 통합된 플렉스를 설치하면 war 파일 형태가 아닌 세 개의 폴더(flex, profiler, samples)가 생성되어 시스템에 위치하며, 기본적으로 8700포트가 사용된다. http://locathost:8700/samples 설치가 끝나면 샘플로 제작된 플렉스의 데모를 볼 수 있다. 자세한 설치 관련 사항은 플렉스 인스톨 문서(http://www.macromedia.com/go/flex_install)를 참고하기 바란다.

플렉스에서는 콜드퓨전이나 커뮤니케이션 서버와 같은 어드민 콘솔 형식의 사용자 컨피규레이션 툴은 제공하지 않는다. 서버의 설정은 flex-config 파일을 통해 가능하며, 여기서는 디버깅 정보 생성 여부(프로파일링 포함), 컴포넌트 관련 경로, 웹 서비스나 HTTP 서비스 그리고 리모트 오브젝트, 캐싱, 컴파일러, 플래시 플레이어 자동 감지, 로깅, 폰트 등을 설정할 수 있다.

플렉스 애플리케이션 제작에는 MXML과 액션스크립트가 사용된다. 두 가지의 언어로 작성된 코드는 플렉스 컴파일러에 의해 브라우저가 MXML 파일을 요청할 때 그에 상응하는 swf 파일로 컴파일해 사용자의 브라우저에서 보여진다. 현재 베타 4 테스트 중인 플렉스 빌더 ‘브래디(Brady)’로 제작하면 쉽고 빠르게 제작이 가능하지만, 일반적인 텍스트 에디터나 메모장을 사용해도 상관없다. 물론 자바 개발 툴인 이클립스 등을 사용해도 된다.

플렉스 컴포넌트
흔히 컴포넌트는 프로그램의 꽃이라 비유된다. 컴포넌트의 장점이라 한다면 간단한 설정을 통해 프래그램에서 다양한 효과를 손쉽게 구현할 수 있다는 데에 있다. 플렉스에서 컴포넌트들은 모두 액션스크립트의 MovieClip 클래스로부터 상속받아 사용된다(<그림 1>).

<그림 1> 플렉스 컴포넌트의 계층 구조

무비클립은 플래시에서 가장 많이 사용되는 요소 중 하나로, 외부로부터 불러들이는 플래시 무비나 그림들은 모두 무비클립 형태로 이용된다. 플렉스 프로그램의 개발시에도 개발자가 직접 만든 플래시 컴포넌트를 플렉스 애플리케이션에서 사용할 수 있다. 그러나 이때에는 작성된 결과물을 일반 swf 파일이 아닌 swc 파일 형식으로 만들어 사용해야 한다.

플래시에서는 컴포넌트의 개념이 스마트클립에서 출발해 MX 버전부터 본격적으로 적용됐다. 따라서 역사가 길다고 할 수는 없으나 유용한 컴포넌트들이 많이 존재한다. 컴포넌트 중 가장 일반적인 UI 컴포넌트 사용 예제를 살펴보자(<리스트 1>).

<리스트 1> component.mxml

<?xml version="1.0" encoding="utf-8"?><!--MXML 파일의 시작 부분에는 항상 XML을 선언해야 한다.--> <mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml">     <mx:Accordion heightFlex="1">       <mx:Canvas label="BUTTON">         <mx:Button x="70" y="45" alpha="20" label="submit" />         <mx:Button x="160" y="45" label="cancel" />       </mx:Canvas>       <mx:Canvas label="RADIO BUTTON">         <mx:RadioButton x="70" y="45" label="radio1" groupName="radio" />         <mx:RadioButton x="70" y="65" label="radio2" groupName="radio" />         <mx:RadioButton x="70" y="85" label="radio3" groupName="radio" />         </mx:Canvas>       <mx:Canvas label="CALENDAR">       <mx:DateField x="70" y="45" width="100"/>       <mx:DateChooser x="70" y="85" />       </mx:Canvas>     </mx:Accordion> </mx:Application>

<리스트 1>에서 컴포넌트의 내부 구성이 어떻게 되어 있는지는 전혀 알 수 없다(컴포넌트를 사용하면 사용자의 간단한 조작으로 원하는 형태의 결과물을 얻을 수 있다. 플렉스에서 사용되는 플래시 컴포넌트는 swc 파일로 존재한다). 몇 줄 되지 않는 코드에서 보여지는 화면은 정말 흥미롭다. 앞에서도 언급했듯 플렉스 컴포넌트는 무비클립 클래스에 기반을 두고 있다. 무비클립 클래스에 대한 자세한 내용은 「Flex ActionScript and MXML API Reference」를 참조하기 바란다.

<화면 1> 컴포넌트 예제

플렉스 컨트롤
컨트롤은 UI 컴포넌트의 컨트롤을 의미한다. 여기서는 Checkbox, Button, Text Area, 그리고 Combobox 컨트롤에 대해서 알아보자. 플렉스에서는 기본적인 컨트롤(버튼, 체크박스, 라디오 버튼 등)과 데이터 프로바이더 컨트롤(리스트, 트리, 콤보박스 등)을 제공한다.

<리스트 2> Control.mxml

<?xml version="1.0" encoding="utf-8"?> <mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml">   <mx:Script><!-- MXML에서 액션스크립트 구문을 사용할 때에는 항상 <mx:Script></mx:Script> 태그 안에서 사용해야 한다.-->     <![CDATA[     var cityArray : Array=[ <!?배열을 만들고 해당 값을 넣는다.-->       {label : "SEOUL", data :"SEOUL"},       {label : "TORONTO", data :"TORONTO"},       {label : "NEW YORK", data :"NEW YORK"}];     function addCity(){ <!--콤보박스에 새로운 아이템을 추가한다.-->       cityCombo.dataProvider.addItem("BUSAN","BUSAN");     }     function removeCity(){<!?콤보박스의 3번째 인덱스 아이템을 지운다.-->       cityCombo.dataProvider.removeItemAt(3);     }     ]]>   </mx:Script>   <mx:VBox id="myVbox">     <mx:CheckBox width="100" label="Checkbox?" />     <mx:ComboBox id="colorCombo">       <mx:dataProvider>       <mx:Array>         <mx:Object label="RED" data="RED"/>         <mx:Object label="BLUE" data="BLUE"/>         <mx:Object label="BLACK" data="BLACK"/>         </mx:Array>       </mx:dataProvider>     </mx:ComboBox>     <mx:ComboBox id="cityCombo" dataProvider="{cityArray}"/>       <!?콤보박스에 액션스크립트로 정의된 배열 값을 넣는다.-->     <mx:Button label="Add City" click="addCity()"/>     <mx:Button label="Remove City" click="removeCity()" /> <mx:TextInput id="myInput" width="150" /> …중략…

<리스트 2>에서 데이터 ComboBox 컨트롤에 데이터를 넣는 법, CDATA 섹션을 사용해 데이터를 처리하는 부분, MXML에서 Action 함수를 호출하는 부분은 유심히 봐야 한다. 기존의 데이터 ComboBox에 데이터를 설정하는 방법은 두 가지로 분류했다. colorCombo ComboBox에는 MXML 코드에서 직접 데이터를 넣었고, cityCombo ComboBox에는 프로그램적인 요소가 섞여 있을 경우 액션스크립트를 사용해 처리했다.

만일 XML 파서가 액션스크립트 구문 안에 ‘{‘ 나 ‘<’ 같은 문자들을 XML 코드로 인식해 파싱하게 되면 에러가 발생한다. 이런 경우에는 CDATA 섹션을 사용해 파싱하지 않고 파서에 넘겨주는 방법을 사용하며, 일반적으로 액션스크립트 블럭은 CDATA섹션으로 감싸주는 것이 좋다.

<화면 2> 컨트롤 예제

컨테이너 사용
컨테이너란 컴포넌트가 실행되는 것으로 알려져 있는 프로그램 빌딩 블럭 내의 애플리케이션이나 서브시스템을 말한다. 플렉스에서 컨테이너의 개념은 컨트롤을 담는 컴포넌트를 일컫는다. 보통 웹 프로그램에서는 화면을 프레임, 테이블 등으로 구성하지만 일반 윈도우 응용 프로그램 작성시에는 panel이나 Group Box 등을 이용해 화면을 구성하게 된다.

얼마 전 후배가 델파이로 작성된 프로그램을 갑자기 수정해야 할 일이 생겼다며 필자를 찾아 온 적이 있었다. 이 후배는 ASP, PHP, JSP 등 웹 프로그램만을 하다가 윈도우 응용 프로그램은 처음 접한 상황이었다. 그 후배가 필자를 급히 찾았던 이유는 기존에 구성된 폼에 패널을 추가해 화면을 재구성하는 내용이었다.

플래시는 Panel이나 Canvas 등을 사용해 화면을 구성하는 개념 없이 무비를 구성한다. 이 때문에 플렉스에서 컨테이너를 구성과 배치하는 것이 어색하게 느껴질 수도 있을 것이다. 가장 좋은 방법은 머릿속에 화면 구성을 생각해 놓고 자신이 생각한 그대로를 만들어 보는 것이다. 플렉스에서 컨테이너를 사용해 구성한 예제를 살펴보자(<리스트 3>).

<리스트 3> container.mxml

<?xml version="1.0" encoding="utf-8"?> <mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml">   <mx:XML id="treeModel" source="tree.xml"/><!?외부 XML 파일을 treeModel 변수로 참조--> 　   <mx:Panel id="main" title="Flex Samples Explorer">       <mx:HDividedBox backgroundColor="#FFFFFF" >         <mx:Tree id="topicTree" dataProvider="{treeModel}"/>}"/><!--tree 컴포넌트에 treeModel 변수로 참조된 XML 데이터를 삽입--> 　         <mx:TabNavigator id="tn"> 　      <mx:VBox label="Sample1">           아코디언 메뉴바 위치         </mx:VBox> 　      <mx:VBox > 　        <mx:VDividedBox > 　          데이터 그리드 위치 　        </mx:VDividedBox> 　        … 　      </mx:TabNavigator> 　      </mx:HDividedBox> 　      <mx:ControlBar horizontalAlign="right"> 　      </mx:ControlBar> 　    </mx:Panel> 　</mx:Application>

　
Panel 안에 Horizonatl divider로 좌우를 나눈 다음 좌측은 Tree가 위치하고, 우측은 다시 Tab TabNavigator로 나누었다. 오른쪽의 Tree 메뉴에서는 XML 파일에서 데이터를 읽어와 Tree 메뉴를 구성했다. 컨테이너를 사용해 화면을 구성할 때에는 일반 메모장이나 에디터 프로그램보다는 ‘브래디’를 활용하는 것이 더욱 편리하다. 마치 HTML로 화면 구성시 드림위버를 사용하는 것에 비유할 수 있다.

<화면 3> 컨테이너 예제

이벤트 사용
이벤트란 프로그램에 의해 감지되는 어떤 행동이나 발생된 사건 등을 가리킨다. 예를 들어 마우스 단추나 키보드 키를 누르는 것과 같이 사용자에 의해 발생하는 행위뿐 아니라, 특정 조건에 의해 시스템에서 발생한 일들도 이벤트로 간주된다.

대부분의 최신 응용 프로그램들은 이벤트에 반응하도록 설계되어 있기 때문에 프로그램을 만드는 데 있어 이벤트처리는 매우 중요하다. 플렉스 애플리케이션 역시 이벤트 처리가 중요한 것은 말할 것도 없다. 플렉스 애플리케이션에서는 액션스크립트를 사용해 발생되는 이벤트를 처리한다.

<리스트 4>는 기본적인 버튼 이벤트의 구성이다. 사용자가 버튼을 클릭하면 btnClick 함수를 호출한다. 여기서 MXML 파일에서 click 이벤트를 호출하는 방법은 자바스크립트의 문법과 거의 유사하다. ComboBox에 두 가지의 이벤트가 사용됐다. 콤보박스가 열릴 때 openEvt() 함수를 호출하고, 내용이 바뀔 때 changeEvt()가 실행되어 Object를 인자로 넘긴다.

<리스트 4> event1.mxml

<?xml version="1.0" encoding="utf-8"?> <mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml">   <mx:Script>     <![CDATA[       function openEvt(){<!--콤보박스가 열릴 때 호출된다.-->       forChange.text="";       }       function changeEvt(e){<!?콤보박스가 변경될 때 호출된다.-->         forChange.text=e.target.value+" "+" "+e.target.selectedIndex;       }       ]]>   </mx:Script>       <mx:ComboBox open="openEvt()" change="changeEvt(event)">       <mx:dataProvider>         <mx:Array>           <mx:String>Orange</mx:String>           <mx:String>Apple</mx:String>           <mx:String>Mango</mx:String>         </mx:Array>       </mx:dataProvider>   </mx:ComboBox>   <mx:TextArea id="forChange" width="100"/> </mx:Application>

　

<화면 4> 이벤트 1 예제		<화면 5> 이벤트 2 예제

<리스트 5>는 이벤트 리스너를 사용한 이벤트 처리 예제이다. 이벤트 리스너는 함수가 아닌 객체이므로 객체를 생성한 다음 addEventListener 메쏘드로 해당 이벤트를 추가한 후 사용해야 한다.

<리스트 5> event2.mxml

<?xml version="1.0" encoding="utf-8"?> <mx:Application initialize="createListener()" xmlns:mx="http://www.macromedia.com/2003/mxml">   <mx:Script>     <![CDATA[       function createListener(){         var myListener = new Object();         myListener.click = function(event){           if(event.target.className == "Button"){             alert("Button Event");           }else if(event.target.className == "CheckBox"){             alert("CheckBox Event");           }         }         button1.addEventListener("click", myListener);         cb1.addEventListener("click", myListener);       }     ]]>   </mx:Script>   <mx:Button label="submit" id="button1"/>   <mx:CheckBox label="All Words" id="cb1"/> </mx:Application>

　
스타일 사용
플렉스 컴포넌트의 외형을 바꾸기 위해서는 스타일 프로퍼티를 사용해야 한다. 프로퍼티로는 크기, 폰트, 라벨 컨트롤 또는 배경색을 수정하는 데 사용되며, 한번 정의된 스타일을 이용해 모든 타입과 클래스에 이 속성을 적용시킬 수 있다. 또한 이 속성을 이용해 사용자가 적용하고 싶은 곳에만 스타일을 적용시킬 수도 있어 사용자가 애플리케이션을 제작할 때 매우 유연하게 컨트롤할 수 있다.

일반적으로 이 방법은 해당 파일에만 스타일을 적용할 경우 사용되며, 태그 안에 스타일 속성을 정의한다. 또한 StyleManager 클래스를 사용해 스타일을 적용하면 글로벌하게 스타일을 적용시킬 수 있다. StyleManager를 사용한 스타일의 적용 문법은 mx.styles.StyleMamager.styles.style_name.setStyle(“property”, value);과 같다.

<화면 6> 스타일 예제

스타일 프로퍼티를 직접 제어하는 방법은 mx.styles.StyleMamager.styles.style_name.property=“value”;과 같다. 글로벌한 스타일을 적용시킬 경우에는 타입과 클래스를 선택해서 적용시킬 수 있다.


다음은 setStyle()과 getStyle 메쏘드를 적용시킨 예제이다.

스타일시트가 적용되는 우선 순위는 <그림 2>와 같다.
◆ 해당 코드 라인에 정의된 경우 :
◆ setSyle() 메쏘드가 정의된 경우 : btn1.setStyle(“color”, “red”)
◆ 인스턴스 클래스 선택의 경우 :
◆ 타입 선택의 경우 : Button{ color : red }
또는 StyleManager.styles.Button.setStyle(“color”, “red”)
◆ Global 스타일 타입 선택의 경우 : Global{ color : red }
또는 StyleManager.styles.global.setStyle ("color”, "red”)

<그림 2> 스타일시트 적용 우선순위

드래그 앤 드롭 매니저 사용
리치 인터넷애플리케이션의 장점을 그대로 보여지게 하는 기능 중 하나이다. 컴포넌트 또는 리스트, 이미지 등의 데이터 이동이 마우스의 드래그 앤 드롭만으로 가능하다. <화면 7>에서 볼 수 있듯이 놀라운 효과의 구성이 플렉스에서는 너무도 간단하게 구현 가능하다.

<화면 7> 드래그 앤 드롭 예제 1

이 기능을 활용하면 시각적인 효과가 뛰어나고 사용하기 쉬운 애플리케이션을 제작할 수 있다. <리스트 6>은 Canvas 컨테이너에는 드래그가 가능하도록 MouseDown 이벤트를 정의하고, List 컨트롤에는 dragEnter, dragExit, dragOver, dragdrop 이벤트를 정의해 구성된 예제이다.

<리스트 6> dragAndDrop.mxml

<?xml version="1.0" encoding="utf-8"?> <mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml" width="400" height="600" marginLeft="6" marginRight="6" initialize="appInit()"> <mx:Script source="DragHandlers.as"/> <!--액션스크립트 코드를 불러들인다.--> <mx:Tile width="263"> <mx:Canvas backgroundColor="#FF0000" width="30" height="30" mouseDown="dragIt(event, 'Red 1','red')"> <!?Canvas에 드래그를 위해 mouseDown 이벤트를 정의한다.-->   <mx:Label text="1" x="8" y="6" width="22" height="24"/> </mx:Canvas> ... </mx:Tile> <mx:VBox> <mx:Label text="Drag red items into this list" /> <mx:List dragEnter="doDragEnter(event,'red')" <!?리스트 컨트롤에 dragEnter, dragExit, dragOver, dragDrop 이벤트를 정의한다.-->   dragExit="doDragExit(event);"   dragOver="doDragOver(event);"   dragDrop="doDragDrop(event,'firstList',['red'])"   widthFlex="1"   heightFlex="1"   height="50"   id="firstList" /> <mx:Label text="Drag blue items into this list" /> … DragHandlers .as import mx.managers.DragManager; <!--드래그 매니저, 드래그 소스의 클래스에서 임포트해야 한다.--> import mx.core.DragSource; function dragIt(event,text,format){   var ds : DragSource = new DragSource();     ds.addData(text, format); <!?데이터 소스에 인자 값으로 넘겨받은 text, format 데이터를 넣는다.-->     DragManager.doDrag(event.target , ds, mx.containers.Canvas,     {backgroundColor:event.target.backgroundColor, width : 30 , height:30},     undefined, undefined, 30); <!?doDrog 메소드를 호출한다. --> } function doDragEnter(event, format){ <!?인자 값으로 넘겨받은 format 값을 비교해 list 컨트롤에 추가 여부를 판단한다.-->   if(event.dragSource.hasFormat(format)||format=="any"){     event.handled = true;     event.target.drawFocus(true); } } function doDragOver(event){ <!?키값을 체크하여 copy, link, move를 결정한다.-->   if(Key.isDown(Key.CONTROL))     event.action = DragManager.COPY;   else if(Key.isDown(Key.SHIFT))     event.action = DragManager.LINK;   else     event.action = DragManager.MOVE; } function doDragDrop(event, target, formats){ <!--doDragOver 함수에서 정의된 내용을 바탕으로 list컨트롤에 추가한다.-->   var prefix:String = "";   if(event.action == DragManager.COPY)     prefix = "Copy of ";   else if(event.action == DragManager.LINK)     prefix = "Link to ";   doDragExit(event)   for(var i=0; i<formats.length; i++){     var data = event.dragSource.dataForFormat(formats[i]);     if(data != undefined){       this[target].addItem(prefix + data);       }   } } …

소스를 하나씩 살펴보자. 사용자가 Canvas 컨테이너를 드래그할 때 dragIt() 함수를 호출하며, 함수 내에 정의된 DragManager 클래스인 dodrag 메쏘드가 실행되어 Canvas가 드레그된다. 이때 드래그된 컨테이너가 타겟 컨테이너 위에 위치하면 dragEnter() 함수가 해당 컨테이너로의 추가 여부를 판단한다. 만일 조건이 성립되면 doDragDrop 함수를 통해 해당 아이템을 추가한다.

또한 doDragDrop() 함수는 doDragOver() 함수에서 데이터의 복사, 링크, 이동 여부를 판단해(함수에서 정의한 대로 <Ctrl> 키를 누르고 타겟 컨테이너 위에 위치하면 복사, <Shift> 키는 링크, 아무런 키의 누름이 없으면 이동으로 처리된다) 각 조건에 맞는 문자열을 List 컨트롤에 추가한다.

<화면 8> 드래그 앤 드롭 예제 2

액션스크립트 프로파일러
기존의 스크립트 언어에서 코드의 성능 측정(performance profiling)은 거의 불가능한 일이었다. 그러나 플렉스에서는 자신이 만든 프로그램의 성능을 측정할 수 있는 액션스크립트 프로파일러가 존재한다. 프로파일러는 J2SE 1.3 스펙을 지원하는 운영체제와 애플리케이션 서버에서 동작하며, 플래시 플레이어에서 실행되는 액션스크립트의 성능 데이터를 출력하고 리포트 생성기를 통해 출력된 데이터를 바탕으로 보고서를 보여준다(웹 브라우저를 통해 보여진다, http://localhost:8700/profiler).

프로파일러는 플래시 플레이어가 swf 파일을 실행할 때(플래시에서 디버깅 모드로 컴파일해야 한다. 즉 swd 파일이 존재해야 한다) 함수가 실행된다. 이 때 요구되는 시간은 밀리세컨드 단위로 측정하고 파일에 바이너리 포맷으로 시간 데이터를 기록한다. 파일에 기록된 바이너리 데이터는 프로파일링 세션 동안 swf 애플리케이션의 실행 내용을 보여준다. 액션스크립트 프로파일러를 통해 다음과 같은 성능 데이터 측정이 가능하다.

◆ 성능 스냅샷 요약(Performance Snapshot Summary) : 프로파일링 세션 동안 플레이어가 실행하는 모든 함수를 요약해서 보여준다. 요약 보고서는 다른 성능 분석의 시작점이 된다. 이 보고서는 호출 횟수, 누적 시간, 셀프타임 등이 보여진다. 셀프타임(self-time)이란 하나의 메쏘드가 실행되는데 걸린 총 시간을 말하고, 사용자들은 누적 시간 별, 셀프타임 별로 데이터를 정렬할 수 있다. 그리고 요약 보고서에 있는 이름을 클릭함으로써 성능이 좋지 않은 함수를 발견하고 수정 및 보완할 수 있다.
◆ 메쏘드 레벨 통계(Method-Level Statistics) : 한 명의 사용자가 로파일링 세션 동안 플레이어에서 실행하기 위해 선택되는 함수 하나의 통계를 보여준다. 성능 스냅샷 요약과 유사하게 호출 횟수, 누적 시간, 셀프타임을 보여준다. 정렬 기능을 지원하며 사용자들은 다른 메쏘드 레벨 통계로 가기 위해 함수 이름을 클릭할 수 있다.
◆ MXML/액션스크립트 소스 레벨 통계 : 액션스크립트 소스 레벨 통계 페이지는 로파일링 세션 동안 사용자가 선택한 함수의 통계를 보여준다. 이것은 호출 횟수를 라인별로 보여주며, MXML 컴포넌트들의 모든 태그 안에 있는 함수의 실행 시간을 보여준다.
◆ 프레임 기반 성능 요약(Frame-Based Performance Summary) : 프로파일링 세션 동안 업데이트되는 프레임 사이에 실행되는 모든 함수의 실행 시간을 보여준다. 그러나 기본적으로 프레임 기반 관점으로 데이터를 보여주는 성능 스냅샷 요약 보고서와 같다.
◆ 비동기 함수 레이턴시(Asynchronous Function Latencies) :모든 네트워크 함수의 지연 시간을 밀리세컨드로 보여준다.

일신우일신 ‘플렉스’
지금까지 플렉스에서 사용되는 기본 요소들에 대해 간단히 살펴봤다. 매크로미디어는 X인터넷의 선두 주자이며, 그 중 플렉스는 확실히 리치 인터넷 애플리케이션을 쉽고 빠르게 개발하기 위한 좋은 도구임에 틀림없다. 또한 지금 베타 4 테스트중인 플렉스 IDE 툴 ‘브래디’가 정식 발매되어 사용된다면 그 효과는 더할 나위가 없을 것이다. 플래시가 버전을 거듭할수록 언제나 새로운 모습을 보여왔듯 플렉스 역시 계속해서 새로운 모습을 보일 것임을 믿어 의심치 않는다. @