구글 엔지니어는 이렇게 일한다(타이터스 윈터스, 톰 맨쉬렉, 하이럼 라이트) - 01
공감되거나 인상 깊었던 문장들은 다음과 같다.
- 시간 위를 걷는 프로그래밍. 소프트웨어 엔지니어링은 단순히 코드를 작성하는 행위에 더하여, 시간의 흐름에 발맞춰 한 조직이 그 코드를 구축하고 유지보수하는 데 이용하는 모든 도구와 프로세스를 포괄한다. (P.10)
- 이 책을 통해 공유하고자 하는 핵심은 소프트웨어 엔지니어링이란 ‘흐르는 시간 위에서 순간순간의 프로그래밍을 모두 합산한 것이다.’라는 관점이다. (P.11)
- 이 책은 소프트웨어 조직이 설계, 아키텍처 잡기, 코드 작성 시 명심해야 한다고 믿는 세 가지 기본 원칙을 강조한다. 시간과 변경(time and change)는 코드가 수명을 다할 때까지 새로운 요구사항에 잘 적응하려면 어떻게 해야 하는가에 대한 이야기다. 규모와 성장(scale and growth)는 커져가는 규모에 발맞춰 조직은 어떻게 진화해야 하는지에 대한 이야기다. 트레이드오프와 비용(tradeoff and cost)는 ‘시간과 변경’, ‘규모와 성장’에서 얻는 교훈들을 바탕으로 조직은 어떻게 의사결정을 내려야 하는가에 대한 이야기다. (P.11)
- 소프트웨어 엔지니어링 프로젝트에서 엔지니어는 시간의 흐름과 언제가 변경될 가능성에 더 신경 써야 한다. 소프트웨어 엔지니어링 조직은 만들어낼 소프트웨어 자체뿐 아니라 제작하는 조직까지 양 측면 모두에서 확장과 효율에 더 집중해야 한다. (P.41)
- 짧은 생을 마감하는 코드는 대체로 시간의 영향을 받지 않는다. 이는 프로그래밍과 다를 게 없다. 수명이 길어질수록 변경이라는 요소가 중요해진다. 십 년 이상 살아남는다면 프로그램의 모든 의존성이 처음과는 다를 것이다. 소프트웨어 엔지니어링과 프로그래밍을 가르는 핵심은 이 사실을 인식하는 데서 시작한다. 이 차이가 소프트웨어의 지속 가능성(sustainability)의 핵심이다. 기술적인 이유든 사업적인 이유든, 소프트웨어의 기대 생애 동안 요구되는 모든 가치 있는 변경에 대응할 수 있다면 ‘그 프로젝트는 지속 가능하다’라고 말한다. (P.42)
- 협업은 그 자체로 새로운 문제를 유발하지만, 한 명이 개발하는 것보다 가치 있는 시스템을 만들어낼 잠재력을 지닌다. 소프트웨어 프로젝트의 팀 조직, 프로젝트 구성, 정책과 관례는 모두 소프트웨어 엔지니어링의 복잡성을 좌우한다. 그리고 이 문제들은 모두 규모와 관련이 깊다. (P.43)
- 소프트웨어 엔지니어링에서는 주기적으로 여러 선택지 사이의 트레이드오프를 평가해야 한다. 지속 가능성을 잃지 않으면서 조직, 제품, 개발 워크플로의 규모를 확장하는 비용을 관리해야 한다. 한번 내린 결정은 훗날 다시 검토해야 할 수 있음을 잊지 말아야 하며, 이 결정 때문에 생긴 지연 비용을 정확히 계산해둬야 한다. (P.44)
처음 ‘시간 위를 걷는 프로그래밍’이라는 표현을 봤을 때는 소프트웨어 엔지니어링을 미화하기 위함이라고 생각했다. 뒤따른 내용들을 통해 시간이 지남에 따라 소프트웨어의 복잡도가 높아지고, 유지보수가 어려워짐을 표현한 것이라는 사실을 깨닫곤 공감되는 표현이라 생각했다. 소프트웨어의 수명, 시간이 지남에 따라 커지는 서비스 규모, 팀에 참여하는 모든 이해 관계자들 사이에서 내려진 결정들에 따라 소프트웨어는 입체적이고 유기적으로 움직인다. 구글에선 이런 문제들을 어떻게 해결했는지 다음 내용들이 궁금해졌다.
댓글남기기