반복 집계 쿼리 통합 및 연관 엔티티 조회 최적화

QUERY OPTIMIZATION

반복 COUNT 쿼리와 지연 로딩 추가 조회를 최적화한 과정

목차

• 1. 작업 배경
• 2. 게시판 목록의 COUNT 쿼리 N+1
• 3. GROUP BY 기반 일괄 집계로 개선
• 4. 게시글 상세 조회의 지연 로딩 추가 쿼리
• 5. EntityGraph를 이용한 연관 엔티티 동시 조회
• 6. 변경 전후 결과
• 7. 정리 및 배운 점

1. 작업 배경

이 작업은 커뮤니티 서비스 프로젝트의 조회 기능을 개발하는 과정에서 진행했다. 사용자는 게시판 목록에서 각 게시판의 게시글 수를 확인할 수 있고, 게시글 상세 화면에서는 본문과 함께 게시판, 카테고리, 작성자, 댓글 정보를 조회할 수 있도록 구현했다.

대상 기능은 GET /boards 게시판 목록 조회와 GET /posts/{postId} 게시글 상세 조회였다. 기능 구현 후 SQL 실행 구조를 점검한 결과, 조회 결과를 DTO로 조립하는 과정에서 동일한 목적의 쿼리가 반복되거나 지연 로딩된 연관 엔티티를 개별적으로 조회하는 문제가 확인됐다.

구체적으로 게시판 목록에서는 각 게시판의 게시글 수를 계산하기 위해 게시판마다 COUNT 쿼리를 실행하고 있었다. 게시글 상세 조회에서는 Post를 먼저 조회한 뒤 Board, Category, Author에 접근하면서 추가 조회가 발생했다. 두 조회 기능의 문제 원인이 달랐기 때문에 각각 일괄 집계와 연관 엔티티 동시 조회 방식으로 개선했다.

두 사례는 같은 조회 최적화 작업이지만 성격은 다르다. 게시판 목록은 데이터 개수에 따라 쿼리가 증가하는 명확한 N+1 문제이고, 게시글 상세 조회는 단건 조회 과정에서 지연 로딩으로 발생한 연관 엔티티 추가 조회를 줄인 사례다.

기록 기준
아래 SQL은 당시 남겨 둔 쿼리 수와 실행 구조를 바탕으로 단순화한 예시다. 실제 Hibernate SQL 로그의 전체 컬럼과 별칭을 그대로 옮긴 것은 아니다.

2. 게시판 목록의 COUNT 쿼리 N+1

GET /boards는 삭제되지 않은 게시판 목록과 게시판별 게시글 수를 함께 반환하는 API다. 초기 구현에서는 게시판 목록을 먼저 조회한 뒤, 각 게시판을 DTO로 변환하면서 게시글 수를 개별 조회했다.

// BoardService
public List<BoardResponse> getAllBoards() {
    return boardRepository.findAllByIsDeletedFalse()
            .stream()
            .map(board -> BoardResponse.from(
                    board,
                    postRepository.countByBoardIdAndIsDeletedFalse(
                            board.getId()
                    )
            ))
            .toList();
}

게시판이 3개라면 게시판 목록 조회 1회와 게시판별 게시글 수 조회 3회가 실행된다. 게시판 수를 N이라고 하면 전체 쿼리 수는 1 + N회가 된다.

-- 게시판 목록 조회
SELECT *
FROM boards
WHERE is_deleted = false;

-- 각 게시판의 게시글 수를 개별 조회
SELECT COUNT(*)
FROM post
WHERE board_id = 1
  AND is_deleted = false;

SELECT COUNT(*)
FROM post
WHERE board_id = 2
  AND is_deleted = false;

SELECT COUNT(*)
FROM post
WHERE board_id = 3
  AND is_deleted = false;

게시판 수	목록 조회	COUNT 조회	전체 쿼리 수
3개	1회	3회	4회
N개	1회	N회	1 + N회

이 구조는 게시판 수가 증가할수록 COUNT 쿼리도 같은 비율로 증가한다. 개별 게시판의 게시글 수를 조회하는 기능 자체에는 문제가 없지만, 목록 API에서 반복 호출하는 방식이 비효율적이었다.

3. GROUP BY 기반 일괄 집계로 개선

게시판마다 게시글 수를 따로 계산하는 대신, 전체 게시판의 게시글 수를 한 번의 집계 쿼리로 조회하도록 변경했다.

// PostRepository
@Query("""
    SELECT p.board.id, COUNT(p)
    FROM Post p
    WHERE p.isDeleted = false
    GROUP BY p.board.id
    """)
List<Object[]> countByBoardGrouped();

Repository는 게시판 ID와 게시글 수를 한 번에 반환한다. Service에서는 집계 결과를 Map<Long, Long>으로 변환한 뒤, 게시판 DTO를 생성할 때 게시판 ID로 게시글 수를 조회하도록 구성했다.

// BoardService
public List<BoardResponse> getAllBoards() {
    List<Board> boards =
            boardRepository.findAllByIsDeletedFalse();

    Map<Long, Long> postCountMap =
            postRepository.countByBoardGrouped()
                    .stream()
                    .collect(Collectors.toMap(
                            row -> (Long) row[0],
                            row -> (Long) row[1]
                    ));

    return boards.stream()
            .map(board -> BoardResponse.from(
                    board,
                    postCountMap.getOrDefault(
                            board.getId(),
                            0L
                    )
            ))
            .toList();
}

변경 후에는 게시판 목록 조회 1회와 게시판별 게시글 수 집계 1회만 실행된다. 게시판 수와 관계없이 쿼리 수가 2회로 고정된다.

-- 게시판 목록 조회
SELECT *
FROM boards
WHERE is_deleted = false;

-- 게시판별 게시글 수를 한 번에 집계
SELECT board_id, COUNT(id)
FROM post
WHERE is_deleted = false
GROUP BY board_id;

게시판 목록 조회 결과

• 변경 전: 게시판 3개 기준 4회 조회
• 변경 후: 게시판 수와 관계없이 2회 조회
• 쿼리 증가 구조: 1 + N회에서 고정 2회로 변경
• 게시글이 없는 게시판은 getOrDefault(..., 0L)로 처리

4. 게시글 상세 조회의 지연 로딩 추가 쿼리

GET /posts/{postId}는 게시글 본문뿐 아니라 게시판, 카테고리, 작성자 정보와 댓글 목록을 함께 반환한다. 초기 구현에서는 findById()로 게시글만 조회한 뒤 DTO 생성 과정에서 연관 엔티티에 접근했다.

// PostService
public PostDetailResponseDto getPostById(
        Long postId,
        String email
) {
    Post post = postRepository.findById(postId)
            .orElseThrow(() ->
                    new EntityNotFoundException(
                            "존재하지 않는 게시글입니다."
                    )
            );

    // DTO 생성 과정에서 board, category, author 접근
    ...
}

board, category, author가 지연 로딩으로 설정되어 있으면 실제 접근 시점에 별도 조회가 발생한다. 당시 기록상 게시글 상세 조회는 전체 5회의 쿼리가 실행됐다.

-- Post 조회
SELECT *
FROM post
WHERE id = 1;

-- Board 지연 로딩
SELECT *
FROM boards
WHERE id = 1;

-- Category 지연 로딩
SELECT *
FROM category
WHERE id = 1;

-- 루트 댓글 조회
SELECT *
FROM comments
WHERE post_id = 1
  AND parent_id IS NULL;

-- 대댓글 일괄 조회
SELECT *
FROM comments
WHERE parent_id IN (?, ?, ?);

게시글 한 건을 조회하는 API이므로 이 사례를 목록 기반의 전형적인 N+1 문제라고 표현하기는 어렵다. 다만 상세 응답에 반드시 필요한 연관 엔티티를 개별 쿼리로 조회하고 있었기 때문에, 한 번의 조회로 통합할 수 있는 추가 비용이 발생하고 있었다.

5. EntityGraph를 이용한 연관 엔티티 동시 조회

상세 응답에 항상 필요한 board, category, author를 한 번에 조회하기 위해 Repository 메서드에 @EntityGraph를 적용했다.

// PostRepository
@EntityGraph(
    attributePaths = {
        "board",
        "category",
        "author"
    }
)
Optional<Post> findWithDetailsById(Long id);

Service에서는 기존의 findById() 대신 findWithDetailsById()를 사용하도록 변경했다.

// PostService
public PostDetailResponseDto getPostById(
        Long postId,
        String email
) {
    Post post =
            postRepository.findWithDetailsById(postId)
                    .orElseThrow(() ->
                            new EntityNotFoundException(
                                    "존재하지 않는 게시글입니다."
                            )
                    );

    ...
}

적용 후에는 Post, Board, Category, Author가 조인된 한 번의 쿼리로 조회된다. 댓글 트리 조회는 별도 조회 전략을 유지했기 때문에 전체 쿼리 수는 5회에서 3회로 줄었다.

-- Post와 상세 응답에 필요한 연관 엔티티 동시 조회
SELECT ...
FROM post p
LEFT JOIN users u
       ON u.id = p.author_id
LEFT JOIN boards b
       ON b.id = p.board_id
LEFT JOIN category c
       ON c.id = p.category_id
WHERE p.id = 1;

-- 루트 댓글 조회
SELECT *
FROM comments
WHERE post_id = 1
  AND parent_id IS NULL;

-- 대댓글 일괄 조회
SELECT *
FROM comments
WHERE parent_id IN (?, ?, ?);

댓글 조회를 별도로 유지한 이유
게시글의 다대일 연관관계와 댓글 컬렉션을 한 쿼리에서 모두 조인하면 결과 행이 중복될 수 있고, 댓글 트리 구성도 복잡해질 수 있다. 이번 작업에서는 게시글의 단건 연관 엔티티 조회만 통합하고, 루트 댓글과 대댓글 조회는 기존의 두 단계 조회를 유지했다.

6. 변경 전후 결과

API	문제	개선 방식	변경 전	변경 후
GET /boards	게시판마다 게시글 수 개별 조회	GROUP BY 일괄 집계	게시판 3개 기준 4회	2회
GET /posts/1	지연 로딩된 연관 엔티티 추가 조회	@EntityGraph 적용	5회	3회

게시판 목록은 데이터 개수에 따라 쿼리가 증가하던 구조를 제거했다는 점이 핵심이다. 게시판이 늘어나도 게시판 목록과 집계 쿼리 두 번만 실행된다.

게시글 상세 조회는 상세 응답에서 항상 사용하는 단건 연관관계를 미리 조회하도록 변경했다. 게시글과 게시판, 카테고리, 작성자를 하나의 쿼리로 가져오면서 불필요한 추가 조회를 줄였다.

최종 결과

• 게시판별 게시글 수 조회를 1 + N회에서 고정 2회로 축소했다.
• 게시글 상세 조회를 5회에서 3회로 축소했다.
• 목록 집계와 단건 연관 조회의 문제 성격을 구분해 각각 다른 방식으로 해결했다.
• 댓글 트리 조회는 별도 전략을 유지해 조인 중복과 응답 조립 복잡도를 피했다.

7. 정리 및 배운 점

이번 작업을 통해 N+1 문제는 연관관계 지연 로딩에서만 발생하는 것이 아니라, 목록을 순회하면서 Repository 메서드를 반복 호출하는 서비스 로직에서도 발생할 수 있다는 점을 확인했다.

게시판 목록에서는 각 게시판의 게시글 수를 개별 조회하는 코드가 직접적인 원인이었다. 단순히 연관관계의 fetch 전략을 변경하는 것으로는 해결할 수 없었고, 필요한 집계 결과를 GROUP BY로 한 번에 조회하는 방식이 적절했다.

반면 게시글 상세 조회에서는 응답에 필요한 연관 엔티티가 명확했기 때문에 @EntityGraph를 이용해 조회 시점에 함께 가져오는 방식이 적합했다. 모든 연관관계를 항상 즉시 로딩하도록 변경하지 않고, 특정 조회 메서드에만 로딩 전략을 적용해 사용 범위를 제한했다.

또한 쿼리 수가 많다고 해서 모든 조회를 하나의 쿼리로 합치는 것이 항상 적절한 것은 아니다. 특히 컬렉션 연관관계를 함께 조인하면 중복 행과 페이징 제약이 발생할 수 있다. 이번 작업에서는 단건 연관관계와 댓글 트리 조회를 분리해, 필요한 범위에서만 쿼리를 통합했다.

정리하면 이번 최적화는 게시판별 반복 집계를 일괄 집계로 변경하고, 상세 조회에 필요한 단건 연관관계만 선택적으로 함께 조회한 작업이었다. 쿼리 수를 줄이는 것뿐 아니라 조회 목적과 연관관계 형태에 맞는 해결 방식을 선택하는 과정이 중요했다.