페이징 처리의 표준화: Offset 방식의 한계와 Cursor 방식의 진화
데이터가 수백만 건을 넘어가는 시점부터, 단순한 '페이지 번호' 기반의 페이징은 서비스 성능의 시한폭탄이 됩니다. 많은 API 개발자들이 습관적으로 사용하는 Offset 방식은 데이터가 쌓일수록 느려지는 구조적 한계를 지니고 있기 때문입니다. 효율적인 API 설계는 단순히 기능을 구현하는 것을 넘어, 데이터 규모가 커져도 일관된 응답 속도를 보장하는 '확장성(Scalability)'을 확보하는 것입니다. 본 글에서는 페이징 전략의 두 축인 Offset과 Cursor를 기술적으로 비교하고, 실무에서 어떤 상황에 무엇을 선택해야 하는지 분석합니다.
Offset 페이징: 직관적이지만 위험한 선택
가장 대중적인 방식은 `LIMIT`과 `OFFSET`을 사용하는 것입니다. 페이지 번호를 기반으로 직관적인 구현이 가능하다는 장점이 있지만, 내부적으로는 치명적인 성능 저하 요소를 안고 있습니다.
- 문제의 핵심: 10,000페이지를 조회하기 위해 DB는 앞선 99,990개의 데이터를 모두 읽고 건너뜁니다.
- 비효율성: 데이터가 늘어날수록 건너뛰어야 할 데이터의 양이 비례해서 증가하므로, 뒤로 갈수록 응답 속도는 기하급수적으로 느려집니다.
- 데이터 정합성 문제: 페이징 중에 새로운 데이터가 삽입/삭제되면, 사용자는 동일한 데이터를 중복해서 보거나 특정 데이터를 누락할 위험이 있습니다.
Cursor 페이징: 성능과 정합성을 잡는 현대적 대안
[변경 사항: 두 방식의 동작 원리와 성능 차이를 실무 관점에서 명확히 대조하기 위해 요약표를 추가하였습니다.]
| 비교 항목 | Offset 방식 | Cursor 방식 |
|---|---|---|
| 성능 | 데이터 증가 시 속도 저하 | 데이터 규모와 무관하게 일정 |
| 정합성 | 낮음 (중복/누락 발생) | 높음 (현재 지점 고정) |
| 구현 난이도 | 매우 쉬움 | 상대적으로 높음 |
엔지니어링 통찰: 언제 무엇을 쓸 것인가
모든 상황에 Cursor 방식이 정답인 것은 아닙니다. 명확한 선택 기준이 필요합니다.
Offset 페이징은 다음 경우에 유용합니다: 게시판처럼 총 페이지 수를 보여주어야 하거나, 데이터 규모가 매우 작고(예: 1,000건 이하), 사용자가 특정 페이지로 바로 점프(Jump)해야 하는 UX가 필수적인 경우입니다.
Cursor 페이징은 다음 경우에 필수입니다: 무한 스크롤(Infinite Scroll) 환경이거나, 데이터가 실시간으로 변동되는 서비스, 혹은 수십만 건 이상의 대용량 테이블을 조회해야 하는 경우입니다. 인덱스(Index)를 활용해 특정 지점부터 데이터를 읽어오므로 성능이 매우 안정적입니다.
결론: 서비스 성장을 고려한 페이징 설계
단순한 페이징 구현이 나중에 시스템 전체의 병목이 될 수 있습니다. 초기에는 Offset으로 충분해 보일지라도, 서비스가 성장하여 데이터가 비대해졌을 때 다시 페이징 구조를 뜯어고치는 것은 엄청난 비용을 유발합니다. 여러분의 서비스가 지향하는 데이터 규모를 고려하고, 지금 당장의 편의성보다 확장성을 고려한 페이징 전략을 선택하십시오. 좋은 API 설계는 오늘 만든 코드가 내일도 성능을 유지할 것이라는 확신을 주는 설계입니다.
댓글
댓글 쓰기