dev.jung

React useEffect 의존성 배열과 stale closure 이해하기

React를 배우다 보면 useEffect의 두 번째 인자인 의존성 배열을 자주 만납니다. 특히 []를 넣으면 “처음 한 번만 실행된다”고 외우기 쉽지만, 실무에서는 이 이해만으로 부족합니다.useEffect는 렌더링 이후 React 바깥의 시스템과 컴포넌트를 동기화할 때 쓰는 Hook입니다. 여기서 외부 시스템은 타이머, 이벤트 리스너, 네트워크 구독, 브라우저 API처럼 React 밖에서 살아 있는 대상을 뜻합니다.의존성 배열은 실행 횟수 옵션이 아니다의존성 배열은 effect가 어떤 값에 반응해야 하는지를 React에 알려주는 목록입니다. props, state, 컴포넌트 안에서 만든 변수나 함수처럼 렌더마다 바뀔 수 있는 값이 effect 안에서 쓰인다면, 그 값은 의존성 후보입니다.따라서 []는..

React Hydration과 Selective Hydration 쉽게 이해하기

Next.js처럼 서버 렌더링을 사용하는 React 앱을 다루다 보면 hydration mismatch 경고를 한 번쯤 만나게 됩니다. 단순한 경고처럼 보이지만, 실제로는 서버가 만든 HTML과 브라우저에서 React가 처음 계산한 화면이 서로 맞지 않는다는 신호입니다.이번 글에서는 hydration이 무엇인지, 왜 서버와 클라이언트의 첫 렌더 결과가 같아야 하는지, 그리고 React 18 이후의 selective hydration이 어떤 문제를 줄이려는지 정리해보겠습니다.Hydration이란?Hydration은 서버가 먼저 만들어 둔 HTML에 React의 이벤트와 상태를 연결하는 과정입니다.서버 렌더링으로 내려온 HTML은 처음에는 정적인 마크업에 가깝습니다. 화면은 보이지만, 아직 버튼 클릭이나 입..

Next.js loading.tsx와 Suspense 차이 이해하기

Next.js App Router를 쓰다 보면 loading.tsx와 를 함께 만나게 됩니다. 둘 다 “로딩 중에 무엇을 보여줄 것인가”를 다루기 때문에 처음에는 같은 역할처럼 보입니다.하지만 실제로는 적용되는 위치가 다릅니다. loading.tsx는 Next.js 라우트 세그먼트 단위의 로딩 UI이고, 는 React 컴포넌트 트리 안에서 특정 영역을 기다리게 만드는 경계입니다.핵심은 간단합니다. “페이지 전체를 기다릴 것인가, 페이지 안의 일부만 기다릴 것인가”를 구분하는 것입니다.loading.tsx는 라우트 단위의 기본 로딩 화면loading.tsx는 Next.js App Router의 파일 규칙입니다. 특정 라우트 세그먼트에 loading.tsx를 두면, 해당 세그먼트의 페이지가 준비되는 동안 N..

Next.js revalidateTag와 updateTag 차이 정리

Next.js App Router를 쓰다 보면 서버에서 가져온 데이터를 캐시하고, 필요한 순간에만 다시 갱신해야 하는 상황이 자주 생깁니다. 게시글 목록, 상품 재고, 공지사항처럼 “항상 새로 가져오면 비싸지만, 바뀌었을 때는 빨리 반영되어야 하는 데이터”가 대표적입니다.이때 자주 등장하는 개념이 revalidate, revalidateTag, updateTag입니다. 이름은 비슷하지만 역할은 다릅니다. 핵심은 시간 기준으로 오래된 데이터를 갱신할 것인지, 태그 기준으로 특정 데이터만 무효화할 것인지, 사용자 액션 직후 바로 새 값을 보장할 것인지입니다.revalidate는 시간 기반 캐시 정책이다revalidate: 60은 캐시된 데이터를 60초 동안 재사용하겠다는 뜻입니다. 이 시간 안에는 같은 데이..

Next.js Server Component와 Client Component 기준

요약: Next.js App Router에서 Server Component와 Client Component를 나누는 기준을 실행 위치, 상호작용, props 직렬화 관점에서 정리합니다. use client를 언제 붙여야 하는지 간단한 카운터 예제로 확인합니다.Next.js App Router를 쓰다 보면 가장 자주 만나는 질문이 있습니다. “이 컴포넌트에 use client를 붙여야 하나?”입니다. 결론부터 말하면 기준은 파일 위치가 아니라 어느 런타임에서 실행되어야 하는가입니다.Server Component는 서버에서 데이터와 HTML을 준비하는 역할에 가깝고, Client Component는 브라우저에서 상태와 상호작용을 담당합니다. 이 경계를 이해하면 use client 에러, 이벤트 핸들러 전달 ..

CORS와 Preflight 요청, 헷갈리는 이유와 실무 디버깅법

프론트엔드 개발을 하다 보면 한 번쯤은 CORS 오류를 만납니다. API 서버는 분명 정상인데 브라우저 콘솔에는 에러가 뜨고, Network 탭에서는 요청이 성공한 것처럼 보여 더 헷갈리기도 합니다.이 글에서는 CORS를 “요청이 막히는 문제”로만 보지 않고, 브라우저가 응답을 JavaScript에 공개해도 되는지 판단하는 규칙으로 정리해보겠습니다. 함께 자주 등장하는 preflight 요청도 실제 요청 전에 무엇을 확인하는 절차인지 살펴봅니다.CORS를 이해하려면 Same-Origin Policy부터 봐야 한다브라우저 보안의 기본값은 Same-Origin Policy입니다. 같은 출처에서 온 스크립트만 응답을 자유롭게 읽을 수 있다는 규칙입니다.여기서 출처는 보통 다음 세 가지 조합으로 판단합니다.프로..

HTTP 캐시 재검증 쉽게 이해하기: no-cache, no-store, 304 차이

HTTP 캐시를 공부하다 보면 가장 자주 헷갈리는 표현이 no-cache와 no-store입니다. 이름만 보면 둘 다 “캐시하지 말라”는 뜻처럼 보이지만, 실제 동작은 꽤 다릅니다.핵심부터 말하면 no-store는 응답을 저장하지 말라는 뜻이고, no-cache는 저장은 하되 사용하기 전에 서버에 다시 확인하라는 뜻입니다. 그리고 이 확인 과정에서 리소스가 바뀌지 않았다면 서버는 304 Not Modified를 응답해 본문 전송을 생략할 수 있습니다.HTTP 캐시는 “저장”보다 “언제 재사용할지”가 중요하다HTTP 캐시는 한 번 받은 응답을 다음 요청에서 다시 사용할 수 있게 해주는 계층입니다. 하지만 중요한 건 단순히 저장 여부가 아닙니다. 더 중요한 질문은 이것입니다.저장된 응답을 지금 그대로 써도 ..

브라우저 렌더링과 FOUC, 왜 화면이 흔들릴까

웹페이지를 열었을 때 잠깐 기본 스타일로 보이다가, 곧바로 디자인이 바뀌는 장면을 본 적이 있을 겁니다. 버튼 크기가 달라지고, 배경색이 바뀌고, 글꼴이나 레이아웃이 뒤늦게 정리되는 현상입니다.이런 현상을 보통 FOUC, 즉 Flash of Unstyled Content라고 부릅니다. 말 그대로 스타일이 적용되지 않은 콘텐츠가 순간적으로 보이는 문제입니다.단순히 “화면이 예쁘지 않다”의 문제가 아닙니다. 브라우저가 첫 화면을 그리기 전에 필요한 스타일을 제때 확보하지 못했고, 그 중간 상태가 사용자에게 노출됐다는 뜻입니다.브라우저는 어떻게 첫 화면을 그릴까브라우저는 HTML을 받으면 먼저 문서를 파싱해서 DOM을 만듭니다. 동시에 CSS를 읽어 CSSOM을 구성합니다. 이후 DOM과 CSSOM을 조합해 ..

브라우저 이벤트 루프: task, microtask, rAF 차이

자바스크립트 코드는 위에서 아래로 실행되는 것처럼 보이지만, 브라우저 안에서는 조금 더 복잡한 순서로 움직입니다. 특히 Promise.then, setTimeout, requestAnimationFrame을 함께 쓰면 “왜 이 코드가 먼저 실행되지?”라는 상황을 자주 만나게 됩니다.핵심은 브라우저가 작업을 크게 task, microtask, 렌더링 단계로 나누어 처리한다는 점입니다. 이 차이를 이해하면 클릭 후 UI가 늦게 바뀌는 이유, setTimeout(0)이 바로 실행되지 않는 이유, requestAnimationFrame을 언제 써야 하는지 훨씬 명확해집니다.한 줄로 정리하기task는 브라우저가 처리하는 큰 작업 단위입니다. microtask는 현재 task가 끝난 직후 먼저 비워지는 우선 대기열..

requestAnimationFrame으로 DOM 읽기와 쓰기 분리하기

requestAnimationFrame으로 DOM 읽기와 쓰기 분리하기프론트엔드 성능을 이야기할 때 requestAnimationFrame은 자주 등장합니다. 하지만 단순히 “애니메이션에는 rAF를 쓰면 된다” 정도로만 이해하면 실제 성능 개선으로 이어지기 어렵습니다.중요한 건 requestAnimationFrame 자체보다 브라우저가 언제 레이아웃을 계산하고, 언제 화면에 반영하는지를 예측 가능하게 만드는 것입니다. 특히 DOM을 수정한 직후 레이아웃 값을 읽는 패턴은 성능 문제의 흔한 원인이 됩니다.requestAnimationFrame은 언제 실행될까?requestAnimationFrame은 브라우저가 다음 화면을 그리기 직전에 콜백을 실행하도록 예약하는 API입니다.requestAnimationF..

React 렌더링 비용과 브라우저 렌더링 비용의 차이

프론트엔드 성능 최적화를 하다 보면 “렌더링 비용을 줄인다”는 말을 자주 듣습니다. 그런데 여기서 말하는 렌더링이 항상 같은 의미는 아닙니다.React에서 말하는 렌더링 비용과 브라우저가 실제 화면을 그리는 렌더링 비용은 서로 다른 계층의 문제입니다. 이 둘을 구분하지 못하면 최적화 방향이 쉽게 빗나갑니다.예를 들어 React Profiler에서 특정 컴포넌트가 불필요하게 자주 렌더링되는 상황인데 CSS 속성만 조정하거나, 반대로 레이아웃 계산이 병목인데 React.memo만 붙이는 식의 실수가 생길 수 있습니다.React 렌더링 비용이란?React 렌더링 비용은 컴포넌트 트리 안에서 발생하는 비용입니다.상태나 props가 바뀌면 React는 어떤 컴포넌트를 다시 계산해야 하는지 판단하고, 컴포넌트 함수..

React Context와 useSyncExternalStore 차이 이해하기

React에서 전역 상태를 다루다 보면 Context와 useSyncExternalStore를 함께 마주치게 됩니다. 둘 다 여러 컴포넌트에서 값을 읽는 데 쓰일 수 있어서 비슷해 보이지만, 실제 역할은 꽤 다릅니다.한 줄로 정리하면 이렇습니다. Context는 React 트리 안에서 값을 전달하는 도구이고, useSyncExternalStore는 React 바깥에서 변하는 값을 React 렌더링 흐름에 맞게 구독하는 도구입니다.Context는 값을 전달하는 도구다React Context는 props를 여러 단계로 계속 넘기지 않아도 하위 컴포넌트에서 공통 값을 읽을 수 있게 해줍니다. 테마, 로그인 사용자, 언어 설정, 앱 전역 설정처럼 여러 컴포넌트가 함께 알아야 하는 값을 내려줄 때 유용합니다.하지..