프론트엔드 카테고리의 최신글

프론트엔드

URL을 상태로 관리한 방법: TanStack Router

인턴 기간 동안 백오피스 프로젝트에서 React Router 기반 레거시 코드를 마이그레이션 하는 작업을 맡았다. 단순히 마이그레이션 하기 보다는, 기존 JavaScript의 상태를 TypeScript로 마이그레이션 하면서 어떻게 런타임과 컴파일 타임 둘다 안정성을 잡을 수 있을지에 대한 고민이 많았다. 레거시 React Router 구조 기존 구조에서는 많은 필터 값을 url에 올리지 않고, 내부 상태로만 관리하고 있었다. 여기에서의 문제점은 사용자가 새로고침 시, 설정해놓은 필터 값들이 사라진다는 것이다. 따라서 UX를 향상하기 위해 사용자가 필터 값들을 새로고침 시에도 상태가 변경되지 않게 URL에 올리기로 결정하였다. URL로 상태를 옮기며 마주한 문제 ① 타입 안정성 저하 예를 들어 이런 URL이 들어올 수 있다 page, size는 number 타입이어야 하지만 실제로 사용자가 임의로 주소창에 입력한 값은 string이다. 사용자가 직접 값을 주입하였을 때, 서버로 값이 들어갈 수 있다는 점에서 라우터 단의 타입 관리가 필요해보였다. ② 상태의 기준점 모호 URL에 필터값을 올리는 방식을 채택하였을 때 필터 상태가 다음과 같이 여러 군데에 흩어져 있는 문제가 있다. useState로 관리되는 내부 상태 서버 요청 시 사용하는 query 객체 URL search 파라미터 따라서 이 기준점을 어디에 잡아야할지도 논의 및 합의가 필요한 부분이었다. 라우터 단에서 상태를 정규화하기 TanStack Router는 React Router와 달리 라우터 단에서 validateSearch를 제공한다. search 파라미터를 읽는 것과 동시에, 컴파일 및 런타임에서 zod로 검증 및 정규화를 수행할 수 있다. 라우터 단에서 다음의 기능을 수행하였다. 허용된 값만 통과 타입 자동 추론 실패 시 기본값 정규화 잘못된 쿼리는 서버에 전달되지 않음 상태 업데이트 규칙을 통일하기 URL 쿼리 값 정규화 문제는 해결하였지만, 가장 큰 문제는 필터가 있는 화면에서 코드가 계속 반복된다는 점이었다. 부분 업데이트 로직 기본값 처리 URL과 useState, URL과 서버 상태의 동기화 로직 이런 로직들이 페이지마다 반복되고 있었으며, 개발자마다 다른 로직을 사용하여 코드를 알아보기에도 쉽지 않았다. 이 문제는 useSearchParams 커스텀 훅을 만들어 해결하였다. useSearchParams Custom Hook 이 훅의 목적은 단순하다. search는 항상 타입 안전해야 하고 업데이트 방식은 팀 내에서 동일해야 한다. ① URL에 들어갈 수 있는 타입 제한 Date, 객체, Map 같은 값은 애초에 타입 단계에서 차단했다. search는 URL 직렬화 가능한 원시값만 가진다는 규칙을 강제했다. ② 업데이트 방식을 통일 이 구조로 인해서 페이지에서 search를 다루는 방식이 완전 동일해졌다. 부분 업데이트는 applySearch 전체 리셋은 resetSearch undefined는 무시 defaultSearch는 항상 기준점 적용 이후의 변화 이 커스텀 훅을 사용함으로써 다음의 변화가 생겼다. 프론트엔드 개발자 3명이 동일한 navigation 규칙 사용 필터 로직 중복 코드 약 40% 감소 공유, 새로고침, 뒤로가기 상황에서 상태 유지 신규 페이지 추가 시, navigation 로직 추가 간편화 회고 URL을 상태로 쓰는 건 생각보다 까다롭다. 페이지 내부 상태로만 관리할 때는 "내가 넣은 값만 존재한다"는 가정이 가능하지만, URL로 올리는 순간부터는 “누군가 아무 값이나 넣을 수 있다” 는 전제가 시작된다. 그래서 오히려 상태가 더 불안정해질 수도 있다. 재미있게도, 이런 종류의 문제는 결국 라이브러리 선택보다 팀 규칙의 문제다. 정규화 지점이 어디인지, 기본값이 무엇인지, 업데이트가 어떤 규칙을 따르는지. 이걸 문서가 아니라 코드로 강제했을 때 팀 생산성이 가장 크게 달라졌다. 전체 useSearchParams 코드 ts const { search, applySearch, resetSearch } = useSearchParams({ defaultSearch: { page: 1, keyword: '' }, Route, }) applySearch({ keyword: 'abc', page: 1 }) applySearch({ keyword: '' }) // keyword 제거 의도 applySearch({ tags: ['a', '', 'b'] }) // tags -> ['a','b'] applySearch({ tags: [] }) // tags 제거 의도 resetSearch() *

2026년 02월 12일 03:56

프론트엔드

🧨 우당탕탕 Axios 인터셉터 만들기

-- 토큰 만료와의 혈투 기록 -- 프론트엔드를 하다보면, 그 어떤 api보다도 나를 가장 괴롭히는게 등장한다 바로 토큰 만료(401) 이번 글은 “처음에 대충 회사 코드 ctrl c + ctrl v 했다가 혼나서 결국 프로젝트 갈아엎고 다시 처음부터 axios 인터셉터 설계하게 된 이야기” 시작은 항상 \복붙이었다. 솔직히 말하면 인터셉터 만들 여유보다는 화면 구성하고싶은 맘이 조급했다. 백오피스를 마이그레이션 하라는 지시를 받았고, 인터셉터 그까이거 그냥 사용하던거 쓰면 되는거 아님? 당연히 이렇게 시작했다. 나는 그냥 옛날 코드 가져와 붙였고, 아무 생각 없이 진행하고 있었다. 근데 코드리뷰에서 멘토님이 한 말씀 기존거 가져다쓰지 마시고 처음부터 머리 박아가면서 만들어보시죠. 네..? 다시요..? 그렇게 나는 다시 401을 맞았다. 그래서 진짜로 인터셉터가 어떤 구조로 작동해야 하는지, 토큰 로직은 어떻게 구성해야 하는지 기본부터 다시 뜯어보기로 했다. 사실 이번 인턴 면접에서 토큰 기반 인증에 관한 질문이 있었고, (현 멘토님이 내 면접관이셨다) 한 페이지에서 여러 요청이 동시에 401 에러가 나오면 어떻게 해결하는지에 대해 여쭤보셨다. 나는 그것까지는 생각을 해본 적이 없어서 잘 모르겠다고 답 했었고?? 두고두고 맘에 남았다. 그래서 기존 프로젝트 axios 인터셉터 보고 “오 이렇게 만드는구나. 설계가 잘 되어있구나” 하고 그대로 갖다 썼던 마음이 큰 것 같다. 첫 삽질: 401 해결하려다 403 맞기 나는 빠르게 at 만료 감지를 만들고, refresh api도 붙였다. 그리고 좀 기다려서 만료되었을 때 나의 시나리오 오래된 at로 api 호출 서버가 401 던짐 인터셉터가 refresh 호출 새 토큰으로 요청 재시도 … 되어야 하는데 만료된 at로 api 호출 -> 401 err 자동적으로 refresh api 호출 -> 403 err 아니 왜 재발급 한번도 못했는데 왜 403 나옴? 이 악몽같은 현상으로 하루종일 삽질만 했다. 재발급 시마다 alert도 띄워보고, Authorization 헤더도 다시 붙여보고, 인터셉터 바깥에서 refresh 호출 성공하는것도 확인했는데,, 원인이 걍 퐝당했음. at와 rt의 유효기간이 같았던 것임!!! 아!뿔!싸! 기존 인터셉터도 이거 처리가 안되어있더라! 너무 모르겠어서 jwt.io에서 token 까보고 알았다. at가 만료되었을 때 rt도 만료가되어 refresh를 할 수 있는 시간이 없었던 것이다. accessToken 만료 → refresh 요청 시도 근데 refreshToken도 이미 만료 → 403 그래서 당연히 403이 나는 구조였다. 근데 백엔드를 바꿔달라고 할 수가 없는 상황 이걸 계기로 오랜만에 조금 머리를 굴려보았다. 자동 재발급? 그건 좀 아닌것같아요. 처음에는 이런 식의 자동 로직을 생각했다. 사용자가 뭘 하든 at 만료 5분전에 자동으로 refresh 하자 근데 이 생각을 말씀드렸더니 멘토님이 말씀하셨다. 사용자가 아무 행동도 안하는데 알아서 재발급 하는건 아닌 것 같아요! 맞말임. 아무래도 백오피스다보니까 보안적인 부분도 고려를 했어야했다. 그래서 방향을 바꿨다. 사용자가 실제 api 요청 시 만료 시간이 5분 이하라면 그때 refresh 하자 즉 활성 사용자만 재발급 → 비활성 사용자 세션은 종료 동시 요청 문제 → Pending Queue 도입 다음 문제는 이거였다. 이거는 내가 면접 때 질문을 받고 대답을 못했던 그 문제이기도 한데 A API 요청 시 → 토큰 만료 → refresh 시작 그 사이에 B API 요청 → 또 토큰 만료 → refresh 또 호출 이러면 refresh api가 동시에 여러번 호출되며 경합이 발생한다. 그래서 필수적으로 refresh 중엔 다른 요청을 멈춰서 줄세우는 로직이 필요하였다. 그것이 바로 pending queue ~~내가 자료구조 수업에서 듣고 코테 풀때만 쓰던 큐를 진짜 써보는 날이 오다니~~ 요약하자면 refresh 중이면 → 요청을 queue 에 쌓아둠 refresh 끝나면 → queue에 있던 요청들을 새 토큰으로 재요청 이렇게 하면 동시 재발급 요청 문제는 해결된다. 세션 만료 경고가 여러 번 뜨는 문제 아 근데 산넘어 산이라더니 에베레스트가 나옴 refresh 실패(401/403) → 로그아웃 처리할 때 다음과 같은 코드가 있었다. 근데 api 여러개가 동시에 터지면서 alert이 여러개가 떴던것임! alert 확인 버튼 연타함 그래서 로그아웃이 한 번만 실행되게 하기 위해서 zustand에 isLoggingOut state를 추가하여 해결하였다. 근데 왜 isLoggingOut 초기화가 안돼요? 문제 발생 두번째 세션 만료 로그아웃 때, 401 떴는데 로그아웃이 안되더라 그건 내가 isLoggingOut 상태값을 zustand persist 미들웨어에 넣어놨기 때문이었다. 그래서 persist partialize 설정해서 해결하였다. ㅎㅎ 바보 최종 Axios 인터셉터 코드 삽질 끝에 만들어진 인터셉터 구조는 다음과 같다. 토큰 만료 5분 이하 → refresh refresh 동안 다른 요청은 pending queue refresh 실패 → 로그아웃 alert 중복 방지 → isLoggingOut accessToken, refreshToken 상태는 zustand에서 관리 Authorization 헤더 자동 주입 정리하자면.. 이번에 인터셉터를 처음부터 설계하면서 느낀 점: 토큰 구조를 이해해야 한다 세션 만료 UX까지 고려해야 한다 동시 요청 문제까지 잡아야 한다 상태관리까지 연계해야 한다 인터셉터는 그냥 훅 두 개가 아니라 프로젝트의 전체 인증 흐름을 담당하는 중요한 부분임을 깨달았다. 그리고 무엇보다: 절대… 생각 안하고 코드 복붙부터 시작하지 말자.

2025년 11월 20일 00:33

프론트엔드

@tanstack/react-query Optimistic Updates

@tanstack/react-query Optimistic Updates Tanstack Query에서 Optimistic Updates는 서버 응답을 기다리기 전에 UI를 먼저 바꿔서 체감 속도를 올리는 패턴이다. 서버가 실패하면 되돌리고, 성공하면 실제 응답으로 확정한다. 사용하는 경우 버튼을 누르자마자 리스트/카운트/좋아요 상태가 바뀌어야 할 때 삭제/수정/좋아요/핀토글 처럼 결과가 예측 가능한 옵션 네트워크 지연이 UX를 해치는 구간 절차 onMutate: 서버 호출 직전, 관련 쿼리 refetch 취소 -> 현재 캐시 스냅샷 저장 -> 캐시를 낙관적으로 업데이트 onError: 실패 시 스냅샷으로 롤백 onSuccess: 서버 응답으로 정합성 확정(필요하면 캐시 merge) onSettled: 마지막에 관련 쿼리 invalidate/refetch ❗️ refetch를 취소하는 이유 게시글 목록을 보고 있음 -> useQuery(['posts'])가 캐시를 들고 있음 좋아요 버튼 클릭 -> useMutation() 실행됨 React Query는 이 와중에 자동으로 refetch 중일 수도 있음 (예: 창을 다시 클릭해서 포커스 됐을 때) refetch가 서버에서 예전 데이터를 받아오면, 당신이 방금 낙관적으로 바꿔둔 캐시(좋아요 눌림 상태)가 다시 덮어써짐 ❗️ refetch는 자동으로 취소되는가? ❌ refetch 취소는 자동으로 되지 않는다. 개발자가 onMutate 안에서 직접 cancelQueries()를 호출해야 한다. 예제: 좋아요 토글 사용

2025년 11월 04일 17:34

프론트엔드

피크민 블룸은 어떻게 꽃길🌸을 남길까?  

걷기만 했는데 꽃이 심어졌다. 어떻게 작동하는 걸까? 프론트 개발자 입장에서 추정해봤다. 위치 수집과 저장 꽃을 심기 시작하면, 앱은 사용자의 위치를 실시간으로 추적하기 시작한다. 이때 예상되는 기술 흐름은 다음과 같다: CLLocationManager를 통한 실시간 위치 수집 일정 간격으로 좌표를 샘플링하여 배열에 저장 -> 너무 가까운 위치는 무시하여 노이즈 제거 앱을 닫아도 백그라운드에서 계속 추적 (배터리 최적화 필요) 저장 포맷은 아마도? 꽃을 심은 경로는 단순 좌표가 아닌 시간 + 위치 + 심은 꽃 종류 등 메타데이터가 포함되어 있을 가능성이 높다. 지금 5월이라 또 가정의 달이라고, 이달의 꽃은 카네이션, 장미 등등.. 난리났다. 각각 꽃 이름을 다 고유명사로 짓기에는 한계가 있을테니 시즌-꽃-색상 이렇게 짓지 않았을까? 25-5-rose-red (25년 5월 시즌 빨간색 장미꽃) 지도 위 시각화 꽃을 심고 나면, 지도 위에 꽃잎들이 길을 따라 자동 배치된다. 이를 구현하려면 다음과 같은 절차가 필요하다: MKPolyline 또는 커스텀 캔버스를 이용해 라인을 그림 일정 간격으로 꽃 모양 아이콘을 offset에 따라 반복 배치 아이콘은 애니메이션 또는 이미지 뷰로 간단하게 처리 가능 성능 문제는? 꽃이 많아지면 오브젝트 수도 급격히 증가 -> 렌더링 최적화 필수 과거 기록도 남기려면 서버 측에 저장하고, 맵 확대 시에만 불러오는 식의 lazy loading 전략이 유력 그래서 아이폰 12 mini 에서는 꽃을 오래 심으면 앱이 자꾸 꺼진다 ㅜㅜ 실시간 위치 추적과 일반 걸음 기록은 다르다 피크민 블룸은 항상 걸음을 기록하지만, 꽃을 심을 때만 파란 위치 아이콘이 뜨는 것을 보면 두 기능은 서로 다르게 작동한다. 🌱 일반 걸음 기록 아이폰에서 피트니스 API 또는 HealthKit과 연동되어 걸음 수만 수집 이때는 정확한 위치 정보는 사용하지 않음 -> 아이폰 상단에 파란색 위치 아이콘이 뜨지 않음 🌸 꽃을 심을 때는 실시간 GPS 추적 사용자가 ‘꽃 심기’ 버튼을 누르는 순간부터, CLLocationManager가 실시간으로 위치를 추적하며 경로를 저장 -> 아이폰 상단에 파란 위치 추적 아이콘이 표시됨 이후 종료 버튼을 누르면 기록이 서버에 업로드되거나 저장됨 맵 전체가 아닌, 현재 위치 중심 반경 N미터만 렌더링한다 피크민 블룸을 실행하면, 꽃이 원형으로 촤라락 펼쳐지듯 한 번에 맵에 나타난다. 이걸 보면 전체 데이터를 로딩하는 게 아니라, 현재 위치 기준 반경 약 200~300m 정도만 요청하고 시각화하는 것으로 보인다. (더 넓을수도?) 예상되는 흐름 앱 실행 / 맵 이동 감지 현재 위치를 기준으로 일정 반경 (ex. 200m) 설정 서버에 꽃 정보 요청 응답 받은 꽃 데이터 기준으로 렌더링 경로 따라 꽃 아이콘 배치 종류별로 다른 텍스처 사용 일정 간격마다 반복 표시 사용자가 이동할 경우, 일정 거리 이상 벗어나면 새 요청 * 이전에 본 영역은 로컬 캐시로 보여줌 왜 반경 단위로 렌더링할까? 퍼포먼스 때문: 전체 도시 데이터를 한 번에 불러오면 부하가 너무 큼 프라이버시 때문: 다른 유저의 꽃 경로를 멀리까지 보여줄 필요 없음 인터랙션 유도: 근처만 보여줘야 걷고 이동하게 만들 수 있음 결론 피크민 블룸은 단순한 위치 기반 게임이 아니라, 실시간 GPS 추적 + 사용자 입력 이벤트 + 거리 기반 로딩 전략이 모두 섞인 정교한 구조를 갖고 있다. 이런 구조를 보면 ‘걷기’라는 일상적인 활동도 얼마나 다양하게 확장 가능한지 실감하게 된다.

2025년 05월 04일 01:53

프론트엔드

Next.js 마이그레이션: 서버 컴포넌트(SSC)와 클라이언트 컴포넌트(CSC) 선택하기

React 프로젝트를 리팩토링 하면서 Next.js로 마이그레이션을 하게 되었고, 처음으로 서버 사이드 컴포넌트(Server-side Component, SSC) 를 사용할 기회를 갖게 되었다. 기존 React에서는 React Query를 활용하여 서버의 부담을 줄이며 데이터를 관리해왔는데, Next.js에서도 기존처럼 React Query를 사용할 수 있을지 고민하게 되었다. SSC와 CSC의 차이 Next.js의 서버 컴포넌트(SSC) 와 클라이언트 컴포넌트(CSC) 는 동작 방식이 다르다. SSC(Server-side Component): 서버에서 데이터를 가져와 미리 렌더링하여 클라이언트에 전달함 → SEO 최적화 CSC(Client-side Component): 클라이언트에서 데이터를 가져오고, 동적으로 업데이트함 → 실시간 변화 가능 이전처럼 React Query를 사용하여 데이터를 가져오려 했지만, 만약 모든 데이터를 클라이언트에서 가져온다면 Next.js의 서버 렌더링 기능을 제대로 활용하지 못하게 된다. Next.js를 사용하면서 서버의 역할을 최대한 활용해야 한다는 점에서 React Query만을 사용할 수는 없었다. 서버 부담 문제와 캐싱 처음에는 페이지를 이동할 때마다 서버가 데이터를 불러오면 부담이 커질 것이라고 생각했다. 하지만 Next.js에서는 서버에서 데이터를 가져올 때 캐싱을 통해 성능을 최적화할 수 있는 방법이 있었다. 위와 같이 revalidate: 60을 설정하면 60초 동안 같은 요청을 반복하지 않고 캐싱된 데이터를 반환한다. 덕분에 SEO를 챙기면서도 서버의 부담을 줄일 수 있다. 어떤 데이터는 SSC, 어떤 데이터는 CSC로? 처음에는 서버와 직접적인 연관이 있는 것은 SSC로, 정적인 것은 CSC로 사용해야 한다고 생각했는데, 사실은 그 반대였다. ✔️ 서버 컴포넌트(SSC)를 사용해야 하는 경우 SEO가 중요한 데이터 (검색 엔진 노출 필요) 초기 렌더링이 빠른 것이 중요한 데이터 변경이 자주 일어나지 않는 데이터 페이지 구조를 구성하는 주요 데이터 ✅ 예시 블로그 글 목록 (게시글 리스트) 블로그 글 내용 (제목, 본문) 사용자 프로필 정보 (변경이 잦지 않은 경우) 카테고리 목록 ✔️ 클라이언트 컴포넌트(CSC)를 사용해야 하는 경우 실시간으로 변화하는 데이터 사용자와의 인터랙션이 필요한 데이터 페이지 내에서 상태 변화가 필요한 데이터 ✅ 예시 좋아요 개수, 댓글 검색 기능 (검색어 입력 시마다 데이터 변경) 무한 스크롤 (React Query의 useInfiniteQuery 활용) 사용자 설정 변경 결론: SSC와 CSC의 최적 조합 초기 데이터를 서버에서 받아와 렌더링해야 하는 경우 → SSC 사용 자주 변경되거나 사용자 인터랙션이 필요한 경우 → CSC + React Query 사용 서버 부담을 줄이기 위해 revalidate 로 캐싱 활용 Next.js 마이그레이션을 하면서 서버 컴포넌트와 클라이언트 컴포넌트를 적절히 나누는 것이 성능 최적화에 매우 중요하다는 것을 깨달았다. SEO가 필요한 데이터는 서버에서 미리 받아오고, 실시간 업데이트가 필요한 데이터는 클라이언트에서 관리하는 것이 핵심이다. 이를 잘 활용하면 서버 부담을 줄이면서도 빠른 렌더링을 유지할 수 있다.

2025년 03월 19일 08:12