구글 엔지니어는 이렇게 일한다 - 1장, 2장

(책을 읽으며 느낀 개인적인 사견이 회색 글씨로 작성되어 있습니다.)

1장 소프트 웨어 엔지니어링

1. 소프트웨어 엔지니어링이란?

소프트웨어 엔지니어링 프로젝트에서 엔지니어는 시간의 흐름과 언젠가 변경 될 가능성에 더 신경 써야 합니다.

• 프로그래밍과 소프트웨어 엔지니어링의 차이
  • 시간
  • (규모) 확장
  • 실전에서의 트레이드오프
• 규모 관점에서 보는 소프트웨어 엔지니어링
  • 조직이 성장하고 프로젝트가 확장될수록 소프트웨어 생산 효율도 높아지는가?
  • 개발 워크플로의 효율도 우리의 성장에 발맞춰 개선되는가?
  • 우리가 따르는 버전 관리 정책과 테스트 전략이 조직규모가 확장되면 비례하여 비용을 증가시키는가?

소프트웨어 엔지니어 혹은 리더는 지속 가능성을 잃지 않으면서 조직, 제품, 개발 워크플로의 규모를 확장하는 비용을 관리해야 합니다.

• 소프트웨어 엔지니어링에서 만병통치약을 찾기는 어렵다.
  • 구글의 경험이 딱 들어맞지 않을 것
  → 규모와 현재 상황에 따라 알맞는 방법은 다 다를 것, 때로는 오버엔지니어링이 될 수 있음

1.1 시간과 변경

현업에서도 단명하는 코드를 다루는 개발자를 찾을 수 있습니다. 모바일 앱의 수명은 다소 짧은 편이며 좋든 싫든 코드 전체를 처음부터 새로 작성하는 비율도 상대적으로 높습니다.

• 소프트웨어 프로젝트의 기대수명 스펙트럼의 최저점과 최고점 사이 어딘가에서 전환이 일어날 때
  → 프로젝트는 외부 환경의 변화에 대비해야 함
  → 일회성 프로그램과 수십 년을 지속하는 프로젝트 사이에서 발생
• 이 전환(업그레이드)을 성공적으로 마치고, 현 상태를 안정되게 유지할 수 있어야 프로젝트가 오래 지속 가능할 확률이 높음
• 지속 가능하기 위해서는 요구되는 변경들의 영향을 계획하고 관리 해야 함
• ‘동작한다’와 ‘유지보수 가능하다’의 차이를 분명하게 인지할 것

1.1.1 하이럼의 법칙

API 사용자가 충분히 많다면 API 명세에 적힌 내용은 중요하지 않습니다. 시스템에서 눈에 보이는 모든 행위(동작)를 누군가는 이용하게 될 것이기 때문입니다.

• 최선의 의도, 최고의 엔지니어, 꼼꼼한 코드 리뷰가 뒷받침 되더라도 공표한 계약(명세)이나 모범 사례를 완벽하게 구현해냈다고 단정할 수 없다는 현실을 표현한 말
• API 사용자는 간혹 명세에 없는 기능을 찾아 활용 → 그 기능이 유용해서 널리 쓰이게 되면 API 변경 어려워짐

1.2 규모 확장과 효율성

조직에서 코드를 작성하고 관리하는 데 활용하는 모든 것이 총비용과 자원 소비 측면에서 확장 가능해야 합니다. 특히 반복적으로 수행하는 일이라면 모두 인적비용 측면에서 확장 가능해야 합니다.

1.2.2 확장 가능한 정책들

우리가 좋아하는 구글 내부 정책 중 인프라팀이 인프라 변경을 안전하게 진행하게끔 보호해주는 정책이 하나 있습니다. 바로 ‘인프라를 변경하여 서비스가 중단되는 등의 문제가 발생하더라도, 같은 문제가 지속적 통합 시스템(CI)의 자동 테스트에서 발견되지 않는다면 인프라 팀의 책임이 아니다’ 라는 정책입니다.

• 비욘세 규칙
  • 코드를 짰으면 자기 코드에 대한 테스트도 자기가 제대로 만들었어야 한다.
  • 공통 CI 시스템에 추가해두지 않은 테스트는 인프라팀이 책임지지 않는다는 뜻

1.2.4 원점 회귀(왼쪽으로 옮기기)

• 개념잡기, 설계, 구현, 리뷰, 테스트, 커밋, 카나리, 배포
• 위 타임라인에서 문제 발견 시점을 왼쪽으로 이동시킬수록 수정 비용이 줄어듬
• 이 왼쪽으로 옮기는 행위 → 원점 회귀

1.3 트레이드 오프와 비용

• ‘비용’에 포함되는 요소들
  • 금융 - 돈
  • 리소스 - CPU 시간
  • 인적 자원 - 엔지니어링 노력
  • 거래 비용 - 조치를 취하는데 드는 비용
  • 기회 비용 - 조치를 취하지 않게 된 비용
  • 사회적 비용 - 선택이 사회 전체에 미치는 영향

1.3.1 사례: 화이트보드 마커

의사결정이 ‘내가 시켰으니까’가 되어서는 안됩니다.

• 엔지니어링 조직의 선택을 결정짓는 요인
  • 반드시 해야하는 일(법적 요구사항, 고객 요구사항)
  • 근거에 기반하여 당시 내릴 수 있는 최선의 선택(적절한 결정권자가 확정)

---

2장 팀워크 이끌기

일찍 실패하고, 빨리 실패하고, 자주 실패하라

• 버스 지수
  • 몇 명의 팀원이 버스에 치어서 일을 할 수 없게 될 때 프로젝트가 망하게 되는지를 나타내는 지수
• 혼자 잘못된 길로 접어들었다가 뒤늦게 깨닫고 빠져나오는 데 수많은 시간을 낭비한 경험이 있을 것 입니다.

홀로 일하기는 함께 일하기보다 본질적으로 더 위험합니다. 다른 사람이 아이디어를 훔친다거나 여러분이 똑똑하지 않다고 생각하는게 두렵더라도, 잘못된 일에 여러분의 천금같은 시간을 낭비 할 가능성을 더 걱정해야합니다.

2.4 모든건 팀에 달렸다

2.4.1 사회적 상호작용의 세 기둥

• 사회적 스킬의 세 기둥
  • 겸손
    • 당신과 당신의 코드는 우주의 중심이 아닙니다. 당신은 모든 것 을 알지도 완벽하지도 않습니다. 겸손한 사람은 배움에 열려있습니다.
  • 존중
    • 함께 일하는 동료를 진심으로 생각합니다. 친절하게 대하고 그들의 능력과 성취에 감사해합니다..
  • 신뢰
    • 동료들이 유능하고 올바른 일을 하리라 믿습니다. 필요하면 그들에게 스스로 방향을 정하게 해도 좋습니다.
• 사회적 관계의 힘을 과소평가하지 말라
  • 관계는 언제나 프로젝트보다 오래 지속됩니다. 동료들과 끈끈해지면 여러분이 필요할 때 기꺼이 자신들의 수고를 마다하지 않을 것입니다.

2.4.3 겸손, 존중, 신뢰 실천하기

• 자존심 버리기
• 비평하고 비평받는 법 배우기
• 빠르게 실패하고 반복하기
  • 가끔씩 실패하지 않는다면 충분히 혁신적이지 않거나 위험을 충분히 감수하지 않은 것이다
  • 실패란 배우고 다음 단계로 넘어갈 수 있는 절호의 기회
  → 실패한 구조가 될까 걱정돼서 끝없이 고민만 하다 시간을 낭비하게 된 경험이 있음
  → 고민이 될 때는 빠르게 논의 or 우선 진행하고 PR에서 함께 보면서 판단하는 것이 더 정확하고 빠른 길

2.4.4 비난 없는 포스트모템 문화

• 실패한 근본 원인을 분석하여 문서로 남기는 것
• 포스트 모템에 담겨야하는 내용
  • 사건의 개요
  • 사건을 인지하고 해결에 이르기까지의 타임라인
  • 사건의 근본 원인
  • 영향과 피해 평가
  • 문제를 즉시 해결하기 위한 조치 항목(소유자 명시)
  • 재발 방지를 위한 조치 항목
  • 해당경험에서 얻은 교훈
• 인내심을 기르자
• 마음을 열고 받아들이자