시리즈 마지막 편입니다. 이번에는 코드 이야기가 아니라 프로젝트를 만들면서 느낀 점, 그리고 실제 프로덕션 트레이딩 플랫폼을 만든다면 어떤 점들을 더 고려해야 하는지 정리해봤습니다.전체 소스코드는 GitHub에 공개되어 있습니다.git clone https://github.com/kimkuns91/upbit-realtime-dashboard.gitcd upbit-realtime-dashboardnpm install && npm run dev1. 왜 이 프로젝트를 만들었는가평소에 궁금했던 게 있었습니다. 주식이든 코인이든, 트레이딩 화면을 보면 숫자가 쉴 새 없이 바뀝니다. 호가창, 체결 내역, 캔들 차트가 동시에 움직입니다. 이걸 프론트엔드에서 어떻게 처리하는 걸까?React로 일반적인 CRUD 앱을 만..

업비트 실시간 대시보드 시리즈 마지막 편입니다. 호가창(Order Book)을 3가지 방식으로 구현하고 실제 성능을 비교해봤습니다.전체 소스코드는 GitHub에 공개되어 있습니다. /benchmark 페이지에서 3가지 방식의 성능 차이를 직접 확인할 수 있습니다.git clone https://github.com/kimkuns91/upbit-realtime-dashboard.gitcd upbit-realtime-dashboardnpm install && npm run dev# http://localhost:3000/benchmark 접속1. 왜 호가창이 어려운가?호가창은 프론트엔드에서 구현 난이도가 가장 높은 컴포넌트 중 하나입니다. 이유는 단순합니다.업비트 WebSocket으로 초당 10~20회 호가 ..

업비트 실시간 대시보드 시리즈 2편입니다. 이전 글에서 WebSocket 파이프라인을 구축했고, 이번에는 그 위에 캔들 차트를 올립니다. REST API로 과거 200개 캔들을 불러오고, WebSocket 체결 데이터로 마지막 캔들을 실시간 업데이트하는 구조입니다.전체 소스코드는 GitHub에 공개되어 있습니다.git clone https://github.com/kimkuns91/upbit-realtime-dashboard.gitcd upbit-realtime-dashboardnpm install && npm run dev1. 왜 TradingView Lightweight Charts인가?금융 차트 라이브러리를 고를 때 D3.js, Recharts, ECharts 등을 검토했습니다. 결론은 Lightwe..

업비트 Public WebSocket API를 사용해서 실시간 암호화폐 트레이딩 대시보드를 만들어본 기록입니다. 이번 1편에서는 WebSocket 연결부터 React 훅으로 래핑하는 과정까지 다룹니다.전체 소스코드는 GitHub에 공개되어 있습니다. 직접 클론해서 돌려보실 수 있습니다.git clone https://github.com/kimkuns91/upbit-realtime-dashboard.gitcd upbit-realtime-dashboardnpm install && npm run dev1. 왜 WebSocket인가?실시간 암호화폐 데이터를 프론트엔드에서 보여주려면 선택지가 몇 가지 있습니다. Polling, SSE(Server-Sent Events), WebSocket.호가창은 초당 10~20..

v15에서 "왜 자꾸 캐싱 안 돼?"라고 당황했던 개발자라면, v16의 변화가 반가울 것이다.들어가며2025년 10월 21일, Next.js 16이 정식 출시됐다.릴리즈 노트를 읽다가 눈이 멈춘 부분이 있었다. revalidateTag() 시그니처 변경. 이거 기존 코드 전부 깨지는 거 아닌가? 확인해보니 맞았다. 그것도 두 번째 인자가 필수로 바뀌는 Breaking Change였다.단순히 API 하나 바뀐 게 아니다. v14 → v15 → v16으로 이어지는 캐싱 철학의 변화가 이번 버전에서 완성됐다. 이 흐름을 이해하지 않으면 마이그레이션할 때 "왜 이렇게 바꿨지?"라는 의문만 남는다.정리해봤다.버전별 캐싱 정책의 변화먼저 세 버전의 캐싱 정책을 한눈에 보자.버전캐싱 기본값개발자 반응v14Cached..

React의 Error Boundary는 컴포넌트 렌더링 도중 발생하는 오류를 포착하여 앱이 완전히 중단되지 않도록 돕는 강력한 기능입니다.하지만 한 가지 중요한 한계가 있습니다 — 비동기 코드에서 발생한 오류는 Error Boundary가 잡을 수 없습니다.## 왜 Error Boundary는 비동기 에러를 잡지 못할까?그 이유는 비동기 에러가 렌더링 시점의 콜스택이 모두 비워진 후에 발생하기 때문입니다.React는 컴포넌트를 렌더링할 때 하나의 연속된 콜스택 안에서 작업을 수행하며, Error Boundary 또한 이 흐름 안에서만 동작합니다.즉, 동기적인 렌더링 과정 중에 발생한 오류만 감지할 수 있습니다.class MyComponent extends React.Component { render(..

React에서 “언제, 왜, 어떻게” 리렌더링이 일어나는지 정확히 이해하면 성능 최적화와 불필요한 복잡도 감소에 큰 도움을 줍니다. 이 글은 리렌더링의 이론을 체계적으로 정리하고, 실행 가능한 예시와 실무 체크리스트로 마무리합니다.핵심 개념: 렌더링 파이프라인 3단계Trigger: 상태(state) 변경, 상위 컴포넌트 렌더, context 값 변경, key 변경, 외부 스토어 구독 변경 등으로 “업데이트 필요”가 발생합니다. React는 내부 업데이트 큐에 변경을 기록합니다.Render: 변경된 상태로 함수 컴포넌트를 다시 호출하여 새로운 VDOM(Fiber 트리)을 만듭니다. 이전 트리와 비교(diff)하지만, 이 단계에서는 실제 DOM 조작이 없습니다.Commit: diff 결과를 실제 DOM에 최..

안녕하세요! 프론트엔드/풀스택 실무에서 자주 부딪히는 “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..