들어가며
지난 10여 년 동안 자바스크립트(JavaScript)는 브라우저라는 원래의 영역을 훌쩍 넘어, 클라우드·에지(Edge)·스마트폰·스마트TV·마이크로컨트롤러까지 사실상 모든 곳에서 실행되는 언어가 되었습니다.
이 변화의 배경에는 수많은 런타임(runtime) 과 엔진(engine) 의 등장이 있었죠.
이 글에서는 최근 10년간의 런타임 확산 흐름을 정리하고, 왜 "단 하나의 최고의 런타임"이 존재할 수 없는지 살펴보겠습니다.
1. 에지 컴퓨팅과 런타임 전쟁
- 초기: 아카마이(Akamai)가 2002년에 Java, .NET 기반의 에지 컴퓨팅을 제시했지만, JS는 한참 뒤에 합류했습니다.
- Node.js (2009) → AWS Lambda (2014) → Lambda@Edge (2016-2017): 비로소 자바스크립트가 서버리스 환경에서 쓰이기 시작.
- Cloudflare Workers (2017): Service Worker API를 기반으로 한 경량 런타임. “에지 런타임을 직접 상품화한 첫 사례” 라는 점에서 의미가 큼.
이후:
- Deno (2018) → Deno Deploy
- Bun (2022) → JavaScriptCore 기반, 서버리스·CI·에지 진출
- Wasmer Edge (2023) → SpiderMonkey 기반
- AWS LLRT (2024) → QuickJS 기반, 저지연 특화
👉 포인트: 단순히 Node.js와 V8의 독무대가 아니라, 상황에 맞는 엔진 선택이 유행처럼 번지기 시작했습니다.
2. 마이크로컨트롤러: 극한의 제약 환경
- MCU(마이크로컨트롤러)는 3센트짜리 칩, 수백 바이트 메모리 같은 극저자원 환경.
- Node.js는 절대 불가능 → 초경량 엔진 등장:
- Duktape, Espruino, mjs (2013)
- JerryScript (2014) → IoT.js, Microlattice.js 기반
- Moddable XS (2018)
- elk (2021) → 100바이트 수준으로 동작!
👉 의미: "돈이 되지 않더라도, 자바스크립트를 어디서든 돌리고 싶다"는 순수한 엔지니어링 열망.
3. 폴리글랏 엔진: 언어 간 경계 허물기
- Rhino (1997): Java 기반 JS 엔진, JVM 위에서 동작.
- Nashorn (2014) → Graal.js (2018): JVM + GraalVM 기반, Node.js SDK까지 지원.
- .NET, Python, Ruby, Go, Rust, Zig 등 각 언어별로 JS 엔진이 속속 등장.
- 심지어 자바스크립트로 구현된 JS 엔진까지:
- Narcissus (2007, Brendan Eich 제작)
- Porffor (2023): JS로 작성된 JS→WASM 컴파일러
👉 포인트: 자바스크립트를 다른 언어 생태계와 연결하려는 수요가 막강하다는 증거.
4. 네이티브 앱과 JS 런타임
자바스크립트는 GUI 앱 개발에 강점이 있어서 모바일·데스크톱·TV까지 빠르게 확산했습니다.
WebView 기반
- PhoneGap (2009) → Cordova → Ionic → Capacitor
- Electron (2013~) → Slack, Discord, VSCode 등 데스크톱 앱 시장 장악.
- Smart TV: 삼성 Tizen, Fire TV, HbbTV, webOS 등 수많은 플랫폼이 WebView와 JS 기반 앱 실행.
React Native (2015~)
- 모바일: iOS/Android 동시 지원, JS ↔ 네이티브 브릿지 구조.
- Hermes 엔진 (2019): 모바일 특화 엔진, 빠른 시작·메모리 최적화.
- 현재 상위 100 iOS 앱 중 30개가 React Native 기반.
- 데스크톱은 상대적으로 약세, 여전히 Electron이 우위.
- 스마트TV 영역에서는 NFL, Bloomberg, Crunchyroll 같은 앱들이 React Native 활용.
NativeScript (2014~)
- V8, JSC, QuickJS 등 다양한 엔진 지원.
- 최근에는 Node-API 기반 엔진-무관 네이티브 바인딩으로 확장.
Node.js
- 모바일용 포팅도 있었으나 제한적.
- 데스크톱에서는 Electron 외 GUI 시도 많았지만 메인스트림엔 실패.
5. 결론: 왜 단 하나의 런타임은 없을까?
자바스크립트 런타임은 각기 다른 상황에 최적화됩니다:
- 에지: 빠른 시작과 지연 최소화
- 마이크로컨트롤러: 메모리·전력 극소 사용
- 네이티브 앱: 시스템 API 접근과 GUI 성능
- 폴리글랏: 다른 언어 생태계와의 연결성
즉, 시작 속도, 실행 속도, 번들 크기, 네이티브 API 접근성 같은 요소가 서로 충돌하기 때문에, "모든 상황에 최적"인 단일 런타임은 존재할 수 없습니다.
하지만 바로 이 다양성 덕분에 JS는 모든 곳에서 가장 안전한 선택지가 되었고, 앞으로도 "가장 범용적인 프로그래밍 언어" 자리를 유지할 것입니다.
원문 - The many, many, many JavaScript runtimes of the last decade