디자인이란?
구상·계획·설계·의장(意匠) 등 여러 가지 의미를 포함하며, 이것들을 종합한 뜻으로 또는 이들 중 어느 하나에 역점을 둔 것으로 쓰이는 용어. 산업혁명으로 물건제작에 변화를 맞은 근대 이후의 생산방식에서는 단순히 물건이 만들어진다는 사실 이상으로, 생산제도를 정비하고 또는 생산물이 사회 속에서 차지하게 될 위치를 미리 고려하는 등, 방향설정의 단계가 중요하게 되었다. 디자인이라는 말 속에 포함되어 있는 구상과 계획이란 근대적인 생산방식에서는 불가결한 전제적인 사항에 대한 사고를 가리킨다. 그러나 실제의 단계에 들어가서 한층 더 구체적으로 설계되고 제품화되는 과정에서는 정합성(整合性)과 함께 외관상의 아름다움이 문제가 되는데, 이러한 관점에서 디자인의 좋고 나쁨이 논해진다. 디자인이라는 말은 다의성을 지닌 채 그러한 것들을 총괄하는 용어로 쓰인다. (yahoo 백과사전 인용)
디자인이란 단어는 뜻이 굉장히 복잡하다.. 추상적은 의미가 많아 내 스스로 정의하기가 힘들었다.. 사실 내 마음대로 정의하고 나서도 써놓고 나면 찝찝한 마음이 생기기에.. 똑똑하신 분들께서 정의 해놓은 글을 그대로 복사하였다.
디자인은 말 그대로 굉장히 폭 넓은 의미를 가지고 있다. 그래서 Designer, Graphic Designer, Hair Designer 등 Designer가 들어간 직업 종류도 많다..난 Designer가 들어간 직업을 가지고 있지 않지만 Design이란 단어를 매우 좋아한다. 다른 분들도 그러실지 모르시겠지만 나 같은 경우는 Design을 다 한경우에 머리속에서 시뮬레이션을 하고 나면 마치 만들고 난듯한 느낌을 가지게 될때가 있다.
디자인은 이 만큼 넓은 범주의 뜻과 중요한 역활을 가지고 있다. 프로그램을 개발하는 데에 있어서 기반은 디자인이라 생각된다. 디자인 없이 훌룡한 프로그램은 존재하기 힘들며(존재하지 않는다! 라고 쓰고 싶었지만..없이도 잘하는 우리나라의 프로그래머들이 계셔서..) 나중에는 점점 깨진 유리창이 번지게 된다. 디자인을 기반으로 프로그램을 개발하다보면 점점 더 디자인적인 문제점을 찾게 된다. (디자인 찬양론자..)
이제는 Design을 하는 방법에 대해서 정리를 해볼까 한다. 여기에서 내가 말하고자 하는 Design은 소프트웨어 디자인이다. 그러나 디자인이라는 단어가 말해주는 포괄적인 내용으로 정리를 해보기 위해서 위에 내용을 적게 돼었다.
디자인은 왜 하는 것인가? 사실 우리나라 프로그래머는 이러한 의문점을 가질 수 있을 것이다. 개발 당시에는 개발 속도와 뭔가 하지 않는 듯한 느낌을 가질 수 있기 때문인것 같다. 나 역시 그런 경험을 하였고 디자인과 실제로 프로그래밍을 하면서 디자인이 점점 바뀌어 가는 것도 역시 느끼게 되었다. 100% 매칭이 된다면 이 분은 굉장히 훌룡한 디자이너이며 내가 사장이라면 이 분의 실력을 높게 평가해 연봉을 최대한 드리려고 노력할 것이다. 하지만 언제나 사람은 뭔가 배워가는 그러한 과정이 필요하다. 처음부터 잘 할 수도 처음부터 슈퍼맨일 수는 없는 것이다. 그런면에서 난 참 인간적이다..;
내가 디자인대로 그대로 만들어본적은 거의 없는 것 같다. 항상 프로그래밍을 하다보면 디자인이 바뀌는 경우가 있다. 그 이유는 아마도 프로그래밍을 할때 프로그래밍 언어의 특성이나 이러한 문제인데, 완벽하게 매칭되는 디자인을 뽑으려면 시스템과 프로그래밍언어의 특성등을 잘 파악해야 할 것이다. 이 부분도 Wrapper와 Adaptor를 쓰면 해결할 수 있겠지만, 간혹 플랫폼 자체가 너무 특이한 경우가 있다. 결국엔 언어에 대한 숙지와 프로그래밍의 경험 그리고 감각등이 필요한 직업이다.
이제 디자인 중심적인 프로그래밍의 장점과 단점을 비교해볼까 한다. 장점은 대규모의 프로젝트의 경우 디자인 중심적인 프로그램 개발론이 아닌 머리에서 생각해서 하는 경우에는 메인 개발자의 영향을 매우 많이 받게 된다. 메인 개발자가 없이는 프로젝트가 진행이 되지 않고 사람들은 전체적인 구조를 머리속에 꿰고 있어야 하기 때문에 프로젝트 자체에 투입됐을 경우에 그 사람의 효율을 이끌어 내는데 상당히 오랜 시간이 걸린다. 이런 일이 생기는 이유는 디자인을 먼저 체계적으로 하는 경우에는 모듈을 잘 분리해서 하나하나씩 사람들에게 처리하게 할 수 있기 때문에 스케쥴 관리와 새로온 사람이 있더라 하더라도 그 하나의 모듈에 대한 이해도로도 진행하는데 지장이 없으므로, 체계적인 관리가 가능하다. 하지만 머리에서 처리되서 프로젝트를 진행 하는 경우, 전체적인 흐름을 파악하지 않으면 작업 자체를 맡기가 쉽지 않기 때문에 새로운 인력이 왔을 때 효율적인 관리가 쉽지가 않게 된다. 어느정도 환경에 익숙해질때까지의 시간이 필요하기 때문이다.(물론 실력있는 새로운 인력은 소스코드의 문제점과 필요 없는 부분등을 잘 찾아낸다. 이런 것을 봤을 때 언제나 새로운 시점에서 디자인을 바라보고 코드를 바라보는게 필요한 것 같다.)
글 자체가 너무 딱딱해서 그런지, 내가 쓰면서도 기억이 안나는 내용이 있다; 분명 글에 문제가 있을 것이라 생각되어진다. 그리고 글에 가독성이 너무 떨어지는 것 같다..어떻게 정리하면 좋을지..댓글을 달아주시면 감사하겠습니다..잘못된 부분도 코멘트를!
