Round10 #241

sylee6529 · 2026-01-02T08:27:14Z

📌 Summary

주간/월간 상품 랭킹 집계 시스템을 구현했습니다.

주요 구현 내용:

Chunk-Oriented Processing으로 ProductMetrics 데이터를 읽어 가중치 기반 점수 계산
전체 상품 중 TOP 100 랭킹을 Materialized View 테이블에 저장
주간/월간 기간별 랭킹 조회 API 제공 (페이지네이션 지원)

배치 처리 플로우:

ProductMetrics → JdbcPagingItemReader → RankingScoreProcessor
→ InMemoryCollector → StepListener(정렬 & TOP 100 저장) → Materialized View

💬 Review Points

1.QueryDSL 벌크 DELETE vs JPA deleteBy 선택

현재 구현 (QueryDSL 벌크 DELETE):

queryFactory.delete(weeklyRanking)
    .where(weeklyRanking.weekStartDate.eq(weekStartDate))
    .execute();  // 1개 쿼리

JPA deleteBy 방식:

void deleteByWeekStartDate(LocalDate weekStartDate);
// SELECT 1개 + DELETE N개 = N+1 쿼리

질문:

QueryDSL 벌크 DELETE는 영속성 컨텍스트를 거치지 않아 동기화 문제가 있을 수 있는데, 배치 환경에서는 안전한가요?
@Query + @Modifying(clearAutomatically = true)를 사용하는 것이 더 안전한가요?

2.StepExecutionListener에서 DELETE + SAVE 트랜잭션 분리 문제

현재 구현:

// Repository 메서드별로 독립적인 트랜잭션
@Override
@Transactional
public void deleteByWeekStartDate(LocalDate weekStartDate) { ... }

@Override
@Transactional
public void saveAll(List<WeeklyRanking> rankings) { ... }

StepExecutionListener에서 호출:

weeklyRankingRepository.deleteByWeekStartDate(weekStartDate);  // 트랜잭션 1
weeklyRankingRepository.saveAll(rankedList);  // 트랜잭션 2

질문:

DELETE 성공 후 SAVE 실패 시 → 랭킹 데이터 손실될 수 있습니다. DELETE + SAVE를 하나의 트랜잭션으로 묶어야 할까요?
서비스 레이어를 추가하여 @Transactional replaceWeeklyRanking() 메서드를 만드는 것이 나을까요?

3. 랭킹데이터를 쌓을 때, 모든 데이터에 대한 랭킹을 쌓지는 않을 것 같은데, Top-100이면 100개만 저장하는 식으로 구현하시나요?

✅ Checklist

🧱 Spring Batch

Spring Batch Job 을 작성하고, 파라미터 기반으로 동작시킬 수 있다.
Chunk Oriented Processing (Reader/Processor/Writer or Tasklet) 기반의 배치 처리를 구현했다.
집계 결과를 저장할 Materialized View 의 구조를 설계하고 올바르게 적재했다.

🧩 Ranking API

API 가 일간, 주간, 월간 랭킹을 제공하며 조회해야 하는 형태에 따라 적절한 데이터를 기반으로 랭킹을 제공한다.

Summary by CodeRabbit

출시 노트

새로운 기능
- 조회수, 좋아요 및 판매 메트릭을 기반으로 주간 및 월간 상위 100개 상품 랭킹을 계산하는 배치 작업 추가
- 주간 및 월간 랭킹 계산을 수동으로 실행할 수 있는 관리자 엔드포인트 추가
- 일별, 주간, 월간 랭킹을 기간별로 조회할 수 있도록 랭킹 API 확장
인프라
- Spring Batch 구성 및 자동 스키마 초기화를 포함한 배치 처리 모듈 초기화

_{✏️ Tip: You can customize this high-level summary in your review settings.}

Spring Boot 3.x Auto-configuration 사용을 위해 @EnableBatchProcessing 제거 Batch 모듈을 별도 모듈로 분리하여 재사용성 향상

주간/월간 랭킹을 위한 Entity 및 Repository 인터페이스 추가 기간 타입(DAILY/WEEKLY/MONTHLY) 및 날짜 계산 유틸리티 구현

QueryDSL 기반 Repository 구현으로 N+1 문제 해결 주간/월간 TOP 100 랭킹 저장을 위한 MV 테이블 DDL 추가 트랜잭션 처리 및 QueryDSL delete 쿼리 최적화

ProductMetricsDto: 배치 Reader가 읽어올 DTO RankedProductDto: 점수 계산 후 정렬용 DTO RankingScoreProcessor: 가중치 기반 점수 계산 (view 0.1, like 0.2, order 0.6) InMemoryRankingCollector: Step 완료 후 정렬을 위한 메모리 수집기

Chunk-Oriented Processing (CHUNK_SIZE=100) 적용 JdbcPagingItemReader로 product_metrics 페이징 조회 StepExecutionListener에서 정렬 후 TOP 100 선택 및 저장 Reader 초기화를 위한 afterPropertiesSet() 호출 추가

RankingService: 주간/월간 랭킹 조회 및 N+1 해결 RankingFacade: PeriodType에 따라 DAILY/WEEKLY/MONTHLY 분기 처리 배치 조회로 상품 및 브랜드 정보 효율적 조회

BatchJobController: 주간/월간 랭킹 집계 Job 수동 실행 API RankingV1Controller: period 파라미터로 일간/주간/월간 선택 지원 batch.yml 설정 import 추가

WeeklyRankingJobTest: 주간 랭킹 배치 3개 시나리오 테스트 MonthlyRankingJobTest: 월간 랭킹 배치 4개 시나리오 테스트 TestContainers 기반 실제 MySQL 환경 테스트 init-ranking-tables.sql: 테스트용 DDL 스크립트

coderabbitai · 2026-01-02T08:27:24Z

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

개요

이 PR은 Spring Batch를 활용한 주간 및 월간 상품 랭킹 배치 작업을 도입합니다. 새로운 배치 모듈, 랭킹 엔티티, 저장소, 프로세서, 그리고 RankingFacade를 통한 다중 기간 조회 기능(일일, 주간, 월간)을 추가합니다.

변경 사항

그룹 / 파일(들)	변경 요약
배치 모듈 설정 `modules/batch/build.gradle.kts`, `modules/batch/src/main/java/com/loopers/config/batch/BatchConfig.java`, `modules/batch/src/main/resources/batch.yml`, `apps/commerce-api/build.gradle.kts`, `settings.gradle.kts`	배치 모듈 추가, Spring Batch 스타터 의존성 구성, 자동 실행 비활성화 설정, 상위 build 파일에서 배치 모듈 참조
배치 작업 구성 `apps/commerce-api/src/main/java/com/loopers/application/batch/WeeklyRankingJobConfig.java`, `apps/commerce-api/src/main/java/com/loopers/application/batch/MonthlyRankingJobConfig.java`	주간/월간 랭킹 배치 작업 정의, JDBC Paging Reader, 랭킹 스코어 프로세서, 메모리 수집기, StepExecutionListener를 통한 후처리(정렬, TOP 100 선정, 랭킹 할당, 저장)
배치 데이터 전달 객체 및 프로세서 `apps/commerce-api/src/main/java/com/loopers/application/batch/dto/ProductMetricsDto.java`, `apps/commerce-api/src/main/java/com/loopers/application/batch/dto/RankedProductDto.java`, `apps/commerce-api/src/main/java/com/loopers/application/batch/processor/RankingScoreProcessor.java`	ProductMetricsDto 레코드, 정렬 가능한 RankedProductDto 레코드, 가중치 기반 총점 계산 프로세서(조회·좋아요·주문 가중치 및 로그 정규화)
배치 쓰기 구성 요소 `apps/commerce-api/src/main/java/com/loopers/application/batch/writer/InMemoryRankingCollector.java`	청크별 아이템을 동기화된 리스트에 수집하는 ItemWriter 구현, 수집 크기 및 정보 조회 메서드 제공
도메인 랭킹 엔티티 및 저장소 `apps/commerce-api/src/main/java/com/loopers/domain/ranking/weekly/WeeklyRanking.java`, `apps/commerce-api/src/main/java/com/loopers/domain/ranking/weekly/WeeklyRankingRepository.java`, `apps/commerce-api/src/main/java/com/loopers/domain/ranking/monthly/MonthlyRanking.java`, `apps/commerce-api/src/main/java/com/loopers/domain/ranking/monthly/MonthlyRankingRepository.java`	JPA 엔티티(주간/월간 랭킹), 조회·페이지네이션·삭제·일괄 저장 메서드가 포함된 저장소 인터페이스
도메인 유틸리티 및 서비스 `apps/commerce-api/src/main/java/com/loopers/domain/ranking/PeriodType.java`, `apps/commerce-api/src/main/java/com/loopers/domain/ranking/PeriodUtils.java`, `apps/commerce-api/src/main/java/com/loopers/domain/ranking/RankingService.java`	PeriodType 열거형(DAILY, WEEKLY, MONTHLY), 주간/월간 범위 계산 유틸리티, 페이지네이션을 사용한 주간/월간 랭킹 조회 및 N+1 회피를 위한 배치 상품·브랜드 로드
인프라 저장소 구현 `apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/weekly/WeeklyRankingJpaRepository.java`, `apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/weekly/WeeklyRankingRepositoryImpl.java`, `apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/monthly/MonthlyRankingJpaRepository.java`, `apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/monthly/MonthlyRankingRepositoryImpl.java`	JPA 저장소 인터페이스 및 QueryDSL 기반 구현, 주간/월간 조회 및 삭제 기능
API 레이어 `apps/commerce-api/src/main/java/com/loopers/interfaces/api/batch/BatchJobController.java`, `apps/commerce-api/src/main/java/com/loopers/interfaces/api/ranking/RankingV1Controller.java`, `apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingFacade.java`	배치 작업 실행을 위한 /admin/batch 엔드포인트(주간/월간), RankingV1Controller에 PeriodType 매개변수 추가, RankingFacade를 일일/주간/월간 조회로 확장
데이터베이스 스키마 `apps/commerce-api/src/test/resources/db/init-ranking-tables.sql`, `docker/mysql/init/03-ranking-materialized-views.sql`	mv_product_rank_weekly, mv_product_rank_monthly, product_metrics 테이블 생성(인덱스, 주석 포함)
테스트 `apps/commerce-api/src/test/java/com/loopers/application/batch/WeeklyRankingJobTest.java`, `apps/commerce-api/src/test/java/com/loopers/application/batch/MonthlyRankingJobTest.java`	150개 메트릭 삽입 및 TOP 100 검증, 100 미만 데이터 처리, 월/주 간 격리, 기존 데이터 삭제를 확인하는 통합 테스트

시퀀스 다이어그램

주간/월간 랭킹 배치 작업 흐름

sequenceDiagram
    participant JobLauncher
    participant BatchJob as Batch Job
    participant Reader
    participant Processor as Processor<br/>(Score Calc)
    participant Collector as Memory<br/>Collector
    participant Listener as Step<br/>Listener
    participant DB as Database
    
    JobLauncher->>BatchJob: Launch with targetDate
    
    rect rgb(200, 220, 255)
        note over Reader,Collector: Chunk Processing Loop
        Reader->>DB: Read ProductMetrics (paginated)
        Reader-->>Processor: ProductMetricsDto
        Processor->>Processor: Calculate weighted score<br/>(view, like, order)
        Processor-->>Collector: RankedProductDto
        Collector->>Collector: Collect in memory
    end
    
    rect rgb(220, 255, 220)
        note over Listener,DB: After Step Execution
        Listener->>Listener: Parse targetDate
        Listener->>Listener: Compute week/month range
        Listener->>DB: Delete old rankings<br/>for period
        Listener->>Collector: Get all collected items
        Listener->>Listener: Sort by score (DESC)
        Listener->>Listener: Select TOP 100
        Listener->>Listener: Assign rank positions
        Listener->>DB: Persist MonthlyRanking<br/>or WeeklyRanking
        Listener->>Listener: Log completion
    end
    
    BatchJob-->>JobLauncher: Job Completed

API 랭킹 조회 흐름 (주간/월간)

sequenceDiagram
    participant Client
    participant Controller as RankingV1<br/>Controller
    participant Facade as Ranking<br/>Facade
    participant Service as Ranking<br/>Service
    participant WeekRepo as Weekly/Monthly<br/>Repository
    participant ProductRepo as Product<br/>Repository
    participant BrandRepo as Brand<br/>Repository
    
    Client->>Controller: GET /rankings?period=WEEKLY&page=1
    Controller->>Facade: getRankings(date, WEEKLY, page, size)
    
    alt period == WEEKLY or MONTHLY
        Facade->>Service: getWeeklyRankings<br/>or getMonthlyRankings<br/>(targetDate, page, size)
        Service->>WeekRepo: findByWeekStartDate<br/>WithPagination
        WeekRepo->>WeekRepo: Query with LIMIT/OFFSET
        WeekRepo-->>Service: List<WeeklyRanking>
        
        rect rgb(255, 240, 200)
            note over ProductRepo,BrandRepo: Batch Loading (避免 N+1)
            Service->>ProductRepo: loadProductsByIds<br/>(collected productIds)
            ProductRepo-->>Service: Map<Long, Product>
            Service->>BrandRepo: loadBrandsByIds<br/>(collected brandIds)
            BrandRepo-->>Service: Map<Long, Brand>
        end
        
        Service->>Service: Build RankingItemInfo list<br/>(rank, product, brand, score)
        Service-->>Facade: RankingPageInfo
    else period == DAILY
        Facade->>Facade: getDailyRankings<br/>(from ProductRankingCache)
    end
    
    Facade-->>Controller: RankingPageInfo
    Controller-->>Client: ApiResponse<RankingPageResponse>

예상 코드 리뷰 노력

🎯 4 (복잡함) | ⏱️ ~60 분

제안된 레이블

enhancement

🐰 배치로 열심히 정렬하고,
주간, 월간 랭킹을 계산하고,
TOP 100은 영광의 자리,
점수로 점프하는 상품들,
이제 모든 시간을 품안에! 🌟

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 39.47% which is insufficient. The required threshold is 80.00%.	You can run `@coderabbitai generate docstrings` to improve docstring coverage.
Title check	❓ Inconclusive	제목 'Round10'은 매우 모호하고 PR의 실제 변경 내용을 전혀 설명하지 않습니다.	PR의 주요 변경 사항을 명확히 반영하는 구체적인 제목으로 변경하세요. 예: 'feat: 주간/월간 상품 랭킹 배치 시스템 구현'

✅ Passed checks (1 passed)

Check name	Status	Explanation
Description check	✅ Passed	PR 설명이 요약, 리뷰 포인트, 체크리스트를 포함하여 템플릿 구조를 대체로 따르고 있습니다.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

coderabbitai

Actionable comments posted: 7

♻️ Duplicate comments (1)

apps/commerce-api/src/main/java/com/loopers/application/batch/MonthlyRankingJobConfig.java (1)

143-160: WeeklyRankingJobConfig에서 언급한 동일한 동시 실행 위험이 존재합니다

deleteByMonthYear() 후 saveAll() 사이에 경합 조건이 발생할 수 있습니다. month_year와 rank_position에 대한 유니크 제약 조건 추가를 고려해 주세요.

🧹 Nitpick comments (21)

docker/mysql/init/03-ranking-materialized-views.sql (1)
1-28: DDL 구조가 잘 설계되었습니다.

인덱스 전략이 기간별 조회(idx_week_product, idx_month_product)와 상품별 이력 조회(idx_product_week, idx_product_month) 모두를 효율적으로 지원합니다.

몇 가지 고려 사항:
데이터 무결성: 동일 기간 내 동일 product_id의 중복 삽입을 방지하려면 UNIQUE 제약 조건 추가를 고려하세요:
UNIQUE KEY uk_week_product (week_start_date, product_id),
UNIQUE KEY uk_month_product (month_year, product_id),
점수 정밀도: DOUBLE은 부동소수점 오차가 발생할 수 있습니다. 정밀한 점수 비교가 필요하다면 DECIMAL(10,4) 사용을 고려하세요.
apps/commerce-api/src/main/java/com/loopers/interfaces/api/ranking/RankingV1Controller.java (1)
33-34: 날짜 형식 검증 추가 권장

date 파라미터가 yyyyMMdd 형식이어야 하지만 형식 검증이 없습니다. 잘못된 형식의 날짜가 입력되면 RankingFacade나 하위 레이어에서 파싱 오류가 발생할 수 있습니다.
🔎 날짜 형식 검증 추가
+import jakarta.validation.constraints.Pattern;
+
 @GetMapping("/rankings")
 public ApiResponse<RankingPageResponse> getRankings(
-        @RequestParam(value = "date", required = false) String date,
+        @RequestParam(value = "date", required = false) 
+        @Pattern(regexp = "^\\d{8}$", message = "날짜는 yyyyMMdd 형식이어야 합니다") 
+        String date,
         @RequestParam(value = "period", defaultValue = "DAILY") PeriodType period,
apps/commerce-api/src/main/java/com/loopers/domain/ranking/weekly/WeeklyRanking.java (1)
30-34: MonthlyRanking과의 일관성을 위해 주차 식별자 필드 추가 고려

MonthlyRanking에는 monthYear 필드(예: "2024-01")가 있어 월별 조회가 편리한데, WeeklyRanking에는 이에 대응하는 주차 식별자 필드가 없습니다. 주 단위 조회 시 날짜 범위 비교가 필요하여 쿼리가 복잡해질 수 있습니다.
🔎 주차 식별자 필드 추가 예시
 @Column(name = "week_end_date", nullable = false) 
 private LocalDate weekEndDate;
 
+@Column(name = "week_identifier", nullable = false)
+private String weekIdentifier; // 예: "2024-W01", "2024-W52"
+
 public WeeklyRanking(Integer rankPosition, Long productId, Double totalScore, 
-                    LocalDate weekStartDate, LocalDate weekEndDate) {
+                    LocalDate weekStartDate, LocalDate weekEndDate, String weekIdentifier) {
     this.rankPosition = rankPosition;
     this.productId = productId;
     this.totalScore = totalScore;
     this.weekStartDate = weekStartDate;
     this.weekEndDate = weekEndDate;
+    this.weekIdentifier = weekIdentifier;
 }
apps/commerce-api/src/main/java/com/loopers/domain/ranking/monthly/MonthlyRanking.java (1)
11-48: LGTM! 엔티티 구조가 적절합니다.

JPA 엔티티가 올바르게 설계되었습니다. @NoArgsConstructor(access = AccessLevel.PROTECTED)로 JPA 요구사항을 충족하고, WeeklyRanking과 일관된 구조를 유지합니다.

선택적으로, 생성자 파라미터에 대한 null 검증 추가를 고려해볼 수 있습니다:
🔎 Null 검증 추가 예시
 public MonthlyRanking(Integer rankPosition, Long productId, Double totalScore,
                       String monthYear, LocalDate monthStartDate, LocalDate monthEndDate) {
+    Objects.requireNonNull(rankPosition, "rankPosition must not be null");
+    Objects.requireNonNull(productId, "productId must not be null");
     this.rankPosition = rankPosition;
     this.productId = productId;
     this.totalScore = totalScore;
     this.monthYear = monthYear;
     this.monthStartDate = monthStartDate;
     this.monthEndDate = monthEndDate;
 }
apps/commerce-api/src/main/java/com/loopers/domain/ranking/PeriodUtils.java (3)
8-8: 유틸리티 클래스에 private 생성자가 없습니다.

인스턴스화를 방지하기 위해 private 생성자를 추가하는 것이 좋습니다.
🔎 Private 생성자 추가
 public class PeriodUtils {
+    
+    private PeriodUtils() {
+        // Utility class - prevent instantiation
+    }
     
     private static final DateTimeFormatter MONTH_FORMATTER = DateTimeFormatter.ofPattern("yyyy-MM");
50-52: DateTimeFormatter를 호출마다 생성하고 있습니다.

parseDate 메서드에서 매번 새로운 DateTimeFormatter를 생성합니다. MONTH_FORMATTER처럼 상수로 추출하면 효율적입니다.
🔎 Formatter 상수화
 public class PeriodUtils {
     
     private static final DateTimeFormatter MONTH_FORMATTER = DateTimeFormatter.ofPattern("yyyy-MM");
+    private static final DateTimeFormatter DATE_FORMATTER = DateTimeFormatter.ofPattern("yyyyMMdd");
     
     // ... 
     
     public static LocalDate parseDate(String dateString) {
-        return LocalDate.parse(dateString, DateTimeFormatter.ofPattern("yyyyMMdd"));
+        return LocalDate.parse(dateString, DATE_FORMATTER);
     }
22-24: getWeekEndDate 메서드 간소화 가능.

DayOfWeek.SUNDAY를 직접 사용하면 더 간결하고 명확합니다.
🔎 간소화된 구현
 public static LocalDate getWeekEndDate(LocalDate date) {
-    return date.with(DayOfWeek.MONDAY).plusDays(6);
+    return date.with(DayOfWeek.SUNDAY);
 }
apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/monthly/MonthlyRankingJpaRepository.java (1)
15-17: 파라미터 순서가 일반적인 패턴과 다릅니다.

메서드 시그니처에서 offset이 limit 앞에 있습니다. SQL의 LIMIT ... OFFSET 순서와 일치하도록 limit, offset 순서가 더 직관적입니다.
🔎 파라미터 순서 변경
-    List<MonthlyRanking> findByMonthYearWithPagination(String monthYear, int offset, int limit);
+    List<MonthlyRanking> findByMonthYearWithPagination(String monthYear, int limit, int offset);
apps/commerce-api/src/main/java/com/loopers/interfaces/api/batch/BatchJobController.java (2)
44-47: 예외 메시지 노출 주의

e.getMessage()를 응답에 직접 포함하면 내부 구현 세부 사항(스택 정보, DB 오류 등)이 외부에 노출될 수 있습니다. 프로덕션 환경에서는 일반적인 오류 메시지만 반환하고 상세 정보는 로그에만 기록하는 것이 좋습니다.
🔎 제안된 수정
         } catch (Exception e) {
             log.error("주간 랭킹 집계 Job 실행 실패", e);
-            return ApiResponse.fail("BATCH_ERROR", "주간 랭킹 집계 Job 실행에 실패했습니다: " + e.getMessage());
+            return ApiResponse.fail("BATCH_ERROR", "주간 랭킹 집계 Job 실행에 실패했습니다.");
         }
27-74: 중복 코드 리팩토링 고려

runWeeklyRankingJob과 runMonthlyRankingJob 메서드가 거의 동일한 구조를 가지고 있습니다. 공통 로직을 private 헬퍼 메서드로 추출하면 유지보수성이 향상됩니다.
🔎 리팩토링 예시
private ApiResponse<Object> runRankingJob(Job job, String targetDate, String jobName) {
    try {
        String dateParam = targetDate != null ? targetDate : LocalDate.now().toString();
        
        JobParameters jobParameters = new JobParametersBuilder()
            .addString("targetDate", dateParam)
            .addLong("timestamp", System.currentTimeMillis())
            .toJobParameters();
        
        jobLauncher.run(job, jobParameters);
        
        log.info("{} Job 실행 완료 - targetDate: {}", jobName, dateParam);
        return ApiResponse.success(jobName + " Job이 성공적으로 실행되었습니다.");
        
    } catch (Exception e) {
        log.error("{} Job 실행 실패", jobName, e);
        return ApiResponse.fail("BATCH_ERROR", jobName + " Job 실행에 실패했습니다.");
    }
}
apps/commerce-api/src/test/java/com/loopers/application/batch/MonthlyRankingJobTest.java (1)
198-202: 주석과 구현이 일치하지 않음

주석에는 "점수가 다양하도록 랜덤하게 생성"이라고 되어 있지만, 실제 구현은 결정적(deterministic) 방식으로 점수를 부여합니다. 이는 테스트 재현성 측면에서 올바른 접근이므로 주석을 수정하는 것이 좋겠습니다.
🔎 제안된 수정
     /**
      * 샘플 ProductMetrics 데이터 생성
      * - productId: 1부터 count까지
-     * - 점수가 다양하도록 랜덤하게 생성
+     * - productId 역순으로 점수 부여 (테스트 재현성을 위해 결정적 값 사용)
      */
apps/commerce-api/src/test/java/com/loopers/application/batch/WeeklyRankingJobTest.java (3)
170-174: 주석과 구현이 일치하지 않음

MonthlyRankingJobTest와 동일하게, 주석에는 "랜덤하게 생성"이라고 되어 있지만 실제로는 결정적 방식입니다.
🔎 제안된 수정
     /**
      * 샘플 ProductMetrics 데이터 생성
      * - productId: 1부터 count까지
-     * - 점수가 다양하도록 랜덤하게 생성
+     * - productId 역순으로 점수 부여 (테스트 재현성을 위해 결정적 값 사용)
      */
138-168: 다른 주(week) 데이터 격리 테스트 누락

MonthlyRankingJobTest에는 shouldNotAffectOtherMonthsRanking 테스트가 있지만, 이 테스트 클래스에는 유사한 "다른 주의 랭킹 데이터가 영향받지 않는다" 테스트가 없습니다. 배치 작업의 격리성을 보장하려면 추가하는 것이 좋겠습니다.

다른 주 데이터 격리 테스트 코드를 생성해 드릴까요?

175-188: 테스트 유틸리티 중복 코드

insertSampleProductMetrics 메서드가 MonthlyRankingJobTest와 동일하게 구현되어 있습니다. 테스트 유틸리티 클래스로 추출하면 유지보수가 용이해집니다.
apps/commerce-api/src/main/java/com/loopers/domain/ranking/RankingService.java (3)
53-56: 전체 데이터 조회로 인한 성능 문제

totalCount를 구하기 위해 모든 랭킹 데이터를 조회하고 있습니다. 랭킹 데이터가 최대 100개로 제한되어 있어 현재는 심각하지 않지만, 향후 확장성을 위해 별도의 count 쿼리를 추가하는 것이 좋습니다.
🔎 제안된 수정

Repository에 count 메서드 추가:
// WeeklyRankingRepository
long countByWeekStartDate(LocalDate weekStartDate);
Service에서 사용:
-        // 3. 전체 개수 조회
-        List<WeeklyRanking> allRankings = weeklyRankingRepository
-            .findByWeekStartDateOrderByRankPosition(weekStartDate);
-        long totalCount = allRankings.size();
+        // 3. 전체 개수 조회
+        long totalCount = weeklyRankingRepository.countByWeekStartDate(weekStartDate);
95-138: Weekly/Monthly 빌더 메서드 중복

buildRankingItemsFromWeekly와 buildRankingItemsFromMonthly가 거의 동일한 로직을 가지고 있습니다. 공통 인터페이스나 제네릭을 활용하여 중복을 줄일 수 있습니다.
🔎 리팩토링 예시
private <T> List<RankingItemInfo> buildRankingItems(
    List<T> rankings,
    Function<T, Long> productIdExtractor,
    Function<T, Integer> rankPositionExtractor,
    Function<T, Double> scoreExtractor,
    String logPrefix
) {
    List<Long> productIds = rankings.stream()
        .map(productIdExtractor)
        .toList();
    
    List<Product> products = productRepository.findByIdIn(productIds);
    Map<Long, Product> productMap = products.stream()
        .collect(Collectors.toMap(Product::getId, Function.identity()));
    
    List<Long> brandIds = products.stream()
        .map(Product::getBrandId)
        .distinct()
        .toList();
    List<Brand> brands = brandRepository.findByIdIn(brandIds);
    Map<Long, Brand> brandMap = brands.stream()
        .collect(Collectors.toMap(Brand::getId, Function.identity()));
    
    return rankings.stream()
        .map(ranking -> {
            Product product = productMap.get(productIdExtractor.apply(ranking));
            if (product == null) {
                log.warn("[{}] Product not found - productId: {}", logPrefix, productIdExtractor.apply(ranking));
                return null;
            }
            Brand brand = brandMap.get(product.getBrandId());
            String brandName = brand != null ? brand.getName() : "Unknown";
            
            return new RankingItemInfo(
                rankPositionExtractor.apply(ranking),
                product.getId(),
                product.getName(),
                brandName,
                product.getPrice(),
                product.getLikeCount(),
                scoreExtractor.apply(ranking)
            );
        })
        .filter(Objects::nonNull)
        .toList();
}
136-136: 메서드 참조 사용 권장

filter(item -> item != null) 대신 filter(Objects::nonNull)을 사용하면 더 간결합니다.
🔎 제안된 수정
+import java.util.Objects;
 ...
             })
-            .filter(item -> item != null)
+            .filter(Objects::nonNull)
             .toList();
apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingFacade.java (1)
118-143: parseAndValidateDate와 validateAndNormalizeDate 메서드의 중복 로직

두 메서드가 유사한 날짜 파싱/검증 로직을 수행합니다. validateAndNormalizeDate가 더 이상 사용되지 않는다면 제거를 고려해 주세요. 사용된다면 parseAndValidateDate를 활용하도록 리팩토링할 수 있습니다.
#!/bin/bash
# validateAndNormalizeDate 메서드 사용 여부 확인
rg -n "validateAndNormalizeDate" --type java
apps/commerce-api/src/main/java/com/loopers/application/batch/MonthlyRankingJobConfig.java (1)
44-201: WeeklyRankingJobConfig와 상당한 코드 중복이 있습니다

MonthlyRankingJobConfig와 WeeklyRankingJobConfig는 reader 설정, processor 생성, listener 로직 등 대부분의 코드가 동일합니다. 현재는 두 클래스만 있어 관리 가능하지만, 향후 유지보수성을 위해 공통 로직 추출을 고려해 볼 수 있습니다.
🔎 공통 로직 추출 예시
// 공통 추상 클래스 또는 헬퍼 클래스 추출 예시
public abstract class AbstractRankingJobConfig {
    
    protected JdbcPagingItemReader<ProductMetricsDto> createReader(
            DataSource dataSource, String readerName) {
        // 공통 reader 설정 로직
    }
    
    protected RowMapper<ProductMetricsDto> productMetricsRowMapper() {
        // 공통 RowMapper
    }
    
    protected List<T> processAndRankItems(
            InMemoryRankingCollector collector, int topN) {
        // 공통 정렬 및 TOP N 선택 로직
    }
}
apps/commerce-api/src/test/resources/db/init-ranking-tables.sql (2)
2-16: 동일 주간에 중복 순위 방지를 위한 유니크 제약 조건 추가 권장

현재 스키마에서는 동일한 week_start_date에 같은 rank_position이 여러 번 삽입될 수 있습니다. 배치 job의 동시 실행이나 재실행 시 데이터 무결성 문제가 발생할 수 있습니다.
🔎 유니크 제약 조건 추가 예시
 CREATE TABLE IF NOT EXISTS mv_product_rank_weekly (
     id BIGINT AUTO_INCREMENT,
     rank_position INT NOT NULL,
     product_id BIGINT NOT NULL,
     total_score DOUBLE NOT NULL,
     week_start_date DATE NOT NULL COMMENT '주간 시작일 (월요일)',
     week_end_date DATE NOT NULL COMMENT '주간 종료일 (일요일)',
     created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
     updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,

     PRIMARY KEY (id),
+    UNIQUE KEY uk_week_rank (week_start_date, rank_position),
     INDEX idx_week_rank (week_start_date, rank_position),
     INDEX idx_week_product (week_start_date, product_id),
     INDEX idx_product_week (product_id, week_start_date)
 ) COMMENT '주간 상품 랭킹 (TOP 100)';
19-34: 월간 테이블에도 동일한 유니크 제약 조건 추가 권장

mv_product_rank_monthly 테이블에도 (month_year, rank_position)에 대한 유니크 제약 조건이 없습니다.
🔎 유니크 제약 조건 추가 예시
 CREATE TABLE IF NOT EXISTS mv_product_rank_monthly (
     ...
     PRIMARY KEY (id),
+    UNIQUE KEY uk_month_rank (month_year, rank_position),
     INDEX idx_month_rank (month_year, rank_position),
     ...
 ) COMMENT '월간 상품 랭킹 (TOP 100)';

📜 Review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 53345ef and 0450d2a.

📒 Files selected for processing (30)

apps/commerce-api/build.gradle.kts
apps/commerce-api/src/main/java/com/loopers/application/batch/MonthlyRankingJobConfig.java
apps/commerce-api/src/main/java/com/loopers/application/batch/WeeklyRankingJobConfig.java
apps/commerce-api/src/main/java/com/loopers/application/batch/dto/ProductMetricsDto.java
apps/commerce-api/src/main/java/com/loopers/application/batch/dto/RankedProductDto.java
apps/commerce-api/src/main/java/com/loopers/application/batch/processor/RankingScoreProcessor.java
apps/commerce-api/src/main/java/com/loopers/application/batch/writer/InMemoryRankingCollector.java
apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingFacade.java
apps/commerce-api/src/main/java/com/loopers/domain/ranking/PeriodType.java
apps/commerce-api/src/main/java/com/loopers/domain/ranking/PeriodUtils.java
apps/commerce-api/src/main/java/com/loopers/domain/ranking/RankingService.java
apps/commerce-api/src/main/java/com/loopers/domain/ranking/monthly/MonthlyRanking.java
apps/commerce-api/src/main/java/com/loopers/domain/ranking/monthly/MonthlyRankingRepository.java
apps/commerce-api/src/main/java/com/loopers/domain/ranking/weekly/WeeklyRanking.java
apps/commerce-api/src/main/java/com/loopers/domain/ranking/weekly/WeeklyRankingRepository.java
apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/monthly/MonthlyRankingJpaRepository.java
apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/monthly/MonthlyRankingRepositoryImpl.java
apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/weekly/WeeklyRankingJpaRepository.java
apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/weekly/WeeklyRankingRepositoryImpl.java
apps/commerce-api/src/main/java/com/loopers/interfaces/api/batch/BatchJobController.java
apps/commerce-api/src/main/java/com/loopers/interfaces/api/ranking/RankingV1Controller.java
apps/commerce-api/src/main/resources/application.yml
apps/commerce-api/src/test/java/com/loopers/application/batch/MonthlyRankingJobTest.java
apps/commerce-api/src/test/java/com/loopers/application/batch/WeeklyRankingJobTest.java
apps/commerce-api/src/test/resources/db/init-ranking-tables.sql
docker/mysql/init/03-ranking-materialized-views.sql
modules/batch/build.gradle.kts
modules/batch/src/main/java/com/loopers/config/batch/BatchConfig.java
modules/batch/src/main/resources/batch.yml
settings.gradle.kts

🧰 Additional context used

🧠 Learnings (4)

📚 Learning: 2025-11-27T09:09:24.961Z

Learnt from: sky980221
Repo: Loopers-dev-lab/loopers-spring-java-template PR: 121
File: apps/commerce-api/src/main/java/com/loopers/infrastructure/product/ProductJpaRepository.java:22-24
Timestamp: 2025-11-27T09:09:24.961Z
Learning: Product 엔티티 (apps/commerce-api/src/main/java/com/loopers/domain/product/Product.java)는 유즈케이스별로 의도적으로 다른 락 전략을 사용한다: 좋아요 기능에는 비관적 락(findByIdForUpdate)을, 재고 차감에는 낙관적 락(Version + 재시도)을 사용한다.

Applied to files:

apps/commerce-api/src/main/java/com/loopers/application/batch/dto/RankedProductDto.java
apps/commerce-api/src/main/java/com/loopers/application/batch/dto/ProductMetricsDto.java

📚 Learning: 2025-11-21T03:38:07.494Z

Learnt from: minor7295
Repo: Loopers-dev-lab/loopers-spring-java-template PR: 99
File: apps/commerce-api/src/main/resources/application.yml:26-30
Timestamp: 2025-11-21T03:38:07.494Z
Learning: The batch job implementation for likeCount synchronization in apps/commerce-api is temporary and intended for development environment only. It will be replaced with Event-Driven Architecture (EDA) before production deployment, so production-level configuration concerns (like profile-based initialize-schema settings) are not required.

Applied to files:

modules/batch/src/main/resources/batch.yml
apps/commerce-api/src/main/resources/application.yml
apps/commerce-api/src/main/java/com/loopers/application/batch/MonthlyRankingJobConfig.java
apps/commerce-api/src/main/java/com/loopers/application/batch/WeeklyRankingJobConfig.java
apps/commerce-api/src/main/java/com/loopers/interfaces/api/batch/BatchJobController.java

📚 Learning: 2025-11-09T10:41:39.297Z

Learnt from: ghojeong
Repo: Loopers-dev-lab/loopers-spring-kotlin-template PR: 25
File: apps/commerce-api/src/main/kotlin/com/loopers/domain/product/ProductRepository.kt:1-12
Timestamp: 2025-11-09T10:41:39.297Z
Learning: In this codebase, domain repository interfaces are allowed to use Spring Data's org.springframework.data.domain.Page and org.springframework.data.domain.Pageable types. This is an accepted architectural decision and should not be flagged as a DIP violation.

Applied to files:

apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/monthly/MonthlyRankingJpaRepository.java
apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/weekly/WeeklyRankingJpaRepository.java
apps/commerce-api/src/main/java/com/loopers/domain/ranking/weekly/WeeklyRankingRepository.java

📚 Learning: 2025-12-02T08:12:06.383Z

Learnt from: junoade
Repo: Loopers-dev-lab/loopers-spring-java-template PR: 0
File: :0-0
Timestamp: 2025-12-02T08:12:06.383Z
Learning: ProductQueryService에서 상품 목록 조회 시 Redis 캐시를 적용했으며, 캐시 키는 brandId, sortType, pageNumber, pageSize의 조합으로 구성되고 TTL은 5분으로 설정되어 있다.

Applied to files:

apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingFacade.java

🧬 Code graph analysis (9)

apps/commerce-api/src/main/java/com/loopers/application/batch/processor/RankingScoreProcessor.java (1)

apps/commerce-api/src/main/java/com/loopers/application/batch/writer/InMemoryRankingCollector.java (1)

Slf4j (17-42)

apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/monthly/MonthlyRankingRepositoryImpl.java (1)

apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/weekly/WeeklyRankingRepositoryImpl.java (1)

Repository (15-56)

apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/weekly/WeeklyRankingRepositoryImpl.java (1)

apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/monthly/MonthlyRankingRepositoryImpl.java (1)

Repository (14-55)

apps/commerce-api/src/test/java/com/loopers/application/batch/WeeklyRankingJobTest.java (1)

apps/commerce-api/src/test/java/com/loopers/application/batch/MonthlyRankingJobTest.java (1)

SpringBootTest (30-217)

apps/commerce-api/src/main/java/com/loopers/domain/ranking/RankingService.java (1)

apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingInfo.java (1)

RankingInfo (7-40)

apps/commerce-api/src/main/java/com/loopers/interfaces/api/batch/BatchJobController.java (1)

apps/pg-simulator/src/main/kotlin/com/loopers/interfaces/api/ApiControllerAdvice.kt (1)

log (22-119)

apps/commerce-api/src/main/java/com/loopers/domain/ranking/weekly/WeeklyRanking.java (1)

apps/commerce-api/src/main/java/com/loopers/domain/ranking/monthly/MonthlyRanking.java (1)

Entity (11-48)

apps/commerce-api/src/main/java/com/loopers/domain/ranking/monthly/MonthlyRanking.java (1)

apps/commerce-api/src/main/java/com/loopers/domain/ranking/weekly/WeeklyRanking.java (1)

Entity (11-44)

apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingFacade.java (1)

apps/commerce-api/src/main/java/com/loopers/domain/ranking/PeriodUtils.java (1)

PeriodUtils (8-75)

🔇 Additional comments (23)

modules/batch/src/main/resources/batch.yml (1)

1-6: LGTM! Spring Batch 설정이 적절합니다.

spring.batch.job.enabled=false로 자동 실행을 비활성화하고 수동 실행을 지원하는 것은 올바른 접근입니다.

initialize-schema: always 설정은 개발 환경에서는 적합하지만, 프로덕션 배포 시에는 never 또는 embedded로 변경하거나 프로파일별로 분리하는 것을 고려하세요. (기존 학습에 따르면 EDA로 전환 예정이므로 현재는 문제없습니다.)

settings.gradle.kts (1)

10-10: LGTM!

새로운 batch 모듈이 적절하게 Gradle 빌드에 포함되었습니다.

apps/commerce-api/src/main/resources/application.yml (1)

25-25: LGTM!

batch.yml 설정 파일이 올바르게 import되었습니다. 인프라 모듈 설정 다음, 지원 모듈 설정 전에 배치하여 일관성 있는 구조를 유지하고 있습니다.

modules/batch/src/main/java/com/loopers/config/batch/BatchConfig.java (1)

1-16: LGTM! Spring Boot 3.x 배치 설정 방식이 올바르게 문서화되어 있습니다.

@EnableBatchProcessing 대신 auto-configuration을 사용하는 Spring Boot 3.x 접근 방식에 대한 설명이 명확합니다.

현재 빈 클래스이지만, 향후 커스텀 배치 빈(예: JobRepository, PlatformTransactionManager 커스터마이징)을 추가할 수 있는 확장 지점으로 유지해도 좋습니다.

apps/commerce-api/src/main/java/com/loopers/domain/ranking/PeriodType.java (1)

1-7: LGTM!

기간 유형을 명확하게 정의한 심플한 enum입니다. DAILY가 포함되어 있어 향후 일간 랭킹 기능 확장에도 대비되어 있습니다.

apps/commerce-api/build.gradle.kts (1)

6-6: LGTM!

batch 모듈 의존성이 올바르게 추가되었습니다. 이를 통해 WeeklyRankingJobConfig, MonthlyRankingJobConfig 등 배치 관련 컴포넌트들이 Spring Batch를 사용할 수 있게 됩니다.

modules/batch/build.gradle.kts (1)

1-14: LGTM!

배치 모듈 빌드 설정이 적절합니다. java-library 플러그인 사용과 api 의존성 노출 방식이 올바릅니다.

apps/commerce-api/src/main/java/com/loopers/domain/ranking/weekly/WeeklyRanking.java (1)

11-34: 인덱스는 이미 DDL 파일에서 정의되어 있으므로 Java 엔티티에 추가할 필요가 없습니다.

apps/commerce-api/src/test/resources/db/init-ranking-tables.sql에 mv_product_rank_weekly 테이블이 다음과 같이 정의되어 있습니다:

INDEX idx_week_rank (week_start_date, rank_position) ✓

INDEX idx_week_product (week_start_date, product_id) ✓

INDEX idx_product_week (product_id, week_start_date) ✓

이 프로젝트는 DDL 마이그레이션 스크립트를 통해 인덱스를 관리하고 있으므로, Java 엔티티 클래스에 @Index 주석을 추가할 필요가 없습니다. 현재 상태가 올바릅니다.

Likely an incorrect or invalid review comment.

apps/commerce-api/src/main/java/com/loopers/interfaces/api/ranking/RankingV1Controller.java (1)

34-34: Spring의 enum 파라미터 자동 검증 확인됨

Spring Framework는 @RequestParam으로 선언된 enum 타입 파라미터에 잘못된 값이 입력될 때 자동으로 HTTP 400 Bad Request를 반환합니다. StringToEnumConverterFactory가 대소문자를 구분하는 Enum.valueOf()를 사용하므로, 유효하지 않은 값에 대해 ConversionFailedException이 발생하며 이는 자동으로 400 응답으로 처리됩니다. PeriodType enum에 대해서도 이 표준 동작이 적용되므로 추가 검증 로직은 필요하지 않습니다.

apps/commerce-api/src/main/java/com/loopers/domain/ranking/weekly/WeeklyRankingRepository.java (1)

6-15: LGTM! 깔끔한 도메인 레포지토리 인터페이스입니다.

Spring Data 의존성 없이 도메인 계층에서 필요한 메서드만 정의하여 클린 아키텍처를 잘 따르고 있습니다.

apps/commerce-api/src/main/java/com/loopers/domain/ranking/monthly/MonthlyRankingRepository.java (1)

5-14: LGTM! WeeklyRankingRepository와 일관된 구조입니다.

monthYear를 String 타입으로 사용하는 것이 "yyyy-MM" 포맷 저장 방식과 잘 맞습니다.

apps/commerce-api/src/main/java/com/loopers/application/batch/processor/RankingScoreProcessor.java (1)

27-43: LGTM! 점수 계산 로직이 잘 구현되었습니다.

Math.log1p를 사용한 로그 정규화로 고가 상품 편중을 방지하는 설계가 좋습니다. 가중치를 생성자 주입으로 받아 유연성을 확보했습니다.

apps/commerce-api/src/main/java/com/loopers/application/batch/writer/InMemoryRankingCollector.java (1)

20-27: Collections.synchronizedList 사용은 현재 구조에서 불필요합니다.

현재 Step 설정에서 taskExecutor가 구성되어 있지 않으므로, 이 Step은 단일 스레드로 실행됩니다. 따라서 동시성 문제는 발생하지 않으며, Collections.synchronizedList는 불필요한 오버헤드를 추가합니다.

단순한 ArrayList로 변경하거나, 향후 멀티스레드 처리가 필요해질 경우를 대비하여 명확한 의도를 반영한 컬렉션(예: ConcurrentHashMap 기반 또는 명시적 동기화)을 사용하는 것을 권장합니다.

apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/monthly/MonthlyRankingRepositoryImpl.java (1)

14-55: LGTM!

구현이 WeeklyRankingRepositoryImpl과 일관성 있게 작성되었습니다. QueryDSL을 사용한 조회 로직과 트랜잭션 처리가 적절합니다.

apps/commerce-api/src/test/java/com/loopers/application/batch/MonthlyRankingJobTest.java (1)

30-33: 테스트 구성 적절함

@SpringBootTest와 @ActiveProfiles("test") 조합으로 통합 테스트 환경이 잘 구성되어 있습니다. @Sql을 통한 테이블 초기화와 @BeforeEach에서의 데이터 정리로 테스트 격리가 보장됩니다.

apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/weekly/WeeklyRankingRepositoryImpl.java (1)

15-56: LGTM!

MonthlyRankingRepositoryImpl과 일관된 패턴으로 구현되어 있습니다. QueryDSL을 활용한 조회와 페이지네이션, 트랜잭션 처리가 적절합니다.

apps/commerce-api/src/main/java/com/loopers/domain/ranking/RankingService.java (1)

24-33: N+1 문제 방지를 위한 배치 로딩 구현 적절함

상품과 브랜드 정보를 한 번에 조회하여 N+1 문제를 방지하는 설계가 잘 되어 있습니다.

apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/weekly/WeeklyRankingJpaRepository.java (1)

16-18: JPQL LIMIT/OFFSET 구문은 현재 프로젝트에서 전적으로 지원됩니다

Spring Boot 3.4.4는 Hibernate 6.6.2.Final을 사용하며, Hibernate 6.0부터 JPQL에서 네이티브하게 LIMIT과 OFFSET 키워드를 지원합니다. 따라서 해당 쿼리는 유효하며, 이 메서드는 RankingService.java에서 실제로 사용 중입니다.

apps/commerce-api/src/main/java/com/loopers/application/batch/WeeklyRankingJobConfig.java (3)

58-65: 가중치 합이 1.0이 아닙니다 - 의도된 설계인지 확인 필요

현재 설정된 가중치의 합은 0.1 + 0.2 + 0.6 = 0.9입니다. 이것이 의도된 설계인지 확인해 주세요. 만약 정규화된 점수가 필요하다면 가중치 합을 1.0으로 맞추는 것이 일반적입니다.

75-86: RankingScoreProcessor 인스턴스 생성 시 @Value 필드 주입 시점 확인 필요

weeklyRankingStep() 메서드 내에서 new RankingScoreProcessor(viewWeight, likeWeight, orderWeight)를 호출할 때, @Value 어노테이션으로 주입되는 필드들이 이미 초기화되어 있어야 합니다. Spring의 빈 라이프사이클상 @Bean 메서드 호출 시점에는 필드 주입이 완료되어 있으므로 정상 동작하지만, weeklyRankingStep()이 다른 빈에서 직접 호출되는 경우 문제가 될 수 있습니다.

91-114: Reader 설정은 적절하지만, 빈 스코프 고려 필요

JdbcPagingItemReader는 stateful하므로 기본 singleton 스코프에서 동시 실행 시 문제가 발생할 수 있습니다. 현재 private 메서드로 매번 새 인스턴스를 생성하므로 괜찮지만, 향후 @Bean으로 변경 시 @StepScope를 적용해야 합니다.

apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingFacade.java (1)

42-56: 기간 타입별 라우팅 로직이 깔끔하게 구현되었습니다.

switch 표현식을 사용한 period type 라우팅이 명확하고, 각 기간 타입에 맞는 서비스 메서드를 호출하는 구조가 잘 설계되었습니다.

apps/commerce-api/src/test/resources/db/init-ranking-tables.sql (1)

37-46: 테이블 구조가 적절합니다.

product_metrics 테이블은 배치 job의 소스 데이터로서 적합한 스키마를 가지고 있습니다. product_id를 PK로 사용하고 메트릭 컬럼들의 기본값이 0으로 설정된 것이 좋습니다.

apps/commerce-api/src/main/java/com/loopers/application/batch/dto/ProductMetricsDto.java

apps/commerce-api/src/main/java/com/loopers/application/batch/dto/RankedProductDto.java

...ommerce-api/src/main/java/com/loopers/application/batch/processor/RankingScoreProcessor.java

coderabbitai · 2026-01-02T08:32:12Z

apps/commerce-api/src/main/java/com/loopers/application/batch/WeeklyRankingJobConfig.java

+            public ExitStatus afterStep(StepExecution stepExecution) {
+                String targetDateParam = stepExecution.getJobParameters()
+                    .getString("targetDate");
+
+                if (targetDateParam == null) {
+                    log.error("[WeeklyRanking] targetDate 파라미터가 없습니다");
+                    return ExitStatus.FAILED;
+                }
+
+                LocalDate targetDate = LocalDate.parse(targetDateParam);
+                LocalDate weekStartDate = PeriodUtils.getWeekStartDate(targetDate);
+                LocalDate weekEndDate = PeriodUtils.getWeekEndDate(targetDate);
+
+                log.info("[WeeklyRanking] Step 완료 - 주간: {} ~ {}", weekStartDate, weekEndDate);
+
+                // 1. 기존 주간 랭킹 데이터 삭제
+                weeklyRankingRepository.deleteByWeekStartDate(weekStartDate);
+                log.info("[WeeklyRanking] 기존 주간 랭킹 데이터 삭제 완료: {}", weekStartDate);


⚠️ Potential issue | 🟠 Major

동시 실행 시 데이터 손실 위험 - 삭제 후 저장 사이의 경합 조건

deleteByWeekStartDate() 호출 후 saveAll() 호출 전에 다른 job 인스턴스가 같은 주간 데이터를 삭제하면 데이터가 손실될 수 있습니다. RunIdIncrementer를 사용하므로 동일 파라미터로 재실행이 가능합니다.

동시 실행 방지를 위한 방안을 고려해 주세요:

DB 레벨의 유니크 제약 조건 추가 (week_start_date, rank_position)

또는 JobParametersIncrementer 대신 중복 실행 방지 로직 추가

coderabbitai · 2026-01-02T08:32:12Z

apps/commerce-api/src/main/java/com/loopers/application/batch/WeeklyRankingJobConfig.java

+                // 3. 정렬 (점수 내림차순)
+                Collections.sort(collectedItems);


⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

find . -type f -name "*.java" | xargs grep -l "InMemoryRankingCollector"

Repository: Loopers-dev-lab/loopers-spring-java-template

Length of output: 373

🏁 Script executed:

cat -n ./apps/commerce-api/src/main/java/com/loopers/application/batch/writer/InMemoryRankingCollector.java

Repository: Loopers-dev-lab/loopers-spring-java-template

Length of output: 1472

🏁 Script executed:

head -n 180 ./apps/commerce-api/src/main/java/com/loopers/application/batch/WeeklyRankingJobConfig.java | tail -n 20

Repository: Loopers-dev-lab/loopers-spring-java-template

Length of output: 820

Collections.sort()는 InMemoryRankingCollector의 내부 리스트를 직접 수정합니다

InMemoryRankingCollector의 @Getter 어노테이션은 내부 collectedItems 리스트에 대한 직접 참조를 반환합니다. Collections.sort()가 이 참조를 수정하므로 collector의 내부 상태가 변경됩니다. getCollectedItems()에서 방어적 복사본을 반환하도록 수정하거나, 호출 시점에서 new ArrayList<>(collector.getCollectedItems())로 복사본을 생성하세요.

🤖 Prompt for AI Agents

In apps/commerce-api/src/main/java/com/loopers/application/batch/WeeklyRankingJobConfig.java around lines 171-172, Collections.sort(collectedItems) mutates the internal list returned by InMemoryRankingCollector#getCollectedItems because the getter exposes the internal reference; fix by avoiding in-place modification — either change InMemoryRankingCollector#getCollectedItems to return a defensive copy (e.g., new ArrayList<>(collectedItems) or Collections.unmodifiableList(copy)) or, at this call site, sort a copy: create a new ArrayList<>(collector.getCollectedItems()) and call Collections.sort on that copy so the collector's internal state is not mutated.

coderabbitai · 2026-01-02T08:32:12Z

...pi/src/main/java/com/loopers/infrastructure/ranking/monthly/MonthlyRankingJpaRepository.java

+    @Modifying
+    @Transactional
+    void deleteByMonthYear(String monthYear);


⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

rg -n "deleteByMonthYear|deleteByWeekStartDate" --type=java -B5 -A5

Repository: Loopers-dev-lab/loopers-spring-java-template

Length of output: 10779

🏁 Script executed:

cat -n apps/commerce-api/src/main/java/com/loopers/application/batch/MonthlyRankingJobConfig.java | sed -n '140,180p'

Repository: Loopers-dev-lab/loopers-spring-java-template

Length of output: 2044

🏁 Script executed:

cat -n apps/commerce-api/src/main/java/com/loopers/application/batch/MonthlyRankingJobConfig.java | sed -n '80,140p'

Repository: Loopers-dev-lab/loopers-spring-java-template

Length of output: 2812

🏁 Script executed:

cat -n apps/commerce-api/src/main/java/com/loopers/application/batch/MonthlyRankingJobConfig.java | sed -n '1,85p'

Repository: Loopers-dev-lab/loopers-spring-java-template

Length of output: 4033

🏁 Script executed:

rg -n "\.deleteByMonthYear\(" --type=java -B2 -A2

Repository: Loopers-dev-lab/loopers-spring-java-template

Length of output: 767

🏁 Script executed:

cat -n apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/monthly/MonthlyRankingJpaRepository.java

Repository: Loopers-dev-lab/loopers-spring-java-template

Length of output: 1124

리포지토리 메서드에서 @Transactional 제거 권장

@Transactional이 인터페이스와 구현체 양쪽에 중복으로 선언되어 있습니다. StepExecutionListener.afterStep()에서 호출되는 메서드이므로, 트랜잭션은 서비스 계층이나 배치 설정 레벨에서 관리하는 것이 더 적절합니다. 리포지토리 메서드의 @Transactional은 제거하고, 필요시 호출 계층에서 관리하세요.

🤖 Prompt for AI Agents

In apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/monthly/MonthlyRankingJpaRepository.java around lines 19-21, remove the @Transactional annotation from the repository method declaration (keep @Modifying) so the repository does not declare its own transaction; let the service layer or the batch StepExecutionListener manage the transaction. If there is an implementation or another interface duplicating @Transactional, remove the duplicate there as well and ensure callers (service or batch config) wrap the deleteByMonthYear(String monthYear) call in an appropriate @Transactional boundary.

coderabbitai · 2026-01-02T08:32:12Z

apps/commerce-api/src/main/java/com/loopers/interfaces/api/batch/BatchJobController.java

+@RestController
+@RequestMapping("/api/v1/admin/batch")
+@RequiredArgsConstructor
+@Slf4j
+public class BatchJobController {


⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash # Search for the BatchJobController file find . -type f -name "BatchJobController.java" | head -5

Repository: Loopers-dev-lab/loopers-spring-java-template

Length of output: 178

🏁 Script executed:

#!/bin/bash # Search for Spring Security configuration files find . -type f -name "*Security*.java" -o -name "*Config*.java" | grep -i security | head -20

Repository: Loopers-dev-lab/loopers-spring-java-template

Length of output: 261

🏁 Script executed:

#!/bin/bash # Look for WebSecurityConfigurerAdapter or SecurityFilterChain patterns rg -l "SecurityFilterChain|WebSecurityConfigurerAdapter|@EnableWebSecurity" --type=java | head -10

Repository: Loopers-dev-lab/loopers-spring-java-template

Length of output: 158

🏁 Script executed:

#!/bin/bash # Search for admin path security configurations rg -n -C5 "admin|ADMIN" --type=java -g '*Security*' -g '*Config*' | head -50

Repository: Loopers-dev-lab/loopers-spring-java-template

Length of output: 70

🏁 Script executed:

#!/bin/bash # Read SecurityConfig.java to see admin path security configuration cat -n ./apps/commerce-api/src/main/java/com/loopers/config/SecurityConfig.java

Repository: Loopers-dev-lab/loopers-spring-java-template

Length of output: 1348

🏁 Script executed:

#!/bin/bash # Also read the full BatchJobController.java to check for any security annotations cat -n ./apps/commerce-api/src/main/java/com/loopers/interfaces/api/batch/BatchJobController.java

Repository: Loopers-dev-lab/loopers-spring-java-template

Length of output: 3329

/admin/** 엔드포인트에 인증 설정 필요

현재 SecurityConfig에서 anyRequest().permitAll()로 모든 요청을 허가하고 있어, /api/v1/admin/batch 엔드포인트가 인증 없이 공개되어 있습니다. 관리자 기능이므로 적절한 인증/인가 설정을 추가해야 합니다.

SecurityConfig의 authorizeHttpRequests 메서드를 수정하여 /api/v1/admin/** 경로에 authenticated() 또는 특정 권한 검증을 추가하세요.

🤖 Prompt for AI Agents

In apps/commerce-api/src/main/java/com/loopers/interfaces/api/batch/BatchJobController.java around lines 14 to 18, the controller is mapped to /api/v1/admin/batch and is currently exposed because SecurityConfig uses anyRequest().permitAll(); update SecurityConfig.authorizeHttpRequests() to require authentication for the admin path (e.g., add an antMatcher or requestMatchers for "/api/v1/admin/**" with .authenticated() or .hasRole("ADMIN") before the anyRequest rule), ensure order of matchers places the admin rule above the permissive catch-all, and keep CSRF/session settings consistent with API auth.

sylee6529 added 8 commits January 2, 2026 14:41

feat: Spring Batch 모듈 설정 및 Auto-configuration 적용

ab7d77b

Spring Boot 3.x Auto-configuration 사용을 위해 @EnableBatchProcessing 제거 Batch 모듈을 별도 모듈로 분리하여 재사용성 향상

feat: 랭킹 도메인 모델 및 Period 유틸리티 추가

79a0f2b

주간/월간 랭킹을 위한 Entity 및 Repository 인터페이스 추가 기간 타입(DAILY/WEEKLY/MONTHLY) 및 날짜 계산 유틸리티 구현

feat: 랭킹 Repository 구현 및 Materialized View DDL 추가

bf82a12

QueryDSL 기반 Repository 구현으로 N+1 문제 해결 주간/월간 TOP 100 랭킹 저장을 위한 MV 테이블 DDL 추가 트랜잭션 처리 및 QueryDSL delete 쿼리 최적화

feat: 랭킹 Service 기간별 조회 지원 추가

42f0dae

RankingService: 주간/월간 랭킹 조회 및 N+1 해결 RankingFacade: PeriodType에 따라 DAILY/WEEKLY/MONTHLY 분기 처리 배치 조회로 상품 및 브랜드 정보 효율적 조회

feat: Batch Job 실행 API 및 Ranking API period 파라미터 추가

ea663e9

BatchJobController: 주간/월간 랭킹 집계 Job 수동 실행 API RankingV1Controller: period 파라미터로 일간/주간/월간 선택 지원 batch.yml 설정 import 추가

sylee6529 self-assigned this Jan 2, 2026

coderabbitai bot reviewed Jan 2, 2026

View reviewed changes

sylee6529 added 2 commits January 2, 2026 22:20

fix: Batch DTO의 boxed Long을 primitive long으로 변경하여 NPE 방지

b6dbc3d

feat: 랭킹 테이블에 유니크 제약 조건 추가하여 동시 실행 시 데이터 손실 방지

b10a63d

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Round10 #241

Round10 #241

Uh oh!

sylee6529 commented Jan 2, 2026 •

edited

Loading

Uh oh!

coderabbitai bot commented Jan 2, 2026 •

edited

Loading

Review skipped

Uh oh!

coderabbitai bot left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

coderabbitai bot Jan 2, 2026

Uh oh!

coderabbitai bot Jan 2, 2026

Uh oh!

coderabbitai bot Jan 2, 2026

Uh oh!

coderabbitai bot Jan 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

		// 3. 정렬 (점수 내림차순)
		Collections.sort(collectedItems);

Round10 #241

Are you sure you want to change the base?

Round10 #241

Uh oh!

Conversation

sylee6529 commented Jan 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📌 Summary

💬 Review Points

1.QueryDSL 벌크 DELETE vs JPA deleteBy 선택

2.StepExecutionListener에서 DELETE + SAVE 트랜잭션 분리 문제

3. 랭킹데이터를 쌓을 때, 모든 데이터에 대한 랭킹을 쌓지는 않을 것 같은데, Top-100이면 100개만 저장하는 식으로 구현하시나요?

✅ Checklist

🧱 Spring Batch

🧩 Ranking API

Summary by CodeRabbit

출시 노트

Uh oh!

coderabbitai bot commented Jan 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review skipped

개요

변경 사항

시퀀스 다이어그램

주간/월간 랭킹 배치 작업 흐름

API 랭킹 조회 흐름 (주간/월간)

예상 코드 리뷰 노력

관련 가능성 있는 PR

제안된 레이블

Pre-merge checks and finishing touches

Uh oh!

coderabbitai bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

coderabbitai bot Jan 2, 2026

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Jan 2, 2026

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Jan 2, 2026

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Jan 2, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

sylee6529 commented Jan 2, 2026 •

edited

Loading

coderabbitai bot commented Jan 2, 2026 •

edited

Loading