(개인 사비로 책을 구매 후 작성하였습니다.)

최근에 개발자 분들 뿐만 아니라 개발자가 아닌 분들도 많이 읽으시는 "구글 엔지니어는 이렇게 일한다(원제: Engineering at Google)" 를 읽고 느낀 점들을 이야기 해 보고자 합니다.

나무위키에 따르면, 구글은 1998년에 설립되어 24년이 넘은 회사입니다. 그만큼 많은 엔지니어들이 대규모의 서비스를 구축하고 운영한 역사가 있고, 이러한 과정에서 배운 것들이 아주 많을 것입니다.

최근 저의 경험을 돌이켜 보면, 사수가 없이 일하는 경우가 많았습니다. 그리고 지금은 제가 작은 팀을 이끌어야 하는 상황이 되었네요. 이러한 상황을 겪다 보니 다른 사람들은 어떻게 일하는지 궁금했는데, 마침 이 책이 나와서 반갑다는 생각이 들었습니다.

저는 이 책의 표지에도 있듯, 개발 문화, 프로세스, 도구의 측면에서 각각 느낀 점을 이야기 해 보겠습니다.

개발 문화의 측면에서

이 책을 보다 보면 “하이럼의 법칙"을 자주 만날 수 있습니다. 하이럼의 법칙은 다음과 같습니다.

API 사용자가 충분히 많다면 API 명세에 적힌 내용은 충분하지 않습니다. 시스템에서 눈에 보이는 모든 행위(동작)를 누군가는 이용하게 될 것이기 때문입니다. (p.46)

사실 구글까지 가지 않더라도, 지금 다니는 회사에서 서비스운영팀을 통해 이야기를 듣다 보면, ‘저 기능을 저렇게도 쓸 수 있어?‘라는 생각이 들 때가 있습니다. 이게 와닿지 않는다면, 스타크래프트와 같은 게임을 생각해 봐도 좋을 것 같습니다. 제가 초등학생일 때 나온 게임인데, 아직도 하는 사람들이 있고 희한한 전략들이 나오고 있기 때문이죠. (‘게임 X같이 하네’라는 극찬은 덤이죠. 물론 저는 게임을 잘 못 합니다)

이렇듯 하이럼의 법칙은 이 책 전체를 관통하는 원칙이고, 개발 및 구축 뿐만 아니라 운영, 마이그레이션, 폐기, 기타 소프트웨어 엔지니어링의 모든 상황에서 항상 고려해야 할 원칙이 아닌가 싶습니다.

그리고 이 책을 읽으면서 “코드는 쓰는 시간보다 읽는 시간이 더 많다"라는 말을 종종 보게 됩니다. 구글은 이런 부분을 바탕으로 코드의 가독성에 많은 신경을 쓰고 있다고 합니다. 또한 서로를 존중하면서 협업하는 문화, 지식을 공유하려는 문화, 다양성과 다양한 문화를 추구하려는 문화에 대해 알 수 있었습니다.

팀 리더 역할을 하다 보니, 팀을 이끌 때 어떤 역할을 해야 하는지에 대해 좀 더 고민해 볼 수 있었습니다. 예전에 개발 7년차, 매니저 1일차라는 책을 읽었는데, 여기서 팀 리더와 테크 리드에 대한 개념을 처음으로 봤었거든요. 구글에서도 관리자와 테크 리드의 역할에 대해 언급하고, 어떻게 리더십을 발휘해야 할 지에 대해 좋은 사례와 나쁜 사례를 함께 제시하고 있습니다. 또한 조직 측면에서 어떻게 조직을 성장시킬 것인지, 생산성 측정은 어떻게 할 것인지에 대해서도 언급하고 있습니다.

프로세스의 측면에서

구글은 언어별 스타일 가이드를 가지고 있습니다. Google Style Guides 문서를 참고하면, 다양한 언어에 대해 스타일 가이드를 제공하고 있습니다. 자주 쓰는 언어들의 스타일 가이드는 한 번 정도 읽어보면 좋을 것 같습니다. 물론 구글은 문서화와 같은 부분도 중요하게 생각하기 때문에 Google Developer documentation Style Guide라는 문서도 제공하고 있습니다.

코드 리뷰 및 테스트에 대해서도 아주 상세히 설명되어 있습니다. 테스트의 경우 무려 4 개의 장에서 테스트와 관련된 내용을 다루고 있는데, 단위 테스트부터 대규모의 테스트까지 어떤 것들을 테스트 해야 하고, 테스트에 대해 좋은 사례와 좋지 못한 사례들을 자세히 설명해 주어서 좋았습니다.

마지막으로는 폐기에 대해 다루는데, 개발된 소프트웨어는 유지보수 비용을 계속해서 고려해야 한다는 점을 바탕으로 설명합니다. 어떻게 보면 일반적인 이야기겠지만, 앞에서 이야기했던 ‘하이럼의 법칙’에 따라 개발한 사람들도 모르게 사용하고 있는 것들이 있는 것은 아닌지에 대해 생각해 보아야 할 것 같습니다. 또한, 폐기를 담당하는 부서나 인원을 확실히 지정해 주어야 한다는 점도 인상 깊었습니다.

도구의 측면에서

구글은 하나의 레포지토리를 이용해서 많은 소프트웨어를 개발합니다. 또한 소프트웨어를 배포할 때는 하나의 버전(원-버전)으로 배포합니다. GitHub에서 큰 규모의 소스를 받다 보면 파일 뿐만 아니라 커밋 히스토리를 받는 데에도 많은 시간이 걸립니다. 그럼에도 불구하고 구글이 모노레포 방식으로 소스를 관리하고, 하나의 버전을 유지하는 것은 많은 사람들의 노력을 바탕으로 했기 때문에 가능하지 않나 싶습니다.

그 외에도 빌드와 코드 리뷰에 사용되는 도구들, Code Search와 같이 개발자의 생산성을 높이기 위해 고민한 도구들, 안정성을 위해 정적 분석, 의존성 관리를 위해 사용하는 정책과 도구들에 대한 이야기들이 있었습니다. 어떻게 보면 일반적인 스타트업이나 작은 기업들은 상상하기 어려운 규모가 아닌가 싶었습니다.

지금은 데브옵스 엔지니어로 일하다 보니, 마지막 3 개의 챕터는 주의깊게 읽었습니다. 빠른 피드백 루프를 통해 작은 단위로 빠르게 실패하고, 개발 - 스테이징 - 프로덕션 단계로 승격할 때마다 철저한 테스트를 거친다는 점이 인상 깊었습니다. 또한 지속적인 배포를 진행할 때 새로운 기능에 대한 공개 범위를 어떻게 제어할 것인지, 어느 부분까지 배포를 할 것인지 등에 대한 내용들도 좋았습니다. 마지막 장이었던 컴퓨트 환경과 관련된 부분에서는 VM 환경, 컨테이너, 서버리스에 대해 구글이 어떻게 생각하고 있는지에 대해 알 수 있습니다. (물론 저는 AWS를 주로 이용하긴 하지만요) 인프라 아키텍처를 설계할 때 참고해 보면 좋을 것 같습니다.

마무리 하며

어떻게 보면 이 책에서 설명하는 내용들은 ‘구글이니까 가능한 이야기일 수도 있지 않나?’ 라는 생각을 할 수도 있겠습니다. 하지만 팀이나 회사가 커지는 과정을 겪다 보면, 위의 사례들은 한창 성장하는 엔지니어링 조직에게는 레퍼런스가 될 수 있는 책이라고 생각합니다. 이미 구글이 겪은 상황을 참고하여 저나 다른 분들이 속한 조직에도 적절하게 적용할 수 있기 때문입니다. 예를 들면 팀의 구성원이 증가하는 경우라던가, 하나의 API를 다수의 서비스가 참조하면서 사용하는데 애플리케이션을 개선해야 할 때, 어떻게 이를 극복했는지 보면서 제가 속한 조직에서는 어떻게 적용할지 고민해 볼 수 있었습니다. (물론 저 혼자만의 노력으로는 어렵겠지요)

생각보다 흥미로웠던 부분은, 협업을 원활하게 하기 위해 엔지니어들의 행동에 제약을 걸어둔 것이라고 생각합니다. 예를 들어 외부 의존성을 이용하는 경우 어떤 버전을 이용할 것인지, 코드 수정 사항을 추가하는 단계부터 제한을 걸어두는 부분, 가독성 자격증을 가진 사람들이 코드 리뷰에 포함되어야 한다는 점과 같은 부분들 말이죠. 또한 모노레포 구조로 모든 서비스(크로미움과 안드로이드 제외)를 유지한다는 점도 아주 신기했습니다. 물론 버전 관리 시스템부터 테스트, 코드 리뷰, 빌드, 배포와 같은 과정들을 자체적으로 구성한 것이 바탕이 되었기 때문에 가능하지 않았나… 라는 생각이 들었습니다.

개인적으로는 개발자라면 한 번쯤은 읽어 볼 만한 책이라는 생각이 들었습니다. 제가 소위 말하는 ‘네카라쿠배’와 같은 큰 회사에서 일한 적이 없어서 그런지는 몰라도, 소프트웨어 엔지니어링에 대해 갖고 있던 생각을 다른 관점으로 바라볼 수 있게 해 주는 책이었기 때문입니다. 한 번만 읽어볼 게 아니라, 상황에 따라 여러 번 다시 읽어보면서 곱씹어 보면 좋을 것 같아요.

한 번 읽어보니, 각자의 사정에 따라 다음 챕터를 추천드리고 싶습니다.

• CTO나 개발 조직을 이끌고 있는 경우, 구글의 엔지니어링 문화를 다루는 Part 2(문화), Part 3(프로세스)와 같은 부분을 특히 읽어보시면 좋을 것 같습니다.
• 개발자라면 Part 3(프로세스), Part 4(도구) 중 궁금한 부분들 위주로 먼저 읽어보면 좋을 것 같습니다.
• 인프라를 구축하거나 운영하신다면, Part 3(프로세스) 중 테스트 관련 장(11~14 장), 15장(폐기), Part 4(도구) 중 16, 20~25장을 읽어보시면 좋을 것 같습니다.

읽어주셔서 감사합니다 :)