프레임워크 트랙 - Next.js
백엔드 전환자가 SSR/CSR 경계를 프론트에서 설계할 때 이해해야 할 큰 그림입니다.
React를 쓴다고 해서 라우팅, 데이터 주입, 응답 타이밍이 해결되는 건 아닙니다. 그 경계를 실제로 정리해 주는 도구가 프레임워크 선택입니다.
이 문서는 Next.js가 왜 백엔드 출신에게도 중요한지, 무엇을 해결해 주는지 중심으로 보입니다.
Next.js가 해결하려는 질문
- 초기 화면은 언제 그리고 어디서 계산되어야 하는가?
- 화면 전환 시 어느 값은 그대로 두고 어느 값은 다시 가져와야 하는가?
- 서버와 브라우저가 같은 페이지를 같은 의도로 공유하려면 어떤 책임 분할이 필요한가?
- 인증/권한, 개인화 데이터는 언제 주입되어야 하는가?
1) SSR/CSR 경계의 문제를 프레임워크가 다룬다
백엔드 관점에서는 요청 단위로 응답 경계를 잡지만, 프론트에서는 “보이는 순간”과 “상호작용 가능한 순간”이 다르게 나타납니다.
Next.js는 이 간격을 운영 가능한 단위로 바꿉니다.
- 라우트 단위로 렌더링 성격을 나눈다.
- 서버에서 HTML/초기 데이터 책임을 정한다.
- 클라이언트에서 인터랙션 책임을 정한다.
2) 라우트 단위 데이터 소유권의 모델
동일한 앱에서도 화면마다 같은 API를 쓰더라도 렌더링 비용, 캐시 전략, 인터랙션 타이밍이 다릅니다.
Next.js는 라우트 단위로 데이터 수집과 렌더 경계를 나눠서, 어떤 화면은 서버에서 먼저 계산할지, 어떤 화면은 클라이언트 상태 변화로 즉시 처리할지 구분시킵니다.
백엔드 전환자에게는 이 분리가 익숙한 개념으로 바뀝니다. 요청 처리 위치를 엔드포인트 단위로 정하듯, 화면도 데이터 소유권을 라우트 단위로 나누는 것입니다.
3) hydration과 인터랙션 가능 시점의 분리
서버 렌더링으로 화면이 보였더라도, 이벤트 바인딩이 붙기 전에는 실제 상호작용이 느리거나 누락될 수 있습니다.
Next.js는 이 과정을 하드하게 제약하지 않고, 앱 구조에서 어디까지 서버 계산을 하고 어디서 클라이언트 계산을 붙일지 설계할 수 있게 합니다.
4) 서버 컴포넌트/클라이언트 컴포넌트의 역할 분리
렌더와 상태 문제를 더 단순화하려면, 화면의 코드 단에서도 책임 분리가 필요합니다.
- 서버에서 충분히 계산 가능한 값은 서버 단에 둔다.
- 사용자 입력과 브라우저 API 접근은 클라이언트 단에 둔다.
- 경계는 의도적으로 명시한다(“누가 언제 데이터를 읽고 쓰는가”).
이게 Next.js에서 중요한 이유는 성능이 아니라 의존성의 방향을 일관되게 유지하기 위함입니다.
어떻게 보면 좋은가
Next.js를 먼저 쓰는 이유는 문법 때문이 아닙니다.
web 트랙에서 본 렌더링 단계에,
라우팅/데이터 소유권/서버-클라이언트 경계를 한 번에 붙여주는 입문 점프 패드이기 때문입니다.