페이지네이션 관리자 기능 만들 때 실수 줄이기

페이지네이션을 구현할 때는 처음부터 정답을 맞히려고 하면 시간을 낭비한다. 먼저 어떤 데이터가 몇 개인지, 한 페이지에 몇 개씩 보여줄 건지, 전체 페이지가 몇 개인지부터 정확히 파악해야 한다.

페이지 관련 설정을 명확하게 하기

첫 페이지는 0부터인지 1부터인지, 한 페이지의 크기는 고정인지 유동적인지, 전체 데이터 개수는 얼마인지부터 정해야 한다. 이 설정이 부정확하면 마지막 페이지가 이상해지거나 데이터가 빠진다.

데이터 쿼리와 표시 로직 분리하기

페이지네이션 기능은 두 부분으로 나뉜다. 하나는 데이터베이스에서 해당 페이지의 데이터를 가져오는 부분(예: LIMIT, OFFSET), 또 하나는 UI에서 페이지 번호를 표시하는 부분이다. 한쪽에서 실수하면 다른 쪽이 정상이어도 결과가 이상하다.

# API 응답 확인
curl -s 'https://api.example.com/items?page=1&limit=10' | jq '.'

# 로컬 빌드와 UI 확인
npm run build

마지막 페이지가 정상인지 확인하기

전체 데이터가 47개인데 한 페이지에 10개씩 보여주면 5페이지가 되고, 마지막 페이지에는 7개만 있다. 이 마지막 페이지에서도 페이지네이션이 제대로 작동하는지 확인해야 한다. 버튼이 이상하게 남아 있거나, 데이터가 중복으로 보이지는 않는지 체크한다.

로컬과 운영 환경에서 데이터 개수가 다르지는 않은지

개발 중에는 테스트 데이터가 적을 수 있지만, 운영 환경에는 훨씬 많을 수 있다. 로컬에서는 페이지네이션이 필요 없어 보이지만, 운영에서는 성능 문제가 생길 수도 있다. 데이터가 많을 때의 동작을 미리 테스트하자.

페이지 번호 입력이 범위를 벗어나면

사용자가 URL을 직접 조작해서 존재하지 않는 페이지(예: 100번째 페이지)를 요청할 수도 있다. 이 경우 에러 페이지를 보여줄 건지, 빈 목록을 보여줄 건지, 첫 페이지로 리다이렉트할 건지 정해야 한다. 관리자 기능이면 더 명확한 에러 메시지가 필요하다.

정렬과 필터링과 함께 사용할 때

페이지네이션만 고치는 게 아니라 정렬이나 필터링 옵션이 들어갈 때가 많다. 예를 들어 "최신순 페이지 2"를 선택했을 때 다시 첫 페이지로 돌아가는 건 아닌지, 정렬 순서가 변해도 현재 페이지가 유지되는지 확인해야 한다.

사용자 경험까지 고려하기

관리자가 데이터를 수정할 때 그 데이터가 현재 보이는 페이지에서 사라질 수도 있다. 예를 들어 최신순 정렬에서 가장 최신 데이터를 삭제하면 페이지 구성이 바뀐다. 이런 상황에서 사용자에게 명확한 피드백을 주는 게 중요하다.