XAP 사이즈, 압축하지 않겠는가?에서 얘기한 것 처럼 실버라이트 배포에 가장 중요한 점 중 하나는 바로 용량을 줄이는거죠. 그래서 배경화면이나 복잡한 디자인 등에 사용하는 이미지 파일은 프로젝트에 포함하지 않고 웹 서버쪽에 두는 것이 정석이에요. 그런데 이렇게 하면 개발자들이야 어차피 디자인을 보면서 작업하는 일이 많지 않아서 별로 문제가 안되지만, 디자이너들에겐 치명적인 문제가 되죠. 생각해보세요 배경화면을 보면서 디자인을 해야 하는데 이미지가 프로젝트에 없어서 보이지 않는다니!

요컨대, 다음과 같이 배경 이미지 한장을 보여주는 아주 간단한 샘플을 놓고 보죠.

image image

최초로 Images 폴더에 ducks.jpg를 추가하면 기본적으로 Build Action이 Resource가 되어 프로젝트를 빌드할 때 어셈블리에 리소스로 포함되고 이 이미지의 용량은 고스란히 XAP파일의 용량이 증가하는 결과로 이어지죠. 그렇다고 이미지를 삭제하고 웹서버에만 놓기엔 디자이너가 볼 수가 없어서 애매하죠.

이럴 때는 간단하게 해당 이미지 파일을 프로젝트에 그대로 놓은 상태에서 Build Action만 None으로 설정하세요.

image

이렇게 하면 비주얼 스튜디오의 디자인 뷰에는 나오지 않지만 블렌드로 열어보면…

image

잘 보이죠? 그러면서도 배포 사이즈는 이미지의 크기가 빠지게 되죠.

별거 없지만 첨부된 프로젝트를 보면서 참고하세요.


Posted by gongdo

Submit comment.

  1. Favicon of http://gilverlight.net BlogIcon 길버트 2009.02.19 16:18  comment URL  Edit/Remove  Submit comment.

    정말 우아한 방법이군요. ^^
    유지보수를 위해 저 상태의 XAML을 유지하고, 런타임 시의 에러창 뜨는 것을 방지하기 위해서,
    비어있는 ImageFailed 핸들링 함수를 하나 곁들여 두는 게 좋겠군요.

  2. 프로글래머 2009.02.19 16:29  comment URL  Edit/Remove  Submit comment.

    유용한자료 감사합니다.

트랙백이 없는 네이버 카페ㅠ.ㅜ
http://cafe.naver.com/mssilverlight/1742 글에 대한 답변이에요.
참 'XX에게의 편지' 따위의 제목을 쓰고 싶진 않았는데 더 적당한 말이 떠오르지 않네요;


모든 것에 앞서 얘기드리고 싶은 건, 전 골수 개발자에요. 전혀 디자인 관련 공부를 해본적도 일을 해본적도 없을 뿐더러 디자인 감각조차 꽝이라는(그 점이 제일 가슴아프네요) 거죠. 따라서 제가 싸질러 놓은 모든 글들은 디자이너의 입장에서 전혀 공감되지 않을 수도 심지어 완전히 헛소리일 수도 있음을 감안해 주세요. 만약, 제가 그런 헛소리를 해대고 있다면 어떤 점이 잘못되었는지, 디자이너가 느끼는 진짜 문제는 뭔지에 대해 댓글로 남겨주시면 개발자와 디자이너가 소통하는 데 중요한 키가 될 수 있을 거에요. 주저 없이 의견을 날려 주세요.


이제 많은 사람들이 같은 고민을 하게 될 것 같네요.

먼저 실버라이트와 관련된 디자인에 나름 참고가 될만한 제 글들을 링크해 볼께요.

http://gongdosoft.com/228

http://cafe.naver.com/mssilverlight/1615

http://gongdosoft.com/category/Expression

제 글 외에도 UX에 관한 사항은 마이크로소프트의 UX 이반젤리스트인 리건님이 운영하는 http://uxfactory.net 가 도움이 될 것 같고요.

현재로서는 명쾌한 답 같은건 없다는게 제 결론이에요.

반대로, 개별 상황을 해결할 수 있는 최선의 방법이 있다 라고 얘기할 수도 있겠죠. 돌가님이 제기한 의문에 대한 나름의 답을 생각해봤어요.


1. 과연 디자이너에게 있어서 UX란 무엇인가!

UX는 굉장히 넓은 범위로 얘기될 수 있는 주제지만, 저는 '사람들이 쓰고 싶어하고 또 쉽게 쓸 수 있는 사용자 경험'이라고 요약하고 싶네요.

전통적인 디자인의 목표라면 '쓰고 싶게 하는 것', 바로 디자인의 감성적인 측면으로, 어도비의 많은 툴들은 바로 이런 점에 촛점을 맞춰서 디자인되었고 또 많은 디자이너들이 여기에 익숙해져있죠.

반면, '쉽게 쓸 수 있는 것'은 디자인의 기능적인 측면이라고 볼 수 있는데요, 초기 RIA에서 나타난 문제점 중에 하나는 화려하고 현란하고 멋지긴 한데... 도무지 쓰기가 어렵고 반응성도 좋지 않았다는 점들이죠. 이런 점들은 어떤 툴을 사용하든 사용자 경험에 대한 배려와 노력이 없으면 이룰 수 없을 거에요.

저는 이런 UX에 대한 고민의 답을 게임들의 인터페이스에서 어느 정도 찾을 수 있을 거라고 생각해요. 게임은 UI라곤 단지 사각형과 텍스트밖에 없던 오래전부터 보다 화려하고 현란하고 멋진 그래픽을 표현함과 동시에 사용자들이 보다 쉽게 조작하고 쉽게 사용할 수 있는 인터페이스를 구현하는 엄청난 노하우가 집약된 분야라고 생각해요. 과거에는 이런 게임들의 인터페이스를 웹이나 데스크탑 애플리케이션에서 구현한다는 것은 굉장히 어려운 일이었지만 아시다시피, 현재는 플래시와 같이 강력한 툴의 지원으로 상당 부분 따라갈 수 있게 되었죠.

현재 웹에서의 그래픽 표현(2D)은 거의 한계에 가까워졌다고 생각해요. 툴들이 보다 지능적이고 자동화 되는 발전 과정이 있을 뿐 남은 것은 디자이너 개개인의 창조성에 달려있다는 거죠. 반면, 사용자 경험에 대한 전반적인 논의와 고민은 아직 많은 쟁점을 가지고 있고 보다 더 고민하고 개척해야할 분야라고 생각해요. UX의 관점에서 전자는 기본이요, 후자의 중요성이 점점 더 커질 수 있다는 거죠.


2. 그렇다면 우리나라의 UX는?

이 부분에 대해서는 저도 심각하고 심지어 절망적이기까지 해요. 아시다시피 우리나라의 UX는 모든 것을 한꺼번에 차린 밥상 이라고 표현할 수 있는 다소 난잡한 포털식이잖아요? 이게 사용자가 원해서인지 아니면 초기 포털이 그런식으로 발전해 왔고 사용자들은 단지 적응을 한 것 뿐인지는 잘 모르겠어요. 만약 후자라면 그나마 가능성은 있어보이죠. 요컨대, 수년 전 인터넷 비즈니스는 '야후'때문에 할게 없다 라고 툴툴거려왔고 지금은 '구글'때문에 할게 없다 라고 하죠. 야후는 전통적인 포털 서비스와 같은 UX를 제공해왔고 구글은 단순함에 기반한 UX를 추구하고 있기 때문에 많은 것을 시사하고 있다고 봐요.

그렇지만, 다시 현실로 돌아오면 분명히 말해 현실의 서비스는 정확히는 서비스 제공자들은 구글과 같은 혁신적인 모험을 원치 않을거에요. 처음 계획에는 뭔가 새로운걸 시도하기 위해 이런저런 회의를 하겠지만 시간이 지날 수록 사람들은 당장의 현실에 한계를 짓는 경우가 많죠.

분명히 말해서, 아직까지 국내에서 혁신적인 UX를 말한다는 것은 무리일지 몰라요. 그러나 UX가 반드시 단순하고 깔끔한 디자인 또는 화려하고 멋진 UI만을 얘기하는 것은 아니잖아요? 네이버나 다음과 같이 난잡한 UI속에서도 사용자들이 좀 더 쉽고 편안하게 쓸 수 있는, 그런 것이 바로 UX겠죠.

그렇지만 저는 좀 더 혁신적인 UX를 가진 웹 서비스를 만들어보고 싶고, 제 바램을 구현할 수 있는 직장과 일을 선택하고 싶어요.


3. Microsoft Expression Studio가 어도비의 툴들과 경쟁력이 있는가?

물론 당장은 아니죠. 하지만 시간이 지나면 어떨지 아무도 예측할 수 없겠죠. 심지어 저는 폐쇄적으로 닫혀있는 어도비보다 열려있는 마이크로소프트의 그것이 훨씬 더 큰 발전 가능성을 가지고 있다고 생각해요.

단순히 툴만으로 비교하자면 십수년간 디자이너를 위한 그래픽 툴을 만들어온 어도비가 압도적으로 유용하고 유리하겠죠. 그러나 Expression Studio는 단순히 그래픽 툴로서의 가치만을 가지는게 아니라고 생각해요. Expression Studio는 마이크로소프트의 UX, 그 중에서도 Presentation 분야에 특화된 툴이고 마이크로소프트의 Presentation은 XAML이라는 잘 설계된 방향을 향하고 있죠. 아시다시피 XAML은 완전히 열려있는 플랫폼이기 때문에 설사 마이크로소프트의 Expression Studio가 좋은 툴을 제공할 수 없다고 해도 서드 파티에서 보다 완벽하고 보다 디자이너 친화적인 툴을 만들어낼 수 있을거에요.

예를 들어보죠.

포토샵은 현존하는 가장 유명하고 가장 많이 사용되는 그래픽 툴이고 PSD는 바이너리 포맷으로 닫혀 있는 포맷이죠. 그럼에도 불구하고 페인터와 같은 툴들은 포토샵이 긁어주지 못한 곳을 파고들어 하나의 영역을 구축하는데 성공했어요. 저는 이들이 어도비와 어떤 파트너쉽을 가지고 있는지 모르겠지만, 만약 제가 페인터와 같은 툴을 만든다고 하면 눈앞이 깜깜해 질거에요. PSD와 같은 거대한 바이너리를 맨땅에서 분석해내야 하기 때문이죠.

반면, Expression Studio(정확히는 Blend에 한정되지만 개념상)는 기본적으로 완전히 열려있는 XAML을 기반으로 하고 있고 누구나 마음만 먹으면 그 스펙을 열람하여 훨씬 더 좋은 툴을 개발할 수 있다는 점이 달라요. 벌써 WPF쪽으로는 3D 디자인을 위한 ZAM 3D라는 서드파티 툴이 Blend에 비해 훨씬 더 좋은 기능을 제공해주고 있죠.

어쩌면 이런 생각이 질문과는 거리가 멀지 모르겠어요. '툴'자체의 유용성은 시간이 지나면서 변하기 나름이라고 생각해요.

제 생각에 단기적으로는 혹은 조금 더 많은 시기 동안은 어도비 포토샵과 일러스트레이터의 아성은 견고할거에요. 그러나 웹 디자인, RIA에 있어서 중요한 표현은 단지 그래픽이 아니라 UX라는 점이죠. 단지 툴만으로 경쟁이 되는 것이 아니라 기획자와 디자이너, 그리고 궁극적으로 사용자가 원하는 UX를 보다 생산성 있게 운용할 수 있는 기술, 그것이야 말로 경쟁의 포인트가 된다고 생각해요.

적어도 수 년간(소심스럽긴...^^)은 어느 한쪽이 일방적인 승리를 거둘 수는 없을 거에요. 마이크로소프트의 UX전략은 어느정도 시장에 진입하기 시작했고 그리 쉽게 떨어져 나가지는 않을 거라고 예상해요. 이런 상황에서 물론 가장 좋은 것은 모든 툴을 잘 다룰 수 있는 능력이겠지만 현실적으로 그것이 어렵기 때문에 디자이너에게 다음과 같은 제안을 해볼께요.

먼저 포토샵(취향에 따라 일러스트레이터)은 디자이너로서 가지고 있는 창조성을 보여주기에 무리가 없을 정도로 숙련도를 높일 필요가 있을 거에요. 적어도 수 년간(^^)은 포토샵과 일러스트레이터의 아성은 깰 수 없을 테고, 실제로 현재로서는 가장 좋은 그래픽 퀄리티를 낼 수 있는 툴이니까요.

다음으로 시장의 요구에 따라 -회사의 요구에 따라^^- 실버라이트와 플래시or플렉스의 선택을 강요받게 되겠죠? 이 때는 자신이 선택에 달려 있을 거에요. 플래시/플렉스는 지금 당장은 더 많은 리소스와 커뮤니티 그리고 금쪽같은 노하우를 더 많이 얻을 수 있기 때문에 안전한 선택이 되지만 그만큼 더 많은 경쟁이 기다리고 있겠고, 실버라이트/WPF는 초기 기술에서의 갖은 문제점과 부족한 리소스와 정보 때문에 상당히 시달릴 거에요. 그렇지만 보다 적은 경쟁에서 닷넷 개발자들의 열렬한 환호와 도움을 받으며 새로운 시장을 개척해볼 수 있는 기회를 얻게 되죠. 참고로, 전 디자이너는 아니지만 후자에 걸겠어요^-^


4. 디자이너로서 긍정적인 방향으로 준비할 것은?

먼저 개발(협업) 프로세스의 어려움에 대해 얘기해 보죠. 디자이너와 개발자와의 협업 프로세스에서 가장 어려운 점은 심지어 개발자들조차도 UX를 지향하는 웹 애플리케이션을 어떻게 만들어야 하는지 모른다는 점이 아닐까 싶어요. 누구도 그런 완전한 경험을 해보지 않았기 때문이죠. 잘은 모르겠지만, 실버라이트와 가장 비슷한 개발 모델인 플렉스에서도 훨씬 먼저 나왔지만 지금까지도 그런 협업 프로세스에서의 문제점으로 골치아픈 걸로 알고 있어요. 하물며 프로젝트의 파일 교환이 훨씬 더 어려운 플래시는 더 할테고요.

이런 문제는 서로 많은 공부를 하고 좋은 구조와 방법론을 사용하는 것도 하나의 방법이겠지만, 그보다 더 중요한 것은 디자이너가 표현하고자 하는 바를 좀 더 구체적으로 설명하고 좀 더 세부적으로 나누어서 표현하는 것, 그리고 개발자는 개발 플랫폼에서 디자이너의 오브제들이 어떤식으로 운용되고 디자이너의 니즈를 어떻게 만들 수 있는지에 대해 잘 설명하는 것, 즉 진부하지만 디자이너와 개발자는 더 많은 대화와 소통을 필요로 한다는 거죠.

플래시는 전통적으로 '디자인'으로 간주되는 영역이기 때문에 거의 개발자가 해야할 임무인 스크립팅 까지도 디자이너가 하지 않으면 안되었죠. 디자이너는 그렇게 어려운 싸움(?)을 해왔고 노하우를 습득해왔는데 이제와서 개발자들이 옆에서 궁시렁거리면 당연히 기분 나쁘겠죠? '니들이 뭘 알어 엉?' 이러면서요. 그래서 오히려 더 서로 좋은 협업이 어려워지는 것 같아요.

반면 실버라이트는 태생이 개발자 중심적인 환경이었고 모든 것들이 디자이너에게 다소 생소한 개념으로 다가 올 수 있어요. 그래서 콧대가 높아진 개발자들은 우쭐해져서 디자이너를 가르치려 들거에요. 반대로 '니들이 뭘 알어 엉?'이러면서요^^

자 이런 상황이 되면 뭘 선택하든 결과는 마찬가지일 거에요. 제가 무슨 얘기를 하고 싶은지 아시겠죠? :D

다시 처음 했던 얘기를 반복해 볼께요. 모든 상황에 들어맞는 개발/협업 프로세스 따위는 존재하지 않아요. 모든 프로젝트는 현재 구성원이 처해있는 상황과 능력, 기술, 취향, 성격에 따라 완전히 달라질 수 밖에 없죠. 바로 이 점을 명확하게 이해하고 인정해야 할 거에요. 몇 가지 전형적인 상황에 따른 협업 프로세스 혹은 대처 방안은 http://cafe.naver.com/mssilverlight/1615 2.19 네이버 실버라이트 카페 세미나에서 정리한 적이 있어요.

현실은 늘 이상과는 멀게만 느껴지지만 그래도 이상을 지향하는 것이 훨씬 더 발전적이고 즐거운 일이 될거에요. 그런 의미에서 제가 생각하는 디자이너와 개발자와의 이상적인 협업 모델을 얘기해 볼 께요.

그래픽 디자이너는 전문적이고 아름다운 그래픽 오브제와 레이아웃 그리고 전체적인 주제를 결정하고 만들어 내는 역할을 할 거에요. 아마도 이 그래픽 디자이너는 익숙한 포토샵과 일러스트레이터를 사용하거나 혹은 조금 더 개방적이라면 Expression Design과 Blend를 함께 사용할 수도 있겠죠. 그래픽 디자이너는 과거와는 달리 모든 디자인을 '통짜'로 만들지 않고 각 오브제들의 상관 관계와 계층 관계를 고려하여 적절하게 그룹화 하고 사전에 협의된 중요한 오브제에 대해 적절한 이름도 붙여주는 것도 잊지 않았을 거에요.

인터랙티브 디자이너는 디자인과 적당한 코드 작성 능력을 갖추고 그래픽 디자이너가 만들어 놓은 오브제들에 생명을 넣는 일을 하게 되죠. 또한 인터랙티브 디자이너는 사용자의 반응에 대해서도 충분한 고민을 하고 보다 역동적이면서도 편리하게 쓸 수 있는 UI를 구성할 거에요. 또 로직 개발자들이 제공하는 데이터를 바인딩 하여 애플리케이션이 더 의미 있는 정보를 보여줄 수 있게 할 거에요.

로직/서버 개발자는 애플리케이션에서 사용될 데이터의 흐름과 가공을 모델링하고 보편적이고 단순화된 방법으로 인터랙티브 디자이너가 필요로 하는 데이터를 전달해주는 역할을 해요.

그리고 이 모든 과정에는 아마도 디자이너/개발자와의 협업에서 싸우는 것보다 훨씬 더 많이 싸우게 될 기획자(내지는 팀장님^^)가 있고 특히 디자이너들은 기획자의 기획의도를 어떻게 잘 표현할 수 있을지 그리고 개발자는 그러한 요구에 필요한 개발과 프로덕션에 필수적인 전반적인 개발 일정을 주도하게 될 거에요.

물론 이 모델에도 구체적인 파일 교환, 수정 사항에 대한 대응 등 많은 문제가 있겠지만 제 생각에는 이 정도로 이상적인 모델을 구축할 수 있다면 다른 기술적인 문제도 함께 해결 할 수 있을 거라고 봐요.


마지막으로, 디자이너와 개발자의 공통점을 찾자면 '창조'가 아닐까 싶어요. 다만 그 창작물에 이르기까지의 관점이 다를 뿐이죠. 더 창조적인 디자이너와 개발자가 되기 위해서는 자신이 만들고 싶은 것들을 어떻게 하면 더 좋게 더 멋지게 그러면서도 현실적인 시간의 범위 안에서 구현해 낼지에 대해 끊임 없이 고민하고 노력하고, 결정적으로 즐기는 것이 필요하다고 생각해요. 답답하고 꽉 막힌 현실에서 뜬 구름 잡는 얘기 같지만, 이런 노력들 하나하나도 바로 현실 속에서 일어난다고 생각하면 한번쯤 해볼 만한 가치가 있을 거에요.

돌가님이 제기한 의문에 자극 받아서 다다다다 타이핑을 했네요. 부디 이런 고민들이 더 많이 모이고 더 나은 현실을 만드는 데 도움이 되길 바래요.

Posted by gongdo

Submit comment.

  1. D_돌가 2008.02.23 06:07  comment URL  Edit/Remove  Submit comment.

    좋은 이야기와 긍정적인 답변에 만족하고 돌아갑니다.

    사실 그림쟁이로 시작하여 나름데로 책도 보고 열시미라 달렸지만, 많이 어렵네요 ^^;

    제가 항상 주위분들에게 말하고는 하죠.. 과학의 발달이 디자이너를 두번 죽인다고..

    처음에 붓을들고 그림만 그리다, MAC/PC를 접하고, 아도베의 툴을 접하고...

    LCD라는 모니터가 나와 컬러의 딜레마를 만들더니.. 이제는 RIA, 플렉스 등등..


    갈길이 멉니다..


    정성스럽게 글을 써주셔서 너무나 감사하고, 수십번 정독하여 하나씩 이해해야 겠습니다.

    감사합니다.

    • Favicon of http://gongdosoft.com BlogIcon 공도 2008.02.23 07:33  comment URL  Modify/Remove

      뜨핫... 수십번 정독해야 할 정도라면 제가 글을 잘못쓴건데요ㅠ.ㅜ
      여기에서 그치지 않고 생각의 타래가 계속되었으면 해요. :)

  2. Favicon of https://emotionbank.tistory.com BlogIcon 감정은행 2008.02.27 15:31 신고  comment URL  Edit/Remove  Submit comment.

    전 예전에 리건님의 강의를 짤막히들은적이 있었는데...디자이너로서..개발자와 커뮤니케이션문제는 어떤식으로 디자이너가 표현한것을 개발자가 잘 구현해주느냐의 샘플들이 많이 나온다면 그 이해도는 쉬워질것이고, 플렉스에 비해서 활용도도 높아질 것 같습니다.
    아직까지 플렉스는 디자이너가 표현하기에는 언어적으로 액션스크립트를 많이 다룬사람이 아니고서는 접근하기가 쉽지 않다는 것이 제 느낌이었습니다.^^

    잘봤습니다.

    • Favicon of http://gongdosoft.com BlogIcon 공도 2008.02.27 21:09  comment URL  Modify/Remove

      그렇군요. 제가 가진 고민 중 하나는 디자이너가 원하는 표현을 어떻게 개발자가 구현할 수 있을지에 대한 것이에요. 따라하기 쉬운 샘플의 필요성은 정말로 중요할 것 같네요. 이제 실버라이트 2만 나오면 달려보죠! ^^

  3. Favicon of http://blog.naver.com/ssongkoon BlogIcon 다롱엄마 2008.03.28 14:15  comment URL  Edit/Remove  Submit comment.

    좋은 글 감사합니다. 감히 퍼가겠습니다.

  4. doomoak 2008.05.30 18:21  comment URL  Edit/Remove  Submit comment.

    재취업 강좌에서 닷넷과정 마지막 프로젝트를 남기고있는 학생입니다.
    예전에 웹디자인일을 하다 c#을 새롭게 시작했는데 '내가 디자인을 하러 여길왔나?'라는
    의문이 들을정도로 수업내내 진행하는 프로젝트마다 디자인 전담을 맡게되었습니다.
    그래도 다행히 결과물들은 나름대로 만족할만큼 나왔지만, 정작 중요한 코딩은 거의
    손을 못대는(일정이 빠듯한 관계로 디자인찍어내기도 힘든...겨우 디버깅이나 수정하는정도..)
    지경이여서 무척이나 회의가 들었었는데, 이 글을 보니 왠지 기분이 부쩍 놓이는군요! ^^

    • Favicon of http://gongdosoft.com BlogIcon 공도 2008.05.30 22:03  comment URL  Modify/Remove

      후후... 전직 디자이너가 디자인의 꿈을 잠시 접고 코딩의 세계에서 살아가려면 철저하게 디자인 경력을 숨겨야 하죠. 하이에나 같은 개발자들은 디자인 냄새만 나도 물고 늘어질 테니까요.^^

  5. Favicon of http://zzangmyon.tistory.com BlogIcon 짱묜 2008.07.09 17:21  comment URL  Edit/Remove  Submit comment.

    요즘들어.. 무작정 달려오던것에서 멈추어 다시 생각해 보게 되네요..ㅋ
    예전엔 이해하지 못했던 이야기들이 많이 공감됩니다.
    개발자와 디자이너 서로 이해 하려하지만 하지 못하는 부분도 있는것 같고..
    크크..조만간 이런걸 이야기 할 수 있는 자리가 마련됐으면 좋겠어여 ㅋㅋ

    • Favicon of http://gongdosoft.com BlogIcon 공도 2008.07.10 09:39  comment URL  Modify/Remove

      어제도 얘기했지만, 이 글을 쓸 때의 시점보다 오히려 지금이 더 디자이너에게 접근하기 어려워진 것 같아요.
      기술적으로 알아야 할 것도 훨씬 많아져서 어디서부터 뭘 어떻게 설명해야 할지 잘 감이 안잡히네요.

  6. Favicon of http://http://blog.naver.com/elelss BlogIcon nuney 2009.03.07 11:00  comment URL  Edit/Remove  Submit comment.

    참많은 생각을 하게되었습니다.
    아직은 디자이너라고 말하기 힘들정도로 실력은 좋지않지만 그래도 항상 머릿속에
    그려지는 그런것들이 있습니다.이건저렇게저건저렇게..뭐 그런거요
    근데 그게 잘 않될때가 많더라구요..디자이너와 개발자와의 이해...흠...참 어렵더군요
    어떤예가 있으면 좋은데 커뮤니케이션의 문제라기 보단 생각...뭐 그런거?
    개발자와 디자이너가 공존하는 뭐 그런 이상적인?ㅋㅋㅋ 한사람이 두개다?음헤헤
    감사합니다. 어쨌든 토요일 오전 잠시 들린곳에서 많은것을 생각하게 되네요..^^

딜레마의 시작
실버라이트는 풍부한 사용자 경험을 제공하는 RIA를 위해 등장하였고, 특히 닷넷 프레임워크의 경험에 기반한 개발환경은 분명 닷넷 개발자들에게는 대단히 매력적인 것이었죠. 저 또한 실버라이트가 C#으로 개발 될 수 있다는 점 특히, 클라이언트 프로그래밍이란 점에서 굉장히 큰 매력을 느꼈고 지금까지 오게 되었어요.

실버라이트로 화려하고 풍부하고 멋진 RIA를 만들기 위해서는 어떤게 중요할까요? 한가지 분명한 것은 실버라이트의 개발 기반이 되는 닷넷 프레임워크가 제공하는 강력하고 편리한 개발환경이라던가 XAML로 구성되는 훌륭한 아키텍처상의 장점만이 전부는 아니라는 점이에요. 풍부하고 화려하고 멋진 RIA들은 대체로 비주얼, 사운드 및 사용자와의 인터랙션과 같은 감성적인 면에 집중되어 있고 이런 것들은 애플리케이션 개발의 효율성이나 재사용성과 같은 개발자적인 관점에 비해서 훨씬 더 중요한 것 같아요.

지금까지 제가 경험했던 런칭된-혹은 런칭 예정중인-실버라이트 애플리케이션들을 돌아봤을 때, RIA는 기존의 플래시나 웹 디자인에 대한 풍부한 경험이 있는 디자이너가 만드는 것이 훨씬 더 좋은 퀄리티를 보여준다는 것은 확실해요. 구체적으로, SBS의 NView는 탑레벨 디자인 에이전시에서 디자인되었고, MNet TVDeep은 MNet 자체의 디자이너가 전체적인 룩과 인터랙션을 디자인했어요. MNet의 방송 프로그램들을 보면 확실히 다른 풍부한 비주얼들을 보여주죠. 또 지금 개발중인 마이크로소프트의 모 사이트는 전문 탑레벨 디자인 에이전시에서 심지어 인터랙션 코드 개발까지 전담하고 있죠. 그런데, 이들 디자이너, 플래셔들은 대체로 C#이나 닷넷 프레임워크에 관심이 없거나, 익숙치 않거나 혹은 아예 필요치 않았어요. 바로 여기에서 실버라이트의 딜레마가 시작되는거죠.

애증의 JavaScript
자바스크립트를 전문적으로 그리고 심층적으로 다루는 분들은 자바스크립트가 흔히 웹 개발에서 떠올리는 alert따위로 끝나는게 아닌 매우 개방적이고 자유도가 높은 언어라는 것에 찬성할 거에요. 그러나, 자바스크립트의 개방성과 자유도는 오히려 복잡한 애플리케이션의 개발에는 적합하지 않다고 생각해요. 자바스크립트는 인터프리팅 방식의 언어이고 이런 언어는 말 그대로 누구나 쉽게 사용할 수 있는 스크립팅에 알맞지 정교한 사용자 컨트롤이나 혹은 복잡한 데이터 처리 및 연산에는 불리하다는 거죠. 물론 자바스크립트의 고수들은 저의 이런 주장에 명확한 이유로 반대를 할 수 있을 거에요. 하지만, 개발자에게 있어서 단지 변수명을 잘못 썼다고 해서 런타임이 되어서야 문제점을 발견할 수 있는 언어는 결코 생산적이지 못하다고 단언할 수 있어요.

어쨌든, 기존의 RIA 시장은 아시다시피 플래시가 독식해왔고 플래시는 웹에서 벡터 그래픽과 애니메이션을 구현하기 위한 일종의 '그래픽 툴'로 시작했죠. 그러다가 플래시에 하나둘씩 사용자의 인터랙션에 반응할 수 있는 기능들이 추가되고 사용자들은 점점 더 많은 기능과 인터랙션을 요구했고 급기야 액션 스크립트라는 자바스크립트-정확히는 ECMAScript-를 기반으로 한 언어까지 만들어지게 되었죠. 이게 무려 10년도 넘게 이어진 이야기에요. 제 기억엔 2000~2001년 무렵이었던 걸로 생각되는데요, 액션 스크립트가 등장하면서 디자이너가 해야 할지 개발자가 해야 할지에 대한 혼란이 대단히 컸었죠. 마치 지금의 실버라이트 처럼 말이에요!

중요한 점은 단순한 그래픽 디자인에서 보다 복잡한 인터랙션을 포함하는 플래시 애플리케이션을 만들기 위해 '플래셔'는 좀 더 세분화 되었고 특히 액션 스크립트를 전문적으로 다루는 디자이너 혹은 개발자가 나왔죠. 이들이 지금의 플래시와 스크립트에 적응하고 익숙해지는데 얼마나 오래 걸렸을까요? 과연 이들이 지금까지 힘들게 익혀왔던 기반인 자바스크립트를 쉽게 버릴 수 있을까요?

간단하죠. 아니에요.

저는 실버라이트가 C#을 사용할 수 있다는 점이 실버라이트의 가장 큰 매력중 하나라고 생각했지만 아이러니컬하게도 실버라이트 덕분에 자바스크립트를  더욱 더 깊게 다룰 수 있게 되었죠. 왜냐구요? 현재 실버라이트 닷넷 버전(1.1 alpha)은 오직 개발 테스트 및 평가를 위해서만 제공되고 애플리케이션으로 배포할 수 있는 것은 오직 자바스크립트만을 지원하는 1.0 버전이기 때문이죠.

한편으로는 디자이너 내지는 플래셔들에게 있어서 C#보다는 자바스크립트가 일단 눈에 더 익숙하고 거부감이 덜했을 거에요. 아마도 실버라이트 1.0은 '어디 한번 해볼까?' 정도로 다가올 수 있었을 것이고 심지어 비주얼 스튜디오 없이 익숙한 에디트 플러스(!!!)로도 척척 만들어 낼 수 있었죠. 비주얼 스튜디오 중독자인 저로선 정말이지 경이로운 능력이었어요. (어떻게 디버그 모드도 없는 에디터 따위로 애플리케이션을 만든단 말인가!)

기존의 협업 경험으로 봤을 때 디자인적인 감성이 우선되는 애플리케이션은 그래픽 오브젝트는 제외하더라도 애니메이션과 인터랙션을 제어하는 코드는 디자이너(플래시의 액션 스크립터)가 담당하는 것이 디자인 포인트를 저해하지 않는 일반적인 방식이라고 생각돼요. 그리고, 지금 당장 화려하고 동적인 RIA를 만들어 낼 수 있는건 실버라이트로 RIA를 시작한 개발자들 보다는 보다 풍부한 경험과 감성을 가지고 있는 디자이너들이라고 말 할 수 있을 거에요. 이 디자이너들에게 당장 C#을 시작하라는 것은 단지 강요가 될 뿐일 수도 있을 것 같다는 생각이 들어요. 그런 의미에서 실버라이트가 개발 언어로서는 골치아플 뿐인 자바스크립트를 지원하는 것은 올바른 선택이었다고 생각하지만 자바스크립트는 실버라이트에게 있어서 하나의 딜레마가 되죠.

Designers! Designers! Designers!
사용자의 입장에서, 애플리케이션이 어떤 기술로 만들어졌느냐는 떠다니는 먼지 한 개 만큼도 중요하지 않죠. RIA에서 가장 중요한 것은 결국 사용자에게 어떻게 보여지고 어떻게 느껴지는가가 아닐까요? 때로는 그것을 위해 깊은 기술적인 배경이 있을 수도 있지만 그런 것들은 다른 영역으로 분리될 수 있고 많은 경우 RIA는 결국 데이터와 그것을 보여줄 비주얼로 압축될 수 있을거에요.

현재 실버라이트의 비주얼은 주로 미디어 경험과 관련된 사항이 많고 그외의 부분은 사실상 딱히 대단해 보이는게 없어요. Tafiti의 Tree View는 글쎄요, 저에겐 기술적으로도 감성적으로도 잘 와닿지 않는 서비스였어요. 물론 Logi-craft의 사례처럼 비즈니스적으로 또한 개발자의 관점에서 멋진 사례도 있지만 비주얼적으로 한정해보자면 말이에요.

RIA가 사용자에게 주는 인상은 비주얼적인, 감성적인 측면이 가장 크고 이것을 표현하는 디자이너가 무엇보다 중요한 것 같아요. 그렇다면, 실버라이트는 과연 디자이너에게 어떤 비전을 보여주고 있을까요? 어떤 표현의 자유를 보장하고 있을까요? 저는 XAML에서 이 답을 얘기하고 싶지만, XAML을 디자인하는 툴 자체의 미숙함은 이 문제에 확실한 답을 하는 것을 주저하게 만들어요. 디자인 툴의 사용성은 그 기능은 접어두고서라도 반드시 개선되어야 할거에요.

또 실버라이트의 발전 방향은 주로 닷넷 프레임워크에 기반해 있기 때문에 많은 향상과 기능의 추가가 예고되어 있는 2.0의 경우 자바스크립트 지원에 관한 얘기는 아직 들어보지 못했어요. 과연 기존의 디자이너들이 실버라이트의 기능만을 보고 실버라이트를 선택하게 될지는 의문이에요. 가능한 1.0과 같이 자바스크립트를 함께 지원하는 것이 기존 디자이너들에게는 더 좋은 선택이 될 거에요. 물론 이 선택은 위에서 얘기한 딜레마의 원인이 되겠지만요.

딜레마의 해결 방법을 찾아서
한 가지는 협업의 포인트를 찾는 것, 디자이너가 닷넷 프레임워크 언어에 익숙하지 않더라도 닷넷 개발자와 함께 멋진 애플리케이션을 만들어 내는 것이죠. 현실적으로 지금 당장 디자이너가 닷넷 프레임워크를 익히고 C#으로 코드를 짠다는 것은 어려울 거에요. 그렇다면 어떻게 하면 디자이너와의 간극을 줄이면서 디자이너가 표현하고자 하는 바를 잘 나타낼 수 있을지, 어떻게 하면 닷넷을 어렵지 않게 접근할 수 있을 지 또는, 어떻게 하면 디자이너가 사용해야 하는 코드를 최소한으로 줄이면서 표현할 수 있게 할 수 있을지...에 대한 답을 찾아야겠죠. 아직은 답을 찾지 못했지만 할 수 있을 거라고 생각해요.

또 한 가지는 디자이너가 원하는 기능에 귀를 기울이는 것이죠. 대체로 단순한 그래픽의 표현은 Path, 이미지의 조합으로 얼마든지 할 수 있어서 큰 차이가 나지 않지만, 타이포 그라피의 표현력이나 이미지 프로세싱, 애니메이션의 성능 같은 것들은 상당히 중요할 것 같아요. 물론 디자인 툴의 향상도 아주 중요한 문제겠고요.

마지막으로 압도적으로 멋진 기능의 지원이 있겠죠. 지금도 실버라이트가 제공하는 미디어 기능은 상당히 뛰어나고 현재 상용으로 사용되는 실버라이트 애플리케이션의 대부분이 미디어에 집중되어 있는 것을 생각해보면 예를 들어 뛰어난 이미지 프로세싱 기능이 추가된다면 그 분야로도 더 많은 디자이너가 관심을 가질 수 있을 거에요.


쓰다보니 상당히 길어졌네요. 혹시 다른 종류의 고민이나 문제점들 또 해결 방법들에 대해서 피드백을 해주시면 많은 도움이 될거에요 :) 요즘 블로그에 피드백이 적네요. 피드백 좀 주시죠~ 굽실굽실.

Posted by gongdo

Submit comment.

  1. Favicon of http://blog.naver.com/ivoryguard.do BlogIcon ivoryguard 2008.02.08 07:27  comment URL  Edit/Remove  Submit comment.

    매번 공감가는 글을 올려주셔서 감사합니다.

    사실 실버라이트는 기존의 .NET과는 달리 개발자뿐만 아니라 디자이너까지 고려해야하는 아주 복잡한 개발 환경이죠. 사실 실버라이트에서 가장 큰 문제는 디자이너가 아닌가 싶네요.

    사실 전 기업용 솔루션을 개발하고 있는데 회사 내부에 자체 디자이너가 없이 필요할 때마다 외부 인력을 사용하고 있습니다. 일반 웹사이트나 플래시 광고와 같은 부분은 외부에서 디자이너를 쉽게 구할 수 있기 때문에 작업하기가 쉬운 반면, 실버라이트쪽을 다룰 수 있는 디자이너는 국내에 거의 전무하다보니 현재 작업하고 있는 실버라이트 어플은 제가 UI설계, 디자인부터 구현까지 전부 다 하고 있는 실정이랍니다^^;

    그래도 SBS나 MNET은 업체 규모가 좀 있다보니 전문 디자인 인력을 동원하여 XAML로 디자인할 수 있겠지만 중소규모 레벨에서는 아마 저같이 개발자가 직접 디자인하거나 또는 Adobe 툴로 디자인한 결과물을 개발자가 MS 툴로 컨버전하는 경우가 많을 것으로 봅니다.

    결국 실버라이트 쪽에서는 자체 디자인 인력을 가지고 있는 업체가 아닌 이상 개발자의 업무 부담이 더 커지는 방향으로 가게 되지 않을까 싶네요.

    • Favicon of http://gongdosoft.com BlogIcon 공도 2008.02.08 12:02  comment URL  Modify/Remove

      닷넷 기업들은 대체로 마이크로소프트와 닮은 꼴이라 디자인으로 시작한 업체가 아니라 전문 개발 업체라서 제대로된 디자이너 인력 풀이 없다는 문제도 있는 것 같네요.

      제 생각엔 해결 방법이라고 제시한 것 중 가장 효과적인것은 역시 압도적인, 누구도 못하는 기능의 추가와 적절한 지원일 것 같아요.

      현재 실버라이트의 미디어 경험도 웹 WMV 플레이어로서 실버라이트 외의 대안이 없었기 때문에 다른 것들보다 쉽게 받아들여졌다고 생각하거든요.

  2. Favicon of http://blog.naver.com/hanyutong BlogIcon 한어통 2008.02.08 23:58  comment URL  Edit/Remove  Submit comment.

    공도님의 말씀대로 현재 실버라이트를 사용하는 디자이너가 굉장히 적다는게 문제죠.
    사이트의 디자인은 실버라이트가 혼자서 하는게 아니라 결국은 디자이너가 해야하는데...
    당장 실버라이트로 사이트를 만들려고 한다면 디자인부분을 어떻게 해결 할 수 있을까요?

    • Favicon of http://gongdosoft.com BlogIcon 공도 2008.02.10 19:34  comment URL  Modify/Remove

      아오 댓글을 달았는데 없어졌네요;
      저도 아직까지 만족스런 답을 찾지는 못했지만 그간 경험을 바탕으로 협업에 관한 내용을 정리한게 http://cafe.naver.com/mssilverlight/1615 여기에 있어요.
      한번 확인해 보시길...

  3. Favicon of http://beyondf.com BlogIcon beyond 2008.02.12 15:09  comment URL  Edit/Remove  Submit comment.

    글을 늦게 봤네요 ^^;
    예전에... 플래시커뮤니티에서 있었던 일인데
    누군가 플래시 프로젝트의 제작단가에 대해서 언급했던 일이 있는데 그것이 엉뚱하게 얘기가 흘러서
    플래시를 잘 만들수 있는 능력이 최고의 덕목이고 그것만이 단가를 최소한 유지할 수 있다라는 얘기를 하더군요.
    거기에 그건 아니다 제일 중요한 것은 크리에이티브다 라는 덧글을 달았다가 매장 당하는지 알았습니다.
    만드는 능력이 없는데 무슨 크리에이티브냐면서...
    저는 아직도 마찬가지 생각입니다. 툴을 다루는 능력, 코드를 짤 수 있는 능력 결국 만들 수 있는 능력은 크리에이티브를 따라 온다고 생각합니다.(그렇다고 제가 크리에이티브한 것은 아니고요ㅋ)
    플래시건 플렉스건 실버라이트건... AS1.0 ,2.0, 3.0, 자바스크립트, C#... 별로 중요하다고 생각하지 않습니다. 무엇을 만드냐가 중요하죠. 실제로 저랑 코웍하고 있는 천재스러운 인터렉티브 디자이너가 있는데 그는 AS3.0을 AS1.0 처럼 다룹니다. 퍼블리시(플래시컴파일)만 3.0 모드로 하고 작업은 1.0 하듯이 하고 있죠. 그러나 그가 만든 결과물은 놀라울 따름입니다.
    중요한 것은 '실버라이트가 얼마만큼 크리에이티브한 생각을 표현하는데에 있어 걸림돌이 없는 것인가' 일 것입니다.
    디자이너를 배려하는 툴이나 언어도 중요하겠지만, 디자이너가 얼마나 그 툴, 언어에 익숙해 지고 그것을 '수족 부리 듯' 다루는 것은 그 사람이 할 몫이죠. 어떤 디자이너던 필요하면 다 사용하게 되는 것이 툴일 것입니다.

    • Favicon of http://gongdosoft.com BlogIcon 공도 2008.02.12 15:58  comment URL  Modify/Remove

      좋은 말씀 감사드려요 :D
      확실히 아직까지 실버라이트의 표현력에는 몇 가지 걸림 돌이 있고 이것을 어떻게 해결할 것인가 어떻게하면 더 편한 방법으로 쓸 수 있을 것인가를 고민하게 되었어요.

      무리한 부탁일지 모르겠지만 디자이너에게 걸리는 그런 요소는 계속 지적해주세요. 그것을 해결하는 과정도 또 하나의 재미거든요.

      닷넷 개발자에게 있어서 실버라이트는 정말로 매력적인 '표현'능력을 가지고 있고 beyond님처럼 크리에이티브한 능력을 가진 디자이너와 함께 작업할 수 있다면 정말 좋을 것 같으니까요.

    • Favicon of http://blog.naver.com/hanyutong BlogIcon 한어통 2008.02.12 23:30  comment URL  Modify/Remove

      크리에이티브한 생각에 걸림돌이 없는 도구..
      라기 보다는
      크리이에이티브를 더욱 잘 구현해 줄 수 있는 도구가 되어야겠지요?

      지금 사이트기획단계에 있는 제개인적인 고민은 과연 어느정도 검증된 플렉스(플래시)로 갈것인지.. 아니면 신진세대인 실버라이트로 갈것인지.. 정말 고민입니다.

      나름대로 장단점이 있어서 쉽게 결정내리지 못하겠네요.
      그냥 한번 크게 모험하는셈치고 실버라이트로 가서 좋은 레퍼런스가 되보면 어떨가 쉽기도 하다가도..
      정말 고민이네요.

      실버와 플래시 사이에서 고민인 저같은 사람에게 MS에서 주는 혜택은 없을까요?

  4. Favicon of http://gongdosoft.com BlogIcon 공도 2008.02.13 00:06  comment URL  Edit/Remove  Submit comment.

    한어통// 필요하다면 직접 미팅을 해보시는 건 어떨까요? 단순히 개인적인 관심이 아니라 어떤 서비스 구현적인 문제라면 MS의 UX 이반젤리스트인 리건님이 운영하는 http://uxfactory.net 에 문의를 하실 수도 있을거에요. 그리고 기획하고 계신것도 살짝 귀띔해주시면 더 좋을 것 같네요^^

    현재 단계에서 미디어를 제외한 실버라이트의 장점이라면 확실히 닷넷에 있는 것 같아요. 표현 능력에의 비교는 저보다는 플래시나 플렉스를 경험하신 분들이 더 정확하게 해주실 수 있겠죠. 한가지 제가 할 수 있는 거라면, 실버라이트와 플래시는 기반 구조나 설계 사상이 많이 다른데 실버라이트의 설계상의 이점을 살릴 수 있는 구조로 개발하는 방법이나 방향을 도와드릴 수 있을 거에요.

  5. Favicon of http://spponge.tistory.com BlogIcon spponge 2008.02.26 16:43  comment URL  Edit/Remove  Submit comment.

    실버라이트로 무엇을 만들지 간에 그것이 웹 2.0의 킬러 어플리케이션이 되어야 한다고 생각합니다. 그러한 성공 사례와 사용자 경험만이 실버라이트를 대중화 할 수 있겠죠...