2026년 프론트엔드 패러다임 12종 — 자작 언어를 위한 조사 노트

왜 이걸 조사했나

자작 프로그래밍 언어를 만들고 있다. ML 계열의 작은 언어로, 대수적 이펙트, capability passing, region 기반 메모리 모델을 가진다. 코어가 안정되면 WASM으로 빌드해 web UI도 쓸 수 있게 만들고 싶다.

단순한 계획은 “내 언어로 React를 재구현”이다. 블로그 글로는 깔끔한 이야기지만, 설계 판단으로는 마음에 걸렸다. React는 2013년의 설계다. 그것을 정의한 VDOM diff 모델은 이미 몇 년째 벤치마크에서 지고 있다. 내가 비교하고 싶은 언어들 — JS의 Solid, Rust의 Leptos, OCaml의 Bonsai — 은 이미 오래전에 앞서 나갔다.

그래서 차분히 앉아서, 2026년에 사람들이 실제로 web UI를 무엇으로 만들고 있는가, 그리고 각각이 무엇을 트레이드오프하는가를 지도화했다. 이 노트는 그 조사 결과다. 나 자신을 위해 쓴 것이기도 하지만, 다른 누군가에게도 쓸모가 있을지 모른다.

미리 말해 두면, 나는 백엔드 / 언어 쪽 사람이 프론트엔드를 바라보는 입장이다. 이 커뮤니티들 중 어느 쪽을 변호할 수 있는 위치가 아니다. 그래도 설계 공간을 파악하는 일은 나에게 중요한데, 만들고 있는 언어가 선택을 해야만 하기 때문이다 — 더 정확하게는, 여러 선택을 순서대로 해 나가야 한다.

12개의 패러다임

“React냐 Vue냐” 같은 이분법보다 세상은 훨씬 넓다. 몇 번 정리하고 나서 12개로 수렴했다. 경계는 모호하다. Vue 3는 #1과 #2 사이에 있고, Svelte 5는 #3에서 #2로 움직이고 있다. 그래도 클러스터의 중심은 분명히 존재한다.

1. Virtual DOM + diff

대표: React, Vue 2, Preact, Inferno

“모던 프론트엔드”의 원조 이야기. UI를 state → vdom tree의 순수 함수로 표현한다. state가 바뀔 때마다 트리를 통째로 다시 만들고, 이전 트리와 diff를 떠서 차이만 실제 DOM에 반영한다.

멘탈 모델이 단순하다. UI를 state의 함수로 생각한다. 세상을 다시 렌더하면 최소한의 DOM 변경을 프레임워크가 알아서 한다. 오랫동안 이것이 지배적인 교과서 서사였고, React가 아닌 프레임워크들도 “props를 받아 JSX 풍 출력을 반환하는 컴포넌트”를 채택했다.

대가는 매번 트리를 만들고 두 트리를 걸어 다니며 비교한다는 점이다. 화면을 움직이지 않는 GC 압력과 CPU 시간이 그곳에서 발생한다. 런타임도 크다. React + ReactDOM이 minify 후 40KB 정도다.

순수 VDOM이 최전선에서 물러난 것은 그것이 망가졌기 때문이 아니다 — 앱은 멀쩡히 돌아갔다. 새로운 설계가 같은 일을 적은 노력으로 해내게 되었고, React 자신의 현재 방향(Server Components, Compiler)도 어떤 의미에서는 2013년의 전제에서 도망치려는 시도다.

2. Fine-grained reactivity / 시그널

대표: Solid.js, Vue 3, Leptos (Rust), Angular Signals, Preact Signals, Knockout(역사적 선조)

“state가 바뀌면 세상을 다시 만든다”가 아니라, 각 state를 시그널 — 읽고, 쓰고, 구독할 수 있는 값 — 으로 가진다. 렌더 함수 안에서 시그널을 읽으면, 프레임워크는 그 함수가 그 시그널에 의존한다는 것을 기록한다. 시그널이 바뀌면 그것을 읽은 DOM 노드만 갱신된다.

VDOM이 없다. 컴포넌트 단위의 재렌더도 없다. 수동 useMemo나 useCallback도 필요 없다 — 의존성 그래프는 read 추적으로 자동 구성된다.

이것이 2026년 JavaScript 프레임워크 벤치마크를 사실상 휩쓸고 있다. Krausest js-framework-benchmark에서 Solid가 선두, Vue 3, Leptos, Angular Signals, Preact Signals, Svelte 5가 같은 방향으로 가고 있다. 2020년대 중반 프론트엔드를 정의하는 트렌드를 하나만 꼽으라면 “모두 시그널로 옮겨가고 있다”가 그것이다.

트레이드오프는 개념적이다. 시그널은 기본적으로 참조 전달이다. Solid의 count는 숫자가 아니라 getter다. JavaScript처럼 보이지만 JavaScript가 아닌 코드는 React 초기의 stale closure 문제처럼 사람을 걸려 넘어뜨린다.

내 언어에는 이것이 가장 흥미로운 target이다. capability passing은 시그널 passing에 거의 그대로 대응된다. 의존성 그래프는 이펙트를 추적할 수 있는 타입 시스템을 요구하는데, 그것이 바로 내가 만들고 있는 것이다.

3. Compile-time reactivity

대표: Svelte (1–4), Marko

프레임워크가 런타임을 아예 출하하지 않고, 대신 컴파일러가 평범해 보이는 코드를 정밀한 DOM 갱신으로 변환한다는 발상.

Svelte에서는 let count = 0; count += 1이라고 쓰면 컴파일러가 DOM 갱신 호출을 emit해 준다. 시그널 타입도 없고, useState도 없고, proxy도 없다. 출력 번들은 매우 작아서 Svelte 3은 대략 3KB로 출하된다.

대가는 컴파일러가 블랙박스가 된다는 점이다. 한 줄의 코드 동작이 컴파일러가 어떻게 instrumentation하느냐에 달려 있다. 잘 돌면 좋지만 안 돌면 당황한다. 특히 컴파일러가 보지 못하는 동적 패턴 — 예를 들어 루프 안에서 생성되는 state — 에서 문제가 된다.

Svelte 5는 조용히 이 싸움의 일부를 양보해서 runes를 도입했다. 시그널과 비슷한 명시적 reactive primitive다. compile-time only의 이상은 중간 복잡도를 넘어서면 밀어붙이기 어려웠다. 그러나 근본 아이디어 — “내 컴파일러는 프론트엔드 최적화의 기회다” — 는 옳고 충분히 활용되지 않았다.

자기 컴파일러를 가진 언어에게는 흥미로운 영토다. compile-time 접근은 내 언어가 원래 하려고 하는 macro / staged compilation 작업과 겹친다.

4. Web Components + tagged template

대표: Lit, FAST, Stencil

브라우저의 실제 프리미티브를 쓴다. Custom Elements, Shadow DOM, slot. 작은 라이브러리로 감싸 html\…`` 템플릿 리터럴을 주고, 템플릿을 한 번 파싱한 뒤 동적인 구멍만 갱신한다.

슬로건은 “브라우저가 이미 하고 있는 일을 다시 발명하지 말자”. Lit의 컴포넌트는 진짜 HTMLElement다. React에서도, Vue에서도, 바닐라에서도 쓸 수 있다 — 프레임워크의 프리미티브가 아니라 플랫폼의 프리미티브다.

이 패러다임은 공개 논의에서는 잘 안 보이지만 엔터프라이즈에서는 비중이 크다. Apple, Google, Adobe, IBM이 디자인 시스템에 Web Components를 쓴다. Lit의 번들 사이즈는 작고, 여러 스택을 가로질러 소비되는 컴포넌트 라이브러리를 출하한다면 “프레임워크 비의존”은 진지한 기능이 된다.

약점은 리액티비티가 얕다는 점이다. Lit은 @property 데코레이터로 필드를 reactive하게 만들 수 있지만, fine-grained reactivity라기보다 “슈가 붙은 명령형 DOM”에 가깝다. 작은 범위라면 괜찮다. 복잡한 state graph가 되면 더 원하게 된다.

5. Server-driven UI

대표: HTMX, Hotwire (Turbo + Stimulus), Phoenix LiveView, Blazor Server, Inertia.js

클라이언트는 dumb하다. HTML을 렌더한다. 인터랙션마다 요청을 보내고 서버가 HTML을 돌려준다 — 전체 페이지일 때도 있고, hx-target 같은 속성으로 DOM에 swap되는 조각일 때도 있다. LiveView와 Blazor Server는 WebSocket을 열어 두고 서버에서 부분 갱신을 실시간으로 push한다.

지난 몇 년간 변한 것은 기술이 아니다 — 서버 렌더 HTML은 JavaScript보다 오래되었다 — 그게 아니라, 많은 앱에게 그것이 정답이라는 인식이 퍼졌다는 점이다. HTMX는 특히 “프론트엔드의 복잡함은 선택의 결과이고, 선택하지 않을 수도 있다”라는 결집점이 되었다. 라이브러리 본체는 14KB이고, 나머지는 HTML과 기존 백엔드뿐이다.

언어 빌더에게는 압도적으로 쉬운 프론트엔드 이야기다. UI 프레임워크를 출하할 필요가 실은 없다. 서버 쪽 좋은 언어와 템플릿 이야기를 출하하면, 나머지는 HTMX나 LiveView 풍 속성이 처리한다. 인터랙션 모델은 “요청 → HTML 응답 → DOM swap”이 되고, 언어는 백엔드 모양 그대로 머물러도 된다.

대가는 모든 것이 왕복이라는 점이다. 오프라인은 안 된다. 낙관적 UI는 어렵다. CRUD형 제품에는 최고지만, 로컬처럼 느껴져야 하는 도구 — 드로잉 앱, IDE, 실시간 게임 — 에는 맞지 않는 선택이다.

6. FRP (Functional Reactive Programming)

대표: Elm, Cycle.js, 부분적 근사로서의 RxJS

UI를 시간에 따른 값으로 다룬다. 이벤트는 stream이 된다. stream은 map, filter, merge, switch로 합성 가능하다. 임의의 순간의 UI는 stream graph의 현재 상태의 함수다.

이것은 리액티비티의 학술 버전이다. 잘 작동하면 아름답고, 안 되면 잔인하다. Elm 커뮤니티는 더 제한된 방언을 다듬어냈다 — The Elm Architecture — 날것의 stream을 명시적인 Msg 타입과 update 함수로 바꿨고, 가르치기가 훨씬 쉬워졌다.

Elm과 일부 PureScript / OCaml 라이브러리 바깥에서는 순수 FRP가 시장을 잡지 못했다. 그러나 그 아이디어는 곳곳에 있다. 시그널은 본질적으로 FRP 문헌의 “behavior”이고, Solid의 의존 추적 모델은 90~2000년대 FRP 연구의 직계 자손이다.

ML 계열 언어에는 홈 코트 어드밴티지다. 타입 시스템이 stream 합성을 자연스럽게 다루고, 이펙트 시스템이 불순한 부분을 깔끔히 다루고, 결과 코드는 국소적으로 추론 가능함이 증명될 수 있을 정도로 명료해진다. 문제는 시장이다 — 프로덕션에서 FRP를 쓰고 싶어 하는 사람은 매우 적고, 쓰고 싶은 사람은 이미 Elm을 쓰고 있다.

7. 명령형 + 헬퍼

대표: jQuery, 바닐라 JS, Alpine.js

DOM 노드를 잡아서 바꾼다. 이벤트 리스너를 단다. 프레임워크를 출하하지 않는다.

이것을 “이미 지난 것”으로 분류하고 싶지만, 실상은 더 모호하다. 돌아가는 프로덕션 코드의 상당량 — 사내 도구, CMS 기반 페이지, Rails나 Django 앱 위에 얹힌 것들 — 은 지금도 어떤 형태로든 “헬퍼 라이브러리 붙은 명령형 DOM”이다. Alpine.js는 명시적으로 2020년대의 jQuery로 설계되었다. 몇 KB로, HTML에 속성만 뿌리면 리액티비티가 따라온다.

언어 빌더에게는 명령형 + 헬퍼의 길이 자연스러운 초기 단계이기도 하다. fine-grained reactivity는 공짜가 아니다. 처음 출하할 수 있는 것은 “WASM 모듈이 set_text 함수를 export하고, JS가 DOM에 다리를 놓는다”이다. 내 언어도 거기서 시작한다.

8. Canvas / WebGL / WebGPU

대표: Figma, Pixi.js, three.js, Excalidraw, Google Maps와 Earth의 일부

DOM을 완전히 건너뛴다. canvas를 받아서 픽셀을 그린다. 3D나 무거운 2D가 필요하면 WebGL이나 WebGPU를 쓰고 GPU에 일을 시킨다.

이것은 다른 패러다임과는 다른 게임이다. “프레임워크”가 되려는 게 아니라, 자체 UI 런타임을 만들고 있다. Figma의 텍스트 레이아웃, 선택, 히트 테스트, IME 처리 — 그 전부가 canvas 위에 있는 커스텀 코드다. 그들이 그렇게 하는 이유는 DOM이 병목이기 때문이다. Figma 규모에서 “브라우저에게 백만 노드 레이아웃을 시키자”는 불가능하고, “보이는 viewport를 60fps로 우리가 그리자”는 성립한다.

WebAssembly는 여기에 강한 적합성이 있다. canvas 기반 길은 기존 C++나 Rust 코드베이스를 이식하기에 DOM 기반 길보다 훨씬 친화적이기 때문이다. Figma는 잘 알려져 있듯 브라우저에 살고 있는 WASM C++ 애플리케이션이다.

내 언어에는 이것이 long tail의 옵션이다. WASM이 동작하고 언어가 WebGL과 대화할 수 있게 되면 드로잉 앱형 제품이 성립한다. 그러나 범용 web 프레임워크의 길은 아니다 — 특정 애플리케이션 클래스의 길이다.

9. Islands Architecture

대표: Astro, Iles, Fresh (Deno), Eleventy + Alpine

페이지 전체를 정적 HTML로 출하한다. 그리고 인터랙티브해야 하는 작은 부분 — 검색 박스, 카트 버튼, 댓글 폼 — 만 개별적으로 hydrate한다. 각 “island”는 독자적인 프레임워크 인스턴스로 돈다. 나머지는 그냥 HTML이고, JS가 손대지 않는다.

지난 몇 년간의 큰 트렌드 시프트 중 하나다. 깨달음은 콘텐츠 사이트 — 블로그, 문서, EC 리스트 — 에 SPA 모델은 과잉이었다는 점이다. 페이지의 대부분은 변하지 않는다. 왜 거기에 런타임을 출하하는가?

Astro가 이것을 구체화하고 출하 가능하게 했고, 그 모델은 널리 모방되었다. React Server Components는 같은 본능의 더 깊이 들어간 버전이다. UI 트리의 대부분은 인터랙티브할 필요가 없으니, 클라이언트에서 그 비용을 지불하지 말자.

언어 빌더에게 islands 모델이 흥미로운 이유는 “프레임워크”를 React적 의미로 만들 필요가 없기 때문이다. 정적 사이트 제너레이터와 작은 인터랙티브 컴포넌트를 임베드하는 방식을 만든다. 인터랙티브한 부분은 다른 어떤 패러다임을 써도 된다.

10. Resumable / Serializable (Qwik)

대표: Qwik

최전선. 앱 전체를 서버에서 렌더한다. HTML뿐 아니라 JavaScript의 state — 클로저 캡처, 이벤트 핸들러 — 까지 HTML에 그대로 시리얼라이즈한다. 클라이언트는 HTML을 로드한 순간 인터랙티브해진다. hydration 없음, JS 실행 없음, “프레임워크 로드” 없음. 무언가를 클릭했을 때 그 특정 버튼의 핸들러만 lazy load한다.

슬로건은 “앱 크기와 무관하게 일정 시간에 interactive해진다”. 5MB Qwik 앱은 50KB와 같은 속도로 시작한다. 클라이언트가 필요해질 때까지 대부분을 실행하지 않기 때문이다.

구현은 영웅적인 컴파일러다. Qwik은 코드를 수천 개의 작은 청크로 쪼개고, 각각을 개별적으로 fetch 가능하게 만든다. 모든 클로저가 시리얼라이즈 가능한 객체가 된다. 필요한 컴파일러 통합 수준이 너무 높아서, 현재로서는 Qwik은 Qwik만의 것이다 — 다른 프레임워크는 이 묘기를 재현하지 못했다.

내 언어에는 이것이 가장 야심 찬 target이다. 내가 쥐고 있는 컴파일러 통제력은 resumability를 시도하기에 충분하다. 다만 엔지니어링 비용이 크고 관객은 작다.

11. State machine driven

대표: XState, Robot, Stately.ai

UI는 유한 상태 기계다. 상태 전이를 명시적으로 선언한다. view는 현재 상태에서 도출된다. 불가능한 상태는 표현 불가능해진다.

이것이 “프레임워크”로 나타나는 경우는 드물다. 보통은 React나 Solid 위에 얹히는 복잡한 상태 흐름 관리 레이어다 — 마법사, 체크아웃, 동영상 플레이어 UI 등 “사용자가 실제로 처할 수 있는 상태가 무엇인가”가 “이게 어떻게 보이는가”보다 중요한 모든 곳.

합 타입과 패턴 매칭이 있는 ML 언어에서는 상태 기계가 공짜로 떨어진다. type State = Idle | Loading | Loaded of Data | Error of Reason과 update : State → Msg → State는 거의 The Elm Architecture이고, 자연스러운 fit이다.

12. Functional UI (ML 계열)

대표: Elm, Halogen (PureScript), Mint, Bonsai (OCaml, Jane Street 제작)

The Elm Architecture를 일반화한 것. Model이 모든 state를 가진다. view : Model → Html Msg가 그것을 렌더한다. update : Msg → Model → Model이 변경을 다룬다. 부작용은 update에서 반환되는 값(Cmd)으로 표현되고, 런타임이 실행한다.

이것은 ML 커뮤니티의 UI에 대한 답이고, “원칙적인 버전”이라는 주장에 가장 강하게 설 수 있다. Jane Street 내부에서 무겁게 쓰이고 있는 Bonsai는 OCaml로 대규모·실용·사내 도구 등급의 UI를 만들 수 있다는 것을 증명했다. Elm의 “런타임 예외 0” 주장은 마케팅이 아니다 — 타입 시스템이 JavaScript를 괴롭히는 종류의 버그를 통째로 잡아낸다, 이건 사실이다.

시장은 작다. Elm의 개발 속도는 느려졌고, PureScript는 학술 쪽에 머물러 있으며, OCaml의 web 프론트엔드는 거의 Bonsai 형태다. 그러나 내가 만들고 있는 것 같은 언어에는 이게 자연스러운 거처에 가장 가깝다. 내가 멋부리지 않고 그저 Bonsai의 설계를 내 언어로 옮기는 것만으로도 이미 일관되고 정당화 가능한 프론트엔드 이야기가 된다.

최적화의 5축

12개의 패러다임이 있고 승자가 없는 이유는 각자 다른 것을 최적화하고 있기 때문이다.

• 런타임 속도: 시그널(Solid, Leptos), compile-time(Svelte). state 변경당 작업량이 적어 벤치마크에서 이긴다.
• 번들 크기: compile-time(Svelte), server-driven(HTMX). 출하하는 코드가 적어 이긴다.
• Time-to-interactive: resumability(Qwik), islands(Astro), server-driven. 클라이언트가 쓸 만해지기 전에 실행해야 할 양이 적어 이긴다.
• 개발자 경험: VDOM(React), functional UI(Elm). React는 생태계 규모와 채용 용이성에서, Elm은 내부 일관성과 버그 적음에서 이긴다.
• 타입 안전 / 정확성: functional UI(Elm, Bonsai), FRP, 상태 기계. 불가능한 상태가 출하 전에 사라지므로 이긴다.

한 축을 잡으면 좋은 프레임워크다. 두 축이면 훌륭하다. 5축 전부를 잡은 것은 없다 — 목표들이 서로 싸우기 때문이다.

2026년에 실제로 움직이고 있는 것

상승 중: 시그널. 언어를 가로질러, 프레임워크를 가로질러. Angular가 채택했다. Vue는 이미 거기 있다. Svelte 5는 순 compile-time에서 물러나 시그널 쪽으로 다가갔다. Preact는 가지고 있다. React Compiler조차도 시그널 전제로 쓰이지 않은 코드에 대해 시그널 같은 것을 가짜로 만들려 하고 있다. 2026년에 신규 프로젝트의 기본 리액티비티 모델을 고른다면 시그널이 명백한 답이다.

상승 중: 진지한 선택지로서의 server-driven UI, 레트로가 아니라. HTMX에는 진짜 채용자들이 나왔다. Phoenix의 LiveView는 성숙해졌다. Inertia가 “Laravel형 백엔드”와 “React형 프론트엔드”를 다리 놓았다. 많은 팀이 자기 제품에 대해 SPA 모델이 과잉이었음을 인정하기 시작했다.

천천히 상승: islands와 resumability. 둘 다 툴링 성숙도에 묶여 있지만, 근본 본능 — “클라이언트가 앱 전체일 필요는 없다” — 은 널리 옳다.

정체 또는 하락: 순 VDOM. React 자신이 원래의 VDOM-only 이야기에서 벗어나고 있다. 현재 방향은 Server Components + Compiler이고, 이는 2013년판 React보다 “compile-time + server-driven”에 가깝다.

니치하지만 안정: FRP, functional UI, 상태 기계. 10년간 늘 거기에 있어 왔다 — 작은 커뮤니티, 강한 내부 논리, 브레이크아웃의 순간은 없음.

내 언어에게 무엇을 의미하는가

내가 만드는 것은 ML 계열의 언어로, 이펙트 핸들러, capability passing, region 기반 메모리, 작은 표면적을 가진다. 질문은 이 12 패러다임 중 내가 설득력 있게 떠받칠 수 있는 것은 무엇이고, 가장 먼저 어떤 것을 향해 만들어야 하는가이다.

언어가 이미 할 수 있는 것에 가장 잘 맞는 패러다임:

• Fine-grained reactivity(시그널) — capability는 시그널이다. 함수 안에서 시그널을 읽는 일은 내 타입 시스템이 이미 추적하고 있는 이펙트 그 자체다. 가장 강한 기계적 fit.
• Functional UI(Elm / Bonsai) — 언어는 이미 ML 계열이다. Bonsai 풍 아키텍처는 내 언어로 OCaml을 쓰는 감각일 것이다. 만드는 것도 가르치는 것도 싸다.
• 상태 기계 — 합 타입과 패턴 매칭이 있어 상태 기계는 공짜로 떨어진다. “XState”를 만들 필요가 없다 — 언어에 이미 프리미티브가 있다.
• Compile-time reactivity(Svelte 풍) — 컴파일러를 쥐고 있다. 손이 많이 가지만 가장 “언어 고유”의 각도다.

약한 fit의 패러다임:

• VDOM — 쓰레기를 만들고, 내 region 할당기와 싸우고, 내 타입 시스템의 강점을 쓰지 않는다. 쫓을 가치 없음.
• 순 Canvas/WebGL UI — 성립하지만 별개의 제품이다, 프론트엔드 프레임워크가 아니다.
• Resumability — 원리적으로는 가능하지만 당분간 구현 비용이 이득을 능가한다.

실제로 할 것 같은 순서:

1. WASM target이 브라우저에서 텍스트를 띄울 수 있을 정도로 안정화. 프레임워크 없음.
2. 명령형 + 헬퍼 레이어 — wasm-bindgen 상당의 바인딩을 통한 직접 DOM 액세스. 카운터 앱이 동작한다.
3. 시그널 도입. 이것이 첫 번째 진짜 설계 판단. capability passing이 시그널 구독에 매핑된다. Solid 같으리라 예상한다, 다만 타입이 더 붙어서.
4. 선언적 DOM 구축 — 아마 JSX보다 Lit에 가까운 tagged template 스타일. compile-time 템플릿 파싱을 원한다.
5. 컴포넌트 합성. 여기서 Bonsai의 설계를 다시 확인하고 가까이 따라갈지 결정한다.
6. 지루하지만 필요한 것들. 라우팅, 폼, fetch, 빌드 툴링.

이건 대략 6개월~2년의 사이드 프로젝트 규모다. 초기 단계는 글로 낼 수 있을 만큼 작다. 후기 단계는 언어가 실제 앱에서 쓸 가치가 있는 상태에 이르는지에 달려 있고, 그것은 별개의, 더 어려운 질문이다.

마치며

오늘 프론트엔드 스택을 고르고 있어서 이걸 읽고 있다면, 짧은 결론은 이렇다. 시그널이 지금의 기본이고, server-driven은 사람들이 생각하는 것보다 더 자주 옳고, 순 VDOM은 더 이상 똑똑한 선택이 아니다.

자작 언어를 만들면서 프론트엔드 이야기까지 손을 댈지 고민 중이라면 — 손대도 좋다, 다만 언어를 먼저 제대로 만들고, 언어가 이미 가진 프리미티브와 맞물리는 패러다임을 골라야 한다. 언어의 설계가 다른데 React를 이식할 이유는 없다.

실제 구현 단계는 진행에 따라 별도 노트로 적을 예정.