프롤로그: 산 정상에서
2025년 5월, Remix Jam 컨퍼런스.
Ryan Florence와 Michael Jackson이 무대에 올랐습니다. React Router와 Remix를 만든 이 두 사람이 전할 메시지는 간단했습니다.[^36-1]
"우리는 산 정상에 도착했습니다. 하지만 주변을 둘러보니... 더 나은 산이 보입니다."
그들은 React를 떠나기로 했습니다.
10년 넘게 React 생태계를 이끌어온 사람들이 왜 이런 결정을 내렸을까요?[^32-1]
이 이야기는 2020년부터 시작됩니다.
1막: React의 선택 - 복잡성을 떠안다 (2020-2023)
Next.js의 절정
2020년, Next.js는 이미 React 생태계의 표준이었습니다.[^24-1]
SSR? Next.js
SSG? Next.js
ISR? Next.js
하지만 문제가 있었습니다.
여전히 모든 컴포넌트 코드가 클라이언트로 전송되고 있었어요. 서버에서만 실행되면 되는 코드도, 클라이언트 번들에 포함되어 다운로드되었습니다.
// 이 코드는 서버에서 실행되지만...
export async function getServerSideProps() {
const data = await db.query(...); // DB 로직
return { props: { data } };
}
// 이 컴포넌트는 여전히 클라이언트로 전송됩니다
export default function Page({ data }) {
return <div>{data.map(...)}</div>
}
JavaScript
복사
이게 동형(Isomorphic) 컴포넌트의 한계였습니다.[^27-1]
React Server Components의 등장
2020년 12월, React 팀이 RFC를 공개했습니다.[^22-1]
"React Server Components"
핵심 아이디어는 간단했습니다:
•
어떤 컴포넌트는 오직 서버에서만 실행
•
클라이언트에는 HTML만 전송
•
번들 사이즈 대폭 감소
// Server Component - 클라이언트로 전송되지 않음
async function BlogPost({ id }) {
const post = await db.posts.find(id); // 직접 DB 접근
const author = await db.users.find(post.authorId);
return (
<article>
<h1>{post.title}</h1>
<Comments postId={id} /> {/* Client Component */}
</article>
);
}
JavaScript
복사
이론적으로는 혁명적이었습니다.[^31-1]
하지만 실무는 달랐습니다.
복잡성의 폭발
2023년, Next.js 13이 RSC를 App Router에 통합했습니다.[^29-1]
그리고... 개발자들은 혼란에 빠졌습니다.[^22-1][^26-1]
// 이게 서버 컴포넌트인가요?
function MyComponent() {
return <div>Hello</div>
}
// 아니면 클라이언트 컴포넌트인가요?
'use client' // <- 이걸 붙여야 하나요?
function MyComponent() {
return <div>Hello</div>
}
JavaScript
복사
새로운 규칙들이 쏟아졌습니다:[^22-1][^26-1]
1.
서버 컴포넌트는 async가 가능하지만 클라이언트 컴포넌트는 불가능
2.
서버 컴포넌트는 useState, useEffect 사용 불가
3.
클라이언트 컴포넌트는 서버 컴포넌트를 import 불가 (props로는 가능)
4.
서버 컴포넌트는 브라우저 API 사용 불가
5.
...
개발자들의 반응:[^22-1][^23-1][^28-1]
"이게 정말 진보인가요?"
"React가 점점 프레임워크처럼 느껴집니다"
"단순함을 위해 React를 선택했는데..."
한 개발자는 이렇게 말했습니다: "use client 지시어를 관리하는 것이 점점 힘들어집니다. 앱이 복잡해질수록, 결국 트리 깊숙한 곳에서는 대부분 클라이언트 컴포넌트에 의존하게 됩니다."
디버깅도 악몽이 되었습니다: "애플리케이션의 일부가 서버에서 실행되기 때문에, 전통적인 브라우저 기반 디버깅 도구로는 충분하지 않습니다. 개발자들은 서버 로그, 특수 디버깅 도구, 추가적인 관찰 기법에 의존해야 합니다."
React의 대답
하지만 React 팀의 입장은 명확했습니다.[^32-1]
"React는 개발자를 대신해 복잡성을 떠안습니다."
React의 목표는 "responsive user experience의 기준을 높이는 것"입니다. 그들은 최종 사용자에게 더 나은 경험을 제공한다면, 개발자를 대신해 엄청난 복잡성을 받아들일 것입니다.
이것은 가치의 선택이었습니다:
•
Capability (기능) over Simplicity (단순함)
•
Performance (성능) over Developer Experience (개발 경험)
•
End User (최종 사용자) over Developer (개발자)
2025년 React Conf에서도 메시지는 동일했습니다:[^32-1]
•
React 19.2 API
•
View Transitions 실험
•
더 정교해진 컴파일러
"안정성, 조합성, 기능성. 이것이 우리의 가치입니다."[^32-1]
2막: Remix의 갈림길 (2024-2025)
React Router v7 - 안정성의 선택
2024년 11월, 큰 발표가 있었습니다.[^12-1][^19-1]
Remix v2가 React Router v7으로 통합되었습니다.
Remix의 모든 기능이 React Router v7의 "framework mode"로 합쳐졌습니다. Vite 플러그인과 서버 런타임 코드가 React Router로 직접 이동했습니다.
그리고 중요한 것: RSC 지원을 추가했습니다.
Jacob Ebey가 수년간 작업한 결과였습니다. "그는 아마도 이것의 12가지 버전을 만들었을 것입니다. 그는 React의 모든 API를 지원하는 최선의 방법을 찾아냈고, 이는 수백만 개의 기존 React Router 앱이 점진적으로 도입할 수 있으면서도 새로운 앱에서도 훌륭하게 느껴지는 방식입니다."
React Router는 이제 Shopify, X.com, GitHub, ChatGPT, Linear, T3Chat 등에서 사용되며, GitHub에는 거의 1,100만 개의 프로젝트가 있습니다.
이것은 안정성과 호환성의 선택이었습니다.
Remix v2 사용자들은 간단히 업그레이드할 수 있었고, RSC도 원한다면 사용할 수 있었습니다.
Remix v3 - 단순함의 선택
하지만 Ryan과 Michael은 다른 길을 보았습니다.[^40-1][^36-1]
2025년 5월, "Wake up, Remix!" 포스트:[^40-1]
"Remix를 진화시키려 했을 때, 우리는 그것이 풀스택 RSC 중심 React 프레임워크가 될 것으로 예상했습니다. 하지만 예상치 못한 일이 일어났습니다: React Router v7이 정말, 정말 좋아졌습니다."
"이제 우리는 다음에 올 것을 만들 자유가 있습니다. 지난 몇 년 동안 웹 플랫폼은 놀라운 진전을 이뤘습니다... 하지만 복잡성도 무겁게 느껴지는 방식으로 증가했습니다."
그들의 결정:
"우리가 제어하지 못하는 추상화 계층에 의존하지 않고 풀스택을 소유해야 합니다. 그것은 React조차도 포함하지 않는다는 것을 의미합니다. 우리는 Preact의 fork로 시작하고 있습니다."
왜 React를 떠났는가?
Remix Jam 2025에서 Ryan이 무대 위에서 라이브 코딩을 했습니다.[^32-1][^36-1]
드럼 머신을 만들면서 보여준 것:
// React 방식
function DrumMachine() {
const [isPlaying, setIsPlaying] = useState(false);
useEffect(() => {
// 언제 이게 실행되는지 예측하기 어렵습니다
}, [dependency1, dependency2, ...]);
return ...
}
// Remix v3 방식
function DrumMachine() {
playSound() {
this.update(); // 명시적으로 업데이트를 제어
}
return ...
}
JavaScript
복사
Ryan이 말했습니다: "이 코드에서, 무언가가 업데이트되는 유일한 때는 제가 그렇게 하라고 했을 때입니다." 자동 리액티비티 그래프도 없고, 숨겨진 구독도 없고, 왜 무언가가 예상치 못하게 리렌더링되는지 디버깅할 필요도 없습니다. 컴포넌트가 왜 업데이트됐는지 궁금하다면, "어딘가에서 당신이 그렇게 하라고 했기 때문입니다."
Michael Jackson이 <Frame> 컴포넌트로 서버 렌더링을 시연했을 때, 그는 어떻게 plain HTML을 wire format으로 사용하는지 보여줬습니다.
Remix v3의 철학:[^32-1]
1.
Simplicity - 명시적으로 업데이트 제어
2.
Web Platform Alignment - 표준 이벤트, 표준 스트림
3.
Debuggability - 모든 업데이트를 특정 this.update() 호출로 추적
"Remix 팀은 React의 목표인 UX 기준을 높이는 것을 거부하지 않습니다. 하지만 그들은 React가 그것을 달성하기 위해 받아들이는 복잡성 세금을 거부합니다."
대가
하지만 이 선택에는 대가가 있었습니다.[^32-1][^34-1]
Remix v2 사용자들은 업그레이드 경로가 없습니다. "Remix 3은 Simplicity를 선택했습니다. Remix 2 사용자들은 그 대가를 치릅니다."
this.update()가 React의 hook 시스템보다 이해하기 쉬운 멘탈 모델을 만들지만, 명시적 렌더링은 더 장황한 코드를 의미합니다. AbortController는 수동으로 정리를 연결해야 합니다.
그리고 우려도 있습니다: "Remix 2와 react-router의 이야기는 Ryan과 Michael이 작동하는 것으로 피봇하는 것에 익숙하다는 것을 보여줍니다... 하지만 대규모 조직이 변화하는 플랫폼 위에 구축하기는 어렵습니다. Remix 3가 안정되기 전에 얼마나 많이 변할까요?"
Remix 팀은 솔직했습니다: 알파는 연말까지 예상되며, 일관된 패키지는 2026년에 나올 것입니다. "하지만 경고는 명확합니다: Remix 3는 당분간 프로덕션에 준비되지 않았습니다. 모든 것이 새롭고 변경될 수 있습니다."
3막: 다른 목소리들 (2020-2025)
HTMX - "복잡성은 나쁩니다"
Ryan과 Michael만이 복잡성에 의문을 품은 것은 아니었습니다.
Carson Gross는 더 급진적이었습니다.
2020년, 그가 만든 htmx[^161-1]는 간단한 질문을 던졌습니다:
"왜 JavaScript 프레임워크가 필요한가요?"
<!-- htmx 방식 -->
<button hx-post="/clicked"
hx-swap="outerHTML">
Click Me
</button>
HTML
복사
클릭하면? 서버가 HTML을 돌려주고, 그게 전부입니다.[^162-1][^163-1]
Carson이 인터뷰에서 말했습니다: "복잡성은 나쁩니다. 개발자들은 복잡한 것을 만드는 것을 좋아하지만, 그것은 사용자에게도, 개발자에게도 나쁩니다."
htmx의 철학:[^164-1]
•
JavaScript 최소화
•
서버 중심
•
Hypermedia 활용
•
웹의 원래 모습으로
Hotwire - Rails의 귀환
DHH도 비슷한 길을 걸었습니다.
2020년, Basecamp의 Hotwire:[^168-1][^169-1]
<!-- Turbo Frame -->
<turbo-frame id="messages">
<%= render @messages %>
</turbo-frame>
HTML
복사
서버에서 HTML을 보내고, Turbo가 해당 부분만 교체합니다.[^170-1]
DHH는 2013년부터 이야기해왔습니다: "진자는 다시 돌아옵니다. 우리는 2000년대에 서버 사이드 렌더링에서 시작했고, 2010년대에 SPA로 갔다가, 이제 다시 서버로 돌아오고 있습니다."
하지만 차이가 있습니다:[^169-1]
•
2000년대: 느린 full page reload
•
2025년: Turbo Drive로 빠른 부분 업데이트
왜 이들이 성공했을까?
흥미롭게도, 이 "단순한" 도구들이 견인력을 얻었습니다.[^166-1][^167-1]
이유는?
개발자들이 지쳤기 때문입니다. React의 복잡성에. 끝없는 도구 체인에. use client와 use server를 고민하는 것에.
htmx와 Hotwire는 말합니다:
"그냥 HTML을 쓰세요. 서버에서 렌더링하세요. 단순하게 가세요."
그리고 많은 프로젝트에서, 그것으로 충분했습니다.
에필로그: 진자의 의미
우리는 원점으로 돌아왔는가?
타임라인을 다시 보겠습니다:
•
1995년: PHP → 서버에서 HTML 생성
•
2005년: AJAX → 일부를 클라이언트로
•
2010년: SPA → 대부분을 클라이언트로
•
2015년: Isomorphic → 다시 양쪽으로
•
2020년: Server First → 다시 서버 중심으로
•
2023년: RSC → 서버 + 클라이언트의 새로운 조합
•
2025년: HTML Over Wire → 서버에서 HTML을...
이게 회귀일까요? 진보일까요?
아마도... 둘 다입니다.
매번 같은 곳으로 돌아오지만, 매번 더 나은 도구를 가지고 돌아옵니다:
•
1995년: PHP → 느리고, 보안 취약
•
2025년: htmx → 빠르고, 타입 안전하고, 테스트 가능
한 개발자가 잘 표현했습니다: "기술은 두 극단 사이를 오가는 진자처럼 움직입니다. 어떤 것은 유행입니다. 어떤 것은 그 순간의 기술적 제약에 의해 주도됩니다... 그리고 진자는 다시 돌아오기 시작합니다."
우리는 원을 그리고 있는 게 아니라, 나선형으로 올라가고 있습니다.
가치의 선택
Bryan Cantrill의 프레임워크를 빌리자면: "선거는 가치의 차이를 해결하지 못합니다. 아무리 많은 투표를 해도. 실제로 사람들의 마음을, 그들의 가치를 바꾸지 않는 한, 실제로는 아무것도 해결하지 못합니다."
2025년, 우리는 서로 다른 가치를 가진 진영들을 봅니다:
React / Next.js 진영:[^32-1]
•
Capability (기능성)
•
Stability (안정성)
•
End User First (최종 사용자 우선)
•
"복잡성을 우리가 떠안겠습니다"
Remix v3 진영:[^32-1][^40-1]
•
Simplicity (단순함)
•
Debuggability (디버깅 가능성)
•
Web Platform (웹 표준)
•
"명시적이고 추적 가능하게"
htmx / Hotwire 진영:[^165-1][^168-1]
•
Minimalism (최소주의)
•
Server-Centric (서버 중심)
•
No Build Step (빌드 없이)
•
"HTML만으로 충분합니다"
어느 것이 옳을까요?
답은 명확합니다: "이 가치들은 공존할 수 없습니다."
각 팀은, 각 프로젝트는, 자신의 가치를 선택해야 합니다.
당신의 선택은?
2025년, 새 프로젝트를 시작한다면?
Next.js App Router?
•
최신 기술과 RSC
•
거대한 생태계
•
하지만 높은 복잡도
React Router v7?
•
안정적이고 검증됨
•
RSC 점진적 도입
•
1,100만 프로젝트의 신뢰
Remix v3? (2026년 출시 예정)
•
Web Platform 우선
•
명시적 제어
•
하지만 불확실한 미래
htmx?
•
극도로 단순
•
서버 언어 자유
•
하지만 복잡한 상호작용은 어려움
Hotwire?
•
Rails 생태계
•
15년의 검증
•
하지만 Rails에 종속
정답은 당신이 결정합니다.
그리고 당신이 어떤 선택을 하든, 10년 후에는 또 다른 선택지들이 나타날 겁니다.
그게 웹의 역사였고, 그게 웹의 미래일 겁니다.
다음 장 예고
하지만 이 이야기에는 마지막 장이 남아있습니다.
React 팀은 정말 복잡성을 "해결"했을까요?
아니면 단지 다른 곳으로 옮긴 것일까요?
RSC는 정말 미래일까요?
아니면 또 다른 JavaScript Fatigue로 향하는 길일까요?
제8장에서 계속됩니다...
참고 문헌
[^12-1]: Remix Official Blog, "Merging Remix and React Router" (2024)
[^14-1]: Remix Official Blog, "React Router RSC Preview"
[^15-1]: Remix Official Blog, "Wake up, Remix!"
[^19-1]: Remix Official Blog, "Incremental Path to React 19: React Conf Follow-Up" (2024)
[^21-1]: Remix Official Blog, "React Router and React Server Components: The Path Forward"
[^22-1]: Mayank, "React Server Components: the Good, the Bad, and the Ugly"
[^23-1]: DEV Community, "Why I Decided to Stop Working with React.js in 2025" (Jan 2025)
[^24-1]: 200OK Solutions, "React Server Components: The Future of React in 2024 Web Development" (Oct 2024)
[^26-1]: N-School, "Limitations and challenges of using React Server Components" (Apr 2025)
[^27-1]: Smashing Magazine, "The Forensics Of React Server Components (RSCs)" (2024)
[^28-1]: Hacker News, "My take on the current React and Server Components controversy" (Jul 2023)
[^29-1]: Ably, "5 React trends to get ahead of in 2024"
[^31-1]: DEV Community, "Why I Finally Embraced Server Components in React and You Should Too" (Apr 2025)
[^32-1]: Laconic Wit, "React and Remix Choose Different Futures" (2025)
[^36-1]: Remix Official Blog, "Remix Jam 2025 Recap"
[^40-1]: Remix Official Blog, "Wake up, Remix!" (May 2025)
[^42-1]: mb21, "Building a Modern Website? SSG vs. SSR, SPA vs. MPA" (2023)
[^161-1]: Wikipedia, "htmx"
[^162-1]: SE Radio 671, "Carson Gross on HTMX"
[^163-1]: Answer.AI, "How HTMX is Revolutionizing Web Development - Interview with Carson Gross"
[^164-1]: Syntax FM #734, "HTMX Web Apps with Carson Gross" (2024)
[^165-1]: InfoWorld, "Complexity bad: An interview with HTMX creator Carson Gross" (2024)
[^166-1]: Changelog Podcast #646, "The CEO of htmx likes codin' dirty featuring Carson Gross"
[^167-1]: Ben Nadel, "Hypermedia Systems by Carson Gross" book review (2025)
[^168-1]: WizVille Blog, "DHH interview about Hotwire"
[^169-1]: Economy Blocked, "Hotwire: HTML Over The Wire, Turbo, and Stimulus JS" (2023)
[^170-1]: Listen Notes, "Hotwire, Rails NEXT, and the DHH Stack
with David Heinemeier Hansson" (2021)
