[정독하기] 구글 엔지니어는 이렇게 일한다 - Chapter 1

 안녕하세요 마개입니다.
읽어야지 생각하고 읽지 않았던 “구글 엔지니어는 이렇게 일한다”를 읽으면서 기록 남겨봅니다.

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

• 프로그래밍과 소프트웨어 엔지니어링의 가장 큰 차이는 시간, 확장, 실전에서의 트레이드오프 3가지
  • 시간 : 이 코드의 예상 수명은?
  • (규모) 확장 : 몇 명이 참여하는가? 시간의 흐름에 따라 엔지니어들은 개발과 유지보수의 어느 부분에 관여하는가?
  • 트레이드오프 : 상황에 맞게 트레이드오프를 평가하여 합리적인 결정을 내려야 함.
• 소프트웨어 엔지니어링은 흐르는 시간 위에서 순간순간의 프로그래밍을 모두 합산한 것이다
• 프로그래밍 작업 : 개발 (Development)
• 소프트웨어 엔지니어링 작업 : 개발 (Development) + 수정 (Modification) + 유지보수 (Maintenance)

시간과 변경

• 소프트웨어 프로젝트의 기대 수명과 업그레이드 중요도의 관계
  • 기대 수명이 짧은 프로젝트에 대해서 업그레이드를 할 필요가 없음
  • 기대 수명 스펙트럼의 최저점과 최고점 사이 어딘가에서 전환이 일어남
  • 구글에서는 일반적으로 전환 시점이 5~10년이었음
• 하지만 초기에 업그레이드를 고려하지 않는 프로젝트는 힘들어짐
• 하이럼의 법칙
  • API 사용자가 충분히 많다면 API 명세에 적힌 내용은 중요하지 않습니다. 시스템에서 눈에 보이는 모든 행위(동작)를 누군가는 이용하게 될 것이기 때문입니다.

규모 확장과 효율성

• 프로젝트 규모가 두 배로 커진 뒤에 똑같은 상황이 닥치면 인력도 두 배만 투입하면 해결될 것인가
• 소프트웨어에 필요한 자원과 코드베이스 자체도 확장이 가능해야 함.
• 확장하기 어려운 정책들
  • 인원은 그대로이고 작업량은 늘었는데 작업을 자동화하거나 최적화할 수단이 없다면 확장성에 문제가 있음
  • 시스템을 버전업해서 기존 방식을 폐기하고 마이그레이션해야 하는 상황에서 사용자에게 마이그레이션을 부탁할 경우 진행이 어려워짐.
  • 그렇기에 마이그레이션을 담당하는 내부에서 자동화를 이용해 직접 하는 것이 더 좋은 방법임
• 확장 가능한 정책들
  • 비욘세 규칙 : 인프라를 변경하여 문제가 발생하더라도, 같은 문제가 CI 자동 테스트에서 발견되지 않는다면 인프라팀의 책임이 아니다
• 원점 회귀 (왼쪽으로 옮기기)
  • 개발 과정에서 문제를 일찍 발견할수록 비용이 적게 든다.

트레이드오프와 비용

• 좋은 결정을 내리는 일.
• 합의를 통해 결정을 내림.
• 비용은 금융 비용뿐만 아니라 기회 비용, 사회적 비용도 있음

소프트웨어 엔지니어링 vs 프로그래밍

• 둘 중 어느 것이 더 낫다는게 아니라 이 둘에 적용되는 제약 사항, 가치, 모범 사례가 서로 다름
• 프로그래밍 : 코드를 생산하는 즉각적인 행위
• 소프트웨어 엔지니어링 : 활용 가치가 남아 있는 한 오랫동안 코드를 유용하게 관리하고 팀 간 협업을 가능케 하는 정책, 관례, 도구 모두를 아우르는 개념