2026.09.03 pl미팅 피드백 기반 추가학습 - 100-hours-a-week/KTB4-3rd-wiki GitHub Wiki

Next.js

BFF

Backend For Frontend의 약자로, 각 프론트엔드의 요구사항에 맞도록 하나의 백엔드 계층을 두는 것 입니다.

BFF를 쓰는 이유

BFF는 웹과 모바일처럼 서로 다른 프론트엔드가 하나의 백엔드를 공유할 때 발생하는 요구사항 충돌과 개발 결합도를 줄이기 위해 사용합니다.

데스크톱 웹과 모바일은 화면 크기뿐만 아니라 네트워크 환경, 성능, 필요한 데이터의 양과 형태가 다릅니다. 동일한 백엔드를 사용하면 한쪽 클라이언트의 요구사항을 반영할 때 다른 클라이언트에 영향을 주거나, 백엔드 내부에 클라이언트별 분기 로직이 계속 증가할 수 있습니다. 그래서 프론트엔드별로 BFF를 두고, 각 클라이언트에 필요한 데이터를 조합·변환하도록 구성합니다. 이때 공통 비즈니스 로직은 기존 백엔드가 담당하고, BFF는 클라이언트별 응답 형태나 API 조합을 담당하게 하여 변경 영향을 줄일 수 있습니다.

마이크로소프트 공식문서

실제 사례

  • 여러 프론트엔드 인터페이스가 있으며, 각각의 api 요구사항이 다른 경우
  • 여러 백엔드 API를 하나로 조합해야 하는 경우
  • 브라우저에 인증 토큰이나 내부 API 주소를 노출하고 싶지 않은 경우
  • 레거시 API 응답을 프론트엔드 형식에 맞게 변환해야 하는 경우
  • 프론트엔드 전용 데이터 가공 로직이 많은 경우
  • Next.js 서버에서 쿠키 인증과 백엔드 API 호출을 처리하고 싶은 경우

장/단점

장점

  • 백엔드 주소를 브라우저에 직접 노출하지 않음
  • 서버에 보관해야 하는 토큰이나 비밀키를 보호할 수 있음
  • 여러 백엔드 API를 Next.js에서 한 번에 호출하고 조합할 수 있음
  • 백엔드 응답을 화면에 필요한 형태로 변환할 수 있음
  • 브라우저와 백엔드 사이의 CORS 문제를 줄일 수 있음

단점

  • 네트워크 지연 증가
  • 운영 비용 증가
  • 새로운 장애 지점이 생김
  • 코드 중복 가능성
  • 데이터 정합성 문제
  • 캐싱과 인증이 복잡해짐

App router / page router

Page Router는 pages 디렉터리의 파일을 기반으로 라우팅하고, getServerSideProps나 getStaticProps를 이용해 데이터를 패칭하는 기존 방식입니다. App Router는 app 디렉터리를 기반으로 하며, React Server Components가 기본으로 적용됩니다. 또한 중첩 레이아웃, loading.tsx, error.tsx, Route Handler, Server Action 등을 사용할 수 있습니다.

React

VDOM 쓰는이유

VDOM을 사용하는 가장 큰 이유는 상태 기반의 선언적 UI를 유지하면서 실제 DOM 변경을 효율적으로 처리하기 위해서입니다. 상태가 변경되면 React는 새로운 React Element 트리를 만들고 이전 트리와 비교한 뒤, 실제 DOM에서 변경된 부분만 반영합니다. 또한 개발자가 직접 DOM을 조작하지 않아도 React가 화면 업데이트를 관리해주므로, DOM 조작 코드가 줄어들고 컴포넌트와 비즈니스 로직에 집중할 수 있습니다. 다만 VDOM이 항상 실제 DOM보다 빠르다는 의미는 아니며, 불필요한 DOM 작업을 줄이는 데 의미가 있습니다.

리액트 상태 업데이트 과정

리액트에서 상태변경 함수인 setState가 호출되면 React가 새로운 렌더링을 예약합니다. React는 여러 상태 변경을 배치처리해서 컴포넌트 함수를 다시 실행해 새로운 VDOM을 만듭니다. 그리고 이전 VDOM과 비교합니다. 이후 변경된 부분만 실제 DOM에 반영하고 브라우저가 화면을 다시 그립니다.

상태관리

서버 상태와 클라이언트 상태를 나눠야하는 이유

서버 상태와 클라이언트 상태를 나눠야하 하는 이유는 데이터의 원본 위치와 생명주기가 다르기 때문입니다. 서버 상태는 최신 데이터인지 확인하고 서버와 동기화해야 하는 상태입니다. 반면 클라이언트 상태는 모달이나 탭처럼 사용자의 화면 조작에 따라 즉시 바뀌는 상태입니다.

두 상태가 섞여서 관리되면, 서버 데이터와 로컬 기기간 데이터 불일치 문제나, 무의미하고 복잡한 보일러플레이트코드가 늘어나는 등의 문제를 겪을 수 있습니다. 따라서 각 상태를 나눠서 관리하는것이 권장됩니다.

zustand가 관리하는 값들에는 뭐가 있을까?

Zustand에는 모달, 토스트, 필터·정렬 조건처럼 클라이언트에서 발생하고 여러 컴포넌트가 공유해야 하는 UI 상태를 관리합니다.

하나의 페이지 안에만 있는 데이터는 해당 페이지에서 useState로 관리하고, 공통 모달이나 토스트, 또는 페이지를 이동해도 남아있어야하는 필터나 정렬 조건을 zustand로 관리합니다.