TIL 24: 무한 스크롤을 위한 페이징 API 설계

TL;DR

• 무한 스크롤은 페이지 번호를 이용한 고전적인 페이징 기법과 달리 무한하게 스크롤을 내리는 UX에 적합하다.
• 무한 스크롤 페이징 API 설계 시, 정렬 조건을 함께 서버에 전달해야 한다.
• 누락되는 항목까지 고려한다면, 더 복잡해질 수 있다.

무한 스크롤(Infinite scroll)이란?

일반적으로 웹사이트의 게시판에서 쉽게 접할 수 있는 페이징 기법은 “1, 2, 3, …“과 같이 목록의 하단에 페이지 번호가 있고 한 페이지에 특정 갯수가 목록에 보여지는 방식일 것이다.

이와 달리 무한 스크롤(Infinite scroll)이라 불리는 페이징 기법은 페이지 번호가 따로 없고, 아래로 스크롤하다가 끝에 도달하면 다음 페이지의 목록을 현재 목록에 추가하여 목록을 연장하는 방식이다. 그래서 마치 무한하게 스크롤을 내릴 수 있다하여 무한 스크롤이라 불린다.

페이지 번호를 사용하는 페이징 기법을 사용할 지, 무한 스크롤을 사용할 지는 기획에 따라 다르며, 컨텐츠의 종류에 따라 적절한 UX를 선택해야 한다.

사내 페이징 API의 문제점

이번에 신규 모바일 프로젝트를 진행하며, 대량의 목록을 조회할 수도 있는 화면에서 페이징 기법을 사용할 필요가 있었다. 기존의 웹 솔루션을 앱으로 만드는 것이라 서버 팀에서는 웹 API를 그대로 활용하여 모바일 API로 전달해주었으나, 여러가지 문제가 많아 수정을 계속 요청하는 상태였다.

기존 웹 솔루션에서는 게시판처럼 고전적인 페이징 기법을 사용하고 있었고, 모바일 프로젝트의 화면에서는 무한 스크롤을 기획으로 요구했기 때문에 해당 API를 그대로 사용할 수 없었다. 더군다나 서버 팀의 일정이 바쁜 탓에 설계를 할 시간이 없었고, 가장 적절한 무한 스크롤 기법을 찾기 위해 리서치를 진행했다.

무한 스크롤 페이징 API 설계 시, 정렬 조건에 유의하자

리서치된 내용을 조합하여 최선을 찾으려 노력했으며, 페이징 API 호출 시 어떤 정보를 서버에 넘길 지가 관건이었다.

일반적으로는 생성된 날짜를 기준으로 정렬하기 때문에 기준이 되는 항목의 생성된 날짜를 넘기는 식으로 구현이 가능하지만, 해당 프로젝트에는 정렬 기준이 다소 달랐기 때문에 다르게 적용할 필요가 있었다.

해당 프로젝트의 정렬 기준은 화면마다 다를 수 있어 넘겨야 하는 정보가 그때그때 달랐으며, 페이징 도중에도 언제든지 다음 페이지 항목의 순서가 (데이터로써) 상단으로 땡겨질 수 있기 때문에 누락되는 항목까지 고려해야 할 필요가 있었다.

결국 어찌저찌 설계를 완료해 서버 팀에 넘겼으나 제대로 적용될 지는 두고 봐야 한다. 예전에는 단순히 주어진 대로 누락될 수 있는 가능성을 무시하고 고전적인 페이징 기법을 사용해 개발했지만, 이번에는 제대로 개발하고자 시도를 해보았다. 추후 좀 더 다듬어 Best Practice가 되도록 만들어야겠다. 👨🏻‍🔧