GET /api/books/{bookId}/chapters 조회 시 챕터 목록을 가져온 뒤 각 챕터별 청크 개수를 다시 조회하는 구조였다.
이 방식은 챕터 수만큼 추가 조회가 발생해 N+1 문제가 생기고, 책 규모가 커질수록 응답 시간이 불필요하게 늘어날 수 있었다.
ChunkRepository에서 MongoDB Aggregation Pipeline으로 여러 챕터의 난이도별 청크 개수를 한 번에 조회하도록 바꿨다.
ChapterService는 개별 count 호출 대신 집계 결과를 맵으로 받아 응답 조합에 사용하도록 정리했다.
목록 조회에서 가장 비싼 부분은 반복적인 청크 개수 조회였다. 이 문제는 캐시보다 먼저 조회 패턴을 바로잡는 편이 단순하고, 데이터 정합성도 유지하기 쉽다. Aggregation은 현재 MongoDB 구조를 크게 바꾸지 않으면서도 쿼리 수를 줄일 수 있는 가장 직접적인 선택이었다.
ChapterServiceTest에서 집계 결과를 기반으로 응답이 조합되는지 확인한다.- 목록 조회 시 챕터 수에 비례해 청크 개수 조회가 반복되지 않는지 로그와 쿼리 패턴으로 확인한다.
- 동일한 요청에서 기존 응답 필드와 진행률 계산이 유지되는지 회귀 테스트로 확인한다.
content/book영역 전체에서 비슷한 반복 조회가 더 있는지 추가 점검이 필요하다.- 실제 트래픽 기준 성능 개선 폭은 쿼리 로그나 부하 테스트로 별도 측정해두는 편이 좋다.
- 집계 결과가 더 복잡해지면 응답 조합 로직을 별도 조회 모델로 분리할지 다시 검토할 수 있다.
- 관련 이슈: 없음
- 관련 PR: #197