(번역) 꼭 Next.js일 필요는 없습니다

ComfyDeploy 대시보드를 Next.js에서 순수한 리액트로 마이그레이션했습니다.

원문: You don't need Next.js

"꼭 Next.js일 필요는 없습니다"

요약

• 빌드 시간이 3분 에서 18초로 단축 되었습니다.
• 핫 리로드가 200ms 이내로 개선 되었습니다.
• 팀원 모두가 더 행복해졌어요. (훨씬 더!)

이에 대한 제 트윗이 폭발적인 반응을 얻었기 때문에 이러한 조치를 취한 이유를 정확히 분석하는 것이 도움이 될 것 같았습니다.

지금까지의 여정

저는 ComfyDeploy를 오픈 소스 프로젝트(GitHub)로 시작했습니다. Next.js가 프런트엔드와 백엔드 모두에 대한 전반적인 작업을 수행하는 풀스택 앱입니다. Drizzle과 서버 액션을 사용해 모든 것을 타입 세이프하고 깔끔하게 만들었습니다.

처음에는 모든 것이 괜찮았지만, 점점 문제가 생기기 시작했습니다.

• 한 사용자로부터 비롯된 막대한 API 사용량으로 인해 Vercel로부터 예상치 못한 2,000달러의 청구서를 받았습니다.
• 수많은 서버 액션이 API 라우트와 섞여 있었기 때문에 API 테스트는 악몽이 되었습니다.
• 빌드 시간이 너무 느려져서 마치 페인트가 마르는 것을 지켜보는 것 같았습니다.
• 로컬 개발은 끔찍했습니다. 아주 작은 변경 사항도 SSR을 전부 다시 로드하게 했습니다.

Next.js는 강력한 풀스택 프레임워크이지만, 올인원 접근 방식은 애플리케이션이 커짐에 따라 개발 복잡성으로 이어질 수 있습니다. 마이그레이션을 결정한 것은 두 가지 주요 요인에 따른 것입니다. 첫째, API 플랫폼으로서 Vercel의 기능 제한을 넘어 확장해야 했습니다. 전용(dedicated) 오토 스케일링 서버가 Next.js의 API 계층보다 더 합리적이었습니다. 둘째, 대시보드가 ​​주로 리액트 기반이었고 Next.js의 서버 측 기능이 필요하지 않았기 때문에 프레임워크의 최적화가 불필요한 오버헤드를 추가했습니다. 순수한 리액트로 구성되도록 전환하는 것이 우리 사례에서 가장 합리적인 선택이었습니다.

심각해지는 상황

성장을 거듭하면서, 우리는 라이브러리를 계속 추가했습니다. 빌드는 점점 더 느려졌습니다. Sentry를 추가한 이후엔 7분이 걸리기도 했습니다. 7분. 오타 하나 고치는 데도 커피 한 잔 마실 시간이 걸렸습니다.

로컬 개발 상황도 별반 다르지 않았습니다. Turborepo로 모노레포를 운영하고 있었는데, 관리가 너무 힘들어졌습니다. 심지어 개발 서버를 시작하는 것은 오래된 Windows 95 PC를 부팅하는 것만 같았습니다. 실제로는 M3 Max Macbook Pro였는데 말이죠.

그러다 Next.js 15 RC가 나왔습니다. 저는 "오, Turbopack이 우리를 구해줄지도 몰라!"라고 생각했습니다. 업그레이드하는 데 일주일을 보냈지만 호환성 문제가 발생했습니다. 일주일 후, 우리는 다시 14로 돌아왔고, 왜 실제로 제품을 만드는 것보다 Next.js와 씨름하는 데 더 많은 시간을 허비하고 있는지 의문이 들었습니다.

전환점

어느 날 아침, 저는 Next.js가 시작되는 데 10초가 걸리는 것을 지켜보고 있었습니다. 그게 끝이었습니다. 더 이상 참을 수 없었습니다.

"팀원 여러분, 다시 리액트로 돌아가야겠어요. 1주일만 시간을 주세요."

우리는 TanStack Router + Rspack으로 모든 것을 전환했습니다. shadcn 폴더 전체, 컴포넌트, 모든 것을 옮겼습니다. 그리고 그 결과? 며칠 만에 우리가 인식하지 못했던 사슬에서 벗어난 것 같은 느낌이 들었습니다.

• 즉시 실행되는 개발 서버 - 2초 이내
• Vercel에서 빌드는 18초 이내에 완료됩니다.
• 웹 개발이 다시 즐거워졌습니다!

이 마이그레이션 과정에서 대대적인 정리가 이루어졌습니다. 불필요한 오래된 기능을 버리고, 사용하지 않는 종속성을 제거하고, API 설정을 완전히 재구성했습니다. 때로는 무언가 더 나은 것을 만들기 위해 모든 것을 허물어야 할 때도 있습니다.

측정치

터보 모드가 적용된 Next js 15

터보 모드가 적용된 Next js 15의 로컬 개발 경험은 다음과 같습니다.

지표	시간
첫 페이지 빌드	10.4s

영상(업로드시 추가)

Tanstack Router + Rspack을 사용하는 리액트

지표	시간
라우팅 완료	~200ms
최초 개발 번들	1.67s

영상(업로드시 추가)

트레이드오프

현실적으로 모든 기술적 결정에는 트레이드오프가 따릅니다. 우리가 포기하고 얻은 것은 다음과 같습니다.

우리가 잃은 것

1. 프런트엔드와 백엔드의 코로케이션(Co-location)

코드베이스가 프런트엔드와 백엔드로 각각 분리되었지만, 관심사를 더 잘 분리하고 경계를 더 명확히 할 수 있게 되었습니다.

2. Next.js 캐싱 기능

내장된 캐싱 메커니즘을 잃었지만 사실 대부분의 데이터는 실시간 업데이트가 필요했습니다. 따라서 실제로 필요한 부분에만 캐싱을 구현하게 되었습니다.

3. 사전 렌더링과 초기 로딩

더 이상 자동 정적 생성이 이루어지지 않습니다. 페이지 로드 속도를 향상시키기 위해 보다 신중한 코드 분할이 필요했습니다. 하지만 결과적으로 UX가 개선되었습니다. JS가 로드되지 않아 사용자가 상호 작용할 수 없는 버튼을 보는 "고스트 클릭"이 더 이상 발생하지 않습니다. 보다 명확한 로딩 상태를 갖게 되었습니다.

4. 서버 컴포넌트 및 액션

서버 컴포넌트의 "마법"이 사라졌습니다. 서버 액션으로 인해 데이터를 빠르게 가져오는 것이 너무 쉬워졌습니다(어쩌면 너무 쉬웠던 걸지도?). 실시간 요구에 맞게 더 의도적인 API를 설계해야 했습니다. 서버 액션을 차단하자 폴링 업데이트가 훨씬 더 어려워졌습니다.

현실 직시

이렇게 “잃어버린 것” 덕분에 아키텍처에 대해 보다 나은 의사 결정을 할 수 있었습니다. 프레임워크의 마법에 의존하는 대신 더 나은 결정을 내려야 했습니다.

• API 컨트랙트를 더 신중하게 설계
• 정말 필요한 곳에만 캐싱을 구현합니다.
• 데이터 흐름과 상태 관리에 대해 더 신중하게 생각하기

때때로 제약은 더 나은 무언가를 구축하는 데 꼭 필요한 것이기도 합니다.

결론

만약 두 버전을 비교해보고 싶다면 ComfyDeploy React와 ComfyDeploy Next.js를 비교해보세요.

Next.js는 랜딩 페이지, SEO 등의 용도로 사용하기에 좋습니다. 단순한 개념을 멋지게 보이게 합니다(서버 액션은 REST API 호출일 뿐입니다).

하지만 대부분의 제품의 경우에는? 벽을 부수는데 사용하는 큰 망치로 액자를 거는 것과 다름없습니다. Next.js 14에서 15로 넘어가면서 종속성이 곳곳에서 깨졌고, 터보 모드를 사용하더라도 개발 서버는 여전히 벽에 머리를 부딪치고 싶을 정도로 느렸습니다.

랜딩 페이지와 SEO 작업에는 여전히 Next.js를 사용하지만 대시보드는 어떨까요? TanStack Router와 Rspack을 사용하는 순수한 리액트입니다. API? 필요할 때 언제든지 확장되는 간단한 Python FastAPI 서버가 Google Cloud Run에서 작동합니다.

때로는 덜어낼수록 더 나아집니다. 저희의 경우 Next.js를 덜어내는 것은 더 많은 배포, 더 빠른 속도, 더 많은 개발자의 만족을 의미했습니다.

그리고 분명히 말씀드리고 싶은 것은 Vercel은 놀라운 제품을 만들어온 놀라운 회사입니다. 저희는 여전히 다양한 프로젝트에 이 플랫폼을 사용하고 있습니다. 다만 Next.js는 우리 제품의 특정 사용 사례에 필요 이상의 기능을 제공할 뿐이었습니다.

마지막!

프런트엔드에서 픽셀을 배치하는 것부터 백엔드에서 확산 모델을 최적화하는 것까지 개발 도구를 출시하는 데 관심이 있는 분을 찾고 있습니다. 관심이 있으시면 트위터로 저에게 DM을 보내주세요.

🚀 한국어로 된 프런트엔드 아티클을 빠르게 받아보고 싶다면 Korean FE Article(https://kofearticle.substack.com/)을 구독해주세요!