Leaving Google (원저자 - Jay Conrod)
시작하기 전
Google에서 2015년부터 일한 사람이 Google에서의 후기와 SW Engineer 포지션에 대한 꿀팁을 작성한 글이다.
블로그 글로 공유해주신 내용을 정리했다.
- Google Docs 팀에서 일하다가
- Bazel 팀으로 이동했다.
Docs 팀에서의 교훈
TLDR;
- 팀에는 멘토가 있어야한다.
- 매니지먼트가 날 서포트 할 수 있어야한다.
- 조직의 목표와 내 업무적 가치관이 잘 맞는지 확인하자.
멘토
새로운 팀에 참여할 때, 해당 팀에 멘토가 있는지 꼭 확인하자
Jay는 신설 Docs팀에 합류하였다. 정확히 얘기하자면, Docs팀은 원래 Google Drive 팀에 소속되어있다가 막 분리된 제품 팀이였는데, 새로 만든 조직이였기 때문에 팀 인원이 막 입사한 사람들로 이뤄져있었다.
그러다보니 팀의 인프라 구조를 아는 사람도 없었고, 누구한테 어떤 질문을 던져야하는지도 잘 모르는 상황이 되었다.
이 부분에 대해 Jay가 조언하는 바는, ‘새로운 팀에 참여할 때, 해당 팀에 멘토가 있는지 꼭 확인하자’ 이다. 누군가는 프로젝트 아키텍처, 역사, 조직의 소통 및 정치(?) 구조를 설명해 줄 수 있어야한다. 내가 새로운 팀에 참여하면 꼭 이런 것들을 알려줄 수 있는 사람을 찾자.
매니지먼트
‘승진하기 위해서는 매니지먼트의 서포트가 필수적이다’
Docs 팀의 매니저는 바쁜 사람이였다. 25개의 리포트를 한번에 처리해야했고, 팀원과의 미팅도 3주에 한번 (그것도 겨우 30분)만 했다. 이런 형태가 지속되다보니, 몇달이 지나도 매니저는 Jay의 프로젝트 이름을 제대로 기억하지도 못했다. 이런 상황에서 승진은 꿈꿀 수도 없다.
심지어 Jay는 이전 직장인 Qualcomm에서 더 높은 직책이였는데, Google로 옮길 때는 하나 낮은 직책으로 가도 금방 실력을 보여서 승진할 수 있을 것이라고 생각했다. 아무리 실력이 좋아도, 매니지먼트가 관심을 줄 수 없는 상황이라면 승진은 어렵다. 2년동안 Docs에서 일하다가 못참겠어서 다른 팀으로 이동하고, 그 팀에서는 1년만에 승진했다고 한다.
조직/나의 목표
‘조직과 나의 목표가 맞아야한다’
조직의 목표에 내 목표를 억지로 맞추자는 것이 아니다.
Docs팀 PM의 목표는 고객에게 새로운 피쳐를 지속적으로 빠르게 전달해주는 것이였다. 그에 반해, Jay의 목표는 간단명료하고 버그가 없는 잘 도는 소프트웨어를 만드는 것을 중요시하였다. 둘 중 무엇이 맞고 무엇이 틀렸다는 것이 아니다 (둘 다 중요하다). 하지만 개발 방법론에 있어서 이 둘은 상충되기도 한다.
조직의 목표과 내 목표가 다르다면, 조직이 요구하는 업무를 수행하면서 나는 절대로 행복할 수 없을 것이다.
Go 팀에서의 교훈
TLDR;
- 많이 아는 것도 좋지만 빠르게 공부할 줄 아는 것도 굉장히 중요하다.
- 개개인 단위에서 집중할 수 있는만큼만 중장기 프로젝트를 운용하자. 제품을 책임지는건 팀이다. 내가 아니고.
- 대규모 프로젝트에 참여하는건 종종 ‘지루할 수도’ 있다.
공부
Jay는 2017년에 Go 팀으로 이동하며, Bazel 빌드 시스템에 Go 지원 기능을 추가하는 업무를 담당하게 되었다. Jay는 Go나 Bazel을 잘 쓸 줄 몰랐다 (본인 말로는 책 하나 읽은 정도라고 한다). Jay의 팀원들 중에는 팀에 참여하고나서 Go를 처음 배운 사람들도 있다고 한다.
Jay는 ‘N년의 경력’ 같은건 중요하지 않다고 한다. 어떤 것이든 빠르게 배워서 적용할 수 있으면, 경력 따위는 중요하지 않다고 한다. 'Smart people can pick up anything quickly, and diverse perspectives are valuable'.
업무로드 & 번아웃
Go 팀의 단점을 꼽자면, 팀원 모두가 엄청나게 일을 많이 하고 있었다는 것이다. 물론 팀원들은 모두 생산성 넘치고 똑똑한 사람들이였지만, 업무로드가 믿기지 않을 정도로 많이 걸려있었다. 프로젝트는 유지보수 업무가 끝나지 않았기 때문에 지속적으로 끌고가면서, 계속 추가적인 프로젝트가 들어왔다. Jay는 나중에는 6개의 프로젝트를 진행해야했다.
동시에 너무 많은 프로젝트를 진행하면 정신도 여러 곳으로 분산될 뿐만이 아니라 시간을 제대로 할애하지 못한다. 6개의 프로젝트를 진행할 때에는 이슈 트랙킹과 코드리뷰만 해도 하루가 끝나기도 했다.
대규모 프로젝트에서는 똑똑하게 일해야한다 (그게 항상 재밌고 활기찬건 아니다)
Bazel 팀에서 일 할 때에는, 동료들이 특정 버그나 이슈가 생겼을 때 바로바로 해결해주고 고맙다는 이야기를 많이 들었다. 굉장히 뿌듯했고, 하나씩 쳐내간다는 성취감이 아주 좋았다. 하지만 이런 액션은 사실 끝도없이 계속 나타난다. 도큐먼트가 생기기 전 까지는 어쩔 수 없이 반복하게 된다.
Module reference documentation에 대해 작업을 한 적이 있다. 약 80장 정도 되는 리포트에 Module system의 작동원리를 적었고, 빌드 중 나타나는 이슈들에 대한 매뉴얼을 적었다. 도큐먼트를 적는거는 지루하지만, 결과적으로 더 많은 사람들이 빌드를 하는데에 생기는 이슈들을 피할 수 있었다.
구글에서 일을 할 수 있던 이유
좋은 동료들이 있어서!
Docs 팀에서는 밤새 게임을 같이 하기도 했다. 바에 같이 놀러가기도 했다.
Go 팀에서는 요리를 같이하거나 디너 파티를 하기도 했다. GopherCon에서 같이 마가리타를 마시면서 당구를 친건 정말 재밌었다.
밝은 분위기를 만들어주는 팀원들에 감사한다.
원격근무로 전환 시 이런 좋은 관계들을 가지지 못할 것 같아서 아쉽다. 이러한 관계는 직접 만나서만 만들 수 있기 때문이다.
구글을 떠난 이유
Google에 있는 사람들은 다 조금씩 ‘Google이 직장 중에 제일 좋다’라는 생각을 가지고 다닌다. 딱, 퇴사할 때 까지만.
Google 보다 좋은 곳들은 사실 많다.
Google을 떠나게 된 이유는 다음과 같다.
번아웃
지쳤다. 이전에 트윗을 올린게 화제가 된 적이 있다 (모두가 피곤해서, 미팅에서 아무도 얘기할 거리를 가져오지 않아서 미팅이 계속 취소된다는 트윗. 미팅을 진행해도 별 이야기 없이 엄청 금방 끝난다는 트윗.).
지쳤고, 일이 몰렸고, 코로나 때문에 엄청 불편하게 되었다. 잠을 잘 못자게 되었고, 두통이 자주 찾아오고 허리가 아팠다. ‘Brain fog’ 때문에 집중하는것도 어려웠고, 결정을 내리기도 어려웠다. 말을 하던 도중에 단어와 이름을 자주 잊어버렸고, 대화의 내용을 잊어버렸다. 회사 업무 외의 다른 일을 할 에너지도 없었다.
커리어 & 보상
이렇게 힘들때는 보통 좀 쉬고 오면 괜찮아진다. Google은 3달은 무급휴가로 쉴 수 있다. 그럼에도 Google을 나온 이유는 다음과 같다.
Google에서 원격근무 포지션으로 전환 시 연봉의 10%를 차감한다고 했다. 이 방침이 결정되기 전에 Jay는 San Diego로 이사를 갔다. 물론 Jay는 원격근무 방침이 생길 것을 알고 있었고, 해당 방침으로 인해 연봉 조건이 안 좋아질 경우 퇴사를 할 각오도 다져놨다. 동일한 팀에서 동일한 일을 하는데 연봉 10% 삭감은 Jay의 입장에서는 받아드릴 수 없는 부분이였다. 특히나, 회사가 돈이 없거나 그런 것도 아니였다. Google Cloud는 2021년 Q1에 전년도에 비해 53%의 매출이 더 났기 때문이다.
또 다른 이유로는, Go 팀에서 하던 작업으로는 L6로 승진을 할 것 같지 않았기 때문이다. Google은 Jay가 개발한 go command 나 module로 작업을 하지 않는다. 단순히 오픈소스의 용도로만 만든 것이다. Google에서 L5 이상으로 승진을 하기 위해서는 비즈니스에 직접적으로 수익을 가져올 수 있는 작업을 해야하기 때문에, 대부분의 Go 팀 인원들은 L5에 있었다. 더 높은 직책으로 가기 위해서는 Google 내 새로운 포지션을 찾거나 이직을 해야했다.
결론
쉬고 오신답니다 ㅎㅎ