Amazon, 신입사원이 많은 곳
협업을 몹시 중요하게 생각하는 회사
사실은 실리콘밸리 출장 당시, 시애틀을 들렀다가 샌프란시스코로 이동하는 일정이었다.
글을 쓰는 순서도 일정과 맞추려고 앞서 올라간 1-7회 까지의 글은 실리콘밸리에서 방문했던 회사 순서이다. 시애틀에서 방문한 두 회사는 내용 정리가 좀 늦어져서 실리콘밸리 내용을 먼저 올리게 됐다.
뭐, 말을 안했으면 이 순서는 나만 아는거겠지만 뭐 그렇다고...
내 주변엔 뛰어난 개발자 친구들이 많은데, 그 친구들이 단체로 특정 업무에 대해 아마존에서 메일을 종종 받는다. 또 다른 지인은 최종 합격했다가 미국 비자 발급에 걸려서 다른 지역으로 가게 됐고, 그래서 결국 안가기로 결정한 사람도 있다.
그만큼 아마존은 글로벌하게 인재 채용을 많이 한다는 뜻이고, 그래서 한국 개발자가 외국으로 나가고 싶은 생각이 들었을 때 첫 번째 회사로 선택하는 회사이기도 하다.
(2018년 3월 19일 추가)
2015년 11월에 이 글을 쓴 이후로 사내에서 벤치마킹으로 같은 회사에 방문한다는 여러 조직에서 연락이 왔었다. 아마 다른 회사도 같은 이유로 벤치마킹을 많이 다닐 텐데, 저 때 쓰지 않았던 내용을 조금 더 추가해본다.
본문에도 적었지만, 아마존은 신입사원에게도 아키텍쳐를 만들어오라고 하는 회사다. 6개월 전 아마존 베를린에 입사한 내 지인은 6개월 만에 자신이 그린 아키텍쳐 리뷰를 받는다며 떨린다는 소감을 전해오기도 했다. 그는 과거 내 동료였고 코드잼으로 선발된 우수 인재라 실력이 출중했는데도 그곳에 간 직후에는 코드 한 줄 커밋하는 것도 부담스럽다든지, 본인이 잘하고 있는 건지 모르겠다는 이야기를 전해오기도 했다.
이처럼 협업이 강조되고 신입사원에게도 많은 기회를 주는 개발 환경은 제목에 적은 것과 같은 이유가 아닐까 싶다. 신입사원이 많은 환경이지만 일일이 붙잡고 가르쳐줄 수 없고, e-commerce 시장은 가격이 자주 바뀌고 그로 인해 분 단위로 움직여야 하는 분주한 곳이니 1인으로 그 역할을 빠르게 해내야 하니까. 그런 특수성이 작용하여 아마존의 개발 문화를 만들어낸 게 아닐까?
그렇다. 그것은 문화다. 조직 문화. 솔루션이 아니고.
이러한 이유로 다른 회사의 방식을 우리 회사에서 똑같이 시도한다고 해서 같은 생산성이 나올 리 만무하다. 벤치마킹에서 가장 먼저 해야 하는 일은 우리 회사의 현 상태와 문제점이 뭔지 정확히 파악하는 것이다. 그게 없으면 아무리 다른 회사를 많이 돌아다녀도 "저기 좋아요. 저렇게 해야 해요" 이상의 말은 나오지 않을 것이다.
아마존은, 구성원의 유입과 유출이 많은 회사
실제 아마존에 입사한 사람 가운데 1년 만에 그만두는 사람이 많다고 한다. 이는 곧 신입 사원이 많다는 뜻인데, 이 때문에 신입에게 업무를 파악하라는 목적으로 아키텍처 디자인을 맡긴다고 한다.
한가지 역할에 대한 전문성을 강조하는 전통적인 조직과 가장 큰 차이점이 아닐까 생각된다.
물론, 10년차 이상도 많으며 거의 대부분 manager이며, 인성면접이 따로 없고 기술면접을 볼 때 사이사이 인성에 대한 질문이 이루어진다.
* Amazon은 퇴사 후 외부에서 경험을 쌓고 승진되어 재입사하는 것 가능하다.
* 참고로 미국은 HR이 hiring decision에 전혀 관여하지 않는다. 채용은 개발부서 의견 기준이며 HR이 힘이 없다. 애초에 뽑을 때부터 '확실히 잘할 것 같다'는 만장일치가 아니면 뽑지 않는다.
내 코드가 제품에 들어가기 까지
1. User story(일종의 시나리오라고 볼 수 있다)가 나오면 특정 개발자에게 디자인을 맡긴다. 어떤 framework을 쓸건지, 어떤 API를 쓸건지 모두를 포함한다. (특정 개발자라 함은 한명이 계속 한다는 의미가 아니고 팀원 중 한 명이 한다는 뜻이다. 디자인은 모두가 돌아가면서 한다.)
2. 아키텍처 디자인은 여러개의 옵션과 왜 이런 디자인을 만들었는지 각각의 장/단점 분석을 포함해야 한다. 아키텍처를 디자인하는 일은 한 명이 단독으로 하지 않고 팀 내에서 돌아가면서 한다. 아키텍트라는 역할 자체를 따로 두지 않는다.
3. 아키텍처 디자인 안이 나오면 시니어 개발자와 함께 팀이 모두 모여 함께 장단점에 대한 논의를 하고, 디자인 리뷰를 거쳐 일정을 estimation 한다.
4. 아키텍처 디자인을 확정하면, 일의 단위를 쪼개 task를 만들고 estimation을 반영하여 일을 나눠가진다.
5. 팀마다 2~3명씩 짝을 지어 pair programming을 통해 개발하고 코드리뷰를 하거나, 팀 전체가 testing까지 포함하는 feedback을 한다.
6. feedback loop이 끝나면 코드가 제품에 반영되는 절차를 거친다.
개발 기간 estimation은 개발자가 직접
Estimation은 Dev Manager와 개발자가 함께 하고, 위에서 기간을 내려주지 않는다.
한국 스타일을 잠시 보면, 위에서 일정을 정해서 내려주기 때문에 개발자는 over estimation을 하게 되고, 그걸 윗사람은 다시 줄여버리는 식으로 진행되는데, Amazon에서는 개발자들이 "이 일은 이틀이면 돼요"라고 말해도 기존에 하던 유지보수 업무를 감안하여 PM이 보통 2배 정도로 버퍼를 잡는다.
유지보수 업무도 개발자가 관리해야 하는 일임을 manager가 인정하고 있는 것이다.
대부분이 개인이 아니고 팀 단위로 design부터 함께 리뷰하므로 속도와 역량은 팀단위로 측정한다.
표준을 제시해 그대로 따르는 것을 싫어하고 결과로 말하는 것을 좋아하는 회사
User story가 발의되고 만들어지기까지, 기술적인 부분은 TPM(Technical Program Manager)가 관리하며, TPM은 Business case를 세분화하는 역할도 한다.
전체적으로 진행되는 것은 다음과 같다.
1. Product Manager가 요구사항을 쓰고,
2. 그 일을 하기로 결정되면,
3. 개발 팀장에게 위임한다.
4. 관련된 팀이 모두 involve 되고, 이때부터 PM이 관리한다
5. 만약 이 규모가 너무 크면 TM이 참여한다. (TM=Technical Manager)
=> 이것이 Amazon의 정형화된 process 이지만, 사실 일하는 프로세스는 팀마다 다르다.
아마존은 구성원에게 책임과 권한의 범위가 꽤 넓게 주어지는 것으로 유명하다.
위에서는 큰 그림만 제시하고 세부적인 것은 개발자에게 맡겨 책임까지 지도록 한다. 이렇다보니 개발자 개인에게 주어지는 부담이 엄청나며, 스스로 직접 책임져야 하기 때문에 시키는 것을 수행하는 것에 익숙한 사람들이 지내기는 어려운 곳이다.
보통으로 해서는 소화하기 어려울 정도의 업무가 주어지는데, 이는 우선순위를 정해서 중요한 것부터 하라는 의미이다. 개발자가 자기계발에 투자할 시간을 내기 힘들 정도로 업무량이 많지만, 업무에서 배우는 것이 많다고 한다. 이처럼 개발자에게 충분한 권한을 주는 만큼 기대치를 충족시켜야 하는 것에 대한 부담이 크기도 하다.
Amazon은 customer 중심 회사여서 '개발자가 사용자를 얼마나 생각해서 개발을 하느냐'가 개발 문화인 곳이기 때문에 어떤 개발자는 삐삐를 차고 일하며 이슈 발생시 24시간 이내 해결해야 한다고도 한다.
Code Review
코드리뷰는 github과 같은 툴을 써서 한다.
커밋에 키보드 배틀이 일어나기도 하는데, 20~30줄 코드에 80개의 comment가 남겨질 정도로 치열하게 코드 리뷰를 한다. Disagree commit이 있어 code review 문화가 가능하다.(물론, 동의하지 않아도 다수가 동의하면 코드리뷰는 통과할 수 있다.)
의견 정리가 안되면 회의를 통해 정리하고, 그래도 안되면 시니어가 정리한다.
코드리뷰의 단위는 움직임이 있는 작은 단위 이상이며, commit에는 test code가 반드시 포함되어야 한다. AWS의 경우 Test coverage가 95% 이상이며, Test 코드 또한 고객에게 공개되어 있다.
Peer Review로 평가
어느 조직이나 성과를 잘 내는 것은 당연히 중요하다. 팀 단위로 일을하고 성과를 내기 때문에 peer reveiw를 진행하여 동료들이 리뷰한 것이 매니저에게 가고, 본인의 리뷰와 종합해서 평가한다.
이와 더불어 Amazon에서는 Leadership Principle을 굉장히 중요하게 본다.
Leadership Principle에는 협업과 태도(인성)가 큰 비중을 차지하는데, 특히 승진을 할 때는 coding skill보다 leadership을 더 중요한 팩터로 본다.
Manager와 1, 2주에 한 번씩 one on one 미팅
분야가 빠르게 바뀌고 모든 구성원이 같은 수준으로 따라가기 힘들기 때문에 manager와 1, 2주에 한 번씩 one on one 미팅을 진행하며, 본인이 하고 있는 업무에 대한 이야기를 하면서 속도를 조절한다.
일정이 불가능해 보일 때는 안된다고 커뮤니케이션 하기 보다는 대안을 제시하고, 인원을 늘리거나 feature를 축소하는 방향으로 업무를 정리해간다.
예를 들어, 만약 내려온 일 10개 중에서 5개만 일정 내에 할 수 있다고 판단되는데, 10개를 다 하길 원하면 팀원을 더 달라고 협상할 수 있다. (이런 커뮤니케이션을 하는 사람이 DPM이다.) 이처럼 반대 입장을 말할 수 있는 용기(disagree)가 필요하고, 하겠다고 했으면 끝까지 해야한다.(commitment)
개발자는 1주일에 하루 정도는 재택근무를 할 수도 있다. 만약 개인 사정으로 인해 업무에 영향을 줄 것 같다면 그런 이야기를 하기도 한다. 개인 사유로 업무를 쉬어갈 수 있고, 이에 대해 불이익을 주지 않는다.
개인과 조직의 발전을 위해 조직이동 권장
한 가지 일을 오랫동안 하면 지루해지고 루틴해지기 마련이다. 이런 이유로 개인 차원에서는 역량의 발전시킬 수 있도록, 회사 차원에서의 조직의 발전을 위해 한가지 일을 2~3년 하면 구성원이 다른 조직으로 이동하는 것을 리더가 적극 권장한다. 사람을 보내고 받는 것이 자유롭고, 이 것이 아마존의 문화로 정착되어 있다.
매니저들이 "yo man~너 지루해보여~" 하면서 데려가는 것이 일반적인 모습이고, 한 명이 나가면 다른 한 명이 다시 들어오니 이동을 막진 않는다.
길고 어려운 인터뷰 절차를 통과해서 들어온 똑똑한 사람임을 알기에 안옮겨주면 퇴사하니까, 본인의 역량을 더 발휘할 수 있는 곳에서 일하는 것이 조직 전체 차원에서 더 도움되는 일이라고 생각한다.
만약, 개발자로 일을 하고 있는데 개발 능력은 보통이지만 people managing을 잘하는 사람이라면 manager를 추천하기도 한다. 이 경우 개인의 만족도도 높은 편이라고.
또, 내부적으로 Job posting이 열리면 지원이 가능하고, 지원하면 hiring manager와 미팅을 하여 이동이 시작된다.
업무 전환은 어떻게 되는가?
Dev에서 PM으로 이동은 있으나 PM에서 Dev로의 이동은 거의 없다.
미국에선 manager의 역할이 굉장히 중요하다. 따라서 사람들을 잘 organize하고 leadership이 보이는 사람은 조직에서 먼저 manager를 하는게 어떻겠냐는 제안을 받는다. Amazon에는 멘토링 시스템이 잘돼있어서 조언도 많이 해준다.
SDM에서 Dev로, Dev에서 TPM으로 전환하는 경우도 많다.
1회. Rob Pike 만나기 : https://brunch.co.kr/@banglab/12
2회. Google : https://brunch.co.kr/@banglab/4
3회. LinkedIn : https://brunch.co.kr/@banglab/6
4회. Oracle : https://brunch.co.kr/@banglab/31
5회. NETFLIX : https://brunch.co.kr/@banglab/5
6회. Tesla : https://brunch.co.kr/@banglab/28
7회. Haxlr8r : https://brunch.co.kr/@banglab/3
