프로그래밍에 대한 관심이 높다.
각종 언어나 방법에 대한 일반인의 지대한 관심은 익히 알 수 있다.
그러나 현업 개발자들이 가장 많이 궁금하고 필요로 하는 것은 '소프트웨어 엔지니어링'이다.
보다 더 나은 코딩, 개발환경, 문화..
이런 것에 대한 치열한 고민을 하고 있다.
이 책 '구글 엔지니어는 이렇게 일한다'는 그에 대한 좋은 가이드가 되어 줄 것이다.

이 책의 저자들은 세계 최고의 소프트웨어 그룹 중 하나인 구글에서 일하였다.
그곳서 얻은 소프트웨어 엔지니어링을 방법을 이 책에 담고 있다.
구글에서 개발에 대한 '문화', '프로세스', '도구'에 대해 보여주고 있다.

소프트웨어 엔지니어링이란 '흐르는 시간 위에서 순간순간의 프로그래밍을 모두 합산한 것이다.'

소프트웨어 엔지니어링이란 개념에 막막하게 느껴질 수도 있다.
개발에 대한 모든 것이 소프트웨에 프로그래밍이라 생각하면 쉽게 정리할 수 있을까?

• 시간과 변경 : 코드가 수명을 다할 때까지 새로운 요구사항에 잘 적응하려면 어떻게 해야 하는가?
• 규모와 성장 : 커져가는 규모에 발맞춰 조직은 어떻게 진화해야 하는가?
• 트레이드오프와 비용 : '시간과 변경', '규모와 성장'에서 얻은 교훈들을 바탕으로 조직은 어떻게 의사결정을 내려야 하는가?

이것이 이 책을 통해 우리가 배울 수 있는 것들이다.
흔히 개발에 대해 '새로운 것을 만들어 내기 위한 것'을 말한다.
그것을 위한 최적의 프로그래밍 언어, 시스템, 코딩에 대해서 생각한다.
하지만 그 다음을 생각한다면 결코 그것의 최적이 아닐 수 있다.
변경은 어떻게 할 것이며, 서비스가 확장되면 어떻게 처리할 것인지, 분리와 폐기는 용이한 것인지...
다양한 것에 대해 생각하고 분석하고 적용해야 한다.

어떻해 팀을 만들고, 운영하는지,
그 팀과 함께 일하기 위한 좋은 개발 환경-코딩 가이드, 테스트-는 어떻게 만들어야 하는지,
버전 관리와 배포, 통합은 어떻게 운영하는 것이 좋은지를 볼 수 있다.
개발자들이 그리 좋아하지 않는 문서화에 대한 언급도 무척 좋았다.

이 책으로 프로그래밍에 대한 도움을 얻고자 한다면 실망할 수 있다.
이 책은 '프로그래밍'이 아닌 '소프트웨어 엔지니어링'에 대한 책이다.
개발에 대한 책이지만 코딩에 대한 언급은 물론이고, 코드도 부가적인 설명을 위해 쓰이고 있을 뿐이다.

세계적인 그룹으로 성장했기 구글의 문화, 프로세스, 도구가 모두 옳다고 말하고 싶지 않다.
하지만 그들의 성장 동력 중 하나였음은 분명하고 그것을 이렇게 한 권의 책을 통해 쉽게(?) 접할 수 있음은 무척 큰 행운이다.
구글과 지금의 회사와 같지 않기에 똑같이 적용하기에는 무리가 있을 수도 있다.
하지만 분명 바로 도입하고 적용할 수 있는 것도 있을 것이다.

[한빛미디어 ＜나는 리뷰어다＞ 활동을 위해서 책을 제공받아 작성된 서평입니다.]

IT 분야에서는 일하는 사람이라면 누구나 꿈꾸는 기업 "구글"입니다.

구글이 바라보는 개발자와 개발 문화에 대해 관심이 있더 차에 "구글 엔지어는 이렇게 일한다"를 보게 되었습니다.

이책은 구글이 소프트웨어 엔지이어링을 바라보는 주된 시각에 따라 이 책의 주제를 아래 세가지로 나누었습니다.

• 문화

• 프로세스

• 도구

구글의 문화는 독특하지만 구글이 엔지니어링 문화를 발전시키는 깨우친 교훈들을 폭넓게 적용할 수 있을 것입니다.

1부는 조직 혹은 개별 프로그래머를 위한 정책, 모범 사례를 평가하고 정의하는 방법, 관리 가능한 소프트웨어로 만들어주는 도구와 기술 관련 모든 주제에 대해서 다룹니다.

문화를 다루는 2부(2~7장)는 소프트웨어 기업이 갖는 집단적 본성, 쉽게 말해 소프트웨어 개발은 팀에 의해 이루어지므로 조직이 성장하고 건실하게 유지되려면 개발 문화 면에서도 올바른 원칙이 꼭 필요하다는 점을 강조합니다.

3부에서 소개하는 기법 대부분은 대다수 소프트웨어 엔지니어에게 익숙한 내용일 것입니다. 3부에서는 구글이 버터낸 시간과 규모에서 효과적으로 작동한 프로세스들을 소개합니다.

4부는 끊임없이 커져가고 나이를 먹는 코드베이스를 말끔하게 관리하기 위해 구글이 도구 인프라에 어떻게 투자해왔는지를 이야기합니다. 구글에 한정된 도구도 있지만 가능한 한 대체할 수 있는 오픈 소스 도구나 서드파티 도구에 대해서도 소개합니다.

목차

[Part I 전제]

CHAPTER 1 소프트웨어 엔지니어링이란?

1.1 시간과 변경

1.2 규모 확장과 효율성

1.3 트레이드오프와 비용

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

1.5 마치며

1.6 핵심 정리

[Part II 문화]

CHAPTER 2 팀워크 이끌어내기

2.1 내 코드를 숨기고 싶어요

2.2 천재 신화

2.3 숨기는 건 해롭다

2.4 모든 건 팀에 달렸다

2.5 마치며

2.6 핵심 정리

CHAPTER 3 지식 공유

3.1 배움을 가로막는 장애물

3.2 철학

3.3 판 깔아주기: 심리적 안전

3.4 내 지식 키우기

3.5 질문 확장하기: 커뮤니티에 묻기

3.6 지식 확장하기: 누구나 가르칠 게 있다

3.7 조직의 지식 확장하기

3.8 가독성 제도: 코드 리뷰를 통한 표준 멘토 제도

3.9 마치며

3.10 핵심 정리

CHAPTER 4 공정 사회를 위한 엔지니어링

4.1 편견은 피할 수 없다

4.2 다양성이 필요한 이유 이해하기

4.3 다문화 역량 갖추기

4.4 다양성 실천하기

4.5 단일한 접근 방식 거부하기

4.6 확립된 프로세스에 도전하기

4.7 가치 vs 결과

4.8 관심을 잃지 말고 전진하자

4.9 마치며

4.10 핵심 정리

CHAPTER 5 팀 이끌기

5.1 관리자와 테크 리드(혹은 둘 다)

5.2 개인 기여자에서 리더로

5.3 엔지니어링 관리자

5.4 안티패턴

5.5 올바른 패턴

5.6 예상 못한 질문

5.7 그 외 조언과 요령

5.8 사람은 식물과 같다

5.9 마치며

5.10 핵심 정리

CHAPTER 6 성장하는 조직 이끌기

6.1 늘 결정하라(Always Be Deciding)

6.2 늘 떠나라(Always Be Leaving)

6.3 늘 확장하라(Always Be Scaling)

6.4 마치며

6.5 핵심 정리

CHAPTER 7 엔지니어링 생산성 측정하기

7.1 엔지니어링 생산성을 측정하는 이유

7.2 선별: 측정할 가치가 있는가?

7.3 GSM 프레임워크: 목표와 신호를 뒷받침하는 의미 있는 지표 선정하기

7.4 목표(goal)

7.5 신호(signal)

7.6 지표(metric)

7.7 데이터로 지표 검증하기

7.8 조치를 취하고 결과 추적하기

7.9 마치며

7.10 핵심 정리

[Part III 프로세스]

CHAPTER 8 스타일 가이드와 규칙

8.1 규칙이 필요한 이유

8.2 규칙 만들기

8.3 규칙 수정하기

8.4 지침

8.5 규칙 적용하기

8.6 마치며

8.7 핵심 정리

CHAPTER 9 코드 리뷰

9.1 코드 리뷰 흐름

9.2 코드 리뷰 @ 구글

9.3 코드 리뷰의 이점

9.4 코드 리뷰 모범 사례

9.5 코드 리뷰 유형

9.6 마치며

9.7 핵심 정리

CHAPTER 10 문서자료

10.1 문서자료란?

10.2 문서자료가 필요한 이유

10.3 문서자료는 코드와 같다

10.4 독자를 알라

10.5 문서자료 유형

10.6 문서자료 리뷰

10.7 문서화 철학

10.8 테크니컬 라이터가 필요한 순간

10.9 마치며

10.10 핵심 정리

CHAPTER 11 테스트 개요

11.1 테스트를 작성하는 이유

11.2 테스트 스위트 설계하기

11.3 구글 규모의 테스트

11.4 구글의 테스트 역사

11.5 자동 테스트의 한계

11.6 마치며

11.7 핵심 정리

CHAPTER 12 단위 테스트

12.1 유지보수하기 쉬워야 한다

12.2 깨지기 쉬운 테스트 예방하기

12.3 명확한 테스트 작성하기

12.4 테스트와 코드 공유: DRY가 아니라 DAMP!

12.5 마치며

12.6 핵심 정리

CHAPTER 13 테스트 대역

13.1 테스트 대역이 소프트웨어 개발에 미치는 영향

13.2 테스트 대역 @ 구글

13.3 기본 개념

13.4 테스트 대역 활용 기법

13.5 실제 구현

13.6 속이기(가짜 객체)

13.7 뭉개기(스텁)

13.8 상호작용 테스트하기

13.9 마치며

13.10 핵심 정리

CHAPTER 14 더 큰 테스트

14.1 더 큰 테스트란?

14.2 더 큰 테스트 @ 구글

14.3 큰 테스트의 구조

14.4 더 큰 테스트 유형

14.5 큰 테스트와 개발자 워크플로

14.6 마치며

14.7 핵심 정리

CHAPTER 15 폐기

15.1 폐기시키는 이유

15.2 폐기는 왜 그리 어려운가?

15.3 폐기 유형

15.4 폐기 프로세스 관리

15.5 마치며

15.6 핵심 정리

[Part IV 도구]

CHAPTER 16 버전 관리와 브랜치 관리

16.1 버전 관리란?

16.2 브랜치 관리

16.3 버전 관리 @ 구글

16.4 모노리포(단일 리포지터리)

16.5 버전 관리의 미래

16.6 마치며

16.7 핵심 정리

CHAPTER 17 Code Search

17.1 Code Search UI

17.2 구글 개발자가 Code Search를 이용하는 방법

17.3 독립된 웹 도구로 만든 이유

17.4 규모가 설계에 미치는 영향

17.5 구글은 어떻게 구현했나?

17.6 구글이 선택한 트레이드오프

17.7 마치며

17.8 핵심 정리

CHAPTER 18 빌드 시스템과 빌드 철학

18.1 빌드 시스템의 목적

18.2 빌드 시스템이 없다면?

18.3 모던 빌드 시스템

18.4 모듈과 의존성 다루기

18.5 마치며

18.6 핵심 정리

CHAPTER 19 Critique: 구글의 코드 리뷰 도구

19.1 코드 리뷰 도구 원칙

19.2 코드 리뷰 흐름

19.3 1단계: 변경 생성

19.4 2단계: 리뷰 요청

19.5 3~4단계: 변경 이해하고 댓글 달기

19.6 5단계: 변경 승인(변경에 점수 매기기)

19.7 6단계: 변경 커밋

19.8 마치며

19.9 핵심 정리

CHAPTER 20 정적 분석

20.1 효과적인 정적 분석의 특징

20.2 정적 분석을 적용하며 깨우친 핵심 교훈

20.3 Tricorder: 구글의 정적 분석 플랫폼

20.4 마치며

20.5 핵심 정리

CHAPTER 21 의존성 관리

21.1 의존성 관리가 어려운 이유

21.2 의존성 임포트하기

21.3 (이론상의) 의존성 관리

21.4 유의적 버전의 한계

21.5 자원이 무한할 때의 의존성 관리

21.6 마치며

21.7 핵심 정리

CHAPTER 22 대규모 변경

22.1 대규모 변경이란?

22.2 누가 대규모 변경을 처리하나?

22.3 원자적 변경을 가로막는 요인

22.4 대규모 변경 인프라

22.5 대규모 변경 프로세스

22.6 마치며

22.7 핵심 정리

CHAPTER 23 지속적 통합

23.1 지속적 통합이란?

23.2 지속적 통합 @ 구글

23.3 마치며

23.4 핵심 정리

CHAPTER 24 지속적 배포

24.1 지속적 배포 이디엄 @ 구글

24.2 속도는 팀 스포츠다: 배포를 관리 가능한 조각으로 나누기

24.3 변경을 격리해 평가하자: 기능 플래그로 보호하기

24.4 기민해지기 위한 분투: 릴리스 열차 갖추기

24.5 품질과 사용자에 집중: 사용할 기능만 배포하자

24.6 원점 회귀: 데이터에 기초해 더 일찍 결정하자

24.7 팀 문화 바꾸기: 배포 규율 세우기

24.8 마치며

24.9 핵심 정리

CHAPTER 25 서비스형 컴퓨트

25.1 컴퓨트 환경 길들이기

25.2 관리형 컴퓨트에 적합한 소프트웨어 작성하기

25.3 시간과 규모에 따른 CaaS

25.4 컴퓨트 서비스 선택하기

25.5 마치며

25.6 핵심 정리

마치며

- 20년 넘게 수만명의 구글러가 쌓아온 노하루를 이 책한권으로 습득할 수 있습니다.

이제 더 이상 소프트웨어 엔지니어링은 단순히 조직을 효과적으로 운영하는 방법에 그치지 않을 것입니다. 이 책에서는 반드시 알아야 할 프로그램을 효과적으로 짜는 방법은 물론, 코드베이스를 지속 가능하고 건실하게 만들어주는 엔지니어링 스킬에 대해 모두 소개합니다.

좋은 개발자가 되고 싶은 분들에게 방향성을 제시해줄 책입니다. 품질 좋은 소프트웨어를 개발하고 싶거나 구글의 소프트웨어 관리 방법이 궁금한 모든 분들에게 좋은 안내서가 되어 줄 것입니다.

이번에 리뷰를 하게 된 책은 “구글 엔지니어는 이렇게 일한다’, 원제는 “Software engineering at google” 입니다.

한글 제목만을 보면 흔히 들어왔던 구글의 고속도로 변의 광고판을 이용해서 신규 직원 채용한 이야기, 구글 직원을 위한 25가지 복지 혜택이 구글 직원들의 업무 성과를 높여주는 것에 대한 이야기, 하루의 대부분을 다른 일을 하는 것 같지만 시간에 맞춰서 결과물을 만들어 내는 기인(奇人)들이 모여서 일을 하는 것이나 유사한 이야기가 아닐까? 라는 생각을 할 수도 있습니다. 저도 책의 목차를 보고 읽기 시작하다 다시 원제를 확인해보니 이 책은 “구글의 직원들이 일을 하는 방법’에 대한 책이 아닌 “구글의 직원들이 소프트웨어를 개발/유지/보수” 하는 것에 대한 책이라는 것을 확인할 수 있었던 것이지요.

이렇 듯 언제 인가부터 번역서를 보면 그 책의 원래 제목을 찾아 보는 습관이 생겼습니다.  여태껏 이런저런 책들을 보다 보니 가끔은 책을 돋보이게 하기 위해 수정한 제목이 그 책에서 말하고자 하는 가장 중요한 ‘본질’을 흐리는 경향이 있다는 것입니다. 그래서 원서의 원래 제목을 찾아보거나 원제를 다시 한번 생각해 보는 것이 습관이 되어 버렸습니다.

이제 책의 내용을 잠시 살펴보겠습니다.

이 책은 파트 1 서론을 제외하고 크게 3부분으로 구성되어 있습니다. 

파트 2에서는 Software Engineering을 위한 회사의 문화에 대해서 설명하고 있습니다. 2장 팀워크 이끌어 내기, 3장 지식 공유…  관리직에 있다면 파트 2는 반드시 읽어야 할 부분입니다.

이 책의 파트 2를 보다 보니 자신이 잘 모르는 것을 숨기기 위해서 의견을 내면 무시 하면서도 “알아서 일해야 하지 않나..”, “시키는 대로 해라” 는 말로 팀을 이끌어 나가는 이사, 새로운 것 임에도 자신이 아는 것에 억지로 끼워 맞춰가면서 자신이 알고 있던 문제점이 새로운 것도 있다고(있을 것이다 도 아니고 있다고) 똥고집을 부리던 대표가 있는 회사가 생각납니다.

회사에서 새로운 문화를 만드는 것은 쉽지 않습니다. 특히나 대표나 몇몇 핵심 인력이 회사를 좌지우지 할 때는 말이지요. 그런 분들이 이 책의 파트 2를 봐야 하는데 문제는 그런 분들은 이런 책을 절/대/로/ 보지 는다는 것이 더 큰 문제입니다. 아랫사람이 말을 하면 이해도 못하면서 아는체 해야 하니 말입니다.

또 다른 경험으로 공동 작업을 하면서도 제대로 문서와 및 자료 교환이 되지 않아서 초당 8번 이상 데이터를 갱신해야 할 장비 개발해야 함에도 5초에 한 번 데이터를 갱신하도록 만들어서 들고 오는 연구소도 있었습니다.  이 책의 파트 2에 나오는 ‘기술 공유’나 파트 3의 ‘문서화’만 살펴봐도 이런 결과는 나오지 않았을 텐데 말입니다.

파트 3은 소프트웨어를 만들고 테스트하는 방법에 대한 설명에 대해서 이야기를 하고 있습니다. 처음 문서화 부분 이외엔 실제로 코드를 작성하고 테스트를 진행해 본 적이 없다면 조금은 지루하고 JAVA 에 익숙하지 않은 사람은 파트 3의 반 이상이 제대로 이해가 안될 부분도 있습니다. 하지만 이 책의 저자가 하는 이야기의 주제와 핵심은 분명합니다. 코드를 작성할 때 제대로 된 테스트가 필요하고 코드는 유지 보수가 쉽게, 그리고 테스트는 다양하고 깊게. 이 책의 모든 테스트 기법을 적용할 수 없더라도 이 책에서 말하고자 하는 바를 가끔씩 떠올리며 코딩을 한다면 분명히 이후에 도움이 될 내용들입니다.

파트 4에는 구글에서 사용하는 소스 관리 및 분석 툴에 대한 소개인데 이런 관리 분석 툴들을 다 적용하는 것은 불가능 할 수도 있고 시간이 걸리는 일입니다. 구글도 20년에 걸쳐서 지금의 방식으로 계속 개선되어 왔기 때문입니다.

이 책을 보고 나니 제가 회사를 다니다 혼자서 일을 시작한 지 얼마 되지 않았지만 이상하게 SE를 위한 문화를 만들어가는 이 책의 파트 2에 더 많은 공감을 느끼게 됩니다. 이건 혼자 일을 하지만 이전의 회사에서 절실하게 느꼈던 문제점에 대한 경험 때문일 수도 있고 이런 문화는 앞으로 새로운 고객과 일을 할 때 필요한 내용들이기 때문일 겁니다.

이 책의 파트 3의 내용의 많은 부분이 공감이 가지만 지금 12000 라인이 넘어가는 코드에 적용은 아무래도 힘들 것 같습니다. 지금 잘못 적용하다가 어떤 일이 벌어질 지 모르니 말입니다.  늦은 느낌은 있지만 그래도 최근 다시 시작한 각종 함수/구조체의 문서 작업은 이 책의 내용을 참고해서 다른 사람이 보는 것을 염두에 두고 고쳐 쓰기 시작했습니다. 이전에도 나만 본다고 문서화를 해 놓고 나중에 봤을 때 기억이 안 나거나 헷갈리는 부분들이 있었기 때문입니다. 잠시 잊고 있었는데 이 책을 보고 다시 기억을 떠올리게 되는군요.

개인적으로 이 책은 상당히 도움이 되는 책이라고 봅니다. 그렇다면 이 책은 누가 읽어야 할까요? 저 같은 개발자? 소프트웨어 개발 회사? 제가 보기엔 이 책은 소프트웨어 개발 만이 아니라 제대로 된 장비나 어느 정도 미래를 보고 계속 개발하는 회사의 임원들과 개발 담당하는 분들이라면 다 읽어야 할 것 같습니다. 한권을 사서 서로 읽는 부분을 나눠서 라도 말이지요.

나는 하드웨어를 만드는데 이 책은 SE 다..

나는 전자가 아니고… 

나는 개인 개발자…

가끔은 자신의 게으름을 무마하기 위해서 저런 식으로 이야기를 하는 사람들이 많습니다.  하지만 구지 소프트웨어 분야가 아니더라도, 구글에서 일하지 않더라도 이 책을 한 번 읽어 보기를 권하고 싶습니다.

구글은 예전에는 검색 엔진으로 시작해서 브라우저를 만들고 OS를 만들고 SW를 만들고 언제 인가부터 스마트 폰까지 만들어 왔습니다. 이런 회사에서는 이 SE 방법을 소프트웨어 개발에만 적용하지는 않습니다.  비록 이 책을 쓴 저자가 SE(software engineering) 분야를 예로 들어 이야기하더라도 말입니다. 

무엇이던 배우고자 하는 사람들이 있다면 틈을 내서 책을 읽으면서 필요한 지식들을 얻을 수 있겠지만, 자신의 게으름을 덮고자 하는 사람들을 “왜 책을 읽나요“ 라는 이야기로 자신의 게으름을 덮으려고 하더군요. “아침에 SNS나 유튜브에서 본 단편적인 정보들은 진정한 지식이 될 수 없기 때문입니다”(책 “무엇이 과연 진정한 지식인가” 에서 인용)

이 책이 비록 두께가 제법 되고 많은 내용을 상세히 설명하고 있지만, 읽으면서 필요한 부분을 잘 선택하는 것도 능력입니다. 매번 몇 줄로 요약된 보고서만 받아보고 카톡으로 의미가 모호한 지시만 내리거나 카톡으로 자료 교환을 하는 회사라면, 회의 하기 전 회의 주제도 모르고 준비도 없는 회의를 해온 회사라면 더욱 더 이런 책을 봐야 할 것 같습니다. 과연 어떤 것이 제대로 된 문서인지 자료인지 그리고 정보교환이지를 알기 위해서라도 말이지요.

이만 리뷰를 마칩니다.

 "한빛미디어 ＜나는 리뷰어다＞ 활동을 위해서 책을 제공받아 작성된 서평입니다."