(펌글) 아마존 3년 출근기
인상적인 내용들
매일 하는 스탠드업 미팅(데일리 스크럼)은 오후 4시입니다.
오후 4시에 하는 데일리 미팅이라. 신기하다. 보통 오늘 할 일과, 이슈 등을 이야기하는 것이 잘 알려진 daily meeting의 practice인데 오후에 한다니. 아래 내용을 보면 야근도 안 한다는데. 흠.. 신기하네
아마존에서 일한 이래 일이 많아서 사무실에 늦게까지 남아 야근을 한 일은 한 번도 없습니다. 일년에 두 세번 정도 일이 좀 남아서 퇴근 후에 집에서 한 두시간 정도 일을 한 적은 있습니다.
어떻게 이게 가능할까?
정말 업무를, 과제를 팀 능력에 맞게 잘 계획해서?
시장(?)이나 어떤 이유로 인해 빠른 개발을 요구받는 경우도 없나? 분명히 야근은 없다고 했는데.
아마도 B2B지만, 고객의 기능, 일정 요구에 맞춰서 개발을 진행하는 것이 아니라 우리 팀의 개발 일정에 맞게 진행해서 그런 것이 아닌가 싶다. 그게 아니라면 어떻게 가능할까??
이런 걸 신기하다고 생각하는 나, 내가 속한 조직이 이상한 걸까? 아니면 저런 조직이 특이한 걸까? 지난 번에 샌프란시스코에서 본 후배도 비슷하게 일하는 걸 보면 아마존만 이상하거나 특이한 건 아닌 듯 한데. 그렇다고 내가 속한 조직만 그런 건 아니고 옆, 그 옆 그리고 그 옆옆 부서도 그런 걸 보면 적어도 내가 있는 건물에 있는 우리 회사는 대부분 저 아마존하고 다른 건 확실한데.
코드 리뷰에 열심히 참여할 수록 팀에서의 영향력이 증가합니다.
중요한 내용이네. 코드를 많이 알수록 팀의 업무를 많이 알게 되는 거라 그 만큼 할 수 있는 일이 많아진다는 뜻인 듯.
시니어 엔지니어일 수록 본인이 직접 코드를 작성하는 시간보다 아키텍쳐 리뷰, 디자인 리뷰, 코드 리뷰 등을 통해 간접적으로 코드를 작성하는 시간이 길어지게 됩니다. 참고로, 아마존의 최상위 엔지니어 등급인 프린시플 엔지니어들은 대부분의 시간을 문서 리뷰 혹은 멘토링에 할애한다고 합니다.
우리와는 다른 의미의 prinipal engineer. 아무튼 경력/경험이 많아질 수록 리뷰하는데 많은 시간을 보낸 다는 것. 우리 회사도 그렇기는 한 듯.
팀의 분위기는 스타트업과 비슷합니다. 신규 서비스이기 때문에 개발팀 스스로 요구사항을 정의하고, 사용자 패턴을 상상해 서비스를 만들어 나가고 있습니다.
글을 쓴 사람이 속한 팀 성격이 새로운 서비스를 만드는 팀이라서 그렇다고 하네. 여기서 말하는 서비스가 어떤 정도의 크기인지는 잘 모르겠지만, 새로운 캐시카우가 되길 바란다는 정도면 그래도 하나의 단독적인 서비스라고 생각이 되지만 우리 회사가 일하는 과제보다는 사이즈가 작지 않을까 하는 예상.
13 포인트가 한 사람이 한 스프린트에서 수행할 수 있는 최대 포인트로 상정하고 이에 기반해 팀 토론을 거쳐 사이즈를 예측합니다. 또한, 단일 이슈가 13포인트 이상이 되면 세부 이슈로 나눕니다.
Sprint 주기를 2주라고 했는데 그럼 하나의 이슈가 2주일 짜리도 가능하다는 이야기인가? 그리고 여기서 말하는 13포인트는 어디서 나온 걸까? 피보나치 수에서 가져왔다고 하는데(scrum에서 흔히 사용하는 story point인 듯 하긴 하네, https://wormwlrm.github.io/2018/09/09/Scrum-tutorial-for-adapting-agile-methodologies.html, https://ko.popularhowto.com/estimating-end-of-scrum-projects-with-fibonacci-numbers-and-story-points) 좀 더 공부해 봐야 할 듯.
스프린트가 종료되면 각자가 해당 스프린트에서 완료한 작업을 간단히 시연합니다. 또한, 해당 스프린트 동안 잘 된일, 개선할 수 있는 일들을 논의하고, 액션 아이템을 도출합니다.
요즘 시연을 하는 게 별로 없었는데 다시 좀 활성화시키면 좋겠다. 다들 개발자다 보니 뭔가 동작하는 걸 만들면 조금 더 성취감을 느끼지 않을까?
아마존의 개발팀은 시니어 엔지니어와 매니저(팀장)가 이끈다고 볼 수 있습니다. 팀장과 시니어 엔지니어 모두 부장 정도의 레벨이라고 보면 될 것 같습니다. 이 중 시니어 엔지니어는 일을 ‘어떻게’ 할 것인지(컴포넌트 구성, 소프트웨어 디자인, 인터페이스 등)를 결정한다면, 매니저는 ‘무엇을’ 할 것인지를 결정합니다. 주로 일의 우선 순위 관리가 이에 해당하겠지요. 그렇기 때문에 매니저는 기술적인 구현에 거의 관여하지 않고, 시니어 엔지니어가 이를 주도합니다. 팀장의 큰 역할 중 하나는 팀내 개발자들의 ‘관리’입니다. 개별 개발자가 본인의 일을 잘 할 수 있도록 불필요한 일들을 치워 주거나, 다른 팀의 역할이 필요한 경우 해당 팀을 설득하거나 혹은 개발자가 성장할 수 있도록 적절한 일을 맡기는 등의 일입니다.
아무래도 난 매니저로서의 시니어 엔지니어가 그나마 더 가망이 있어 보이는데. 아직도 개발자 마인드가 크게 남아 있어 여전히 전략적으로 말하지 못하고(물어보면 신나서 아는 거 다 이야기하는 개발자 속성) 설득력있는 논리를 만드는 능력이 부족하다. 때(?)로는 만들어진 논리가 순리를 이기는 경우가 많은 데 아직도 ‘옳은 게 맞는 거다’라는 생각을 버리지 못한다.
하지만 개발이던 매니징이던 다 잘하는 사람이 있는 걸 보면 그냥 이건 핑계일 뿐, 내 능력이 부족해서 그런거라…
오늘도 한숨 100번 하고