느린 React 컴포넌트 1초 만에 해결하기! (새로운 GitHub Storybook 애드온)

BBetter Stack
컴퓨터/소프트웨어AI/미래기술

Transcript

00:00:00GitHub에서 Storybook을 위한 매우 강력한 애드온을 출시했습니다. 이 애드온은
00:00:05컴포넌트 성능을 테스트하는 방식을 완전히 바꿔 놓을 것입니다.
00:00:07상세한 성능 패널이 포함되어 있으며, 다음과 같은 가치 있는 통찰력을 제공합니다.
00:00:12프레임 타이밍, 입력 응답성, 레이아웃 안정성, React 프로파일링, 메모리 부하 등
00:00:18다양한 지표를 측정할 수 있습니다.
00:00:19이번 영상에서는 이 애드온이 제공하는 기능들을 자세히 살펴보겠습니다.
00:00:23매우 흥미로운 내용이 될 테니, 바로 시작해 보시죠.
00:00:31시작하기 전에 간단한 질문을 하나 드리겠습니다.
00:00:32여러분은 “시프트 레프트(Shift-Left)” 성능 테스트가 무엇인지 아시나요?
00:00:35이것은 앱 컴포넌트의 성능을 개발 후순위가 아니라,
00:00:40개발 프로세스 초기에 테스트해야 한다는 개발 패러다임입니다.
00:00:45이 도구는 개발자가 초기에 올바른 판단을 내릴 수 있도록 특별히 제작되었으며,
00:00:50제품이 실제 출시되기 전에 컴포넌트가 어떻게 작동하는지 실시간으로 보여줍니다.
00:00:55따라서 Storybook 성능 패널은 컴포넌트가 브라우저의
00:01:00렌더링 엔진과 어떻게 상호작용하는지 정밀하게 보여줍니다.
00:01:02예를 들어, 프레임 타이밍을 추적하여 지터(Jitter), 즉 애니메이션을
00:01:07끊기게 만드는 프레임 간의 미세하고 불규칙한 간격을 식별합니다.
00:01:10또한 메인 스레드의 DOM 처리량(Churn)과 스래싱(Thrashing)을 모니터링합니다.
00:01:15DOM 처리량은 코드 내에서 불필요하게 요소를 생성, 삭제 또는 업데이트할 때 발생하며,
00:01:20스래싱은 스타일을 연달아 읽고 쓰는 바람에 브라우저가
00:01:25한 프레임 안에서 레이아웃을 여러 번 재계산해야 할 때 발생합니다.
00:01:30이 애드온은 어떤 프레임워크를 사용하든 잘 작동합니다.
00:01:33React를 사용 중이라면 렌더링 캐스케이드(Render Cascades) 같은 지표를 강조해 줍니다.
00:01:38이는 작은 상태 변화가 앱 전체에 거대한 재렌더링 파동을 일으키는 현상을 말하죠.
00:01:44또한 P95 소요 시간을 추적하여 평균값이 아닌,
00:01:50가장 느린 사용자가 겪는 최악의 시나리오를 보여줍니다.
00:01:52React를 사용하지 않더라도 유니버설 모드가 Vue, Svelte,
00:01:58또는 웹 컴포넌트에서 완벽하게 작동합니다.
00:01:59최상의 결과를 위해 Chrome이나 Edge 브라우저에서 실행하는 것을 권장합니다.
00:02:04이 지표들을 직접 확인할 수 있는 라이브 플레이북도 제공됩니다.
00:02:08예를 들어, 애니메이션 박스 예제에서는 애니메이션 도중에
00:02:13인라인 스타일 변경이 얼마나 일어나는지 정확히 추적할 수 있습니다.
00:02:16이 경우에는 모든 것이 양호해 보이네요.
00:02:18프레임 속도와 타이밍이 완벽하게 안정적입니다. 브라우저가
00:02:23스타일 업데이트를 무리 없이 처리하고 있다는 뜻이죠.
00:02:25하지만 대용량 리스트 예제는 이야기가 다릅니다.
00:02:29이 긴 리스트를 필터링할 때 몇 가지 위험 신호가 보입니다.
00:02:32먼저, 누적 레이아웃 이동(CLS) 수치가 매우 높게 치솟습니다. 이는
00:02:38로딩 시 요소들이 심하게 요동치며 사용자에게 불쾌한 경험을 준다는 뜻입니다.
00:02:43또한 DOM 처리량도 급증하는데, 브라우저가 수많은 노드를
00:02:49동시에 제거하고 다시 만드느라 과부하가 걸리고 있다는 증거입니다.
00:02:52이로 인해 프레임 드랍이 발생하며, 인터페이스의
00:02:57체감 속도와 부드러움이 크게 떨어지게 됩니다.
00:02:58엘리먼트 타이밍 예제에서는 'element timing' 속성이 있는 모든
00:03:04DOM 요소의 정확한 렌더링 시간을 측정합니다.
00:03:06이 기능은 히어로 콘텐츠나 CTA 버튼이 화면에 나타나는
00:03:11정확한 시점을 파악하는 데 매우 유용합니다. 단순한 페이지 로드 지표보다
00:03:17더 정확한 체감 성능 데이터를 얻을 수 있습니다.
00:03:21비싼 렌더링(Expensive Render) 예제에서 재렌더링 버튼을 누르면,
00:03:26P95 소요 시간이 급증하는 것을 볼 수 있습니다.
00:03:29무거운 자바스크립트 실행으로 인해 메인 스레드가 점유되어
00:03:34UI가 매우 느리게 반응하기 때문입니다.
00:03:36여기서 프레임 지터 경고도 볼 수 있는데, 이는 프레임 사이의
00:03:41시간 간격이 불규칙하게 요동치며 렌더링되고 있음을 나타냅니다.
00:03:44또한 총 차단 시간(TBT)도 높게 나타납니다.
00:03:47TBT는 중요한 경고 신호입니다. 메인 스레드가 오랫동안 차단되어
00:03:52사용자가 버튼 클릭이나 스크롤 같은 상호작용을
00:03:57전혀 할 수 없었다는 뜻이기 때문입니다.
00:03:58메모이제이션 낭비 예제에서도 비슷한 현상이 관찰됩니다.
00:04:03모든 요소를 불필요하게 재렌더링하면
00:04:08얼마나 심각한 지연이 발생하는지 보여줍니다.
00:04:09반면, 제대로 메모이제이션을 적용한 예제는
00:04:15얼마나 많은 연산을 절약할 수 있는지 보여줍니다.
00:04:16불필요한 렌더링을 건너뜀으로써 메인 스레드를 확보하고 프레임 속도를
00:04:2160fps로 고정하여 아주 매끄러운 화면을 제공합니다.
00:04:25렌더링 캐스케이드 예제에서는 useLayoutEffect 내부에서
00:04:30setState를 사용할 때 어떤 일이 일어나는지 보여줍니다.
00:04:31값 하나가 증가할 때마다 연쇄 반응이 일어납니다. useLayoutEffect는
00:04:37DOM 변경 직후, 브라우저가 화면을 그리기 전에 동기적으로 실행되기 때문입니다.
00:04:42여기서 상태 업데이트를 발생시키면, React는 컴포넌트 트리를 다시 처리하고
00:04:47브라우저는 사용자가 첫 번째 결과를 보기도 전에 레이아웃을
00:04:52두 번째로 다시 계산하게 됩니다.
00:04:53이는 매 프레임마다 작업을 두 배로 늘리는 좋지 않은 방식이며,
00:04:58단순한 상호작용조차 무겁게 느껴지게 만드는 렌더링 지연을 초래합니다.
00:05:02스타일 스래싱 예제에서도 중요한 관찰 결과를 보여줍니다.
00:05:07600개의 서로 다른 노드의 인라인 스타일을 동시에 변경하면 어떻게 될까요?
00:05:13스래싱 섹션에서 즉시 실행 중단(Stall) 경고가 나타나며,
00:05:18이는 브라우저가 리플로우(Reflow) 루프에 빠졌음을 의미합니다.
00:05:21자바스크립트가 여전히 변경을 가하는 동안 600개 요소의
00:05:26위치를 동시에 계산하려고 시도하는 것입니다.
00:05:27이로 인해 메인 스레드가 완전히 포화 상태가 되어
00:05:33프레임 지표가 매우 나빠지게 됩니다.
00:05:34이러한 예제들을 통해 Storybook 애드온을 사용하여 훨씬 정밀한 환경에서
00:05:38성능 병목 현상을 파악하는 방법을 이해하셨기를 바랍니다.
00:05:41물론 Lighthouse 같은 도구도 쓸 수 있지만, Lighthouse는 포괄적인 분석에 가깝습니다.
00:05:46개별 컴포넌트가 앱 성능에 미치는 영향을 이처럼
00:05:51외과 수술과 같은 정밀도로 보여주지는 못하죠.
00:05:53이 애드온을 다운로드하여 여러분의 Storybook에 추가하고 직접 사용해 보시길 권장합니다.
00:05:58직접 확인해 보시면 얻을 수 있는 통찰이 정말 많습니다.
00:05:59컴포넌트가 내부적으로 실제로 어떻게 작동하는지
00:06:03전체적인 그림을 볼 수 있게 될 것입니다.
00:06:06지금까지 새로운 GitHub Storybook 성능 패널 애드온에 대해
00:06:10간략하게 살펴보았습니다.
00:06:11여러분은 이 도구에 대해 어떻게 생각하시나요?
00:06:13그리고 여러분은 앱의 성능을 어떻게 측정하고 계신가요?
00:06:16아래 댓글로 여러분의 의견을 남겨주세요.
00:06:18이러한 기술적인 분석 영상이 마음에 드셨다면,
00:06:22좋아요 버튼을 눌러주시고 채널 구독도 잊지 마세요.
00:06:28지금까지 Better Stack의 Andres였습니다. 다음 영상에서 뵙겠습니다.

Key Takeaway

새로운 Storybook 성능 애드온은 개발자가 컴포넌트 제작 초기 단계에서 브라우저 렌더링 지표를 정밀하게 모니터링하여 복잡한 성능 문제를 즉각적으로 해결할 수 있게 돕습니다.

Highlights

GitHub에서 출시한 Storybook 전용 성능 패널 애드온의 주요 기능과 가치

개발 초기 단계에서 성능을 검증하는 '시프트 레프트(Shift-Left)' 패러다임의 중요성

프레임 타이밍, DOM 처리량, 스타일 스래싱 등 브라우저 렌더링 엔진과의 상세 상호작용 분석

React의 렌더링 캐스케이드 및 메모이제이션 유무에 따른 성능 차이 실증

Lighthouse와 차별화된 개별 컴포넌트 단위의 정밀한 성능 병목 현상 파악 능력

Timeline

Storybook 성능 애드온 소개 및 시프트 레프트 패러다임

GitHub에서 출시한 Storybook용 성능 패널 애드온의 강력한 기능들을 소개하며 영상이 시작됩니다. 이 도구는 프레임 타이밍, 입력 응답성, React 프로파일링 등 개발자가 놓치기 쉬운 세부 지표를 시각화하여 제공합니다. 특히 개발 후반이 아닌 초기 단계에서 성능을 테스트하는 '시프트 레프트' 접근 방식을 강조하며 제품 출시 전 실시간 피드백의 중요성을 설명합니다. 개발자는 이를 통해 컴포넌트가 브라우저 렌더링 엔진과 어떻게 상호작용하는지 정밀하게 파악할 수 있습니다. 성능 최적화의 시작점이 도구의 도입임을 명확히 보여주는 섹션입니다.

주요 성능 지표 및 브라우저 상호작용의 이해

애니메이션을 끊기게 만드는 '지터' 현상과 메인 스레드에 부담을 주는 DOM 처리량 및 스래싱 개념을 상세히 다룹니다. 스타일을 반복적으로 읽고 쓰는 과정에서 발생하는 레이아웃 재계산 문제를 지적하며 성능 저하의 원인을 분석합니다. React 사용자들을 위해 상태 변화가 큰 파동을 일으키는 '렌더링 캐스케이드' 지표를 설명하고 P95 소요 시간을 통해 최악의 사용자 경험을 추적할 것을 권장합니다. 이 애드온은 Vue, Svelte와 같은 다양한 프레임워크에서도 작동하는 유니버설 모드를 지원합니다. 최적의 분석 환경으로 Chrome과 Edge 브라우저 사용을 제안하며 기술적 기반을 다집니다.

라이브 플레이북을 통한 실전 성능 테스트 사례

실제 예제를 통해 정상적인 애니메이션과 문제가 있는 대용량 리스트의 성능 차이를 직접 비교합니다. 긴 리스트를 필터링할 때 발생하는 누적 레이아웃 이동(CLS)의 급증이 사용자 경험을 어떻게 해치는지 시각적으로 보여줍니다. 불필요한 DOM 노드의 생성과 삭제가 프레임 드랍을 유발하며 인터페이스의 부드러움을 저하시키는 과정을 설명합니다. 또한 'element timing' 속성을 활용하여 히어로 콘텐츠나 버튼이 화면에 나타나는 정확한 시점을 측정하는 유용한 팁을 제공합니다. 단순한 로딩 지표보다 실제 체감 성능 데이터가 왜 중요한지를 실례를 통해 입증합니다.

심각한 성능 병목 현상: TBT와 렌더링 지연

무거운 자바스크립트 실행으로 인해 발생하는 '비싼 렌더링'과 메인 스레드 점유 문제를 집중적으로 분석합니다. 총 차단 시간(TBT)이 높게 나타날 경우 사용자가 상호작용을 전혀 할 수 없는 심각한 상태임을 경고합니다. 메모이제이션을 적절히 적용했을 때 60fps를 유지하며 메인 스레드를 확보하는 극명한 대비 효과를 예시로 보여줍니다. React의 useLayoutEffect 내에서 setState를 사용할 때 발생하는 동기적 연쇄 반응의 위험성을 심도 있게 다룹니다. 이는 매 프레임마다 작업을 두 배로 늘려 단순한 클릭조차 무겁게 만드는 주요 원인이 됨을 강조합니다.

스타일 스래싱 분석 및 도구 활용 권장

수백 개의 노드 스타일을 동시에 변경할 때 브라우저가 리플로우 루프에 빠지는 '스타일 스래싱' 현상을 마지막 예제로 설명합니다. 이로 인해 메인 스레드가 포화 상태가 되어 성능 지표가 급격히 악화되는 과정을 보여주며 주의를 당부합니다. 저자는 Lighthouse가 전체적인 분석을 제공한다면 이 애드온은 외과 수술처럼 정밀하게 개별 컴포넌트의 문제를 진단한다고 평가합니다. 시청자들에게 직접 애드온을 설치하여 컴포넌트 내부의 작동 원리를 파악해 볼 것을 강력히 권장하며 마무리합니다. 댓글을 통해 성능 측정 방식에 대한 의견 공유를 제안하고 구독을 독려하며 인사를 전합니다.

Community Posts

View all posts