Section 7 React App Debugging
TIL1) React Strict Mode
React에서 제공하는 Strict Mode는 코드에서 잠재적인 문제를 미리 감지하기 위한 도구이다. 주로 개발 중에만 활성화되며, 성능 저하 없이 안전한 코드를 작성하는 데 도움을 준다.
주요 개념
Deprecated 라이프사이클 메서드 경고: componentWillMount, componentWillReceiveProps 등 더 이상 사용되지 않는 메서드가 감지된다.
불필요한 사이드 이펙트 감지: 렌더링 중 의도하지 않은 사이드 이펙트를 미리 경고해준다.
React 18 변화: React 18에서는 Strict Mode에서 useEffect가 두 번 호출되며, 사이드 이펙트를 더 쉽게 찾아낼 수 있다.
<React.StrictMode>
<App />
</React.StrictMode>
배운점
React Strict Mode는 처음에는 다소 번거롭다고 느껴질 수 있지만, 사전 예방적 디버깅 도구로서 개발 시 많은 문제를 미리 방지할 수 있다는 점에서 매우 유용하다.
TIL2) React Devtools
React Devtools는 컴포넌트 트리, 상태, props 등을 실시간으로 확인하며 애플리케이션을 디버깅할 수 있는 브라우저 확장 프로그램이다. React 애플리케이션의 상태 변화를 쉽게 추적할 수 있게 해준다.
주요 개념
컴포넌트 구조 시각화: 컴포넌트 트리를 시각적으로 확인할 수 있으며, 각 컴포넌트의 props와 state를 실시간으로 볼 수 있다.
Re-render 감지: 어떤 컴포넌트가 다시 렌더링되었는지 확인할 수 있어 성능 최적화에 큰 도움을 준다.
Hooks 디버깅: 훅의 상태를 추적하며 어떤 값이 변경되었는지 쉽게 파악할 수 있다.
Chrome이나 Firefox에 React Devtools를 설치한 후,
개발자 도구의 React 탭에서 애플리케이션을 분석할 수 있다.배운 점
Devtools 덕분에 컴포넌트의 상태와 props를 빠르게 파악할 수 있었고, 특히 성능 이슈가 발생했을 때 어떤 컴포넌트가 자주 리렌더링되는지 쉽게 찾을 수 있어 큰 도움이 됐다.
Learned
이번 Section 7에서 React의 디버깅 도구들을 사용해보면서 많은 깨달음을 얻었다. React Strict Mode와 React Devtools 모두 처음에는 단순한 도구처럼 느껴졌지만, 실제로 사용하면서 그 진가를 알게 되었다.
Strict Mode는 마치 '개발자용 안전망'이라고 할 수 있었다. 특히 React 18에서 훅이 두 번 호출되면서 사이드 이펙트를 감지하는 부분이 인상 깊었다. 처음에는 렌더링이 두 번 일어나서 불필요한 성능 저하를 유발하는 것처럼 느껴졌지만, 나중에 이를 통해 나도 모르게 잘못된 패턴을 잡아내는 과정을 보면서 매우 유용하다고 느꼈다. 가령, 불필요한 비동기 작업이나 DOM 조작을 useEffect에서 무심코 넣었다가 Strict Mode에서 두 번 호출되며 잡힌 경험이 있었다. 이런 점을 통해 더 신중하게 코드를 작성하게 됐고, 장기적으로는 코드 퀄리티가 크게 향상될 것 같다.
React Devtools는 상태를 추적하고 props를 실시간으로 확인할 수 있어서 복잡한 상태 관리 로직을 디버깅할 때 유용했다. 특히 컴포넌트가 언제 다시 렌더링되는지 확인하면서 성능 최적화에 대한 실질적인 인사이트를 얻을 수 있었다. React가 제공하는 디버깅 도구들이 강력한 만큼, 이를 잘 활용할 수 있는 역량을 더 키워야 한다는 생각이 들었다.
모두 강의의 자료를 참고로 확인했고, 직접 프로젝트를 실행할때 사용하고 싶다.
질문 준비하기
React Strict Mode와 최적화 문제
Strict Mode에서 useEffect가 두 번 호출되는 부분은 버그를 감지하는 데 유용하긴 하지만, 성능에 영향을 줄 수 있다는 우려가 생깁니다. 이러한 성능 문제를 최소화하면서 Strict Mode를 사용하는 최적의 방법은 무엇일까요? 실제로 Strict Mode로 인해 발견된 문제를 어떻게 해결해 나가셨는지 사례가 궁금합니다.
React 18의 Concurrent Mode
React 18에서 도입된 Concurrent Mode는 아직 익숙하지 않지만, 성능을 크게 개선할 수 있다고 들었습니다. 실제로 Concurrent Mode를 프로젝트에 적용해보셨는지, 그렇다면 어떤 시나리오에서 가장 효과적이었는지 궁금합니다.
특히 Strict Mode와 연계해서 Concurrent Mode가 어떻게 성능 최적화에 기여하는지 설명해주시면 감사하겠습니다.
작성해주신 것처럼, 리액트 프로젝트에서 주요 관심사 중 하나는 렌더링 횟수를 줄이는 건데요!
state에 변화가 있거나 특정 함수를 실행했을 때 일어나는 렌더링의 범위가 작을수록, 횟수가 적을수록 사용자 입장에서는 좋은 성능을 가졌다고 느껴지기 때문입니다.
개발 환경에서 Strict Mode를 켜고 작업하면 두 배의 렌더링이 일어나기 때문에 실제 배포할 사이트에 비해서 성능이 안 좋게 느껴지는 경우가 있어요. 하지만 일반적인 경우 두 배의 성능 차이는 사용자가 인지할 만큼 큰 성능 차이가 아니어야 합니다.(0.1초와 0.2초 간 차이는 크지 않으므로) 그렇기 때문에 Strict Mode에서도 성능 문제가 느껴지지 않는 것을 목표로 작업하고 있습니다. 예외가 되는 경우는 성능 문제를 감안하더라도 굉장히 많은 수의 컴포넌트를 렌더해야 하는 경우 등이 있는데, 이런 경우 간혹 예외적으로 배포 이후 환경을 기준으로 작업하기도 합니다.
Concurrent Mode는 Strict Mode와는 조금 차이가 있는 컨셉인데요!
웹사이트들은 과거에 비해서 서버와의 통신이나 복잡한 로직을 실행하는 경우가 많아졌기 때문에 비동기 작업들을 더 효율적으로 실행해야 하고, 때에 따라 렌더링을 잠시 중단하고 싶은 경우들도 생겼습니다. Concurrent Mode는 이런 부분에 대한 니즈를 충족하기 위해서 렌더링 방식에 변경을 주는 모드입니다.
Concurrent Mode를 켜면 사용할 수 있는 새로운 기능들이 있지만, 기본적으로는 React가 실행되는 방식 자체가 달라지는 것이기 때문에 별도로 기능들을 이용하지 않아도 성능 개선이 되는 부분이 존재합니다. 오르카에서는 이 모드에서 제공하는 기능인 Suspense를 비교적 적극적으로 활용하고 있는데, 이 부분에 대해서는 한 번 찾아보고 오시면 코드랑 함께 구체적으로 얘기해보면 좋을 것 같아요!