[목 차]
  

옮긴이 머리말 xi

추천의 글 xiii

베타리더 후기 xvi

추천 서문 xviii

시작하며 xx

감사의 글 xxii

이 책에 대하여 xxiv

표지에 대하여 xxvii

 

PART I 코드 리뷰의 기초 지식

 

CHAPTER 1 코드 리뷰의 중요성 3

1.1 대상 독자 7

1.2 책의 구조 9

1.3 코드 리뷰가 필요하다 11

__1.3.1 더 나은 애플리케이션 11

__1.3.2 팀의 이해 수준 향상 12

1.4 팀 설득하기 12

1.5 코드 리뷰 개선하기 13

요약 14

 

CHAPTER 2 코드 리뷰 분석하기 15

2.1 코드 리뷰 시스템 15

__2.1.1 사람 주도 16

__2.1.2 도구 기반 16

__2.1.3 혼합형 17

2.2 코드 리뷰는 어떻게 작동할까? 18

__2.2.1 현재의 코드 리뷰 워크플로 19

__2.2.2 우리의 코드 리뷰(PR 워크플로) 22

2.3 훌륭한 PR의 요소 22

__2.3.1 제목: ‘what’ 23

__2.3.2 디스크립션: ‘why’ 28

__2.3.3 레이블 34

__2.3.4 리뷰 상태 37

2.4 코드 리뷰 참여자와 기대사항 40

__2.4.1 리뷰어 41

__2.4.2 작성자 46

__2.4.3 팀 51

__2.4.4 관리자 53

__2.4.5 조직 54

요약 58

 

CHAPTER 3 팀의 첫 코드 리뷰 프로세스 구축하기 60

3.1 목표 설정하기 61

__3.1.1 버그 발견 61

__3.1.2 코드베이스의 안정성과 유지 보수성 63

__3.1.3 지식 전달과 정보 공유 64

__3.1.4 멘토링 67

__3.1.5 기록 보관/변경 이력 관리 68

__3.1.6 자신의 코드 리뷰 목표 선택하기 69

3.2 도구 선택하기 70

__3.2.1 코드 리뷰 기능 평가하기 71

__3.2.2 도구 선택하기 72

3.3 가이드라인 설정하기 76

__3.3.1 팀의 워크플로 76

__3.3.2 리뷰의 중점 79

__3.3.3 PR 승인을 막는 요인 80

__3.3.4 승인 정책 82

3.4 프로세스 개선하기 85

__3.4.1 개선 사례 가이드 88

요약 90

 

PART II 고급 코드 리뷰를 위한 필수 요소

 

CHAPTER 4 팀 워킹 어그리먼트 93

4.1 팀 워킹 어그리먼트란? 94

4.2 팀 워킹 어그리먼트로 팀 기대치 설정하기 94

__4.2.1 시나리오 1: 빠른 리뷰와 빠르지 않은 리뷰 95

__4.2.2 시나리오 2: 의미의 불일치 95

__4.2.3 시나리오 3: 승인 또는 미승인 97

4.3 팀 워킹 어그리먼트 수립하기 98

__4.3.1 팀에 팀 워킹 어그리먼트가 꼭 필요할까? 98

4.4 팀 워킹 어그리먼트에 포함할 사항 고려하기 102

__4.4.1 명확한 코드 리뷰 기대사항 102

__4.4.2 합리적인 응답 시간 102

__4.4.3 적절한 PR 크기 105

__4.4.4 문제 식별 106

__4.4.5 PR 셀프 승인하기 109

__4.4.6 사소한 지적 111

__4.4.7 긍정적인 리뷰 환경 112

__4.4.8 정책을 위반했을 때는 어떻게 할까? 113

4.5 팀 워킹 어그리먼트 적용하기 114

__4.5.1 수정이 필요할 때 114

__4.5.2 정리하기 115

요약 115

 

CHAPTER 5 자동화의 이점 117

5.1 자동화의 중요성 118

5.2 자동화의 전제 조건 120

__5.2.1 팀 스타일 가이드 120

__5.2.2 적절한 도구 123

5.3 리뷰 전 자동화 124

__5.3.1 포매팅 124

__5.3.2 린트 127

__5.3.3 정적 분석 129

__5.3.4 테스트 자동화 131

5.4 코드 리뷰 과정 중 자동화 133

__5.4.1 PR 템플릿 133

__5.4.2 PR 검증 도구 136

__5.4.3 리뷰어 할당 139

__5.4.4 PR 게이트 체크 143

__5.4.5 리마인더와 에스컬레이션 147

요약 148

 

CHAPTER 6 효과적인 코드 리뷰 코멘트 작성하기 150

6.1 코멘트를 효과적으로 만드는 방법 151

__6.1.1 객관성 151

__6.1.2 구체성 157

__6.1.3 명확한 결과 163

__6.1.4 효과적인 코드 리뷰 코멘트 샘플 165

6.2 말투(표현 방식) 167

6.3 코드 칭찬하기 171

요약 172

 

PART III 딜레마

 

CHAPTER 7 코드 리뷰가 망하는 순간들 177

7.1 코드 리뷰 프로세스에서 겪는 문제 178

__7.1.1 대충 진행하는 코드 리뷰 178

__7.1.2 나쁜 코드 리뷰 180

__7.1.3 일관성 없는 코드 리뷰 182

__7.1.4 엄격한 코드 리뷰 183

7.2 그렇다면 무엇을 해야 할까? 185

요약 185

 

CHAPTER 8 코드 리뷰 지연 줄이기 186

8.1 리뷰를 할 수 있는 시니어 개발자가 한 명밖에 없어요 187

8.2 PR이 이해되지 않아요 191

8.3 리뷰할 파일이 너무 많아요 192

8.4 기능이 너무 커서 리뷰가 어려워요 193

8.5 논의가 너무 길어지는 것 같아요 196

8.6 코드 리팩터링이 필요해요 199

요약 201

 

CHAPTER 9 프로세스의 허점 제거하기 203

9.1 허점이 발생하는 이유 203

9.2 허점(그리고 해결 방법) 204

__9.2.1 정의되지 않은 코드 리뷰 프로세스 205

__9.2.2 코드 리뷰 시간 부족 212

__9.2.3 도구의 (잘못된) 설정 214

__9.2.4 피드백 문화의 부재 215

__9.2.5 승인 지향 지표 217

__9.2.6 비상 상황 이용하기 220

요약 220

 

CHAPTER 10 비상 대응 매뉴얼 222

10.1 비상 대응 매뉴얼이 무엇일까? 223

10.2 비상 대응 매뉴얼의 필수사항 224

__10.2.1 의사결정 트리 224

__10.2.2 승인 프로세스 225

__10.2.3 우회 메커니즘 226

__10.2.4 다음 단계 227

10.3 언제 비상 대응 매뉴얼을 사용할까? 229

요약 229

 

CHAPTER 11 코드 리뷰와 페어 프로그래밍 233

11.1 코드 리뷰를 해야 할까, 페어 프로그래밍을 해야 할까? 234

__11.1.1 페어 프로그래밍으로 코드 리뷰 보완하기 235

__11.1.2 페어 프로그래밍이 코드 리뷰를 대체할 수는 없다 236

11.2 페어 프로그래밍을 프로세스에 통합하기 238

__11.2.1 페어 프로그래밍 시도를 위해 팀 설득하기 238

__11.2.2 페어 스타일 240

__11.2.3 효과적인 페어 프로그래밍을 위한 고려사항 243

요약 251

 

CHAPTER 12 코드 리뷰와 몹 프로그래밍 253

12.1 코드 리뷰 vs. 몹 프로그래밍 254

__12.1.1 몹 프로그래밍의 장점 255

__12.1.2 몹 프로그래밍으로 코드 리뷰 보완하기 257

__12.1.3 몹 프로그래밍은 코드 리뷰를 대체할 수 없다 259

12.2 몹 프로그래밍을 코드 리뷰와 통합하기 260

__12.2.1 상호 보완 접근 방식 261

__12.2.2 몹 프로그래밍의 핵심 요소 266

요약 269

 

CHAPTER 13 코드 리뷰와 AI 271

13.1 코드 리뷰에서 AI의 이점 272

__13.1.1 리뷰 속도 향상 272

__13.1.2 코드 품질 개선 273

__13.1.3 리뷰 일관성 274

__13.1.4 팀과 코드베이스의 규모에 영향을 받지 않는 리뷰 확장성 274

13.2 AI 코드 리뷰의 한계 274

__13.2.1 맥락과 도메인 지식 이해의 어려움 274

__13.2.2 학습 데이터에 크게 의존하는 성능 276

__13.2.3 AI에 과도한 의존은 리뷰어의 전문성을 저해할 수 있다 276

13.3 AI 기반 코드 리뷰가 무엇을 할 수 있을까? 277

13.4 AI를 코드 리뷰에 통합하기 287

13.5 코드 리뷰의 미래: 인간과 AI의 협업 289

요약 290

 

APPENDIX A 팀 워킹 어그리먼트 스타터 템플릿 294

 

APPENDIX B 비상 대응 매뉴얼 스타터 템플릿 300

B.1 비상 대응 매뉴얼 명명하기 300

B.2 의사결정 트리 300

B.3 승인 프로세스 301

B.4 우회 메커니즘(관련 작업) 301

B.5 다음 단계 302

__B.5.1 문서화 302

__B.5.2 커뮤니케이션 302

__B.5.3 사후 분석 303

 

APPENDIX C PR 템플릿 304

 

APPENDIX D 리소스 307

D.1 각 장의 리소스 리스트 307

D.2 언어별 린터 리스트 313

D.3 언어별 정적 분석 도구 318

 

APPENDIX E 한국어판 부록: 한국 개발자의 코드 리뷰 이야기 339

E.1 AI와 함께 진화하는 코드 리뷰 문화(김연태) 339

E.2 코드 리뷰가 시스템이 되는 순간(김완섭) 341

E.3 작게 나누고 크게 배우는 코드 리뷰 문화(선용주) 342

E.4 완벽보다 팀을 택하는 코드 리뷰 문화(윤기쁨) 344

E.5 팀과 개인을 모두 성장시키는 코드 리뷰의 태도(임슬기) 345

 

참고 문헌 348

찾아보기 352

[본 문]
  

중요한 변경(breaking change)에 대한 PR을 요청할 때 사람들이 가장 먼저 알고 싶은 것은 변경이 미치는 영향 범위다. 이때는 영향을 받는 프로젝트 리스트를 작성하면 매우 유용하다. 리뷰어는 이를 통해 코드베이스의 어떤 부분에 집중해야 하는지 쉽게 알 수 있으며, 변경으로 인해 발생할 수 있는 잠재적인 문제를 빠르게 파악할 수 있다. / 물론 리뷰어가 파일을 확인하며 영향받는 프로젝트를 스스로 파악할 수도 있지만, 이는 불필요하게 시간만 지연시키는 일이 된다. 정보를 가장 잘 아는 작성자가 시간을 들여 중요한 변경사항으로 인해 영향을 받는 프로젝트나 컴포넌트를 나열하고 의미를 설명한다. 내용을 잘 아는 작성자는 빠르게 내용을 작성할 수 있으므로, 리뷰어에게 필요한 정보를 미리 제공하고 리뷰를 올바른 방향으로 진행할 수 있도록 도와준다. 결과적으로는 전체 리뷰 과정의 시간이 줄어들게 된다. (33쪽)

 

마지막으로, 리뷰 상태에 대해 알아보자. PR에 상태를 추가함으로써 여러 문제를 피할 수 있다. 일상에서 접하는 UI를 보면 상태 진행 바나 로딩 스피너, 튀어오르는 공과 같은 애니메이션 요소를 사용하여 사용자에게 현재 로딩 중인 상황을 전달하고 잠시 기다려달라는 메시지를 전달한다. 그러나 이와 같은 개념을 우리는 코드에도 적용하는 것을 가끔씩 잊는다. 만약 코드 리뷰 도구나 프로세스에서 PR 상태를 표시할 수 있는 방법이 있다면 반드시 활용해야 한다. 리뷰 상태를 더욱 효과적으로 만들기 위해서는 팀이 사용하는 상태 리스트와 각각의 의미를 정의하고 상태의 진행을 명확히 나타내야 한다. (37쪽)

 

무엇보다도 코드 리뷰는 단위 테스트로 잡을 수 없는 버그를 찾는 것이 목적이다. 예를 들어보자. 캐시에서 소량의 데이터를 가져오는 새로운 기능 추가 PR이 진행 중이다. 이 PR에는 변경사항에 대한 상세 정보와 관련 티켓 링크도 포함되어 있으며, 유효한 방식으로 수정되어 단위 테스트도 모두 통과했다. 하지만 코드는 캐시 데이터를 가져오긴 하지만 잘못된 캐시에서 가져오고 있다는 문제가 있었다. 이 사례를 통해 테스트가 통과한다고 해서 코드의 품질이 보장되는 것은 아니며, 버그가 없다고 단정할 수도 없다는 것을 알 수 있다. 이러한 유형의 버그는 단위 테스트를 통해서는 쉽게 발견할 수 없지만, 코드 리뷰를 통해서는 쉽게 발견할 수 있다. 그리고 이러한 프로세스를 통해서 리뷰어는 이러한 유형의 버그를 찾아낼 수 있다. 버그를 발견하는 것은 코드 리뷰 프로세스의 가치를 더욱 빛나게 하는 것이며, 정적 분석 도구나 자동화 테스트가 놓칠 수 있는 부분을 보완한다. (62~63쪽)

 

코드 리뷰의 일부가 더 이상 효과적이지 않고 조정이 필요하거나 새로운 요소의 추가가 필요할 때는 팀 전체에 공유하고 논의를 시작해야 한다. 이것이 변경을 위한 첫 번째 단계다. 명확하게 변경사항을 제안하는 방법을 마련하면 이 과정이 더 쉬워진다. 월간 팀 미팅에서 전용 논의 시간을 할애하거나, 회고에서 논의 항목으로 다루거나, 변경사항 논의를 위한 메시지 채널 등의 방식을 사용할 수 있다. 옵션은 다양하므로 팀이 자연스럽게 참여할 수 있는 방식을 찾고, 이를 공식적인 프로세스 개선 논의 방식으로 정하는 것이 중요하다. (85쪽)

 

코드 리뷰 자동화를 시작하는 가장 쉬운 방법은 무엇일까? 바로 가장 사소한 문제부터 해결하도록 하여 PR에 포함되지 말아야 할 부분을 제거하는 것이다. 이를 적용하여 자동화의 장점을 확인할 수 있는 시점이 있다면 실질적인 코드 리뷰 직전과 개발 단계다. / 코드 포매팅, 린팅, 정적 분석, 자동화 테스트를 사용하면 불필요한 논쟁을 줄이거나 없앨 수 있고, 사소한 문제를 미리 해결하거나 리뷰어가 더 중요한 문제에 집중하도록 만들 수 있다. 이러한 메커니즘은 겹치는 경우가 많고 일부 도구에서는 여러 기능이 통합되어 있기 때문에 혼동할 수도 있다. 따라서 이번 절에서는 각 자동화 작업의 의미를 설명하고 언어나 개발 환경에 따라 달라질 수 있는 부분을 구별해서 설명한다. 어떤 방식을 사용하더라도 코드 리뷰가 시작되기 전에 자동화를 하는 것이 필수다. (124쪽)

김연태 (헤렌 CTO)

코드 리뷰를 하다 보면 바쁜 일정에 쫓겨 형식적인 승인만 하거나, 동료의 리뷰를 기다리다 언제 다시 요청해야 할지 고민했던 경험이 누구나 한 번쯤은 있을 것입니다. 이 책은 이러한 코드 리뷰의 실질적인 고민을 해결하는 방법을 제시합니다. 단순히 리뷰 자체만이 아니라 개발자의 협업 활동 전반을 다루며, 팀 단위로 적용할 수 있는 다양한 방법을 체계적으로 정리하고 있습니다. 특히 6장의 컨벤셔널 코멘트 레이블과 9장의 리뷰 프로세스 개선 사례는 당장 실무에 적용해보고 싶을 만큼 실용적입니다. 더 나은 코드 리뷰 문화를 만들고 싶은 모든 개발자에게 추천합니다

 

김완섭 (독일계 보험사 시니어 아키텍트, 《깃허브 액션으로 구현하는 실전 CI/CD 설계와 운영》역자)

코드 리뷰를 체계적이면서 실용적으로 잘 다룬 책입니다. 코드 리뷰를 하고 있지만 아직 제대로 하고 있는지 모르거나, 팀이 공유할 만한 정해진 규칙이 없다면 이 책이 좋은 길라잡이가 될 것입니다.

 

선용주 (트레드링스 백엔드 개발자)

코드 리뷰, 개발을 업으로 한다면 너무나도 익숙한 표현입니다. 그런데 이 코드 리뷰를 막상 진행하려면 참 어렵습니다. 이유도 가지각색이죠. 어느 때는 코드 리뷰가 무슨 의미가 있나 하는 생각도 듭니다. 바쁘게 돌아가는 초기 스타트업의 개발자들에게는 더더욱 그렇습니다. 그러나, 그럼에도 코드 리뷰는 해야 합니다. 그것이 개발자의 소통법이자 문화를 만들어가는 과정이기 때문입니다. 처음은 조금 어색할 수 있습니다. 리뷰를 하는 과정도 그렇지만, 리뷰를 받는 과정은 민망하기도 합니다. 우리는 Pull Request를 하고, 리뷰어에게 나의 의도를 잘 전달하는 방법을 고민합니다. 또한 Pull Request를 확인하고, 리뷰이에게 더 나은 피드백을 하기 위해, 코드의 의도를 받아들이기 위해 질문을 던집니다. 그렇게 대화하는 과정에서 문화가 생깁니다. 이 책은 그런 과정에서 겪을 수 있는 어려움에 많은 힌트를 건넵니다. 때로는 그 원인이 도구에, 절차에, 구성원 중 누군가에게, 때로는 나에게도 있을 수 있죠. 여러분이 겪는 어려움은 생각보다 어렵지 않은 방법으로 풀어나갈 수 있습니다. 처음부터 끝까지, 때로는 부분적으로 우리 팀과 동료에게 저자가 건네는 노하우를 적용해보며 더 즐겁게 개발을 이어나가기를 바랍니다.

 

윤기쁨 (블룸에이아이 프런트엔드 개발자)

LGTM에서 그치지 않는 건설적인 피드백을 교환하고, 안정성 있는 코드로 병합하기 위한 방식을 다루는 교과서와 같은 책이었습니다. 현업에서 막연하게 느꼈던 코드 리뷰의 문제점을 명확히 짚어주고, 실질적인 개선 방법에 대한 시야가 트이는 경험을 할 수 있었습니다. 리뷰어뿐 아니라 작성자가 갖추어야 할 좋은 코드 리뷰 방식을 위한 역할과 책임을 다시 한번 짚어볼 수 있는 좋은 계기가 되었으며, 무엇보다 '개발자는 코드가 아니라 사람'이라는 핵심 메시지를 통해 코드 리뷰 문화를 어떻게 가꾸어나가야 하는지 명확한 인사이트를 얻을 수 있었습니다. 더 나은 코드 리뷰 문화를 만들고 싶은 모든 개발자에게 추천합니다.

 

임슬기 (프리랜서 개발자)

코드 리뷰는 이제 우리에게 너무나 익숙한 주제로, 그 의미와 필요성은 이미 많은 개발자 커뮤니티에 깊이 자리 잡고 있습니다. AI의 도움으로 일부 리뷰 과정이 효율화되고 있지만, '함께 만드는 결과물'의 방향을 정하는 작업 리뷰는 여전히 합리적인 의사결정을 기반으로 하며, 가장 중요한 비즈니스 문제를 해결하는 데 더욱 핵심적인 역할을 맡게 될 것입니다. 이 책을 읽을 때 '우리 팀이 지금 당장 리뷰해야 할 일은 무엇이며, 현재 우리 팀에 적합한 리뷰 문화는 무엇일까?'라는 지극히 실용적인 관점에서 읽는 것을 추천합니다. 책을 읽다 보면 당장 현재 작업에서 도입할 수 있는 것이 보이고, 현재 팀 내부에서 겪는 어려움에 공감하고, 우리 팀에 간절히 도입하고 싶은 요소를 발견할 수 있을 것입니다. 이 책은 '코드 리뷰'에 참여하는 많은 의사결정권자들의 역할과 책임, 코드 리뷰를 팀에 정착시키기 위한 이해를 담고 있습니다. 이를 통해 우리는 우리의 작업을 더 명확하게 파악하고, 효율적인 의사소통을 이루는 데 도움을 받을 수 있을 것입니다.

 

스벤 페테르스(Sven Peters) (아틀라시안)

코드 리뷰의 인간적 측면을 과감히 다루며, 공감, 존중, 건설적인 피드백으로 코드 리뷰의 방향을 전환합니다.

 

올리버 드로트봄(Oliver Drotbohm) (브로드컴)

코드 리뷰 접근법, 함정 그리고 더 높은 품질의 소프트웨어를 출시하는 방법에 대한 포괄적 개요

 

조이스 린(Joyce Lin) (Viam)

팀의 성패를 좌우할 수 있는 패턴에 주목합니다. 자기 성찰을 하고 어떤 개발자가 되고 싶은지 결정할 준비를 하세요.

 

론 다그다그(Ron Dagdag) (세븐일레븐)

코드 리뷰에 대한 상쾌하고 인간 중심적인 접근법. 강력 추천합니다!

 

스콧 한셀먼(Scott Hanselman) (마이크로소프트 개발자 커뮤니티 부사장)

이 책은 여러분과 여러분의 팀을 더 좋은 코드 리뷰 문화로 이끌어줄 것입니다.