통계 대시보드 불필요한 추상화 걷어내 유지보수 부담 줄인 리팩토링

통계 대시보드 리팩토링을 하면서 hourly lap 블록을 제거하고 설명을 간소화했다. 겉으로는 작은 변경이지만, 이런 결정이 코드 유지보수성과 팀의 인지 부하에 미치는 영향을 정리해본다.

과도한 추상화의 신호

hourly lap block이라는 표현부터 그 자체로 문제를 드러낸다. 개발자가 코드를 읽을 때 이 개념이 무엇인지 순간적으로 이해하기 어려웠을 거고, 실제로 기능을 하는 부분이 해당 구문이었는가를 계속 검증해야 한다. 통계 대시보드에서 "시간별 주기"라는 개념이 정말 필요했는가, 아니면 특정 성능 최적화나 비즈니스 요구사항의 잔재였는가를 판단하는 것이 리팩토링의 출발점이었다.

내가 많이 봤던 패턴이 이거다. 초기 구현에서는 성능이나 특수한 처리 요건 때문에 어떤 단계적 처리(lap block)가 필요했는데, 시간이 지나 기능이 진화하면서 그 제약이 사라진다. 그런데 코드는 남아있고, 새로운 개발자는 그 이유를 모른 채 "이게 왜 필요한 건가?" 하며 10분을 낭비한다. 이게 반복되면 기술 부채가 된다.

단순함의 가치

리팩토링은 보통 "더 좋은 구조로 재편성한다"고 생각하지만, 이번 경우는 명확하게 "제거"였다. 추가 추상화 계층을 걷어내고, description도 간결하게 했다.

이런 변경을 할 때 항상 확인하는 것:
- 기존 lap block이 실제로 기능 요구사항을 구현했는가, 아니면 구현 최적화만 했는가
- 제거 후에도 통계 수집/대시보드 표시가 정확한가
- 팀의 온보딩 시간이 줄어드는가

회고: 간결함이 먼저

개발하면서 "기능"을 추가하는 것만큼 중요한 게 불필요한 것을 제거하는 타이밍이다. 특히 대시보드처럼 주기적으로 접근하는 모듈은 한 번 복잡해지면 그 혼란이 계속된다. 코드 리뷰 때 "이 부분은 왜 이렇게 복잡한가"라는 질문이 반복되면, 그게 신호다.

이번 작업을 통해 팀과 함께 정한 원칙 중 하나가 있다: 명확한 이유 없이 추상화 계층을 만들지 말자. 한두 곳에서만 쓰이는 로직을 범용화하려다 보면, 그 범용성 자체가 이해 비용을 올린다. 나중에 정말 필요하면 그 때 추상화하면 된다.

stats 대시보드 같은 ops 성격의 모듈은 동료들이 자주 들어가 수정한다. 그 진입장벽을 낮추는 것만으로도 버그 제보가 명확해지고, 개선 제안이 쉬워진다.

🛒 이 글과 어울리는 추천 상품

• 기계식키보드 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.