Contents

클라이언트 사이드 - 서버 사이드 페이지네이션 비교

페이지네이션을 구현하다 보면 문득 구현하는 방법에 두 가지가 있다는 것을 깨닫게 된다.

서버 사이드 페이지네이션과, 클라이언트 사이드 페이지네이션 중에서 어떤 것을 언제 사용해야 할까?

https://buildthis.com/client-side-vs-server-side-pagination/ 각 방법의 특징과 장단점을 정리해보았다.

서버 사이드 페이지네이션

말 그대로 서버가 클라이언트에게 데이터의 일부분만 리턴하는 페이지네이션 방식이다.

예를 들어, 어플리케이션에 부동산 목록을 검색하는 기능이 있다고 가정해보자.

  • 2개의 침실, 2개의 화장실이 있는 매물만 검색하고 싶다.
  • 10000개의 결과가 검색 조건과 매칭된다.
  • 이 때 서버 사이드 페이지네이션은 이 결과 중 일부분만 클라이언트에게 전달한다. 또한 전달하는 몇 가지 부가 요소들도 존재하는데,
    • 쿼리 질의와 매칭되는 결과가 전체 몇 개 있는지
    • 쿼리 질의 결과 내용 중에서 내가 현재 보고 있는 데이터는 대략 어느 정도에 위치해 있는지를 같이 리턴해줘야 한다. (그렇지 않으면 보고 있는 정보에 대한 컨텍스트를 잃는다 == 길을 잃는다)

구체적인 예시를 들자면..

서버 사이드 페이지네이션의 장점으로는,

  • 정말로 필요한 데이터만 보여준다.
  • 데이터가 추가적으로 더 필요한 경우 다시 서버에 요청해서 데이터를 가져온다.

서버 사이드 페이지네이션은 레스토랑에 가서 요리를 하나씩 주문하는 것과 같다.

  • 이 경우 요청한 하나의 음식만 나온다.
  • 하지만 다음 음식을 만드는데 시간이 걸린다. (요청을 처리하는 시간)
    • 때문에 레스토랑에 손님이 많을 경우 음식이 제 때 나오지 않을 수도 있다. (요청에 대한 지연)
    • 이 경우 레스토랑에 조금 더 큰 주방이 필요할 수도 있다. (서버 리소스 추가)

클라이언트 사이드 페이지네이션

클라이언트 사이드 페이지네이션은 쿼리 질의가 만들어지고, 데이터를 하나의 큰 덩어리로 보내는 방식의 페이지네이션이다.

클라이언트 사이트 페이지네이션은 레스토랑에 가서 먹을 음식을 한번에 주문하는 것과 같다.

  • 주방에서 주문을 받은 모든 요리를 다 조리하는데에는 당연히 하나의 요리를 준비하는 것보다 오랜 시간을 필요로 한다.
  • 하지만 테이블에 다 놓여진 이후로는 한 음식을 먹다 다른 음식을 먹기 매우 쉽다.
  • 모든 데이터를 한 번에 다 받기 때문에, 페이지네이션 자체의 속도가 빨라진다. (이미 데이터는 클라이언트에서 가지고 있기 때문이다)

어떤 페이지네이션 방식을 선택해야 할까?

어떤 방식이 좋고, 나쁜 것이 아니라 각 방식 마다 장단점이 있으므로 서비스와 서비스가 다루는 데이터의 특징을 잘 파악해서 적절한 방법을 적용하는 것이 좋다.

고려해봐야 할 사항으로는..

  1. 데이터가 얼마나 복잡한가?
    1. 데이터 간 관계가 복잡한 쿼리 질의 결과는 서버에서 처리하는 시간을 더 많이 필요로 한다.
  2. 데이터의 크기가 얼마나 큰가?
    1. 클라이언트 사이드 페이지네이션의 경우 클라이언트가 들고 있는 데이터의 크기가 늘어난다.
  3. 데이터와 어떻게 상호작용해야 하는가? 정렬이나 검색 기능이 얼마나 빈번하게 일어나는가?
    1. 데이터에 대한 검색이나 정렬과 같은 상호작용이 빈번하게 일어난다면 클라이언트가 서버에 질의해야 하는 횟수가 늘어난다는 것을 의미한다.
  • 상호작용이 많고 간단한 데이터의 경우 : 클라이언트 사이드 페이지네이션을 사용하는 것이 좋다.
  • 상호작용이 적고 복잡하거나 크기가 큰 데이터의 경우 : 서버 사이드 페이지네이션을 사용하는 것이 좋다.

또한, 클라이언트 사이트 페이지네이션의 장점으로는 구현이 좀 더 빠르고 쉽다는 점이 있다.

  • 데이터 테이블을 구현하는 수 많은 자바스크립트 라이브러리가 존재하고, 이 경우 클라이언트 사이드 페이지네이션은 라이브러리의 힘을 빌려 데이터의 한 덩어리에서 빠르고 유연하게 동작할 수 있다.

하지만 어플리케이션의 크기가 커지고 시스템이 복잡해진다면,, 서버 사이드 페이지네이션을 고려해봐야 한다.

  • 서버 사이드 페이지네이션은 구현하기 좀 더 어렵지만 (페이징 API를 따로 개발해야 하므로) 스케일이 쉽기 때문에 빠르게 성장하는 비즈니스와 어플리케이션에서 적합하다.

초창기에는 : 클라이언트 사이드 페이지네이션 사용

서비스 성장 시 : 서버 사이드 페이지네이션으로 유연한 전환 고려