이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 GitLab MR을 처음 써봤습니다. 처음엔 단순 승인으로 넘기는 경우가 많았는데, 팀에서 리뷰 기준을 같이 정하면서 달라졌습니다. 제가 먼저 확인하는 건 동작 정확성과 테스트 커버리지입니다. 엣지 케이스를 처리했는지, 테스트 없이 로직이 바뀐 건 아닌지를 먼저 봅니다. 그 다음은 가독성인데, 변수명이 의미를 담는지, 함수가 한 가지 일을 하는지를 확인합니다. 보안 관련해서는 외부 입력을 그대로 쿼리에 쓰는 코드가 있으면 빠짐없이 코멘트를 남기는 습관이 있습니다. 리뷰 코멘트는 Suggestion: 형태로 대안을 함께 제시하면서 지적보다 제안이 되도록 쓰는 걸 중요하게 생각합니다. 리뷰를 통해 서로 코드 스타일을 맞춰가는 과정이 팀 전체 코드 품질을 올리는 데 직접 기여한다는 걸 배웠습니다.
GitLab MR 코드 리뷰에서 태도가 드러난 경험은 지적보다 제안 형태로 코멘트를 쓰는 방식이 자리 잡은 케이스였습니다. 처음에는 문제를 발견하면 직접 지적하는 코멘트를 남겼는데, 받는 사람 입장에서 방어적이 되는 경우가 있었습니다.
Suggestion: 형태로 대안을 함께 제시하는 방식으로 바꾸자 논의가 더 건설적으로 이루어졌습니다. 코드 리뷰에서 코멘트는 코드를 평가하는 것이 아니라 더 나은 방향을 함께 찾는 것이고, 제안 형태가 그 목적에 더 맞는다는 결이 생겼습니다.
GitLab MR 코드 리뷰에서 효과로 이어진 경험은 리뷰 기준을 팀에서 함께 정한 뒤 일관성이 생긴 케이스였습니다. 처음에는 팀원마다 다른 기준으로 리뷰하다 보니 어떤 PR은 자세히 검토되고 어떤 PR은 빠르게 통과되는 차이가 있었습니다.
팀에서 리뷰 기준을 함께 정한 뒤 리뷰 품질이 일관해졌고, 코드 스타일도 점차 맞춰졌습니다. 코드 리뷰의 효과는 개별 리뷰어의 역량보다 팀이 공유하는 기준이 있을 때 더 일관되게 나타난다는 결이 남아 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 배달의민족(우아한형제들) 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.