개발 slecs

피규어 검색 추가로 무한스크롤 제대로 작동시키기

목차

피규어 덱스 홈 화면의 무한스크롤이 제대로 작동 안 되던 문제를 검색창 추가와 동시에 데이터 로딩 방식을 바꿔서 해결했다. 단순 기능 추가가 아니라, 근본적인 설계 문제를 짚고 넘어가던 작업이었다.

무한스크롤이 제 역할을 못 하던 상황

처음부터 생각해보니, 홈 화면에서 전체 피규어를 메모리에 한 번에 덤프(dump)해서 돔에 렌더링하는 방식을 쓰고 있었다. 이렇게 하면 무한스크롤의 존재 자체가 말이 안 된다. 스크롤할 새로운 데이터가 없기 때문이다. 더 근본적인 문제는, 피규어 규모가 커질수록 초기 로딩이 지수적으로 무거워진다는 것. 수천 개의 피규어를 첫 페이지 로드에 싹 가져와야 했으니까.

이 방식은 처음 프로토타입 수준에선 "빠르게 동작하는 것처럼" 보였다. 작은 데이터셋에선 사실 느껴지지 않으니까. 하지만 서비스 규모가 자라면서, 특히 검색 기능을 더해야 한다는 요구가 나왔을 때 비로소 문제가 드러났다. 전체 데이터를 먼저 메모리에 올려놓고서 클라이언트 사이드에서 필터링하는 방식이면, 검색 쿼리마다 또 전체를 로드해야 한다. 악순환이다.

설계 결정: 점진적 로딩으로 전환

결국 두 가지를 동시에 진행했다.

첫째, 홈 화면(HomeBody)에 검색창을 추가했다. 단순한 입력폼이 아니라, 검색 쿼리를 받으면 필터링된 결과만 요청하는 구조. 이건 백엔드 API가 쿼리 파라미터를 받아 처리하도록 설계해야 한다는 뜻이다.

둘째, FiguresBody 컴포넌트의 데이터 로딩 로직을 무한스크롤 방식으로 다시 짰다. 초기에는 첫 페이지(예: 20개)만 로드하고, 사용자가 아래로 스크롤할 때마다 다음 페이지를 동적으로 요청하는 패턴으로. 이건 익숙한 기법이지만, 검색 필터와 함께 작동해야 하니까 상태 관리가 중요했다.

Before (문제):
홈 화면 로드 → 전체 피규어 쿼리 → 메모리에 덤프 → 돔에 렌더링
검색 요청 → 클라이언트 필터 (이미 메모리에 있는 걸로만)

After (해결):
홈 화면 로드 → 첫 페이지만 로드 (20개)
사용자 스크롤 → 다음 페이지 동적 로드
검색 입력 → 새로운 쿼리로 API 요청 → 첫 페이지부터 다시 시작

이런 설계 결정의 깊이

무한스크롤을 제대로 구현하려면 몇 가지 고민할 점이 있다.

첫째, 상태 관리. 현재 페이지 번호, 검색 쿼리, 로딩 중 상태, 더 이상 데이터가 없는 상태(end-of-list)를 추적해야 한다. 사용자가 검색 쿼리를 바꾸면 페이지 번호를 초기화해야 하고, 로딩 중에 또 스크롤하면 중복 요청이 되지 않도록 방어해야 한다.

둘째, API 설계 관점. 백엔드가 이런 점진적 로딩을 효율적으로 처리할 수 있어야 한다. 페이지네이션을 지원하고, 검색 쿼리와 함께 쓸 수 있어야 하며, 응답 메타데이터(전체 개수, 페이지 수)를 명확히 제공해야 한다.

셋째, UX 관점. 스크롤할 때 로더(spinner)를 보여줄지, 어디에 보여줄지. 검색 쿼리를 바꾸면 화면이 처음으로 스크롤될지, 현재 위치에 머물지. 네트워크 에러가 나면 재시도 버튼을 어디에 둘지.

이런 게 다 맞아떨어져야 사용자 입장에서 "부드러운" 느낌이 난다.

팀 관점에서의 의사결정

이 작업을 우선순위 높게 끌어올린 이유는 세 가지다.

  1. 성능 개선이 직결된다. 초기 로딩 시간이 드라마틱하게 줄어든다. 첫 페이지 20개만 로드하는 것과 전체 5000개를 로드하는 것은 천지차이.

  2. 검색 기능의 기반이 된다. 검색을 "제대로" 하려면 (서버 사이드에서) 이 구조가 필수다. 클라이언트 필터만으로는 확장성이 없다.

  3. 다른 팀원들이 참고할 패턴이 된다. 비슷한 리스트 화면을 여러 곳에서 구현할 텐데, 이 무한스크롤 + 검색 조합이 일종의 템플릿 역할을 할 수 있다.

학습한 점

이 작업 후로는 초기 설계 단계에서 데이터 규모 예상을 더 진지하게 본다. "지금은 작지만 6개월 뒤엔 10배 클 것 같다면?" 하는 질문을 일찍 던지는 습관이 생겼다. 무한스크롤은 사실 "선택지"가 아니라 규모가 커지면 "필수"가 되는 기능이니까.

또 하나, 기능 추가(검색)와 성능 최적화(무한스크롤)를 분리하지 않았다는 게 좋은 선택이었다. 동시에 진행하니까 일관된 설계가 나올 수 있었다. 순서를 바꿔서 검색 기능을 먼저 달았으면, "이미 있는" 전체 덤프 방식을 유지하려고 했을 가능성이 높다.

🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

이어보기

댓글 0

첫 댓글 달아줘.