서버 사이드 렌더링
server side rendering
뜻과 개념
서버에서 HTML을 만들어 브라우저에 전달하는 렌더링 방식입니다.
어떻게 작동하나요?
서버 사이드 렌더링은 서버에서 페이지의 HTML을 만들어 브라우저에 전달하는 방식입니다. 이용자가 받은 초기 응답에 주요 내용이 들어갈 수 있어 브라우저의 JavaScript 실행에만 의존하는 구조와 다릅니다. PHP로 본문을 출력하는 전통적인 웹사이트도 서버에서 HTML을 만드는 예입니다.
왜 알아야 하나요?
핵심 본문과 링크를 빠르게 전달하고 스크립트를 실행하지 못하는 환경에서도 읽을 수 있게 하는 데 유용합니다. 그러나 서버에서 처리할 작업이 많으면 응답이 느려질 수 있고, 이후 화면 상호작용에 필요한 코드가 별도로 있을 수 있습니다. SSR이라는 이름만으로 성능과 SEO가 보장되지는 않습니다.
실무에서 적용하는 방법
페이지 소스를 확인해 제목, 본문, 링크가 초기 HTML에 포함되는지 봅니다. 데이터 조회가 느리거나 실패했을 때 어떤 응답을 보내는지 점검하고 적절한 캐시를 설계하세요. 개인화된 정보가 다른 이용자에게 캐시로 노출되지 않도록 범위도 구분해야 합니다.
JavaScript가 추가로 동작하는 구조라면 서버와 브라우저가 같은 데이터를 기준으로 화면을 만드는지 확인합니다. 화면이 나타나는 시점과 버튼을 사용할 수 있는 시점은 다를 수 있으므로 둘 다 테스트합니다. 없는 주소는 적절한 오류 상태를 반환해야 합니다.
실무에서는 이렇게 봅니다
용어집 상세를 PHP가 데이터에서 읽어 HTML로 출력하고 검색 입력과 메뉴는 가벼운 JavaScript로 보완한다고 가정해 보겠습니다. 본문은 스크립트가 없어도 읽을 수 있습니다. 다만 데이터 읽기 오류를 빈 200 페이지로 처리하면 SSR이어도 검색과 이용 경험에 문제가 생깁니다.
주의할 점
SSR과 정적 생성, 스트리밍, 클라이언트 렌더링은 서로 조합될 수 있습니다. 프로젝트 요구와 호스팅 환경에 맞게 선택해야 합니다. 검색을 이유로 이미 잘 작동하는 단순 사이트를 불필요하게 복잡한 프레임워크로 바꿀 필요는 없습니다.
자주 묻는 질문
SSR이면 JavaScript를 안 쓰나요?
반드시 그렇지는 않습니다. 서버가 본문 HTML을 제공하고 브라우저에서 추가 상호작용을 붙이는 구조도 흔합니다.
SSR을 적용하면 무조건 빠른가요?
서버 작업과 네트워크, 캐시, 브라우저 코드에 따라 달라집니다. 실제 응답 시간과 화면 사용 가능 시점을 측정해 판단해야 합니다.