🧠 무한 스크롤, 가상 리스트, 그리고 Lazy Rendering

프론트엔드 개발을 하다 보면 리스트 렌더링 관련 고민은 늘 빠지지 않죠. 특히 "많은 데이터를 어떻게 사용자에게 빠르게, 부드럽게 보여줄 것인가?"는 모든 서비스에서 중요한 문제입니다.

최근 저는 구성원 정보를 보여주는 테이블 UI를 리뉴얼하면서 이 문제를 직접 겪었고, 그 해결을 위해 IntersectionObserver 기반 Lazy Rendering을 선택했습니다. 오늘은 그 여정과 실무 적용 포인트를 공유해보려 합니다.

---

🧩 기존 구조의 한계: 페이지네이션에서 무한 스크롤로

기존 구성원 정보 페이지는 페이지네이션 기반이었습니다. 사용자는 1페이지, 2페이지를 넘기며 데이터를 봐야 했고, UX 측면에서 꽤 불편했습니다. 이에 따라:

• ✅ 더 자연스럽게 데이터를 탐색할 수 있는 무한 스크롤로 변경
• ❗ 하지만 무한 스크롤로 전환하자 곧바로 렌더링 성능 이슈가 나타났습니다

문제는 "렌더링이 너무 많다"는 것.
리스트 데이터를 모두 렌더링해버리면 브라우저 메모리가 터질 수도(?) 있죠. 특히 각 구성원마다 프로필 이미지(Avatar), 아이콘, 상세정보 등이 복잡하게 얽혀 있던 터라 성능이 급격히 떨어졌습니다.

---

🔍 가상 리스트를 도입할까? 고민의 시작

가장 먼저 떠오른 건 당연히 가상 리스트(Virtual List) 라이브러리였습니다.

react-window, react-virtualized, @tanstack/virtual 등 훌륭한 라이브러리가 많죠.

하지만 현실은 언제나 이상과 다릅니다...

가상 리스트의 도입이 어려웠던 이유

• 우리 리스트는 단순한 텍스트가 아니라 중첩된 테이블 구조 + 레이아웃이 다이나믹
• 스크롤 컨테이너가 iframe 구조를 타고 들어가 있어 직접 제어가 어려움
• 기존 코드와 가상 리스트 라이브러리의 궁합이 안 맞아, 도입 난이도가 높음

→ "좋은 기술이어도 도입 비용이 너무 크다면, 실무에선 적절하지 않다"

---

🎯 그래서 선택한 것은 IntersectionObserver 기반 Lazy Rendering

복잡한 구조를 건드리지 않으면서도, 현재 보이는 요소만 렌더링하고 싶었고, 그래서 떠오른 게 IntersectionObserver였습니다.

 

const observer = new IntersectionObserver((entries) => { entries.forEach((entry) => { if (entry.isIntersecting) { setIsRendered(true); } }); }, { root: document.getElementById("main-content-box"), threshold: 0.1, });

핵심은 여기 👇

• root를 null이 아닌 #main-content-box로 지정
  → 실제 스크롤이 발생하는 지정된 컨테이너 기준으로 정확한 감지
• threshold를 조정해 얼마나 보여야 "렌더링하자"고 판단할지 정함
• isRendered 플래그를 기반으로 Avatar, Icon 등을 조건부 렌더링

단순하면서도 유연하게, 진짜 보이는 것만 렌더링하는 구조 완성!

---

💡 Lazy Rendering의 장점 (vs Virtual List)

비교 항목Lazy Rendering (IntersectionObserver)Virtual List

적용 난이도	✅ 낮음 (기존 코드 거의 유지)	❌ 높음 (구조 재정비 필요)
유연성	✅ 컴포넌트마다 개별 제어 가능	❌ 단일 리스트로만 구성
성능 최적화	✅ 실질적 렌더링 수 감소	✅ DOM 수 제한으로 최적
부작용	❌ 상태 초기화 이슈 가능	❌ 스크롤/레이아웃 깨질 수 있음

---

✨ 결과와 효과

• 최초 렌더링 DOM 수 약 80% 감소
• 불필요한 컴포넌트 렌더링 제거
• 사용자 체감 성능 향상 (스크롤 부드러움 + 로딩 지연 없음)
• Virtual Scroll 도입 없이도 퍼포먼스 최적화 달성

---

🧭 결론: 정답은 없다. “지금” 우리에게 맞는 해법이 중요

"기술 자체보다 중요한 건 상황에 맞는 판단과 실행이다"

가상 리스트는 훌륭한 기술이지만, 현재의 구조와 여건에서는 오히려 더 큰 부담이 될 수 있습니다. 오히려 IntersectionObserver는 작지만 정확한 선택이었습니다.

지금 여러분의 프로젝트에서도 "렌더링이 너무 많아서 느리다"는 이슈가 있다면,
꼭 거창한 라이브러리 도입이 아니어도 IntersectionObserver 기반 Lazy Rendering을 고려해보세요.

간결한 코드, 즉각적인 성능 개선, 그리고 개발자의 행복까지 덤으로 얻을 수 있습니다. 😎