주니어한테 하지 말아야 할 코드 리뷰 멘트 — 시니어의 반성문
과거의 나한테 하고 싶은 말이 있다. '왜 이렇게 짰어?'라는 말은 최악이다
코드 리뷰를 하면서 한 말들을 다시 읽어보면, 내가 얼마나 무례했는지 깨닫는다. 특히 주니어 개발자에게 했던 말들이 그렇다.
이 글은 과거의 나를 반성하고, 더 나은 리뷰 문화를 만드는 방법에 대해 쓴다.
절대로 하지 말아야 할 리뷰 멘트
"왜 이렇게 짰어?"
이 말은 상대를 전면 부정하는 것이다. 주니어는 이 말을 받으면:
- "내 판단이 틀렸나?"
- "나는 능력이 부족한가?"
- "이 회사에서 계속 일할 수 있을까?"
이 생각들이 든다. 그리고 다음번엔 더 위축된 코드를 제출한다.
대신: "이 부분은 이렇게 하면 어떨까요? <理由>" 라고 하자.
"이건 상식인데?"
상식은 배운 사람의 입장에서만 상식이다. 5년차가 상식인 것이 1년차에는 한국 교육과정에 없는 내용일 수 있다.
"너무 복잡한데?"
주니어는 기술 부채를 모르고, 확장성을 고려하지 않기 때문에 단순하게 짠다. 이를 비난하는 것은 부당하다. 대신 "여기서는 이렇게 하면 나중에 유지보수가 쉬워져"라고 설명하자.
"이 라이브러리 쓰면 5줄로 끝나는데?"
주니어가 라이브러리를 모르는 건 자신이 조사하지 않아서가 아니라, 경험이 없어서다. 이 비난은 정말 치열했다.
좋은 리뷰의 특징
내가 받았던 리뷰 중 가장 도움이 된 것:
시니어 A의 리뷰:
"좋은 접근인데, 이 부분에서 edge case를 다시 생각해보면 좋을 것 같아. 사용자가 null을 입력할 때는 어떻게 되지?"
이 말은:
- 전체 구조는 인정함
- 개선할 부분을 구체적으로 지적
- 스스로 생각하게 유도
- 문제가 아니라 질문 형태
시니어 B의 나쁜 리뷰:
"이건 초급 실수야. 다시 쓰세요"
이 말을 받으면:
- 무엇이 잘못되었는지 모름
- 다시 짜는 방법도 모름
- 왜 안 되는지도 설명 없음
- 순전히 기분만 상함
좋은 리뷰의 원칙
1. 먼저 칭찬한다
좋음: "네이밍이 명확하네요. 이 부분은 이렇게 하면 어떨까요?"
안 좋음: "이건 왜 이렇게?"2. 이유를 설명한다
좋음: "이 방식은 O(n²) 복잡도라서, 데이터가 많으면 느려져요. 이렇게 하면 O(n)이 돼요"
안 좋음: "비효율적이네요"3. 선택지를 준다
좋음: "방법 1: A를 쓰면 이런 장점이, 방법 2: B를 쓰면 이런 장점이 있어요"
안 좋음: "무조건 이렇게 해야 해"4. 학습 기회를 만든다
좋음: "이 부분에서 디자인 패턴을 적용하면 좋아요. 이전에 얘기했던 Singleton 패턴 기억하죠?"
안 좋음: "너 Singleton 몰라?"리뷰에서 구분해야 할 것
Must (강제):
- 보안 문제
- 성능 문제 (심각할 때)
- 버그
Should (권장):
- 가독성 개선
- 일관성 유지
- 베스트 프랙티스
Nice to Have (선택):
- 스타일 (따옴표 종류 등)
- 개인의 선호도
- 미래를 위한 개선
주니어 때는 Must만 지적하고, 나머지는 피드백이 아니라 제안으로 전하자.
내가 바꾼 리뷰 문화
현재 내 팀의 리뷰 규칙:
- 칭찬 먼저: 모든 리뷰에 칭찬이 있어야 함
- 질문으로: "왜?"는 질문이지 비난이 아님
- 제한적 피드백: 한 번에 3개 이상 지적 금지
- 24시간 대기: 화난 상태로 리뷰 금지
- 1:1 대화: 복잡한 건 DM으로 토론
결과: PR 머지 시간이 2배 빨라졌고, 버그는 35% 줄어들었다.
나에게 도움이 되었던 리뷰
가장 기억에 남는 리뷰:
"좋은 코드네. 근데 이 부분, 다른 방법도 생각해볼 만할 것 같은데? 과제가 아니라 생각해볼 주제로."
이 한 마디 때문에, 나는 그 주제를 2주간 공부했다. 그리고 지금도 그 방법을 쓴다.
결론: 리뷰는 폭력이 아니다
코드 리뷰는 코드를 개선하는 것이 아니라, 사람을 성장시키는 과정이어야 한다.
과거의 나: "빨리 좋은 코드를 짜게 만들어야지"
지금의 나: "이 사람이 좋은 개발자가 되도록 도와야지"
오랜 개발 경험에서 배운 것: 진짜 시니어는 코드를 잘 짜는 사람이 아니라, 주니어를 성장시키는 사람이다.