[프로젝트] 페이지네이션 방식 선택 과정

PROJECT

페이지네이션 방식 선택 과정

목차

• 1. 배경
• 2. 방식 비교
  • - 오프셋 기반 페이지네이션
  • - 커서 기반 페이지네이션
• 3. 결정
• 4. Page vs Slice 선택 과정

1. 배경

페이지네이션이란?

페이지네이션(Page Pagination)은 많은 데이터를 한 번에 조회하지 않고, 일정 개수씩 나누어 조회하는 방식이다. 데이터 양이 많아질수록 한 번에 모든 데이터를 가져오는 것은 성능 저하로 이어질 수 있기 때문에, 사용자에게는 필요한 만큼만 데이터를 보여주고 서버 부하를 줄이기 위해 사용된다.

예시

 

게시물, 메모, 추천 도서 목록이 전체 조회 방식으로 구현되어 있었다. 초기 데이터가 적을 때는 문제가 없지만, 데이터가 계속 쌓이면 한 번에 많은 데이터를 조회하게 되어 응답 속도와 서버 부하 측면에서 문제가 생길 수 있다.

그래서 목록 조회 API에 페이지네이션을 도입하기로 했고, 그 과정에서 오프셋 기반 페이지네이션과 커서 기반 페이지네이션 중 어떤 방식을 사용할지 비교했다.

핵심 기준은 현재 서비스 규모, 구현 복잡도, UI 방식이었다. Booktine은 독서 기록 목록을 페이지 단위로 보여주는 구조가 더 자연스럽다고 판단했다.

2. 방식 비교

오프셋 기반 페이지네이션

오프셋 기반 페이지네이션은 Spring Data의 Pageable을 활용하는 방식이다. 데이터베이스에서는 LIMIT과 OFFSET을 사용해 특정 페이지의 데이터를 조회한다.

PostRepository.java/PostService.java

Page<Post>를 반환 타입으로 지정하면 Spring Data JPA가 자동으로 count 쿼리를 함께 실행해 전체 페이지 수를 계산한다. Pageable은 컨트롤러에서 전달받은 page, size 값을 담는 객체다.
Repository에서 반환된 Page<Post>를 map()으로 DTO로 변환한다. 엔티티가 외부로 노출되지 않도록 PostResponse::from 정적 팩토리 메서드를 사용했다.

 

PostController.java

page와 size에 기본값을 설정해 파라미터 없이 요청해도 동작하도록 했다. page=0은 첫 번째 페이지, size=10은 한 페이지에 10개를 의미한다.

 

장점	단점
Spring Data에서 기본 지원하므로 구현이 단순하다.	페이지가 뒤로 갈수록 OFFSET N만큼 건너뛰는 비용이 커진다.
페이지 번호를 기준으로 원하는 페이지에 바로 접근할 수 있다.	데이터 추가 또는 삭제가 발생하면 중복이나 누락이 생길 수 있다.
전체 페이지 수와 전체 데이터 개수를 제공할 수 있다.	대규모 데이터에서는 성능 저하가 발생할 수 있다.

 

커서 기반 페이지네이션

커서 기반 페이지네이션은 마지막으로 조회한 항목의 식별자를 커서로 삼아, 그 이후 또는 이전 데이터를 조회하는 방식이다.

// Repository
List<Post> findByUserIdAndIdLessThanOrderByIdDesc(Long userId, Long cursor, Pageable pageable);

// Service
public List<PostResponse> getPosts(Long userId, Long cursor, int size) {
    Pageable pageable = PageRequest.of(0, size);
    return postRepository.findByUserIdAndIdLessThanOrderByIdDesc(userId, cursor, pageable)
            .stream().map(PostResponse::from).toList();
}​

커서 기반 페이지네이션 구현 예시

장점	단점
일정한 성능 유지	직접 구현 필요, 복잡도 높음
중복/누락 없음	전체 페이지 수 제공 어려움
무한 스크롤에 적합	임의 페이지 접근 불가

3. 결정

Booktine에서는 오프셋 기반 페이지네이션을 선택했다.

현재 서비스 규모에서는 오프셋 기반의 성능 문제보다, Spring Data의 Pageable을 그대로 사용할 수 있는 구현 단순성이 더 큰 장점이라고 판단했다.

 

PageRequest 기본값 설정 이유

PageRequest.of(page, size)의 기본값을 page=0, size=10으로 설정했다. 첫 페이지부터 10개씩 노출하는 방식이 독서 기록 목록 UI에 적합하다고 판단했기 때문이다.

 

Page<T> 응답 구조

{
  "content": [
    {
      "id": 1,
      "title": "독서 기록 제목",
      "content": "독서 메모 내용"
    }
  ],
  "totalPages": 3,
  "totalElements": 25,
  "number": 0,
  "size": 10
}

4. Page vs Slice 선택 과정

// Slice<T> — count 쿼리 없음, 다음 페이지 존재 여부만 반환 (무한 스크롤)
Slice<Post> findAllByUserId(Long userId, Pageable pageable);

// Page<T> — count 쿼리 발생, 전체 페이지 수/현재 페이지 정보 반환 (페이지 번호 UI)
Page<Post> findAllByUserId(Long userId, Pageable pageable);

두 방식의 차이는 count 쿼리 유무다. Slice<T>는 다음 페이지 존재 여부(hasNext())만 반환하고, Page<T>는 전체 페이지 수와 전체 데이터 개수까지 반환한다.

Slice<T>는 count 쿼리가 없어서 성능상 유리하지만, 무한 스크롤 UI에 적합한 방식이다.

반면 이 프로젝트는 페이지 번호 기반 UI가 더 적합하다고 판단해 전체 페이지 정보를 제공하는 Page<T>를 선택했다.