개발자들의 성장과 서비스 안정을 위해 필수적인 방어막, 바로 '코드 리뷰(Code Review, PR)'입니다. 다른 동료가 짠 수백 줄의 코드를 깃허브(GitHub) 등에서 눈으로 읽으며 품질을 검사하는데, 명백하게 비효율적인 DB 쿼리나 오타, 로직의 허점을 발견하게 됩니다. 이때 직설적으로 "이거 코드 잘못 짜셨네요", "이 방식은 성능 저하가 심합니다"라고 다이렉트로 댓글을 달면, 상대방은 모욕감을 무의식적으로 방어 기제를 발동시켜 감정싸움으로 번지곤 합니다. 동료의 자존심을 구기지 않으면서도 수정을 100% 관철시키는, 달콤하고 부드러운 개발자 쿠션어 작성법입니다.
나의 비판을 질문으로 위장하는 존중형 쿠션 화법
의문을 제기하며 스스로 고치게 유도하기.
와, OOO 프로님! 이번 새 기획서 로직 엄청 복잡했는데 모듈화해서 깔끔하게 잘 짜셨네요! 꼼꼼한 코드 덕분에 재밌게 잘 읽었습니다 👍👍 다름이 아니라 조금 궁금한 게 있는데요~ 파일 53번째 줄 라인 근처에서, 기존 공통 유틸(Utils)쪽 풀을 안 쓰시고 굳이 [DB 커넥션]을 별도로 맺도록 처리하신 로직이 있던데, 혹시 제가 모르는 특별한 병목 방어 의도나 설계 배경이 따로 있으실까요? 만약 특별한 의도가 없다면, 이 부분은 기존처럼 공통 레거시를 통일해서 가져다 쓰는 게 트래픽 증가 시 메모리 비용 측면에서 조금 더 유리해 보여서 조심스레 의견 드려 봅니다! 제 생각 한 번 가볍게 검토(크로스체크) 부탁드리고, 괜찮으시다면 반영(리팩토링) 한 번 부탁드릴게요! 이번 건 수고 많으셨습니다~
📋💡 실전 활용 팁
- 오타나 변수명 띄어쓰기 같은 단순한 컨벤션(규칙) 실수는 굳이 장문으로 길게 훈수 두지 마시고, 깃허브의 'Suggest Changes (코드 직접 수정 제안)' 기능을 사용해 바로 적용 버튼만 누르게 던져주는 것이 실무 배려입니다.
⚠️ 주의사항
[ "코드 리뷰 창에 대고 \"이거 예전에 쓰지 말라고 제가 몇 번이나 공지했던 패턴 같은데요?\" 라며 과거의 잘못이나 실력 깎아내리기를 시전하면, 그 팀의 분위기는 얼어붙고 결국 아무도 서로 리뷰를 달지 않는 사일로(장벽)가 형성됩니다." ]
코드 리뷰의 대원칙은 '사람 (Who)'을 공격하지 말고 철저히 '코드 문맥 (Why)'에만 집중하는 것입니다. 코드를 지적할 때는 언제나 나보다 동료가 더 똑똑할 수 있다는 가정을 바탕으로 방어적인 화법을 구사해야 합니다. "당신이 틀렸고 고쳐라"가 아니라, 전체적인 결과물에 대한 칭찬을 한 스푼 깔아준 뒤, "이 부분을 설계하신 뭔가 특별한 의도나 고민이 있으신지(내가 놓친 게 있는지) 궁급합니다만~" 식의 '질문형'으로 물어보세요. 이 부드러운 쿠션어를 쓰면, 상대방은 자신이 실수했음을 스스로 깨닫고 기분 상하지 않게 묵묵히 코드를 리팩토링합니다.