구글 엔지니어는 이렇게 일한다(타이터스 윈터스, 톰 맨쉬렉, 하이럼 라이트) - 10

공감되거나 인상 깊었던 문장들은 다음과 같다.

• 트레이드 오프는 ‘사람의 행동’에도 적용된다. (P.167)
• 정의상 중요하고 모호한 문제에는 마법 같은 ‘은총알’이 없다. 세상이 끝날 때까지 어떤 상황에서든 옳은 답이란 없다. ‘특정 상황에서의 최선의 답’이 있을 뿐이며, 그마저도 거의 언제나 몇 가지 면에서 절충을 해야 한다. (P.168)
• ‘늘 떠나라’는 구글의 전 엔지니어링 디레터인 바트 메더라다(Bharat Mediratta)의 유명한 말을 인용한 표현이다. 바트의 진정한 뜻은 리더는 모호한 문제를 풀어줄 뿐 아니라 맡은 조직이 리더 없이도 ‘스스로’ 문제를 풀 수 있게 유도해야 한다는 것이다. (P.171)
• 관찰과 경청 95%, 절묘하고 시의적절한 개입 5%. 이것이 좋은 관리다. 부하 리더들의 말을 경청하고 보고서는 건너뛰어라. 고객과 대화해라. 참고로 ‘고객’이라고 해서 꼭 최종 사용자를 의미하는 것은 아니다. 특히 엔지니어링 인프라를 개발하는 팀이라면 바로 옆의 동료들이 고객이다. (P.175)
• 저에겐 두 가지 종류의 문제가 있습니다. 급한 문제와 중요한 문제. 급한 문제들은 중요하지 않고, 중요한 문제들은 절대 급하지 않다. (P.179)
• 조직이 두 배 커지면 소통 비용은 제곱으로 늘어난다. 사업을 확장하려면 충원을 피할 수 없는데, 그에 따른 소통 비용이 너무 가파르게 늘어난다. 그래서 조직 덩치에 비례하게 사업을 키워나갈 수는 없다. (P.185)
• 실제로 의미 있는 엔지니어링 생산성 지표는 어떻게 측정할 수 있을까? 구글은 지표를 만들 때 GSM이라는 프레임워크를 쓴다. GSM은 목표(goal)/신호(signal)/지표(metric)의 약자다. (P.191)
  • 목표는 측정자가 원하는 최종 결과다. 측정을 통해 이해하고 싶은 내용을 고차원의 어휘로 표현하되 특정한 방식을 명시해서는 안된다. (P.191)
  • 신호는 원하는 최정 결과를 이루었는지 판단하는 방법이다. 측정하고 싶어 하는 것이지만 신호 자체는 측정하지 못할 수 있다. (P.191)
  • 지표는 신호를 대변한다. 우리가 실제로 측정하는 대상이다. 이상적인 측정법은 아닐 수 있으나 충분히 가깝다고 믿는 것이어야 한다. (P.192)
• 구글은 생산성을 다섯 개의 요소로 나눴다. 이 다섯 요소 사이에는 서로 트레이드오프가 일어난다. 이를 퀀츠(QUANTS)라고 한다. (P.193)
  • 코드 품질(Quality of the code): 작성된 코드의 품질, 회귀 버그를 예방하기에 충반한 테스트 케이스, 아키텍처는 위험과 변경을 받아드릴 수 있을 만큼 유연한가?
  • 엔지니어들의 몰입도(Attention from engineers): 엔지니어들은 얼마나 자주 몰입 상태에서 깨어나는가? 알림은 엔지니어의 주의력을 얼마나 흐트리는가? 도구는 엔지니어들의 작업 맥락을 전환하는 데 도움을 주는가?
  • 지적 복잡성(Intellectual complexity): 작업을 완료하는 데 인지 부하가 얼마나 걸리는가? 해결해야 할 문제에 내재된 복잡성은 어느 정도인가? 엔지니어들이 불필요한 복잡성을 처리해야 하는가?
  • 박자와 속도(Tempo and velocity): 엔지니어들은 작업을 얼마나 빨리 완수할 수 있는가? 릴리즈를 얼마나 빨리 밀어낼 수 있나? 주어진 시간에 얼마나 많은 작업을 완료하는가?
  • 만족도(Satisfaction): 엔지니어가 도구에 얼마나 만족하는가? 도구가 엔지니어에게 필요한 기능을 얼마나 잘 지원하는가? 엔지니어들이 주어진 업무와 완성한 제품에 얼마나 만족하는가? 엔지니어들이 번아웃되지는 않는가?

---