프레임워크는 무엇을 하는가
프레임워크는 반복되는 문제를 미리 해결해둔 코드 뼈대예요.
SSR의 핵심 기능들—Hydration, 라우팅, 데이터 페칭, SSG, ISR—을 직접 구현할 수 있어요. 기능적으로는 동작하지만, 실제 서비스에 적용하려면 넘어야 할 산이 더 있어요.
4장에서 직접 구현한 것들
직접 구현 | 프레임워크 |
hydrateRoot 직접 호출 | 자동 Hydration |
수동 라우팅 (경로 매칭) | 파일 기반 라우터 |
수동 데이터 페칭 | getServerSideProps / loader |
수동 직렬화 (JSON.stringify) | 자동 serialization layer |
SSG 빌드 스크립트 | 빌드 시 자동 생성 |
이걸 매번 직접 만드는 건 비효율적이에요. 그래서 프레임워크가 추상화해서 제공해요.
이 장에서는 프레임워크가 무엇인지, 그리고 왜 필요한지 살펴볼게요.
이 장의 구성
직접 구현의 한계
직접 구현한 것들을 다시 살펴보면, 각각은 동작하지만 프로덕션 레벨로 끌어올리기엔 부족한 점들이 보여요.
•
번들 크기: 앱이 커지면 초기 로딩이 느려짐 → 코드 스플리팅 필요
•
빌드 관리: 빌드할 페이지 목록을 수동으로 관리 → 자동화 필요
•
이미지 최적화: 포맷, 크기, 로딩 전략 → 직접 구현하면 복잡함
•
개발 경험: HMR, 프록시, 환경 변수 → 매번 설정하기 번거로움
프레임워크는 이런 문제들을 검증된 방식으로 해결해줘요. 핵심 원리를 이해하는 건 중요하지만, 매 프로젝트마다 처음부터 구현하는 건 비효율적이에요.
본질로 돌아가기
3장에서 봤던 본질로 돌아가볼게요:
“서버에서 HTML 형태로 응답을 만들어 보내요 - 이게 전부예요.”
4장의 모든 기능이 이 기본 원리 위에 쌓여 있고, 프레임워크는 이 과정을 자동화했을 뿐이에요.
Next.js의 getServerSideProps도, Remix의 loader도, Nuxt의 asyncData도 결국 같은 원리의 다른 표현이에요. 서버에서 데이터를 가져오고, HTML을 만들어서 보내는 것.
프레임워크는 마법이 아니에요. SSR 원리의 당연한 확장이에요.
다음 단계
직렬화, Streaming SSR, React Server Components, Server Actions—모두 “서버와 클라이언트 경계”를 다루는 다른 방식이에요.
