[독후감] 구글 엔지니어는 이렇게 일한다

구글 엔지니어는 이렇게 일한다 - 예스24

 

강연을 듣다가 "저와 같은 기업 엔지니어들의 고민을 먼저 생각하고 해결한 책들이 있어서 꼭 읽어보시길 추천한다"  하여서 읽게되었다.

 

한줄평 : 너무 배울 점이 많은 책. 개발자 지인/ 동료들에게 강제로 읽게 하고 싶은 책

 

장점이 너무 많아서, 다 적을 수가 없을 거 같다. 매우 쉽게 풀어서 적었지만, 나한테는 어려운 부분도 너무 많았다.

 

네이버 검색플랫폼 총괄 곽용재님이 "시중에 나온 많고 많은 자기계발/실천법 서적들을 응축하여 구글이 핸드드립한 에스프레소를 마시느 느낌이니, 이 책만 잘 읽어도 이 바닥 전체를 섭렵한 기분이 들 것입니다." 라는 서평을 적었는데 정확한 표현이라 생각이 든다.

 

단원을 보면 알겠지만, 팀워크, 개발 방법론, 개발 도구에 대해서 설명하는데, 2000년도의 역사부터 현재에 이르기까지 구글이 진행한 고민을 실패와 성공 사례를 들어서 다양한 분야에서 설명해준다. (영문판은 2020년 출간이여서, 거기까지 일단 2020년까지의 고민이다.)

 

 

좋았던 점

정말 수 많은 장점이 있었지만, 내가 정말 좋았던 점을 뽑아보겠다.

 

1. 모든 글에 트레이드오프에 대한 관점이 녹아 있으며, 생각의 유연함과 목표에 중요성에 대해서 알려준다.

 

4단원 구글의 도구편에서 특히 많이 보이는 데, 그들의 행동에는 모두 이유가 있다. 어떤 문제를 해결하기 위해서, 다양한 시도를 해보면서, 그 시도에서 장점과 단점을 모두 분석한다. 그리고 제품의 현재 상황에 맞게 방법을 선택한다.

 

대표적인 아래 두 예시가 있다.

- 구글 code search에서, 정확성을 조금 낮추는 대신 속도를 올리기로 선택하였다. 검색 지연시간이 개발자의 집중력(생산성)을 낮출 수 있기 때문에 더욱 빠르게 제공을 하는 선택을 하였고, 그에 대한 트레이드 오프로 정확성이 조금 낮아지는 과정을 설명해주었다. ( 이 부분도, 알고리즘을 바꾸거나, 타겟의 분석을 통하여 정확성을 최대한 확보할 수 있도록 개선하였다)

- 테스트와 관련하여서, 잘못된 테스트에 대해서 잘못된 결과가 나오지 않게 테스트가 정확해야한다는 조언을 해준다. 왜냐하면, 잘못된 테스트로 인하여, 오류가 없는 부분을 체크하는 곳에서 시간이 낭비되기 때문이다. 하지만, 보안과 관련된 부분에서는 잘못된 결과가 있더라도 확실한 위험을 체크하는 게 더 중요하기 때문에 부정확한 테스트를 일부 감수해야한다는 의견을 보여준다.

 

첫 번째 예시는 트레이드 오프를 보여준다. "생산성"을 위해서 완벽성을 100퍼에서 조금 낮추되, 100퍼에 가깝게 보이도록 그들이 어떤 노력을 했는 지 보여준다.

두 번째 예시는 목표에 따른 방향에 차이에 대해서 보여준다. 같은 테스트이지만, 일반적인 테스트는 테스트의 신뢰성이 중요하다. 하지만, 보안 관련 테스트는 "생산성"보다 "안정성"을 목표로 한다. 그래서 두 테스트는 목표가 다르기에 방향성도 달라지게 된다

 

이런 사례가 정말 끝도 없이 나온다. 그리고 위 예시를 통해서 문제를 해결했지만, 트레이드 오프한 대상마저 극복하기 위해서 지금도 새로운 방법을 시도하고 더 노력하고 있다.

 

2. 생산성과 협력에 대한 수많은 조언

 

생산성과 협력에 대해서 정말 수많은 조언을 해준다.

 

위키(문서 검색 도구) / 코드 서치 (코드 검색 도구) / 테스트 / 스타일 가이드(가독성) / 코드 리뷰 / 빌드 시스템 등에 대한 구구글 문화를 알려준다. 또한, 여기서 "이건 구글이니까 가능하다", "구글을 기반으로 한 00 오픈소스가 있다" 등 현실적인 조언을 아끼지 않는다. 이 부분에서 정말 개발적 생산성을 올리기 위한 방법에 대해서 많이 생각하게 된다. 덤으로, 2000년도부터 다양한 시도를 다 보여준 부분에서 프로그래밍의 역사(?)를 배우게 된다. 

 

협력에 대해서도 많이 이야기해준다. 2챕터는 전부 성장 관련된 이야기인데, 이걸 따로 분리해서 작은 책으로 팔았어도 좋았을 거 같다. 성장하는 조직, 팀워크 이끌기 등 여러 조언이 있지만, 가장 인상 깊었던 말은 "리더는 팀원들의 행복을 책임져야한다." 라는 점이다. 이 부분은 굉장히 인상 깊었다. 팀장은 팀을 이끌고 프로젝트를 완성하는 것이 목적이라 생각했는데, 팀장의 역할은 팀이 안정적이고 지속가능하게 유지하는 것도 있는 것이다. 훌륭한 리더는 결국 밑의 사람들을 책임지는 것인데, 이런 부분을 경험해보지 못해서 낯설고 한 대 맞은 기분이었다.

 

다만, 이런 이상적으로 팀이 운영될 수 있는 규칙은 해고라는 막강한 징벌권이 있어서 그런 게 아닌가 하는 의심도 든다.

 

3. 시간 위를 걷는 프로그래밍

 

사실 이 책에서 가장 인상 깊은 점은 "시간 위를 걷는 프로그래밍"이라는 용어이다. 

 

- "단순히 코드가 실행되면 되지? 왜 테스트도 하고, 가독성을 챙겨서 코드를 짜야하는 가?"

- "왜 시간이 지나면 코드는 에러가 발생하는가?"

- "내 코드가 수정되는 것이 문제가 되는 가?" 

를 답변하는 용어가 "시간 위를 걷는 프로그래밍"이다.

 

코드는 단순히 지금 끝나는 것이 아니다. 내일 내가 유지보수할 수도 있고, 내 동료가 할 수도 있고, 내가 모르는 누군가가 할 수도 있다. 반대로, 내가 당할 수도 있다. 그러니, 기업의 누군가가 할 수 있도록, 읽기 쉽게 만드는 것이다.

 

오늘의 코드는 현재 기업 제품에 알맞을 지도 모른다. 하지만, 성장한 기업에서 오늘의 코드는 부족할 수 있다. 느릴 수도 있고, 정확성이 떨이질 수도 있고, 생산성이 낮을 수도 있고, 유지보수 비용이 너무 클 수도 있다. 기술의 흐름과 맞지 않을 수도 있다. 그렇게 새로운 문제를 직면하게 된다. 그때, 내가 있다면 내가 유지보수를 할 것이고, 없다면 누군가가 할 것이다. 그 때, 그 사람이 이 코드를 유지보수할 수 있게 만드는 것이 중요하다.

 

이 때, 이 코드를 수정하는 것은 그 문제를 해결하는 단순한 일일까? 아쉽게도, 그 제품을 누군가 사용하고 있다면, 그렇지 않다. 누군가 사용한다면, 내 코드의 변화에 따라서 사용자도 영향을 받는다. (버전관리를 하고 있다면, 지금은 안 받지만 최신버전으로 업그레이드한다면 받게된다.) 가장 쉽게 버전 업 하면서 API가 바뀌었다 생각해보자. 이름만 바뀌어도 사용하는 모든 곳을 업데이트 해야할것이다. API 함수의 인수나 기능이 바뀌었다면... 제대로 동작하지 않을 수도 있다. 

 

이런 부분들을 구글에서는 내부적인 용어로 설명한다.

- 하이럼의 법칙 :  사용자들이 많아질수록 API를 제작한 사람의 의도와는 상관없이 사용자들은 그 API에 접근할 수 있는 한 다양한 행위들을 저지를 수 있다는 의미

- 비욘세 규칙 : 네가 좋아했다면 CI 테스트를 준비해뒀어야지 (변경사항에 대해서, 테스트가 없어서 에러난 부분에 대해 책임을 묻지 않는다는 규칙)

 

이럼 점들이 있기에 우리는 단순한 코드가 아니라 미래지향적으로 코드를 짜야한다. 테스트를 하고 가독성을 높이고, 여러 문제를 해결해나가야한다. 그래서 우리는 시간 위를 걷는 프로그래밍을 해야한다.

 

이외에도 정말 보석같은 조언들을 원하다면 직접 읽어보길 원한다. 나는 4단원이 너무 인상 깊었다.

 

아쉬운 점

4단원이 정말 어려웠다. 아무래도 내가 비전공자이다보니 이것저것 용어에서 막히고, 너무 당연한 말을 이해못했었다.

 

책에서도 계속 언질을 주기는 하지만, 사실 너무 압도적이다. 오픈소스로 있는 도구들을 사용하지 않는다면, "구글이니까 가능하다" 라는 말을 계속 하게 만든다.

 

결론

나중에 성장해서 다시 읽고 싶은 책이다.

내가 아직 배포쪽 관련해서 간략한 지식만 있어서 더 알쏭달쏭 하기도 하였다. 좀 더 성장해서 그 부분은 꼭 다시 보고 싶다.

 

책을 읽으면서 정말 감사하다는 말이 나오게 된다.