Next.js 프로젝트(v12)에서 styled-components를 적용하며 발생한 스타일 FOUC(Flash of Unstyled Content) 문제와 이를 해결한 과정을 정리했습니다. 문제 상황: SSR 환경에서의 스타일 미적용 Next.js는 기본적으로 서버 사이드 렌더링(SSR) 을 지원하며, 초기 페이지 로드 시 HTML을 미리 생성해 클라이언트에 전달합니다. 프로젝트 초기에 아래와 같은 문제가 발생했습니다: 새로고침 시 스타일이 적용되지 않은 HTML이 먼저 렌더링됨 이후 JS가 로드되면서 styled-components 스타일이 적용됨 사용자 입장에서 순간적으로 깨진 UI가 보이는 경험을 하게 됨 이는 흔히 말하는 FOUC (Flash of Unstyled Content) 플리커 현상으로, SSR 환경에서 styled-components를 사용할 때 자주 발생하는 이슈입니다. ...
이전 글에서 클라이언트 상태와 서버 상태를 분리하는 과정에서 Context API 대신 Recoil을 도입하게 된 이유를 정리한 바 있습니다. 이번 글에서는 해당 구조가 실제 프로젝트에서 어떻게 적용되었는지, 그리고 Recoil을 사용함으로써 성능 측면에서 어떤 개선 효과가 있었는지를 자세히 공유하려고 합니다. 왜 Recoil이 필요했는가 이전 글에서 언급했듯이 처음에는 Context API만으로도 충분해 보였습니다. 작은 단위의 상태들을 중앙에서 관리하고, 빠르게 구조화할 수 있었기 때문이다. 하지만 프로젝트가 커지고 기능이 쌓이면서, Context를 사용하는 컴포넌트가 많아지고, 하나의 값 변경에도 여러 곳에서 렌더링이 발생하기 시작했다. ...
연결 단계에서 발견된 간헐적 연결 문제 WebRTC는 RTCPeerConnection과 ICE 프로토콜을 통해 두 클라이언트 간 최적 경로를 탐색한다. const peerConnection = new RTCPeerConnection({ iceServers: [{ urls: "example.google.com:19302" }], }); peerConnection.onicecandidate = (event) => { if (event.candidate) { socket.emit("ice-candidate", event.candidate); } }; peerConnection .createOffer() .then((offer) => peerConnection.setLocalDescription(offer)) .then(() => { socket.emit("offer", peerConnection.localDescription); }); 해외 네트워크 환경을 사용하는 사용자들의 연결 기능에서 다음과 같은 현상이 간헐적으로 발생했다: 영상이 연결되지 않거나 상대가 보이지 않음 상태 동기화나 메시지 수신이 실패함 네트워크 문제인지 브라우저 문제인지 식별하기 어려움 사용자 입장에서는 연결 상태에 대한 명확한 피드백이 없어 혼란을 느낌 📌 VPN 사용 환경에서의 연결 실패 또한 일부 사용자들이 VPN을 활성화한 상태에서 접속하는 경우, WebRTC 연결이 실패하는 이슈가 존재했습니다. ...
이전 글에서 Recoil 활용해 클라이언트 상태를 정리했던 이야기를 남긴 적이 있다. 이번에는 같은 프로젝트 내에서 서버 상태를 다루는 방식에 대해 정리해보려 한다. Context API를 빠르게 선택했던 이유 처음 프로젝트를 시작할 때는 아주 간단한 요구사항만 있었기 때문에, 굳이 무거운 상태 관리 라이브러리를 도입하지 않고 Context API만으로 충분하다고 판단했다. 속도를 중시한 결정이었다. 실제로 빠르게 결과물을 만들 수 있었고, 배포도 문제없이 진행됐다. 하지만 이후 사업이 확장되며 기능이 하나씩 추가되기 시작했고, 그때부터 context 구조가 무겁게 느껴지기 시작했다. 추가되는 context마다 리렌더링 범위가 넓어졌고, UI 단위에서만 필요한 데이터까지 전역에 얹히는 구조가 되었다. ...
하울링은 왜 생기는가? 하울링은 간단히 말하면, 자신의 마이크에서 들어온 소리가 다시 자신의 스피커로 출력되고, 그게 다시 마이크로 입력되면서 무한 루프를 타는 상황입니다. WebRTC는 getUserMedia로 마이크와 카메라를 활성화하고, 실시간으로 stream을 주고받기 때문에 이런 구조에서는 오디오 루프가 쉽게 생길 수 있습니다. 여러 방법을 시도해봤습니다 처음에는 아래와 같은 해결책들을 시도했습니다: 연결 직후 마이크를 자동으로 mute 처리 local stream과 remote stream을 분리해 렌더링 오디오 트랙만 따로 추적해서 제어 <audio muted /> 설정 (그러나 의도대로 안 되는 경우도 많음) 하지만 완벽하게 해결되진 않았고, 상황에 따라 다시 하울링이 발생했습니다. ...