Virtualized List로 DOM다이어트 하기

안녕하세요. 노머스 프론트엔드 팀 김민주입니다.

저희 프론트엔드팀은 채널 및 스토어에서 발생하는 속도 이슈를 인지하고, 이를 개선하기 위한 스터디를 진행했습니다. 최근 UX/UI의 중요성이 커진 만큼, 프론트엔드 차원에서 개선할 수 있는 좋은 방법이라 생각되어 공유드립니다.

Virtualized List 스터디 배경

• 문제 인식

피드 게시물을 길게 스크롤할 때 피드 노출이 오래 걸린다는 QA가 접수되면서 문제를 인지하게 되었습니다. 백엔드에서 쿼리 성능을 개선해 API 응답 시간을 크게 단축해주셨지만, 게시글이 많은 채널에서는 여전히 스크롤 시 로딩 지연과 발열이 발생했습니다.

• 문제 상황

스크롤이 진행될수록 DOM에 수많은 엘리먼트가 누적되면서 브라우저 렌더링 비용이 급격히 증가하는 것이 원인이었습니다. 결국 API 속도가 개선되었음에도 DOM 렌더링 자체가 속도 저하와 발열을 유발하고 있었습니다.

따라서, 저희는 서버 최적화와 별개로 프론트엔드 차원에서의 근본적인 성능 개선이 필요하다고 판단했습니다. 그 과정에서 불필요한 DOM 렌더링을 최소화하고 스크롤 성능을 안정적으로 유지할 수 있는 Virtualized List 기술이 적합하다고 보았고, 이에 따라 해당 기술에 대한 스터디를 진행하게 되었습니다.

Virtualized List란?

: Virtualized List는 뷰포트, 사용자의 화면에 보이는 항목만 DOM에 렌더링하고, 보이지 않는 항목은 렌더링하지 않는 기법입니다. Virtualized List 적용전 테스트 환경 피드 상황

현재 저희 피드를 보시면 사용자에게는 한두 개의 피드만 보이지만, 실제 DOM 구조를 확인해보면 훨씬 더 많은 피드 요소들이 렌더링되고 있는 것을 확인할 수 있습니다.

즉, Virtualized List가 적용 되어있지 않을 경우 수십개, 많게는 수십만개의 피드가 렌더링되어 브라우저 렌더링 성능에 직접적인 부담을 주게 됩니다.

Virtualized List를 적용한다면

이런 상황에서 Virtualized List를 적용하게 된다면 실제 사용자가 보고있는 요소만 동적으로 DOM에 추가하여 브라우저가 처리해야 할 DOM 노드 수를 줄이고, 렌더링 성능을 최적화할 수 있을 것입니다.

Virtualized List 적용후 테스트 환경 피드 상황

현재 프롬에 Virtualized List가 필요한 이유

현재 프롬 운영환경에서는 많은 채널의 게시글이 지속적으로 누적되고 있습니다. 이는 성능 문제가 발생할 가능성이 높다는걸 알려주는데요,

실제 데이터를 통해 살펴 보자면 2025년 7월 9일 기준, 프로미스나인 피드 포스트는 107,717개였으나 2달 뒤인 9월 2일 기준, 프로미스나인 피드 포스트 140,426개로 약 4만개의 피드 포스트가 증가했습니다 ⬆️

일반적으로 화면에 500개 이상의 요소가 렌더링되는 상황에서는 가상화가 큰 효과를 발휘합니다.

따라서 프롬에 Virtualized List를 적용하면 스크롤 성능과 전반적인 사용자 경험을 더욱 안정적으로 개선할 수 있을 것입니다.

스터디 목표 및 진행

본격적인 스터디에 들어가기전 저희는 세가지의 목표를 정했습니다.

첫번째, Virtualized List의 개념과 성능 최적화 원리를 이해하고, @tanstack/react-virtual 라이브러리에 익숙해지기

두번째, 직접 구현을 통해 렌더링 최적화 기법 체득

세번째, 실제 서비스에 적용 가능한 컴포넌트까지 작성하기입니다.

위 목표를 바탕으로,

1주차엔 @tanstack/react-virtual 공식문서 를 통한 Virtualized List의 개념 정립후 해당 라이브러리, 기술을 우리 서비스에 도입했을때 발생할 수 있는 이슈나 우려사항을 공유했습니다.

2주차엔 프로젝트내 상황별로 어떤 방식의 접근을 해야 할지에 대한 고민과 논의를 진행했습니다.

• 가상화 방식이나 방법들 중 어떤걸 채택할지에 대한 고민과 논의 진행
  • 공식문서에 나와있는 예시는 지정된 특정 영역 안에서 스크롤을 해주는 방식으로 우리 프로젝트와는 맞지 않았음 → 특정영역이 아닌 화면 전체를 기준으로 스크롤해도 아이템 리스트 영역이 스크롤 되어야했음
    • useVirtualizer을 통해 특정 영역 스크롤을 먼저 구현해보고, useWindowVirtualizer로 윈도우 영역 에서 스크롤이 되도록 작업 진행
  • 높이가 정해져있는 영역은 작업에 큰 문제가 없었으나 높이가 아이템마다 다른 경우 공식문서에 나와있는dynamic 와 variable중 어떤걸 채택해야 효율적일지에 대한 고민
    • 아이템이 렌더링된 후 ref={virtualizer.measureElement}를 통해 높이를 추정할 수 있는 dynamic을 채택해서 작업 진행
      

3주차부터 6주차까지는 프로젝트에 실 적용을 해보는 시간을 가졌습니다.

고정된 높이에 한번에 전체 데이터 로드해서 보여주는 페이지, 무한 스크롤로 구현된 페이지 그리고 다양한 높이의 아이템이 있는 무한스크롤 페이지까지 다양한 케이스로 실습을 진행했습니다.

스터디 진행에서 겪은 어려움

저희는 이번 스터디에서 단순히 이론만 학습하는 데 그치지 않고, 실제 코드로 가상화 리스트를 구현하며 팀원 각자가 느낀 어려움을 함께 공유해봤습니다.

그 과정에서 아래와 같은 다양한 기술적 이슈를 마주했고, 이를 해결해 나가며 여러 인사이트를 얻을 수 있었습니다.

1. 레이아웃 계산 문제

: 한 줄에 한 개씩 배치할지, 두세 개씩 배치할지에 따라 계산 로직이 달라짐
→ 기존에 정의된 스타일을 useVirtualizer의 size 인수에 맞게 재정의하여 해결

2. 스크롤 중복 이슈

: 특정 영역에만 가상 리스트를 적용하는 방식 useVirtualizer 사용 시, 가상 리스트가 적용되는 영역과 그 외 영역이 분리되어 스크롤이 두 개 생기는 문제가 발생
→ useWindowVirtualizer를 사용하여 전체 윈도우 스크롤에 대응하도록 설정하여 해결

3. 높이 값 불균일 문제

: 아이템마다 높이가 달라 무한 스크롤 시 스크롤 위치 계산이 빠르고 정확하게 이루어지지 않아 어색한 움직임이 나타남
→ estimateSize로 추정 높이의 정확도를 높이고 measureElement으로 실제 높이를 측정 및 캐싱하여 해결

4. 스택뷰 환경 문제

: 스택뷰 형태로 노출되는 페이지에서 스크롤과 렌더링 동작이 매끄럽지 못함
→ 가상리스트 영역에 높이를 지정해줌으로써 해결

실습에 어려움이 있었지만 가상화(Virtualization)를 실제로 적용하면서 채널 및 스토어의 성능개선 가능성을 확인할 수 있었고 특히 스크롤 시 불필요한 DOM 렌더링을 최소화함으로써, 사용자 경험(UX) 측면에서도 의미 있는 성능 향상을 기대할 수 있었습니다.

실습 과정에서 마주한 다양한 문제들을 함께 고민하고 해결해 나가면서, 단순한 개념 학습을 넘어 실제 서비스 환경에서의 적용 가능성을 구체적으로 검증할 수 도 있었습니다.

이를 바탕으로 더 많은 사용자가 유입되더라도 안정적이고 부드러운 사용자 경험을 제공 할 수 있을 것으로 기대합니다.

다음 단계

스터디를 통해 Virtualized List의 가능성을 확인했으니, 다음 단계는

1. 가장 데이터가 많이 쌓인 팬피드에 우선 적용
2. CS 이슈로 제기된 “뒤로가기 시 스크롤 위치 보존” 구현으로 문제 해결

• Virtualized List의 scrollToIndex API 활용

3. 스토어 상품 리스트 적용

• 피드 적용 경험을 바탕으로 확대

4. 공통 컴포넌트화

• 프로젝트 전체에서 재사용 가능한 VirtualizedList 컴포넌트 개발

스터디를 마치며

이번 스터디를 통해 Virtualized List에 대한 기술적 가능성을 직접 확인할 수 있어서 저희 팀에 큰 의미가 있었습니다.

실제 프로젝트에 적용할 경우 성능 개선 효과를 기대해볼 수 있었고, 최근 CS로 제기된 스크롤 복원 문제 또한 Virtualized List의 특성을 활용해 해결할 수 있을 것으로 보였습니다. 단순히 문서나 책에 의존하지 않고 직접 실습해보는 과정이 특히 도움 되었습니다.

반면 6주간의 스터디에서 아쉬운 점도 있었는데요,

동적 높이를 가진 피드 리스트까지 완성도 있게 구현하지 못했고, 전반적으로 공식 문서에 대한 의존도가 높아 응용과 변형에 한계가 있었습니다. 또한 초기 목표였던 최종 컴포넌트 완성과 성능 측정까지 마무리하지 못했다는 점도 아쉬움으로 남습니다.

그럼에도 이번 경험을 통해 다음 스터디에서 더욱 현실적인 목표를 세우고 발전시켜 나갈 수 있을 것으로 기대합니다.

감사합니다