01. Intro.

이번 글은 필자가 최근에 심도있게 공부하고 팔로우 업하고 있는 하나의 현상에 대해 조금 끄적여 볼까한다.

우리는 보통, 각 분야 혹은 포지션에서 누군가 그 길이 되어주는 사람들이 닦아 온 길을 살펴보고 따라간다.

이게 무슨 개발자 블로그에 엉뚱한 소리냐? 라고 반문하실 수 도 있다.

하지만, 그 원리는 프로그래밍의 세계에서도 역설적이게도 통요되는 이야기다.

필자가 하려는 이야기는 어쩌면 하나의 프레임워크 얘기일 수도 있겠지만, 이미 수 년 동안 프론트엔드 챕터의 가장 큰 영향력을 행사하고 있는 리액트에 대한 이야기다.

02. react에 대하여.

아래 그림은 위키 피디아에서 리액트에 대해 서술해 놓은 부분이다.
리액트는 이미 출시된 지 10년이 넘은 장수 라이브러리다.

어쩌면, 이 프로그램은 누구보다 프로그래머들의 편의성과 사용성에 맞게 발 맞춰왔기에, 이 정도로 장수하고 있는 게 아닌가 싶다. 또 물론, 갑자기 어떤 획기적인 라이브러리나 프레임워크가 나와 대체될 지는 그 누구도 모른다. 항상 시장은 혁신과 변혁이 있어야 살아남는 것이. 그게 시장의 원리니까.

하지만, 그럼에도 불구하고 리액트는 급변하는 프론트의 역사를 토대로 봤을 때도 정말 장수한 프로그램임에는 누구나 다 아는 사실이다.

그렇다면, 리액트를 엄청 칭송할려고 글을 썼냐고 물을 수 있지만, 사실 반은 맞고 반은 틀리다.

이번 글에서는 필자의 의도는 리액트와 그와 관련된 여러 식구(라이브러리)들이 뭔가 같은 흐름으로 흘러간다는 느낌을 받았다. 그래서 그 흐름이 무엇인지에 대해 한 번 끄적여 보겠다.

03. csr? ssr?

먼저, 이 논쟁이 항상 끊임 없지만, csr vs ssr에 대해서다. 물론 이글은 이에 대해서 자세히 말하지는 않을 예정이다. 단순히 어떤 흐름 정도인지 정도만이다.

불과 몇년 전만해도 csr이 대세였다. 하지만, 필자는 항상 여기에 의심을 품었다. 과연 리액트는 csr을 위한 도구일 뿐인가? 그렇다면 ssr은 죽었다 깨놓아도 못 하는건가?

하지만, 이제 react 18의 등장과 동시에 다양한 기능들이 "야! 나두? 너두?" 마치 이런 과거 문구처럼.

"이제 나도 ssr할 수 있고 준비해 놓았다"를 외치는 것과 같다. 물론 그걸 위해서는 조금 이해해야 할 필수적인 개념들이 좀 있다. 그것들 하나, 둘 천천히 살펴보자.

04. how? what?

그렇다면, 과연 어떻게 그리고 무엇이 그것을 가능하게 했는 지에 대해 리액트 18버전을 통해서 살펴보자.

물론, 여기서는 전체 모든 기능들을 세부적으로 다룰 수는 없다. 대표적으로 기존에도 물론 있었지만, 리액트 18버전에 들어오면서 보다 강화된 서버쪽 기능들을 살펴보고자 한다.

1) RSC

react18의 가장 큰 특징 중 하나를 꼽자면, react server component의 도입이라고 생각한다.

이유는 다음과 같다.

크게 보면, 결국 기존의 csr 방식과는 다르게, 클라이언트 전용 컴포넌트와 서버 전용 컴포너트가 분리된다. 최근 next13의 app-router 방식의 페이지 렌더링 방식도 아마도 이를 바탕으로 만들어진 것일 것이다. 이에 대해서는 이번 시리즈가 아닌, 다음 시리즈에서 보다 자세히 다루겠다.

아래 코드를 살펴보자. 아래 코드를 보면, 메시지 관련된, data를 db에서 직접 접근해서 랜더링하도록 하는 것을 볼 수 있다.

// Message.server.js

import {db} from './db.server';

function Message({id}) {
  const message = db.messages.get(id);
  return (
    <div>
      <h1>{message.title}</h1>
      <p>{message.body}</p>
    </div>
  );
}

export default Message;

아래 다시 살펴보면, 클라이언트 단에서 스테이트로 선택한 아이디를 바탕으로 Message 컴포넌트가 그려지는 것을 다시 확인할 수 있다.

// App.client.js

import {useState} from 'react';
import Message from './Message.server';

function App() {
  const [selectedId, setSelectedId] = useState(1);
  return (
    <div>
      <button onClick={() => setSelectedId(selectedId + 1)}>
        Next
      </button>
      <Message id={selectedId} />
    </div>
  );
}

export default App;

즉, 위의 예시 코드처럼 결국 리액트는 어떤 부분은 서버로 어떤 부분은 클라이언트단에서 제어하게 분리시켜 둔 것이라고 볼 수 있다.

그렇다면 도대체 왜? 왜 이렇게 굳이 하지라는 반문을 하실 수 있다.

5) why?

React팀의 최종 목표를 나타내는 간단한 그림을 한 번 살펴보자. 서버에서 렌더링 되는 컴포넌트가 주황색, 클라이언트에서 렌더링 되는 컴포넌트가 파랑색이다.

결국, 이유는 간단하다. 기존의 클라이언트 단으로만 제어했던 랜더링 구조는 현대적으로 복잡해 지는 웹 브라우저 환경에서 점점 기능이나 성능적으로 한계를 가져왔다. 뭐, 흔힌들 얘기하는 seo 측면 뿐만 아니라, 클라이언트 단에서는 서버 단 로직에 접근 자체가 안 되었고, 그에 따라 랜더링이나 로직 처리에 있어서 시간이 걸렸다.

이런 것들이 한 개, 두 개 쌓여감에 따라 사용자의 ux에도 좋지 않은 결과를 끼쳐오게 되는 것이었다.

그렇다면 정말 우리는 rsc가 필요할까?

이전 업급처럼 React 서버 컴포넌트가 등장하기 전 모든 React 컴포넌트는 브라우저에서 동작하는 “클라이언트” 컴포넌트였다. 브라우저가 React 페이지를 방문하면 필요한 모든 React 컴포넌트에 관한 코드를 다운로드한 뒤 React 컴포넌트 트리를 구성하고 이를 DOM에 렌더링했다.

(또는, SSR을 사용하는 경우 DOM에 hydrate를 수행함) React 앱은 상호작용이 가능하기 때문에 이벤트 핸들러를 추가하고, 상태를 추적하며, 이벤트에 대한 응답으로 React 트리를 변경하고 DOM을 효율적으로 업데이트 할 수 있다.

그럼 여기서 또 하나 의문이다.

왜 우리는 서버에서 렌더링 하고 싶어 할까?

브라우저에 비해 서버 랜더링이 같는 장점은 다음과 같다.

1) db등과 같은 서버 로직에 대한 접근의 자유도.

서버는 데이터베이스, GraphQL 엔드포인트 혹은 파일시스템 같은 데이터 소스에 더욱 직접적으로 접근 가능하다. 서버는 API 엔드포인트를 거치지 않고 필요한 데이터를 직접 가져올 수 있으며 일반적으로 데이터 소스와 더 가깝게 위치해 브라우저보다 더 빠르게 가져올 수 있다.

2) 무거운 코드 모듈

서버는 “무거운” 코드 모듈을 더욱 가볍게 이용할 수 있다. 예를 들어, 브라우저에서 마크다운을 html로 렌더링 하기 위한 무거운 npm 패키지를 항상 번들로 받은 뒤 사용하는 것 대신 서버에서는 이런 의존성들을 매번 다운로드 할 필요가 없다.

즉, 각자가 각자가 잘하는 역할을 하기 위한 분리라고 생각하는 것이 좋다.

간단히 말해서 React 서버 컴포넌트는 서버와 브라우저가 각자 가장 잘 할 수 있는 것을 담당하게 하는 것을 가능하게 한다.

서버 컴포넌트는 데이터 가져오기 및 콘텐츠 렌더링에 집중할 수 있고 클라이언트 컴포넌트는 상태 저장 및 상호 작용에 집중할 수 있게 된다. 그로 인해 페이지 로드 속도는 증가하고 자바스크립트 번들은 작아지며 사용자 경험이 향상될 것이다.

6) who's the next?

자 이번에는 왜 리액트 18버전에서 rsc가 도입되었고, 어떻게 작동하는 지에 대해 정말 간단하게만 살펴봤다. 다음 글은 앞서 언급한 rsc외에도, renderToReadableStream 등의 기능에 대해 더 deepdive 할 예정이다. 추가로 리액트 외에 다른 next, react-query등이 그에 맞춰 그들이 어떻게 준비하고 있는 지에 대해 알아보겠다.