[ FE 면접 CS] 대용량 데이터를 부드럽게 처리하는 무한 스크롤 전략

 

취준 스터디 JobScript의 첫번째 면접 스터디에서 정리한 질문입니다.

프론트엔드 개발자 입장에서 CS의 알고리즘 문제를 적용한다면 무슨 질문이 나올까 고민하며 질문을 선정하였습니다.

 

무한 스크롤에서 적용할 수 있는 알고리즘은 무엇인가요?

✅ 답변

가상 스크롤 + 슬라이딩 윈도우로 화면에 보이는 윈도우(start~end) + 앞뒤 버퍼만 렌더링합니다.

 

이전에는 DOM Element를 DOM에 계속 append 하다보니, 노드가 기하급수적으로 늘어나 Layout/Paint/Composite가 과도해져 성능이 급감하는 문제가 발생합니다. 

 

이를 해결하기 위해, 가상 스크롤과 슬라이딩 윈도우 방식을 통해 뷰포트에 보이는 아이템만 dom에 추가(가상 스크롤링)합니다.

 

스크롤 시에는 requestAnimationFrame(rAF)로 스크롤 이벤트를 묶어 프레임당 1회만 윈도우 계산을 수행하고(= rAF 배치), 총 높이·topOffset·보이는 아이템의 개수 같은 값은 캐싱을 통해 재사용합니다. 이때 아이템은 id를 key 값으로 설정해 겹치는 아이템은 재렌더링하지 않고 dom에서 재활용할 수 있습니다.

 

화면에 보이지 않는 구간은 스페이서(가짜 공간)를 두어, 아이템이 없는 가짜 공간만 할당하여 스크롤 길이는 유지할 수 있도록 합니다.

이를 통해 DOM 관리 비용이 전체 n → 상수 k(뷰포트+버퍼)로 축소됩니다.

✅  requestionAnimationFrame (rAF) 
이벤트를 프레임당 묶어서 1회만 진행하여 과도한 렌더링 연산을 줄임, 프레임 렌더링 직전에 수행함으로써 화면 동기화 시점이 맞아 화면 전환이 매끄럽다.

✅  vs setTimeOut/쓰로틀 
> setTimeOut : 시간 간격 기준
> 페인트 타이밍과 어긋날 수 있어 결국중복 계산이 가능성 존재, 렌더링의 경우는 rAF를 사용하는 것이 적절

네트워크 호출 빈도 등 비 렌더 작업 → 스로틀/디바운스
레이아웃/렌더 갱신 → raF

---

1. 슬라이딩 윈도우가 무엇인지?

지금 보이는 구간만 유지하고, 스크롤에 맞춰 그 구간(윈도우)을 미끄러지듯 이동시키는 방식

1. 스크롤 시에 scollTop으로 start/end 인덱스를 계산
2. 바뀐 경우만 dom에 패치
3. 아이템 각각 움직이지 말고 컨테이너의 topOffset만 업데이트(= 컨테이너 이동 패턴)
4. 이 모든 계산은 rAF 배치로 프레임당 1회 수행, 총 높이/offset은 캐시로 즉시 사용

✅ 추가 설명
: 실제 이동은 모든 개별 아이템들을 이동시키는 것이 아니라 아이템들을 하나의 받침에 올려서 그 받침 하나만 translate(topOffset)로 내린다.


1️⃣만약 아이템의 높이가 고정되어 있다면,

startIndex가 지나쳐온 아이템의 개수라고 했을 때,
: topOffset = startIndex * 아이템의 높이

2️⃣아이템이 가변 높이라면?
: topOffeset : 그동안 지나간 아이템들의 높이를 모두 더한 누적합

---

2. 그러면 방금 본 아이템도 스크롤 할 때마다 데이터 패칭을 해야 하는데 줄이기 위한 방법은?

양방향 커서를 두어 하단 상단 sentinel이 보일 때만 after/before 커서로 요청하고 메모리는 최근 창만 유지합니다. 이때 메모리에는 최근 창만 유지하고Lateset Recently Used로 비우고 필요시 재 요청합니다.

상단에 과거 페이지를 붙일 때는 앵커 아이템을 기준으로 scrollTop을 보정해 사용자가 보던 위치를 그대로 유지하여 점프를 방지

✅ sentinel
: 무한 스크롤이나 가상 스크롤링 구현에서 사용되는 감시 요소, 주로 상단과 하단에 한쌍으로 배치되어 사용자의 스크롤 동작을 감지

이때, 상단 sentinel은 과거 데이터 로딩, 하단 sentinel은 미래 데이터 로딩 담당
상단 sentinel은 특히 다시 위로 스크롤 할때 상단에 아이템이 추가되면 기존 콘텐츠가 아래로 밀려나게 되는데, 이때 앵커 아이템을 기준으로 scrollTop을 내려간 만큼 역조정하여 튕기는 현상을 최소화

주로 Intersection Observer와 함께 사용되어 비동기적으로 요소의 가시성 변화를 감지하여 메인 스레드를 블로킹하지 않는다.

sentinel이 경계선 역할을 하면서 적절한 타이밍에 데이터를 로드하거나 해제함으로써 메모리 효율성과 사용자 경험의 균형을 맞춘다.

---

3. 추가 최적화 방법이 없을까?

네 화면에 보이는 아이템을 렌더링할 때 이전 뷰표트에 있던 아이템은 리렌더링하지 않고 DOM 에서 재활용

 

 슬라이딩 윈도우 시 변경되는 부분만 패치하는 전략을 세울 수 있다.

1. 아이템 key는 index가 아닌 Id로 고정하여 겹치는 구간은 DOM을 재사용
2. 컴포넌트를 메모하는 React.memo와 안정화된 props로 겹치는 컴포넌트는 리렌더를 차단

윈도우 diff 로 배열 전체가 아닌 이전 다음 범위를 비교해서 변경 부분만 패치한다

✅왜 Index 가 아닌 Id로 진행하나?
: Index로 진행하면 위로 스크롤 이동 시 중간에 아이템이 추가되어 index가 +1 씩 뒤로 밀린다.


✅ 안정화된 props?
: React.memo로 컴포넌트를 메모해도 style 이나 함수 등 새로운 객체를 생성하여 props로 넘기면 상태가 바뀌었다고 판단
즉, React.memo가 적용되지 않고 호출시마다 리렌더링
객체를 props로 넘겨야 한다면 cache를 통해 객체를 재사용하여 전달

---

4. 슬라이딩 윈도우를 적용했을 때 가변높이 아이템들이 섞여있으면 무슨 문제가 발생? 해결책은?

이미지가 늦게 로딩되는 경우 높이가 변해서 아이템들이 아래로 밀려내려가는 스크롤이 튀는 현상이 발생

 

ResizeObserver를 통해 아이템의 높이 변화가 감지되면 아이템의 높이 누적합에서 부분적으로 갱신하고, 화면 최상단의 앵커아이템을 기준으로 scrollTop을 아래로 내려간 만큼 역으로 재조정

 

또, 이미지의 경우 placeholder 높이를 미리 두어 점프 현상 최소화

---

5. 슬라이딩 윈도우 방식으로 적용하면 단점은?

검색 접근성, 가변 높이 점프, 기존 상태가 다 사라지는 문제가 발생

 

1. 검색 접근성 

: DOM에 없는 항목은 브라우저 리더가 보지 못해 검색을 할 수 없다

→ 내장 검색창을 통해 데이터 상의 위치로 매핑해 그 위치로 스크롤을 이동시키는 방법으로 해결

 

2. 가변 높이 점프

: 이미지가 늦게 로드되어 높이가 나중에 커지면 스크롤이 갑자기 아래로 튀는 현상이 발생

→ 뷰포트 최상단에 보이는 앵커 아이템을 기준으로 삼고, 변경 전 위치 차이만큼 scrollTop 을 반대로 조정하거나 placeholder로 미리 이미지 높이를 예약

 

3. 기존 상태가 다 사라지는 현상

: 댓글을 작성하다가 위로 올렸을 때 작성하고 있던 댓글창이 DOM에서 사라지면서 기존에 작성하던 댓글이 사라지는 문제

→ 입력이나 포커스 상태는 외부 스토어에 map 형태로 아이템ID 의 상태를 저장하고 화면에 보일 때 상태 복원