코드 리뷰에서 이런 코멘트를 받은 적이 있다. "이 로직 왜 이렇게 짰어요?"

기술적으로 틀린 부분이 있었던 거라 지적 자체는 맞았다. 근데 기분이 안 좋았다. "왜 이렇게 짰어요?"는 코드에 대한 질문인데, 읽는 사람 입장에서는 "이것도 모르냐"로 느껴질 수 있다. 같은 내용을 "이 부분은 이렇게 하면 성능이 더 나을 것 같은데 어떻게 생각해요?"라고 썼다면 느낌이 완전히 달랐을 거다.

이 경험 이후로 피드백이라는 걸 의식적으로 생각하게 됐다. 어떻게 말하느냐에 따라 같은 내용도 건설적인 조언이 되기도 하고, 그냥 기분 나쁜 지적이 되기도 한다는 걸. 개발자 커리어에서 코드 리뷰는 매일 하는 건데, 피드백 스킬은 아무도 가르쳐주지 않는다. 스스로 부딪히면서 배우는 수밖에 없었다.

피드백을 받는 게 어려운 이유#

개발자한테 코드는 본인의 연장선이다. 코드에 대한 피드백을 자신에 대한 평가로 받아들이기 쉽다. 특히 주니어일수록 그렇다. 내가 그랬다.

입사 초기에 PR에 코멘트가 5개 이상 달리면 맥북 앞에서 한숨부터 쉬었다. "또 뭘 잘못했지." 하나하나 읽으면서 속으로 변명을 준비했다. "이건 이런 이유가 있어서 그렇게 한 건데..." 리뷰어가 말한 의도는 "이렇게 하면 더 좋지 않을까"인데, 나는 "너 이것도 못하냐"로 해석하고 있었다.

이게 바뀐 건 시니어 한 분의 말 한마디 덕분이었다. 점심을 먹다가 코드 리뷰 얘기가 나왔는데, 시니어가 이렇게 말했다. "리뷰 코멘트가 많다는 건 리뷰어가 네 코드를 꼼꼼하게 봤다는 뜻이야. 코멘트 없이 approve만 달리면 오히려 걱정해야 해." 그 말이 관점을 바꿔줬다.

그 뒤로는 코멘트를 읽을 때 "이 사람이 나를 공격하려는 건가, 코드를 더 낫게 만들려는 건가?"를 먼저 생각한다. 거의 대부분은 후자다. 간혹 공격적인 톤의 리뷰를 만나면, 그건 그 사람의 커뮤니케이션 스타일 문제이지 내 코드의 문제가 아니다.

피드백을 잘 받는 연습#

피드백을 받을 때 가장 효과적이었던 건, 바로 반박하지 않고 일단 이해하려고 하는 거다.

코멘트를 보면 반사적으로 "근데 이건..."이라고 답하고 싶은 충동이 올 때가 있다. 그럴 때 10분만 기다린다. 10분 뒤에 다시 읽으면 처음과 느낌이 다를 때가 많다. 감정이 가라앉으면 내용 자체에 집중할 수 있다.

그리고 리뷰어의 의도가 명확하지 않으면 물어본다. "이 부분은 어떤 관점에서 말씀하신 건가요?"라고. 추측으로 반박하면 대화가 산으로 간다. 확인하고 나서 논의하면 훨씬 생산적이다.

한번은 리뷰에서 "이 상태 관리 방식이 복잡해 보인다"는 코멘트를 받았다. 처음에는 "이게 최선인데"라고 생각했는데, 왜 복잡하다고 느꼈는지 물어봤더니 "새로 합류하는 사람이 이해하기 어려울 것 같다"는 거였다. 나는 기능적인 관점에서만 봤는데 리뷰어는 유지보수 관점에서 본 거다. 그 코멘트 덕분에 구조를 단순화했고, 실제로 나중에 후배가 그 코드를 수정할 때 큰 어려움 없이 이해했다.

피드백을 주는 게 더 어렵다#

받는 것보다 주는 게 더 어렵다고 느꼈다.

후배 코드를 리뷰할 때 "이건 아닌데"라는 생각이 드는 부분이 있다. 근데 어떻게 말해야 상처를 안 주면서 정확하게 전달할 수 있을까. 딱 맞는 표현을 찾는 게 힘들다. 너무 돌려 말하면 의도가 전달이 안 되고, 직설적으로 말하면 상처를 줄 수 있다.

시행착오 끝에 나름의 원칙을 만들었다.

코드를 비판하지, 사람을 비판하지 않기. "왜 이렇게 짰어요?"가 아니라 "이 부분을 이렇게 바꾸면 어떨까요?" 주어를 사람이 아니라 코드로 만든다.

이유를 함께 쓰기. "이 변수명 바꿔주세요"보다 "이 변수명이 역할을 좀 더 명확하게 드러내면 좋을 것 같은데, 예를 들어 userList보다 activeUsers가 이 맥락에서 의미가 더 명확해 보여요" 같이 이유와 예시를 함께 쓴다. 시간이 좀 더 걸리지만 받는 사람 입장에서는 훨씬 이해하기 쉽다.

좋은 부분도 언급하기. 이건 억지로 칭찬하라는 게 아니다. 진짜 좋은 부분이 있으면 말해주는 거다. "이 에러 핸들링 깔끔하게 잘 처리했네요"라는 한마디가 분위기를 바꾼다. 피드백이 전부 지적이면 받는 사람이 방어적이 된다.

1:1에서의 피드백#

코드 리뷰는 그나마 비동기적이라 생각할 시간이 있다. 1:1이나 대면 상황에서의 피드백은 난이도가 다르다.

한번은 팀 리드와 1:1에서 "커뮤니케이션에서 좀 더 적극적이면 좋겠다"는 피드백을 받았다. 구체적으로 뭘 의미하는지 물어봤더니, "작업 중에 막히면 혼자 끙끙대는 시간이 길어 보인다, 좀 더 빨리 공유하면 팀 전체 효율이 올라갈 것 같다"고 했다.

듣는 순간에는 좀 찔렸다. 근데 돌아와서 생각해보니 맞는 말이었다. 3시간 혼자 고민한 걸 5분 만에 해결한 적이 실제로 있으니까. 이 피드백을 받은 뒤로 "30분 룰"을 만들었다. 30분 동안 안 풀리면 누군가한테 공유한다. 무조건.

피드백 문화를 만드는 것#

개인의 기술도 중요하지만 팀의 문화가 더 영향이 크다.

예전 팀에서는 코드 리뷰가 형식적이었다. 대부분 approve만 달리고, 가끔 사소한 컨벤션 지적만 있었다. 깊이 있는 피드백을 받기 어려웠다. 지금 팀은 다르다. 리뷰에서 설계 관련 논의가 오가고, 때로는 코멘트 스레드가 10개 넘게 달리기도 한다. 처음에는 부담스러웠는데, 이런 환경에서 성장 속도가 확실히 빠르다.

이런 문화는 리드의 역할이 크다. 우리 팀 리드는 자기 PR에도 리뷰를 요청하고, 코멘트를 달면 성실하게 답한다. 리드가 그러니까 팀원들도 자연스럽게 따라간다. 리드가 피드백에 방어적이면 팀원들도 방어적이 된다. 리드가 "오 좋은 지적이네, 고칠게"라고 하면 팀원들도 피드백을 편하게 받아들이게 된다. 문화는 위에서 아래로 흐른다.

나도 작은 시도를 하나 했다. PR 올릴 때 "이 부분은 고민이 되는데 의견 부탁드려요"라고 직접 질문을 달기 시작한 거다. 리뷰어 입장에서는 뭘 봐야 하는지 명확해지니까 더 구체적인 피드백이 온다.

비동기 vs 동기 피드백#

코드 리뷰는 비동기 피드백이다. 쓰고, 읽고, 답하고. 시간 여유가 있다. 근데 가끔은 동기적으로 대화하는 게 더 효과적일 때가 있다.

한번 코드 리뷰 코멘트에서 의견이 갈린 적이 있다. 나는 A 방식이 낫다고 생각했고, 리뷰어는 B 방식을 제안했다. 코멘트로 3번 왔다 갔다 했는데 합의가 안 됐다. 글로 쓰니까 미묘한 뉘앙스가 전달이 안 되는 거다.

결국 "잠깐 통화 가능해요?" 하고 5분 전화를 했다. 목소리로 얘기하니까 3분 만에 합의가 됐다. 서로의 관점을 이해하고, 절충안을 찾았다. 글로는 30분 동안 코멘트를 주고받아도 안 됐던 게, 대화로는 금방 해결됐다.

이후로 코멘트가 2번 이상 왔다 갔다 하면 바로 "통화 한번 할까요?"라고 제안한다. 코멘트 스레드가 길어지면 감정도 섞이기 쉽다. 빨리 대화로 전환하는 게 효율적이기도 하고 관계를 위해서도 낫다.

셀프 피드백#

남한테 받는 피드백 말고, 스스로한테 하는 피드백도 중요하다.

나는 2주에 한 번 정도 최근에 올린 PR을 다시 본다. 2주 전의 내 코드를 보면 "이걸 왜 이렇게 했지?"라는 부분이 꼭 보인다. 그때는 최선이라고 생각했는데 시간이 지나면 더 나은 방법이 떠오른다. 이걸 기록해두면 같은 실수를 줄일 수 있다.

한번은 3개월 전에 작성한 컴포넌트를 다시 봤는데, props가 8개였다. 지금 보면 명백하게 분리해야 할 컴포넌트인데, 당시에는 "하나의 컴포넌트로 처리하는 게 효율적"이라고 생각했다. 이런 걸 발견할 때마다 성장하고 있다는 걸 느낀다. 과거의 코드가 부끄러운 건 좋은 신호다.

피드백은 결국 근육이다. 주고받는 걸 반복하면서 점점 자연스러워진다. 처음에는 어색하고 불편하지만, 그 불편함을 넘어가야 성장이 있다. 적어도 내 경험에서는 날카로운 피드백을 받았을 때 가장 많이 배웠다. 그때는 아팠지만.