디자인하는 감정은행

정말 두고두고 보여주고 싶은 글이군요...
이글이 정말 정답이라는 글은 아니지만 읽으면서 웹디자인쪽이나 디자인을 하시는분들에게
문서화 해서라도 보여주고 싶은 글입니다.
아래의 글은 그분의 개인적인 의견이 저와 일치하지는 않지만
후배 디자이너에게 한번씩 읽게 해주고픈 글입니다.

출처


웹디자이너는 홈페이지 구축에 있어 기획된 스토리보드에 의거하여 화면디자인을 하는 사람을 말합니다. 정보를 사용자가 효과적으로 이해하기 위해서는 컨텐츠의 내용뿐만 아니라 컨텐츠를 효율적으로 배분하고 이해하기 쉽게 화면을 구성하는것이 중요하다 이는 같은 내용을 제시하는 사이트 일지라도 화면구성이 어떻게 다르냐에 따라서 내용의 가치가 달라 보이기 때문이다. 구체적으로 디자이너는 웹컨텐츠제작에 필요한 자료를 사용자가 이해하기 쉽도록 쾌적하게 화면 레이아웃 및 디자인을 구상하는것을 말한다.
전공을 하지않았는데도 할수있나?
우선 네 무조건 할수있습니다
꼭 디자인을 전공했다고 해서 웹디자인을 잘하는 것은 절대 아닙니다 10년 넘게 영어를 공부했고, 대학에서 영문학을 전공했다고 영어를 다 잘하는 것이 아니듯, 디자인을 전공했다고 해서 뛰어난 웹디자이너가 되는 것은 아닙니다.웹디자인은 미적 감각과 기능적인 부분이 함께 잘 조화 됐을 때 훌륭한 작품이 나옵니다.
또한 모니터상에서 펼쳐지는 디자인은 다른 디자인들과 많은 차이와 특수성을 가지고 있습니다.
그렇기에 웹상에서 필요한 디자인은 그 특수성을 인식하고 하였을 때 제대로 된 디자인이 나올 수 있는 것입니다.

얼마 전 '앙드레 김은 웹디자이너가 아니다'라는 글을 읽은 적이 있습니다. 있는데, 아주 적당한 비유였다고 생각합니다.
그 글의 요지는 전공자가 유리하기는 하지만, 그것이 전부는 아니며 디자이너에게 가장 필요한 것은 감각 이라는 것이었다.
디자인 전공자가 아닌 사람이 자기의 미적 감각을 개발하지 않았기 느끼는 것이지무조건 디자인 전공자가 디자인을 더 잘한다고 볼 수 없는 것입니다. 거니깐요 가치판단에 기준을 자격증에 두지마시고 감각과 실력으로 현재 웹디자인 시장에는 아직까지 전공자가 그리많지 않은걸로 알고있습니다
중요한것은 전공이냐 비전공이냐가 아니라 자신의 노력여하와 실력을 믿고 열씨미 하면 누구든지 할수있는 직업이라고 생각합니다

나의 디자인 감각과 센스가 어떤지 분석해 보고 그 감각을 발전시키고 유지하기 위해서 노력하면 좋은결과가 기다립니다.
연봉은 얼마나 되나요?

정말 에매한 질문이 아닐 수 없습니다. 일반 사무직이라면 년차로 해서 그 사람의 연봉이 쉽게 계산 될 수 있겠지만 , 웹디자이너란 직업이 전문직이기 때문에 각자 마다 틀리구 회사마다 틀립니다.
'웹'자 들어간 직업은 하늘 높은 줄 모르고 몸값이 치솟고 있다. 물론 이 가운 데 특히 상종가를 기록하는 직종이 있는데, 그 하나가 단연 '웹 디자이너'. 아 울러 전자 상거래 홈페이지와 포털 사이트를 기획 및 제작하는 '웹 기획자'와 '웹 프로그래머', 벤처 기업의 기술을 홍보하여 투자를 유치하도록 만들어주 는 '웹 프로모터' 들이 이 시대 최고의 직종으로 꼽히고 있다.
미국에서도 21세기 최고의 직종으로 '웹 사이트 매니저'가 꼽혔고, 이어 웹마 스터, 웹 개발자, 웹 프로그래머, 웹 기획자 등이 다섯 손가락 안에 꼽히는 황 금 직종으로 선정된 바 있다.

이렇듯 웹 직업 열풍이 불자 대다수의 사람들은 '웹'자 들어간 직업을 가지면 모두 기천만원대의 연봉을 받으며 제대로 된 대접을 받을 거라고 생각한다. 하지만 분명 오해다. 현재 웹 직업에 쓸 만한 사람이 없다는 것은 사람은 많되 그만한 경력자 내지 능력자가 없다는 것을 뜻한다. 특히 지난 석 달 동안 3,000개의 인터넷 벤처 기업이 생겼지만 웹자 들어간 직종의 실력자들이 씨가 마른 상태. 이는 웹 관련 직종이 인기 있는 이유 중 하나이다.

예를 들자면 프로야구 선수가 오래 되었다구 해서 몸값을 높게 받는 것이 아 니라 그 선수의 능력을 측정하여 연봉을 계산 하듯이, 웹디자이너두 그 사람 의 디자인 능력과 여러가지 제반 능력을 측정하여 연봉을 계산하게 됩니다.

웹디자이너중에는 연봉 1억을 넘는 사람도 있지만, 제 판단으로는 10명이 넘지 않을 것으로 봅니다.

또한 뉴스에서 웹디자이너들이 엄청나게 많은 월급을 받고 있는 것처럼 보도 되지만 그것은 사실이 아니라고 봅니다.
대개가 일반 셀리맨 수준의 월급을 받습니다. 그러나 그 사람의 능력이 탁월 하다면 몸값은 엄청나게 올라갑니다.

보통 처음시작하는 사람은 연봉, 1,200~1,500 사이가 되고 1년차의 경우가 1,800정도 되며 2~3년차가 2,000~3,000만원 수준입니다. 웹디자인 시작은 어디서부터 해야하나요?

웹자인이란 "웹+디자인"입니다. 다시말해 인터넷을 위한 그래픽으로 해석되 지요. 자 웹을 만들기 위해 필요한 것이 바로 "HTML"이구요. 디자인을 하기 위한 기본적인 것이 "포토샵"입니다.

그래픽을 만들 줄 아는 능력과 그것을 웹상에 표현하는 능력만 갖춰지면 웹디자인의 능력이 어느정도 갖춰졌다고 할 수 있습니다.

이 기본적인 것을 배우고 나면 자기가 만든 홈페이지에 살을 붙이는 역활이 자바스크립, 플래쉬, 드림위버 정도라 보시면 됩니다.
따라서 웹디자인을 공부하시려 계획하시는 분은 먼저 포토샵과 HTML을 공부하십시요. html 은 웹에 기본이기때문에 꼭 알아야합니다.

처음하시는 분들이 가장 고민스러워 하는 것이 어떤것을 먼저 공부하는 것인데. 각기 본인 특색에 따라 틀리지만 성격이 급하신분은 프로그램 툴 가능하면 드림위버를 먼저공부를 하는 것이 좋구요. 성격이 차근차 근하신분은 2D부터 천천히 공부하시는 것이 좋을 것 같습니다.
물론 플래쉬, 포토샵, 드림위버를 가지고도 홈페이지를 만들었다는 이야기를 많이 들었을 것입니다. 하지만 웹디자이너가 되기 위해서는 다양한 툴을 사용해야 합니다.

포토샵은 칼라로 과정이 세세하게 나온 책을 사서 한번 대충 쭉 읽어 보신 후 거기에 있는 예제들을 따라해 보십시요. 한 10일만 하면 충분히 자신감이 붙 을 것입니다. HTML은 굳이 책을 안 사셔도 됩니다.
인터넷 상에 너무도 좋은 사이트들이 많으니까요.

(추가)앞으로는 여러분께서 html을 공부하고 xml또한 공부를 해야 된다고 생각됩니다.
웹 디자이너 10계명

1. 몇가지 다른 기능의 툴을 자유롭게 사용할 수 있는가.
웹디자이너가 필수적으로 다루어야 할 툴은 무엇이 있을까? 우선 그래픽 툴부터 따져보자면 Bitmap방식의 대표적인 툴인 Photoshop과 Panitshop pro 와 Vector방식의 Illustrator와 Coreldraw가 있으며그 외에 Imageready, Freehand, Painter, Gif Animator 등이 있다.간단한 문자 3D를 생성 해 주는 Xara 3D와 Cool 3D라는 프로그램도 있으며, 조금은 복잡한 3D 프로그램인 3D Max 등의 프로그램도 함께 다룰 줄 안다면 보다 전문적인 디자이너가 될 수 있다.또한 에디터 툴도 필요하다. 요즘 많이 사용하는 툴은 Dreamweaver, Golive, 나모 웹에디터, Frontpage 등인데 모두 각기 조금씩 기능이 다르며 한가지만 전문적으로 사용하는 것도 좋지만 되도록이면 모두 사용할 줄 안다면 각 프로그램의 장단점을 파악하여 가장 쉽게 만들어 주는 기능들을 그때그때 사용하는 것도 좋은 방법이다.이상의 프로그램 외에도 웹에 쓰이는 프로그램이 많이 있다.툴만 많이 쓸 줄 안다고 훌륭한 디자이너가 된다고 할 수는 없지만 같은 상황이라면 유리하다고는 할 수 있겠다.

2. 브라우져는 자신의 컴퓨터에 다양하게 설치 해 놓고 있는가.

웹디자이너는 항상 브라우져에 민감해야한다. 새로운 버전의 브라우져가 나왔다고 해서 이전버전의 프로그램을 지우고 이용해서는 안된다. 웹디자이너는 항상 최악의 환경에서 이용하고있는 유저들을 인식해야 하며 그사람들을 위한 환경도 고려해야 한다.그러므로 다양한 종류의 브라우져와 버전으로 테스트를 걸친 후에 오픈해야 하는 책임이 있다.

3. 업계의 동향을 항상 파악하고 있는가.

모든 것에는 유행이 있듯이 웹사이트에도 유행이 있다. 성격에 있어서도 포탈사이트에서 허브사이트로 바뀌어 가는 경향이 있듯이 이에 맞는 사이트 레이아웃과 디자인도 달라져야한다.웹디자이너는 디자인만 하는 것이 아니다. 가장 중요한 것은 사이트 기획력이며 성격에 알맞은 디자인을 기획하기 위해서는 웹에 대한 다양한 지식을 가지고 있어야 하며 항상 변화에 대응하여 준비를 철저히 해 놓고 있어야 한다. 다행히 웹은 모든 정보가 인터넷에 공개되어 있으므로 자신만 관심을 갖고 부지런히 배워간다면 훌륭한 웹디자이너가 될 수 있다.더 많이 아는 클라이언트에게 끌려가기 보다는 더 많이 아는 디자이너가 클라이언트에게 제안하고 설득할 수 있는 능력이 있어야 한다.

4. 자신의 디자인에 대한 컨셉과 특징을 정확하게 표현할 수 있는가.

모든 일에는 이유와 목적이 있듯에 디자인에도 정확한 의도가 있어야 한다.자신이 만든 디자인의 레이아웃이 왜 이래야만 하는지? 어떤 의도로 이렇게 표현하였는지 클라이언트에게 설명할 수 있어야 한다는 것이다.이유도 없고 의도도 없는 마냥 예쁘고 참신한 화면은 결코 쉽게 설득될 수 없는 디자인이다.웹디자인은 예술성 보다는 상업성과 기능을 함께 창출 해 낼 수 있는 디자인의 또다른 장르이다.

5. 웹서핑은 자주 하는가.

디자이너가 하루종일 회사에서 웹서핑만 한다고 꾸짖는 상사는 참으로 뭘 모르는 사람이다.(물론 게임이나 채팅, 주식은 하는 경우는 다르지만…)디자이너는 최대한 많은 웹사이트를 돌아다녀보아야 한다. 최소한 국내의 모든 회사와 국외의 유명한 회사의 홈페이지 정도는 모두 꿰뚫고 있어야 한다.누군가가 불시에 어디어디 사이트를 아느냐? 라고 물었을 때 "그게 뭔가요?" 또는 "뭐하는 곳이지요?"라고 되묻는다면 참으로 안타까운 일이 될 것이다.웹디자이너는 그 누구보다도 많은 사이트를 돌아다녀야 한다. 왜 그래야만 하는지, 또 어떻게 바뀌어야 하겠다는 정도의 관심정도는 가져야 하지 않을까?

6. 웹프로그래머와 항상 상의하라.

웹디자이너 중 그래픽작업만 하는 디자이너와 HTML, Scripting까지 모두 작업하는 디자이너가 있다.물론 후자가 더 능력있다 할 수 있으나 그래픽작업만으로도 충분히 능력을 인정받는 디자이너도 많이 있다.그러나 중요한 것은 웹의 신기술, 예를 들면 Style Sheet, DHTML, Java-script, Java Applet 등이 어느정도까지 뒷받침 해 줄 수 있는지를 알고 있어야 디자인의 상상력의 범위도 달라질 수 있다.메인메뉴와 서브메뉴로 펼쳐지는 기술도 수도 없이 많은 방법이 있다. 그중 가장 적합한 방법을 선택하는 것, 또 그보다 더 뛰어난 방법을 고안 해 내는 것은 프로그래머와 디자이너가 함께 노력해야 할 일이다. 웹프로그래머가 방법을 가르쳐 줄 수도 있지만 더 좋은 것은 디자이너가 기본 지식을 바탕으로 표현의 범위를 제안 해 보는 것이다.또한 DB와 관련된 지식도 기본적인 것은 알고 있어야 한다. 게시판을 디자인 하더라도 그 게시판의 구동원리를 알고 디자인 하는 것과 모르고 하는 것은 표현의 방법에서 많은 차이를 보일 수 있기 때문이다.

7. 모방에서 창조로 발전시킬 수 있는 능력모든 디자인은 모방에서 시작된다.

같은 사람의 한가지 샘플을 보고 아이디어를 얻어 디자인 한다고 해도 그 샘플을 그대로 모방하지 않는 한 작업 결과물은 판이하게 다른 현상을 보인다.웹사이트를 많이 보아야 하는 이유도 이 때문이다. 맘에 드는 사이트를 화면캡쳐 해 놓고 아이디어가 부족할 때에 한번씩 꺼내보고 작업을 한다면 훨신 창의적인 사이트로 디자인 할 수 있다.모방을 기반으로 훌륭한 사이트로 창조해낼 수 있는 것. 이것이 디자이너의 능력이 아닐까?

8. 작업한 소스는 모두 간직하라.
실패한 시안, 만들다만 디자인 레이아웃… 이런 것들은 모두 나중에 좋은 재산이 될 수 있다.절대로 지난 작업분을 버리지 말고 보관하자. 나중에 꺼내보면 쓸만한 것들이 많을 것이다.실패했던 소스를 기반으로 더 멋진 화면으로 언제든 발전 시킬 수 있기 때문이다.

9. 항상 겸허하게 남의 것을 받아들일 줄 알라.
프로젝트에서 가장 힘든 것이 클라언트와의 의견충돌이다. 보통사람들은 대체로 디자이너들은 고집이 세다고 생각한다. 고집 센 디자이너. 다분히 매력적일 수 있으나 어찌보면 고지식한 사람으로 보여질 수도 있다. 디자이너가 아니라도 상대에게서 배울점은 많이 있다. 그들의 의견을 흘려 듣지 말고 항상 수용하는 입장에서 버릴 것은 버리고 받아들일 것은 겸허하게 받아들여야 한다. 웹디자인은 예술성도 중요하지만 상업성도 중요하다. 많은 사람들이 쉽게 친숙 해 지고 자연스럽게 받아들일 수 있는 디자인을 만드는 것, 이것이 웹디자이너의 역할이다.

10. 웹디자이너는 팔방미인?

현재 미국의 실리콘밸리에서 가장 인기있는 직업 1위가 웹디자이너라고 한다.우리나에서도 웹디자이너가 되고 싶어하는 사람이 엄청나게 늘어나고 있다. 그러나 웹디자이너는 그리 쉬운 직업이 아니다. 디자인 감각과 기획력, 프로그래밍 능력까지 모두 갖추어야 하기 때문이다.누구나 쉽게 시작할 수 있는 직업이기도 하지만 아무나 성공할 수 있는 분야의 직업도 아니다.항상 새롭게 발전하고 적응할 수 있는 디자이너가 되어야 하겠다

웹 디자이너는 화가가 아니다

웹디자인은 특정한 대상을 위한 디자인이 아니다, 순수 예술과 같이 매니아를 형성해 나아가거나 적품성을 위주로 작업하는 것이 아니다. 정말 잘된 웹디자인은 사용자의 편의성, 정보의 효과적인 전달 에 초점이 맞추어진 것이다.
물론이와 더불어 마음에 와닿는 디자인 감각이 느껴진다면 더욱 좋을 것이다.
웹디자이너는 웹이라는 매체를 통해서 정보를 전달하는 시안이다.

웹 디자이너는 기획능력이 있어야 한다

웹디자이너는 프로젝트의 시작과 끝을 이해하고, 프로젝트의 진행 프로세스 를 파악하고 있어야 한다. 개발자들과의 원활한 의사소통과 의견 교환 시점을 잘 알고, 그에 대한 디자인 컨셉의 변화 및 표현이라는 것을 인지하고 있어야 한다.
즉, 기획력을 갖추고 기획된 것을 표현할 줄 알아야 한다.

웹 디자이너는 웹을 이해해야한다

1. 전문적인 정보 검색 능력과 분석 능력

기획자는 앞서 다양한 WEB관련 작업을 수행한다고 언급한 바 있다. 그 다양 한 작업을 진행하는데 있어 가장 중요한 것이 바로 근거 자료라고 할 수가 있을 것이다. 특히 그런 자료가 경영이나 마케팅에 관련된 자료라면 더 그러 할 것이다. 그런 자료들은 꼭 필요할 때 없게 되는 경우가 많다. 그러한 때를 대비해서 정보를 검색하는 능력은 정말 중요한 능력으로 평가 받을 것이다.

실제로, 정보를 검색하는 것은 검색 사이트를 잘 다룬다는 것을 말하는 것은 아니다. 필자의 경험으로 보았을때는 관련 정보에 대한 더듬이를 항상 켜놓고 있는 것이 제일 좋은 방법이리라 생각된다. 할 일 없이 사이트를 보다가도 관 심있는 배너를 보았다던가 흥미있는 URL을 발견했다면 주저말고, 해당 사이 트로 접속하라. 그리고, 찬찬히 살펴보고 필요한 자료가 된다면 북마크를 해 두자. 효율적인 북마크는 자료가 없어 쩔쩔매는 당신에게 좋은 자료가 되어줄 것이다.
그러한 정보 검색 능력과 함께 요구되어지는 사항이 분석능력이다. 어떤 정보 를 자신의 것으로 만들기 위해서는 해당 자료를 꼼꼼히 살펴보고 분석 할 수 있는 능력이 필수적일 것이다. 이미 우리는 제도권 교육내에서 분석이란 틀에 익숙해 질대로 익숙해져 있는지도 모른다. 초등학교때부터 해온 감상문 이나 리포트라는 것들이 일종의 분석 연습이라면 이해가 갈까? 필자나 여러분이 분석하는 출발점은 바로 여기에서부터 출발하여야 하리라.
단, 분석이 합리에 기초해야 할 것은 당연한 일이다. 어느 정도 개인의 합리에 기초한 분석이라면 그 분석을 통한 자신의 의견이 도출될 것이고, 그러한 의 견들을 적극적으로 자신의 의견으로 만들어 나가야 한다. 예를 들어 어떠한 문제가 상대방과의 의견 충돌을 일으킨다고 했을 때, 상대방의 의견을 경청하 는 것도 물론 중요하지만, 합리적인 자신의 의견을 내어놓는 것도 중요하다.
웹 기획이란 업무가 앞서도 잠시 언급하였듯이 컴퓨터와 씨름하는 것이 아니 라 사람과 Communication 하는 것이기 때문에 현상을 보고 분석하여 자신 의 것으로 만드는 작업은 정말 필수적인 것이다.
사이트를 분석하던, WEB에서 느낀 현상들을 분석하던, 분석을 했다면 자신 만의 의견을 도출하라. 신세대처럼(?) 좋다 나쁘다 는 식의 감정적 분석이 아니고, 어떠 어떠해서 어떻다라는 합리적인 분석을..

2. 관련 분야에 대한 지속적인 관심

어느 개발자가 예전에 이런 이야기를 했다. 컴퓨터 업계가 엄청나게 빠르게 변하기 때문에 수시로 세미나나 관련 글들을 읽어본다고... 그 개발자는 우리 들 사이에 "바른생활 사나이"로 불리운다. 난 그런 그를 보고 있으면 일종의 장인정신 비슷한 것을 느끼곤 한다. 적어도, 이 바닥(컴퓨터 업계)에서는 관 련정보를 얼마나 빨리 취득하느냐 무척이나 중요한 관건으로 인식된다. WEB 기획을 하던, WEB 디자인을 하건 간에 관련 정보는 이 바닥에서 생존해 나가 는데 있어 필수적인 요건으로 인식하여야 한다. WEB 기획을 공부하는 사람 이라면 신문이나 어느 사이트에서 필요한, 혹은 필요할 정보라면 주저말고 체 크하고 한번이라도 읽어보아야 한다. 또, 관련 업계의 흐름에도 민감한 감각 을 지녀야 한다. 이러한 것은 컴퓨터 분야라는 특수성에 기인하는 것이다. 구 태여, 유명한 무어의 법칙을 따르지 않아도, 컴퓨터 업계는 제반 기술들의 발 전정도에 따라 정말 하루가 다르게 변하고, 그 영역을 넓혀나가고 있다. 그런 곳에서 살아남으려면 꾸준히 보고 듣고, 배워야 하는 마음가짐이 필요하다. 말이 쉽지 평생 그렇게 살수 있을까? 필자도 그럴 수 있을지는 모르겠다.

3. 문화에 대한 고민과 관심

인터넷이란 가상공간에 대한 문화적인 관심이 높다. 90년대 들어 일반 미디어 가 주도하는 여론이란 것을 일정정도 인터넷이 대신하고 있다는 생각이 든다.
그런 여론의 일정부분을 담보하는 인터넷이란 가상공간을 만들고, 기획하는 사람의 입장에서는 사회일각에서 벌어지는 문화적 현상에 대한 나름대로의 뚜렷한 관점이 있어야 한다. 이것은 웹 사이트를 만들고 하는 좁은 의미의 웹 기획과는 아무런 상관이 없다. 그러나, 일을 하는데 있어 생기는 변화무쌍 한 문제들에 대해서 가장 근본적인 해결점을 제시해줄 것이다. 예를 들어 사 회적으로 문제가 될만한 사이트를 의뢰하였을 경우 웹 기획자는 어떤 관점에 서 그 일을 바라 볼 것인가? 자신의 일이기 때문에 그냥 열심히 만들어주면 되는 것일까? 그 문제에 대한 대답은 여러분 자신이 내려야 할 것이다. 필자 도 아직 그런 일이 생기지는 않았지만, 그건 아무도 모르는 일인 것이다.

비단, 사회적인 역할에 대한 부분만을 강조하지 않아도, 문화에 대한 고민과 관심은 필요하다. 앞서 넓은 의미의 WEB 기획 부분을 언급할 때 잠시 말하였 지만, 사이트를 기획한다는 의미는 단순하게 온라인 공간에 일정부분을 차지 한다는 의미는 아니다. 적어도 사업적인 판단력과 기술적인 가능성을 두루 고려해야하는 부분일 것이다. 특히, 사업적인 판단력에 있어 중요한 역할들이 사회문화에 대한 관심이 될 것이기 때문이다. 필자의 경우에는 학교 다닐 때 부터 문화현상에 대해서 관심이 많아서 한때는 문화운동(?)을 할까 하는 생각 도 했었고, 대학교 2학년 때는 문화비평가가 되려고 한 적도 있었다. 그래서, 그런지 WEB에서 일어나는 일련의 현상들을 제법 자주 분석하려 한다. 대부 분의 WEB에서 일어나는 문화적인 현상들도 기존의 사회현상과 크게 다르지 않다. 단지, 기존에는 잘 들리지 않던 소수의 목소리가 더 잘 들릴 수 있다는 것이다. 그렇기 때문에 우리가 알고있는 또다른 사실들과 함께 세상을 바라보 는 눈 또한 넓어지는 것이다.

클라이언트와의 조화

1. 클라이언트에게는 열린귀로! 자신에게는 열린 눈으로 작업에 임한다.
고집센 디자이너. 클라이언트를 무작정 설득하려는 디자이너, 자신 이외의 사람들의 안목을 용납하지 않는 디자이너. 이런디자이너들은 진정한 디자이 너가 될 수 없다. 손톱만한 개미들에게도 배울 것이 있듯이, 모든 사람에게서 도 배울 것은 많다.
항상 모든 것을 수용하는 자세로 작업에 임해보자. 클라이언트가 너무 무리한 요구를 할 경우 무작정 인상먼저 찌푸리지 말고 그들이 왜 그렇게 요구하는지 를 먼저 생각 해 보는 것이 중요하다. 뜻밖에 그곳에 더좋은 정답이 있을지도 모를 테니 말이다.
우선 그들이 요구하는 것들을 하나도 빠짐없이 들어주고, 그 중에서 가능한 작업들은 진행하고, 불가능한 작업들은 왜 그래야만 하는지를 친절히 설명 해주자. 무작정 안된다고 하면 그들도 지치고 흥미를 잃어가게 되며, 그러한 사이트는 제대로 표현되어 보여질 수 없을 것이다. 현업에서 부딪히는 그들은 분명히 그들의 사이트에 대 한 목적과 기능을 그 누구보다도 잘 알고 있을 것이다.

2. 약속한 날짜는 꼭 지키자.클라이언트는 언제나 디자이너를 쪼아댄다.
그들에게 약점 잡히지 않는 가장 중요한 방법. 바로 약속을 지키는 것이다. 작업이 하루 또 하루 늦어지게 되면 디자이너의 권한은 갈수록 떨어져 갈 것이다.

고객과의 약속은 나 자신과의 약속보다 귀중하다고 생각하자. 그들의 요구한 것들을 완벽히 소화 해 낼 수 있을때에, 디자이너 또한 자신의 권리와 의견을 정당하게 표현할 수 있는 것이다.

3. 항상 한발 앞서가라.
웹디자이너는 전문가이다. 항상 그들보다 많이 알아야 하고 항상 먼저 제안하고, 먼저 알고 있어야 한다.
그들이 멋지다고 추천하는 사이트는 이미 몇 개월 전에 보고 마음에 새겨 버린 상태여야한다.그들을 설득하기 위해서는 내가 더 많이 알아야 한다. 더 많이 알기 위해서는 항상 준비해야 한다. 그들보다 먼저…

4. 고쳐야 겠다고 생각하는 부분은 그들이 지적하기 전에 먼저 처리하라.
작업을 하다가 잘못된 부분이나 고쳐야 할 부분들이 눈에 들어올 때가 있다. 이때 "에잇… 고객이 찾아내면 그때 못이기는 척 처리 해 주자!"라고 나중에 미루지 말고 그때그때 처리 해 두자. 자신이 찜찜한 부분은 항상 결국에는 고 치게 된다.
5. 질문을 많이 하자.
클라이언트와 회의를 진행할 때나 업무내용을 전달 받을 때 관련된 이야기는 물론 질문도 많이 하는 것이 좋다. 질문이 많다는 것은 그만큼 일에 관심이 많고, 욕심 또한 많다는 뜻이다. 클라이언트에게 자신의 일에 대한 열정을 보 여주고 싶다면 질문을 많이 해 보자. 질문에 대답하기 싫어하는 클라이언트는 없을 것이며, 그들 또한 당신에게 상당히 호의적이 될 것이다.
6. 항상 모든 것이 가능하다는 전제하에 진행하라.
그들에 어떠한 구현방법에 대해 문의 해 올 때에 안되다고 하기본다는 우선 된다는 전제 하에 노결부터 해 보려는 태도가 중요하다. 항상 넘치는 의욕과 발전하는 자세는 클라이언트들 에게는 크나큰 안심의 대상이 될 것이다.

7. 모든 근거자료는 보관 해 두자.
프로젝트는 짧게는 한달에서 길게는 3~4달까지 연속될 것이다. 이 때 고객 측에서 의뢰한 자료들을 (메일형테이든, 디스켓이든, 팩스상태이 든)꾸준히 모아두어야 한다. 나중에 어떤 일이 생길지 모르므로 이런 자료들 은 꼼꼼히 챙겨두는 것도 매우 중요하다. 또한 초기에 결정되었던 사 항들이 나중에 터무니없이 바뀔 수도 있으니 그 때 우리측의 주장을 확실히 하기 위 해서라도 그런 자료들은 반드시 필요하다.

8. 내용이 새로이 바뀌게 되어도 기존의 자료를 백업 해 두는 것이 좋다.
프로젝트를 수행 할 동안 참으로 상상치 못했던 일이 자주 있다. 기존의 내용 을 수정해서 올렸는데, 또다시 기존의 내용으로 복귀시켜놓아야 한다든지… .하여튼 참으로 디자이너들의 속을 태우는 일들이 수없이 발생하곤 한다. 이 때 항상 자료를 백업해 둔다면 작업은 훨씬 수월 해 질 것이다.
9. 항상 웃는 얼굴로, 할상 즐겁게 대하자.
디자이너도 일종의 서비스업이다.
고객을 만족시키는 것이 목적이기도 하기 때문이다. 웃는 얼굴에 침은 못뱉는 법! 자기 주장을 펼 때나, 잘못된 부분을 따질 떄 되도록 웃는 얼굴로 이야기 를 나누어 보라. 서로 얼굴 붉혀가며 나누어야 하는 짜증나는 이야기도 뜻밖 에 쉽게 해결 딜 수도 있는 일이다.
10. 웹디자이너와 클라이언트는 상호 협조관계
언뜻 이들의 관계를 보면 항상 싸우고 항상 의견충돌을 일으키는 관계로 보일 수도 있으나, 어찌보면 서로에게 크나큰 도움이 될 수 있는 관계이기도 하다.
서로의 입장을 이해하고, 서로 협조한다면 그 프로젝트는 그야말로 성공적으 로 끝낼 수 있을 것이다. 모든 일에서 가장 중요한 것은 사람과 사람들의 관계 이기 때문이다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

라이틀리 Writely
미국 업스타틀의 웹기반 워드프로세서 서비스
www.writely.com

짐브라 ZImbra
웹기반의 협업툴로 마이크로 소프트 아웃룩과 유사한
인터페이스를 가진 메일서비스
http://www.zimbra.com/

---------------------------------------------------------------
현재 스프링노트의 정체도 짐브라와 라이틀리의 기능이 결합된
사이트가 아닐까 생각해본다.

하지만 곧 나올...이 아랫놈에 비하면..
헐 웃음이 나온다..

이 아랫놈은 구글의 캘린더이상의 것으로 보이는데...이름도 life+pod란다..
ipod의 결정판인가..
더 중요한건 이 개발자분이 맥의 오픈디자인을 이용한...사이트를 만들었다는거
어제 오전에 그냥 모니터만 보고있었다.,--;

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

팝업창이나 alert창을 띄우면 확인 버튼이나 창 닫기 버튼을 눌러야하는 번거로움도 있고 그래서 조금 색다른 느낌의 팝업을 만들어봤습니다. allblog.net이나 여러 곳에서 사용하고 있는 방법의 레이어팝업입니다.
레이어팝업 데모보기

주석의 내용대로 div 세개와 객체 생성 스크립트를 적당한 곳에 둡니다.
그리고 푸터 파일쯤? 암튼 적당한 곳에서 이 객체를 생성합니다.
압축해서 올린 파일에는 var win = new new_popup(); 으로 win이란 객체를 만들었구요

사용하실 함수들은
win.dialog_open('팝업 중앙에 보여질 php or html or etc 파일','<-- 이 파일의 폭', '높이(빈칸으로 두면 170px 디폴드), '팝업 띄우고 포커스를 준다든가 하는 스크립트(빈칸이면 스크립트 실행 안함)');
win.dialog_close(); 창 닫기
win.in_alert('알림 메세지'); 화면 좌측 상단에 2초간 보여질 내용입니다.
닉네임을 빼먹었으니 입력하라던가 하는 상황에 써먹으면 좋겠다 싶어서 만들었구요
이 세 함수가 다입니다.
open에서 보내진 파일을 Ajax에서 출력물을 받아다가 가운데 창 레이어의 innerHTML로 넣어주도록 동작하고 있습니다.

그런데 innerHTML에 스크립트를 넣는 경우 실행이 안되는것 같네요
그래서 저는 인클루드 되는 js파일에 레이어 안에서 필요한 함수들을 모아놓고 사용하고 있습니다.
레이어 내부에 포커스를 준다든가 하는 간단한 스크립트는 네번째 인자에 주면 동작하게 했구요

출처: phpschool.com

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

필자가 플래시로 제작하는 리치 인터넷 애플리케이션에 관심을 가지게 된 가장 큰 이유 중 하나는 2001년 미국의 포레스터에서 제안했던 차세대 인터넷인 ‘X인터넷’ 때문이었다. X인터넷 개념 중 eXecutable(실행가능한) 인터넷에 대한 개념을 바탕으로 만들었다고 해도 과언이 아닐 정도로 플래시가 제공하는 리치 인터넷 애플리케이션 개발 환경은 X인터넷 애플리케이션의 개발 환경과 비슷하다는 느낌을 받았다.

하지만 원래 디자인 저작도구로 출발한 플래시의 개발 환경에 개발자들이 적응하지 못해 리치 인터넷 애플리케이션 보급은 기대했던 만큼 활발하지는 못했다. 매크로미디어에서는 이런 상황에 대한 해결책으로 2003년 ‘로얄(Royale)’이라는 코드명의 새로운 프로젝트를 진행하게 된다. 그 목적은 개발자들에게 맞는 리치 인터넷 애플리케이션 개발 환경의 제공으로 그 결과는 ‘플렉스(Flex)’라는 서버 제품으로 우리 앞에 나타났다.

플렉스는 웹 애플리케이션 개발자들이나 기존의 플래시 개발자들에게도 매우 생소한 개념이다. 그러므로 여기서는 독자들이 플렉스와 플렉스 애플리케이션에 대한 이해도를 높일 수 있도록 플렉스 애플리케이션 제작 프로세스에 대해 간단히 살펴보고, 예제를 통해 플렉스에 대한 이해도를 높여보도록 하겠다. 또한 마지막 부분에서는 플렉스 애플리케이션을 과연 어떤 분야에 적용할 수 있을까에 대해 생각해 보도록 할 것이다.

플렉스 애플리케이션 제작 프로젝트 플렉스는 기존의 웹 애플리케이션 개발 환경이나 플래시 애플리케이션 개발 환경과는 분명히 다른 개발 환경을 제공한다. 그러므로 플렉스 애플리케이션 제작 프로젝트 역시 별도의 프로세스를 따르게 마련이다. 이번에는 플렉스 연구과제 프로젝트를 수행한 경험을 바탕으로 플렉스 애플리케이션 프로젝트 팀의 구성과 개발 프로세스에 대해 간단히 설명해 보겠다.

프로젝트 팀 구성 플렉스 애플리케이션 제작 프로젝트 팀은 프로젝트 매니저(PM)를 중심으로 디자인팀과 개발팀으로 구성된다. 디자인팀에는 디자이너와 정보 설계자(information architect)가 필요하며, 개발팀에는 클라이언트측 개발자와 서버측 개발자가 필요하다. 물론 프로젝트의 규모에 따라 디자이너와 개발자들의 수가 늘어날 수는 있지만 기본적인 팀 조직 자체가 변할 필요는 없다.

프로젝트 매니저 프로젝트 매니저의 가장 큰 역할은 프로젝트 기간 동안 개발자, 디자이너와 고객 사이의 원활한 커뮤니케이션이 이뤄질 수 있도록 하는 것이다. 또한 프로젝트의 자원 분배와 시간 배정, 비용 산정과 같은 업무도 병행하게 된다. 또한 고객과 실제 프로젝트 수행 팀간의 커뮤니케이션 통로가 되기도 한다. 다른 애플리케이션 개발에서도 마찬가지이지만, 프로젝트 매니저는 프로젝트 기간 내내 투입돼야 하지만 100% 프로젝트에 묶일 필요는 없다. 물론 프로젝트 매니저가 시스템 아키텍처 설계나 정보 설계와 같은 업무를 병행하는 경우가 있을 수도 있다.

팀장 디자인팀과 개발팀의 팀장으로 프로젝트 규모가 커 여러 명의 디자이너와 개발자가 참여하는 경우에 필요하다. 이들은 프로젝트 매니저를 대신해 각각의 팀원들의 업무 분장과 업무 진척도를 체크하고, 팀 생산물의 단위 테스트를 수행하게 된다. 또한 이들은 프로젝트 매니저의 자원 분배와 시간 배정, 비용 산정과 같은 업무를 도와주기도 하며, 실질적인 현상을 파악해 프로젝트 매니저와 프로젝트 중간에 생기는 위험요소를 관리하기도 한다.

디자이너 디자이너는 플렉스 애플리케이션의 전반적인 디자인을 제작한다. 또한 디자인과 관련된 폰트나 색상 선정, 브랜딩  업무 등 일반적인 애플리케이션 제작과 관련된 부분도 수행한다. 한편 플렉스 애플리케이션을 제작할 때 컴포넌트나 컨트롤, 아이콘과 같은 디자인은 플래시를 이용해 SWC 컴포넌트의 스킨을 변경하거나 사용자 정의 컴포넌트를 제작해야 한다. 플래시를 어느 정도 다룰 줄 아는 디자이너들은 간단하게 SWC 컴포넌트의 스킨을 변경할 수 있지만, 복잡한 SWC 컴포넌트의 스킨 변경이나 사용자 정의 컴포넌트의 제작과 같은 경우에는 컴포넌트 개발자와 함께 작업해야 한다. 이런 경우에는 개발자가 작업하기 전에 미리 컴포넌트의 외형을 디자인해 개발자가 개발할 수 있도록 지원해야 하며, 개발 과정 중에 필요한 디자인 요소들을 개발하기도 한다.

정보 설계자 플렉스 애플리케이션 개발을 위한 정보 설계자는 일반적인 웹 애플리케이션 정보 설계 경험보다는 데스크탑 애플리케이션 정보 설계 경험이 있는 사람이 적합하다. 실제로 플렉스 애플리케이션은 하나의 애플리케이션에서 다양한 상호작용과 빈번한 데이터 교환이 일어나기 때문에, 정보 설계의 측면에서는 데스크탑 애플리케이션과 유사하다.

플렉스 정보 설계자는 애플리케이션의 전체적인 레이아웃을 잡고, 스토리보드와 유즈케이스 작성도 하게 된다. 또한 고객과의 커뮤니케이션을 통해 프로젝트 요구사항을 정리해야 한다. 실제로 플렉스 애플리케이션 개발 과정에서 가장 중요한 역할은 바로 정보 설계자이다. 기존의 웹 애플리케이션과는 다른 형태의 애플리케이션을 제작하게 되므로 창의력과 다양한 데스크탑 애플리케이션 사용자 요구 분석의 경험이 있는 사람이 적합하다.

클라이언트 개발자 클라이언트 개발자는 클라이언트 애플리케이션의 코드를 작성하는 개발자이다. 이들은 주로 디자이너나 정보 설계자와 함께 컴포넌트 커스터마이징이나 사용자 정의 컴포넌트를 개발한다. 한편 서버 개발자와는 서버와 데이터를 주고받을 수 있는 API 등을 정의하기도 한다.

플렉스 애플리케이션에서 클라이언트 개발자의 특징적인 업무 중 하나는 사용자의 키보드 입력이나 마우스 클릭과 같은 이벤트를 처리하는 코드를 작성하는 것이다. 실제로 클라이언트 애플리케이션은 사용자와 상호작용이 많기 때문에 정보 설계자와 함께 편리한 사용자 환경을 제공하기 위한 다양한 컨트롤을 제작해야 한다.

클라이언트 개발자들은 대부분 MXML과 액션스크립트를 알고 있어야 하며, XML과 액티브X 컨트롤, 웹 서비스에 경험이 있으면 도움이 된다. 한편 컴포넌트를 제작하기 위해서는 플래시를 이용한 사용자 정의 컴포넌트 제작 경험도 있어야 한다.

서버 개발자 서버측 스크립트 개발 경험이 많은 개발자가 적합하다. 물론 MXML, 액션스크립트에도 익숙해야 하며, 애플리케이션의 데이터 송수신 부분에 경험도 있어야 한다. 이외에도 XML이나 SOAP 웹 서비스도 구축할 수 있어야 하며, 클라이언트 애플리케이션에서 외부와 데이터를 송수신할 수 있는 API들을 제작해 제공해야 한다. 또한 보안이나 플렉스 서버, 데이터베이스 서버 관리와 같은 업무들도 담당한다.

플렉스 애플리케이션 제작 프로세스 플렉스 애플리케이션 제작 프로세스는 다른 애플리케이션 제작 프로세스와 크게 다르지 않다. 일반적인 애플리케이션 제작 프로세스는 준비→분석→설계→개발 및 통합으로 이뤄진다. 다음에 나올 블로그 애플리케이션 제작 과정을 가정해 각각의 범위를 간단하게 설명해 보겠다.

준비 프로젝트란 특정 문제를 해결하는 것이다. 그러므로 문제의 원인을 파악해 그 문제를 해결할 수 있는 방안 제안이 바로 준비 단계에서 중요하게 수행돼야 한다. 또한 문제 해결 과정에서 비용과 기간 등도 검토돼야 하며, 문제를 해결하기 위해 필요한 솔루션들이 검증해야 한다. 기술적이고 비즈니스적인 제한사항들에 대해서도 검토가 이뤄져야 한다. 블로그 애플리케이션 구축 프로젝트에서 해결해야 할 가장 큰 문제점은 HTML 기반의 웹 애플리케이션 형태로 제작된 기존의 블로그가 사용자들에게 불편함을 준다는 점이다. 그 불편한 사항들은 다음과 같이 정리가 가능하다. ◆ 여러 블로그를 주기적으로 검색해야 하는 경우 블로그 별로 URL을 통해 방문해야 한다. ◆ 블로그의 제목 목록이 일목요연하게 보여지지 않는다. ◆ 블로그 내용 조회시 새로운 정보가 나오면 별도로 검색 사이트 창을 띄워 해당 내용을 검색해야 관련 정보를 찾을 수 있다. ◆ 사용자의 요청에 따라 화면이 갱신되므로 일관성있는 사용자 경험을 제공하지 못한다.

이번 프로젝트는 플렉스 애플리케이션의 특징과 제작 방법에 대해 알아보기 위한 프로젝트로 기본적으로 플렉스 서버를 이용해야 한다. 또한 기간과 비용도 최소한으로 설정했다.

분석 분석 단계에서는 프로젝트의 성공을 정의하는 것이 가장 중요하다. 또한 프로젝트의 범위를 선정하기도 하며, 비즈니스적인 측면과 기술적인 측면의 정보들을 모으고 해당 애플리케이션 담당자나 사용자들과 인터뷰를 하기도 한다. 한편 프로젝트 수행에 필요한 범위와 비용, 예산 등도 확정한다. 블로그 애플리케이션 제작 프로젝트의 성공 조건은 다음과 같다. 성공 조건이 도출되면 간단한 레이아웃 시안과 그와 관련된 간단한 스토리보드 초안, 시스템 구성도 등이 포함된 프로젝트 기획서가 나와야 한다. ◆ 블로그 목록과 해당 블로그의 글 제목 목록은 한 화면에서 볼 수 있을 것 ◆ 블로그의 내용을 조회할 때도 블로그의 목록과 글 제목 목록의 상태를 유지시켜 일관성있는 사용자 경험을 제공할 것 ◆ 블로그의 내용을 바탕으로 편리한 검색이 되도록 할 것 설계 설계 단계에서 가장 중요한 것은 개발팀과 디자인팀, 그리고 고객이 프로젝트를 통해 만들어질 결과물의 형태에 대해 같은 이해를 가지도록 하는 것이다. 이 단계에서는 정보 설계가 마무리되어 상세한 스토리보드가 작성돼야 하며, 레이아웃과 디자인 시안이 확정돼야 한다. 한편 개발팀에서는 마무리된 정보 설계를 바탕으로 컴포넌트의 기능 사양에 대해 정리해야 한다. 또한 플렉스 애플리케이션과 외부 서버와의 데이터 송수신 방식에 대한 사항들도 결정해야 한다. 블로그 애플리케이션의 설계 결과물은 다음과 같다. ◆ 레이아웃 시안, 디자인 시안, 스토리보드 ◆ 정보 설계서, 컴포넌트 기능 사양서 ◆ 데이터 송수신 API 목록, ERD 등 설계 단계에서는 개발팀, 디자인팀, 고객이 프로젝트의 결과물에 대한 같은 청사진을 가져야 한다. 또한 컴포넌트 기능 사양서와 정보 설계서의 완성을 위해서는 간단한 샘플을 제작해 보는 것도 효율적인 설계를 위해 필요하다. 특히 플렉스 애플리케이션의 경우 다양한 기능과 형태의 컴포넌트가 애플리케이션에서 사용되고, 컴포넌트간의 상호작용이 많으므로 정보 설계서와 스토리보드를 바탕으로 상세한 컴포넌트 기능 사양서를 제작해야 한다. 만약 개발자들이 컴포넌트의 기능 사양을 잘못 이해하고 본래의 의도에 벗어난 컴포넌트를 제작하는 경우가 발생하면 전체 프로젝트의 수행에 차질이 생길 수 있을 정도로 심각한 상황이 발생할 수 있다.

<화면 1> 플렉스 블로그 애플리케이션

개발 및 통합 실제로 플렉스 애플리케이션을 개발하는 단계이다. 분석 설계 과정에서 만들어질 결과물에 대한 명확한 이해를 바탕으로 팀별로 개발해 나가면 된다. 블로그 애플리케이션의 경우 플렉스의 내장 컴포넌트를 그대로 사용하면서 외부와의 데이터 송수신은 블로그 사이트에서 제공하는 RSS(Rich Site Summary)나 RDF(Resource Description Framework)와 같은 XML 문서 양식을 이용했다.

개발 단계에서는 컴포넌트의 기능들을 구현하고 관련 디자인을 개발한다. 또한 서버와의 데이터 통신을 위한 웹 서비스나 자바 객체를 개발한다. 개발하면서 단위 테스트를 수행해 각각의 기능들을 테스트해 본다. 또한 통합 단계에서는 각각의 컴포넌트를 통합해 전체적인 애플리케이션 유즈케이스에 따라 통합 테스트를 수행한다.

블로그 애플리케이션 예제 개발자들 사이에서는 ‘백견이 불여일타’라는 말이 있다. 소스코드를 백 번 보는 것보다 직접 소스코드를 작성하면서 예제를 만들어 보는 것이 제작 과정을 이해하기 쉽다는 것이다. 플렉스 애플리케이션에 대해 이해하기 위해 직접 플렉스 애플리케이션을 만들어 보는 것은 매우 중요하다.

예제로는 플렉스에서 샘플로 제공하는 블로그 애플리케이션을 이용하기로 했다. 블로그를 예제로 선택한 이유는 블로그의 사용 방법을 알고 있는 사람들이 많다는 점이다. 그러므로 플렉스 블로그 애플리케이션을 만들어 보면 기존의 웹 애플리케이션과 플렉스 애플리케이션의 차이점을 쉽게 확인할 수 있을 것이다. 또한 대부분의 블로그들이 컨텐츠를 RSS나 RDF와 같은 XML 문서로 제공하고 있으므로 별도의 웹 서비스나 자바 객체와 같이 데이터 송수신을 위한 별도의 API를 작성하지 않고도 애플리케이션을 완성할 수 있다는 장점이 있다.

한편 블로그 외에 HTTP를 통해 XML 문서를 제공하는 뉴스 사이트들의 컨텐츠들도 예제에서 보여지도록 하겠다. 구글 검색 웹 서비스를 이용해 블로그 애플리케이션에 검색 기능도 추가해 보겠다. 기존의 블로그 애플리케이션들을 생각해 보자. 하나의 컨텐츠를 읽기 위해 컨텐츠의 제목을 클릭하면, 전체 화면이 서버로부터 HTML의 형태로 전송되어 클라이언트의 웹 브라우저에 렌더링된다. 그러므로 사용자들이 블로그의 컨텐츠를 읽을 때마다 HTML 문서가 전송되어 화면에 보여지게 될 때까지 시간이 걸리게 된다. 하지만 플렉스 애플리케이션의 경우 컨텐츠의 제목을 클릭하면 컨텐츠의 내용이 보여지는 화면만 변경할 수 있으므로 전체 화면의 데이터를 모두 받을 필요가 없으며, 서버로부터 해당 데이터가 전송되면 자동으로 화면을 변경해 주므로 사용자가 대기하는 시간이 줄어들게 된다.

<화면 2> 전형적인 블로그 웹 애플리케이션

컨테이너를 이용한 레이아웃 지금부터 플렉스 블로그 애플리케이션 예제를 제작해 보겠다. 먼저 애플리케이션의 레이아웃부터 시작하겠다. 플렉스 애플리케이션의 레이아웃은 레이아웃 컨테이너를 이용해 구성한다. 이때에는 VBox와 HBox 컨테이너를 사용한다. 다음 MXML 코드를 살펴보자. <?xml version = "1.0" encoding = "utf-8" ?> <mx:Application width="100%" height="100%" xmlns:mx="http://www.macromedia.com/2003/mxml">    <mx:HBox>       <mx:Tree />       <mx:VBox>          <mx:VBox />          <mx:DataGrid />          <mx:TextArea />       </mx:VBox>    </mx:HBox> </mx:Application> 기본적으로 플렉스 MXML 코드는 XML 마크업 언어이다. 맨 윗부분에 XML 문서 선언 부분을 참고하기 바란다. 그 다음 애플리케이션은 <mx:Application> 태그로 선언된다. 이 애플리케이션 내부에 HBox와 VBox 컨텐이너를 추가해 전체적인 레이아웃을 구성했다.

HBox 컨텐이너에는 Tree 컴포넌트와 VBox 컨테이너를 포함하고 있다. HBox 컨텐이너는 내부의 포함하는 요소들을 왼쪽에서 오른쪽으로 정렬해 준다. 그러므로 먼저 왼쪽에 Tree 컴포넌트가 위치하고 오른쪽에 VBox 컨테이너가 위치하게 된다. VBox 컨테이너에는 또 다른 VBox 컨테이너와 DataGrid 컴포넌트, 그 아래에 TextArea 컴포넌트가 포함되어 있다. HBox와 달리 VBox는 내부의 포함하는 요소들을 위에서 아래쪽으로 정렬해 준다. 그러므로 오른쪽 상단에는 VBox가, 중단에는 DataGrid가, 맨 하단에는 TextArea가 위치하게 된다. <화면 3>은 앞의 코드를 실행시킨 모습이다. 내부에 데이터가 없는 상태로 해당 구성 요소들의 모습은 파악할 수 없으나 전체적인 레이아웃의 모습은 파악할 수 있다.

<화면 3> 인터페이스 레이아웃

저장과 배포 플렉스 애플리케이션은 플렉스 서버를 통해 배포된다. 앞에서 작성한 MXML 문서를 플렉스 설치시 생성되는 flex 폴더 안에 blogReader라는 폴더를 만들고 BlogReader.mxml이라는 이름으로 저장한다. 필자의 경우 C:\Program Files\Macromedia\Flex\jrun4\servers\default\flex\BlogReader에 들어 있다.

이렇게 저장된 플렉스 애플리케이션은 웹 브라우저를 통해 배포할 수 있다. 웹 브라우저를 열고 해당 플렉스 애플리케이션의 경로를 입력하면 <화면 3>과 같이 플렉스 애플리케이션이 배포되어 실행되는 것을 확인할 수 있다. 필자의 시스템에서 플렉스 애플리케이션의 경로는 http://localhost:8700/flex/BlogReader/BlogReader.mxml이다. 필자의 경우 윈도우 XP에 별도의 J2EE 애플리케이션 서버를 설치하지 않고, 플렉스를 Integrated Flex Server 옵션으로 설치했다. Integrated Flex Server로 설치하면 J2EE 애플리케이션 서버인 JRun이 통합되어 설치되므로 별도로 애플리케이션 서버를 설치하지 않고도 플렉스 애플리케이션을 배포해 실행시킬 수 있어 플렉스 애플리케이션을 제작하거나 테스트할 때 매우 유용하다.

Tree 컨트롤 추가 먼저 왼쪽의 Tree 컴포넌트에 블로그 목록이 나타나도록 해보겠다. 앞에서 레이아웃을 구성할 때 추가했던 Tree 컴포넌트 부분을 다음과 같이 수정한다. <mx:Tree id="blogTree" width="250" heightFlex="1">    <mx:dataProvider>       {blogList}    </mx:dataProvider> </mx:Tree> 먼저 <mx:Tree> 태그를 살펴보자. Id 속성은 Tree 컴포넌트를 다른 컴포넌트나 액션스크립트에서 참조할 수 있도록 blogTree라고 정했다. width 속성은 Tree 컴포넌트의 넓이를 설정해 주는 속성으로 여기서는 Tree 컴포넌트의 넓이를 250픽셀로 정했다. 특이한 것은 heightFlex 속성인데, 여기서는 heightFlex 속성을 1이라고 설정했기 때문에 웹 브라우저의 윈도우 창의 크기가 변경되면 그에 따라 Tree 컴포넌트의 넓이도 변한다. 또한 <mx:dataProvider> 요소는 Tree 컴포넌트에 표시될 데이터를 변수 이름으로 지시하게 된다. 그러므로 앞의 코드는 blogList 변수에 저장된 데이터가 Tree 컴포넌트 안의 내용으로 보여주라는 의미를 가진다.

데이터 모델과 바인딩 앞의 코드에서 <mx:dataProvider> 요소를 이용해 컴포넌트에 데이터를 맵핑시켜 주는 것이 바로 데이터 바인딩 부분이다. 이제는 ‘blogList’ 변수를 선언하고 해당 데이터를 선언해 주는 것이 필요하다. <mx:Application> 태그의 자식 요소로 <mx:XML id=“blogList” source=“blogList.xml”/>과 같은 <mx:XML> 요소를 추가해 준다. <mx:XML>는 플렉스 애플리케이션의 데이터 모델을 선언할 때 사용하는 태그이다. 이때 선언할 데이터가 XML 형태인 경우에는 <mx:XML> 태그를 사용하고, 단순한 데이터 형인 경우에는 <mx:Model>을 사용한다. 물론 액션스크립트 클래스를 이용해 데이터 모델을 선언할 수도 있다. 앞과 같이 선언함으로써 blogList.xml에 있는 XML 데이터는 blogList 변수로 참조해 Tree 컴포넌트의 내용으로 보여주게 된다. blogList.xml 문서는 다음과 같다.

<리스트 1> blogList.xml

<?xml version="1.0" encoding="euc-kr"?> <node>      <node label="매크로미디어">      <node label="Christophe Coenraets" url="http://www.markme.com/cc/index.rdf"/>      <node label="Christian Cantrell" url="http://www.markme.com/cantrell/index.rdf"/>      <node label="Kevin Lynch" url="http://www.klynch.com/index.rdf"/>      <node label="Mike Chambers" url="http://www.markme.com/mesh/index.rdf"/>      <node label="John Dowdell" url="http://www.markme.com/jd/index.rdf"/>    </node>    <node label="자바 커뮤니티">       <node label="James Gosling" url="http://today.java.net/jag/blog.rss"/>       <node label="TheServerSide" url="http://theserverside.com/rss/theserverside-1.0.rdf"/>    </node>    ...중략 </node>

blogList.xml 문서는 앞에서 제작한 MXML 문서와 같은 폴더에 저장한다. 이제 다시 웹 브라우저를 통해 플렉스 애플리케이션을 실행해 보자. <화면 4>와 같은 결과를 볼 수 있다. 웹 브라우저 창의 크기를 조절하면 Tree 컴포넌트의 높이가 자동으로 웹 브라우저 창 높이에 맞게끔 변하는 것을 확인할 수 있다. 또한 Tree 컴포넌트의 폴더 앞에 있는 화살표를 클릭하면 해당 폴더 안에 저장되어 있는 블로그의 목록들을 확인할 수 있다. HTML 기반의 웹 애플리케이션에 Tree 컴포넌트와 같은 기능을 추가하기 위해서는 상당히 많은 노력과 시간이 필요하게 될 것이다. 하지만 플렉스에서는 컴포넌트의 형식으로 제공하기 때문에 몇 줄의 코드로 Tree 컴포넌트의 다양하고 복잡한 기능을 활용할 수 있다.

<화면 4> 블로그 목록을 보여주는 Tree 컴포넌트

블로그 제목을 보여주기 위한 DataGrid 컨트롤 추가 이제 Tree 컴포넌트의 블로그 이름을 클릭하면 오른쪽의 DataGrid 컴포넌트에 해당 블로그의 글 제목이 나타나도록 해보자. 먼저 <mx:Tree id=“blogTree” width=“250” heightFlex=“1” change=“fetchBlogEntries(event);”>과 같이 Tree 컴포넌트의 태그를 수정해 준다.

진하게 표시된 부분은 Tree 컴포넌트에 변화가 일어나는 이벤트가 발생하면 fetchBlogEntries(event) 함수가 호출되도록 선언한 것이다. 플렉스 애플리케이션에서는 이벤트 처리가 가능하므로 사용자의 특정 행동을 감지해 처리할 수 있다. 여기서는 사용자가 Tree 컴포넌트 안에 있는 블로그 목록을 선택하는 이벤트를 포착해 fetchBlogEntries 함수를 실행시키고 있다.

<mx:Scirpt> 태그를 이용한 액션스크립트 입력 fetchBlogEntries 함수를 선언해 보자. 플렉스 애플리케이션에서 함수를 선언할 때는 대체로 액션스크립트 2.0을 사용한다. MXML 문서 안에서는 <mx:Script> 태그 안에 액션스크립트를 입력하 된다. 다음은 MXML 문서 안에 액션스크립트로 fechBlogEntries 함수를 선언하는 코드이다. 이 코드는 <mx:Application>의 자식 요소로 입력하면 된다. fetchBlogEntries 함수를 살펴보자. 먼저 블로그의 URL 정보를 blogURL 속성에 저장하고, blogViewHelper 클래스의 setSelectedBlog 메쏘드를 실행한다. <mx:Script>    function fetchBlogEntries(event)    {       var blogURL = event.target.selectedItem.attributes.url;       if(blogURL != null)       {          blogViewHelper.setSelectedBlog(blogURL);          feed.send();       }    } </mx:Script> 액션스크립트 클래스 선언과 인스턴스화 blogViewHelper 클래스는 blogViewHelper.as라는 별도의 액션스크립트 파일에 입력하고 BlogReader.mxml를 저장한 폴더에 저장한다. 다음은 blogViewHelper 클래스를 선언하는 액션스크립트 코드이다. class BlogViewHelper {    function setSelectedBlog( blogURL : String )    {       selectedBlog = blogURL;    }    function getSelectedBlog() : String    {       return selectedBlog;    }    public var selectedBlog:String; } BlogViewHelper 클래스에는 selectedBlog 속성이 있으며, 이 속성과 관련된 set/get 메쏘드도 작성했다. 앞의 액션스크립트에서 setSelectedBlog 메쏘드를 호출했는데, 이렇게 setSelectedBlog 메쏘드를 호출해 주면 selectedBlog 속성에 선택한 블로그의 URL 정보가 저장된다. 외부에 작성한 액션스크립트 클래스 파일을 MXML 내부에서 사용하�