백엔드
파트너오피스 리뉴얼, 왜 우리는 리팩터링을 하였는가?
두줄요약
파트너오피스 리뉴얼 과정에서 가독성 저하, 공용 구조, 미사용 코드 등을 정리하며 리팩터링을 진행했습니다. 그 결과 코드 라인 감소와 함께 서비스 이해도, 유지보수성이 함께 개선되었습니다.
문제 상황
- 중구난방한 코드 스타일과 지나친 축약어로 인한 낮은 가독성
- 여러 API가 같은 클래스와 Request, Response를 공유하며 생기는 수정 범위 확장과 사이드 이펙트 우려
- 미사용 변수·메서드, 매직 넘버, String 상태코드, 과도하게 긴 서비스 로직 등 레거시 누적
원인 분석
- 공통 클래스로 모든 기능과 필드를 묶은 구조로 인한 유지보수 난이도 상승
- 명명 규칙과 책임 분리가 통일되지 않아 코드 추적과 리뷰 효율 저하
- @Lazy와 범용화된 구조처럼 불필요하게 남은 설계 선택들
해결 방법
- 팀 코드 스타일 컨벤션 정의와 리뷰를 통한 규칙 통일
- 도메인 분리, VO 재정의, 미사용 코드 제거, Enum 전환으로 구조 단순화
- 정책·변환·예외처리 분리와 API별 Request, Response 분리로 책임 재배치
성능/운영 포인트
- 패키지 전체 라인 약 30% 감소, 일부 서비스 파일 292줄에서 119줄로 축소
- API별 입력·출력 분리로 스펙 변경 시 영향 범위 축소
- @Lazy 제거로 런타임 오류 지점 축소와 초기화 단계에서 문제 확인 유도
적용해볼 점
- 레거시도 한 번에 정리할 범위를 정해 점진적으로 개선
- 이름·책임·공유 구조를 먼저 점검해 리팩터링 우선순위 설정
- 팀 컨벤션과 리뷰를 통해 재발 방지 체계 마련
