React와 Remix가 선택한 서로 다른 미래

Front-End•2025.11.24

Laconic Wit 블로그 포스트 번역

2025-10-23

원문: https://laconicwit.com/react-and-remix-choose-different-futures/

Bryan Cantrill의 강연 Platform as a Reflection of Values는 저에게 필요했던 관점을 제공해주었습니다. 플랫폼들이 서로 다른 길을 걸을 때, 그는 그것이 기술적 장점 때문이 아니라 가치관의 차이에 기인한다고 주장했습니다. 한 커뮤니티에서 가장 중요한 것들이 다른 커뮤니티에서는 그렇지 않을 수 있다는 것입니다.

저는 2주 전 Remix Jam에 참석했고, 지난 주에는 React Conf 2025 영상들을 시청했습니다. 저는 지난 10년간 React에서 프로덕션 코드를 배포했고, 지난 2년간은 Remix에서 배포했습니다.

이제 React와 Remix 두 생태계 모두 변화하고 있으며, 다른 접근 방식으로 보였던 것이 양립할 수 없는 비전이 되었습니다.

React Conf의 기술 발표는 점진적이었습니다: React 19.2 API, View Transitions 실험, 더욱 정교해지는 컴파일러. 메시지는 명확했습니다: React는 커뮤니티의 의견을 듣고 있으면서 복잡성을 개발자 대신 수용하고 있습니다. 안정성, 조합성, 기능성: 이것이 React의 가치관입니다.

Remix 팀은 완전히 다른 것을 발표했습니다: React와의 단절입니다. use client로 도입된 멘탈 모델의 변화와 Server Components의 구현 복잡성이 선택을 강요했습니다. 그리고 Remix 3는 단순성을 선택했습니다. Remix 2 사용자들이 대가를 치르게 됩니다; 3로 업그레이드 방법이 없습니다.

단순성을 위해 안정성을 버린 선택은, 이 두 가치가 결코 공존할 수 없다는 진실을 명백히 드러냅니다.

React의 가치관: 기능으로서의 복잡성

React의 명시된 목표는 "반응형 사용자 경험의 기준을 높이는 것"입니다. React Conf 2025에서 React 팀은 이것이 실제로 무엇을 의미하는지 보여주었습니다. 그들은 최종 사용자를 위해 더 나은 경험을 제공한다면 개발자 대신 엄청난 복잡성을 수용할 것입니다.

React Compiler가 가장 명확한 예입니다. 이것은 여러분의 코드를 분석하고, 컴포넌트를 더 작은 논리 조각으로 나누고, 렌더링을 자동으로 최적화합니다. Meta의 Quest 스토어 앱에서 그들은 12% 더 빠른 로드 시간과 2배 빠른 상호작용을 보았습니다. 앱이 이미 수동으로 최적화되었음에도 불구하고요. 컴파일러는 개발자 기술을 대체하는 것이 아닙니다; 수동으로 유지하기에는 비현실적인 복잡성을 처리하고 있습니다. Joe Savona는 도전 과제를 설명했습니다: "모든 컴포넌트가 업데이트되어야 하는" 컨텍스트 기반 앱에서 컴파일러는 이제 대부분의 작업을 자동으로 건너뜁니다.

이것이 React의 가치 제안입니다: 안정성(컴파일러는 기존 코드와 함께 작동), 조합성(동시 렌더링, Suspense, transitions과 통합), 기능성(수동 최적화가 도달할 수 없는 성능을 해제). 팀이 증분 계산에 대한 다년간의 탐색에 대해 이야기했을 때, 그들은 복잡성에 대해 사과하지 않았습니다. 그들은 그 기준을 높이는 대가를 설명하고 있었습니다.

React 팀은 이것이 React를 복잡하게 만든다는 것을 알고 있습니다. 하지만 선택은 명확합니다: 개발자들이 복잡성을 감당하지 않아도 되도록, React가 그 복잡성을 떠안는 것입니다. 이는 훌륭한 접근이지만, 그만큼 개발자들은 React의 내부 동작을 더욱 신뢰해야 합니다.

Remix의 반대 가치관: 자유를 주는 단순성

Remix 팀은 React가 단지 몇 가지 기본 요소만을 가진 조합 가능한 렌더링 라이브러리였던 시절을 기억합니다. Remix Jam에서 Ryan Florence는 단순성을 핵심 원칙으로 삼았을 때 어떤 결과가 나오는지 시연했습니다: 암묵적인 것보다 명시적인 것, 자동인 것보다 추적 가능한 것.

가장 명확한 예는 this.update()입니다. Ryan이 무대에서 라이브 드럼 머신을 만들었을 때, 모든 상태 변화는 수동이었습니다: "이 코드에서 무언가가 업데이트되는 유일한 시간은 내가 그렇게 하라고 말했을 때입니다." 자동 반응성 그래프 없음, 숨겨진 구독 없음, 무언가가 예상치 못하게 다시 렌더링되는 이유를 디버깅할 필요 없음. 컴포넌트가 업데이트된 이유가 궁금하다면, "어딘가에서 그렇게 하라고 말했기 때문입니다."

이 명시성은 Remix 3의 전체 설계에 걸쳐 확장됩니다. 이벤트 처리는 일반 DOM을 통해 버블링되는 네이티브 DOM 이벤트와 함께 on 속성을 사용합니다. AbortControllers(this.signal)는 정리를 명시적으로 연결합니다. Context는 다시 렌더링을 트리거하지 않습니다. 여러분이 설정하고, 컴포넌트가 읽고, 무언가가 변하기를 원할 때 this.update()를 호출합니다.

드럼 머신을 시연한 후 Ryan은 철학을 설명했습니다: "우리는 함께 것들을 구성하고, 값을 변경하고, 모든 것이 해야 할 일을 하는 이 아이디어를 추구해왔습니다. 하지만 제 경험상 설정하기가 어렵고, 일단 설정되면, 갑자기 예상치 못한 일이 발생하면 그것을 풀어야 합니다."

Michael Jackson이 <Frame> 컴포넌트로 서버 렌더링을 시연하며, 순수 HTML을 전송 형식으로 사용하는 방식을 보여주었습니다. React Server Components가 실질적인 문제를 해결하는 것은 사실이지만, Remix는 Web Platform에 의존함으로써 그 문제들을 더욱 단순하게 풀 수 있다고 믿습니다.

이것이 Remix의 가치 제안입니다: 단순성(명시적으로 언제 업데이트할지 제어), Web Platform 정렬(표준 이벤트, 표준 스트림, 크로스 런타임 호환성), 디버깅 가능성(모든 업데이트를 특정 this.update() 호출로 추적). 팀은 React의 UX 기준을 높이는 목표를 거부하지 않지만, React가 이를 달성하기 위해 수용하는 복잡성이라는 벌금을 거부하고 있습니다.

Web Platform: 필연인가 선택인가?

Remix의 React 이탈을 분석하기 위해 Cantrill의 프레임워크를 사용하는 것에는 아이러니가 있습니다: Remix 팀은 웹 플랫폼에 대한 자신들의 헌신을 가치의 선택으로 보지 않습니다. 그들은 단순히 퍽이 가는 곳으로 스케이트를 타고 있을 뿐이라고 믿습니다. 모든 프레임워크는 결국 웹 플랫폼 API를 받아들일 것입니다. 단지 시간의 문제일 뿐입니다.

그러나 Cantrill의 발표는 이것이 불가피한 미래가 아니라 분명한 가치의 선택임을 드러낸다. 그는 Node.js가 엄격함 대신 접근성을 선택하고, 브라우저 개발자들이 서버 사이드 JavaScript 작업을 쉽게 할 수 있도록 웹 플랫폼 API를 도입한 것을 비판했다. 그 API들을 Node로 가져온 실무자들이 바로 자신이 소중히 여기던 가치들—견고성, 디버깅 용이성, 운영 정확성—을 밀어낸 장본인이라고 느꼈다. Cantrill에게 웹 플랫폼에 맞추는 것은 개발자 편의성을 위해 엔지니어링 엄밀함을 희생하는 것이나 마찬가지였다.

Remix 3는 바로 그 웹 플랫폼 API들 위에 전적으로 구축되고 있습니다. Streams, fetch, File API, 모든 플랫폼 의존성은 브라우저, Bun, Deno, Node에서 동일하게 작동합니다. Ryan과 Michael은 Remix Jam 전체에서 이를 보여주었습니다: 표준 HTML 응답, 네이티브 DOM 이벤트, 크로스 런타임 호환성. React도 Web Platform API를 존중하지만, 그 위에 무언가를 구축할 토대로 취급합니다. Remix 3는 이를 최종 목적지로 취급합니다. 이것은 항상 Remix 가치였으며, Remix 1과 2에서 명백했지만, Remix 3은 그것을 절대적인 원칙이 되었습니다.

그리고 저는 이것 때문에 Remix를 정말 좋아합니다.

저는 개방형 웹을 사랑하지만, 모든 서버 프레임워크가 웹 플랫폼에 완전히 맞춰질 것이라고, 또는 그래야 한다고 확신하지 않습니다. 브라우저와 서버는 다른 트레이드오프를 강요하는 다른 제약 조건 하에 있습니다. 목표는 그들 사이의 이음새를 지우는 것이 아니라 그것을 보이고 의도적으로 만드는 것입니다. Remix 2는 이 긴장을 우아하게 처리합니다. 그러나 이것은 플랫폼을 노출할 위치에서의 취향의 결과이지, Web Platform과 합치하는 것이 만들어내는 본질적 결과는 아닙니다.

Remix 2는 죽었습니다. react-router 만이 있을뿐

Remix가 future flags를 사용한 업계 최고의 업그레이드 정책 중 하나를 가지고 있음에도 불구하고, Remix 2에서 Remix 3으로의 마이그레이션 도구는 없을 것입니다. 변화가 너무 근본적입니다. Remix Jam에서 Michael Jackson은 분명히 밝혔습니다: "우리는 React Router를 10년째 개발해왔습니다... 많은 사람들이 React Router를 사용했습니다. Shopify도 React Router를 기반으로 했죠... 우리는 그걸 그냥 버리지 않을 겁니다." Remix 2 사용자는 react-router v7로 유지되는 선택을 할 수 있습니다. 하지만 Remix 3은 이혼에서 이름을 가져가고 새로운 방향으로 나아가고 있습니다.

단순성이 조직 원칙이 될 때, 안정성은 협상 가능해집니다. 새로운 on 속성은 React의 레거시 이벤트 시스템과 공존할 수 없습니다. 명시적인 this.update API는 React의 hooks를 완전히 대체합니다. 하위 호환성 깨기는 부수적 손상이 아니라 요점입니다. 이것은 this를 오버로딩하는 트릭(인수 순서에 의존하지 않고 컴포넌트에 선택적 두 번째 매개변수를 제공)과 같은 설계 공간을 열어줍니다. 이것은 JavaScript의 기존 기능에 의존하기 때문에 단순해 보입니다.

알파는 연말까지 예상되며, 응집력 있는 패키지는 2026년에 따를 것입니다. 하지만 경고는 명확합니다: Remix 3은 아직 프로덕션 준비가 되지 않았습니다. 모든 것이 새롭고 변경될 수 있습니다. 그 동안 우리는 react-router를 가지고 있습니다.

열린 질문들

이벤트를 통신 백본으로 사용하는 것은 영리하지만, 컴포넌트 간 통신을 위해 공유 이벤트 버스에 의존하는 복잡한 Backbone.js 앱을 상기시킵니다. 한동안은 작동했지만, 특정 복잡성 수준에서 새로운 개발자가 기존 프로젝트를 이해하기 어려워졌습니다. Remix의 명시성과 TypeScript 지원이 도움이 될 것입니다. 하지만 2010년에 해결할 수 없었던 도전 과제를 해결하기에 충분할까요?

this.update()는 React의 hook 시스템보다 더 쉬운 정신 모델을 만듭니다. 하지만 명시적 렌더링은 더 많은 코드를 의미합니다. AbortControllers는 정리를 수동으로 연결하도록 요구합니다. 트레이드오프는 명확합니다: 더 많이 작성하지만 더 많이 이해합니다. 이것이 해방인지 아니면 단지 이동된 복잡성인지는 여러분의 팀과 코드베이스에 따라 달라집니다.

Remix 2와 react-router의 이야기는 Ryan과 Michael이 작동하는 것으로 피벗하는 것에 낯설지 않다는 것을 보여줍니다. 이것은 절대적으로 그들의 강점 중 하나이지만, 변화하는 플랫폼 위에 구축하기는 대규모 조직에게 어렵습니다. Remix 3이 안정화되기 전에 얼마나 많이 변할까요?

갈림길 속에서 살기

Cantrill은 그의 강연을 경고로 끝냈습니다: "선거는 가치관의 차이를 해결하지 않습니다. 여러분이 원하는 만큼 많은 투표를 할 수 있습니다. 실제로 사람들의 마음을 바꾸지 않고, 그들의 가치관을 바꾸지 않으면, 여러분은 실제로 아무것도 해결하지 않는 것입니다."

react-router 포크는 Remix 팀이 가치관이 하룻밤 사이에 변하지 않는다는 것을 알기 때문에 존재합니다. 이것은 Remix 3이 자신을 증명하는 동안 Remix 2의 안정성이 필요한 사람들을 위한 유지되는 경로입니다. 그 분할은 현실을 인정합니다: 프로덕션 소프트웨어는 비전만으로 새로운 프레임워크를 채택하지 않습니다. 팀은 다른 가치관에 따라 다른 선택을 할 것입니다. 일부는 React에 머물면서 컴파일러의 정교함을 수용할 것입니다. 일부는 단순성이 마이그레이션 비용과 불확실성의 가치가 있다고 내기하면서 Remix 3으로 일찍 점프할 것입니다.

두 경로 모두 유효합니다. 하지만 그들은 다른 가치관에 대해 유효합니다. 프레임워크가 명시적으로 가장 중요한 것을 재우선순위화할 때, 팀은 선택을 피할 수 없습니다. 기능이나 성능 벤치마크에 기반하지 않고, 어떤 종류의 복잡성을 수용할 의지가 있고 어떤 종류의 제어를 유지해야 하는지에 기반합니다. 이것은 기술적 결정이 아닙니다. 이것은 가치관 결정입니다.

React 생태계는 이제 미래에 대한 두 가지 양립할 수 없는 비전을 가지고 있습니다. Cantrill의 프레임워크는 불편하더라도 왜 그것이 괜찮은지 보는 데 도움이 됩니다. 여러분의 가치관을 선택하고, 그 다음 여러분의 도구를 선택하세요.