이제 React는 프론트엔드? 아니, 풀스택이다.

지금부터 내가 할 이야기는 React 19 이후의 얘기다. React 18 이하 버전은 해당되지 않으니 기존 리액트와 싸잡아서 내 글을 판단하는 일은 없기 바란다.

리액트는 업계에서도 인기있고, 말도 많고, 탈도 많지만, 여전히 많이 사랑받고 있는 Meta(페이스북)이 만든 오픈소스 프론트엔드 기술이다.
그리고 이 리액트가 19 버전을 작년 말에 출시하고 내가 소개한 바 있다.

리액트 19를 보면 알겠지만, 프론트엔드의 향상점이라고는 그저 유틸성 훅 말고는 뵈는 게 없어 보이고,
거의 서버 렌더링 쪽의 기능 추가 및 향상에 치중되어 있다는 이미지가 있다.
이에 대해 SPA 위주의 리액트 개발자들은 우려의 의견이 일부 존재하며, Next.js 가 지배하는 리액트 생태계를 탐탁치 않아 하는 개발자가 꽤 있다.
특히 시니어들에게는 더 이상 리액트답지 않은 리액트라고 말할 테지.
항상 그래왔어. 시니어들은 한 기술에 대격변이 일어나면 먼저 꺼내는 말이 'XX답지 않게 변했어.' 야.
내가 자바 8 나왔을 당시에도 이 소리를 들었거든. 람다가 왜 그런 소리를 들어야 하는지 당최 이해를 할 수 없었지만 말이야.
자바는 내가 겪어본 언어 중 가장 보수적인 축에 속하는 언어다. C#은 너무 진보적이어서 내가 '뇌절언어' 라고 놀리곤 했지만.

다시 리액트로 돌아와서,
리액트는 말이야. 프론트엔드 프레임워크에서는 앵귤러보다 느리다고 알려져 있다.
2024년 한 벤치마크 에 따르면,

• 리액트는 앵귤러 다음으로 JS 번들 크기가 크다. (SPA 기준)
• 리액트를 잘 쓰면 앵귤러보다 빠르지만 Svelte, Vue 등의 주요 프레임워크 기술보단 여전히 느리다.
• 하지만 SSR 에서 리액트는 상당히 강력함을 입증했다.

이런 결론을 내렸다고 한다. 일단 내가 찾은 게 전부라 조만간 자료가 있으면 더 얘기하도록 하겠다.
근데 대체적으로 결론은 비슷했다. 리액트가 경쟁 프론트엔드 기술보다 느린 건 심지어 공식 팀에서도 인정했기 때문이다.
그래서 리액트 팀이 현 상황에서 강점을 찾은 게 바로 SSR, 서버 렌더링에 좀 더 투자를 하기 시작했고,
마침 Next.js 및 Remix 와의 협업으로 SSR에 날개를 달기 시작했으며,
그리고 React 19는 Vercel 의 많은 기여와 테스트, 검증을 통해 SSR 기능을 넣어 탄생했다.
이런 점에서 차기 리액트는 호불호가 확실한, 이제 '프레임워크'라고 불러야 할 만큼 되버린 것.

React 19는 Next.js 만 쓸 수 있나?

아직은 그렇다. 하지만 곧 아니게 된다. 왜냐면 이미 몇몇 진영에서 리액트 19의 SSR 기능을 포함하여 개발 중이다.
React 19를 지원할 준비가 된 프레임워크들이 이미 준비 중이다. 대부분 너희들이 한번쯤 들어본, 아~ 할 것들이다.

• Tanstack Router (Tanstack query 많이들 쓰고 있지? 더 말할 것도 없다.)
• React Router (Remix 버전업 없다고? 응 없어. 앞으로도. 여기에 통합할 거거든. 근데 그거 아니고도 SPA에 많이 쓰잖아)
• Waku (일본어 '와꾸' 알지? Zustand 요즘 많이들 쓰기 시작했지? 거기서 만들고 있는 프레임워크다)

셋 다 쟁쟁한 짬들이 만들고 있는 프레임워크다.

• 서버 간의 통신 기능에 강한 Tanstack이냐,
• 라우팅의 최고봉 React Router 이냐,
• 상태관리의 신세계를 보여준 Zudtand 처럼 Waku가 또다른 신세계를 제공해 줄 것인가,

그러면 SSR은 Next.js 뿐인가?

아니다. 현재에도 쓸 수 있는 Remix도 있고, 심지어 네가 Express든 Hono든 연동해서 구현 가능하다.
그리고 정적 페이지에 매우 강한 모습을 보여주는 Astro 또한 각종 프론트엔드의 SSR 가능을 통한 SSG의 신세계를 보여준다.
따라서 SSR 기능 자체는 오래전부터 이미 성숙하게 구축되어 있고, 구축 또한 가능하다.
단지, 리액트 19의 서버 기능을 추가하기엔 아직 미숙한 면이 많아서 문제라면 문제지.
즉, 리액트 19 신기능만 빼고는 이미 생태계가 갖춰져 있으니 걱정 붙들어 매도 된다.

그러면 앞으로의 리액트는 풀스택인가?

팀에서 공식적으로 대놓고 풀스택 가겠다는 언급은 없지만, 리액트 19를 본 개발자들은 이런 느낌을 지울 수 없을 것이다.
특히 이를 찬양하는 한 블로그 사이트가 있다. 이 사이트는 앞으로의 리액트 19에 대한 강좌도 팔 정도로 꽤 리액트 신기술에 진심으로 나서기도 한다.
여기 말고는 아직 국내나 해외나 공격적으로 리액트 19에 대한 강좌나 리소스를 파는 곳은 아직은 보기 힘들 것이다.
가뜩이나 리액트 자체부터 러닝커브가 높은데 서버 기능까지 배우기엔 부담스러운 건 인정해야지.
결론은, 그렇다. 리액트는 지금 프론트엔드의 한계를 알고 있기에, 풀스택으로 눈을 돌릴 수밖에 없을 것이고,
앞으로 풀스택 기능에 Vercel 뿐만 아니라 위에 소개한 기여자들도 합세하여 리액트의 미래를 구축할 것은 자명한 일이다.

그럼 리액트 SPA는 죽는건가?

아니, 리액트 공식 팀이 Suspense에서 미처 발견하지 못했던 결함 때문에 19 출시를 중단한 바가 있기 때문에, SPA에 더 신경쓰지 않는다는 걱정은 안해도 된다. 특히 use 훅에 대한 기대가 있고, 지속적으로 React에 맞는 훅 함수를 rfc 통해 제시하고 의논하고, 그리고 이게 검증이 끝나면 선정하기도 한다. 낙관적 상태관리 훅인 useOptimistic 지원 시작과, startTransition 의 비동기 함수 지원을 보라. 리액트는 SPA로 시작했기 때문에 무작정 손놓지는 않을 것이고, 결국엔 리액트에 상태관리가 한 배에 탔으니, 없어질 일은 없다. React 컴파일러 가지고 지지고 볶는게 괜히 있는 게 아니라는 소리다.

그럼 미래의 리액트를 개발한다면 선택은?

선택의 폭이 넓어진다는 점을 알아두기 바란다. 한국은 항상 그래왔다. 윈도우만 써야 하고, 한글워드 써야 하고, IE 써야했던 시절이 있었다. 물론 지금은 어느정도 선택의 폭이 생겨서 꼭 자바를 백엔드로 써야 하는 시장은 아니다. 물론 네이버나 카카오 같은 거대 기업들은 자바를 주력으로 쓰긴 하지만.
어쨌든, 앞으로의 리액트 개발 시 지금과 크게 다르지 않을 것이고, 선택지가 하나 추가된다고 생각하면 된다.
Next.js 를 보면 간단하다. App Router 냐 Page Router냐 선택하는 그런 식이라는 것이다.

배고파서 이만 줄이겠다.
끗.