안녕하세요 단테입니다.
오늘은 SSR 구현시 상태관리 라이브러리를 사용해야 하는 근본적인 이유에 대해 이야기해보겠습니다.

서버사이드에서 생성된 html과 hydration이후의 돔이 변경점이 없게 하기 위해 가장 간단한 방법이 상태관리 도구 도입입니다.

모듈로 임포트하는 방식

자바스크립트 모듈로 만들어진 인스턴스는 전체 프로그램에서 싱글톤으로 만들어지기 때문에 리퀘스트나 특정 동작/연산마다 새롭게 생성되게 하기 위해서는 함수에서 반환하는 형태로 작성이 되어야 합니다.

// A simple global state
let globalState = {
  username: null
};

export default globalState;

여기서 인스턴스는 Object literal나 클래스로 생성된 인스턴스를 의미하며 . operator를 통해 속성값으로 다른 모듈에서 사용되는 객체입니다.

클라이언트 사이드 렌더링으로만 동작하는 앱의 경우 브라우저에서 상태 객체 초기화가 되기 때문에 상태 모듈을 사용하는 대상은 사용자 말고는 없습니다.

다음은 브라우저, 서버 환경에서 상태관리 인스턴스를 접근하는 것을 도식화한 다이어그램입니다.

클라이언트 사이드 렌더링에서의 자바스크립트 모듈 사용

글씨가 잘 안보일 수 있는데 첫번째는 Browser, 두번째 줄은 Javascript Module입니다.
Javascript Module 내부에는 앞서 봤던 예제 코드와 같이 생긴 Global state(전역 객체)가 있습니다.

// A simple global state
let globalState = {
  username: null
};

export default globalState;

이 전역 객체를 사용해 앱의 전체 생애 주기동안 이런 저런 액션을 하더라도 이 객체를 사용하는 주체는 유저 단 한명이기 때문에 상태에 다른 유저의 정보가 흘러들어갈 여지가 없습니다. 다른 브라우저의 사용자로부터 오염되지 않는 순수한 상태 객체로 남아있습니다.

서버사이드 렌더링에서의 자바스크립트 모듈 사용

서버 사이드 렌더링(SSR)으로 구동되는 앱은 웹 어플리케이션 서버에서 특정 객체 인스턴스를 사용해서 화면을 그리는데 필요한 정보를 취합합니다.

노드 서버에서는 자바스크립트 모듈의 객체를 사용할 수 있는데

이때 두 명의 유저가 순차적으로 서버로 요청을 보냈을 때 Singleton으로 제작된 인스턴스를 참조하여 상태 값을 업데이트하고 생성한다면 User2는 User1의 요청에서 이미 한번 가공된 이력이 있는 인스턴스에 영향을 받게 됩니다.

그래서 두 개의 Request에서 상태 객체가 오염되는 상황이 오기 때문에 본 글의 처음에서 이야기했던 각 요청마다 새롭게 인스턴스를 생성하게 도와주는 함수가 필요합니다.

전역 상태 라이브러리의 사용

서버에서는 상태관리를 참조하고 있다가 브라우저를 다시 그리는 등의 reacivity가 필요 없지만
서버사이드 렌더링에서 생성된 html이 hydration 과정을 거친 이후에는 상태 객체는 reactivity 해야 이후 클라이언트 사이드에서 상태 변경에 대한 re-paint를 발동할 수 있습니다.

따라서 앞서 말한 상태 인스턴스 오염과 hydration이후의 reactivity를 같이 충족시키기 위해 가장 간단한 방법이 상태 관리 도구의 사용입니다.

Vue3부터 공식 상태관리 도구로 지정된 pinia의 문서를 보면 이러한 상태인스턴스 오염을 방지하는 것이 Pinia를 도입해야 하는 한가지의 이유가 될 수 있다고 이야기합니다.