Lovable이 Vite를 Rust로 재작성했습니다... (어느 정도는요)

한국어العربية Deutsch English Español Français हिन्दी Bahasa Indonesia 日本語 Português Русский 中文

Computing/SoftwareSmall Business/StartupsInternet Technology

Transcript

00:00:00또 하나의 Rust 재작성 사례가 추가되었습니다. 이번에는 Vite 개발

00:00:03서버를 Lovable 팀이 Rust로 다시 작성했는데요. 메모리 사용량은

00:00:074배 개선되고 콜드 스타트는 2배 빨라졌다고 합니다. 약간 오해의 소지가

00:00:12있을 수 있으니 이 주장을 한번 검증해보고, 앞으로 여러분이 전환할 만한

00:00:15가치가 있는지, 또 Vite 제작자는 이것이 오픈소스의 미래에 어떤 의미라고 보는지 알아보겠습니다.

00:00:24제가 말씀드릴 프로젝트는 OJ, 즉 Orange Juice라는 프로젝트입니다. 핵심 개념은 기존 Vite

00:00:29프로젝트에 Rust 바이너리 하나를 실행하기만 하면 바로 돌아간다는 것입니다. 기존 Vite

00:00:33설정을 읽고 플러그인도 그대로 실행하지만, 그 밑단의 개발 서버, 즉 파일

00:00:38와처, 모듈 그래프, 핫 모듈 교체(HMR), React Fast Refresh 등을 모두 Rust로 재작성한 것이죠.

00:00:44재미있는 점은, Vite 자체도 사용하고 VoidZero가 유지보수하는 Rolldown과 Oxc를

00:00:49사용해 만들어졌다는 겁니다. 직접 확인해보기 위해 TanStack 앱을 하나 만들어서

00:00:53Vite dev와 OJ dev로 실행했을 때 차이가 있는지 비교해 보았습니다. 겉보기에는 거의 똑같이 동작하며,

00:00:58서버 사이드 렌더링, 하이드레이션, 서버 함수, Fast Refresh,

00:01:03동적 파일 라우트, 서버 라우트, Tailwind, 에셋 임포트 등 모든 기능이 잘 작동했습니다. 하지만 좀 더 파헤쳐 보니

00:01:07사소한 차이점이 몇 가지 보였습니다. 첫 번째는 Fast Refresh 부문이었는데요. 파일을 수정할 때

00:01:13Vite의 카운터는 기존 상태를 유지하지만, OJ 환경에서는 카운트가 0으로 초기화되었습니다.

00:01:17즉, 변경된 컴포넌트만 업데이트하는 게 아니라 전체 페이지를 새로고침한다는 뜻이죠. 그래서 저는

00:01:22TanStack Start가 아닌 일반 React 앱에서도 동일하게 동작하는지 테스트해 보았습니다.

00:01:26흥미롭게도, 일반 React 앱에서는 제대로 작동하는 것 같았습니다. 동일하게 편집해도 카운트가 유지되고

00:01:30전체 페이지가 업데이트되지 않아서 진정한 핫 업데이트가 이루어지는 것으로 보였습니다. TanStack Start와

00:01:35일반 React 앱 간에 왜 이런 차이가 발생하는지는 모르겠지만, 아직 고려되지 않은

00:01:39예외 케이스 중 하나일 수도 있습니다. 두 번째로 발견한 차이점은

00:01:42서버 함수 관련이었습니다. 이 서버 함수는 앱 내부에서 개발 서버의 전체 프로세스 트리의 메모리를 측정하는데,

00:01:46Vite 환경의 이 앱에서는 2개 프로세스에 걸쳐 약 380MB가 사용되었고, OJ 환경에서는

00:01:53동일하게 2개 프로세스에서 약 320MB가 사용되었습니다. 따라서 이처럼 규모가 작은 앱에서는

00:01:59메모리 사용량이 거의 비슷하고, OJ가 아주 근소하게 앞서는 정도입니다. 그렇다면 이 프로젝트가

00:02:04완전히 쓸모없다는 뜻일까요? 그렇지는 않습니다. OJ가 원래 이런 앱을 위해 만들어진 게 아니기 때문입니다. OJ는

00:02:09아주 규모가 큰 앱에서 가장 진가를 발휘합니다. 5,000개의 컴포넌트가 있는 React 앱에서 테스트해 보았는데요.

00:02:14각 개발 서버 코드 실행, 실제 Chrome 브라우저에서 페이지 열기, 가장 깊은

00:02:19컴포넌트가 DOM에 도달했을 때 타이머 중지, 그리고 전체 프로세스 트리의 메모리를 샘플링하는 스크립트를 돌려보니,

00:02:24OJ의 일반 모드는 기본 Vite보다 페이지 렌더링까지 약 1.7배 빠르고, 메모리는

00:02:29약 4분의 1만 사용했습니다. 물론 Vite를 변호하자면, Vite 8.1에서 번들 개발 모드라는 실험적 기능을 선보였고,

00:02:34이 기능을 켜면 Vite도 1.18초에 도달하여 OJ의 일반

00:02:40모드보다 살짝 빠르긴 하지만, 메모리는 절약되지 않습니다. 그리고 OJ에도 번들 모드가 존재하는데,

00:02:45이를 사용하면 약 0.89초로 훨씬 더 빨라지면서도 메모리는 Vite의 4분의 1 수준을 유지합니다.

00:02:51따라서 OJ는 상당한 메모리 절감 효과가 있어 보이며, 이것이 바로 Lovable이

00:02:55이 프로젝트를 만든 핵심 이유입니다. Lovable 프리뷰는 실제 Vite 개발 서버를 실행하는데,

00:03:00Lovable 측에 따르면 하루에 약 100만 개의 샌드박스를 실행한다고 합니다. 이런 스케일에서는

00:03:04자원 소비량이 엄청나게 중요해집니다. 그래서 Lovable은 앱을 구동하는 생태계를

00:03:09포기하지 않으면서도, 즉시 시작되고 가볍게 유지되는 프리뷰를 만들기 위해 OJ를 개발했습니다.

00:03:13또한 이러한 유스케이스, 즉 AI 에이전트를 고려한 꽤 멋진 설계 결정을 내렸습니다. 사람이 편집할 때는

00:03:17보통 한 번에 하나의 파일을 저장하지만, 에이전트는 순식간에 10개 정도의 파일을 작성할 수 있습니다.

00:03:22Vite는 이러한 저장 각각을 개별 업데이트로 처리하지만, OJ에서는 와처,

00:03:26모듈 그래프, 컴파일러, 핫 업데이트가 하나의 파이프라인으로 묶여 있어 연달아 발생하는 변경을 하나의 업데이트로 병합합니다.

00:03:32또한 에이전트 자체가 플러시 엔드포인트로 요청을 보낼 때까지 업데이트를 대기시키는

00:03:35게이트 기능도 켤 수 있어서, 완결된 변경 사항만 프리뷰에 적용되도록 할 수 있습니다. 보다시피 이것은

00:03:40Lovable 자신의 유스케이스를 해결하기 위한 매우 특화된 프로젝트이며, Vite의 제작자인 Evan You 역시

00:03:45이 점을 인정했습니다. 그의 트윗 첫 번째 지점은, Lovable의 문제를 훌륭히 해결한

00:03:49매우 인상적인 프로젝트이지만 Vite 전체를 다시 쓴 것은 아니라는 사실입니다. 개발 서버에 한정된 것이며,

00:03:54또한 VoidZero가 유지보수하는 Rolldown과 Oxc 기반으로 구축되었으므로 이들을 대체한다고 보기는 어렵습니다.

00:04:00OJ의 파서, 트랜스포머, 프로덕션 번들러는 모두 VoidZero의 산물이며,

00:04:04Lovable은 그 주변의 서버만 작성했을 뿐입니다. 본질적으로 Vite는 Rust를 제어하는

00:04:08Node 프로세스인 반면, OJ는 Rust를 제어하는 Rust 프로세스이며, 중간 레이어가

00:04:13JavaScript로 되어 있어 Vite의 플러그인 API와 통신할 수 있는 형태라고 볼 수 있습니다. 이어서 Evan은

00:04:17OJ가 빠를 수 있는 이유는 단 한 가지 형태의 앱만 지원하기 때문이라고 지적합니다. OJ는 실제로

00:04:22React 앱, 즉 Lovable이 생성하는 형태의 앱에서만 작동합니다. 반면 Vite는

00:04:27모든 프레임워크, 온갖 특이한 설정, 이를 기반으로 만들어진 모든 툴을 지원해야 하며, 그렇기 때문에

00:04:31esbuild나 React 플러그인 같은 요소들을 별도 패키지로 남겨두어 필요시 직접 추가하도록 의도적으로 설계되었습니다.

00:04:36뒤이어 그는 벤치마크의 맹점도 짚어냅니다. 블로그의 Vite 콜드 스타트 측정에는

00:04:40백그라운드 워커에서 TypeScript를 실행하는 vite-plugin-checker가 포함되어 있지만, OJ는 실제로

00:04:45해당 플러그인을 지원하지 않아 그 작업을 완전히 건너뜁니다. 또한 Vite에서 번들 개발

00:04:50모드를 사용할 경우 OJ의 콜드 스타트에 가까워지며 이는 저희 테스트 수치와도 일치한다고 밝혔습니다. 다만

00:04:55OJ가 메모리를 훨씬 적게 사용한다는 점은 인정하며, Vite도 이를 개선하는 것을 목표로 삼아야 할 것이라고 언급했습니다.

00:04:59이 트윗에서 Evan이 제시한 마지막 지점이 제가 가장 흥미롭게 느낀 부분입니다. 오픈소스의 역학관계가

00:05:03변하고 있습니다. AI 덕분에 무언가를 다시 구현하는 비용이 급격히 줄어들었기 때문에,

00:05:08그가 말하는 '맞춤형 오픈소스 도구'의 모습을 앞으로 더 자주 보게 될 것입니다. 즉, 동일한 의존성을

00:05:13특정 유스케이스와 제약 조건에 맞춰 재구축하는 것이죠. 그는 TanStack의 Redact를 또 다른 예로 들었습니다.

00:05:19다가올 미래에는 메인테이너들이 수천 개의 자잘한 PR에 시달리는 대신,

00:05:23각자 자신만의 전용 포크를 유지 관리하게 될지도 모릅니다. 솔직히 이것이 좋은 현상인지는 확신할 수 없지만,

00:05:28몇 년 안에 실제로 그렇게 될 가능성이 높다고 생각한다고 그는 말합니다. 한편으로는 전용 포크가

00:05:33수많은 PR보다 메인테이너에게 더 나을 수 있지만, 생태계가 파편화될 위험이 있습니다.

00:05:39이것이 어떻게 전개될지, 오픈소스의 미래가 어떻게 될지는 결국 시간이 지나봐야 알 것 같습니다.

00:05:43전반적으로, 샌드박스에서 수백만 개의 Vite 개발 서버를 실행하는 것과

00:05:47완전히 동일한 문제에 직면한 경우가 아니라면 Lovable 외의 다른 사람이 사용할 만한 툴은 아닙니다.

00:05:52개인 노트북에서 Vite가 느리다거나 메모리를 너무 많이 쓴다고 느낀 적이 정말 있으신가요? 저는 개인적으로

00:05:57없지만, 그래도 확실히 멋진 프로젝트이고 이런 시도를 했다는 점 자체가 흥미롭습니다.

00:06:01어떻게 생각하시는지 댓글로 남겨주세요. 구독도 잊지 마시고요. 그럼 늘 그렇듯

00:06:04다음 영상에서 뵙겠습니다.

00:06:09다음 영상에서 뵙겠습니다.

Key Takeaway

Lovable의 OJ는 하루 100만 개 샌드박스 실행 환경에 특화되어 메모리를 75% 절감하는 Rust 기반 개발 서버이며, AI 시대에 특정 유스케이스 맞춤형 오픈소스 포크가 늘어나는 경향을 보여준다.

Highlights

Lovable이 개발한 Rust 기반 Vite 서버 'OJ(Orange Juice)'는 대규모 React 앱에서 메모리 사용량을 4분의 1로 줄이고 페이지 렌더링 속도를 1.7배 향상시킨다.
OJ의 번들 모드를 적용하면 페이지 렌더링 시간이 0.89초까지 단축되며, 기본 Vite 8.1의 번들 모드(1.18초)보다 우수한 성능을 보인다.
AI 에이전트의 연달아 발생하는 파일 수정 작업을 하나의 업데이트로 병합하고 대기시키는 게이트 기능을 갖추고 있다.
OJ는 파서, 트랜스포머, 프로덕션 번들러 영역에서 VoidZero의 Rolldown 및 Oxc 프로젝트에 의존한다.
AI 발전으로 복제 및 재구축 비용이 감소함에 따라 특정 유스케이스에 특화된 포크 형태의 '맞춤형 오픈소스 도구'가 증가하는 추세다.

Timeline

OJ 프로젝트의 개요와 기능 작동 검증

OJ는 기존 Vite 프로젝트 환경에서 Rust 바이너리 실행만으로 작동하며 개발 서버 핵심 기능을 Rust로 처리한다.
기본 React 앱에서는 Fast Refresh 상태가 정상 유지되지만 TanStack Start 환경에서는 전체 페이지가 새로고침되는 차이가 존재한다.
소규모 앱 기준 메모리 사용량은 Vite가 약 380MB, OJ가 약 320MB로 차이가 미비하다.

OJ(Orange Juice)는 Vite의 기존 플러그인과 설정을 유지하면서 파일 와처, 모듈 그래프, HMR, React Fast Refresh를 Rust로 대체한다. VoidZero가 유지보수하는 Rolldown과 Oxc 기술을 기반으로 구축되었으며, SSR, 하이드레이션, 서버 함수, Tailwind 등 기본 Vite 기능을 동일하게 지원한다. 일반 React 앱에서는 핫 업데이트가 정상 작동하지만, 프레임워크 구조에 따라 컴포넌트 상태가 초기화되는 일부 예외 케이스가 발생한다.

대규모 앱 벤치마크 및 AI 에이전트 전용 설계

5,000개 컴포넌트 기준 대규모 React 앱에서 OJ는 Vite 대비 렌더링 속도 1.7배 향상 및 메모리 75% 절감 효과를 낸다.
OJ 번들 모드 적용 시 렌더링 시간은 0.89초로 Vite 8.1 번들 모드의 1.18초보다 빠르다.
AI 에이전트의 다중 파일 동시 수정 요청을 단일 업데이트로 합치는 파이프라인 통합 및 게이트 기능을 제공한다.

OJ의 진가는 대규모 애플리케이션 환경과 클라우드 프리뷰 샌드박스에서 나타난다. 하루 100만 개의 샌드박스를 구동하는 Lovable 환경에서는 메모리 효율이 핵심이다. 인간 사용자와 달리 짧은 시간에 여러 파일을 동시에 작성하는 AI 에이전트의 동작 특성에 맞춰, 변경 사항을 모아 한 번에 플러시하는 게이트 기능을 파이프라인에 직접 내장했다.

Vite 제작자 Evan You의 분석과 오픈소스의 미래

OJ는 React 전용으로 설계되어 높은 성능을 내며, 범용성을 지닌 Vite 전체를 완전히 대체하는 프로젝트는 아니다.
Vite의 블로그 벤치마크 차이는 vite-plugin-checker 지원 여부 등 측정 조건의 차이에서 비롯된다.
AI 기술 발전으로 특정 목적에 맞춘 전용 오픈소스 포크가 점차 늘어나는 구조적 변화가 시작되고 있다.

Evan You는 OJ가 Lovable의 서버 자원 문제를 해결한 훌륭한 프로젝트임을 인정하면서도, 복잡한 설정과 다양한 프레임워크를 지원해야 하는 Vite와 달리 단일 React 환경에만 초점을 맞췄기 때문에 높은 성능을 낼 수 있었다고 설명한다. 또한 AI 덕분에 코드 재구축 비용이 낮아지면서, 메인테이너에게 다수의 PR을 보내는 방식 대신 자신들의 유스케이스에 맞춘 전용 포크를 직접 유지관리하는 '맞춤형 오픈소스 도구' 트렌드가 강화될 것으로 전망한다.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video