계층형 문서 조회 N+1 → Fetch Join + In-Memory 트리
450ms → 25ms (18배)Problem— API 응답 450ms → 25ms (18배 개선)
사이드바 문서 목록 조회에서 쿼리가 대량 발생하고, 응답시간이 450ms까지 느려졌습니다.문서 30개를 조회할 때 각 문서의 부모(parent) 관계를 Lazy Loading으로 개별 SELECT하는 구조여서, 문서 수에 비례해 쿼리가 늘어나는 N+1 문제가 발생했습니다.
- •실측 응답시간 450ms, 사이드바 열 때 뚜렷한 지연 체감
- •쿼리 로그 확인 후 원인 특정
Approach
Fetch Join으로 1쿼리 로드 후, HashMap O(n) 트리 조립으로 해결했습니다.
@BatchSize도 검토했지만, 사이드바 트리는 전체 문서가 항상 필요해 부분 로딩의 이점이 없었습니다. Fetch Join으로 전체 로드 후 DocumentTreeResponse.from()으로 필요 필드만 DTO에 매핑해 엔티티 그래프 탐색을 차단했습니다.스크리브닝 모드(무한 스크롤)는 Pageable이 필요해 Fetch Join 시 메모리 경고가 발생, 네이밍 쿼리로 분리해 해결했습니다.Result
쿼리 61개 → 1개, 응답 450ms → 25ms로 18배 개선.Chrome DevTools Network 탭에서 응답 시간을 측정해 확인.
↳용도별 쿼리 분리: 사이드바 트리 = Fetch Join(페이징 불필요) / 스크리브닝 = Spring Data 네이밍 쿼리 + Pageable
↳HHH90003004 회피: 스크리브닝에서 Fetch Join + Pageable 시도 → 메모리 전체 로딩 경고 → 쿼리 분리로 해결
↳In-Memory 트리 구성: Fetch Join으로 Flat 데이터 로드 후 HashMap O(n) 트리 조립
DocumentRepository.javaFetch Join으로 1쿼리 조회
@Query("SELECT d FROM Document d LEFT JOIN FETCH d.parent WHERE d.project = :project ORDER BY d.order ASC")
List<Document> findByProjectWithParent(@Param("project") Project project);
// DocumentService.java — HashMap으로 O(n) 트리 조립
private List<DocumentTreeResponse> buildTreeInMemory(List<Document> documents) {
Map<UUID, DocumentTreeResponse> dtoMap = new HashMap<>();
List<DocumentTreeResponse> roots = new ArrayList<>();
for (Document doc : documents) {
dtoMap.put(doc.getId(), DocumentTreeResponse.from(doc));
}
for (Document doc : documents) {
DocumentTreeResponse dto = dtoMap.get(doc.getId());
if (doc.getParent() == null) {
roots.add(dto); // ← 루트 노드
} else {
dtoMap.get(doc.getParent().getId()).getChildren().add(dto); // ← O(1) 연결
}
}
return roots;
}