상태 관리 라이브러리를 고를 때 Redux, Recoil, Jotai, Zustand 사이에서 고민하는 경우가 많다. 하나의 전역 스토어에 모든 상태를 넣을지, 아토믹하게 쪼갤지, 아니면 그 중간 어딘가를 선택할지는 프로젝트 규모와 팀 상황에 따라 다르다. pixelDiff를 개발하면서 Zustand를 선택하고, "도메인 기반 복합 스토어" 패턴을 적용했다. 단순한 투두 앱이 아니라 캔버스 에디터 수준의 복잡도를 가진 프로젝트에서 상태 관리를 어떻게 설계했는지 정리한다. 왜 Zustand인가상태 관리 라이브러리 선택지를 비교해보면 이렇다.라이브러리특징적합한 상황Redux단일 스토어, 보일러플레이트 많음대규모 팀, 엄격한 구조 필요Recoil아토믹, React 종속Facebook 생태계, Suspense ..
React에서 탭이나 모드를 전환할 때 컴포넌트가 느리게 뜨는 경험을 해본 적이 있을 것이다. 특히 iframe이나 Canvas처럼 초기화 비용이 큰 컴포넌트가 매번 리마운트되면 사용자 경험이 확연히 나빠진다. 문제: 모드 전환마다 컴포넌트가 리셋된다pixelDiff에는 세 가지 비교 모드가 있다:iframe 모드: 웹페이지를 iframe으로 띄우고 Figma 이미지와 오버레이 비교opacity 모드: 투명도 조절로 차이점 확인devices 모드: 여러 기기 해상도에서 동시에 비교초기 구현은 단순한 조건부 렌더링이었다: {comparisonMode === 'devices' && }{comparisonMode !== 'devices' && } 문제는 모드를 전환할 때마다 발생했다:DevicesMode 리마..
버튼을 누르고 서버 응답을 기다리는 동안 UI가 멈춰 있으면 사용자는 불안해한다. "클릭이 안 된 건가?" 하고 다시 누르기도 한다. 낙관적 업데이트는 이 문제를 해결한다. 서버 응답을 기다리지 않고 UI를 먼저 바꾸는 것이다. 낙관적 업데이트의 핵심 구조React Query(TanStack Query)에서 낙관적 업데이트는 useMutation의 콜백 조합으로 구현한다. useMutation({ mutationFn: (data) => api.update(data), onMutate: async (variables) => { // 1. 진행 중인 쿼리 취소 (경쟁 상태 방지) await queryClient.cancelQueries({ queryKey: ['items'] }); // ..
Next.js로 개발하다 보면 이런 상황을 겪는다.API 코드를 수정하고 저장한다. 브라우저에서 새로고침한다. 잘 된다. 몇 번 더 수정하고 저장한다. 갑자기 API가 먹통이 된다.Error: Too many connections콘솔에 에러가 뜨고, 모든 API 요청이 실패한다. 개발 서버를 재시작하면 다시 동작한다. 하지만 또 몇 번 저장하면 같은 일이 반복된다.혼자 개발하고 있는데 연결이 부족하다니, 뭔가 이상하다. 문제의 원인: HMR이 연결을 쌓는다Next.js는 개발 환경에서 HMR(Hot Module Reload) 을 사용한다. 파일을 저장하면 해당 모듈만 다시 로드해서 빠른 개발 경험을 제공한다.문제는 Prisma Client다. 모듈이 다시 로드될 때마다 새로운 PrismaClient 인스..
NextAuth.js로 인증을 구현할 때 세션 전략 선택은 성능에 직접적인 영향을 미친다. pixelDiff 프로젝트에서 Figma OAuth를 구현하면서 DB 세션에서 JWT로 전환한 경험을 정리한다. 문제 상황Figma OAuth 연동 후 API 응답이 체감될 정도로 느렸다. 원인을 추적해보니 매 요청마다 세션 테이블을 조회하는 데서 병목이 발생하고 있었다.[요청] → [세션 테이블 조회] → [사용자 정보 반환] → [응답] ↑ 약 400ms 소요세션 조회 자체는 단순한 쿼리지만, 네트워크 왕복(Supabase PostgreSQL)과 커넥션 오버헤드가 누적되면서 체감 지연이 발생했다. 선택지 분석전략동작 방식장점단점DB 세션매 요청마다 세션 테이블 조회서버에서 세션 무효..
사이드 프로젝트를 시작할 때마다 같은 고민이 반복된다. 프론트엔드는 React나 Next.js로 금방 결정되는데, 백엔드는 어떻게 할 것인가. Express? NestJS? 별도 서버를 띄우면 인프라가 두 배가 된다. pixelDiff를 만들면서 "Next.js API Routes만으로 얼마나 갈 수 있을까?"를 실험해봤다. 결론부터 말하면, 프로덕션급 서비스까지 충분히 가능하다. 38개 엔드포인트, OAuth 인증, PostgreSQL 연동, Rate Limiting까지 모두 Next.js 안에서 해결했다. 왜 별도 백엔드를 두지 않았나 선택지는 세 가지였다.방식장점단점Express/Fastify + React자유도 높음, 검증된 패턴두 개의 배포, 두 개의 인프라NestJS + React체계적인 구조..
디자인 비교 도구를 만들다 보면, 레이어를 이리저리 옮기는 일이 많다. Figma 이미지 위에 스냅샷을 올려놓고 위치를 조정하는데, 손이 미끄러져서 엉뚱한 데 놓는 경우가 생각보다 잦다.그럴 때마다 "아 Cmd+Z 눌러야지" 하고 습관적으로 단축키를 누르게 되는데, 당연히 안 된다. Undo 기능이 없으니까. Undo/Redo가 필요한 이유사실 처음엔 없어도 괜찮다고 생각했다. 레이어 위치 좀 틀리면 다시 드래그하면 되니까. 근데 실제로 써보니까 생각이 달라졌다. 되돌리기 기능은 "실수해도 괜찮다"는 안전망이다.이게 없으면 모든 조작이 신중해져야 하고, 그만큼 피로도가 올라간다. 특히 레이어가 여러 개일 때, 하나를 옮기다가 실수로 다른 걸 건드리면 원래 위치가 어디였는지 기억도 안 난다. 결국 Undo..
Next.js Conf에서 발표했듯이, Next.js 14는 우리의 가장 집중적인 릴리즈이에요: Turbopack: App & Pages Router에 대한 5,000개의 테스트가 통과됨 53% 더 빠른 로컬 서버 시작 Fast Refresh와 함께 94% 더 빠른 코드 업데이트 Server Actions (안정화): 점진적으로 향상된 변화 캐싱 및 재검증과 통합 단순한 함수 호출, 또는 폼과 자연스럽게 작동 Partial Prerendering (미리보기): 빠른 초기 정적 응답 + 동적 콘텐츠 스트리밍 Next.js Learn (신규): App Router, 인증, 데이터베이스 등을 교육하는 무료 강좌 Next.js Compiler: Turbocharged Next.js 13부터, 우리는 Next.j..
