파트너오피스 리뉴얼, 왜 우리는 리팩터링을 하였는가?

Context

파트너오피스 플랫폼의 백엔드 코드베이스가 개발자마다 다른 명명 규칙, 축약어 과다 사용(pnlt, entr, onl_brnd_nm), 158개 필드를 가진 거대한 베이스 클래스(EtEntrBaseEx)로 인해 가독성과 유지보수성이 심각하게 저하된 상태였다. 기존 기능 수정 시 의존 관계를 파악하기 어렵고, 사용하지 않는 변수와 메서드가 숨어있으며, API 스펙 변경 시 예상치 못한 사이드 이펙트가 발생하는 문제가 있었다.

Technical Solution

• 팀 코드 스타일 컨벤션 정의: 클래스명, 변수명, 메서드명(get/search/find, persist/save/regist, update/modify, delete/remove) 등 10개 항목에 대해 61개 코멘트를 통해 통일
• 거대한 베이스 클래스 분해: EtEntrBaseEx(70개 필드) + EtEntrBase(64개 필드) + BaseCommonEntity(24개 필드)를 도메인별로 분리하고 관련 필드를 Value Object(VO)로 재정의
• 미사용 코드 제거: IDE 정적 분석 도구를 활용해 사용되지 않는 변수와 메서드를 식별 후 2차 확인을 거쳐 제거
• String 기반 상태값을 Enum으로 변환: 매직 스트링(O-1000, D-1000, D-1001 등)을 Enum으로 변경하여 타입 안정성 확보
• Request/Response 구조 개선: 여러 API에서 공용하던 클래스를 API당 하나씩 InnerClass로 매핑(xxx.Request, xxx.Response)
• @Lazy 애노테이션 제거: 런타임 성능 저하 가능성, 예상치 못한 오류 발생 시점 지연, 순환참조 부재 등의 사유로 모두 제거
• 비즈니스 로직 분리: 110줄의 단일 메서드에서 변수 설정, 정책 확인, 예외처리 등을 별도 메서드로 추출하여 책임 분담

Impact

• 특정 서비스 파일 코드 라인: 292줄 → 119줄(60% 감소)
• 전체 패키지 코드 라인: 약 30% 감소
• String 상수값이 Enum으로 변환되어 코드 가독성 향상 및 타입 안정성 확보

Key Takeaway

코드 개선은 단순히 라인 감소가 아니라 일관된 명명 규칙, 단일 책임 원칙 적용, 타입 안정성 확보를 통해 온보딩 시간 단축과 버그 발생 포인트 조기 발견을 가능하게 한다. 신규 입사자가 2~3개월 내에 대규모 서비스의 비즈니스 로직을 정확히 이해할 수 있다는 것은 설계 개선의 구체적 가치이다.