이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 팀 코드베이스에서 레거시 코드 비율이 높아 기능 추가 때마다 사이드 이펙트가 잦았습니다. 리팩터링 PR을 제안했더니 '시간이 없다'는 반응이 먼저 왔고, 저는 보이스카우트 룰(들어갈 때보다 조금 더 깨끗하게 나오기)을 팀 규범으로 제안했습니다. 수정하는 파일 안에서만 명백한 중복·죽은 코드를 함께 정리하는 방식으로, 별도 리팩터링 일정 없이 적용할 수 있다는 점에서 거부감이 적었습니다. 3개월 뒤 해당 파일들의 테스트 커버리지가 평균 18%p 올랐고, PR 사이즈도 줄어 리뷰 속도가 빨라졌습니다. 리팩터링 문화는 별도 일정을 만드는 것보다 일상 작업에 스며들게 하는 방식이 지속성이 높다는 것을 이 경험에서 배웠습니다.
보이스카우트 룰을 팀에 제안하면서 가장 신경 쓴 것은 개인 의견이 아닌 팀 합의로 만드는 것이었습니다. 처음엔 제가 혼자 리팩터링 PR을 올렸는데 팀원들이 리뷰를 어떻게 해야 할지 기준이 없어 머지가 늦어지는 패턴이 반복됐습니다. 코드 리뷰 체크리스트에 수정 파일 내 중복 코드·죽은 변수 정리 여부를 항목으로 추가하자고 팀에 제안했고, 한 번의 팀 미팅에서 기준을 함께 정리한 뒤 리뷰어와 작성자 모두 같은 기준을 공유할 수 있었습니다. 이후엔 리팩터링 관련 리뷰 코멘트가 명확한 기준을 근거로 달리기 시작했습니다. 문화는 구두로 설득하는 것보다 기존 프로세스에 한 줄을 추가하는 방식이 더 오래 유지된다는 것을 배웠습니다.
리팩터링 문화 정착에서 팀원들이 어디부터 시작해야 할지 모르는 것이 참여를 막는 주요 원인이었습니다. 복잡도 측정 도구로 함수별 순환 복잡도(Cyclomatic Complexity)가 높은 파일 목록을 추출해 팀 공유 문서에 올렸습니다. 숫자로 보이니 어느 파일이 가장 위험한지 직관적으로 드러났고, 팀원이 스프린트마다 목록에서 하나씩 가져가 리팩터링하는 흐름이 자연스럽게 생겼습니다.
복잡도 10 이상 파일을 매주 집계해 리팩터링 티켓에 자동으로 연결하는 스크립트를 만들었습니다. 3개월 뒤 해당 목록의 파일 수가 28개에서 9개로 줄었고, 그 기간 동안 관련 파일의 버그 발생 건수도 눈에 띄게 감소했습니다. 리팩터링 문화는 규칙보다 가시성이 먼저라는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.