DarkGarden

Topics

Sections

Mastering the Code Review Process - Pete Muldoon - CppCon 2025

70 min read

Mastering the Code Review Process - Pete Muldoon - CppCon 2025

📺 원본 영상: Mastering the Code Review Process - Pete Muldoon - CppCon 2025
🎙️ 채널: CppCon
📅 정리 일자: 2026-01-29
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.

개요

Bloomberg의 시니어 엔지니어 Pete Muldoon이 CppCon 2025에서 발표한 이 강연은 코드 리뷰의 “기술적 디테일”이 아닌 “프로세스 자체”에 초점을 맞춘다. 21년간 컨설턴트로 수많은 조직의 코드 리뷰 문화를 관찰하고, 최근 1년간 Bloomberg 내부에서 코드 리뷰 프로세스 개선을 주도한 그의 경험을 바탕으로, 코드 리뷰가 단순히 “코드의 정확성 검증”을 넘어 “코드베이스의 장기적 건강성 유지”와 “팀 협업 문화 형성”의 핵심 도구가 되어야 한다고 강조한다. 이 강연에서는 효과적인 코드 리뷰를 위한 체크리스트 설계, 타이밍 관리, 메트릭 추적, AI 활용 자동화 기법까지 실무에 즉시 적용 가능한 구체적인 방법론을 다룬다.

코드 리뷰의 본질: 프로세스가 우선이다

Pete Muldoon은 강연의 시작부터 명확히 선을 긋는다. “이 강연은 코드 리뷰 그 자체(code review)가 아니라 코드 리뷰 프로세스(code review process)에 관한 것”이라고. 그는 1991년부터 C++을 사용해온 베테랑 엔지니어로, 표준 라이브러리조차 없던 시절부터 소프트웨어를 개발해왔다. 21년간 컨설턴트로 활동하며 수많은 기업과 팀의 코드 리뷰 문화를 직접 목격했고, 현재는 Bloomberg의 Ticker Plant 팀에서 전 세계 거래소의 실시간 데이터를 처리하는 시스템을 담당하고 있다.

강연자가 강조하는 핵심은 이것이다. 엔지니어들은 종종 코드의 구문적 디테일(syntax)에 집착하지만, 정작 중요한 것은 “어떻게 코드 리뷰를 수행하는가”라는 엔지니어링 원칙이다. 들여쓰기, 카멜케이스, 언더스코어 같은 포맷팅 논쟁은 자동화 도구로 해결할 문제이며, 진짜 문제는 코드 리뷰가 팀의 생산성을 죽이는 병목이 되고 있다는 현실이다. 그는 “코드 리뷰를 제대로 하지 않으면 코드베이스는 결국 재작성(rewrite)을 향해 간다”고 경고한다.

코드 리뷰의 목표: 정확성을 넘어서

강연자는 청중에게 질문을 던진다. “코드 리뷰의 핵심 목표(core objectives)는 무엇인가?” 청중은 “품질(quality)”, “정확성(correctness)”, “유지보수성(maintainability)“을 답한다. 강연자는 이를 인정하면서도, 이것만으로는 불완전하다고 지적한다. 코드 리뷰의 목표는 세 가지 축으로 정의되어야 한다.

첫째, 비즈니스 가치 제공이다. 아무리 완벽한 코드라도 프로덕션에 배포되지 않으면 의미가 없다. 코드 리뷰가 지나치게 엄격하거나 느리면, 새로운 기능 제공이 지연되고 결국 비즈니스 기회를 잃는다. 강연자는 “코드가 프로덕션 어디에나 배포되는 것(everywhere in production)“을 자신의 “최소한의 완료 정의(minimum definition of done)“라고 말한다.

둘째, 장기적 코드베이스 건강성 유지이다. 많은 팀이 정확성(correctness)에만 집착하지만, 진짜 문제는 코드베이스가 시간이 지나면서 얼마나 지속 가능한가(sustainability)이다. 빠른 기능 개발과 버그 수정에만 집중하면, 몇 년 후 코드베이스는 재작성이 불가피한 상태로 악화된다.

셋째, 지식 공유와 책임 분산이다. 코드 리뷰는 단순히 실수를 잡는 도구가 아니라, 주니어 개발자를 교육하고 팀 전체의 역량을 높이는 기회다. 또한 리뷰어는 단순히 조언자가 아니라, 해당 코드에 대한 공동 책임(shared responsibility)을 지는 사람이다. 강연자의 배지에는 이런 문구가 적혀 있다고 한다. “프로덕션에서 문제가 생기면 개발자가 아닌 리뷰어를 찾아가라(A problem in production, go after the reviewer not the developer).” 리뷰어는 자신의 이름이 그 코드에 붙어 있다는 책임감을 가져야 한다.

코드 리뷰가 실패하는 이유: 프로세스의 부재

강연자는 SmartBear의 5년 전 조사를 인용한다. 설문 응답자의 24%가 “코드 리뷰가 코드 품질 향상의 1순위 방법”이라고 답했고, 그 다음이 유닛 테스트(unit testing)였다. 흥미롭게도 이 두 가지는 강연자가 지난 1년간 Bloomberg에서 집중적으로 개선해온 항목이기도 하다. 그는 코드 리뷰를 “코드베이스를 지속 가능하게 유지하는 마지막 방어선(last line of defense)“이라고 정의한다. 개발자는 코드를 작성하는 것보다 읽는 시간이 훨씬 많으며, 코드 리뷰는 좋은 관행을 확산시키는 힘의 배수(force multiplier)가 될 수 있다.

하지만 현실은 어떤가? 강연자는 청중에게 묻는다. “코드 리뷰 프로세스에 문제가 있다고 생각하는 사람?” 대부분의 손이 올라간다. “코드 리뷰를 받는 사람?” 거의 모두가 손을 든다. “코드 리뷰를 하는 사람?” 역시 거의 모두다. “당신이 그 문제의 일부일 수 있다(You might be part of that problem)“라는 그의 농담은 웃음을 자아내지만, 동시에 뼈아픈 진실을 담고 있다.

강연자가 목격한 전형적인 문제들은 다음과 같다. Pull Request(PR)가 일주일, 심지어 한 달 동안 방치되는 경우가 흔하다. 거대하고 복잡한 PR이 반복적으로 제출되어 리뷰어가 압도당한다. 테스트 커버리지가 들쭉날쭉하여, 리팩토링을 시도하면 프로덕션이 터진다. 자전거 헛간 효과(bike shedding)가 만연하여, 중요한 아키텍처 문제는 회피하고 변수명이나 들여쓰기 같은 사소한 것만 논쟁한다. 팀 간에 “무엇이 좋은 코드인가”에 대한 기준이 제각각이다. 이 모든 것이 프로세스의 부재에서 비롯된다.

코드 리뷰 준비: 제출 전 체크리스트

강연자는 묻는다. “PR을 제출하기 전에 무엇을 해야 하나?” 청중 중 한 명이 “스스로 리뷰하라(review it yourself)“고 답하지만, 강연자는 “아무도 그렇게 안 한다(No one does that)“며 웃는다. 그는 명확한 체크리스트를 제시한다.

첫째, 정적 분석과 경고 제거이다. 컴파일 시 경고(warnings)가 수없이 쏟아지는 코드베이스를 강연자는 극도로 싫어한다. 경고 속에 실제 에러가 묻혀 있으면, 다시 페이지를 뒤져 찾아야 한다. 개발 중에는 경고를 무시할 수 있어도, 프로덕션 빌드에서는 절대 안 된다.

둘째, 모든 유닛 테스트와 통합 테스트 통과이다. 만약 관찰 가능한 동작(observable behavior)이 변경되었다면, 새로운 테스트가 반드시 추가되어야 한다. 강연자는 “테스트를 추가하지 않은 이유에 대한 온갖 변명”을 들어왔다고 한다. 결국 그 변명은 “이 코드는 테스트되지 않았고, 테스트 불가능하다(untested and untestable)“는 뜻이다. 이는 아무도 코드에 테스트 가능성(testability)을 요구하지 않았기 때문에 방치된 결과다.

**셋째, 자기 리뷰(self-review)**이다. 명백히 어리석은 실수(silly mistakes)는 제출 전에 스스로 잡아야 한다. 예를 들어 함수에 상수 참조(constant reference)를 전달하는 것 같은, 명백히 잘못된 코드를 리뷰어가 발견해서는 안 된다. 강연자는 AI를 활용해 자기 리뷰를 보조할 수 있다고 제안하지만, AI는 문제를 지적하면 항상 “당신이 절대적으로 옳습니다(you’re absolutely correct)“라고 답한다며 농담을 던진다. 그는 “거짓말을 던져도 AI가 동의할지 궁금하다”고 덧붙인다.

**넷째, 적절한 제목과 설명(title and description)**이다. 강연자는 이 부분에 대해 특히 강하게 말한다. “I’m fixing a bug”같은 제목은 거의 아무런 정보도 주지 않는다. 특히 테스트조차 첨부되지 않았을 때는 더욱 그렇다. 그는 “제목을 쓸 때 영어를 잊어버린 것처럼 마치 네 살짜리가 쓴 것 같다”고 비꼰다. 설명란(description)에 아무것도 쓰지 않은 PR도 흔하며, 심지어 “적절한 제목이 제공될 때까지 체크인하지 마시오(do not check in till a proper title is provided)“라는 문구가 붙은 PR이 실제로 체크인되는 경우도 봤다고 한다.

강연자는 세 가지를 명확히 써야 한다고 강조한다. **무엇(What)**을 하는가? Diff에서 추론할 수 있을지 모르지만, 의도하지 않은 부수 효과(side effect)가 있을 수 있다. 왜(Why) 하는가? “새로운 거래 기능을 추가한다” 또는 “거래소에서 새로운 틱 유형이 들어오기 때문”처럼 구체적인 이유를 밝혀야 한다. 어떻게(How) 검증했는가? “그냥 괜찮을 것(it’ll be gracious)“이 아니라, “이러한 테스트를 추가했다”고 명시해야 한다.

강연자는 청중의 반론에 대비한다. “새로운 기능이면 어떻게 하나?” 또는 “문맥을 파악하려면 티켓이나 이슈를 찾아봐야 하지 않나?” 강연자는 단호히 답한다. “코드 리뷰를 할 때 범죄 수사(forensic hunt)를 하고 싶지 않다. 그게 프로세스를 갈아먹는(grinds up the gears) 요인이다. 당신이 그렇게 하고 싶으면 하라. 하지만 난 거기 있고 싶지 않다.”

리뷰어를 배려하라: 인지 부하(Cognitive Load) 줄이기

강연자는 강력히 주장한다. “리뷰어를 배려하면(take it easy on your reviewers), 리뷰가 매우 철저해지고, 좋은 피드백을 받으며, 프로세스를 빠르게 통과한다.” 리뷰어의 인지 부하를 줄이는 것이 핵심이다.

PR의 크기(scope)를 제한하라. 강연자는 5,000개 파일이 변경된 PR을 본 적이 있다고 한다. 청중에게 묻는다. “5,000개 파일이 변경되고 매우 까다로운 작업을 하는 PR이 있다면, 당신 회사는 어디인가? 아직 살아있는 회사인가?” 거대한 PR은 리뷰어를 압도하며, 승인 버튼을 누르기가 두렵다. 강연자는 한 팀에게 “이 PR이 너무 크다, 단계별로 쪼개야 한다”고 말했지만, 개발자는 “쪼갤 수 없다”고 답했다. 강연자가 “여기, 여기, 여기서 쪼갤 수 있다”고 구체적으로 지적하자, 그 개발자는 놀랍게도 이렇게 답했다. “만약 첫 PR이 승인되면, 마지막 PR을 리뷰하는 사람은 처음에 무슨 일이 있었는지 모를 것이다. 그 문맥을 놓치게 된다.” 강연자는 이것이 **마인드셋 문제(mindset problem)**라고 지적한다. 인터페이스가 제대로 설계되었다면, 뒤의 구현을 알 필요 없이 앞의 인터페이스만 이해하면 된다. “전체 코드베이스를 알아야 어떤 코드든 사용할 수 있다”는 발상은 잘못된 개발 문화다.

주요 변경 위치를 강조하라. 만약 50~60개 파일이 변경되었지만 핵심은 1~2개 파일에 집중되어 있다면, “변경의 핵심은 여기에 있다. 나머지는 단지 50~60개 파일에 새로운 호출을 추가한 것일 뿐”이라고 명시하라.

Draft PR에 대한 오해를 풀어라. 강연자는 초기 발표 연습에서 Draft PR을 언급하지 않았지만, 청중이 계속 물어서 추가했다고 한다. Draft PR은 체크인되는 것이 아니다(not something you check in). Draft는 조기 피드백(early feedback), 방향 확인, 도움 요청을 위한 것이다. 인터페이스가 엉성하거나, 역사적으로 숨겨진 “지뢰”를 모를 때 사용한다. 하지만 Draft에서 “리뷰 준비 완료”로 전환하는 순간, 모든 엄격한 규칙이 적용된다.

코드 리뷰 타임라인: 속도가 생명이다

강연자는 코드 리뷰의 전형적인 생명주기(lifetime)를 도식화한다. 코드 개발 → 초기 리뷰 요청 → 피드백 수신 → 피드백 반영 후 재요청 → 최종 리뷰 → 승인 → 머지. 여기서 가장 큰 문제는 **대기 시간(wait time)**이다. 강연자는 묻는다. “이 프로세스를 어떻게 대폭 단축할 수 있나? 리뷰어를 재촉하는 것(rushing)이 아니라, 어떻게?” 청중은 답하지 못한다. 강연자는 코드에서 병목을 찾듯이, 프로세스에서 대기(waits)를 찾아 제거해야 한다고 말한다.

강연자의 해법은 명확하다. **리뷰 시작을 위한 24시간 윈도우(24-hour window)**를 설정하라. 과거 팀을 이끌 때, 매일 아침 스탠드업(stand-up)에서 이렇게 물었다고 한다. “어제 리뷰를 제출한 사람?” “그 리뷰를 받아야 하는 사람은?” “리뷰가 누락된 사람은?” 그리고 이렇게 말한다. “아, Fred가 아직 리뷰를 안 했네요.” Fred를 바로 문책하지는 않지만, 모든 사람 앞에서 가시화(visible)된다. Fred는 “미팅 직후에 하겠습니다”라고 답한다. 몇 번만 이렇게 하면, 더 이상 지적할 필요가 없다. 사람들은 스스로 습관을 들이게 된다.

강연자가 이 제안을 팀에게 했을 때, 그들은 “기절할 듯이 의자에서 떨어질 뻔했다(almost swoon and fall off the seat)“고 한다. “만약 엄청나게 큰 리뷰라면 24시간 안에 못 끝낸다!” 강연자는 답한다. “24시간 안에 **시작(start)**하라는 것이다. 대부분의 리뷰는 20분에서 1시간 정도면 끝난다. 정규분포로 그리면 3 표준편차 안에 들어갈 것이다.” 사람들은 예외(outliers)만 들먹인다. “엄청 큰 리뷰라면?” “유일하게 리뷰할 수 있는 사람이 휴가 중이라면?” 강연자는 반박한다. “그 사람이 Cabo에서 일광욕하는 동안 모두가 기다려야 한다니, 팀에 무슨 문제가 있는 건가?”

가이드라인은 대부분(most)에 적용되는 것이지, 모든(every) 리뷰에 적용되는 게 아니다. 유연성은 필요하다. 하지만 “나중에 처리하겠다(we’ll get to it later)“는 말이 반복되면, 프로세스는 막힌다.

대기가 쌓이면 머지 충돌(merge conflicts)이 악몽이 된다. PR이 2주 동안 방치되면, 다른 20개 팀이 코드베이스에 변경을 푸시한다. 작은 수정을 반영하려 해도 머지가 충돌하고, 다시 문맥을 머리에 로드해야 한다. 이것이 프로덕션 도달 시간을 늘린다.

강연자는 SmartBear 조사를 다시 인용한다. “얼마나 자주 코드 리뷰에 참여하는가?”와 “코드 리뷰 프로세스에 얼마나 만족하는가?”를 비교한 결과, 매일(daily) 리뷰하는 팀이 가장 만족도가 높았다. 주간, 격주, 월간, 분기별 리뷰로 갈수록 만족도는 떨어진다. 강연자는 24시간이 이상적이지만, 팀이 불가능하다면 2일, 3일이라도 명시적으로 정하라고 권한다. 중요한 것은 기준을 세우고 책임을 명확히 하는 것이다.

PR을 머지하는 책임은 누구에게 있나? 강연자는 “개발자(developer)“라고 답한다. 청중도 동의한다. 코드를 작성하고 승인을 받았으면, 개발자가 머지까지 책임져야 한다. “내 일은 끝났으니 누군가 알아서 머지하겠지”라는 태도는 프로세스를 방치하는 것이다.

피드백 카테고리: 이모지로 명확히 하라

강연자는 코드를 볼 때 세 가지 유형의 피드백을 제시한다고 말한다. 첫째, **구조적으로 문제가 있는 것(structurally unsound)**이다. 이것은 수정되어야 한다. 강연자는 빨간 이모지(red emoji)를 사용한다. 둘째, 더 나은 대안이 있다고 생각하는 것이다. “이렇게 하는 게 어떤가요?”라는 제안이며, 강연자는 망치와 스패너 이모지(hammer and spanner)를 사용한다. 이것은 논의가 필요하며, 개발자가 고려하지 않으면 승인을 보류할 수 있다. 셋째, **사소한 선호(nitpick)**다. “이렇게 하는 건 어때요?” 정도의 개인 취향이며, 강연자는 픽(pick) 이모지를 사용한다. 개발자는 이를 받아들이거나 무시할 수 있다.

하지만 이 세 가지만으로는 부족하다. 강연자는 두 가지를 더 추가한다. 넷째, **질문(question)**이다. “이게 어떻게 동작하는지 모르겠다”거나 “이 부분 설명 좀 해주세요.” 이 질문에 답을 받아야 제대로 된 피드백을 줄 수 있다. 다섯째, **칭찬(praise)**이다. “이 부분 정말 잘했네요!” 강연자는 청중에게 묻는다. “코드 리뷰에서 칭찬을 하는 사람?” 약 1/3만 손을 든다. 강연자는 웃으며 말한다. “당신들은 좋은 사람들이다. 나머지를 좀 쳐다보세요. 그냥 응시하세요.”

중요한 것은 피드백의 카테고리를 명확히 표시하는 것이다. 이모지를 쓰든, 태그를 쓰든, 방법은 상관없다. 강연자는 이렇게 말한다. “나는 가장 부드럽고 공감적인 언어로 문제를 지적할 수 있다. 하지만 빨간 이모지가 붙어 있으면, 그건 절대 넘어가지 않는다. 동시에 개발자의 기분을 상하게 하지도 않는다.” 강연자는 리뷰를 시작할 때 작은 키(legend)를 첨부해 이모지의 의미를 설명한다고 한다.

코드 리뷰의 Do’s: 체크리스트와 협업

강연자는 코드 리뷰에서 **반드시 해야 할 것들(do’s)**을 나열한다. 첫째, 기본 사항을 표준화하라. 짧은 체크리스트로 일관성을 유지하라. 강연자는 묻는다. “회사의 모든 팀이 일관된 코드 리뷰를 한다고 생각하는 사람?” 아무도 손을 들지 않는다. “왜 그럴까?” 전기 기사가 소켓을 아무렇게나 연결하고 가면, 집이 불에 탈 수 있다. 배관공도 마찬가지다. 이들 직업에는 절대적인 규범(code)이 있다. 소프트웨어 엔지니어도 최소한의 가이드라인이 있어야 한다. “이 코드는 괜찮다. 옆의 형편없는 코드와 똑같으니까(The same as the other crappy code over here)“라는 논리는 잘못됐다. **그 변화(be that change)**가 되어야 한다.

둘째, 코드 리뷰를 협업과 도움의 기회로 보라. 강연자는 자신이 신뢰하는 유능한 리뷰어들을 코드 리뷰에 초대하는 것을 좋아한다고 한다. “나는 내가 제안받은 해결책이 더 나았다는 걸 인정하는 데 자존심이 상하지 않는다. 정말 도움이 됐다고 말할 수 있다.” 코드 리뷰는 공개적으로 질책당하는 처벌이 아니라, 함께 배우는 과정이어야 한다.

셋째, 기술을 훈련하라. 강연자는 묻는다. “코드 리뷰 교육 과정을 들은 사람?” 거의 없다. “아마 존재하지도 않을 거다. 어쩌면 내가 CppCon 2026에서 ‘코드 리뷰 하는 법(How to do code reviews)‘을 발표해야 할지도 모르겠다.” 팀에는 “이 사람의 리뷰를 받고 싶다. 문제를 잘 찾고, 기분 상하게 하지도 않는다”는 평가를 받는 사람이 있다. 그런 역량을 훈련하고 전파해야 한다.

넷째, 지속적인 교육이다. C++ 언어는 빠르게 진화하고 있다. 컨퍼런스에 오는 것도 좋고, 영상을 보는 것도 좋다. 또는 팀에서 수요일 오후 1시간을 할애해 컨퍼런스 토크를 함께 보고, 그것을 자신들의 작업에 어떻게 적용할지 논의하는 “북 클럽(book club)” 또는 “비디오 클럽(video club)“을 운영하라.

다섯째, 테스트를 제대로 리뷰하라. 강연자는 이 부분을 특히 강조한다. “테스트가 있으니 괜찮겠지”라고 가정하지 마라. 유닛 테스트와 통합 테스트가 있는가? 정상 경로(happy path)와 비정상 경로(unhappy path)를 모두 다루는가? 엣지 케이스(corner cases)를 테스트하는가? 테스트 이름이 명확한가? 매직 넘버(magic numbers)를 사용하지 않는가? 강연자는 테스트 이름이 “works_good_1”, “works_good_2”, “works_good_3” 같은 것을 본 적이 있다고 한다. 이런 이름으로는 무엇을 테스트하는지 알 수 없다. 대신 “이런 조건에서 이런 거래를 실행할 때(executing this type of trade with this condition)“처럼 구체적으로 써야 한다. 또한 테스트에 “expect(price, 1.35725)“같은 매직 넘버가 있으면, 그 의미를 알기 위해 코드베이스를 뒤져야 한다. 대신 “expected_price = 1.35725; expect(retrieve_price, expected_price)“처럼 의미를 명시하라. 테스트는 코드 동작을 이해하는 문서가 되어야 하며, 복잡하게 꼬여 있어서는 안 된다.

코드 리뷰의 Don’ts: 나쁜 선입견과 일관성의 함정

강연자는 **피해야 할 것들(don’ts)**도 제시한다. 첫째, **나쁜 선입견(bad preconceptions)**을 갖지 마라. “이 코드는 주변의 다른 코드와 똑같아 보이니까 괜찮다.” 과거에는 지구가 평평하다는 모델(flat-earth model)이 통했다. 하지만 지구를 한 바퀴 돌 수 있다는 걸 알게 되면서 구형 모델(globe)로 바뀌었다. 일관성이라는 이름으로 나쁜 습관을 유지하지 마라. 이것은 새로운 기능과 더 나은 엔지니어링 관행을 막는다.

레거시 코드베이스는 이 문제로 심각하게 고통받는다. 그 코드는 엔지니어링 지식이 부족했던 시절, 언어 기능도 부족했던 시절에 작성되었다. 모든 것을 직접 작성해야 했고, 품질은 들쭉날쭉하다. 강연자는 “일관된 모양과 느낌(look and feel)은 중요하지만, 많은 스타일 가이드가 이것에만 집착한다”고 지적한다. **일관성(consistency)은 때때로 발전의 적(enemy of progress)**이 될 수 있다. 뇌를 쓰지 않고 옛날 방식을 고수하는 것은 잘못이다.

강연자는 1995년 스타일의 인터페이스를 고집하는 팀을 만난 적이 있다고 한다. raw 포인터, in-out 매개변수가 가득했다. 그는 “optional이나 variant를 쓸 수 있다”고 제안했지만, 그들은 “포인터가 정말 효율적이다(pointers are really efficient)“라고 답했다. 강연자는 말한다. “그건 25년간의 발전을 무시하는 것이다. 우리는 포인터를 언어에서 빼내려고 노력해왔다. 지금 우리가 포인터라고 부르는 것(unique_ptr, shared_ptr)은 포인터 의미론(pointer semantics)을 가질 뿐, 진짜 포인터가 아니다.”

반대로 모든 새로운 기능을 무분별하게 남용하는 것도 문제다. “모든 걸 코루틴(coroutine)으로 만들어야 해. 모든 걸 최신 핫한 기능으로 만들어야 해.” 곧 리플렉션(reflection)이 나오면 “사람들이 이상한 짓을 할 것”이라고 강연자는 예언한다. “이거 봐, 얼마나 귀여운가!”라며 복잡하게 꼬아놓은 코드를 자랑하는 사람들이 나타날 것이다. 변화를 위한 변화(change for change’s sake)는 아무 데도 가지 않는 길이다.

강연자는 한 팀 리드(TL)가 찾아와 이렇게 말한 경험을 공유한다. “우리는 이 코드를 더 나아지게 리팩토링해야 한다고 했습니다. 그런데 제 팀원들이 코드를 이리저리 옮겼지만, 실제로 뭘 했는지 모르겠습니다.” 강연자는 묻는다. “왜 리팩토링을 하나요?” “테스트 가능성(testability)을 위해서요.” “테스트가 있나요?” “아니요. 테스트는 다음 리팩토링에서 들어옵니다.” 강연자는 말한다. “나는 의심이 많은 사람이다. 절대 안 들어온다. 거짓말인 걸 알지 못할 수도 있지만, 분명히 거짓말이다.” 또 다른 경우는 테스트가 없는 PR에 대해 “테스트는 바로 뒤따라오는 PR에 있습니다”라고 말하는 것이다. 강연자는 단언한다. “절대 안 온다(never does).”

메트릭: 프로세스를 측정하라

강연자는 “하드 데이터를 좋아한다(I like hard data)“며, 프로세스의 효과를 어떻게 측정하는지 설명한다. “그냥 팀에 더 행복한 분위기가 도는 것 같아요”는 좋지만 충분하지 않다. 측정(measurement)을 해야 한다.

**첫 번째 메트릭: PR당 테스트 비율(tests per PR)**이다. 테스트가 있는 PR 수 대 전체 PR 수의 비율이다. 강연자가 이를 측정했을 때, “정말 좋지 않은 소식(wasn’t really good news)“이었다고 한다. 그는 관리자들에게 가서 히트맵(heat map)을 보여줬다. 조직 전체를 팀별로 나눠 색으로 표시했다. 진한 색은 테스트가 많은 팀, 연한 색은 테스트가 없는 팀이다. “어디에 사랑과 관심이 필요한지 한눈에 볼 수 있다. 이 조직 부분에는 테스트를 넣지 않는 무언가가 있다.”

**두 번째 메트릭: 생성된 PR 대 머지된 PR(created vs merged PRs per group)**이다. 만약 머지보다 생성이 지속적으로 많으면, 백로그가 쌓이고 있다는 뜻이다. 백로그가 커지면 무슨 일이 일어나나? 잊혀진다.

**세 번째 메트릭: 리뷰 시작 시간(time to review)**이다. 강연자는 이것에 특히 집착한다. 그는 팀의 Chris에게 Git 저장소에서 가능한 모든 정보를 추출하는 도구를 작성해달라고 했다고 한다. 시간, 리뷰어, 팀 소속, 변경된 파일 유형 등 모든 것을 추출해 메트릭을 뽑아낸다. 만약 어떤 그룹이 평균 2주 동안 코멘트를 받기 시작조차 하지 않는다면, “그들에게 사랑을 좀 줘야 한다(we have to go and give them some love).”

💡 [영상 참조] 강연자는 이 시점에서 화면에 메트릭 차트를 보여주며 설명합니다. 상세 내용은 원본 영상을 확인하세요.

강연자는 흥미로운 조사 결과를 공유한다. SmartBear 조사에 따르면 메트릭을 사용하는 팀이 그렇지 않은 팀보다 3배 더 만족한다고 한다. 강연자는 솔직히 “사람들이 내가 메트릭을 돌리는 걸 좋아할 리 없다”고 생각했지만, 메트릭이 개선되면 사람들이 실제로 만족한다고 말한다. “우리 PR의 20%가 테스트가 있었는데, 이제 60%로 올랐고, 다음 분기에는 80%를 목표로 한다”고 말할 수 있다면, 누가 기분 나쁠까?

Blast Radius: 위험도에 따른 리뷰 전략

강연자는 모든 PR이 동일하지 않다는 점을 강조한다. **Blast Radius(폭발 반경)**이라는 개념을 도입한다. 작은 기능적 변경, 단일 정답이 명확한 낮은 위험의 변경이 있다. 이런 경우에도 테스트를 작성해야 한다. 강연자는 “위험이 아무리 낮아도 테스트를 써라(I don’t care how low the risk is, write a test for it)“고 단호히 말한다.

반면 더 큰 아키텍처 변경(architectural changes)이 있다. 예를 들어 파일 기반에서 클라우드로 이동하는 것 같은 변경이다. 이런 경우 훨씬 더 신중해야 한다. 특히 새로운 공개 인터페이스(public interface)를 내놓거나 확장할 때는 더욱 그렇다. 일단 공개하면 변경할 수 없기 때문이다. 더 많은 위험 고려가 필요하다. 아키텍처 설계 기록(Architectural Design Record, ADR)에 따르고 있는가? 아니면 방향을 벗어났는가?

강연자는 리뷰어 구성을 위험도에 따라 조정하라고 제안한다. 작은 코드 리뷰는 동료(peers)와 팀 리드(TL)로 충분하다. 하지만 더 심각한(severe) 변경이라면, 역사적 지식을 가진 사람들(historical people)을 불러야 한다. “시체가 어디 묻혀 있는지 아는 사람(They know where the bodies are buried). 아마 그들이 묻었을 것이다.” 이들은 당신이 모르는 함정을 안다. “오랫동안 있었으니, 이게 통할까요?”라고 물으면 도움이 된다. 또한 아키텍처 전문가(architectural expert)가 필요하다. 여기서 전문가란 단순히 코드베이스를 잘 아는 사람이 아니라, 컨퍼런스를 다니고 논문과 책을 읽으며 업계 트렌드를 따라가는 사람이다. 그래야 “황제의 새 옷(emperor with new clothes)“이 되는 것을 막을 수 있다.

강연자는 **하나 이상의 리뷰어 또는 승인자(more than one reviewer or approver)**를 항상 권장한다. “한 명만 리뷰하는 건 싫다.” 누군가 “정말 작은 변경인데, 왜 두 명이 리뷰해야 하나요?”라고 물으면, 강연자는 “주석만 바꾸는 거면 그냥 넣어라. 하지만 그건 예외다”라고 답한다. 심각도가 높아질수록 더 신중하고 더 많은 사람을 포함해야 한다.

코드 리뷰 생애주기: PR 생성 전후의 흐름

강연자는 자신의 가이드라인 문서에서 코드 리뷰의 생애주기를 단계별로 정리한 내용을 소개한다.

PR 생성 전: 중요한 변경이라면 **설계 리뷰(design review)**를 할 수 있다. 어디로 가고 있는지 아이디어를 공유한다. 프리랜싱(freelancing)하지 않는다. 또한 팀 논의(team discussions)나 비공식 페어 프로그래밍(pair programming)을 할 수 있다.

PR 생성: Draft PR을 만들 수 있다. 이는 선택 사항이다. 조기 피드백이 필요하면 사용한다. 그 후 **메인 PR 제출(main PR submission)**을 한다. “제발 리뷰해 주세요.”

PR 이후: 많은 논쟁이 있거나 중요한 변경이라면 **리뷰 미팅(review meeting)**을 가져야 한다. 단순히 두 사람이 뒤에서 담합(colluding)하는 게 아니라, 더 많은 사람을 프로세스에 포함시켜야 한다. 그 후 승인되면, 모두가 합리적으로 동의하고 테스트를 좋아한다면 **머지(merge)**한다.

이 모든 과정이 체계적으로 진행되면, 나쁜 일(bad stuff)이 일어나지 않는다.

좋은 문화 강화: 체크리스트와 코칭

강연자는 좋은 코드 리뷰 문화를 강화하는 방법을 제시한다. 첫째, **체크리스트(checklist)**를 사용하라. 이것은 표준화하고 논쟁을 줄인다. “가이드라인에 이렇게 나와 있다. 그래서 이렇게 해야 한다.” 일반적인 실수(common mistakes)를 체크리스트에 추가하라. 하지만 체크리스트는 짧아야 한다. 너무 길면 아무도 보지 않는다. 강연자는 2페이지가 이상적이라고 본다.

둘째, **코드 리뷰 코칭과 페어링(code review coaching and pairing)**이다. 강연자는 한 번은 새로운 팀과 함께 앉아 코드 리뷰를 처음부터 끝까지 워크스루(walk through)했다고 한다. “이것은 그들에게 현대적인 방식으로 구조적 코드를 작성하고 리뷰를 준비하는 법을 교육하는 가장 강력한 도구였다.”

셋째, **팀 리뷰 워크스루(team review walkthroughs)**이다. 전체 팀이 모여 어떤 PR을 함께 본다. 사람들이 어떻게 생각하는지 통찰을 얻고, 관행을 따르고 있는지 확인한다. 단, 조심해야 할 것은 “오늘은 이 사람 PR을 모두가 공격하는 날”처럼 만들지 않는 것이다. 목표는 집단 교육이지 개인 공격이 아니다.

넷째, 메트릭을 돌려라. 사람들이 “우리 잘하고 있다”고 말하면, “여기 메트릭이 있는데, 잘하는 것 같지 않다”고 보여준다. 그때 변명이 시작된다. 하지만 시간이 지나면 사람들은 구조적으로 올바른 일을 하는 습관을 들이게 된다. 서로가 서로를 감시(policing)하기 때문이다.

건설적 피드백 주는 법: 비난이 아닌 질문으로

강연자는 “어떻게 건설적인 피드백을 주고, 팀원들이 서로 싸우지 않게 할까?”를 다룬다. 팀이 두 파로 나뉘어 “저쪽은 미쳤다” “저쪽은 무슨 말을 하는지 모른다”고 하는 상황을 피하는 법이다.

첫째, 구체적인 용어(specific terms)로 피드백하라. “이거 형편없다. 틀렸다(This sucks. It’s wrong)” 같은 말 대신, “이 객체의 생명 주기(lifetime)에 문제가 있을 것 같습니다”라고 말하라. 왜(why) 문제인지 설명하라. “바보라면 다 알 수 있는 거 아닌가요(any idiot can figure that out)“라고 말하지 마라. 왜냐하면 명백히 그들은 모르기 때문이다.

둘째, 좋은 코드를 칭찬하라. 그리고 나쁜 것을 지적할 때도, 질문 형태로 하라. “이렇게 해보는 건 어떤가요? 이런 상황은 고려했나요?” “이건 틀렸어. 바보 같아. 이게 문제야”라고 하지 마라.

셋째, 코드를 리뷰하지 개발자를 리뷰하지 마라(Don’t review the developer). 인간이기 때문에 화가 날 수 있다. 리뷰에서 개인적 공격으로 빠지고 싶은 유혹이 있다. 하지만 그렇게 하지 마라(don’t be a detractor, don’t be a Debbie downer).

일반적인 함정: 지연, 과부하, 피로

강연자는 코드 리뷰에서 **흔한 마찰 지점(common pitfalls)**을 정리한다. 첫째, **느린 리뷰(slow reviews)**다. 시작이 느리고, 결국 급하게 처리되어 나쁜 피드백을 주고, 프로덕션에서 문제가 생긴다. 둘째, **크고 복잡한 PR(large complicated PRs)**을 주는 것이다. “나는 2주 동안 이걸 했다. 당신은 1시간 안에 내가 2주 동안 한 걸 소화해야 한다. 나는 25번 커밋했지만, 당신은 마지막 커밋만 본다.” 이건 불공평하다. 셋째, **본질이 아닌 스타일에 집중(focus on style not substance)**하는 것이다. 사람들이 코드를 이해하지 못하면, ESLint 같은 도구의 경고 몇 개를 나열하고 끝낸다. 이건 도움이 안 된다. 넷째, **리뷰어 피로(reviewer fatigue)**다. “이 사람에게 계속 말하는 게 지쳤다” 또는 “계속 왔다 갔다 하는 게 지쳤다.”

강연자는 두 사람의 사진을 보여준다. 한 명은 매우 불행해 보이고, 한 명은 매우 행복해 보인다. 그는 묻는다. “행복한 사람으로 만들려면 어떻게 해야 할까?” 그는 농담처럼 “수염을 기르면 된다(You grow a beard)“고 답한다. AI가 생성한 이미지에서 수염 난 사람들이 다 행복해 보인다는 것이다. 청중이 웃는다.

진짜 답은 이것이다. **공유된 기대치를 설정(set shared expectations)**하라. “코드 리뷰란 이런 것이다.” 체크리스트를 사용하거나 AI에게 체크리스트를 확인하게 하라. **구체적인 언어(specific language)**를 쓰고, 질문을 하라. 모든 팀원이 프로세스에 참여하라. 일부만 과부하되지 않게 하라. 그리고 **좋은 PR과 유용한 리뷰를 축하(celebrate)**하라.

기본 체크리스트 예시

강연자는 자신이 사용하는 기본 체크리스트를 공유한다. 언어에 무관한 일반적인 항목들이다.

💡 [영상 참조] 강연자는 이 시점에서 화면에 체크리스트를 보여줍니다. 상세 내용은 원본 영상을 확인하세요.

  • 요구사항을 충족하는가? 불필요한 복잡성이나 조기 최적화는 없는가? 제목과 설명이 명확해야 판단할 수 있다.
  • 크기와 인지 부하는 적절한가? 이 변경과 관련된 위험은 무엇인가?
  • 문서화가 적절한가? 예상치 못한 부분은 없는가?
  • 지역적 추론(local reasoning)이 가능한가? 전체 코드베이스를 알아야만 이해할 수 있는 구조는 피해야 한다.
  • 충분한 테스트가 추가되었는가?
  • 클래스에 기능이 뒤섞여(cobbled together) 있지 않은가? 기능적으로 분리하라.

C++ 전용 체크리스트도 있다. 레거시 코드에서 보고 싶지 않은 것들이다.

  • 매직 넘버를 사용하지 않았는가?
  • const 정확성이 있는가?
  • override 키워드를 사용했는가?
  • 초기화된 구조체(initialized structures)와 지정된 초기화자(designated initializers)를 사용했는가?
  • 전치(transposition) 같은 실수는 없는가?
  • assert와 expect를 올바르게 사용했는가? 강연자는 많은 사람이 테스트에서 assert(price == expected_price) 같은 걸 쓴다고 지적한다. 만약 여기서 실패하면 프로그램이 터진다. 수정하면 다음 줄에서 터진다. 테스트에서는 expect를 써야 한다. assert는 “optional이 비어있지 않다”, “unique_ptr이 null이 아니다” 같은 전제 조건(precondition)을 확인할 때만 써야 한다.

강연자는 청중에게 묻는다. “왜 C++ Core Guidelines를 사용하지 않나요?” 그는 답한다. 둘은 다르다(They’re different). 하나는 구체적(specific)이고, 하나는 일반적(general)이다. 하나는 모범 사례(best practices)를 찾는 것이고, 하나는 “PR의 목표를 충족했나?”를 묻는 것이다. 하나는 실행 가능한 항목(actionable items)이고, 다른 하나는 이론적 설명이 많다. 또한 체크리스트는 일반적 실수(common mistakes)로 채워지고, 가이드라인은 모든 것으로 채워진다.

예를 들어 비교하면, 체크리스트는 “엣지 케이스에 대한 적절한 테스트를 보장하라”고 말한다. 가이드라인은 “GTest를 사용해 적절한 테스트를 하는 방법은 이렇다”고 설명한다.

다시 한번, SmartBear 조사에서 가이드라인이 있는 팀이 2배 더 만족한다고 나왔다. 부족한 지식(tribal knowledge)에만 의존하지 않기 때문이다.

AI와 코드 리뷰: 자동화 가능한 변환

강연자는 강연의 마지막 부분에서 AI를 코드 리뷰에 어떻게 활용하는지 다룬다. 그는 “시간이 거의 다 돼서 빠르게 가겠다”고 말한다. 앞서 그는 AI가 코드 리뷰를 완전히 대체하기는 어렵다고 말했지만, 간단한 변환 작업(simple transformations)에는 AI가 매우 유용하다고 강조한다.

왜 구두점이나 포맷팅을 자동화하지 않나? 왜 리뷰에서 “이게 맞지 않아 보인다” 또는 “왜 이렇게 안 했나?”를 계속 물어야 하나? AI에게 시키면 된다. AI는 **지역적으로 추론 가능한 간단한 변환(simple transformations that are locally reasonable)**을 잘한다. 위험도 낮다. 변경 사항을 바로 확인할 수 있기 때문이다. 인간은 지루해하고 피곤해하지만, AI는 아마 그렇지 않다. 이것은 레거시 코드 비즈니스에 정말 좋다.

강연자는 자신이 프롬프트 스크립트(prompt script)에 작성한 변환 작업들을 나열한다.

  • 오버라이드 함수에서 virtual 키워드 제거, override로 교체: 옛날에는 virtual을 썼지만, 이제는 override를 쓴다.
  • const가 없는 멤버 함수에 const 추가
  • 단순 멤버 함수에 noexcept 추가: 클래스 변수만 접근하는 경우. 강연자의 회사에는 noexcept에 대한 PTSD가 있다고 한다. 프로덕션에서 코드가 터지는 걸 두려워한다. 하지만 “이건 bool을 반환한다. 절대 터질 수 없다. 만약 터진다면 다른 문제가 있는 것”이라고 설득한다.
  • typedef를 using으로 변환: C++11 스타일
  • for 루프를 범위 기반 for(ranged-for)로 변환: 매우 잘한다.
  • first, second 대신 구조화된 바인딩(structured bindings) 사용
  • 간단한 멤버 함수를 인라인(inline)으로 전환: 루프가 없고 한 줄짜리 함수라면, 헤더 파일로 옮겨 인라인으로 만든다.
  • 사용되지 않는 헤더 include 제거: include-what-you-use 도구도 있지만, AI도 할 수 있다.
  • C++17 스타일 네임스페이스 적용: namespace A::B::C 대신 중첩 괄호를 쓰던 옛날 방식을 바꾼다.

중요한 주의사항: 강연자는 경고한다. “만약 AI에게 12가지를 한 번에 다 하라고 하면, 코드가 뒤섞인다(scrambled). 코드에 최악의 일이 벌어질 것이다.” 간단한 변환 하나씩 해야 한다.

강연자는 예시를 보여준다. using 선언은 매우 간단하다. AI가 프롬프트 파일 안에 작성한 코드(강연자가 직접 작성한 게 아니라 AI가 스스로 작성)를 보면, “이렇게 하세요”라고 말하면 AI가 코드를 만든다. 강연자는 “잘못된 typedef가 using으로 바뀐 걸 본 적이 없다”고 말한다.

하지만 **noexcept 정확성(noexcept correctness)**은 훨씬 복잡하다. AI는 온갖 이상한 것을 한다. 그래서 강연자는 **많은 가드레일(guardrails)**을 추가했다. 규칙은 이렇다.

  • 간단한 멤버 함수에만 noexcept 추가 (getter, setter)
  • 멤버 함수가 다른 멤버를 호출할 때, 그 멤버가 noexcept여야만 추가
  • 더 많은 규칙들이 있고, AI가 잘못할 때마다 추가됨

또한 AI는 스스로 작은 클래스를 작성해 무엇을 해야 하는지 아이디어를 얻는다. 강연자는 말한다. “이 도구는 정말 잘 작동하며, 변동성이 매우 적다. 가드레일이 많기 때문이다.”

강연자는 몇 가지 코드 조각(snippet)을 보여준다.

💡 [영상 참조] 강연자는 이 시점에서 화면에 Before/After 코드를 보여줍니다. 상세 내용은 원본 영상을 확인하세요.

  • virtual → override 변환
  • typedef → using 변환
  • 이터레이터 루프 → 범위 기반 for 변환

강연자는 말한다. “이런 걸 당신의 오래된 코드베이스 덩어리에 실행한다고 상상해보라.” 그는 while 루프를 보면서 “이 루프가 100% 괜찮을 거라고 알 수 있다”고 말한다. 청중 중 한 명이 “당신은 알겠지만, 다른 사람도 알까요?”라고 묻는다. 강연자는 웃으며 “잡아냈을 것”이라고 답한다.

그는 다시 강조한다. “이런 것들이다.” 이것이 AI를 활용한 코드 리뷰 자동화의 실용적 예시다.

마무리: 코드 리뷰는 프로세스다

강연자는 강연의 핵심을 요약하며 마무리한다. 코드 리뷰에서 우리가 달성하려는 것은 무엇인가? 정확하고 유지보수 가능한 코드(correct, maintainable code)이며, 장기적 생존 가능성(long-term viability)을 갖춘 코드다. 또한 지식 공유와 협업도 포함되어야 한다.

어떻게 하는가? 코드 리뷰 체크리스트로 기본 사항을 표준화하라. 명백한 실수를 잡기 위해 자기 리뷰를 장려하라. 좋은 메트릭으로 모두가 정직하게 일하도록 하라. 건설적인 피드백을 보장하라. 정기적인 그룹 리뷰를 통해 코드베이스를 함께 검토하되, 누군가를 희생양으로 만들지 마라. 실수를 학습 기회로 정상화하라. 단, 프로덕션에서의 실수를 정상화하는 게 아니다. 프로덕션에서 터진 건 “정말 좋은 학습 기회”일 수도 있지만, 강연자는 코드 리뷰에서 잡는 걸 선호한다. 그리고 반복(iterate)하라.

요약하자면:

  • 코드 리뷰는 코드 품질을 향상시키고 제품을 출시(shipping product)하는 것이다. 사소한 트집만 잡으며 배포를 막는다면, 제품 출시를 막는 것이다.
  • 주니어 멤버를 코칭하고 온보딩(onboard)하는 기회다.
  • 개인 선호가 아닌 가이드라인에 기반한 객관적 코드 리뷰(objective code review)를 추구하라. 이것이 개선된 솔루션, 생산성, 그리고 좋은 그룹 역학(group dynamic)으로 이어진다.

행동 촉구(call to action):

코드 리뷰는 프로세스에 관한 것이지, 단지 보고 있는 작은 코드 조각에 관한 것이 아니다. 강연자는 전체 프로세스—크기, 타이밍, 무엇을 찾아야 하는지—를 이야기했다. 코드 그 자체만이 아니다. 엔지니어들은 코드에 매혹되는 경향이 있지만, 코드 리뷰는 그 이상이다.

리뷰어로서의 책임을 인정하라. 강연자는 고위 관리자들에게 발표할 때, 한 관리자가 다른 관리자에게 물었던 장면을 공유한다. “당신 팀원들은 리뷰어로서의 책임을 얼마나 진지하게 받아들이나요?” 그 관리자는 답했다. “충분하지 않다(not enough).” 강연자는 이것이 일반적으로 사실이라고 믿는다. “우리는 책임의 심각성을 인정하지 않는다.”

프로세스를 수정하고 개선하라(Fix and improve your process).

강연자는 “끝났습니다. 죄송하지만 조금 길어졌네요”라고 말하며 웃는다. 그는 질문 시간이 있는지 묻는다. “여러분이 간식을 먹으러 가고 싶을 것 같은데.” 하지만 청중은 남아 있고 싶어 한다.

질의응답 하이라이트

강연 후 몇 가지 질문이 이어진다.

질문 1: 대규모 코드베이스에서 사일로(siloing) 방지

한 청중이 묻는다. “15~30명의 팀원이 있는 대규모 코드베이스에서, 개발자들이 자신의 코드를 스스로 머지하고 2~3명의 리뷰를 받는다면, 어떻게 사일로를 방지하나요? 제가 자주 보는 건 결국 3개의 고품질로 리뷰된 독립적인 로깅 프레임워크가 생기는 것입니다. 전체 제품을 책임지는 단일 유지관리자(single maintainer)가 없다면, 개발자 그룹들이 서로의 노력을 모르게 되는 것을 어떻게 막나요?”

강연자는 답한다. “같은 저장소(repo)에 있다면, 들어오는 PR을 보라.” 질문자는 “모든 개발자가 모든 PR을 봐야 한다는 건가요?”라고 묻는다. 강연자는 “모든 PR에 들어가서 리뷰하는 게 아니다. 제목을 보라. 제목이 잘 쓰여 있다면, 어떤 게 자신과 관련 있는지 볼 수 있다.”

질문 2: 리뷰어가 너무 많으면?

또 다른 질문. “리뷰어가 너무 많으면 어떻게 하나요? 10명의 리뷰어가 붙으면 너무 많지 않나요?” 강연자는 답한다. “회사가 근본적으로 비즈니스 전환을 하는 게 아니라면, 10명은 너무 많다.”

질문 3: 리뷰 중에 다른 사람이 승인하면?

“제가 리뷰 중인데, 다른 두 사람이 승인해서 머지되면, 저는 시간을 낭비한 거 아닌가요?” 강연자는 웃으며 “아마 늦게 참여한 것 같다. 24시간 안에 시작했어야 했다”고 답한다. 질문자가 “아니, 저는 지금 보고 있는데, 다른 사람들도 비슷한 시간에 본 것 같다”고 하자, 강연자는 “그럼 해결하라. 목표는 실패하지 않는 코드를 프로덕션에 넣는 것이다. 그렇게 되게 만들어라”고 말한다.

질문 4: 리뷰 중에 수정을 해도 되나?

마지막 질문. “리뷰가 진행 중일 때 PR에 수정을 계속 반영해도 되나요? 장점은 빠르게 수정되지만, 단점은 리뷰하는 배가 흔들리는(rocking boat) 것 같습니다.” 강연자는 자신의 선호를 밝힌다. “나는 24시간 동안 그대로 두는 걸 선호한다. 여러 사람이 들어와서 서로 다른 의견을 낼 수 있다. 사람 A는 ‘여기 이렇게 하지 마세요’라고 하고, 사람 B는 ‘난 좋은데요’라고 할 수 있다. 그럼 내가 선택할 수 있다.”

강연자는 청중에게 감사를 표하며 “예정보다 늦게 잡아둬서 죄송합니다”라고 마무리한다.

핵심 정리

Pete Muldoon의 강연은 코드 리뷰를 단순한 코드 검증 도구가 아닌, 팀 문화와 코드베이스 지속 가능성을 결정하는 핵심 프로세스로 재정의한다. 그는 21년간 컨설턴트로, 그리고 Bloomberg에서 1년간 실제로 프로세스 개선을 주도한 경험을 바탕으로, 다음과 같은 핵심 원칙을 제시한다.

  1. 프로세스가 우선이다: 코드의 구문이 아니라, 코드 리뷰를 어떻게 수행하는가가 성공을 결정한다.
  2. 목표는 삼중이다: 정확성, 장기적 코드베이스 건강성, 지식 공유 및 협업.
  3. 속도는 생명이다: 24시간 내 리뷰 시작, 명확한 타임라인, 대기 시간 최소화.
  4. 크기는 중요하다: 작은 PR일수록 철저한 리뷰와 빠른 승인을 받는다.
  5. 메트릭은 거짓말하지 않는다: 테스트 비율, 생성/머지 비율, 리뷰 시작 시간을 추적하라.
  6. 책임을 공유하라: 리뷰어는 단순 조언자가 아니라, 코드의 공동 소유자다.
  7. AI는 보조자다: 간단한 변환 작업은 자동화하고, 인간은 구조와 의미에 집중하라.
  8. 문화를 만들어라: 체크리스트, 코칭, 그룹 리뷰, 칭찬을 통해 좋은 습관을 강화하라.

강연자가 반복해서 강조하는 메시지는 명확하다. “코드 리뷰는 프로세스다. 그 프로세스를 고쳐라(Fix and improve your process).” 개별 코드 조각에 집착하지 말고, 팀 전체가 어떻게 코드를 생산하고 검증하는지를 시스템적으로 개선해야 한다. 이것이 레거시 코드베이스를 재작성의 나락으로 떨어뜨리지 않고, 지속 가능하게 유지하는 유일한 길이다.

📚 출처 및 참고

구분내용
원본 영상Mastering the Code Review Process - Pete Muldoon - CppCon 2025
채널CppCon
영상 길이(음성 변환 텍스트 기준 약 1시간 이상 추정)
리포트 작성2026-01-29
작성 방식YouTube 영상 STT 변환 후 에디팅

💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.

그래프 뷰

Related Reports

백링크