입사 초기에 PR을 올렸다. 일주일간 공들여 만든 기능이었다. 기존 코드를 분석하고, 팀 컨벤션을 따르려고 노력했고, 테스트도 꼼꼼히 작성했다.

리뷰가 달렸다. 코멘트가 14개. 대부분 수긍할 수 있는 지적이었는데, 하나가 걸렸다.

"이 접근 자체가 잘못됐습니다. 처음부터 다시 설계해야 할 것 같아요."

그 한 줄에 일주일의 노력이 부정당한 느낌이었다. 머리로는 코드에 대한 피드백이라는 걸 알지만, 감정은 "나"에 대한 평가로 받아들였다.

코드 = 나?#

개발자에게 코드는 자기 표현의 수단이다. 시간과 고민을 쏟아서 만든 결과물이니까, 그게 부정되면 자신이 부정당하는 것 같다. 특히 경험이 적을수록 코드와 자아를 분리하기 어렵다.

시간이 지나면서 깨달은 건, 코드 리뷰에서 상처받는 건 실력 문제가 아니라 관점의 문제라는 거다. 코드는 "내 작품"이 아니라 "팀의 산출물"이다. 리뷰어가 "이 접근이 잘못됐다"고 할 때, 그건 더 나은 방향을 찾자는 제안이지 나를 깎아내리는 게 아니다.

이걸 머리로 이해하는 것과 감정으로 받아들이는 건 다른 문제다. 솔직히, 지금도 날카로운 코멘트를 보면 잠깐 움찔한다.

상처가 됐던 패턴들#

돌아보면, 내용보다 톤이 문제인 경우가 많았다.

"왜 이렇게 했어요?" 이 질문은 두 가지로 읽힌다. 순수한 궁금함일 수도 있고, "이러면 안 되는 거 아시죠?"의 완곡한 표현일 수도 있다. 텍스트에서는 뉘앙스가 전달되지 않는다. 나중에 그 리뷰어와 대화해보니 진짜 궁금해서 물어본 거였다. 그런데 텍스트로 읽을 때는 비난으로 느꼈다.

수정 요청만 있고 이유가 없는 코멘트. "이거 바꿔주세요." 왜? 뭐가 문제인지 모르니까 배울 수도 없고, 단순히 취향 차이인지 실질적인 문제인지 판단할 수도 없다. 이런 코멘트를 받으면 "시키는 대로 해야 하는 건가" 하는 무력감이 든다.

공개 채널에서의 지적. PR 코멘트는 팀 전체가 본다. 기초적인 실수를 공개적으로 지적당하면 창피하다. 이건 리뷰어가 의도한 게 아니라 코드 리뷰라는 시스템의 특성인데, 그래도 감정은 어쩔 수 없다.

내가 바뀐 것#

코멘트를 바로 반응하지 않는다. 날카로운 코멘트를 보면 일단 닫는다. 30분 뒤에 다시 읽으면 감정이 빠지고 내용만 보인다. 즉각적으로 반응하면 방어적인 답변을 쓰게 된다. "그건 이래서 이렇게 한 건데요"라는 정당화. 30분만 기다리면 "아, 맞네. 이렇게 바꾸겠습니다"로 끝날 수 있다.

모르면 물어본다. "왜 이렇게 했어요?"에 대해 "이런 이유로 이렇게 했는데, 더 나은 방법이 있을까요?"라고 묻는다. 방어 대신 질문. 이러면 대화가 열리고, 대부분의 리뷰어는 기꺼이 설명해준다.

리뷰어에게 맥락을 먼저 제공한다. PR 설명에 "왜 이 접근을 선택했는지"를 적어둔다. 리뷰어가 의사결정 배경을 알면, "왜 이렇게 했어요?"라는 질문 자체가 줄어든다.

리뷰어가 됐을 때#

내가 리뷰를 할 때는, 받는 입장에서 상처가 됐던 패턴을 의식적으로 피하려고 한다.

"이거 바꿔주세요" 대신 "이렇게 하면 ~한 이유로 더 좋을 것 같아요". 이유를 붙이면 지시가 아니라 제안이 된다.

잘 된 부분에도 코멘트를 남긴다. "이 부분 깔끔하게 처리했네요" 한 줄이면 된다. 문제만 지적하면 코드 리뷰가 "틀린 곳 찾기"가 되는데, 긍정 피드백이 섞이면 "같이 더 좋은 코드를 만드는 과정"이 된다.

코드 리뷰는 기술적 활동이지만, 결국 사람과 사람 사이의 커뮤니케이션이다. 좋은 코드를 만드는 것만큼, 서로의 감정을 존중하는 것도 중요하다. 이걸 깨닫는 데 꽤 오래 걸렸다.