Context API vs Zustand 그리고 Auth

11 asked

0

안녕하세요 Coi 님, 이번 Part 3 미션을 수강하시면서 Context API부터 전역 상태 관리, 그리고 인증(Auth)과 라우팅 보호까지 프론트엔드 아키텍처의 가장 깊은 곳까지 치열하게 고민하신 흔적이 묻어나는 질문입니다. 실무에서 누구나 한 번쯤 거대한 벽을 느끼는 주제들을 이렇게 논리적으로 정리해 주셔서 진심으로 감사합니다. 남겨주신 질문들이 서로 긴밀하게 연결되어 있으므로, 흐름에 따라 하나씩 자연스럽게 상세히 짚어보겠습니다.

먼저 Context API와 Zustand의 선택 기준에 대한 Coi님의 이해는 완벽하게 맞습니다. 상태의 변경 빈도, 구독하는 컴포넌트의 범위, 리렌더링의 영향 등은 실무에서 두 기술을 나누는 가장 핵심적인 기준입니다. 이를 현실의 회사에 비유해 볼까요? Context API는 회사 전체에 울려 퍼지는 사내 방송 시스템과 같습니다. 다국어 설정이나 다크 모드처럼 '오늘부터 사내 공용어는 영어를 사용합니다', 혹은 '전 층 소등합니다'와 같이 가끔 발생하지만 모두가 알아야 하는 정보에 아주 적합하죠. 하지만 방송으로 '김 대리님, 버튼 색상 좀 바꿔주세요'라고 수시로 떠든다면, 모든 직원이 하던 일을 멈추고 방송을 들어야 하는 비효율, 즉 불필요한 리렌더링이 발생합니다.

반면 Zustand는 특정 팀원들끼리만 소통하는 사내 메신저 단톡방과 같습니다. 상태가 수시로 변하더라도 해당 채팅방에 있는 사람들, 즉 구독한 컴포넌트에게만 알림이 가기 때문에 성능적으로 매우 유리합니다. 여기에 실무적인 기준을 한 가지 더 추가하자면, '일반 유틸리티 함수나 Axios 인터셉터 내부와 같은 React 컴포넌트 생명주기 외부에서도 해당 상태에 접근해야 하는가'를 고려해야 합니다. Context API는 반드시 React 트리 내부에서만 동작하지만, Zustand는 React 밖에서도 상태를 읽고 쓸 수 있다는 강력한 무기를 가지고 있습니다.

그렇다면 애플리케이션의 척추와도 같은 Auth 상태는 어디에서 관리하는 것이 좋을까요? 결론부터 말씀드리면, 로그인한 유저 정보의 본질적인 '진실의 원천'은 클라이언트가 아니라 서버에 있습니다. 따라서 서버 상태를 동기화해주는 TanStack Query의 캐시를 그대로 진실의 원천으로 사용하는 것이 가장 현대적이고 권장되는 패턴입니다. 서버에서 데이터를 가져온 뒤 이를 Zustand나 Context에 다시 담아두는 방식은 피하는 것이 좋습니다. 현실에 비유하자면, 서버라는 은행에서 내 통장 잔고를 조회해 왔는데, 그걸 내 개인 수첩인 Zustand에 한 번 더 펜으로 적어두는 것과 같습니다. 시간이 지나면 수첩의 기록과 실제 은행 잔고가 달라지는 데이터 동기화 문제가 필연적으로 발생하기 마련입니다.

물론 실무에서의 예외적인 케이스도 존재합니다. 만약 3번 질문에서 언급하신 ‘클라이언트에서 JWT 관리’ 방식을 채택하여, 보안상 Access Token을 로컬 스토리지가 아닌 메모리에 저장하기로 했다면 이야기가 다릅니다. 이때는 Axios 인터셉터 등 React 외부에서 최신 토큰을 꺼내 쓰기 위해 Zustand를 '토큰 저장소'로 활용하는 것이 매우 대중적이고 훌륭한 실무 패턴입니다. 또한, NextAuth.js(Auth.js) 같은 검증된 표준 라이브러리들은 내부적으로 <SessionProvider>라는 Context API를 사용해 전역에 인증 상태를 뿌려줍니다. 이렇게 라이브러리 차원에서 제공하는 Context를 사용하는 것은 자연스러운 패턴이니 안심하셔도 됩니다. 핵심은 '개발자가 직접 서버 데이터를 전역 상태에 수동으로 중복 복사하는 것을 지양하자'는 의미입니다.

이러한 원칙은 React와 Next.js, 그리고 JWT와 세션 등 환경에 따라 조금씩 형태를 달리하지만 본질은 같습니다. 클라이언트에서 JWT를 관리하든 서버 세션 기반이든, 가장 중요한 것은 프론트엔드가 가진 유저 정보는 언제나 서버의 상태를 잠깐 빌려온 캐시라는 점입니다. 사실 이 내용은 향후 서버 개발을 하시면서 Redis나 Session 등 백엔드의 인프라를 다루시게 될 때 더욱 체감이 되실 텐데, 지금처럼 프론트엔드 관점에서만 보기보다는 이처럼 하나의 서비스가 굴러가는 풀스택 관점에서 큰 그림을 보는 것이 향후 개발을 해나가심에 있어 아주 큰 도움이 되실 것입니다. 예를 들어 React 환경에서 세션 기반 인증을 한다면, 클라이언트는 토큰의 존재조차 알 필요 없이 단순히 TanStack Query로 유저 정보를 요청하고 그 결괏값을 믿고 UI를 그리면 됩니다. Next.js 환경이라면 이 과정을 브라우저가 아닌 서버 컴포넌트에서 먼저 수행하여 캐싱된 상태를 클라이언트로 내려주는 방식으로 발전하게 되죠. 어떤 환경이든 내 클라이언트 전역 상태 수첩에 억지로 데이터를 복사하지 않고 캐시를 활용한다는 점이 핵심입니다.

이어서 질문해주신 라우트 보호와 계층 분리에 대한 고민도 아주 예리하십니다. Coi님께서 말씀하신 대로 '로그인하지 않은 사용자에게 UI를 보여주지 않는 것'과, '실제 데이터 접근을 막는 보안'은 완벽하게 분리되어야 하는 별개의 문제입니다. 클라이언트에서의 라우트 보호는 현실의 클럽 입구에 쳐놓은 벨벳 밧줄과 같습니다. 정상적인 손님들에게 '여기는 VIP 전용입니다'라고 안내하여 헛걸음을 방지하는 UX적인 장치일 뿐입니다. 실제 철통같은 보안은 밧줄을 넘어갔을 때 마주치는 덩치 큰 경호원, 즉 서버의 인증 및 인가 API가 담당해야 합니다.

따라서 React SPA 환경에서는 React Router v7의 loader 기능을 활용하는 것을 가장 권장합니다. 컴포넌트가 렌더링되기도 전에 TanStack Query 캐시나 서버 호출을 통해 인증 여부를 확인하고 진입을 차단하는 것이 가장 깔끔합니다. 반면 Next.js 환경이라면 이 경호원을 클럽 문 앞이 아니라 아예 동네 어귀에 배치할 수 있습니다. 바로 Middleware를 활용하는 방식입니다. 사용자가 프라이빗한 페이지를 요청하는 순간, React 컴포넌트가 실행되기도 전에 Next.js 미들웨어 엣지 단에서 쿠키를 검증하고 곧바로 로그인 페이지로 튕겨낼 수 있습니다.

여기에 더해 Next.js App Router 환경이라면, TanStack Query를 거칠 필요도 없이 Server Component 단에서 직접 cookies()나 세션을 조회하여 곧바로 redirect 시킬 수도 있습니다. 서버 컴포넌트 자체가 든든한 경호원 역할을 겸할 수 있다는 점이 Next.js가 가진 가장 강력한 무기 중 하나입니다.

실무에서 이 구조들이 어떻게 맞물려 돌아가는지 실제 코드 예시를 로직별로 상세하게 나누어서 보여드리겠습니다. 가장 먼저, Auth 상태의 진실의 원천을 TanStack Query로 관리하는 커스텀 훅을 작성합니다.JavaScript

export function useAuthUser() {
  return useQuery({
    queryKey: ['authUser'],
    queryFn: fetchCurrentUser,
    staleTime: 5 * 60 * 1000, 
  });
}

이렇게 만들어진 훅과 캐시를 바탕으로, React Router v7의 loader를 활용하여 UX 측면의 라우트 보호를 구현할 수 있습니다. 여기서 중요한 점은 Context나 Zustand를 보지 않고 서버 검증 결과를 신뢰한다는 것입니다.JavaScript

// 주의: 컴포넌트 외부이므로 useQueryClient 훅을 사용할 수 없습니다.
// App.js 등에서 생성한 전역 queryClient 인스턴스를 직접 import 해와야 합니다.
export async function protectedLoader() {
  try {
    const user = await queryClient.fetchQuery({
      queryKey: ['authUser'],
      queryFn: fetchCurrentUser,
    });
    
    if (!user) return redirect('/login');
    return user;
  } catch (error) {
    return redirect('/login');
  }
}

마지막으로 컴포넌트 내부에서는 Zustand와 억지로 동기화할 필요 없이 Query만 사용하여 아주 깔끔하게 화면을 그려낼 수 있습니다.

export function Dashboard() {
  const { data: user } = useAuthUser();
  return <div>환영합니다, {user.name}님!</div>;
}

이러한 설계가 실제 실무 쇼핑몰 서비스에서 어떻게 거대한 풀스택 워크플로우로 굴러가는지, 프론트엔드와 백엔드의 상태 그리고 동기화 과정까지 포함하여 아주 상세하게 하나의 큰 그림으로 그려보겠습니다. 사용자가 장바구니에 담아둔 상품을 결제하기 위해 마이페이지에 진입하는 순간을 상상해 보시길 바랍니다. 가장 먼저 사용자가 페이지 이동 버튼을 누르면, 프론트엔드에서는 React Router의 loader나 Next.js의 Middleware(또는 Server Component)가 작동하여 브라우저에 세션 쿠키가 존재하는지 1차적으로 꼼꼼하게 확인합니다. 앞서 말씀드린 클럽 입구의 벨벳 밧줄 역할입니다. 쿠키가 없다면 화면을 렌더링조차 하지 않고 즉시 로그인 페이지로 돌려보냅니다.

만약 쿠키가 존재해서 무사히 페이지 컴포넌트가 마운트되면, 이때 TanStack Query가 작동하여 백엔드 서버로 내 유저 정보와 장바구니 데이터를 달라는 API 요청을 보냅니다. 자, 이제 이 요청이 네트워크를 타고 백엔드 서버에 도착하는 순간부터 진짜 풀스택의 흐름이 시작됩니다. 클라이언트가 보낸 HTTP 요청은 가장 먼저 웹 서버나 로드밸런서를 거쳐 백엔드 API 서버에 도달하게 됩니다. 백엔드 서버는 요청 헤더에 담긴 HttpOnly 세션 쿠키를 추출해냅니다. 이 쿠키 안에는 사용자의 실제 개인정보가 아니라 그저 의미 없는 길고 복잡한 문자열인 세션 ID만이 들어있습니다. 서버는 이 세션 ID를 들고 가장 먼저 인메모리 데이터 저장소인 Redis로 달려갑니다. Redis는 하드 디스크가 아닌 메모리에서 동작하기 때문에 엄청나게 빠른 속도로 이 세션 ID가 유효한지, 만료되지는 않았는지, 그리고 이 세션의 주인이 어떤 유저 ID를 가지고 있는지 찾아냅니다. 만약 사용자가 다른 기기에서 로그아웃 버튼을 눌렀거나 세션 만료 시간이 지났다면 Redis에는 이 키가 없을 것이고, 서버는 즉시 401 권한 없음 에러를 프론트엔드로 던져 진짜 철통같은 보안 경호원 역할을 수행하게 됩니다.

Redis에서 무사히 유저 ID를 확보했다면, 서버는 이제 이 유저의 실제 장바구니 데이터를 가져오기 위해 MySQL이나 PostgreSQL 같은 메인 관계형 데이터베이스에 접근합니다. 유저 테이블을 조회하여 최신 유저 프로필 정보를 가져오고, 장바구니 테이블과 상품 테이블을 조인하여 현재 담겨 있는 상품의 이름, 가격, 재고 상태 등을 하나의 깔끔한 JSON 데이터로 묶어냅니다. 이렇게 완벽하게 검증되고 가공된 '진실의 원천' 데이터가 다시 네트워크를 타고 프론트엔드로 응답됩니다.

프론트엔드의 TanStack Query는 이 JSON 데이터를 받아 자신의 캐시 저장소에 예쁘게 저장하고 화면에 렌더링합니다. 이때 우리는 받아온 데이터를 Zustand나 Context API에 두 번 복사하지 않습니다. 서버의 상태를 그대로 거울처럼 비춰서 보여줄 뿐입니다. 그렇다면 Zustand는 언제 쓰일까요? 사용자가 장바구니 목록을 보다가 다크 모드 버튼을 누르거나, 모바일 화면에서 사이드바 메뉴를 열 때 사용됩니다. 이런 UI 상태는 서버와 전혀 상관이 없고 오직 클라이언트 브라우저 안에서만 유효하기 때문에 Zustand에 저장하고 빠르게 특정 컴포넌트들만 리렌더링 시키는 것입니다.

만약 사용자가 상품의 수량을 플러스 버튼을 눌러 추가한다면 어떨까요? 프론트엔드는 즉시 백엔드로 수량 변경 POST 요청을 보내고, 백엔드는 다시 Redis에서 세션 권한을 확인한 뒤 메인 데이터베이스의 장바구니 테이블을 업데이트합니다. 서버가 성공 응답을 주면, 프론트엔드는 TanStack Query의 invalidateQueries를 호출하여 기존 캐시를 폐기하고, 앞서 말씀드린 서버로부터 장바구니 데이터를 다시 가져오는 그 정교한 과정을 새롭게 동기화해옵니다. 이처럼 프론트엔드에서 상태를 관리한다는 것은 단순히 클라이언트 라이브러리 하나를 고르는 것이 아니라, 거대한 서비스의 데이터가 서버의 메인 DB에서 출발해 빠른 Redis를 거쳐, API를 타고 클라이언트의 TanStack Query 캐시에 머물렀다가, 최종적으로 React 컴포넌트에 뿌려지는 이 거대한 물줄기의 흐름을 제어하는 아주 멋진 일입니다. 풀스택 관점에서 이 큰 그림을 머릿속에 담아두신다면, 앞으로 어떤 라이브러리가 새로 유행하더라도 흔들리지 않는 튼튼한 아키텍처 기준을 갖추시게 될 것입니다.

특히 AI 코딩 어시스턴트가 적극적으로 도입되며 개발의 경계가 빠르게 허물어지는 지금 같은 시점에는, 프론트엔드라는 영역에만 국한되지 않고 풀스택 관점에서 서비스 아키텍처 전체의 큰 그림을 설계하는 능력이 그 어느 때보다 중요해졌습니다. 이번 고민을 발판 삼아 숲 전체를 조망할 수 있는 훌륭한 엔지니어로 성장하시기를 진심으로 응원합니다.

사실 이 아키텍처 설계라는 것이 단순히 폴더 구조나 라이브러리 하나만의 문제는 아닙니다. 이 구조 안에는 컴포넌트의 상태를 어떻게 관리할 것인지, props를 어떤 방식으로 내려줄 것인지, 함수와 훅의 재사용성은 어떻게 챙길 것인지 등 여러 복합적인 문제들이 아주 촘촘하게 얽혀 있기 때문에 단편적으로 무조건 이 방식이 정답이라고 말하기 참 힘든 부분이기도 합니다.

그래서 권장해 드리고 싶은 방법은, 제가 조금 더 직접적이고 실무적인 도움이 될 수 있도록 현재 코딩하고 계신 프로젝트나 고민 중인 아키텍처의 형태를 대략적으로나마 말씀해 주시는 것입니다. 현재 팀의 상황이나 사용 중인 기술 스택, 고민되는 병목 지점 등을 공유해 주시면, 제가 그 맥락에 맞춰서 이런 방식의 설계가 조금 더 좋지 않을까 하고 시니어 관점에서 맞춤형 권장을 드릴 수 있을 것 같습니다.

마지막으로, 현재 저희 우리동네코딩스튜디오 내부적으로 작은 이벤트를 진행하고 있습니다. 깊이 있는 고민으로 학습에 임하시는 Coi 님께 응원의 의미를 담아 작은 선물을 드리고자 하니, jeony0535@naver.com 으로 연락 한 통 주시면 우리동네코딩스튜디오 전 강의 쿠폰을 전달해 드리겠습니다. 앞으로도 학습하시면서 구조나 설계에 대한 실무적인 고민이 생기시면 언제든지 편하게 질문 남겨주세요.

0

안녕하세요, 인프런 AI 인턴입니다. Coi님.

질문하신 Context API와 Zustand의 선택 기준, 그리고 TanStack Query·Zustand·Context 간 상태 분리와 관련해 참고할 만한 기존 답변을 안내드립니다.

17강 zustand store 서버에서 생성

서버에서 받아온 사용자 정보나 초기 데이터를 Zustand에 주입할 때의 기준을 설명한 답변입니다. 핵심은 다음과 같습니다.

• 서버에서 가져온 데이터 자체는 server state이므로 TanStack Query가 관리하는 것이 적합합니다.
  
• 다만 폼 입력값, 임시 편집값, UI 조작 상태처럼 서버 데이터에서 파생된 클라이언트 상호작용 상태는 Zustand로 분리할 수 있습니다.
  
• TanStack Query의 데이터를 Zustand에 계속 복사해 두면 동일한 데이터가 여러 곳에 존재하게 되므로, 동기화 문제가 발생할 수 있어 가급적 피하는 것이 좋습니다.
  
• 초기값만 서버에서 주입하고 이후 클라이언트에서 독립적으로 관리하는 구조가 필요한 경우에 Zustand를 활용할 수 있습니다.
  

따라서 로그인 사용자 정보처럼 서버 세션이나 API 응답을 기준으로 하는 데이터는 TanStack Query 또는 서버 세션을 source of truth로 두고, 클라이언트에서는 모달 표시 여부·로그인 UI 상태·임시 사용자 설정 등 별도의 UI 상태만 Context나 Zustand로 관리하는 방식이 일반적입니다.

27강 Context내 RSC 사용 관련 문의

Context Provider의 범위와 Client Component 경계에 대해 설명한 답변입니다. Context API는 특정 컴포넌트 트리에서만 필요한 상태나 변경 빈도가 낮은 전역 상태를 공유할 때 적합하며, Provider를 필요한 범위의 하위 트리로 제한하는 것이 중요합니다.

또한 Next.js에서는 다음과 같이 역할을 나누는 것이 좋습니다.

• Server Component, Server Action, API: 세션 확인 및 실제 인증·인가 처리
  
• Middleware/Proxy: 보호된 경로에 대한 빠른 사전 차단
  
• TanStack Query: 서버에서 관리되는 사용자 정보와 세션 관련 데이터의 조회·캐싱
  
• Context/Zustand: 클라이언트에서만 필요한 UI 상태 또는 상호작용 상태
  
• Client redirect: 사용자 경험을 위한 보조적인 화면 이동 처리
  

클라이언트의 isAuthenticated 값만으로 접근을 제한하는 것은 보안 수단이 될 수 없습니다. 클라이언트 상태는 조작될 수 있으므로, 실제 데이터 접근과 API 요청에서는 반드시 서버가 쿠키·세션·토큰을 검증해야 합니다. 즉, “페이지를 보여줄지 결정하는 UI 제어”와 “데이터에 접근할 수 있는지 결정하는 보안 검증”은 별도로 처리해야 합니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.