티스토리 뷰

얼마전 김상훈님이 운영하는 "Interpreting Compiler 블로그"에서 "카카오와 페이스북이 지루함과 싸우는 법"을 읽게 되었다. 김상훈님은 IT 관련 이야기를 주로 다루시는 분으로 구글 및 해외의 다양한 IT 기업에 대한 이야기를 담론으로 소개하고 있는 분이다. 


이글을 읽으면서 들었던 생각은 기업이 문화를 만들고 특성을 만들어 가는 것이 얼마나 험난하고 어려운가를 깨닫게 됬던 것 같다. 김상훈님은 지루함이라는 단어를 통해서 최근 주목 받고 있는 IT 기업들의 기업 문화를 소개하고 있다. 기업이 생산적이고 능동적으로 발전하기 위해서는 '지루함'을 없애야 한다는 것이다. 


얼핏 온라인 서비스 회사를 말하며 지루함을 이야기 한다는 것이기에 서비스가 지루해지지 않게 해야 한다는 말로 착각 할 수도 있을지 모른다. 그런나 이분의 이야기는 서비스에 대한 지루함이 아니라 바로 조직 내부에 대한 지루함을 이야기하고 있는게 특징이다. 조직에 긴장감이 떨어지고 지루함이 만연하면 그 조직은 발전하기 힘들다는 것이다. 


오늘은 이와 관련한 이야기를 한번 살펴볼까 한다.




 


기업문화에 있어서의 지루함이란?


만약, 기업에서 특정 프로젝트 개발을 위해서 기획, 디자인, 개발 일정에 따라 일정한 시간이 만들어졌다고 하자. 기업의 고유한 개발 프로세스에 따라서 개발을 하면서 조율해 3~4달의 시간이 걸렸다고 가정할때, 어떨까 매우 Activity하게 조직이 돌아갈까? 실제 이과정을 접해 본 독자라면 알겠지만, 실제 누수되는 시간되 있고 조율후 각 단계별 프로세스를 다시 거치는 기간동안 유휴 시간등이 발생한다. 


개발자는 그 시간동안 꼼짝없이 개발이 아닌 외적인 일에 시간을 투자해야 하는 상황이 발생할 수 있다. 이런 상황이 반복되면 매너리즘에 빠지고 지루함에 빠져, 기업 생활에 있어서 반감이 생길 수 있다. 개발자가 원하는 일을 하는데 시간이 너무나 많이 걸리기 때문일 것이다. 


그런 이유들 때문에 다양한 기업들이 조직 내부에 지루함을 없애기 위해 노력하고 있고, 실제 카카오의 경우도 다음과 같은 조직 구성을 통해서 능동적인 조직을 만들 수 있도록 노력하고 있다는 것이다.  


이상혁 카카오 최고개발책임자(CDO)는 인터뷰에서  카카오를 지속적인 신규 서비스 개발을 위한 ‘혁신 주도형 조직’ 으로 만들여 졌다고 이야기 했다. 이를 위해 사내 직원 모두가 손쉽게 자신의 아이디어를 어디에서든 게재 할 수 있게 했고, 반응(주로 댓글)이 좋을 경우 팀을 꾸려 실제 프로젝트가 진행 될 수 있도록 유연한 조직을 만들고 있다고 전했다.


또, 빠른 의사 결정을 위해 팀장 이외의 직책은 없앴으며, 너무나 빠르게 생기고 사라지는 조직 때문에 영어 이름을 도입해 서구식의 수평문화가 조직에 스며들도록 정책적 지원을 아끼지 않고 있다고 한다.


이런 조직적 특성화 문화를 지원함으로서 다양한 아이디어가 시도 되 능력과 아이디어 만으로 팀을 꾸릴 수 있게 된다. 이것이 카카오스토리, 카카오게임, 카카오 스타일 같은 신생 서비스를 지속적으로 출시하는 이유가 될 것이다. 끊임 없는 좋은 아이디어의 실현은 서비스에 생동감을 제공하고 기업들이 느끼는 신선함에 대한 갈증도 덤으로 해소 할 수 있을 것이다. 


문제는 그런 기업 문화를 누구나 쉽게 만들 수 없다는 점이다. 이게 바로 기업 문화의 딜레마로, 기업 문화는 만들어지는게 아니라.. 스르로 형성되는 것이라는 점을 우리는 인식해야 할 것이다. 


 


페이스북, 구글과 같은 조직의 문화를 깊숙히 이해하자.


페이스북, 구글은 대표적인 해커 문화의 상징이 된 기업들이다. 이런 기업들은 해커톤이란 행사를 통해 새로운 아이디어를 발굴하고, 이 행사에 참여하는 팀은 10명 이내로 구성한다고 한다. 그 이상의 팀은 죄악으로 여길 정도인데, 이는 너무 많은 인원은 유연성을 떨어뜨리기 때문이라고 한다. 작은 팀으로 확실하게 팀내의 아이디어와 생각을 서로 이해할 수 있게 유지시키는게 이런 유연한 조직으 큰 특징이라고 한다. 


그렇다면, 여기서 엔지니어들 중심의 기업은 이런 해커톤 같은 행사를 통해서 엔지니어들에게 새로운 도전 의식을 제공하지만, 반대로 개발자가 아닌 직군에서는 어떻게 유연성을 확보해야 할까?


김상훈님은  구글에서 일하다 퇴사후 타파스 미디어라는 회사를 창업한 김창원 대표의 사례를 통해 이에 대한 실마리를 제공하고 있다.


창업한 김창원 대표는 구글이 자랑하는 20%의 자유시간으로 새 일을 해보지 그랬느냐는 질문에 “그건 엔지니어에게 허락된 시간이고, 엔지니어가 아닌 나머지 스탭 부서 직원들은 120%의 시간을 회사 일에 바쳐도 부족하다”고 말했다.  회사 문화가 엔지니어 위주라 나머지 지족은 서포터 기능에 초점을 맞춰야 한다는 이야기..


카카오 이수진 홍보팀장도 “회사의 모든 자원이 개발자 우선으로 쓰이기 때문에 다른 모든 직군은 이들을 잘 도와주기 위해 존재하는 것”이라고 정의 했다. 회사가 제품을 개발하는 회사라면, 개발자에게 천국을 만들어주는 게 정답이고 그렇게 하면 이런 핵심인력들이 하고 싶은 일만 해도 회사는 돌아간다. 


다시 말하면 개발 중심의 서비스 조직이나 소프트웨어 개발 조직이 유연성과 창조성을 발휘하려면, 개발 직군이 마음껏 창조적 활동을 할 수 있는 회사의 시스템이 잘 갖추어져 있어야 한다는 이야기다. 


고로 개발 직군이 아닌 직군들은 더 많은 일을 해야 한다. 제품 출시에 따른 마케팅과 모니터링, 피드백을 지원해야 하고, 다양한 문제 요소들을 파악하고 서비스가 잘 굴러 갈 수 있도록 운영에 참여해야 한다. 어떤 방향이든 개발직군이나 비 개발직군 모두 창조적 일을하거나 서포트를 하기 위해선 모든 영역에서 지루함이 배제될 수 있다. 


형평성 문제는 있을 수 있겠지만, 관료화 문제를 해결하기 위해서는 이런 소규모 그룹 단위의 조직 구성이 최적이 아닐까란 생각이 들었다. 


 


개발지군의 의무도 이해해야?


그렇다면, 개발 직군은 자기가 하고 싶은 것만 개발하면 끝날까? 전혀 그렇지 않다. 개발을 통해 문제가 되는 내용들은 충분히 검토해서 개선해야 한다. 이 개선의 방향은 자신의 창조적인 업무에 시간을 투자 할 수 있는 방향이어야 한다는 깊은 공감대가 조직 내부에 뿌리 내리고 있어야 한다는 것이다. 이에 대해 김상훈님의 정리한 내용을 요약해 보면 이렇다. 


창조적 업무를 하는 개발 직군이라도 단순 반복적인 지루한 일이 있다. 페이스북에선 이런 문제를 해결 하기 위해서 “자동화될 수 없는 단순반복작업은 없다”고 주장하며 엔니어에 대한 과제를 지워준다고 한다.


첫째는 스스로 정말 하고 싶은 일을 할 수 있게 만들기

둘째는 스스로 하기 싫은 일은 기계가 처리 할 수 있도록 만들기


재미있지 않은가? 자기가 원한은 일에만 몰두하게 하되, 하기 싫은 일이 발생 할 경우 자신이 아닌 시스템이 처리하게 문제를 해결하게 하는 정책을 지원한다. 만약 이 두가지 중 하나라도 수행하지 못하는 인재라면 회사를 떠나야 한다고 하니 페이스북이 모태 스타트업에서 이렇게 대기업으로 성장하는 과정에 얼마나 개발자의 창의적 문화를 수용하고 개선하기 위해 노력해 왔는지 알 수 있다는 생각이다. 

이렇게만 보고 우리도 이걸 적용해 보자 하면 큰일날 소리다. 많은 시행 착오를 거치면서, 개발자들의 업무와 성과를 평가하고 이에 참여 할 수 있는 시스템과 프로세스를 이들은 구축해 왔을 것이다. 조직 규모에 따라서 이 시스템은 다양한 변수가 존재했을 것이고 그런 과정을 거치면서 대규모 조직에 맞는 기업문화와 이를 지원하는 기업의 시스템이 완성 됬을 것이라고 판단해 볼 수 있다. 


하기 싫은 일이 발생 했을때, 이런 반복적인 작업을 하는 개발자도 없을 테지만, 이런 부분을 지적하고 개선할 수 있는 문화적 토대를 어떻게 만들었을까를 고민해 보면 쉽게 답나오는 이야기는 아니라는 생각이다. 


 


기업 오너의 마인드도 바뀌어야 


‘해커먼스’(Hackamonth)라는 말을 들어봤는가?  페이스북의 특이한 제도로 완전히 새로운 프로젝트를 1달 정도만 하고 자신의 팀이나 프로젝트에 돌아와야 한다는 제도란다. 지루함 없이 일할 수 있는 긴장감을 유발하는 열린 조직을 만들기 위한 제도로 한달만에 프로젝트를 완료 할 수 있는가에 대한 의문이 있을 수 있지만, 이들은 이런게 문화적으로 뿌리내리고 있고, 이런 단기적 성과 요구를 통해서 프로젝트 완수에 대한 일정한 부담을 제공해 생산성을 높였다고 볼 수 있다. 


다만, 이런 정책적 지원들은 개발자가 매너리즘에 빠지지 않고 다양한 사고와 조직에서 문화적으로 충돌하며 새로운 것에 끊임 없이 도전하게 만들기위한 정책이지 생산성을 강조하는 정책이 아니라는 점이다. 


또한, 이것을 인센티브나 성과 측정의 하나의 기능으로 활용하는 것은 조직을 경직 시킬 수 있다. 스타트업 같은 조직을 대기업에서 유지하려면 성과 측정과 방법에 있어서도 이런 조직에 맞는 룰을 만들고 찾아야 한다. 


스타트업 입장에서도 이런 문화를 쉽게 따라하는 것은 개인적으로 반대한다. 이들이 이룩한 문화는 3~4인 조직의 문화가 아니다. 이미 대기업이 된 기업들의 문화이고 시스템적으로 개발자들의 창의성과 능동성을 보장하기 위한 다양한 장치가 마련되어 있다. 이미 시스템적으로 잘 굴러갈 수 있는 토대가 닦여 있는 조직에 것을 스타트업 같이 불안전하고 갖추어지지 않은 조직에 도입한다는 것은 운전도 할 줄 모르면서 자동차를 운전하는 것과 똑 같은 일이라고 지적하고 싶다. 


필자 역시 스타트업 초기에 구글의 20% 개인화 프로젝트를 도입해 보려고 했으나? 실제 현재 몸담고 있는 조직은 그런 프로젝트를 수행 할 여력이나 시스템이 갖추어져 있지 않았다는 사실을 간과했다. 조직은 늘 자신들의 규모에 맞는 정책과 시스템이 필요한데, 이런것에 대해 고민해야지 남의 것만 쫒는 것을 그래서 반대하는 것이다. 


페이스북이 지루함과 싸운다는 이야기를 읽고 개인적으로 신생 스타트업들에 해주고 싶었던 이야기는, 페이스북 모델을 따르라는게 아니라, 지신들의 조직 상황에 맞게 이런 긴장감을 유지 할 수 있는 방법을 고민해 보라는 조언을 하기 위함임을 잊지 말아주길 바라며 이번글 마무리하는 바이다. 



해당 글은 iamday.net의 IT 칼럼 (http://www.iamday.net/apps/article/talk/1892/view.iamday)에 기고 된 글입니다. 


댓글