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아니면 둘 다 사용하지 않고 다른 옵션을 사용하는지 알려주세요.