1. 글의 핵심 한 줄 요약
React와 Remix는 더 이상 “같은 생태계 안의 다른 선택지”가 아니라,
완전히 다른 가치관(복잡성을 감수해 능력을 얻을 것인가 vs 단순함을 위해 안정성을 버릴 것인가)을 택한 두 개의 분리된 미래이다.
2. 배경: 왜 둘의 길이 갈라졌는가
글의 출발점은 Bryan Cantrill의 발표 “Platform as a Reflection of Values”.
- 플랫폼의 분기점은 기술적 우월성보다 “가치의 불일치(Value misalignment)”에서 나온다는 관점.
- 서로 다른 커뮤니티는 “무엇을 더 중요하게 여길지” 우선순위가 다르고,
- React와 Remix는 이제 이 우선순위를 완전히 다르게 가져가고 있음이 드러났다는 것이 글의 주장.
글쓴이는:
- 최근 Remix Jam(오프라인 행사)에 다녀왔고,
- React Conf 2025 영상을 연달아 챙겨본 뒤,
- “둘이 단순히 다른 접근을 하는 정도가 아니라, 이제는 서로 양립 불가능한 비전”이 되었다고 결론내린다.
3. React의 가치: 복잡성을 능력으로 바꾸는 전략
3-1. React Conf 2025의 메시지
React 쪽 발표는 크게 “점진적 진화”에 가까움.
- React 19.2 API들
- View Transitions 실험
- 더 정교해진 React Compiler
- Server Components·동시성 렌더링과의 결합 등
공통된 메시지:
“React는 커뮤니티의 목소리를 듣고 있고, 복잡성을 대신 떠안아 주겠다.”
React가 내세우는 키워드:
- Stability(안정성)
- Composability(조합 가능성)
- Capability(능력, 성능·표현력)
3-2. React Compiler: 복잡성을 감수해 만들어낸 능력
가장 대표적인 예로 React Compiler가 언급된다.
- 코드 전체를 분석해, 컴포넌트를 더 작은 계산 단위로 쪼개고 자동으로 렌더링을 최적화.
- Meta의 Quest 스토어 앱 사례:
- 이미 수동으로 최적화된 코드였음에도,
- 로딩 속도 12% 향상,
- 인터랙션 반응성 2배 개선.
- 특히 컨텍스트 기반 구조(“모든 컴포넌트가 업데이트되는 것처럼 보이는 앱”)에서,
- 컴파일러가 대부분의 불필요한 업데이트를 자동으로 건너뛰게 만듦.
여기서 중요한 포인트:
- 기존 코드와 호환(Stability)
- 동시성 렌더링, Suspense, 트랜지션과 연계(Composability)
- 사람이 유지하기 어려운 수준의 최적화(Capability)
React 팀은 이걸 “복잡해서 미안하다”가 아니라
“사용자 경험의 기준을 끌어올리기 위해 감수한 비용”으로 설명한다.
3-3. React가 개발자에게 요구하는 것: 보이지 않는 기계에 대한 신뢰
- React는 “복잡성을 대신 떠안겠다”고 말하지만,
- 그 의미는 곧 “개발자는 점점 더 보이지 않는 내부 기계(invisible machinery)를 믿어야 한다”는 것.
- 훅·동시성·컴파일러·서버 컴포넌트가 얽히면서,
- 프레임워크 안에서 일어나는 일을 완전히 이해하기는 점점 더 어려워진다.
- 대신 “잘 설계된 추상화와 도구를 신뢰하는 쪽으로 마인드셋을 바꾸라”는 메시지에 가깝다.
4. Remix 3의 가치: 단순함을 위해 안정성을 버리다
4-1. React와의 결별 선언
Remix 팀은 행사에서 아예 방향 전환을 공식화했다.
- use client, Server Components로 인한 정신 모델 변화와 구현 복잡성이
- React와 Remix 사이의 긴장을 극단적으로 키웠고,
- Remix 3는 결국 “React와의 결별”을 택한다.
가장 중요한 점:
- Remix 2 → Remix 3로의 업그레이드 경로가 없다.
- 이는 단순 부작용이 아니라 “의도된 선택”이다.
- “단순함(Simplicity)”을 최우선 가치로 두면,
- “기존 안정성(Stability)”은 협상 가능한 대상이 되기 때문.
4-2. this.update(): 명시적 업데이트라는 철학
Ryan Florence가 Remix Jam 라이브 코딩에서 보여준 예시:
- 라이브 드럼 머신을 만들면서,
- 모든 상태 변경을 this.update()로 명시적으로 호출.
- “이 코드에서 무언가 업데이트되는 순간은, 내가 직접 업데이트를 지시했을 때뿐이다.”
- 자동 반응성 그래프, 숨겨진 구독, “왜 렌더링이 또 되었지?” 같은 문제를 없애는 방향.
Remix 3의 구조는 여기에 맞춰 설계된다.
- 이벤트 핸들링: on 속성 + 네이티브 DOM 이벤트 버블링
- 정리/취소: AbortController(this.signal)를 통해 완전히 명시적으로 처리
- 컨텍스트: 값을 공유하되, 자체로 리렌더를 트리거하지 않음
- 상태 변화가 필요하면 this.update()로 직접 호출
핵심 철학:
“뭔가 이상하게 동작할 때, 어디서 업데이트가 일어났는지 100% 추적 가능해야 한다.”
자동화된 반응성 대신 “명시적 제어권”을 택한 설계이다.
4-3. 웹 플랫폼 정렬: HTML·DOM·표준 API를 목적지로 본다
Michael Jackson이 보여준 컴포넌트:
- 서버 렌더링의 와이어 포맷을 “그냥 HTML”로 삼는다.
- React Server Components가 풀고 있는 문제를 인정하면서도,
- Remix는 “웹 플랫폼에 더 밀착된 방식으로 더 단순하게 풀 수 있다”고 본다.
Remix 3는 플랫폼 의존성을 이렇게 가져간다.
- Streams, fetch, File API 등
- 브라우저, Bun, Deno, Node에서 동일하게 동작하는 Web Platform API에 올인.
- React는 Web API를 “위에 쌓을 기반”으로 쓰지만,
- Remix 3는 그 자체를 “도착지”로 본다는 차이가 있다.
Remix의 가치 제안:
- Simplicity: 언제, 무엇이 업데이트되는지 전부 명시적
- Web Platform Alignment: 표준 이벤트·스트림·API 중심
- Debuggability: 모든 업데이트를 this.update() 호출로 추적 가능
5. “웹 플랫폼 정렬”도 결국 가치 선택이다
글쓴이는 다시 Cantrill의 프레임으로 돌아간다.
- Remix 팀은 “웹 플랫폼에 정렬하는 것은 언젠가 모두가 갈 길”이라고 주장.
- 하지만 Cantrill의 관점에서 보면, 이것 역시 명백한 “가치 선택”이다.
Node.js 사례:
- Node는 브라우저 개발자 접근성을 위해 Web API를 받아들이며 “Approachability”를 선택.
- 그 과정에서 Cantrill이 중요하게 여겼던
- 견고함(robustness)
- 디버깅 가능성
- 운영상 정확성
같은 가치가 밀려났다고 비판한다.
Remix 3 역시:
- Streams, fetch, File API 등 Web API를 전면에 두며
- “웹 플랫폼을 곧 모든 프레임워크가 도달할 목적지”로 보고 있는데,
- 이것이 실제로는 “어떤 가치를 우선시할 것인가”에 대한 선택이라는 것이다.
6. Remix 2의 종말과 react-router의 역할
6-1. Remix 2 → Remix 3: 단절을 인정한 전략
- Remix는 그동안 future flags 등으로 업그레이드 정책을 잘 가져온 편이었지만,
- Remix 3로는 “아예 마이그레이션 경로가 없다”고 못 박았다.
- 변화가 너무 근본적이기 때문.
- Michael Jackson의 발언:
- “우리는 10년 넘게 React Router를 만들어 왔다.”
- “Shopify 같은 큰 회사도 React Router 위에 얹어 썼고, 그걸 버릴 계획은 없다.”
- 결론:
- Remix 2는 react-router v7로 진화하는 안정 경로를 제공.
- Remix 3는 이름만 가져가서 완전히 다른 방향으로 가는 신규 플랫폼.
6-2. Simplicity를 위해 Stability를 버리는 디자인
- 새로운 on 속성은 React의 기존 이벤트 시스템과 공존할 수 없음.
- this.update는 React 훅 시스템 전체를 통째로 대체.
- 호환성이 깨진 것은 “사고가 아니라, 설계 목표의 직접적인 결과”.
여기서 얻는 설계 공간:
- this를 오버로딩해, 두 번째 인자를 선택적으로 제공하는 등
- JS의 기존 능력 위에서 “간단해 보이는 API”를 설계.
- 하지만 그 대가로:
- 기존 생태계와의 끊김,
- 라이브러리·도구·교육 자료 전체를 처음부터 다시 쌓아야 하는 부담이 생긴다.
6-3. 성숙도: 아직은 연구 프로젝트에 가까움
- Remix 3의 알파는 연말 출시 예상.
- 실제 프로덕션에 쓸 만한 일관된 패키지는 2026년 이후를 바라봐야 할 가능성이 높다.
- 지금 시점에서 메시지:
- “지금 Remix 3에 회사 운명을 걸지 말라.”
- 당분간은 React + react-router가 현실적인 안정 경로.
7. 남는 질문들: 단순함은 진짜 단순한가?
글에서도 몇 가지 우려를 제기한다.
- 이벤트 중심 설계의 확장성
- 모든 것을 이벤트로 연결하는 패턴은 Backbone.js 시절에도 존재.
- 일정 규모를 넘어서면 “이벤트가 어디서 어디로 날아다니는지”를 이해하기 어려워지는 문제가 있었음.
- Remix 3의 명시성·타입 시스템이 이를 충분히 상쇄할 수 있을지 미지수.
- this.update의 대가
- 정신 모델은 React 훅보다 단순하고 직관적일 수 있음.
- 그러나:
- 렌더링을 전부 명시적으로 트리거해야 하므로 코드가 장황해지고,
- AbortController를 직접 관리해야 하므로 클린업 로직까지 모두 수동으로 처리.
- “복잡성이 사라졌다기보다, 프레임워크에서 사용자 코드로 옮겨진 것 아닌가?”라는 질문이 남는다.
- 빈번한 피벗과 조직 규모의 상충
- Remix 팀은 이미 Remix 2·react-router 사례에서 보듯
- “잘 안 되는 길을 빨리 버리고 피벗하는 능력”이 강점.
- 하지만 대기업·장기 프로젝트 입장에서는
- “빠르게 변하는 플랫폼 위에 비즈니스를 올리는 것” 자체가 리스크.
- Remix 3가 어느 시점에서 안정 상태를 찾을지, 그리고 그때까지 얼마나 많은 설계가 다시 바뀔지 예측하기 어렵다.
- Remix 팀은 이미 Remix 2·react-router 사례에서 보듯
8. 실무 관점에서 읽는 메시지: 선택해야 하는 것은 “기술”이 아니라 “가치”
글의 마지막 정리는 명확하다.
- 어떤 프레임워크를 쓸지는
- 기능 목록,
- 벤치마크 수치,
- 유행이 아니라,
- “어떤 종류의 복잡성을 감수할 것인가, 어떤 종류의 통제력을 유지하고 싶은가”라는 가치 선택이다.
정리하면:
- React 쪽 가치관
- 복잡성: 프레임워크 내부로 최대한 집어넣는다.
- 개발자는 추상화와 도구를 신뢰하고, 더 높은 UX 기준을 향해 간다.
- 대규모 팀·장수 프로젝트·안정성을 중시하는 조직에 잘 맞는 방향.
- Remix 3 쪽 가치관
- 복잡성: 자동 마법 대신, 명시적 코드와 Web API에 분산한다.
- 개발자는 더 많은 코드를 쓰지만, 모든 업데이트 경로를 이해할 수 있다.
- 초기에는 실험적인 팀·작은 조직·프레임워크 자체를 연구·기여하려는 팀에게 더 적합할 가능성이 크다.
Cantrill의 말처럼:
“가치는 투표나 인기 경쟁으로 쉽게 합의되지 않는다.
결국 각자 다른 가치를 가진 채로 다른 선택을 하게 된다.”
React 생태계는 이제:
- 복잡성을 대신 떠안는 React,
- 단순함을 위해 몇 년치 안정성을 기꺼이 버리는 Remix 3,
이 두 개의 상반된 비전이 공존하는 시대로 들어섰다.
팀과 조직은 언젠가 이 질문에 답해야 한다.
“우리가 받아들일 복잡성의 형태는 무엇이고,
우리가 놓치지 않으려는 가치는 무엇인가?”
okorion's Tech Study Blog.