<구글 엔지니어는 이렇게 일한다> 리뷰(feat. 소프트웨어 개발자로서 딱 한 권만 읽는다면 이 책을 추천합니다)

&lt;구글 엔지니어는 이렇게 일한다&gt; 앞표지

한빛미디어에서 <구글 엔지니어는 이렇게 일한다>를 출간했습니다.

---

정말 주변분들에게 진심으로 강력추천하는 책! <구글엔지니어는 이렇게 일한다> 리뷰를 시작하겠습니다. 한빛미디어에서 지난 5월 10일에 신간 <구글 엔지니어는 이렇게 일한다> '구글러가 전하는 문화, 프로세스, 도구의 모든 것'을 출간했습니다. 이 책의 원제는 Software Engineering at Google인데요. 2020년에 미국에서 출간했던 책인데, 2년만에 번역을 해서 출간을 했으니 상당히 빠르게 국내에 소개된 책이라고 할 수 있습니다.


이 책은 아마존 소프트웨어분야 베스트셀러인데요, 22년 5월 3일 기준으로 Amazon 소프트웨어 디자인 도구 1위, 컴퓨터 하드웨어 설계 및 아키텍처 1위, 컴퓨터 시스템 분석 및 디자인 2위를 기록한 책입니다. 그만큼 책의 내용이 좋기 때문에 이번에 한빛미디어에서 출간했습니다.


사실 국내에 IT분야 전문출판사가 여러 곳이 있지만, 한빛미디어만 믿고 보는 출판사는 드물다고 생각합니다. 이 말은 제가 한빛미디어 <나도 리뷰어다> 활동을 하기 때문에 입에 발린 소리가 아닙니다. 제가 이 활동을 하기 전부터, 또 주변에 수많은 개발자 지인들의 이야기를 들어도 한빛미디어만큼 수준급의 책을 꾸준하게 출판하는 곳은 없다고 합니다.


개발책의 경우 전문지식을 다루기 때문에 아주 작은 오류만 있어도, 시스템을 멈추게 만드는 치명적 결함을 일으키는데요. 그만큼 IT 관련 책은 실력있는 저자를 선정해서, 독자가 원하는 내용을 선별하여 실력있는 검수자가 꼼꼼하게 검토하여 출간을 해야 합니다.


이런 면에서 한빛미디어는 탁월한 역량을 갖춘 출판사라고 할 수 있습니다. 이는 미국의 컴퓨터프로그래밍 전문 출판그룹 O'REILLY 오라일리미디어의 책을 국내에 번역하는 다른 출판사의 책과 한빛미디어의 책을 비교해보면 확연하게 드러나는 부분입니다.

<구글 엔지니어는 이렇게 일한다>는 무려 704쪽의 방대한 분량을 다루고 있는 책입니다. 그럼에도 불구하고 정말 쉽고 빠르게 읽힙니다. 제가 읽으면서도 이 책의 내용이 너무 좋아서, 주변 지인들과 개발자분들에게 꼭 이 책을 읽어야 한다고 추천을 드렸는데요.


그정도로 <구글 엔지니어는 이렇게 일한다>는 IT테크 기업에 일하는 분들이라면 반드시 알아야 할 내용을 모두다 담았다고 할 수 있습니다. 사실 책의 내용이 너무 좋아서, 리뷰 쓰기를 약간 망설였습니다. 왜냐하면 책이 좋은 만큼, 제가 이 좋은 책의 내용을 리뷰에서 온전히 드러내지 못할까봐 걱정이 들었기 때문입니다.


그동안 여러 책을 읽고 리뷰를 꾸준히 작성해왔습니다. 그런데 한번도 책의 내용에 누가 될까봐 리뷰 작성을 망설였던 적은 없었습니다. 그정도로 <구글 엔지니어는 이렇게 일한다>의 책은 너무 좋았고, 이 책의 좋은 점을 한 명에게라도 더 알리고픈 마음이 들었습니다.


이렇게 좋은 책을 출간한 한빛미디어와 빠르게 번역해준 개앞맵시(이복연)님께 감사의 말을 전하고 싶습니다. 본격적으로 리뷰에 앞서 이 책이 너무 좋아서, 개앞맵시님 페북 친구추가도 했습니다.

개앞맵시가 도대체 무슨 말인가 했는데, <개발자의 앞길에 맵핵 시전>의 줄임말이었구요. 이미 저는 예전부터 이 페이지에 좋아요를 눌렀더라고요. 그 정도로 개발자 사이에서는 실력으로 인정받는 개앞맵시님의 책이니 믿고 봐도 된다고 말씀드리고 싶습니다.


또한 <구글 엔지니어는 이렇게 일한다>가 5월 10일에 출간되자마자 3일만에 2쇄 출간을 위해 수정 작업에 들어간 개앞맵시님이 올린 포스팅을 보면, 교보 4위, 예스 5위, 알라딘 4위, 리디 1위를 기록했다고 합니다.


미국뿐만 아니라 한국에서도 <구글 엔지니어는 이렇게 일한다>는 엄청난 인기를 끌고 있습니다. <골빈해커의 3분 딥러닝 텐서플로 코드로 맛보는 CNN, AE, GAN, RNN, DQN (+ Inception)>를 쓴 저자 골빈해커(김진중)님은 자신의 페이스북에 다음과 같은 글을 남겼습니다.

소프트웨어 개발자로써 딱 세 권만 읽는다면 다음 책들을 추천합니다. 다른 좋은 책들도 많지만, 기본이 되는 거의 모든 내용이 이 세 권의 책에 다 있다고 볼 수 있을 것 같네요. 다른 책들은 이 세 권의 책을 온전히 이해한 후 읽거나, 혹은 이 책들의 내용을 이해하기 위해 읽으면 좋을 것 같습니다.

사실 "코드 컴플리트"와 "리팩터링" 이후 뭔가 하나 더 필요한데.. 뭐지? 뭐지? 했는데, “구글 엔지니어는 이렇게 일한다” 책을 읽고 딱 라인업이 완성됐다고 생각했네요. (툴의 사용과 협업에 관련된 내용) 책 제목이 좀 아쉽지만...

이 포스팅을 보면서 왜 골빈해커(김진중)님이 <구글 엔지니어는 이렇게 일한다>의 책 제목이 아쉽다고 말하지는 이해가 됐습니다. <구글 엔지니어는 이렇게 일한다>라는 제목으로는 이 책에 담겨있는 내용을 모두 아우를 수 없다고 저도 생각합니다.


그만큼 이 책은 방대하면서도 꼼꼼하면서도 구체적이면서도 핵심을 담고 있습니다. 특히 개발자를 존중하고 조직과 팀을 이끌어가는 문화까지도 상세한 사례와 함께 다루고 있기 때문에 개발자는 당연히 읽어야 하고, 개발자와 함께 일하는 IT테크기업의 전직군 모두가 읽어야 한다고 생각합니다.

반응형

&lt;구글 엔지니어는 이렇게 일한다&gt; 뒷표지

<구글 엔지니어는 이렇게 일한다>를 조금 더 자세히 살펴보면 다음과 같습니다.

---

<구글 엔지니어는 이렇게 일한다>의 목차

먼저 <구글 엔지니어는 이렇게 일한다>의 목차부터 살펴보겠습니다. 이 책은 구글의 소프트웨어 엔지니어링 전반에 관한 내용을 다루고 있습니다. 그래서 소프트웨어 엔지니어링에 관한 구글의 주된 시각에 따라 네 파트로 구분했습니다.

• 전제
• 문화
• 프로세스
• 도구

개발자라면 이 세 파트를 하나도 남김없이 꼼꼼하게 읽기를 추천합니다. 개발자가 아니어도 IT테크기업에 근무하는 분들이라면 전제와 문화 파트만큼은 꼭 읽어보기를 추천합니다.

특히 테크 기반의 스타트업이나 스케일업의 대표라면 읽어보아야 한다고 생각합니다. 이에 대한 자세한 이야기는 다음 챕터에서 다루기로 하겠습니다.

파트1. 전제

먼저 파트1. 전제부터 살펴보겠습니다.

• 챕터1 : 소프트웨어 엔지니어링이란?

이 주제가 파트1 전제의 전부입니다. 이 파트1에서 가장 핵심은 프로그래밍 작업과 소프트웨어 엔지니어링 작업의 차이점을 명확하게 구분하여 설명합니다. 실무 경험이 없는 주니어 개발자라면 반드시 읽고 이해해야 할 부분이라고 생각합니다.


소프트웨어 공학을 학습하지 않은 비전공자 역시 기술 기반의 기업에서 일하기 위해서 알아야 하는 필수 지식이라고 생각합니다. (덧붙여서 이 부분이야말로 '비전공자를 위한 필수 IT 지식'이라고 생각합니다.

프로그래밍	소프트웨어 엔지니어링
개발	개발 + 수정 + 유지보수

소프트웨어 엔지니어링은 흐르는 시간 위에서 순간순간의 프로그래밍을 모두 합산한 것! -41p

시간이 프로그램에 미치는 영향을 알아보려면 저자는 다음의 질문을 던져보기를 추천합니다.

반응형

이를 통해서 구글의 소프트웨어 엔지니어링은 지속가능성을 중요시하고 있음을 우리는 알 수 있습니다. 동시에 전세계 최대 규모의 소프트웨어를 다루고 있는 구글이기에 규모에 대한 이야기를 자세하게 나눕니다.

이는 <구글 엔지니어는 이렇게 일한다>는 수 만명의 개발자와 함께 전 세계에 뻗어 있는 컴퓨팅 자원 위에서 수십 년을 살아남을 소프트웨어를 개발하고 유지보수하며 깨달은 핵심 정수를 다루고 있다는 뜻입니다.


어떠한 스타트업도 고작 수 분, 수 시간만 동작할 기술을 개발하고 싶어하지는 않을 것입니다. 최소 수 개월에서 길게는 수 십년, 구글처럼 오랫동안 지속하는 기술을 개발하여 성장하고 싶어할 것입니다.

세르게이 브린과 래리 페이지가 처음 구글을 실리콘밸리에서 시작했을 때, 어느 누구도 지금과 같이 구글이 성장할 것이라고 예상하지는 못했을 것입니다. 정작 세르게이 브린과 래리 페이지, 두 창업자도 마찬가지였을 것입니다. 하지만 그 둘은 이것만큼은 확신했을 것입니다. 자신들의 웹검색 기술이 단명하지 않을 것이라는 점이요.


그렇다면 처음에는 단 두 명이서 시작을 해서, 지금처럼 거대한 규모의 기업으로 성장하는데 가장 큰 요인은 무엇이었을까요? 고도의 기술력이었을까요? 코드 리뷰를 잘해서였을까요?


디자인패턴과 스타일 가이드를 명료하게 제시했기 때문일까요?빌드 시스템 철학때문일까요? 물론 이 모든 것도 중요한 요소로 작용을 했을 것입니다. 그러나 구글이 지금처럼 성장할 수 있었던 가장 큰 이유는 바로 구글의 문화때문입니다.

구글 역시 문화가 중요하다는 것을 알고 있습니다. 그렇기에 <구글 엔지니어는 이렇게 일한다>는 파트1. 전제 이후 바로 파트2에서 문화를 다룹니다. 다른 요소보다 중요하니까 먼저 나오는 것입니다. 항상 순서는 중요도에 따라 배치하는 것이니까요. 그러면 파트2부터 파트4까지의 주요 목차를 살펴보겠습니다.

파트2. 문화

• 챕터2 : 팀워크 이끌어내기
• 챕터3 : 지식 공유
• 챕터4 : 공정 사회를 위한 엔지니어링
• 챕터5 : 팀 이끌기
• 챕터6 : 성장하는 조직 이끌기
• 챕터7 : 엔지니어링 생산성 측정하기

파트3. 프로세스

• 챕터8 : 스타일 가이드와 규칙
• 챕터9 : 코드 리뷰
• 챕터10 : 문서자료
• 챕터11 : 테스트 개요
• 챕터12 : 단위 테스트
• 챕터13 : 테스트 대책
• 챕터14 : 더 큰 테스트
• 챕터15 : 폐기

파트4. 도구

• 챕터16 : 버전 관리와 브랜치 관리
• 챕터17 : Code Search
• 챕터18 : 빌드 시스템과 빌드 철학
• 챕터19 : Critique 구글의 코드 리뷰 도구
• 챕터20 : 정적 분석
• 챕터21 : 의존성 관리
• 챕터22 : 대규모 변경
• 챕터23 : 지속적 통합
• 챕터24 : 지속적 배포
• 챕터25 : 서비스형 컴퓨트

'질문하기'의 방식으로 책을 전개한다.

704쪽이라는 방대한 분량이기에 각 내용을 모두 리뷰하기는 상당히 많습니다. 각 챕터를 한 문장씩만 설명해도 총 챕터가 25챕터나 되기 때문이죠. 그러나 방대한 분량에도 불구하고, <구글 엔지니어는 이렇게 일한다>의 가장 큰 장점을 세 가지만 뽑아보겠습니다.


첫번째로 저자는 '질문하기' 방식으로 글을 전개합니다. 실제로 구글의 매니저(관리자)와 테크 리드는 팀원의 문제에 답을 직접 해결하기보다는 팀원에게 질문을 함으로써 팀원 스스로 문제를 해결할 수 있도록 돕습니다. 그런데 이러한 일은 실로 어렵습니다.

우리는 잘 알고 있습니다. 내가 10분이면 해결할 일을, 팀원이 2시간 내내 끙끙거리고 있을때 그것을 지켜보는 것이 얼마나 고역이라는 것을 말이죠.

그러나 구글은 겸손, 존중, 신뢰를 원칙으로 이 어려운 것을 해냅니다. 그리고 그 문화는 자연스럽게 이 책에도 드러나죠. 그래서 <구글 엔지니어는 이렇게 일한다>는 끊임없이 독자에게 질문을 던집니다. 독자가 주도적으로 고민하면서 책을 읽을 수 있도록 말이죠. 그러다보니 독자는 자연스럽게 이 책에 몰입합니다.

구글의 실제 사례를 자세하게 다룬다.

또한 지난 20여년 간 구글의 실제 사례를 다양하게 수록합니다. 이 점은 제가 이 책을 대학 교재로 추천하는 이유이기도 합니다. 실제 대학에서 강의를 하면 케이스스터디가 중요합니다.

복잡한 구글 검색 사례

비록 제가 졸업한 지 15년이 넘었지만, 지금도 대학 강의는 교수가 30분 이내 짧게 강의하고, 이와 관련된 케이스 스터디를 팀프로젝트로 수행해서 발표하는 식일 것입니다. 그만큼 사례연구가 중요하죠. 제가 경영학 수업, 조직행동론이나 운영관리와 같은 수업을 들을 때 대부분 도요타나 GE와 같은 중공업 제조기업들을 연구했습니다.

웹 서버 '지연시간' 해결하기 사례

이제 시대는 바뀌었죠. 4차 산업혁명, 디지털트랜스포메이션에 발 맞추어 IT 기술 기반의 테크기업을 연구해야 할 필요성이 강하게 대두됩니다. 그때 구글만큼 사례연구하기 좋은 기업은 없다고 생각합니다.

그런데 서점이나 도서관에서 구글 관련 서적을 검색하면, 마땅치 않은 책들만 많이 나옵니다. 정작 구글에서 근무하는 수많은 직군들이 어떻게 일하는지 구체적으로 다루고 있지는 않습니다. 다루더라도 추상적이거나 개발자의 시선이 아닌 경영자의 시선으로 다룬 책들이 많았습니다.

리뷰 도구 Gerrit의 사례

테크 기업에서 가장 중요한 자산은 바로 인적 자본, 즉 개발자고, 개발자와 관련된 내용이 가장 중요할 것입니다. 이 부분에 대해서 <구글 엔지니어는 이렇게 일한다>는 아주 자세하게 다루고 있습니다. 이는 기업의 조직행동론에서 매우 중요하게 다루는 주제이기도 합니다. 결국 기업 성과와 깊은 연관을 맺기 때문이죠.

소프트웨어 엔지니어링처럼 매우 창의적이고 수익성 높은 분야에서는 인적 비용이 중요합니다. 엔지니어가 행복하게 느끼고 일에 집중하고 참여할 수 있게 해주면 효율이 높아집니다. 집중력이 생산성에 미치는 영향은 아주 커서 10~20%의 차이는 우습게 만듭니다. -<구글 엔지니어는 이렇게 일한다>, 59쪽

위 내용을 보면 제가 학부때 배웠던 호손효과를 떠올리게 합니다. 호손이 공장 노동자를 대상으로 했던 유명한 실험인데요. 100년전에는 공장 노동자를 대상으로 했던 실험이 이제는 IT기업의 개발자에게도 그대로 적용됩니다.


호손효과 대신 구글효과라 부르면 어떨까요? 경영학원론이나 조직행동론 시간에 <구글 엔지니어는 이렇게 일한다>를 읽으면서 문화의 중요성을 실제 사례와 함께 익히면 좋습니다. 구글을 사례연구하고자 한다면 이 책을 추천드립니다.

개발자 커뮤니티에서 흥했던 드립을 적재적소에 인용한다.

내용을 이해하면 빵터지는 드립

이 책의 세 번째 특징으로 개발자 커뮤니티에서 흥했던 드립을 적재적소에 인용하는 점을 들 수 있습니다. 사실 드립은 대개 이미지로 구성되어 있는데요, 드립 안에 대화는 영어입니다.

비전공자도 한참 웃는 드립

이것까지도 꼼꼼하게 번역을 해서 독자가 충분히 이해할 수 있도록 구성을 하였습니다. 아래 사례를 직접 보면 이해가 되실 것입니다.

컴파일은 최고의 핑계

<구글 엔지니어는 이렇게 일한다>는 이런 분들에게 강력하게 추천합니다.

---

• CEO, 관리자, 테크 리드 등 기업의 리더
• 소프트웨어 개발자(엔지니어)
• 개발자와 함께 협업하는 모든 분

앞에서도 말씀드렸듯이 성장을 추구하는 소프트웨어 개발자에게 반드시 <구글 엔지니어는 이렇게 일한다>를 꼭 읽어보길 추천합니다.

파트3 프로세스와 파트4 도구에서 품질 좋은 소프트웨어 제품을 신속하게 개발하고 그 소프트웨어를 관리하는 방법, 즉 소프트웨어 엔지니어링에 관한 상세한 설명을 구체적인 사례와 함께 제시하고 있기 때문입니다.


이는 실제 기술기업에서 근무하는 현직 개발자에게도 상당히 중요한 인사이트를 제공하면서, 주니어 개발자에게도 매우 유의미한 정보를 제공합니다.

그런데 개발자가 아닌 분들에게 저는 이 책을 한 번씩 꼭 읽어보라고 추천합니다. 만약 본인이 IT기업, 테크기업, 기술기업, IT기술을 기반으로 하는 스타트업이나 스케일업에 근무한다면 한 번씩 읽어보길 권합니다. 아마도 저처럼 다른 분들에게 이 책을 '전도'하게 될 것입니다.


개발자가 아니어도 괜찮습니다. 개발자와 함께 협업하는 분들에게도 강력히 추천합니다. 개발자를 관리하는 관리자(매니저)나 리드분들에게도 추천드립니다. 이 책이 어렵다면 다 읽지 않아도 됩니다. <파트2. 문화> 부분만이라도 가볍게 읽어보길 추천합니다.


구글과 같은 IT기술 기반의 기업이 회사 구성원을 어떻게 존중하고, 어떠한 문화로 회사를 운영하는지 궁금하다면 이 책을 읽어야 합니다. 구글의 인터널브랜딩이 궁금하다면 역시 이 책을 읽어야 합니다.


특히 이 책은 관리자나 관리자 트랙으로 성장하고픈 분들이라면 욕심낼 법한 책이라고 생각합니다. 그리고 이 책이 국내에 널리 읽힌다면 국내 기업의 문화가 긍정적으로 바뀌면서, 구성원을 존중하는 문화가 국내에서도 확산될 것이라고 생각합니다. 또한 기업이 사적 이윤을 추구하면서도 공공의 이익을 추구하는 방법을 고민하게 될 것이라고 생각합니다.


그렇다면 인상 깊었던 내용 중에서 추리고 추려서 본문에서 몇 부분을 인용해보겠습니다. 제가 밑줄 친 부분을 모두 소개하면 이 글은 밤새 작성해도 끝나지 않을 것이기 때문입니다.

리더라면?

늘 확장하라 - 리더에게 주어진 가장 값진 자원은 ‘자신의 제한된 시간, 집중력, 에너지’입니다. 스스로의 내면을 보호할 방법을 익히지 못한 채 팀의 책임과 영향력만 공격적으로 키워버리면 확장은 오히려 파멸로 가는 지름길로 돌변합니다. -본문 176p

코드 작성을 벌목에 비유한다면 리더의 역할은 나무들 사이로 숲 전체를 보면서 목표한 중요 나무까지로 가는 길을 찾아 엔지니어들을 안내해주는 것이다. 먼저 눈 가리개를 찾아내고, 트레이드오프들을 파악한 다음, 해법을 결정하고 반복해야 합니다. -본문 167p

리더로서 여러분은 ‘나만이 할 수 있는 일’을 처리해야 한다. 이를 위해서는 반응형 일처리보다 능동형 일처리를 해야 한다. 능동형으로 일을 하려면 결국에는 버려야 한다. 의도적으로. 무시할 것 20% , 조금 급하거나 중요하지 않은 것 60%, 가장 중요한 것 20%로 나눈다.

상위 20%, 즉 여러분만이 할 수 있는 중요한 일들을 신중하게 골라낸 다음 오직 그 일들에만 집중하는 것입니다. 나머지 80%를 버릴 권환을 자신에게 부여하세요. - 본문 181p

특정한 엔지니어링 문제 해결이 아니라 거시적인 전략을 짜는 것이죠. 여러분이 내리는 결정 대부분은 여러 전략 사이의 트레이드오프들을 정확히 찾아내는 일입니다. -본문 166p

구글은 엔지니어링을 아는 사람만이 소프트웨어 엔지니어링 관리자(매니저)가 될 수 있다. 엔지니어링 관리자(매니저)는 팀 구성원의 성과, 생산성, 행복을 책임진다. 그와 동시에 팀에서 만드는 제품의 사업적 요구까지 충족을 시켜야 한다는 것을 처음 알았다. -본문 136p

개발자라면?

버스지수란? 몇 명의 팀원이 버스에 치어서 일을 할 수 없게 될 때 프로젝트가 망하게 되는지를 나타내는 지수 -본문 76p

버스지수가 높다면 누군가가 단일장애점이 되고 있을 확률이 높습니다. 이를 위해서 문제 공간을 분할해야 합니다. -본문 171p

미래의 훌륭한 엔지니어로서 우리는 편견과 차별 때문에 가장 고통받는 사용자들에게 최우선으로 관심을 기울여야 합니다. -본문 132p

구글은 품질, 지연시간, 용량 변화가 적절한 균형을 이루는지를 매월 반복해 돌아보면서 늘 결정하고 있습니다. - 본문 171p

학위가 있다고 해서 자동으로 좋은 엔지니어가 되는 것은 아닙니다. -본문 124p

구글은 개인의 시간을 가장 소중히 여긴다

자기계발서와 같은 수많은 책에서 중요한 일과 급한 일을 구별해야 한다는 내용을 언급합니다. 스티븐 코비의 <성공하는 사람들의 7가지 습관>에서 보았던 내용인데, 이 책에서도 인용을 하고 있습니다.

그전에 자기계발서에서 볼 때는 뜬구름 잡는 느낌이었는데, 구글 엔지니어의 생생한 경험을 통해 접하니 확 와닿았습니다. 동시에 구글은 개인의 시간 활용을 위해 사소한 부분까지도 신경쓴다는 것을 알았습니다.

화이트보드와 마커 -본문 60p
테크스톱 - 본문149p

개발자가 화이트보드와 마커를 활용해서 브레인스토밍을 합니다. 그러다가 갑자기 마커가 말라버리죠. 주변에 마커를 찾습니다. 교체합니다.

그런데 그 마커 역시 나오지 않습니다. 몇 번을 마커를 찾다보면 어느새 흐름은 끊기고, 아이디어는 사라지죠. 구글은 이것을 막기 위해 마커를 정말 충분히 배치합니다. 이런 사소한 부분도 놓치지 않는 구글입니다.

테크스톱이라는 제도가 있습니다. 이것도 상당히 흥미로운데요. 간단히 말하면 컴퓨터 소모품을 필요한 만큼 마음껏 가지고 가는 사내 소모품 편의점입니다. 물론 무료입니다. 마우스부터 케이블까지 다양하게 비치되어 있습니다.

직원들이 몰래 과도한 양을 훔쳐가는 것보다 직원이 소모품을 사기 위해서 행정절차를 밟고 시간을 소비하는 것의 비용이 더 크다고 구글은 생각합니다. 그런 직원의 시간을 아끼기 위해 운영하는 것이죠. 그만큼 구글은 개인의 시간을 가장 소중히 여깁니다. 일을 하든, 여가를 가든 그 모든 것이 결국은 생산성으로 이어진다고 보는 것이죠.

트레이드오프란?

트레이드오프가 명확할 때도 있지만 때로는 시간이 한참 지나서야 피해를 주는 예상치 못한 결과를 가져오기도 합니다. -본문 167p

어떤 트레이드오프가 존재하고 어떻게 작용하는지를 이해하고 나면 여러분의 힘이 커집니다. 이 정보를 활용하여 가령 이번 달에 수행할 최선의 결정을 내릴 수 있게 되죠.

그리고 다음 달이 되면 트레이드오프들을 다시 평가하고 균형점도 새로 잡아야 할 것입니다. 반복적인 프로세스라는 말이죠. 이것이 바로 ‘늘 결정하라’라고 부르는 이유입니다. -본문 169p

이 책에서는 트레이드오프라는 개념이 상당히 빈번하게 등장합니다. 구글은 선택하는 기업이기 때문인데요. 저는 처음에는 트레이드오프를 기회비용의 개념으로 생각을 했는데, 조금은 다른 것 같습니다.

위키사전에서는 <트레이드오프(trade-off, tradeoff) 또는 상충 관계>는 다른 측면에서 이득을 얻으면서 집합 또는 디자인의 품질, 양, 속성을 없애거나 잃어버리는 일이 수반되는 상황적 결정이라고 말합니다. 즉, 하나가 증가하면 다른 하나는 무조건 감소한다는 것을 뜻한다.라고 하는데 다른 기업에서는 트레이드오프를 어떻게 다루는 더 찾아보고 싶습니다.

테크리드와 매니저의 차이는?

테크 리드는 제품의 기술적인 면, 기술과 관련한 결정과 선택, 아키텍처, 우선순위, 성능과 일반적인 프로젝트 관리를 책임집니다. -본문 136p

구글은 엔지니어링을 아는 사람만이 소프트웨어 엔지니어링 관리자(매니저)가 될 수 있다. 엔지니어링 관리자(매니저)는 팀 구성원의 성과, 생산성, 행복을 책임진다. 그와 동시에 팀에서 만드는 제품의 사업적 요구까지 충족을 시켜야 한다는 것을 처음 알았다. -136p

구글에서 일하려면 어떤 능력이 필요한가?

천재라고 해서 괴짜처럼 행동하는 게 용서받는 시대는 지났습니다. 천재든 아니든 사회성이 부족한 사람은 팀원으로 적합하지 않기 때문이죠.

구글에서의 업무 거의 대부분이 천재 수준의 지능을 요구하지 않는 빙면, 모든 업무가 최소한의 사회성을 요구합니다. (다른 회사들도 대동소이합니다.)

그래서 우리의 경력을 미래로 이어주는 핵심은 다른 사람과 얼마나 잘 협력하느냐입니다. (구글 같은 기업에서는 특히 더 합니다.) -본문 74p

실패는 무의미한가?

"가끔씩 실패하지 않는다면 충분히 혁신적이지 않거나 위험을 충분히 감수하지 않은 것이다" 그러므로 실패는 "배우고 다음 단계로 넘어갈 수 있는 절호의 기회"다. -본문 85p

이 사실을 분명하게 공표합시다! 실패는 '많은 것을 아주 빠르게 배우는 기회'이다. -본문 143p

전문가가 일대일로 해주는 조언의 가치와 문서화된 지식의 가치 중 어느 것이 더 큰가?

전문가가 일대일로 해주는 조언의 가치는 매우 큽니다. 매우 효과적이지만, 확장성이 부족하여 팀이 커지면 유용하지 못합니다.

반면에 문서는 일반적 상황을 다룹니다. 반면에 개별 학습자가 처한 특수한 상황에서는 적합하지 않습니다.

기록된 지식은 확장성이 좋지만 사람이 해주는 맞춤형 도움도 장점이 큽니다.

현장지식과 문서화된 지식은 서로를 보완해줍니다.

모든 형태의 배움에 최고인 유일무이한 지식 공유법은 존재하지 않습니다.

어떻게 조합하는 게 최선일지는 조직에 따라 다릅니다. -94p

질문하기는 문제해결의 수단인가?

초심자가 저지르는 가장 큰 실수는 무언가 막혔을 때 질문하지 않는 것입니다. 혼자서 극복해내고 싶다거나 '너무 기초적인' 질문이란 소리를 듣는 게 두려워서일 수 있습니다.

혹은 '도움을 청하기 전에 최대한 노력해봐야 해'라고 생각할지 모릅니다. 이 함정에 빠지지 마세요! 여러분의 동료가 가장 훌륭한 정보 소스일 경우가 많습니다.

이 자원을 질문으로 충분히 활용하세요. -본문 98p

팀원이 여러분에게 조언을 구하러 옵니다. 하지만 리더는 곧장 문제 해결 모드로 전환하면 안됩니다. '직접 해결하기'는 가장 마지막에 택해야 하는 전략입니다.

조언을 구하는 사람은 보통 '여러분이 나서서' 해결해주길 원하는 게 아닙니다. 스스로 문제를 해결하는 걸 도와주길 바라는 거죠.

스스로 해결하도록 이끄는 가장 쉬운 방법은 '질문하기'입니다. 겸손, 존중, 신뢰를 담아서 조언을 청한 사람이 자기 힘으로 문제를 해결하도록 도와주려 노력해야 합니다.

문제를 다시 정의하고 탐구해보도록 보조해주세요. -본문 152p

여러분 스스로가 모든 해법을 알고 있을 필요는 없습니다. 하지만 누가 해결해줄 수 있는지 알고 있다면 큰 도움이 되죠. 많은 경우 정확한 답을 알고 있기보다 올바른 사람을 알고 있을 때의 가치가 더 큽니다. -본문 153p

멘토가 되는 데 필요한 세가지 능력은?

• 팀의 프로세스와 체계에 대한 경험
• 다른 이에게 무언가를 설명해주는 능력
• 멘티에게 도움이 얼마나 필요한지를 측정하는 능력

테크 리드로서 가장 실천하기 어려운 일을 뽑으라면 '내가 하면 20분이면 끝날 일을 세 시간씩 매달려 있는 주니어 팀원 지켜보기'를 빼놓을 수 없습니다. 스스로 배울 기회를 주는 일은 훌륭한 리더십에서 빠질 수 없는 요소이지만 특히 처음에는 매우 고통스럽습니다. -본문 154p

문제를 일찍 발견하면 비용이 적게 드는가?

개발자 워크플로의 타임라인과 결함수정비용의 관계

개발 과정에서 문제를 일찍 발견할수록 비용이 적게 든다는 사실은 널리 받아들여지는 진실입니다. -본문 57p

소프트웨어 엔지니어링 분야에서 가장 큰 자산은 무엇인가?

엔지니어들이 행복을 느끼게 만들고 일에 집중하고 참여할 수 있게 해주면 효율이 높아지죠. 집중력이 생산성에 미치는 영향은 아주 커서 10~20%의 차이는 우습게 만들어냅니다. -본문 59p

<구글 엔지니어는 이렇게 일한다>는 대학 교재로도 추천합니다.

---

구글은 데이터를 토대로 결정하는 데이터 주도 회사이다. - 본문 185p

먼저 이 책을 갑자기 대학 교재로 추천하나? 생각하실 것입니다. 그건 바로 이 책은 어떻게 가르치고 성장할 것인가?에 대한 근본적인 고민을 담고 있기 때문입니다.

대표적으로 피드백에 관한 부분입니다.

• 나와 결과물을 분리하라.
• 답을 주려 하지 말고, 연결시켜라
• 적절한 피드백을 제공하라.
• 피터의 법칙 -직원은 자신의 무능력이 드러나는 직급까지 승진하는 경향이 있다.

'나는 내 코드가 아니다.'라고 반복해서 되뇌세요. 여러분 자신과 여러분이 만든 것을 구분 지으세요. -본문 84p

위 내용만 하더라도 최근 교육학에서 가장 핫한 내용을 모두 포함하고 있습니다. 구글은 이러한 내용을 말그대로 실전에서 겪고, 문서화 시켰습니다. 경영학이나 컴퓨터공학뿐만 아니라 이제는 교육학도 구글을 연구해야 하는 시대가 온 것입니다.

구글은 이제 검색 서비스를 제공하는 하나의 기업만이 아닙니다. 20여년간 대규모 조직을 이루어 사업을 확장해온 거대한 기업이자 사회이자 공동체입니다.


그 안에서 커뮤니케이션을 고민하고, 성장과 교육을 고민했으며, 문제해결 방법을 모색했습니다. 컴퓨터 엔지니어링 기술의 발전을 위해 지속적으로 투자했고, 동시에 겸손, 존중, 신뢰라는 가치를 추구했습니다.


구글은 단순히 이윤추구 기업을 넘어서 연구하고, 교육하고, 사람과 사람을 연결시키며, 사회 공헌을 한 것입니다. 이러한 모든 것은 구글은 이렇게 일한다에서 담아낸 것입니다.

구글포토는 흑인을 '고릴라'로 인식했다.

구글 포토의 이미지 인식 알고리즘에서 흑인 친구의 사진을 고릴라로 인식했던 사례 -본문 123p

오늘날의 개발은 많이 쓰이는 기능을 먼저 만들고 특수한 상황에 쓰이는 기능이나 개선은 나중으로 미루는 방식으로 주로 진행됩니다. 하지만 여기에는 결함이 있습니다. 기술을 접하기에 유리한 사람들에게 우선권을 줌으로써 불평등을 가중하는 방식인 것입니다. -본문 129p

저는 돈의 논리로 어쩔수 없이 많이 쓰이는 기능을 먼저 만들겠지만, 이것이 불평등을 더 심화시킨다는 사실을 <구글 엔지니어는 이렇게 일한다>를 읽으면서 처음 알았습니다.

저는 지난 30여년을 왼손잡이로 살면서 왜 이렇게 불편한 것이 많은가? 고민을 많이 했는데, 이것도 불평등을 가중하는 방식때문에 그런 것은 아닐까? 생각했습니다.

이런 철학까지도 깊이있게 사유하게 만드는 책이다보니, 이 책의 제목은 무언가 아쉬움을 줄 수 밖에 없습니다. 이 책에 저변에 깔려있는 고귀한 가치를 개발자나 CEO만 보기 너무 안타깝습니다.

정말 어떠한 분야를 공부하거나 일을 하더라도 상관없이 모든 사람들이 다 한번쯤은 읽어봤으면 하는 책입니다. All for One 제가 최근 1년 동안 읽은 책 중에서 개발자뿐만이 아니라 모든 사람을 위해 단 한 권만을 추천하라고 하라면 저는 이 책을 추천하고 싶습니다.


이 책의 깊은 울림을 이 짧은 포스팅에 모두 담지 못해서 너무 아쉽습니다. 동시에 제 리뷰가 오히려 이 책의 빛나는 장점을 담아내지 못한 것은 아닌가 하는 마음도 듭니다. 하지만 개발자가 아닌, 찐문과생인 제가 읽어도 이렇게 좋은 책이니, 소프트웨어 개발자라면 완전 강추하는 것입니다.

끝으로 이 글은 한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성한 서평이지만, 철저히 주관적으로 상세하게 독자에게 도움이 되도록 적은 글임을 밝힙니다. 특히 책 외에는 일절 원고료나 광고비를 받지 않았습니다.