[번역] 리액트는 기본값으로 승리했습니다 – 그리고 프런트엔드 혁신을 죽이고 있습니다

출처 : 나노 바나나

원문: https://www.lorenstew.art/blog/react-won-by-default/

React-by-default에는 숨겨진 비용이 있습니다. 이 글은 작업에 맞는 올바른 프레임워크를 선택하기 위해 의도적인 선택을 내려야 한다는 주장입니다.

---

리액트는 더 이상 기술적 우위로 승리하고 있지 않습니다. 지금은 기본 선택지라는 이유만으로 승리하고 있습니다. 이 기본값이 프런트엔드 생태계 전반의 혁신을 늦추고 있습니다.

팀이 새로운 프런트엔드를 만들어야 할 때, 대화는 좀처럼 "제약 조건이 무엇이고, 어떤 도구가 가장 적합한가?"로 시작하지 않습니다. 대부분 "리액트를 쓰자. 다들 리액트는 알잖아."로 시작합니다. 이 반사적인 선택은 기술적 적합성이 아닌 네트워크 효과가 아키텍처를 결정하는 자기 강화적 순환을 만들어냅니다.

한편, 혁신적인 아키텍처 방식을 도입한 프레임워크들은 도입에 어려움을 겪고 있습니다. Svelte는 런타임 시그널(signal)과 컴파일 타임 최적화를 결합해 더 작은 번들을 만들어냅니다. Solid는 가상 DOM의 비용 없이 세밀한 반응성을 제공합니다. Qwik은 재개 가능성(resumability)을 통해 즉각적인 시작을 실현합니다. 이러한 방식들은 일반적인 시나리오에서 리액트 모델을 능가할 수 있지만, 리액트가 기본 선택지로 선택되기 때문에 공정한 평가를 받지 못하는 경우가 많습니다.

리액트는 많은 면에서 탁월합니다. 문제는 리액트 자체가 아니라, React-by-default라는 사고방식입니다.

혁신의 천장

리액트의 기술적 기반은 오늘날의 불편함 중 일부를 설명해줍니다. 가상 DOM은 2013년의 문제에 대한 영리한 해법이었지만, Rich Harris가 "Virtual DOM is pure overhead"에서 설명했듯이, 현대 컴파일러라면 충분히 피할 수 있는 작업을 유발합니다.

훅은 클래스 컴포넌트의 고충을 해소했지만, 의존성 배열, 오래된 클로저, 잘못 사용된 이펙트라는 새로운 복잡성을 도입했습니다. 리액트 공식 문서조차 "이펙트가 필요 없을 수도 있습니다"라고 자제를 강조할 정도입니다. 서버 컴포넌트는 클라이언트 측 자바스크립트를 줄이고 서버 전용 데이터 접근을 가능하게 하지만, 아키텍처 복잡성과 새로운 장애 유형을 추가합니다.

리액트 컴파일러는 useMemo/useCallback 같은 패턴을 자동화하는 영리한 해법입니다. 하지만 그 존재 자체가 신호이기도 합니다. 모델 자체에 내재된 제약을 중심으로 최적화하고 있다는 신호입니다.

2025년 10월에 출시된 리액트 19.2도 이 패턴을 이어갑니다. 새로운 useEffectEvent 훅은 이펙트의 의존성 배열 문제를 해결하기 위해 특별히 도입되었습니다. 훅 자체가 만들어낸 복잡성에 붙인 패치인 셈입니다. Svelte나 Solid 같은 프레임워크에도 비슷한 untrack 기능이 있지만, 이 프레임워크들은 기본적으로 자동 의존성 추적을 사용하기 때문에 untrack은 엣지 케이스에서만 필요합니다. 리액트는 모든 이펙트에 수동으로 의존성 배열을 작성해야 하고, 그 모델의 한계를 우회하기 위해 useEffectEvent를 추가했습니다.

같은 릴리스에서는 앱의 표시/숨김 상태를 관리하는 <Activity /> 컴포넌트와 새로운 부분 프리렌더링(partial pre-rendering) API도 도입되었습니다. 추가될 때마다 개발자가 익혀야 할 API 표면적은 늘어나는 반면, 대안 프레임워크들은 더 단순한 기본 요소로 유사한 결과를 달성합니다.

대안적 접근 방식과 비교해보세요. Svelte 5의 Rune은 런타임 시그널로 세밀한 반응성을 구현하고, Solid의 세밀한 반응성은 변경된 부분만 정확히 업데이트하며, Qwik의 재개 가능성은 기존의 하이드레이션을 없애버립니다. 이것들은 리액트 모델에 대한 점진적인 개선이 아닙니다. 서로 다른 한계를 가진, 완전히 다른 모델입니다.

채택 없는 혁신은 결과를 바꾸지 못합니다. 선택이 반사적으로 이루어지는 한, 채택은 일어날 수 없습니다.

우리 모두가 짊어지고 있는 기술 부채

리액트를 기본값으로 선택하면 더 이상 의문을 품지 않는 런타임 비용과 재조정(reconciliation) 비용이 따라옵니다. 충분히 빠르더라도, 리액트 모델의 한계는 컴파일 타임 모델이나 세밀한 반응성 모델보다 낮습니다. 개발자의 시간은 가치를 전달하는 대신 리렌더링 관리, 이펙트 의존성, 하이드레이션 경계를 다루는 데 쓰입니다. 성능 연구에서 얻은 더 넓은 교훈은 일관됩니다. 자바스크립트는 크리티컬 패스(critical path)에서 비용이 큽니다(The Cost of JavaScript).

성능을 넘어, 우리는 웹의 근본 원칙 대신 "리액트 패턴"을 중심으로 사고 모델을 구축해왔고, 이는 기술의 이식성을 낮추고 아키텍처 관성을 심화시킵니다. 손실은 성능에만 그치지 않습니다. 더 적합한 대안이 한 번도 평가받지 못할 때 발생하는 기회 비용입니다.

숨이 막혀가는 프레임워크들

Svelte: 컴파일 타임 최적화를 갖춘 시그널

Svelte 5는 런타임 시그널을 통한 세밀한 반응성과 적극적인 컴파일 타임 최적화를 결합합니다. 가상 DOM이 없고, 런타임도 리액트보다 작습니다. 컴포넌트는 효율적이고 직접적인 DOM 조작으로 컴파일됩니다. 사고 모델이 웹의 근본 원칙과 잘 맞아떨어집니다.

하지만 "일자리가 충분하지 않다"는 이유로 Svelte 도입은 기술적 강점에도 불구하고 인위적으로 낮은 수준에 머물고 있습니다. 더 가디언지의 프런트엔드 Svelte 전환 같은 실제 사례들은 번들 크기 감소와 로드 시간 단축을 비롯한 성능과 개발자 생산성에서 측정 가능한 성과를 보여줍니다. Wired의 Svelte 관련 기사에서 소개된 것처럼, 개발자 Shawn Wang(X/Twitter의 @swyx)은 컴파일 타임 최적화를 활용해 자신의 사이트 크기를 리액트 기반의 187KB에서 Svelte 기반의 9KB로 줄였습니다. 특히 느린 연결 환경에서 더 빠르고 효율적인 앱을 만들 수 있게 됩니다.

Solid: 반응형 기본 요소 접근법

Solid는 JSX에 익숙한 방식으로 세밀한 반응성을 제공합니다. 업데이트는 시그널을 통해 영향을 받는 DOM 노드로 직접 전달되어 재조정 병목을 우회합니다. 뛰어난 성능 특성을 갖추고 있지만, 인지도는 제한적입니다. Solid의 비교 가이드에서 설명하듯, 이 방식은 리액트의 가상 DOM보다 효율적인 업데이트를 가능하게 하며, 정밀한 반응성으로 불필요한 작업을 최소화하고 더 단순한 상태 관리를 통해 개발자 경험을 향상시킵니다.

더 많이 알려진 프레임워크들에 비해 두드러진 사례 연구가 부족한 것은 주로 Solid의 낮은 도입률 때문입니다. 그러나 초기 도입자들의 경험담은 업데이트 효율성과 코드 단순성 면에서 비슷한 혁신적 성과를 시사하며, 더 많은 팀이 실험함에 따라 확산될 가능성이 있습니다.

Qwik: 재개 가능성의 혁신

Qwik은 하이드레이션 대신 재개 가능성을 사용합니다. 현재 상호작용에 필요한 것만 불러와 즉각적인 시작을 가능하게 합니다. 모든 애플리케이션 상태를 직렬화할 수 있어야 한다는 아키텍처 제약이 있지만, 측정 가능한 성능 향상을 제공합니다. 콘텐츠가 많은 사이트, 느린 네트워크, 모바일 우선 애플리케이션에 이상적입니다. Qwik의 Think Qwik 가이드에 따르면, 이는 점진적 로딩과 상태 및 코드 직렬화를 통해 구현됩니다. 앱은 무거운 클라이언트 사이드 부트스트래핑 없이 즉시 실행을 재개할 수 있어, 기존 프레임워크에 비해 뛰어난 확장성과 단축된 초기 로드 시간을 실현합니다.

Qwik의 성공 사례가 잘 알려지지 않은 것은 기본 선택에서 벗어나 시도해본 팀이 적기 때문입니다. 그러나 시도해본 팀들은 시작 시간과 자원 효율성에서 극적인 개선을 보고하며, 도입이 확산될 경우 발휘될 잠재력이 크다는 것을 보여줍니다.

세 프레임워크 모두 기술적 부족함이 아닌, 기본 선택지라는 장벽이 시도 자체를 막기 때문에 도입이 저조합니다.

게다가 리액트의 API 표면적은 대안 프레임워크들보다 현저히 크고 복잡합니다. 훅, 컨텍스트(context), 리듀서(reducer), 메모이제이션(memoization) 패턴 등 함정을 피하기 위해 주의 깊게 다뤄야 할 개념들이 가득합니다. 이처럼 방대한 API는 개발자의 인지 부하를 높이고, 의존성을 잘못 이해하거나 과도하게 설계하는 데서 비롯된 버그로 이어지는 경우가 많습니다. 예를 들어, 2025년 9월 12일 Cloudflare 장애에서는 문제 있는 의존성 배열을 가진 useEffect 훅이 반복적인 API 호출을 유발해 Tenant Service를 압도하고 광범위한 장애를 일으켰습니다. 반면, Svelte, Solid, Qwik 같은 프레임워크들은 단순함과 웹의 근본 원칙을 강조하는 더 작고 집중된 API를 갖추고 있어, 정신적 부하를 줄이고 익히고 유지 관리하기 쉽게 만들어줍니다.

네트워크 효과의 감옥

리액트의 지배력은 자기 강화적 장벽을 만들어냅니다. 채용 공고는 "프런트엔드 엔지니어"가 아닌 "리액트 개발자"를 요구해 기술 다양성을 제한합니다. 컴포넌트 라이브러리와 팀의 체득된 경험은 조직적 관성을 만듭니다.

위험을 회피하는 리더들은 "안전한" 선택지를 고릅니다. 학교는 취업 시장이 요구하는 것을 가르칩니다. 이 순환은 기술적 우위와 무관하게 계속됩니다.

이것은 건강한 경쟁이 아닙니다. 기본값에 의한 생태계 포획입니다.

네트워크 효과 탈출하기

탈출에는 여러 차원에서의 의도적인 행동이 필요합니다. 기술 리더들은 관성이 아닌 제약 조건과 장점을 바탕으로 선택해야 합니다. 기업은 소규모 혁신 예산을 대안 시도에 배분할 수 있습니다. 개발자들은 하나의 사고 모델을 넘어 역량을 키울 수 있습니다.

교육자들은 특정 도구와 함께 프레임워크에 종속되지 않는 개념을 가르칠 수 있습니다. 오픈 소스 기여자들은 대안 생태계가 성숙할 수 있도록 도울 수 있습니다.

변화는 저절로 일어나지 않습니다. 의식적인 선택이 필요합니다.

프레임워크 평가 체크리스트

새 프로젝트를 시작할 때 의도적인 선택을 내리기 위해 다음의 간단한 체크리스트를 활용하세요.

• 성능 요구사항 파악 — 시작 시간, 업데이트 효율성, 번들 크기 같은 지표를 평가하세요. 속도가 중요하다면 컴파일 타임 최적화를 제공하는 프레임워크를 우선시하세요.
• 팀 역량과 학습 곡선 — 기존 전문성을 고려하되 전환 경로도 함께 살펴보세요. 많은 대안이 완만한 진입로를 제공합니다(예: Solid의 리액트와의 JSX 호환성).
• 확장성과 유지 비용 — 유지 관리, 의존성 관리, 기술 부채를 포함한 장기 비용을 계산하세요. 대안 프레임워크들은 런타임 오버헤드를 줄여 호스팅 비용을 낮추고 확장성을 개선하는 경우가 많습니다.
• 생태계 적합성 — 성숙도와 혁신성 사이의 균형을 맞추세요. 중요하지 않은 영역에서 파일럿을 진행해 전환 가능성과 ROI를 테스트하세요.

흔한 반론들

"생태계 성숙도가 중요하잖아요!" 성숙도는 분명 가치 있습니다. 하지만 관성을 고착시킬 수도 있습니다. 연륜이 곧 오늘날의 제약에 대한 적합성을 의미하지는 않습니다.

성숙한 생태계는 서드파티 패키지에 대한 강한 의존성을 의미하기도 합니다. 이는 의존성 최신화, 보안 취약점 대응, 사용하지 않는 코드로 인한 번들 비대화 같은 유지 관리 부담을 초래할 수 있습니다. 경우에 따라 필수적이기도 하지만, 이런 유연성은 과도한 의존으로 이어질 수 있습니다. 특정 요구에 맞춘 맞춤 솔루션이 장기적으로는 더 가볍고 유지하기 쉬운 경우가 많습니다. 대안 프레임워크의 더 작은 생태계는 기본부터 구축하도록 장려해 더 깊은 이해와 적은 기술 부채로 이어집니다. 게다가 AI 코딩 어시스턴트가 정확한 맞춤 함수를 즉시 생성할 수 있게 된 지금, 특수 목적 유틸리티를 만드는 진입 장벽은 크게 낮아졌습니다. lodash 같은 범용 라이브러리나 Moment, date-fns 같은 날짜 라이브러리를 완전히 배제하고 가볍고 앱에 특화된 구현으로 대체하는 것도 충분히 실현 가능합니다.

"채용이 문제잖아요!" 채용은 수요를 따릅니다. 중요하지 않은 경로에서 대안을 먼저 시범 운영한 후, 기본기를 갖춘 인재를 채용해 실무 교육을 병행하면 위험을 줄일 수 있습니다.

"컴포넌트 라이브러리가 필요하잖아요!" 컴포넌트 라이브러리는 군더더기입니다. 출시 속도가 다른 모든 것을 압도할 때 유용할 뿐입니다. 애플리케이션의 특정 요구에 맞춰 컴포넌트를 구축하면 존재하지도 않는 문제를 위한 코드를 배포하지 않아도 되므로 더 가벼운 솔루션이 만들어집니다. 프레임워크에 종속되지 않는 디자인 시스템과 웹 컴포넌트(Web Components)는 공유 컴포넌트가 필요할 때 속도를 유지하면서도 종속성을 줄여줍니다.

"안정성이 중요하잖아요!" 클래스에서 훅으로, 서버 컴포넌트로, 다시 리액트 19.2의 useEffectEvent와 <Activity /> 컴포넌트로 이어진 리액트의 진화는 안정성이 아닌 끊임없는 변화를 보여줍니다. 대안 프레임워크들은 오히려 더 일관된 API를 제공하는 경우가 많습니다.

"대규모 검증이 되어 있잖아요!" jQuery도 대규모로 검증된 기술이었습니다. 과거의 성공이 미래의 적합성을 보장하지는 않습니다.

더 넓은 생태계에 끼치는 해악

단일 문화(monoculture)는 한 프레임워크의 제약이 사실상의 한계가 될 때 웹의 발전을 늦춥니다. 인재들은 플랫폼을 발전시키는 대신 프레임워크 특정 문제를 해결하는 데 시간을 씁니다. 투자는 기술적 우위와 무관하게 기존 강자를 따릅니다.

교육 과정은 기본기보다 즉각적인 취업 가능성에 최적화되어, 이식 가능한 기술 대신 프레임워크 특화 기술을 만들어냅니다. "리액트가 처리할 수 있다"는 말이 기본 답변이 되면서 플랫폼 개선이 지연됩니다.

다양성이 사라지면 생태계 전체가 고통받습니다.

우리가 가꿀 수 있는 정원

건강한 생태계에는 단일 문화가 아닌 다양성이 필요합니다. 혁신은 다양한 접근 방식이 경쟁하고 교차 수분할 때 싹틉니다. 개발자는 다양한 사고 모델을 배우며 성장합니다. 여러 프레임워크가 서로 다른 경계를 밀어붙일 때 플랫폼이 발전합니다.

모든 것을 하나의 모델에 거는 것은 단일 장애점을 만듭니다. 그것이 한계에 부딪히면 어떻게 될까요? 대안을 탐색하지 않음으로써 우리가 놓치고 있는 기회는 무엇일까요?

이제는 관성이 아닌 제약 조건과 장점을 기반으로 프레임워크를 선택할 때입니다. 여러분의 다음 프로젝트는 React-by-default보다 나은 선택을 받을 자격이 있습니다. 생태계는 다양성만이 제공할 수 있는 혁신을 받을 자격이 있습니다.

더 이상 기본값으로 같은 씨앗을 심지 마세요. 다양한 프레임워크 탐색을 통해 가꿀 수 있는 정원은, 우리가 자연스럽게 빠져든 단일 문화보다 훨씬 더 회복력 있고 혁신적일 것입니다.

선택은 우리에게 달려 있습니다.