EO

에어비앤비가 연내 상장에 박차를 가하고 있습니다. 이들은 코로나로 인해 계획에 큰 차질을 빚었음에도 불구하고 탈도시 전략 등으로 올 3분기 1,900만 달러(한화 약 210억 원)의 순 이익을 올리며 흑자 전환에 성공했는데요. 공유경제, 여행과 같이 팬데믹으로 타격이 심한 분야에 걸쳐 있음에도 그 위용이 실로 대단하다고 할 수 있습니다.

그만큼 에어비앤비의 성장 전략, 조직문화에 이전보다도 더 많은 관심이 갈 수밖에 없는데요. 유호현 님은 그런 에어비앤비를 몸소 겪으며 조직을 진정으로 성장시키는 역할조직과 기여주의를 깨닫고 한국으로 돌아와 스타트업을 하고 있습니다. 개발자로서 일을 하며 여러모로 행복했다는 그의 실리콘밸리 이야기를 EO와 함께 직접 들어보시죠.

Q. 자기소개 부탁드릴게요.

안녕하세요, 저는 샌프란시스코 에어비앤비 결제팀에서 소프트웨어 엔지니어로 일했던 유호현입니다. 그전에는 3년간 트위터에서 자연어 처리팀과 검색팀에서 근무했고요. 현재는 올해 9월 출시한 정치 SNS 스타트업 옥소폴리틱스를 창업해서 운영하고 있습니다.

Q. 2019년에 출간하신 <이기적 직원들이 만드는 최고의 회사>에서 조직문화를 중심으로 여러 가지 이야기를 담아내셨잖아요. 그중 첫 번째가 위계조직과 역할조직에 관한 이야기였는데요. 우선, 두 조직의 기본적인 개념부터 설명해 주시면 어떨까요?

위계조직은 위계가 제일 높은 사람이 모든 결정권을 갖는 조직입니다. 맨 위에서 내리는 결정을 위해 많은 보고서를 써야 하는 구조를 띠죠.

역할조직은 하향식의 위계조직과 달리 각 역할을 맡은 전문가들이 결정권을 갖는 조직입니다. 스스로 결정을 내리기 때문에 자신이 한 일에 대한 책임을 지고, 윗사람 눈치를 볼 필요 없이 개인의 커리어를 만들어나갈 수 있어요.

Q. 보다 실질적인 예시로 두 조직의 특징을 짚어주실 수 있을까요?

직책의 이름만으로도 이 특징이 자명하게 드러나는데요. 우리나라에서는 '과장', '부장'이라는 직책으로 누구에게 결정권이 있는지를 명확하게 하잖아요. 반면, 실리콘밸리에서는 직원을 '엔지니어', '디자이너'라고 부르기 때문에 엔지니어링에 관한 결정은 엔지니어가 내리고, 디자인에 관한 결정은 디자이너가 내려야 한다는 인식이 명확하죠.

예를 들어, 디자이너가 핸드폰을 아주 예쁘게 디자인했다고 쳐볼게요. 사장님한테 딱 가져갔더니 사장님이 별로라면서 싫대요. 위계조직이라면 그 디자인은 시장에 나갈 수 없습니다. 역할조직은 아니에요. 사장님이 싫다고 해도 그건 디자인 비전문가이자 경영전문가인 사장님의 개인 의견일 뿐이에요. 참고는 하되, 결정은 디자이너가 하죠.

그래서 위계조직에서는 제품이 시장에 나갔을 때 안 되어도 사장님 책임, 잘되어도 사장님 책임이에요. 최종 결정을 사장님이 내렸으니까요. 역할조직에서는 안 되어도 해당 파트를 담당한 내 책임, 잘되어도 내 책임입니다. 

근데 디자이너가 결정하는 역할조직에서는 안 되든 잘되든 내 책임이에요. 만약 잘되면 커리어가 됩니다. 나중에 다른 회사에서 "그 핸드폰 디자인한 사람 누구야? 데려와"라고 할 수도 있겠죠. 그러면 그럴수록 축구선수처럼 몸값이 올라가고요. 즉, 개인이 커리어를 만들고, 전문화되어 이적 시장이 활발해지는 모델이 역할조직인 거예요.

Q. 축구선수를 말씀하셨는데, 지금 가장 뛰어난 한국인 프리미어리거일 뿐만 아니라 전 세계로 보아도 가장 뛰어난 공격수 중 한 명인 손흥민 선수로 한 번 더 이야기를 풀어주셔도 재미있을 것 같아요.

그렇겠네요. 손흥민 선수가 현재 토트넘 홋스퍼(이하 토트넘)에서 엄청난 활약을 하고 있잖아요. 지금은 토트넘에 있지만, 개인적인 커리어를 위해 열심히 골을 넣고 인정받으면 다른 팀에 갈 수 있겠죠. 그 과정에서 토트넘은 엄청나게 많은 이득을 보죠.

저 역시 에어비앤비에서 열심히 일했던 이유가 그 일들이 제 커리어에 도움이 된다고 생각했기 때문입니다. 다른 회사의 면접을 보거나 지금처럼 스타트업을 시작하면 필요한 스킬을 익히기 위해서는 실전 경험을 쌓아야 한다고 본 거죠.

간단히 정리하면 역할조직에서는 나를 위해서 열심히 할 수밖에 없는 겁니다. 에어비앤비가 사랑스러워서, 또 하나의 가족 같아서가 아니라 스스로 강한 동기를 갖고 내 커리어를 잘 쌓고 싶으니까요. 마치 손흥민이 지금은 토트넘에서 계속 뛰긴 해도 이 팀을 마냥 자신의 일생을 책임져줄 팀으로 생각하지 않는 것처럼 말이죠.

Q. 그럼 에어비앤비에서 전체가 완벽한 역할조직인 조직을 경험하신 건가요?

우선, 에어비앤비는 다양성을 중요시하는 조직입니다. 어떤 매니저가 위계조직같이 팀을 운영해도 그냥 용인해요. 그냥 그 사람의 스타일인 거죠. 그 밑에 있는 직원들은 조금 괴롭겠지만요.

제가 속한 역할조직 스타일의 팀이 위계조직이었던 옆 팀과 프로젝트를 같이 진행한 적이 있었는데요. 1년 6개월짜리 프로젝트인데도 옆 팀은 6개월 만에 프로젝트를 끝내려고 엄청 빨리하더라고요. 왜 이렇게 급하게 하냐고 물었더니 반년 만에 끝내면 매니저가 승진시켜준다고 그랬다는 겁니다.

그 팀은 진짜 6개월 만에 프로젝트를 끝냈습니다. 근데 너무 빠르게 진행했다 보니까 버그도 있고, 테스트도 잘 안 되어 있었어요. 신기한 게 그럼에도 돌아가는 코드를 만들어 놨더라고요. 문제는 승진이 목표였다 보니까 프로젝트가 끝나고 팀을 나가버리는 겁니다. 아마 계속 유지보수를 하기 싫었던 거겠죠.

나중에 저희 팀도 프로젝트를 다 끝내서 옆 팀과의 통합을 시도했는데요. 옆 팀이 개발한 것이 혼자서는 간신히 돌아가는데, 통합하니까 안 돌아가더라고요. 당장 끝냈을 때는 금방 끝났다 싶었겠지만, 길게 보았을 때는 좋은 선택이 아니었던 거죠. 처음부터 엉망으로 만들어 놓으면 버그를 찾기가 엄청 어렵거든요.

결국, 그 문제 때문에 전체 프로젝트가 엄청나게 딜레이됐고요. 이후 추가 진행을 1년이나 더 해야 했습니다.

Q. 위계조직의 문제점을 보여주는 적나라한 예시라고 할 수 있겠네요.

네, 위계조직 스타일로 소프트웨어를 만들면 빠르기만 할 뿐, 장기적인 관점에서 막대한 추가 부담이 생기는 거예요. 코드 재사용성은 떨어지고요. 반대로 코드 재사용성을 최대한 올려놓으면 레고 블록처럼 깔끔한 모듈이 나옵니다. 그걸 쉽게 오픈소스*할 수도 있고요.

* 누구나 특별한 제한 없이 사용할 수 있게끔 소스 코드를 공개하는 행위

위계조직이 많은 우리나라는 코드 퀄리티가 안 되어서 오픈소스를 못 하는 경우가 많아요. 오픈소스의 코드 퀄리티는 굉장히 높은데, 말씀드린 것처럼 위계조직에서는 코드 재사용성이 떨어지니까요. 업계 전체적으로 큰 손해를 보는 셈이죠.

또 하나 위계조직의 문제를 짚자면, 고립된 개발 방식(Siloed Development)가 있습니다. 사일로는 농촌에서 분뇨를 담는 등 여러 용도로 쓰이는 긴 원통을 말하는데요. 이 개발 방식에 따르면, 일단 매니저가 설계한 대로 일을 쪼개서 나눠줍니다. 개발자는 배분받은 일만 알겠죠. 옆 사람이 뭘 하는지 모르고요. 그럼 코드 리뷰가 안 됩니다.

이런 상황을 방지하기 위해 제가 일했던 에어비앤비 팀에서는 시간이 오래 걸리더라도 다 같이 프로젝트를 만들어 갔습니다. 모든 엔지니어에게 전체 맥락을 이해시켜놓고 '너 이거 해'라는 식으로 지시하지 않았어요.

그래서 저희 팀이 5명이면 4명이 저에게 제가 쓴 코드에 관해 물어볼 수 있습니다. 그로써 모두가 작업 내용을 똑같이 알고 있게 되는 거죠. 그 내용을 다이어그램이나 문서로 정리해둬서 새로운 사람이 합류해도 설명하기 쉽고요. 실질적으로 보면 제가 휴가를 편히 다녀올 수 있는 조건이 갖춰져 있다고 할 수 있습니다.

위계조직에서는 그럴 수 없어요. 내 일을 나만 알고 있으니까 휴가를 못 가거나 가더라도 마음이 불편해요. "나 아니면 회사 안 돌아가"라고 하시는 분들이 종종 있는데요. 그런 사람들은 사실 어떤 정보를 독점하고 있을 가능성이 커요.

이렇게 위계조직은 특성상 모든 사람이 병목이에요. 역할조직에서는 그 병목을 없애는 게 굉장히 중요합니다. 5명 중 1명이 빠지면 속도가 80%는 유지해야지, 50%나 0%까지 낮아지는 건 이상하잖아요. 팀 내에 심각한 문제가 있지 않은 한 그건 정상적이지 않아요.

Q. 실제로 에어비앤비에서 어떤 사고가 일어났을 때의 특별한 경험담이 있나요? 정보의 공유 측면에서 일반적인 위계조직과 다른 무언가가 있을 것 같은데 말이죠.

제가 회사에서 버그를 하나 만들어서 20,000달러(한화 약 2,200만 원)가 날라간 적이 있습니다. 그 돈들이 사람들의 계좌에 들어가서 찾아올 수도 없는 상황이었어요. 그걸 2시간 만에 발견하고, 이런 생각을 하며 밤새 이불킥을 했죠. '내일 회사 가면 죽었다', '내 월급에서 까야 하나', '2,000만 원이면 꽤 큰 돈인데'

다음 날 회사에 가서 매니저한테 실토했습니다. “매니저, 나 어제 20,000달러 날렸어”라고 했더니 매니저가 포스트 모템을 쓰자고 하더라고요. 포스트 모템은 '죽음 후', '사후', 다시 말해 사후 부검을 뜻합니다. 이걸 하면 발생한 문제에 관해 무척 자세하게 써야 해요. 요약부터 언제 발생하고 발견한 문제이며, 어떻게 멈추게 했고, 개선책까지 말이죠.

무엇보다 왜 이 문제가 일어났는지, 즉 근본 원인을 써야 하는데요. 이 근본 원인을 발견하는 방법이 재미있습니다. '왜'를 5번 물어본다고, '5 Why'라고 부르는데요. 가령 이런 식입니다.

20,000달러를 날렸다. 왜?

내가 쓴 코드에 버그가 있었다. 왜?

여기서부터 '아, 내가 XX이다'라고 말하고 싶어지는데요. 잘못된 가정을 한 채로 내가 했던 것처럼 해도 계좌에서 돈이 나가지 않고 시스템 안에 있을 줄 알았다. 왜?

또 '내가 부주의해서'라고 하고 싶은데, 그게 아니라 시스템 문서를 충분히 읽지 않았다. 왜?

이 과정에서 중요한 건 시스템이 뭐가 잘못됐느냐는 겁니다. 왜 문서를 제대로 안 읽고도 코드를 쓸 수 있었는지까지 시스템 차원에서 접근하는 거예요. 우리나라 사람들이 항상 직장에서 사고가 터지면 본인이 잘못했다고 말하는 것과 사뭇 다르죠.

그렇게 근본 원인을 찾아내면 실행 계획을 짭니다. '앞으로 유닛 테스트*를 만들어서 같은 문제가 또 발생하면 절대로 코드 병합이 안 되게 조치한다' 같은 식으로요.

* 컴퓨터 프로그래밍에서 소스 코드의 특정 모듈이 의도된 대로 정확히 작동하는지 검증하는 절차

Q. 포스트 모템을 하면 그게 누구에게까지 전달되나요?

일종의 시말서 같은 포스트 모템에 처음부터 끝까지 뭐가 문제였는지를 나열해서 다 쓰고 제출 버튼을 누르려고 하니까요. 그 옆에 '제출 버튼을 누르면 이 내용이 전 직원에게 이메일로 전달됩니다'라고 쓰여 있는 겁니다.

별생각이 다 들었어요. '나 에어비앤비에서 끝났다', '전사적으로 완전히 부주의한 엔지니어로 찍히겠구나', '내일부터 내 별명은 20,000달러가 되는 건가?'

근데 의외의 답장이 오더라고요. 열어보니 '이전에도 이런 일이 있었는데, 그때는 포스트 모템을 안 해서 또 같은 일이 반복됐다. 근데 너가 포스트 모템을 책임졌다' 같은 내용과 함께 고맙다고 하는 거예요. 여기서는 책임을 진다는 개념이 발생한 문제를 제대로 고치고, 앞으로 동일한 문제가 절대 안 일어나도록 대책을 마련하는 행동인 겁니다.

그러고 나서 생각해보니까 위계조직에서는 포스트 모템으로 재발 방지를 할 수가 없겠더라고요. 사고가 났다고 보고하면 저는 과장님에게 혼나고, 과장님은 부장님에게 가서 혼나니까요. 그때 최선의 선택은 내 선에서 숨기는 것뿐입니다. 제가 안 덮어도 부장님에게 혼나기 싫으니까 과장님이 덮어주실 거고요.

저희는 그러지 않고 실수를 통해 체계적으로 배우려 해요. 이를 위해 그냥 포스트 모템이 아니라 '비난하지 않는 포스트 모템'을 하려 하고요. 아무리 포스트 모템이 중요하다고 해도 '너 때문에 20,000달러 날아갔잖아' 같은 소리 한 번이라도 들으면 그냥 뭐든 하기 싫어지니까요.

비난하는 대신 '네가 잘못하긴 했지만, 온전히 네 잘못이라기보다는 이런 일이 일어날 수밖에 없었던 시스템이 문제였으니 시스템을 고치자'라고 접근하는 거죠. 에어비앤비뿐만 아니라 실리콘밸리의 기업들은 이렇게 실수를 통해 계속해서 배움을 축적해 나가는 거 같아요.

Q. 성과주의와 기여주의에 대한 이야기로 이어가 보겠습니다. 우선, 기여주의라는 다소 생소한 개념 이전에 성과주의 이야기부터 조금 해볼까요?

옛날에는 연공서열제에 따라 직원들이 돈을 받았잖아요. 호봉제니까 열을 열심히 하든, 하지 않든 간에 승진하면 돈을 더 많이 받았죠. 저는 그와 가장 비슷한 개념이 공산주의라고 생각합니다. 둘 다 위에서 다 계획해서 똑같이 나눠 가지니까 열심히 할 필요가 없어지는 단점이 있잖아요.

연공서열, 호봉제로 하기 때문에 일을 열심히 하든 열심히 안 하든 올라가면 돈을 받았었죠. 제일 비슷한 걸 찾았는데 공산주의였어요. 왜냐하면 위에서 다 계획해서 똑같이 나누니까 열심히 할 필요가 없잖아요. 그게 공산주의의 단점이잖아요.

그 문제를 해결하려고 나온 게 성과주의예요. 성과주의는 모든 걸 획일화된 수치로 평가합니다. 10개 만든 사람한테 5개 만든 사람보다 2배의 연봉을 주는 거예요. 표면적으로는 좋아 보일 수 있는데요. 문제는 보여주기식 일 같은 게 생겨나면서 성과의 왜곡이 일어납니다.

엔지니어를 평가할 때, 코드 줄 수를 기준으로 삼으면 엔지니어들이 이상한 짓을 하게 되는 식이죠. 코드 1줄이면 끝날 일을 10줄씩이나 짜는 등 비효율적인 프로그래밍을 하게 되는 겁니다.

Q. 그럼 기여주의는 무엇인가요?

제가 기여주의라는 말을 만든 건 우리나라와 실리콘밸리가 생각하는 성과주의가 서로 다르다는 생각이 들었기 때문입니다. 기여주의는 획일화된 기준으로 사람을 평가하지 않습니다. 대신 팀과 회사의 미션이 있으면 '너는 우리 팀과 회사를 위해 어떤 기여를 했니?'라고 물어보죠.

실제로 실리콘밸리에서는 엔지니어를 평가할 때 주관식으로 물어봅니다. '당신은 팀의 성공에 어떻게 기여했습니까?', '당신이 지금까지 했던 일 중에 제일 잘한 건 무엇인가요?' 이런 식으로요. 그만큼 각자의 유니크한 장점을 캐치할 수 있는 평가 방식이 기여주의입니다.

또 축구로 예를 들어볼까요? 박지성은 현역 시절에 골을 많이 넣는 선수가 아니었습니다. 그렇다고 어시스트를 많이 하는 선수도 아니었죠. 하지만 박지성은 수비가 뛰어나고 공수 균형을 잘 맞추는 특이한 공격수로서 맨체스터 유나이티드에서 엄청난 성과를 냈어요.

이 특이한 공격수를 성과주의로 평가하면 골과 어시스트가 모두 많지 않은 그저 그런 선수에 지나지 않을 겁니다. 기여주의로 평가하면 얘기가 달라지죠. 이 방식에 따르면 공수 조율은 물론, 상대편 공격수를 꽁꽁 묶어놓는 데다 공간 창출까지 잘하는 엄청난 선수로 인정받을 수 있어요.

즉, 성과주의에서는 어떤 지표를 위해 보이는 일만 하기에 사람들이 좋아하는 일과 좋아하지 않는 일이 나뉘는 반면, 기여주의에서는 자신이 생각하기에 회사에 도움 되는 일이면 그냥 할 수 있는 겁니다.

Q. 그럼 호현 님은 에어비앤비에 계실 때, 어떤 유니크한 기여를 했다고 생각하시나요? 또, 피어 리뷰는 어떤 방식으로 진행되나요?

저는 코드를 빨리 쓰고, 유닛 테스트를 잘 붙이는 엔지니어로서 기여했다고 생각해요. 평가에 그런 내용을 써두면 퍼포먼스 리뷰를 360도로 진행합니다. 저랑 같이 일하는 모든 사람이 그 말을 토대로 평가를 하죠. 나중에 매니저가 모든 평가를 모아서 최종 점수를 주기는 하는데요. 동료들의 평가 없이 매니저가 마음대로 쓰지는 못합니다.

Q. 한국 정서상으로는 약간 살벌하게 느껴지기도 하는 것 같아요. 내가 잘하는 것을 내 입으로 얘기하는 것을 두고 직원들에게 종합적인 평가를 한다는 거잖아요.

일단 평가는 문서로 하고요. 다들 솔직하게 피드백하니까 저에게 무척 중요하고 도움도 많이 돼요. 항상 평가지에서 '잘하고 있는데, 다음 레벨로 발전하려면 무엇을 더 해야 합니까?'라고 꼭 묻기 때문이에요. 그럼 이 사람의 단점을 쓸 수밖에 없겠죠?

그럼 그 사람을 비판하려는 목적이 아니라 더 격려해주기 위한 제언을 하게 됩니다. 거기서 제 단점이 나오는 거예요. '컴퓨터 사이언스 공부를 안 했으니까 프로그래밍 공부를 더 많이 해야겠다', '더 큰 프로젝트를 맡아봤으면 좋겠다' 이런 식이죠.

또한, 정해진 영역에 따라 평가가 이루어져요. 기술은 몇 레벨, 생산성은 몇 레벨, 업무 범위는 몇 레벨 등 여러 항목에 걸쳐 평가하죠. 프로페셔널 엔지니어니까 엔지니어링 스킬을 비롯한 업무만이 기준이고, 사람을 보고서 '얘는 인간이 됐네 안 됐네'라고 따지지 않고요.

여러 항목을 놓고 보면 같은 엔지니어라도 서로 다른 유니크함을 알맞게 평가할 수 있습니다. 코드의 양 같은 표준화할 수 있는 지표로 점수를 매기지 않으니까요. 코드를 잘 쓰든, 리뷰나 설계를 잘하든 간에 함께 일하는 동료들이 생각했을 때 '당신이 우리에게 정말 큰 도움이 됐어'라고 생각하면 그만인 거예요. 기여주의 체제의 최대 장점이죠.

Q. 다음은 완벽주의와 '경험축적'입니다. 아마 현재의 IT 산업이 빨리 시도하고 빨리 실패하는 방식에 관한 이야기가 녹아 있을 것 같은데요.

맞습니다. 그전에 제조업에서는 확실히 완벽주의가 중요합니다. 냉장고가 왔는데, 문짝이 떨어지면 리콜을 해야 하는 비용도 들고 여러모로 손해가 막심합니다. 소프트웨어는 그렇지 않아요. 버그가 있으면 바로 수정할 수 있으니까요. 완벽한 제품을 내놓기보다 실수로부터 배워서 다음 버전에 적용하는 게 더 중요한 이유죠.

그래서 조직의 미션도 과거와는 많이 다릅니다. 제조업 회사의 미션은 대부분 '세계에서 제일가는 자동차를 만들자' 같은 거잖아요. 목표는 오직 자동차를 빨리 만드는 거고요. 최고가 되자는 것뿐인 만큼 미션 내용도 서로 비슷해서 이를 아는 사람이 별로 없습니다. 삼성, LG만 봐도 그렇잖아요.

그런데 실리콘밸리의 소프트웨어 회사들은 미션부터 아이덴티티를 명확하게 드러냅니다. 에어비앤비는 'Belong Anywhere', 세계 어디를 가도 우리 집처럼 느끼게 하자고 하고요. 페이스북은 '전 세계 모든 사람을 연결하자', 구글은 '정보를 모아서 모든 사람이 쉽게 쓸 수 있도록 하자'가 미션이에요.

비슷하게 '인류의 이동을 편하게 하자'라는 미션을 가진 회사가 있다면 그 회사는 수많은 방법을 고민하고, 시도하고, 실패하면서 성과를 내기 위해 나아갈 거예요. 스케이트보드도 만들어보고, 일반 스케이트보드는 방향 전환이 어려우니 핸들도 달아보고, 그것도 불편하면 자전거나 오토바이도 만들어보겠죠.

여러 가지 방안을 모색하다 보면 분명 제조업 회사보다 늦게 완벽에 가까운 제품을 만들 겁니다. 하지만 제조업 회사는 뛰어난 자동차 하나를 만들면 기업으로서 달성할 미션이 아예 없어지죠. 실리콘밸리형 회사의 미션은 이제 시작일 테고요. 나중에는 기차, 비행기, 우주선을 만들 수도 있으니까요.

테슬라가 딱 그렇잖아요. '세계 1위 전기자동차를 만들어서 시장 점유율 1위를 먹자'가 아니라 '전 지구의 에너지 문제를 해결하자'라는 미션을 내걸잖아요. 화석 연료를 없애야 하니까 전기 발전소를 만들고, 그래도 안 되면 화성으로 도망가자면서 우주 회사 스페이스 X도 만들었죠.

Q. 그 꿈이 너무 원대해서인지 그래서 일론 머스크가 한때 사기꾼이다 뭐다 말이 많았잖아요.

테슬라도 그렇고, 미션을 생각하면 다 말이 되는 회사들이에요. 미션을 생각하지 않으면 '돈도 안 되는 거 왜 해?'라는 반응이 나올 수밖에 없고요.

근데 혁신 산업에서는 이윤 창출을 목적으로 하면 망합니다. 이윤 창출을 하려면 지금까지 만든 것을 조금 개선해서 더 잘 팔면 그만인데, 미션을 이루려다 보면 이전에 없던 것을 새로 만들다 보니까 독점 시장이 생기거든요. 그러면 막대한 자본이 몰리죠. 예전과 다르게 돈 자체가 아닌 미션을 쫓아가야 돈이 생기는 구조인 겁니다.

이 점에서 우리나라 스타트업들도 혁신을 하고 싶다면 '기업의 목적은 이윤 창출이다'라는 낡은 프레임을 깨야 유리할 겁니다. 피벗을 할 때도 아무거나 돈 되는 쪽으로 하는 게 아니라 미션을 향해서 이렇게도 가보고, 저렇게도 가보는 거죠.

Q. 우리나라 스타트업 이야기를 살짝 해주셨는데요. 한국이 지금보다 더 혁신 성장을 하기 위해서는 어떤 변화가 일어나야 할까요?

제가 구글에 우리나라가 선진국이냐고 물어본 적이 있는데요. 이렇게 답이 나오더라고요. '한국은 선진국이야. GDP가 높고, 영아 사망률이 낮고, 평균 수명이 길고, 교육 수준이 높기 때문이야' 그렇지만 미국이 선진국이어도 엄청 많은 문제를 안고 있듯이 우리도 이제 선진국형 문제가 넘쳐나기 시작했습니다.

국민 소득 3만 불 시대가 열렸죠. 연봉과 최저임금이 올라가죠. 그에 따라 가격 경쟁력과 수출 경쟁력이 떨어지죠. 제조업 경쟁력을 상실해가는 사이에 중국이 올라오죠. 이런 현상이 벌어지니 임금 낮추고, 최저임금을 올리지 말라는 이야기가 개발도상국일 때는 통했습니다. 공장 일을 할 때는 시간 투입 대비 생산량이 정비례하니까요.

근데 혁신경제에서는 2명 투입하면 2배, 3명 투입하면 3배였던 과거와 달리 1명을 투입해도 10배, 20배의 레버리지를 낼 수 있으니까 그 말이 안 통합니다. 기계 공학 박사에게 무제한 자유와 경영 정보를 주고 "여기에 맞는 기계 만들어줘"라고 해서 기계를 만들면 효과가 10명 투입해서 10배 날 때보다 1,000배, 10,000배 날 수 있으니까요.

즉, 단순히 비용 등을 조절하는 게 아니라 우리만 할 수 있는 새롭고 특별한 것을 만들어야 우리나라가 새로운 시대에 경쟁력을 가질 수 있다는 겁니다. 근데 딱딱한 위계조직으로는 그럴 수 없어요. 소프트웨어 위주의 혁신 경제를 이루려면 전문가들이 각 전문 영역에서 결정을 내리면서 새로운 것을 자꾸 만들어나가는 역할조직이어야 해요.

Q. 현실적으로 한국의 현재 소프트웨어 개발 환경이 당장 겪고 있는 문제를 짚자면 어떤 게 있을까요?

실리콘밸리 개발자들이 항상 생각하는 개발 딜레마의 삼각형이라는 게 있는데요. 속도를 높이면 퀄리티가 낮아지고, 기능 수가 적어질 수밖에 없고요. 퀄리티를 높이면 속도가 떨어지고, 기능 수가 줄어들 수밖에 없어요. 기능 수를 늘리면 속도와 퀄리티가 아쉬워지고요.

그런데 우리나라에는 기획자라는 포지션이 있어서 제품의 설계가 다 되어서 나옵니다. 퀄리티와 기능 수는 고정된다는 거죠. 남은 건 스피드잖아요. 그러다 보니 빨리 만드는 개발자는 무조건 좋은 개발자이고, 느리게 만드는 개발자는 나쁜 개발자라는 인식이 있는 거 같아요.

Q. 여전히 서비스 기획자, 제품 기획자 같은 포지션을 희망직군으로 적어내는 분들이 많은데, 이에 대해서는 어떻게 생각하시나요?

기획자에서 점점 프로덕트 매니저로 가야겠죠. 지금 기획자들은 엔지니어링까지 다 설계해버리는데, 사실 이게 말이 안 되는 거거든요. 프로덕트 매니저로서 컨셉을 잡고, 요구사항을 체크하는 정도여야 해요. 우리의 고객들이 뭘 원하는지 명확하게 해야 하고요.

Q. 위계조직과 역할조직, 성과주의와 기여주의 등 조직문화에 관해 전방위적으로 이런저런 이야기를 많이 나눠봤는데요. 정리해서 마지막으로 전하고 싶으신 말씀이 있다면 부탁드릴게요.

저는 역할조직을 어떻게 만드냐는 질문보다 이 질문을 더 많이 받았는데요. '전공이 영문과인데 어떻게 실리콘밸리가 엔지니어가 되셨어요? 작년부터 제 답변은 '저 프로그래밍 타고났어요'예요. 영문과 나와서 아무나 소프트웨어 엔지니어가 될 수 있는 건 아니긴 하니까요. 

이 답이 무척 재수 없는 답이잖아요. 왜 재수가 없냐면 우리나라 사회에서는 모든 사람의 목적이 똑같았기 때문이에요. 분명 열심히 노력해서 어려운 시험 패스해서 개천에서 용 나는 게 맞는데, 타고난 애가 그냥 잘해버리면 불공평한 세상 정말 재수 없잖아요.

하지만 요즘 시대는 자신이 잘하는 걸 개발하면 시험 패스 같은 거 안 해도 되는 시대예요. 전문가와 역할조직의 시대이니 자신이 뭘 타고나고, 잘하는지를 아는 것이 중요해요. 그걸 어필까지 해도 괜찮은 다양성의 시대가 왔으니 모두 자신만의 길을 찾아가셨으면 하는 바람입니다.

* 본 아티클은 2019년 5월 공개된 <실리콘밸리 회사들이 직원들을 평가하는 법>, 2019년 5월 10일 열린 오프라인 행사 <태용의 the Real: 에어비앤비 본사 엔지니어 유호현>의 내용을 바탕에 두고 있습니다.

👆🏻 트위터, 에어비앤비에서 역할조직과 기여주의의 진수를 경험하고 한국으로 돌아와 스타트업을 창업한 유호현 님의 이야기를 영상으로도 만나보세요.

글·편집 김정원

melo@eoeoeo.net

EO(Entrepreneurship & Opportunities)