오랫만에 이에 관련한 두번째 글을 쓰게 되었네요.

불필요한 서두는 짧게 끊고 본론으로 들어가겠습니다.^^

플래시를 해오신 대부분의 분들은 웹프로젝트 환경에 익숙하실 것이며,

플래시의 맛보기를 해주는 각종 서적들의 대부분 역시 웹환경을 기준으로 집필되어 있습니다.

모바일 프로젝트를 시작했던 첫 순간,

저 역시 가장 큰 착각을 한것이 바로, "웹이랑 뭐 달라야 얼마나 다르겠어?"

라는 생각을 했던 것 입니다.

작업 공간에 지인 몇분이 계셔서 혹독한 환경에 대해 적나라하게 말씀해 주셨지만,

솔직히 처음에는 심각하게 귀담아 듣지 않았습니다.

작업하면서, 시간이 흘러갈수록 몸으로 깨닫게 되었을 뿐이죠. "이 환경은 정말 혹독하네."

라고 말입니다.

두번째 이야기는 바로, 그렇게 다른 점이 무엇인지를 바탕으로 얘기를 해보려 합니다.

모바일 작업 환경은 웹 작업 환경과는 거의 모든것이 다르다고 할 수 있습니다.

작업진행방식 / 작업기간 / 제작환경 / 유지보수 까지...

제 경험상 다르지 않은 것이 없었습니다.

가장 단순한 비교를 하나 짚어 하고 넘어가 보겠습니다.

"웹에서 사용자의 입력영역은 작업 환경에 크게 영향을 미치지 않습니다. 마우스 포인터의 모서리가
사용자에게 클릭되어야 하는 포인트로 이끌어 가주는 역활을 하기 때문입니다. 허나, 모바일은
입력의 발생이 손가락으로부터 시작합니다. 손가락의 형태는 둥글고 사람마다 크기도 다르기 때문에
어떻게 입력이 발생할지 , 어느 정도 영역안에서 입력이 발생토록 해야할지 또한, 그 부분을 벗어난
경우의 예외는 어떻게 해야할지에 대한 고민을 심각하게 해야합니다."

위의 비교에서 볼 수 있는 유사한 경우들을 겪고 해결 해 나가며, 웹과 모바일의 차이점에 대해서

정의한 저의 기준은 이렇습니다.

"웹은 넓은 환경에서 새로운 퍼포먼스를 만들어 내는것이 어렵고,
모바일은 좁은 환경에서 안정화 시키는 것이 어렵다."

즉, 웹은 상상하는 대로 모든것을 만들수 있는 환경이 제공되어 있습니다.

허나 작업자의 상상력 혹은 기술력이 그에 미치지 못한다면, 한정된 구현에 만족하고 결국 클라이언트의

기대에 부응하지 못하는 결과에 닿게 되는 것 입니다.

허나, 모바일은 환경의 제약으로 구현에 사용할 수 있는 기술력의 한계가 좁으며, 대부분의 컨텐츠 구성이

웹에서 쉽게 볼수 있는 것들 입니다. 허나, 그 좁은환경으로 인하여 웹에서 손쉽게 구현하고 동작시켰던

것들을 안정화 하기 위해 (저 역시 그랬지만,) 작업을 처음부터 다시 시작할 수도 있는 경우가 있습니다.

두 환경 모두 작업자에게 장점 / 단점 을 동시에 제공하고 있음은 충분히 이해하고 있어야 할 것 같습니다.

이러한 차이점을 무시하고 프로젝트를 시작한다면, 멀지 않은 미래에 크나큰 낭패가 기다리고...;

모바일 프로젝트를 시작하신다면, 저와 같은 착오를 하지 마시고 환경의 차이점을 분명히 인식하셔서,

불필요한 소모를 줄여가셨음 하는 바램입니다.

저도 위와 같은 차이점을 인식하지 못한 댓가로 적잖은 밤샘을 했던 악몽같은 시간들이 기억납니다 ㅡㅠ

환경의 차이점을 분명히 인식하시면, 가급적 절재하여 사용할 부분들은 판단이 되며, 그 판단을 기준으로

초기작업 진행을 보다 안정적으로 하실수 있을것이라 생각합니다.

선행작업에 대한 마음가짐(?)을 충분히 가지고 나면,

두번째로 진행되어야 할 부분은 "분기" 가 아닐까 싶습니다.

즉 역활을 나누고 해야할 일을 명확하게 구분한다는 것이라 생각 합니다.

역활은 즉, Role 의 형태로 모델러를 만드는 것인데,

이것은 진행되면서 컨셉의 변경 혹은 예상치 못한 예외로 인하여 작업의 결말까지 계속해서 수정이

발생하는 경우입니다.

그렇기에 유지보수에 있어서도 비용발생에 적잖은 영향을 주기 때문에, 비용을 줄이고 노동의

수준을 낮추기 위해서는 역활의 명확성 과 변경을 위한 유연함을 갖춰야 할 것 입니다.

저 역시 아직까지도, 프로젝트 시간에 급급하여 때때로 잘못된분기로 인하여, 프로젝트 마감때

진땀빼며 머리를 쥐어짜는 경우들이 종종 있습니다.

그러면서 늘 후회하곤 합니다.

" 내가 대체 왜이렇게 구분해놨을까? ㅠㅡㅠ" 라고 말이죠.

이런 악순환의 반복이 계속해서 발생하는 가장 큰 이유는 아마도 구현에 급급함 때문일 것 입니다.

하나의 행위만을 목적으로 결과를 만드는데 집중하는 것이지요.

여기서 치명적인 실수가 빈번히 발생하는데, 그 실수는 바로 다른 요소들이 받을 영향에 대한 무심함으로

인한 크리티컬한 문제를 말합니다.

사소한 예를 들어 본다면, 하나의 객체에 롤오버 이벤트가 발생을 하는 경우 그 롤오버 이벤트로 인하여

해당 객체로 인하여 주변 기타 객체들의 위치가 변경되는 경우에, (저 역시 그래왔지만,...)

대부분의 분들이 아마도 해당 객체의 행위를 정의한 후에 미치는 영향에 대한 고려를 할 것 입니다.

아마도 이런식으로...

"오버가 되었으니 오버가 된 객체의 행위는 이렇게 되도록 만들었으니, 해당 객체의 위치를 바꿔야겠다."

유년 시절 제가 다니던 미술학원의 원장님이 하신 말씀이 갑자기 떠오릅니다.

"명암의 형태를 만들어갈때는 전체적인 균형을 맞추고 디테일을 표현하는 것이 좋다." 
(갑자기 왠 쌩뚱맞은 미술학원 경험담을 늘어놓느냐고 말씀하실 수도 있지만, 제가 말하고자 하는 얘기에
보다 도움이 되는 말이라 생각 합니다^^.)

객체에 롤오버 이벤트가 발생하는 경우에 대한 디테일한 구현을 하기 앞서서, 전체적으로 발생하는 경우

들을 고려하여 균형을 맞추는 것이 우선이라는 얘기를 하고 싶습니다.

사소한 행위들은 나중에 결정지어도 늦지 않는다는 말이죠.

행위의 집착은 분기의 분명함에 적잖은 악영향을 미친다고 생각 합니다.

private funciton over($e:MouseEvent):void
{

제가 금년(2009)에 처음으로 모바일 프로젝트에 투입하여 작업을 진행하였습니다.

처음 한 프로젝트 였기에 모바일의 규모에 관하여 구체적인 사실들은 모르지만,

들은 바로는 역대 가장 큰 프로젝트 중 하나라고만 듣고 알게 되었습니다.

솔직히, 매우 힘들었습니다.

제가 맡게 되었던 작업의 진행이 이전에 한참 잘못 되어있었기 때문이기도 하지만,

프로젝트 자체가 많은 시도를 하였기에 어려운 점이 많았던것 같습니다.

이제는 완료가 되어 전세계에 시판까지 이뤄지고 있고, 저는 제가 몸담아 있던 곳을 

떠나, 현재 제가 속한 곳에서 모바일 프로젝트를 하고 있진 않지만,

그간 겪어왔던 상황들, 그리고 능숙하게 대처하여 벗어났던 난관의 순간들, 그리고

반드시 겪을법한 고비들에 관하여 써가보고자 "MOBILE" 카테고리를 만들었습니다.

앞으로 차근차근 프로젝트 작업의 진행 방식 과 함께 다양한 정보를 남기도록 하겠습니다.

플래시라는 프로그램에 대한 개념이...

디자인 툴 이라는 인식으로 부터 시작하여 개발 툴 이라는 인식으로 변하는 현재 상황에서

언어라는 요소가 더욱 큰 비중을 차지하게 되어 플래시에 접근하기는 더욱 어려워 진것이 사실 입니다.

위에 말한 내용에서 핵심을 뽑아 다시 말해본다면,

"개발은 언어로 인해 어렵다."

라고 정의내릴 수 있을 것 입니다.

이것은 개발이기 때문에 어렵다기 보단, 언어라는 속성 자체가 이해가 어렵기 때문입니다.

(진화론에 의거하여) 각 생명체가 탄생하여 집단을 이루고 그 집단의 구성원들이 발전하여 지금의

현재 입니다. 그와 함께 지금까지 무수히 많은 생명체들이 각기 다른 방법으로 소통을 위해

발전해온 것이 "언어" 입니다.

언어란 그와 같이 순식간에 갖춰진 것이 아니며, 또한 한 순간에 소통이 가능한 상태로 되는 것은

저는 불가능 하다고 생각 합니다.

그렇다면 "나는 소통할 수 있는 언어를 갖춘 사람인데 왜 개발이 어려울 수 있을까? 라는 의문을

가질 수도 있을것 입니다.

저는 스스로 이 질문에 대한 답을 이렇게 내렸습니다.

"소통할 수 있는 언어를 가졌다 확신하기 때문에 개발이 어려운 것이다." 라고 말입니다.

이 말은 즉, 본인 스스로가 확신하는 결과로 인하여 소통이 무너지는 것이라 봅니다.

현재는 모두가 본인의 의사표현만으로도 그 안에서 모든 것을 행하며 살 수 있기에,

소통을 위해 선행 해야할 것들을 잊어가게 되는 것이 아닌가 싶습니다.

개발(언어를 통한 개발에 한정함.)은 컴퓨터와 소통을 하는 것 입니다.

즉, 컴퓨터가 사용하는 언어와 나 자산이 사용하는 언어 사이의 통신을 이뤄내는 것이

개발의 시작이라 할 수 있을 것 입니다.

그 시작을 위해서는 반드시 거쳐야 할 선행이 있어야 한다고 생각 합니다.

그것을 명사로 표현해 본다면 "배려" 가 아닌가 싶습니다.

"배려 - 도와주거나 보살펴 주려고 마음을 씀"

물론, 이 명사의 의미가 새로운 소통만을 위해 반드시 거쳐야 하는 선행은 아닙니다.
언어체계가 갖춰진 사람 사이라 해도 그 안에서 근본적으로 갖춰야할 선행일 것 입니다.
그 보다 지금은 컴퓨터와의 소통에 중심을 두겠습니다^^. 

컴퓨터에게 어떻게 하면 좀더 명확하고 정확한 의사전달을 할 수 있을까? 라는

진심의 배려가 개발을 위한 언어의 첫 마디 부터 완성된 문장에 이르기까지 그 흐름을

유연하게 만들어 준다고 생각 합니다. 

그리하여 저는 개발의 첫번째 선행 작업은 "배려" 라고 생각 합니다.

어찌보면 개발과는 동떨어진 인문학적 표현이지만, 가장 보편적인 과정 부터 철저히 하는 것이

차후에 안전성을 보장한다는 것이 저의 생각이기에, 이렇게 생각을 적었습니다.

선행작업에 관한 두번째 이야기를 약속하며 이만 글을 마칩니다.

"보다 고개 숙인 벼삭부터, 사람의 손길이 와닿는다."

요즘 가장 고심하며 생각하는 부분이 다름아닌 "좋은 커뮤니케이션 이란? 무엇일까?."

입니다.

일차적 개념은 의사소통 이라 정의할 수 있으며,

좀 더 개념적으로 접근한다면, 상대방이 이해할 수 있는 의사소통이라 할 수 있을것이라 생각합니다.

그 문제에서 보다 깊은 생각을 하게 되었는데,

그렇다면 과연, 이해할 수 있는 "의사소통이란 어느정도의 수준으로 정의할 수 있을것인가?" 에 관한

문제 였습니다.

이것에 대한 답이 있을 수 있을까? 라는 반문으로 합리화 하려 하였지만,

여전히 좋은 커뮤니케이션 이란? 에 대한 답은 내릴수가 없었습니다.

그리하여 좀 더 현실적으로 접근해보고자 대화를 나눴던 수 많은 대상들과의 대화내용을 떠올려

보았습니다.

생각하고 생각할수록...

"나는 지독하게 이기적이었구나. 그들이 이해해는 제스쳐를 한건 나를 배려한것 뿐이었어."

라고 판단하게 되었습니다.

그러던 와중에 저를 가르치고 계신 스승님께서 저의 문제점을 지적해 주셨는데, 제 무릅을 탁 치게

만드는 얘기였습니다.

그 분은 이렇게 말씀하셨습니다.

"모두가 이해할 수  있는 글을 쓰려면 보기쉽고 내용을 정리해서 간결하게 작성되어야 겠지?
그렇다면, 지식이 충만한 사람은 그 글을 더욱 이해하기 쉽겠지?"

제 글을 보는 분들께선 이쯤되면 "좋은 커뮤니케이션" 에 대해 "아!" 하고 이해를 하지 않으셨을까

생각합니다.

좋은 커뮤니케이션이란 커뮤니케이션을 위한 특정 대상을 넘어 이해하기 쉽도록 논리적이며,

간결하게 정리되어 체계화 되어야 한다는 것이라 생각합니다.

물론, 정답이라 섣불리 생각하진 않습니다.

그저, 지금까지 저의 짧은 경험과 지식이 깨닫게 해준 결과일 뿐입니다.

앞으로 있을 보다 많은 과정이 이 결과를 더욱 성장시켜 주겠지요.

왠지 앞으로 지금까지 보다 좀 더  좋은 커뮤니케이션 할 수 있지 않을까란 자부심이 들기도 합니다.

대상을 배려하며, 원활한 소통 관계를 맺어 갈 수 있도록 노력하려 합니다.

"좋은 "코드"  는 좋은 커뮤니케이션 으로 부터 출발한다."

이것을 앞으로 제가 할 코딩의 제 1 원칙으로 삼고자 합니다.

스터디를 시작한지 벌써 3주가 지났습니다.

10년이 지나도 강산은 변하지 않는다 했는데,

저는 3주만에 참으로 많이도 변한것 같네요.

변화의 시작은 논리적인 사고 에서 부터 시작 하였습니다.

뇌리에 가득했던 개념들을 싹다 들어내서 새롭게 가공하는 중이라,

하루가 짧다해도 과언이 아닌듯 합니다.

저의 배움이 얼마나 빈약했었는지,

논리를 가지고 외쳤다 생각했던 주장들.

참으로 부끄럽기 짝이 없을 정도로 숙연해 집니다.

지금까지 제가 깨달을 논리적 사고의 가장 큰 중점은 이러합니다.

"논리적 사고는 결코 나를 기준으로 정의 되어서는 안된다."

그 이유는 논리의 대상은 결코 내가 아니기 때문이라 생각 합니다.

논리적 사고를 배워가며 제 자신의 변화를 가장 크게 느낀 부분은

요즘은 코드 한줄을 짜더라도 (변수를 가정한다면) 왜? 변수명은 이렇게 지어져야 하는지.

중첩되 사용될 문제는 없는지. 이 변수는 이곳에서 어떤 역활을 할 것 인지? 등등...

변수가 가진 특성으로 한두줄의 문장을 만들어 고민해보고 정리를 해가는 과정이 생긴것 입니다.

예전에는 정말 즉각적으로,

"숫자값이 필요하네? 넘버타입 변수 만들어야겠다."

라고 생각했던 제 자신이 참 멍청해 보입니다.
(이런 경험도 보다 나은 경험을 위해 소중하다 생각합니다.)

그래서 문득 든 생각이, 조만간 시간이 좀 생기면 과거(플래시에 대한 개념이 전혀 없던시절...)

작업본들을 논리적으로 세분화 하여 그 수 많은 코드량을 줄여볼 생각입니다.

그럼, 제가 무엇을 잘 못 했었는지, 그리고 잘못된 논리를 좀더 구체적으로 명확하게 갖추는 연습을

할 수 있지 않을까요?!.

여담이지만, 요즘은 말 한마디도 쉽게 내 뱉지 않게 된것도 참으로 크게 변한점이 아닌가 싶네요.

예전에 그리도 열광했던 "롤랑바르트" 의 "기호학" 과 "사진학" 을 다시 한번 읽어보려 합니다.

예전엔 지금보다 더 어리석었어서, "이렇게 어려운 논제들을 왜 이리 짧게 써논거야!" 라고 불만만

토로하고 억지 논리를 세웠는데, 다시 한번 그의 생각과 사고를 읽어보려 합니다.

논리란 참으로 사람을 구속하면서도,

즐거운 기호 인 것 같습니다^^

신...

제가 군대 있을때 가장 많이 읽었던 올림포스 신들의 이야기를 바탕으로 

그들이 머물고 있는 환경과 함께 그들의 뒤를 이을 후보생들이 겪는

사건들을 토대로 스토리가 구성 되어 있습니다..

개인적으로 올림포스 신들은 물론, 그 외 존재들에 관심이 많았던지라,

읽을때마다 개인적으론 매우 재미를 느끼게 해주는 책인데,

구매한지는 좀 됐는데 이제야 "1권"을 마무리 했네요.

너무너무 읽고 싶긴 한데, 다른데 신경쓰다 보면 자꾸 책의 존재를

까먹습니다. -_-;

"제발 자주좀 펼치자." 라고 외치며.

끝 내용이 궁금해서 "6권"을 넘겨버리기 전에...

오늘 몇시간 동안 프로젝트 공유를 위해!

호스팅을 살펴봤습니다.

알고만 있던 수준에서 한 참 벗어난 것들이 많았던지라 솔직히 놀랐습니다.

근데 아쉬운건 얼마 전까지만 해도 제공 되었던 훌륭한 서비스들!

어떤 사유에 의해서인지 모두 유료화 된 것은 참으로 아쉽더군요.
(아마도 수익 문제겠죠....)

이런 것들을 보면 공부하는 사람들을 위해!

사업체들의 유료화는 더욱 구체적으로 갖춰져야 한다고 생각합니다.

사업체는 그 돈을 낭비라 보지 말고, 사업체의 사용으로 인해 발생하는

수익이 안정되면 업체들은 제공하는 무료 서비스를 보다 확대할테고
(망상일수도 있다는건 알고있습니다.!) 

그 훌륭한 서비스들! 을 적극적으로 활용하고 성장하는 이들이 미래에

자사의 인재들이 될 수 있음을 믿어줘야 하지 않을까요?
(사장님들 제발 무료만 끌여다 서비스 하려는 생각은 버리셔야할 세상이 아닐까요-_-)

물론! 이용만 하고 양심없이 토끼는 동물들이 먼저 각성하고 사람이 되야 할 것 입니다.

상부상조 하는 세상.

참 아름답지 않나요^^?!