zooil.com

제가 플래시 개발을 한 지 올해로 10년째입니다. 그간 참 많이도 변했죠. 버튼 이벤트 몇 개와 프레임 제어가 전부였는데, 이젠 웹에서 포토샵까지 만든다고 난립니다.



그런데 변하지 않는 게 하나 있습니다. 그 곳에서 '개발'을 하고 있는 사람은 여전히 개발자가 아닙니다. 돌연변이 Xman이죠.

늘 궁금했지만 요즘 들어 더욱 궁금합니다. 왜 그들은 진정 개발자가 못됐을까?라는 물음입니다. UI를 개발 한다고 고민한 1년전부터 다시금 원점으로 돌아갔습니다. 우린 왜 개발자가 아닌 걸까요?

사실 중요치 않을 수도 있습니다. 호칭이 뭐 중요하다구요? 개발이면 어떻고 스크립터면 어때요? 내가 즐겁고 결과물에 사람들이 행복하면 되는 거 아닌가요? 그래도 억울할 때가 있네요. 바로 동종업계라고 부를 수 있는 다른 분야의 개발자들에게 무시당할 때는 견디기 힘들답니다.

플래시 개발에는 3가지 호칭이 있습니다. 통칭해서 플래셔(Flasher)라고 부르지만 일이 좀 다릅니다.

1. 모션 그래픽 디자이너 or 애니메이터 - 플래시로 애니메이션을 만듭니다. 다만 동영상이나 이미지 위주로 만들면 모션 그래픽 디자이너라 할 수 있고 일러스트레이션 위주의 드로잉 결과물로 제작하면 애니메이터입니다. 이들은 대략 프레임 제어나 이벤트를 처리하기도 합니다. 이들이 사용하는 코드는 프레임에 작성하며, 평균 10줄 정도의 코드를 씁니다.


2. 액션스크립터 - 인터랙티브한 플래시를 제작하는 사람입니다. 대체로 프로그래밍은 모션과 인터랙션에 중점을 두며, 디자인적인 감각이 요구되는 직종입니다.


3. 액션스크립트 개발자 - 애플리케이션 위주의 플래시를 제작하는 사람입니다. 코드는 주로 클래스를 사용하며 라이브러리와 모듈화를 중요시 여깁니다. 코드에 과도한 집착을 보이기도 합니다.

대략 이렇게 구분해 볼 수 있는데, 상하 관계로 구분 짓거나 어느 것이 중요하다고 말할 순 없습니다. 모두가 중요하고 전문적인 일이지요.

자... 여기엔 개발 직군이 존재합니다. 프로그래머 또는 개발자라고 불리우고 싶은 사람들이 있는 거죠. 디자이너도 아닌 하드코어 개발도 아닌 어정쩡한 개발자들이지만 그들이 만들어내는 결과물에 대한 자부심 하나만으로 버티고 있는 사람들이 있답니다.

무엇이 문제일까요? 저는 이렇게 봅니다.

플래시의 근본에 좀 문제가 있.었.습니다. 이건 어디까지나 과거형이고 지금은 그렇지 않다는 게 잘 알려지지 않았죠. 플래시는 초창기 디자인만의 툴이었습니다. 거기에 프로그래밍을 더한 것이고, 실제로 하드코어한 개발은 없었습니다. 초기의 고착화된 개념이 지금까지 바뀌지 않았죠.

플래시의 개발 장벽이 좀 높습니다. 아니 매우 높다고 할 수 있겠네요. 다른 언어를 쓰는 개발자들이 넘지 못하는 벽이 바로 멀티프레임 입니다. 이는 무비클립일 수도 있지만 결국 무비클립도 멀티프레임을 내장하고 있으므로 동일하다 생각합니다. 코드는 프레임에 박혀 있고, 도대체가 디자인과 떡이 되어있는 요상한 괴물로 무얼 개발한다고 할 수 있는지 의심스러운 것이죠.

개발자들은 지독히 코드에 집착합니다. 소스 코드 레벨에서 보이지 않는 것은 믿지 않으려는 경향이 있죠. 따라서 플래시는 그저 SWF 덩어리인 디자인 결과물이라고 넘깁니다.

플래시 개발에 대한 알려진 지식이 별로 없습니다. 이게 참 저도 궁금한데, 플래시 개발자들만 말 안하는 사람도 아닐텐데 왜 그런지 모르겠습니다. 나름대로 결론 짓자면 초창기 플래시 시장은 '소스'가 매우 중요했습니다. 특출난 기교들은 자신만의 비법이 됐고 그걸 만천하에 공개하는 것은 결국 내 일거리를 빼앗기는 거라는 고집을 부리게 했죠.

에... 또... 개발에 대한 이론 자체가 별로 없는 이유는 플래시 개발을 하는 사람들의 출신이 SW 개발이 아니란 점도 한 몫을 합니다. 제가 지금까지 만나본 플래시 개발자들의 대부분은 '그저 플래시가 좋아서' 시작한 경우가 많습니다. '자바가 좋아서' 자바 개발을 하는 경우가 있는지 모르겠네요(쉽게 이해할 수 없겠지만 진짜 그렇습니다. 그래서 플래시를 제작하는 사람들은 고집이 아주 쎄지요). 이들 중 10% 미만이 컴퓨터 관련 지식들을 갖고 이 분야에 발을 내딛였습니다. 물론 그래서 개발을 잘 못한다는 것은 아니지만 그러다보니 이런 생각들을 해요 '내가 만드는게 정말 제대로 하는 걸까?'하는 고민이죠. 하지면 여기서 우리나라 토론 문화까지 문제를 만듭니다. 정반합 속에서 좋은 결과를 도출할 텐데, 고민은 그냥 각자 마음 속에 메아리를 치다 사그러들죠.

저는 이렇게 생각합니다. 플래시 개발은 쉽다고 보는데, 그건 어느 언어나 마찬가지 일 겁니다. 그냥 그까이꺼 대충 해보는 건 어느거나 쉽지요. 하지만 '제대로'하기엔 선지식으론 불가능합니다. 요즘 들어 '특정 도메인의 언어에 종속되지 말자'는 경향이 있는데, 여느 외국어와 마찬가지로 서바이벌은 할 수 있겠지만 마음으로의 진정한 대화는 매우 어렵습니다(개발에서도 잘 만든 진정한 코드를 그렇게 볼 수 있겠지요).

아직 제 고민도 결론을 낸 것은 아닙니다. 지금도 진행형이고 저만 고민했다고 풀 수 있는 문제도 아니고 이분야의 종사자들이 함께 노력해야 할 문제들입니다.

부탁입니다만 서로를 이해하기 위해서는 상대방을 인정하고 시작해야 한다는 점을 간과하지 말았으면 좋겠습니다. 부정하고 듣기 싫고 폄훼하는 상황에서 무얼 잘할 수 있겠습니까? 플래시 개발자들도 노력해야 하겠지요. 그들이 대화할 수 있도록 기회를 줬으면 좋겠네요. 부탁입니다.

외국영화를 보다 보면 '넌 해고야'라는 말을 듣고 짐을 싸는 장면이 나온다. 학창 시절에도, 직장을 다니는 지금까지도 어떻게 그게 가능할까 하는 생각이 든다. 외국이라 가능한 걸까?

그 장면에서 두가지가 놀라운데 우선, 회사가 사원을 그렇게 쉽게 해고할 수 있다는 것과 박스 하나만 달랑 싸들고 회사를 뜰 수 있다는 사실.

주로 미국 영화니 미국에서는 가능한 스토리인 것같다. 부당해고에 해당하는 것은 없을까? 성과주의 제도라서 가능한 걸까? 암튼 뭐 내가 인사 담당자는 아니니 거기에 대해선 자세히 모르겠다.

난 회사에 짐이 많은데, 회사가 아직 세입자이다보니 이사를 많이 다녔다. 이사때마다 '뭔놈의 짐이 이렇게 많아? 내가 이렇게 회사에 미련이 많았나?' 하는 고민이 끊이질 않는다. 근데 달랑 한박스라니! 내가 무식해 보인다.

그런데 얼마전 산학연계로 숭실대 가서 강의을 했다. 이제 졸업을 앞두고 있는 친구들이라 무슨 이야길 해줄까 고민하다가 그냥 내 인생 이야길 해줬다. 사회로 나가서 첫 발을 디딜 친구들이니 도움이 되지 않을까 하는 마음에...

그러고보니 나도 하던 일을 관둘뻔할 때가 있었다. 현재의 직장에서 말이지...

그땐 입사해서 1년쯤 됐을 땐데 플래시 게임을 만들고자 했었다. 싱글게임팀의 한 파트로 5명 정도 근무. 나 포함 개발자 3명, 디자이너 2명.

어느날 실장님이 부르셔서 가보니 '주일아 아무리 고민해봐도 플래시 게임으로 뭘 해야 할지 모르겠다. 답이 안나와... 그래서 말인데 너가 팀장으로 팀을 한번 만들어 보고 너희들끼리 고민해봐 단 6개월 뒤에 다시 보자'. 6개월 뒤엔 어떻게 되냐고 여쭈었는데, '답이 없으면 해체. 다른일 해야지'.

깜깜했다. 내게 게임에 대한 재능이 있는 것도 아니고 그냥 플래시를 좋아하다 그걸 업으로 삼게 됐고, 더구나 그땐 병특이었단 말이다. 나더러 어쩌라고... 하지만 길게 고민할 순 없었다. 팀을 만들면 어떻게 해야 할까? 목표는 어떻게 잡나? 성과 평가는? 이런 조직 관리는 떠오르지도 않았다. 팀장이란거 해볼 생각도 없는 상태에서 그게 아니면 내 인생이 망가질지도 모를 상태였으니까(사실 팀원들 걱정도 그땐 못했다).

암울했던 시기는 어째 지나갔고 지금 돌이켜 보건데 늘 밥벌이 고민을 했던 것 같다. 팀원들이랑 '왜 맨날 우리는 하루하루 어떻게 살아야 하는 가만 고민해야해?'하며 울먹인 적도 많았다. 근데 그때 뿐 아니라 예전에도 지금도 늘 그런 고민을 하며 산다. 내가 고민이 많은 건지 아니면 인생이 그런 고민하며 살라고 있는 건지...

죽을 때까지 고민하겠지? 내일 뭐 입지? 라고... ㅎㅎ

코드 시연에 대한 자료 업로드 했습니다. 코드 제작을 말로써 설명하는 것이 참 힘들다는 점 양해 부탁 드립니다. 최대한 자세히 설명한다고 정리했는데, 너무 너무 어렵네요. 개발에 대한 전반적 지식과 특정 프로그래밍 언어를 숙지하지 않으면 쉬운 문제가 아닙니다. 강연에서도 말씀 드렸듯이 '어 이거 괜찮네~' 정도의 동기부여만 있어도 성공한거라 생각합니다.

>> 예제파일 다운받기





에혀 그날 왜 그랬을까요? 실수만 안했어도 이렇게 전전긍긍하진 않았을텐데... 멋지게 코드 시연 보여주겠다는 과욕이 화를 불렀습니다. 나름 노트북 키보드는 불편할 것 같아 회사에서 쓰던 키보드까지 챙겨가지고 갔는데, 선보여드릴 기회가 없었네요. 암튼 많은 걸 배웠습니다~

제가 유저의 경험(UX:User Experience)이라는 말을 알게 된 것은 Flash를 만든 Macromedia 덕분이었습니다. 이제 전설이 된 그 회사는 Experience Matters라는 화두를 전파하기 위해 노력했었죠. 덕분에 사용자들은 보다 편리한 도구와 컴퓨팅의 즐거움까지 얻게 됐습니다. 이젠 Better by Adobe란 전략을 구사하는 Flash가 됐지만, 저는 아직도 Flash와 UX가 동일하게만 느껴집니다.



물론 Flash가 UX의 가치를 너무 변질시키고 왜곡 시켰다는 책임을 면할 수는 없습니다. 하지만 그건 도구를 이용한 제작자들의 잘못이지 도구 자체가 틀린 것은 아닙니다. 살인 사건에 칼이 사용됐다고 모든 가정의 부엌에서 칼을 없앨 수는 없지요.

어릴적 외국 영화를 보거나 외국의 문물을 구경할 수 있었던 매체 등을 통해서 제가 본 세상은 제가 살아가는 세상과 다르다고 생각했습니다. 치기어린 마음에 트루먼쑈처럼 혹시 세상이 날 속이고 있는 것은 아닐까하는 마음이 들기도 했었죠. 길거리는 왜 그렇게 우리보다 예쁜지, 우아한 건물들은 회색톤의 아파트 숲에 쌓인 우리네 환경보다는 천국처럼 보이기도 했습니다.

머리가 커졌을 때 그들이 사는 세상 속에 가볼 기회가 생겼을 때 사람 사는 곳이 별로 차이가 없다는 걸 알게됐습니다. 하지만 어릴적 느꼈던 마음은 여전히 동일했죠. 참으로 궁금했습니다. 그게 무얼까하고...

정확히 한단어로 짚어볼 수 없는 그 느낌을 정의하면 '공공디자인', '완성도(조잡함의 반대로)', '프로세스', '자연(nature)' 정도라 할 수 있습니다. 그리고 그것을 통칭하면 '경험'이 다르다고 할 수 있지요.

우린 참 투박한 환경에 살았습니다. 좋게 이야기 하면 군더더기 없이 만든 제품을 쓰고, 불편하지 않은 정도로 꾸며진 곳에서 살아가는 것이죠. 경험의 가치? 그게 뭐 중요하다고요. 그냥 누울 곳 있고, 배불리 먹을 수 있음 되는 것을...

기능중심적이고 성장지향적인 시대를 지나오면서 이제는 다른 세상에 눈을 돌리고 있습니다. 어느날 갑자기 밋밋하던 아파트들이 '푸르지오', '래미안', '낙천당(이런 브랜드가 있습니다. 좀 갸우뚱한데, 왜 이렇게 이름을 지었을까요? 중국 브랜드 같습니다 ;-)' 이란 이름을 갖고 화려한 옷을 입기 시작했습니다. 더불어 녹지도 많아지고 사용자의 동선을 고려한 내부 설계를 통해 살 맛 나는 공간이 됐지요. 그리고 사람들은 대우아파트 보다는 푸르지오로 몰립니다(기존 아파트 이름도 브랜드로 바꾸죠. 그래서 예전 이름으로 찾기 힘든 동네도 더불어 많아졌습니다 -_-).

제가 사는 세상은 이랬고, 또 이렇게 변하고 있네요. 그럼 본론으로 들어가서 '오만한(?) Flex 관련글에 대해 한 말씀~'을 본 소감을 적어볼까요?

기간계 업무가 얼마나 대단한지 전 모릅니다. 앞으로 그럴 일을 하게 될 수도 하고 싶지도 않을 것 같고요. 하지만 이런 예를 들어볼까요? 자동차 만들 줄 아십니까? 차를 만들 줄 알아야지만 차에 대해 논할 수 있을까요?

'표현이 일부분 적절하지 못해 딴지거리를 제공한다'고 하셨지만 좋은 말이 끝에가서 畵龍點睛이 못되고 蛇足으로 전락한 것에 대해 '알지도 못하는 사람들이 쓸데 없는 간섭'을 하는 것은 아닙니다.

기간계 업무 대부분이 Java를 쓴다는 것은 애초 그 업무를 담당했던 사람들이 Java 세상에 있던 사람들은 아닐까요? Java가 없던 시절에는 COBOL을 썼다지요. 요즘 와서 기술적 우위는 그 간격이 매우 좁습니다. 오히려 자본에 따라 기술이 바뀌고 그걸 만드는 사람이 다룰 수 있는 기술로만 제품을 만들게 되지요. 우리 모두가 비지니스의 노예들 아닙니까? ;-)

기간업무에 UX 컨설턴트를 참여 못시키는 환경인 것과 필요 없다고 단정 짓는 것은 차이가 있습니다. 이에 대해서는 앞서 말한 저의 어린 시절을 회상해보면 그 뜻을 알 수 있겠지요. UX는 사용자(사람이던 기계던)가 존재한다면 개념은 꼭 탑재 해야 합니다. 인트라넷을 예로 들어 보지요. 대표적으로 UX가 무시되는 환경입니다. 엉망인 UI 구성이 대부분이죠. 조직도를 보려면 분석 차트를 보려면 ActiveX 서너개쯤은 너끈히 깔아야 합니다. 메일을 보냈는데 못 받았다네요. 알고 보니 동명이인이 존재 했고, 전달을 누를 때 수신인 확인쯤은 해줬어야 합니다. 외부 고객이 쓰지 않는다고 사용성을 간과하기 일 쑤지만 저는 이렇게 생각합니다. 내부고객(사원)이 정말 해피하게 작업도구(인트라넷 시스템도 포함되죠)를 다루도록 환경을 구축해야 외부고객에 대한 편의도 기본이 된다는 사실 말입니다.

문제의 핵심은 '비지니스 사기꾼'들인데 그것을 Flash 세상에 있는 사람들을 전부 비하했다는 것이지요. 그리고 그 이야기가 개인 블로그도 아닌 플렉스 챔피언들의 팀 블로그에서 전파됐다는 것도 한 몫을 하고 있습니다. 더불어 팀블로그를 떠나 유저가 많은 오픈 스페이스에 퍼블리싱 했다는 것도 Flex 유저 전체 의견처럼 호도되고 있지요. Flash 하는 사람들이 무슨 잘못입니까? 자바를 다루는 사람도 미꾸라지가 있지 않나요?

제 의견은 이렇습니다. 이만 총총.

Flex에 대한 단상이란 글을 보고 여러가지 생각이 들었다. 일면 정확한 지적도 있다. 하지만 그 배경에 묻어있는 개발분야에서의 잘못된 인식에 대해 개인적으로 불만이 가득하다.



경험디자인의 요소란 책을 보면 다음과 같은 내용이 처음에 등장한다.

1장 - 사용자의 경험, 왜 중요한가?

흔히 있는 불행한 사건들의 대부분은 사용자 경험을 간과한 것에서 기인한다. '재수없는 사건들' 모두가 제품을 설계할 때 좀더 신경을 쓴다면 피할 수도 있는 일이었다. 이러한 사례들 모두가 사용자 경험(user experience)에 대한, 즉 실제 세계에서 사용자가 제품을 어떻게 사용하고 제품이 어떻게 동작하는가에 대한 주의 부족을 보여주고 있다.

제품을 개발할 때, 사람들은 '그 제품이 무슨 일을 하는가'에 주로 신경을 쓴다. 제품이 어떻게 작동되는가하는 사용자 경험에 대한 생각은 성공적인 제품과 실패작의 차이를 결정할 수도 있는 중요한 부분이지만 무시되는 경우가 종종 있다 .

사용자 경험은 제품이 내부적으로 어떻게 작동하는가의 문제가 아니다. 사용자의 경험은 제품이 외부에서, 즉 한사람이 그 제품과 접촉하고, 그것을 가지고 일하는 그곳에서 어떻게 작동하는가의 문제이다.

UI는 그것이 불필요한 화려함이라고 치부할 대상은 아니다. 그 중심에는 사용자에 대한 배려와 경험의 증가에 대한 고민이 묻어있는 결과물이다. 버튼에 마우스를 올려놓았을 때, 버튼의 롤오버 색상이 변한다는 것이 개발자에게는 무가치할 수 있고 번거로운 작업물일 수 있지만 사용자가 느끼는 경험의 단위는 판이할 수도 있다. 실제로 별로 멋지지 않은 인터페이스가 그런식의 반응을 보이면 더욱 역겨울 수도 있는 일이지만...

예쁘다의 중요성

'예쁜 것'은 사람의 본성을 자극하는 기본 요소이다. 예쁜 이성을 찾는 것도, 예쁜 물건을 사는 일도 다 심미적인 충동을 부추기는 경제적 행위와 맞물려있다. 하지만 웹 사이트에서 이런 부분은 너무나 자극적인 치장으로만 구현한 것이 사실이며, UX에 대한 진지한 고민없이 겉치례에만 집중해서 속빈강정으로만 남은 서비스들이 많이 있다.

그러나 개발 영역에서 볼 때, 디자인에 대한 지지를 충분히 해왔다고 할 수 있는지도 더불어 고민해야만 한다. 과연 디자인의 요소 요소가 충분히 그 가치가 있으리라는 '대화'를 시도해 봤는가? 개발자는 디자인 영역을 그냥 '화려하고 쓸데없는 것들'이라고 무시하진 않았는가? 수 많은 디자이너들이 말하는 개발에 대한 불만은 '왜 나의 일이 중요하지 않냐'는 것이다.

바벨탑의 아집

물론 개발자들은 '디자이너가 불필요한 군더더기를 많이 붙인다'거나 '오히려 데이터의 가치를 희석시킨다'라고 말한다. 이런 과정에서 서로의 생각차를 좁힐 수 없을 때 그 문제가 점점 심각해진다. 공통의 언어가 없을 때, 대화는 중지되고 결과는 사용자에게 고통이될 수 밖에 없다. 서로 자신의 오만과 편견을 버리지 않고 고집만 부렸기 때문에 실패한 프로젝트 사례들은 무수히 많다. 같은 목적으로 뭉친 하나의 팀이란 생각을 갖고 공통의 목표를 추구했다면 그런 일이 발생하지 않았을텐데 말이다.

실버라이트 자료 中

UI는 사용자와의 대화

사용자가 생활하는 곳을 실세계라고 한다면, 기저에 깔려있는 보이지 않는 데이터의 세계를 이상계나 환상계 쯤으로 부를 수 있지 않을까?(용어만 차용했다. 굳현님의 견해와는 달리...) 그렇다면 모니터 저 너머의 세상과 현실을 연결시켜주는 통로는 바로 UI가 된다. UI는 바로 개발자가 원하는 다수의 유저가 나의 시스템을 많이 사용하도록 만드는 행위를 유발하는 시발점이다. 개발자의 직접적인 고객은 기획자나 기업 클라이언트겠지만 개발한 시스템을 본질적으로 사용하는 유저는 그들과 직접 관련있는 사람들보다 훨씬 큰 집단이다. 실제 사용자와 면대면 대화를 하는 것이 바로 UI에 해당한다. 그렇기 때문에 사용자는 데이터보다도 BackEnd 개발작업보다도 훨씬 중요한 가치를 갖는다. 당장의 내 코드가 데이터를 어떻게 실어나르고 그것을 처리하는 것도 중요하지만 사용자에게 필요한 부분도 간과할 수는 없다. 실제로 내가 생활할 수 있는 봉급을 주는 사람일테니까...

극단적인 가정

일례로 다음과 같은 가정을 들어보자.

A) 시스템의 보이지 않는 부분은 엉망이다. 그러나 UI가 좋다.

B) 시스템을 아주 잘 구축했다. Perfect! 그러나 UI가 구리다.

어떤게 더 성공할 것이라 생각하는가? 물론 시스템의 BackEnd와 FrontEnd가 모두 우수하다면 더할 나위없다. 하지만 극단적으로 가정해볼 때, B보다는 A의 선호도가 높을 것은 자명한 사실이다. 실제로 우리나라는 제품의 기능면에서 우수성은 오래전에 입증했지만 사용성이나 감성을 자극하는 디자인면에서는 실패를 맛봐왔다. 최근 디자인 경영을 앞세운 회사가 한두 기업에 그치지 않는 것만 봐도 그 중요성을 무시할 수 없다는 점을 인정해야 한다.

UI개발도 전문영역

세상의 모든 일들이 그렇듯, 어떤 분야가 발전을 거듭할 수록 세분화되고 전문화되는 것이 필수다. 그만큼 다루어야 하는 지식의 양이 방대해지니까. UI개발 역시 클라이언트 사이드의 기술 발전과 더불어 전문 영역과 직군에 종사하는 사람들이 생겨나고 있다. 물론 그 전부터 제품에 있어서는 특별한 UI개발 영역이 존재했지만, 대개 플랫폼과 디바이스가 하나이고, 디자인을 기존 개발자들이 적절히 결합시키는 단위의 업무가 많았다. 하지만 웹에서는 사용방법이 여러가지이고, 이에 따라 웹표준과 크로스브라우징을 고려한 UI개발 영역이 세분화되고있다.

세상에 모든걸 다할 수 있는 맥가이버 개발자는 그리 많지 않다. 디자인과 개발은 함께해야 존재가치가 있지만, 영원히 사랑할 수 없는 철도 레일일 수 밖에 없다. 따라서 아직까지 회색지대로 남아있는 UI개발이라는 영역(디자인 관점에서 UI디자인일 수도 있지만)은 이들 두 집단의 간극을 밀접하게 맺어줄 수 있고, 따라서 그들의 영역도 새로운 언어(소통을 위한)를 구비하고 보다 전문적인 지식이 필요한 분야로 성장과 더불어 기존 집단에서 그 가치를 인정해야 한다.

Flash 개발

많은 개발자들이 Flash를 안좋아한다. 불필요하고 거추장스러운 인터페이스라고 생각하며, 디자인 툴에서 출발한 Flash IDE가 개발툴로써 이상한 형태를 갖고 있기 때문이다(개발자들은 Flash IDE의 멀티프레임의 필요성을 익히는데 한참 걸린다).

플래시라는 용어에는 현재 3가지 의미가 들어있는데, 플랫폼으로서의 플래시(Flash Player에서 구동되는), 어도비 제품 군으로서의 플래시(Flash, Flex, Apollo 등), 그리고 오래전부터 존재했던 Flash IDE를 지칭한다. 플래시(이하 Flash IDE)가 원래는 애니메이션 툴이었지만 현재는 멀티미디어 디자인 툴 + Actionscript 언어를 내장한 개발 툴로서의 가치가 공존한다. 요즘들어 플래시 개발분야라는 것이 진정 있을까하는 회의마저 드는데, 그것은 개발 플랫폼으로서의 가치를 너무나 얕게 보는데 있어서의 억울함 때문이다.

개발 분야에 있어서 플래시는 매우 협소한 시장이다. 그만큼 전문가층이 얇고 수요를 공급이 충족시키지 못할만큼 개발자가 없다. 따라서 실제로 개발에 대한 범용적인 이해정도와 개발능력이 부족한 것도 사실이다. 하지만 실제로 기능성이나 사용성에서 후진 플랫폼인 것은 절대 아니다. 모르면서 그렇게 평가 절하하는 것은 자신만의 아집에 싸여 있는 것이며 히키코모리 수준밖엔 안된다.

모르는 것에 대해 무식하다고 비난 할 수만은 없다. 그 시장의 가치나 개발 영역으로서의 새로운 분야로의 인식이 필요하다. 그만큼 해당 시장에 있는 종사자들의 노력도 뒷받침되어야 하지만 기존 시장에서의 기득권 세력들도 손을 내밀어 포용해줄 필요가 있다. 배척하기만 한다면 그 분야는 더욱더 후진을 면치 못할테니까...

전 분야의 지식을 모두 소유할 수 있는 사람은 없다. 한가지 도메인에서의 지식이 있다 해서 다른 분야의 지식이 무가치하며 자신보다 못하다는 인식을 가져서는 안된다. 결국 목표는 매한가지인 것이 아닌가? 동일한 사용자를 기대하고 있다는 점 말이다.

결국 Flex도 Flash다

Flex가 아무리(정확히 말해서는 FDS다) 데이터 통합이나 편리한 유저 환경을 제공한다고 해도 Flash와의 융합 없이는 사용자에게 커스텀 인터페이스를 제공할 수 없다. 물론 Flex에서 컴포넌트를 제작할 수 있지만 기존 시장에서 Flash 개발자의 노하우와 Flash IDE가 가진 생산성을 따라잡기 힘들다. Adobe가 마케팅 수단으로 Flex의 화려함을 일부러 포장한 것이 아니라 시장에서의 기대가 그만큼 융통성 있는 Flash 인터페이스를 요구했기 때문이다. 그리고 유저가 마주하게 되는 것은 결국 Flash SWF 이므로 무엇이 잘났다고 따지는 것은 정말 무의미한 밥그릇 투쟁밖엔 안된다. 그러므로 서로가 필요한 기술이라는 존중과 함께 공존할 수 있는 방안을 간구하는 것이 오히려 각자의 영역을 키우는 상생의 길일 것이다.

토양이 없다면 나무가 자라지 못한다. 나무가 없으면 민둥산일 뿐 숲으로서 가치가 없다. 자연은 공존을 통해 우리에게 더 큰 경험을 제공하는 것이다.