코드 악취를 맡는 후각 훈련의 시간

입고관리 시스템의 한 달짜리 리팩토링을 세 명이 안전하게 진행하기 위해 대상 선정, 기준 합의, 테스트, 단계 배포를 설계한 회고다. 막연히 전체를 갈아엎는 대신 기능 유사성에 따라 8개 영역으로 나누고 3차에 걸쳐 QA와 배포를 반복했다. 코드 개선뿐 아니라 팀 전체의 시스템 이해도와 테스트 습관을 끌어올린 과정을 다룬다.

핵심 포인트

큰 코드베이스를 8개 영역과 3개 배포 단계로 쪼개 리팩토링 범위와 검증 단위를 통제했다.
30줄 초과, 3중 조건문, 매개변수 5개 이상, 죽은 코드, 모호한 이름 등 멈춰서 검토할 최소 기준을 만들었다.
대상과 변경 방향을 소스의 TODO로 남기고 팀 리뷰를 거쳐 같은 기준으로 합의했다.
기존 동작을 보존하기 위해 서비스 레벨 mock 테스트로 가능한 분기를 먼저 덮고 로컬·QA 통합 테스트까지 이어갔다.
공통화가 오히려 조건문을 키운 코드는 다시 분리하고, 예외를 enum으로 구조화해 읽기와 검증 가능성을 높였다.

상세 정리

배경: RMS는 기능과 성능에는 큰 문제가 없었지만 초기 설계의 미흡함이 누적돼 팀이 전면 재작성까지 고민하던 상태였다.
제약: 개발자 세 명에게 약 한 달이 주어졌다. 눈에 보이는 신규 기능 없이 합당한 결과를 내야 했고, 어디서 시작할지 공통 기준도 없었다.
범위 분할: 메인 기능과 비슷한 동작을 하는 도메인을 기준으로 코드를 8개 파트로 나눴다. 3차로 작업하고 각 단계마다 QA 후 따로 배포하기로 했다.
기준 학습: 팀원이 리팩토링 책을 한 권 이상 읽고 토론해 탐지 규칙을 정했다. 길이·중첩·매개변수·죽은 코드·주석 코드·불필요한 로그·모호한 이름이 신호였다.
대상 기록: 메모장과 엑셀보다 개발 도구에서 바로 확인되는 TODO를 택했다. 해당 코드가 어떤 기준을 어겼고 어느 방향으로 바꿀지 모든 관련 위치에 남겼다.
방향 합의: 개인 의견으로 바로 수정하지 않고 팀 리뷰에서 최종 변경안을 합의해 TODO에 갱신했다. 유사 코드를 놓치는 것도 줄였다.
회귀 방지: 과거 코드에는 이유가 있을 수 있다고 보고 먼저 테스트를 작성했다. 여건상 모든 계층 대신 서비스 레벨 mock 테스트에 집중하되 분기를 최대한 포함했다.
검증 순서: 리팩토링 후 시그니처 변경으로 생긴 컴파일 오류를 고친 뒤 테스트를 실행했다. 이어 로컬 서버와 QA 통합 테스트로 실제 데이터 처리까지 확인했다.
예외 개선: 문자열 메시지를 담은 RuntimeException과 중복 custom exception을 ExceptionType enum 중심으로 통합했다. 테스트에서 오류 종류를 명확히 검증할 수 있게 됐다.
공통화 해체: 검수·검품 로직을 합친 공통 함수에 구분용 if와 설명 주석이 계속 늘었다. 도메인별 처리로 다시 나눠 가독성을 회복했다.
결과 측정: 절대적인 품질 지표는 아니지만 가독성 개선과 함께 코드 라인이 줄었고, 서비스 레벨 테스트 커버리지가 증가했다.
팀 효과: 익숙하지 않은 영역을 의도적으로 맡아 전체 시스템 이해가 고르게 올라갔다. 반복적인 테스트 작성으로 테스트 코드에 대한 거부감도 낮아졌다.
지속성: 2차까지 배포하고 3차를 준비했지만 리팩토링을 종료 상태로 보지 않았다. 현재의 좋은 코드도 변화에 따라 다시 개선 대상이 된다는 관점을 남겼다.