본문 바로가기

원포인트 레슨

17. 양날의 검 ‘협업’


 몇일 전 한 분이 기발한 아이디어가 있는데 개발자 구하는 것이 너무 어렵다며 혹시 협업을 할 생각이 없느냐는 문의의 메일을 보내왔다. 하지만 메일 수신자도 여러 명 참조되어 있었고 단순히 이걸 만들면 무조건 대박이라는 식으로 설득을 하고 있었기 때문에 협업할 사람을 쉽게 구하기 어려울 것 같다는 생각이 들었다.

사실 요즘 필자의 주변만 봐도 자신은 좋은 아이디어가 있는데 개발을 할 줄 모르고 자본금이 없기 때문에 포기했다며 변명 아닌 변명을 하는 친구들이 여럿 있다. 그렇지만 정말 좋은 아이디어가 있고 정중히 문의를 한다면 비용 없이도 협업에 동참할 개발자들은 충분하다. 게다가 올해 초에 비해 스마트폰 개발자들도 많이 증가했기 때문에 협업을 하기엔 최적의 시기가 온 것 같다. 






협업의 장점과 단점 

협업의 최대 장점은 위험부담을 최소화 할 수 있다는 점이다. 아무리 간단한 아이디어라도 개발자와 디자이너를 고용하기 위해서는 최소 수 백만 원이 필요하다. 하지만 협업을 통하면 수익분배를 통해 인건비를 충당할 수 있기 때문에 거의 무자본으로도 앱 제작을 시도할 수 있다. 하지만 막상 협업을 해보면 결코 쉽지 않다는 것을 느낄 수 있다. 특히 경험이 없는 사람들이 모여 앱을 제작하는 경우 예상치 못한 문제와 분쟁이 발생할 확률이 매우 높다. 모두 동등한 위치에 있기 때문에 상대방의 의견을 쉽게 수용하기 어렵고 무임승차를 하려는 사람이 생겨나면 순식간에 팀의 사기가 저하될 위험도 있다. 이런 이유로 오늘은 효과적인 협업을 위해 검토해야할 몇 가지 사항들에 대해 살펴보고자 한다. 



1. 직접 만나 비밀보호서약을 하자

모르는 사람과 협업을 할 경우 자신의 아이디어를 설명하지 않고서는 적합한 사람을 구하기가 어렵다. 하지만 아이디어가 생명인 앱 시장에서 제품에 대한 세부적인 내용을 게시판이나 메일로 설명하는 것은 자살행위나 다름없다. 아이디어가 좋다면 글을 본 누군가가 먼저 만들어 버릴 확률이 높고 이런 경우 법적으로 보상받을 수 있는 방법은 전혀 없기 때문이다. 따라서 사람을 구할 때는 먼저 제품에 필요한 기술적인 요소나 디자인의 형태 등만 간단히 설명한 뒤 일차적으로 사람을 선별해야 한다. 

물론 개발자나 디자이너의 업무범위는 굉장히 다양하기 때문에 기존에 만든 제품이나 포트폴리오를 면밀히 검토하면서 내가 기획한 앱을 만들기에 적합한 사람인지 확인해야 한다. 적합한 사람을 찾았다면 그 다음에는 직접 만나서 아이디어에 대한 세부적인 내용을 공유해야 한다. 하지만 이에 앞서 꼭 해야 할 일이 있다. 바로 아이디어 누출을 막기 위한 비밀보호서약서를 작성하는 것이다. 보통 계약서는 아이디어의 누출에 대한 형사상의 책임을 진다는 내용으로 작성하게 되는데 별거 아닌 것 같지만 그 효과는 확실하니 아이디어 자체로 승부하는 앱인 경우에는 이 과정을 꼭 거치도록 하자. 

서약서에 사인을 받은 후에는 앱에 대한 세부적인 내용을 공유하게 되는데 이때 역시 단순히 언제까지 무엇을 개발해 달라고만 말하기 보다는 앱에 대해 서로간의 생각에 대해 충분한 대화를 나누면서 서로간의 머릿속에 있는 생각을 일치시키는 것이 중요하다. 서로 간에 제작할 앱에 대한 관심과 신뢰가 있어야 그만큼 성공 할 가능성도 높고 향후 의사소통도 원활하게 진행되기 때문이다. 



2. 수익배분은 신중히 결정하자

협업에 있어 최대의 적은 무임승차다. 특히 경험이 없는 사람들끼리 모여 단지 초반의 열정만으로 프로젝트를 시작하는 경우에 많이 발생하는데, 한 번 무임승차가 발생하면 순식간에 팀원전체의 사기가 꺾일 수 있기 때문에 각별한 주의가 필요하다. 

맨 처음 도전을 시작하면 모두 들뜬 마음에 열의가 넘친다. 하지만 시간이 지나면 끝까지 주도적으로 열정적인 사람이 있는 반면 대박나면 나도 한 몫을 챙겨야지 하는 속셈으로 대충대충 적당히 참여를 하는 사람도 나타날 수 있다. 사실 경험이 있는 전문가 집단의 협업이라면 무임승차가 발생할 확률은 극히 적다. 업계 경험에 비추어 해당 앱을 제작하는데 어떤 역할을 하는 사람이 많은 비중을 차지하는지 비슷한 기준을 가지고 있기 때문이다. 예를 들어 아이디어 자체로 승부를 보는 간단한 앱이라면 기획자가 많은 지분을 갖게 되고 기술적으로 어려운 개발능력이 필요한 앱이라면 개발자 몫의 비중이 커지게 된다. 

하지만 경험이 부족한 사람들이 모여 시작한 프로젝트라면 초반에 수익분배방식을 정하는 것이 프로젝트 성공의 위험요소로 작용할 수 있다. 필자는 주변에서 구체적인 프로젝트가 진행이 되기도 전에 무조건 참여한 사람 수에 대해 n등분으로 지분을 나누는 경우를 몇 번 봤는데 대부분 프로젝트가 끝나기도 전에 서로 불편한 관계로 해체되는 경우가 많았다. 이유는 간단하다. 처음엔 모두 열정적으로 자신의 역할을 맡아 수행할 줄 알았던 사람들 중에 대충 묻어가기 식의 팀원이 생기게 되는데 이미 초반에 수익을 나누는 기준을 n등분으로 정했기 때문에 다른 팀원들이 이로 인해 열정에 상처를 받은 것이다. 이렇게 비전문가들이 모인 경우 수익배분비율을 초반에 결정해버리면 끝까지 목표를 달성하기가 쉽지않다. 

그래서 차라리 일정기간은 지분에 대해 결정을 하지 않고 다 같이 열심히 일한 다음 어느 정도 프로젝트에서 공헌한 사람이 명확해지기 시작할 무렵 대표자를 뽑고 그에게 권한을 위임해 지분을 정하는 것이 보다 효과적이다. 만일 약간의 의견차이가 발생한다 하더라도 서로 간의 해온 역할들을 알기 때문에 의견을 조율해 납득할만한 수준에서 지분을 분배하기도 수월하다. 만약 앱 제작이 처음이고 서로에게 맡겨진 임무가 명확하지 않은 상황이라면 처음부터 지분배분율을 고정하고 시작하지 말고 신중한 계획을 세우자. 



3. 주기적으로 진행사항을 공유하자 

처음 협업을 위한 사람을 구하기 위해서는 직접 만나 충분한 대화를 통해 앱에 대한 의견을 공유하라고 했다. 이는 그 사람의 성실도와 능력을 확인하는 것뿐만 아니라 프로젝트에 대해 서로 간의 신뢰를 쌓고 각자의 의견을 충분히 공유시키기 위함이다. 그런데 각자 맡은 업무와 마감 일자가 정해진 뒤에도 주기적인 의사소통은 꼭 필요하다. 

보통 공통된 공간에서 협업을 하는 경우는 드물다. 때문에 '서로 맡은 일은 잘 하겠지'라는 막연한 생각으로 일을 진행하다보면 마감일자가 다가와서야 생각했던 것과 전혀 다른 형태의 결과물을 받는 경우가 생기게 된다. 때문에 최소 일주일에 두 번 정도는 직접 만나 진행사항을 파악하는 것이 좋다. 이런 과정이 다소 번거롭고 업무에 방해된다고 여길 수도 있겠지만 아무 연락 없다가 마감일에 원치 않은 결과를 보게 될 가능성을 생각한다면 이처럼해해주기적으로 진행과정을 직접 파악하며 의사소통하는 것은 협업의 필수라고 할 수 있다. 



성공적인 협업은 ‘신뢰’에서 시작된다 

앱 제작은 누구나 할 수 있다. 하지만 기획, 개발, 디자인 삼박자를 혼자서 해결하지 않는 한 비용은 발생하게 된다. 그리고 이런 비용이 부담스러운 사람들에게 분명 협업은 매력적인 수단이다. 하지만 양날의 검처럼 협업의 비용절감이란 장점의 이면에는 다양한 위험들이 존재한다. 성공적인 협업을 하고 싶은가? 그러기 위해서는 자신의 관점을 잠시 내려놓고 상대방의 관점에서 프로젝트를 바라보려고 노력해보자. 결국 성공적인 협업을 위해 가장 중요한 것은 제품의 성공에 대한 믿음을 공유하고 단단한 신뢰를 쌓는 것이며, 이를 위해서는 나와 상대방과의 차이를 인정하는 것부터 선행돼야 하기 때문이다.