[volume-10] Collect, Stack, Zip

[Kimjipang]

📌 Summary

Spring Batch

• 주간/월간 랭킹 집계 batch 프로그램 구현(파라미터 기반 실행 가능한 형태)
• chunk 기반 처리
  • reader
  • processor
  • writer
• 집계 결과를 저장할 주간/월간 Materialized View 설계

랭킹 API

• 일간/주간/월간 랭킹 API 제공

💬 Review Points

Q1).

회사에서 1년에 2번 약물 데이터(.asc 확장자 파일)를 어느 웹사이트에서 다운로드 받아 테이블에 저장해주는 작업을 spring batch로 구현해둔 상태입니다.

현재 잠시 업무가 홀딩된 상태이긴 하지만 추후에 해당 파일을 웹사이트에서 다운로드 받아 테이블에 데이터를 저장시키고 S3에 파일들을 업로드 해야 하는데요!

이를 자동화한다면 어떻게 할 수 있을까요? 찾아보니 AWS Lambda 사용하는 방법이 있기는 하던뎁 어떤 방법이 좋을까요?!

Q2).

주간/월간 랭킹 집계 프로세스가 다음과 같은데 알맞은 방법일까요?

product_metrics 테이블에 집계를 할 때 집계날짜(metric_date)를 같이 저장하고 있습니다. 그래서 (product_id, metric_date) 가 고유한 값인데요.

Reader

• product_metrics 테이블에서 productId 별로 7일 간의 row를 조회할 때 view_count, like_count, sales_volume를 sum()해서 read

Processor

• read한 데이터들을 각각이 가진 가중치에 따라 score를 계산

Writer

• 각 조회용 테이블(mv)에 적재

Q3).

일간/주간/월간 랭킹 정보를 반환해주는 API에 대한 질문입니다.

요구 사항이 엔드 포인트를 하나로 통일하고 각각을 구분할 수 있는 무엇인가로 일간/주간/월간 랭킹 데이터를 반환해야 하는 것으로 이해하고 그렇게 진행을 하였습니다.

엔드포인트가 동일하다보니 응답 본문을 맞춰주어야 했고 각각을 구분하고자 period를 requestParam으로 넣었습니다.

그리고 Facade에서 period가 어떤 값인지에 따라 분기 처리해서 각각의 서비스 로직을 수행하도록 했는데요.

Facade에서 값에 따라 분기하여 다른 서비스 로직을 호출하는 이 형태가 올바른 형태인가요?

Q4). 아키텍처 관련 질문입니다.

새로운 클래스를 정의할 때마다 이것이 어느 곳에 위치해야 되는지가 어려웠습니다.

기존에 제공되었던 템플릿에 존재하는 유형의 클래스들이라면 그대로 따라했지만 그렇지 않은 경우(kafka publisher, listener, outbox 등등)에는 판단이 잘 안되더라구요 !

아키텍처에 대한 이해도를 높이면 해결이 될까 싶어서 루퍼스 이후에 아키텍처에 대해서 공부해보려고 합니다. 이 공부가 도움이 될 공부인지와 도움이 된다면 어떻게 공부하면 좋을지 궁금합니다. (ex. 서적 추천)

Q5). 루퍼스 이후 방향성에 대한 질문

🧑‍💻 첫 번째 질문

아쉬움이 많이 남지만 동시에 많이 성장했다고 단언할 수 있는 시간이었습니다. 궁금한 게 생기면 이것 저것 확인받고 싶고 찾아보고 하는 편이라 과제 통과를 많이 못한 게 특히 아쉽습니다.

평소 gpt로 이론적인 학습을 많이 하는 편인데요.

아무래도 gpt가 거짓을 말하는 경우가 분명 있다보니 해당 방법이 좋은 것은 아닐까 하는 생각도 듭니다. 멘토님은 어떻게 공부하시나요?

🧑‍💻 두 번째 질문

이후에 루퍼스 발제 자료를 참고하며 다시 1주차부터 밟아보며 못했던 것과 궁금했던 것에 대해 깊이 학습해보고자 합니다.

하면서 도움이 될 만한 서적이나 방법에 무엇이 있을까요?

🧑‍💻 세 번째 질문

멘토님이 생각하는 저는 어떤 사람인가요? (태도, 실력 등을 장단점으로 가감없이 솔직하게 말씀 부탁드리겠습니다. ㅎㅎ.. 매운맛도 가능합니다!)

아직은 모르겠다 싶으시다면 편히 말씀 주셔도 됩니다.

🧑‍💻 마무리..

10주간 정말 감사드립니다 ㅎㅎ 항상 유쾌하게 멘토링 받았었네요.

2025년도 고생 많으셨구 다가온 새해에는 더욱 많은 행복을 찾아가시길 진심으로 바라겠습니다 !

✅ Checklist

🧱 Spring Batch

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

🧩 Ranking API

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

📎 References

Summary by CodeRabbit

릴리스 노트

• 새로운 기능

  • 일일, 주간, 월간 상품 순위 조회 기능 추가
  • 상품 순위 API 개선 (날짜 및 기간 선택 파라미터 추가)

• 개선 사항

  • 순위 데이터 배치 처리 최적화

• 제거됨

  • 데모 작업 및 관련 리스너 제거

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

[coderabbitai]

Walkthrough

일일, 주간, 월간 상품 랭킹을 처리하는 새로운 서비스 계층을 도입하고, RankingFacade를 리팩토링하여 서비스 위임으로 변경했습니다. API 엔드포인트를 일반화하고, 배치 작업으로 주간/월간 랭킹 데이터를 처리하는 기능을 추가했습니다.

Changes

Cohort / File(s)	요약
랭킹 애플리케이션 서비스 DailyRankingService.java, WeeklyRankingService.java, MonthlyRankingService.java	Redis ZSET과 데이터베이스로부터 일일, 주간, 월간 상품 랭킹을 조회하는 새로운 서비스. 페이지네이션 정규화, 날짜 범위 계산, RankingV1Dto 매핑 수행
랭킹 도메인 모델 Period.java, WeeklyRankingMv.java, MonthlyRankingMv.java	랭킹 기간(DAILY, WEEKLY, MONTHLY) 열거형과 주간/월간 랭킹 데이터를 매핑하는 JPA 엔티티 추가
랭킹 저장소 인터페이스 WeeklyRankingRepository.java, MonthlyRankingRepository.java	주간/월간 랭킹 조회 및 개수 집계를 위한 도메인 저장소 계약 정의
저장소 구현 WeeklyRankingJpaRepository.java, WeeklyRankingRepositoryImpl.java, MonthlyRankingJpaRepository.java, MonthlyRankingRepositoryImpl.java	QueryDSL 기반 주간/월간 랭킹 조회 구현 및 Spring Data JPA 인터페이스
RankingFacade 및 DTO RankingFacade.java, RankingV1Dto.java	세 가지 기간별 서비스를 주입받아 위임하도록 리팩토링. ProductRankingPageResponse에 period, startDate, endDate 필드 추가
API 계층 RankingV1ApiSpec.java, RankingV1Controller.java	엔드포인트를 getProductRanking(date, period, page, size)로 변경. date와 period 요청 파라미터 추가
배치 설정 BatchConfig.java	주간/월간 상품 지표 집계를 위한 Spring Batch 작업 설정. 삭제 단계 및 집계 단계 포함
배치 DTO 및 처리 ProductMetricsAgg.java, ProductRankRow.java, ProductMetricProcessor.java	집계 지표를 담는 DTO와 가중 점수 계산 프로세서 추가
배치 읽기 및 쓰기 ProductMetricReader.java, ProductMetricWeeklyWriter.java, ProductMetricMonthlyWriter.java	JDBC 기반 지표 읽기 및 주간/월간 랭킹 테이블 쓰기 구현
데모 작업 제거 DemoJobConfig.java, DemoTasklet.java, ChunkListener.java, JobListener.java, StepMonitorListener.java	미사용 배치 데모 및 리스너 컴포넌트 제거

Sequence Diagram(s)

sequenceDiagram
    participant Client
    participant Controller as RankingV1Controller
    participant Facade as RankingFacade
    participant Service as DailyRankingService
    participant Redis as Redis ZSET
    participant DTO as Response DTO

    Client->>Controller: GET /rankings?date=20260101&period=DAILY&page=1&size=20
    Controller->>Facade: getProductRanking(date, DAILY, 1, 20)
    Facade->>Service: getDailyRanking(20260101, DAILY, 1, 20)
    Service->>Redis: reverseRangeWithScores(ranking:all:20260101, 0, 19)
    Redis-->>Service: List<ZSetOperations.TypedTuple>
    Service->>Service: 점수별 정렬 및 순위 계산
    Service->>DTO: ProductRankingPageResponse 생성
    DTO-->>Service: 페이지네이션 메타데이터 포함
    Service-->>Facade: ProductRankingPageResponse
    Facade-->>Controller: ProductRankingPageResponse
    Controller-->>Client: ApiResponse 반환

Loading

sequenceDiagram
    participant Batch as Batch Job
    participant Config as BatchConfig
    participant Reader as ProductMetricReader
    participant Processor as ProductMetricProcessor
    participant DB as Database
    participant Writer as ProductMetricWeeklyWriter
    participant Target as mv_product_rank_weekly

    Batch->>Config: weeklyProductRankingJob 실행
    Config->>Config: deleteWeeklyMvStep 실행
    Config->>DB: DELETE FROM mv_product_rank_weekly
    DB-->>Config: 삭제 완료
    
    Config->>Config: aggregateWeeklyRankStep 실행
    Config->>Reader: 주간 지표 읽기 (JdbcPagingItemReader)
    Reader->>DB: SELECT 집계 지표
    DB-->>Reader: ProductMetricsAgg 청크
    Reader-->>Processor: 청크 전달
    
    Processor->>Processor: 가중 점수 계산<br/>(view: 0.1, like: 0.3, sales: 0.6)
    Processor-->>Writer: ProductRankRow 변환
    
    Writer->>Writer: MapSqlParameterSource 배치 구성
    Writer->>Target: batchUpdate (INSERT)
    Target-->>Writer: 삽입 완료
    Writer-->>Batch: 배치 쓰기 완료

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Possibly related PRs

• [volume-9] Product Ranking with Redis  #219: 상품 랭킹 기능을 Daily/Weekly/Monthly 서비스로 확장하고 RankingFacade 및 DTO를 업데이트하는 메인 PR과 동일한 랭킹 API 및 로직을 수정
• [volume-9] Product Ranking with Redis #211: 새로운 Daily/Weekly/Monthly 랭킹 서비스가 "ranking:all:{date}" Redis ZSET을 읽고 페이지별 응답을 빌드하는 방식과, 이전 Redis 기반 RankingFacade 및 관련 랭킹 컴포넌트가 동일한 데이터 소스를 사용하므로 코드 수준에서 직접 연관
• [volume-9] Product Ranking with Redis  #227: RankingFacade 및 랭킹 API/DTO를 수정하여 상품 랭킹 조회 방식을 변경(Redis 기반 로직을 Daily/Weekly/Monthly 서비스 위임으로 교체)

Poem

🐰 산토끼 펄쩍펄쩍 뛰며
일주월 랭킹 새로 정렬,
Redis에서 DB로 춤을 춘다네.
배치로 묵은 데이터 씻고,
API는 더 우아하게! ✨
레이어마다 책임 나누니,
코드 정원 활짝 피었다.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.
Title check	❓ Inconclusive	PR 제목 '[volume-10] Collect, Stack, Zip'은 모호하고 일반적이어서 변경 사항의 핵심을 명확히 전달하지 못합니다.	Spring Batch 주간/월간 랭킹 집계 기능과 통합 랭킹 API 구현을 구체적으로 명시하는 제목으로 수정하세요. 예: '[volume-10] Implement weekly/monthly ranking batch and unified ranking API'

✅ Passed checks (1 passed)

Check name	Status	Explanation
Description check	✅ Passed	PR 설명은 요구 사항 템플릿의 주요 섹션(Summary, Review Points, Checklist)을 충실히 포함하고 있으며, 구현된 기능과 설계 결정사항이 명확하게 설명되어 있습니다.

✨ Finishing touches

• 📝 Generate docstrings

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

Actionable comments posted: 11

♻️ Duplicate comments (1)

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

21-89: MonthlyRankingService와 코드 구조 동일

이 메서드는 MonthlyRankingService의 getMonthlyTop100과 구조적으로 동일합니다. 앞서 MonthlyRankingService 리뷰(Lines 21-89)에서 언급했듯이, 공통 로직을 추상화하여 두 서비스 간 중복을 제거하는 것을 권장합니다.

Based on learnings, 이미 MonthlyRankingService에서 동일한 리팩토링 제안을 했으므로 여기서는 간단히 참조만 합니다.

🧹 Nitpick comments (14)

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

19-21: 서비스 계층과 중복된 검증 로직

safePage와 safeSize 검증이 WeeklyRankingService의 9-10번 라인에서도 동일하게 수행되고 있습니다. 리포지토리 계층에서의 방어적 검증은 유용하지만, 서비스에서 이미 정규화된 값을 받는다면 중복 처리입니다.

🔎 제안: 리포지토리는 이미 검증된 파라미터를 신뢰

     @Override
     public List<WeeklyRankingMv> getWeeklyTop100(String endDate, String startDate, int page, int size) {
-        int safePage = Math.max(page, 1);
-        int safeSize = Math.max(size, 1);
-
-        long offset = (long) (safePage - 1) * safeSize;
+        long offset = (long) (page - 1) * size;
 
         return queryFactory
                 .selectFrom(weeklyRankingMv)
                 .where(
                         weeklyRankingMv.startDate.eq(startDate)
                                 .and(weeklyRankingMv.endDate.eq(endDate)))
                 .orderBy(
                         weeklyRankingMv.score.desc(),
                         weeklyRankingMv.productId.asc()
                 )
                 .offset(offset)
-                .limit(safeSize)
+                .limit(size)
                 .fetch();
     }

apps/commerce-batch/src/main/java/com/loopers/batch/writer/ProductMetricMonthlyWriter.java (1)

49-50: 스트림 내부에서 반복적인 ZonedDateTime.now() 호출

각 아이템마다 ZonedDateTime.now()를 호출하면 대용량 배치에서 불필요한 오버헤드가 발생할 수 있습니다. 스트림 외부에서 한 번만 호출하는 것이 더 효율적입니다.

🔎 제안: 타임스탬프를 한 번만 생성

     @Override
     public void write(Chunk<? extends ProductRankRow> chunk) {
+        ZonedDateTime now = ZonedDateTime.now();
         MapSqlParameterSource[] batch = chunk.getItems().stream()
                 .map(item -> new MapSqlParameterSource()
                         .addValue("startDate", startDate)
                         .addValue("endDate", endDate)
                         .addValue("productId", item.productId())
                         .addValue("viewCountSum", item.viewCountSum())
                         .addValue("likeCountSum", item.likeCountSum())
                         .addValue("salesVolumeSum", item.salesVolumeSum())
                         .addValue("score", item.score())
-                        .addValue("createdAt", ZonedDateTime.now())
-                        .addValue("updatedAt", ZonedDateTime.now()))
+                        .addValue("createdAt", now)
+                        .addValue("updatedAt", now))
                 .toArray(MapSqlParameterSource[]::new);
 
         jdbcTemplate.batchUpdate(SQL, batch);
     }

apps/commerce-batch/src/main/java/com/loopers/batch/dto/ProductMetricsAgg.java (1)

3-8: productId 타입 일관성 검토

productId는 Long 래퍼 타입을 사용하지만 다른 필드들은 long 기본형을 사용합니다. ProductMetricReader(line 36-40)에서 rs.getLong("ref_product_id")로 매핑되며, SQL 결과가 NULL일 경우 0으로 반환될 수 있습니다. productId가 실제로 NULL일 수 있다면 Long이 적절하지만, 그렇지 않다면 일관성을 위해 long으로 통일하는 것을 권장합니다.

🔎 제안: NULL이 불가능하다면 기본형으로 통일

 public record ProductMetricsAgg(
-        Long productId,
+        long productId,
         long sumLike,
         long sumView,
         long sumSales
 ) {
 }

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

6-6: 메서드 이름 "Top100"이 page/size 파라미터와 모순됩니다

메서드 이름이 getWeeklyTop100이지만 page와 size 파라미터를 받아 100개 이상 또는 이하의 결과를 반환할 수 있습니다. 이는 사용자에게 혼란을 줄 수 있습니다.

예를 들어, getWeeklyTop100(date, lastWeek, 0, 50)을 호출하면 50개만 반환되고, getWeeklyTop100(date, lastWeek, 1, 100)은 101~200번째 결과를 반환하게 됩니다.

🔎 명확한 메서드 이름으로 변경 제안

-    List<WeeklyRankingMv> getWeeklyTop100(String date, String lastWeek, int page, int size);
+    List<WeeklyRankingMv> getWeeklyRankings(LocalDate endDate, LocalDate startDate, int page, int size);

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

21-27: date 파라미터에 대한 유효성 검증 및 기본값 설정 고려

date 파라미터가 필수값으로 설정되어 있으나 형식 검증이 없습니다. DailyRankingService, WeeklyRankingService, MonthlyRankingService에서 BASIC_ISO_DATE 형식(예: "20260102")을 기대하고 있어, 잘못된 형식의 날짜가 전달되면 DateTimeParseException이 발생할 수 있습니다.

또한 size와 page 파라미터에 기본값이 없어 클라이언트가 생략하면 요청이 실패합니다.

🔎 기본값 추가 및 날짜 형식 검증 제안

     public ApiResponse<RankingV1Dto.ProductRankingPageResponse> getProductRanking(
-            @RequestParam String date,
+            @RequestParam(defaultValue = "#{T(java.time.LocalDate).now().format(T(java.time.format.DateTimeFormatter).BASIC_ISO_DATE)}") String date,
             @RequestParam(defaultValue = "DAILY") Period period,
-            @RequestParam int size,
-            @RequestParam int page
+            @RequestParam(defaultValue = "20") int size,
+            @RequestParam(defaultValue = "1") int page
     ) {

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

18-18: Period 파라미터 사용되지 않음

period 파라미터가 메서드에 전달되지만, 응답에서는 항상 Period.DAILY로 하드코딩되어 있습니다 (라인 29, 37, 60). 파라미터를 제거하거나 전달된 값을 사용하는 것이 일관성 있습니다.

apps/commerce-batch/src/main/java/com/loopers/batch/writer/ProductMetricWeeklyWriter.java (1)

49-50: 배치 내 타임스탬프 일관성 고려

ZonedDateTime.now()가 각 아이템 매핑 시 호출되어 배치 내 레코드 간 미세한 시간 차이가 발생할 수 있습니다. 일관된 타임스탬프가 필요하다면 배치 시작 시점의 시간을 캡처하여 사용하는 것이 좋습니다.

🔎 일관된 타임스탬프 사용 예시

     @Override
     public void write(Chunk<? extends ProductRankRow> chunk) {
+        ZonedDateTime now = ZonedDateTime.now();
         MapSqlParameterSource[] batch = chunk.getItems().stream()
                 .map(item -> new MapSqlParameterSource()
                         .addValue("startDate", startDate)
                         .addValue("endDate", endDate)
                         .addValue("productId", item.productId())
                         .addValue("viewCountSum", item.viewCountSum())
                         .addValue("likeCountSum", item.likeCountSum())
                         .addValue("salesVolumeSum", item.salesVolumeSum())
                         .addValue("score", item.score())
-                        .addValue("createdAt", ZonedDateTime.now())
-                        .addValue("updatedAt", ZonedDateTime.now()))
+                        .addValue("createdAt", now)
+                        .addValue("updatedAt", now))
                 .toArray(MapSqlParameterSource[]::new);

         jdbcTemplate.batchUpdate(SQL, batch);
     }

apps/commerce-batch/src/main/java/com/loopers/batch/reader/ProductMetricReader.java (1)

20-24: Exception 대신 구체적인 예외 타입 사용 권장

throws Exception은 너무 광범위합니다. provider.getObject()에서 발생할 수 있는 구체적인 예외 타입을 명시하면 호출자가 더 명확하게 예외를 처리할 수 있습니다.

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

18-19: 파라미터 순서 혼란 및 메서드명 오해 소지

두 가지 개선 사항이 있습니다:

1. 파라미터 순서: getMonthlyTop100(String endDate, String startDate, ...) 순서가 직관적이지 않습니다. 일반적으로 startDate가 먼저 오는 것이 자연스럽습니다. WeeklyRankingRepositoryImpl도 동일한 패턴을 사용하고 있어 일관성은 있지만, 호출부에서 실수하기 쉽습니다.

2. 메서드명: getMonthlyTop100이라는 이름이지만 실제로는 size 파라미터에 따라 개수가 결정됩니다. getMonthlyRankings 또는 getMonthlyRankingPage가 더 정확할 수 있습니다.

🔎 파라미터 순서 수정 제안

     @Override
-    public List<MonthlyRankingMv> getMonthlyTop100(String endDate, String startDate, int page, int size) {
+    public List<MonthlyRankingMv> getMonthlyTop100(String startDate, String endDate, int page, int size) {

참고: 이 변경은 인터페이스 MonthlyRankingRepository와 호출부 MonthlyRankingService에도 적용되어야 합니다.

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

21-89: WeeklyRankingService와의 코드 중복 제거 권장

이 메서드는 WeeklyRankingService의 getWeeklyTop100과 구조가 거의 동일합니다(페이지네이션 로직, 빈 응답 처리, 랭킹 매핑 등). 공통 로직을 추상화하여 중복을 제거하면 유지보수성이 향상됩니다.

💡 리팩토링 방향 제안

공통 페이지네이션 및 랭킹 매핑 로직을 추출할 수 있습니다:

// 공통 유틸리티 또는 추상 베이스 클래스에 추가
protected <T extends RankingMv> RankingV1Dto.ProductRankingPageResponse 
    buildRankingResponse(
        String date, 
        Period period,
        String startDate, 
        String endDate,
        int page, 
        int size,
        long totalElements,
        List<T> rows,
        Function<T, Long> productIdExtractor,
        Function<T, BigDecimal> scoreExtractor
    ) {
    // 공통 로직 구현
}

이렇게 하면 Weekly/Monthly 서비스에서 중복된 페이지네이션 및 DTO 매핑 코드를 제거할 수 있습니다.

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

19-23: 날짜 필드를 String으로 저장

startDate와 endDate가 String 타입입니다. BASIC_ISO_DATE 포맷(yyyyMMdd)을 사용하는 것으로 보이지만, 타입 안정성과 DB 수준의 날짜 연산을 위해 LocalDate 또는 DB의 DATE 타입 사용을 고려할 수 있습니다.

현재 구조의 장점: String 기반 날짜는 정렬과 비교가 간단하고 포맷 제어가 명확합니다.

대안 고려사항: 만약 향후 날짜 범위 쿼리나 날짜 연산이 복잡해진다면, LocalDate로 변경하는 것이 더 안전할 수 있습니다. 하지만 현재 사용 패턴(단순 equality 비교)에서는 String도 충분히 적합합니다.

apps/commerce-batch/src/main/java/com/loopers/batch/config/BatchConfig.java (3)

57-74: 삭제 작업에 대한 로깅 추가를 권장합니다.

DELETE 작업의 영향을 받은 행 수를 로깅하면 운영 시 문제 추적에 도움이 됩니다. jdbcTemplate.update()는 영향받은 행 수를 반환합니다.

🔎 로깅 추가 제안

     @Bean
     @StepScope
     public Tasklet deleteWeeklyMvTasklet(
             @Value("#{jobParameters['weeklyStartDate']}") String startDate,
             @Value("#{jobParameters['weeklyEndDate']}") String endDate
     ) {
         return (contribution, chunkContext) -> {
             String sql = """
             DELETE FROM mv_product_rank_weekly
             WHERE start_date = :weeklyStartDate AND end_date = :weeklyEndDate
             """;
-            jdbcTemplate.update(sql, Map.of(
+            int deletedCount = jdbcTemplate.update(sql, Map.of(
                     "weeklyStartDate", startDate,
                     "weeklyEndDate", endDate
             ));
+            // log.info("Deleted {} rows from mv_product_rank_weekly for period {} ~ {}", deletedCount, startDate, endDate);
             return RepeatStatus.FINISHED;
         };
     }

---

76-84: Fault tolerance 정책 추가를 고려해 주세요.

현재 chunk 처리 중 단일 아이템 실패 시 전체 Step이 실패합니다. 일시적인 오류(네트워크, 데드락 등)에 대한 retry 정책이나, 특정 예외에 대한 skip 정책 추가를 권장합니다.

🔎 Fault tolerance 설정 예시

     @Bean
     public Step aggregateWeeklyRankStep(@Qualifier("weeklyProductMetricsAggReader") JdbcPagingItemReader<ProductMetricsAgg> weeklyProductMetricsAggReader) {
         return new StepBuilder("aggregateWeeklyRankStep", jobRepository)
                 .<ProductMetricsAgg, ProductRankRow>chunk(1000, transactionManager)
                 .reader(weeklyProductMetricsAggReader)
                 .processor(productMetricProcessor)
                 .writer(productMetricWeeklyWriter)
+                .faultTolerant()
+                .retryLimit(3)
+                .retry(Exception.class)  // 필요에 따라 특정 예외로 제한
                 .build();
     }

---

96-148: 코드 중복 개선을 고려해 주세요.

Weekly와 Monthly 설정이 거의 동일한 구조로 반복됩니다. 현재 상태로도 동작에 문제는 없지만, 향후 유지보수 시 helper 메서드나 팩토리 패턴으로 공통 로직을 추출하면 변경 사항을 한 곳에서 관리할 수 있습니다.

🔎 리팩토링 아이디어

// 예시: 공통 Step 생성 메서드
private Step createDeleteMvStep(String stepName, String tableName, String startDateParam, String endDateParam) {
    Tasklet tasklet = (contribution, chunkContext) -> {
        String sql = String.format("DELETE FROM %s WHERE start_date = :startDate AND end_date = :endDate", tableName);
        jdbcTemplate.update(sql, Map.of(
            "startDate", chunkContext.getStepContext().getJobParameters().get(startDateParam),
            "endDate", chunkContext.getStepContext().getJobParameters().get(endDateParam)
        ));
        return RepeatStatus.FINISHED;
    };
    return new StepBuilder(stepName, jobRepository)
            .tasklet(tasklet, transactionManager)
            .build();
}

단, 현재 구조가 명확하고 독립적인 진화가 가능하므로, 필요 시 나중에 리팩토링해도 무방합니다.

📜 Review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5a4975e and 52e3752.

📒 Files selected for processing (28)

• apps/commerce-api/src/main/java/com/loopers/application/ranking/DailyRankingService.java
• apps/commerce-api/src/main/java/com/loopers/application/ranking/MonthlyRankingService.java
• apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingFacade.java
• apps/commerce-api/src/main/java/com/loopers/application/ranking/RankingV1Dto.java
• apps/commerce-api/src/main/java/com/loopers/application/ranking/WeeklyRankingService.java
• apps/commerce-api/src/main/java/com/loopers/domain/ranking/MonthlyRankingMv.java
• apps/commerce-api/src/main/java/com/loopers/domain/ranking/MonthlyRankingRepository.java
• apps/commerce-api/src/main/java/com/loopers/domain/ranking/Period.java
• apps/commerce-api/src/main/java/com/loopers/domain/ranking/WeeklyRankingMv.java
• apps/commerce-api/src/main/java/com/loopers/domain/ranking/WeeklyRankingRepository.java
• apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/MonthlyRankingJpaRepository.java
• apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/MonthlyRankingRepositoryImpl.java
• apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/WeeklyRankingJpaRepository.java
• apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/WeeklyRankingRepositoryImpl.java
• apps/commerce-api/src/main/java/com/loopers/interfaces/api/ranking/RankingV1ApiSpec.java
• apps/commerce-api/src/main/java/com/loopers/interfaces/api/ranking/RankingV1Controller.java
• apps/commerce-batch/src/main/java/com/loopers/batch/config/BatchConfig.java
• apps/commerce-batch/src/main/java/com/loopers/batch/dto/ProductMetricsAgg.java
• apps/commerce-batch/src/main/java/com/loopers/batch/dto/ProductRankRow.java
• apps/commerce-batch/src/main/java/com/loopers/batch/job/demo/DemoJobConfig.java
• apps/commerce-batch/src/main/java/com/loopers/batch/job/demo/step/DemoTasklet.java
• apps/commerce-batch/src/main/java/com/loopers/batch/listener/ChunkListener.java
• apps/commerce-batch/src/main/java/com/loopers/batch/listener/JobListener.java
• apps/commerce-batch/src/main/java/com/loopers/batch/listener/StepMonitorListener.java
• apps/commerce-batch/src/main/java/com/loopers/batch/processor/ProductMetricProcessor.java
• apps/commerce-batch/src/main/java/com/loopers/batch/reader/ProductMetricReader.java
• apps/commerce-batch/src/main/java/com/loopers/batch/writer/ProductMetricMonthlyWriter.java
• apps/commerce-batch/src/main/java/com/loopers/batch/writer/ProductMetricWeeklyWriter.java

💤 Files with no reviewable changes (5)

• apps/commerce-batch/src/main/java/com/loopers/batch/listener/StepMonitorListener.java
• apps/commerce-batch/src/main/java/com/loopers/batch/listener/ChunkListener.java
• apps/commerce-batch/src/main/java/com/loopers/batch/listener/JobListener.java
• apps/commerce-batch/src/main/java/com/loopers/batch/job/demo/step/DemoTasklet.java
• apps/commerce-batch/src/main/java/com/loopers/batch/job/demo/DemoJobConfig.java

🧰 Additional context used

🧠 Learnings (3)

📚 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/WeeklyRankingJpaRepository.java
• apps/commerce-api/src/main/java/com/loopers/domain/ranking/WeeklyRankingRepository.java

📚 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-batch/src/main/java/com/loopers/batch/dto/ProductRankRow.java

📚 Learning: 2025-12-19T21:30:16.024Z

Learnt from: toongri
Repo: Loopers-dev-lab/loopers-spring-kotlin-template PR: 68
File: apps/commerce-api/src/main/kotlin/com/loopers/infrastructure/outbox/OutboxEventListener.kt:0-0
Timestamp: 2025-12-19T21:30:16.024Z
Learning: In the Loopers-dev-lab/loopers-spring-kotlin-template Kafka event pipeline, Like events (LikeCreatedEventV1, LikeCanceledEventV1) intentionally use aggregateType="Like" with aggregateId=productId. The aggregateId serves as a partitioning/grouping key (not a unique Like entity identifier), ensuring all like events for the same product go to the same partition for ordering guarantees and aligning with ProductStatisticService's product-based aggregation logic. Using individual like_id would scatter events across partitions and break the statistics aggregation pattern.

Applied to files:

• apps/commerce-batch/src/main/java/com/loopers/batch/dto/ProductMetricsAgg.java

🧬 Code graph analysis (12)

apps/commerce-batch/src/main/java/com/loopers/batch/processor/ProductMetricProcessor.java (3)

apps/commerce-batch/src/main/java/com/loopers/batch/reader/ProductMetricReader.java (1)

• Component (15-60)

apps/commerce-batch/src/main/java/com/loopers/batch/writer/ProductMetricMonthlyWriter.java (1)

• Component (15-55)

apps/commerce-batch/src/main/java/com/loopers/batch/writer/ProductMetricWeeklyWriter.java (1)

• Component (15-56)

apps/commerce-batch/src/main/java/com/loopers/batch/writer/ProductMetricWeeklyWriter.java (3)

apps/commerce-batch/src/main/java/com/loopers/batch/processor/ProductMetricProcessor.java (1)

• Component (12-35)

apps/commerce-batch/src/main/java/com/loopers/batch/reader/ProductMetricReader.java (1)

• Component (15-60)

apps/commerce-batch/src/main/java/com/loopers/batch/writer/ProductMetricMonthlyWriter.java (1)

• Component (15-55)

apps/commerce-api/src/main/java/com/loopers/application/ranking/WeeklyRankingService.java (4)

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

• Component (13-62)

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

• Component (9-31)

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

• Component (13-52)

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

• Component (13-52)

apps/commerce-batch/src/main/java/com/loopers/batch/writer/ProductMetricMonthlyWriter.java (3)

apps/commerce-batch/src/main/java/com/loopers/batch/processor/ProductMetricProcessor.java (1)

• Component (12-35)

apps/commerce-batch/src/main/java/com/loopers/batch/reader/ProductMetricReader.java (1)

• Component (15-60)

apps/commerce-batch/src/main/java/com/loopers/batch/writer/ProductMetricWeeklyWriter.java (1)

• Component (15-56)

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

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

• Entity (13-38)

apps/commerce-api/src/main/java/com/loopers/application/ranking/MonthlyRankingService.java (5)

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

• Component (13-62)

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

• Component (9-31)

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

• Component (14-91)

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

• Component (13-52)

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

• Component (13-52)

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

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

• Component (14-90)

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

• Component (9-31)

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

• Component (14-91)

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

• Component (13-52)

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

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

• Component (13-62)

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

• Component (14-90)

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

• Component (14-91)

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

• Component (13-52)

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

• Component (13-52)

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

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

• RankingV1Dto (7-25)

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

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

• Component (9-31)

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

• Component (14-91)

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

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

• Entity (13-40)

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

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

• RankingV1Dto (7-25)

🔇 Additional comments (18)

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

28-29: LGTM!

날짜 범위 필터링과 null 안전 처리가 적절합니다.

Also applies to: 45-46

---

19-19: 메서드 호출 시 파라미터 순서 확인 필요

WeeklyRankingRepositoryImpl 메서드 시그니처의 파라미터 순서(endDate, startDate)와 WeeklyRankingService에서의 호출 패턴을 검증하여 의도한 순서가 맞는지, 그리고 startDate/endDate가 올바르게 매핑되는지 확인해야 합니다.

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

1-7: LGTM!

간단하고 명확한 enum 정의입니다. 도메인 계층에 적절하게 위치하며 서비스와 API 계층에서 잘 활용되고 있습니다.

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

6-7: LGTM!

표준 Spring Data JPA 레포지토리 패턴을 따르고 있으며, 인프라 계층에 올바르게 배치되었습니다. 기본 CRUD 작업을 위한 적절한 구현입니다.

apps/commerce-batch/src/main/java/com/loopers/batch/dto/ProductRankRow.java (1)

5-11: productId 타입은 실제로는 널 불가능하므로 검토 불필요

ProductMetricReader의 rowMapper에서 rs.getLong("ref_product_id")를 사용하므로, productId는 실제로 null 값을 받지 않습니다. 데이터베이스 컬럼이 NULL이면 rs.getLong()은 null이 아닌 0을 반환합니다. 따라서 Long 타입 선언은 혼동을 줄 수 있지만, NullPointerException이나 데이터베이스 제약 조건 위반의 실제 위험은 없습니다. Writers의 MapSqlParameterSource도 null 값을 안전하게 처리합니다. 이는 타입 일관성 개선 사항이지 기능적 결함이 아닙니다.

Likely an incorrect or invalid review comment.

apps/commerce-batch/src/main/java/com/loopers/batch/processor/ProductMetricProcessor.java (1)

14-34: LGTM! 가중치 기반 점수 계산 로직이 잘 구현되었습니다.

BigDecimal을 사용하여 부동소수점 정밀도 문제를 방지하고, 가중치 합계가 1.0(0.1 + 0.3 + 0.6)으로 정확히 맞습니다. HALF_UP 반올림 모드도 적절합니다.

향후 가중치 조정이 필요할 경우, @Value 어노테이션을 통해 properties에서 주입받도록 확장할 수 있습니다.

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

1-25: LGTM! DTO 구조 개선이 잘 되었습니다.

패키지가 interfaces.api.ranking에서 application.ranking으로 이동되어 계층 아키텍처에 더 적합해졌습니다. ProductRankingPageResponse에 period, startDate, endDate 필드가 추가되어 다양한 랭킹 기간을 지원할 수 있게 되었습니다.

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

39-51: LGTM! countMonthly 구현이 안전하게 작성되었습니다.

fetchOne() 결과가 null일 경우를 적절히 처리하여 0L을 반환합니다.

apps/commerce-batch/src/main/java/com/loopers/batch/reader/ProductMetricReader.java (1)

52-57: RowMapper 필드 순서 확인 완료

ProductMetricsAgg 생성자의 파라미터 순서 (productId, sumLike, sumView, sumSales)가 rowMapper에서 추출하는 순서 (ref_product_id, sum_like, sum_view, sum_sales)와 정확히 일치합니다. 값의 순서가 올바르므로 추가 수정이 필요하지 않습니다.

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

28-28: 월간 기간 계산 방식 검토 필요

minusDays(30)을 사용하면 항상 30일 기간이 되어 실제 달력 월(28~31일)과 차이가 발생합니다. 비즈니스 요구사항이 "지난 30일"인지 "해당 월"인지 확인이 필요합니다. 만약 달력 월 기준이라면 minusMonths(1)을 고려하세요.

참고: WeeklyRankingService에서는 minusDays(6)을 사용하여 정확히 7일 윈도우를 구현했습니다(Line 28). Monthly도 동일한 패턴(고정 일수)을 따르는 것으로 보이지만, 월간 랭킹의 경우 달력 월 기준이 더 직관적일 수 있습니다.

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

16-29: 서비스 위임 패턴이 잘 구현됨

RankingFacade가 Period에 따라 적절한 서비스로 위임하는 구조가 명확합니다. Switch expression을 사용하여 가독성도 좋습니다.

Minor suggestion: Java의 sealed class나 exhaustive switch를 활용하면 default 케이스가 불필요해질 수 있지만, 현재 구조도 충분히 안전합니다. Period enum에 새로운 값이 추가되면 컴파일러가 경고하지 않으므로, 새로운 Period 추가 시 이 메서드를 업데이트하는 것을 잊지 마세요.

---

27-27: Period enum 값 검증 로직은 적절하며 default 케이스는 이론상 실행되지 않습니다

Period enum이 DAILY, WEEKLY, MONTHLY 세 가지 값만 정의되어 있고, 모든 케이스가 switch 문에서 처리되고 있습니다. 또한 RankingV1Controller의 @RequestParam(defaultValue = "DAILY") 설정으로 인해 null 값이 업스트림에서 차단되며, Spring의 enum 바인딩 검증이 유효하지 않은 Period 값을 거부합니다. 따라서 default 케이스는 이론상 실행될 수 없습니다. 그럼에도 불구하고 방어적 프로그래밍 차원에서 default 케이스의 존재는 적절합니다.

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

28-28: 주간 기간 계산이 올바름

minusDays(6)을 사용하여 endDate 포함 7일 윈도우를 정확히 구현했습니다. 예: endDate가 2024-01-07이면 startDate는 2024-01-01이 되어 7일 기간이 됩니다.

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

13-38: WeeklyRankingMv와 일관된 구조로 구현됨

MonthlyRankingMv는 WeeklyRankingMv와 동일한 패턴을 따르며, 테이블 이름(mv_product_rank_monthly)만 다릅니다. 이러한 일관성은 유지보수에 도움이 됩니다.

참고: WeeklyRankingMv 리뷰(Lines 13-40)에서 언급한 사항들(batch writer 검증, String 날짜 필드)이 이 엔티티에도 동일하게 적용됩니다.

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

13-40: 배치 쓰기는 JPA가 아닌 직접 SQL을 사용하므로 엔티티 구조 변경 불필요

검증 결과, ProductMetricWeeklyWriter와 ProductMetricMonthlyWriter는 NamedParameterJdbcTemplate.batchUpdate()를 사용하여 ProductRankRow DTO 객체를 직접 SQL INSERT 문으로 변환합니다. 배치 쓰기 과정에서 WeeklyRankingMv 엔티티 객체가 인스턴스화되지 않으므로, setter나 빌더가 필요하지 않습니다.

이 엔티티는 Materialized View를 나타내며 읽기 전용으로 설계된 것이 올바릅니다. 현재 구조(protected no-arg 생성자, @Getter만 포함)는 JPA 하이드레이션과 쿼리 결과 매핑에 최적화되어 있습니다.

apps/commerce-batch/src/main/java/com/loopers/batch/config/BatchConfig.java (3)

29-40: LGTM!

Spring Batch 설정을 위한 의존성 주입이 올바르게 구성되어 있습니다. Lombok @RequiredArgsConstructor를 활용한 생성자 주입 방식이 적절합니다.

---

41-48: LGTM!

@StepScope를 활용한 job parameter 주입이 적절합니다. Step 실행 시점에 파라미터가 바인딩되어 동적 날짜 범위 조회가 가능합니다.

---

86-93: LGTM!

RunIdIncrementer를 사용하여 동일 파라미터로 Job 재실행이 가능합니다. Delete → Aggregate 순서의 Step 실행 흐름이 적절합니다.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Long.parseLong(member)에서 예외 발생 가능성

Redis에서 가져온 member 값이 유효한 숫자가 아닐 경우 NumberFormatException이 발생할 수 있습니다. 데이터 무결성이 보장된다면 문제가 없지만, 방어적 코딩을 위해 예외 처리를 고려해 보세요.

🔎 방어적 예외 처리 제안

             for (var t : tuples) {
                 String member = t.getValue();
                 Double score = t.getScore();
                 if (member == null || score == null) continue;

+                Long productId;
+                try {
+                    productId = Long.parseLong(member);
+                } catch (NumberFormatException e) {
+                    continue; // 또는 로깅 후 건너뛰기
+                }
+
                 items.add(new RankingV1Dto.ProductRankingResponse(
                         rank++,
-                        Long.parseLong(member),
+                        productId,
                         score
                 ));
             }

🤖 Prompt for AI Agents

In
apps/commerce-api/src/main/java/com/loopers/application/ranking/DailyRankingService.java
around lines 46 to 56, parsing the Redis member string with
Long.parseLong(member) can throw NumberFormatException for non-numeric or
malformed values; wrap the parse in a defensive check (e.g., trim and validate
with a numeric check or regex) or a try-catch around Long.parseLong, log a
warning including the offending member and skip adding that entry (do not
increment rank for skipped items), and ensure null/blank members are also
handled consistently so the loop continues safely without crashing.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

프로덕션 로깅 방식으로 교체 필요

System.out.println은 프로덕션 환경에 적합하지 않습니다. 적절한 로깅 프레임워크(SLF4J)를 사용하여 로그 레벨과 출력 위치를 제어할 수 있도록 변경하세요.

🔎 제안하는 수정사항

클래스 상단에 logger 선언을 추가:

+import lombok.extern.slf4j.Slf4j;
+
+@Slf4j
 @Component
 @RequiredArgsConstructor
 public class MonthlyRankingService {

그리고 System.out.println을 로거로 교체:

-        System.out.println("startDate = " + startDate);
+        log.debug("Monthly ranking calculation - startDate: {}, endDate: {}", startDate, endDate);

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents

In
apps/commerce-api/src/main/java/com/loopers/application/ranking/MonthlyRankingService.java
around line 30, replace the System.out.println call with SLF4J logging: add a
private static final Logger logger =
LoggerFactory.getLogger(MonthlyRankingService.class) declaration at the top of
the class (ensure org.slf4j.Logger and org.slf4j.LoggerFactory are imported),
then change the println to logger.debug or logger.info("startDate = {}",
startDate) as appropriate for the message severity so logs are managed by the
configured logging framework.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Find repository interfaces and service implementation
echo "=== 파일 위치 확인 ==="
find . -type f -name "*RankingRepository*" -o -name "MonthlyRankingService.java" | head -20

echo -e "\n=== MonthlyRankingService 파일 찾기 ==="
fd MonthlyRankingService.java

echo -e "\n=== 리포지토리 파일들 찾기 ==="
fd "RankingRepository" --type f

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

Length of output: 1111

---

🏁 Script executed:

#!/bin/bash
# MonthlyRankingService의 line 32와 65 확인
echo "=== MonthlyRankingService.java 내용 (라인 25-75) ==="
cat -n apps/commerce-api/src/main/java/com/loopers/application/ranking/MonthlyRankingService.java | sed -n '25,75p'

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

Length of output: 2190

---

🏁 Script executed:

#!/bin/bash
# 리포지토리 인터페이스 메서드 시그니처 확인
echo "=== MonthlyRankingRepository getMonthlyTop100 메서드 ==="
rg "getMonthlyTop100" -A 2 -B 1

echo -e "\n=== MonthlyRankingRepository countMonthly 메서드 ==="
rg "countMonthly" -A 2 -B 1

echo -e "\n=== WeeklyRankingRepository getWeeklyTop100 메서드 ==="
rg "getWeeklyTop100" -A 2 -B 1

echo -e "\n=== WeeklyRankingRepository countWeekly 메서드 ==="
rg "countWeekly" -A 2 -B 1

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

Length of output: 9011

---

리포지토리 메서드 간 파라미터 순서 일관성 통일 필요

Line 65의 getMonthlyTop100(endDate, startDate, ...)와 Line 32의 countMonthly(startDate, endDate) 호출에서 파라미터 순서가 반대입니다. MonthlyRankingRepository 인터페이스에서 두 메서드의 파라미터 순서가 일관되지 않으므로 (getMonthlyTop100은 endDate 먼저, countMonthly는 startDate 먼저), WeeklyRankingRepository와 동일한 패턴으로 통일하는 것을 권장합니다. 같은 논리를 다루는 메서드들에서 파라미터 순서를 일관되게 유지하면 혼동을 방지할 수 있습니다.

🤖 Prompt for AI Agents

In
apps/commerce-api/src/main/java/com/loopers/application/ranking/MonthlyRankingService.java
around line 65, the call getMonthlyTop100(endDate, startDate, ...) uses the
opposite parameter order to countMonthly(startDate, endDate) (called at line
32); make the parameter ordering consistent with WeeklyRankingRepository and
other methods by changing getMonthlyTop100's signature and all its usages to
accept (startDate, endDate, ...) instead of (endDate, startDate), then update
the repository implementation and any callers (including this line 65) to pass
startDate first and endDate second so both methods use the same
startDate,endDate ordering.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

프로덕션 로깅 방식으로 교체 필요

MonthlyRankingService와 동일한 이슈: System.out.println은 프로덕션 환경에 적합하지 않습니다. SLF4J 로거를 사용하세요.

🔎 제안하는 수정사항

+import lombok.extern.slf4j.Slf4j;
+
+@Slf4j
 @Component
 @RequiredArgsConstructor
 public class WeeklyRankingService {

-        System.out.println("startDate = " + startDate);
+        log.debug("Weekly ranking calculation - startDate: {}, endDate: {}", startDate, endDate);

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents

In
apps/commerce-api/src/main/java/com/loopers/application/ranking/WeeklyRankingService.java
around line 30, replace the System.out.println call with SLF4J logging: add a
private static final org.slf4j.Logger logger =
org.slf4j.LoggerFactory.getLogger(WeeklyRankingService.class); import the SLF4J
classes, then change the print statement to logger.info("startDate = {}",
startDate); ensuring you use parameterized logging and remove the
System.out.println.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

치명적: 파라미터 순서 불일치로 인한 잠재적 버그 위험

getMonthlyTop100은 endDate를 startDate보다 먼저 받지만, countMonthly는 startDate를 endDate보다 먼저 받습니다. 이러한 파라미터 순서의 불일치는 개발자가 호출 시 날짜를 잘못된 순서로 전달하여 잘못된 데이터를 조회하는 심각한 버그를 유발할 수 있습니다.

또한 WeeklyRankingRepository.getWeeklyTop100과도 파라미터 순서가 다릅니다.

🔎 일관된 파라미터 순서로 수정 제안

-    List<MonthlyRankingMv> getMonthlyTop100(String endDate, String startDate, int safePage, int safeSize);
+    List<MonthlyRankingMv> getMonthlyTop100(String startDate, String endDate, int safePage, int safeSize);
     long countMonthly(String startDate, String endDate);

더 나은 개선안 (String 날짜 문제도 함께 해결):

+import java.time.LocalDate;
+
 public interface MonthlyRankingRepository {
-    List<MonthlyRankingMv> getMonthlyTop100(String endDate, String startDate, int safePage, int safeSize);
-    long countMonthly(String startDate, String endDate);
+    List<MonthlyRankingMv> getMonthlyRankings(LocalDate startDate, LocalDate endDate, int page, int size);
+    long countMonthly(LocalDate startDate, LocalDate endDate);
 }

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	List<MonthlyRankingMv> getMonthlyTop100(String endDate, String startDate, int safePage, int safeSize);
	long countMonthly(String startDate, String endDate);
	List<MonthlyRankingMv> getMonthlyTop100(String startDate, String endDate, int safePage, int safeSize);
	long countMonthly(String startDate, String endDate);

[coderabbitai]

⚠️ Potential issue | 🟠 Major

String 타입 날짜 파라미터는 타입 안정성 문제를 야기합니다

날짜를 String 타입으로 받으면 다음과 같은 문제가 발생합니다:

• 런타임 파싱 오류 가능성
• 날짜 형식 불일치 (예: "2025-01-02" vs "20250102")
• 컴파일 타임 타입 검증 불가
• 날짜 연산 시 매번 파싱 필요

또한, 파라미터 명명이 일관되지 않습니다: date와 lastWeek는 의미가 명확하지 않으며, countWeekly의 startDate/endDate와도 불일치합니다.

🔎 LocalDate 사용으로 개선 제안

-    List<WeeklyRankingMv> getWeeklyTop100(String date, String lastWeek, int page, int size);
-    long countWeekly(String startDate, String endDate);
+    List<WeeklyRankingMv> getWeeklyTop100(LocalDate endDate, LocalDate startDate, int page, int size);
+    long countWeekly(LocalDate startDate, LocalDate endDate);

파일 상단에 import 추가:

 import java.util.List;
+import java.time.LocalDate;

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents

In
apps/commerce-api/src/main/java/com/loopers/domain/ranking/WeeklyRankingRepository.java
around line 6, replace the two String date parameters with java.time.LocalDate
and standardize names to match other APIs (e.g., startDate and endDate) to
ensure type safety; update the method signature to use LocalDate startDate,
LocalDate endDate (keeping page and size), add the necessary import
(java.time.LocalDate) at the top, and then propagate this change to all
implementations, callers, and unit/integration tests to parse/convert input
strings to LocalDate at the boundary (e.g., controller) rather than inside the
repository.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Search for usage of WeeklyRankingJpaRepository
rg -nP --type=java 'WeeklyRankingJpaRepository' .

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

Length of output: 281

---

🏁 Script executed:

#!/bin/bash
# Search for WeeklyRankingRepositoryImpl and related classes
rg -nP --type=java 'WeeklyRankingRepository' .

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

Length of output: 883

---

WeeklyRankingJpaRepository 제거 필요

WeeklyRankingJpaRepository는 선언되어 있지만 코드베이스 어디에서도 주입되거나 사용되지 않습니다. 실제 사용되는 것은 WeeklyRankingRepository 도메인 인터페이스이며, WeeklyRankingRepositoryImpl이 이를 구현하고 있습니다. 따라서 WeeklyRankingJpaRepository는 제거하면 됩니다.

🤖 Prompt for AI Agents

In
apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/WeeklyRankingJpaRepository.java
around lines 6 to 8, remove the unused JpaRepository interface declaration:
WeeklyRankingJpaRepository is never injected or referenced (the code uses
WeeklyRankingRepository and its implementation WeeklyRankingRepositoryImpl), so
delete this file and any imports referencing it; run a project-wide search to
confirm no remaining usages and update build/config if needed.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

find . -type f -name "RankingV1ApiSpec.java" | head -20

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

Length of output: 178

---

🏁 Script executed:

find . -type f -path "*commerce-api*" -name "*.java" | grep -i ranking | head -20

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

Length of output: 1807

---

🏁 Script executed:

cat -n ./apps/commerce-api/src/main/java/com/loopers/interfaces/api/ranking/RankingV1ApiSpec.java

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

Length of output: 526

---

🏁 Script executed:

cat -n ./apps/commerce-api/src/main/java/com/loopers/interfaces/api/ranking/RankingV1Controller.java

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

Length of output: 1518

---

🏁 Script executed:

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

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

Length of output: 1492

---

🏁 Script executed:

rg -A 10 "getProductRanking" ./apps/commerce-api/src/main/java/com/loopers/ --type java

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

Length of output: 3461

---

🏁 Script executed:

cat -n ./apps/commerce-api/src/main/java/com/loopers/application/ranking/DailyRankingService.java

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

Length of output: 2833

---

🏁 Script executed:

rg "LocalDate|DateTimeFormatter|parse" ./apps/commerce-api/src/main/java/com/loopers/application/ranking/ -A 2 --type java

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

Length of output: 3076

---

🏁 Script executed:

cat -n ./apps/commerce-api/src/main/java/com/loopers/application/ranking/WeeklyRankingService.java

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

Length of output: 3570

---

🏁 Script executed:

cat -n ./apps/commerce-api/src/main/java/com/loopers/application/ranking/MonthlyRankingService.java

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

Length of output: 3575

---

Controller의 date 파라미터에 @DateTimeFormat 애노테이션 추가 및 형식 문서화 필요

@RequestParam String date에 형식 지정이 없어 다음 문제 발생:

• WEEKLY와 MONTHLY 기간 조회 시 LocalDate.parse(date, BASIC_ISO_DATE) 호출로 "yyyyMMdd" 형식 강제되지만 문서화되지 않음
• 잘못된 형식(예: "yyyy-MM-dd") 입력 시 DateTimeParseException 발생
• OpenAPI/Swagger 스펙에서 날짜 형식 명시 불가능

RankingV1Controller의 getProductRanking 메서드에서 @DateTimeFormat(pattern = "yyyyMMdd")를 추가하고, JavaDoc으로 "yyyyMMdd 형식의 날짜" 명시 필요.

🤖 Prompt for AI Agents

In
apps/commerce-api/src/main/java/com/loopers/interfaces/api/ranking/RankingV1ApiSpec.java
around line 9, the date request parameter lacks a declared format causing
LocalDate.parse(date, BASIC_ISO_DATE) to fail for inputs like "yyyy-MM-dd" and
leaving the OpenAPI spec without a date pattern; add @DateTimeFormat(pattern =
"yyyyMMdd") to the controller/interface method parameter for date and update the
method JavaDoc to state "date must be in yyyyMMdd format" so the runtime
parsing, exception behavior and generated OpenAPI documentation clearly reflect
the expected format.

[coderabbitai]

🛠️ Refactor suggestion | 🟠 Major

ProductMetricWeeklyWriter와 높은 코드 중복

이 클래스는 ProductMetricWeeklyWriter와 거의 동일한 구조를 가지고 있으며, 테이블 이름과 파라미터 키만 다릅니다. 추상 베이스 클래스나 템플릿 메서드 패턴을 사용하여 중복을 제거하는 것을 권장합니다.

🔎 제안: 추상 베이스 클래스 추출

// 새 파일: AbstractProductMetricWriter.java
@RequiredArgsConstructor
public abstract class AbstractProductMetricWriter implements ItemWriter<ProductRankRow> {
    protected final NamedParameterJdbcTemplate jdbcTemplate;
    
    protected abstract String getStartDateParam();
    protected abstract String getEndDateParam();
    protected abstract String getTableName();
    
    @Override
    public void write(Chunk<? extends ProductRankRow> chunk) {
        ZonedDateTime now = ZonedDateTime.now();
        String sql = String.format("""
            INSERT INTO %s
              (start_date, end_date, ref_product_id,
               view_count_sum, like_count_sum, sales_volume_sum,
               score, created_at, updated_at, deleted_at)
            VALUES
              (:startDate, :endDate, :productId,
               :viewCountSum, :likeCountSum, :salesVolumeSum,
               :score, :createdAt, :updatedAt, NULL)
            """, getTableName());
        
        MapSqlParameterSource[] batch = chunk.getItems().stream()
                .map(item -> new MapSqlParameterSource()
                        .addValue("startDate", getStartDateParam())
                        .addValue("endDate", getEndDateParam())
                        .addValue("productId", item.productId())
                        .addValue("viewCountSum", item.viewCountSum())
                        .addValue("likeCountSum", item.likeCountSum())
                        .addValue("salesVolumeSum", item.salesVolumeSum())
                        .addValue("score", item.score())
                        .addValue("createdAt", now)
                        .addValue("updatedAt", now))
                .toArray(MapSqlParameterSource[]::new);

        jdbcTemplate.batchUpdate(sql, batch);
    }
}

// ProductMetricMonthlyWriter는 간소화
@Component
@StepScope
public class ProductMetricMonthlyWriter extends AbstractProductMetricWriter {
    @Value("#{jobParameters['monthlyStartDate']}")
    private String startDate;
    
    @Value("#{jobParameters['monthlyEndDate']}")
    private String endDate;
    
    public ProductMetricMonthlyWriter(NamedParameterJdbcTemplate jdbcTemplate) {
        super(jdbcTemplate);
    }
    
    @Override
    protected String getStartDateParam() { return startDate; }
    
    @Override
    protected String getEndDateParam() { return endDate; }
    
    @Override
    protected String getTableName() { return "mv_product_rank_monthly"; }
}

🤖 Prompt for AI Agents

In
apps/commerce-batch/src/main/java/com/loopers/batch/writer/ProductMetricMonthlyWriter.java
(lines 18-54) and its Weekly counterpart, there is high duplication; extract a
new AbstractProductMetricWriter base class that holds the
NamedParameterJdbcTemplate, the generic write(Chunk) implementation (builds SQL
using an abstract getTableName(), constructs the batch params using
ZonedDateTime.now() once, and calls jdbcTemplate.batchUpdate), and declares
abstract getters getStartDateParam(), getEndDateParam(), and getTableName();
make jdbcTemplate protected final and move common SQL/template logic into the
base class; update ProductMetricMonthlyWriter to be a thin subclass (keep
@Component and @StepScope, keep @Value fields for
monthlyStartDate/monthlyEndDate, call super(jdbcTemplate) in constructor, and
implement the three abstract getters returning the injected fields and
"mv_product_rank_monthly"); apply the same refactor to ProductMetricWeeklyWriter
(return weekly params and table) so both classes only provide parameter values
and table name.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

배치 재실행 시 중복 데이터 삽입 위험

INSERT 문에 중복 처리 로직(ON CONFLICT 또는 ON DUPLICATE KEY UPDATE)이 없어, 동일한 기간에 대해 배치가 재실행되면 중복 레코드가 삽입됩니다. 배치 작업의 멱등성(idempotency)을 보장하기 위해 upsert 패턴을 고려해 주세요.

🔎 PostgreSQL의 경우 ON CONFLICT 사용 예시

     private static final String SQL = """
         INSERT INTO mv_product_rank_weekly
           (start_date, end_date, ref_product_id,
            view_count_sum, like_count_sum, sales_volume_sum,
            score, created_at, updated_at, deleted_at)
         VALUES
           (:startDate, :endDate, :productId,
            :viewCountSum, :likeCountSum, :salesVolumeSum,
            :score, :createdAt, :updatedAt, NULL)
+        ON CONFLICT (start_date, end_date, ref_product_id)
+        DO UPDATE SET
+          view_count_sum = EXCLUDED.view_count_sum,
+          like_count_sum = EXCLUDED.like_count_sum,
+          sales_volume_sum = EXCLUDED.sales_volume_sum,
+          score = EXCLUDED.score,
+          updated_at = EXCLUDED.updated_at
         """;

참고: ProductMetricMonthlyWriter.java에도 동일한 수정이 필요합니다.

🤖 Prompt for AI Agents

In
apps/commerce-batch/src/main/java/com/loopers/batch/writer/ProductMetricWeeklyWriter.java
around lines 27-36, the SQL INSERT lacks conflict handling so re-running the
batch can insert duplicate rows for the same period/product; update the
statement to an upsert by adding an ON CONFLICT clause keyed on the unique
constraint (probably start_date, end_date, ref_product_id) that performs DO
UPDATE setting the aggregate columns (view_count_sum, like_count_sum,
sales_volume_sum, score) and timestamps (updated_at) from the excluded values,
ensure created_at remains unchanged on update, and mirror the same change in
ProductMetricMonthlyWriter.java.