트러블슈팅

관리자 기능 확장에 따른 Controller·Service 구조 개선

문제 상황

초기 관리자 기능은 하나의 AdminController와 AdminService에서 처리하도록 구현하였다.

AdminController
      ↓
AdminService
 ├── 대시보드
 ├── 신고 관리
 ├── 회원 관리
 ├── 판매자 신청 관리
 └── 상품 관리

관리자 기능이 추가되면서 하나의 Controller와 Service에 여러 도메인의 API와 비즈니스 로직이 집중되었다.

그 결과 특정 기능을 수정하기 위해 관련 없는 코드까지 함께 확인해야 했으며, 새로운 관리자 기능을 추가할 때 기존 클래스의 코드가 계속 증가하는 문제가 발생했다. 또한 Controller에서 여러 Service를 직접 의존하게 되면서 클래스 간 결합도 역시 높아졌다.

원인

기능의 구분 없이 관리자 기능이라는 큰 범위만을 기준으로 Controller와 Service를 구성한 것이 원인이었다.

특히 각 기능이 서로 다른 책임을 가지고 있음에도 하나의 Service에서 회원, 신고, 상품 등의 비즈니스 로직을 모두 처리하고 있었다.

해결

관리자 기능을 도메인별로 분리하여 각 기능이 독립적인 책임을 갖도록 구조를 변경하였다.

AdminMemberController  → AdminMemberService
AdminReportController  → AdminReportService
AdminSellerController  → AdminSellerService
AdminProductController  → AdminProductService

대시보드처럼 여러 도메인의 데이터를 하나의 응답으로 조합해야 하는 기능은 각 Service를 Controller에서 직접 호출하지 않고 AdminDashboardService가 조합하도록 구성하였다.

AdminDashboardController
          ↓
AdminDashboardService
     ┌────┼────┬────┐
     ↓    ↓    ↓    ↓
  Member Report Seller Product
  Service Service Service Service

이를 통해 Controller는 HTTP 요청과 응답 처리에 집중하고, 각 도메인의 비즈니스 로직은 해당 Service에서 담당하도록 책임을 분리하였다.

결과

• 관리자 기능별 책임이 명확해져 코드 탐색과 유지보수가 쉬워졌다.
• 특정 기능을 수정할 때 관련 없는 도메인의 코드를 확인해야 하는 범위를 줄였다.
• 새로운 관리자 기능을 추가할 때 기존 Controller와 Service의 코드 증가를 최소화할 수 있었다.
• Controller가 여러 도메인의 Service를 직접 의존하지 않도록 하여 의존 관계를 단순화하였다.
• 여러 도메인의 기능을 조합해야 하는 대시보드는 상위 Service에서 조합하도록 하여 각 도메인 Service의 책임을 유지할 수 있었다.

개선 후 구조

admin
├── dashboard
│   ├── AdminDashboardController
│   └── AdminDashboardService
│
├── member
│   ├── AdminMemberController
│   └── AdminMemberService
│
├── report
│   ├── AdminReportController
│   └── AdminReportService
│
├── seller
│   ├── AdminSellerController
│   └── AdminSellerService
│
└── product
    ├── AdminProductController
    └── AdminProductService

이번 개선을 통해 단순히 클래스를 분리하는 것에 그치지 않고, 각 기능의 책임과 의존 관계를 기준으로 구조를 재설계하여 기능 확장에 대응하기 쉬운 구조로 개선하였다.