확장메뉴
주요메뉴


소득공제 베스트셀러
미리보기 공유하기

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

: 구글러가 전하는 문화, 프로세스, 도구의 모든 것

리뷰 총점9.6 리뷰 23건 | 판매지수 49,839
베스트
IT 모바일 23위 | 국내도서 top100 1주
명화를 담은 커피, 가을을 닮은 책 - 명화 드립백/명화 캡슐 커피/명화 내열 유리컵+드립백 세트/매거진 랙
[IT 기획전] IT, 모두의 교양
9월의 얼리리더 주목신간 : 웰컴 투 북월드 배지 증정
[대학생X취준생] 꼭 공부를 해야 할 상황이라면? 2학기, 공부할 결심!
박해선 저자의 머신러닝/딥러닝 패스
[단독]『혼자 공부하는 파이썬』 개정판 출간
직장인을 위한 업무 단축 필살기! 길벗 무따기 오피스
내일은 개발자! 코딩테스트 대비 도서전
[단독] 에듀윌 IT 자격증 기획전 - 가장 빠른 합격출구 EXIT
9월 전사
쇼핑혜택
1 2 3 4 5

품목정보

품목정보
출간일 2022년 05월 10일
쪽수, 무게, 크기 704쪽 | 1325g | 183*235*40mm
ISBN13 9791162245620
ISBN10 116224562X

이 상품의 태그

책소개 책소개 보이기/감추기

구글은 어떻게 개발하고 코드를 관리하는가

지난 50년의 세월과 이 책이 입증한 사실이 한 가지 있다. 바로 '소프트웨어 엔지니어링의 발전은 결코 정체되지 않는다'라는 것이다. 빠른 기술 변화 속에서 소프트웨어 엔지니어링의 중요성이 더욱 강조되면서 소프트웨어 엔지니어의 역할은 점점 더 확장될 것이다. 이제 더 이상 소프트웨어 엔지니어링은 단순히 조직을 효과적으로 운영하는 방법에 그치지 않을 것이다. 이 책에서는 여러분이 궁금해하고, 반드시 알아야 할 프로그램을 효과적으로 짜는 방법은 물론, 코드베이스를 지속 가능하고 건실하게 만들어주는 엔지니어링 관행까지 모두 소개한다. 이 책 한 권이면 소프트웨어 엔지니어링 프로세스를 완벽하게 익히고 좋은 제품을 남들보다 빠르게 구현할 수 있게 된다. 또한 20년 넘게 수만 명의 구글러가 쌓아온 노하우도 습득할 수 있다. 품질 좋은 소프트웨어 제품을 신속하게 개발하고 싶거나 구글의 소프트웨어 관리 방법이 궁금한 모든 이에게 훌륭한 안내서가 되어줄 것이다.

목차 목차 보이기/감추기

[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 핵심 정리

저자 소개 (4명)

출판사 리뷰 출판사 리뷰 보이기/감추기

구글러가 공개하는 기업에 혁신을 가져다주는 엔지니어링 전략

여러분이 또 하나의 거대한 소프트웨어 엔지니어링 기업 ‘구글’을 만들 필요는 없습니다. 다만 구글이 그간 쌓아온 숱한 노하우를 모른다면, 여러분은 수만 명의 엔지니어가 20년 넘게 조화를 이뤄 다듬어온 소프트웨어 엔지니어링의 지식을 놓치게 됩니다. 모른 척하기에는 너무도 값진 지식일 것입니다. 이 책에서는 구글의 소프트웨어 엔지니어와 테크니컬 라이터가 뭉쳐 구글의 독창적인 엔지니어링 문화, 프로세스, 도구를 소개합니다. 단순히 도구의 기능과 활용법을 넘어 구글의 팀들이 따르는 철학과 프로세스까지 아주 상세히 설명합니다. 또한 프트웨어 조직이 코드를 설계, 작성, 유지 관리할 때 절대 잊어서는 안 되는 세 가지 기본 원칙도 함께 살펴봅니다. 이 책에 담긴 수만 명의 구글러가 여러 시행착오 끝에 검증한 실전 대응 기법이 적용된 다양한 사례와 예제로, 소프트웨어 엔지니어링의 핵심을 꿰뚫어보는 시각을 얻어 훌륭한 엔지니어로 거듭나길 바랍니다.

추천평 추천평 보이기/감추기

경험이 있는 개발자는 프로그래밍과 소프트웨어 엔지니어링이 다르다는 것을 압니다. 집중한 머리는 비트와 춤을 추고, 눈은 모니터 화면을 응시하고, 손은 키보드를 두드리는 게 프로그래밍입니다. 그렇다면 소프트웨어 엔지니어링은 무엇일까요? 이 질문에 대한 답은 이 책에서 찾을 수 있습니다. 구글 개발자 특유의 풍성하고, 깊고, 날카로운 사고를 담은 이 책을 좋은 개발자로 성장하고 싶은 모든 이에게 권합니다.
- 임백준 (삼성리서치)

이 책은 구글이 지금의 자리까지 이르게 하는 데 가장 큰 이바지를 한 소프트웨어 엔지니어들이 구글에서 실제로 어떻게 일하고 있는지 알려줍니다. 그래서 소프트웨어 엔지니어링과 관련된 문화, 프로세스, 도구들에 대한 고찰을 통해 고품질의 소프트웨어를 효과적으로 개발하는 데 필요한 통찰을 얻을 수 있습니다.
- 권순선 (구글 글로벌 머신러닝 생태계 프로그램 리드)

지난 19년간 구글 검색팀에서 소프트웨어 엔지니어, 엔지니어링 매니저와 디렉터를 거치면서 보고 경험했던 내용이 이 책 한 권에 담겨 있어서 매우 놀라웠습니다. 소프트웨어 엔지니어뿐만 아니라 IT 분야에 종사하는 모든 이에게 이 책을 추천합니다.
- 이준영 (구글 소프트웨어 엔지니어링 디렉터)

그간 여러 곳에 소개된 구글의 소프트웨어 엔지니어링은 단편적이었습니다. 하지만 이 책은 구글 엔지니어링의 역사, 변화 과정, 소프트웨어 개발을 다각도로 들여다봅니다. 작게는 구글이 사용하는 도구, 넓게는 문서화, 깊게는 의존성 관리, 대규모 변경, 지속적 배포 등을 다룹니다. 이 책은 성장하는 엔지니어링 조직에서 일하고 있는 모든 이에게 ‘어떤 문제를 어떻게 접근해야 하는가'에 대한 좋은 가이드가 되어줄 겁니다.
- 서민구 (구글 코리아 테크 리드 메니저)

우리는 소프트웨어 엔지니어입니다. 소프트웨어 엔지니어링은 단순히 고객의 요구사항을 해소하는 것에만 그치지 않습니다. 문제의 근본 원인을 찾고 개선해나가며, 지속 가능성과 확장성을 고려하여 최적의 결과물을 만들어나가야 합니다. 이 책은 소프트웨어 엔지니어로 나아가기 위한 길을 제시해주고 있습니다. 이 책과 함께라면 우리에게 더 큰 보상과 기회의 문이 열리게 될 것입니다.
- 당근마켓 (서비스코어 부문)

구글의 아리스토텔레스 프로젝트를 통해 성공하는 팀이 가져야 하는 기준을 알게 되어, 그 내용을 사내에 적용하고 코칭하면서 많은 것을 배웠고 좋은 성과도 일궈냈습니다. 이 책에는 이렇게 성공하는 팀이 엔지니어링 측면에서 일하는 방식과 문화를 어떻게 만들어가는지에 대한 내용이 담겨있습니다. 이 책을 통해 알게 된 내용들을 과제와 조직에 적용할 생각을 하니 벌써부터 가슴이 뜁니다.
- 우경우 (삼성전자 조직개발 코치 SWITCH 사무국)

지금까지 출간된 ‘구글은 이렇게 한다’식의 책들과 달리, 불친절한 개념 설명도 없고 구글의 뛰어난 시스템 자랑 나열도 별로 없습니다. 그저 인터넷 서비스 업체에서 벌어지는 소프트웨어 개발에 대한 전부를 개념부터 한 숟가락씩 떠먹여 주고 그동안의 현장 경험과 노하우를 예제와 함께 소개합니다. 시중에 나온 많고 많은 자기계발/실천법 서적들을 응축하여 구글이 핸드드립한 에스프레소를 마시는 느낌이니, 이 책만 잘 읽어도 이 바닥 전체를 섭렵한 기분이 들것입니다. 이 책에서 제시하는 테크닉과 방법론은 현장감 있고 생생하다는 느낌을 받았습니다. 무엇보다도 소프트웨어 엔지니어링의 정수는 여기에 있다고 말하는듯이, 테스트와 변경 관리에 할애한 분량이 매우 많고 상세하다는 점이 매우 인상적이고 동감하는 바입니다. 목 넘김 좋은 막걸리처럼 술술 잘 넘어가는 한국어화 품질도 크게 칭찬해주고 싶습니다. 마지막으로, ‘이상적이고 순수하고 정직하다’라는 말을 하고 싶습니다. 구글 엔지니어들은 과연 이걸 진짜로 해낸 것일까요?
- 곽용재 (NAVER 검색플랫폼 총괄)

저는 소프트웨어 엔지니어링이라는 용어에 막연한 거부감을 느끼며 살아왔습니다. 소프트웨어 엔지니어링보다는 프로그래밍이 우리가 하는 일을 더 잘 대변한다 생각했고, 소프트웨어 엔지니어보다 프로그래머로 불리기를 바랬습니다. 하지만 이 책에서 소프트웨어 엔지니어링을 ‘시간 위를 걷는 프로그래밍’으로 정의한 표현을 읽는 순간, 지금까지 가지고 있던 소프트웨어 엔지니어링에 대한 거부감이 사라졌습니다. 지금까지 중요하게 여기고 강조했던 많은 활동이 소프트웨어 엔지니어링에 해당했기 때문입니다. 이 책은 지금까지 가지고 있던 소프트웨어 엔지니어링에 대한 막연한 거부감을 깨트리고, 이에 대한 중요성과 구글의 시행착오를 간접 경험할 기회를 선사합니다. 또한 프로그래밍에 시간 축을 추가함으로써 한 조직이 고려해야 할 개발 문화, 프로세스, 도구를 소개합니다.
- 박재성 (우아한테크코스 총괄)

회원리뷰 (23건) 리뷰 총점9.6

혜택 및 유의사항?
포토리뷰 [도서 리뷰]구글 엔지이어는 이렇게 일한다. 내용 평점4점   편집/디자인 평점4점 YES마니아 : 골드 a****0 | 2022.05.31 | 추천0 | 댓글0 리뷰제목
이번에 리뷰를 하게 된 책은 “구글 엔지니어는 이렇게 일한다’, 원제는 “Software engineering at google” 입니다.   한글 제목만을 보면 흔히 들어왔던 구글의 고속도로 변의 광고판을 이용해서 신규 직원 채용한 이야기, 구글 직원을 위한 25가지 복지 혜택이 구글 직원들의 업무 성과를 높여주는 것에 대한 이야기, 하루의 대부분을 다른 일을 하는 것 같지만 시간에 맞;
리뷰제목

이번에 리뷰를 하게 된 책은 “구글 엔지니어는 이렇게 일한다’, 원제는 “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나 유튜브에서 본 단편적인 정보들은 진정한 지식이 될 수 없기 때문입니다”(책 “무엇이 과연 진정한 지식인가” 에서 인용)

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

 

이만 리뷰를 마칩니다.

 

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

 

 

댓글 0 이 리뷰가 도움이 되었나요? 공감 0
구글 엔지니어는 이렇게 일한다 내용 평점5점   편집/디자인 평점5점 꿈* | 2022.05.30 | 추천0 | 댓글0 리뷰제목
  아마 IT업계에서 일하는 사람들이라면 각자 속한 팀내에서 활용되는 규칙이나 철학같은 것이 있을 것이다. 나름의 규칙을 가지고 에자일 프로세스를 따르기도 하고, 코드 리뷰를 통해 오류를 찾는 과정을 거치며, 정적분석을 통해 소프트웨어의 품질을 유지하려고 노력할 것이다. 내가 속한 팀도 그렇게 엄격하지는 않더라도 나름의 규칙을 통해서 이런 개발 프로세스를 유지하;
리뷰제목

 

아마 IT업계에서 일하는 사람들이라면 각자 속한 팀내에서 활용되는 규칙이나 철학같은 것이 있을 것이다. 나름의 규칙을 가지고 에자일 프로세스를 따르기도 하고, 코드 리뷰를 통해 오류를 찾는 과정을 거치며, 정적분석을 통해 소프트웨어의 품질을 유지하려고 노력할 것이다. 내가 속한 팀도 그렇게 엄격하지는 않더라도 나름의 규칙을 통해서 이런 개발 프로세스를 유지하려고 한다. 뭐 워낙 소규모의 팀이고, 어떻게 보면 귀찮은 일일수 있겠지만, 그래도 이런거라도 있어서, 아직 우리가 만든 소프트웨어가 잘 돌아가고 개발이 되는 거겠지 쉽다.

 문득 이런 개발 프로세스를 잘 유지하는 회사가 어딜까 싶었는데, 아무리 생각해도 "구글"이 제일 먼저 생각난다. 아마 대부분의 개발자들도 github에 있는 구글 코드를 참고해보겠지만, 구글만의 개발프로세스나 gerrit같은 것을 살펴보면 정말 잘되어 있다는 것이 느껴질 것이다.

 

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

 

이번에 읽은 책은 구글에서 이뤄지는 소프트웨어 엔지니어링에 대한 내용을 다룬 책이다. 사실 이 책은 저자가 상에서 무료로 볼 수 있도록 공개되어 있는 책인데도, 아마존에서도 판매 순위가 높을만큼 좋은 평가를 받고 있는 책이다. 나도 원래 웹상에서 읽다가 방대한 양으로 인해서 필요한 부분만 발췌해서 읽었었는데, 이번에 번역본으로 출간되었다. 역시 번역본도 약 700쪽에 달할 만큼 방대한 양을 담고 있다.

우선 간단하게 이 책은 프로그래밍 책이 아니다. 테스트 파트에서 어떻게 진행이 되는지 예시를 들기 위해서 간단한 코드들이 나올 뿐, 거진 대부분의 내용이 구글에서 활용되고 있는 문화, 프로세스, 도구에 대한 내용이 설명되어 있다. 그래서 그렇게 큰 부담을 가지고 읽을 필요없을 듯하다. (나도 그냥 일하다가 틈틈히 읽거나 잠자기전에 조금씩 읽었는데, 뭔가 이해하면서 읽다는 느낌보다는 구글에서는 이렇게 일하다는 것에 대한 다큐멘터리를 본 느낌이었다.)

이책에서 담고 있는 내용은 다음과 같다.

  • 소프트웨어 엔지니어링의 정의
  • 팀을 관리하는데 있어 필요한 문화와 리딩 능력
  • 테스트와 코드 리뷰같은 개발 프로세스
  • 구글에서 활용하는 도구들: 버전관리와 정적분석, CI 등

세계적으로 큰 회사의 개발 문화에 대해서 이 한책으로 설명하기가 참 어려웠을텐데, 이 책에는 정말로 위의 내용들이 모두 들어 있다. 추가적으로 내용 설명과 동시에 구글에서 활용하면서 실제 적용되어 있는 서비스들과 연계되어 있어서 그만큼 읽는 재미도 있었다. 개인적으로 관심있던 부분은 구글에서 활용되는 도구에 대한 내용들이었는데, 특히 bazel에 대한 내용이던가 정적분석, 의존성 관리같은 부분은 실제 개발자들이 현업에서도 겪는 문제들을 구글에서는 이렇게 해결한다는 방법론을 제시하고 있었다. (한편으로는 구글이니까 이렇게까지 했겠지... 하는 체념도 들기도 했다. 어떻게 읽으면 읽을수록 현업에서 하고 있는 방법론들이 조금 부족하다는 것을 느꼈다거나...)

문득 아마존에서 글 리뷰를 보다가 재미있는 내용을 보았다.

 

아마존 리뷰중

 

 사실 이 리뷰가 어떻게 보면 책의 목적을 대변하고 있다고 생각한다. 앞에서 서두에 했던 말처럼 "그냥 구글이 이렇게 하니까 이게 진리다!" 라는 인식보다는 왜 구글이 이런 방법론을 택하고 발전시켰는지에 대한 생각을 해볼 필요가 있다고 생각한다. 그런 점에서 이 책은 무조건 구글! 이 아닌 그 근거에 대해서 장문의 페이지를 통해서 설명하고 있는 셈이다. (어쩌면 구글에서 하고 있는 방식은 구글이 다루는 문제에서 유용한 것이지 실제 우리같은 회사한테는 overkill일 수도 있겠다.) 개발하는 사람이나 그 사람들을 관리하는 PM들한테는 이런 부분을 책읽으면서 와닿지 않을까 하는 생각을 한다.

(해당 포스트에서 소개하고 있는 "구글 엔지니어는 이렇게 일한다" 책은 한빛 미디어로부터 제공받았음을 알려드립니다.)

출처: https://talkingaboutme.tistory.com/entry/Book-software-engineering-at-google [자신에 대한 고찰:티스토리]

댓글 0 이 리뷰가 도움이 되었나요? 공감 0
[구글 엔지니어는 이렇게 일한다더라] 1부, 문화 내용 평점5점   편집/디자인 평점5점 세***자 | 2022.05.29 | 추천0 | 댓글0 리뷰제목
한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다...만 진심이 담겨있습니다. 허위 사실 유포는 ??일절 없음.       "구글 엔지니어는 이렇게 일한다."이 내 주변에서 조금 핫하다. 이 책을 모르는 개발자가 드물었다. 아마 제목이 큰 역할을 한게 아닐까 싶기는 하다. 어그로는 아니지만 "구글 엔지니어"라는 단어가 딱 들어가니;
리뷰제목
한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다...만
진심이 담겨있습니다. 허위 사실 유포는 ??일절 없음.

 

 

 

"구글 엔지니어는 이렇게 일한다."이 내 주변에서 조금 핫하다. 이 책을 모르는 개발자가 드물었다. 아마 제목이 큰 역할을 한게 아닐까 싶기는 하다. 어그로는 아니지만 "구글 엔지니어"라는 단어가 딱 들어가니깐 이직이나 성장에 목마른 사람들에게 자극적이었을 것이다. 나 역시도 그러했기에 이 책을 이번주까지 다 읽으려고 했었다. 맥락으로 느꼈을 것이다. 나 역시도 타이슨에게 한대 맞았다.

 

 

계획대로 되지 않았다. 본 글에서 변명이 중요한건 아니지만 그럼에도 변명 하나를 꺼내보자면... 이번 책은 꼭꼭 씹어 먹었다. 다른 포스팅에 "함께 자라기"라는 서적을 언급하면서 내 취향이 아니라고 한 적이 있다. 개발자의 조직과 성장과 관련된 서적은 정말 많지만 내 입맛에 맞는 것을 찾기는 쉽지 않다. "구글 엔지니어는 이렇게 일한다."는 내 입맛에 딱이었다. 그렇다보니 평소보다 한장의 무게감이 더 묵직했다.

 

이렇게 된 이상 이번 리뷰는 좀 디테일하게 해보기로 했다. 책 제목을 약간 비틀어서 "구글 엔지니어는 이렇게 일한다더라"라는 이름으로 3회의 포스팅을 할 예정이다. 크게 3개의 파트로 나누어진 이 책을 꼭꼭 씹어먹고 소화한 내용을 공유해본다.

 

이 드립을 생략하기에 너무 아쉽다

 

전제. 소프트웨어 엔지니어링이란 (Chapter.1)

이 책은 소프트웨어 엔지니어링을 소개하는 전제 파트와 전제 파트에서 상세하게 다룰 내용을 소개하는 3개의 파트로 구성된다. 소프트웨어 엔지니어링이란 무엇일까? "흐르는 시간 위에서 순간순간의 프로그래밍을 합산한 것"이라고 저자는 설명하는데 쉽게 와닿지 않는다. 프로그래밍과의 차이를 통해 대략적인 정의를 확인할 수 있다.

 

프로그래밍 작업 : 개발
소프트웨어 엔지니어링 작업 : 개발 + 수정 + 유지보수

 

이 차이를 저자는 지속 가능성에 두었다. 지속이라는 키워드에서 봤듯이 소프트웨어 엔지니어링에는 시간 개념을 염두해야 한다. 하이럼의 법칙을 통해 얼마나 심각해질 수 있는지 알 수 있다. 

 

API에 충분한 수의 유저가 있다면, 명세에서 지정된 것은 아무런 상관이 없다.
시스템에서 관측될 수 있는 모든 행동 양식은 다른 이들에게 달려있을 것이다.
- Hyrum's Law

 

API는 시간이 흐를수록 사용자가 늘어나고 사용자는 API의 의도나 명세와 관계없는 형태로 활용할 가능성이 올라간다. 그렇게 된다면 개발자는 API를 수정하기가 어려워진다.(낮은 지속가능성) 높은 지속가능성을 유지하기 위해서는 소프트웨어 엔지니어링적인 시각으로 작업이 되어야 한다. 이 때 중요한 것이 문화, 프로세스, 도구다.

 

 

 

문화. 팀워크와 지식공유 (Chapter.2~3)

저자가 문화 파트에서 첫번째로 강조한 것은 "숨기지 말 것"이다. 조직의 모든 사람이 천재가 아니기에 본인의 역량이 그대로 드러나는 코드가 부끄러울 수 있다. 하지만 이를 숨긴다면 조기 감지와 장애, 속도면에서 해롭다고 언급한다. 특히 버스 지수에 대해 설명한게 인상적이다. 버스 지수는 몇 명의 팀원이 버스에 치어서 일을 할 수 없게 될 때 프로젝트가 망하게 되는지를 나타내는 지수다. 예전에 어느 대기업은 이런 경우를 차단하기 위해 핵심 인물들이 대량 이동할 때 의도적으로 비행기 2대 이상 나누어서 이동한다고 들었던 적이 있다. 여기서는 특정 인물에게 중요한 작업이 집중되어 있는지 조직원들에게 잘 분산되어 있는지를 언급하기 위해 버스 지수를 설명하고 있다.

 

이런 팀워크를 마들기 위해서 다음 3가지를 강조하고 있다.

 

1. 겸손 humility
2. 존중 respect
3. 신뢰 trust

 

 

저자는 단순히 조직 내부 뿐 아니라 거의 모든 사회적 갈등의 근본 원인이 여기에 있다고 얘기한다. 그러면서 어떻게 실천할 수 있는지 방법을 제시하고 있다. 비평하고 비평받는 법 배우기, 빠르게 실패하고 반복하기, 포스트모템 문화 등. 그 중 가장 중요해 보이는 실천 방법은 "자존짐 버리기"가 아닐까 싶다. 앞에서 "숨기지 말 것"이 나온 이유도 이 자존심 때문이 아닐까. 그렇다고 이 책에서 바짝 엎드리라고 하지는 않는다. 생산성을 떨어뜨리는 자존심보다는 팀의 성취와 단체의 자부심을 높이길 권하고 있다.

 

팀워크는 단순히 업무에서만 작용하지 않는다. 배움의 문화를 통해서도 팀워크는 강화된다. 배움을 가로막는 장애물(심리적 안전 부족, 정보 섬 등)이 있다면 이를 극복해서라도 지식 공유는 필요하다. 그럴려면 앞에서 얘기한 장애물을 치워야 한다. 심리적 안전은 숨기는 것을 줄여줄 것이다. 멘토를 두어도 좋고 구성원 그룹 단위로 쉽게 도움을 청할 수 있는 분위기를 형성하는 방법도 있을 것이다.

 

지식은 스터디, 컨퍼런스를 통해서만 전달되는 것은 아니다. 가장 기본이 되는 것은 질문이다. 어떻게 질문을 하고 맥락을 이해하고 대답을 해주느냐에 따라 지식의 폭이 넓어질 수도 좁아질 수도 있다. 물론 지식을 확장하는 방법에는 여러가지가 있다. 오피스 아워, 기술 강연과 수업, 문서자료 등. 특히 스타트업에 종사하는 분들에게는 이 문서자료를 갱신하고 새로 작성하는데 소홀할 수 있다. 하지만 문서가 때론 사람을 통할 때보다 더 효율적일 때도 있다. 문서에 관한 내용은 2부에서도 다루도록 하겠다.

 

구글에서는 조직의 지식을 확장하기 위해 많은 노력을 했다. 지식 공유 문화를 자리잡도록 했고 표준 정보 소스라고 해서 전문가의 지식을 표준화하고 전파하는 수단을 만들기도 했다. 누구도 소외되지 않게 하기 위해 뉴스레터나 커뮤니티를 활용하는 방법도 제시한다. 가독성 제도라는 것도 소개한다. 내용을 보면 코드리뷰보다 10배는 더 귀찮을 것같은 제도이다. 프로그래밍 언어 모범사례를 전파하기 위한 구글 전사 차원의 '표준 멘토링 프로세스'라고 한다. 표준화와 개인화가 융합된 방식의 지식 확장 수단으로 문서화된 지식과 현장 시직을 보완하는 매력적인 방식이다. 저자는 이런 방식이 본인이 다니는 조직에도 어울리는지를 먼저 파악하라고 말한다. 뭐, 당연하다. 인력 여유가 되지 않는다면 엄두도 내기 힘든 방법이니깐. 하지만 기억해두었다가 언젠가 이런 방법을 건의해도 좋지 않을까 싶다.

 

 

 

문화. 공정사회를 위한 엔지니어링 (Chapter.4)

문화파트에서 가장 인상적인 챕터다. 아무리 구글이라도 차별 이슈에서 자유롭지 못했다. 하지만 스스로 이를 인정하고 인지하며 반성하고 개선하려는 노력을 했다. 이 책을 읽은 독자 입장에서 구글이 모든 차원에서 옳은 결정을 했다고 생각하지 않는다. 하지만 이런 내부 반성의 모습은 부럽다. 이 챕터에서는 다양성이 왜 필요하고 어떻게 갖출 수 있는지 다루고 있다. 그들은 이 부분에 대해 이토록 고민하고 지금도 연구하고 있음을 엿볼 수 있다.

 

가장 짧은 챕터 중 하나다. 그렇지만 불공정이 얼마나 위험한지 강하게 설명한다. 단순히 일만 잘하는 개발자보다 가치있는 엔지니어링이 무엇인지 고민하는 개발자가 더 가치있음을 알려준다. "관심을 잃지 말고 전진하자". 이 챕터의 핵심 문장이 아닐까.

 

 

 

문화. 팀 그리고 성장하는 조직 이끌기 (Chapter.5~6)

나는 관리자도 리더도 아니다. 하지만 언젠가는 이 둘 중 하나는 될 것이다. 그럼 어떤 역할이 어울릴지 생각해보는 것도 나쁘지 않다. 여기서는 엔지니어링 관리자, 테크 리드, 테크 리드 매니저를 소개하고 있다. 어떤 역할을 맡게 되든 관리를 하는 입장이 되는 것에 거부감만 느끼지말고 맡은 역할과 그 주변을 두려워하며 맡겨진 입장에서는 섬기는 리더십을 가질 필요가 있다.

 

엔지니어링 관리자는 과거의 단순한 노동을 관리하는 역할이 아니다. 안티 패턴으로 본인 행동 양식을 경계하며 올바른 패턴으로 구성원의 촉매제 역할이 되어야 한다. 안티 패턴으로는 만만한 사람 고용, 저성과자 방치, 사람 문제 무시 등이 있다. "희망은 전략이 아니다."라는 말을 빌려 저성과자나 사람 문제를 희망적으로만 바라보다간 오히려 고효율 인력을 낭비하는 상황으로 만들 수 있다. 그럼 올바른 패턴은 무엇일까. 자존심을 버리고, 본인의 마음을 다스릴줄 알며, 조직원의 장애물이 되는 것을 치우고, 때론 선생이나 멘토가 될 수 있으면 훌륭한 엔지니어링 관리자라고 할 수 있다. 물론 기술 부분을 책임지는 테크 리드도 동일하게 적용된다.

 

그럼 성장하는 조직을 이끌려면 어떻게 해야할까? 저자는 3A 리더십을 언급했다.

1. 늘 결정하라 Always Be Deciding
2. 늘 떠나라 Always Be Leaving
3. 늘 확장하라 Always Be Scaling

 

리더는 선택의 연속이다. 눈가리개가 되는 것을 찾고 핵심 트레이드오프를 파악하고 결정하고, 이를 반복해야 한다. 이로서 작업의 사이클이 돌아간다. 작업 사이클이 더 원활하게 돌아가려면 자율주행팀이 되어야 한다. 버스 지수에서 얘기한 것처럼 리더가 부재하다고 해서 업무가 마비되면 안된다. 그래서 리더의 역할을 위임하는 능력도 필요하다. 여기서 위임에 대한 얘기가 자주 나오는데 그만큼 혼자서 해결하기보다 팀에서 같이 해결하는 것이 더 효율적임을 강조하는 것이다. 마지막으로, 작업의 확장은 피할 수 없기에 무엇이 중요한지 이해하고 구성원의 시간과 에너지를 잘 관리해야 한다.

 

 

문화. 엔지니어링 생산성 측정하기 (Chapter.7)

어디든 엔지니어 조직의 생산성을 측정하고 싶어할 것이다. 하지만 쉽지 않다. 단순히 코드 라인 갯수로 파악할 수 있는게 아니기 때문이다. 이런 방식은 부작용이 더 크다. 쓰레기 코드만 늘어날 수 있기 때문이다. 그렇다면 생산성 측정은 어떻게 진행하는게 좋을까?

 

먼저 측정하려는 대상이 정말 가치있는 대상인지 확인을 해야한다. 어떤 결과를 기대하고 결과에 따라 행동이 바뀌는지 등을 체크하여 가치있다고 판단했을 때 생산성 측정을 위한 목표를 설정한다. 구글 사례로 GSM 프레임워크를 소개했다. Goal(목표), Signal(신호), Metric(지표). 목표는 원하는 속성을 설명해야지 어떠한 지표도 명시되면 안된다. 신호에서는 목표 달성 여부를 알 수 있는 방법이 나와야 한다. 그리고 지표에서 정성적, 정략적 측정으로 검증을 진행한다. GSM 프레임워크는 어디까지나 구글에서 사용한 방식이다. 충분히 표준적인 형태로 소개하여 다른 조직에서도 사용가능하겠지만 충분히 사전 검토를 하고 적용을 해야겠다. 물론 목표 결과까지 나온 뒤 결과를 추적하여 정말 가치있는 엔지니어링 생산성 측정이였는지도 잊지말고 해야한다.

 

 


 

이렇게 문화적인 측면에서 구글이 일하는 방식을 확인해 보았다. 2부에서는 프로그래밍 스타일 가이드, 코드리뷰, 테스트가 포함된 프로세스에 대해 소개해보겠다.

 

 

 

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

구글은 어떻게 개발하고 코드를 관리하는가지난 50년의 세월과 이 책이 입증한 사실이 한 가지 있다. 바로 `소프트웨어 엔지니어링의 발전은 결코 정체되지 않는다`라는 것이다. 빠른 기술 변화

www.yes24.com

 

??

댓글 0 이 리뷰가 도움이 되었나요? 공감 0

한줄평 (6건) 한줄평 총점 9.0

혜택 및 유의사항 ?
구매 평점4점
기대됩니다.
이 한줄평이 도움이 되었나요? 공감 0
g********s | 2022.09.18
구매 평점5점
개발자를 위한 진수성찬 같네요.
이 한줄평이 도움이 되었나요? 공감 0
YES마니아 : 플래티넘 t******g | 2022.07.09
평점3점
번역이 조금 아쉽습니다만 좋은 책입니다.
이 한줄평이 도움이 되었나요? 공감 0
바**비 | 2022.07.06
스프링분철 서비스를 선택하세요.
수량감소 수량증가 40,500
  •  다운받은 받은 쿠폰은 결제 페이지에서 적용해 주세요.
  •  분철옵션 선택 시, 영업일 기준 3일내 출고됩니다.
  •  분철상품은 해외배송이 불가합니다.
1   40,500

스프링분철 신청 가능

뒤로 앞으로 맨위로 aniAlarm