앤에서 무한 스크롤: 정의, 원리 및 구현

모바일 애플리케이션에서 무한 스크롤이란?

무한 스크롤(Infinite Scroll)은 사용자가 스크롤한 때 새 요소가 자동으로 리스트 끝에 추가되는 데이터 로딩 패턴입니다. 사용자는 “다음” 또는 “더 보기” 버튼을 클릭하지 않습니다 — 시스템 자체가 언제 다음 데이터 배치를 요청할지 결정하고 기존 리스트에 새 항목을 원활하게 삽입합니다.

Infinite Scroll은 소셜 네트워크 덕분에 인기를 얻었습니다 — Twitter, Instagram 그리고 TikTok은 그것을 주요 콘텐츠 전달 메카니즘으로 사용합니다. Nielsen Norman Group(2024)에 따르면, Infinite Scroll은 콘텐츠 애플리케이션의 참여를 30–50% 증가시킵니다. 이는 인지 부하를 줄이기 때문입니다. 하지만 정확한 네비게이션이 필요한 작업(검색, 제품 비교)에서는 Infinite Scroll이 효율성을 낮출 수 있습니다.

기술적으로 Infinite Scroll은 세 가지 구성 요소로 구성됩니다: scroll listener(스크롤 위치 추적), threshold(로딩을 트리거하기 위한 리스트 끝까지의 거리), 그리고 페이지네이션 메카니즘(API 요청 및 데이터 삽입). threshold의 적절한 설정은 매우 중요합니다: 트리거가 너무 이르면(1000 px 남았을 때) 사용자가 필요 없는 요청을 받게 되고, 너무 늦으면(50 px) 사용자가 로딩 일시 중단을 알차합니다.

Infinite Scroll 작동 방식: 아키텍처와 메카니즘

Infinite Scroll의 아키텍처는 이벤트 구동 모델에 기반합니다: 리스트 컴포넌트가 스크롤 임계값에 도달하면 이벤트를 생성하고, ViewModel이 그것을 처리하여 다음 데이터 배치를 로드하도록 리포지토리를 호출합니다. 응답을 받은 후, 새 요소가 리스트에 삽입되고 UI가 어댑터를 통해 업데이트됩니다. 이 체인은 비동기적이어야 하고 UI 스레드를 차단하지 않아야 합니다.

기본 Infinite Scroll 알고리즘은 네 단계로 구성됩니다. 초기화: 화면이 처음 열릴 때 첫 번째 데이터 배치가 로드됩니다(페이지 1 또는 cursor = null). 추적: scroll listener가 사용자가 임계값에 도달했는지 확인합니다(보통 리스트 끝에서 200–500 px). 로딩: 페이지네이션 매개변수와 함께 API에 요청이 보려지고, UI에 로딩 지표(푸터의 스필너)가 표시됩니다. 삽입: 새 요소가 어댑터에 추가되고, 점프를 피하기 위해 스크롤 위치가 조정됩니다.

중요한 양상은 요청 디바우싱(debouncing)입니다. 사용자가 빠르게 끝까지 스크롤하면, 서버으로부터 응답을 받기 전에 트리거가 여러 번 발생할 수 있습니다. debounce가 없으면 중복 요청(경쟁 상태)이 발생합니다. 해결 방법은 이전 요청이 완료될 때까지 새 요청을 차단하는 것입니다. ViewModel의 isLoading 플래그가 여러 호출을 막습니다: 요청 보낼 때 isLoading = true를 설정하고, 응답 또는 오류를 받았을 때 재설정합니다.

모바일 플랫폼에서는 Infinite Scroll에 전문 메카니즘이 사용됩니다. iOS에서는 UICollectionView의 prefetchDataSource가 사용되어 화면 밖의 셀을 위한 데이터를 자동으로 요청합니다. Android에서는 Google의 Paging 3 Library가 사용되며, PagingSource, PagingData 그리고 PagingDataAdapter를 지원하는 완성된 아키텍처를 제공합니다. Paging 3는 네트워크와 로컬 데이터를 결합하기 위한 RemoteMediator를 지원하고 로딩 상태를 자동으로 관리합니다.

Cursor-based vs Offset-based 페이지네이션

Offset-based 페이지네이션은 page와 size 매개변수를 사용합니다: page=2, size=20은 레코드 21–40을 반환합니다. 이 접근 방식은 구현이 간단하지만 근본적인 문제가 있습니다 — 요청 사이에 데이터베이스에서 레코드가 추가되거나 삭제되면 오프셋이 비지지 되어집니다(사용자가 중복 또는 겹을 봅니다). 변경 빈도가 높은 피드(뉴스, 댓글)에서는 offset-based 페이지네이션이 잘못된 결과를 내죽니다.

Cursor-based 페이지네이션은 마지막 요소의 고유 식별자(cursor)를 사용합니다: after=id_12345&limit=20. 서버는 지정된 커서 다음 20개의 레코드를 반환합니다. 이 접근 방식은 삽입과 삭제에 관계없이 데이터 일관성을 보장합니다. GraphQL Best Practices(2024)에 따르면, cursor-based 페이지네이션은 데이터가 동적으로 변경되는 모든 실시간 애플리케이션에 권장됩니다.

접근 방식 선택은 애플리케이션 유형에 따라 달랍니다. 소셜 네트워크(Instagram, TikTok)에서는 피드가 지속적으로 업데이트되므로 cursor-based만 사용합니다. 변경이 거의 없는 카탈로그(온라인 상점의 제품 카테고리)에서는 offset-based 페이지네이션이 허용됩니다. 하이브리드 시나리오에서는 Google이 Paging 3 RemoteMediator를 권장하며, 이는 네트워크의 cursor-based 페이지네이션과 로컬 Room 데이터베이스의 offset-based 페이지네이션을 결합합니다.

iOS 및 Android에서 Infinite Scroll 구현

Android에서는 Jetpack의 Paging 3 라이브러리가 표준 접근 방식입니다. PagingSource는 데이터 소스(네트워크 또는 데이터베이스)를 정의하고, PagingData는 데이터 캌크를 포함하며, PagingDataAdapter는 그것들을 RecyclerView에 표시합니다. Paging 3는 프리페치 거리, 재시도 및 새로고침을 자동으로 관리합니다. 네트워크 통합에는 RemoteMediator가 사용됩니다: API에서 데이터를 로드하고, Room에 저장하고, PagingSource에 업데이트를 알립니다. Google I/O 2024에 따르면, Infinite Scroll을 사용하는 Android 애플리케이션의 60%가 Paging 3를 사용합니다.

기본 Paging 3 구현 예제:

class FeedPagingSource(
    private val api: FeedApi
) : PagingSource<String, Post>() {
    override suspend fun load(
        params: LoadParams<String>
    ): LoadResult<String, Post> {
        val response = api.getFeed(
            cursor = params.key,
            limit = params.loadSize
        )
        return LoadResult.Page(
            data = response.items,
            prevKey = null,
            nextKey = response.nextCursor
        )
    }
}

iOS에서는 Infinite Scroll이 prefetchDataSource를 사용한 UICollectionView로 구현됩니다. UICollectionViewDataSourcePrefetching 프로토콜에는 collectionView(_:prefetchItemsAt:) 메서드가 있으며, 시스템이 특정 index paths에 대한 스크롤을 예층할 때 호출됩니다. Android Paging 3와 달리 iOS에는 빌트인 페이지네이션 라이브러리가 없습니다 — 개발자가 직접 구현하거나 RxSwift + NSLayoutConstraint 또는 Combine 기반 파이프라인같은 서드 파트 해결 책을 사용합니다.

iOS에서 프리페치 예제:

extension FeedViewController: UICollectionViewDataSourcePrefetching {
    func collectionView(
        _ collectionView: UICollectionView,
        prefetchItemsAt indexPaths: [IndexPath]
    ) {
        let lastRow = collectionView.numberOfItems(inSection: 0) - 1
        if indexPaths.contains(IndexPath(row: lastRow, section: 0)) {
            viewModel.loadNextPage()
        }
    }
}

SwiftUI는 onAppear 수식자를 통해 더 선언적인 접근 방식을 제공합니다. 개발자는 리스트 끝에 ProgressView를 배치하고 그것이 나타날 때 다음 페이지의 로딩을 트리거합니다. Apple WWDC 2024에 따르면, 새로운 AsyncSequence와 Swift Algorithms API는 빌트인 chunking과 debounce 연산자를 제공하여 Infinite Scroll 구현을 간소화합니다.

무한 스크롤의 UX 문제와 해결 방법

Infinite Scroll의 주요 UX 문제는 푸터와 네비게이션 손실입니다. 온라인 상점에서 사용자는 좌층처나 링크를 보기 위해 푸터로 이동하렧는 경우가 많습니다. 무한 스크롤은 푸터를 접근 불가하게 만듭니다 — 더 많은 콘텐츠가 로드됨에 따라 계속 아래로 내려갑니다. 해결 방법은 빠른 상단 이동을 위한 플로팅 액션 버튼(FAB)을 추가하거나 리스트와 별도로 푸터를 고정하는 것입니다.

두 번째 문제는 스크롤 기록 부재입니다. 사용자가 위치 3에서 흡미 있는 제품을 보고, 위치 50까지 스크롤한 다음 “뒤로” 버튼을 누르면 리스트 처음으로 돌아가서 다시 위치 50까지 스크롤해야 합니다. 해결 방법은 ViewModel에 스크롤 위치를 저장하거나 Activity/UIViewController 레벨에서 상태 복원을 사용하는 것입니다. iOS는 위치 복원을 위한 NSUserActivity를 지원하고, Android는 onSaveInstanceState를 지원합니다.

세 번째 문제는 수천 개 요소에서의 성능입니다. 가상화가 구성되지 않으면 500–1000개의 요소가 로드된 후 메모리 사용량 증가로 애플리케이션이 는려지기 시작합니다. 해결 방법은 보이는 셀과 프리페치된 셀만 메모리에 유지하는 RecyclerView 또는 UICollectionView를 사용한 가상화입니다. 오랜 데이터의 정기 정리(N 페이지 이상의 페이지 폐기)는 부하를 줄입니다.