[IT 도서리뷰📘] 구글 엔지니어는 이렇게 일한다 - 주요 내용 정리 1️⃣(1)

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

 

 

• 저자 : 타이터스 윈터스, 톰 맨쉬렉
• 출판사 : 한빛미디어
• 2022년 05월 출간

---

들어가며

아는 지인중에 구글에서 개발자로 일하시는 분이 있습니다. 그 분과 이야기를 나누다 보면 우리 기업과 같은 IT 기업인데도, 꽤나 다른 면이 많다는 것을 느끼곤 했었죠. 구글은 github도 쓰지 않고, 내부적으로 codeSearch 라는 검색엔진도 사용하는 등 완전히 그들의 효율성을 극대화할 수 있는 구글만의 세계를 직접 만들어 놓았더군요. 자급자족 정책을 성공적으로 마친 셈입니다. 이런 기술이나 문화들은 공개적으로 외부에 공개한 것들도 있지만, 내부자가 아니고서는 알 수 없는 사실들이 많습니다. 저는 그런 점들에 호기심이 많았고, 지인분이 얘기해주시는 것들 하나하나가 새롭고 흥미로웠습니다😄. 허나, 관계자들이랑 얘기 조금 나눈다고 해서 그들의 문화나 기술을 파악할 수 있을리가 없습니다. 듣는다고 해도 금방 잊어버리기 마련이죠.. 🥲  

 

이런 저에게 '구글 엔지니어는 이렇게 일한다' 는 관심을 안가질래야 안가질 수가 없는 책이었습니다. 관심이 있다보니, 꽤나 짧은 기간 안에 완독했던 것 같습니다.

 

---

목차

# PART I 전제
1. 소프트웨어 엔지니어링이란?

 

# PART II 문화
2. 팀워크 이끌어내기
3. 지식 공유
4. 공정 사회를 위한 엔지니어링
5. 팀 이끌기
6. 성장하는 조직 이끌기
7. 엔지니어링 생산성 측정하기

 

# PART III 프로세스
8. 스타일 가이드와 규칙
9. 코드 리뷰
10. 문서자료
11. 테스트 개요
12. 단위 테스트
13. 테스트 대역
14. 더 큰 테스트
15. 폐기

 

# PART IV 도구
16. 버전 관리와 브랜치 관리
17. Code Search
18. 빌드 시스템과 빌드 철학
19. Critique: 구글의 코드 리뷰 도구
20. 정적 분석
21. 의존성 관리
22. 대규모 변경
23. 지속적 통합
24. 지속적 배포
25. 서비스형 컴퓨트

 

(목차 출처: https://jybaek.tistory.com/959)

 

 

---

메모 및 Key Point ✨

제가 추후에 다시 읽어볼 용도로 정리해보았습니다. 생략된 내용이 매우 많으며, 제 주관적인 생각도 포함되어 있습니다.

 

 

프로그래밍과 소프트웨어 엔지니어링

 

소프트웨어 엔지니어링의 가장 중요한 요소는 사람이다.

 

확장 가능성의 중요성, 변경 비용이 시간 흐름보다 가파르게 상승하는 시스템은 확장가능하지 않다.

 

원점 회귀 (shift left) : 보안을 고려하는 시점을 왼쪽으로 이동시켜라. 취약점은 일찍 발견될 수록 처리하는 비용이 낮아진다.

 

 

마인드셋

 

화합, 사회적인 능력의 중요성

 

- 다른 사람과 얼마나 잘 협력하느냐가 중요하다.

- 피드백을 조기에 받을 수록 위험은 줄어든다.

- 개인의 지혜 < 공동의 지혜

- 겸손, 존중, 신뢰

- 집단적 자존심 : 팀의 성취와 자부심을 높이려고 노력해라.

 

포스트모템(postmortem)

 

실패한 근본 원인을 분석하여 문서로 남기는 것이 실수로부터 배우는 핵심이고, 이런것을 포스트모템 이라고 합니다.

이 책에서는 아래와 같은 제게 매우 인상적이었던 문구가 있었습니다.

실패는 선택이다. 가끔씩 실패하지 않는다면 충분히 혁신적이지 않거나 위험을 충분히 감수하지 않은 것이다.

 

실제로 조직이 성장하기 위해서는 팀원들이 '무언가를 시도하다 실패해도 안전하다' 라는 인식을 가질 수 있도록 하는 것이 매우 중요하다고 합니다. 함께 자라기에서도 계속해서 강조됐던 내용이죠?

https://programming119.tistory.com/237

[도서리뷰📘] 함께 자라기 - 애자일로 가는 길 🍀

 

이 내용들에 크게 공감한 저는, 감히 제 좌우명을 만들어보았습니다. 😄

'성공' 여부보다 '성장' 여부가 중요한 것이다.

 

---

지식 확장

이 책에서는 지식 확장에 대해 꽤나 자세히 다루는 데요,

 

조직의 지식을 확장하는 데에는 직접적으로 주입하는 오피스 아워(누군가 특정 주제에 관한 질문에 답해줄 목적으로 시간을 비워 둔 정기적 이벤트), 기술강연과 수업을 오픈하기 등의 방법을 설명하고 있습니다.

 

기타 지식 공유에 중요한 요소들에는 '존중', '상냥함', '지식 공유의 문화' 등이 있습니다.

 

구글에는 가독성 인증 프로세스 라는 것이 존재해서 가독성 자격증을 받은 엔지니어의 검증을 거쳐야 코드가 커밋될 수 있다고 합니다.

 

---

문서화

문서자료(문서화)  또한 조직내 지식을 관리하는 데에 매우매우 중요한 요소입니다. 이 책에서도 꽤나 자세히 다루고 있어요. 저희 팀은 아직도 이 팀의 문서화 정책을 어떻게 가져갈지 고민하고 논의하고 있답니다. 그만큼 중요하고 어려운 부분이죠.

 

구글의 문서화

문서자료를 코드처럼 취급하여 엔지니어링 ㅍ워크플로에 통합

 

구글은 g3doc이라는 소스코드와 함께 문서자료를 관리하는 방법을 사용하는데요, 실제 소스코드와 유사하게 문서자료를 관리하고 변경사항이 생긴다면 소스코드와 마찬가지로 리뷰와 피드백을 거친 뒤에 커밋된다고 합니다. 그리고 전사적으로 go/링크 라는 서비스를 이용해서 주소창에서 바로바로 궁금한 정보를 검색한다고 합니다. 

 

문서화에 대한 나의 생각

 

여기서 느낄 수 있는 문서화와 지식공유의 중요한 요소는 '피드백' 여부인 것 같습니다. 저희 팀은 팀 내 문서를 소스코드와는 별개의 플랫폼으로 관리하다보니, 작업하면서 접하게 될 일도 줄어들고, 변경하더라도 팀원들에게 알림이 가지 않아 피드백을 받을 수 있는 기회가 적습니다. 그러다보니 문서화가 다소 부족해지고 문제가 생기더군요.. 그리고 '보상과 인정' 또한 굉장히 중요한 부분인 것 같습니다. 소스코드의 변경은 그 자체로 '일' 이자 '성과' 이다보니까, 보상과 인정이 자연스럽게 주어지고 이는 의욕이 되고 동기부여가 되는데, 문서화는 그렇지 않죠. 문서화도 소스코드 만큼 중요한 요소인 만큼 '보상' 혹은 '인정'을 받을 수 있는 시스템이 필요한 것 같습니다.

 

---

생산성 측정

생산성은 대충 뭉뚱그려 판단하는 것이 아니라 반드시 데이터를 기반으로 측정해야 한다. 이 점은 이제 IT 뿐만 아니라 모든 비즈니스 들에서도 다 공감하는 말일 것 같습니다. 그만큼 데이터 과학의 중요성이 대두되고 있죠. 하지만 데이터 기반으로 측정하기 위해서는 '어떠한 지표를 설정할 것인가?' 또한 매우 중요하고 어려운 일입니다. 그렇기 때문에 구글에서는 지표 선정 자체에도 힘을 많이 쏟는다고 합니다.

 

GSM 프레임워크

 

구글은 지표를 설정하는 데에 있어, GSM 이라는 프레임워크를 사용한다고 합니다.

가장 먼저 목표(원하는 최종 결과)를 세우고, 신호(최종 결과를 이루었는지 판단하는 방법)를 정한 다음, 마지막으로 지표를 만드는 순서를 통해 가로등 효과를 막아준다고 합니다. 중요한 저점은 추적 가능성을 잃지 않고 각각의 지표로부터 관련 신호를 찾아내고 나아가 그 신호가 대변하는 목표에까지 거슬러 추적할 수 있어야 한다고 합니다. 그래야만 어떤 지표가 무엇을 측정하고, 왜 측정하는지 알 수 있으니까요.

 

이 책에서는 각각의 단계에 대해 더 자세하게 설명하고 있습니다. 이는 생략할게요.

 

---

코드리뷰

구글은 크리틱 이라는 코드리뷰 도구를 쓴다고 합니다.

프리커밋 리뷰 (코드베이스에 커밋 전에 리뷰를 받음) 방식을 쓰고, 메일로 리뷰를 요청하고 코멘트는 별개로 받는 등 우리 조직보다 코드 리뷰 파이프라인이 더 깐깐합니다. 그 뿐만 아니라 코드 소유자의 승인과 가독성 승인 여부 또한 필요합니다.

 

코드를 변경할 때의 중요한 점들

- 변경의 크기를 작게 만들기

- 변경 설명의 첫 줄은 어떤 종류의 변경인지를 잘 요약

- 관련 테스트도 함께 수정

 

---

테스트

최근, 테스트의 중요성은 언제 어디서나 강조되고 있습니다. 테스트가 배포 전 안정성을 주는 것 뿐만 아니라, 테스트를 작성하는 행위 자체가 시스템의 설계도 개선해주고, 작성과 동시에 검토를 하는 역할도 하며, 읽는 사람으로 하여금 일종의 문서로 쓰일 수도 있습니다.

 

하지만 조심해야 할 점도 있습니다.

테스트는 엔지니어에게 신뢰를 줄 때만 가치가 있다는 사실을 잊지 마세요. 테스트가 생산성을 떨어트리고 고칠 게 계속 나오거나 결과를 믿을 수 없다면 엔지니어들은 더 이상 테스트를 신뢰하지 않고 우회 방법을 찾으려 할 것입니다. 나쁜 테스트 스위트는 테스트가 아예 없는 것만 못합니다.

 

솔직히 말하자면, 저희 조직은 현재 테스트가 원할하게 돌아가지 못하고 있는 상태입니다. 위와 같은 상황에 직면한 것 같습니다 ㅠ 

이런 상황 자체를 대대적으로 개선하는게 필요할 것 같은데, 선뜻 나서기가 쉽지가 않습니다. 많은 고민이 필요하겠네요...

 

구글의 테스트

 

구글은 모든 테스트를 크기 기준으로 분류한다고 합니다. 크기가 클 수록, 환경이 복잡해지는 것을 허용(외부 시스템 및 여러 대의 기기 사용 가능)하는 테스트라고 가정하고, 최대한 작게 테스트를 가져가려고 한다고 합니다. 테스트는 밀폐될수록 관리하기도 쉽고, 의도대로 동작하니까요.

 

테스트의 범위로도 나뉘는데, 관련된 좋은 블로그 글이 있네요.

https://mparchive.tistory.com/182

[Testing] 테스트 피라미드를 통해 테스팅의 세가지 범주 살펴보기

 

테스트를 작성할 때 주의할 점

 

- 테스트 이름은 매우 중요하다. 테스트의 이름을 지을 때 신중하게 성의있게 짓자.

- 메서드가 아니라 행위 를 테스트해야한다. 행위가 부각되게끔 테스트를 작성하자.

- 테스트 코드에서는 스마트한 로직보다 직설적인 코드가 좋다.

- 기대한 상태와 실제 상태를 명확히 구분해서 출력하도록 하고, 결과가 만들어진 맥락 정보도 제공하돌고 하자.

- DRY(Don't Repeat Yourself) 대신에 DAMP(Descriptive And Meaningful Phase)

 

 

---

폐기

이 책에서 '폐기' 는 낡은 시스템을 완전히 걷어내는 것을 의미합니다.

가치를 만들어 내는 것은 '코드'가 아니라 '기능' 이며 다시말하자면 코드는 자산이 아니라 부채 입니다.

 

'권고 폐기'와 '강제 폐기' 로 나뉩니다.

 

권고 폐기

 

기한이 없고 조직에서도 우선순위가 높지 않은 케이스. 강제성이 없고, 기능과 안정성 모두 정식 서비스가 가능한 수준에 올라섰을 때 시행해야합니다. 새로운 시스템이 사용자에게 주는 혜택이 클 때 효과가 좋으며, 이 혜택은 혁신적인 수준이어야 합니다. 하지만 사용자들의 방향을 원하는 쪽으로 유도하는 것 뿐이지 모두가 의도대로 따라줄 것이라고 생각하면 안됩니다.

 

강제 폐기

 

시스템의 지원 종료일을 못 박는 형태. 이 경우, 전담하는 팀을 하나 따로 꾸리는 것이 좋습니다. 정치적인 반대에 직면할 수 있고, 따라서 정책적으로 뒷받침되어야 합니다. 고객들은 이런식의 폐기를 지원 없이 주어지는 의무로 부정적으로 받아들일 수 있으므로 조심해야 합니다. 몇 주 혹은 몇 달 전에 점진 적인 일시 중지 일정을 계획해서 공표하면 좋습니다. (인터넷 익스플로러 케이스를 생각해보면 좋겠네요! 😄)

 

경고 메시지에는 실행 가능성 과 적시성 이 매우 중요합니다. 관련 동작을 수행할 때 경고가 뜨도록 해야하고, 평균적인 엔지니어가 이론적으로 뿐만 아니라 실직적으로 조취가 가능해야 합니다.

 

또한, 폐기가 진행중인 케이스에 대해 퇴행이 되지 않도록 신경써야 합니다. (예 : @deprecated 같은 애너테이션을 추가 해두어서, 이러한 폐기 심볼이 있는 코드를 재사용하지 않는다.)

 

---

버전관리

 

구글은 자체 개발은 트렁크 기반의 중앙집중형 VCS인 Piper 를 사용한다고 합니다. 동시 커밋을 지원하며, 수천명의 엔지니어가 매일 내뿜는 커밋 뿐만 아니라 매일 6~7만건의 반자동 프로세스의 커밋들까지 받아들인다고 합니다. 엄청나게 거대한 모노리포 방식이죠.

 

그리고 버전관리에 있어서는 원-버전 을 가져간다고 합니다. 의존성 문제를 최대한 줄이기 위한 선택이죠.

 

브랜치는 '트렁크 기반 개발' 방식이 좋다고 여겨지고 있으며, 그리고 장기간 유지되는 개발 브랜치가 적을 수록 좋다고 합니다. 오래된 개발 브랜치는 병합하는 과정에 있어서 안정성이 매우 떨어지기 때문이죠.

 

 

---

2부에서 이어집니다.

---