코드 리뷰가 잘못됐다
출처: Dev.to

Originally published on lavkesh.com
팀 리더가 마감일이 급한 프로젝트에서 동료의 코드 검토를 맡기라고 했을 때, 저는 그 프로젝트에 참여하고 있었습니다. 코드는 네이밍 규칙이 일관되지 않았고, 로직이 중복돼 있었으며, 주석이 전혀 없었습니다. 전부 결함을 지적하고 코드를 전체적으로 다시 쓰라고 제안하는 가차없는 리뷰를 작성했습니다.
동료는 제 피드백에 방어적으로 반응했고 상처받았으며, 팀 리더가 상황을 진정시키기 위해 개입해야 했습니다. 저는 비판이 너무 가혹했으며, 피드백이 건설적이지 않았다는 사실을 깨달았습니다. 동지를 돕기보다 코드를 비판하는 데 집중했습니다.
그 경험을 통해宝贵한 교훈을 얻었습니다. 피드백을 제공할 때는 구체적이고 객관적이며 존중하는 것이 필수적입니다. 코드를 비판하기보다 개선점을 제시하고 도움을 제공하는 데 집중해야 했으며, 동료가 겪고 있던 상황과 제약도 고려해야 했습니다.
이후로는 피드백을 건설적이고 존중하는 방식으로 제공하기 위해 의식적으로 노력하고 있습니다. 또한 비판적인 피드백을 받아도 겸손하게 수용하는 법을 배웠습니다. 피드백이 개인 공격이 아니라 배우고 성장할 수 있는 기회라는 것을 알게 되었습니다.
저는 ‘샌드위치 방법’을 사용합니다. 이는 긍정적인 내용으로 시작하고, 건설적인 피드백을 제시한 뒤 다시 긍정적인 내용으로 마무리하는 방식입니다. 이 접근법은 비판의 충격을 완화하고 피드백을 더 부드럽게 만듭니다.
저는 사람보다 행동이나 코드를 중심으로 합니다.
‘당신은 나쁜 개발자다’ 대신 ‘이 코드는 …으로 개선될 수 있다’라고 말합니다.
이 방식은 방어적 반응을 피하고 더 건설적인 대화를 촉진합니다.
피드백을 받을 때는 질문하고 명확히 파악하려는 습관을 기르기도 했습니다.
이를 통해 피드백을 정확히 이해하고 실행할 수 있습니다.
피드백은 한 번의 사건이 아니라 지속적인 과정입니다. 동료가 어떻게 진행 중인지 확인하고 추가 도움이 필요한지 지속적으로 팔로우업하는 것이 중요합니다.
피드백을 주고받는 것은 좋은 엔지니어이자 팀 플레이어가 되는 데 필수적인 부분입니다.
항상 쉽지는 않지만, 성장과 개선의 핵심 요소입니다.
동료와 팀 리더들로부터 피드의 가치를 배우고 효과적으로 전달·수신하는 법을 배우게 되어 감사하게 생각합니다.
건설적인 피드백이 팀에 미치는 긍정적 영향을 목격했습니다. 팀 사기를 높이고 협업을 개선하며 더 좋은 결과를 낼 수 있습니다.
또한 파괴적인 피드백이 방어적 반응, 감정 상해, 의사소통 단절로 이어질 수 있음을 목격했습니다.
동지를 함께 성장할 수 있도록 지속적으로 학습하고 돕겠다는 약속을 합니다.
피드백이 그 과정의 핵심이라고 믿으며, 그 긍정적 영향을 기대합니다.
제 경험은 피드백이 성장과 개선에 필수적임을 가르쳤으며, 제 이야기가 다른 사람들이 실수를 배우고 더 나은 엔지니어와 팀 플레이어가 되도록 도울 수 있기를 바랍니다.
