RDB에서 페이징 쿼리의 중요성과 LIMIT, OFFSET 방식의 장단점
대용량 데이터를 처리할 때, 페이징(Paging)은 데이터 전달 효율성과 사용자 경험 개선을 위한 필수 기능입니다. 이 글에서는 RDB 환경에서 많이 쓰이는 LIMIT, OFFSET 기반 페이징의 작동 방식과 함께, 실제 상황에 적용할 수 있는 예제를 통해 장단점을 구체적으로 살펴보겠습니다.
1. 페이징 쿼리란?
페이징은 데이터를 일정 단위로 분할하여 조회하는 기법입니다. 대부분의 UI는 한 화면에 모든 데이터를 출력하지 않고, 페이지 또는 무한 스크롤 방식으로 일부만 보여줍니다.
예를 들어 게시글 목록을 보여줄 때 다음과 같은 SQL을 사용할 수 있습니다:
SELECT * FROM posts ORDER BY created_at DESC LIMIT 10 OFFSET 20;- 최신 게시글을 기준으로 3번째 페이지(1페이지당 10개)를 불러오는 쿼리입니다.
2. LIMIT, OFFSET 방식의 장단점
장점과 예제
장점 1: 구현이 매우 간단하다
- 대부분의 DBMS에서 기본적으로 지원되며, 추가 로직 없이 바로 사용할 수 있음.
예제
블로그 글 목록 API를 구현할 때:
SELECT * FROM posts ORDER BY created_at DESC LIMIT 10 OFFSET 0; -- 첫 페이지
SELECT * FROM posts ORDER BY created_at DESC LIMIT 10 OFFSET 10; -- 두 번째 페이지➡ OFFSET 값만 바꾸면 손쉽게 페이징 가능. 프론트엔드에서도 페이지 번호 계산이 단순함.
장점 2: UI 페이지네이션과의 궁합이 좋다
- 사용자가 특정 페이지(예: 4페이지)를 클릭하면 OFFSET = (페이지번호 - 1) * 페이지크기 로 계산 가능
예제
-- 4번째 페이지 (1페이지당 20건)
SELECT * FROM users ORDER BY id ASC LIMIT 20 OFFSET 60;➡ LIMIT, OFFSET 조합으로 정형화된 페이지네비게이션 구조에 적합
단점과 예제
단점 1: OFFSET이 클수록 성능이 급격히 저하됨
- OFFSET은 해당 위치까지의 데이터를 모두 스캔해야 하므로 비효율적
예제
-- 백만 건 중 마지막 페이지 조회 (1페이지당 10건)
SELECT * FROM logs ORDER BY created_at DESC LIMIT 10 OFFSET 999990;➡ 쿼리는 단 10건을 가져오지만, 내부적으로 999,990건을 스캔 후 버림 → 큰 I/O 비용 발생
단점 2: 데이터 추가/삭제 시 정합성 문제
- 사용자가 페이지를 넘기는 중간에 데이터가 변경되면, 중복되거나 누락되는 결과가 발생할 수 있음
예제
- 사용자가 1페이지를 조회함 (OFFSET 0)
- 그 사이에 새 데이터 5건이 삽입됨
- 2페이지(OFFSET 10)를 조회했을 때 기존 데이터 일부가 밀려 중복 조회되거나 빠짐
➡ 특히 실시간 데이터가 많은 시스템(댓글, 피드 등)에서는 사용자 경험 저하 가능성 있음
단점 3: 정렬 기준이 모호할 경우 결과 불안정
- ORDER BY가 명확하지 않으면, 페이지 간 결과가 일관되지 않을 수 있음
예제
SELECT * FROM orders ORDER BY status LIMIT 10 OFFSET 20;➡ status가 중복값이 많은 컬럼이면, 페이지 간 순서가 불안정 → 중복/누락 가능성 증가
➡ 해결책: 항상 고유한 정렬 기준(예: created_at DESC, id DESC) 추가
3. 대안: 커서 기반 페이징 (참고)
성능과 정합성이 중요한 시스템에서는 커서 기반 페이징(Cursor-based Paging) 또는 Keyset Pagination을 고려해야 합니다.
-- 이전 요청에서 마지막 게시글의 created_at이 '2024-12-01 10:00:00'이었다면
SELECT * FROM posts
WHERE created_at < '2024-12-01 10:00:00'
ORDER BY created_at DESC
LIMIT 10;➡ OFFSET을 쓰지 않고, 마지막 위치의 값을 기준으로 이어서 조회 → 빠르고 일관된 결과 보장
마무리
기준LIMIT/OFFSET 방식커서 방식
| 구현 난이도 | 낮음 | 높음 |
| 성능 (대용량) | 낮음 | 높음 |
| 실시간 정합성 | 낮음 | 높음 |
| 유저가 특정 페이지로 이동 | 용이 | 어려움 |
| 일반적인 CRUD 리스트 | 적합 | 부적합 |
LIMIT, OFFSET 방식은 간단하고 직관적이지만, 대규모 데이터 처리나 실시간 시스템에서는 성능과 정확성 이슈가 발생할 수 있습니다. 따라서 서비스 특성에 따라 적절한 페이징 전략을 선택하는 것이 중요합니다.