00:00:00그래서 V+의 최종 공개 버전은 아마도,
00:00:03뭔가 재미있는 도구처럼 느껴질 거예요.
00:00:06에반 유(Evan Yu)입니다.
00:00:07에반 유 씨입니다.
00:00:09에반 유.
00:00:10에반 유 씨네요!
00:00:10저는 Vue와 Vite를 만들었습니다.
00:00:14지금은 Voice Zero라는 회사를 운영하고 있죠.
00:00:16Vite는 Vite+와 어떻게 다른가요?
00:00:19개발 경험은 지금의 Vite와
00:00:21완전히 똑같을 겁니다.
00:00:22하지만 그 이상의 기능을 원하신다면,
00:00:24끝까지 여러분을 지원해 줄 준비가 되어 있죠.
00:00:26팀과 본인은 AI를 어떻게 활용하시나요?
00:00:28Angular 컴파일러를 Rust로 이식하는 것 같은
00:00:30파격적인 실험을 시작했습니다.
00:00:32React Server Components에 대해 어떻게 생각하세요?
00:00:34저는 처음부터 회의적인 입장이었습니다.
00:00:36보통 팟캐스트를 시작할 때
00:00:39게스트분들께 자기소개를 부탁드리는데요.
00:00:40제 생각엔 이걸 보고 계신 분 중에
00:00:42에반 씨를 모르는 분이 있다면 정말 놀랄 것 같아요.
00:00:44워낙 유명하시니까요.
00:00:46그래도 누구나 알 법하고,
00:00:48대부분의 사람들은 당신이 누구인지 알 겁니다.
00:00:49최소한 Vite나 Vue에 대해서는 확실히 들어보셨겠죠.
00:00:53네, 제가 Vue와 Vite를 만들었습니다.
00:00:57지금은 Voice Zero라는 회사를 운영하며
00:00:59더 많은 오픈 소스 프로젝트를 진행하고 있습니다.
00:01:03Rodeo, Vtest, OXC 등이 있죠.
00:01:07Vue와 Vite가 아마 더 유명하겠지만,
00:01:11Voice Zero에서 작업 중인 다른 프로젝트들도
00:01:14꽤 멋진 것들이 많습니다.
00:01:15Rodeo는 Rust 기반의 번들러이고요.
00:01:18OXC는 파서부터 리졸버, 트랜스포머,
00:01:22미니파이어 등을 모두 포함하는
00:01:25전체 Rust 툴체인입니다.
00:01:28그리고 OXC를 기반으로 OX Lint와 OX Format이 있는데,
00:01:32각각 ESLint와 호환되는 린터이자
00:01:35Prettier와 호환되는 포매터입니다.
00:01:37아직 작업 중인 것들이 더 있지만, 대략 이렇습니다.
00:01:41일단은 오픈 소스 이야기에 집중해 보죠.
00:01:45좋습니다.
00:01:45그렇게 많은 일을 하고 계신데,
00:01:47시간 배분은 어떻게 하시나요?
00:01:50음, 제가 직접 모든 프로젝트의
00:01:52코드를 짜지는 않습니다.
00:01:53사실 회사를 시작한 이후로는
00:01:56코드 작성량이 훨씬 줄었어요.
00:01:58회사에는 저보다 훨씬 Rust를 잘 다루는
00:02:01훌륭한 엔지니어들이 많고,
00:02:03그들은 이제 완전히 AI에 빠져 있거든요.
00:02:05작업의 절반은 그들이, 나머지 절반은 Cursor나 Codex 같은
00:02:10AI가 Rust 코드를 작성하고 있죠.
00:02:12저는 많은 개발자 경험(DX) 관련 의사 결정이나
00:02:17다음에 무엇에 집중할지 결정하는 일을 합니다.
00:02:22다음에 무엇에 집중할지 결정하는 일을 합니다.
00:02:25물론 수익을 낼 수 있는
00:02:28제품으로 어떻게 전환할지도
00:02:31고민해야 할 부분이죠.
00:02:32아직 계속해서 고민 중인 부분이고요.
00:02:34네, 요즘 회사를 운영하기 위해
00:02:39해야 할 모든 일들을 하고 있습니다.
00:02:41새로운 오픈 소스 프로젝트에 대한 아이디어는
00:02:43보통 어디서 얻으시나요?
00:02:45내부적인 필요에 의해 시작했다가
00:02:48다른 사람들의 문제도 해결할 수 있겠다
00:02:49싶어서 만드시는 건가요?
00:02:53사실 모든 건 Vite에서 시작됐습니다.
00:02:56처음 Vite를 만들었을 땐 그냥 취미 삼아 해본 거였어요.
00:03:01프로토타입으로 시작했다가
00:03:03번들러가 필요하다는 걸 깨달았죠.
00:03:07처음에는 번들링하지 않는
00:03:10네이티브 ESM 개발 서버로 시작했어요.
00:03:13간단한 코드에는 그 아이디어가 잘 맞았지만,
00:03:16규모가 큰 라이브러리들을 불러오기 시작하자
00:03:18번들링 없이 모든 의존성을 로드하는 건
00:03:21확장성에 한계가 있다는 걸 알게 됐습니다.
00:03:24예를 들어 파일이 700개나 되는
00:03:26Lodash-es 같은 경우 말이죠.
00:03:28그래서 생각했죠,
00:03:30의존성을 번들링할 무언가가 필요하다고요.
00:03:34당시에는 Rollup, esbuild, Webpack이 있었습니다.
00:03:41Webpack은 ESM을 출력하지 않아서 사용할 수 없었죠.
00:03:47Rollup을 살펴봤는데, 속도가 상당히 느렸어요.
00:03:50esbuild에 비하면 아주 느린 편이었죠.
00:03:53Webpack보다는 빠르지만 esbuild보다는 느렸습니다.
00:03:56그래서 의존성을 미리 번들링하는 데 esbuild를 썼는데,
00:03:59정말 엄청나게 빨랐습니다.
00:04:00그 상태로 소스 코드는 번들링되지 않은 ESM으로 서빙했고
00:04:02그 방식이 잘 통했죠.
00:04:04그런데 프로덕션 환경을 생각하니
00:04:06처음에는 그냥 프로덕션 빌드 전체에
00:04:08esbuild를 써서 번들링하려고 했어요.
00:04:10프로덕션 빌드 전체에 말이죠.
00:04:11그런데 esbuild는 청크를 어떻게 나눌지에 대한
00:04:14제어권이 매우 제한적이었습니다.
00:04:17대규모 애플리케이션을 빌드할 때는 청크 제어가 꼭 필요합니다.
00:04:19예를 들어 라이브러리 의존성들은
00:04:21캐싱 효율을 높이기 위해
00:04:24별도의 벤더 청크에 넣고 싶을 수 있잖아요.
00:04:26이 청크는 절대 바뀌지 않았으면 좋겠다거나,
00:04:28일관된 해시값을 갖길 원하죠.
00:04:32내 소스 코드를 수정하더라도
00:04:33해당 청크의 해시는 그대로 유지되어야 합니다.
00:04:35그래야 사용자가 웹사이트를 재방문했을 때
00:04:38캐시된 청크를 그대로 쓸 수 있으니까요.
00:04:39이런 종류의 최적화 기능들을
00:04:41esbuild는 전혀 허용하지 않았습니다.
00:04:44기본으로 정해진 청크 분할 방식
00:04:47하나뿐이었죠.
00:04:49플러그인 시스템도 유연하지 않았어요.
00:04:53한 플러그인이 특정 파일을 처리하겠다고
00:04:56결정하면 그걸로 끝입니다.
00:04:59다른 플러그인은 그 파일에 손을 댈 수 없었죠.
00:05:02반면 저희는 Rollup을 많이 사용해 왔고,
00:05:05Rollup의 플러그인 시스템에 익숙했습니다.
00:05:08그래서 결국 내린 결론은,
00:05:10프로덕션 번들링에는 Rollup을 쓰고
00:05:13개발 환경의 프리번들링에는 esbuild를 쓰는 거였죠.
00:05:15각자의 장점을
00:05:20조합해서 사용하는 식이었습니다.
00:05:23사실 오늘날의 Vite 7도 여전히
00:05:26이 조합을 기반으로 하고 있습니다.
00:05:27많은 사람에게 꽤 잘 작동하고 있죠.
00:05:31하지만 당연히 문제는 있습니다. esbuild는 Go로,
00:05:35Rollup은 JavaScript로 작성되었다는 점이죠.
00:05:40이는 프로덕션 빌드 속도가
00:05:41RSPack 같은 완전 Rust 기반
00:05:43번들러에 비해 여전히 상당히 느리다는 걸 의미합니다.
00:05:47개발 서버 측면에서도 esbuild와
00:05:52Rollup은 플러그인 시스템이 서로 다르죠.
00:05:55개발 중에는 동일한 플러그인 세트를
00:05:57의존성에 적용할 수 없는데,
00:05:59프로덕션 빌드 중에는 그 의존성들에
00:06:01플러그인이 적용됩니다.
00:06:03또한 미묘한 상호운용성 동작 차이도 있어요.
00:06:07ESM과 CJS가 섞인 그래프를 처리할 때
00:06:10esbuild와 Rollup의 처리 방식이 조금 다릅니다.
00:06:13트리 쉐이킹 동작에도 차이가 있고요.
00:06:15물론 둘 다 잘 작동하긴 하지만,
00:06:18저희가 이런 동작 불일치를
00:06:22일일이 보정해 왔습니다.
00:06:22어떻게든 돌아가게 만들었지만, 속으로는 알고 있었죠.
00:06:25서로 다른 두 도구를
00:06:29억지로 이어 붙여 놓은 상태라는 걸요.
00:06:31그래서 프로덕션 빌드를 더 빠르게 만들고
00:06:35개발과 프로덕션 빌드의 일관성을 높이기 위한 최선은,
00:06:40두 역할을 모두 수행하는 하나의 번들러를 갖는 것입니다.
00:06:42두 역할을 모두 수행하는 하나의 번들러를 갖는 것입니다.
00:06:44하지만 문제는 esbuild가 빠르긴 해도
00:06:47확장성이 그리 좋지 않다는 거였습니다.
00:06:50코드베이스가 전부 Go로 되어 있으니까요.
00:06:54esbuild를 만든 에반 월리스(Evan Wallace) 씨는
00:06:57분명 천재적인 괴짜 엔지니어이고
00:06:59esbuild를 믿을 수 없을 정도로 빠르게 만들었지만,
00:07:02다른 사람들이 기능을 확장하거나
00:07:05포크를 해서 쓰거나,
00:07:07그 위에 레이어를 얹어 관리하기에 적합한 구조는 아니었습니다.
00:07:10그게 쉽지 않은 일이죠.
00:07:12또한 에반 월리스 씨가 하기 싫어하는 일을
00:07:15설득해서 하게 만드는 것도 정말 어렵습니다.
00:07:17그는 돈이 필요한 것도 아니고 상관하지 않거든요.
00:07:21그래서 생각했죠. 그럼 Rollup은 어떨까?
00:07:27Rollup을 더 빠르게 만들 순 없을까?
00:07:28몇 가지 실험이 있었지만,
00:07:30근본적으로 Rollup은 JavaScript로 작성되었고
00:07:33싱글 스레드로 작동합니다.
00:07:36워커 풀을 쓰거나 워커에서 플러그인을 돌려보기도 했죠.
00:07:41Rollup 메인테이너는 Rust 기반 파서인
00:07:47SWC 파서를 도입해보려고도 했고요.
00:07:50하지만 성능 향상이 눈에 띄지 않았는데,
00:07:54Rust와 JS가 혼재된 시스템에서는
00:07:57데이터 전달 비용이 발생하기 때문입니다.
00:07:59거대한 문자열 덩어리를 앞뒤로 계속 주고받아야 하니까요.
00:08:02메모리를 복사해야 하는 상황이면 더 느려집니다.
00:08:05결국 파서만 Rust로 바꾸고
00:08:09나머지는 모두 JavaScript인 구조에서는,
00:08:12Rust로 얻은 순수 성능 이득이
00:08:13데이터 전달 비용 때문에 상쇄되어 버립니다.
00:08:16그래서 결국 성능이 거의 비슷하게 나왔죠.
00:08:19그래서 Rollup을 획기적으로 빠르게 만드는 건
00:08:23기술적으로 불가능하다는 결론을 내렸습니다.
00:08:26결국 남은 유일한 선택지는 새로 만드는 것이었죠.
00:08:30Vite에 최적화되어 있으면서도
00:08:33엄청나게 빠른 번들러를 처음부터 다시 쓰는 겁니다.
00:08:37그렇게 무엇을 해야 할지 고민하는
00:08:40기나긴 여정이 시작되었습니다.
00:08:42저희가 내린 결정은 근본적으로,
00:08:44원래 아이디어는 Rollup을 Rust로 포크하는 거였어요.
00:08:48포크가 아니라 이식(porting)이죠.
00:08:49Rollup을 Rust로 이식하고 싶었습니다.
00:08:51그래서 프로젝트 이름이 Rolldown인 거예요.
00:08:53Rollup, Rolldown 이런 식이죠.
00:08:54직접적인 이식으로 시작했지만,
00:08:58JavaScript로 작성된 코드를
00:09:02Rust로 직접 옮기는 게 쉽지 않다는 걸 깨달았습니다.
00:09:06JavaScript는 매우 동적인 언어이기 때문이죠.
00:09:08동적인 언어잖아요.
00:09:11TypeScript를 쓴다고 해도
00:09:13원하는 만큼 값을 변경하고 수정할 수 있습니다.
00:09:16하지만 Rust는 메모리에 대해 매우 엄격합니다.
00:09:19라이프사이클, 소유권 등에 아주 까다롭죠.
00:09:23그래서 JavaScript와는
00:09:25완전히 다른 구조로 설계해야 합니다.
00:09:27기존 JavaScript 코드를
00:09:29Rust 같은 언어로 직접 이식하는 건
00:09:31절대 순탄할 수 없습니다.
00:09:33거의 새로 쓰는 것이나 다름없죠.
00:09:35그리고 저희는 사실,
00:09:37양쪽의 장점을 모두 취하고 싶었습니다.
00:09:42Rollup 자체는 꽤 가벼운 핵심 기능을 가졌습니다.
00:09:45그래서 Rollup을
00:09:47프로덕션에서 바로 쓸 수 있는 설정으로 만들려면,
00:09:49사실 꽤 복잡한 작업이 필요합니다.
00:09:51노드 리졸버 플러그인 같은 게 필요하거든요.
00:09:54노드 모듈을 해석하는 건 내장 기능이 아니니까요.
00:09:56플러그인으로 추가해야 합니다.
00:09:58Rollup 코어는 ESM 전용이라 CommonJS 모듈을 지원하려면
00:10:03CommonJS 플러그인도 추가해야 하고요.
00:10:06그리고 define, inject, replace 같은
00:10:10수많은 플러그인을 더해야 합니다.
00:10:14이런 기능들 중 상당수는 esbuild에는 내장되어 있지만,
00:10:17Rollup에서는 플러그인이 필요합니다.
00:10:20더 나쁜 건 JavaScript 진영의 이런 플러그인 대부분이
00:10:25매번 전체 AST 파싱, 변환, 코드 생성을 거치도록 구현되어 있다는 겁니다.
00:10:30그래서 모든 플러그인이 실제로
00:10:33이전 플러그인에서 받은 코드를 가져와
00:10:36다시 파싱하고, 변환하고,
00:10:38새 코드를 만들고 소스 맵을 생성하는 과정을 반복하죠.
00:10:41그런 다음 그 소스 맵들을 모두 하나로 합쳐야 합니다.
00:10:43이게 JavaScript 빌드 시스템이 점점 느려지는 이유입니다.
00:10:46모든 플러그인이 이 과정을 계속 반복하니까요.
00:10:49그래서 이런 기능들을 내장할 필요가 있다고 생각했습니다.
00:10:53결국 esbuild의 범위를 가지면서도
00:10:56Rollup의 API 형태를 갖춘 것이 바로 Rolldown입니다.
00:11:01그런데 Rolldown을 만들려면
00:11:03파서도 필요하고 각종 변환 도구들도 필요했죠.
00:11:07미니파이어와 리졸버도 필요했고요.
00:11:10그걸 어디서 구할 수 있을까요?
00:11:12거기서 OXC가 등장합니다.
00:11:14OXC는 이 모든 걸 제공하는
00:11:17저수준 언어 툴체인 세트입니다.
00:11:20OXC 개발자는 당시에 바이트댄스(ByteDance)에서 일하고 있었고
00:11:25저는 오랫동안 그 프로젝트를 눈여겨보고 있었습니다.
00:11:28보르신(Borshin)이라는 친구인데 그가 OXC를 만들었죠.
00:11:30지금은 Voice Zero의 엔지니어링 부사장입니다.
00:11:33제가 회사를 세웠을 때 바로 합류한 건 아니었어요.
00:11:36계속 영입하려고 제안했지만 그는
00:11:38잘 모르겠다며 망설였죠.
00:11:39하지만 저희는 어쨌든 OXC 위에 Rolldown을 구축하기 시작했습니다.
00:11:44이건 정말 훌륭한 결과물이니까요.
00:11:45저는 확신했습니다.
00:11:47가능한 모든 옵션을 다 검토해 봤거든요.
00:11:51조립이 가능한 구조를 원했습니다.
00:11:54툴체인의 각 부분이
00:11:57개별 크레이트(crate)로 사용될 수 있기를 바랐죠.
00:12:00또한 극도로 빠르기를 원했고요.
00:12:03그래서 OXC와 SWC를 비교해 봤습니다.
00:12:06OXC 파서는 SWC 파서보다 3배 정도 더 빠른데,
00:12:09둘 다 Rust로 작성되었음에도 불구하고 말이죠.
00:12:12설계상의 결정들과
00:12:15저수준 기술 사양들에서
00:12:18이런 성능 차이가 발생했습니다.
00:12:20주된 이유는 보르신이 저희 회사에 오기 전부터
00:12:24파서와 링킹 성능에 집착해 왔기 때문입니다.
00:12:27대부분의 시간을 거기에 쏟았죠.
00:12:30예를 들어,
00:12:32OXC는 아레나 할당기(arena allocator)라는 걸 사용하는데,
00:12:34이는 AST를 위한 모든 메모리 할당을
00:12:39연속된 메모리 청크에 배치합니다.
00:12:41메모리를 커다란 덩어리로 한 번에 할당하고
00:12:43거기에 AST를 직접 넣는 거죠.
00:12:45덕분에 메모리를 해제하는 시간이 더 빨라집니다.
00:12:50또한 OX Lint에서 빠른 JS 플러그인을 구현할 때
00:12:53흥미로운 가능성들을 열어주었죠.
00:12:57일관된 메모리 구조 덕분에
00:12:59복사 과정 없이 메모리 청크 전체를 JavaScript로 전달하고
00:13:01JS 쪽에서 바로 역직렬화할 수 있게 해줍니다.
00:13:05장점이 정말 많았습니다.
00:13:06당시 그 프로젝트를 보며
00:13:10정말 깊은 인상을 받았고,
00:13:10그 위에 Rolldown을 짓기로 결정하면서
00:13:13결국 보르신을 설득해 합류시켰습니다.
00:13:16이제 회사의 사업 범위는 실질적으로
00:13:21파서에서 시작되는
00:13:24수직적인 Rust 스택을 갖추게 되었습니다.
00:13:26번들링과 Vite를 거쳐
00:13:29린터, 포매터, 테스트 러너까지 모두 다루게 된 거죠.
00:13:33전체 툴체인을 갖춘 셈입니다.
00:13:34저희가 다음에 할 일은,
00:13:37사실 꽤 오랫동안 작업해 온 것인데,
00:13:40이 모든 것들을 하나의 일관된 패키지로 묶어
00:13:43기본 앱을 실행하기 위해 5개의 개별 도구를
00:13:47따로 설치하지 않아도 되게 만드는 겁니다.
00:13:50또한 대여섯 개의
00:13:51서로 다른 설정 파일도 필요 없게 만들 거예요.
00:13:55그냥 하나의 설정 파일로 통합하고,
00:13:57동일한 파서와 동일한 변환 파이프라인,
00:13:59동일한 리졸버를 기반으로 하기 때문에
00:14:02모든 도구가 완벽하게 연동되는 것을 보장합니다.
00:14:05예기치 못한 오류가 없을 거예요.
00:14:07예를 들어 Webpack과 Jest를 같이 쓰면
00:14:10서로 다른 리졸버를 사용하기 때문에
00:14:14경로 해석 로직을 각각 따로 설정해 줘야 하죠.
00:14:16그래서 저희의 비전은 정말 명확합니다.
00:14:19어디서나 일관되게 작동하는
00:14:22수직 통합 스택을 구축하는 것이죠.
00:14:25개발 경험을 최대한 단순하고
00:14:29빠르게 만드는 겁니다.
00:14:30성능은 아주 중요한 요소죠.
00:14:32저는 당연한 것으로 생각했지만,
00:14:34아마 트위터에서 Rolldown이
00:14:39Rollup보다 20배 빠르다는 글을 보셨을 거예요.
00:14:43OX Lint는 ESLint보다 50~100배 더 빠르고요.
00:14:47OX Format은 Prettier보다 30~40배 더 빠릅니다.
00:14:51저희 목표는 호환성을 갖춰서
00:14:57대규모 리팩토링 없이도 쉽게 옮겨올 수 있게 하는 동시에,
00:15:00엄청난 성능 향상을 누릴 수 있게 하는 것입니다.
00:15:04이제 테스트 루프, 린트 체크를 비롯한
00:15:08모든 과정이 훨씬 빠르고 매끄러워질 거예요.
00:15:12그러면 사람들이 더 많은 앱을
00:15:15더 빠르게 개발할 수 있게 되겠죠.
00:15:17와, 처음에 Vue를 위한 빌드 도구가 필요하다는 생각에서 시작해
00:15:20이 부분도 개선하고 싶고 저 부분도 개선하고 싶다며
00:15:22점점 확장되는 과정이 정말 놀랍네요.
00:15:24말씀하신 대로 전체 수직 스택을
00:15:25완전히 장악하고 계시는군요.
00:15:27정말 인상적이고 빌드 속도도 엄청 빠르네요.
00:15:29정말 인상적이고 빌드 속도도 엄청 빠르네요.
00:15:32시작하기 전에 동료들에게도 이야기했는데,
00:15:33이전 직장에서 맡았던
00:15:35오래된 프로젝트 하나는
00:15:37Webpack을 썼는데 빌드에 50분이나 걸렸거든요.
00:15:40뭐가 문제인지조차 알 수 없을 정도였죠.
00:15:42그래서 제가 가서 가장 먼저 한 말이
00:15:43당장 Vue로 바꿔야 한다는 거였어요.
00:15:46CSS 하나만 바꿔도
00:15:47다시 빌드되는 걸 보려고 2분을 기다려야 했거든요.
00:15:49정말 말도 안 되는 상황이었죠.
00:15:49HMR(Hot Module Replacement)이 꼭 필요했습니다.
00:15:52파일을 저장하면 바로 반영되어야 하니까요.
00:15:54Vue가 그런 부분에서 확실히 큰 도움이 됐죠.
00:15:57Vue가 성장하고 자리 잡는 속도가
00:15:59정말 경이롭다고 생각합니다.
00:16:02매달 NPM 다운로드 수가
00:16:052억 건이 넘는다는 기사를 본 것 같은데 정말 엄청나네요.
00:16:07정말 엄청나네요.
00:16:09네,
00:16:10얼마 전에 주간 다운로드 5,000만 건을 돌파했습니다.
00:16:13정말 상상이 안 가는 숫자네요.
00:16:15그 5,000만 건이라는 숫자에는
00:16:19요즘 유행하는 AI 기반 코딩 앱들로 인한
00:16:21어느 정도의 거품이 껴 있을 수도 있어요.
00:16:23그냥 한번 만들고 버려지는 일회성 앱들 말이죠.
00:16:26그래도 여전히 수많은 사람이나
00:16:29AI 에이전트들이 활발하게 쓰고 있다는 증거겠죠.
00:16:33사실 Betaslack의 엔지니어링 팀도
00:16:34Vue의 열렬한 팬입니다.
00:16:36백엔드는 Rails를 쓰고 프론트엔드에 Vue를 사용하거든요.
00:16:40팟캐스트를 진행하면서 대화 흐름에 맞춰
00:16:42그들이 궁금해하는 질문들을 몇 가지 드려볼게요.
00:16:46방금 번들링에 대해 언급하셨는데
00:16:48그들의 질문 중 하나가,
00:16:49Rails에서 임포트 맵(import maps)을 사용하고 있기 때문에,
00:16:52번들링의 미래를 어떻게 보시는지였습니다.
00:16:54임포트 맵을 쓰면 번들링할 일이
00:16:56별로 없으니까요.
00:16:57앞으로 어떻게 변할까요?
00:17:00사실 Rolldown 문서에도
00:17:02관련된 전용 페이지가 있습니다.
00:17:04제목이
00:17:07"왜 아직도 번들러가 필요한가?"예요.
00:17:10혹시 평소에 이 질문을 많이 받으시나요?
00:17:13네, DHH(데이비드 하이네마이어 핸슨) 씨도
00:17:16번들링과 빌드가 필요 없다는 주장을 아주 강력하게 하시죠.
00:17:18그래서 저도 신경을 쓰지 않을 수 없었습니다.
00:17:20임포트 맵이 어느 정도까지는 잘 작동하지만,
00:17:24번들링 없는 개발은 보통
00:17:29특정 규모까지만 유효한 개념입니다.
00:17:35앱의 모듈 수가 1,000개 미만이라면
00:17:39전체 모듈 그래프가 로드되는 데
00:17:41수백 밀리초 정도밖에 안 걸릴 테니
00:17:43전혀 문제가 없죠.
00:17:45그 정도 제약 조건 안에서 작업하신다면
00:17:48그건 사실 아주 훌륭한 방식입니다.
00:17:50기본적으로 지연 로딩 방식이라,
00:17:53앱의 규모가 크더라도
00:17:56각 페이지가 독립적이고
00:17:58하위 모듈 그래프를 가진다면 잘 작동하죠.
00:18:00Vite가 개발 환경에서 잘 작동하는 이유이기도 하고요.
00:18:01하지만 이게 만능 해결책은 아닙니다.
00:18:05Vite를 통해 확인한 사실이자
00:18:07저희가 Rolldown에서
00:18:09"풀 번들 모드"를 개발하고 있는 이유는,
00:18:12번들링하지 않는 방식에는 한계가 있기 때문입니다.
00:18:15결국 병목 지점은 모듈의 개수가 되거든요.
00:18:18수많은 애플리케이션이
00:18:21개발 단계에서 수천 개의
00:18:25모듈을 불러오고 있습니다.
00:18:293,000개 정도의 모듈을 불러오게 되면
00:18:32브라우저에 과부하가 걸리기 시작하죠.
00:18:33네트워크 수준에서 병목이 발생하는데,
00:18:36네이티브 ESM 환경에서는
00:18:38모든 개별 모듈마다 HTTP 요청을 보내야 하기 때문입니다.
00:18:40모듈 임포트 깊이가 깊다면,
00:18:44첫 번째 모듈을 가져온 뒤에야
00:18:46추가로 필요한 모듈이 무엇인지 알게 되고
00:18:49다시 그 모듈들을 요청하게 되죠.
00:18:52이런 식으로 계속 꼬리에 꼬리를 물고,
00:18:53전체 그래프를 다 훑어야만
00:18:54비로소 첫 번째 모듈을 실행할 수 있게 됩니다.
00:18:57따라서 네트워크 상태가 좋지 않다면,
00:19:00화면에 무언가를 띄우기도 전에
00:19:04수많은 네트워크 왕복이 발생할 수밖에 없습니다.
00:19:06모듈이 수천 개라면 상황은 더 심각해지겠죠.
00:19:09로컬 개발 환경의 Vite 서버에서도
00:19:13모듈이 3,000개를 넘어가면
00:19:17로딩하는 데 1~2초는 족히 걸립니다.
00:19:20그러니 프로덕션 네트워크 환경에서
00:19:23어떤 일이 벌어질지 상상해 보세요.
00:19:27번들링을 했다면
00:19:29아마 100밀리초 정도면 끝났을 일이죠.
00:19:31규모가 일정 수준을 넘어서면
00:19:35번들링은 반드시 챙겨야 할
00:19:38가장 손쉬운 최적화 수단입니다.
00:19:40번들링과 빌드 도구를 아예 피하려는 주된 이유는
00:19:41사람들이 도구 설정에 지쳤기 때문이라고 생각해요.
00:19:45버그를 만나거나 해결하기 힘든
00:19:47설정 문제에 부딪혔던 경험이 많으니까요.
00:19:52Webpack이 설정을 너무 복잡하게 만들었기 때문에
00:19:55다들 번들러 설정이라고 하면
00:19:56자기가 할 일이 아니라고 생각하고 피하고 싶어 하죠.
00:20:01사람들은 '빌드 단계'라는 말만 들어도
00:20:04거부감을 느끼고 피하려 합니다.
00:20:06그래서 저희가 새로운 도구들로 하고 싶은 건,
00:20:08이런 개념들을 아주 명확하고 단순하게 만드는 것입니다.
00:20:11물론 크고 복잡한 앱에서는
00:20:14절대 단순할 수 없겠지만요.
00:20:16하지만 새로 시작하는 앱이라면
00:20:19너무 많이 고민하지 않아도 될 만큼
00:20:22충분히 단순하게 만들고 싶습니다.
00:20:24그냥 Vite로 앱을 띄우면 모든 게 잘 될 거라는
00:20:28믿음을 주고 싶어요.
00:20:32실제로 Ruby Vite나 Vite Rails 같은
00:20:34커뮤니티 프로젝트들이
00:20:37Rails에서 Vite가 잘 작동하도록 돕고 있죠.
00:20:41빌드 없는 설정도 분명 장점이 있습니다.
00:20:45복잡한 의존성이나
00:20:48시스템을 망가뜨릴 수 있는 불확실성을 피할 수 있으니까요.
00:20:50빌드 시스템에 대한 신뢰를 잃은 분들도 많을 거예요.
00:20:55의존성을 업그레이드할 때마다 빌드가 깨지곤 하니
00:20:59그 모든 걸 아예 피하고 싶어지는 게 당연하죠.
00:21:05하지만 결국 좋은 기술과 안정성이 뒷받침된다면,
00:21:12언제나 사용자에게 최상의 UX를 제공하고 싶어 할 겁니다.
00:21:14완전한 비번들링 방식은 애플리케이션 크기에 대해
00:21:17매우 엄격한 제약을 감수해야 한다는 뜻입니다.
00:21:20최적화에 대해서도 계속 고민해야 하죠.
00:21:23특정 페이지를 방문할 때
00:21:26실수로 너무 많은 모듈을 가져오지는 않는지,
00:21:29모듈 캐싱을 어떻게 영리하게 할지 같은 것들이요.
00:21:33심지어 번들링하지 않는 Rails에서도,
00:21:36모듈이 제대로 캐싱되도록 스탬핑하는
00:21:37일종의 전처리 단계가 필요할 겁니다.
00:21:41결국 제대로 작동시키려면
00:21:45어떤 식으로든 최적화에 신경을 써야 한다는 거죠.
00:21:48이 방식이 꽤 많은 사례에서 잘 작동하겠지만,
00:21:52모든 사용 사례를 다 커버할 수는 없습니다.
00:21:54어떤 사람들은 정말 거대한 앱을 만드니까요.
00:21:57기능이 정말 많은 앱들 말이죠.
00:22:01그런 분들에게 무조건 번들링하지 말라고 강요해서
00:22:03성능을 최적화할 수 없는 막다른 길로 몰아넣을 수는 없죠.
00:22:06아직 잘 모르시는 분들을 위해,
00:22:08Vite와 Vite+는 어떻게 다른가요?
00:22:11그리고 사용자들은 거기서 무엇을 얻을 수 있나요?
00:22:15Vite+는 현재 그 정체성에 대해
00:22:18약간의 피벗과 정제 과정을 거치고 있습니다.
00:22:21핵심 아이디어는 이겁니다. 만약 누군가
00:22:24JavaScript 개발을 완전히 처음 시작한다고 해보죠.
00:22:29아무것도 설치되지 않은 새 컴퓨터를 가지고 있을 때,
00:22:31HMR과 각종 모범 사례,
00:22:35린트, 포맷팅, 테스트까지 완벽하게 세팅된 앱을
00:22:37어떻게 하면 가장 빠르게 만들 수 있을까요?
00:22:39지금은 배워야 할 게 너무 많습니다.
00:22:42가장 먼저 배워야 할 것이,
00:22:45Node.js가 무엇인지부터죠.
00:22:49어떻게 설치하는지,
00:22:54노드 버전 매니저는 무엇인지,
00:22:57패키지 매니저와 빌드 도구는 뭘 써야 하는지,
00:23:02린터는 또 뭘 써야 하는지까지.
00:23:06이 모든 질문에 답을 해야 합니다.
00:23:11저희는 그 모든 질문 과정을 없애고 싶습니다.
00:23:14아주 탄탄한 시작점을 제공해 드리는 거죠.
00:23:17심지어 Node.js를 직접 설치할 필요도 없게요.
00:23:21저희가 실험하고 있는 새로운 Vite+ 사용 방식은
00:23:25curl 명령어로 스크립트를 실행해 설치하는 겁니다.
00:23:28curl -s [https://vplus.dev/install](https://www.google.com/search?q=https://vplus.dev/install) | bash 처럼요.
00:23:33그러고 나서 'vp new'로 새 프로젝트를 만들고
00:23:36'vp dev'만 입력하면
00:23:38필요한 모든 환경이 완벽하게 갖춰집니다.
00:23:39린터, 포매터, 테스트 러너, 번들러까지 다 있죠.
00:23:40모노레포 구조를 잡는 데도 쓸 수 있고요.
00:23:42라이브러리 번들링 기능도 포함되어 있습니다.
00:23:44lint-staged 같은 기능이나
00:23:45변경 이력(changelog) 관리 기능도 추가할 계획입니다.
00:23:47대규모 모노레포 라이브러리를 운영할 때 유용하겠죠.
00:23:49또한 'vp run'이라는 도구도 있는데,
00:23:50pnpm run과 비슷하지만
00:23:52훨씬 정교한 실행 도구입니다.
00:23:54Nx처럼 작업들 간의 올바른
00:23:57실행 순서를 파악하고
00:23:59영리하게 캐싱까지 해주죠.
00:24:03물론 이건 선택 사항입니다.
00:24:08이런 추가 기능들이 필요 없다면
00:24:15그냥 일반 Vite처럼 쓰시면 됩니다.
00:24:17개발 경험은 지금의
00:24:21Vite와 완벽하게 똑같을 거예요.
00:24:25하지만 더 나아가서
00:24:28엔터프라이즈급 모노레포로 확장하고 싶을 때도
00:24:31Vite+가 끝까지 함께해 줄 겁니다.
00:24:32이미 실무에서 검증된
00:24:39기술들을 기반으로 만들어졌으니까요.
00:24:41그게 저희가 선사하고 싶은 가치입니다.
00:24:44기존의 많은 사용자를
00:24:49저희 오픈 소스 생태계로 끌어오고 있죠.
00:24:52Webpack에서 Vite로,
00:24:57ESLint에서 OX Lint로 넘어오고 계세요.
00:24:59Vite+가 추구하는 역할은,
00:25:03JavaScript에 갓 입문한 분들이
00:25:04"이제 뭘 해야 하지?"라고 물을 때
00:25:07가장 빠르고 간단한 해답을 드리는 것입니다.
00:25:11그 질문에 답하는 동시에
00:25:13AI와도 아주 잘 어우러지게 만들고 싶습니다.
00:25:17회사의 목표가 무엇인지 궁금하네요.
00:25:18오픈 소스 프로젝트 뒤에 영리 기업이 있으면
00:25:20특정 기능을 유료화할까 봐 걱정하는 분들이 많잖아요.
00:25:24그런데 당신이 늘 그래왔듯,
00:25:27Vite+가 해주는 일을 사용자가 직접 할 수도 있잖아요.
00:25:31설정이 아주 복잡하겠지만요.
00:25:33그러니까 Vite+는 일종의 편의성을 제공하며
00:25:35하나로 묶어주는 패키지 같은 거군요.
00:25:39그럼 기능을 유료로 제한할 일은 없겠네요?
00:25:44네, 저희가 Vite+의 라이선스에 대해
00:25:47잠시 언급했던 적이 있죠.
00:25:48회사가 일정 규모 이상이면
00:25:52비용을 지불해야 한다는 식으로요.
00:25:54그 생각은 계속 발전하고 있는데,
00:25:57많은 관심 기업들과 대화하며
00:26:00더 많은 사람에게 가치를 전달하면서도
00:26:02우리가 가치를 창출하고 지속 가능성을
00:26:05확보할 수 있는 접점이 어디일지 고민하고 있습니다.
00:26:07유료화 기준이 되는 기업 규모를 훨씬 더 높일 생각이에요.
00:26:11그래서 아주 일부의 기업들만
00:26:14비용을 지불하게 될 겁니다.
00:26:15대부분의 사용자는 그냥 무료로 즐길 수 있게 될 것이고,
00:26:17또한 저희는 단순히
00:26:20기능을 파는 게 아니라 서비스 형태의 모델을 구상 중입니다.
00:26:23Vite+와 연동되어
00:26:25코드 품질을 개선하고 모니터링하며
00:26:26팁이나 아이디어를 제공해서
00:26:29코드를 더 좋게 만들도록 돕는 서비스 말이죠.
00:26:31저희가 가진 도메인 지식을
00:26:34AI 에이전트를 통해 확장성 있게 제공하려 합니다.
00:26:37그쪽 방향으로 활발히 탐색하고 있습니다.
00:26:39그렇군요. 궁금한 게 하나 더 있는데,
00:26:41Vite+가 모든 걸 편리하게 만들어주는 것처럼
00:26:44AI가 기존 솔루션들로도 충분히 그런 일을 할 수 있지 않을까요?
00:26:46혹시 AI에게 린터나 빌드 환경 등
00:26:50전체 포맷을 구성해달라고 시켜본 적이 있으신지,
00:26:53아니면 AI가 학습 데이터 때문에 낡은 기술에만 의존해서
00:26:56코드를 엉망으로 만들 수도 있다고 보시는지 궁금합니다.
00:27:00실제로 AI가 생성한 앱들을 보면
00:27:02여전히 Vite 6 같은 걸 쓰는 경우가 많아요.
00:27:07저희가 새 버전을 출시하고
00:27:11새 기능을 내놓으면 모델이 그 데이터를 학습하는 데
00:27:14시간이 걸리기 때문이죠.
00:27:17모델은 언제나 최신 뉴스나 기술보다 뒤처질 수밖에 없습니다.
00:27:20그래서 저희가 하려는 것 중 하나가,
00:27:25Vite+ 새 버전을 출시할 때
00:27:27그에 맞는 에이전트 스타일의 안내 지침과 기술들을 함께 제공하는 겁니다.
00:27:31Vite+를 업그레이드하면
00:27:35관련된 에이전트의 지침 파일도 자동으로 업데이트되고,
00:27:37NPM 패키지에 포함된
00:27:39최신 기술들과 연결되도록 하는 거죠.
00:27:41또한 특정 버전에서 다른 버전으로
00:27:44업그레이드하고 싶을 때 도움이 되는
00:27:48프롬프트를 제공해서 에이전트가 더 매끄럽게 처리하게 할 수도 있고요.
00:27:51이런 역할은 도구 제작자들이
00:27:53직접 맡아야 한다고 봅니다.
00:27:56저희가 OX Lint와 OX Format, Vtest를
00:28:00OpenClaw라는 프로젝트에서 사용 중인 걸 봤는데,
00:28:02정말 어마어마한 코드베이스더군요.
00:28:05JavaScript로만 5만 4천 줄에 달하고
00:28:07변화 속도도 엄청나게 빠르죠.
00:28:09심지어 작성자가 코드를 제대로 읽지도 않고 머지하고 있어요.
00:28:13말도 안 되는 코드들이
00:28:17정말 많이 들어있습니다.
00:28:20OX Lint를 도입하거나
00:28:26업그레이드하려는 몇몇 PR을 살펴보면,
00:28:29존재하지도 않는 옵션을 있는 것처럼 꾸며내기도 하더라고요.
00:28:31저희는 "이런 옵션 없는데?"라며 당황했죠.
00:28:34타입 체크 과정에서도
00:28:37그냥 대충 넘어가는 식이었습니다.
00:28:41"그냥 이 규칙 꺼버려야지, 그럼 타입 통과되겠지."
00:28:44가이드라인을 주지 않으면
00:28:47AI는 이런 식으로 지름길만 택하려 합니다.
00:28:50더 중요한 사실은 OpenClaw를 만든 피터는
00:28:54애초에 TypeScript 개발자가 아니라는 점이에요.
00:28:58그냥 어쩌다 보니 TypeScript를 선택해 개발 중인 거죠.
00:29:00도구 활용 전문가도 아니고
00:29:05이 분야에 경험이 많은 것도 아닙니다.
00:29:08AI가 그를 도와줬을 뿐이죠.
00:29:10하지만 AI가 사용하는 도구를 만드는 저희 입장에선
00:29:13어디서 부족함이 생기는지 명확히 보입니다.
00:29:17저희가 그런 점들을 지적해주지 않고
00:29:19이런 식으로 계속 방치한다면
00:29:22그 코드는 석 달 안에 무너질 거예요.
00:29:26그래서 AI 시대에 저희가
00:29:29제공할 수 있는 가치는 이렇습니다.
00:29:31무언가 망가뜨리지 않으면서도
00:29:34어떻게 빠르게 결과물을 낼 것인가?
00:29:36AI와 함께 어떻게 빠른 개발 속도를 유지할 것인가?
00:29:40에이전트 덕분에 코드 배포 속도는
00:29:43엄청나게 빨라지고 있습니다.
00:29:45사람보다 훨씬 더 많은 기능을 쏟아낼 수 있죠.
00:29:46하지만 그 기능들이 제대로 검토되었을까요?
00:29:51하루에 20개의 PR을 머지할 때
00:29:54코드베이스가 예전처럼
00:29:57제대로 관리되고 있을까요?
00:29:59코드의 건강 상태가 매우 불안정해질 수 있습니다.
00:30:00그래서 사람이 개발할 때처럼
00:30:04주기적으로 점검하는 과정이 필요합니다.
00:30:06한동안 기능을 마구 쏟아냈다면
00:30:07잠시 멈추고 생각해야 하죠.
00:30:09"좋아, 이제 정리가 필요해."
00:30:12"쌓여있는 기술 부채를 해결해야겠어."
00:30:15AI 에이전트로 인해 개발 속도가 빨라진 만큼
00:30:18기술 부채도 훨씬 빨리 쌓이고 있습니다.
00:30:20그 부채를 갚는 데도 다시 AI를 활용해야 하죠.
00:30:22사람들이 간과하고 있지만
00:30:25현재 정말 해결이 필요한 부분이라고 생각합니다.
00:30:26네, 저도 말씀하신 OpenClaw 코드베이스를 봤는데
00:30:29정말 혼란스럽더라고요.
00:30:30아무런 감독 없이 AI를 그냥 풀어두면
00:30:35어떤 일이 벌어지는지 보여주는
00:30:38정말 좋은 사례인 것 같습니다.
00:30:41지난 몇 주 동안 인터넷에서 화제가 된 걸 보며
00:30:44참 흥미로웠어요.
00:30:46그리고 AI의 역할에 대해 질문 하나 더 드리자면,
00:30:50AI 에이전트가 더 잘 쓸 수 있도록 포매터나
00:30:54린터를 만드는 방식 자체를 바꾸기도 하시나요?
00:30:58그게 미래를 결정하게 될까요?
00:30:59아니면 포매터와 린터를 단지 빠르게 만든 것 자체가
00:31:03AI 시대에 큰 도움이 되고 있다고 보시나요?
00:31:06빠르니까 AI 에이전트들이 쓰기에 좋을 테니까요.
00:31:11그건 분명히 고민해 볼 만한 주제입니다.
00:31:14저희도 실제로 그 문제를 생각하기 시작했거든요.
00:31:19린터와 포매터가 처음 목표로 삼았던 범위는
00:31:22사실 어마어마하게 넓었습니다.
00:31:2510년 가까이 프로덕션에서 쓰여 온
00:31:26ESLint나 Prettier와 호환되어야 했으니까요.
00:31:30사람들이 가진 온갖 커스텀 규칙과
00:31:33오래된 사용 사례들까지 모두
00:31:36100% 호환되게 만드는 것이 목표였습니다.
00:31:37정말 엄청난 작업이었는데 드디어 해냈습니다.
00:31:38최근에 ESLint 플러그인 호환성 100%를 달성했거든요.
00:31:40ESLint의 모든 플러그인 테스트를 통과했고,
00:31:42저희 포매터도 Prettier와
00:31:45100% 일치하는 결과를 보여줍니다.
00:31:49이 두 마일스톤은 이제 사람들에게
00:31:53자신 있게 저희 도구로 갈아타라고 말할 수 있게 됐음을 뜻하죠.
00:31:56그럼 이제 다음은 무엇일까요?
00:31:57아주 좋은 질문입니다.
00:32:00에이전트들이 도구를 사용할 때
00:32:03린트와 포맷팅은 어떻게 적응해야 할까요?
00:32:05저희가 현재 활발히 고민하고 있는 숙제입니다.
00:32:07네.
00:32:09그에 대한 답변은 아직 현재 진행형이라고 봐야겠네요.
00:32:11계속해서 진화하고 있죠.
00:32:13AI가 코딩 세계의 많은 것을 바꾸고 있으니
00:32:16참 지켜보는 재미가 있습니다.
00:32:19다시 Vite+ 이야기로 돌아가 보자면,
00:32:22ViteConf 2025에서 'vite install'이라는
00:32:26기능을 선보이셨잖아요.
00:32:29그 기능은 여전히 유효한가요?
00:32:31그리고 Vite+는 BUN 같은 도구와
00:32:34얼마나 겹치는 부분이 생길까요?
00:32:38좋은 질문입니다.
00:32:40ViteConf 이후로 상황이 좀 변하긴 했어요.
00:32:45제 생각에 최종적으로,
00:32:48Vite+의 최종 공개 버전은 어떤 면에서는
00:32:50BUN과 비슷한 느낌을 줄 거예요.
00:32:53온보딩 경험에 대해서도 말씀드렸듯이,
00:32:54완전 새 컴퓨터에서
00:32:56최대한 빨리 웹 앱을 만들고 싶을 때,
00:33:00그냥 curl로 스크립트를 한 줄 실행하면
00:33:03전역 바이너리인 'vp'가 생깁니다.
00:33:06그러면 프로젝트 안에서 무엇을 할 수 있느냐,
00:33:09프로젝트에 '.node-version' 파일이 있거나
00:33:13'package.json'에 'packageManager' 필드가 있다면,
00:33:17보통 작업 환경을 지정할 때 쓰는 것들이잖아요.
00:33:21그럼 'vp run build'라고 쳤을 때
00:33:23Vite+가 자동으로,
00:33:25'vp build'나 'vp lint' 같은 걸 실행할 때마다
00:33:28JavaScript 실행이 필요한 모든 상황에서
00:33:31그 프로젝트에 맞는 정확한 노드 버전과
00:33:34정확한 패키지 매니저를 알아서 골라 실행해 줍니다.
00:33:38심지어 그 프로젝트에서
00:33:40Vite+를 직접 사용하지 않더라도,
00:33:44이런 표준적인 환경 설정 파일만 있다면
00:33:49Vite+를 nvm의 대체제로 쓸 수 있습니다.
00:33:53corepack 대용으로도 쓸 수 있고요.
00:33:54버전 문제로 고민할 필요가 아예 없어지는 거죠.
00:33:57워크플로우를 돌릴 때
00:33:59'npm run' 대신 'vp run'을 쓰게 될 겁니다.
00:34:01그렇게 하면 적절한 노드 버전과
00:34:04적절한 패키지 매니저 버전을 알아서 사용해 줄 테니까요.
00:34:06설치 기능에 대해 말씀드리면,
00:34:10당장 저희만의 패키지 매니저를 만들 생각은 없어요.
00:34:14그보다는 corepack과 비슷한 역할인데,
00:34:17앤서니 푸(Anthony Fu)가 만든 'ni'라는
00:34:19패키지를 써보셨는지 모르겠네요.
00:34:21'ni'는 실행만 하면
00:34:23실행이든 설치든 삭제든
00:34:27알맞은 패키지 매니저를 자동으로 추론해 주거든요.
00:34:30'vite install'도 본질적으로는 그런 기능에
00:34:33패키지 매니저 관리 기능이 더해진 것입니다.
00:34:38그게 바로 corepack이 하는 일이죠.
00:34:41아무것도 설치되지 않은 컴퓨터로 프로젝트에 들어가도
00:34:43'package.json'에 특정 버전의
00:34:45pnpm이 명시되어 있다면,
00:34:46Vite+가 그 버전의 pnpm이 있는지 확인하고
00:34:51없으면 자동으로 설치한 뒤에
00:34:56'pnpm install'을 실행해 줍니다.
00:35:02린트와 포맷팅 그 이상의 문제를
00:35:04해결하고 싶은 게 저희의 생각이에요.
00:35:06JavaScript 워크플로우에서 필요한 모든 공통적인 것들 말이죠.
00:35:11초보자들이 고민할 필요도 없게
00:35:15이런 흔한 문제들을 아예 없애버리고 싶습니다.
00:35:20처음 프로젝트를 생성할 때
00:35:22저희는 노드 최신 LTS 버전을 사용하고 pnpm을 추천할 겁니다.
00:35:26그리고 그 정보를 프로젝트에 기록해 두겠죠.
00:35:28그럼 다음에 프로젝트를 다시 열었을 때
00:35:31언제나 올바른 조합으로 환경이 세팅될 수 있습니다.
00:35:36특별히 pnpm을 추천하시는 이유가 있나요?
00:35:40기능 집합과 정확성, 디스크 효율성, 속도,
00:35:44그리고 카탈로그(catalog) 같은 훌륭한 워크스페이스 지원까지
00:35:45가장 적절한 균형을 갖추고 있기 때문입니다.
00:35:48다양한 워크스페이스 기능들을 비교해 봤을 때
00:35:52pnpm이 여전히 가장 최적의 밸런스를 보여줬어요.
00:35:55BUN이 말도 안 되게 빠른 건 알지만,
00:35:59대부분의 상황에선 pnpm도 충분히 빠릅니다.
00:36:02또한 저희 런타임에서 BUN을 지원하거나
00:36:05패키지 매니저 버전 관리 대상으로 삼을 가능성도
00:36:06전혀 배제하고 있지 않습니다.
00:36:10BUN을 쓰겠다고 설정하면
00:36:14저희가 BUN으로 모든 과정을 처리해 드릴 수도 있죠.
00:36:16Vite 8은 원래
00:36:19설(음력 신년) 이후에 출시될 예정이었죠?
00:36:24맞습니다.
00:36:27정식 출시 전에 베타 버전에서
00:36:30가장 집중하고 계신 부분은 무엇인가요?
00:36:34오직 안정성입니다.
00:36:36생태계 CI 시스템인데,
00:36:41Vite에 의존하는 수많은 하위 프로젝트에
00:36:45Vite 8을 직접 돌려보는 거대한 CI 시스템을 가동 중입니다.
00:36:48최근에는 SvelteKit의 모든 테스트를
00:36:49Vite 8에서 통과시켰습니다.
00:36:51저희에겐 아주 큰 의미가 있는 일인데
00:36:56안정성이야말로 무엇보다 중요하기 때문입니다.
00:36:58생각해 보세요.
00:37:01기존의 두 번들러를 빼내고
00:37:03저희가 밑바닥부터 새로 만든 걸로 교체하는 거잖아요.
00:37:07하늘을 날고 있는 비행기의 엔진을 교체하면서
00:37:08착륙할 때까지 아무 문제가 없기를 바라는 것과 같습니다.
00:37:12조심하고 또 조심해야 하는 일이죠.
00:37:14아까 여쭤보려던 건데, Rust를 선택하신 게
00:37:16팀원들이 이미 Rust를 잘 알았기 때문인가요?
00:37:20TypeScript 진영에서는 Go를 선호하는 경우가 많더라고요.
00:37:25코드 이식이 더 쉽다고 생각해서인지
00:37:31TypeScript 팀조차 컴파일러를
00:37:34Go로 옮기려 하고 있고요.
00:37:36TypeScript 팀이 Go로 이식하려는 이유는
00:37:40말씀하신 대로 Go가 훨씬 수월하기 때문일 겁니다.
00:37:43두 언어의 멘탈 모델이 훨씬 비슷하니까요.
00:37:45저희가 Go를 선택하기 어려웠던 결정적인 이유 중 하나는
00:37:50Go의 웹어셈블리(Wasm) 지원이 미흡하다는 점이었습니다.
00:37:53바이너리 크기도 너무 크고
00:37:55웹어셈블리 환경에서의 성능이
00:37:59Rust에 비해 그리 좋지 않거든요.
00:38:02그리고 Rust를 선택한 데는
00:38:06함께 할 수 있는 인재 풀의 영향도 컸습니다.
00:38:10이미 Rust 생태계에 열정을 가지고
00:38:15헌신하고 있는 분들이 많았거든요.
00:38:19기반이 될만한 토대를 찾아보았을 때
00:38:21OXC만큼 잘 구현되어 있고
00:38:25조립이 자유로운 파서나 툴체인 세트가 없었습니다.
00:38:29OXC는 애초에 그 위에 무언가를 쌓아 올리기 위해 만들어졌거든요.
00:38:33Go 진영에는 그 정도 수준의 도구가 보이지 않았습니다.
00:38:35esbuild가 파서 등을 다 갖추고 있지만
00:38:37거대한 단일 시스템이라
00:38:40파서만 떼어내서 쓰기가 불가능하죠.
00:38:42또한 esbuild의 define, inject, transform 같은 기능들은
00:38:44최상의 성능을 내기 위해
00:38:49단 3번의 AST 패스(pass) 안에 구현되어 있습니다.
00:38:52한 번의 패스 안에서
00:38:54트랜스포메이션, 인젝트, 코드 수정 등의
00:38:58다양한 관심사가 한데 뒤섞여 있다는 뜻이죠.
00:39:00이는 확장 가능한 시스템을 만들기에는
00:39:04전혀 이상적이지 않습니다.
00:39:06저희는 더 많은 트랜스폼 기능을 제공하고
00:39:10사용자가 기능을 켰다 껐다 할 수 있게 하고 싶었거든요.
00:39:15사용자가 직접 변환 로직을 짤 수도 있게 하고요.
00:39:17린터 시스템도 명확하게 계층화되어 있어서
00:39:21여러 사람이 동시에 작업할 수 있는 구조를 원했습니다.
00:39:24결국 당시 가용했던 자원들이 큰 영향을 주었죠.
00:39:27물론 Rust는 매우 강력한 성능을 보여주고요." : "Rust는 매우 강력한 성능을 보여줍니다.
00:39:28Rust로 수준 높은 트랜스폼 로직을 짜는 건 분명 까다롭습니다.
00:39:30방문자(visitor) 패턴과 트랜스포머 파이프라인을 위한
00:39:33좋은 아키텍처를 구상하는 데 꽤 오랜 시간을 쏟아야 했어요.
00:39:36메모리 소유권 문제 때문인데,
00:39:40트리의 깊숙한 곳을 탐색하다가
00:39:43부모 트리를 수정해야 할 때 상황이 아주 복잡해지거든요.
00:39:46그래도 결국 해결책을 찾아냈습니다.
00:39:48Go였다면 훨씬 쉬웠겠지만,
00:39:49저희는 웹어셈블리로 컴파일되어
00:39:51브라우저에서도 돌아가는 환경을 원했습니다.
00:39:55Rolldown은 브라우저에서도
00:39:57꽤 만족스러운 속도로 작동합니다.
00:39:58esbuild도 브라우저에서 돌릴 수는 있지만
00:40:02Rust의 웹어셈블리 성능이 훨씬 뛰어납니다.
00:40:04팀원들이 Rust를 쓰고 계신다는 말씀에 이어,
00:40:09에반 씨 본인과 팀은 AI를 어떻게 활용하시나요?
00:40:13아까 팀원들이 이미
00:40:17AI를 많이 쓴다고 말씀하셨잖아요.
00:40:21지금 하시는 일에도 AI가 도움이 되나요?
00:40:26웹 개발이나 웹사이트 구축 같은 건
00:40:29GitHub에 워낙 예시 코드가 많아서
00:40:32AI가 학습이 아주 잘 되어 있겠지만,
00:40:35지금 하시는 작업은 기술적으로 훨씬
00:40:39난도가 높고 저수준의 작업이잖아요.
00:40:41그런 분야에서도 AI가 유용한가요? 아니면 여전히
00:40:44대부분 직접 코딩하시나요?
00:40:46분명히 도움이 됩니다.
00:40:48이 분야가 정말 빠르게 변하고 있거든요.
00:40:54작년 이맘때만 해도 저도 회의적이었습니다.
00:40:59"써봤는데 별로 도움이 안 돼. 내가 하는 일은 너무 저수준이라서 말이지."
00:41:04그런데 OXC를 이끄는 보르신은
00:41:08지금 우리 회사에서
00:41:11가장 AI에 진심인 사람이에요.
00:41:14그가 정말 파격적인 실험들을 시작했죠.
00:41:18지난달에는 일주일 동안 AI로 60개의 PR을
00:41:23쏟아내기도 했어요.
00:41:25에이전트를 병렬로 여러 개 돌리면서 말이죠.
00:41:30심지어 Angular 컴파일러를 Rust로 이식하는
00:41:33말도 안 되는 실험도 해봤어요.
00:41:36AI한테 그냥 던져주고 되나 보자 했는데,
00:41:37그게 어떻게 또 되더라고요.
00:41:39나중에 그 분야에서 무언가 결과물이 나올지도 모르겠네요.
00:41:41아무튼 AI의 능력치에 대한 저희의 인식은
00:41:42새 모델이 나올 때마다,
00:41:45그리고 더 나은 활용법이 나올 때마다
00:41:51몇 달 주기로 계속 갱신되고 있습니다.
00:41:54에이전트에게 계획(plan) 모드를 쓰게 하거나
00:41:57에이전트 지침 파일을 작성하는 식의
00:42:01최신 팁들을 적용해 보면서 말이죠.
00:42:03그런 작은 변화들을 시도해 보면 정말 깨닫게 됩니다.
00:42:07"아, 진짜 계속해서 좋아지고 있구나."
00:42:09물론 도입 정도는 사람마다 다르긴 합니다.
00:42:13저희는 팀원들이 각자 판단하기에
00:42:16적합한 수준까지는 마음껏 쓰라고 독려하고 있어요.
00:42:22원한다면 Claude 3.5 Sonnet 같은 걸 쓸 수 있게
00:42:26매달 크레딧도 지원해 주고요.
00:42:28정말 만족하며 적극적으로 의견을 내는 친구들도 있고," : "정말 만족하며 적극적으로 활용하는 팀원들도 있고,
00:42:31실제로 아주 훌륭한 PR들을 올리고 있습니다.
00:42:34결국 얼마나 잘 활용하느냐의 문제인 것 같아요.
00:42:37물론 모델 자체의 성능도 중요하지만요.
00:42:39사용자가 어떻게 제어하느냐(harness)가 관건인데,
00:42:42이 제어 계층의 발전 양상은
00:42:44예전 JavaScript 프레임워크 춘추전국시대 같아요.
00:42:45다들 각자만의 방식을 시도하고 있죠." : "다들 자기만의 방식을 시도하고 있죠.
00:42:49결국 다들 비슷비슷한 걸 하고 있긴 해요.
00:42:51어떤 건 조금 더 특별한 기술을 가지고 있을지 몰라도
00:42:53몇 달 지나면 다들 똑같이 따라 하게 되죠.
00:42:57모델도 마찬가지입니다.
00:42:59몇 달마다
00:43:01Sonnet 3.5 같은 새 모델이 쏟아져 나오잖아요.
00:43:05DeepSeek에서도 새 모델이 나온다고 하고요.
00:43:07그냥 계속해서 좋아질 수밖에 없습니다.
00:43:09적절한 가이드만 있다면 AI가 엄청난 능력을
00:43:12보여준다는 건 이미 명백한 사실이에요.
00:43:14하지만 가이드해주는 역할은 여전히 매우 중요합니다.
00:43:16Rust를 전혀 모르는 사람이 AI만 믿고
00:43:19OXC 코드베이스를 다룰 순 없거든요.
00:43:21애초에 질문을 어떻게 던져야 할지도 모를 테니까요.
00:43:23반면 OXC에 능숙한
00:43:25Rust 엔지니어가 AI를 사용하면
00:43:28생산성이 어마어마하게 높아지고
00:43:30기능들을 훨씬 빨리 배포할 수 있게 됩니다.
00:43:32이게 제 전반적인 견해입니다.
00:43:34참고로 저는 회사에서
00:43:38AI로 코드를 짜는 비중이 가장 적은 편에 속해요." : "AI로 코드를 생성하는 비중이 가장 적은 편에 속해요.
00:43:41저는 주로 조사용이나 아이디어 검토용으로만 씁니다.
00:43:45정말 묘한 세상이 되어가고 있네요.
00:43:49코딩의 흐름이 변하는 걸 보며
00:43:52배워야 할 하위 에이전트는 몇 개인지," : "에이전트를 몇 개나 동시에 써야 하는지,
00:43:59병렬 처리는 어떻게 하고, 레포지토리에 어떤
00:44:03마크다운 가이드 파일을 둬야 하는지 따라가기가 참 벅차네요.
00:44:04네, 시시각각 변하고 있죠.
00:44:07미래에 우리가 어디쯤에 도달해 있을지
00:44:11참 궁금해집니다.
00:44:13다시 Vite 이야기로 잠시 돌아가 보죠.
00:44:16Vite 7에서 React Server Components(RSC) 지원 기능을 발표하셨는데요.
00:44:19제 개인적인 생각으로는 RSC가
00:44:24개발팀이 예상했던 만큼 대성공을 거두지는 못한 것 같아요.
00:44:27TanStack처럼 RSC를 받아들이지 않는
00:44:29유명한 프레임워크들도 있고,
00:44:33Remix는 아예 자기들만의 독자적인 길을 가기로 했잖아요.
00:44:39RSC에 대해 어떻게 생각하시는지,
00:44:43그리고 왜 기대만큼 안착하지 못했다고 보시나요?
00:44:46네, 저는 항상 RSC에 대해 매우 보수적이었고
00:44:48사실 첫날부터 회의적인 편이었습니다.
00:44:51그래서 Vue에 비슷한 기능을
00:44:55도입하는 것도 전혀 고려하지 않았죠.
00:45:00핵심적인 문제는 RSC가 대체
00:45:03어떤 문제를 해결하려는 것인가입니다.
00:45:06그런데 그게 좀 과하게 홍보된 면이 있어요." : "그런데 도입 과정에서 좀 과하게 홍보된 면이 있어요.
00:45:08사람들의 기대치를 높이려고
00:45:13마치 모든 걸 해결해 줄 만능 열쇠처럼 광고됐죠." : "마치 모든 걸 해결해 줄 은빛 탄환처럼 광고됐죠.
00:45:18모든 웹사이트를 더 빠르게 만들어줄 것처럼요.
00:45:22막상 뚜껑을 열어보니 사람들은 깨닫게 됐죠.
00:45:24"아, 모든 경우에 다 써야 하는 건 아니구나."
00:45:27실제로 도움이 되는 사례는
00:45:33특정 유형에 한정되어 있고,
00:45:36그 외의 상황에서는 트레이드오프(상충 관계) 덩어리일 뿐입니다.
00:45:40서버에서 돌아가는 부분들 때문에
00:45:45모든 상호작용이 결국
00:45:49네트워크 왕복을 거쳐야 하니까요." : "네트워크 라운드 트립을 거쳐야 하니까요.
00:45:52오프라인 우선(offline-first) 경험을 중시한다면
00:45:54이건 꽤 치명적인 단점입니다.
00:45:57또한 하이드레이션(hydration) 비용에서도
00:46:00완전히 자유로울 수는 없다고 봅니다.
00:46:03클라이언트 측의 하이드레이션 비용을 줄이는 대신
00:46:08그 부담을 서버로 떠넘기는 거니까요.
00:46:11결국 모든 요청에 대해
00:46:13서버가 더 많은 일을 하게 되는 셈이죠." : "서버가 더 많은 리소스를 소모하게 되는 셈이죠.
00:46:17그래서 일각에서는 음모론까지 나옵니다.
00:46:18Vercel이 서버 컴퓨팅 사용량을 늘리려고 밀어붙인다는 식의 얘기요.
00:46:21전 진짜로 그렇다고 생각하진 않아요.
00:46:23하지만 RSC를 쓴다는 건
00:46:26서버 부하가 늘어난다는 뜻이긴 합니다.
00:46:32서버에서 더 많은 걸 실행해야 하고,
00:46:34결국 더 많은 컴퓨팅 비용을 쓰게 되죠.
00:46:37물론 장점도 있습니다. 예를 들어
00:46:41컴포넌트 일부를 서버에 두면
00:46:45번들 크기를 줄일 수 있죠.
00:46:50하지만 그 문제를 해결하는 방법은 많습니다.
00:46:54반드시 Node.js 서버를
00:46:58돌려야만 하는 건 아니라는 거죠.
00:47:00물론 이건 제 개인적인 의견일 뿐입니다.
00:47:03프론트엔드에서는 흔히들
00:47:08아키텍처가 정말 중요하다고 말하죠.
00:47:13SPA를 쓸 것인가,
00:47:16서버 사이드 렌더링(SSR)이 필요한가 같은 것들요.
00:47:20RSC는 그보다 훨씬 더 구체적인 문제입니다.
00:47:25RSC가 정말 필요한가라는 질문은
00:47:27답하기 매우 어려운 문제이기도 하고요.
00:47:29만약 쓰겠다고 결정했다면
00:47:32그에 따르는 비용도 충분히 인지해야 합니다.
00:47:34사람들에게 널리 퍼지지 못한 이유 중 하나는
00:47:37일단 너무 복잡하기 때문입니다.
00:47:38개념 자체를 설명하기도 어렵고
00:47:40작동 원리를 이해시키기도 힘들죠." : "어떻게 작동하는지 설명하기도 어렵죠.
00:47:43저희도 내부를 깊숙이 파헤쳐야 했는데,
00:47:43시스템 전체를 유기적으로 돌리려면
00:47:47빌드 도구 레벨에서 아주 정교한 조율이 필요하거든요.
00:47:52그래서 실제로 날것의 RSC가
00:47:54어떻게 돌아가는지 아는 사람은 극히 드뭅니다.
00:47:57대부분은 Next.js에 구현된
00:48:00모습을 통해 RSC를 접할 뿐이죠.
00:48:01평범한 개발자가 순수 React와 Vite 혹은 Webpack만으로
00:48:04RSC 환경을 밑바닥부터 직접 구축하는 건
00:48:07거의 불가능에 가깝거든요.
00:48:10매일같이 하는 일반적인 개발 업무가 아니니까요.
00:48:14그러니 프레임워크를 쓰는 거고," : "그러니 프레임워크를 쓰고 싶어 하겠죠.
00:48:17프레임워크가 바로 그 역할을 하라고 있는 겁니다.
00:48:20그런데 프레임워크가 RSC를 도입하려면
00:48:23RSC를 어떤 방식으로 사용자에게 보여줘야
00:48:28괜찮은 개발 경험(DX)을 줄지 어려운 설계 결정을 내려야 합니다.
00:48:30개인적으로 Next.js는 그 점을 완벽히 해결하진 못한 것 같아요.
00:48:35'use server', 'use client'의 혼란이라든가,
00:48:38특정 부분을 서버 컴포넌트로 만들면
00:48:40갑자기 기존의 것들이 안 돌아가는 뒤섞인 그래프 문제 같은 것들이요.
00:48:42사용할 수 있는 기능이 제한되고
00:48:44어떤 라이브러리를 가져왔는데
00:48:48그게 'use server'에서 안 돌아가면
00:48:51다시 'use client'를 써야 하죠.
00:48:54이런 식으로 계속 왔다 갔다 하는 과정이,
00:48:56자잘하게 개발자의 신경을 긁는
00:48:59불편한 경험들을 만들어냅니다.
00:49:04광고했던 장점들을 얻기 위해
00:49:06평생 이런 DX의 짜증스러움을
00:49:08감수해야 할 가치가 있는가라고 묻게 되죠.
00:49:10정말 그럴만한 가치가 있을까요?
00:49:14그래서 사람들이 고민하는 건 지극히 당연한 일입니다.
00:49:20프레임워크 제작자들 입장에서도 마찬가지예요.
00:49:21Vercel은 React 팀과 아주 밀접한 관계를 맺고
00:49:26협업하며 빠르게 개선해 나갈 수 있지만,
00:49:29다른 제3자들은 상황이 좀 다르죠." : "다른 프레임워크들은 상황이 좀 다르죠.
00:49:31기술적으로는 Vercel도 제3자이긴 하지만요.
00:49:33하지만 Remix나 TanStack 같은
00:49:38다른 프레임워크들에게 RSC 문제는
00:49:44그리 단순하게 접근할 수 있는 일이 아닙니다." : "그리 쉽게 해결할 수 있는 문제가 아닙니다.
00:49:47React 팀의 많은 API 업데이트가
00:49:51Next.js를 우선순위에 두고 이루어지는 경향이 있거든요.
00:49:52그걸 비난하고 싶지는 않습니다.
00:49:54Vercel은 그들의 설계 파트너니까요.
00:49:56Vercel과 협력해서
00:49:59기능을 다듬고 출시하는 건 합리적인 결정이죠.
00:50:01하지만 그런 구조 때문에,
00:50:02사람들이 RSC를 쓸 수 있는 실질적인 방법은
00:50:06Next.js뿐이었습니다.
00:50:07그런데 그 경험이 그렇게 환상적이진 않았던 거죠.
00:50:10그래서 기대만큼 잘 풀리지 않았던 것 같아요.
00:50:14또한 제 생각엔,
00:50:17RSC의 개발 경험이 완벽해지는 이상적인 세상이 오더라도," : "RSC의 DX가 완벽해지는 이상적인 세상이 오더라도,
00:50:19여전히 모든 경우를 해결해 줄
00:50:21만능 열쇠는 아닐 거라고 봅니다.
00:50:24어디에 적합하고 어디에 부적합한지
00:50:27충분히 공부하고 써야 해요.
00:50:31고려해야 할 트레이드오프가 너무 많습니다.
00:50:33Vue에서도 비슷한 걸 시도하라는
00:50:35압박은 없었나 보네요.
00:50:37아무래도 Vercel과도 연결되어 있으니까요.
00:50:39Vue 기반의 메타 프레임워크인 Nuxt를 만든
00:50:43Nuxt Labs를 Vercel이 인수했잖아요.
00:50:46Vercel에 인수된 이후로 Nuxt와 Vue의
00:50:48관계는 어떻게 변했나요?
00:50:50솔직히 말씀드리면 크게 변한 건 없습니다.
00:50:52Vercel은 인수 후에도 꽤 방임적인 태도를 유지해 왔고
00:50:56덕분에 Nuxt 팀도 하던 일을
00:50:58계속해서 즐겁게 해나가고 있습니다.
00:51:02아마 Nuxt를 Vercel에서
00:51:04더 잘 돌아가게 만들거나
00:51:07일급 시민으로 대우하려는 노력은 있을 겁니다." : "Vercel의 핵심 서비스로 지원하려는 노력은 있을 겁니다.
00:51:11하지만 Vercel도 커뮤니티 내에서
00:51:14자신들의 이미지가 어떤지 잘 알고 있고
00:51:17그걸 더 이상 훼손하지 않으려고 매우 조심하고 있어요.
00:51:20그래서 Nuxt를 인수한 뒤에도,
00:51:23사람들이 싫어할 만한 일을 억지로 시키는 건
00:51:27가장 피하고 싶은 일일 겁니다.
00:51:29안타깝게도 에반 씨가 중요한 전화를 받으러
00:51:30조금 일찍 자리를 뜨게 되었는데요.
00:51:33바쁜 시간 내주셔서 모든 질문에
00:51:36통찰력 있는 답변을 주신 점 정말 감사드립니다.
00:51:39팟캐스트에 초대하고 싶은 게스트가 있다면
00:51:42댓글로 꼭 알려주세요.
00:51:47다른 의견이나 피드백도
00:51:51언제든지 환영합니다.
00:51:55저희의 의견을 듣고 싶으시면
00:51:58스포티파이나 애플 팟캐스트에서 저희를 찾아주세요.
00:52:01그럼 다음 시간에 뵙겠습니다. 감사합니다.
00:52:03안녕히 계세요.
00:52:06감사합니다.
00:52:08즐거웠습니다. 감사합니다.
00:52:10함께해 주셔서 정말 감사합니다.
00:52:12in DX makes people think, okay,
00:52:15like in order to get the claimed benefits,
00:52:20now I have to also just put up with this annoyance of DX
00:52:24all the time, forever into the future.
00:52:27Is it really worth it, right?
00:52:28So yeah, so I think it's fair that people are like,
00:52:35do I really want to use it?
00:52:37And also like even for framework authors, right?
00:52:40Vercel had this really close relationship with the React team
00:52:42so they can collaborate and iterate on it fast.
00:52:45But for third party, I wouldn't even say third party
00:52:49because technically Vercel is third party, right?
00:52:52But for other frameworks like remix and test stack,
00:52:57it's not that straightforward for them to work on,
00:53:02to work on this problem because a lot of these API iterations
00:53:06from the React team is like prioritizing Next.js.
00:53:08So I think I'm not really criticizing them for it
00:53:13because it's like, okay, Vercel is their design partner.
00:53:15They want to partner with Vercel
00:53:17to get this feature polished and ship it,
00:53:19which makes sense, right?
00:53:21But I think, and because of that,
00:53:25like Next.js essentially was the only real way
00:53:29for people to use RSC.
00:53:31And that experience hasn't been super great.
00:53:33So I think that's why it just didn't pan out as it could.
00:53:38And also like, I think the general premise
00:53:41of even in an ideal world where RSC has like perfect DX,
00:53:46I still don't think it's going to be a silver bullet
00:53:49in all cases, right?
00:53:50So you need to be fully educated
00:53:52on where it makes sense, where not.
00:53:54So just too many trade-offs.
00:53:57- I assume there's been no sort of push
00:53:59to implement something similar in view
00:54:01because obviously linking is back to Vercel.
00:54:03They bought Nuxt Labs,
00:54:05which is the sort of meta framework on top of Vue
00:54:08for piecing it all together.
00:54:09How's that sort of relationship been between Nuxt and Vue
00:54:13now that Vercel own them?
00:54:14- Honestly, it didn't change much.
00:54:18I think Vercel has been pretty hands-off since the acquisition
00:54:21so the Nuxt team is just happy to be able
00:54:24to keep doing what they do.
00:54:25There are probably some efforts to say,
00:54:30make Nuxt work better on Vercel,
00:54:32make a first-class citizen.
00:54:34But I think the thing is Vercel is aware
00:54:38that some of the images it has in the community
00:54:43and they would be really careful not to damage it further.
00:54:47And so after acquiring Nuxt, right,
00:54:50the last thing they'd want to do
00:54:52is to force Nuxt to do things people don't like.
00:54:54- Unfortunately, Evan had to leave early
00:54:56to take an important call,
00:54:58but we really appreciate his time
00:55:00and all his insightful opinions on all the questions we asked.
00:55:04If you have any future guests you'd love on the podcast,
00:55:06please let us know in the comments.
00:55:08And if you have any feedback in general,
00:55:10also let us know too.
00:55:11We'd love to hear it.
00:55:12Find us on anywhere you listen to podcasts
00:55:15like Spotify or Apple Podcasts.
00:55:17And until next time, it's a bye from me.
00:55:20- Bye from me.
00:55:21- Bye from me.
00:55:21- It's a pleasure, thank you all.
00:55:23- Thank you very much for joining us.