API 페이지네이션 완벽 가이드: 오프셋 vs 커서 기반 접근법

안녕하세요! API를 개발하다 보면 한 번에 너무 많은 데이터를 처리해야 해서 어려움을 겪은 적이 있지 않으신가요? 예를 들어 수천 개의 사용자 로그, 제품 목록, 소셜 미디어 게시물을 한꺼번에 전송해야 하는 서비스를 만든다고 상상해 보세요. 상당히 부담스럽죠? 바로 이때 페이지네이션이 도움이 됩니다. 대량의 데이터를 더 작은, 다루기 쉬운 덩어리로 나눠서 개발자, 서버, 사용자 모두 편하게 처리할 수 있게 해주는 거예요.

오늘은 페이지네이션을 처리하는 두 가지 일반적인 방법에 대해 이야기해 보려고 해요. 오프셋 기반 페이지네이션과 커서 기반 페이지네이션이 그것인데요. 각각의 장단점을 살펴보면서 어떤 상황에 더 적합한지 알아보도록 할게요. 시작해 볼까요?

 

왜 페이지네이션이 필요할까요?

 

왜 페이지네이션이 필요할까요?

한 번에 수천 개의 데이터를 API로 반환하려고 한다고 상상해 보세요. 사용자 활동 로그, 제품 목록, 소셜 미디어 포스트 등 끝도 없이 많은 데이터일 수 있죠. 이렇게 하면 어떤 일이 벌어질까요?

• 서버 과부하: 서버가 너무 많은 데이터를 처리하느라 부담이 커지고, 결국 응답 시간이 길어집니다.
• 네트워크 혼잡: 대량의 데이터 전송은 네트워크 속도를 느리게 만들고, 결과적으로 느린 앱이 되겠죠.
• 사용자 경험 악화: 사용자는 로딩 스피너만 바라보며 기다리게 되고, 그 누구도 이런 경험을 원하지 않아요.

그래서 페이지네이션이 필요한 거예요. 대규모 데이터를 작고 쉽게 처리할 수 있는 조각으로 나눠줍니다. 10,000개의 데이터를 한꺼번에 보내는 대신, 10개, 50개, 혹은 100개씩 나눠서 보내는 거죠. 이렇게 하면 처리 속도가 빨라지고, 앱은 더욱 쾌적해지며, 사용자 경험도 훨씬 좋아져요.

 

오프셋 기반 페이지네이션: 간단한 접근법

 

오프셋 기반 페이지네이션: 간단한 접근법

먼저 오프셋 기반 페이지네이션부터 살펴볼게요. 이 방법은 꽤 간단해요. 마치 책의 페이지를 넘기듯 데이터를 나눠서 볼 수 있어요. 특히 데이터가 자주 변경되지 않는 블로그 게시글이나 포럼 게시물 같은 경우에 잘 맞아요.

오프셋 기반 페이지네이션에는 두 가지 주요 형태가 있어요:

1. 페이지 기반 페이지네이션: API에 특정 페이지와 페이지당 항목 수를 요청하는 방식이에요. 예를 들어, 3번째 페이지에서 20개의 항목을 가져오고 싶다면 다음과 같은 쿼리를 사용할 수 있어요:
2. SELECT * FROM posts LIMIT 20 OFFSET 40;
3. 오프셋과 제한: 원하는 항목 수와 시작 위치를 지정하는 방식이에요. 간단하죠.

이 방법은 비교적 정적인 데이터에는 잘 작동하지만 몇 가지 단점도 있어요:

• 성능 저하: 오프셋 값이 클 경우, 데이터베이스가 해당 오프셋까지 모든 행을 스캔해야 하기 때문에 속도가 느려질 수 있어요.
• 데이터 불일치: 데이터가 자주 변경되면(예를 들어 새로운 레코드가 추가될 때) 오프셋이 엉망이 되어, 일부 레코드를 놓치거나 중복된 데이터를 볼 수 있어요.

 

커서 기반 페이지네이션: 빠르고 신뢰할 수 있는 방법

 

커서 기반 페이지네이션: 빠르고 신뢰할 수 있는 방법

이제 커서 기반 페이지네이션에 대해 이야기해 볼게요. 이 방법은 조금 더 복잡하지만 실시간 데이터나 지속적으로 변경되는 대규모 데이터에 적합해요. 예를 들면 소셜 미디어 피드나 금융 데이터 같은 경우죠.

작동 방식은 다음과 같아요:

1. 고유한 열 선택: 먼저 ID나 타임스탬프 같은 고유한 값을 커서로 사용해요.
2. 커서 해싱: 때로는 데이터 보안을 위해 커서를 해싱하기도 해요.
3. 클라이언트가 커서 값 전송: 클라이언트가 추가 데이터를 요청할 때 마지막 커서 값을 함께 보냅니다.
4. 서버가 데이터와 새로운 커서 반환: 서버는 다음 데이터와 함께 다음에 사용할 커서를 반환해요.

예를 들어 이런 식으로 쿼리할 수 있어요:

SELECT * FROM posts WHERE id > last_seen_id ORDER BY id LIMIT 20;

왜 이렇게까지 해야 할까요?

• 일관성: 새 레코드가 추가되거나 삭제되더라도 결과가 안정적이고 일관성이 있어요.
• 더 나은 성능: 이전의 모든 행을 스캔할 필요 없이 이전 위치에서 바로 이어서 가져오면 되니까, 마치 책에 북마크를 끼워두는 것과 같아요.

그래서 커서 기반 페이지네이션은 실시간 피드나 데이터가 계속 바뀌는 환경, 예를 들어 채팅 앱이나 소셜 미디어 같은 곳에 적합해요.

 

커서 기반 페이지네이션의 다양한 유형

 

커서 기반 페이지네이션의 다양한 유형

커서 기반 페이지네이션의 두 가지 인기 있는 방법을 살펴볼게요:

1. 키셋 페이지네이션: 고유한 키(예: 기본 키)를 사용해서 필요한 행으로 바로 이동하는 방식이에요. 효율적이고 불필요한 스캔을 피할 수 있어요.
2. 시간 기반 페이지네이션: 시간에 민감한 데이터(예: 이벤트 로그나 타임스탬프가 있는 데이터)를 다루는 애플리케이션에서는 시간 기반 페이지네이션이 완벽해요. 타임스탬프를 커서로 사용해서 특정 시간 범위의 데이터를 가져올 수 있죠.

 

오프셋 vs. 커서: 어떤 것을 선택해야 할까요?

그렇다면 어떤 방식을 선택해야 할까요?

• 오프셋 기반 페이지네이션: 작고 상대적으로 정적인 데이터셋에 가장 적합해요. 구현하기 쉽고 이해하기도 쉬워서, 제품 목록이나 블로그 게시글 같은 경우에 좋아요.
• 커서 기반 페이지네이션: 크고, 동적인 데이터셋에서 일관성을 유지해야 한다면(예: 뉴스 피드, 소셜 미디어, 사용자 댓글) 커서 기반 페이지네이션을 사용하는 것이 좋아요. 나중에 골치 아플 일을 피할 수 있어요.

 

마무리

어떤 페이지네이션 방법을 선택할지는 결국 여러분의 상황에 달려 있어요. 데이터셋이 비교적 정적이라면 오프셋 기반 페이지네이션이 간단하고 충분히 효과적이에요. 하지만 데이터가 자주 변경되고 일관성이 필요하다면 커서 기반 페이지네이션이 더 나은 선택이에요.

다소 복잡하게 느껴질 수 있지만, 성능, 일관성, 확장성 면에서 장점이 많기 때문에 대규모나 자주 변경되는 데이터셋에는 꼭 필요한 방법이에요.