Refactor/udt 276 추천 서비스 분리

[hjg727]

📝 요약(Summary)

무엇을 수정했나요?

콘텐츠 추천 서비스의 막대한 역할을 4개의 비즈니스 컴포넌트로 분리하여 콘텐츠 추천 서비스 클래스의 코드를 줄여나갔습니다.
그로 인한 여러 클래스들이 생성 및 테스트 코드 구현을 했습니다.

왜?

• 기존 문제점: ContentRecommendationService가 269줄의 복잡한 로직을 포함하며, 장르 분석, 점수 계산, 쿼리 빌드, 응답 생성 등 여러 책임을 가지고 있었습니다.
• 개선 효과:
  • 각 컴포넌트가 단일 책임만 가지도록 분리하여 유지보수성 향상
  • 테스트 용이성 증가 (Mock 의존성 감소)
  • 코드 가독성 및 재사용성 개선

주요 변경 사항

1. 4개의 새로운 컴포넌트 생성:

   • RecommendationScoreCalculator: 추천 점수 계산 로직 (171줄)
   • GenreAnalyzer: 장르 분석 및 파싱 로직 (73줄)
   • RecommendationQueryBuilder: 플랫폼 필터링 쿼리 생성 (48줄)
   • RecommendationResponseBuilder: 추천 응답 빌드 (43줄)

2. 기존 서비스 클래스 간소화:

   • ContentRecommendationService: 269줄 → 약 100줄로 감소
   • 핵심 비즈니스 플로우에만 집중

3. 테스트 커버리지 강화:

   • 각 컴포넌트별 단위 테스트 추가 (총 1,045줄의 테스트 코드)
   • 기존 통합 테스트도 새로운 구조에 맞게 리팩토링

💬 공유사항 to 리뷰어

고민: ContentRecommendationService 테스트 코드의 목적 -> 각 분리 클래스들의 상호작용을 테스트하자.

결론: Slice Test 전략 채택

• Mock: 외부 의존성만 (DB, Cache, Lucene)
• Real: 비즈니스 로직 컴포넌트 (GenreAnalyzer, ScoreCalculator, QueryBuilder, ResponseBuilder)
• 이유: 실제 협력 동작을 검증하면서도 빠른 테스트 유지

기존 방식

@Mock
private RecommendationScoreCalculator scoreCalculator;

@InjectMocks  
private ContentRecommendationService service;

• 모든 의존성을 Mock으로 처리
• 간결하지만 실제 비즈니스 로직 검증 부족

적절한 접근 방식

// Mock: 외부 의존성만
@Mock
private ContentRecommendationQuery contentRecommendationQuery;

// 실제 객체: 비즈니스 로직 컴포넌트
private RecommendationScoreCalculator scoreCalculator;
private GenreAnalyzer genreAnalyzer;

@BeforeEach
void setUp() {
    // new 연산자로 실제 객체 생성
    scoreCalculator = new RecommendationScoreCalculator();
    genreAnalyzer = new GenreAnalyzer(scoreCalculator);
    
    // 수동으로 의존성 주입
    service = new ContentRecommendationService(
        contentRecommendationQuery,
        luceneIndexService,
        luceneSearchService,
        cacheManager,
        scoreCalculator,  // 실제 객체
        genreAnalyzer,    // 실제 객체
        queryBuilder,     // 실제 객체
        responseBuilder   // 실제 객체
    );
}

왜 이렇게 변경했나요?

1. 실제 비즈니스 로직 검증: Mock이 아닌 실제 객체를 사용하여 점수 계산, 장르 분석 등의 로직이 올바르게 동작하는지 확인
2. 테스트 가독성 향상: 각 테스트가 무엇을 검증하는지 명확하게 드러남
3. 리팩토링 안정성: 내부 구현 변경 시 테스트가 실제 동작을 검증하므로 더 안전

테스트 코드 변경 사항

• shouldRecommendActionThrillerContent → shouldBoostScoreForPreferredGenres

  • Before: "장르 포함" 여부만 검증
  • After: 실제 순위 검증 (기생충 1위, 라라랜드 2위, 블랙팬서 3위)
  • 협력: GenreAnalyzer가 장르 추출 → ScoreCalculator가 부스트 적용 → 순위 변경

• shouldFilterByPlatform: 플랫폼 필터링 협력 검증

  • 협력: QueryBuilder가 디즈니+ 필터링 → 디즈니+ 콘텐츠 2개 이상 포함

• mockLuceneSearchService()

  • 목적 명시: "실제 Lucene 인프라 테스트가 아닌 추천 로직만 테스트"

리뷰 요청 사항

1. 컴포넌트 분리 기준이 적절한지 검토 부탁드립니다.

   • 각 클래스가 단일 책임을 잘 가지고 있는지
   • 더 분리하거나 합쳐야 할 부분이 있는지!!!

2. 테스트 작성 방식에 대한 의견 부탁드립니다.

   • DAMP 원칙 적용이 우리 프로젝트에 적합한지
   • new 연산자로 직접 생성하는 방식에 대한 의견

참고사항

• 기존 기능에 영향 없이 내부 구조만 변경했습니다.
• 모든 기존 테스트가 통과하며, 추가로 1,000줄 이상의 단위 테스트를 작성했습니다.
• 추후 각 컴포넌트를 독립적으로 확장/수정할 수 있습니다.

✅ PR Checklist

PR이 다음 요구 사항을 충족하는지 확인하세요.

• 커밋 메시지 컨벤션에 맞게 작성했습니다.
• 변경 사항에 대한 테스트를 했습니다.(버그 수정/기능에 대한 테스트).
• 기존 테스트가 모두 통과합니다.
• 새로운 단위 테스트를 추가했습니다. (4개 클래스, 1,045줄)

🤔 Review 예상 시간

• 20분 😭

[github-actions]

refactor/UDT-276-추천-서비스-분리 브랜치 빌드 테스트에 성공했습니다! 🎉

[github-actions]

refactor/UDT-276-추천-서비스-분리 브랜치 빌드 테스트에 성공했습니다! 🎉

[LGAIN]

고생하셨습니다~! 👍