[Refactor] 피드 전체 조회 n+1 문제 해결

[paka-jo]

📌 개요

• 피드 목록 조회 시, 각 피드마다 좋아요/댓글/미디어 정보를 가져오기 위한 추가 쿼리가 발생하는 N+1 문제로 성능 저하 발생하여 피드 개수만큼 나가던 쿼리를 로그인 시 3개 / 비로그인 시 2개로 고정하여 조회 성능 최적화

🛠️ 작업 내용

• Feed 엔티티에 commentCount, likeCount, sharedCount 컬럼 추가.
• 필요한 필드만 조회하는 FetchFeedResponse DTO 매핑 적용
• 미디어 파일, 좋아요 여부 조회 시 IN 절을 사용하여 한 번에 조회하도록 리팩토링
• 무한 스크롤 성능을 위해 Count 쿼리가 없는 Slice 방식 도입.

쿼리문 최적화

• Before: 피드 10개 조회 시 쿼리 10+N개 발생 (N+1 문제)

• After: 피드 개수와 상관없이 쿼리 3방으로 고정 (피드 조회 -> 미디어 조회 -> 좋아요 여부 조회)

결과

100만건 이상의 피드 조회 시

측정 지표 (Metric)	개선 전 (Before)	개선 후 (After)	개선 효과
평균 응답 속도 (Avg Duration)	6.95초 (6,950ms)	0.0029초 (2.93ms)	약 2,370배 단축
체감 응답 속도 (P95 Duration)	11.47초 (11,470ms)	0.004초 (4.04ms)	약 2,839배 단축
초당 처리량 (Throughput)	8.9 req/s	196.7 req/s	약 22배 증가
총 처리 요청 수 (Total Reqs)	469건	9,917건	약 21배 증가

📌 차후 계획 (Optional)

• feed 상세조회 시 발생하는 n+1 문제 최적화 예정
• 대용량 트래픽에 대비한 추가 성능 개선 고려 (Redis 캐싱 처리, No-Offset 커서 기반 페이징 등)

📌 테스트 케이스

• 기능 정상 동작 확인
• 새로운 의존성 추가 여부 확인 (package.json, build.gradle 등)
• 코드 스타일 및 컨벤션 준수 확인
• 기존 테스트 통과 여부 확인

📌 기타 참고 사항

📌 리뷰어가 확인해야 할 추가 내용, 고민한 점, 결정 과정 등

• J@Query를 활용한 JPQL Projection 방식을 시도 했으나 성능 저하로 인해 EntityManger를 사용해 Custom Repository 방식으로 변경하여 쿼리 실행 계획을 최적화하였습니다
• JPQL 방식 시도 시 성능 저하 로그

---

🙏🏻아래와 같이 PR을 리뷰해주세요.

• PR 내용이 부족하다면 보충 요청해주세요.
• 코드 스타일이 팀의 규칙에 맞게 작성되었는지, 일관성을 유지하고 있는지 확인해주세요.
• 코드에 대한 문서화나 주석이 필요한 부분에 적절하게 작성되어 있는지 확인해주세요.
• 구현된 로직이 효율적이고 올바르게 작성되었는지, 아키텍처를 잘 준수하고 있는지 검토해주세요.
• 네이밍, 포매팅, 주석 등 코드의 일관성이 유지되고 있는지 확인해주세요.