1장은 모듈화된 컴포넌트로 나누자. 은탄환은 없다..
17장은 restful하게 만들자. 그외엔 다 하고 있는 듯? ex) 센트리, 버저닝, 인증헤더
18장 리액트 컴파일러 빨리 만들어져서 안정화됐으면 & 서버 컴포넌트에 대하여
- 리액트 컴파일러는 잘 할 수 있을까에 대한 걱정. 원하는 부분의 메모가 아니라면 디버깅이나 해결이 어려워질 것 같음. 이걸 수동으로 안하게 하는 게 더 번거로워질 수도..?
지피티 생각
React 컴파일러는 아직은 “magic”에 가까운 기술인데, 이게 안정적으로 정착하려면 투명성이 핵심일 것 같아. 내부 동작을 설명해주는 좋은 도구(예: DevTools 지원) 없이는 오히려 복잡도를 높일 수도 있고, “알아서 잘 해준다”는 게 항상 반가운 건 아니지. 개발자가 명시적으로 개입할 수 있는 opt-out 구조가 있다면 훨씬 더 신뢰할 수 있을 거야.
- 서버 컴포넌트 19버전에선 안정적, nextjs 스럽다. nextjs의 미래는?
지피티 생각
서버 컴포넌트가 본격적으로 도입되면, Next.js는 React 표준의 실험장이자 실질적인 디폴트 프레임워크로 자리잡을 가능성이 높아. 실제로 지금도 많은 기능이 Next에 먼저 들어가고 React에 흘러가는 구조잖아. 근데 이 흐름은 개인이나 작은 팀에게는 꽤 부담스러울 수도 있어 — 서버 렌더링, 캐싱 전략 등 더 복잡한 영역을 신경 써야 하니까. 그런 의미에서 Next.js의 미래는 더 “완결된 플랫폼”으로 갈 거고, 개발자는 그 생태계를 잘 따라가는 게 더 중요해질 수도 있음.
Remix vs Next.js: React Server Components 관점 비교
항목 | Next.js | Remix |
RSC 도입 여부 | ✅ 공식 지원 (App Router 기준)19버전 이후로 안정화 단계 | ❌ 아직 도입 안 함지켜보는 중이며 필요성에 대해 신중한 입장 |
철학적 방향 | 서버 주도 렌더링 강화RSC 통해 서버에서 로직·렌더링 처리 후 클라이언트 전송 | 서버 우선 + 브라우저 존중서버 fetch → HTML 전송, 브라우저에서 폼, 전통 방식 강조 |
데이터 fetching 방식 | fetch()를 RSC 내부에서 직접 사용 가능동기적 코드 스타일 지향 | loader() 함수에서 서버 데이터 처리클라이언트는 별도 요청 없이 서버에서 받은 HTML 렌더 |
클라이언트/서버 분리 명확성 | RSC에서 경계를 모호하게 추상화 (자동 처리) → DX는 편하지만 추적 어려울 수 있음 | 서버/클라이언트 명확히 구분됨개발자가 흐름을 명시적으로 제어 |
폼 처리 방식 | 클라이언트 중심 처리 많음 (useForm 등)점점 서버 호출이 많아짐 | HTML form submit 중심점진적 향상, 브라우저 기본 기능 활용 |
경험적 복잡도 | RSC, Suspense, Streaming 등 신기술 결합 → 진입장벽 존재 | 비교적 직관적 구조하지만 서버 관련 이해는 필요 |
커뮤니티/표준 채택 | React 팀과 공식 협력사실상 RSC 레퍼런스 프레임워크 | React 생태계에 속하지만공식 기술 변화와는 독립적 흐름 |
미래 지향성 | React의 미래 방향에 적극 참여신기능 우선 채택 | 독자 노선 유지필요 시 도입 고려 (하지만 주도하진 않음) |
🧭 해석 요약
- Next.js는 RSC를 기반으로 한 React 미래 기술의 실험장이자 표준화 선도자 역할.
- Remix는 RSC 도입 없이도 같은 문제를 해결하려는 철학 중심의 대안적 프레임워크.
그래서 선택은 어떻게?
상황 | 추천 프레임워크 |
최신 리액트 기술(RSC, Suspense 등) 적극 사용하고 싶음 | ✅ Next.js |
서버와 브라우저의 전통적인 웹 방식 선호, 명시적 코드 제어 원함 | ✅ Remix |
공식 레퍼런스에 가까운 생태계 선택, 안정적인 커뮤니티 지원 기대 | ✅ Next.js |
기술보다는 철학과 구조적 통제에 무게를 두는 팀/개발자 | ㅤ |
- 번외) bran의 use 사용 후기가 궁금함
지피티 생각
브라우저에서 use로 데이터를 동기처럼 받아온다는 건 DX의 큰 혁신이지만, 이것도 결국 서버-클라이언트의 경계를 어떻게 다룰 것인가라는 질문으로 연결돼. 캐싱 전략, fallback UI, error handling까지 포괄적인 설계가 필요해서, use 하나만 보고 따라가기엔 아직 부담이 있는 듯해. 다만, 실무에서 점점 더 비동기 흐름을 간단하게 다루고 싶은 욕망이 커지고 있으니, 실험적이지만 방향은 맞다고 생각해.
리액트의 lazy 함수를 동적 임포트와 함께 사용하는 것은 default exports를 사용할 때만 효과있는 이유
promise.then(module => { return module.default; });
React.lazy의 내부 구현은 default 키를 자동으로 가져오는 방식으로 되어있기 때문
벤더 분할이란?
벤더 분할은 코드에서 서드파티 의존성을 분리할 때 사용하는 기법이다. 서드파티 의존성과 관련된 코드를 별도의 덩어리로 잘라내 독립적으로 캐싱함. 그래서 우리 코드를 업데이트했을 때, 최종 사용자는 전체 라이브러리를 다시 다운로드하지 않아도 됨. 라이브러리는 이미 캐싱되어 있기 때문.
에딩거 기준 build/public/javascripts에 vendors~*.js 와 같은 파일이 있음. 아고라, 센드버드같은 거 있음.
자바스크립트 비용 줄이는 방법
- 번들 크기가 50-100KB를 초과한다면 작은 번들로 나눠라
- HTTP/2 멀티플렉싱을 사용해라 (서버에서 지원해주고 있나?, 참고로 지피티는 쓰고 있을 가능성이 높다 함)
질문 | 답변 |
왓챠에 HTTP/2 멀티플렉싱이 필요한가요? | 네, 성능 향상을 위해 매우 유용하며 실제로도 사용 중일 가능성이 높습니다 |
꼭 필요한가요? | 영상 전송 자체에 필수는 아니지만, UX 개선과 리소스 최적화 측면에선 사실상 필수 수준 |
이미 사용 중일까? | 거의 확실하게 사용 중입니다 (h2로 응답, 최신 인프라 기반) |
- 스크립트 크기가 1 KB를 넘으면 인라인으로 작성하지 말라
- HTTP3를 써라. ga나 센트리는 h3인데 일반적인 api는 h2인듯?
- 서드파티를 줄여라. (줄일 게 있나..)
- 저희 streams api나 fetch api를 이용한 스트리밍 요청이나 transformStream 을 쓰나여..?
리액트 쿼리가 캐싱 메모리를 관리하는 방법
리액트 쿼리의 캐싱이 독특한 이유는, 전통적인 브라우저 저장소나 서버 기반 캐시가 아닌, 앱 실행 중의 메모리를 활용한 자체 관리 캐시를 구현했기 때문. 마치 클라이언트 상태를 다루듯 서버 상태를 다룰 수 있게 해줘서 훨씬 더 정교한 UX를 만들 수 있음. swr도 마찬가지.
리액트 쿼리로 데이터 미리 가져오는 방법
리액트 쿼리에서 prefetchQuery는:
데이터를 미리 가져와서 캐시에 넣어두는 함수
queryClient.prefetchQuery(['user', id], fetchUser)
이렇게 쓰면, 데이터를 화면에 아직 안 보여줘도 미리 가져와서 캐시에 저장해둬.
그다음 useQuery(['user', id], fetchUser)가 실행되면, 이미 캐시에 있어서 즉시 응답 가능!
💡 그럼 이걸 “언제” 쓰냐?
prefetchQuery는 다음 같은 **“예측 가능한 사용자 행동 전에 미리 데이터 가져오기”**에 쓰여:
1.
이벤트 핸들러 안에서 사용
(예: hover, focus, 클릭 등)
<button onMouseEnter={() => { queryClient.prefetchQuery(['product', 123], fetchProduct) }} > 상품 상세 보기 </button>
→ 사용자가 버튼에 마우스를 올려놓기만 해도, 백그라운드에서 데이터를 미리 받아둬.
→ 사용자가 실제로 클릭해서 상세 페이지 들어가면, 이미 데이터가 있어서 빠르게 보여줄 수 있음.
2.
컴포넌트 라이프사이클에서 사용
(예:
useEffect
)
useEffect(() => { queryClient.prefetchQuery(['dashboardData'], fetchDashboardData) }, [])
→ 컴포넌트가 마운트될 때, 아직 쓰이지는 않지만 곧 쓸 것 같은 데이터를 미리 받아놓음.
3.
라우팅 전에 미리 요청
(예: 페이지 이동 전에 데이터 준비)
<Link to="/profile" onMouseEnter={() => { queryClient.prefetchQuery(['profile'], fetchProfile) }} > 프로필 보기 </Link>
→ 사용자가 링크에 마우스를 올려놓은 순간, /profile 페이지에서 쓸 데이터를 미리 받아놓음.
→ 실제로 이동하면 로딩 없이 바로 렌더링됨. 🔥
리덕스 아키텍처
- 국제화로 동적로딩, 복수형 처리 잘 하고 있는가?
a/b 테스트 잘 하는 방법
- context api를 활용하자
- statsing 같은 라이브러리 이용하기 - 가격 (직접 만드는 것보다 저렴한듯)
- 사용자를 잘 나누자
- 10% 소규모 사용자 그룹에서 시작해 25%, 50%, 100%로 비율 늘려나가기
(그냥 질문) 사내에서 토커와 쿠버네티스 어떻게 사용하고 있는가
도커(Docker)는 컨테이너를 생성하고 관리하는 플랫폼이며, 쿠버네티스(Kubernetes)는 컨테이너들을 오케스트레이션하여 관리하는 플랫폼입니다. 즉, 도커는 컨테이너 자체를 다루는 도구이고, 쿠버네티스는 컨테이너들을 그룹화하고 관리하는 도구입니다.
vercel과 netlify는 aws랑 gcp 위에 구축된 플랫폼이다 (o/x)
네, 정확히 말하면 Vercel과 Netlify는 AWS, GCP, Azure 같은 클라우드 인프라 위에 구축된 **추상화된 플랫폼(PaaS, Platform as a Service)**입니다.
좀 더 자세히 설명하자면:
- Vercel과 Netlify는 서버리스 배포, CI/CD, 캐싱, 글로벌 CDN, 폼 처리 등 프론트엔드 개발자에게 필요한 기능을 추상화해서 쉽게 사용할 수 있도록 만든 JAMstack 호스팅 플랫폼이에요.
- 이들 자체적으로 물리적인 서버를 운영하지 않으며, 대신 AWS, GCP, Azure 등의 인프라 제공자의 리소스를 사용해서 서비스를 제공합니다.
예를 들어:
- Vercel은 내부적으로 AWS Lambda나 Cloudflare Workers를 사용할 수 있고, (공식적으로는 AWS 위주)
- Netlify도 AWS Lambda를 기반으로 Functions 기능을 제공합니다.
비유로 설명하면:
- AWS/GCP는 “전기, 수도, 가스”를 제공하는 인프라 공급자고,
- Vercel/Netlify는 그 위에 지어진 편의점 같은 서비스입니다. 우리가 직접 발전소(AWS)를 건드리지 않아도 편의점(Vercel)에서 쉽게 물건(웹사이트)을 배포할 수 있는 거죠.
필요하다면 어떤 경우에 Vercel/Netlify를 쓰고, 어떤 경우엔 직접 AWS/GCP를 쓰는 게 나은지도 알려줄게요!
언제 스냅숏 테스트를 작성해야 하는가?
- 컴포넌트의 출력(렌더링 결과)이 복잡하거나 자주 바뀌지 않을 때
- 디자인 시스템 컴포넌트나 공통 UI 요소
- 렌더 결과 외엔 테스트할 것이 딱히 없는 단순한 프레젠테이셔널 컴포넌트
- 테스트 주도 개발(TDD) 시 빠른 피드백 용도로 임시 작성
이럴 때 피하자
- 자주 변하는 출력이 있을 때
- 스냅숏이 너무 커서 diff 확인이 어려운 경우
- 냅숏 업데이트를 무비판적으로 계속 눌러버리는 팀 문화
왜 나는 젠킨스를 쓴 적이 없을까
✅ 1.
GitHub Actions는 GitHub와 완전히 통합되어 있어서 사용이 간편함
- GitHub에서 직접 제공하니까 추가 설정이나 인프라 준비 없이 바로 사용 가능.
- 프론트엔드는 보통 코드 푸시 → 테스트 → 빌드 → 배포 정도의 CI/CD만 필요한 경우가 많아요.
- 이 정도 작업은 GitHub Actions에서 워크플로우 파일 몇 줄로 바로 구현 가능하죠.
- 결과도 GitHub UI 안에서 바로 확인 가능해서 따로 Jenkins 대시보드 같은 게 필요 없음.
🛠️ 2.
Jenkins는 셀프호스팅 기반 → 인프라 관리 부담 있음
- Jenkins는 자체 서버에 설치하고 유지보수해야 해요.
- 프론트엔드 프로젝트는 DevOps 인력이 따로 없거나 적은 경우가 많기 때문에, Jenkins 서버를 굳이 따로 운영할 필요가 없어요.
- 또한 Jenkins는 권한 관리, 플러그인 설치, 보안 설정 등 초기 세팅이 복잡합니다.
GitHub Actions: “바로 쓸 수 있는 SaaS”
Jenkins: “직접 돌려야 하는 CI 플랫폼”
🧪 3.
프론트엔드는 Jenkins보다 GitHub Actions, Vercel, Netlify 등과 더 친숙한 환경
- Next.js, React 같은 프로젝트는 GitHub 푸시만으로도 Vercel, Netlify에서 자동 배포 가능.
- Jenkins는 보통 복잡한 백엔드 시스템, 온프레미스 환경, 엔터프라이즈 환경에서 사용돼요.
- 예: 수백 개의 마이크로서비스, 복잡한 배포 단계, 사내 네트워크만 접근 가능한 서버 등.
- 반면 프론트엔드는 클라우드 친화적이고 간단한 파이프라인이 많죠.
🏢 4.
회사/팀의 규모와 문화도 영향
- 스타트업이나 소규모 팀은 Jenkins 같은 무거운 CI 툴보다 GitHub Actions, CircleCI 등 간편한 솔루션을 더 선호.
- Jenkins는 전용 DevOps 팀이 있는 규모 있는 조직이나 보안·규정상 SaaS 사용이 제한된 조직에서 더 자주 사용돼요.
클라이언트 사이드 렌더링 vs 클라이언트 사이드 라우팅
🖼️ 렌더링 (Rendering)
화면에 보여지는 UI를 언제, 어디서 생성하느냐에 대한 이야기입니다.
- 클라이언트 사이드 렌더링 (CSR)
브라우저(클라이언트)에서 JS로 렌더링.
👉 초기에는 빈 HTML + JS, 이후 JS가 화면 그려줌.
- 서버 사이드 렌더링 (SSR)
서버가 HTML을 완성해서 클라이언트로 전달.
👉 초기 페이지 로딩 빠름, SEO에 유리.
🧭 라우팅 (Routing)
어떤 URL로 요청이 들어왔을 때 **어떤 화면(컴포넌트)**을 보여줄지를 결정하는 것.
즉, URL과 페이지 간의 연결.
- 클라이언트 사이드 라우팅 (CSR)
한 번 페이지 로딩 후, URL만 바뀌고 실제 페이지는 안 바뀜.
👉 React Router, Vue Router 등이 예.
👉 페이지 간 이동이 빠르고 부드러움.
👉 주소는 바뀌는데 실제로는 자바스크립트가 내부적으로 컴포넌트를 바꿈.
- 서버 사이드 라우팅 (SSR)
URL이 바뀔 때마다 서버에 새로 요청해서 새 페이지를 받아옴.
👉 전통적인 웹 방식 (예: PHP, JSP 기반 사이트).
👉 새로고침처럼 매번 전체 페이지 새로 불러옴.
💡 결론
- “클라이언트 사이드 렌더링”과 “클라이언트 사이드 라우팅”은 다른 개념이에요.
- 하지만 보통 클라이언트 사이드 렌더링을 사용하는 앱은 클라이언트 사이드 라우팅도 함께 써요.
- 서버 사이드도 마찬가지로, SSR이면 SSR 라우팅이 함께 쓰이는 경우가 일반적이에요.