[Spring Data JPA] Pageable, Page, Slice 뜯어보기 (JPA에서 Page를 생성하는 내부 동작)

🧐 들어가기전

페이스북, 인스타그램, 네이버 카페 등 우리가 자주 사용하는 서비스들에는 공통점이 하나 있다. 바로 모든 데이터를 한 번에 보여주지 않고 필요한 만큼만 잘라서 보여준다는 점이다. 사용자는 현재 보고 있는 데이터를 기준으로 "다음", "이전", 또는 "특정 페이지"를 요청하고 시스템은 이에 맞는 데이터 일부만을 응답한다.

 

이는 단순히 UX의 문제만은 아니다. 수천, 수만, 수백만 건에 달하는 데이터를 한 번에 응답하는 일은 서버에 큰 부하를 주고 성능 저하나 장애로 이어질 수 있다. 따라서 위 사진처럼 N개의 데이터만 보여주고, 사용자의 요청에 따라 다음 혹은 이전 순번의 N개의 데이터를 볼 수 있게 구현하는 것을 통해 이러한 점을 보완할 수 있다.

 

하지만, 위와 같은 기능을 구현하기 위해서는 데이터베이스 종류에 따라 서로 다른 문법을 사용해야 한다는 번거로움이 있다.

SELECT * FROM posts LIMIT 10 OFFSET 20;

예를 들어, MySQL은 위와 같이 LIMIT과 OFFSET을 활용하여 위와 같이 작성한다.

SELECT * FROM (
  SELECT a.*, ROWNUM rnum FROM (
    SELECT * FROM posts
  ) a WHERE ROWNUM <= 30
) WHERE rnum > 20;

반면 ORACLE은 ROWNUM을 활용하여 복잡한 서브쿼리를 구현해야 한다.

 

이처럼 DBMS마다 서로 다른 방식으로 페이지구현을 처리해야 하기 때문에, 개발자는 매번 데이터베이스 특성을 고려해 코드를 작성해야 하고, 유지보수도 복잡해진다.

List<Item> items = entityManager.createQuery("select i from Item i", Item.class)
                    .setFirstResult(0)
                    .setMaxResults(10)
                    .getResultList();

그래서 Spring에서는 이러한 번거로움을 없애기 위해 Pageable, Page 등의 기능을 통해 페이지네이션을 추상화하여 제공한다. JPA를 사용하면 복잡한 SQL 없이도 손쉽게 페이지네이션을 구현할 수 있으며, 어떤 데이터베이스를 사용하더라도 일관된 방식으로 데이터를 나눠서 조회할 수 있다.

---

🔸Pageable

Spring Data JPA에서는 페이지네이션 기능을 손쉽게 구현할 수 있도록 Pageable이라는 인터페이스를 제공한다.

이 Pageable을 통해 우리는 몇 번째 페이지를 조회할 것인지, 한 페이지에 몇 개의 데이터를 담을 것인지 등의 정보를 손쉽게 전달할 수 있다.

 

하지만 그 내부를 조금 더 들여다보면, 이 Pageable은 단순한 인터페이스가 아니라 구체 클래스를 통해 구현되고 있는 추상 구조를 가지고 있다.

 

위의 그림은 Pageable 인터페이스를 구현하는 계층 구조를 보여준다:

• Pageable: 페이지 요청 정보를 정의하는 인터페이스
• AbstractPageRequest: Pagable을 부분적으로 구현한 추상 클래스
• PageRequest: 구체 구현체

이러한 구조를 가지고 있기 때문에 개발자는 구체 구현체인 PageRequest 객체를 통해 쉽게 Pagable을 생성할 수 있다.

---

1️⃣ PageRequest

PageRequest는 Spring Data JPA에서 페이징 처리에 필요한 정보를 담는 불변 객체

페이지네이션 요청을 만들기 위해 사용하는 대표적인 구현 클래스 PageRequest의 구조에 대해 살펴보고자 한다.

 

🔹주요 생성자 & 정적 팩토리 메서드

public class PageRequest extends AbstractPageRequest {
    private static final long serialVersionUID = -4541509938956089562L;
    private final Sort sort;

    protected PageRequest(int pageNumber, int pageSize, Sort sort) {
        super(pageNumber, pageSize);
        Assert.notNull(sort, "Sort must not be null");
        this.sort = sort;
    }

    public static PageRequest of(int pageNumber, int pageSize) {
        return of(pageNumber, pageSize, Sort.unsorted());
    }

    public static PageRequest of(int pageNumber, int pageSize, Sort sort) {
        return new PageRequest(pageNumber, pageSize, sort);
    }

    public static PageRequest of(int pageNumber, int pageSize, Sort.Direction direction, String... properties) {
        return of(pageNumber, pageSize, Sort.by(direction, properties));
    }
    
    ...
    
}

우선 PageRequest는 필드값으로 Sort 객체를 가진다.

 

기본 생성자는 pageNumber, pageSize, sort를 인자값으로 받고 pageNumber와 pageSize는 부모 객체의 필드에 정의해 준다.

 

기본 생성자를 protected로 정의함으로써 외부에서는 직접 생성할 수 없고 정적 메서드를 통해서만 생성할 수 있다

이때, 정팩메의 종류는 다음과 같다.

Pagable 관련 정적팩토리 메서드들은 페이징 할 데이터의 개수뿐만 아니라, 페이징 정렬 조건(Sort)까지 함께 지정할 수 있다.

 

1.pageNubmer + pageSize

PageRequest request = PageRequest.of(0, 10)

pageNumber와 size로 PageRequest객체를 생성할 수 있다.

 

Pageable 인터페이스의 ofSize() 메서드를 통해서도 Pageable 객체를 생성할 수 있다.

하지만 이때 주의해야 할 점은  pageSize만 인자값으로 전달받기에 default pageNumber index가 0으로 설정되어 있음을 확인할 수 있다.

2. page Number + pageSize + sort

Sort sort = Sort.by("createdAt");
PageRequest request = PageRequest.of(0, 10, sort);

PageRequest request = PageRequest.of(0, 10, Sort.by(Direction.DESC, "createdAt"));

Sort.by()에 엔티티 필드명을 정의함으로써 정렬을 수행할 수 있다.

 

3. pageNumber + pageSize + direction + properties

PageRequest request = PageRequest.of(0, 10, Sort.Direction.DESC, "createdAt");

Sort객체를 직접 정의하지 않아도 필드명을 인자값으로 넘겨줌으로써 정렬을 수행할 수 있다.

 

🔹페이징 관련 메서드

public PageRequest next()     // 다음 페이지 요청 객체 생성
public PageRequest previous() // 이전 페이지 요청 객체 생성 (0이면 그대로)
public PageRequest first()    // 첫 페이지 요청 객체 생성
public PageRequest withPage(int pageNumber) // 원하는 페이지로 이동

 

🔹정렬 정보 변경

public PageRequest withSort(Sort.Direction direction, String... properties)
public PageRequest withSort(Sort sort)

 

위와 같은 메서드들은 새로운 PageRequest 객체를 생성해서 return 해준다.

=> PageRequest는 불변객체이기 때문!

---

2️⃣AbstractPageRequest

AbstractPageRequest.class

앞서 본 PageRequest의 기본생성자에서 super로 넘겨주는 pageNumber와 pageSize가 AbstractPageRequest의 필드로 정의되어 있음을 확인할 수 있다.

 

AbstractPageRequest.class

또한, 앞에서 본 PageRequest의 페이징 관련 메서드들은 AbstractPageRequest의 메서드를 오버라이드한 것을 확인할 수 있고 return type이 Pageable 인터페이스로 감싸져 있다는 것을 확인할 수 있다!

---

🔸Page & Slice

앞서 살펴본 Pageable은 페이징 요청 정보를 담는 인터페이스다.
하지만 이는 어디까지나 요청자 입장에서의 입력 값일 뿐, 개발자가 궁극적으로 수행해야 하는 부분은 요청에 맞는 데이터를 페이지 단위로 감싸서 전달해 주는 것이다.

 

페이징을 진행할 데이터의 원본은 데이터베이스에 있다.

따라서 JPA는 Pageable 정보를 기반으로 DB에 적절한 쿼리를 날리고, 그 결과를 다시 특정 객체로 감싸서 반환해줘야 한다.

이때 요청 결과를 담아주는 객체가 바로 Page와 Slice다.
해당 객체들은 데이터 리스트뿐만 아니라, 다음 페이지가 있는지, 전체 페이지 수는 몇 개인지 등 페이징에 필요한 메타 정보를 함께 제공해 준다.

 

 

Page와 Slice의 객체의 내부구조를 살펴보면서 차이점을 알아보고 그에 따른 사용하기에 적절한 상황에 대한 인사이트까지 도출해 볼 예정이다.

---

1️⃣ 객체들 간의 상속관계

객체들간의 상속관계를 살펴보면 위와 같은 구조임을 확인할 수 있다.

🔹1. Slice

"다음 페이지가 있는지"만 알려주는 가벼운 페이징 결과 객체

 

 

🔹2. Page

Slice의 모든 기능 + 전체 페이지 수, 총 데이터 개수까지 제공

🔹3. Chunk

Slice의 공통 구현을 담당하는 추상 클래스

🔹4. SliceImpl

Slice<T>를 구현한 실제 클래스

🔹5.PageImpl

Page<T>를 실제로 구현한 대표 클래스

🔹6. GeoPage

지리 기반 검색 결과를 담는 PageImpl<GeoResult<T>>의 확장 클래스.
Page기능 + 각 결과의 거리 정보 + 평균거리

 

각각의 클래스와 내부동작에 대해서는 Page와 Slice를 중심으로 설명하고자 한다.

---

2️⃣ Page

Page 객체는 PageImpl 구현 클래스를 통해 객체를 생성하고 동작을 수행한다.

spring-data-commons/src/main/java/org/springframework/data/domain/PageImpl.java at main · spring-projects/spring-data-commons

PageImpleClass

위와 같이 PageImpl의 생성자를 살펴보면 두 가지 방식으로 Page를 생성할 수 있음을 확인할 수 있다.

(content와 pagable은 Chunk 객체에서 관리한다.)

 

🔹생성자 1. List<T>content + pageable + total

// 현재 페이지의 데이터
List<String> content = Arrays.asList("item1", "item2", "item3");

// Pageable 정보 (0번 페이지, 3개씩 조회)
Pageable pageable = PageRequest.of(0, 3);

// 전체 데이터 개수가 100개라고 가정
long total = 100

// Page 생성
Page<String> page = new PageImple<>(content, pageable, total);

전체 페이징 정보를 직접 전달하는 가장 일반적이고 대표적인 생성자이다.

• content: 현재 페이지에 해당하는 데이터 목록
• pageable: 요청 정보
• total: 전체 데이터 개수

전체 데이터 개수를 알아야 하기 때문에, Spring Data JPA는 내부적으로 count(*) 쿼리를 별도로 실행하여 전체 데이터 수를 조회한다. => "Select 쿼리가 나간다"

 

🔹생성자 2. List<T>content

List<String> content = userRepository.findAll() // 전체 데이터
Page<User> page = new PageImpl<>(content);      // 전체를 Page로 감싸기

페이지 정보 없이, 단순히 리스트만 주어진 경우에 사용하는 간단한 생성자이다.
내부적으로 Pageable.unpaged()를 사용하고, 총 개수는 content.size()로 대체한다.

 

🔹메서드

또한 PageImpl에서는 위와 같이 hasNext(), isLast(), map() 메서드에 대해 제공해 준다.

(getTotalPages()와 getTotalElements()는 Page 메서드를 override 한 메서드이다.)

getTotalPages()와 getTotalElements() 메서드는 Slice와 달리 Page 객체만 가지고 있는 메서드이다.

• hasNext(): 다음 페이지가 있는지에 대한 여부
• isLast(): 현재 페이지가 마지막인지에 대한 여부

---

3️⃣ Slice

Slice객체는 SliceImpl 구현 클래스를 통해 객체를 생성하고 동작을 수행한다.

spring-data-commons/src/main/java/org/springframework/data/domain/SliceImpl.java at main · spring-projects/spring-data-commons

SliceImplClass

SliceImpl 클래스도 마찬가지로 두 가지의 생성자를 제공해 준다.

 

🔹생성자 1. List<T>content + pageable + hasNext

 // 현재 페이지의 데이터
List<String> content = Arrays.asList("item1", "item2", "item3");

// Pageable 정보 (0번 페이지, 3개씩 조회)
Pageable pageable = PageRequest.of(0, 3);

// 다음 페이지가 있다고 가정
boolean hasNext = true;

// SliceImpl 생성
Slice<String> slice = new SliceImpl<>(content, pageable, hasNext);

슬라이스 페이징 결과를 생성할 수 있게 해주는 주요 생성자이다.

• content: 현재 페이지에 해당하는 데이터 목록
• pageable: 요청 정보
• hasNext: 다음 페이지의 여부

🚨 Page객체와의 차이점

Page 객체와는 달리, Slice는 total이 아닌 hasNext 값을 인자로 받는다.
즉, 전체 데이터 개수를 알기 위한 별도의 COUNT(*) 조회 쿼리가 필요하지 않다.

따라서 전체 페이지 수를 알 필요가 없는 무한 스크롤과 같은 경우, 불필요한 쿼리 부담을 줄일 수 있어 Slice를 사용하는 것이 적합하다.

 

🧐 전체페이지를 조회하지 않는데 어떻게 hasNext()를 판별할 수 있는가?

정말 재미있는 부분이었다.

Slice는 별도의 COUNT(*) 조회 쿼리를 실행하지 않아서 전체 페이지 개수를 알 수 없다.

그러면 PageRequest값을 받았을 때 어떻게 현재 페이지가 마지막 페이지인지 알 수 있을까?

PageRequest pageRequest = PageRequest.of(0, 10); // 0페이지 10개씩
Slice<User> users = userRepository.findBySomething(..., pageRequest);

위와 같이 Slice 객체를 반환받고자 할 때 나가는 쿼리를 확인해보자.

select 
    user0_.id as id1_0_, 
    user0_.name as name2_0_, 
    user0_.age as age3_0_ 
from 
    user user0_ 
where 
    user0_.age > ? 
order by 
    user0_.id asc 
limit ? offset ?

Hibernate log 상으로는 위와 같이 나가게 된다.

이때 중요한 부분은 ?에 들어가는 값이다. 이를 알아보기 위해서는 p6spy 라이브러리를 통해서 살펴보자.

SELECT 
  user0_.id, 
  user0_.name, 
  user0_.age 
FROM 
  user user0_ 
WHERE 
  user0_.age > 20 
LIMIT 11 OFFSET 0;

이렇게 로고가 찍히는 것을 살펴보면 특이한 점을 확인할 수 있다.

앞서 본 PageRequest에서는 페이지 사이즈를 10으로 조회하였는데 로고에서는 10 + 1인 11로 찍혀있다.

기존에 조회하고자 하는 사이즈보다 한 개를 더 가져오는 원리는 무엇일까?

만약 10개씩 데이터를 가져온다면 전체 개수를 조회하는 게 아닌 이상 다음의 페이지 여부에 대해서는 알기 힘들 것이다.

그러나 만약 기존의 페이지 사이즈보다 한 개를 더해서 불러온다면 다음 페이지에 데이터가 있는지에 대한 여부를 확인할 수 있다는 점이다. 따라서 JPA에서는 이 점을 이용하여 쿼리를 보낼 때 PageRequest가 요구하는 페이지 사이즈에 +1을 하여 쿼리를 조회하고, 다음 페이지의 여부를 확인한다.

 

🔹생성자 2. List<T>content

List<String> content = userRepository.findAll() // 전체 데이터
Slice<User> slice = new SliceImpl<>(content);   // 전체를 Slice로 감싸기

PageImpl의 두 번째 생성자와 마찬가지로 간단한 용도의 생성자로, pageable이 필요 없는 경우에 사용한다.

this(content, Pageable.unpaged(), false);

이때, 내부 동작은 hasNext를 false로 사용한다. 

 

🔹Slice 메서드

int getNumber(); // 현재 페이지 번호 (0부터 시작)
int getSize(); // 한 페이지당 데이터 개수
int getNumberOfElements(); // 현재 페이지에 포함된 실제 데이터 수
List<T> getContent(); // 현재 페이지의 데이터 목록
boolean hasContent(); // 데이터가 존재하는지 여부
Sort getSort(); // 정렬 정보 반환
boolean isFirst(); // 첫 페이지인지 여부
boolean isLast(); // 마지막 페이지인지 여부
boolean hasNext(); // 다음 페이지가 있는지 여부
boolean hasPrevious(); // 이전 페이지가 있는지 여부
Pageable getPageable(); // 현재 페이지의 Pageable 정보
Pageable nextPageable(); // 다음 페이지의 Pageable 정보
Pageable previousPageable(); // 이전 페이지의 Pageable 정보
<U> Slice<U> map(Function<? super T, ? extends U> converter); // content를 변환해 새로운 Slice 생성
Pageable nextOrLastPageable(); // 다음 페이지 있으면 next, 없으면 현재 Pageable 반환
Pageable previousOrFirstPageable(); // 이전 페이지 있으면 previous, 없으면 현재 Pageable 반환

SliceImpl에서는 별도로 구현된 메서드는 없으며, Slice 인터페이스에서 정의된 메서드들을 Chunk 추상 클래스가 공통으로 구현하고 있다.

따라서 앞서 살펴본 getContent(), hasNext(), isFirst()와 같은 메서드들은 Slice뿐만 아니라 Page 객체에서도 동일하게 사용할 수 있다. 이는 PageImpl 역시 Chunk를 상속하고 있기 때문에 가능한 구조다.

 

단 차이점이 있다면 PageImpl에서는 전체 데이터 개수에 대한 정보를 추가로 포함하고 있으며,
이에 따라 getTotalElements(), getTotalPages()와 같은 메서드도 함께 제공한다.

---

🔸JPA에서는 어떻게 Page객체를 반환할 수 있을까?

YourRepository → SimpleJpaRepository → JpaQueryExecution → PageExecution → PageImpl

JPA에서 페이징 요청을 담은 PageRequest를 인자값으로 받아 Page 객체로 return 하는 내부적인 동작의 흐름은 위와 같다.

1️⃣ YourRepository

interface PostRepository : JpaRepository<User, Long> {
    fun findByNameContaining(keyword: String, pageable: Pageable): Page<User>
}

위와 같이 Page 객체를 반환받기 위해서 개발자들은 Repository에 위와 같은 메서드를 정의한다.

위에서 학습한 바로는 pageable의 객체를 통해 Page 객체를 생성하기 위해서는 PageImpl의 생성자를 통해 생성되어야 한다.

따라서 JPA에서는 return의 형식이 Page인 경우, 위와 같은 시그니처가 호출되는 경우 그에 맞는 SimpleJpaRepository를 구현체를 사용한다.

 

2️⃣ SimpleJpaRepository

SimpleJpaRepository (Spring Data JPA Parent 3.4.4 API)

SimpleJpaRepository 공식문서

SimpleJpaRepository 공식문서를 살펴보면 findAll함수에 spec과 pageable을 인자로 하는 함수가 존재한다.

그리고 해당 함수는 Page를 return 한다. 따라서 위에서 정의한 레포지토리 메서드 findByNameContaining는 

findAll(Specification<T> spec, Pageable pageable)

해당 함수를 내부적으로 호출하는 것이다.

findAll의 시그니처

그렇다면 내부 코드 구조는 어떠한 형식일까?

spring-data-jpa/spring-data-jpa/src/main/java/org/springframework/data/jpa/repository/support/SimpleJpaRepository.java at main

SimpleJpaRepository.class

내부적으로는 위와 같은 구조를 띄고 있었다.

TypedQuery<T> query = getQuery(spec, pageable);

spec과 pageable 정보를 기반으로 데이터 조회용 JPQL 쿼리를 만든다.

 

return pageable.isUnpaged()
    ? new PageImpl<>(query.getResultList())
    : readPage(query, getDomainClass(), pageable, countSpec);

pageable.isUnpaged()인 경우

즉, 페이징 정보가 없는 경우 그냥 List<T>만 조회해서 new PageImpl<>(...)로 감싼다

 

pageable이 유효한 경우 즉, 실제 페이지를 요청하는 경우에는 다음의 로직을 따른다.

1. 쿼리 실행 (query.getResultList())
2. countSpec를 기반으로 카운트 쿼리 실행
3. 결과를 PageImpl<T>로 반환

🧐spec vs countSpec?
조회용 spec과 count용 spec을 따로 분리해서 최적화된 쿼리를 날릴 수 있도록 함

 

=> SimpleJpaRepository에서 실제 쿼리 실행 + 카운트 쿼리 실행 + PageImpl 생성까지 이뤄진다.

 

3️⃣ JpaQueryExecution → PageExecution → PageImpl

실제 리포지토리 메서드가 실행될 때는 쿼리 실행 전략을 선택해서 실행하는 구조이다.

spring-data-jpa/spring-data-jpa/src/main/java/org/springframework/data/jpa/repository/query/JpaQueryExecution.java at main · sp

JpaQueryExecution.class

static class PagedExecution extends JpaQueryExecution

Repository 메서드의 리턴 타입이 Page<T>일 경우, Spring Data JPA가 이 전략을 선택해서 실행한다.

 

protected Object doExecute(AbstractJpaQuery repositoryQuery, JpaParametersParameterAccessor accessor) {

			Query query = repositoryQuery.createQuery(accessor);

			return PageableExecutionUtils.getPage(query.getResultList(), accessor.getPageable(),
					() -> count(repositoryQuery, accessor));
		}

우선 JPQL 또는 NativeQuery로  실제 데이터를 가져올 쿼리를 생성한다.

 

그러고 나서 getResultList()로 데이터를 먼저 조회한 뒤, 카운트 쿼리를 실행할지 말지를 판단해서 최종적으로 PageImpl을 만들어주는 도우미 클래스 사용한다.

private long count(AbstractJpaQuery repositoryQuery, JpaParametersParameterAccessor accessor) {
        List<?> totals = repositoryQuery.createCountQuery(accessor).getResultList();
        return totals.size() == 1 ? (Long)JpaQueryExecution.CONVERSION_SERVICE.convert(totals.get(0), Long.class) : (long)totals.size();
}

또한 이때 PageableExecutionUtils.getPage()의 메서드를 호출할 때 count()에 대한 메서드를 호출하는 것을 살펴볼 수 있는데,

이때, repositoryQuery.createCountQuery(...)로 카운트 쿼리를 생성 후 실행하는 것이다!

 

spring-data-commons/src/main/java/org/springframework/data/support/PageableExecutionUtils.java at main · spring-projects/spring

PageableExecutionUtils.java

이때, 위에서 호출하는 getPage의 메서드를 들어가보면 최종적으로 content, pageable, totalCount값을 인자로 받아 PageImpl 객체를 생성하는 것을 확인할 수 있다.

 

JPA에서 Pageable의 인자를 가지고 Page 객체를 어떻게 생성하는지에 대한 의문이 풀리는 순간이다..!

 

이렇게 하여 최종적으로 JPA에서 PageImpl 객체를 Page 객체로 감싸서 반환하는 것이다!

---

🔸JPA에서 제공해주는 반환 타입

Page<User> findByLastname(String lastname, Pageable pageable);

Slice<User> findByLastname(String lastname, Pageable pageable);

List<User> findByLastname(String lastname, Sort sort);

List<User> findByLastname(String lastname, Sort sort, Limit limit);

List<User> findByLastname(String lastname, Pageable pageable);

Jpa에서는 Pagable을 인자로 받는 경우에 Page 객체가 아니어도 Slice 형태는 당연하고,

List의 형태로도 객체를 반환할 수 있다.

 

이는 JPA가 내부적으로 LIMIT, OFFSET, ORDER BY 등을 자동으로 붙여주는 방식 덕분에 가능한 유연성이다.

 

🧐 그렇다면 어떤 상황에서 어떤 타입을 쓰는 게 좋을까?

반환타입	설명	적합한 상황
Page<T>	전체 개수(count(*))와 전체 페이지 수를 함께 제공	페이지 번호와 전체 페이지 수 표시가 필요한 페이징 (예: 게시판)
Slice<T>	다음 페이지 유무만 판단 (count(*)는 실행하지 않음)	무한 스크롤, 성능이 중요한 경우 (ex. 모바일 피드)
List<T>	단순히 정렬된 결과나 일부 데이터만 필요	페이징/전체 개수 불필요한 단순 리스트 조회 (예: 드롭다운 옵션)

 

🚨대용량 쿼리일 때 주의

하지만 공식문서에 따르면 대용량 쿼리 요청인 경우에는 각각의 방식에 따라 주의해야 할 점이 존재한다.

https://docs.spring.io/spring-data/jpa/reference/repositories/query-methods-details.html#repositories.special-parameters

주의 사항만 정리하자면 다음과 같다.

• List<T>: 데이터가 많을수록 메모리 소진 위험과 전체로딩에 시간이 오래걸릴 수 있다.
• Slice<T>: 오프셋이 큰 경우 DB 성능 저하 가능
• Page<T>: COUNT 쿼리 비용이 클 수 있음

따라서 상황에 맞는 객체로 JPA에서 반환받는 것이 중요해 보인다!

---

📙 Ref.

https://github.com/spring-projects/spring-data-commons/blob/main/src/main/java/org/springframework/data/domain/PageImpl.java

https://docs.spring.io/spring-data/jpa/reference/repositories/query-methods-details.html#repositories.special-parameters

https://hudi.blog/spring-data-jpa-pagination/#Pageable%EA%B3%BC-PageRequest