안녕하세요! 프론트엔드/풀스택 실무에서 자주 부딪히는 “JWT를 어디에 보관할 것인가” 문제를 정리했습니다. 저장 위치별 보안/UX 트레이드오프, 실제로 일어나는 탈취(steal) 시나리오, 그리고 탈취 되었을 때 어떻게 눈치채고 대응할지까지 바로 적용 가능한 체크리스트로 담았습니다.저장 위치별 비교구분localStoragesessionStorageCookie (HttpOnly 권장)접근성JS로 window.localStorage 읽기/쓰기탭 수명(탭 닫히면 소멸)JS 접근 불가(HttpOnly)·자동 전송(도메인/경로 일치 시)지속성브라우저 종료 후에도 유지탭 살아있는 동안만만료 시각/세션/영구 선택 가능XSS에 대한 노출높음(스크립트가 읽을 수 있음)높음낮음(HttpOnly면 읽기 불가)CSRF 위험..

서론이번 글에서는 아직 다루지 않은 SSR(Server-Side Rendering) 페이지의 풀 페이지 캐싱에 대해 이야기합니다.SSR은 매 요청마다 서버에서 HTML을 생성하므로 항상 최신 데이터를 보장하지만, 그만큼 성능 부담이 큽니다.그렇다면 SSR 페이지를 캐싱하면서도 신선함을 유지할 수 있는 방법은 무엇일까요?SSR의 본질 (Next.js 15 기준)SSR이 하는 일매 요청마다 서버에서 HTML 생성데이터는 요청 시점에 가져옴SEO 친화적, 항상 최신 상태 반영적합한 경우자주 변하는 데이터사용자별 맞춤형 페이지인증 필요 페이지성능 문제가 발생하는 경우모든 요청이 DB/API 호출을 동반고트래픽 시 서버 부하 급증TTFB(Time to First Byte) 지연따라서 풀 페이지 캐싱은 필수적인 최..

리액트에서 useEffect와 setInterval을 함께 쓰다 보면, 분명 1초마다 증가시키라고 했는데 상태가 갱신되지 않거나 0에 멈춰 있는 현상을 자주 만납니다. 원인은 대부분 “stale closure(오래된 클로저)” 입니다. 핵심만 간단히 정리합니다.TL;DR문제 원인: 빈 의존성 배열 []로 등록한 이펙트는 최초 렌더의 count를 클로저로 캡처합니다. 그 뒤 타이머 콜백은 계속 “초기값”만 봅니다.정석 해결: 다음 상태가 이전 상태에 의존하면, 항상 함수형 업데이트 setState(prev => ...)를 사용하세요.필수: 타이머는 반드시 정리(cleanup)합니다.문제 코드 import { useEffect, useState } from 'react' export default fun..

리액트 프로젝트를 하다 보면 꼭 한 번은 만나게 되는 상황이 있습니다.컴포넌트 트리 어딘가에서 에러가 터지면, 앱 전체가 그대로 하얀 화면(whitescreen of death)이 되어버리는 순간이죠.이럴 때 사용자를 보호해주는 최후의 안전망이 바로 ErrorBoundary입니다.그런데 재미있는 사실 하나. 함수 컴포넌트 전성시대인 지금도, ErrorBoundary만은 클래스 컴포넌트로만 작성해야 합니다."왜 아직도 클래스일까?" 오늘은 그 이유와 한계, 그리고 실전 적용 팁을정리해봅니다.TL;DR (Too Long; Didn’t Read)Error Boundary는 여전히 클래스 전용라이프사이클(getDerivedStateFromError, componentDidCatch)로만지원됩니다.함수형 훅으로 ..

브라우저/Node.js 런타임에서 비동기 코드의 실행 순서를 정확히 이해하는 것은 디버깅과 성능 최적화의 출발점입니다. 특히 마이크로태스크 큐는 렌더링 타이밍과 상태 일관성에 직접적인 영향을 주므로, 실무에서 정확한 모델을 갖추는 것이 중요합니다.핵심 개념 정리Call Stack: 자바스크립트가 함수를 동기적으로 실행하는 스택.Web APIs(환경): 타이머, DOM, Fetch 등 비동기 작업이 대기하는 영역.Task Queue(매크로태스크 큐): setTimeout, setInterval, setImmediate(Node) 등이 들어가는 큐.Microtask Queue(마이크로태스크 큐): Promise.then/catch/finally, queueMicrotask, MutationObserver 등..

Next.js는 App Router 기반으로 서버 컴포넌트와 데이터 페칭을 통합하면서캐싱 체계를 전면 재설계하였습니다. 본 글에서는 실무에서 가장 자주사용되는 네 가지 축, 즉 Request Memoization, Client RouterCache, Data Cache, Full Route Cache를 중심으로 원리를정리하고, 실행 가능한 예제와 함께 권장되는 베스트 프랙티스를 제시합니다.목차Request Memoization: 동일 요청 중복 제거Client Router Cache: 탐색 성능 최적화Data Cache: fetch 응답의 서버 캐싱 및 검증Full Route Cache: 페이지 단위 정적 캐싱(ISR 포함)실무 팁/주의사항, 비교 표, 참고 자료캐싱 전반 개념 맵서버 단계: Reques..

프론트엔드 면접에서 자주 듣는 질문 중 하나가 "의존성 주입(Dependency Injection, DI) 경험이 있나요?"입니다.이 질문은 단순히 특정 DI 프레임워크를 써봤냐를 묻는 게 아니라, 코드 구조와 의존성 관리 문제를 이해하고 있는지를 확인하는 의도에 가깝습니다.1. 의존성 문제(Dependency Problem)란?소프트웨어에서 어떤 클래스나 모듈이 다른 객체를 직접 생성하거나 강하게 참조하면 문제가 발생합니다.class UserService { private api = new ApiClient(); // 직접 생성 → 강한 결합}이 경우:테스트하기 어려움 (ApiClient를 Mock으로 교체 불가)재사용성이 낮음 (다른 구현체로 교체하기 힘듦)결합도가 높아 유지보수가 어려움즉, 의존성..

의의와 배경useRef는 리렌더링 간에도 유지되는 가변 저장소를 제공한다. 값 변경이 렌더를 유발하지 않는다는 점에서 useState와 구분되며, 컴포넌트 인스턴스마다 독립적으로 유지된다는 점에서 단순 let과도 다르다. 주로 DOM 접근, 타이머/외부 핸들 저장, 최신 값 보관 등 렌더와 무관한 정보를 관리할 때 사용한다.목차개념 정리: 렌더링 모델과 ref.current비교: useState vs useRef vs let사용 시나리오와 코드 예시주의사항(안티패턴)체크리스트결론개념 정리useRef(initial)는 { current: T } 형태의 객체를 반환한다.ref.current를 변경해도 컴포넌트는 리렌더링되지 않는다.같은 컴포넌트 인스턴스에서 렌더 간 동일한 ref 객체가 유지된다.의도: “렌..

의의와 배경Core Web Vitals는 구글이 웹 사용자 경험을 정량화하기 위해 정의한 핵심 성능 지표다. 이 지표는 실제 사용자 경험을 직접적으로 반영하며 검색 순위(SEO)에도 영향을 미친다. 프론트엔드 개발자는 필수적으로 이해하고 지속적으로 관리해야 한다.목차개요: 지표 정의와 목표 기준LCP: 의미, 원인, 개선 체크리스트INP: 의미, 원인, 개선 체크리스트CLS: 의미, 원인, 개선 체크리스트측정 방법: Lab vs Field, 실측 코드 예시실무 팁/흔한 실수체크리스트와 결론개요Core Web Vitals는 세 가지 지표로 구성된다.지표의미권장 기준주의 구간LCP (Largest Contentful Paint)가장 큰 콘텐츠가 화면에 보이기까지의 시간≤ 2.5s2.5s ~ 4.0sINP (..

프론트엔드를 하다 보면 상태 변경과 데이터 변환이 정말 자주 등장한다. 이때 함수형 프로그래밍(FP)은 코드를 더 예측 가능하고 테스트하기 쉽게 만든다. 이번 글은 핵심을 짧게 정리하고, 코드 예제로 바로 확인한다. 실제로 언제 FP가 맞는지도 함께 본다.1. 기본 개념 한 줄 요약함수형 프로그래밍은 순수 함수와 불변성에 기반한 선언적 스타일이다.동일 입력 → 동일 출력, 외부 상태 변경 없음. 원본은 건드리지 않고 새 값을 만든다.2. 순수 함수 vs 부수효과, 코드로 비교 // 순수: 동일 입력이면 항상 동일 출력, 외부 상태 변경 없음 function add(a: number, b: number): number { return a + b; } // 비순수: 외부 상태(total)를 변경..