프론트엔드 설계
라우팅·CSR·SSR·SEO와 전달 전략
문서 탐색 구조(SPA/MPA)와 HTML 생성 위치(CSR/SSR)는 서로 독립적인 설계 축입니다.
이럴 때 필요해요
화면 성격에 맞춰 초기 표시 속도, 상호작용 준비 시간, 검색 엔진 노출, 서버 운영 비용의 균형을 잡습니다.
어떻게 동작하나요?
쇼핑몰의 상품 상세 페이지는 검색 엔진에 잘 노출되고 첫 화면이 빨리 떠야 하는 반면, 로그인 뒤에 쓰는 관리자 대시보드는 잦은 필터링과 탭 전환이 매끄러워야 합니다. 여기서 하나의 문서를 유지한 채 클라이언트 라우터로 화면을 갈아끼우는 SPA와 이동마다 새 문서를 받는 MPA는 '탐색 구조'의 구분이고, HTML을 브라우저에서 만드는 CSR과 서버에서 만들어 보내는 SSR은 '렌더링 위치'의 구분입니다. 따라서 첫 진입은 SSR로 받고 이후 이동은 SPA처럼 동작하는 조합이 널리 쓰입니다.
SSR은 데이터가 채워진 HTML을 먼저 보내 주어 초기 콘텐츠 표시와 크롤러 대응에 유리하지만, 서버 연산 비용과 브라우저에서 이벤트 핸들러를 연결하는 Hydration 과정을 함께 고려해야 합니다. 반대로 CSR은 정적 파일 호스팅만으로 배포가 간편하고 진입 후 전환이 빠르지만, 초기 JavaScript 번들이 너무 크거나 데이터 요청이 직렬(Waterfall)로 이어지면 첫 화면이 늦어질 수 있습니다.
Next.js 같은 프레임워크를 쓰면 정적 생성(SSG), 요청 시 서버 렌더링(SSR), 스트리밍, 클라이언트 컴포넌트를 경로와 컴포넌트 특성에 맞게 조합할 수 있습니다. 아울러 검색 엔진 최적화(SEO)는 단순히 SSR을 켰다고 끝나는 것이 아니라 크롤 가능한 <a href> 링크, 페이지별 고유한 title·메타 태그, 시맨틱 마크업, 그리고 없는 페이지에 정확한 404 상태 코드를 반환하는 기본기를 함께 갖춰야 완성됩니다.
코드 예제
동작을 설명하는 읽기 전용 예제입니다.
// React Router 설정의 설명용 조각
<Routes>
<Route path="/products" element={<ProductList />} />
<Route path="/products/:id" element={<ProductDetail />} />
</Routes>클라이언트 라우터 설정 조각입니다. 사용자가 주소창에 /products/123을 직접 입력해 들어올 때도 404가 나지 않도록 서버나 호스팅에서도 해당 경로 요청을 올바르게 처리해야 합니다.
자주 헷갈리는 포인트
- SSR을 적용하면 브라우저에서의 JavaScript 다운로드와 Hydration 실행 비용까지 모두 사라진다고 생각하지 않습니다.
- 클라이언트 라우터만 설정해 두고 정적 호스팅 서버의 하위 경로 직접 진입(Fallback) 설정을 누락해 새로고침 시 404가 나는 문제를 놓치지 않습니다.
내 말로 설명해 보기
검색 유입이 중요한 공개 상품 상세 페이지와 로그인 후 사용하는 사내 편집 도구의 렌더링 전달 전략을 다르게 선택한다면 어떤 근거를 들 수 있을까요?
함께 읽으면 좋은 개념
관련 면접 질문 5개
클라이언트 사이드 라우팅(CSR Routing)은 어떻게 동작하나요?
클라이언트 사이드 라우터는 브라우저의 History API(pushState, popstate 등)를 사용해 서버로부터 새 HTML 문서를 매번 다시 받지 않고도 URL을 변경하고 그에 맞는 컴포넌트를 화면에 그려 줍니다. 뒤로 가기·앞으로 가기 탐색과 동적 경로 파라미터, 중첩 레이아웃, 데이터 로딩 및 에러 화면을 URL 상태와 동기화해 관리합니다. 다만 사용자가 특정 하위 경로(/products/42)를 주소창에 직접 입력하거나 새로고침할 때는 브라우저가 서버에 요청을 보내므로, 서버나 호스팅 설정에서도 해당 경로에 앱 엔트리 문서나 적절한 응답을 내려주도록 구성해야 합니다.
꼬리질문과 참고자료 →Next.js는 React에 어떤 기능과 아키텍처를 더하나요?
Next.js는 UI 라이브러리인 React 위에 파일 기반 라우팅, 서버 렌더링(SSR)·정적 생성(SSG)·스트리밍, 데이터 패칭 및 번들 최적화 구성을 통합해 제공하는 풀스택 웹 프레임워크입니다. 페이지나 컴포넌트 성격에 따라 서버에서 미리 HTML과 데이터를 준비해 초기 표시 속도와 검색 노출을 개선하고, 상호작용이 필요한 부분만 클라이언트 컴포넌트로 분리해 전달할 수 있습니다. 다만 사용하는 라우터 방식(Pages Router vs App Router)과 버전에 따라 서버·클라이언트 경계와 캐싱 동작이 다르므로 프로젝트 기준을 명확히 이해하고 설계해야 합니다.
꼬리질문과 참고자료 →SPA와 MPA는 어떤 기준으로 구분하나요?
SPA(Single Page Application)는 처음 로드된 하나의 HTML 문서를 유지한 채 클라이언트 라우팅과 데이터 교환으로 화면을 전환하는 구조이고, MPA(Multi Page Application)는 페이지 이동마다 서버로부터 새로운 HTML 문서를 받아 전체 페이지를 새로 로드하는 구조입니다. 여기서 중요한 점은 SPA·MPA는 '탐색 시 문서 교체 방식'에 대한 구분이고, CSR·SSR은 'HTML을 어디서 생성하는가'에 대한 구분이라는 것입니다. 따라서 현대 웹에서는 첫 진입은 SSR로 빠르게 HTML을 받고 이후 이동은 SPA처럼 부드럽게 전환하는 하이브리드 구조를 널리 사용합니다.
꼬리질문과 참고자료 →