TOC
참고
본 내용은 구글 엔지니어는 이렇게 일한다(링크)를 읽고 정리한 내용입니다.
책의 내용과 함께 개인적인 의견과 생각, 학습을 담아 작성하였습니다.
들어가며
- 프로그래밍과 소프트웨어 엔지니어링 작업은 다르다.
- 프로그래밍 : 개발
- 소프트웨어 엔지니어링 : 개발 + 수정 + 유지보수
- 의사결정의 복잡성과 이해관계 측면에서도 차이가 있다.
- 트레이드오프를 평가하여 합리적인 결정을 내려야 한다.
시간과 변경
- 시간이 프로그램에 미치는 영향을 알아보려면 '이 코드의 예상 수명은?'이라는 질문을 던져보면 좋다.
- 단명하는 시스템은 '그저' 프로그래밍 문제와 다를 게 없다.
- 수명이 길어질수록 변경이라는 요소가 점점 중요해진다. 우리가 말하는 소프트웨어의 지속 가능성의 핵심이다.
하이럼의 법칙
- 수명이 길어질수록 '동작한다'와 '유지보수 가능하다'의 차이를 더 분명하게 인지해야 한다.
- '당장 돌아가야 한다'라는 생각으로 작성한 코드와 '언제까지고 작동해야 한다'라는 생각으로 작성한 코드의 차이를 생각해보면 어떤 관계인지가 분명하게 그려진다.
- 구글에서는 '기발한'이 칭찬으로 느껴진다면 프로그래밍이라 하고, 질책으로 느껴진다면 소프트웨어 엔지니어링이라 말한다.
규모 확장과 효율성
- 가장 중요한 자산인 코드베이스 자체도 확장 가능해야 한다.
- 빌드 시스템이나 버전 관리 시스템이 점 점 느려진다면 어느 순간 더는 정상 운영할 수 없는 시점이 온다.
- 조직이 커지고 브랜치 수가 늘어나면 머지않아 반복 되는 작업에 엄청난 시간과 노력을 쏟아붓고 있는 모습을 발견할 것
확장 가능한 정책들
- 비욘세 규칙: 공통 CI 시스템에 추가해두지 않은 테스트는 인프라팀이 책임지지 않는 정책
- 시행착오의 결과: 자동화(한 사람이 더 많은 일을 수행), 통합과 일관성(저수준 변경이 영향을 미치는 범위 제한), 전문성(적은 인원으로 더 많은 일을 수행)
- 업그레이드에 안정적이고 싶다면
- 규칙적으로 하자.
- 유용한 정책과 절차를 갖추자.
- 자동화하자.
- 더 자주 하자.
원점 회귀
- 개발 과정에서 문제를 일찍 발견할수록 비용이 적게 든다는 사실은 널리 받아들여지는 진실이다.
- 그래서 다양한 버그를 개발 초기에 잡을 수 있도록 '다층 방어' 전략을 구사한다.
트레이드오프와 비용
- 우리가 만들 제품의 기술적 결정이 초래할 이로운 점과 해로운 점 모두를 인지해야 합니다.
- 조직의 건실성에는 은행 잔고뿐 아니라 구성원들이 스스로의 가치를 느끼고 생산적인 일을 하고 있다고 생각하는지까지 포함
사례: 화이트보드 마커
- 작은 마커 때문에 흐름 끊기지 않도록 구글은 지원한다.
- 물리적 비용으로 인적 비용을 지키는 사례
- 엔지니어링 조직의 선택을 결정짓는 요인
- 반드시 해야 하는 일 (법적 요구사항, 고객 요구사항)
- 근거에 기반하여 당시 내릴 수 있는 최선의 선택(적절한 결정권자가 확정)
사례: 분산 빌드
- 구글에서도 로컬에서 컴파일하던 시기가 있다.
- 엄청난 성능의 컴파일 로컬 머신이 있었지만, 코드가 커질수록 감당이 안 됐다.
- 자체 분산 빌드 시스템을 개발했다. 엔지니어 비용이 들었지만 그래도 투입됐다.
- 빌드가 빨라지고 인적 리소스를 그대로 활용할 수 있었다.
- 그런데 개개인의 빌드 최적화를 점차 놓으면서 전체가 의존성을 감당해야 했다.
- 제번스의 역설: 효율이 좋아지면 자원 소비가 늘어난다.
- 트레이드오프를 감당하고 계산하고, 선례를 만들었던 사례.
결정 재고하기와 잘못 인정하기
- 데이터 주도 방식은 시간이 흘러 데이터가 변하면(혹은 가정이 무너지면) 프로젝트의 방향도 바뀔 수 있다.
- 잘못을 인정하고 계획을 수정하는 것은 당연한 일이다.
- 잘못했음을 인정할 수 있게 해주는 능력 역시 데이터 중심 문화가 주는 커다란 장점
- 그땐 맞고, 지금은 아닐 수 있다. 장수하는 조직에 특히 중요한 요소이다.
소프트웨어 엔지니어링 vs 프로그래밍
- 소프트웨어 엔지니어링이 프로그래밍보다 우수한 게 아니다. 단지 이 둘에 적용되는 제약 사항, 가치, 모범 사례가 서로 다르다. 그러니 구분을 잘 해야 한다.
- 시간 흐름에 따른 코드 관리. 시간 흐름에 따른 규모 확장의 영향, 이런 관점에서의 의사결정 방식
- 프로그래밍은 코드를 생산하는 즉각적인 행위
- 소프트웨어 엔지니어링은 활용 가치가 남아 있는 한 오랫동안 코드를 유용하 게 관리하고 팀간 협업을 가능케 하는 정책, 관례, 도구 모두를 아우르는 종합적인 개념
- 동일한 모범 사례를 수명 축의 양 끝단에 위치하는 두 프로젝트에 똑같이 적용하려는 건 너무 안일한 생각
