한 달여를 준비해왔던 스타트업을 위한 웹 개발 기초를 오늘 진행했다. 결과는 경기장 밖에서는 실패, 경기장 안에서는 성공.

우선 좋은 것부터 이야기하자면, 강의 주제의 목표를 제대로 달성했다. 개발에 대한 경험이 전혀 없는 사람이 하루 만에 기본적인 기능이 탑재된 웹사이트를 개발해내는 것. 실제로 프로그래밍 언어란 게 뭔지 모르는 수강생도 있었지만, 훌륭하게 예제를 소화해냈다. 개발자가 아니라도 하루 만에 웹 개발의 기초를 배우는 것은 가능하다.

강의 평가도 꽤 좋았다. 점수는 다 5점 척도. 주관식은 프라이버시 문제상 공개하지 않음.

• 이 강의가 수강한 목적에 도움이 되었나요? => 4.5
• 이 강의 이후 심화과정도 수강할 생각이 있나요? => 4.5
• 교육과정의 가격에 대해서 어떻게 생각하십니까? => 3.5 (1:비싸다, 5:싸다)
• 스타트업을 하고 싶어하는 지인이나 동료들에게 이 강의를 추천하실 의향이 있나요? => 5

우려했던 바와 달리 결제를 한 사람들은 22만원이라는 가격을 비싸게 느끼지 않았다. 아예 무료라면 모를까, 돈을 내고 배운다면 이 정도는 내야지 같은 느낌이 아니었을까 짐작한다. 물론 나도 프로그래밍 해본 적이 없는 사람이 하루 만에 여기까지 할 수 있는데 비싸다고 생각하진 않는다.

NPS를 의도한 질문인 추천의향은 전원 5점을 줬는데, 사실 여기에는 약간의 편향이 있어서 곧이 곧대로 받아들이면 안될 것 같다. 강의 인원이 소수다보니 약간 사적인 이야기도 나누었고, 그러다보니 어느 정도 인간 관계가 형성이 되서 심리적으로 더 좋게 평가했을 가능성이 있다. 어쨋든 정말로 추천하면 참 좋겠다.

잘된 부분들을 보면, 일단 강의 교재 준비는 거의 완벽에 가까웠다. 초보자가 이해할 수 있는 스텝의 크기를 정확하게 분석했다. 이건 내가 자랑하는 능력 중 하나이며, baby step에서 배운 것이다. 고수는 일의 크기를 자유자재로 나눌 수 있어야 한다. 스피드를 내야 할 때 big step을 밟으면서도 필요할 때는 언제든지 baby step으로 돌아갈 수 있는 것. 이게 가능하기 때문에 초보자에게도 일을 시킬 수 있는 것이지. 물론 교재와 소스코드는 tutorial은 아니다. 혼자서 보고 따라하는 게 아니라 강의에서 활용하는 것을 전제로 만들었기 때문에 이것만 보고 초보자가 따라할 수는 없다. 그래서 자료 보고 강의는 안 올까 하는 걱정을 하지 않고 강의자료와 소스코드를 모두 미리 공개한 것이다. 여기까지는 계산대로였다.

에러 메세지를 보고 다음 스텝을 결정하게 만드는 시나리오도 꽤 적중했다. 단계를 밟아나갈 때마다 에러 메세지가 바뀌는데, 에러 메세지가 나쁜 것이 아니라 정보를 담고 있으며, 다음 할 일을 가르쳐준다는 점을 인식시키는데 성공했고, 두어 번은 수강생이 스스로 다음 할 일을 짚어내기까지 했다. Django tutorial에서는 가르쳐주지 않는 것이지.

반복 요소도 적당히 효과를 봤다. 짧은 시간의 강의를 하다보면 이것저것 소개만 하다보니 강의 중에는 복습이 안되기 쉬운데, 앞에서 배운 내용을 뒤에서 다시 반복할 수 있는 기회들을 꾸준히 만들어서 처음엔 계속 실수하던 것을 나중에는 스스로 해결하기도 했다.

계산을 빗나간 부분은 수강생들의 진도가 저마다 다르다는 것이다. 어떤 사람은 따라하기도 바쁜데, 어떤 사람은 지루할 수 있다. 게다가 수강생들의 진도를 눈으로 확인하기가 어려워서 일일이 물어봐야 하다보니 더 어려웠다. 그나마 수강생이 적어서 오히려 다행이었달까. 10명 다 찼으면 못했을지도 모르겠다. 이 부분은 대책이 필요하다.

또 하나 몰랐던 사실은, 강의를 하면 목이 아프다는 것이다. 원래는 이 강좌를 시발점으로 일주일 짜리 강좌도 만들려고 했는데, 내가 일주일 연속으로 강의를 할 수 있을 것 같진 않다. 심각하게 고민해야 할 문제. 차크라 소모를 생각하면 한 달에 2회가 한계인 듯.

아뭏든, 여기까지만 보면 대성공이지만, 큰 그림으로 보면 대실패다. 왜냐면, 10명 정원인 강의에 2명 밖에 안 왔기 때문이다. ㅠㅠ 참석한 사람은 사전에 결제한 두 명 뿐이고, 대기자에 있던 사람들은 끝끝내 결제도 하지 않았고 참석도 하지 않았다. 그래서 온오프믹스의 유료 모임에 미결제 대기자로 있는 건 참석 안함이라고 봐도 될 것 같다. 그래서 두 명 밖에 안되는데 모임 장소는 더 작은 곳으로 바꾸지 못해서 모임 장소 비용과 온오프믹스 수수료로 비용이 나가고 나면 남는 돈은 오늘 하루치의 인건비도 안된다. 강의 준비는 거의 풀타임 3일치인데...

그래서 사실 에브리클래스처럼 수강 정원이 차야 강의를 하는 방식이 가능해야 할 것 같다. 하지만, 이건 사실 반대로 생각하면 실패에 대한 비용을 줄이는 것이지 성공을 위한 방법은 아니다. 더 좋은 것은 기간 내에 수강 정원이 차고, 다 참석하게 하는 것이다. 이것을 못했던 것이 실패의 핵심이다.

정원이 다 차지 않은 이유는 여러 가지로 생각해볼 수 있겠다. 우선 핵심 가설, 프로그래밍 경험이 없지만 배워서라도 자기 아이디어를 실현해보고 싶은 사람이 많다는 것이 틀렸을 수 있다. 그것보다는 개발 할 줄 아는 사람을 구하는 게 더 쉽다고 생각할 수 있을 듯. 만약 이 가설이 틀렸다면 이 강의는 여기서 스톱해야 한다.

핵심 가설은 여전히 유효하지만 홍보 부족일 가능성도 크다. 온오프믹스 대기자 뿐 아니라 개인적으로 컨택해온 대기 수요도 꽤 많았다는 점을 생각해보면 홍보가 다섯 배 더 잘되었으면 정원을 채웠을 거라고 생각해볼 수 있다. 내 SNS만 홍보한 것은 너무 부족했을 가능성이 높다. 다만, 내가 SNS를 넘어선 효과적인(그러면서 돈 안드는) 홍보 방법을 모른다는 문제는 극복해야 할 것이다.

핵심 가설이 맞고, 홍보도 많이 되었지만 하루 만에 비 개발자가 개발을 배우는 게 가능하지 않다고 생각하는 사람이 많았을 수도 있다. 홍보의 양과는 별개로 홍보의 설득력이 부족했을 가능성이다. 이건 지난 번 시범 강의와 이번 강의 평가를 공개하면 많이 보완할 수 있다.

평일 강의라는 점도 제약일 수 있다. 몇몇 지인과 선화가 이 문제를 언급했다. 이건 토요일 강의를 해보면 알겠지.

그런데 문제가 하나 있다. 원래 이 강의를 내가 기획한 것은 안정적인 수입원을 찾기 위한 것이다. 그러니까 내가 지금 2년 후에 대박 나는 것, 내일 10원 벌기 시작할 수 있는 것, 이번 달에 수백만원 벌 수 있는 것, 이렇게 세 가지로 나눠서 분산 투자를 하고 있는데, 세번째 카테고리에 속했던 교육 사업이 지금 상태로 봐서는 두번째 카테고리에 더 가까운 일이 되었다는 것이다. 그럼 세번째 카테고리가 비는 문제도 생길 뿐더러, 두번째 카테고리의 다른 아이템과의 경쟁 문제도 생긴다. 말하자면, 이 교육사업은 안정적인 수입원이 아니라 스타트업인 셈이다. 사실 다른 pros & cons는 다 예상 범위에서 크게 벗어나지 않았는데, 이 점 하나만큼은 오늘 해보고서야 깨달은 것이다. 생각해보면 전에도 깨달을 수 있었던 문제인데, 역시 난 내 손으로 해봐야 되는 타입인 듯.

그래서 두 가지 방향으로 생각 중이다. 일단은 2차 강의는 한 번 더 해봐야 한다. 핵심 가설 이외의 문제점들은 일단 다 극복 가능해보이므로 거기까지는 시도해본다. 두번째는 방향을 살짝 틀어서 동영상 강의로 제작하고 vod나 유튜브 광고 수입을 노려보는 것이다. 여기까지 해보고 나면 아마 접을지 말지 시원하게 결정할 수 있지 않을까 싶다.

그러고보면 예제 소스를 먼저 만들어 본 것, SNS에서 의향 조사를 해본 것, 시범 강의를 열어본 것 등등 모두 린 스타트업 방식으로 해왔는데, 그래놓고도 이게 스타트업이 아니라 안정적인 수입원이라고 생각했다는 게 참 멍청했던 것 같다;; 당연히 처음부터 스타트업으로 분류될 일인 것을.

어쨋든 이번 주 목표 중에 제일 중요한 것은 제대로 달성했다. 슬프지만 뿌듯한 하루.

블로그 / 스타트업 / 비즈니스

플랫폼 전략이란 일반적인 서비스를 만들어내는 것으로 만족하는 것이 아니라, 다른 서비스가 올라탈 수 있는 플랫폼을 만들자는 전략이다. 이 플랫폼이라는 키워드는 Web 2.0이 흥할 때 구글, 이베이 등의 성공 요인으로 플랫폼이 떠오르면서 화두가 되었다. 그래서 이후에 플랫폼을 지향하는 회사가 많아졌고, 대표적으로 오픈마루는 출범 초기부터 플랫폼 전략을 핵심으로 내세웠다.

그리고, 오픈마루는 실패했고, 실패의 주요 원인으로 플랫폼 전략이 지목되곤 한다.

이에 대해 오픈마루의 리더였던 김범준님의 분석글도 커뮤니티에 회자된 바 있다.

• 플랫폼을 하기 전에 살아남을 궁리부터...
• 플랫폼 - 진화 그리고 blueprint와 recipe

일단 난 위의 두 글에 90% 이상 동의하고, 오픈마루의 플랫폼 전략이 틀렸다는 점도 동의한다. 하지만 본론에 앞서 잠깐 이야기하고 싶은 것은, 플랫폼 전략이 틀렸지만 그것 때문에 오픈마루가 실패한 것은 아니라고 생각한다. 초기 전략 한 번 잘못 세웠다고 조직이 실패하는 것은 아니다. 전략의 오류를 깨닫고 수정하면 된다. 굳이 실패의 요인을 말하라면 틀린 전략을 중간에 깨닫고 수정할 만한 역량이 안되었다는 것이지.

아뭏든, 플랫폼 전략은 틀렸다. 하지만, 난 오픈마루의 플랫폼 지향성 자체가 틀렸다고는 생각하지 않는다. 오히려 플랫폼을 지향하는 것은 바람직하고 권장해야할 일이라고 생각한다. 그럼 플랫폼 전략과 플랫폼 지향은 뭐가 다른데?

그 전에 플랫폼의 정의를 명확하게 해야 할 것 같다. 플랫폼이라는 말이 코에 걸면 코걸이, 귀에 걸면 귀걸이가 되는데, 적어도 당시 Web 2.0의 컨텍스트에서 플랫폼이 뜻하는 바는 명확했다. 이를테면, 지마켓과 이베이를 비교할 수 있겠다. 이베이가 플랫폼이 되었다는 것에는 이의를 제기할 사람이 많지 않을 것이다. 그럼 지마켓은 어떤가? 플랫폼을 수많은 사업자가 참여할 수 있는 공간으로 정의한다면 지마켓도 플랫폼이다. 그리고, 불행히도 국내에서 플랫폼을 이야기하는 사람 중에는 지마켓 같은 모델을 말하면서 플랫폼이라고 부르는 경우가 많다.

물론, 플랫폼을 정의하기에 따라 그것도 플랫폼인 건 맞다. 근데, 그런 광의의 플랫폼은 전략으로서의 가치가 없다. 그냥 버즈워드가 될 뿐이지. 의미 있는 전략 키워드로서의 플랫폼은 좀더 명확해야 한다. 단순히 사업자가 참여할 수 있는 것으로는 부족하다.

내가 생각하는 플랫폼의 좀더 좋은 정의는 "다른 서비스를 개발해서 올려놓을 수 있는 서비스"다. 지마켓 위에도 수많은 비즈니스가 일어나고, 지마켓만 이용하는 회사도 많이 생겨났지만, 지마켓 위에 올라타는 서비스는 없다. 하지만 이베이 위에 올라타는 서비스는 엄청나게 많고, 한 때 이베이 매출의 80%가 이베이 바깥에서 일어났다고까지 한다. 이 차이를 만드는 것은 당연히 API다. API가 없으면서 플랫폼이라고 말한다면 뭐 틀린 말은 아니지만 별로 의미는 없는 말이 된다.

카카오톡도 게임을 런칭하기 전까지는 플랫폼이라고 할 수 없었다. 그냥 아주 성공적인 서비스였을 뿐이다. 하지만 카톡이 API를 게임 회사들에게 제공하기 시작하면서 게임이 올라탈 수 있는 플랫폼이 된 것이다. 그러니까, API는 플랫폼의 필수 조건이다.

그럼 API만 있으면 플랫폼이 될 수 있는가? 이것만으로는 앞서 지마켓과 같은 말을 해줄 수 밖에 없다. 플랫폼은 맞는데 별 의미는 없다. 이게 바로 오픈마루의 전략 실패 포인트이고, 아마 플랫폼을 하기 전에 살아남을 궁리부터...의 이야기도 같은 이야기인 듯 하다.

내가 스프링노트를 개발하면서 가졌던 의문도 비슷했다. 스프링노트 API를 왜 처음부터 오픈하려고 하지? 스프링노트 유저도 얼마 안되는데 그 API가 대체 무슨 소용일까? 오픈마루는 플랫폼 전략일 내세웠기 때문에 오픈 API를 몹시 중시했고, 초기부터 많은 시간을 투자했다. 하지만, 성공하지 못한 서비스의 API는 개발자들에게 가치가 없다. 성공해야 비로소 그 API가 가치를 가지기 시작하는 것이다. 이베이가 지금과 같은 수준의 API를 사용자 1천명일 때 갖춘다면 그 때부터 이베이는 플랫폼 역할을 할 수 있었을까? 그럴 리가 없겠지.

그래서 플랫폼의 성립 조건 두번째는, 성공한 서비스가 되는 것이다. 그런데, 성공한 서비스를 만드는 것 자체가 스타트업의 본질이다. 그러니까 스타트업이 플랫폼 전략을 한다는 것은 일종의 동어반복인 셈이다. 우리는 성공하기 위해 성공한 서비스를 만들 거야. (응?)

그런데, 이런 반론을 해볼 수 있겠다. 그럼 성공하기만 하면 어떤 서비스든 플랫폼이 될 수 있는가? 어떤이라는 말이 워낙 광범위하기 때문에 단적으로 yes라고 말하긴 어렵지만, 대체로 yes라는 것이 내 판단이다. 이를테면, 플리커는 단순히 사진을 찍어서 올리는 서비스인데 API를 통해서 플랫폼이 될 수 있었다. (하지만 "성공한 서비스"라는 조건이 약해져서 망해가고 있지) 포스퀘어는 뭐 범용성이 있는 서비스라서 플랫폼이 된 것인가? 유튜브는? 닭이 먼저냐 달걀이 먼저냐의 문제다. 얘네들이 플랫폼이 되고 나니까 마치 범용적인 성격이 있었던 것 같은 착각이 드는 것 뿐이지, 원래 이들 서비스는 모두 고도로 집중된 타겟을 가진 서비스였다. 반례를 생각해본다면 좀더 유익하다. 성공했는데도 불구하고 플랫폼이 될 수 없는 서비스가 존재하는가? 이를테면 소셜 커머스는 성공했는데 API만 까면 플랫폼이 될 수 있는가? 어려운 문제지만 가능하다고 생각한다. 그래서 난 티몬에 있을 때 API를 오픈하면 경쟁사와는 다른 각도로 앞서갈 수 있을 것이라고 생각했고, 일부분 추진하기도 했었다. 물론 이건 확정적으로 이야기할 수는 없다. 대체로 그렇다 정도의 주장을 할 수 있을 뿐이지.

아뭏든, 플랫폼의 성립조건은 다음 두 가지다.

• 성공한 서비스가 될 것
• API를 제공할 것

 편하게 한 마디로 요약하면, 성공한 서비스의 API를 제공하는 것이다. 굳이 오픈 API라고까지는 말하지 않겠다. 카톡은 오픈하지 않고도 성공했잖아. 오픈이냐 아니냐는 비즈니스 모델을 어떻게 접근하느냐의 차이이기 때문에 플랫폼이냐 아니냐에서 크게 중요한 것은 아니다.

이것을 이해한다면, 플랫폼을 만들고 싶을 때 어떤 전략을 취해야 하는가를 알 수 있다. 플랫폼을 만들고 싶으니까 뭔가 범용성이 있는 서비스를 설계한다? 땡! 오픈마루처럼 처음부터 API를 오픈하는데 시간을 투자한다? 땡! 일단 닥치고 성공한 서비스를 만드는데 집중하는 것, 그리고 성공하고 나면 열린 마음으로 API를 오픈하는 것. 이게 내가 생각하는 플랫폼에 대한 답이다.

어쨋든 플랫폼을 지향하는 것이 나쁠 이유는 없다. 그냥 성공한 서비스에 그칠 수 있었던 서비스들이 API를 오픈하면서 예상을 벗어난 폭발적인 성장을 많이 보여주었다. 그런 가능성을 품을 수 있다면 안할 이유가 있겠는가? 나도 당연히 플랫폼을 만들고 싶다. 오픈마루가 플랫폼을 지향했던 것에도 동의한다. 단지, 스타트업(린 스타트업에서 정의하는)이라는 관점에서는 플랫폼을 생각하지 않는 게 좋다는 것이다. 일단 서비스를 성공시키고 나야 플랫폼에 도전할 수 있는 자격이 생기는 것이다.

블로그 / 스타트업

국내 소프트웨어 회사 치고 글로벌을 꿈꾸지 않은 회사가 있을까? 개발자들도 다들 글로벌을 꿈꾼다. 근데, 이상하게도 글로벌을 목표로 하는 회사나 사람 중에 다음과 같이 이야기하는 사람이 많다.

글로벌 진출을 하려면 미국에 가서 해야 한다

나는 이 주장에 대해 반박을 하고 싶다. 우선, 이런 주장을 하는 사람들에게 왜냐고 물어보면 다음과 같은 논리를 제시한다.

1. 미국에서 성공하지 않으면 글로벌에서 성공했다고 할 수 없다.
2. 미국에서 성공하려면 미국 문화를 이해해야 하므로 미국에 가야한다.
3. 고로, 글로벌에서 성공하려면 미국에 가야 한다.

2+. 여기에 덧붙여, 단순히 미국에 가는 것 뿐 아니라 미국 문화를 잘 이해하는 미국인을 채용해야 한다고까지 주장하기도 한다.

난 여기서 1, 2번이 모두 틀렸고, 그래서 1,2에서 이끌어낸 결론도 틀렸다고 생각한다.

우선 1번. 미국에서 성공하지 않으면 글로벌이 아니다?

반대로 질문해보자. 미국 이외의 모든 나라에서 흥한 서비스가 있으면 그건 글로벌에서 성공한 것인가, 아닌가? 라인이 쭉쭉 뻗어나가서 아시아 뿐 아니라 유럽, 남미 시장까지 다 장악했다고 가정해보자. 그럼 라인은 글로벌에서 성공했다고 인정할 수 있는가? 아마도 대부분 인정할 수 있을 것이다. 그런데 왜 다들 이런 말도 안되는 주장을 근거라고 대는가?

거기에는 어느 정도 이유가 있다. 우선, 미국에서 흥한 서비스는 다른 나라로 퍼져나가기 쉽다. 소프트웨어 산업에서 미국은 세계의 기준이 되기 때문이다. 그래서 시작이 어디가 되었든 미국을 점령하고 나면 그 다음은 쉽게 다른 나라로 확장할 수 있는 경우가 많다. 그러니까 미국은 글로벌 진출을 위한 최고의 디딤돌로는 볼 수 있다.

또 하나의 이유는 미국이 가장 hot한 시장이라는 것이다. 뛰어난 IT 기업들이 가장 먼저 서비스를 내놓는 곳이 미국 시장이니만큼, 거기서 증명한다면 상당히 좋은 아이템이라고 증명하는 셈이니 다른 곳에서도 통할 확률이 높은 것이다.

그러니까, 1`. 미국에서 통하는 서비스라면 글로벌에서 통할 확률이 매우 높다라고 한다면 이건 참일 가능성이 매우 높다. 위의 3단 논법에서 1번을 거론하는 사람들이 대부분 이런 논리를 펼친다. 안타까운 건, 여기까지는 참이라고 하더라도 저 명제의 이가 참이 되지는 않는다는 것이다. 저 명제는 미국에서 통하지 않는 서비스가 글로벌에서 통할지 아닐지에 대해 아무 것도 말해주지 못한다. 지금껏 글로벌에 대해 위의 3단 논법을 주장한 사람들에게 1의 근거를 요구하면 단 한 명의 예외도 없이 1`의 근거를 말했다. 반복하지만 1`가 참이라도 1이 참이 되진 않는다.

고로, 1번 명제는 틀렸으므로 저 3단 논법은 이미 틀렸다. 그러나, 사실 더 중요한 오류는 2번에 숨어 있으므로 2번까지 헤집어 보자.

2. 미국에서 성공하려면 미국 문화를 이해해야 하므로 미국에 가야한다.

이 명제에서 가정하고 있는 것은 A 나라에서 성공하라면 A 나라의 문화를 이해해야 한다는 것이다. 이건 내가 2번 명제를 반박하기 쉽게 만드려고 일반화시킨 게 아니고, 2번 명제를 주장하는 사람들이 실제로 저 명제를 일반론으로 믿고 있기에 하는 말이다. 그 나라에서 성공하고 싶으면 그 나라의 문화를 잘 이해해야 하는 거 아닌가요? 하는 반문도 많이 받아봤다.

자, 이것도 반대로 질문해보자. 스티브 잡스가 동양 철학에 심취한 적이 있어서 아시아를 잘 이해했기에 아이폰이 한중일에서 한 때나마 대박을 냈었다고 생각하는가? 야후는 대체 일본에 대해서 뭘 알았기에 일본 시장을 장악했었는가? 구글은 전 세계 각국의 문화를 잘 이해해서 전 세계 검색 시장을 제패했는가? 페이스북은? 트위터는?

그야말로 글로벌 서비스의 존재 자체가 2번 명제를 몸으로 반박하고 있다. 그 나라에서 성공하기 위해 그 나라의 문화를 잘 이해해야 한다면 글로벌 서비스는 존재할 수 없다. 주장 자체가 모순인 것이다. 드랍박스는 대체 미국의 무슨 문화에서 탄생했는데? 이베이는 미국의 문화를 잘 이해했기 때문인가? 아마존은 미국 문화에서만 발생할 수 있는 독특한 서비스인가?

이것은 서비스의 카테고리 분류 실패에서 오는 오류다. 예를 들어 미국에서 오픈 테이블은 성공했고, 한국에서 포잉은 (아직) 성공하지 못했다. 여기에는 문화의 차이가 존재한다. 괜찮은 레스토랑 찾아서 식사하려면 일단 차 타고 나가야 하는 미국과 도심에 맛집이 밀집해 있는 한국의 차이가 있다. 밥 한 번 먹으려면 예약해야 하는 나라와, 데이트할 때만 예약하면 되는 나라의 차이다. 그런데, 소셜 커머스는 어떤가? 그루폰의 모델을 그대로 카피한 티몬과 쿠팡은 폭발적인 성공을 거두었다. 이 비즈니스 모델은 미국에서만 발견할 수 있는 것인가? 반대로 이 모델을 한국에서 발굴해서 미국에서 런칭했으면 한국 사람이 했으니까 실패했을까?

글로벌에 대한 이해 부족이다. 글로벌에서 통하는 제품을 만든다는 것은 세계 각국의 문화적 차이와 큰 상관이 없는 인류 공통의 본질적인 문제를 해결하는 제품을 만든다는 것이다. 위대한 IT 기업은 모두 그 본질적인 문제를 해결했기 때문에 글로벌 기업이 된 것이지, 미국 문화를 잘 이해했기 때문에 글로벌 기업이 된 것이 아니다.

더 심각한 문제는 미국 문화를 잘 파고들어서 이루어낸 성공은 글로벌 성공을 담보하지 못한다는 것이다. 인간의 본질적인 문제를 해결한 것이 아니라 미국인만의 문제를 해결한 제품을 만들어낸다면 그게 글로벌에서 통할지 아닐지 어떻게 알겠는가.

그래서 난 이건 오히려 정반대라고 생각한다. 미국인이 미국에서 만들고 미국에 출시해서 성공시킨 서비스가 글로벌 확장에 성공할 확률 vs 한국인이 한국에서 만들고 미국에서 출시해서 성공시킨 서비스가 글로벌 확장에서 성공할 확률. 어디에 걸겠는가? 난 당연히 후자다. 후자가 인간의 본질적인 문제를 해결하는 제품일 가능성이 더 높기 때문이다.

고로, 미국에 가서 미국인도 채용하고 미국 문화를 이해하면서 해야 글로벌 성공을 이뤄낼 수 있다는 주장은 그 자체로 안티 글로벌이나 다름 없다.

하지만 이게 끝이 아니다. 또 이런 주장이 있다.

미국 이외에서 만든 서비스가 미국에서 흥한 사례가 있는가?

거의 없다. 작은 사례들은 많이 있지만 페이스북, 구글, MS, 애플, 아마존, 이베이, 넷플릭스 이런 수준으로 성공한 사례는 아직 없다. 근데 그게 왜? 카톡, 라인 이전에 한국 서비스가 해외에서 성공한 적이 있었나? 그래서 라인이 해외 진출 안했었더라면?

그리고 제품을 소프트웨어에서 조금만 넓혀보면 상황이 달라진다. 삼성전자는 여전히 핵심 제품 개발을 수원에 있는 연구원들이 진행하며, 이들이 제품 개발을 위해 해외 문화를 체험한다든지 하는 일은 없다. 그저 아이폰을 베낄 뿐. 그럼에도 갤럭시 S는 엄청난 글로벌 성공을 이뤄냈다. 만약 삼성이 애플 따라잡자고 미국에 연구소 세우고 미국 개발자 채용하고 그랬으면 과연 지금처럼 아이폰을 제치는데 도움이 되었을까?

소프트웨어 안에서도 게임을 본다면 대박은 얼마든지 많다. 왜 굳이 게임과 비 게임을 나눠야 할까? 오히려 게임이 더 문화적 차이가 크게 작용하는 분야 아닌가? 그런 게임에서도 한국에서 만든 게임이 미국에서 대박 친 사례가 여럿 있다면 다른 소프트웨어가 안될 이유는 무엇인가?

카톡은 왜 미국 시장에 파고들지 못하는가?

뭐, 내가 카카오에 있으니까 이번 카톡도 생각해보자. 카톡은 왜 미국 시장에 파고들지 못하는가? 카톡은 미국에 파고들지 못했으니까 글로벌 서비스가 될 가능성이 없는 서비스인가? 라인은 그저 일본과 동남아에만 통하는 서비스인가?

이건 가치 가설과 성장 가설의 차이를 혼동하는데서 오는 오류다. 구글 플러스를 보자. 구글 플러스는 출시되고 나서 제품 자체에 대해서는 좋은 평가를 많이 받았다. 페이스북과 트위터의 장점은 모두 흡수하고 단점은 다 해소했으며, 사진, 채팅 등의 연동으로 더 강력해졌다. 근데 왜 구글 플러스는 성공하지 못했는가? 구글 플러스는 제품이 사실은 나쁜 것인가? 당연히 그렇지 않다. 페이스북과 트위터가 없었다면 아마 빠른 속도로 SNS 시장을 장악했을 것이다. 그런데 경쟁자를 어떻게 제칠지에 대한 고민 없이 제품만 잘 만들려고 했기 때문에 실패한 것이다.

카톡도 마찬가지다. 아니, 문자를 공짜로 주고 받는데 무슨 문화가 필요한가? 이건 한국에서 만들어낸 자랑스러운 글로벌 서비스다. 글로벌 서비스로서의 가치가설은 이미 라인과 함께 증명했다. 단지 성장 가설이 증명되지 못한 것 뿐이다. 미국시장에 파고들지 못한 것은 카톡이 부족해서가 아니고 페이스북 메신저가 이미 시장을 장악하고 있기 때문이다. 그러니까 카톡이 미국 시장 진출을 하려면 페이스북을 어떻게 이길 것인가를 고민해야 하는 것이고, 어떻게 글로벌에 통할 제품을 만들어낼 것인가를 고민할 필요는 없다는 것이다.

아직 기회는 남아 있다. 페이스북 메신저가 빠른 속도로 카톡을 카피하고 있지만, 아직 단일 제품으로만 비교하면 페이스북 메신저보다 카톡이 훨씬 낫다. 하지만 이 기회는 그리 오래 가지 않을 것이다. 길어야 1년일 것이고, 그 때까지 카톡이든 라인이든 미국에 성공적으로 진출하지 못한다면 앞으로 꽤나 오랫동안 페이스북을 따라잡을 기회는 오지 않을 것이다.

흔히 메신저 시장은 친구가 다 엮여 있어서 쉽게 바뀌지 않는 시장이라고들 한다. 하지만, 이것도 사실과 다르다. 국내 메신저 시장만 봐도 초기에 인터넷 부흥기에 ICQ에서 MS가 메신저 밀면서 급격히 MSN 메신저로 이동했고, 또 네이트온이 등장하면서 다들 네이트온으로 이동했다. 그러다가 모바일 세상이 되면서 카톡으로 이동했고, 또 카톡의 속도가 문제될 때는 대거 틱톡으로 이동하는 현상도 보였다. 프리챌에서 싸이월드로, 다음 카페에서 네이버 카페로, 그리고 다시 페이스북으로 유저들은 끊임 없이 더 좋은 서비스로 이동한다. 오히려 친구가 엮여 있기 때문에 한두 명의 얼리어답터가 많은 친구들을 쉽게 움직이는 건지도 모른다. 이미 우리는 "야, 틱톡이 훨씬 빨라, 이제 틱톡 써"하는 모습을 목격한 바 있다. 네이버 카페에서 페이스북 그룹으로 옮기는 것도 대부분 한두 명이 주장해서 다들 옮겨간다.

그래서, 페이스북 메신저가 아직 부족한 지금이야말로 카톡과 라인이 온 힘을 다해 뛰어들어서 경쟁해야 할 시점이다. 근데 대체 왜!!!! ㅁ나ㅣ어헤ㅐ80ㅗ2ㅝㅁ너ㅟㅜ.ㅓㅣㅏ ㅁ나

한국 개발자들 글로벌에 대한 이해도 있고, 서비스나 UX에 대한 안목도 높고, 개발도 잘한다. 좀 믿고 맡겨 봐라. 어설픈 미국 개발자 채용할 생각 말고.

블로그 / 스타트업

개발자가 모자라요

개발자라는 직업 특성상(?) 다양한 회사들을 만나고 다니다보니 꽤나 자주 들려오는 이야기가 있다. 개발자가 모자라요. 근데 이것도 크게 보면 두 가지 종류가 있다. 스타트업이 개발자를 제대로 구하지 못해서, 혹은 구한 개발자를 붙들어두지 못해서 개발자 공백 상태가 되는 경우. 그리고 또 하나는 개발팀을 그런대로 확보해놓았지만 그 개발팀의 생산성이 만족스럽지 않은 경우. 두 경우의 공통점도 있는데, 그건 개발자가 모자라는 것이 현상이지 원인이 아니라는 것이다. 그래서 https://twitter.com/pakyoungrok/status/296225395940921344 이런 트윗도 날렸었고. 근데 이 트윗에 대한 반응을 보면 주로 전자 쪽에 집중되는 것 같다. 물론 전자도 이미 SNS에서 여러 사람의 글로 화제가 되었고 심각한 문제임은 틀림 없지만, 이미 많은 사람들이 다루었으니 나는 오늘 후자 쪽에 초점을 맞춰보려고 한다.

좀 풀어서 설명하면 이런 경우다. 회사가 투자를 받거나, 혹은 매출을 내거나 해서 그럭저럭 유지가 되는 상황이라 개발자들 월급도 제대로 줄 수 있고, 개발자도 적지 않게 뽑아놓았다. 개발자의 머리 수는 적지 않다. 그런데, CEO를 비롯한 많은 부서에서 쏟아내는 요청들을 개발팀이 다 감당하지 못해서 여러 부서에서 한 목소리로 "개발팀이 안 받쳐줘서 아무 것도 못해요"라고 외친다. 개발팀도 매일매일 바쁘게 일하지만 밀려드는 일을 감당하지 못해 일을 해결하는 속도보다 쌓여가는 속도가 훨씬 높고, 개발 속도도 덩달아 점점 느려진다. 다른 부서들은 개발팀을 비난하고, 개발팀은 점점 방어적으로 변해간다.

이런 일은 회사 규모와 상관 없이 일어난다. 내가 아는 바로 6명 짜리 회사도 겪고 있고, 500명 짜리 회사도 겪고 있는 문제다. 사실 개발자 품귀현상 문제도 이 문제와 관련이 있다. 이런 회사는 개발자를 붙들어둘 수도 없고, 좋은 개발자를 데려올 수도 없기 때문이다. 다른 부서로부터 매일같이 비난의 눈초리를 받는 개발팀에 오래 머물고 싶은 사람이 누가 있겠는가? 밥줄 때문에 버티고 있는 것 뿐이지.

더 골(The Goal)

그럼 이 문제는 왜 일어나는가? 그리고 이 문제는 해결 가능한 문제인가?

물론 해결 가능하다. 이 문제는 이미 인류의 지성이 정복한 바 있는 문제다. 다만, 그 지성이 아직 충분히 확산되지 않았기 때문에 해결하지 못한 조직이 많은 것이다. 아, 그렇다고 이게 당신의 조직이 해결할 수 있는 문제라는 뜻은 아니다. 페르마의 정리는 이미 수학자들이 정복한 문제지만, 그렇다고 니가 그 문제를 풀 수 있는 건 아니지 않은가. 이 문제는 비록 해법이 쉽고 단순하지만 정말로 이걸 실행할 수 있는 조직은 극히 드물다. 뭐 그렇다고 실행 난이도가 엄청 높다거나 그런 건 아니고, 대개의 경우 CEO가 이런 변화를 받아들이지 못하기 때문이다. 에시당초 CEO가 이 문제에 대한 개념이 있으면 이런 문제는 발생하지도 않겠지.

그럼 그 쉽고 단순하다는 해답은 무엇인가? 더 골이다. 옛날 같으면 링크 걸어줬으니 책 읽어보셈, 하고 끝냈겠지만, 오늘은 시간이 많으니 좀 상세히 적어보려고 한다.

핵심은 병목자원 관리다. 병목자원이란 최종 제품으로 나오는 공정 중에서 생산성이 가장 낮은 공정이다. 이런 병목자원이 있을 때는 병목 자원을 중심으로 프로세스를 짜야 한다. 요는 병목자원에서의 시간 낭비를 제거하는 것이다. 낭비를 제거하는 건 당연하잖아 할 수도 있는데, 중요한 건 병목자원의 시간 낭비만 제거하는 것이다. 심지어 다른 공정에는 시간을 더 낭비하게 되더라도 상관 없다. 아니, 병목자원의 시간 낭비를 제거하려고 하면 거의 필연적으로 다른 공정에서는 낭비가 발생한다. 하지만 그래도 해야 한다.

낭비 제거의 포인트는 크게 두 가지. 하나는 병목자원이 대기하는 시간이 생기지 않도록 하는 것이고, 다른 하나는 병목자원에서 불필요한 일을 처리하지 않는 것이다. 이 두 가지를 충분히 해놓고 나서 병목자원의 생산성을 높이는 방안을 강구해야 한다. 이 두 가지가 안되면 병목자원을 확장해도 대개 소용 없다. 

이 문제를 개발팀 문제로 치환해보자. 일단 개발팀이 안 받쳐준다는 이야기가 나온다는 것은 개발팀이 병목자원이라는 뜻이다. 사실 개발팀이 얽혀야 하는 대부분의 조직에서 병목자원은 개발팀이다. 개발자가 10명이든 100명이든 개발팀이 병목이 아닌 회사는 드물고, 또 개발팀이 병목이 아니라면 그 회사는 더 큰 문제가 있는 건지도 모른다. 그래서, 개발팀을 병목자원이라고 놓고 다시 문제를 보자.

병목자원의 시간을 어떻게 낭비하게 되는가

우선 개발팀이 어떤 식으로 시간을 낭비하게 되는지를 보자. 위의 두 가지 중 첫번째를 개발에 대입하면, 개발하기에 필요한 정보가 충분치 않아서 개발자가 개발을 진행할 수 없어서 답변을 기다리면서 대기하는 상태이다. 디자인이 늦게 오거나, 세부기획에 빠진 부분이 있거나, 요구사항이 불명확하거나 등등. 이 문제를 한 마디로 설명한다면 "완벽한 기획서가 존재하지 않기 때문"이다. 개발자의 책상 앞에 기획서를 수북히 쌓아놓지만 개발자는 그 기획서만으로 개발할 수 없다. 디테일은 늘 빠져있게 마련이다. 그럼 개발하면서 계속 이 기획을 낸 사람과 커뮤니케이션을 해서 필요한 정보를 공급 받아야 한다. 그런데, 그 기획자가 이 프로젝트만 하고 있고, 개발자 옆에 딱 붙어 있어서 필요할 때 바로바로 의문을 해결해줄 수 있으면 되는데, 그런 경우는 드물다. 기획이 CEO에서 나오는 경우도 있고, 기획만 전담하는 사람이 아니라 다른 핵심 업무가 있는 부서에서 나오는 경우도 많기 때문이다. 이를테면 영업 부서에서 영업에 필요한 기능을 개발팀에 요청한 경우를 보자. 영업팀의 요청사항이 자세할 리는 없다. 개발자가 보고 개발하다보면 계속 영업팀에 물어봐야 한다. 그런데, 영업팀이니까 영업하느라 바빠서 개발자의 질문에 바로바로 답해주지 못한다. 그럼 그만큼 개발이 늦어지는 것이다.

기획 전담팀이 있어도 마찬가지다. 개발팀의 생산성 문제가 대두된 상황이니만큼 기획자가 만든 기획서는 바로바로 개발되지 않을 것이다. 그럼 기획자는 시간이 남으니까 새로운 기획을 또 하게 되고 개발자의 책상에는 또 새로운 기획서가 쌓인다. 그럼 개발자 앞에 쌓인 재고가 늘어나니까 다른 부서의 요청들은 더 대기시간이 길어진다.

이런 문제를 제대로 이해하고 있는 사람은 드물다. 이를테면 이런 식이다. 개발자는 지금 주어진 기획서를 개발하느라 여념이 없다. 근데 기획서에는 지금 검색조건을 입력하는 인터페이스에 대한 설명이 부족하다. 그래서 개발자가 그 부분에 대한 설명을 기획자에게 요청하려는데 기획자는 다른 일 하느라고 답이 늦어져서 개발이 지체된다. 기다리다 못한 개발자는 다른 업무로 잠시 전환했는데, 그러느라 컨텐스트 전환 비용이 소모된다. 근데 그런 찰나 기획자가 찾아온다. 그래서 필요한 정보를 물어보려는데 기획자가 이미 개발된 기능 중에 하나를 다르게 바꿔달라고 한다. 어, 아직 유저한테 deploy되지도 않은 기능인데? 기획자가 생각이 바뀌었댄다. 온 김에 기획자에게 검색조건 인터페이스를 물어보려고 하니 그건 놔두고 일단 자기가 지금 요청한 거 먼저 해달라고 한다.

자, 여기서 기획자는 무슨 짓을 저지른 것일까? 일단 병목자원의 가동을 멈추게 만들었다. 개발자가 1시간 기다리면 전체 일정이 1시간 늦어진다. 기획자는 1시간을 놀든 하루를 놀든 개발자에게 필요한 정보만 제 때 주면 일정에는 영향을 미치지 않는다. 하지만 기획자는 자기가 개발되길 기다리는 시간이나 개발자가 필요한 정보를 얻기 위해 기다리는 시간이나 같은 가치라고 생각한다. 동등한 사람인데 시간의 가치는 같겠지. 하지만 두 사람의 시간의 가치는 같지 않다. 개발에 필요한 정보를 제때 공급하는 것이야말로 생산성의 핵심이다.

이것만이 아니다. 기획자는 아직 제품화되지 않은 기능의 수정을 요청했다. 제품화는 되지 않았지만 개발이 완료된 기능은 다른 말로 하면 병목자원을 한 번 통과한 기능이다. 그런 기능을 수정한다는 것은 앞서 병목자원을 통과한 시간을 그냥 낭비했다는 것이다. 제품화되서 사용자의 검증도 받기 전에 바꿔버렸다는 것은 불필요한 재고를 생산했다는 것이다. 심지어 그 재고를 생산하기 위해 병목자원의 시간까지 썼으므로 이 기획자가 낭비한 시간은 엄청난 것이다. 이것은 병목자원 낭비의 두번째 케이스다. 덤으로 새로운 재고까지 쌓아서 다른 재고의 리드 타임마저 떨어뜨렸다.

이처럼 별 것 아닌 것 같은 일상적인 기획자의 행동이 개발팀의 생산성을 크게 낭비한다. 이것이 "개발팀이 제 때 제 때 개발해주지 않아요"라고 불평하는 조직에서 일상적으로 일어나는 일이다.

병목자원의 시간을 낭비하지 않게 일하는 법

그럼 어떻게 일해야 병목자원, 곧 개발팀의 시간을 낭비하지 않게 할 수 있는가? 제일 중요한 것은 개발자는 기다리는 시간이 없어야 한다는 것이다. 이게 온전히 가능하려면 어쩔 수 없이 다른 사람이 기다려야 한다. 예를 들어, 기획팀이 A 프로젝트의 기획서를 개발팀에 넘겨준 상태라고 가정해보자. 개발팀은 다른 할 일들이 쌓여 있으니 이 기획서를 당장 수행할 수 없다. 그럼 기획팀은 손이 빈다. 이 때 손이 빈다고 다른 프로젝트를 시작하면 악몽의 시작이다. 이게 중요하다. 개발팀이 A 프로젝트를 시작하기 전까지 아무 것도 하지 말아야 한다. 설령 뭔가를 하더라도 개발팀의 작업 리스트에 또다른 리스트를 올려놓아서는 안된다.

그럼 개발팀이 A 프로젝트를 이제 시작했다고 해보자. 그럼 기획팀은 무엇을 해야 하는가? 마찬가지다. 아무 것도 하지 말아야 한다. 해야 하는 일은 단 하나, 개발팀의 요청에 신속하게 응대하는 것이다. 개발팀이 A 프로젝트를 개발하는데 도움이 되는 일 외에는 아무 것도 하지 말아야 한다. 물론 그러면 기획팀의 시간은 낭비된다. 하지만 이건 상관 없다. 전체 생산성에 영향을 주지 않기 때문이다. 전체 일정에 영향을 주는 요소는 오로지 병목자원의 시간이다. 이것이 핵심이다.

영업팀이나 CEO, 고객지원팀 등에서 요청하고 싶을 때는 어떨까? 마찬가지다. 개발팀이 개발을 시작하면 영업하러 나가지 말고 대기해야 한다. 안 그러면 당신이 요청한 기능은 영원히 완성되지 않을 것이다. 근데 여기서 하지 말아야 할 것 하나는 요청한 사람이 개발자를 재촉하러 오는 것이다. 개발자의 생산성을 심각하게 떨어뜨린다. 자신이 급할 때 개발자에게 가지 말고, 개발자가 필요할 때 가야 한다. 쉽게 말해서 개발팀에 기능을 하나 요청했고, 개발팀이 일단 그 기능을 개발하기로 OK했다면, 그 다음부터는 개발자가 호출할 때까지 얌전히 대기해야 하고, 개발자가 호출하면 즉시 응답해줘야 한다. 이게 제대로 되어야 병목자원 관리를 제대로 하는 팀이라고 할 수 있다.

아니 같은 인간인데 왜 개발자의 시간만 중요하냐고 항변할 수도 있겠다. 정치적으로 모든 사람의 시간은 동등한 가치가 있고, 경제적으로는 각자의 수입과 비례하는 기회비용으로 따질 수 있겠지만, 프로젝트의 관점에서는 병목자원의 시간은 비병목자원과 100배 이런 차이가 아니라 1과 0의 차이다. 비병목자원 수백 명의 시간보다 병목자원 한 명의 시간이 더 중요하다.

비병목자원의 활용

병목자원 관리의 첫번째 포인트가 대기시간의 제거라면, 두번째 포인트는 병목자원에서 불필요한 일을 제거하는 것이다. 불필요한 일은 두 가지다. 하나는 아예 할 가치가 없는 일이고, 또 하나는 프로젝트에는 필요한 일이지만 병목자원을 통과하지 않고 처리할 수 있는 일이다. 여기서 첫번째 아예 할 가치가 없는 일은 사실 해보기 전엔 알 수 없으므로 초점을 맞춰야 하는 것은 병목자원을 통과하지 않아도 되는 일을 식별해내는 것이다. 그러니까, 개발자가 안해도 되는 일은 최대한 다른 팀에서 처리해야 한다는 것이다. 이것도 두 가지 포인트를 잡을 수 있는데, 하나는 개발자가 어드민 시스템을 잘 만들어줘서 되도록 어드민 작업을 개발자의 도움 없이 할 수 있게 해주는 것이다. 물론, 개발자가 이런 어드민 시스템을 만들 시간은 줘야겠지. 또 하나는, 개발자가 하고 있는 업무 중에서 일반인(?)이 할 수 있는 업무는 최대한 다른 팀이 가져가는 것이다. 이건 창의력이 좀 필요하다.

전에 소셜커머스에서 일할 때의 예를 들면 이런 것이다. 소셜커머스에서 대개는 하나의 딜에 하나의 상품이 있지만, 여러 개의 상품이 있는 경우도 있고, 상품별로 가격은 다르게 책정할 수 있다. 그런데, 부가 옵션은 상품별로 붙일 수 없다. 그러면 이 딜은 현재 시스템으로 소화할 수 없고, 상품별로 옵션을 붙일 수 있는 기능을 개발해야 한다. 하지만 이런 종류의 딜은 드물기 때문에 이 딜 하나를 위해 시스템을 개발하기엔 다른 더 중요한 일이 너무 많고, 데이터베이스 설계도 유연하게 되어 있지 않아서 변경 비용이 크다. 이런 경우에 보통의 회사라면 그래도 개발자가 이 기능을 추가로 개발하도록 만들 것이다. 하지만, 그 때 내가 선택한 방법은 딜을 여러 개로 분리하는 것이었다. 아예 분리된 별개의 딜인 것처럼 올려서 처리해버리면 어드민에서 입력하는 사람은 좀더 일이 많아지겠지만, 개발 비용은 추가로 들어가지 않는다. 상품별로 링크를 걸어두면 되니까 딜 판매량에도 영향을 주지 않는다. 아마도 각 회사의 업무에 따라 이런 식으로 개발이 필요한 일 같지만 개발하지 않고 넘길 수 있는 경우가 아주 많을 것이다. 이런 방법을 찾아내는 것도 개발팀이 아니라 다른 팀에서 해주면 더욱 좋고.

이런 복잡한 일만 있는 건 아니다. 사소한 일도 도와줄 수 있다. 이를테면 기획팀이 할 일이 없다면 개발팀에 와서 개발자들이 하고 있는 잡무를 도와줄 수도 있다. 어찌되었건 비개발자가 1시간을 들여서 개발자의 1분을 절약해줄 수 있는 일이라면 뭐든지 팀에 보탬이 되는 것이다. 물론, 이렇게까지 할 수 있는 팀웍을 갖춘 팀은 매우 드물겠지.

일거리의 선별

자, 그럼 개발자의 시간 낭비를 최소한으로 줄이는데 성공했다. 다른 부서들도 모두 개발팀을 중심으로 사고하는데 익숙해졌고, 프로세스는 개발팀을 중심으로 돌아가기 시작했다. 그러면 산처럼 쌓여 있던 많은 일들이 착착 진행될까? 아닐 것이다. 여기서 하나 더 생각해야 할 것이 있다. 어떠한 개발자도 생각하는 속도보다 더 빠르게 개발할 수는 없다는 것.

이게 왜 중요할까? 그런 조직이 겪는 문제 중에 중요한 것은 개발팀이 할 일의 분량 자체가 너무 많다는 것이다. 부서마다 다 자신들의 아이디어를 쏟아내서 개발팀의 작업 큐에 쌓아버리면 어떤 개발팀도 감당할 수 없다. 생각의 속도는 엄청나게 빠른 반면, 개발 속도는 생각하는 속도의 수백 배에서 수백만 배로 느리기 때문이다. 그 어떤 개발자도 생각의 속도를 온전히 작업 속도에 반영할 수 없다.

그러므로 마인드 자체가 생각나는 아이디어를 모두 실행한다가 아니라 고도로 필터링하고 정제된 아이디어를 실행하는 것으로 바뀌어야 한다. 문제는 이것이 스타트업의 문화와 안 맞는 것으로 보이기 쉽다는 것이다. 스타트업에는 실행이 가장 중요하다. 떠오르는 아이디어를 열심히 정제하는 것보다 바로바로 실행에 옮겨서 반응을 보는 게 중요한 것도 사실이다. 그리고, proof of concept에 성공한 스타트업들도 아이디어를 정제하는데 많은 시간을 쓰기보다 바로바로 실행에 옮기는 것을 중시했다. 그럼 어떻게든 개발팀은 모든 부서의 아이디어를 실현할 수 있도록 병목자원의 생산성을 증가시켜야 하는 것 아닐까?

이것이 바로 proof of concept에 성공한 스타트업의 착각이다. 이런 말이 있다. 기업에서 가장 위험한 것은 왜 성공했는지 모르고 성공하는 것이라고. 떠오르는 아이디어를 바로 실행에 옮기는 것이 스타트업의 핵심 성공 요인임은 분명하다. 그러나, 그것만이 아니다. 그게 효과를 볼 수 있었던 것은 떠오르는 아이디어의 종류가 적었고, 모든 멤버들이 그 아이디어를 실행하는데 집중할 수 있었기 때문이다. 초기에는 모든 사람이 한 가지 핵심에 집중하게 마련이다. 그런 상황에서 나오는 아이디어 역시 잘 포커싱되어 있다. 그런데, proof of concept가 되고 매출을 성장시키기 시작한 회사에도 이 방식이 들어맞을 것인가? 당연히 불가능하다. 이제 사람 수도 많고 부서도 많고, 이해관계도 복잡하다. 당연히 이 많은 사람들에게서 나오는 요구들은 핵심에 잘 집중되어 있지도 않고, 아이디어의 종류도, 개수도 많다. 이 모든 것을 소화할 수 있는 개발팀을 구축하는 것은 이미 물리적으로 불가능한 상황이 된 것이다.

이런 상황에서 개발팀이 예전처럼 요청을 다 소화해주기를 바라는데 개발팀은 그렇게 할 수 없으니 "개발팀이 안 받쳐줘서 아무 것도 못해요" 같은 소리가 나오는 것이다. 개발팀이 안 받쳐주면 개발팀이 받쳐주는 만큼 일을 주어야 한다. 아니, 사실은 그보다 더 적게 주어야 한다. 그래야 스스로를 개선해가면서 개발 속도를 올릴 수 있기 때문이다. 그런데, 그런 점은 감안하지 않고 모든 부서에서 중구난방으로 개발팀에 요청을 쏟아내면 개발팀은 중요한 일을 구분할 수 없게 되고 점점 중요하지 않은 일에 시간을 소비하면서 중요한 일을 해내는 속도는 더 느려지는 것이다. 그러니까, 개발팀이 아무 것도 할 수 없게 만드는 건 바로 무작위로 요청을 쏟아내는 다른 팀들인 것이다.

그래서 정말 proof of concept 전처럼 기민하게 움직이고 싶다면 그때처럼 충분히 핵심에 집중할 수 있는 상황도 같이 만들어줘야 한다. 아이디어를 무작정 쏟아낼 게 아니라 잘 정제해서 꼭 필요한 일들만 병목자원을 통과시켜야 한다. 

안타까운 일이지만 proof of concept도 하기 전의 스타트업들도 이런 식으로 무작위적인 아이디어를 쏟아내는 경우가 많다. 마치 개발자를 CEO의 아이디어를 실현해주는 사람 취급을 하는 것이다. CEO가 머리 속으로 이것저것 떠오르는대로 다 개발자에게 전달하면 아주 작은 팀도 위와 같은 문제를 그대로 발생시키게 된다. 아니, 사실 이 경우는 훨씬 심각하다. 성공할 가능성 자체를 낮춰버리기 때문이다.

린 스타트업도 기민하게 움직이기를 요구하지만 아무 아이디어나 생각나는대로 실행하라는 게 아니다. 치밀하게 가설을 세우고, 그 가설을 검증할 수 있는 작업만 하는 것이 린 스타트업이다. 가설을 검증하는데 도움이 되지 않는 일은 1그램도 하지 말아야 한다. 이런 린 스타트업의 방식을 유지할 수 있다면 기업이 작든 크든, proof of concept를 해냈든 아니든 기민하게 움직일 수 있다. 

기능조직의 문제

그런데, 여기서 이런 일이 일어나는 좀더 근본적인 원인을 파고들어보고 싶다. 왜! 다른 조직들은 마치 개발팀의 생산성을 저하시키는 게 목표라도 되는 것처럼 행동하는가? 그들은 나쁜 사람들이라서? 아니면 머리가 나빠서? 단지 더 골을 읽지 않았기 때문에? 난 그렇게 생각하지 않는다. 역량의 차이가 크지 않은 팀의 경우에도 개발팀과 매우 조화롭게 협업해내는 경우가 많이 있다. 그리고 나는 개발팀이 안 받쳐줘서 아무 것도 못한다고 투덜대는 모든 회사들에게서 아주 강력한 공통점을 발견했다. 그것은 기능조직이라는 것이다. 더 많이 세분화된 기능조직일수록 이 현상은 더 심하다.

기능조직의 문제는 크게 두 가지다. 하나는 포커스가 안된다는 것. 기능별로 분리되어 있으니 개발팀은 여러 가지 업무를 맡게 될 수 밖에 없다. 한 개발자가 여러 업무를 맡게 되는 것도 이런 조직에선 자연스럽다. 그러니 개발자는 당면 프로젝트에 집중하기 어렵고, 개별 프로젝트에 대한 이해도도 떨어진다. 업무를 요청한 쪽도 마찬가지로, 개발팀이 지금 어떤 업무들을 하고 있는지 모르니까 자신들의 요청을 우선적으로 처리해달라고 요청할 수 밖에 없다. 그러니까 모든 부서가 다 자신들의 일을 최우선으로 해달라고 요구하게 되고, 그 중에 어딘가는 낮은 우선순위를 배정받을 수 밖에 없으니 개발팀의 퍼포먼스에 불만이 생기게 마련이다.

사실 기능조직은 회사의 규모와 상관 없이 지식노동을 하는 조직에는 적합하지 않다. 기능조직의 우수성이 입증된 사례도 거의 존재하지 않고, 이론적인 장점도 없는, 그냥 틀린 방식이다. IT 회사가 기능조직으로 일을 하고 있다면 경영진의 역량 부족이다.

목적조직에선 위에서 언급한 많은 문제가 저절로 해결된다. 영업부서에서 개발팀에 요청하는 게 아니라 영업부서에 개발자 한 명이 배치되어 있다고 생각해보자. 그리고 그 개발자는 영업부서의 업무만 처리한다. 그럼 이 개발자에게 과도한 업무가 쌓일 일도 없고, 서로 간에 업무 이해도도 높아지므로 개발자가 정보를 얻기 위해 대기해야 하는 시간도 줄어든다. 늘 붙어 있으니까 서로 기민하게 대응할 수 있다. 물론 이렇게 하면 개발자가 일이 없는 순간이 생길 수 있다. 그렇지만 그게 무슨 문제인가. 일이 없어서 노는 건 병목자원이 아니라는 이야기고 이건 문제 없다.

기획팀이 따로 존재하는 것이야말로 인간이 생각해낼 수 있는 최악의 조직 구조다. 마케팅 부서에서 새로운 마케팅을 한다고 가정해보자. 마케팅 부서에 담당 개발자가 있다면 그냥 그 개발자랑 계속 커뮤니케이션하면서 만들어가면 된다. 근데 기획팀이 따로 있으면 마케팅 부서에서 기획팀에 요구사항을 넣고 기획팀은 그 요구사항을 바탕으로 기획안을 만들어서 개발자에게 전달한다. 그러면 그 개발자는 개발하다가 의문사항이 생기면 또 기획자에게 물어보고 기획자는 다시 마케팅에 물어본다. 이런 복잡한 과정을 거쳐서 생산성이 날 리가 없지 않겠는가.

작은 스타트업에서도 이런 현상은 나타난다. 대기업에서 기능조직으로만 일해온 사람들은 5~6명 짜리 스타트업에서도 같은 방시으로 일하면서 기능조직의 문제점을 그대로 노출한다. 5명인데 팀으로 동작하는 게 아니라 따로따로 논다면 그 팀이 성공할 리 있겠는가.

기능조직은 당장 폐기해야 할 구시대의 잔재다. 설령 당장 바꿀 수 없다 해도 경영진이 의식을 가지고 외형적인 구조는 기능조직이더라도 목적조직처럼 일할 수 있게 서포트해야 한다.

개발자는 도구가 아니다

하지만 기능조직도 근본 원인은 아니다. 앞서 말한 것처럼 작은 스타트업도 기능조직처럼 일하는 경우가 많다. 왜 이런 현상이 생길까? 내가 보는 이유는, 개발자를 자신의 아이디어를 실현해주는 도구로 보기 때문이다. 개발자를 함께 회사를 이끌어나가는 동반자로 보느냐, 그저 내 아이디어를 실현해주는 사람으로 보느냐에 따라 일하는 방식이 결정된다. 개발팀이 안 받쳐줘서 뭘 못한다고 생각하는 것 자체가 개발팀은 자신을 받쳐줘야 되는 존재라고 보는 것이다. 그들은 개발팀이 겪고 있는 문제에 관심이 없다. 단지 자신이 요청을 실행해주느냐 아니냐에 따라 판단할 뿐이다.

병목자원 이론, 일거리 선별, 기능조직 등 구체적인 방안들을 이야기하긴 했지만, 사실 더 중요한 것은 개발자를 동반자로 보고 함께 머리를 맞대고 고민하는 것이다. 개발팀을 진정 동반자로 본다면 일거리가 산처럼 쌓여 있는 개발팀에 가서 자기 요청 안해준다고 투정부리고 있겠는가? 개발팀을 신뢰한다면 수시로 가서 해달라고 조르겠는가? 제대로 된 팀이라면 더 골 같은 거 안 읽어도 저런 문제들 안 생긴다. 팀이 붕괴되면 어떤 방안도 다 소용 없는 법이다.

이번 글에서는 "개발자가 모자라요"의 두번째 문제만 다루지만, 첫번째 문제, 스타트업이 개발자를 못 구하는 경우도 사실 마찬가지다. 말로는 기술 중심의 회사니 해커 문화니 떠들고, 함께 성장하는 회사를 말하지만, 사실은 그냥 내 아이디어를 실현해줄 사람을 찾는 경우가 대부분이다. 그런데 그런 마인드를 개발자가 눈치 못 챌 리 없다. 그러니까 개발자를 못 구하는 것이다. 특히 제일 웃긴 이야기는 "개발자만 있으면 이 사업 성공시킬 수 있는데"라는 말이다. 이건 "여자만 있으면 장가갈 수 있는데"라는 말이랑 똑같다. 뭐, 둘다 ASKY지.

개발자는 모자라지 않다.

개발자가 모자란 것은 원인이 아니라 결과다. 원인은 개발자들이 제대로 일할 수 있는 문화가 갖춰지지 않았기 때문이다. 문화가 갖춰지면 개발자들의 생산성은 몰라보게 올라갈 것이고, 뛰어난 개발자도 저절로 모여든다. 개발자가 모자란다고 불평하기 전에, 우리 회사는 왜 개발자가 생산성을 낼 수 없는지 고민하는 것이 우선이다. 그런 고민 없이 아무리 개발자 늘려봐야 소용 없다.

블로그 / 소프트웨어 개발