이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
코드 리뷰와 설계 리뷰를 통해 팀 기술 수준을 높인 경험은 팀 프로젝트에서 있었습니다. PR을 올릴 때 단순 코드 확인이 아니라 '왜 이 방식을 선택했는지'를 리뷰 코멘트에 적는 문화를 먼저 제안했습니다. 처음에는 코멘트가 코드 교정에 치중됐는데, 점차 더 나은 접근 방식을 질문 형태로 나누는 방식으로 바뀌면서 팀 전체가 배우는 채널이 됐습니다. 설계 리뷰는 구현 전 30분 설계 토론을 고정으로 넣었고, 이를 통해 나중에 리팩토링이 필요한 코드가 줄었습니다. 앞으로도 리뷰 문화를 만들 때 지적보다 질문으로 시작하는 방식을 유지하겠습니다.
좋은 리뷰는 코드를 고치는 게 아니라 팀이 함께 배우게 합니다.
코드 리뷰 문화를 바꾼 건 리뷰 방식이 아니라 리뷰를 쓰는 이유를 팀에 공유한 것이었습니다. 팀에 합류했을 때 PR 리뷰가 있었지만 대부분 오탈자나 변수명 수정 수준에 머물렀고, 설계 의도에 대한 대화는 거의 없었습니다. 제가 먼저 '왜 이 구조를 선택했나요?'를 PR 설명에 직접 쓰기 시작했고, 그 포맷을 자연스럽게 공유했습니다. 처음에는 번거롭다는 반응이 있었는데, 한 달쯤 지나니 팀원들이 먼저 설계 의도를 적어 올리기 시작했습니다. 설계 리뷰는 구현 전 별도 자리를 만들기보다 기존 PR에 '설계 고민' 섹션 하나를 추가하는 방식으로 운영했습니다. 그 섹션이 쌓이면서 비슷한 문제를 다음 사람이 반복하지 않아도 되는 문서가 됐습니다. 팀 전체가 설계를 공유하는 분위기가 만들어지는 건 특별한 도구보다 먼저 공개하는 사람이 생겼을 때였습니다.
팀 기술 수준을 올리려 할 때 발표보다 조용한 전파가 더 빠를 때가 있다는 걸 경험했습니다. 코드 리뷰에서 같은 실수가 반복되는 걸 보면서 문제를 개인 차원이 아닌 공유 지식의 부재로 보기 시작했습니다. 그래서 설계 결정을 내릴 때 슬랙 채널에 3~4줄 메모로 남기는 방식을 실험했습니다. PR 링크와 함께 '이 방식을 선택한 이유, 고려했지만 버린 방식'을 짧게 올렸고, 두 달은 반응이 없었지만 세 달째부터 팀원들이 유사한 결정을 내릴 때 그 메모를 참고하기 시작했습니다. 설계 리뷰는 PR 올리기 전에 짧게 의견을 나누는 자리로 운영했고, 형식을 만들기보다 먼저 공유하는 습관에서 시작했습니다. 그 과정에서 팀에서 질문이 늘어나는 방향으로 분위기가 바뀌는 걸 관찰했습니다. 기술 수준이 올라가는 시점은 서로 모르는 걸 말하는 게 자연스러워진 순간이었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.