이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
코드 리뷰를 할 때는 왜 그렇게 짰는지를 먼저 이해하려는 방향으로 접근합니다. 로직이 낯설거나 방식이 달라도 "이건 왜 이렇게 했어요?"라고 묻는 걸 먼저 하고, 이해한 뒤에 제 생각을 얘기하는 편입니다. 팀 프로젝트에서 한 번은 예외 처리 방식을 두고 의견이 갈렸던 적이 있었습니다. 저는 try-except를 좁은 범위에만 쓰는 걸 선호했는데, 팀원은 전체를 감싸는 방식을 써왔습니다. 각자 이유를 설명하다 보니 팀원은 개발 속도를 우선했고 저는 디버깅 편의를 중시했다는 걸 알게 됐습니다. 결국 핵심 로직에는 좁게, 입출력 경계에는 넓게라는 방식으로 합의했습니다. 그 이후로 리뷰에서 의견 차이가 나면 코드 자체보다 상황과 우선순위를 먼저 맞추는 방식으로 접근하고 있습니다.
코드 리뷰를 코드를 고치는 자리보다 서로 기준을 맞추는 과정으로 봅니다. PR 리뷰에서 네이밍 컨벤션을 두고 의견이 갈렸던 적이 있었습니다. 저는 함수명에 동사를 붙이는 방식을 선호했고, 팀원은 명사형 위주로 써왔습니다. 각자 써온 코드베이스 경험이 달랐기 때문이었습니다. 한쪽이 맞다고 설득하는 대신 팀 전체가 함께 쓸 컨벤션 문서를 짧게 만들자고 제안했고, 30분 논의 끝에 두 페이지짜리 기준이 나왔습니다. 그 이후로는 같은 이유로 리뷰가 길어지는 일이 줄었습니다. 코멘트를 쓸 때는 이 방식은 어떨까요?처럼 제안형을 의식합니다. 명령형 코멘트는 방어적 반응을 만들고, 제안형은 토론의 자리를 열었습니다. 의견 차이가 생길 때 어느 방식이 옳냐보다 지금 상황에 무엇이 맞냐로 질문을 바꾸면 방향이 빨리 잡히는 경험을 반복했습니다.
리뷰에서 상대 코드를 처음 볼 때 "내가 짰다면 어떻게 했을까"를 먼저 물어보는 습관이 있습니다. 그렇게 하면 차이가 보여도 의도를 더 잘 이해하게 됩니다. 한 번은 상태 관리 방식을 두고 방향이 달랐던 경험이 있습니다. 저는 전역 상태를 최소화하자는 입장이었고, 팀원은 공유 상태가 있어야 컴포넌트 간 데이터 흐름이 편하다는 입장이었습니다. 둘 다 틀리지 않았습니다.
현재 기능 범위에서는 팀원 방식이 빠르고, 확장 시에는 제 접근이 안전하다는 데 합의했고, 현재 방식을 적용하되 결정 근거를 주석으로 남겼습니다. 이후에 그 주석이 실제로 도움이 됐습니다. 리뷰에서 의견이 엇갈릴 때 어느 방식이 맞냐를 논쟁하기보다 현재 상황에 더 맞는 쪽을 찾는 방향으로 접근하면, 대화가 더 빨리 닫히는 자리가 됩니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 라인 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.