Dev

구글 엔지니어는 이렇게 일한다

prostars 2022. 8. 28. 14:14

책의 도입부가 인상적인데 ‘시간 위를 걷는 프로그래밍’이라는 멋진 말과 함께 소프트웨어 엔지니어링을 ‘흐르는 시간 위에서 순간순간의 프로그래밍을 모두 합산한 것이다’라고 이야기한다. 시간의 무서움에 대한 이야기와 하이럼의 법칙 이야기가 계속된다. 개발해오면서 여러 개발 조직에서 봤던 패턴의 상당수는 ‘일단’ 구현하고, ‘나중에’ 수정하자. ‘일단’ 돌아가니, ‘나중에’ 개선하자. 등이 누적된 세월의 흔적들이 유령의 묘지와 더불어 매우 많다. 코드는 자산이 아니라 부채이므로, 불필요한 코드를 줄여 관리 비용을 줄여야 한다. 그리고, 코드의 일관성은 매우 중요하다. 매우 공감한다. 지금 몸담고 있는 팀에서도 내가 하는 작업의 상당 부분은 방치된 레거시를 정리하고 구조를 리팩토링하면서 그동안 쌓여있던 기술 부채를 갚는 것이다. 작업한 내용 중 일반화해서 공유할 수 있는 부분은 정리해서 가끔 포스팅하고 있다.

책의 제목과 같이 내용의 상당 부분이 구글 내부에서 경험하고 개선한 내용을 소개하면서, 구글의 개발 프로세스에 대한 이야기, 후반부로 갈수록 구글이 내부적으로 개발하여 사용하는 툴에 대한 이야기들이 많다. 구글이니까 가능할 법한 내용들이 많아서, 내 상황에서는 그 툴과 방식을 그대로 사용할 수는 없지만, 그 경험과 통찰을 어깨너머로 보고 저런 방법도 있고, 저렇게 생각할 수도 있다는 정도를 배우는 시간이었다. 다만, 웬만한 개발 에세이보다 텍스트가 많다. 그리고, 같은 말을 너무 반복한다. 이것만 아니었어도 텍스트는 많이 줄었겠다. 아쉽지만, 이 책의 많은 내용과 깊이를 간단히 정리할 능력은 없기에 간단한 독서 후기와 조금 많은 인용문으로 갈음하면서, 일독을 권한다.

https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=294381766

 

[전자책] 구글 엔지니어는 이렇게 일한다

여러분이 궁금해하고, 반드시 알아야 할 프로그램을 효과적으로 짜는 방법은 물론, 코드베이스를 지속 가능하고 건실하게 만들어주는 엔지니어링 관행까지 모두 소개한다. 소프트웨어 엔지니

www.aladin.co.kr

어떤 프로그래밍 언어는 이러한 의존을 원천봉쇄하고자 라이브러리 버전마다, 심지어 같은 프로그램이라도 실행할 때마다 해시 순서가 달라지게 합니다. 하지만 이런 경우조차 하이럼의 법칙에서 완전히 자유롭기는 어렵습니다. 해시 반복 순서가 무작위임을 눈치챈 누군가가 이를 난수 발생기로 사용할 수도 있기 때문이죠. 이제 무작위성을 제거하면 이 개발자의 코드가 오작동할 것입니다.

여러분보다 똑똑하고 여러분을 대체할 역량을 갖춘 사람을 적극적으로 뽑아야 합니다.

‘우린 항상 이렇게 해왔어요’라고 말하면서 현재 방식에 문제가 있을 수 있다고는 의심조차 못하는, 말 그대로 비판 능력을 상실해버리죠. 현상 유지를 정당화하기 위해 메커니즘을 억지스럽게 꼬아놓거나 합리화 논리를 만들어내기도 합니다. 이 부분이 깨끗한 눈을 가진 여러분에게 굉장히 유리한 지점입니다.

코드가 일관되게 작성되어 있다면 엔지니어들은 익숙지 않은 부분을 살펴볼 일이 생겨도 상당히 빠르게 작업을 이어갈 수 있습니다. 로컬 프로젝트라면 고유한 개성이 허용되지만, 그 프로젝트에서 사용하는 도구, 기법, 라이브러리는 모두 똑같으며, 그 모든 게 그냥 동작합니다.

코드 리뷰는 주어진 변경이 수많은 다른 사람에게도 쉽게 이해되는지를 평가하는 첫 번째 시험대입니다. 코드는 작성되는 횟수보다 읽히는 횟수가 몇 배는 많으므로 이해하기 쉽게 작성하는 게 매우 중요합니다.

문서자료는 단 한 번만 작성하면 되지만 결국 수백 번, 수천 번 읽히게 됩니다. 초기 비용은 미래의 모든 독자에게 혜택으로 돌아갑니다. 문서자료의 혜택은 시간에 비례해 커지고, 해당 코드를 조직의 구석구석까지 퍼뜨리기 위해서는 없어서는 안 되는 요소로 작용합니다.

경험상 구글은 단위 테스트를 80%, 그 외 범위가 더 넓은 테스트를 20% 비중으로 작성하도록 장려합니다.

테스트 대역을 사용하려면 코드베이스가 테스트하기 쉽도록 설계되어 있어야 합니다. 그래야 테스트에서 실제 구현을 테스트 대역으로 교체할 수 있습니다.

폐기는 축제 행렬이 휩쓸고 지나간 거리를 청소하는 지저분한 일처럼 느껴질 수 있습니다. 하지만 이런 노력 덕분에 유지보수 부담이 줄고 엔지니어가 알고 신경 써야 할 정보량이 줄어서 전체적인 소프트웨어 생태계가 개선됩니다.

셸 스크립트 디버깅은 고통스러운 일이며 꼼수에 꼼수가 덕지덕지 쌓여갈 것입니다.

유령의 묘지란 너무 오래되고 둔하고 복잡해서 아무도 손대려 하지 않는 시스템을 뜻합니다.
...
코드가 어떻게 이용되는지 정확히 볼 수 있고 각 변경의 영향을 확실하게 파악할 수 있다면 의존성을 관리하며 겪는 문제 대부분은 더 이상 문제가 아니게 됩니다. 다시 말하지만, 버전 관리(프로젝트를 통제할 수 있음)가 의존성 관리(통제할 수 없음)보다 훨씬 쉽습니다. 통제권이 없는 외부 프로젝트를 이용하기 시작하면 이야기가 전혀 달라집니다.

CI를 몇 번 돌릴 때마다 한 번씩 실패하는 불규칙한 테스트는 시도 때도 없이 울리는 거짓 경보만큼이나 해롭습니다. 취할 수 있는 조치가 없다면 경보도 울리지 말아야 하고, SUT의 불변성이 실제로 깨진 게 아니라면 테스트도 실패해서는 안 됩니다.

가축으로 관리하고자 마음먹었다면 다음 선택은 자연스럽게 컨테이너일 것입니다. 컨테이너는 자원을 적게 쓰고 구동 시간도 짧습니다.

- 알라딘 eBook <구글 엔지니어는 이렇게 일한다> (타이터스 윈터스.톰 맨쉬렉.하이럼 라이트 지음, 개앞맵시 옮김) 중에서
반응형