SSR vs SPA | 어느 것을 사용할까?

It looks like only the source citation was provided. Could you please share the text you’d like translated into Korean? Once I have the content, I’ll translate it while keeping the source line unchanged.

소개

이 글의 목적은 여러분이 애플리케이션에 가장 적합한 기술을 선택하도록 안내하는 것입니다.

제가 커리어를 시작했을 때, JSF (JavaServer Faces)를 사용했으며, 이는 MPA (Multi‑Page Application) 형태로 서버가 완전히 렌더링된 HTML을 브라우저에 전달하고 브라우저는 이를 표시만 했습니다. 사용자의 각 상호작용은 새로운 요청을 발생시키고, 그 결과 새로운 페이지 로드가 이루어졌습니다.

그 후 얼마 지나지 않아 Ajax가 jQuery와 함께 인기를 폭발시켰고, 페이지의 일부만 업데이트할 수 있게 되었습니다. 이는 애플리케이션에 더 많은 동적성을 부여하고 전체 reload 횟수를 크게 줄여, 서버‑사이드 모델을 포기하지 않으면서 사용자 경험을 개선했습니다.

다음으로 큰 전환점이 있었습니다. 개인용 디바이스가 더 강력해지고 브라우저가 발전하면서 클라이언트를 인터페이스 렌더링의 주요 담당자로 활용할 수 있는 여지가 생겼습니다. 이러한 맥락에서 SPA (Single‑Page Application) 모델이 인기를 얻으며 프런트엔드 개발을 장악하게 되었습니다.

SPA는 백엔드를 API 제공자로 정립하고, 프런트엔드와 백엔드를 보다 명확히 분리했습니다. 이 변화는 인프라 비용을 절감하고 아키텍처 유연성을 높였지만, 새로운 문제도 가져왔습니다: 애플리케이션의 최초 로드가 느려지고 공개 페이지의 SEO가 크게 악화되었습니다.

이러한 상황에서 SSR이 등장하여 SPA의 문제점을 과거 모델로 단순히 되돌아가지 않고 해결하려는 시도를 합니다. 페이지가 서버에서 렌더링되어 초기 로드가 더 빠르고 인덱싱이 개선되지만, 초기 전달 이후에는 브라우저에서 SPA처럼 동작합니다.

시간이 흐르면서 변한 것은 단순히 기술만이 아니라 서버, 클라이언트, 성능 및 사용자 경험 간의 책임 균형을 맞추는 방식이었습니다.

어느 것을 사용해야 할까?

• 이 애플리케이션은 누구를 위한 것인가?
  내부 시스템, 관리 패널, 인증된 도구, 혹은 최종 사용자를 대상으로 하는 공개 애플리케이션인가요?

• 예산은 얼마인가요?
  서버 렌더링, 캐시 및 추가적인 확장성 비용을 포함한 더 복잡한 인프라를 유지할 자원이 있나요?

• 첫 번째 렌더링이 빨라야 하나요?
  첫 번째 가시 콘텐츠까지의 시간이 사용자 경험에 중요합니까?

• SEO가 페이지에 중요한가요?
  콘텐츠가 검색 엔진에 색인되거나 소셜 미디어에서 적절한 미리보기와 함께 공유되어야 합니까?

• 애플리케이션 규모는 어느 정도인가요?
  첫 번째 렌더링이 빨라야 하더라도, 애플리케이션의 규모와 복잡성이 SSR 사용을 정당화하지 않을 수도 있습니다.

SPA는 누구를 위한 것인가

SPA를 사용하세요, 애플리케이션이 웹사이트보다 소프트웨어처럼 동작할 때. 이러한 경우 첫 렌더링 시간과 SEO는 중요한 요소가 아닙니다.

예시

• 내부 도구 또는 접근을 위해 인증이 필요한 애플리케이션.
  기능과 정보는 일반 대중에게 공개되지 않고, 내부 팀, 파트너 또는 인증된 고객과 같은 특정 사용자에게만 제한됩니다.

SSR은 누구를 위한 것인가

SSR을 사용할 때 애플리케이션이 소프트웨어보다 웹사이트처럼 동작할 때. 이러한 시나리오에서는 첫 렌더링 시간과 SEO가 프로젝트 성공의 핵심 요소입니다.

예시

• 기업 사이트, 블로그, 콘텐츠 포털, 전자상거래 및 랜딩 페이지.
  콘텐츠가 빠르게 제공되고, 검색 엔진에 쉽게 인덱싱되며, 소셜 미디어에 공유될 때 올바른 미리보기가 생성되어야 합니다.

결론

제 경력 동안 SSR로 작은 애플리케이션을 만들고 SPA가 충분히 대응할 수 있는지 검증하기 전에 만든 경우를 보았습니다. 또한 접근이 많은 작은 애플리케이션이 요청량을 처리하기 위해 16대의 서버가 필요했지만, 내용 중 일부만 공개되고 대부분은 인증된 상태였습니다. 이런 경우 두 개의 별도 애플리케이션을 두어 서버 수를 줄일 수 있었습니다.

결국, 가장 좋은 기술은 비즈니스 요구 사항을 충족하면서 비용과 이점을 올바르게 균형 잡는 기술입니다.