| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 |
- SQL #PLSQL #DATABASE #DB #데이터베이스 #컴공 #IT
- 자바스크립트 #IT #개념 #컴공 #컴소
- 책 리뷰 #책 #IT지식 #IT #개발 #컴공 #책 후기
- 자바 #java #개발자
- react #react 강의 #react 기초 #코딩 #컴공
- 온프레미스 #서버 #infra #IT #개발 #docker #도커 #vm #image
- 길벗출판사 #좋은코드리뷰 나쁜코드리뷰 #책 #개발자 #it
- python #마틴파울러 #refactor #refactoring #Python #코딩 #개발자
- 자바스크립트 #JS #Javascript #심화
- SQL #오라클 #DB #데이터베이스 #IT #컴공 #컴소공 #PLSQL
- Java #자바 기초 #자바 개념 #개발자
- Java #자바 #개발자 #자바 기초
- 자바스크립트 #javascript #문법 #기초
- 자바스크립트 #JS #javascript #자바스크립트 기초 정리
- 산학연계 #인턴쉽 #면접 #개발자 #IT #현장실습 #합격
- vue #html #브라우저 #GC #heap #V8
- PL/SQL # ORACLE #DATABASE #DB #컴공 #컴소공 #IT
- python #라이브러리 #pyqt #pySide #PySIde6 #pyside6 #컴공 #개발자
- javascript #자바스크립트 #함수 #개발자 #자바 #컴공
- 협찬 #
- PL/SQL #SQL #DB #ORACLE #DATABASE #컴공 #컴소공 #IT
- js #javascript #기초 #it #컴공
- SQL #PL/SQL #Oracle #DB #데이터베이스 #컴공 #컴소공 #it
- Today
- Total
잼코딩
좋은 코드 리뷰, 나쁜 코드 리뷰 | 개발자는 코드만 잘 짜면 될까? 코드 리뷰와 커뮤니케이션을 배우는 책 본문
※ 이 글은 출판사로부터 도서를 제공받아 직접 읽고 작성한 리뷰입니다.
개발 공부를 하다 보면 자연스럽게 코드를 작성하는 방법이나 프레임워크, 언어 문법에 집중하게 된다.
그런데 실제로 여러 사람이 함께 개발하는 환경에서는 코드를 작성하는 것만큼이나 내가 작성한 코드를 설명하고, 다른 사람의 코드를 리뷰하고, 의견을 주고받는 과정도 중요하다.
이번에 읽어본 책은 바로 이런 부분을 다루고 있는
《좋은 코드 리뷰, 나쁜 코드 리뷰》다.

《좋은 코드 리뷰, 나쁜 코드 리뷰》. 19가지 사례와 33가지 팁을 통해 코드 리뷰 과정에서의 커뮤니케이션 방법을 다룬다.
표지에 적혀 있는
“좋은 개발팀은 어떻게 리뷰하고 소통하는가?”
라는 문장이 이 책의 내용을 가장 잘 설명해주는 것 같다.
단순히 코드의 오류를 찾아내거나 더 좋은 코드를 작성하는 방법을 알려주는 책이라기보다는, 코드 리뷰 과정에서 개발자끼리 어떻게 의견을 전달하고 받아들여야 하는지를 실제 사례를 중심으로 설명한다.
코드 리뷰에도 ‘방법’이 필요하다
처음에는 코드 리뷰에 관한 책이라고 해서 리팩터링이나 클린 코드처럼 코드 작성 방식에 관한 내용이 많을 거라고 생각했다.
하지만 실제로 읽어보니 이 책에서 중요하게 다루는 부분은 사람과 사람 사이의 커뮤니케이션이었다.

책은 ‘마음가짐 - 실전 사례 - 실무 팁’ 순서로 구성되어 있다.
목차를 보면 책의 성격을 더 쉽게 알 수 있다.
책은 크게
PART 1 마음가짐
PART 2 실전
PART 3 TIPS
로 구성되어 있다.
특히 PART 2에는 실제 코드 리뷰에서 충분히 발생할 수 있는 상황들이 사례별로 정리되어 있다.
예를 들어,
- 긴장감 넘치는 리뷰 코멘트
- 설명이 부족한 PR
- 진행이 더딘 PR
- 지나치게 자세한 리뷰 코멘트
- 리뷰되지 않은 PR
- 코멘트에 대한 정정 정보 부족
- 방치된 논의
- 놓친 질문 코멘트
- 찾아보지도 않고 하는 질문
등 제목만 봐도 개발 과정에서 한 번쯤 마주칠 법한 상황들이 많다.
그래서 이론적인 개발 서적보다는 실제 팀 개발 상황을 옆에서 구경하면서 배우는 느낌에 조금 더 가까웠다.
먼저 필요한 것은 코드가 아니라 ‘마음가짐’

1부에서는 본격적인 사례에 들어가기 전, 코드 리뷰를 어떤 관점에서 바라봐야 하는지 설명한다.
개인적으로 책의 구성이 괜찮다고 느꼈던 부분이다.
바로 사례부터 들어가는 것이 아니라 1부에서 먼저 코드 리뷰를 어떤 마음가짐으로 해야 하는지 설명한다.
코드 리뷰를 하다 보면 자연스럽게
“이 코드가 맞다 / 틀리다”
라는 관점으로 접근하기 쉬운데, 이 책에서는 리뷰의 목적을 단순히 상대방의 잘못을 찾아내는 것으로 보지 않는다.
결국 코드 리뷰의 목적은 더 나은 결과물을 만들기 위해 서로 정보를 주고받고 합의하는 것에 가깝다.
리뷰어는 리뷰이가 생각하지 못했던 부분을 알려줄 수 있고, 반대로 리뷰이 역시 자신이 그렇게 구현한 이유나 배경을 리뷰어에게 알려줄 수 있다.
즉, 리뷰 자체가 일방적인 평가라기보다는 서로의 정보를 보완하는 과정이라는 점이 인상적이었다.
가장 공감됐던 부분, ‘놓친 질문 코멘트’

Case 15 ‘놓친 질문 코멘트’. 질문을 남기는 것만큼 그 질문에 제대로 답변하는 것도 코드 리뷰의 중요한 과정이다.
책에는 여러 사례가 등장하는데 그중 재미있었던 것이 ‘놓친 질문 코멘트’ 사례였다.
PR에 리뷰어가 질문을 남겼는데, 리뷰이가 코드만 수정한 뒤 질문 자체에 대한 답변은 하지 않는 상황이다.
겉으로 보면 이미 코드가 수정되었으니 문제가 해결된 것처럼 보일 수도 있다.
하지만 리뷰어 입장에서는
“왜 이렇게 수정했지?”
“내 질문의 의도를 이해한 건가?”
“다른 이유가 있었던 건가?”
라는 의문이 남는다.
이 사례를 보면서 코드 리뷰에서는 코드를 고치는 것과 커뮤니케이션을 끝내는 것이 같은 의미는 아니라는 점이 꽤 와닿았다.
질문이 있었다면 그 질문에 답변하고, 수정했다면 어떤 방식으로 수정했는지 알려주는 과정까지 포함되어야 하나의 커뮤니케이션이 완성된다.
회사에서 업무를 할 때도 비슷한 것 같다.
요청받은 일을 처리하는 것만큼이나
“확인했습니다.”
“이런 이유로 이렇게 처리했습니다.”
“수정 완료했습니다.”
처럼 상대방에게 결과를 다시 전달하는 과정이 중요하기 때문이다.
개발에서도 결국 같은 원리가 적용된다.
코드만 보고 상대방까지 판단하지 않기
📷 IMG_3569.jpg 삽입
코드 리뷰에서 문제가 되는 것은 코드에 대한 지적이 사람에 대한 지적으로 변하는 순간이다.
또 하나 기억에 남았던 부분은 코드에 대한 의견과 사람에 대한 평가를 구분해야 한다는 것이었다.
코드 리뷰를 하다 보면
“왜 이렇게 작성했어요?”
같은 질문 하나도 상황에 따라서는 상대방에게 공격적으로 느껴질 수 있다.
반대로 리뷰를 받는 사람 역시 단순히 코드에 대한 의견인데도 자신에 대한 평가처럼 받아들일 수 있다.
책에서는 이런 상황에서 코드 자체와 작성자를 분리해서 생각해야 한다는 점을 이야기한다.
예를 들어,
“이 코드는 이해하기 어렵습니다.”
라는 것과
“당신이 작성한 코드는 항상 이해하기 어렵습니다.”
는 전혀 다른 의미다.
첫 번째는 현재 코드에서 개선할 부분을 이야기하지만, 두 번째는 코드가 아니라 작성자 자체를 평가하는 표현이 되어버린다.
코드 리뷰에서 사람이 아니라 코드와 문제에 초점을 맞춰야 한다는 것.
당연한 이야기처럼 보이지만 실제 협업에서는 오히려 가장 놓치기 쉬운 부분이라는 생각이 들었다.
좋은 리뷰 코멘트는 ‘정답을 알려주는 것’과도 조금 다르다
책을 읽으면서 계속 등장하는 키워드 중 하나가 상대방의 상황을 고려하는 것이었다.
리뷰어가 자신의 방식이 무조건 정답이라고 생각하고
“이렇게 바꾸세요.”
라고 말하는 것과,
“이 부분은 이러한 문제가 발생할 수 있는데, 이런 방법을 사용하는 것은 어떨까요?”
라고 이야기하는 것은 같은 내용을 전달하더라도 받아들이는 느낌이 상당히 다르다.
또 리뷰 코멘트의 목적도 구분할 필요가 있다.
단순한 질문인지,
수정을 요청하는 것인지,
참고로 전달하는 것인지,
반드시 해결해야 하는 문제인지
명확하게 표현하면 리뷰를 받는 사람 역시 훨씬 쉽게 대응할 수 있다.
결국 좋은 코드 리뷰는 내가 하고 싶은 말을 쓰는 것이 아니라 상대방이 이해할 수 있도록 쓰는 것이라는 생각이 들었다.
19가지 사례 + 33가지 팁이라 읽기 편하다
이 책에서 마음에 들었던 부분은 내용이 지나치게 이론적으로 흘러가지 않는다는 점이다.
PART 2에서는 실제 사례를 통해 문제 상황과 개선 방법을 보여주고, PART 3에서는 조금 더 짧게 활용할 수 있는 팁들을 정리해준다.
예를 들어 목차에 있는 팁을 살펴보면,
커밋을 나누는 방법, 영향 범위 확인, 상대방의 의도를 단정하지 않는 법, Linter 활용, 리뷰 요청 방법, 질문하는 방법, 효과적으로 재촉하는 방법 등 실제 개발 업무에서 사용할 만한 주제가 많다.
그래서 처음부터 끝까지 순서대로 읽어도 되지만, 나중에는 코드 리뷰를 하다가 고민되는 상황이 생겼을 때 필요한 부분만 찾아보는 식으로 활용해도 괜찮을 것 같다.
기술보다 사람 이야기가 더 많은 개발 책

여러 저자의 실제 개발 및 팀 협업 경험을 바탕으로 작성된 책이다.
저자 소개를 보면 실제 개발자와 개발 조직에서의 경험을 바탕으로 책이 작성되었다는 점도 알 수 있다.
그래서인지 책을 읽으면서
“이론적으로는 이렇게 해야 합니다.”
라고 이야기하는 느낌보다는
“실제로 팀에서 이런 일이 발생하는데, 이런 방식으로 해결해보면 어떨까요?”
라고 이야기하는 느낌이 강했다.
특히 개발 경력이 많지 않거나 아직 코드 리뷰를 많이 경험해보지 않은 개발자라면, 실제 회사에서 어떤 방식으로 리뷰가 진행되는지 간접적으로 경험해보기에도 괜찮아 보였다.
이런 사람에게 추천하고 싶은 책
개인적으로는 코딩 테스트나 프로그래밍 문법을 공부하기 위한 책이라기보다 협업 개발을 준비하거나 실제 팀 개발을 시작한 사람에게 더 잘 맞는 책이라고 느꼈다.
특히 Git과 GitHub를 이용해서 PR을 만들어보기 시작했거나, 회사에서 다른 개발자의 코드를 리뷰해야 하는 사람, 반대로 리뷰를 받을 때 코멘트를 어떻게 받아들이고 대응해야 할지 고민되는 사람에게 도움이 될 만한 내용이 많다.
그리고 의외로 개발자가 아니더라도 공감할 부분이 있다.
책의 많은 내용이 결국
질문하는 법, 의견을 전달하는 법, 상대방의 의도를 단정하지 않는 법, 피드백을 주고받는 법
에 관한 이야기이기 때문이다.
읽고 나서

코드 리뷰의 핵심은 결국 ‘코드’와 ‘사람’ 사이에서 균형을 잡는 것이라는 생각이 들었다.
이 책을 읽기 전에는 코드 리뷰라고 하면 자연스럽게
“잘못된 코드를 찾아내고 수정하는 과정”
이라는 이미지가 가장 먼저 떠올랐다.
하지만 읽고 난 뒤에는 조금 다르게 느껴졌다.
코드 리뷰는 단순히 오류를 찾는 과정이 아니라 한 사람이 작성한 코드를 팀 전체가 이해하고, 더 나은 방향으로 발전시키기 위한 커뮤니케이션 과정에 더 가깝다.
좋은 리뷰어가 되기 위해서는 코드를 많이 아는 것도 중요하지만, 자신의 생각을 정확하게 설명하는 능력도 필요하다.
그리고 리뷰를 받는 입장에서도 단순히 지적을 받았다고 생각하는 것이 아니라 왜 이런 의견이 나왔는지 이해하고 필요한 정보를 다시 전달하는 능력이 필요하다.
결국 개발을 잘한다는 것은 단순히 코드를 잘 작성하는 것만을 의미하지 않는다는 점을 다시 생각해보게 된 책이었다.
코드 작성 방법은 공부하고 있었지만 ‘코드에 대해 어떻게 이야기해야 하는지’는 따로 생각해본 적이 없었다면 한 번 읽어볼 만한 책이다.

좋은 코드를 만드는 것만큼, 좋은 방식으로 코드에 대해 이야기하는 것도 중요하다.
한 줄 평
좋은 코드 리뷰는 상대방의 틀린 점을 찾는 것이 아니라, 함께 더 나은 답을 찾아가는 과정이다.
'책' 카테고리의 다른 글
| 감각 있는 일잘러의 IT 지식 책 리뷰 및 후기 (4) | 2026.03.01 |
|---|