잔디 3주차

 잔디 심기.

3주차에 접어들었음. 사진.

아래가 1일차 사진.

다음이 3주차.

앞마당 잔디 심기 (1일차 vs. 1주일 차)

 우리가 이사왔을 당시에는 앞마당 잔디 상태가 좋았는데, 관리를 제대로 못한 탓인지 많은 부분이 죽어버렸다.  듬성 듬성.  

계속 생각만 하다가 빈 곳에 잔디를 패치하기로 하였다.

이게 작업하기 전 잔디상태.  너무 심각하다.  패치가 아니라 전부 다시 깔아야 할듯.

아마존에서 이런 잔디 팩을 구입했다.

10lb가 어느정도인지 몰라서 하나 구입해봤는데, 이걸로는 택도 없다.  20 lb 두개를 홈디포에서 더 구입해서 총 50 lb를 뿌렸다.  다 뿌리고 물 준 사진이 이거다.  갈색이 나는 정도로 뿌리면 됨.

이렇게 잔디를 뿌린날이 지난 월요일. (9월 4일). 레이버 데이 노는날이라 작업하였다.

오늘은 1주일이 지난 토요일.  정확히는 아직 1주일이 지난것은 아님.

매일 저녁 개 산책전에 스프링클러를 돌리고 개산책후 닫았다. 1시간 정도씩 돌림.

스크링클러로 다 커버가 안되는 부분은 직접 물을 뿌렸으나, 그 부분들은 싹이 좀 안난편.

물이 정말 중요한가부다.

전체 사진을 보면 별차이 없음. 

자세히 두눈 부라리고 봐야 겨우 보임.  그치만 싹이 자라고 있는게 관찰됨.

요즘 하는 일 COE (Correction of Error)

이번 스프린트에서 내가 맡은 일: COE action item.  

아마존에는 COE (Correction of Error)라는 프로세스가 있다. 이 페이지에 자세히 나온다. https://wa.aws.amazon.com/wat.concept.coe.en.html

뭔가 고객에게 지대한 영향을 미치는 문제 (이슈)가 발생했을때, 이것을 일단 해결한 후 COE라는 과정을 수행해야 한다. 페이지에 보니까 이슈를 문서화하고 해결하여 품질을 개선하는 과정이라고 나온다. COE는 템플릿이 있어서 그거에 맞게 모든 사항을 다 적시해야 한다. 뭐랄까, 언제, 왜, 어떻게, 그리고 정량화된 자료가 또 있어야 한다. 몇 개의 디바이스가 영향을 받았는지, 몇 개의 ASIN의 attributes이 잘못되었는지 등등.  

가장 중요한 것은 원인 (Root Cause) 규명 (identify)일텐데, 원인 규명 후, 이러한 일이 재발하지 않도록, 또는 재발하더라도 더 빠르게 우리가 알아채서 영향 범위를 줄이려면 뭘 해야 할지, 액션 아이템을 만들어야 한다. 주로 메트릭스, 알람 이런거 재조정하거나 추가하여 더 빠르게 알아챌 수 있게 하고, 버그에 의한  것이라면 버그 고치는 것은 당연히 액션 아이템이 되겠다.

이번 스프린트에서 내가 하고 있는 일은, 약 한달전 우리팀에 Sev2 이슈가 있었고, 그로 인한 COE를 작성했었고, 그 결과 몇 가지 action items이 만들어졌는데 그 중 하나다.  

그 이슈로 인해 좀 많은 일이 발생했는데, 원인은 어이없게도 이 한줄의 코드 때문이었다.

전체를 좀 자세히 보여주기는 뭣해서 이 한줄을 가져왔는데, activeWeblabOverride() 라는 애는 private function 이다. 이렇게 생겼다.

private String activeWeblabOverride(String a, String b, String c)

그러니까, activeWeblabOverride()이 NULL을 리턴한 경우가 발생했고, 그 결과 NPE (NullPointerException)가 발생했다. 

이런 코드 체인지는 코드 리뷰 중에 걸러졌어야 하나 그러지 못하였다. 두 개의 스트링을 equals로 비교시, 하나의 string이 constant 라면 (이 예에서는 "T1") constant를 반드시 먼저 써줘야 한다. 그래야 activeWeblabOverride()이 NULL을 리턴하더라도 T1과 다르니 false를 리턴한다. 

이 한줄의 코드로 어마 어마한 자원 낭비가 발생했고, 많은 문제가 발생했다. 

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

 회사에 가끔 올라오는 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....

원문 링크

새로운 팀 적응 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시.  <-- 이건 심지어 토요일 새벽.

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

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

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

제프 베조스의 메커니즘 (Mechanism) - not asking for good intention

새로운 팀에 오니 처음 아마존에 조인했을때와 비슷하게 적응기간이 주어졌다.  물론 계속 적응만 하고 있을 수는 없어서, 지난주에는 task를 하나 배정받아 처리했다.  그래도 사이 사이 시간에 그동안 미뤄두었던 교육 (training)을 마무리하였다.

오늘 오전에 받은 교육 - 교육명은 "메커니즘 (Mechanisms eLearning)".

처음에는 이게 머신러닝 교육인줄 알았다.. 풉.. 전혀 다른 내용.

예전의 CEO였던 제프 베조스가 말했던 것중 하나, 메커니즘에 관한 내용이었다.

YouTube에 관련 동영상이 있나 찾아봤는데, 못찾았음.

암튼, 15분 정도 되는 영상이었는데, 내용이 참 재밌다.

조직에서 뭔가 잘못되거나 개선할 부분이 있을때 보통 하는 방식이, 관련자들을 주욱 미팅룸에 모아놓고, 이러이러하니 잘 해보자. 더 열심히 하자 (work harder) 인데, 이 방식은 주로 잘 안먹힌다.  왜 그럴까?  라는 내용이다.

이유는 이미 좋은 의도를 가지고 열심히들 하고 있기 때문에, 잘하자 라고 말한들 개선되지 않는다는 것이다.

그럼 어떻게 개선할까?   답은 메커니즘이다.  개선할 부분을 식별한 후, 이것을 개선할 수 있는 도구 (Tool)을 만들고 적용 (adopt) 하는 것. 그리고서 이것을 계속해서 감시(inspection/audit) 하는 것: 즉 고안한 툴을 적용하여 원하는 결과가 도출되는지 계속해서 감시하며 (일종의 오디팅), 툴을 계속 개선해 나가라는 것.

하나의 재미난 예를 들었다.  예전에 제프 베조스가 고객서비스 담당자 (CS rep)와 나란히 앉아서 고객의 콜을 받은 얘기를 들려주었다.  고객이 아마존에 전화를 걸었고, 고객은 자기가 주문한 테이블이 마음에 안드니 반품하고 싶다는 것이다. 커다란 테이블을 어떻게 반품할지 하는 전화였다.  제프는 왜 테이블이 맘에 안드는지 궁금했고, 고객서비스 담당자는 이미 알고 있었다. 저 테이블은 계속해서 반품이 들어오는데, 고객에게 배달할 때 패키징이 잘 안되어, 테이블 표면에 스크래치가 많아, 저 테이블을 산 고객은 거의 언제나 반품하고 싶어한다고 제프에게 말했다.

이렇게 반복되는 문제 (over and over again)를 해결하기 위한것이 메커니즘이다. 여기에서 또 토요타의 Andon Cord가 등장한다. 예전에 토요타는 자동차 회사 이기 이전에, 직물을 만들던 회사란다.  실크를 제작하는데, 조금의 하자가 발생하더라도 줄을 당겨서 누구라도 전체 제작 프로세스를 멈출수 있도록 하는 방식이란다.

아뭏든, 이와 마찬가지 툴을 적용하여, 고객서비스 담당자라면 누구나 buybox를 내릴 수 있도록 하는 방식을 적용하였다. (바이박스라는 것은 아마존 사이트에 아이템을 구입할때 고객이 누르는 버튼.. 이걸 내리면 (화면에서 없애면), 고객은 제품을 주문할 수 없다)

고객담당자는 고객과의 커뮤니케이션을 통해 제품에 대해 가장 잘 알고 있는 사람이다. 제품에 하자가 발생한 경우 이 바이박스 (buybox)를 내려 제품을 구매할 수 없게 한것.. 이런 제품들은 제대로 fix한 이후에라야 다시 주문가능해진다. 이런 제품들이 제시간안에 fix될 수 있도록 하는 메커니즘도 존재할 것이다. (이건 자세히 몰것다).

이러한 메커니즘은 우리의 팀 일상에서도 자주 강조되는 것이다. 자주 발생하는 문제들을 그냥 방치하기 보다는, automatically (program으로) 처리할 수 있도록 하거나 root cause를 해결하도록 강조하는 것과 같은 맥락일 것이다.

새로운 팀으로 이동

시간은 빨리도 흘러, 벌써 입사한지 3년 반이 되었다. 그동안 줄곧 한팀에서 일해왔다. Amazon Device org 내의 팀이다. 우리팀에 있던 기존 팀원들도 하나둘 다른 회사로 가거나 다른 팀으로 이동하더니, 내가 거의 최고참이 되었다.  아마존에서는 1-2년 사이에 많이들 이동한다. 나를 포함한 세명이 최고참 급이었는데, 우리는 거의 같은 시기에 팀에 조인하였다. 그게 2019년 초였다.

내가 많이 따르던 우리팀 메니저 또한 올초 다른 팀으로 이동.  그러던 중, 그 매니저와 얘기할 기회가 생겼는데, SDE 를 채용한다는 얘기를 들었다.  몇 번 얘기하다가 그 팀도 괜찮을거 같고, 나도 마침 옮기고 싶은 생각이 들어서 이동하기로 결정하였다.  결정하고 offer letter에 사인한 것이 7월.

다른 팀으로 이동하기로 하고서 한국으로 휴가를 갔다온 후, 새 팀에 합류하였다.  이번주가 첫번째 주.

새로운 팀은 나를 포함하여 8명의 팀 멤버와 1명의 매니저로 구성. 이 매니저가 나와 일하던 매니저다.

8명 중 1명이 가장 오래있었던 SDE인데, 이 org에서 인턴을 하고 이 팀에서 일한지는 1년이 조금 넘은 친구다.  그래서 이 사람이 가장 시스템 관련해서 많이 아는 거 같다.  매니저는 이 사람을 내 onboarding buddy로 assign해 주었다. 근데 사실 그사람이 많이 바쁜거 같아 뭘 물어보기도 참 어려운 지경.

두번째로 오래있었던 사람이 8개월 된 사람.  8개월정도 된사람이 두 사람있다. 그리고 나머지는 나처럼 최근에 들어온 사람인듯.  모두들 좀 아직 어색한거 같은게.. 전에 있던 팀에서는 팀 미팅 할때 미리 조인하면 안부도 묻고 농담도 하고 그랬는데, 여기는 다들 mute한채로 너무 너무 조용하다. 할말만 하고.   팀 미팅도 별로 없다.  그나마 매일 하던 standup 회의 조차 일주일에 두번으로 줄이고, 나머지 삼일은 slack에 텍스트로 update 하기로 했다고.

먼저 있던 팀에서 옮길 맘이 들었을때는, 너무 미팅이 많아서 일할시간이 없을정도 였는데, 여기는 또 너무 미팅이 없어서 좀 이상하다.  팀마다 굉장히 다르다.