“개발자들이 제 아이디어에 관심을 보이질 않아요.”
아직 한국에 있을 때 일입니다. 제 주변에는 스타트업을 하시는 분들도 많고 관심을 가지신 분들도 많습니다. 그래서 지인들과 연락을 주고받다 보면, 자연스럽게 관련된 이야기들이 화제에 오르곤 합니다.
그런데 그러다 보니, 묘한 점이 하나 있더군요. 상당히 많은 분들이 비슷한 호소를 하신다는 것이었습니다: “괜찮은 개발자 없어? 소개 좀 해줘.” “이 아이디어 정말 좋은데 개발자들이 관심을 안 가져. 개발자만 있으면 바로 창업하고 싶어.” 그러다 보면 결론이 이런 식으로 가곤 했습니다: “우리 일 좀 해주면 안돼? 잘 해줄께.”
왜 갑자기 IBM 이야기를 하다 말고 이 얘기를 하냐 하면은요, 제가 여기 와서 가장 먼저 알아차린 게 이것이었기 때문입니다. 왜 많은 창업자들이 개발자들을 설득하지 못하는가? 왜 그들의 아이디어는 구현의 문턱에도 가보지 못하고 좌초하는가? 결론부터 말씀드리자면, 개발자를 설득할 때 “내 아이디어가 훌륭한 이유”에 대해 구구절절이 설명하는 것은 별로 효과가 없습니다. 오히려 역효과를 볼 가능성도 제법 됩니다. 그 이유를 지금부터 설명드리겠습니다.
‘창조’란 어떻게 이루어지는 것일까
제가 지금 IBM에서 일을 하고 있습니다만, 사실 저는 이번이 두 번째 직장생활입니다. 제 전 직장은 게임회사였고, 저는 해외 서비스 클라이언트를 유지보수하는 일을 맡았었습니다. 그렇기 때문에, 이전에 있던 회사와 ibm은 모든 것이 다릅니다. 일단 코스닥 상장 기업과 초대형 다국적 기업이라는 점이 다릅니다. 온라인 게임을 만든다는 것과 기업용 제품을 연구한다는 점도 다릅니다. 가장 크게 다른 것은 커뮤니케이션의 방식입니다. 이전 직장에서 저는 비기술 직종 분들[footnote]마케터, 기획자, 그래픽 디자이너, QA 팀, 운영자 등등…[/footnote]과 주로 의견을 조율해 가면서 일을 해야 했습니다. 여기서는 그럴 일이 없습니다: 전부 다 엔지니어 뿐이라, 기술적인 이야기만 하면 되거든요.
하지만 이 모든 것에도 불구하고 변하지 않은 것이 있습니다: 저는 뭔가를 창조하는 일을 하고 있으며, 그 과정은 예상치 못했던 문제의 발생과 해결의 연속이라는 것입니다. 3년간의 게임 회사 생활을 돌이켜 보면, 기획팀 혹은 마케팅 팀이 제안한 아이디어가 그대로 구현된 적은, 단언컨대 단 한 번도 없었습니다: 수정, 수정, 수정, 그리고 또 수정의 연속이었지요. 기획안은 단순한데 실제로 해보니 기술적인 문제가 있어 일부 기능을 구현하지 못하기도 하고, 기대를 가지고 열심히 만든 부분이 재미가 없어서 묻히기도 했습니다. 초기 아이디어 단계에서 그리 중요하지 않다 생각해서 단순하게 설계를 해 놓은 부분이 추후 중요해지면서 대폭 수정을 해야 했던 적도 있었군요.
그 과정에서 제가 배운 건, 순수하게 존재하는 아이디어란 사실상 존재하지 않으며 구현 과정은 그 자체로 아이디어를 다듬어가는 과정이라는 것이었습니다. 솔직히 미국에 일하러 오면서 가장 먼저 품었던 생각은, “IBM에서는 어떤 식으로 창조를 할까?” 였습니다. 아까 말씀드린 대로 여러 가지가 다르긴 했습니다만 – 딱 한 가지는 변하지 않더군요. 돌발적인 문제의 발생과 해결의 연속. 이러한 과정의 반복을 통한 개선. 이것이 제가 예전에 했고 또 지금 하고 있는 일입니다.
내가 하는 말이 개발자 귀에는 어떻게 들릴까
많은 분들이 자신의 아이디어가 얼마나 훌륭한지, 이것이 왜 성공 가능성이 높은지를 개발자에게 열심히 설명하면서 설득을 하려 합니다. 하지만 위에서 설명했듯이, “내 가치 있는 아이디어를 구현시켜 줄 개발자를 찾습니다.”는 말은 처음부터 형용 모순입니다. 그 “가치 있는 아이디어”는 구현을 해 가면서 만들어지는 것이거든요. 그
도중에 나타나는 수많은 문제들을 해결해 가면서 말입니다. 역효과가 나기 시작하는 지점은 바로 여기서부터입니다. 개발자 귀에 이 말은 말을 하는 당사자에 대해 최소한 두 가지를 암시하는 것으로 들립니다. 첫째, 그는 창조라는 것을 별로 해 본 경험이 없다. 둘째, 그는 실제 구현과 개선 과정이 가지는 중요성을 과소 평가하고 있다.
비록 겉으로 내색을 하지는 않을지 모르겠지만, 이 순간부터 개발자는 당신을 의심스러운 사람으로 보기 시작합니다. 당연한 것이지만, 그 뒤부터는 무슨 소리를 해도 설득하기 힘들어지는 것은 당연한 일이구요. 그 아이디어가 얼마나 좋은지 구구절절 타당한 근거를 들어 설명했다구요? 좋은 대우를 약속했다구요? 그런 건 이미 귀에 안 들리죠.
이런 고민을 하시는 분들은 대부분 비기술 직종 출신 창업자 분들일 겁니다. 대부분 왜 이 기획안이 훌륭하고 실현 가능성이 높은지 프리젠테이션을 해가며 설명하는 데 아주 익숙한 분들이겠죠. 그렇기 때문에 이렇게 설득하는 것이 당연하다고 생각하고 계실 겁니다. 하지만 개발자들은 보고 경험하는 것도 다르고, 하고 있는 생각도 다르고, 생각하는 방식도 다릅니다. 당연히 듣는 방식도 다르구요. 그렇다면, 그들을 설득하는 방법도 조금은 달라질 필요가 있는 겁니다.
그럼, 대안은 없을까?
그렇다면, 방법은 없을까요? 솔직히 제가 가지고 있는 경험이 일천한 탓에 완벽한 답을 낼 수는 없을 겁니다. 하지만 제 주위에서 개발자 분들을 설득해서 창업에 성공하신 분들, 개발자들과 좋은 파트너쉽을 유지하고 계신 분들을 보면, 약간의 공통점은 있었습니다.
첫째, 당신이 설득하려는 개발자가 평소 어떤 관심을 가지고 있는지를 눈여겨보세요. 현실의 개발자는 게임 속 일꾼처럼 금속과 가스를 캐고, 건물만 만드는 사람이 아닙니다. 엄연히 평소에 좋아하고, 관심을 가지고 있는 분야가 있는 사람들이란 얘깁니다. 사실, 개발자들은 뭔가 만들고 싶은 게 있어서 개발 공부를 시작한 것이 대부분입니다. 능력 있는 개발자라면 더더욱 그렇죠. 예를 들어, 당신이 음악 관련 서비스를 함께 만들고 싶어한다면, 평소에 음악에 관심이 많은 개발자를 설득하는 게 좋습니다. 일단 이런 사람들에게는 이야기를 꺼내기 쉽습니다. 게다가 이런 사람들은 현재의 음악 관련 서비스들이 가진 한계와 대안에 대해 한번쯤은 생각해 본 사람들이기 때문에, 기획안에 더 큰 관심을 가질 가능성이 높습니다. 그만큼 당신은 개발자의 머릿속에 “함께 뭔가를 해 나갈 동료”로 포지셔닝될 가능성도 높구요.
둘째, 자주 만나서 의견을 나누세요. 함께 관심을 가진 사안에 대해 서로의 생각을 교환하고 의견을 나누는 과정을 반드시 가지라는 얘깁니다. 이 과정은 세 가지 이점이 있습니다. 첫째, 서로의 생각을 확인하고 자연스럽게 신뢰를 쌓는 계기가 됩니다. 둘째, 명확한 목표를 설정하고 창업에 나서기 전에 생각을 통일하고 비슷한 시각을 가질 수 있습니다. 셋째, 서로가 가진 명백한 오류들을 조기에 잡아낼 수 있습니다. 이 셋 중 어느 하나 스타트업에게 중요하지 않은 것이 없습니다.
셋째, 개발자가 당신을 위해 뭘 해줄까를 묻기 전에, 당신이 개발자를 위해 무엇을 해줄 수 있는지를 먼저 물으세요. 개발자가 당신의 말에 시큰둥한 이유는 바로 상대방이 자기 자신을 도구로 여긴다는 느낌을 받고 있기 때문입니다. 다른 사람의 도구 취급 받고싶은 사람은 어디에도 없습니다. 특히나 한국에서처럼 전통적으로 엔지니어가 천시받아 온 사회에서 태어나 자란 개발자에게 이런 생각을 조금이라도 비추는 것은, 말하자면 용의 아래턱을 쓰다듬는거나 다를 바가 없습니다. 요컨대 아이디어랍시고 기획안을 세일즈할 생각을 버리고, 개발을 도와줄 수 있는 동료로서의 자기 자신을 세일즈하는 게 더 효과적이라는 얘깁니다. 특히 앞서 설명한 과정같은 걸 생략하고 서류로 작성된 기획안을 불쑥 내밀며 설득하려 드는 순간, 개발자는 매우 불쾌하게 여길 가능성이 높습니다.
너무 복잡하다 생각하십니까? 그렇게 느끼신다면 창업 생각은 고이 접는 걸 권합니다. 눈에 안 보이는 수많은 소비자들을 설득하는 것은 눈앞의 개발자 한두 명을 설득하는 것보다 훨씬 어렵거든요.
위 포스트의 내용은 글쓴이 개인의 의견일 뿐이며, IBM의 공식 입장과는 상관이 없음을 밝힙니다.
* 참고