2022년 10월 21일 금요일

재밌는 기사 하나 - 아마존, 구글 모두 다닌 사람이 쓴 비교글

 회사에 가끔 올라오는 SDE Good reads에 이런 기사가 왔길래 읽어봄.

원문 링크 


제목: 내가 구글의 장점이라 생각하고 좋아한 점이, 또한 싫어하는 점이기도 하다.

부제는 어케 구글은 몽상가를 채용하고 아마존은 일꾼을 뽑나.
(How google hires Dreamers and Amazon hires Builders)


내맘대로 번역해보자면 아래와 같다.  


나는 아마존에서 11년 (개발툴 쪽에서 Principal Engineer로), 구글에서는 최근 2.5년 (Integration testing 을 위한 개발자 인프라에서 Senior staff engineer로) 을 일해왔다.   두 포지션 모두 회사 전체를 대상으로 엔지니어링 생산성을 높이는 역할이기 때문에 매우 다양한 팀과 일할 수 있는 위치였고, (그러므로 역할 특성상) 두 회사 모두의 문화를 깊이 체험할 수 있었다.

그 결과 다음과 같은 깨달음과 패러독스를 마주하게 되었다.

* 내가 구글에 일하면서 좋아한 장점들이, 구글의 싫은 점이기도 하다.

* 내가 아마존에 일하면서 좋아한 것들이 아마존의 싫은 점이기도 하다.

(뭔소리??)

만일 당신이 이 글을 읽으면서 이런걸 기대했다면 - 아마존이 얼마나 안좋은 직장인지, 구글이 얼마나 안좋은 직장인지, 아니면 어디가 다른 곳보다 더 낫다든지 - 이런 얘기를 들을거라 기대했다면, 미안~ 실망하게 될 것이다. 난 진심으로 아마존에서 일했던 시간들이 좋았고, 지금.. 구글에서 일하는게 진심 신난다. 두 직장 모두 매우 좋은 직장이라고 말하고 싶다. 두 회사에서 일한다는 것은, 엄청 똑똑한 (스마트) 엔지니어와 일할 수 있다는 것을 의미하고, 수많은 사람들을 위한 정말 최고 수준의 소프트웨어를 디자인(설계), 코딩, 테스트하고, 디플로이하고 유지보수 하는 일을 한다는 걸 의미하기 때문이다.  하지만, 두 회사는 세상을 생각하는 방식이 극과 극의 정반대에 위치하고 있다. 그리고, 그 극과 극 회사의 문화 가운데 내가 있다. 나란 사람은 절대로 사라지지 않는 부정할 수 없을만큼 강한 아마존 액센트를 가진 자랑스런 구글러다. 이상한 두 가지를 다 가진 혼합형 인간 (hybrid dude) 이다.

내 생애를 보면, 혼합형(하이브리드)이 된게 처음은 아니다. 나는 아르젠티나에서 태어나고 자랐다. 15살이 되었을때 미국으로 왔고 그 이후 계속 미국에 산다. 나는 아르젠티나 사람이고 미국사람이지만, 또한 아르젠티나 사람도 미국사람도 아니다.  (이건도 뭔소리??)  나는 걸어다니는 모순이다. 내가 미국에서 지낸 기간이 얼마나 오래되었는지와 상관없이, 나는 절대로 진짜 100% 미국인이 될 수 없다. (하지만 괜찮다. 내 아내는 내 남미적 특징(?? Latin Flair)를 좋아한다고 말한다). 나에게는 남미인임을 명확히 드러내는 특징, 믿음, 행동을 내면 깊숙히, 어떤것은 무의식중에 지니고 있다. (예를 들면, FIFA 월드컵 동안 내가 얼마나 TV를 보며 소리치며 울부짖는지..) 

=> 이부분에서 고개를 끄덕이게 됨. 이 사람 남미사람이네..  한국살때는 축구가 세계에서 제일 인기있는 종목인줄 알았고 월드컵 기간에는 세계인이 모두 잠을 못자는줄 알았음.  한데, 미국와보니, 미국에서는 축구가 우리나라에서 핸드볼 같은 취급을 받는다.  심지어 여자축구보다 의미가 없다.

그러나 1991년의 그 추운 비오는날, 비행기를 타고 부에노스 아이레스를 떠난 날, 내 인생은 어쩔 수 없이 바뀌게 되었다. 나는 다시는 100% 아르젠티나인 일 수 없을 것이다. 시애틀이 이제 내 집이다. 이곳이 내가 남은 생을 지내고 싶은 그런 곳이 되었다.

나는 이러한 패러독스를 끌어안았고 심지어 반기기에 이르렀다. 이러한 두 개의 서로 다른 문화를 통해 나는 세상에 대한 더 넓은 시각을 가지게 되었다. 내게 중요한 의미가 되는 각각의 문화로부터 나는 원하는 것을 고르고 선택할 수 있다. 서로 다른 두개의 문화가 내 안에서 교류하여 내게로 다가온다. 나는 어떤 사안을 여러 가지의 시각에서 볼 수 있다. 하지만, 제발 내가 하는 말을.. 두 개의 다른 회사 사이의 차이점에 관한 권위있는 가이드라고 생각지는 말길 바란다. 모두의 경험은 다르다 (다양하다). 여기에서 내가 하는 말을, 그저 예전에 아마존에서 일했던 (ex-Amazonian) 엑스 아마조니언이 바라보는 구글이라고 보면 그만이다.


구글은 몽상가(dreamer)를 뽑고, 아마존은 일꾼(builder)를 뽑는다.

첫번째 차이는 채용에 있다. 회사에 누구를 데려올 것인가를 고르는 기준이 회사의 DNA에 영향을 미친다. 나는 아마존에서 813회의 인터뷰에 참여했고, 구글에서는 지금까지 55회의 인터뷰를 진행했다. 두 회사 모두 인터뷰 과정이 어렵다. 근복적으로 매우 유사한 기술적 탐색이 이루어지는 인터뷰를 준비한다면, 리트코드(leetcode) 에 많은 시간을 투자해야 할 것이다. 구글은 높은 지능과 좋은 아이큐를 가진 사람을 골라내는데 포커스를 맞추는 반면, 아마존은 딜리버리 (자신이 맡은 프로젝트를 납품하는 책임감??이라고 해야하나?) 와 실용주의 (행동, 실천 우선..이라고 해야할듯)에 초점을 맞춘다. 아마존은 상황적 질문이 아닌, behavioral questions (이것은 아마존의 리더십 프린시플과 관련한 질문들을 말한다.. ) 에 무게를 둔다. 즉, 과거에 delivery와 관련하여 (제품을 납품하는 일)자신이 얼마나 실천적인 행동을 했는지 보여주는 사람을 뽑는다는 것이다. 

내가 좋아하는 구글의 장점

구글에서 내 주변의 사람들을 보면 이들의 높은 지능/아이큐에 나는 놀라게 된다. 그리고 겸손해진다. 내 주변의 사람 하나 하나가 다 나보다 똑똑하다. 때로 사람들은 순전히 좋은 지능 만으로 매우 어렵고 거의 불가능에 가까운 기술적 문제를 푼다. 이들은 드리머다 (Dreamer).  세계는 이들을 필요로 한다.

구글 내가 싫어하는 점

문제 해결 시, 자기-인센티브는 그 문제가 높은 지능을 요하는 어려운 문제라는 점에 있을 것이다. 일단 이걸 풀면, 그러나 다음에 올 것에 별 흥미를 느끼지 못하게 마련이다. Launching something (어떤 것을 론칭하는 것)과 landing something (어떤 것에 도달하는 것) 간에는 커다른 차이가 있다. 일단 니가 짠 코드가 프로덕션에 들어가게 되면, 이 변경된 부분이 사용자들 간에 잘 알려지도록 해야 하고, 고객들을 교육시켜야 하고, 잘 쓰이게 해야 하고, 더 나아가 이를 나은 방향으로 계속 발전시켜야 한다. 아마존은 이에 관한 한 무자비할 정도로 실천적이고 체계가 잡혀있다. 문제를 해결하는 주요 동기가 머리 좋은 사람 만 풀수 있는 문제여서가 아니다. 이 문제를 해결했을때 우리가 성취할 수 있는 그 영향력에 있다. 이들은 일꾼(builder)이다. 일꾼 또한 필요하다.

나의 평결

나는 중간이 좋다. 두 회사 간의 밸런스를 잘 갖춘 수많은 사람들을 만났다. 그러나 궁극적으로 나는 인터뷰 과정의 이러한 차이가 두 회사의 극명하게 다른 특성을 만들어낸다고 생각한다.


구글은 공감을 주고, 아마존은 가차없이 해고한다. 

이건 좀 당연한 얘기 같다. 누군들 사람을 대놓고 해고하는 회사에서 일하고 싶을까? 아마존의 업무환경이 가혹하다는 것은 부정할 수 없을거다. 모두에게 그렇다는 것은 아니다. 내가 아마존에서 일할 때, 엔지니어 인원 중 하위 5%의 사람들을 정기적으로 해고했다. 내가 매니저 였을때는 내가 사람을 해고했다. 매니저가 아닐 때는, 내 주변의 매니저들에게 사람을 해고하라고 종ㅇ용했다. 이 때문에 아마존은 극도로 홀쭉한 조직을 유지할 수 있다. 반면 구글은 채용 기준이 매우 까다롭지만, 일단 구글러가 되면 심리적인 안전망 안에 머물 수 있다

내가 좋아하는 구글의 장점

내일 짤릴지도 모른다는 걱정이 없다는 것. 이것은 엄청난 안도감을 준다. 이 때문에 업무로 인한 신체적 긴장감이 덜하게 된다. 사람은 정말 일을 잘 해낼 때가 있는가 하면, 그렇지 않을 때도 있다. 구글의 이러한 접근은 보다 전체적이고 장기적인 것에 포커스를 두게 한다. 공감 (Empathy)은 구글의 좋은 특성이다. 구글이라는 회사가 나를 "사람"으로 대접하고 있다고 믿는다.

며칠 전, 나는 동료와 함께 점심시간에 이러한 주제로 갑론을박 한적이 있다. 그는 나에게 이렇게 물었다. "너는 상위 5%, 하위 5%에 둘 다 속해 본적이 있어?". 나는 그렇다고 대답했다. 내가 마이크로소프트, 아마존, 구글에서 일해왔던 25년의 내 커리어 동안 여러 시기에, 여러 이유로 나는 하위 5%에도, 상위 5%에도 속한 경험이 있다.  또 이렇게 물었다. "니가 하위 5%를 치고 내려갔는데도 짤리지 않았을 때 기쁘지 않았어?" 라고.

구글 내가 싫어하는 점

회사 시스템이 허용하는 한 어떠한 자유든 누려보고 싶은게 사람의 본성이라 생각한다. 해고되지 않는 한, 최소의 일을 할 수 있는게 사람이다. 일부러 또는 악의적으로 이렇게 하지 않는다 해도, 무의식 중에 이런 식으로 행동한다. 내가 하위 5%에 속했을 때 내가 정확히 이렇게 행동했다. 그때는 그걸 몰랐는데 이제 되돌아보니 분명히 알 수 있다. 나는 내 커리어를 망치고 있었고, 내 팀, 나아가 내 회사를 망치고 있었다.

이런 타성은 전염성을 가진다. 구글 뿐 아니라 그 어떤 회사가 되었든 이 타성은 팀내에 퍼질 수 있다. 어떤 별볼일 없는 한 개인이 이러한 타성을 보편화할 수 있고 이것이 팀 전체의 기준이 될 수 있다. 일단 팀 기준이 이러한 타성에 맞추진다면, 이를 다시 재교정하는 것은 극도로 어렵다. 이렇게 느끼는 건 나뿐이 아니다. 구글의 CEO인 Sundar는 최근 우리가 집중력을 재정비해야 한다고 분명히 말했다. "전반적으로 우리 회사의 생산성이 우리가 가진 인력에게 필요한 것에 미치지 못한다는 우려가 있다" .

나의 평결

이건 그저 내 개인적인 이론일 뿐. 그러나 낮은 생산성을 보이는 근로자를 향한 공감 (동정?) 은 고(높은) 생선성을 가진 자에게 향하는 공감의 부족이다, 라고 해석할 수 있으며 그 반대로로 해석할 수 있다고 생각하기 시작했다. 여기서, 다시 중간지점을 보고 싶다. - 힘들어하는 엔지니어를 PIP (Performance Improvement Plan)에 보내 적절히 해고하는 것을 걱정하지 않는곳, 그러면서도 동시에 엔지니어의 하위 x%를 정기적으로 제거해야 한다고 주장하지 않는 곳.  심리적인 안전 망 속에서 편안히 더 일을 잘하면서도, 점검과 밸런스를 잘 하자. 


=> 이 부분. 하위 5% PIP 보내 자르기.  이것은 과장이 아니고, 올 4월에 실시한 나와 우리팀 멤버들의 1년 업무평가 미팅을 토대로 볼때, 우리 팀의 경우 하위 10%를 매년 잘라냄... 팀원 8-9인데 한명씩 계속 없어짐.  한명은 UW를 나온 중국 남자였는데, college graduate으로 인턴 잘 마치고 오퍼받고 우리팀에 입사.  몇달 일했는데, 애가 좀 느림. 그치만 내 생각에 나름 그애가 잘하고 있다고 생각함.  그러던 중, 갑자기 연초 삼월쯤부터 안나타남.  매니저가 팀 미팅에서,, 사이먼이 개인 사정으로 휴가를 냈으나 언제 올지 모른다고 함.  사실 나는 그게 비자 문제라고 생각했음.  그런데, 한주, 두주가 지나도 안나오더니, 매니저 왈, 사이먼 그만 두었음. 인사할 틈도 없이 가버렸다며, 우리가 아쉬워함. 더 좋은 회사 (구글 같은. ) 갔나부다. 끝.  

비슷한 시기 (2021년), 인턴이 들어옴. 금발머리 미국애. 오하이오 주립대 출신, 내가 멘토하고 같이 프로젝트 진행. 애가 정말 드럽게 느림. 코딩은 발로 하는 수준임. 인덴트도 안맞고, 옵티마이즈 같은 거 전혀 바랄수 없음. 하지만 아직 대학생이고 (나두 대학때는 발코딩 수준..), 착하고 예의 바르고, 나름 열씸히 하려는 마인드가 있어서 조건부 합격. (잘 가르치기로 함).  졸업 후 우리팀 입사.  여전히 너무 너무 일이 느림.  아마존은 딜리버리 비율 (적기 남품)이 정말 중요함. 스프린트 2주동안 하겠다고 한거 마무리 하도록 최대한 노력해야 함.  근데 이거 거의 안지키고 계속 느리게 하더니 다음해에 자기 PIP 되었다고 나에게 말함.  이때서야 나는 PIP의 실체를 알았고.. 근데 이애는 아직도 PIP 졸업하려고 열심히 노력하고 있고, 아직 짤리지 않음.. :)

......

기사 무지 길다.  to be continued....

원문 링크



2022년 10월 19일 수요일

새로운 팀 적응 2탄 - 악몽의 온콜 시작

아마존에서 일할 때 힘든 것 중 하나가 온콜(on-call) 일 것이다.  온콜은 한 주 동안 해당 팀에 들어오는 여러가지 이슈들을 처리하는 당직 같은 개념이다. 오프콜인 경우, 스프린트에서 적당한 태스크를 어사인한 후 그 일을 해나간다. 이게 대부분 팀 멤버들이 하는 일이고, 온콜에 배정되면 다른 팀에서 들어오는 여러가지 ad-hoc 요청들이나 온콜 티켓들을 한주동안 처리하는 것이다.  온콜 하는 동안은 스프린트 일은 면제됨.

여기에서 티켓(TT: Trouble Tickets)이라고 하는게 있는데 팀 간에 뭔가 요청하고 싶을 때  해당 팀으로 TT를 만든다. 보통 cut a ticket to the team 이라고 부른다.  마치 은행에서 티켓을 끊고 자기 순번을 기다려 서비스를 받듯이, 어떤 팀에 볼일이 있을 때 (예: 에러 로그 요청 , investigation 부탁, 데이터 요청, 마이그레이션 요청 등..) 티켓을 끊고 서비스를 기다린다.  서비스를 누가 하느냐?  해당팀의 온콜이 처리한다.  티켓은 severity 가 있어서, severity에 따라 팀마다 SLA (Service Level Agreement)가 있다.  뭐 어떤 팀은 severity 3의 경우, 비즈니스 데이로 5일 안에 답을 하겠다라든지.. 

사람이 이렇게 요청하는 티켓을 매뉴얼 티켓이라 부른다. 반면 auto-cut 티켓도 있다.  우리팀의 서비스에 metrics를 이용해, 어떤 이상한 현상이 발생하면 auto-cut 티켓이 자동 발행 되도록 alarm을 걸어 놓을 수가 있다. (threshold와 duration 을 이용)  온콜은 이런 오토컷 티켓도 처리해야 한다.  보통은 오토컷은 무쟈게 심각한것이 아니면 안들여다보게 된다.  시간이 좀 지나면 OK로 바뀌는 경우가 허다하기 때문에...  


원래의 얘기로 돌아가서, 새로이 팀을 옮기니 온콜을 하지 않아도 되어서 넘 좋았다.  그러다 결국 1달쯤의 적응기를 지난 후, 온콜 로테이션에 합류하게 되었고 2주전에 첫번째 온콜을 시작했다.  사실, 개인적으로 온콜이 그다지 싫지는 않다.  팀 내의 여러가지 이슈를 볼 수 있어서, 팀 내의 다양한 이슈와 시스템을 이해하는데 온콜 듀티는 매우 도움이 된다.  하지만, 온콜이 힘든 이유는 sev2 ticket 때문인데... ticket의 severity는 1부터 5까지 이나, 아직 나는 severity 1 짜리 티켓을 받아본적은 없다. 얼마전에 다른팀에 sev1 짜리 티켓이 있는걸 보기는 했다.

sev2부터 시작인데, sev2가 발생되면, page가 울린다. 예전에는 정말 의사들처럼 페이저를 지니고 다녔다고 들었다.  이제는 스맛폰이 있으니, 여기다가 앱을 깔고, sev2가 온콜큐에 들어오면 시끄럽게 울린다.  이 소리는 정말로 시끄럽고 귀를 쑤시는 듯한 소리가 나서, 자다가도 벌떡 일어나게 된다.  왜냐면 어느시간에 이게 울리더라도 일어나서 렙탑을 열고 문제를 시간 안에 해결해야 하기 때문이다. (sev2.5 라는 것도 있는데, sev2 처럼 페이저가 울리기는 하지만, 데이타임 sev2다. 근무시간 시작하면 울리는 sev2 티켓이다.)

여태까지 온콜 중 가장 최악의 온콜 기간이었는데, 지금까지 내가 받아본 sev2 중 가장 많은 수의 sev2를 한주동안 받았다. 자그마치 9번 울렸다.  먼저 팀에서는 기껏해서 2-3개 정도면 많다고 그랬는데, 이놈의 팀에서는 첫번째 온콜에 9번. 최악이다.

더욱 최악인건, 유럽에서 일어난 문제여서, 여기 시애틀과는 시간이 정반대다. 목요일 온콜을 시작했는데 목요일 퇴근 후 7시경에 문제가 발생. 똑같은 이슈로 그 다음날 새벽 1시 반.  그 다음날은 또 다른  이슈로 새벽 2시, 5시.  <-- 이건 심지어 토요일 새벽.

계속 자다깨서 일처리를 하다보니 한주동안 정말 비몽사몽이었다. 


이번의 악몽같은 온콜은, 그러나, 비일비재한 일은 아닌 거 같다. 매니저 또한 그렇게 강조했다.  그저 내가 운이 나쁠 뿐이었다.  여러가지 조금 조금한 악재들이 겹쳐져서 대형 사고가 발생한 것.  아직도 사실은 해결되지 않았고, 여러 팀의 문제가 엮여 있었던 것이라 .. 아직도 원인 규명 중.

뭐 이런 악재가 아니라면, 온콜은 분명 할만 하고, 시스템과 팀이 어떤식으로 일하고 돌아가는지, 다른 팀과의 역학관계가 어찌되는지를 파악하는데 참 좋은 경험이 된다.  (이렇게 생각하자)

잔디 3주차

 잔디 심기. 3주차에 접어들었음. 사진. 아래가 1일차 사진. 다음이 3주차.