좋은 코드 리뷰 나쁜 코드 리뷰 베타리딩 후기

좋은 코드 리뷰 나쁜 코드 리뷰 - 19가지 사례와 33가지 팁으로 배우는 개발자 말하기와 글쓰기, 좋은 개발팀은 어떻게 리뷰하고 소통하는가?
토리이 유키 외 지음, 시마다 고지 감수, 김성훈 옮김 / 길벗 / 2026년 8월

길벗 리뷰어 활동으로 도서를 제공받아 읽고 솔직하게 작성한 리뷰입니다. #협찬

『좋은 코드 리뷰 나쁜 코드 리뷰』 베타리딩 후기

• 지은이: 토리이 유키, 쿠보 유코, 모로나가 아야카 (감수 시마다 고지 / 옮긴이 김성훈)
• 펴낸곳: 길벗 | 2026년 8월 25일 | 212쪽 | 22,000원
• 원제: 伝わるコードレビュー — 개발팀의 생산성을 높이는 '잘 전달하는 법'의 교과서
• 부제: 19가지 사례와 33가지 팁으로 배우는 개발자 말하기와 글쓰기

리뷰가 힘든 이유는 대개 코드가 아니었다

17년째 개발 현장에 있으면서 코드 리뷰 때문에 팀 분위기가 가라앉는 장면을 여러 번 봤습니다. 그런데 돌이켜보면 그 갈등의 원인이 '기술적으로 누가 맞느냐'였던 적은 거의 없습니다. 문제는 거의 항상 문장이었습니다. 리뷰어는 30초 만에 툭 던진 한 줄인데, 리뷰이는 그 한 줄을 열 번쯤 다시 읽으며 "이거 나 무시하는 건가?"를 고민합니다. 반대로 리뷰이가 아무 설명 없이 올린 500줄짜리 PR 앞에서 리뷰어는 "이걸 어디서부터 봐야 하지?" 하며 며칠을 미룹니다.

이 책은 바로 그 지점만 팝니다. 코드 리뷰를 '버그를 찾는 절차'가 아니라 텍스트로 하는 협업으로 보고, 그 커뮤니케이션을 감각이나 인성의 문제가 아니라 배우고 훈련할 수 있는 기술로 다룹니다. 베타리딩을 하면서 가장 크게 끄덕인 부분이 이 관점이었습니다.

만요(万葉)라는 조직에서 나온 책

저자들은 일본의 개발회사 만요 소속이거나 그와 인연이 깊은 사람들입니다. 만요는 여러 고객사 현장에 투입되는 SES 형태로 일하면서, 기술만큼이나 텍스트 커뮤니케이션의 품질을 중요하게 여겨 왔다고 합니다. 15년 넘게 코드 리뷰를 개발 프로세스이자 사내 교육 수단으로 굴려 온 조직이라는 뜻입니다.

그래서 책의 사례들이 만들어 낸 예시처럼 느껴지지 않습니다. "실제로 이런 코멘트가 오갔고, 이 문장 때문에 이런 오해가 생겼고, 그래서 우리는 이렇게 바꿨다"는 흔적이 남아 있습니다. 매끈한 원칙론이 아니라 시행착오의 기록에 가깝습니다.

3부 구성 — 원칙, 사례, 팁

• PART 1 마음가짐: '전달력 있는 코드 리뷰'가 무엇인지 정의하고 5대 원칙을 세웁니다. 뒤에 나오는 모든 사례와 팁이 이 원칙 위에 얹힙니다.
• PART 2 실전: 19가지 사례. 긴장감 넘치는 리뷰 코멘트, 설명이 부족한 PR, 진행이 더딘 PR, 지나치게 자세한 코멘트, 방치된 논의, 감정적인 코멘트 등 제목만 봐도 "아, 이거 지난주에 우리 팀에서 있었던 일인데" 소리가 나옵니다.
• PART 3 TIPS: 33가지 팁. 퀴즈를 내지 않는다, 명령하지 않는다, 상대의 의도를 단정하지 않는다, 돌려 말하지 않는다, 기한을 명시한다, 리뷰어 지명 로직을 만든다처럼 한 줄로 요약되고 내일 바로 쓸 수 있는 것들입니다.

212쪽으로 얇고, 사례 하나하나가 짧게 끊어져 있어서 앉은자리에서 두어 시간이면 완독됩니다. 대신 다 읽고 덮는 책이라기보다는 팀 위키에 옮겨 적고 두고두고 꺼내 보는 책에 가깝습니다.

밑줄을 그은 네 문장

베타리딩 중 특히 여러 번 되돌아간 대목들입니다.

1. 행간을 읽는 문화보다, 행간을 읽지 않아도 되는 문화를 만들라

"눈치껏 알아듣기"를 팀의 미덕으로 삼는 순간, 그 팀은 신입과 경력자 사이에 보이지 않는 진입장벽을 세우게 됩니다. 필요한 건 더 예민한 독해력이 아니라 더 명시적인 문장입니다.

2. 도구의 지적은 상대의 감정을 헤아릴 필요도, 사과할 필요도 없다

포맷·컨벤션 같은 기계적인 지적을 사람이 계속 하면 리뷰어는 잔소리꾼이 되고 리뷰이는 지적당하는 사람이 됩니다. Linter에 넘길 수 있는 건 전부 넘기고, 사람은 사람만 할 수 있는 논의(설계 의도, 대안, 트레이드오프)에 시간을 쓰자는 이야기입니다. 리뷰 문화 개선을 '말투 교정'으로만 접근하는 팀이 놓치기 쉬운 지점입니다.

3. 리뷰어는 리뷰이의 마음을 읽을 수 있는 초능력자가 아니다

리뷰가 지연되는 책임을 리뷰어에게만 묻는 팀이 많은데, 배경과 전제와 "어디를 봐 주면 좋겠는지"를 적어 주는 건 리뷰이의 몫입니다. 이 책이 리뷰어의 화법뿐 아니라 리뷰를 받는 쪽의 기술을 같은 비중으로 다룬다는 점이 좋았습니다.

4. 갈등 상황에서는 '문제 vs 우리' 구도를 만들라

'나 vs 너'로 놓이는 순간 그 스레드는 이기고 지는 게임이 됩니다. 목표는 상대를 이기는 게 아니라 납득시키는 것이라는 팁과도 이어집니다.

AI가 코드를 쓰는 시대에 오히려 더 필요한 책

요즘 팀에서 올라오는 PR 중 상당수는 사람이 처음부터 손으로 친 코드가 아닙니다. AI가 초안을 만들고 사람이 다듬어 올립니다. 코드를 만들어 내는 비용이 급격히 싸지면서 병목은 검토와 합의 쪽으로 옮겨 왔습니다. PR은 더 자주, 더 크게 올라오는데 그걸 읽고 판단하고 동료를 납득시키는 일은 여전히 사람의 몫입니다.

그래서 이 책의 주제는 유행이 아니라 오히려 시의성이 있습니다. AI에게 리뷰를 시킬 수는 있어도, 리뷰 코멘트 하나 때문에 상한 동료의 마음을 AI가 대신 풀어 주지는 못합니다.

참고할 점 (모두에게 만능은 아닙니다)

솔직하게 적자면, 이 책은 리뷰의 기술적 기준을 알려 주는 책이 아닙니다. 무엇을 리뷰해야 하는지 — 설계 냄새, 성능, 보안, 테스트 커버리지 같은 판단 기준 — 를 기대하고 집으면 얇다고 느낄 수 있습니다. 그건 다른 책의 몫이고, 이 책은 "전달하는 방식"이라는 좁은 주제를 끝까지 파고듭니다.

또 배경이 GitHub 스타일의 PR 리뷰와 일본 SES 조직 문화라서, 사내 규칙이나 조직 구조에 관한 조언은 각자 환경에 맞게 번역해서 읽어야 합니다. 다만 사례 자체는 도구나 언어를 가리지 않아서, Rails를 쓰든 Java를 쓰든 그대로 통합니다.

이런 분께 권합니다

• 리뷰 코멘트를 쓸 때마다 문장을 세 번씩 고쳐 쓰는 주니어
• 지적은 정확한데 팀원들이 자기 PR을 슬슬 피하는 것 같은 시니어
• 리뷰 문화를 만들고 싶은데 "서로 배려합시다" 이상의 구체적인 규칙을 못 만들고 있는 팀 리더
• 신규 입사자 온보딩 자료에 넣을 만한 짧고 실용적인 텍스트가 필요한 팀

읽고 나서 팀에 적용해 볼 것들

1. 리뷰 코멘트에 태그 붙이기 — 반드시 고쳐야 하는 것, 제안, 단순 질문, 취향 문제를 접두어로 구분해 라벨링합니다.
2. Linter/포매터로 넘길 수 있는 지적은 전부 자동화합니다.
3. PR 템플릿에 '배경', '중점적으로 봐 주었으면 하는 곳', '하지 않은 것'을 항목으로 넣습니다.
4. 리뷰어 지명 규칙을 정해 둡니다 — 아무도 자기 일이라고 느끼지 않아서 방치되는 PR을 막습니다.
5. 스레드가 3회 이상 왕복하면 채팅이나 대화로 전환합니다.

한 줄 평

코드 리뷰가 어렵다면 문제는 당신의 실력이 아니라 문장일 수 있습니다. 두 시간이면 읽고, 그다음 몇 년을 두고 써먹을 수 있는 얇고 단단한 책.

아래는 베타리딩 참여 후 책에 실린 추천평입니다.

행간을 읽는 문화보다 행간을 읽지 않아도 되는 문화를 만들라, 도구의 지적은 상대의 감정을 헤아릴 필요도, 사과할 필요도 없다, 리뷰어는 리뷰이의 마음을 읽을 수 있는 초능력자가 아니다, 갈등 상황에서 '문제 vs 우리' 구도를 만들라는 조언 등 그대로 인용해 팀 위키에 올리고 싶은 문장이 많았습니다.

— 이석곤 (아이알컴퍼니 17년차 AI&빅데이터 개발자)