NETFLIX,실리콘밸리에서 가장 중요한 문서
같이 일할 동료를 까다롭게 뽑고, 또 많이 내보내는 곳
이번 실리콘밸리 출장에서 돌아온 후에 가장 많이 들었던 질문은,
"가장 좋았던 회사가 어디야?"라는 질문이다. 대답하기 정말 어렵더라.
'가장 좋다'라는 기준이 참 모호한데, 대신 내겐 '가장 기억에 남는 회사'가 있다.
바로 NETFLIX 라는 영화와 드라마 스트리밍 서비스 회사이다.
Netflix 에서 자체 제작한 작품들이 이렇게나 많다!한국에도 이미 잘 알려져 있듯이, 최고의 인재만 뽑고 책임과 권한을 엄청나게 부여하는 회사다.
(셰릴 샌드버그가 '실리콘밸리에서 가장 중요한 문서'라고 해서 유명해진 Netflix CEO의 조직운영 철학에 대해 담고있는 문서 : http://www.slideshare.net/watchncompass/freedom-responsibility-culture?qid=ff4280d4-e17e-4287-87a2-81e0574d1b52&v=default&b=&from_search=4)
흔히 NETFLIX를 메이저리그 팀 운영에 비유한다. 최고의 선수로 구성되어야 한다는 의지를 가지고 인재채용을 하기에 언제든 해고될 수 있는 곳으로도 유명하다.
'똥물의 유입을 막아야 한다, 암적인 존재는 내쫓아야 한다'
개인의 능력이 뛰어난 것도 좋지만 더 중요한 것은 일은 혼자 하는 것이 아니라는데에 있다. 부정적인 분위기는 금방 전파되기 때문에 똥물이 유입되어 애써 가꿔온 회사의 culture가 손상되는 것을 가장 염려하여 culture를 망치는 사람은 바로 해고된다.
이 때문에 6개월~1년 사이에 해고되는 경우도 많은데, 그만큼 사람들이 많이 들어오고 나가기 때문에 2년 근무한 직원의 입사 순서가 상위 30~40% 이내이고, 4년 근무한 사람은 상위 20% 안에 든다고 한다.
이쯤되면 이런 말이 나올 수도 있겠다.
"해고를 남발하는 무자비한 회사가 아닌가?"
NETFLIX의 평가방식은 기본적으로 peer review이다.
보스가 일방적으로 하는 평가가 아니고, 함께 일했던 동료로부터 받는 360도 feedback만 존재한다.
1. 무엇을 잘했는지,
2. 무슨 일을 추가로 해야 하는지,
3. cowork를 잘 하는지
10명 정도에게 위의 3가지 항목에 대한 feedback을 실명으로 받고,
다른 부서 사람도 feedback을 줄 수 있으며 feedback을 부탁할 수도 있다.
이는 같이 일하는 동료가 가장 잘 안다는 것에서 기반한 평가 방법으로, 회사에 필요한 성과를 낼 수 있는 사람인지, 팀의 호흡을 따라갈 수 있는 사람인지를 함께 일하는 동료들에게 확인하는 것이다.
따라서 어느날 내가 해고된다고 해도, 이런 feedback 방식 때문에 본인이 왜 해고 당했는지 이유를 알고있다.
더불어 이번 출장에선 한가지 더 눈에 띈 것이 있었다.
채용은 5년 이상 개발 경력이 있는 시니어만 뽑는다고 한다.
'들어와서 배우면서 할게요'와 같은 신입사원은 안받는다는 뜻이다.
그래서 질문을 하나 했다.
"우리나라에서 그렇게 뽑는다고 하면 청년 실업과 일자리 창출을 운운하며 국가에서 압력을 가할 것 같은데 여기는 어떤가요?"
대답은 간단했다.
"회사는 수익을 내기 위해 존재하는 것이므로 필요하지 않다면 그 말을 굳이 들을 필요는 없죠."
어찌보면 이기적인 것 처럼 보이지만 기준을 분명히 가져가는 이 태도가 참 맘에 든다.
어린이들이 없어서인지 회사가 참 고요했다.
다른 실리콘밸리의 회사들이 젊은피로 활기차다는 느낌이었다면 여긴 적막하기까지 했다.
그래서 같이 간 사람들은 별로라는 말도 했는데, 난 오히려 굉장히 합리적이라는 생각마저 들더라.
주니어일 때는 잘 모르지만, 어느정도 궤도에 오르면 시스템이 돌아가는 것을 생각할 수 있고 그 때 비로소 내가 해야할 일이 뭔지 큰 그림을 그릴 수 있는 상태가 된다.
그걸 주도적으로 하나씩 만들어나갈 때, 가장 퍼포먼스가 잘나오는게 아닐까?
그래서 그걸 가능하게 환경을 만들어준 회사를 찾아 들어와있는 것 같다는 느낌이 들었다.
내가 주도적으로 일할 수 있게 해주고, 내가 할 수 있는 것들을 하도록 하는.
그것은 개인의 성장에서 그치지 않고 회사의 성장에 영향을 미치기 때문에 시너지가 날 수밖에 없다.
그런데 잠깐, 짚고 넘어갈 한 가지.
여기서 개발만 한다는건 단순히 코딩만 한다는걸 의미하진 않는다.
단적인 예로, 내가 예전에 개발할 때 난 이메일 프로토콜 개발을 했었다. 그런데 엔진은 단독으로 의미를 가지는 존재는 아니다. 이번에 새로 나온 기능이라도 사용자가 어떤 패턴으로 사용하는지에 따라 우선순위는 매우 낮아질 수 있었기 때문에, 사용자가 실제로 이메일을 사용하는 것을 고려하며 프로토콜에 추가될 신기능의 우선순위도 조정해야했다.
이 때문에 코드를 만드는 활동 외에 프로토콜이 새로 릴리즈되면 아키텍쳐를 어떻게 만들건지 고민하고, 사용자가 어떻게 사용하는지 분석해 UX 시나리오도 직접 만들고, 시나리오 검증도 하고, 새로 나온 경쟁사 폰 구해서 어떻게 동작하는지 패킷까지 잡아서 분석도 하고, 다른 팀에서 논리 없이 위에서 시켰다는 이유로 이상한걸 넣으려고 하면 열심히 싸움질도 하고, 출장가서 사업자랑 협의도 하고, 사업자에 초도버전 나가기 전날 대기하며 혹시나 문제가 생기진 않는지 밤을 새기도 했다.
이런건 그저 내가 맡고 있었던 프로토콜이 이메일 안에서 동작하는 것이기에 이메일 앱을 출시하는데 필요한 일이었기 때문에 했던거지 다른 이유는 없다. 난 그저 내가 how를 선택하며 일할 자유를 원했고 그걸 계속 갖고 있기 위해선 내가 얻은 자유에 대한 책임을 온전히 질 수 있어야 했다. 일을 하면서, 사람에 대한 dependency는 생기지 않을 수록 좋다는걸 실험해본 시간이었다.
Anyway, 사내에서 사람들을 만나다 보면 "개발만 하고싶어요"라는 얘길 하며 회의도 싫고, 이슈 팔로업도 싫다는 경우를 종종 마주하는데, 그것은 틀렸다. 불필요한 일이 많아져서 핵심적인 일을 할 시간이 없다고 느낀다면, 불필요한 일을 줄일 방법을 궁리하는 것도 당신의 몫이다.
1회 보기 : https://brunch.co.kr/@banglab/12
2회 보기 : https://brunch.co.kr/@banglab/4
3회 보기 : https://brunch.co.kr/@banglab/6
4회 보기 : https://brunch.co.kr/@banglab/31
