구글 개발자들은 어떻게 일하는가

지난 5월 10일 한빛미디어에서 번역서 한권이 출간되었습니다.

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

http://www.kyobobook.co.kr/product/detailViewKor.laf?ejkGb=KOR&mallGb=KOR&barcode=9791162245620&orderClick=LEA&Kc= 

구글 엔지니어는 이렇게 일한다 - 교보문고

너무 궁금하여 구매를 안 할 수가 없었습니다.
흔히 개발자들의 꿈이 기업, 초엘리트들이 모여있는 그곳에서 과연 개발자들은 어떻게 일하는지
개발 환경은 어떤지, 어떤 개발 문화인지
언론 보도 혹은 구글에 재직 중인 직원들이 공유하는 몇몇 글들만으로는 부족했습니다.
단순 언론 보도용이 아닌, 카더라 같은 글들이 아닌
구글 SW 엔지니어들이 아주 생생하고, 디테일하게 귀에 때려 박아주길 원했습니다.

결론적으로 말하면 이 책은 그런 궁금증을 해소시켜주는데 어느 정도는 도움이 되었습니다.
다만 완벽히 해소가 안된 부분은 책이 부족해서가 아니라 제 역량이 부족한 탓일 겁니다.

저는 Android app 개발자입니다.
그러다 보니 구글에서 다루는 SW와는 조금 차이가 있고,
그런 부분에서 온전히 이해하기는 어려웠습니다.
(시냇물이 바다를 어찌 이해하겠습니까...ㅠㅠ)

규모의 차이도 있지만, 프론트 엔드에서는 알기 어려운 백엔드의 생태계랄까요?
그런 부분도 무시할 수는 없는 듯 합니다.

누가 이 책을 읽으면 좋을까?

이 책의 목차를 우선 보면 아래와 같습니다.
목차 중 특히 Part II 문화 쪽을 보면 개발자들 중 리드급 혹은 시니어 엔지니어들이 보면 좋을 듯한 제목입니다.
주로 개발 팀을 어떻게 이끌어 나가면 좋을지에 관한 구글의 사례를 소개하는 부분입니다.

[Part I 전제] CHAPTER 1 소프트웨어 엔지니어링이란? [Part II 문화] CHAPTER 2 팀워크 이끌어내기 CHAPTER 3 지식 공유 CHAPTER 4 공정 사회를 위한 엔지니어링 CHAPTER 5 팀 이끌기 CHAPTER 6 성장하는 조직 이끌기 CHAPTER 7 엔지니어링 생산성 측정하기 [Part III 프로세스] CHAPTER 8 스타일 가이드와 규칙 CHAPTER 9 코드 리뷰 CHAPTER 10 문서자료 CHAPTER 11 테스트 개요 CHAPTER 12 단위 테스트 CHAPTER 13 테스트 대역 CHAPTER 14 더 큰 테스트 CHAPTER 15 폐기 [Part IV 도구] CHAPTER 16 버전 관리와 브랜치 관리 CHAPTER 17 Code Search CHAPTER 18 빌드 시스템과 빌드 철학 CHAPTER 19 Critique: 구글의 코드 리뷰 도구 CHAPTER 20 정적 분석 CHAPTER 21 의존성 관리 CHAPTER 22 대규모 변경 CHAPTER 23 지속적 통합 CHAPTER 24 지속적 배포 CHAPTER 25 서비스형 컴퓨트

하지만 그렇다고 팀원이나 주니어 개발자들이 읽지 말란 법은 없습니다.
신입, 주니어도 결국 중니어를 거쳐 시니어가 되고 팀 리드를 맡게 되겠죠.
이런 내용을 미리 읽는다고 잘못될 일은 없습니다.
다만 너무 신입일 경우 이런 부분은 잘 와닿지도 않고 다소 시간 낭비로 느껴질 수도 있겠다 싶더군요.
만약 읽다 그런 느낌이 들면 건너 뛰는 것도 좋을 것 같습니다.

구글 SW 프로세스를 요약해보면

본 책을 읽고 제가 이해한 구글의 프로세스 내지는 정책을 정리하면 다음과 같습니다.

문서화

• 요구 사항을 구현하면서 코드만으로 표현이 어려운 부분은 주석으로 혹은 별도 문서로서 관리한다.

PR

• PR은 최대한 작게 쪼개어 올리되 테스트가 가능한 완전한 상태여야 한다.
• PR은 시스템에 의해 자동으로 테스트되며, 테스트에 통과하지 못하면 머지할 수 없다.
• PR은 반드시 코드 리뷰어의 승인을 받아야 한다.
• 스타일 가이드 툴이나 정적 분석 툴을 통해 코드 스타일을 자동으로 통일한다.
• PR에는 테스트 코드가 포함되어야 한다.

Branch 정책

• 브랜치는 master 브랜치 단일 브랜치 정책으로 가져가며 master 브랜치는 상시 release 가능한 상태로 유지된다.
• master 브랜치에서 별도 개발 브랜치를 생성하고 개발 후 PR을 올려 master 브랜치에 머지하는 것으로 Github Flow로 이해했다. (반면 흔히 많이 쓰이는 브랜치 전략으로 Git Flow가 있다.)

테스트/CI/CD

• 테스트 코드가 기본 문화로 잡혀있다.
• 강제 사항은 아니며 대신 다양한 캠페인 활동으로 테스트 코드 작성을 유도했다고 한다.
• 모든(?) PR이 테스트와 리뷰를 거쳐 머지되기 때문에 master 브랜치는 상시 배포 가능한 상태이다.
• 다시 말하면 하루에도 몇번이고 배포할 수 있으며, 이는 테스트가 든든하게 뒷받침해주기 때문에 가능하다.

테스트, 테스트 그리고 테스트

결국 내게 가장 크게 와닿았던 것은 바로 "테스트" 였습니다.
테스트 없이는 어느 것도 이야기하기 힘듭니다.

객관적으로 봐도 이 책은 테스트에 대해서만 무료 4개 챕터를 할애하고 있습니다.
게다가 테스트에 대한 이야기는 이 4개 챕터만으로도 끝나지 않죠.
코드 리뷰에서도 테스트는 기본 사항입니다.
문서 자료에서도 테스트는 좋은 문서로서 기능하죠.
그리고 CI/CD는 테스트를 전제로 합니다.

최근에는 실무에서 테스트 코드를 작성하는 경우를 종종 볼 수 있습니다.
하지만 아직도 대부분의 회사에서는 테스트 코드를 보기 어려울 겁니다.
테스트 코드 없이 과연 제대로 된 코드 리뷰, 문서화, CI/CD가 돌아갈까요?

이 책은 저 스스로 반성하는 계기가 되었습니다.
이제 실천에 옮기는 것만 남았네요.
실천에 옮기고 그 과정에서 경험하는 것들을 추후 포스팅으로 올리도록 하겠습니다.