Transcript

00:00:00Tan Stack Start가 요즘 주목받고 있는데, 과연 Next.js에서 갈아타야 할까요?
00:00:06Next.js보다 나을까요?
00:00:08어제 저는 두 프레임워크를 비교하며 하나의 앱을 두 번,
00:00:12Next.js로 한 번,
00:00:14Tan Stack Start로 한 번 만드는 라이브 스트림을 진행했는데,
00:00:18관심 있으시면 그걸 보셔도 되고요.
00:00:21여기서는 무엇이 다른지, 무엇이 더 나은지, 어떤 걸 써야 하는지 짧게 정리해드리겠습니다..
00:00:27물론 이건 제 의견일 뿐이고,
00:00:29객관적인 비교는 아니지만,
00:00:30두 프레임워크를 사용해본 경험과 Next.js와 Tan Stack Start에 대한 제 생각을 공유하겠습니다.
00:00:37두 프레임워크를 비교하기 위해 몇 가지 기준을 정했는데,
00:00:42더 추가할 수도 있고 다른 프레임워크들도 포함할 수 있겠죠.
00:00:47Remix나 React Router,
00:00:49Vue의 Nuxt,
00:00:50SvelteKit 같은 것들도 포함할 수 있지만,
00:00:53이 영상은 Next.js와 Tan Stack Start에 대한 것입니다.
00:00:57다른 것들이 나빠서가 아니라, 이 두 프레임워크가 자주 비교되기 때문입니다..
00:01:01우선 짚고 넘어가야 할 점은 Tan Stack Start는 결국 Tan Stack Router에 서버 기능을 추가한 것이라는 겁니다.
00:01:10만약 서버 사이드 렌더링이나 서버 함수가 필요 없는 싱글 페이지 애플리케이션을 만든다면 Tan Stack Router를 단독으로 사용할 수 있습니다.
00:01:19예를 들어 React Vite 앱에서 React Router 대신 Tan Stack Router를 사용할 수 있죠.
00:01:25말씀드린 것처럼 Tan Stack Start는 Tan Stack Router에 서버 사이드 기능을 추가해 풀스택 React 프레임워크로 만든 것입니다.
00:01:32Next.js와 마찬가지로 풀스택 React 프레임워크죠.
00:01:37이게 중요합니다.
00:01:38가끔 Next.js와 React Vite + React Router 중 어떤 걸 써야 하냐는 질문을 받는데,
00:01:45그건 잘못된 비교라고 생각합니다.
00:01:47서버 사이드 로직이나 서버 사이드 렌더링이 필요 없다면,
00:01:50그냥 React Vite,
00:01:52즉 Vite 프로젝트에 React를 추가하고 React Router나 Tan Stack Router를 사용하면 됩니다.
00:02:00그런 경우라면 굳이 Next.js를 선택할 필요가 없습니다.
00:02:02자, 이제 본격적인 비교를 시작하겠습니다.
00:02:05첫 번째 기준은 AI 준비도입니다. 요즘은 당연히 중요한 부분이죠.
00:02:12Next.js나 Tan Stack Start 프로젝트에서 원하는 코드 일부 또는 전부를 AI로 생성할 가능성이 높기 때문에,
00:02:21AI가 해당 코드를 어떻게 작성하는지 알아야 합니다.
00:02:25물론 문서 페이지를 복사하거나 Context 7 같은 MCP를 사용해 AI가 문서에 접근하도록 하거나,
00:02:33웹 검색을 하도록 하거나,
00:02:35Tan Stack Start나 Next.js 사용법을 가르치는 에이전트 스킬을 추가해서 적절한 컨텍스트를 제공할 수 있고,
00:02:45또 그래야 합니다.
00:02:47하지만 기본 상태에서 ChatGPT에 Tan Stack Start에 대해 물어보면,
00:02:52Next.js에 대해 아는 것보다 훨씬 적게 알고 있을 것이고,
00:02:56알고 있는 내용도 아마 틀렸을 겁니다.
00:02:59지금 이 영상을 녹화하는 시점에도 Tan Stack Start는 여전히 릴리스 후보 단계인데,
00:03:05큰 변경사항은 더 이상 없지만 완전히 안정적이지도 않다는 의미입니다.
00:03:10지난 1년간 주로 베타와 알파 단계였고,
00:03:13AI 챗봇들이 기본적으로 가지고 있는 지식이 바로 그 시기의 것이기 때문에 Tan Stack Start에 대해 잘못된 정보를 가지고 있을 수밖에 없습니다.
00:03:23그래서 기본 상태의 AI 준비도는 그다지 좋지 않고, Next.js가 확실히 더 낫습니다.
00:03:31Next.js도 물론 수년간 변화가 있었고,
00:03:34새로운 use cache 지시어 같은 것은 AI가 기본적으로 잘 모르긴 하지만,
00:03:41앱 라우터나 React 서버 컴포넌트 등에 대해서는 꽤 잘 이해하고 있어서 Tan Stack Start보다는 확실히 낫습니다.
00:03:51하지만 다시 말씀드리지만, AI에게 필요한 추가 컨텍스트를 반드시 제공해야 합니다.
00:03:58그렇지 않으면 AI를 잘못 사용하고 있는 겁니다..
00:04:02생태계는 어떨까요?
00:04:03여기서 말하는 생태계란 튜토리얼,
00:04:06유튜브 영상,
00:04:07강좌 같은 다른 리소스들과 이 프레임워크들을 위한 추가 패키지를 의미합니다..
00:04:13그리고 여기서 물론 Next.js는 Tan Stack Start보다 훨씬 더 좋아 보입니다.
00:04:19단순히 더 오래되었고, 더 오래 존재해왔기 때문에 더 크기도 하니까요.
00:04:24그래서 관련 자료를 더 많이 찾을 수 있습니다..
00:04:27물론 더 크다는 것은 더 많이 사용된다는 의미이기도 한데,
00:04:30이는 Next.js가 AI의 기본 스택에 포함되어 있기 때문입니다.
00:04:34AI는 기본적으로 대부분의 웹 앱 요청에 대해 Next.js,
00:04:38React,
00:04:39Tailwind,
00:04:40TypeScript를 제공하죠.
00:04:42Tan Stack Start는 아마 절대 기본 선택지가 되지 못할 겁니다..
00:04:47그래서 당연하게도 두 프레임워크의 다운로드 차트를 비교하면,
00:04:50네,
00:04:51Tan Stack Start의 다운로드 수가 확실히 적은 것을 볼 수 있습니다.
00:04:56Next.js를 제거하면 Tan Stack Start의 멋진 상승 추세를 볼 수 있긴 하지만요.
00:05:01생태계 측면과 관련된 것이 물론 학습의 용이성이지만, 그것만은 아닙니다.
00:05:07학습의 용이성이란 그것을 배우는 것이 얼마나 간단한가를 의미합니다.
00:05:11물론 지금 AI 시대에는 그것을 배우는 데 관심이 없다는 걸 알지만,
00:05:16좋은 개발자라면 자신이 다루는 것을 이해해야 합니다.
00:05:19더 이상 모든 코드를 손으로 직접 작성하지 않을 수도 있지만, AI가 생성하는 코드는 이해해야 합니다.
00:05:25그래서 배우는 것은 여전히 중요합니다.
00:05:28그리고 여기서 Next.js의 경우 복합적이라고 말하고 싶습니다.
00:05:33플러스 하나를 줄지 둘을 줄지 확실하지 않은데, Next.js를 앱 라우터로 시작하는 것은 꽤 간단합니다.
00:05:41참고로 여기 모든 내용은 앱 라우터를 기준으로 합니다..
00:05:46말이 됩니다.
00:05:47어제 스트림에서 노트를 생성하고 저장하고 렌더링할 수 있는 작은 노트 작성 애플리케이션을 만들었습니다.
00:05:56Next.js로 그렇게 하려면 몇 개의 page.tsx 파일만 지정하면 되는데,
00:06:00그게 바로 여러분이 예상한 대로 페이지입니다.
00:06:03동적 세그먼트도 가질 수 있습니다.
00:06:04그리고 그 문법과 애플리케이션을 구축하는 접근 방식을 배우는 것은 결국 꽤 간단합니다.
00:06:12또한 문서가 핵심 개념을 단계별로 안내하고 Next.js를 시작하는 데 좋은 역할을 한다고 생각합니다.
00:06:22하지만 더 복잡한 애플리케이션을 만들고 캐싱 같은 고급 개념에 들어가면 상황이 더 복잡해집니다.
00:06:30특히 캐싱 부분은 매우 혼란스러울 수 있는데,
00:06:34Next.js가 앱 라우터 도입과 함께 여러 레이어에서 매우 공격적인 캐싱을 하기로 결정했기 때문입니다.
00:06:43그것을 이해하고,
00:06:44내장된 캐싱과 잘 작동하도록 컴포넌트를 구성하는 방법을 이해하고,
00:06:50사용자에게 원하는 동작을 제공하는 것은 까다로울 수 있습니다..
00:06:55그렇게 말하겠습니다.
00:06:56시작하기는 훌륭합니다.
00:06:59고급 기능을 배우기는 어렵습니다.
00:07:02아마 여기에 플러스 두 개를 주겠습니다.
00:07:05그리고 Tan Stack Start에도 똑같이 주겠지만 매우 다른 이유에서입니다.
00:07:09Tan Stack Start의 경우 시작하기 문서가 Next.js 문서만큼 좋지 않아서 시작하기가 Next.js보다 약간 더 어렵다고 말하겠습니다.
00:07:20여기에는 데이터 페칭이나 뮤테이션 같은 중요한 개념이 빠져 있다고 봅니다.
00:07:27하지만 이미 Next.js 지식이 있다면 데이터 페칭과 뮤테이션을 포함한 주요 기능을 비교하는 꽤 좋은 비교 문서가 있습니다.
00:07:36하지만 문서가 크게 개선되었다고 말하긴 하지만,
00:07:40여전히 약간의 브레인 덤프 느낌이 있어서 어떤 문서가 필요한지 명확하지 않고,
00:07:46예를 들어 여기에는 데이터 페칭 관련 문서가 없는 등의 이유로 조금 더 어려울 수 있다고 생각합니다.
00:07:54게다가 Tan Stack Start는 모든 라우팅 관련 기능을 Tan Stack Router 위에 구축했기 때문에 Tan Stack Router 문서를 봐야 하는데,
00:08:04처음 볼 때는 이것도 꽤 압도적입니다.
00:08:07하지만 일단 그 초기 장벽을 넘고 나면 훨씬 쉬워지고 제 생각에는 모두 말이 되며 그렇게 어렵지 않고,
00:08:15Next.js에서 겪을 수 있는 캐싱 관련 문제 같은 숨겨진 함정도 없습니다.
00:08:22그래서 Tan Stack Start는 시작하기는 더 어렵지만 일단 시작하고 나면 Next.js보다 더 고급 기능으로 진행하고 파고들기가 더 쉽다고 말하겠습니다.
00:08:32말씀드린 것처럼 이건 물론 제 개인적인 견해일 뿐입니다.
00:08:36그렇다면 개발자 관점에서의 사용 편의성은 어떨까요?
00:08:41작업하기에 얼마나 즐거운가요?
00:08:43물론 완전히 주관적이지만 Next.js는 여기서 분명히 몇 가지 문제가 있습니다.
00:08:48학습과 관련된 문제뿐만 아니라 다른 문제들도 있습니다.
00:08:53예를 들어 캐싱 때문에 개발 모드에서 앱이 프로덕션 모드와 다르게 동작할 수 있는데,
00:08:59이는 항상 프로덕션 모드에서 테스트해야 한다는 의미입니다.
00:09:03어차피 해야 하는 일이지만 개발 중에 항상 이렇게 해야 한다면 작업 속도가 느려지기 때문에 상당히 성가십니다..
00:09:11이게 제가 과거에 겪었던 큰 문제 중 하나입니다.
00:09:14개발 서버도 꽤 느려질 수 있습니다.
00:09:18적어도 webpack 버전을 사용한다면 그렇고,
00:09:21새로운 기본값인 turbo pack 버전은 그 면에서 훨씬 낫지만 제 경험상 Tan Stack Start가 제공하는 vite 기반 설정을 따라오지는 못합니다.
00:09:30그래서 여기에는 플러스 세 개를 주겠습니다. 제 경험상 개발자 경험 관점에서 작업이 정말 부드러웠거든요.
00:09:40빠르고, 예측 가능하며, 대부분의 경우 이상한 동작이 없습니다.
00:09:45여전히 여기저기 약간의 문제는 있고 아직 릴리스 후보 단계이긴 하지만 전반적으로 Next.js보다 Tan Stack Start의 개발자 경험을 선호합니다..
00:09:57물론 여러분에게는 다를 수 있습니다.
00:10:01이제 Next.js와 Tan Stack Start가 제공하는 구체적인 기능은 어떨까요?
00:10:06라우팅의 경우 제가 보여드린 것처럼 Next.js는 파일 기반 접근 방식을 사용하는데,
00:10:11라우트 역할을 하는 파일들을 설정하고 거기서 따라야 할 다양한 네이밍 규칙이 있습니다.
00:10:16문서가 이를 잘 설명하고 있지만 parallel routes 같은 더 복잡한 기능들도 분명히 있고 이들은 설정하기가 까다로울 수 있습니다.
00:10:25Tan Stack Start도 말씀드린 것처럼 Tan Stack Router를 내부적으로 사용하는 파일 기반 접근 방식을 가지고 있으며,
00:10:32여기서도 따라야 할 파일명 규칙이 있는데 이것도 마찬가지로 배우기 쉽습니다.
00:10:36Tan Stack Start에서 얻을 수 있는 한 가지 장점은 파일 기반 라우팅이 완전한 타입 안정성을 제공한다는 점인데,
00:10:44이게 꽤 좋습니다.
00:10:45둘 다 파일 기반이고 어떤 네이밍 패턴을 선호하는지는 여러분의 선호에 달려 있지만,
00:10:51Tan Stack Start는 파일 기반 라우터와 함께 제공되는 100% 타입 안정성이 있다는 점이 좋습니다.
00:11:00이것은 다음 질문에 대한 답이기도 한데,
00:11:02Next.js는 매우 좋은 타입스크립트 지원을 가지고 있고 Tan Stack Start는 제 경험상 훨씬 더 나은 타입스크립트 지원을 제공합니다.
00:11:11또한 server actions나 server functions,
00:11:14또는 뭐라고 부르든 그런 것들과 데이터 페칭에 관해서도 마찬가지입니다.
00:11:18그래서 네,
00:11:18타입스크립트를 사용할 때,
00:11:20제 생각에는 사용해야 하는데,
00:11:21Tan Stack Start는 정말 작업하기 즐겁습니다.
00:11:24데이터 페칭과 데이터 변형에 관해서는,
00:11:26제가 언급한 것처럼 둘 다 서버에서 코드를 실행할 수 있고,
00:11:30둘 다 풀스택 React 애플리케이션이지만 서로 다른 접근 방식을 취합니다.
00:11:35Next.js는 React 서버 컴포넌트를 사용하며 오랫동안 React 서버 컴포넌트를 지원하는 유일한 프레임워크였습니다.
00:11:43즉, 페이지 컴포넌트가 기본적으로 서버에서만 렌더링됩니다.
00:11:48클라이언트에서는 절대 재렌더링되지 않으므로,
00:11:50이런 식으로 뒤에서 데이터베이스에 접근하는 데이터 페칭 코드를 컴포넌트에 넣을 수 있고 그게 클라이언트로 넘어가지 않습니다.
00:11:59Tan Stack Start는 다른 접근 방식을 취합니다.
00:12:01React 서버 컴포넌트 지원도 곧 추가될 예정인데,
00:12:04제가 이걸 녹화하는 시점에는 아직 나오지 않았지만 여기서 보여드리고 제가 모든 프로젝트에서 사용한 이 접근 방식도 계속 존재할 것이며,
00:12:13이 접근 방식에서는 라우트 컴포넌트가 기본적으로 서버 사이드와 클라이언트 사이드 둘 다에서 렌더링되고,
00:12:19서버 사이드에서 사전 렌더링되고,
00:12:21클라이언트 사이드에서 업데이트되기 때문에 컴포넌트 함수에 서버 사이드 코드를 넣을 수 없습니다.
00:12:27대신 Remix에서 익숙할 수 있는 로더 패턴을 사용하는데,
00:12:31라우트에 로더를 연결할 수 있으며 이는 클라이언트와 서버 측 모두에서 실행됩니다.
00:12:37그런 다음 Tan Stack Start에서 제공하는 함수인 create server function으로 데코레이트되거나 래핑된 함수를 호출할 수 있습니다.
00:12:48이는 서버 측에서만 실행되지만 클라이언트 측에서 호출 가능한 함수로 표시하는 것입니다..
00:12:54이것이 바로 서버 함수입니다.
00:12:56이러한 함수가 있으면 로더나 컴포넌트 함수 본문에서 안전하게 호출할 수 있으며 코드는 서버 측에 그대로 유지됩니다.
00:13:05내부적으로는 HTTP 요청이 전송됩니다.
00:13:07Next.js는 주로 RSC에 의존하지만 물론 API 엔드포인트를 설정하고 Fetch API와 함께 useEffect를 사용할 수도 있습니다.
00:13:15Tan Stack Start는 로더와 서버 함수를 사용하지만,
00:13:19여기서도 API 라우트를 설정하고 Fetch API나 Tan Stack Query 같은 것을 사용할 수 있다는 점도 주목할 가치가 있습니다.
00:13:26하지만 주요 내장 방식은 이 로더와 서버 함수를 결합한 접근 방식입니다..
00:13:31변경 작업의 경우 Next.js는 서버 액션을 사용하는데,
00:13:35이는 특별한 useServer 지시어로 데코레이트된 액션들입니다.
00:13:39Next.js에는 useServer, useClient와 같은 지시어들이 있습니다.
00:13:44어떤 사람들은 이것을 좋아하지 않는데, 저도 솔직히 큰 팬은 아닙니다.
00:13:48파일이 useServer로 데코레이트되면 그 안의 모든 함수는 서버에서만 실행되는 서버 함수가 됩니다.
00:13:55클라이언트 측에서는 실행되지 않지만 클라이언트 측에서 여전히 호출할 수는 있습니다.
00:13:59예를 들어 데이터베이스에 노드를 저장하는 이 saveNode 함수는 useActionState 훅을 사용하여 클라이언트 측에서 여전히 호출할 수 있습니다.
00:14:10Tan Stack Start에서는 이 createServer 함수 접근 방식을 계속 사용합니다.
00:14:15왜냐하면 제가 언급했듯이 서버에서 실행이 보장되는 함수들이고,
00:14:18데이터 가져오기나 데이터 변경 작업에 사용할 수 있기 때문입니다.
00:14:21다시 말하지만 코드는 서버에서만 실행됩니다..
00:14:24클라이언트에서도 렌더링되는 컴포넌트 함수에서는 Tan Stack Start에서 제공하는 useServer 함수 훅을 사용하여 서버 함수를 래핑할 수 있으며,
00:14:33이는 본질적으로 클라이언트 측에서 호출 가능하게 만들고 자동 리다이렉트 처리 등의 추가 기능을 제공합니다.
00:14:39그렇게 하면 클라이언트 측 컴포넌트에서 해당 서버 함수를 호출할 수 있습니다.
00:14:43Next.js는 공식 React 서버 함수를 사용하고 Tan Stack Start는 자체 서버 함수를 사용합니다.
00:14:51물론 전반적인 아이디어는 동일합니다.
00:14:54그렇다면 캐싱은 어떨까요?
00:14:56이것이 어려운 부분이라고 말씀드렸습니다.
00:14:58Next.js에서는 꽤 공격적이고 잠재적으로 복잡합니다.
00:15:04확실히 Next.js의 어려운 부분 중 하나입니다.
00:15:07그리고 저는 Next.js를 배우고 싶으시다면 제 Next.js 강의에서 다른 모든 중요한 Next.js 개념들과 함께 이것을 다룹니다.
00:15:16이 강의는 완전 초보자부터 고급 Next.js 사용자까지 성장할 수 있는 훌륭한 자료입니다.
00:15:21하지만 캐싱은 확실히 Next.js에서 더 문제가 되는 주제 중 하나입니다.
00:15:26물론 장점은 공격적인 기본 설정 덕분에 사용자에게 잠재적으로 꽤 좋은 캐싱을 제공할 수 있다는 것입니다.
00:15:35하지만 꽤 쉽게 자충수를 둘 수도 있습니다.
00:15:38Tan Stack Start의 경우 좋은 기본 설정이라고 요약하겠습니다.
00:15:43Next.js보다 훨씬 덜 공격적이고,
00:15:46가장 중요한 것은 제 경험상 개발 모드와 프로덕션 모드 간에 일관성이 있다는 것입니다.
00:15:52사용자가 라우트 간을 탐색할 때 예를 들어 일정 기간 동안 데이터를 캐시하는 기능도 제공합니다.
00:16:00따라서 빠른 탐색을 위해 서버에 수많은 요청을 보내지 않습니다.
00:16:04그리고 이는 물론 성능에 크게 도움이 되지만,
00:16:07모든 것을 캐싱하거나 여러 레이어에서 모든 것을 캐싱하려고 시도하지 않기 때문에 개발자로서 삶을 더 쉽게 만들 수 있습니다.
00:16:14물론 이것은 사용자를 위한 최고의 성능을 얻고 잠재적으로 트래픽을 절약하려면 직접 좋은 캐싱 헤더를 설정하고 Next.js에서 필요할 수 있는 것보다 애플리케이션을 캐싱하는 방법에 대해 조금 더 생각해야 한다는 것을 의미하기도 합니다.
00:16:30하지만 그 경우에는 다른 문제들을 고려해야 합니다.
00:16:32그럼 안정성은 어떨까요?
00:16:35여기서는 아마 둘 다 두 개의 플러스를 주겠습니다.
00:16:39둘 다 꽤 안정적입니다.
00:16:40물론 Next.js가 더 성숙하지만 제 경험상 지난 몇 년간 꽤 버그가 많았습니다.
00:16:49특히 개발 서버에서 크래시 등의 문제가 있었죠..
00:16:53하지만 많이 개선되었고 전반적으로 안정적인 경험을 제공하며,
00:16:57물론 이를 사용하는 수백,
00:16:59수천 개의 애플리케이션이 프로덕션 환경에서 문제없이 운영되고 있습니다.
00:17:03이 점은 분명히 중요하게 언급할 필요가 있습니다.
00:17:06물론 React 보안 취약점들이 있었지만,
00:17:08첫째로 그중 일부는 향후 발견될 수 있고 10-stack start에도 영향을 줄 수 있습니다.
00:17:14특히 그들도 React 서버 컴포넌트를 지원하기 시작하면요.
00:17:17둘째로 이것은 주로 Next.js의 문제는 아닙니다..
00:17:2110-stack start는 아직 릴리스 후보 단계에 있고 저도 분명히 여러 문제들을 겪었습니다.
00:17:28이상한 크래시,
00:17:29이상한 에러 메시지,
00:17:30여기저기서 이상한 동작들이 있어서 그냥 플러스 하나만 줄 수도 있지만,
00:17:35릴리스 후보 단계임을 감안하면 꽤 안정적이라고 할 수 있어서 여기서는 두 개를 주겠습니다.
00:17:41다만 10-stack start를 사용할 때 분명히 몇 가지 문제에 부딪힐 수 있다는 점을 알아두세요.
00:17:47그렇긴 하지만 저는 buildmygraphic.com 같은 프로덕션 애플리케이션을 운영하고 있는데요,
00:17:53AI의 도움으로 멋진 인포그래픽을 만들 수 있는 이 사이트는 10-stack start로 구동되며 문제없이 실행되고 있고 개발하는 데도 문제가 없었습니다.
00:18:02배터리 포함은 어떨까요?
00:18:04최적화된 이미지 렌더링, 국제화 또는 그런 재미있는 것들을 얻기가 얼마나 쉬운가요?
00:18:12여기서는 Next.js가 확실히 더 나은 일을 하고 있습니다.
00:18:15내장 이미지 컴포넌트가 있고,
00:18:17내장 국제화 지원이 있지만 10-stack start에는 그런 것들이 없습니다.
00:18:24계획이 있는지는 모르겠고, 여러분에게 중요한지도 모르겠지만, 확실히 필요한 것은 아닙니다.
00:18:30다른 대안들, 사용할 수 있는 서드파티 패키지들이 있고, 어쩌면 내장 기능을 원하지 않을 수도 있죠.
00:18:36하지만 그것이 여러분이 신경 쓰거나 걱정하는 부분이라면 Next.js가 아마 더 나은 선택일 겁니다..
00:18:43그럼 배포는 어떨까요?
00:18:45이것은 어려운 주제입니다.
00:18:48Next.js는 물론 Vercel에서 만들었고 Vercel에 배포하면 매우 쉽고 부드럽습니다.
00:18:56모든 것이 그것에 최적화되어 있죠.
00:18:58역사적으로 자체 서버에 배포하는 것은 다소 어려웠지만,
00:19:02공평하게 말하자면 Next.js 팀이 그것을 더 쉽게 만들고 더 나은 문서를 작성하는 데 실제로 노력을 기울였고,
00:19:11따라서 요즘에는 다른 서비스에도 큰 문제 없이 배포할 수 있다고 말할 수 있습니다.
00:19:17그래서 두 개 또는 세 개의 플러스인데,
00:19:21Vercel을 사용하면 세 개,
00:19:23다른 제공업체를 사용하면 아마 두 개라고 말하고 싶습니다.
00:19:2810 stack start의 경우 지금은 두 개를 주겠지만 세 개를 줄 수도 있습니다.
00:19:36제가 두 개를 주는 주된 이유는 제가 이것을 녹화하는 시점에 호스팅 문서가 아직 좀 까다롭기 때문입니다.
00:19:45Cloudflare와 Netlify 같은 공식 지원 파트너들이 있는데 꽤 좋은 문서가 있고 배포가 아마 꽤 부드러울 것 같지만,
00:19:53저는 그것들을 사용해보지 않았습니다.
00:19:56예를 들어 BUN으로 자체 VPS에서 실행하고 싶다면 여기에 몇 가지 지침이 있지만,
00:20:02그것들을 따르는 것이 좀 어렵다고 느꼈거나 모두 해결 가능했던 몇 가지 문제들에 부딪혔지만 확실히 시간이 좀 걸렸습니다.
00:20:12BUN이나 Node로 VPS에 10 stack start를 배포하는 좋은 가이드가 생기면 배포가 확실히 더 쉬워질 것 같습니다.
00:20:21특히 그 가이드에 따라야 할 모범 사례나 직면할 수 있는 잠재적인 함정에 대한 권장사항이 포함되어 있다면요..
00:20:29하지만 언급했듯이 이것을 어떻게 보느냐에 따라 세 개의 플러스를 줄 수도 있습니다.
00:20:34말씀드렸듯이 이것은 모두 주관적이고 제 경험과 생각일 뿐이며,
00:20:38물론 저도 여러분의 생각을 듣는 데 관심이 있습니다.
00:20:42전환을 했는지,
00:20:43Next.js와 T3 Stack에 대해 어떻게 생각하는지,
00:20:46전환을 고려 중인지,
00:20:47아니면 둘 다 사용하지 않고 다른 옵션을 사용하는지 알려주세요.

Key Takeaway

TanStack Start는 Next.js에 비해 더 나은 타입 안정성과 개발자 경험을 제공하지만, AI 지원, 생태계, 안정성 측면에서는 Next.js가 여전히 우위에 있으며, 선택은 프로젝트 요구사항과 개발자 선호도에 달려 있다.

Highlights

TanStack Start는 TanStack Router에 서버 기능을 추가한 풀스택 React 프레임워크

AI 준비도와 생태계 측면에서는 Next.js가 압도적으로 우세하지만, TanStack Start는 더 나은 타입 안정성 제공

Next.js는 시작하기 쉽지만 캐싱 등 고급 기능은 복잡하며, TanStack Start는 초기 진입장벽이 있으나 이후 더 쉬움

개발자 경험 측면에서 TanStack Start가 더 빠르고 예측 가능하며, 개발/프로덕션 모드 간 일관성이 우수

Next.js는 React 서버 컴포넌트와 서버 액션을 사용하고, TanStack Start는 로더와 서버 함수 패턴 활용

Next.js는 공격적인 캐싱으로 성능 최적화가 가능하지만 복잡하고, TanStack Start는 합리적인 기본 설정 제공

배포는 Next.js가 Vercel에서 최적화되어 있고, TanStack Start는 아직 문서가 부족하지만 개선 중

Timeline

소개 및 프레임워크 개요

발표자는 TanStack Start와 Next.js를 비교하는 라이브 스트림을 진행한 경험을 바탕으로 두 프레임워크의 차이점을 정리합니다. TanStack Start는 기본적으로 TanStack Router에 서버 사이드 렌더링과 서버 함수 기능을 추가한 풀스택 React 프레임워크라고 설명합니다. Next.js와 React Vite + React Router를 비교하는 것은 잘못된 비교이며, 서버 사이드 로직이 필요 없다면 단순히 Vite 프로젝트에 React와 라우터를 추가하면 된다고 강조합니다. 이 영상은 발표자의 주관적인 의견이지만 실제 사용 경험을 바탕으로 한 솔직한 비교가 될 것임을 밝힙니다.

AI 준비도 및 생태계 비교

AI 준비도 측면에서 Next.js가 압도적으로 유리한데, ChatGPT 같은 AI 도구들이 Next.js에 대해 훨씬 많은 지식을 가지고 있기 때문입니다. TanStack Start는 현재 릴리스 후보 단계이며 지난 1년간 베타와 알파 단계였기 때문에 AI가 보유한 정보가 부정확하거나 오래된 경우가 많습니다. 발표자는 Context 7 같은 MCP나 웹 검색을 통해 AI에게 최신 문서를 제공해야 한다고 조언합니다. 생태계 측면에서도 Next.js는 더 오래 존재했고 더 많은 튜토리얼, 유튜브 영상, 강좌, 추가 패키지를 보유하고 있어 TanStack Start보다 우위에 있습니다. NPM 다운로드 차트를 보면 Next.js가 압도적으로 많이 사용되고 있지만, TanStack Start도 상승 추세를 보이고 있습니다.

학습의 용이성 비교

Next.js는 시작하기는 쉽지만 고급 기능을 배우기는 어려운 반면, TanStack Start는 초기 진입장벽이 있지만 일단 시작하면 더 쉽다고 평가합니다. Next.js는 page.tsx 파일을 사용한 파일 기반 라우팅이 직관적이고 문서가 핵심 개념을 잘 안내하지만, 캐싱 같은 고급 개념에 들어가면 매우 복잡해집니다. Next.js는 앱 라우터 도입과 함께 여러 레이어에서 공격적인 캐싱을 하기로 결정했는데, 이를 이해하고 올바르게 구성하는 것이 까다롭습니다. TanStack Start는 시작하기 문서가 Next.js만큼 좋지 않고 데이터 페칭 같은 중요한 개념이 빠져있으며, TanStack Router 문서까지 봐야 해서 초기에 압도적일 수 있습니다. 그러나 초기 장벽을 넘으면 모든 것이 논리적이고 Next.js의 캐싱 문제 같은 숨겨진 함정이 없어서 고급 기능으로 진행하기가 더 쉽습니다.

개발자 경험 및 사용 편의성

개발자 경험 측면에서 TanStack Start가 Next.js보다 우수하다고 평가합니다. Next.js는 캐싱 때문에 개발 모드와 프로덕션 모드에서 앱이 다르게 동작할 수 있어 항상 프로덕션 모드에서 테스트해야 하는 불편함이 있습니다. Next.js의 개발 서버는 특히 webpack 버전을 사용할 때 느릴 수 있으며, 새로운 기본값인 turbopack이 개선되었지만 여전히 Vite 기반 설정만큼 빠르지 않습니다. TanStack Start는 빠르고 예측 가능하며 이상한 동작이 거의 없어서 전반적인 개발자 경험이 더 부드럽습니다. 아직 릴리스 후보 단계라 여기저기 약간의 문제는 있지만, 발표자는 Next.js보다 TanStack Start의 개발자 경험을 선호한다고 밝힙니다.

라우팅 및 타입스크립트 지원

두 프레임워크 모두 파일 기반 라우팅 접근 방식을 사용하며 각각의 네이밍 규칙을 따라야 합니다. Next.js는 parallel routes 같은 복잡한 기능도 제공하지만 설정이 까다로울 수 있습니다. TanStack Start도 TanStack Router를 기반으로 한 파일 기반 라우팅을 사용하며 배우기 쉽습니다. 가장 큰 차이점은 TanStack Start가 파일 기반 라우팅에서 100% 타입 안정성을 제공한다는 점입니다. 타입스크립트 지원 측면에서 Next.js도 좋은 지원을 제공하지만, TanStack Start는 훨씬 더 나은 타입스크립트 지원을 제공합니다. 서버 액션, 서버 함수, 데이터 페칭 등 모든 영역에서 타입 안정성이 우수하여 타입스크립트를 사용할 때 작업하기 매우 즐겁습니다.

데이터 페칭 및 변형 접근 방식

두 프레임워크 모두 서버에서 코드를 실행할 수 있는 풀스택 React 애플리케이션이지만 서로 다른 접근 방식을 취합니다. Next.js는 React 서버 컴포넌트를 사용하여 페이지 컴포넌트가 기본적으로 서버에서만 렌더링되므로 컴포넌트에 데이터베이스 접근 코드를 직접 넣을 수 있습니다. TanStack Start는 다른 접근 방식을 취하는데, 라우트 컴포넌트가 서버와 클라이언트 양쪽에서 렌더링되기 때문에 Remix에서 익숙한 로더 패턴을 사용합니다. createServerFunction으로 래핑된 서버 함수를 로더에서 호출하여 서버 측 코드를 실행합니다. 변경 작업의 경우 Next.js는 'use server' 지시어로 데코레이트된 서버 액션을 사용하고, TanStack Start는 createServerFunction 접근 방식을 계속 사용하며 useServerFunction 훅으로 클라이언트 측에서 호출 가능하게 만듭니다. Next.js는 공식 React 서버 함수를 사용하고 TanStack Start는 자체 서버 함수를 사용하지만 전반적인 아이디어는 동일합니다.

캐싱 전략 비교

캐싱은 Next.js에서 가장 어려운 부분 중 하나로, 꽤 공격적이고 잠재적으로 복잡합니다. Next.js는 공격적인 기본 캐싱 설정 덕분에 사용자에게 좋은 성능을 제공할 수 있지만, 잘못 설정하면 자충수를 두기 쉽습니다. 발표자는 자신의 Next.js 강의에서 캐싱과 다른 중요한 개념들을 다룬다고 언급합니다. TanStack Start의 경우 훨씬 덜 공격적인 좋은 기본 설정을 제공하며, 가장 중요한 것은 개발 모드와 프로덕션 모드 간에 일관성이 있다는 점입니다. 사용자가 라우트 간을 탐색할 때 일정 기간 데이터를 캐시하여 서버 요청을 줄이고 성능을 향상시킵니다. 다만 최고의 성능을 얻으려면 직접 좋은 캐싱 헤더를 설정하고 애플리케이션 캐싱 전략에 대해 더 생각해야 하지만, 여러 레이어에서 모든 것을 캐싱하려는 Next.js보다 개발자로서 삶이 더 쉬워집니다.

안정성 및 프로덕션 준비도

안정성 측면에서 두 프레임워크 모두 플러스 두 개로 평가됩니다. Next.js는 더 성숙하지만 지난 몇 년간 특히 개발 서버에서 크래시 등 꽤 버그가 많았습니다. 그러나 많이 개선되었고 전반적으로 안정적이며, 수백 수천 개의 프로덕션 애플리케이션이 문제없이 운영되고 있습니다. React 보안 취약점들이 있었지만 이는 주로 Next.js의 문제가 아니며, TanStack Start가 React 서버 컴포넌트를 지원하면 비슷한 문제에 직면할 수 있습니다. TanStack Start는 아직 릴리스 후보 단계이며 이상한 크래시, 에러 메시지, 동작들이 있어서 플러스 하나를 줄 수도 있지만, 릴리스 후보 단계임을 감안하면 꽤 안정적입니다. 발표자는 buildmygraphic.com이라는 프로덕션 애플리케이션을 TanStack Start로 운영하고 있으며 문제없이 실행되고 있다고 언급합니다.

내장 기능 및 배포 옵션

배터리 포함(내장 기능) 측면에서 Next.js가 확실히 우위에 있습니다. Next.js는 최적화된 이미지 컴포넌트와 국제화 지원을 내장하고 있지만 TanStack Start에는 이러한 기능이 없습니다. 물론 서드파티 패키지를 사용할 수 있지만, 내장 기능을 선호한다면 Next.js가 더 나은 선택입니다. 배포 측면에서 Next.js는 Vercel에 배포할 때 매우 쉽고 부드러우며 모든 것이 최적화되어 있습니다. 역사적으로 자체 서버 배포가 어려웠지만, Next.js 팀이 문서를 개선하여 요즘에는 다른 서비스에도 큰 문제 없이 배포할 수 있습니다. TanStack Start의 경우 Cloudflare와 Netlify 같은 공식 지원 파트너들이 있지만, 자체 VPS에 배포하는 문서가 아직 부족하고 따라가기 어렵습니다. 발표자는 BUN으로 VPS에 배포할 때 시간이 걸렸다고 언급하며, 더 나은 가이드와 모범 사례가 필요하다고 지적합니다.

결론 및 최종 의견

발표자는 이 모든 비교가 주관적이고 자신의 경험과 생각일 뿐이라고 다시 한번 강조합니다. 시청자들에게 Next.js와 TanStack Start에 대한 의견, 프레임워크 전환 여부, 어떤 것을 사용하고 있는지 또는 다른 옵션을 사용하는지 댓글로 공유해달라고 요청합니다. 이 비교는 두 프레임워크 모두 장단점이 있으며, 선택은 프로젝트의 요구사항, 팀의 경험, 개발자의 선호도에 따라 달라진다는 것을 보여줍니다. TanStack Start는 더 나은 타입 안정성과 개발자 경험을 제공하지만, Next.js는 더 성숙하고 큰 생태계와 더 나은 AI 지원을 가지고 있어 각각의 사용 사례가 있습니다.

Community Posts

View all posts