서버 사이드 렌더링의 흑과 백

최근 한 디자이너 분의 요청으로, 웹뷰에서 페이지가 로드될 때 반쯤만 화면이 그려지는 현상을 개선하는 작업을 진행하게 되었습니다. 이 문제를 해결하면서 자연스럽게 Next.js의 SSR(Server Side Rendering) 구조에 대해 다시 한번 생각해보게 되었는데요, 오늘은 그 경험을 정리해보고자 합니다.

SSR의 장점: 서버에서 먼저 그려지는 화면

Next.js처럼 SSR을 지원하는 프레임워크를 사용할 경우, 가장 큰 장점은 초기 페이지 요청 시 필요한 데이터를 서버에서 미리 불러올 수 있다는 점입니다. 예를 들어 fetch + Suspense 형태의 CSR(Client Side Rendering)을 사용할 경우, 사용자에게는 일단 빈 화면이나 스켈레톤 UI가 먼저 보이게 됩니다.

하지만 이런 반쯤만 보이는 화면이나 스켈레톤 상태를 디자인적으로 보완하려면, 디자인팀 입장에서는 상당한 공수가 추가로 필요합니다. 시각적으로 어색하지 않으면서도 자연스러운 로딩 경험을 설계하는 것이 결코 간단한 일이 아니기 때문입니다.

결국 이번 작업에서는 개발단에서 SSR을 적극적으로 활용함으로써, 처음부터 완성된 UI가 그려지도록 구성하였고, 이로 인해 디자인팀의 부담은 줄이고 사용자 경험은 더욱 매끄럽게 개선할 수 있었습니다.

디자인과 개발 모두의 만족을 이끌어낸 선택이었던 셈입니다.

실무 사례에서 보는 절충안: Airbnb의 접근

이번 작업을 진행하며 관련 리서치를 해보던 중, Airbnb의 SSR 전략이 인상 깊었습니다.

Airbnb는 SEO가 필요한 핵심 정보들—예를 들어 숙소 제목, 가격, 위치 등—만을 서버에서 미리 불러오고, 그 외 UI 구성 요소들은 클라이언트에서 자연스럽게 스켈레톤 형태로 로드되도록 설계하고 있었습니다.

이러한 방식은 서버 자원을 과도하게 소모하지 않으면서도, 검색 엔진 최적화(SEO)와 사용자 경험 사이의 균형을 지키는 좋은 예시라 할 수 있습니다.

즉, 무엇을 서버에서 그리고, 무엇을 클라이언트에서 그릴 것인가를 정교하게 구분하는 전략이 필요한 시대입니다.

SSR의 단점: 서버 자원은 무한하지 않다

하지만 SSR이 무조건 좋은 것만은 아닙니다. 브라우저에서 API를 직접 호출하는 구조와 달리, 모든 요청이 서버를 통해 처리되기 때문에 사용자가 많아질수록 서버의 부담은 기하급수적으로 증가하게 됩니다. 결국, 렌더링의 책임이 클라이언트에서 서버로 넘어가게 되면서 서버 자원의 관리가 매우 중요해집니다.

또한, Next.js가 제공하는 Server Component나 API Routes 등은 SSR을 훨씬 쉽게 만들기는 하지만, 개발자 입장에서는 여전히 "서버 자원을 효율적으로 관리해야 한다"는 숙제가 남습니다.

정답은 없지만, 전략은 있다

이번 작업을 통해 SSR이 항상 정답은 아니라는 것을 다시금 느꼈습니다. 어떤 페이지는 SSR이 적합하고, 어떤 페이지는 CSR이나 SSG(Static Site Generation)가 더 효율적일 수도 있습니다.

중요한 건 "언제 서버 자원을 사용하고, 언제 클라이언트에 위임할 것인가"에 대한 전략적 판단입니다. 적절한 캐싱 전략, 경량화된 서버 구성, 그리고 사용자 접점에 따른 렌더링 전략 분리가 필요합니다.

결론적으로, SSR은 분명 유저 경험을 개선할 수 있는 강력한 도구입니다. 하지만 그만큼 인프라 설계와 자원 관리에 대한 고민이 반드시 동반되어야 합니다. 이번 사례처럼 영리하게 SSR을 활용하면, 빠르면서도 사용자 친화적인 서비스를 구현할 수 있습니다.