페이지네이션은 큰 결과 집합을 개별 페이지로 나누어, 한 번에 수천 개의 레코드를 로드하지 않게 합니다. 성능과 사용성에 필수적입니다. Django는 template/view를 위한 Paginator 클래스를 제공하고, DRF는 API를 위한 내장 페이지네이션을 제공합니다.
# ❌ 모든 것을 로드 — 수천 개 행에서 느리고, 메모리 부담이 크며, UX가 나쁨
articles = Article.objects.all() # 100,000개 레코드일 수 있음
from django.core.paginator import Paginator
def article_list(request):
articles = Article.objects.all().order_by("-created_at") # 일관된 페이지를 위해 ORDER 중요
paginator = Paginator(articles, 20) # 페이지당 20개 항목
page_number = request.GET.get("page") # ?page=2
page_obj = paginator.get_page(page_number) # 요청된 페이지
return render(request, "list.html", {"page_obj": page_obj})
<!-- template에서 -->
{% for article in page_obj %}
<h2>{{ article.title }}</h2>
{% endfor %}
{% if page_obj.has_previous %}<a href="?page={{ page_obj.previous_page_number }}">Prev</a>{% endif %}
Page {{ page_obj.number }} of {{ page_obj.paginator.num_pages }}
{% if page_obj.has_next %}<a href="?page={{ page_obj.next_page_number }}">Next</a>{% endif %}
Paginator는 queryset을 페이지로 분할하고 get_page()는 네비게이션 헬퍼(has_next, next_page_number 등)를 가진 페이지 객체를 반환합니다—쿼리에 LIMIT/OFFSET을 추가하므로 데이터베이스에서 한 페이지만 가져옵니다.
# settings.py에서 전역 기본값
REST_FRAMEWORK = {
"DEFAULT_PAGINATION_CLASS": "rest_framework.pagination.PageNumberPagination",
"PAGE_SIZE": 20,
}
# 이제 list 엔드포인트가 자동 페이지네이션되어 반환:
# { "count": 1000, "next": "...?page=3", "previous": "...?page=1", "results": [...] }
DRF는 구성되면 list 엔드포인트를 자동 페이지네이션하여, 결과와 함께 페이지 메타데이터(count, next/previous 링크)를 반환합니다—클라이언트는 제공된 URL을 통해 네비게이션합니다.
PageNumberPagination → ?page=2 (단순 페이지 번호)
LimitOffsetPagination → ?limit=20&offset=40 (유연한 오프셋)
CursorPagination → 불투명 커서; 크고/변하는 데이터에 일관되고 성능 좋음
(거대한 데이터셋의 OFFSET 성능 문제 회피)
⚠️ OFFSET 기반 페이지네이션(page/offset)은 거대한 테이블의 깊은 페이지에서 느려짐
(DB가 OFFSET 행을 건너뛰어야 함). 매우 큰 데이터셋에는 CURSOR 페이지네이션
(keyset, 인덱싱된 컬럼에 WHERE 사용)이 훨씬 효율적.
⚠️ 항상 안정적인 필드로 ORDER BY, 그렇지 않으면 페이지가 일관성 없거나 항목 반복.
페이지네이션은 실제 데이터 양을 처리하는 성능 좋고 사용 가능한 애플리케이션을 구축하는 데 필수적입니다—이것 없이는 전체 테이블(잠재적으로 수천 또는 수백만 행)을 로드하는 list 엔드포인트와 페이지가 느리고, 메모리 집약적이며, 사용 불가능해져, 데이터베이스를 압박하고 사용자와 클라이언트를 압도합니다.
페이지네이션을 이해하는 것은 일상적인 실용 지식입니다: Django의 Paginator는 전통적 view/template을 처리하고(queryset을 네비게이션 헬퍼와 함께 페이지로 분할, LIMIT/OFFSET을 통해 한 페이지만 효율적으로 가져옴), DRF의 내장 페이지네이션은 API를 처리합니다(구성되면 메타데이터와 네비게이션 링크와 함께 list 엔드포인트를 자동 페이지네이션)—서버 렌더링 페이지를 구축하는지 API를 구축하는지에 따라 둘 다 필요합니다.
두 맥락에서 페이지네이션을 구현하는 방법을 아는 것은 거의 모든 데이터 나열 기능에 필요합니다.
성능 미묘함은 특히 가치 있는 시니어 수준 지식입니다: 표준 OFFSET 기반 페이지네이션은 매우 큰 테이블의 깊은 페이지에서 저하되므로(데이터베이스가 모든 선행 행을 건너뛰어야 함), 커서(keyset) 페이지네이션이 거대하거나 빠르게 변하는 데이터셋에 효율적인 선택이며, 페이지 전반의 일관성 없거나 중복된 결과를 피하기 위해 항상 안정적인 필드로 정렬하는 것이 필요합니다.
기본 메커니즘(Paginator, DRF 페이지네이션 클래스)과 이러한 성능 고려사항(OFFSET vs 커서 페이지네이션, 일관된 정렬) 모두를 이해하는 것은 데이터가 늘어나도 빠르고 올바른 애플리케이션을 구축하는 데 중요합니다—페이지네이션은 어디에나 있는 요구사항이고, 특히 규모에서 잘 해내는 것은 애플리케이션 성능과 사용자 경험에 직접 영향을 미치는 실용적 기술입니다.