아마존 3년 출근기 #1 – 하루 일과 및 요약

logo_amazon
아마존에 입사한 지 거의 3년이 되었습니다. 저는 그 동안 사무실을 런던에서 뉴욕으로 옮겼고, 조직도 Amazon Video에서 AWS로 옮겼습니다. 그 동안 제가 경험한 것들이 다른 분들에게도 도움이 되었으면 좋겠습니다. 참고로, 여기에 적는 내용은 모두 제 개인적인 경험입니다. 근무 환경, 개발 프로세스 및 각종 정책은 조직에 따라 다를 수 있습니다.

 

영어

하찮은 영어 실력으로 어찌 어찌 면접은 봤지만 막상 업무에 들어가니 영어는 큰 걸림돌이었습니다. 특히 토론이나 회의에서는 상대방의 말을 이해하지 못하니 적절한 대답도, 설득도 할 수 없었습니다. 한동안은 데일리 스크럼에서 할 얘기를 미리 써서 외워 말하기도 했습니다. 하지만 제가 영어를 잘 못하는 것에 대해 무시하거나, 제 말을 못알아 들어 인상을 쓰거나하는 경험은 단 한번도 해보지 못했습니다. 항상 팀원 모두 서로를 존중해주고, 다양성을 중요하게 생각하는 느낌을 받았습니다. 이건 제가 있었던 팀이 특히 좋은 부분이었고, 그렇지 않은 팀도 있다는 얘기는 들었습니다.

하지만 여전히 언어가 충분하지 않기 때문에 제 능력의 100%는 발휘하지 못했고, 이에 따르는 결과는 제가 감수해야 할 부분이었습니다. 지금도 여전히 언어는 제게 있어 걸림돌입니다. 특히 시니어가 될 수록 팀내외 다른 개발자 혹은 프로덕트 팀과의 의사소통이 큰 비중을 차지합니다. 언어 공부에 왕도는 없는 것 같습니다. 많이 듣고, 읽고, 말하고, 써야 합니다. 3년이 지난 지금은 많이 나아졌지만 아직도 갈 길이 멉니다.

 

출퇴근

저는 오전 10시에서 11시 경에 출근합니다. 일찍 오는 사람은 8시 30분 경에도 출근을 하지만, 저는 게을러서 일찍 출근하지 못합니다. 회의가 많지 않은 날을 골라 일주일에 하루 정도 재택 근무를 합니다. 늦잠을 잔 날도 주로 재택 근무를 합니다. 출퇴근이 귀찮아서 그렇습니다. 재택 근무 하는 날은 회의는 화상으로 참여합니다. 매일 하는 스탠드업 미팅(데일리 스크럼)은 오후 4시입니다. 팀장이 오전으로 옮기려고 시도했지만 저를 비롯한 팀의 몇몇 게으름뱅이들이 반대해 여전히 오후 4시입니다. 제가 거의 제일 늦게 출근하는 만큼 퇴근도 늦습니다. 주로 6시 반에서 7시 반경에 퇴근합니다. 하지만 일이 하기 싫으면 다섯시에도 퇴근합니다. 퇴근을 하는 데 누구의 눈치를 보거나 하는 일은 전혀 없습니다.

출퇴근은 지하철을 이용하고, 40분 정도 걸립니다. 서울 지하철은 세계 최고 수준인 만큼 그에는 못 미치지만, 뉴욕의 지하철은 소문 만큼 나쁘진 않습니다. 이건 런던도 마찬가지입니다. 익숙함의 문제겠지요. 여담으로, 런던의 지하철은 핸드폰이 전혀 터지지 않습니다. 그래서인지 아직도 지하철에서 책이나 신문을 보는 사람이 많습니다. 뉴욕 지하철은 런던보단 낫다 하더라도 역시 핸드폰은 잘 안 터지지만 대부분 핸드폰을 봅니다.

 

야근

아마존에서 일한 이래 일이 많아서 사무실에 늦게까지 남아 야근을 한 일은 한 번도 없습니다. 일년에 두 세번 정도 일이 좀 남아서 퇴근 후에 집에서 한 두시간 정도 일을 한 적은 있습니다. 다만, 당직의 개념인 온콜(On call)은 장애 발생 시 가능한 빠른 시간에 문제의 현상과 원인을 파악해 해결해야 하는 임무가 있는 만큼 퇴근 후 혹은 새벽 시간에 장애가 생겨 처리해야 했던 일은 종종 있었습니다. 온콜은 팀별로 개발자들이 일주일 마다 돌아가며 수행합니다. 이 외에 제가 맡았던 프로젝트 오픈 때문에 회사에서 딱 하루 밤을 새워 봤습니다. 이 프로젝트는 런던, 시애틀을 비롯한 여러 지역의 20개가 넘는 팀이 참여하는 큰 프로젝트였습니다.

직급이 올라갈 수록 일과 중 참여해야 하는 미팅이 많아지는 만큼 퇴근 후 혹은 주말에도 일을 하는 사람들이 많아집니다. 연봉이 오르고, 권한과 책임이 커지는 것과 비례합니다.

 

코드 리뷰

출근 후 가장 먼저 하는 일은 코드 리뷰입니다. 이전 글에서도 밝힌 바 있듯이 아마존의 대부분의 팀은 코드 리뷰가 필수입니다. 코드 리뷰는 몇몇의 시니어만 하는 것이 아니라 팀원 모두가 모두의 코드를 리뷰합니다. 최소 한 두명의 동의를 받아야만 코드를 변경할 수 있습니다.  대부분의 경우 팀 전체에 코드 리뷰를 보내지만, 해당 코드에 대해 잘 알고 있는 사람이 있는 경우 그 사람을 특정하기도 합니다. 코드 리뷰에 열심히 참여할 수록 팀에서의 영향력이 증가합니다. 시니어 엔지니어일 수록 본인이 직접 코드를 작성하는 시간보다 아키텍쳐 리뷰, 디자인 리뷰, 코드 리뷰 등을 통해 간접적으로 코드를 작성하는 시간이 길어지게 됩니다. 참고로, 아마존의 최상위 엔지니어 등급인 프린시플 엔지니어들은 대부분의 시간을 문서 리뷰 혹은 멘토링에 할애한다고 합니다.

 

개발 프로세스

현재 저희 팀은 AWS의 새로운 서비스를 개발하는 중입니다. 저는 굉장히 초반에 팀에 합류해서 약 9개월 간 일을 하고 있습니다. 이 서비스는 B2B이기 때문에 많은 분들이 사용하게 되지는 않겠지만, AWS의 새로운 캐시카우가 되길 바랍니다. 팀의 분위기는 스타트업과 비슷합니다. 신규 서비스이기 때문에 개발팀 스스로 요구사항을 정의하고, 사용자 패턴을 상상해 서비스를 만들어 나가고 있습니다. 때문에 아키텍쳐 리뷰, API 리뷰 등 팀 내부 회의가 많습니다. 또한 모든 신규 AWS 서비스들이 지켜야 할 규칙들과 베스트 프랙티스들도 많기 때문에 이를 만족하기 위한 작업도 상당합니다(모니터링, API 컨벤션, 시스템 아키텍쳐 등등등).

전체적인 개발 프로세스는 스크럼입니다. 해야 할 일들은 이슈 트래커에 등록하고, 매주 그루밍 미팅에서 남은 이슈들의 우선 순위와 새로 등록된 이슈들의 사이즈를 측정합니다. 사이즈는 흔히 피보나치 수(1, 2, 3, 5, 8, …) 혹은 티셔츠 사이즈(S, M, L, …) 등으로 측정하는데, 저희는 피보나치 수를 이용합니다.  13 포인트가 한 사람이 한 스프린트에서 수행할 수 있는 최대 포인트로 상정하고 이에 기반해 팀 토론을 거쳐 사이즈를 예측합니다. 또한, 단일 이슈가 13포인트 이상이 되면 세부 이슈로 나눕니다.

스프린트는 2주 단위로 진행합니다. 스프린트 계획 미팅에서우선 순위를 고려해 한 사람당 13 포인트 정도가 할당될 수 있도록 업무를 배분합니다. 해당 스프린트 동안 반드시 그 일들을 끝내야 하는 건 아닙니다. 이 경우 남은 포인트를 대략 추정해 다음 스프린트로 넘기기도 합니다. 각각의 스프린트에서 팀이 완료하는 포인트를 기반으로 남은 작업을 완료하는 데 필요한 대략적인 기간과 인력을 추정합니다. 스프린트가 종료되면 각자가 해당 스프린트에서 완료한 작업을 간단히 시연합니다. 또한, 해당 스프린트 동안 잘 된일, 개선할 수 있는 일들을 논의하고, 액션 아이템을 도출합니다.

 

동료들

런던 팀의 경우 10여 명의 팀원 중 영국인은 두 세명이었고, 나머지는 전부 외국인이었습니다. 국적 또한 스페인, 이탈리아, 독일, 러시아, 폴란드, 한국, 중국, 불가리아, 크로아티아, 인도 등등 정말 다양했습니다. 런던이 유럽의 테크 중심지인 게 큰 이유인 것 같습니다. 참고로 런던에는 아마존 외에 페이스북, 구글, 애플, 마이크로소프트 등 미국의 주요 테크 기업들의 지사가 있고, 개발 조직을 운영하고 있습니다. 알파고를 만든 구글의 딥마인드 역시 런던 오피스에 있습니다. 하지만, 뉴욕 팀은 대부분의 팀원이 미국인이고 저를 포함한 두 세명 만이 외국인입니다. 또한, 런던의 문화 특성 상 점심 먹으러 나가서 맥주 한 잔, 퇴근 후 펍에서 맥주 한 잔, 금요일 오후에는 사무실에서 맥주 한 잔이 흔한 일상이었다면, 여긴 그렇지 않습니다. 2 ~ 3개월에 한 번 주기로 회식을 하긴 합니다. 런던 뉴욕 모두 어딜 가나 사람도 많고 술도 시끌벅쩍하게 마십니다. 밤이 늦어도 안전한 것 역시 좋은 점입니다. 물론 세계 최고 수준의 치안을 자랑하는 서울에 미치지는 못합니다. 런던의 동료들과는 2년이 넘는 시간을 함께 한 만큼 정말 좋은 기억을 갖고 있고, 그 중 몇몇은 흔쾌히 베프라 불러도 될 정도가 되었습니다. 지금의 동료들은 그 만큼은 아니지만, 계속 지지고 볶다 보면 더 끈끈해 지겠지요.

 

팀장과 시니어 엔지니어(SDE-III)

아마존의 개발팀은 시니어 엔지니어와 매니저(팀장)가 이끈다고 볼 수 있습니다. 팀장과 시니어 엔지니어 모두 부장 정도의 레벨이라고 보면 될 것 같습니다. 이 중 시니어 엔지니어는 일을 ‘어떻게’ 할 것인지(컴포넌트 구성, 소프트웨어 디자인, 인터페이스 등)를 결정한다면, 매니저는 ‘무엇을’ 할 것인지를 결정합니다. 주로 일의 우선 순위 관리가 이에 해당하겠지요. 그렇기 때문에 매니저는 기술적인 구현에 거의 관여하지 않고, 시니어 엔지니어가 이를 주도합니다. 팀장의 큰 역할 중 하나는 팀내 개발자들의 ‘관리’입니다. 개별 개발자가 본인의 일을 잘 할 수 있도록 불필요한 일들을 치워 주거나, 다른 팀의 역할이 필요한 경우 해당 팀을 설득하거나 혹은 개발자가 성장할 수 있도록 적절한 일을 맡기는 등의 일입니다. 물론 어디나 그렇듯 자신의 일을 잘 못하는 팀장도 있지만, 제가 있었던 두 팀의 팀장들은 아주 훌륭하게 이 일을 해냈습니다.

제가 다녔던 한국 회사와 가장 다른 점은 팀장과의 1:1 대화입니다. 이전 회사는 팀장과의 공식적인 1:1대화는 일년에 한 두번이었던 반면 아마존은 팀장이 매주 혹은 격주로 개별 팀원과의 1:1 시간을 가져야 합니다. 짧게는 15분에서 길게는 한 시간 정도입니다. 이 시간을 이용해 자신이 어떤 일을 하고 싶은지, 앞으로 더 성장하기 위해서는 어떻게 해야 할 지 등의 대화를 하게 됩니다. 주간 보고 형식 같이 자신이 어떤 일을 했는지는 얘기 하지 않습니다. 팀장은 이미 그것을 알고 있어야 하고, 데일리 스크럼 혹은 스프린트 데모가 이걸 하는 시간이기 때문입니다.

 

곧 2편도 업로드하겠습니다.
Advertisements

14 thoughts on “아마존 3년 출근기 #1 – 하루 일과 및 요약

  1. 우연히 facebook 타임 라인에 떠서 재미있게 읽고 갑니다. 3년 정도 근무하셨고 런던에서 근무하셨었다면 혹시 2015년 초에 H1B 로터리에서 떨어진 사람들이 모였던 Slack 방에 계셨던 분이 아니신지요? 🙂

  2. Pingback: AI 인재 수 세계 2위, 중국…한국보다 7배 많다 – 2019.1.11 개기자의 큐레이션 – 마이크로소프트웨어

  3. 안녕하세요 재밌게 읽었습니다! 한번 만나뵙고 차라도 한 잔 하고 싶네요. 지금은 뉴욕에 계시는군요

  4. 흥미롭게 읽었습니다~ 팀장님과 1대1 대화를 한다고 했는데 개발팀 규모가 어느정도인가요? 주로 몇명 단위로 돌아가는지 알고 싶습니다.

    • 대부분은 5-10명 정도입니다. 작은 팀은 2-3명, 큰 팀은 15명 까지 되는 팀도 있지만, 일시적인 경우가 대부분입니다.

  5. 저는 프론트앤 개발자인데 유럽에 작은회사에 일하고있어요 ㅎ 시애틀 친구를 만나서 꿈을 키워 보라는 말에 지금 하는일하면서 큰 회사 준비를 하는게 어떻께해서 구글링으로 들어오게되었었어요. 저도 글쓴이님 처럼 되고싶네요. 무엇을 준비해야하는걸 대략적으로 알게되서 정말 감사해용. 2편기다해면서 자주 읽으로 올께용

    • 아마존은 최근 프론트엔드 개발 직군을 신설해 별도로 채용하고 있습니다. 관심 있으시면 검색해보시기 바랍니다

  6. 최근에 링크드인을 통해서 아마존에서 연락이 왔던데 캐나다 밴쿠버 지역 근무입니다.
    2월 중순 경에 서울에서 면접을 본다고 하는데 참가해보려고 하는데요..
    현 근무지는 누구나 알만한 휴대폰 만드는 국내 대기업에서 근무 중인데, 아마존으로 이직할 수 있는 기회가 온다면 하는 게 좋을 지.. 결정이 쉽지 않네요ㅠㅠ
    블로그 주인장님의 고견이 필요합니다!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s