프롤로그: 약속의 땅
2023년, Next.js 13 App Router가 출시되었을 때 약속은 명확했습니다.
"React Server Components로 번들 사이즈를 줄이고, 성능을 개선하고, 개발 경험을 혁신하겠습니다."
2년이 지났습니다.
슬라이드는 훌륭했습니다.
데모는 완벽했습니다.
벤치마크는 인상적이었습니다.
하지만 프로덕션은 다른 이야기를 합니다.
1막: 프로덕션의 진실
성공 사례들
GeekyAnts는 용감한 결정을 내렸습니다. 기업 웹사이트를 Next.js 13으로 업그레이드하고 RSC를 활용하기로 한 것입니다. Lighthouse 성능 점수가 50점대였던 랜딩 페이지를 개선하기 위해서였습니다.
결과는 인상적이었습니다: 서버에서 더 많은 작업을 처리하고 클라이언트에 전송되는 JavaScript를 줄임으로써, 극적인 성능 향상을 달성했습니다.
Preply도 성공했습니다. Interaction to Next Paint (INP)가 나빴고, 이는 Google의 SEO 랭킹 요소가 될 예정이었습니다. 분석 결과, INP 개선으로 연간 약 20만 달러를 절감할 수 있을 것으로 추정되었습니다.
이런 케이스들이 헤드라인을 장식했습니다.
하지만 실패는 조용히 찾아왔다
한 개발자가 솔직하게 털어놓았습니다: "몇 주 전, 우리 프로덕션 앱이 멈추기 시작했습니다. 랜덤한 컴포넌트들이 로드되지 않았습니다."
제목이 말해줍니다: "React Server Components가 프로덕션 앱을 망가뜨리고 있습니다 (그리고 아무도 이에 대해 이야기하지 않습니다)"
왜 조용했을까요?
성공은 트윗합니다. 실패는 Slack DM으로 털어놓습니다.
세 가지 숨겨진 비용
1. 라이브러리 생태계의 붕괴
"많은 인기 라이브러리는 여전히 클라이언트 중심입니다. 서버 컴포넌트 내에서 사용하면 hydration 오류가 발생하거나 workaround가 필요할 수 있습니다."
10년 동안 쌓인 React 생태계.
수천 개의 라이브러리.
대부분이 작동하지 않습니다.
// 이 라이브러리... 서버 컴포넌트에서 작동할까요?
import { SomePopularLibrary } from 'popular-library'
// ❌ Error: You're importing a component that needs useEffect
// ❌ Error: Cannot access window in server component
// ❌ Error: This library requires client-side APIs
JavaScript
복사
2. 디버깅의 악몽
"커뮤니티는 고통스러운 프로덕션 경험을 통해 이러한 문제들을 파악했습니다. 문서가 아니라."
에러가 발생했을 때:
•
서버에서? 클라이언트에서?
•
빌드 타임? 런타임?
•
Hydration 불일치? 네트워크 문제?
"애플리케이션의 일부가 서버에서 실행되기 때문에, 전통적인 브라우저 기반 디버깅 도구로는 충분하지 않습니다. 개발자들은 서버 로그, 특수 디버깅 도구, 추가적인 관찰 기법에 의존해야 합니다."
3. 개발 속도의 추락
"고통스럽게 느린 개발 경험이 나를 Next.js에서 떠나게 만들었습니다."
"'God level' 빌드 프로세스는 한 영역의 변경이 애플리케이션의 대부분을 다시 빌드해야 하는 시스템을 만듭니다."
변경 → 저장 → 기다림 → 기다림 → 기다림...
플로우가 깨집니다.
2막: Vercel과 독립성의 환상
"오픈소스입니다"
Next.js는 MIT 라이선스입니다.
완전히 오픈소스입니다.
누구나 fork할 수 있습니다.
이론상으로는.
실무에서는
Northflank이 공개적으로 선언했습니다: "우리가 Next.js를 버리고 다시는 돌아보지 않은 이유"
이유:
•
Next.js 기능은 Vercel에서 가장 잘(또는 오직) 작동합니다
•
Vercel은 비싼 호스팅으로 lock-in 합니다
•
레플리카 간 나쁜 캐시 무효화 때문에 Next.js 확장이 골칫거리입니다
마이그레이션 후: "페이지가 50배 빠르게 로드됩니다 (20ms 대 700ms). 크롤러가 방문해도 더 이상 충돌하지 않습니다."
보이지 않는 커플링
"Image Optimization과 Middleware 같은 기능들은 Vercel의 플랫폼과 밀접하게 통합되어 있어, 다른 호스팅 제공자로 마이그레이션하는 것을 더 복잡하게 만들 수 있습니다."
"Next.js는 오픈소스이지만 Vercel의 로드맵에 크게 영향을 받습니다. Image Optimization, Middleware, Edge Functions 같은 기능들은 Vercel에서 가장 잘—또는 오직—작동합니다."
문제는 라이선스가 아니었습니다.
아키텍처였습니다.
2025년의 엑소더스
Jean Tinland은 Vercel 생태계에 대한 vendor lock-in 우려와 호스팅 결정에 대한 더 많은 통제를 원하며 Next.js를 떠났습니다. 그는 자체 호스팅 배포를 사용하는 더 단순한 Hono 기반 설정으로 이동했습니다.
이것은 고립된 사례가 아니었습니다.
"내 연구에서, 나는 유사한 이동을 문서화한 여러 최근 게시물을 발견했습니다: Northflank 같은 회사들은 'Next.js를 버리고 다시는 돌아보지 않은' 결정을 공개적으로 공유했고, 2024-2025년의 여러 Medium 기사들은 회사들이 프레임워크에서 완전히 떠나는 이유를 논의합니다."
3막: 생태계의 재편
숫자가 말해줍니다
2024년 State of Frontend 보고서의 핵심 발견: "React의 인기가 처음으로 감소했습니다 - 2022년 76.2%에서 2024년 69.9%로 6.3% 하락했습니다."
6.3%.
작아 보이나요?
React가 지배한 10년 동안, 처음으로 하락했습니다.
승자들
Svelte:
"Astro는 새로움에도 불구하고 25%의 놀라운 도입률을 달성했습니다. SvelteKit의 매력은 단순함과 반응성에서 비롯되었으며, 43.6%의 개발자가 미래에 배우고 싶다고 표현했습니다."
"Svelte의 GitHub 스타는 2019년 32,000개에서 2025년 중반까지 80,000개 이상으로 증가했습니다."
Astro:
"Astro는 기본적으로 JavaScript를 전송하지 않습니다 - 정적 HTML을 생성하고 Islands Architecture를 통해 필요할 때만 상호작용을 추가합니다."
"Astro는 2025년에 콘텐츠 중심 웹사이트를 위한 go-to 프레임워크가 되었습니다."
Vue:
"Vue는 '의존할 수 있는 두 번째 선택'으로 자리잡았습니다."
왜 이동했을까?
"Next.js에서 벗어나는 움직임은 웹 개발의 더 넓은 대화를 반영합니다 - 기술 선택을 적절한 크기로 만들고, 성능 우선으로 생각하고, 불필요한 복잡성을 줄이는 방향으로의 움직임입니다."
"많은 개발자들은 Next.js가 나쁘다고 말하는 것이 아닙니다. 그들의 특정 요구에 과한(overkill)이라고 말하는 것입니다."
단순함에 대한 갈망.
에필로그: 우리가 배운 다섯 가지
1. 복잡성은 이동할 뿐, 사라지지 않는다
업로드된 문서에 나온 Fizz와 Flight의 구분이 이를 보여줍니다:
Fizz (Streaming SSR):
•
HTML을 스트리밍
•
클라이언트/서버 동형 컴포넌트
•
비교적 단순
Flight (RSC):
•
가상돔 직렬화
•
번들러 통합 필수
•
새로운 복잡성
"SSR은 CSR의 한계를 해결하는 은 탄환이 아닙니다. SSR은 자체적인 단점이 있습니다. 초기 HTML 렌더링과 데이터 가져오기를 서버로 옮겼기 때문에, 이제 서버들은 훨씬 더 큰 부하를 경험합니다."
복잡성의 이동:
•
클라이언트 번들 → 서버 부하
•
런타임 복잡성 → 빌드 타임 복잡성
•
코드 복잡성 → 인프라 복잡성
2. 데모 ≠ 프로덕션
성공 사례:
•
잘 통제된 환경
•
최적화된 사용 패턴
•
전문 팀
프로덕션:
•
레거시 코드
•
서드파티 라이브러리
•
시간 압박
•
다양한 스킬 레벨
"Server Component 애플리케이션에서 취할 수 있는 최악의 접근은 항상 클라이언트 컴포넌트를 빌드하는 것을 기본으로 하는 것입니다. 나는 이것을 코드베이스에서 항상 봅니다. 개발자들이 Server Components에 대해 긴장하기 때문에, '안전하게' 모든 것에 use client를 붙입니다."
이상과 현실의 간극.
3. 생태계가 기술보다 중요하다
React가 10년 동안 지배한 이유:
•
npm 패키지 수십만 개
•
Stack Overflow 답변 수백만 개
•
채용 공고 수만 개
•
튜토리얼, 강의, 책...
하지만: "React는 채용 공고의 약 52%에 등장합니다. LinkedIn은 전 세계적으로 110,000개 이상의 React 개발자 포지션을 보여주는 반면, Svelte는 단 900개—122:1 비율입니다."
새 기술이 성공하려면:
•
기술적 우위만으로는 부족
•
생태계, 커뮤니티, 일자리가 필요
4. 독립성은 기술이 아니라 아키텍처다
오픈소스 라이선스 ≠ 벤더 독립성
진짜 질문:
•
다른 플랫폼에서 실행하기 쉬운가?
•
특정 호스팅에 최적화되어 있는가?
•
마이그레이션 비용은?
"프레임워크 선택에서 가장 중요한 요소는 기술 자체가 아니라, 팀의 전문성, 프로젝트 요구사항, 장기 목표와 얼마나 잘 맞는지입니다."
5. 만능 해결책은 없다
"경험 많은 팀이 만든 React 애플리케이션은 초보자가 만든 Svelte 애플리케이션보다 성능이 좋을 것입니다. 이론적인 성능 이점에 관계없이."
올바른 도구는 상황에 따라 다릅니다:
•
대규모 대시보드? → React + 강력한 팀
•
콘텐츠 사이트? → Astro
•
모바일 우선? → Svelte
•
레거시 앱? → 점진적 개선
•
단순한 CRUD? → Rails + Hotwire로도 충분
에필로그: 25년의 교훈
회고
1995년부터 2025년까지:
1995-2000: 서버가 모든 것을 함
→ 느리지만 단순
2005-2010: AJAX 혁명
→ 일부를 클라이언트로
2010-2015: SPA 시대
→ 모든 것을 클라이언트로
2015-2020: Isomorphic
→ 다시 양쪽으로
2020-2025: RSC와 분열
→ 선택의 시대
패턴
매번:
1.
새로운 기술이 약속합니다
2.
초기 채택자들이 환호합니다
3.
프로덕션이 현실을 보여줍니다
4.
생태계가 적응하거나 분열합니다
5.
새로운 균형점을 찾습니다
그리고 다시 반복됩니다.
2025년의 선택
지금 우리는 역사상 가장 많은 선택지를 가지고 있습니다:
•
React/Next.js: 생태계, 채용, 하지만 복잡함
•
React Router v7: 안정성, RSC 옵션
•
Remix v3 (2026): 단순함, 웹 표준, 불확실성
•
Svelte: 성능, 작은 번들, 작은 생태계
•
Astro: 콘텐츠 우선, 제로 JS
•
Vue: 균형, 접근성
•
htmx: 극도의 단순함
•
Hotwire: Rails 통합
어느 것이 "승자"일까요?
없습니다.
어느 것이 "올바른" 선택일까요?
당신의 상황에 달렸습니다.
마지막 질문
문서에 나온 Fizz와 Flight의 구분은 더 큰 진실을 암시합니다:
"Flight 없이 Fizz만 쓸 수 있다"
즉:
•
RSC 없이 Streaming SSR만 사용 가능
•
복잡성을 선택할 수 있음
•
필요한 만큼만 채택 가능
이것이 미래입니다:
도그마가 아니라 선택.
"유일한 방법"이 아니라 여러 방법.
전체 채택이 아니라 점진적 채택.
React는 계속 진화합니다: "2024년 9월, React 팀은 React Server Functions (RSF)를 발표했습니다." 더 많은 기능, 더 많은 복잡성이 추가되고 있습니다.
React Forget도 나올 예정입니다: "수동 useMemo/useCallback이 필요 없는 자동 메모화 컴파일러. 2025년 실험적, 2026년 안정화 예상."
그리고 그것도 괜찮습니다.
왜냐하면 이제 우리는 선택할 수 있기 때문입니다.
2026년에...
진자는 계속 움직일 것입니다.
새로운 프레임워크가 나타날 것입니다.
새로운 패러다임이 약속될 것입니다.
새로운 복잡성이 이동할 것입니다.
하지만 우리는 더 현명해졌습니다.
우리는 알고 있습니다:
•
은 탄환은 없다
•
복잡성은 사라지지 않는다
•
프로덕션만이 진실을 말한다
•
선택은 트레이드오프다
그리고 그것으로 충분합니다.
THE END
참고 문헌
[^43-1]: Ideafloats Technologies, "Server Components in React 2025" (June 2025)
[^44-1]: Large Apps Dev, "Advanced React in the Wild" (2024-2025)
[^45-1]: Smashing Magazine, "The Forensics Of React Server Components" (2024)
[^46-1]: DEV Community, "React Server Components Are Breaking Production Apps" (Oct 2025)
[^48-1]: DEV Community, "Enterprise React Performance Techniques in 2025" (Aug 2025)
[^49-1]: DEV Community, "The Complete Guide to React Server Components" (Oct 2025)
[^52-1]: Robin Wieruch, "React Trends in 2025"
[^53-1]: Enstacked, "Why Companies Are Moving Away from Next.js" (Sep 2025)
[^55-1]: mfyz.com, "Why People Are Moving from Next.js" (2025)
[^58-1]: Wisp CMS, "Why Should You Move Off Next.js?" (Apr 2025)
[^59-1]: DEV Community, "Why Some Tech Companies Are Moving Away from Next.js" (Apr 2025)
[^60-1]: Northflank Blog, "Why we ditched Next.js and never looked back"
[^64-1]: TSH.io, "JavaScript frameworks in 2025" (July 2025)
[^65-1]: Trinergy Digital, "Fastest Front-End Frameworks in 2025" (Nov 2025)
[^67-1]: Strapi, "Svelte vs React: A Comprehensive Comparison"
[^68-1]: DEV Community, "The Future of Web UI: Trends in React, Vue & Svelte" (Oct 2025)
[^69-1]: Leverture, "Frontend Frameworks in 2025"
[^71-1]: DEV Community, "The Next Big Things in Frontend" (July 2025)