🤔 왜 아직도 React를 쓰시나요?

React의 위상이 흔들리고 있다는 신호

요즘 웹 개발 커뮤니티에서 뜨거운 논쟁이 하나 있어요. 바로 "React, 정말 필요한가?"라는 질문이죠. 전 세계 개발자들이 사용하는 프레임워크 1위, Netflix와 Airbnb가 선택한 그 React 말이에요. 근데 최근 웹 개발 트렌드를 보면 뭔가 분위기가 달라지고 있거든요.

2024년 JavaScript Rising Stars 보고서에 따르면 항상 1위를 차지했던 React가 htmx에 밀려 2위를 기록했다고 해요. Stack Overflow 2024 개발자 설문조사에서도 흥미로운 결과가 나왔는데요, React의 실제 사용률은 여전히 39.5%로 높지만 만족도 조사에서는 Solid(90.5%), Svelte(89.6%), Qwik(87.4%) 같은 새로운 대안들이 React(68.2%)보다 훨씬 높은 점수를 받았어요. 뭔가 변화의 바람이 불고 있는 것 같지 않나요?

더 놀라운 건 State of JS 2023 조사에서 개발자의 42%가 "React를 다시는 사용하고 싶지 않다"고 답했다는 거예요. 한때 90%가 넘는 만족도를 자랑하던 React의 위상이 이렇게 흔들리고 있다니, 무슨 일이 벌어지고 있는 걸까요?

관성에 의한 선택, 그게 정말 최선일까요?

솔직히 말하면 대부분의 개발자들이 React를 선택하는 가장 큰 이유는 '익숙함'이에요. 이미 알고 있고, 팀원들도 알고 있고, 채용할 때도 편하니까요. Indeed.com 2024 조사에 따르면 React 개발자 구인 공고가 Vue나 Angular보다 3배 이상 많다고 해요. 생태계도 방대해서 필요한 라이브러리는 거의 다 있죠.

하지만 이게 과연 사용자를 위한 최선의 선택일까요? 회사에서 "우리는 React로 표준화합니다"라고 하면 개발자 입장에선 편할 수 있어요. 근데 이런 결정이 실제 웹사이트를 쓰는 사람들한테는 어떤 영향을 미칠까요?

사용자들은 우리가 어떤 프레임워크를 쓰는지 관심 없어요. 그냥 빠르고 부드럽게 작동하는 웹사이트를 원할 뿐이죠. Google의 Core Web Vitals 연구에 따르면 페이지 로딩 시간이 1초에서 3초로 늘어나면 이탈률이 32%나 증가한다고 해요. 5초가 되면? 무려 90%가 떠나버려요. 모바일에서는 더 심각하고요.

브라우저에서 실행되는 React, 그게 문제예요

React의 가장 큰 문제는 클라이언트 사이드에서 실행된다는 거예요. 사용자가 웹사이트에 접속하면 React 전체를 다운로드하고, 파싱하고, 실행해야 하죠. 이게 얼마나 무거운 작업인지 아시나요?

HTTP Archive 2024 데이터를 보면 일반적인 React 기반 웹사이트의 JavaScript 번들 크기는 평균 450KB 정도예요. Gzip으로 압축해도 150KB는 넘죠. 빠른 4G 환경에서도 이걸 다운로드하는 데 1초 이상 걸려요. 3G 환경이라면? 4초는 각오해야 해요.

더 큰 문제는 다운로드 후에도 파싱과 실행 시간이 필요하다는 거예요. 구글의 연구에 따르면 중급 스마트폰에서 450KB의 JavaScript를 파싱하고 컴파일하는 데 약 2.5초가 걸린다고 해요. 그러니까 사용자는 최소 3~6초는 기다려야 제대로 된 인터랙션이 가능한 거죠.

서버에서 코드를 실행할 때는 파일 크기가 크든 작든 큰 문제가 안 돼요. 느리면 서버를 업그레이드하면 되니까요. 하지만 클라이언트는 다르죠. 사용자의 낡은 스마트폰, 느린 네트워크 환경까지 다 고려해야 해요. 그런데 React를 브라우저에서 실행하면 이 모든 부담이 사용자에게 가는 거예요.

Next.js의 하이드레이션, 누구를 위한 기능인가요?

Next.js는 서버 사이드 렌더링을 지원해서 이 문제를 해결한다고 하죠? 맞아요, 서버에서 HTML을 미리 만들어서 보내주니까 초기 로딩은 빨라요. 실제로 First Contentful Paint(FCP)는 확실히 개선돼요. 그런데 여기서 함정이 있어요. 바로 하이드레이션(Hydration)이라는 과정이죠.

서버에서 열심히 HTML을 만들어서 보내줘요. 사용자는 화면을 봐요. 근데 클릭을 해도 아무 반응이 없어요. 왜냐면 그 뒤에 JavaScript를 또 다 다운로드하고 실행해야 하거든요. Web.dev의 분석에 따르면 평균적인 Next.js 앱의 Time to Interactive(TTI)는 FCP보다 3~5초 더 늦다고 해요.

결국 서버에서 한 번, 클라이언트에서 또 한 번, 똑같은 작업을 두 번 하는 셈이에요. 이게 과연 효율적일까요? Vercel의 공식 블로그에서도 "하이드레이션은 비용이 크다"고 인정했어요. 특히 복잡한 컴포넌트 트리를 가진 앱일수록 문제가 심각하죠.

더 큰 문제는 Next.js가 기본적으로 이런 방식을 강요한다는 거예요. 클라이언트로 JavaScript를 안 보내려고 하면 프레임워크와 계속 싸워야 해요. 공식 문서를 뒤져가며 복잡한 설정을 만져야 하죠. 'use client' 디렉티브를 빼먹으면 자동으로 번들에 포함되고, 서버 컴포넌트를 쓰려면 새로운 패러다임을 배워야 해요.

Astro가 보여주는 새로운 길

여기서 등장하는 게 Astro예요. State of JS 2023 기준으로 개발자 사용률이 18%까지 증가했고, Jekyll, Hugo 같은 전통적인 정적 사이트 생성기들을 추월했다고 해요. 만족도는 무려 82.8%로 React보다 훨씬 높고요. Astro가 특별한 이유는 뭘까요?

Astro는 기본적으로 클라이언트에 JavaScript를 최소한만 보내요. 대부분을 순수 HTML로 변환하고, 정말 필요한 부분에만 JavaScript를 추가하죠. 이걸 '아일랜드 아키텍처(Islands Architecture)'라고 불러요. 웹페이지를 큰 바다로 보고, 동적인 부분만 섬처럼 따로 관리하는 거예요.

Astro 공식 벤치마크를 보면 놀라운 결과가 나와요. 같은 내용의 블로그 사이트를 만들었을 때 Astro는 JavaScript를 단 1KB만 보냈어요. Next.js는 327KB였고요. Lighthouse 성능 점수도 Astro가 100점을 기록한 반면 Next.js는 85점에 그쳤어요.

더 놀라운 건 개발자 경험도 포기하지 않는다는 거예요. React가 편하면 React로 코딩하세요. Vue가 좋으면 Vue 쓰세요. Svelte, Solid, Preact 뭐든 좋아요. 심지어 한 페이지에 여러 프레임워크를 섞어 쓸 수도 있어요. 대신 그 코드들은 서버에서 실행되고, 사용자한테는 최적화된 결과물만 전달되죠.

실제로 The Guardian은 Astro로 마이그레이션한 후 페이지 로딩 속도가 40% 개선됐다고 발표했어요. Trivago도 비슷한 경험을 공유했고요. 이런 성과는 단순히 프레임워크를 바꿔서가 아니라 철학 자체가 다르기 때문이에요.

진짜 질문은 이거예요

처음 던진 질문을 다시 생각해볼게요. "왜 React를 쓰나요?"가 아니라 "왜 브라우저에서 React를 실행하나요?"가 진짜 질문이에요.

팀이 React에 익숙해서? JSX가 편해서? 컴포넌트 재사용이 좋아서? 그렇다면 React를 쓰세요. 근데 서버에서만 쓰세요. 사용자의 브라우저에 그 무거운 프레임워크를 보내지 마세요. 개발자의 편의를 위해 사용자 경험을 희생하는 건 본말이 전도된 거잖아요.

싱글 페이지 앱(SPA)이 정말 필요한가요? Netlify의 2024 설문조사에 따르면 개발자의 67%가 "대부분의 프로젝트에서 SPA가 과도하다"고 답했어요. 실제로 Gmail이나 Google Maps처럼 복잡한 인터랙션이 필수인 앱이 아니라면 멀티 페이지로도 충분해요.

정말 SPA가 필요하다면 최소한 React 대신 Preact를 써보세요. 번들 크기가 3KB밖에 안 돼요. React와 API가 거의 같아서 개발자는 차이를 못 느끼지만, 사용자는 확실히 빠르다는 걸 느낄 거예요. Uber는 Preact로 전환한 후 모바일 웹 성능이 50% 개선됐다고 발표했어요.

미래는 이미 시작됐어요

웹 브라우저는 이제 정말 강력해졌어요. 바닐라 JavaScript만으로도 할 수 있는 게 엄청 많아졌죠. CSS Grid, Flexbox, Custom Properties 같은 레이아웃 기능부터 Web Components, View Transitions API 같은 최신 기술들까지요. Can I Use 통계를 보면 이런 기능들의 브라우저 지원률이 이미 90%를 넘어요.

React가 클라이언트에 있으면 이런 최신 브라우저 기능들을 제대로 활용하기 어려워요. Virtual DOM이 실제 DOM과 싸우는 상황이 생기거든요. View Transitions API는 네이티브 브라우저 기능인데, React에서 쓰려면 추가 라이브러리가 필요해요. 이상하지 않나요?

2025년 현재 React 팀은 서버 컴포넌트와 서버 액션을 적극 도입하면서 풀스택 프레임워크로 진화하고 있어요. TanStack Start, Remix, React Router v7 같은 대안들도 계속 등장하고 있고요. 이건 React 생태계조차 "클라이언트만으로는 한계가 있다"는 걸 인정한 거예요.

Cloudflare의 Workers 사용 통계를 보면 서버리스 엣지 컴퓨팅이 2024년 한 해 동안 200% 성장했다고 해요. 개발자들이 점점 더 서버 쪽으로 로직을 옮기고 있다는 증거죠. 클라이언트는 가볍게, 서버는 강력하게. 이게 트렌드예요.

결론: 사용자를 위한 선택을 하세요

결국 웹 개발의 미래는 명확해요. 서버에서 할 수 있는 건 서버에서 하고, 클라이언트에는 정말 필요한 것만 보내는 거죠. React를 쓰고 싶으면 쓰세요. 근데 서버에만 두세요. 사용자를 위해서요.

다음 프로젝트를 시작할 때 한 번만 멈춰서 생각해보세요. "이 웹사이트에 정말 450KB의 JavaScript가 필요한가?" 대부분의 경우 답은 "아니오"일 거예요. 그렇다면 Astro, SvelteKit, 또는 Qwik 같은 대안을 한 번쯤 시도해보는 건 어떨까요?

사용자는 우리가 어떤 도구를 쓰는지 모르고, 관심도 없어요. 다만 빠르고 부드러운 경험을 원할 뿐이죠. 그게 우리가 개발자로서 해야 할 일 아닐까요? 개발자의 편의가 아닌, 사용자의 경험을 최우선으로 하는 선택. 그게 2026년 웹 개발의 정답이에요.