본문 바로가기
한걸음씩/책 & 강의 정리

[책 정리] 구글 엔지니어는 이렇게 일한다. | #1장 소트프웨어 엔지니어링이란? 을 읽고

by TLOWAC 2024. 11. 8.

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

"프로젝트 수명 주기"

이따금 과거의 프로젝트를 돌아보면, "완성 땅땅" 하고선 열어보지도 않는 '프로젝트의 수명주기' 가 채 1주일도 가지 않는것들이 많았다. 

더욱이 알고리즘 같은 경우는 프로젝트의 수명 주기가 1시간이나 될까..

 

이번에 "프로젝트 수명 주기" 를 인지 함으로써, 항상 프로젝트 시작전 많은 고려사항을 고민하며 골머리를 썩히는 시간을 줄일 수 있을것 같다.

"아.. 이거 넣어야 되나? 아... 이거 필요한데" 

"이거 프로젝트 수명 주기 1주일 용도다! 넘겨!"

(웃자고 한소리다... )


 

실제 회사에 근무를 할때 특정 라이브러리들의 의존성 업데이트로 인해 기술 부채가 발생한 경험이 있다. 

스타트업의 특성상 기술 부채의 처리와 고객 유입과 지표 상승, 투자 유치를 위한 신규 기능 업데이트 사이에서의 저울은 항상 어렵게 느껴진다. 

 

당시에는 우린 라이브러리의 버전을 2.x 에서 3.x 로 올리는 과정에서 많은 트러블 슈팅이 있었고, 완료되었다고 생각되는 시점에 에러가 발생하여 업데이트한 내역을 다시 되돌리기도 했다. 이번에 "구글 엔지니어는 이렇게 일한다" 에서 특정 컴파일러 버전에 대한 이러한 사례를 설명해주는데 더욱 공감이 갔다. 라이브러리로도 이렇게 많은 고민을 하고 수정을 거쳤음에도 문제가 발생하였는데, 컴파일러라니 작금의 나는 그 고통을 상상조차 할 수 없을것 같다. 특히, 이로인해 특정 버전의 컴파일러에 의존하게 만들었었다 라는 부분에서도 공감이 갔다. 

 


 

 "인프라를 변경하여 서비스가 주단되는 등의 문제가 발생하더라도 같은 문제가 지속적 통합 시스템의 자동 테스트에서 발견되지 않는다면 인프라팀의 책임이 아니다." 라는 '비욘세 규칙' 과 같은 구글만의 재밌는 규칙도 있다는걸 알게 되었다. ( 책에서는 '네가 좋아했다면 CI 테스트를 준비해뒀어야지' 라는 추가 설명도 달려 있다. ㅋㅋㅋㅋㅋㅋ )

 

솔직히 이런 요소조차 없었으면 704 페이지.. 의 책 두께를 보고 포기할뻔했다. 

 


 

그리고, '원점 회귀' 라는 소주제에서 심금을 울리는 도표를 하나 발견했다. 

모든 개발자들의 심금을 울리지 않았을까 짐작한다. 

 

( 배포 직전 들어오는 신규 기능 추가 / 수정 요청들의 향연... 그 홍수 속 어딘가의 나.. )

반응형

댓글