이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 첫 과제로 레거시 결제 모듈 리팩터링을 맡았습니다. 코드 커버리지가 12%였고 함수 한 개가 200줄이 넘었습니다. 저는 일단 기존 동작을 보호하는 통합 테스트부터 작성해 안전망을 만든 뒤, 함수를 책임 단위로 쪼개는 순서를 택했습니다. Extract Method 패턴으로 결제 유효성 검사·금액 계산·알림 발송을 각각 분리했더니 커버리지가 12%에서 71%로 올랐습니다. 이후 CI에서 커버리지 임계값을 65%로 강제하도록 설정했고, 팀에서 그 기준이 실제로 유지됐습니다. 이 경험으로 리팩터링은 테스트 없이 시작하면 오히려 위험이 커진다는 것을 직접 느꼈습니다.
코드 품질을 한 번에 개선하려다 실패한 경험 이후, 매 PR마다 건드리는 코드 주변을 조금씩 개선하는 방식을 팀에 제안했습니다. 대규모 리팩토링은 리뷰도 어렵고 일정 영향도 크다는 이유로 미뤄지는 경우가 많았는데, 지나치는 길에 조금씩 고치는 것은 별도 일정이 필요 없다는 점에서 팀 내 수용이 빠르게 됐습니다.
Boy Scout Rule이라는 이름으로 PR 템플릿에 관련 항목을 추가했습니다. 3개월 뒤 코드 리뷰 시 지적되는 기술 부채 코멘트가 줄었고, 팀원들도 레거시 코드를 두려워하지 않는 분위기가 생겼습니다. 코드 품질은 일회성 개선 작업이 아니라 매 변경에 조금씩 끼워 넣는 습관이 더 오래 유지된다는 것을 배웠습니다.
코드 품질 개선에서 측정 없이 개선하는 것은 방향을 모르고 걷는 것과 같다는 것을 경험으로 알게 됐습니다. 주관적인 리뷰 코멘트만으로는 어디가 실제로 문제인지 합의하기 어려웠는데, SonarQube를 CI에 연결하니 복잡도·중복·코드 스멜이 수치로 나왔습니다.
팀 전체가 같은 기준을 보게 되니 리뷰에서 개인 취향 논쟁이 줄고, 개선 우선순위를 데이터로 잡는 것이 가능해졌습니다. 처음에는 경고가 수백 개라 막막했는데, 이슈를 critical·major·minor로 나눠 critical만 먼저 잡는 방식으로 진행했습니다.
품질 개선은 완벽을 목표로 하면 시작을 못 하고, 기준선부터 잡아가는 방식이 실제로 움직인다는 것을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 모바일 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.