非 개발자를 위한 개발자 이해 매뉴얼

스크롤 주의...   ==========================================================================================   非 개발자 란 개발자가 아닌 사람, 즉 기획자-디자이너-운영자-코더-커뮤니티가드너-마케터 등등을 의미한다. 프로젝이라는게 먼옛날에는 프로그래머가 혼자서 뚝딱 만들던 시절도 있었고, 웹마스터가 HTML, 디자인을 혼자서 해서 웹페이지를 올리던 적이 있었지만 요즘에는 아무리 간단한 프로젝을 진행한다하더라도 최소한 개발자-디자이너-기획자가 있어야 한다. 포탈에서 어떤 업무를 하던지 개발자와 무관한 Job은 없으며, 개발자를 잘 이해 하지 못하면 업무가 잘 안될 수 밖에 없다.   개발자는 기계와 대화하는 사람이다 개발자들은 사람과 대화하는것 보다 기계와 대화하는것을 더 자연스럽게 느낀다. 그렇기 때문에 프로그래밍 '언어' 라고 이야기 하는것이다. 이러한 대화는 개발자가 기계에게  지시를 내리는 개념으로서 '명령어/명령문' 이라는 단어가 존재한다. 기계에 대한 명령을 내리는것 그것이 바로 코딩이다. 기계와 개발자의 대화는 철저하게 로직을 통해서 이루어지며, 자기가 지시를 내린대로 그대로 실행하며 답변을 하는 기계(PC)에게 편안함을 느낀다. 따라서 로직과 맞지도 않고 지시내린대로 실행도 안되는 '기획자'나 '디자이너'는 이들에게 대화가 안되는 불편한 존재이다.   개발은 와꾸가 맞아야 한다. 기획서나 디자인 시안은 항상 완벽하지 않은데다가 전체적으로 약간 이상해도 큰 문제가 일어나거나 하지 않는다. 그런데 개발은 약간의 로직이 안맞아도 아예 돌아가지 안거나 또는 무한 루프에 빠지거나 스펠링하나만 틀려도 에러가 난다. 개발은 아무리 간단하게 해도 와꾸가 다 맞아야 하는것이다. 예를 들면 초보기획자가 기획서를 들이댓을 때 철자가 틀린거를 일일이 지적해서 고치는 사람은 개발자이다. 개발자는 꼭 프로그래밍이 아니더라도 그런식으로 와꾸가 안 맞는거 자체가 불편하다. 초보 기획자 입장에서는 철자하나 틀렸다고 기획내용이 달라지는것도 아니고 한마디로 '대세에 지장 없는 데 딴지건다' 라고 생각하기 쉽다.   퍼포먼스보다 안정을 추구한다 자. 어떤 이벤트 프로모션을 기획했다고 가정해보자. 98%정도 괜찬고 2% 정도의 데이터 에러가 발생했을때 퍼포먼스가 150%가 나고, 2%의 에러를 잡으면 퍼포먼스가 100%난다라고 한다면 기획자(특히 마케터일때)는 까짓 2%정도는 버리고 150%의 퍼포먼스를 추구하게 된다. 그런데 개발자에게 들고 가면 일단 '구현이 안된다'고 이야기 한다. 2%의 에러가 나는것을 인정할 수가 없기 때문이다. 개발자는 0과1을 다루는 사람들이기 때문에 대개 기획자가 요구하는 '거의 다되는' 상태는 구현이 안된다라고 표현한다. 기획자에게 안된다는 의미는 '아예 안되는 0%' 의 개념이라면, 개발자에게 안된다는 개념은 '100% 가 아님' 이다.  개발자는 퍼포먼스보다 에러없음이 우선이다.   개발에 대해 모르면 무시하는 경향이 있다 기획자/디자이너들은 기본적인 성향이 다들 저잘난맛에 사는 인간들이지만..(나포함) 개발자들은 기본적으로 상하 하이라키가 존재하고, 실력있고 경험있는 윗 선배 개발자들을 존경한다. 대신 그런만큼 개발에 무지한 사람들을 무시하는 경향이 있다. 디자이너나 개발자가 코딩이나 스크립팅을 못하는것이 당연한 사실인데도 (그걸 뻔히 알면서도) 개발에 대해 잘 모르면 상대를 안한다. 심지어 개발자가 아니면 말도 잘 안하려는 개발자도 있다. (외모가 되는 여자 디자이너/ 여자 기획자는 예외) 따라서 개발을 직접 못하더라도 개발에 대해 알고 있어야 한다. '아니 그것도 몰라요?' <- 개발자가 초보기획자에게 수시로 날리는 멘트다.   계획의 변경에 민감하다. 아무리 작은것이라도.. 물론 아무도 계획을 변경 하는것을 반기지 않는다. 기획자 자체도 결코 반갑지 않지만 언제나 기획은 예정이며 미완성이고, 상황이 바뀌고 변경이 발생한다.어찌보면 이러한 변화는 웹자체의 속성이 그러하다고 봐야 한다. 일단 계획이 변경되면 기획자도 괴롭다. 기획서안도 수정해야하고 시나리오도 고쳐야하고, IA도 바꿔야 한다. 하지만 그게 다 다. 기획자는 일부수정인데 개발자는 전체 다시일 경우도 많다. 당연히 변경하는 것에 민감해 질 수 밖에 없다. 그래서 때떄로 변경이 불가하다고도 이야기 한다.(그런데 실제로 불가능한 경우를 본 적 별로 없다.)     그렇다면..어떻게 하면 개발자와 가까와지고 원활하게 소통할 수 있을까? 개발자만큼 언어를 잘 다룬다면 개발자를 하지 구태어 기획자를 할 필요도 없을 것이다. 그리고 기획자 중에 개발자 출신들도 많은데 그렇다고 기획자가 개발을 하면 절대 안된다. 그럴경우 개발자도 기획자도 아닌 어쩡쩡한 상태가 되기 쉽상이다. 기획자는 개발에서 쓰이는 외계어를 공부함으로서 개발자와 이야기 할 수 있는 자격이 생긴다고 봐도 좋다. 예를  몇가지 들면 초보 기획자가 반드시 알아야 할 용어들이 쿠키, 세션, 세션의 유지, 배치잡, 디비스키마, 아키텍쳐, 프레임웤, 오브젝트, 클라이언트-서버 구조, 모듈 등이 개념이 뭔지, 어떤 역할을 하는지 알고 있어야 한다. 그리고 이런 단어들을 가지고 자신이 기획한 기획을 개발자에게 설명할 수 있어야 한다. (아니면 예쁘든지. 예쁘면 개발자가 몇번은 친절하게 설명해준다.)   개발자들은 대부분 남자들이고.(여자개발자도 존재하긴 하지만 거의 없고, 있어도 성격이 남자나 다름없다.) 장비부분에 대해 매니아적인 기질들이 많아서 24인치 대형 델LCD 모니터를 듀얼로 쓴다든지. 20만원이 넘는 해피해킹키보드나 리얼포스 같은 고가 키보드도 많이 사용한다. 공통적으로 태블릿PC나 노트북들에 관심들이 많으므로 그들과 관심 및 취미를 공유하기 위해서는 음악이나 영화 이런것 보다는 최신 노트북에 대해 빠삭하게 알고 있는게 친해지는데 유리하다.   가장 베스트 방법은 스타일 좋은 예쁜 여자를 소개시켜 주는 것이다. 장담하는데 개발자 마음에 드는 여자를 소개시켜주면 안되는 기능은 없다. 어떻게 해서라도 반드시 구현시켜준다. 이 방법은 물론 양날의 칼과 같다. 개발자가 소개시켜준 여자에 너무 빠져들면 개발 퍼포먼스가 무지 떨어지는 리스크를 감수해야 한다.^^   이것 말고도 몇가지 더 있는데 생략하기로 하고, 이 포스트는 무척 주관적인 경험을 바탕으로 쓰여졌으며 위에 기술한 부분에 전혀 해당하지 않는 개발자들도 많다. 참고로 나같은 기획자하고 일하면 편하겠다고 생각하는 개발자도 있을지 모르겠는데, 본인은 상당히 근거를 가지고 쪼는 스타일의 기획자라 개발자들의 기피대상이다. ^^ 기획자와 개발자가 서로 잘 이해하며 사는 세상이 되기를 바라며...