이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
코드 리뷰를 팀 문화로 정착시켰을 때 가장 크게 달라진 건 버그가 혼자서 발견되지 않던 것들이 리뷰 과정에서 잡히기 시작한 것입니다. 각자 자기 코드는 눈에 잘 안 보이는 부분이 있는데, 다른 사람의 시각이 그 부분을 채워줍니다. 팀 프로젝트에서 PR 리뷰를 의무화했을 때, 처음엔 귀찮아하던 팀원도 자기 코드에 피드백이 달리면서 개선 방향을 더 빨리 찾게 됐다고 말했습니다. 페어 프로그래밍은 복잡한 로직을 처음 설계할 때 활용했습니다. 혼자 막혀 있던 문제가 말로 설명하는 과정에서 스스로 해결되는 경우가 자주 생겼습니다.
설명하는 것이 곧 검증이었습니다. 코드 리뷰 문화는 개인 실력보다 팀 전체의 코드 품질 수준을 올리는 방법입니다. 혼자 잘하는 것과 팀으로 잘하는 것은 다르다는 걸 경험으로 배웠습니다.
코드 리뷰를 팀에 도입할 때 처음에 팀원들이 귀찮아하거나 형식적으로 승인만 하는 자리가 생겼습니다. 리뷰가 형식으로만 남으면 버그를 잡는 자리가 생기지 않고, 리뷰를 도입한 의미가 사라지는 자리가 됩니다.
처음에 PR 리뷰를 의무화했는데 팀원들이 코멘트 없이 승인만 하는 자리가 반복됐습니다. 그때 리뷰 기준을 명확히 정리해서 어떤 자리를 봐야 하는지를 구체적으로 공유했더니, 팀원들이 실제로 코멘트를 달기 시작하는 자리가 됐습니다. 리뷰 기준이 없으면 무엇을 봐야 하는지 모르는 자리가 생기기 때문에, 기준이 있어야 리뷰가 작동하는 자리가 됩니다.
리뷰 기준을 함께 정하는 것이 코드 리뷰가 의미 있는 자리를 만드는 결과라고 생각합니다. 기준이 있어야 리뷰가 됩니다.
지금도 코드 리뷰는 도입하는 것보다 어떻게 운영하는지가 더 중요한 자리라고 생각합니다. 운영이 있어야 효과가 됩니다.
코드 리뷰를 운영하면서 매번 어떻게 리뷰할지를 그때그때 결정하면 팀원마다 방식이 달라지는 자리가 생긴다는 것을 알게 됐습니다. 리뷰 규칙을 한 번 정리해두면 새 팀원이 합류할 때도 같은 방식으로 시작하는 자리가 됩니다.
팀 프로젝트에서 PR 크기 제한(최대 300줄), 리뷰 응답 시간(24시간 이내), 코멘트 분류(제안 vs 블로킹)를 팀 규칙으로 정리해서 공유한 경험이 있었습니다. 이 규칙이 있으니 리뷰에서 어디까지가 제안이고 어디서 수정이 필요한 자리인지를 명확히 구분하는 자리가 됐습니다. 규칙이 있어야 리뷰가 갈등 없이 운영되는 자리가 됩니다.
코드 리뷰 규칙을 남기는 것이 있어야 리뷰 문화가 팀 자산이 되는 자리라고 생각합니다. 규칙이 있어야 문화가 됩니다.
지금도 코드 리뷰는 개인 실력보다 팀이 합의한 방식이 있어야 작동하는 자리라고 생각합니다. 합의가 있어야 작동이 됩니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 배달의민족(우아한형제들) 공통직무·미지정 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.