JS 피로감 시대에 등장한 새로운 실험
프론트엔드 개발자라면 "새 프레임워크가 또 나왔대"라는 말에 이제 좀 무덤덤해지셨을 텐데요. 그런데 최근 공개된 'Nectar'는 방향이 꽤 달라서 한번 소개해 드리려고 해요. 한 줄로 요약하면 "Rust 같은 언어로 React 같은 UI를 짜고, 결과물은 자바스크립트가 아니라 WebAssembly로 뽑아내는 프레임워크"거든요.
여기서 WebAssembly(줄여서 Wasm)가 뭐냐면, 브라우저가 자바스크립트 말고도 실행할 수 있는 또 하나의 실행 형식이에요. 자바스크립트는 사람이 읽는 텍스트 코드를 브라우저가 그때그때 해석하고 최적화하면서 실행하는데, Wasm은 미리 기계어에 가까운 바이너리로 컴파일해 둔 걸 실행해요. 그래서 무거운 계산에서 성능이 훨씬 빠르고 예측 가능하다는 장점이 있어요. 지금까지는 주로 게임 엔진이나 피그마 같은 고성능 웹앱의 핵심 부분에 쓰였는데, 이걸 아예 일반 UI 프레임워크의 기반으로 삼겠다는 게 Nectar의 아이디어예요.
"Rust 같은 React"라는 게 무슨 뜻일까요
이 표현을 둘로 쪼개서 보면 이해가 쉬운데요. 먼저 "React 같은"은 개발 경험 이야기예요. 화면을 컴포넌트 단위로 쪼개고, 상태(state)가 바뀌면 그에 맞춰 UI가 자동으로 다시 그려지는 선언적인 방식이요. React를 써보셨다면 익숙한 그 멘탈 모델을 그대로 가져가겠다는 거죠.
"Rust 같은"은 언어 차원의 이야기예요. Rust는 강력한 타입 시스템과 소유권(ownership)이라는 개념으로 유명한데요. 이게 뭐냐면, 어떤 데이터를 누가 갖고 있고 언제까지 유효한지를 컴파일러가 코드 실행 전에 전부 검사해 주는 규칙이에요. 그 덕분에 "undefined는 함수가 아닙니다" 같은 에러를 런타임에 만나는 게 아니라, 컴파일 단계에서 대부분 걸러낼 수 있어요. 자바스크립트에 타입을 얹은 TypeScript보다 한 단계 더 엄격한 안전망이라고 보시면 돼요.
그리고 이런 컴파일 기반 접근에는 또 하나의 이점이 있는데요. React는 가상 DOM이라는 걸 써요. 화면 구조의 복사본을 메모리에 들고 있다가, 상태가 바뀌면 이전 복사본과 비교해서 달라진 부분만 실제 화면에 반영하는 방식이죠. 반면 컴파일 시점에 "이 상태가 바뀌면 정확히 이 DOM 노드만 갱신하면 된다"는 걸 미리 계산해 두는 프레임워크들은 이 비교 과정 자체를 생략할 수 있어요. Svelte나 SolidJS가 자바스크립트 세계에서 증명한 접근인데, Rust 계열 Wasm 프레임워크들도 대체로 이 방향으로 가고 있어요.
사실 혼자가 아니에요 — 경쟁자들과의 비교
Rust로 프론트엔드를 만들려는 시도는 이미 여럿 있어요. Yew는 React와 가장 비슷한 초기 주자였고, Leptos는 SolidJS처럼 세밀한 반응형 시스템(fine-grained reactivity)으로 주목받았고, Dioxus는 웹뿐 아니라 데스크톱과 모바일까지 노리는 크로스 플랫폼 프레임워크예요. 마이크로소프트의 Blazor는 C#으로 같은 일을 하고요. Nectar가 눈에 띄는 점은 기존 Rust를 그대로 쓰는 게 아니라 "Rust를 닮았지만 UI 개발에 맞게 다듬은" 접근을 내세운다는 건데요. Rust의 소유권 규칙이 UI 코드에서는 오히려 발목을 잡을 때가 많다는 불만이 커뮤니티에 꾸준히 있었거든요. 클로저 하나 넘길 때마다 컴파일러와 씨름해 본 분이라면 공감하실 거예요.
다만 냉정하게 봐야 할 지점도 있어요. Wasm은 아직 DOM(웹 페이지의 구조)을 직접 만질 수 없어서, 화면을 갱신하려면 결국 자바스크립트 다리를 건너야 해요. 이 왕복 비용 때문에 "버튼 하나 누르면 텍스트 하나 바뀌는" 평범한 앱에서는 Wasm이 오히려 손해일 수 있어요. 번들 크기도 자바스크립트 프레임워크보다 커지기 쉽고, 생태계와 디버깅 도구도 아직 한참 부족하고요.
한국 개발자에게는 어떤 의미일까요
당장 회사 프로젝트에 도입할 물건은 아니에요. 라이브러리 생태계, 레퍼런스, 채용 시장 모두 React 쪽이 압도적이니까요. 하지만 흐름 자체는 배워둘 가치가 충분해요. Svelte가 보여준 "컴파일러가 일하는 프레임워크" 방향과, Wasm이 열어가는 "브라우저에서 자바스크립트 독점이 깨지는" 방향이 만나는 지점에서 이런 프로젝트가 계속 나오고 있거든요. 주말에 장난감 프로젝트로 Leptos나 Dioxus를 한번 만져보면, 이 흐름이 왜 생기는지 몸으로 느껴지실 거예요.
한 줄 정리: 자바스크립트의 유연함 대신 컴파일러의 엄격함을 선택한 프론트엔드 실험이 또 하나 등장했어요. 여러분은 어떻게 보세요? 프론트엔드의 미래에 Rust 같은 컴파일 언어가 자리 잡을 수 있을까요, 아니면 TypeScript 선에서 충분하다고 보시나요?
🔗 출처: Hacker News