페이지네이션(Pagination)은 상품 목록, 검색 결과, 게시판 글처럼 항목이 많은 콘텐츠를 한 화면에 다 싣지 않고 여러 페이지로 나눠 번호나 이전, 다음 버튼으로 이동하게 하는 방식이다. 한국어로는 페이징, 페이지 매기기라고도 한다.
원래는 문서를 전자 페이지나 인쇄 페이지로 나누는 편집 작업을 가리키는 말이었다 (위키백과, 페이지 매기기). 이 문서는 웹과 API의 페이지네이션을 다루고, 책이나 편집 디자인의 페이지 매기기는 다루지 않는다.
웹에서 페이지네이션은 세 층에서 동시에 일어난다. 서버가 데이터를 어떻게 잘라 주는가(구현 방식), 화면에 무엇을 보여주는가(UI), 검색엔진이 그 페이지들을 어떻게 크롤링하고 색인하는가(SEO)다.
서버가 데이터를 잘라 주는 방식은 오프셋 기반과 커서 기반 둘로 나뉜다. 오프셋은 “앞에서 N개를 건너뛰고 M개를 달라”이고, 커서는 “마지막에 본 항목 다음부터 M개를 달라”다.
| 구분 | 오프셋(Offset) 방식 | 커서(Cursor) 방식 |
|---|---|---|
| 요청 형태 | page=3, LIMIT 20 OFFSET 40 | after=마지막 항목 ID, LIMIT 20 |
| 페이지 번호로 바로 이동 | 가능 | 어려움 |
| 데이터가 추가, 삭제될 때 | 항목이 중복되거나 빠질 수 있음 | 마지막 위치 기준이라 안정적 |
| 뒷페이지 성능 | 건너뛴 행까지 읽어 느려짐 | 인덱스로 바로 찾아 일정 |
| 어울리는 곳 | 게시판, 관리자 화면, 검색 결과 | 타임라인, 무한 스크롤, 대용량 API |
오프셋이 느린 이유는 데이터베이스가 건너뛸 행까지 정렬하고 읽은 뒤 버리기 때문이다. 페이지 사이에 새 행이 끼어들면 다음 페이지에 이미 본 항목이 다시 나오는 중복도 생긴다 (Markus Winand, Use The Index, Luke: No Offset).
슬랙은 API 페이지네이션을 오프셋에서 커서로 바꾸면서 같은 문제를 들었다. 오프셋은 offset+count만큼의 행을 디스크에서 읽어야 하고, 쓰기가 잦은 데이터에서는 페이지 창이 흔들려 항목을 건너뛰거나 중복 반환한다는 것이다 (Slack Engineering, Evolving API Pagination at Slack).
커서 방식은 키셋(Keyset) 페이지네이션이나 시크(Seek) 방식이라고도 부른다. 정렬 기준 컬럼의 마지막 값을 WHERE 조건으로 넘겨 “아직 보지 않은 데이터만” 고르는 구조다 (Winand, 위 인용).
페이지네이션은 사용자가 번호를 눌러 이동하고, 무한 스크롤은 화면 끝에 닿으면 자동으로 다음 항목을 붙이고, 더 보기는 버튼을 누를 때만 붙인다. 셋 중 어느 하나가 모든 사이트에 우월하지는 않다.
| 구분 | 페이지네이션 | 무한 스크롤 | 더 보기 버튼 |
|---|---|---|---|
| 항목 위치 기억 | 몇 페이지에 있었는지 기억 가능 | 위치 기억 어려움 | 중간 |
| 상호작용 비용 | 클릭 필요 | 없음 | 클릭 필요 |
| 어울리는 콘텐츠 | 특정 항목 찾기, 상품 비교 | 소셜 피드, 탐색 | 목록과 피드 사이 |
| 검색엔진 색인 | 각 페이지 URL을 크롤링 | 스크립트만으로는 뒤 항목 미발견 | 버튼 뒤 항목 미발견 |
닐슨 노먼 그룹은 페이지네이션에서는 사용자가 항목이 몇 페이지에 있었는지 기억할 수 있지만 무한 목록에서는 위치를 기억하기 어렵고, 더 보기 버튼은 무한 스크롤의 문제를 일부 줄이는 대신 클릭이라는 상호작용 비용을 더한다고 정리했다 (Nielsen Norman Group, Infinite Scrolling: When to Use It, When to Avoid It).
검색엔진 쪽 차이는 크다. 구글 크롤러는 버튼을 클릭하지 않고, 페이지 콘텐츠를 갱신하는 데 사용자 동작이 필요한 자바스크립트 함수를 실행하지 않는다 (Google 검색 센터, 페이지로 나누기, 증분 페이지 로드 및 검색).
무한 스크롤은 크롤 예산도 낭비한다. 구글은 크롤 예산이 문제가 되는 사이트로 고유 페이지 100만 개 이상이거나 1만 개 이상이면서 매일 바뀌는 사이트를 들고, 무한 스크롤 페이지와 같은 페이지의 다른 정렬 버전을 낭비 요인으로 꼽는다 (Google 검색 센터, 대규모 사이트 소유자를 위한 크롤링 예산 관리 가이드).
이전과 다음 버튼, 숫자 링크 목록, 생략된 번호를 나타내는 말줄임표, 현재 페이지 표시 넷이 기본 구성이다. 정부 디자인 시스템 KRDS는 여기에 페이지 직접 입력과 더 보기 버튼을 대체 구조로 둔다 (KRDS, 페이지네이션 컴포넌트).
KRDS의 사용성 가이드라인은 다음과 같다 (KRDS, 위 인용).
같은 문서는 사용자의 목표가 데이터 집합에서 특정 항목을 찾는 것일 때 페이지네이션이 맞고, 주제별로 묶어 보여줘야 할 때는 맞지 않는다고 구분한다.
각 페이지에 고유한 URL과 자기 자신을 가리키는 표준 URL을 주고, 이전과 다음 링크를 크롤러가 따라갈 수 있는 a 태그로 만드는 것이 전부다. 구글 검색 센터의 권장사항은 2025년 12월 18일 갱신본 기준 다음과 같다 (Google 검색 센터, 페이지로 나누기 문서, 위 인용).
한때 페이지네이션 SEO의 핵심이던 link rel=“next”와 rel=“prev”는 구글이 더 이상 색인에 쓰지 않는다. 구글 문서가 “이전에는 사용했으나 이제는 더 이상 사용하지 않습니다”라고 밝히고 있다 (Google 검색 센터, 페이지로 나누기 문서, 위 인용).
다만 rel=“next”와 rel=“prev”는 HTML 표준 링크 타입으로 남아 있다. 현재 페이지가 속한 순서의 다음 자원과 이전 자원을 가리키는 값이며, 접근성 도구와 다른 검색엔진이 읽을 수 있어 넣어 둬도 해롭지 않다 (MDN, rel 속성).
표준 태그와 중복 콘텐츠 처리는 페이지네이션 SEO의 절반이다. 나머지 절반은 크롤링과 색인이 페이지 2 이후까지 닿게 하는 내부 링크 설계다.
서치폴라리스는 목록을 나누지 않는다. 2026년 9월 27일 curl로 실측한 결과 /wiki/ 목록 페이지는 위키 98편을, /blog/ 목록 페이지는 글 92편을 각각 한 페이지에 전부 실었고, /blog/page/2/는 404였다.
| 목록 페이지 | 항목 수 | HTML 크기 | 페이지 분할 |
|---|---|---|---|
| /wiki/ | 98편 | 약 75KB | 없음(단일 페이지) |
| /blog/ | 92편 | 약 188KB | 없음(단일 페이지) |
항목이 100개 안팎이면 단일 페이지가 크롤링에는 가장 단순하다. 모든 문서 링크가 a 태그로 한 HTML 안에 있어 크롤러가 클릭이나 스크롤 없이 전부 발견한다.
검색 수요도 함께 실측했다. 구글 키워드 플래너 기준 “페이지네이션”은 월 1,900회(12개월 1,600~2,900회), “pagination”은 1,000회, “페이징”은 390회, “무한 스크롤”은 320회다.
네이버 검색광고 기준 “페이지네이션”은 PC 200회, 모바일 80회로 PC 비중이 높은 개발자 키워드다.
구글 자동완성은 “페이지네이션 뜻”, “ui”, “종류”, “디자인”, “구현”, “방식”, “커서”, “버튼”, “영어로” 순이다. 네이버 지식iN의 “페이지네이션” 질문 1,919건 중 상위 10건은 node.js, JSP, 워드프레스, Swiper 구현 질문이 8건이었다.
긴 목록을 여러 페이지로 나누고 번호나 이전, 다음 버튼으로 이동하게 하는 방식이다. 데이터를 자르는 서버 쪽 구현과 번호 버튼을 보여주는 화면 쪽 UI를 모두 가리킨다.
앞에서 N개를 건너뛰고 M개를 가져오는 방식이다. 페이지 번호로 바로 이동할 수 있지만, 뒷페이지로 갈수록 건너뛴 행을 모두 읽어 느려지고 데이터가 바뀌면 항목이 중복되거나 빠진다 (Winand, Slack Engineering, 위 인용).
특정 항목을 찾거나 비교하는 목록은 페이지네이션, 끝없이 훑어보는 피드는 무한 스크롤이 맞고, 어느 쪽이든 모든 사이트에 우월한 답은 없다 (Nielsen Norman Group, 위 인용). SEO만 보면 무한 스크롤도 페이지별 URL을 함께 두면 문제없다.
Pagination이다. 동사는 paginate, 서버 구현 맥락에서는 paging이라고도 쓴다.
구글에서 “pagination”은 월 1,000회, “페이지네이션”은 1,900회 검색된다.
서치폴라리스가 AI 검색 가시성을 진단하고 GEO 실행까지 대행합니다.