마케팅팀이 "랜딩 페이지가 구글에 안 떠요"라고 항의합니다. 개발자는 "저희 앱이 CSR이라 그래요, SSR로 바꾸거나 정적 생성해야 해요"라고 답합니다. 한편 인프라 담당은 "그럼 서버를 더 띄워야 하나요, 아니면 CDN만으로 되나요?"가 궁금합니다. 프론트엔드/백엔드의 경계와 렌더링 방식이 SEO·서버 부하·배포 형태에 어떻게 연결되는지 모르면, 이 대화의 결정을 내릴 수 없습니다.
- 1프론트엔드·백엔드·풀스택의 경계를 "어디서 실행되고 무엇을 책임지는가"로 설명할 수 있다
- 2CSR·SSR·SSG를 "HTML을 누가 언제 만드는가"로 구분할 수 있다
- 3렌더링 방식이 SEO와 초기 로딩 체감에 주는 영향을 설명할 수 있다
- 4렌더링 방식에 따라 배포 형태(CDN vs 런타임 서버)가 달라짐을 판단할 수 있다
프론트엔드 · 백엔드 · 풀스택
실행 위치와 책임으로 나누는 경계
"프론트는 디자인, 백은 코딩"은 흔한 오해입니다. 진짜 경계는 어디서 실행되고 무엇을 책임지는가입니다.
- 프론트엔드(Frontend): 사용자의 브라우저/앱에서 실행. 화면 렌더링, 입력 처리, API 호출. (React, Vue, iOS/Android 앱)
- 백엔드(Backend): 서버에서 실행. 데이터 저장·조회, 비즈니스 로직, 인증/권한, 외부 연동, 보안. (Spring, Django, Express)
- 둘의 연결: [[api-contract]]에서 다루는 API(주로 HTTP/REST)로 데이터를 주고받습니다.
- 풀스택(Full-stack): 한 사람/한 구성이 프론트와 백을 모두 다루는 것.
PM 관점: 하나의 기능도 "화면(FE) + 서버 로직(BE) + 둘을 잇는 API"로 쪼개집니다. 추정·일정에서 이 세 갈래를 따로 보면 누락이 줄어듭니다.
렌더링 — HTML을 누가, 언제 만드는가
CSR · SSR · SSG: 화면이 그려지는 시점과 장소
같은 화면도 "HTML을 누가 언제 만드느냐"에 따라 SEO·속도·배포가 달라집니다.
- CSR(Client-Side Rendering): 서버는 거의 빈 HTML+JS를 보내고, 브라우저가 JS를 실행해 화면을 그림. 앱처럼 인터랙션이 풍부. 단, 첫 응답엔 콘텐츠가 비어 SEO·초기 체감에 불리할 수 있음.
- SSR(Server-Side Rendering): 요청 시점에 서버가 완성된 HTML을 만들어 전송 → 브라우저는 바로 콘텐츠를 보고, 이후 JS가 상호작용을 붙임(hydration). SEO·초기 체감 유리, 서버 연산 증가.
- SSG(Static Site Generation): 빌드 시점에 미리 HTML을 생성해 정적 파일로 둠. 가장 빠르고 CDN 친화적. 단, 내용이 자주 바뀌면 재빌드 필요.
CSR: 서버[빈 HTML+JS] ─▶ 브라우저가 그림 (서버 연산 적음 / SEO 약함)
SSR: 요청마다 서버가 HTML 생성 ─▶ 전송 (서버 연산 큼 / SEO 강함)
SSG: 빌드 때 HTML 미리 생성 ─▶ CDN이 그대로 전달 (가장 빠름 / 갱신 시 재빌드)
렌더링 방식과 배포 형태 — 직접 확인
서버가 주는 첫 HTML에 실제 콘텐츠(텍스트·제목)가 들어 있으면 SSR/SSG, 거의 비어 있고 <div id=\"root\"></div> 같은 빈 컨테이너 + 큰 JS 번들만 있으면 CSR입니다. 인프라 준비(서버 vs CDN)를 가늠하는 단서입니다.
# 첫 응답 HTML 확인 (JS 실행 전 상태)
curl -s https://example.com/ | head -40
# 본문 텍스트가 응답에 실제로 들어있는지 검색
curl -s https://example.com/ | grep -o "기대하는 본문 키워드" | head
<!-- SSR/SSG인 경우: 콘텐츠가 그대로 보임 -->
<h1>서비스 소개</h1><p>저희는 ...</p>
<!-- CSR인 경우: 빈 컨테이너 + 번들만 -->
<div id="root"></div>
<script src="/static/js/main.8f3a.js"></script>
curl -s https://example.com/ | head -40- 첫 응답 HTML에 본문 텍스트가 보이면 SSR/SSG → 크롤러가 콘텐츠를 본다(SEO 양호). 인프라는 SSR이면 런타임 서버, SSG면 CDN으로 준비
- <div id="root"></div>만 있고 본문이 없으면 CSR → JS 실행 후에야 콘텐츠가 생김. SEO가 중요하면 렌더링 전략 변경을 개발팀과 논의
- curl 응답 크기가 작은데(빈 HTML) JS 번들이 수 MB면 CSR 특징 — 초기 로딩 체감이 느릴 수 있어 코드 분할/캐싱 검토 신호
- SSR로 판단되면 배포 시 상시 실행 서버의 헬스체크·오토스케일·메모리 한도가 필요하다(정적 CDN만으론 부족)
상황: CSR 기반 SPA(React 등)를 정적 파일로 Nginx에 배포했는데, 첫 진입은 되지만 /dashboard에서 새로고침하거나 URL을 직접 치면 404가 납니다.
원인: SPA의 라우팅은 브라우저(JS)가 처리합니다. 서버에는 /dashboard라는 실제 파일이 없어, Nginx가 그 경로의 파일을 찾다 404를 반환합니다. 첫 진입은 /로 들어와 JS가 라우팅했기에 됐던 것입니다.
진단:
curl -I https://example.com/dashboard # 404 Not Found 확인
ls dist/ # index.html만 있고 dashboard 파일은 없음
해결: 알 수 없는 경로를 모두 index.html로 보내(SPA fallback) JS 라우터가 처리하게 합니다.
location / {
try_files $uri $uri/ /index.html; # 파일 없으면 index.html로
}
SSR 앱이라면 이 문제가 없습니다(서버가 각 경로를 렌더하므로) — 이것이 렌더링 방식이 인프라 설정까지 바꾸는 예입니다.
인프라 엔지니어로서 "프론트엔드 배포해 주세요" 요청을 받으면, 가장 먼저 렌더링 방식을 묻습니다. **정적 번들(CSR/SSG)**이면 S3+CDN 또는 Nginx로 끝나고 서버 비용이 거의 없습니다. SSR이면 Node 런타임 서버를 상시 띄우고 오토스케일·헬스체크·메모리 한도를 잡아야 하며, 트래픽에 비례해 비용이 듭니다. 이 한 번의 질문이 아키텍처와 클라우드 청구서를 가릅니다.
다음 모듈에서는 이런 FE/BE·렌더링 용어가 실제 채용공고·기술스택 문서에서 어떻게 나열되는지, 그 목록을 층위로 읽는 법을 다룹니다.