Uber, 비전이 멋진 회사
실리콘밸리 사람들은 왜 열정적이고 자발적인가?
작년 11월에 다녀온 후 6개월 만에 또 실리콘밸리에 갔다.
다녀온 이야기를 하면 마치 출장 같다는 반응이지만 난 휴가를 간 게 맞다.
지난번엔 출장으로 구글(Google), 링크드인(LinkedIn), 오라클(Oracle), 넷플릭스(Netflix), 아마존(Amazon), 마이크로소프트(MS)를 다녀왔고, 이번엔 휴가를 갔다가 깃허브(GitHub), 우버(Uber), 테슬라(Tesla), 페이스북(Facebook)에 다녀왔다. 이번엔 주로 샌프란시스코의 회사를 방문했다. 아무래도 최근 많은 사람의 관심을 끌고 있거나 스타트업에서 시작해 스케일링하고 있는 회사들은 샌프란시스코에 있으니 말이다.
그들 중 누군가는 오랫동안 한 회사에서 근무하기도, 다른 누군가는 몇 번의 이직 경험이 있고, 또 다른 누군가는 실리콘밸리 안에서도 계속 이직하며 여러 회사를 경험한 이야기를 해주기도 했다.
고작 열 몇 군데 회사를 가보고, 몇 사람의 얘길 들어보고 일반화한다는 것은 어렵지만, 실리콘밸리는 네트워킹할 수 있는 meetup이 활성화되어 있고, 이직이 잦은 곳으로 유명하여 그들도 자신이 이전에 다녔던 다른 회사와 비교해서 얘길 해주곤 한다. 또, 한국 문화가 어떤지 조금이라도 알고 있는 한국인 교포나 취업을 하여 그곳에 간 사람들을 만났기 때문에 한국의 기업문화와 비교해보기에도 꽤 괜찮은 만남이었다.
여행인지 출장인지 2016, 그 첫 번째 이야기는 Uber 로 시작해볼까 한다.
실리콘밸리의 SW 회사들을 벤치마킹하고 오면 언제나 ‘열정'과 ‘자발적’이라는 키워드가 등장한다.
실리콘밸리에서 개발자들이 자발적으로, 또 그들 스스로 일을 만들어 서비스로 만들어내는 그 과정을 나는 ‘일을 도모한다’라고 표현하고 싶다.
그 과정이 어떤지 머릿속에서 해석해나가는 과정이, 내가 이 글을 쓰면서 그랬듯 당신이 속해 있는 회사의 문화와 비교해보면 좋을 것 같다.
열정적인 사람들, 자발적으로 뭔가를 만들어 내는 문화,
그리고 Bottom-up으로 만들어지는 서비스
사실 실리콘밸리는 열정적이고 자발적인 사람들이 모이는 곳이다. 시키는 일을 묵묵히 하는 것에 익숙한 사람이 자리 잡고 일하는 것이 힘든 곳이라는 뜻이다.
실리콘밸리에서 근무하고 계시는 어떤 한국인을 만나도 이 얘긴 빠지지 않았다.
대부분의 실리콘밸리 회사의 직원들이 열정적이고 자발적인데, 요즘 그 업계에서도 뜨겁다는 Uber의 얘기로 풀어볼까 한다.
UberUber는 한국에서 원활하게 운영되는 서비스가 아니지만, 한국인에게도 매우 익숙하다.
처음 서비스가 한국에 들어온 이후 불법이니 아니니 시끄럽다가 개인 차량을 다른 사람과 공유하는 UberX는 불법 서비스로 분류되어 결국 서비스가 중단되었다. (http://www.bloter.net/archives/222423)
사실 Uber라는 회사에 대해서는 대표 서비스인 ride sharing 서비스의 이름이 Uber이기 때문에 그게 전부라고 생각했다. 이는 미국뿐만 아니라 유럽에 가서도 Uber를 심심찮게 볼 수 있었기 때문이기도 하다.
그런데 개발자분을 만나 대화를 나누다 보니 그게 아니었다.
우리가 흔히 알고 있는 Uber 외에도 ‘승용차 함께 타기’ 운동의 일환인 UberPool이라는 서비스가 있다. 방향이 같은 여러 명을 모아 같이 출퇴근하는 서비스이다. 또, UberEATS라는 음식 배달 서비스도 생겼다.
1. 같이 출퇴근하는 Uber Pool
UberPool은 이름에서도 알 수 있듯이 승용차 함께 타기(Carpool) 서비스이다.
기존 Uber와 같이 ride sharing에서 비롯된 서비스인데, 산호세에 살며 샌프란시스코로 출퇴근하는 사람들이 혼자 자가용을 몰고 다니면 교통체증과 대기오염이 심해지는 사회적인 문제에서 시작되어, ‘승용차 함께 타기’ 운동으로 발전한 서비스이다.
Uber 서비스의 목표는 사람들에게 값싼 교통수단을 공급하는 것이라고 한다.
2. 음식을 배달해주는 UberEATS
UberEATS는 음식 배달 서비스인데, 다른 음식 배달과 다르게 음식을 시키기 전에 이미 음식이 차에 있고, 언제 어떤 지역에서 배달 주문이 올지 수요를 예측해서 미리 가있는 것이 차별점이다. 예를 들어 ‘8시쯤 샌프란시스코의 Mission District 지역에서 페퍼로니 피자의 주문이 많이 들어온다’는 데이터를 얻으면 그 동네에 미리 페퍼로니 피자를 실은 차를 대기하고 있다가 주문하는 즉시 배달해주는 것이다.
UberEATS의 목표는 고객이 주문하고 음식을 받기까지 시간 지연이 거의 없도록 하는 것이 목표다.
이외에도 ‘이런 것도 해?’ 싶은 서비스가 다양하게 있었는데, Uber의 메인 비즈니스가 ride sharing이긴 하지만 싸게 공급한다가 모토인 회사이고, On Demand 운수 서비스를 하는 곳이기에 이런 다양한 서비스가 가능한 것 같다. (참고: http://slownews.kr/29399)
Car sharing으로 시작한 우버가 다른 서비스로 확장하는 과정은 어땠을까?
UberEATS를 예로 들어볼까 한다.
1. Uber의 개발자 중 누군가가 음식을 배달시켰는데 빨리 오지 않자 '내가 음식 먹고 싶은데 오래 걸린다!'라는 불편함을 느꼈다.
2. 이 문제를 개선할 수 있는 내용을 담은 RFC(Request for Comments)를 Google docs에 쓴 뒤, 이를 Uber의 다른 개발자들에게 공유한다. (Uber 직원이라면 Uber 내에서 작성되는 모든 문서를 볼 수 있다고 한다)
3. 공유한 문서에 본인이 생각한 서비스 내용과 아키텍처를 기술하는데, 그걸 리뷰한 다른 사람들은 ‘네가 적어둔 아키텍처 중에 2번은 내 생각엔 이런 문제가 있을 것 같아. 그걸 이런 방식으로 해보면 어떨까?’와 같은 피드백을 준다. 이런 리뷰가 여러 사람에게서 끊임없이 이루어진다. 아이디어를 현실화할 수 있도록 살을 붙이는 과정이다.
4. 이 과정을 거친 RFC로 만들어진 아키텍처는 점점 더 탄탄해지고 더 많은 사람에게 공감받을 수 있는 서비스로 발전한다.
물론 그 과정에서는 의견이 다른 사람들이 있을 수 있다. 하지만 개발자들 모두의 방향성이 같거나, 같아질 때까지 기다리기보단 일단 생각한 것을 시도해보면서 그게 점점 커지는 형태이다.
UberEATS 외에 UberRUSH와 Uber of Everything 등도 그렇게 만들어졌다.
서비스 확장 과정에 대해 한국사람들이 주로 하는 질문
이 과정에 대해 듣고 나면 보통 이런 질문들이 나온다.
Q. Ride sharing과 배달은 전혀 다른 건데 이걸 왜 하나?
Q. 아이디어를 공개했다가 다른 팀에서 훔쳐가면 어떻게 하나?
Q. 아키텍처는 아키텍트 업무를 하는 사람들이 만들고 최종 확정은 대표 아키텍트가 해야지 그걸 공유하면 책임은 누가 지나?
Q. Ride sharing과 배달은 전혀 다른 건데 이걸 왜 하나?
앞서 언급했듯 우버는 On Demand 운수 서비스를 하는 곳이다. 이것이 단순히 ride sharing만 뜻하지 않는다. 교통수단을 활용할 수 있는 다양한 것에 접목할 수 있다.
이처럼 조직의 vision이 상위 레벨에 있으면 그 하위 카테고리에 만들 수 있는 것들의 폭이 넓어진다. 더불어 회사의 vision이 있어야 하는 이유이기도 하다.
Q. 아이디어를 공개했다가 다른 팀에서 훔쳐가면 어떻게 하나?
이런 우려는 한국 회사들의 팀이 생성되는 과정에서 비롯된 게 아닐까 생각한다.
경험상 우리나라 회사는 어떤 목적을 가지고 큰 조직을 새로 만들면 그 하위에 그 일을 해야 할 것 같은 이름을 붙인 팀을 만든다. 그리곤 팀의 이름에 걸맞은 일을 준다. 이 모든 것은 top 레벨에서 이루어진다.
이렇게 만들어진 팀들은 분명 윗사람들이 느낀 필요로 생겼기 때문에 처음엔 그럭저럭 돌아간다.
이후, 시간이 흐르면 시장의 동향이 변화하듯 조직의 방향과 일에도 변화가 생기게 마련이다. 필요한 일과 더는 필요 없는 일들이 드러난다.
이에 따라 애초에 만들었던 팀이 해야 할 일이 없어져도 팀은 여전히 존재하므로 무슨 일이든 줘야 하는 상황이 발생한다. 그 뒤로는 스스로 존재해야 하는 이유를 증명하기 위해 이런저런 일을 찾고, 다른 팀의 아이디어를 기웃거리면서 본인의 것으로 만드는 일도 생긴다.
그러다 보니 비슷한 일을 하는 팀들이 많아지고 비슷한 역할을 하는 사람들이 여기저기 있지만, 팀별로 성과를 측정하기 때문에 아이디어를 뺏기지 않으려고 교류는 하지 않는다.
실리콘밸리에선 어떤 팀에 있던 누군가가 무언가에 불편함이나 필요를 느껴 어떤 일을 시작하고, 그걸 오픈해서 관심 있는 사람들이 모여들어 그 일에 기여한다. 그 일은 결국 그 팀의 일이 되거나 그 일을 하는 새로운 팀이 생겨서 온전히 그 일을 자신들의 일로 만든다. 시간이 지나면서 점점 더 기여하는 사람들이 늘어나고, 그 일을 좀 더 해보고 싶은 사람들은 그 팀으로 조인하는 그런 구조이다.
이 두 가지는 시작점이 다르다.
전자의 경우 세부적인 업무까지 위에서 만들어주어 구성원들은 그에 들어맞는 일만 해야 하는 경우이고, 후자는 구성원들이 자발적으로 내 일을 찾아냈기 때문에 개인에겐 주인의식(ownership)이 생기고, 팀의 업무는 언제든 다른 관심사로 확장될 수 있다.
Q. 아키텍처는 아키텍트 업무를 하는 사람들이 만들고 최종 확정은 대표 아키텍트가 해야지 그걸 공유하면 책임은 누가 지나?
아이디어가 서비스로 변해가는 이 과정 어디에서도 이 일을 해도 되는지 누군가에게 허락을 받거나, 이런 구조로 아키텍처를 가져가도 되는지 임원의 허락을 구하는 일이 필요하지 않다. 어떤 구조를 가져갈 것인지, 어떤 방식으로 구현해나갈지 등에 대한 모든 결정은 처음 RFC를 적었던 사람(document owner)의 몫이다.
다른 사람들에게 받은 리뷰와 피드백은 그 사람들이 대신 결정하도록 하기 위함이 아니다.
불편함과 요구(needs)를 나 혼자만 느끼는지 아니면 다른 사람도 느끼는지, 그리고 그걸 해결할 방안을 나는 A라고 생각하는데 이것 뿐인 것인지 아니면 다른 방안도 있는 건지, 만약 있다면 내가 생각했던 방법과 비교해서 다른 방법들이 가진 더 좋은 점이 뭔지, 우려되는 점은 뭔지 등에 대한 정보를 여러모로 얻는 과정이다.
이렇게 여러 사람이 리뷰한 결과는 기록에 그대로 남지만, 그 누구도 이 방법을 쓰라고 강요하거나 대신 결정해주진 않는다. 함께 하는 많은 사람의 개발 경험을 바탕으로 서비스를 만들기 위한 다양한 선택지와 가능성을 열어두고 의사결정에 도움을 주는 용도지 ‘네가 이렇게 하라고 했잖아’ 처럼 책임을 묻기 위한 용도는 아니다.
책임이라는 단어를 잠시 짚고 넘어가면, 책임이라는 단어는 영어에서 두 가지로 표현되는데 responsibility와 accountability이다.
Responsibility는 기능적인 측면을 강조한 의미이다. 내가 어떤 일을 맡았을 때 맡은 일의 타이틀이 가지는 의무를 뜻한다. 우리가 흔히 ‘책임감 있다’라고 말하는 것이 responsibility이다.
Accountability는 타이틀이 주는 이름값에 윤리적인 것과 지배구조에 대한 의미도 내포하고 있어서, 어떤 일이 발생했을 때 누구의 책임인지 판단하는 의미가 담겨있다. 따라서 자신이 한 행동에 대한 영향에 대해 책임을 지고, 그것에 대하여 비판받을 때 설명할 수 있는 것을 말한다. 흔히 일이 잘못됐을 때 책임을 물어야 한다고 할 때의 책임이 accountability이다.
Responsibility는 자발성을 내포한다. 이는 외부에서 줄 수 있는 성격의 것이 아니므로 자발적인 책임감을 느끼게 하려면 스스로 결정권을 가지게 하는 수밖에 없다.
이처럼 우버에서는 UberEATS가 나오고, Google에서는 20% time rule(직원이 일하는 시간 중 20% 시간을 내서 프로젝트를 하는 것)을 통해 Gmail이 나오는 등 어떤 직원이 자발적으로 프로젝트를 시작한 것들이 결국 서비스로 출시되어 더 많은 사람이 편리하게 사용하고 있다.
도대체 우버와 구글은 도대체 뭐가 다르기에 개발자들이 이렇게도 자발적으로 아이디어를 내서 프로젝트를 하는 걸까?
회사의 비전이 필요한 이유
얼마 전 Uber의 CEO가 5년 안에 샌프란시스코 집값을 내리겠다고 선언했단다. 의문이 생긴다.
'아니, ride sharing을 하는 회사가 임대 사업을 하는 것도 아닌데 집값을 어떻게 내리지?'
Bay Area 지역을 보면 차가 많고, 혼자 타는 차도 많고 대기오염도 높다. 그런데 Uber가 생긴 이후에 샌프란시스코 지역에서 차량 소유율이 낮아졌고 대기 오염도가 낮아졌다고 한다. 심지어 샌프란시스코보다 심했던 LA는 효과를 더 많이 봤단다.
차를 팔아버렸으니 더는 차고가 필요 없어져서 1층 차고는 방으로 꾸며서 싸게 빌려주고, 새로 짓는 집들은 주차장이 없으니 좀 더 싼 주택을 짓도록 유도하는 효과도 있다고 한다. 또, 샌프란시스코에 사는 사람들은 집에서 음식을 해먹기보단 사 온 음식을 데워먹는 정도다. 그럼 음식을 싸게 배달시켜 먹으면 어떨까?
즉, '집값을 내리겠다'는 말은, 직접 주택 사업을 하진 않지만, 우리가 하는 일로 인해 집에 주방도, 주차장도 필요 없는 집을 공급하여 5년 안에 샌프란시스코의 집값을 내리는 데 기여하겠다. 는 뜻을 내포한다.
아마 이런 상위 레벨의 비전이다 보니 서비스 확장의 폭이 넓고, 구성원들은 누구든 나의 불편함과 요구(needs)에서 생긴 아이디어를 새로운 서비스로 만들길 시도하며, 그걸 회사의 비전과 연결하여 비즈니스화할 수 있는 것이다.
도대체 왜 스타 플레이어들이, 그 많은 개발자가 Uber로 모여드는 걸까?
실리콘밸리의 스타 플레이어들이 최근엔 Uber로 이동하고 있다고 한다.
2015년 말까지 3,000명을 만들겠다던 Uber는 2016년 5월 현재 10,000명이 되었다고 한다.
CEO가 했다는 저 말을 비춰보아, 내가 만들어낸 코드가 그저 돈을 버는 것에서 그치는 것이 아니라 사회문제를 개선하는데 일조하고 궁극적으로 세상을 바꾸는 일에 기여한다는 느낌을 받는다는 것이 Uber로의 합류를 선택하는 데 상당 부분을 차지하지 않았을까?
