React 마스터 클래스: Part 3 - 실무 핵심 라이브러리 정복 (TypeScript, Zustand, React Hook Form, TanStack Query)
안녕하세요. Context API의 대안으로 Zustand를 사용할 때의 장점과 함께, Zustand가 반드시 Context API를 대체하는 것이 아니라 상태의 특성에 따라 전략적으로 선택해야 한다고 설명해주셨습니다. 예를 들어 다크 모드나 다국어 설정처럼 변경 빈도가 낮으면서 여러 컴포넌트에서 공유해야 하는 상태의 경우 Context API도 충분히 적합할 수 있다고 이해했습니다. 제가 이해한 바로는 Context API가 적합한 경우를 크게 다음과 같이 생각해볼 수 있을 것 같습니다. 특정 컴포넌트와 그 하위 컴포넌트에서만 공유해야 하는 상태 Provider의 범위를 해당 컴포넌트 트리로 제한하여 사용하는 경우 애플리케이션 전역에서 공유하지만 변경 빈도가 낮은 상태 다크 모드 다국어 설정 전역 configuration 등 반면, 전역에서 사용하면서 변경이 빈번하거나 여러 상태를 세분화하여 구독해야 하는 경우에는 Zustand와 같은 외부 상태 관리 라이브러리가 더 적합할 수 있다고 이해했습니다. 1. Context API에 대한 제 이해가 맞을까요? Context API와 Zustand를 선택할 때 단순히 Local vs Global만으로 구분하기보다는, 상태의 변경 빈도 해당 상태를 구독하는 컴포넌트의 범위 상태 변경으로 인한 리렌더링의 영향 등을 함께 고려해야 한다고 이해했는데, 이 방향이 맞는지 궁금합니다. 혹시 이 외에도 Context API와 Zustand를 선택할 때 중요하게 봐야 하는 기준이 있을까요? 2. 그렇다면 Auth 상태는 어디에서 관리하는 것이 좋을까요? Auth의 경우에는 실무, 프로젝트 작업을 할 때 상태 관리를 어떻게 해야할지 판단이 어렵고 로직을 짜는데 항상 이게 맞나? 괜찮나? 라는 고민을 가졌습니다. 예를 들어 서버에서 현재 로그인한 사용자 정보를 받아온다고 했을 때 다음과 같은 방법들을 생각해볼 수 있을 것 같습니다. TanStack Query로 auth/user 데이터를 가져오고 Query Cache 자체를 상태로 활용 TanStack Query로 데이터를 가져온 뒤 Context API를 통해 공유 TanStack Query로 데이터를 가져온 뒤 Zustand Store에 저장하여 사용 여기서 궁금한 점은 서버에서 가져온 auth/user 정보가 본질적으로 server state라면 TanStack Query의 cache를 그대로 single source of truth로 사용하는 것이 더 적절한지, 아니면 Context나 Zustand에 별도로 저장하여 client state로 관리하는 것이 적절한 경우도 있는지입니다. 특히 TanStack Query에서 가져온 데이터를 다시 Context나 Zustand에 저장하면 동일한 데이터가 두 곳에 존재하게 되는데, 이런 형태는 가급적 피해야 하는지도 궁금합니다. 3. React / Next.js와 인증 방식에 따라 기준이 어떻게 달라질까요? Auth 상태 관리는 프레임워크와 인증 방식에 따라서도 달라질 것 같습니다. 예를 들어 다음 네 가지 경우를 생각해봤습니다. React + 클라이언트에서 JWT 관리 React + 서버 Session 기반 인증 Next.js + 클라이언트에서 JWT 관리 Next.js + 서버 Session 기반 인증 각각의 경우에 인증의 source of truth를 어디에 두고, Context API / Zustand / TanStack Query 중 어떤 역할을 맡기는 것이 적절한지 궁금합니다. 단순히 “Auth는 Context”, “전역 상태는 Zustand”처럼 정해진 기준보다는, 인증 정보의 source of truth가 어디에 있는지, server state와 client state 중 어디에 해당하는지, 그리고 해당 상태를 어떤 범위에서 소비하고 변경하는지 를 기준으로 판단해야 할 것 같은데, 이 관점이 맞는지도 궁금합니다. 4. Route 접근 제한은 어느 계층에서 처리하는 것이 적절할까요? Auth 상태 관리와 함께 궁금한 부분이 인증 여부에 따른 route 접근 제한입니다. 예를 들어 로그인한 사용자만 /dashboard , /mypage 등에 접근할 수 있도록 제한한다고 했을 때, React와 Next.js에서는 접근 방식이 다를 수 있다고 생각했습니다. React + React Router v7 React SPA에서는 서버가 아닌 클라이언트에서 routing이 이루어지기 때문에 다음과 같은 방법들을 생각해볼 수 있을 것 같습니다. Context/Zustand의 auth 상태를 확인한 뒤 컴포넌트에서 redirect React Router의 loader에서 인증 상태를 확인하고 redirect 서버 API 요청 시에도 별도로 인증/인가 검증 이 경우 UI 레벨에서의 route protection과 실제 보안을 위한 서버의 인증/인가를 어떻게 구분해야 하는지 궁금합니다. 또한 Context나 Zustand의 isAuthenticated 같은 client state를 기준으로 route 접근을 제한하는 것이 적절한지, 아니면 서버의 session/token 검증 결과를 기준으로 접근 여부를 판단하는 것이 더 적절한지도 궁금합니다. Next.js Next.js에서는 React SPA와 달리 서버에서 인증 정보를 확인할 수 있기 때문에, Server Component에서 session/cookie를 확인 Middleware 또는 Proxy를 통한 route 단위의 사전 처리 Client Component에서 Context/Zustand의 auth 상태를 확인하고 redirect 실제 Server Action/API에서도 인증 및 권한 검증 등 여러 계층에서 접근 제한을 처리할 수 있다고 알고 있습니다. 이때 궁금한 점은 어느 계층에서 route 접근을 제한하는 것이 가장 적절한지, 그리고 각각의 역할을 어떻게 구분해야 하는지입니다. 예를 들어, “로그인하지 않은 사용자에게 페이지 자체를 보여주지 않는 것”과 “해당 사용자가 실제 데이터나 API에 접근하지 못하도록 보안을 적용하는 것”은 별개의 문제로 보고 각각 처리해야 하는지 궁금합니다. 결국 route protection 역시 Context API / Zustand 중 무엇을 사용하느냐보다, 인증의 Source of Truth가 어디에 있는지 → 어느 시점에 인증 여부를 확인할 수 있는지 → UI 접근 제어와 실제 서버의 인증/인가를 어느 계층에서 담당할 것인지 를 먼저 결정하는 것이 맞는지도 궁금합니다. 추가적으로 실무 관점에서의 예시도 궁금합니다. 가능하시다면 위 질문들에 대해 개념적인 기준뿐만 아니라, 강사님께서 실제 프로젝트를 설계하신다면 각각 어떤 방식을 선택하실지도 궁금합니다. 뿐만 아니라 실무에서 일반적으로 많이 사용하는 패턴이 있는지, 또는 정해진 표준이 없다면 강사님의 실무 경험에서는 어떤 구조를 주로 선택하셨고, 그렇게 선택하신 이유가 무엇인지도 함께 설명해주시면 정말 도움이 될 것 같습니다. 가능하다면 단순한 개념 설명뿐만 아니라 간단한 프로젝트 구조나 코드 예시도 함께 보고 싶습니다.
안녕하세요! 6번 강의의 24:15 부분 즈음부터 설명하시는 장치 의존성에 대해 궁금한 점이 있어서 질문드리려고 합니다. 강의를 들으면 마치 "장치 의존성을 해결하기 위해 React.js와 같은 CSR 방식이 등장하였다."라고 이해하게 되는데, 그런 의도로 말씀하신게 맞는지 궁금합니다. 만약 그러한 의도로 말씀하신 것이 맞다면, 제가 알고 있는 내용과 많이 다른 것 같아 혼란스러워 질문을 작성하게 되었습니다. 제가 기존에 알고 있던 지식으로는, 다양한 화면의 장치에 대응하기 위해(즉, 장치 의존성을 해결하기 위해) "반응형 웹 디자인"이 등장한 것으로 알고 있는데요. HTML은 어떤 장치에서 받든 해당 파일을 구동하는 장치(구체적으로는 프로그램)에서 사용할 수 있게 결국 파싱이 되니까(Ex. DOM 생성) 장치에 의존하지 않는 것 아닌가요? 화면의 크기마다 달라지는 UI를 제어하기 위한 방법으로는 CSS에서의 반응형 웹 디자인으로 알고 있었는데요.. React.js와 같은 CSR이 등장하게 된 배경은 다양한 화면에 맞게 알맞은 UI를 보여주려고 한다기보다는, 웹 서버로 보내는 요청을 획기적으로 줄여(클라이언트의 브라우저에서 JS를 이용해 직접 index.html에서 필요한 요소(컴포넌트)를 리렌더링하므로) 웹 서버가 SSR 방식으로 설계되었을 때보다 더 적은 부하를 맡게 되고, 클라이언트 입장에서는 부드러운 화면전환을 경험할 수 있게 하기 위함으로 알고 있는데요. CSR 방식 자체가 장치 의존성을 해결할 수 있는 것이라면 그 이유가 무엇인지 궁금합니다!
강의 예제에서 add(2,3) -> 항상 5 (순수) getTime() -> 실행 시점마다 달라짐 (순수 아님) "실행 시점 마다 달라진다 또는 전역 변수를 수정하는 함수는 같은 입력을 넣어도 실행 시점에 따라 결과가 달라지기 때문에 순수하지 않습니다. "라고 하셨고, 이와 마찬가지로 "순수 컴포넌트는 동일한 props와 state가 주어졌을 때 항상 동일한 UI를 반환하는 컴포넌트 (외부 변수를 수정하거나, props를 직접 변경하지 않음)" 라고 했는데 제 머릿속에서는 state는 언제든지 변경될 수 있고 props가 어떤 특정한 state값 ( 서버에서 받아온 상품 목록 리스트)이면 결국 해당 props도 변경 될 수 있다라고 생각이 들어서 좀 많이 자세하게 설명을 듣고 이해 하고, 코드를 작성할 때 적용하기 위해 질문을 올립니다. 추가 ctx) 현재 프론트엔드 개발자입니다. 프론트 개발을 하고 있습니다. 언제나 순수 함수 / 순수 컴포넌트 말로 만 듣고 "이런 거겠지" 라고 하며 어물쩡 넘어갔었는데 요번에 확실하게 개념과 이해 그리고 체화 하고 싶어서 질문 남깁니다.
"AI 딸깍의 시대" 원리로 돌파하는 Node.js와 CS Part 2 - 스트림 아키텍처와 하드웨어 통제기
안녕하세요 강의 잘듣고있습니다! 풀스택 개발자를 목표로 하고있고, 원리를 배우는게 너무 즐겁고 큰 도움이 되고있습니다. 그런데 당장 nestjs 및 리액트 등으로 웹서비스 개발업무도 할예정인데 nestjs 는 어떻게 공부를하면좋을까요? T 자형 인재가 되고싶습니다! 그리고 강의듣는 순서도 궁금합니다!! 현재 NODE 듣고있고, 유닉스도 결제했습니다..! NESTJS 도 공부빨리해야하는 상황이네요..
안녕하세요 강의 잘 듣고 있습니다 강의에서 index.html 부분을 설명해주실 때 최신 문법의 js를 사용하고 있어 babel이 jsx를 구버전 js로 컨버팅하는 역할을 수행한다고 설명을 해주셨는데요 node js 로 서버를 호스팅하지 않더라도 로컬 경로의 html이 크롬에서 렌더 되서 보이더라구요 브라우저는 chrome을 사용하고 있는데, 이건 그냥 최신 브라우저들이 jsx를 지원하고 있다고 이해하면 될까요?
다운로드된 수업자료에서 활용 강좌의 완성 예제 깃허브 경로 https://designdigit.github.io/front-portfolio-2025-1 https://designdigit.github.io/front-portfolio-2025-2 로 들어가면 404오류가 뜨고 There isn't a GitHub Pages site here. 이렇게 나옵니다. 정확한 경로를 알려주세요. 그럼 답변기다리겠습니다.
React 마스터 클래스: Part 3 - 실무 핵심 라이브러리 정복 (TypeScript, Zustand, React Hook Form, TanStack Query)
62강 실습 자료로는 ' [Solution] Stale-While-Revalidate: 사용자에게는 캐시를, 뒤에서는 갱신을' 에 관한 내용이 나와야하는데, 현재는 '[Pain] 수동으로 관리하던 전역 로딩/에러 상태가 로직을 오염시킬 때' 로 나와있습니다. 62강 실습 자료 교체 부탁드립니다.
"AI 딸깍의 시대" 원리로 돌파하는 Node.js와 CS Part 2 - 스트림 아키텍처와 하드웨어 통제기
안녕하세요. AI 딸깍의 시대를 1~4 구매하여 수강 중에 있습니다. 강의를 듣다보니, 의문이 들어서 문의드립니다. AI로 딸깍하니, 얕은 수준으로 다루게 되니 원리를 이해하자를 이야기하고자 해당 강의가 있는 것 같습니다. 실무에서는 라이브러리나 프레임워크로 개발을 진행하게 되는 것 같습니다. 원리를 이해하면 개발을 조금 더 잘하게 된다? AI에 명령을 내릴 때 조금 더 잘 내릴 수 있다? 아니면 장애가 터졌을 때 이유를 알 수 있다? 그것도 아니라면 개발 시 장애를 미리 예측하여 대응할 수 있다로 봐야할까요? 보면서 궁금하여 문의드립니다.
안녕하세요. 현재 Node.js를 학습한 뒤 NestJS를 공부하고 있습니다. 부족한 CS 지식과 Node.js의 내부 동작 원리를 보완할 수 있을 것 같아 강의를 수강하고 있는데, NestJS 학습과 개인 프로젝트를 병행하다 보니 강의를 모두 시청하는 데 많은 시간을 투자하기가 어려운 상황입니다. 그래서 가능하다면 강의 노트를 중심으로 학습하여 시간을 조금 더 효율적으로 활용하고 싶습니다. 혹시 강의 노트만으로도 핵심 내용을 충분히 습득할 수 있을까요? 아니면 영상 강의를 통해서만 얻을 수 있는 중요한 설명이나 실무적인 인사이트가 많은 편인지 궁금합니다. 만약 강의에서만 얻을 수 있는 내용이 많다면 시간을 조금 더 내서라도 영상을 함께 수강하려고 합니다. 의견 부탁드립니다.
강의 2강에 대한 노트에 대한 질문입니다. 💡 [CS 및 실무 적용 Point: MSA와 BFF 아키텍처] 현대의 마이크로서비스 아키텍처(MSA)에서 Node.js는 특히 BFF(Backend For Frontend) 패턴의 핵심 기술로 사용됩니다. 브라우저의 DOM을 다루던 언어적 특성을 살려 클라이언트(React, Vue 등)의 요청을 쉽게 파싱하고, 이식된 운영체제 제어 능력(http, fs)을 통해 백엔드의 여러 마이크로서비스(Java, Python 등)로 비동기 네트워크 요청을 뿌린 뒤, 그 결과를 모아 빠르게 클라이언트에게 반환하는 완벽한 미들웨어 역할을 수행합니다. 해당 설명에서 BFF로 NodeJs를 유용한 이유는 I/O 입출력 특출나기 때문에, BFF로 사용하면, API 요청을 받아서 마이크로 서비스에 통신 요청을 보내는 용도로 사용한다는 건가요? 한번 더 거쳐가면 더 성능이 안 좋은 거 아닌가요? 아니면 원래 SpringBoot로 개발되었던 웹 사이트를 NodeJs로 구현한다면 더 좋다는 의미일까요?
"AI 딸깍의 시대" 원리로 돌파하는 Node.js와 CS Part 2 - 스트림 아키텍처와 하드웨어 통제기
// 3. 작업 종료 알림: end 이벤트를 통해 댐 바닥 확인 streamRead.on("end", async () => { console.log("\\n✅ [종료] 댐 바닥 도착. 모든 데이터 복사 완료!"); // 메서드: 더 보낼 물이 없다고 선언하고 파이프 닫기 절차 진입 // finish 이벤트: 쓰기 파이프가 논리적으로 완벽히 닫혔음을 보장 streamWrite.on("finish", async () => { // 쓰기 파일 디스크립터(번호표) 운영체제에 반환 (메모리 누수 방지) await fileHandleWrite.close(); console.timeEnd("복사_소요_시간"); console.log( `📊 요약: 총 ${chunkCount}회 펌프질, ${pauseCount}회 비상 정지(메모리 방어 성공)`, ); // 메서드: 실험용 임시 파일 삭제 클린업 (unlink) await fs.unlink(SOURCE_FILE); await fs.unlink(DEST_FILE); }); streamWrite.end(); // 메서드: 사용이 끝난 읽기 파일 디스크립터(번호표) 운영체제에 반환 await fileHandleRead.close(); 읽기 스트림과 쓰기 스트림을 종료하는 3번 단계에서 쓰기 스트림을 end 하기 전에 .on finish를 등록을 해야 콘솔에서 요약을 볼 수 있었습니다. 클로드는 레이스 컨디션이 발생해서 그렇다고 하는데 어떤 부분에서 경합이 일어났는지 잘 모르겠습니다.
let previousContent = ""; const addToFile = async (path, content) => { if (previousContent === content) return; // 중복 실행 방지를 위한 거름망 if(!(await fileExist(path))) return; // file이 존재하는지 않하는 지 체크 try { await appendFile(path, content); previousContent = content; console.log(`✅ ${content} is successfully appended to ${path}`); } catch (error) { if (error.code === "ENOENT") { console.log(`⚠️ ${path} does not exist`); } console.error(`❌ 에러 발생: ${error.message}`); } }; catch error 부분에서 에러 코드로 ENOENT를 사용해서 path가 존재하지 않는 경우를 잡아내는 코드를 작성했지만, 실제로 실행했을 때 appendFile 자체가 이미 새로운 파일을 생성해내는데 성공하였기 때문에 error로 연결되지 않았습니다. 중복 콘텐츠 방지를 위한 if 밑에 또 다른 if로 fileExist를 사용해서 early return을 하는 이런 방식으로 처리를 하는 게 맞을까요? 아니면 제가 놓친 다른 catch error 가 있는 걸까요?
