[ Refactor ] - AI 리포트 배치 대상 소득분석 조회 N+1 → 벌크 조회 개선

[hanjyoon01]

관련 이슈

• Resolves : [ Refactor ] - AI 리포트 배치 대상 소득분석 조회 N+1 → 벌크 조회 개선 #150

작업 사항

• work-service 소득분석 조회(SETTLEMENT/JOB/WORK_LOG/WORK_LOG_PLATFORM_INCOME)를 사용자 단건 조회에서 벌크(IN절) 조회로 개선
  • SettlementMapper/JobMapper/WorkLogMapper/WorkLogPlatformIncomeMapper에 벌크 조회 메서드 추가, 각 InMemory*Mapper 페이크도 함께 구현
  • IncomeAnalysisService.aggregateMonth를 DB 조회부/순수 집계부로 분리, getMonthlyIncomeAnalysisBulk 추가 - 단건 경로와 buildSummary()로 조립 로직 공유
  • buildEarnedDepositComparisons/buildFatigueSummaries가 findWorkLogsInMonth를 각각 중복 호출하던 부분 제거
  • IncomeAnalysisQueryClient(common)에 default 메서드로 벌크 조회 계약 추가 - 다른 도메인(diagnosis-service/ai-service)의 기존 구현체·테스트는 변경 없이 그대로 컴파일되도록 함
• SettlementMapper가 실제 DB에서 언더스코어 컬럼(actual_amount, job_id 등)을 매핑하지 못하던 버그 발견 및 수정 (resultMap 명시)
• 벌크 vs 단건 유닛 테스트 추가 (결과 일치, 사용자 간 데이터 미혼입 검증)
• 실제 MySQL 기반 성능 비교 테스트 추가 (RUN_INCOME_ANALYSIS_BULK_PERF_TEST=true)

실제 비교 결과 (사용자 1000명)

참고 사항

• SettlementMapper 버그(중요): SELECT * + resultType만 쓰고 명시적 resultMap이 없어서, mapUnderscoreToCamelCase 설정이 없는 이 프로젝트에서는 actual_amount/job_id/period_start 등 언더스코어 컬럼이 전부 null로 매핑되고 있었습니다. InMemorySettlementMapper 기반 유닛 테스트는 실제 DB를 거치지 않아 이 문제를 못 잡았고, 이번에 처음 실제 MySQL로 돌려본 성능 테스트에서 NPE로 드러났습니다. 이 PR에서 resultMap을 추가해 고쳤지만, 운영 환경에서 실제로 소득분석 결과에 영향이 있었는지는 별도 확인이 필요합니다. SETTLEMENT를 함께 쓰는 diagnosis-service 쪽도 확인이 필요합니다.

---

추가 참고 사항‼️ -> 구현 완료

• ai-service 연동은 이번 PR 범위 밖입니다.

• MonthlyAiReportOrchestrationService(ai-service)가 여전히 사용자 루프 안에서 단건 메서드를 호출하는 한, 실제 AI 리포트 배치의 쿼리 수는 줄어들지 않습니다. 벌크 메서드는 이번에 준비만 해뒀고, 배치가 그걸 쓰도록 바꾸는 작업은 별도 이슈로 진행 필요합니다. 참고로 필요한 변경은 대략 이렇습니다:

  1. runBatch()에서 사용자 루프 밖으로 incomeAnalysisQueryClient.getMonthlyIncomeAnalysisBulk(userIds, targetYearMonth) 호출을 빼내서, 전체 사용자분을 미리 Map<Long, MonthlyIncomeAnalysisSummary>로 한 번에 받아둡니다.
  2. processUserReport(userId, targetYearMonth)가 내부에서 직접 getMonthlyIncomeAnalysis(userId, ...)를 호출하던 부분을 지우고, 1번에서 받은 Map에서 꺼낸 값을 파라미터로 받도록 시그니처를 바꿉니다 (processUserReport(userId, targetYearMonth, income)).
  3. 기존엔 사용자 1명 처리 실패가 try/catch로 격리돼 있었는데, 벌크 호출을 루프 밖으로 빼면 그 벌크 호출 자체의 실패는 더 이상 사용자 단위로 격리되지 않습니다. 벌크 호출을 별도로 try/catch해서 실패 시 빈 Map으로 진행하고 로그를 남기는 처리가 필요합니다.
  4. monthlyExpenseQueryClient(account-service, 소비집계)는 이 PR에 포함 안 됐으므로 위 작업을 해도 배치 쿼리 수는 절반만 줄어듭니다. 완전히 해결하려면 account-service 쪽도 같은 방식으로 벌크화하고 배치가 그것도 같이 쓰도록 바꿔야 합니다.

  work-service의 getMonthlyIncomeAnalysisBulk는 사용자 6000명이든 몇 명이든 쿼리 6개로 고정되니, 위 작업만 하면 배치 쪽 쿼리 수도 동일하게 고정됩니다.