벤처를 다니다보면, 일자리 제의가 여기저기서 들어옵니다. 대부분, 돈을 더 줄테니 옮길 생각이 있냐는 것입니다. 만일 이런 삶을 동경하고 있다면, 벤처세계로 나오시길 추천드립니다. 하지만, 막상 사람을 만나보면 달랑 사업계획서 한 부만 들고 있는 경우가 많습니다. 어떤 경우는 사업계획서 없이 서비스기획서만 가지고 있습니다. 난감하죠. 아무튼, 이들은 간절히 개발자를 구합니다. 좋은 개발자 한 명을 만나면, 자신의 꿈을 몽땅 이루어줄 수 있을 것이라는 희망을 가지고서 말이죠. 시장에서 흔히 볼 수 있는 풍경입니다. 오늘은 개발자가 가진 기획자에 대한 오해 몇 가지를 짚어보고자 합니다.
1. 일반적으로 기획자들은 개발자를 자신의 꿈을 이루어주는 소중한 사람으로 생각합니다.
처음에는 쩔쩔매고 어떻게 대화를 해야 할지 어려워합니다. 개발자분들은 그 사람들에게 자신이 얼마나 소중한 사람인지 알아야 합니다. 마음을 열고 다가가세요. 틱틱대면서 선을 긋고 서로 마음의 선을 넘지 않는다면, 같이 일하기는 힘들다고 보아야 합니다.
2. 서비스 기획자가 성공을 꿈꾸지만, 서비스를 '예측'하진 못합니다. '기대'하죠.
그렇기 때문에, 그들은 많은 것을 결정하지 못합니다. 구현되는 실제 부분을 모르기 때문이죠. 개발자가 다가가서 이야기하는 것만이 유일한 해법입니다. 의사들은 어려운 의학용어를 쓰지않고 쉬운 용어로 환자에게 설명을 합니다. 그러면 환자가 훨씬 더 선택하기 쉬워지죠. 개발자는 기획자에게 이렇게 대화할 수 있어야 합니다. 그렇지 않다면, 마스터 밑에서 인술을 더 연마한 뒤에 개인병원을 열기를 권해드립니다. 기획자가 명확히 이야기해주지 않았기 때문에 구현이 잘못된 것이라고 이야기하는 조직에 성공이라는 여신이 찾아올리 만무하지 않습니까?
3. 기획자는 자신이 구현하고자 하는 것을 명확히 알지 못합니다.
엔지니어가 아니기 때문이죠. 그래서, 스펙을 내어놓으라고 하면 올바른 스펙을 내지 못합니다. 스펙이란 것 자체가 기술자 용어이기 때문입니다. 용산에 가서 PC조립을 주문할 때 주문자가 모든 것을 알고 결정하는 경우는 거의 없습니다. 좋은 가게는 주인이 손님에게 친절히 설명을 하고, 주문자가 잘 주문할 수 있게 해줍니다.
4. 스펙은 개발자가 기획자와 인터뷰를 하면서 작성해야 합니다.
아니면, 개발자가 기획내용을 이해하고 혼자서 쓰는 것도 방법입니다. 용산에 있는 친구가 있으면, 그냥 알아서 조립해주는것처럼. 물론, 초보 개발자는 실수를 하니까 고급개발자가 해야 하겠죠.
5. 기획자는 기술을 모릅니다. 마치 아는 것처럼 보이지만, 모릅니다.
그렇게 접근해야 소통하기 쉽습니다. 내공이 쌓이다보니 이야기가 되는 것처럼 보여도 숨어있는 것들을 알기는 어렵습니다. 물론, 개발자가 사업을 하는 경우나 수퍼맨은 예외입니다. 안다고 생각하고 접근하면, 어느 순간부터 대화가 통하지 않을 겁니다. 모른다고 생각하고 이야기하시고, 나머지는 개발자가 챙겨서 해야 합니다.
6. 웹에이전시의 기획자들은 개발자와 소통하는 방식 중 하나를 터득하신 분들입니다.
개발자를 거칠게 다루는 방법을 전수받으신 분들도 있고, 섬세하게 다루도록 전수받으신 분들도 있습니다. SI 처럼 웹에이전시 기획자가 프로젝트를 책임지는 사람이라면, 조용히 따라가는게 맞겠지만, 벤처처럼 운명을 같이해야 한다면 불편함을 피드백하시고 더 좋은 협업방법을 찾으셔야 합니다.
기획자는 꿈을 꾸는 사람입니다. 그들이 꿈을 꿀 수 있도록 손을 가볍게 해주세요. 그게 개발자가 해야할 역할이 아닐까 생각됩니다.
덧붙여 SI에 관한 짧은 소견으로 이야기를 마무리할까 합니다. 1990년대 후반 대한민국 IT의 최첨단이 Window 95에 엑셀이던 시절, 최고로 인기 있던 개발자는 엑셀 매크로 개발자였습니다. 이 때 소위 '갑' 들은 전산을 모르는 그냥 일반 회사 업무를 하시던 분들이었습니다. 이 때 SI 회사들은 창조적 제안을 통해 고객사가 더 발전할 수 있도록 협업을 했었습니다.
하지만, 나쁜 SI개발사가 나오고 망가지는 일들이 나오기 시작하면서, 많은 회사가 전산실을 별도로 만들기 시작했습니다. 그래서 그 창조적 제안을 하는 작업을 내부 전산실의 역할로 두고 SI 업체들은 구현에만 집중했습니다. 이 때 용역방식이 건설 하청 구조로 고착화되어 갔지요. 그리고 안타깝게도 많은 개발자들이 이렇게 일하는 문화에 길들여지게 되었습니다. 물론 일을 시키는 '갑'도 이 문화에 익숙해지게 되었지요.
그래서 책임공방만 무수할 뿐, 본질에 쉽게 접근하지 못하고 이슈가 맴도는 경우가 허다한 것이 SI의 현장입니다. 어느덧 대한민국 IT시장에서 '창의력'과 '도전'이 사라져가게 됩니다. 당연히 이 구조로는 창의적인 서비스를 하기 힘듭니다. 이 구조에 길들여진 기획자와 개발자들은 스스로 알을 깨고 나와야 합니다. 이런 작업은 혼자서는 할 수 없죠.
'줄탁동기(啐啄同機)' 해야 합니다. 그 시작은 솔직하게 털어놓기가 아닐까 합니다. 시장에서 많이 깨져본 사람은, 비난을 두 시간을 들어도 털털 털고 일어납니다. 많은 개발자들이 그런 사람이 되었으면 좋겠습니다.
