며칠 밤을 새워 정성껏 작성한 Pull Request(PR). 두근거리는 마음으로 리뷰를 요청했는데, 다음 날 깃허브 알림에 붉은색 코멘트 27개와 Changes Requested가 찍혀 있는 것을 본 순간의 가슴 철렁함을 기억하시나요? 마치 내 실력 전체를 부정당한 것 같고, 선배들이 "이 친구는 기본도 안 되어 있네"라고 수군거리는 것만 같아 얼굴이 화끈거립니다.
하지만 단언컨대, 코드리뷰는 당신이라는 사람(Ego)에 대한 평가가 아니라 단지 모니터에 떠 있는 코드(Code)에 대한 개선 논의일 뿐입니다. 시니어들이 왜 그렇게 집요하게 코멘트를 다는지, 그리고 이를 내 성장 치트키로 전환하는 비결을 정리해 드립니다.
개발자는 자기가 짠 코드에 자아를 투영하기 쉽습니다. 코드 한 줄 한 줄이 내 땀과 고민의 결과물이기에, 코드의 문제점을 지적받으면 나 자신이 공격받았다고 착각(Ego Trap)하게 됩니다.
LGTM (Looks Good To Me)만 남기고 머지하는 것보다, 구체적인 네이밍, 아키텍처, 예외 처리를 짚어주는 팀이 개발자로서 수십 배 빠르게 성장할 수 있는 최고의 환경입니다.리뷰 코멘트를 받을 때마다 반사적으로 "죄송합니다! 바로 수정하겠습니다 ㅠㅠ"라고 반응하는 주니어들이 많습니다. 자책은 멈추고 다음과 같은 프로페셔널한 커뮤니케이션으로 전환해 보세요.
"미처 고려하지 못했던 NullPointerException 케이스를 짚어주셔서 감사합니다! Optional 체이닝을 적용하여 방어 로직을 추가했습니다. (commit: 3a1f8c)""이 부분은 향후 다국어 지원 확장을 염두에 두고 구조를 분리해 두었습니다. 다만 현재 스코프에서는 오버엔지니어링일 수 있어 말씀해주신 간결한 방식으로 리팩토링할지 의견 여쭙습니다.""제안해주신 팩토리 패턴을 적용하니 가독성이 훨씬 좋아졌네요! 혹시 이 상황에서 전략 패턴 대신 팩토리를 권장해주신 배경을 조금 더 배울 수 있을까요?"
PR을 올린 직후 바로 리뷰어를 호출(Assign)하지 마세요. 내가 작성한 Diff를 깃허브 웹 화면에서 직접 한 줄씩 훑어보는 '5분 셀프 리뷰'만으로도 사소한 지적을 대부분 걸러낼 수 있습니다.
console.log, debugger, System.out.println 같은 임시 디버깅 코드 삭제 여부 확인"이 부분은 OOO 라이브러리의 특성상 비동기 래핑이 필요하여 이렇게 처리했습니다."건강한 피드백은 "이 함수는 복잡도가 높아 쪼개면 좋겠습니다"처럼 코드와 맥락을 향합니다. 반면 "왜 이렇게밖에 못 짜요?" 같은 인격 모독이나 감정적 비난은 정상적인 코드리뷰가 아닙니다. 만약 지속적인 언어적 공격이나 가스라이팅을 겪고 있다면, 이는 당신의 실력 문제가 아니라 조직의 건강성 문제입니다.