구글 엔지니어는 이렇게 일한다

p.73

인간은 본능적으로 리더와 롤모델을 찾고, 그들을 우상화하고 흉내 내려 합니다. 우리 모두에겐 영감을 줄 영웅이 필요하며, 프로그래밍 세계도 다르지 않습니다.

 

p.74

천재라고 해서 괴짜처럼 행동하는 게 용서받는 시대는 지났습니다. 천재든 아니든 사회성이 부족한 사람은 팀원으로 적합하지 않기 때문이죠. 구글에서의 업무 거의 대부분이 천재 수준을 요구하지 않는 반면, 모든 업무가 최소한의 사회성을 요구합니다.

뛰어난 스킬 보다는 협업 능력이 더 중요한 시대이다. 소통하기 힘든 사람이 일 못하는 사람보다 더 스트레스 받는다.

 

p.76

최소한 각 책임 영역마다 2차 소유자(담당자)를 두고, 제대로 된 문서를 갖춰 둔다면 프로젝트의 미래를 보장하는데 도움이 됩니다.

 

p.78

프로젝트는 빠르게 진화하기 때문에 변화하는 환경에 잘 적응해야 합니다. 생각하지도 못한 설계 장애나 정치적인 장벽에 부딪히거나 단순히 무언가가 계획한 대로 동작하지 않을 수 있습니다. 요구사항이 기대와 다르게 바뀔 수도 있고요. 여러분이라면 계획이나 설계 변경이 필요한 시점을 알려줄 피드백 루프를 어떻게 마련할 것인가요? 정답은 팀 플레이입니다. 눈이 많아야 버그가 줄어든다라는 말을 많이 들어봤을 텐데, 눈이 많아야 프로젝트가 탈선하지 않고 옳은 방향으로 나아간다라는 표현이 더 나을 것 같습니다.

 

p.83

혹시 여러분은 모든 논의 주제를 시작하고 마무리 짓는 사람이 자신이어야 한다고 생각하나요? 제안이나 안건마다 사사건건 첨언하고 싶은가요? 혹은 주변에 이런 사람이 있나요? 모든 걸 다 아는 듯 행동하지는 말라는 뜻입니다. 더 나은 방법이 있습니다. 바로 집단적 자존심을 찾는 것이죠. 자신이 잘 아는 분야에 대해 걱정하는 대신 팀의 성취와 단체의 자부심을 높이려 노력하세요.

 

p.85

구글에서 제가 정말 좋아하는 좌우명은 ‘실패는 선택이다’ 입니다. 구글에서는 가끔씩 실패하지 않는다면 충분히 혁신적이지 않거나 위험을 충분히 감수하지 않은 것이다라는 믿음이 널리 통용됩니다. 실패를 배우고 넘어갈 수 있는 절호의 기회라고 생각하는 것이죠.

 

p.86

실패한 근본 원인을 분석하여 문서로 남기는 것이 실수로부터 배우는 핵심입니다. 이를 구글은 포스트모템이라고 합니다. 훌륭한 포스트모템(사후의)에는 다음 내용이 담겨야 합니다. 사건의 개요 사건을 인지하고 해결에 이르기까지의 타임라인 사건의 근본 원인 영향과 피해 평가 문제를 즉시 해결하기 위한 조치 항목(소유자 명시) 재발 장지를 위한 조치 항목 해당 경험에서 얻은 교훈

실패를 경험해야 배울 수 있다기 보다는 복기를 해야지만 실수로부터 배울 수 있고, 개선 할 수 있다.

 

p.88

팀원은 동반자이지 경쟁자가 아닙니다. 여러분 모두는 같은 목표를 향해 달려가는 중입니다.

프로젝트에 참여한 모든 구성원은 동반자이지 경쟁자가 아니다. 기억하자.

 

p.93

전문가가 일대일로 해주는 조언의 가치는 언제나 이루 말할 수 없이 큽니다. 또한 개개인의 전문 영역이 다르므로 팀원 한 명 한 명이 특정 분야에서 최고의 조언자가 되어줄 수 있습니다. 하지만 전문가 한 명이 휴가를 떠나거나 다른 팀으로 옮긴다면 팀이 휘청거릴 수도 있습니다. 이처럼 사람 사이에 일대일로 이루어지는 조언은 어떤 측면에서는 매우 효과적이지만, 확장성이 부족하여 팀이 커지면 그리 유용하지 못합니다. 한편 문서화된 지식은 팀을 넘어 조직 전체로 퍼뜨릴 수 있습니다. 팀 위키 같은 도구를 활용하면 많은 사람이 참여하여 자신들의 전문성을 더 큰 그룹과 공유할 수 있습니다. 이처럼 정리된 문서가 일대일 조언보다 확장성이 좋지만 감수해야 할 트레이드오프도 있습니다.

일을 하다보면 굉장히 많은 순간 순간들에서 1:1 피드백이 이루어진다. 만약 이런 조언들과 피드백들이 문서화된다면 더 많은 사람들에게 지식이 전파될 것이다.

 

p.98

초심자가 저지르는 가장 큰 실수는 무언가 막혔을 때 질문하지 않는 것입니다. 혼자서 극복해내고 싶다거나 '너무 기초적인' 질문이란 소리를 듣는 게 두려워서일 수 있습니다. '이게 뭔지 모르겠는데, 설명 좀 해주시겠어요?' 라고 말하는 걸 두려워하지 마세요. 모르는 분야가 나오면 두려워하지 말고 성장하는 기회로 받아들이세요.

동작하는 원리를 모르겠다면 물어보자. 질문은 배움에 있어서 가장 활용 가치가 높은 도구이다.

 

p.100

'무언가를 옮기거나 바꾸려면 그게 왜 그 자리에 있는지부터 이해하자'라고 말하는 체스터슨의 울타리 원칙을 떠올

려보세요. 도로를 가로지르는 울타리가 있다고 해보죠. 전통에 크게 신경 쓰지 않는 유형의 개혁가는 '무슨 용도로 울타리를 이렇게 설치했는지 모르겠군요. 깔끔히 밀어 버립시다'라고 말할 것입니다. 반면 더 현명한 개혁가는 '용도를 모르겠다면 그냥 밀어버리게 둘 순 없죠. 가서 더 생각해봅시다. 용도를 알아내면 그때 철거할지 결정하자구요.'라고 말할 것입니다.

다른 사람이 개발한 프로젝트를 내가 맡게 되었다. 유지보수 하는 과정에서 “이 코드는 아무리봐도 필요 없는 코드인데 왜 있지?” 라는 생각을 가졌었고, 과감하게 지워버렸다. 그리고 장애가 났다. 이처럼 거의 대부분의 코드는 다 이유가 있어서 그곳에 프로그래밍 된 것이다.

 

p.101

그룹 채팅을 이용하여 질문한다. 그룹 채팅은 간단한 질문에 적합

 

p.109

높은 수준의 기술 리더십을 요구하지만, 모든 리더십이 기술 문제와 관련된 것은 아닙니다. 리더는 주변 사람들을 성장시키고, 팀의 심리적 안전을 개선하고, 팀워크와 협업 문화를 조성하고, 팀 내 긴장을 해소하고, 구글 문화의 가치를 설정하며, 구글을 더 활기차고 신나는 일터로 가꿔야 합니다. 괴짜는 좋은 리더가 아닙니다.

 

p.112

구글 내부에서는 go/ 링크를 가지고 있습니다. 예컨대 go/spanner는 스패너 관련 정보를 가르키고, go/python은 구글의 파이썬 개발자 가이드를 가리킵니다. 실제 정보가 어디에 저장되어 있느냐는 신경 쓸 필요 없는 직관적이고 기억하기 쉬운 접근 수단이 되어줍니다.

좋은 방법이다. 나중에 써먹을 기회가 온다면 이 방법을 적극적으로 검토해 봐야 겠다.

 

p.117

코드는 작성되는 횟수보다 훨씬 많이 읽힌다.

그렇네. 작성한 횟수보다 읽는 횟수가 더 많기에 가독성을 중요시 해야 한다.

 

p.120

지식은 비록 형태는 없을지라도 많은 측면에서 소프트웨어 엔지니어링 조직의 가장 중요한 자산입니다. 그리고 지식 공유야말로 조직에 탄력을 불어넣어 변화에 직면해서도 생존할 수 있도록 하는 데 결정적인 역할을 합니다. 개방적이고 정직한 지식 공유를 장려하는 문화는 지식을 조직 전반에 효율적으로 전파하여 날이 갈수록 조직이 더 확장되도록 해줍니다.

지식 공유를 진행해 보자. 우선 목표는 팀 회의 시간에 하자. 머리로 생각만 하지 말고, 행동을 해야 한다. 이 작은 행동이 더 큰 행동을 불러 일으킨다.

 

p.135

관리자는 사람을 이끌고, 테크 리드는 기술과 관련한 책임을 집니다.

테크 리드를 목표로 다양한 기술에 관심을 가지고 프로젝트를 성공적으로 이끌 수 있는 능력을 기르자.

 

p.145

여러분이 못본 척 하더라도 저성과자의 존재는 팀원 모두가 알고 있습니다. 사실 팀은 누가 저성과자인지를 아주 '정확하게' 꿰뚫고 있습니다. 왜냐하면 저성과자를 업고 뛰는 당사자가 바로 그들이기 때문이죠. 저성과자를 방치하는 일은 새로운 고성과자가 팀에 합류하는 걸 막기도 하며, 그나마 있던 팀내 고성과자를 떠나게도 합니다. 그러다 보면 스스로의 힘으로는 떠날 수 없는 저성과자로만 구성된 팀이 남게 됩니다.

어느 조직이든 저성과자는 존재 한다. 이 문장에서도 언급한 것 처럼 저성과자를 방치하면 안된다. 분명 저성과자를 고성과자로 만들 수 있는 방법은 있다. 여러 방면으로 시도하고, 변화를 이끌어 나가야 한다. 한 가지 조건은 리더가 리더다워야 저성과자를 변화시킬 수 있다. 자기 경영을 제대로 하지 못하는 리더라면 다른 사람들을 경영 할 수 없다.

 

p.159

이제 막 리더로 부임했다면 일거리를 팀원들에게 위임하려는 노력을 더 해야 할 가능성이 큽니다. 한편 팀을 이끈지 제법 되었거나 새로운 팀을 이끌게 되었다면 이야기가 다릅니다. 이때는 오히려 여러분이 직접 일을 처리하는 게 팀원들의 존경을 이끌어내고 팀의 업무 속도를 높이는 가장 손쉬운 방법입니다. 특히 아무도 하려 들지 않는 지저분한 일을 떠맡으세요.

이건 잘 모르겠네. 지저분한 일을 하게 되면 리더는 정신없어질테고, 여유가 없는 리더는 팀 관리에 소홀해 질 수 밖에 없다. 내 생각은 리더라면 최대한 팀원들에게 위임을 해야 한다. 그리고 좀 더 체계적이고 생산적인 팀이 되기 위해서 노력해야 한다. 리더가 일에 치이면 관리가 잘 안된다.

 

p.208

코드는 작성되는 횟수보다 읽히는 횟수가 더 많으며 시간이 지날수록 차이가 벌어집니다. 따라서 읽기 난해한 것보다 타이핑하기 지루한 편이 낫습니다. 구글은 쓰기에 간편함보다 읽기에 간단한 쪽에 가치를 둡니다. 트레이드오프를 한 것이죠. 엔지니어들은 변수와 타입 이름을 서술식으로 더 길게 짓고 반복해서 타이핑하기로 선택했습니다.

맞는 말이다. 코드를 작성하는 횟수보다 읽는 횟수가 훨~~~씬 많다. 가독성이 중요한 이유가 여기에 있다. 우리가 코드를 작성하여 만든 시스템은 오래도록 사용되어진다. 중간 중간 새로운 기능이 추가되고, 오류가 있으면 수정하게 된다. 이 과정속에 코드를 읽는 행위는 무한히 반복된다.

 

p.235

코드 리뷰는 전에 내린 설계를 번복하거나 재논의하는 자리여서는 안 됩니다. 설계를 결정하는 데는 보통 시간이 걸립니다.

코드 리뷰 시 하지 말아야 할 규칙에 포함시켜야 한다. (설계 번복 및 재논의 X)

 

p.240

코드 리뷰 프로세스와 코드 리뷰를 중요하게 다루는 문화가 주는 대표적인 이점 코드가 정확한지 확인해줍니다. 변경된 코드를 다른 엔지니어도 잘 이해합니다. 코드베이스가 일관되게 관리됩니다. 팀이 소유권(주인의식)을 더 강하게 느낍니다. 지식이 공유됩니다. 코드 리뷰 자체의 기록이 남습니다.

 

p.255

문서자료 개선에 더 힘써야 한다는 사실은 모두가 알지만 조직 차원에서는 문서자료가 선물하는 핵심 이점이 무엇인지 이해하지 못하고 있는 것입니다. 구글에서 문서자료를 개선하고자 해본 시도 중 가장 성공적이었던 방법은 문서자료를 코드처럼 취급하여 엔지니어링 워크플로에 통합하는 것이었습니다.

 

p.256

양질의 문서자료는 엔지니어링 조직에 커다란 축복입니다. 코드와 API가 이해하기 더 쉬워지고 실수가 줄어듭니다. 문서자료가 주는 혜택은 주로 후임자들에게 돌아가므로 작성자에게는 즉각적인 이득이 없는 경우가 많습니다. 혜택이 작성자에게 곧바로 돌아오는 테스트와 달리 문서자료는 일반적으로 선제적인 투자에 해당하며 작성자에게는 나중에까지도 명확한 혜택이 돌아가지 않기도 합니다. 하지만 테스트에 대한 투자와 마찬가지로 문서자료에 들인 노력도 날이 갈수록 가치가 커집니다. 문서자료는 단 한 번만 작성하면 되지만 결국 수백 번, 수천 번 읽히게 됩니다. 초기 비용은 미래의 모든 독자에게 혜택으로 돌아갑니다.

문저사료를 덜 중요하게 생각하는 이유 글쓰기를 프로그래밍과는 별개의 기술로 봅니다. 글쓰기에 자신 없어하는 엔지니어도 있습니다. 문저사료가 기존 코드를 유지보수하기 더 쉽게 해준다고 생각하기보다는 유지보수할 대상이 하나 더 늘어난다고 생각합니다.

 

p.259

문서자료는 소스 코드와 밀접하게 연관된 경우가 많으므로 가능한 한 코드처럼 다뤄야 합니다.

• 꼭 따라야 하는 내부 정책과 규칙이 있어야 합니다.
• 버전 관리 시스템에 등록해 관리해야 합니다.
• 관리 책임자를 명시해야 합니다.
• 변경 시 리뷰를 거쳐야 합니다.
• 코드상의 버그를 추적하듯이 문제를 추적해야 합니다.
• 주기적으로 평가를 받아야 합니다.
• 가능하다면 정확성이나 최신 정보 반영 여부 등을 측정해야 합니다.

 

p.261

엔지니어들이 문서자료를 작성하며 범하는 가장 중요한 실수는 자신만을 위해 쓴다는 것입니다. 자연스러운 행동이고 자신을 위해 기록을 남기는 것도 분명 가치가 있습니다. 실제로는 그 문서자료의 독자는 사내의 모든 엔지니어와 외부 개발자까지 상당히 다양할 수 있습니다.

회사 wiki 에 문서를 작성할 때 간혹 나를 위해 작성하는 경우가 있다. (물론 공개되는 문서를 작성할 때에는 잘 작성하려고 노력한다.) 나를 위해 작성하다 보니 설명이 부족한 경우가 많다. 앞으로는 나를 위한 문서를 만들 때에도 동료분들이 쉽게 이해할 수 있도록 작성하자.

 

p.277

오래된 코드와 마찬가지로 오래된 문서도 문제를 일으키곤 합니다. 세월이 흐르면서 문서도 낡고 쓸모없어지다가 종종 버려집니다. 문서를 버리는 일은 되도록 생기지 않도록 노력해야 합니다. 하지만 문서가 본래의 목적을 더 이상 수행할 수 없다면 폐기하거나 폐기 대상으로 표시해줘야 합니다. 구글에서는 문서자료에 신선도 보증 기간을 붙여두곤 합니다.

 

p.282

시스템을 더 많이 더 빠르게 변경하고 싶다면 더 빠르게 테스트하는 방법을 모색해야 합니다.

단위 테스트를 꾸준히 해야 하는 이유이다.

 

p.283

테스트는 엔지니어에게 신뢰를 줄 때만 가치가 있다는 사실을 잊지 마세요. 테스트가 생산성을 떨어뜨리고 고칠 게 계속 나오거나 결과를 믿을 수 없다면 엔지니어들은 더 이상 테스트를 신뢰하지 않고 우회 방법을 찾으려 할 것입니다. 나쁜 테스트 스위트는 테스트가 아예 없는 것만 못합니다.

 

p.286

전문 소프트웨어 테스터들이 시스템의 새 버전이 나올 때마다 모든 기능을 열심히 시험하며 검수하던 과거의 품질보증(QA) 프로세스와 달리, 오늘날의 개발자들은 자신의 코드를 검사하는 자동 테스트를 작성하고 수행하는 데 능동적이고 핵심적인 역할을 합니다. 테스트를 작성한 후에는 작성한 테스트를 실행해야 합니다. 수시로요. 자동 테스트의 핵심은 같은 동작을 끊임없이 반복하는 데 있습니다.

 

p.288

테스트 코드가 주는 혜택

• 디버깅 감소
• 자신 있게 변경
• 더 나은 문서자료 (동작이 궁금할 때 테스트 코드를 본다)
• 더 단순한 리뷰
• 사려 깊은 설계
• 고품질의 릴리즈를 빠르게

테스트 코드가 주는 혜택이 이렇게나 많은데, 왜? 우리는 테스트 코드를 만드는데 소홀히 하는가?

 

p.298

새로 합류한 직원들을 지도하다 보면 어떤 행위나 속성을 테스트해야 하냐는 질문을 자주 받습니다. 간단한 대답은 '깨뜨려보고 싶은 모든 것을 테스트하라'입니다.

모든 메서드를 다 테스트 하면 된다. 대신 메서드 하나에는 하나의 기능만 담겨져 있어야 한다. 여러 기능이 담겨져 있으면 테스트 하기 어려워진다.

 

p.299

코드 커버리지는 어느 테스트가 기능 코드의 어느 라인을 실행하는지를 측정하는 수단입니다. 100라인짜리 코드가 있고 테스트가 90라인을 실행했다면 코드 커버리지는 90%입니다. 코드 커버리지는 호출된 라인 수만 셀 뿐, 실행 결과로 어떤 일이 벌어졌는지는 고려하지 않기 때문입니다. 더 큰 문제는 여느 지표와 마찬가지로 커버리지 자체가 목표가 되기 쉽다는 현실입니다. 많은 팀이 코드 커버리지 목표를 세워두곤 합니다. (가령 80%) 코드 커버리지는 테스트되지 않은 코드가 어디인지는 알려줄 수 있지만, 시스템이 얼마나 제대로 테스트되었느냐를 판가름하는 지표로는 적합하지 않습니다.

 

p.303

엔지니어들이 테스트에 관심을 갖도록 장려하세요. 마치 훌륭한 기능을 출시했을 때와 똑같이 테스트를 견고하게 만든 엔지니어에게 보상해주세요.

 

p.309

조직의 테스트 문화를 바꾸는 데는 시간이 걸립니다.

 

느낀점

구글이 왜 구글하는지 알겠다.

기술적으로나 문화적으로 시스템이 잘 갖춰져 있다.

사실 구글에서 일하는 사람들은 괴짜가 많을 거라 생각했다.

하지만 실력있는 괴짜보다는 협업 능력이 좋은 직원을 더 우선시하는 문화를 가지고 있다.

시스템을 잘 동작 할 수 있게 만드는 가이드라인

그리고 시스템을 만들어 나가면서 자연스럽게 생겨나는 문서들 조차도 가볍게 여기지 않고, 체계적인 가이드라인을 만들어 나간다.

실수 또한 그냥 지나치지 않는다.

실수를 통해서 무엇을 배웠는지에 대한 복기 과정과 다양한 기법을 활용하여 실수의 발생 확률을 현저히 낮추고 있다.

이 책을 읽고나니 테스트 코드 작성의 중요성을 다시 깨우치게 되었다.

자동화를 좋아하는 나이기에 앞으로는 테스트 코드 작성에 소홀함이 없어야 겠다.