커리어··6 min read

피드백 주고받는 게 아직도 어렵다

5년 동안 피드백으로 울고 웃은 이야기, 그리고 아직도 서툰 부분

피드백이 무서웠다

1년 차 때 첫 성과 리뷰를 받았다. "기술 학습 속도는 좋은데, 일정 추정이 부정확하다"는 피드백이었다. 객관적으로 맞는 말이었다. 3일이면 된다고 한 작업이 8일 걸린 적이 있으니까. 근데 그 피드백을 받은 날 밤에 잠을 못 잤다. "나는 일정도 못 맞추는 사람인가" 하면서 자괴감에 빠졌다.

지금 생각하면 웃기다. 1년 차가 일정을 정확히 맞추는 게 오히려 이상한 건데. 근데 그때는 모든 피드백이 인격에 대한 평가처럼 느껴졌다.

받는 법을 먼저 배웠다

피드백을 들을 때 방어 모드가 켜지는 게 문제였다. "그건 이러이러한 이유가 있어서..."라고 변명부터 하고 싶어진다. 이걸 의식적으로 참는 연습을 했다. 일단 듣고, 이해되는 부분과 안 되는 부분을 구분하고, 질문이 있으면 나중에 하는 식으로.

"피드백 감사합니다. 구체적으로 어떤 상황에서 그렇게 느끼셨나요?"라는 문장을 외웠다. 반사적으로 변명하는 대신 이 문장을 쓰니까 대화가 훨씬 생산적이 됐다.

(근데 솔직히 아직도 부정적인 피드백을 받으면 속이 쓰리다. 이성적으로는 이해하는데 감정이 따라오는 데 시간이 걸린다.)

주는 법은 더 어려웠다

3년 차에 후배 코드를 리뷰하면서 피드백을 줘야 했다. 처음에 너무 직설적으로 해서 문제가 됐다. "이 로직은 비효율적이에요"라고 썼더니 후배가 다음 PR에서 코멘트를 달기 전에 먼저 사과를 하더라. "혹시 제가 또 잘못한 거 있으면 말씀해주세요"라고. 내 피드백이 위축시킨 거다.

그 뒤로 피드백 방식을 바꿨다. 일단 좋은 점을 먼저 말한다. "이 부분 추상화가 깔끔하네요." 그다음 개선점을 제안한다. "여기서 이렇게 하면 더 좋을 수 있을 것 같은데, 어떻게 생각해요?" 마지막에 격려를 붙인다. "전체적으로 저번보다 많이 좋아졌어요."

피드백 샌드위치라고 비판하는 사람도 있다. 솔직하지 못하다고. 근데 내 경험에서는 이게 실제로 효과가 있었다. 후배가 방어 모드에 들어가지 않고 피드백을 수용하는 비율이 확 올라갔다.

실수: 피드백 타이밍을 놓쳤다

한번은 후배의 코드 구조에 문제가 있다고 느꼈는데, 바빠서 리뷰를 대충 넘겼다. "다음에 말해야지" 했는데 그 "다음"이 안 왔다. 2개월 뒤에 그 코드 위에 새 기능이 쌓였고, 결국 리팩토링에 일주일이 걸렸다.

피드백은 빨리 줄수록 비용이 적다. 코드가 머지되기 전에 주는 게 머지된 후에 주는 것보다 100배 쉽다.

동료 간 피드백의 미묘함

상사-부하 관계가 아니라 동료끼리 피드백을 주고받는 건 더 미묘하다. 같은 연차인데 "네 코드에 문제가 있다"고 말하면 자존심 대결이 될 수 있다. 나도 동료한테 피드백을 받을 때 "너도 완벽하지 않으면서"라는 생각이 스치는 걸 느낀 적이 있다.

이걸 극복하려면 "사람이 아니라 코드에 대한 피드백"이라는 걸 양쪽 다 인식해야 한다. "네가 잘못한 게 아니라, 이 코드를 더 좋게 만들 수 있는 방법을 같이 찾자"는 전제가 필요하다.

5년 차인데 아직도 어렵다

솔직히 피드백 주고받는 게 편해질 날이 올지 모르겠다. 매번 긴장된다. 다만 예전에 비하면 나아진 건, 피드백을 개인적으로 받아들이는 정도가 줄었다는 거다. 100점이 아니라 한 60점? 아직 40점 남았다.

관련 글