오프셋 기반 페이지네이션이란?
우리가 흔히 게시판에서 보는 ‘1페이지, 2페이지’ 방식이 바로 오프셋 기반 페이지네이션입니다. SQL로 표현하면 LIMIT 10 OFFSET 20처럼, 몇 번째 데이터부터 몇 개를 가져올지 숫자로 지정하는 방식이죠.
이 방식은 구현이 직관적이고, ‘몇 페이지로 이동’같은 UI를 만들기 쉽다는 장점이 있습니다. 하지만 데이터가 많아질수록 치명적인 단점이 드러납니다. 예를 들어 OFFSET 1000000처럼 뒤쪽 페이지를 조회하면, DB는 앞의 100만 건을 일단 다 세어보고 건너뛴 뒤에야 원하는 데이터를 가져옵니다. 데이터가 많을수록 점점 느려지는 구조입니다.
또한 실시간으로 데이터가 추가/삭제되는 상황에서는 ‘중복 노출’이나 ‘데이터 누락’ 문제가 생길 수 있습니다. 예를 들어 1페이지를 보고 있는 동안 새 글이 등록되면, 2페이지로 넘어갈 때 원래 1페이지 마지막에 있던 글이 다시 보이거나, 반대로 하나가 통째로 누락되는 경우가 생깁니다.
커서 기반 페이지네이션이란?
커서 기반 방식은 ‘몇 번째’라는 숫자 대신, 마지막으로 조회한 데이터의 기준점(커서)을 저장해두고, ‘그 다음부터’ 데이터를 가져오는 방식입니다. 보통 고유하고 정렬 가능한 값(예: id, created_at)을 커서로 사용합니다.
예를 들어 도서관에서 책을 순서대로 찾을 때, 오프셋 방식은 ‘입구에서부터 20번째 책’을 세어가며 찾는 것이고, 커서 방식은 ‘방금 본 책 바로 다음 책’을 이어서 찾는 것과 비슷합니다. 후자는 앞부분을 다시 셀 필요가 없으니 훨씬 빠릅니다.
SQL로는 대략 WHERE id > 마지막으로_본_id ORDER BY id LIMIT 10 형태로 구현됩니다. id에 인덱스가 걸려 있다면, 데이터 양과 상관없이 일정한 속도로 조회가 가능합니다.
실무에서는 무엇을 선택할까
정확한 페이지 번호 이동(1,2,3페이지 클릭)이 필요한 관리자 페이지나 게시판이라면 오프셋 방식이 여전히 유용합니다. 구현이 단순하고 UX도 익숙하기 때문입니다.
반면 무한 스크롤처럼 데이터를 계속 이어서 불러오는 SNS 피드, 실시간으로 데이터가 자주 바뀌는 대용량 서비스라면 커서 기반이 훨씬 적합합니다. 트위터, 인스타그램 같은 서비스의 API가 대표적인 예시입니다.
- 오프셋 기반: 구현 간단, 페이지 번호 이동 용이, 대용량/실시간 데이터에서는 성능 저하
- 커서 기반: 대용량 데이터에서도 일정한 성능, 무한 스크롤에 적합, 특정 페이지로 바로 이동은 어려움
결국 선택 기준은 ‘데이터 규모’와 ‘사용자 경험(UX)’입니다. 서비스 특성을 고려해 두 방식 중 적절한 것을 선택하는 것이 중요합니다.