
자바스크립트는 원래 '한 줄로 일하는' 언어예요
자바스크립트를 좀 다뤄본 분들은 'JS는 싱글스레드(single-thread)'라는 말을 들어보셨을 거예요. 이게 뭐냐면, 자바스크립트는 기본적으로 한 번에 한 가지 일만 처리한다는 뜻이에요. 식당에 요리사가 딱 한 명 있어서 주문을 하나씩 순서대로 처리하는 것과 비슷해요. 대신 이 요리사가 '이벤트 루프(event loop)'라는 영리한 방식으로, 오래 걸리는 일은 잠깐 제쳐두고 다른 주문을 받는 식으로 효율을 짜내는 거죠. 그래서 평소엔 큰 문제가 없어요. 그런데 영상 인코딩이나 대용량 이미지 처리처럼 CPU를 빡세게 오래 쓰는 작업이 들어오면, 요리사 한 명으로는 한계가 분명하거든요. 이럴 때 '진짜로 여러 명이 동시에 일하면 안 되나?'라는 갈증이 생겨요.
바로 이 지점에서, Node.js의 대안으로 떠오른 자바스크립트 런타임 'Bun'이 흥미로운 시도를 하고 있어요. 자바스크립트 엔진에 '공유 메모리 스레드(shared-memory threads)'를 추가하는 작업을 진행 중이거든요.
기존 방식의 한계부터 짚어볼게요
사실 지금도 자바스크립트로 병렬 처리를 아예 못 하는 건 아니에요. 브라우저에는 '웹 워커(Web Worker)', Node에는 'worker_threads'라는 게 있어서 별도의 일꾼(스레드)을 띄울 수 있어요. 그런데 여기엔 큰 불편함이 하나 있어요. 이 일꾼들끼리는 보통 데이터를 '복사해서' 주고받아요. 메시지를 한쪽에서 다른 쪽으로 통째로 베껴서 전달하는 방식이죠. 데이터가 작으면 괜찮은데, 수백 메가바이트짜리 큰 데이터를 다룰 땐 이 복사 비용이 어마어마해져요. 옆자리 동료에게 자료를 보여주려고 매번 문서 전체를 복사해서 건네는 셈이니까요.
물론 SharedArrayBuffer라는, 메모리를 공유할 수 있는 특수한 장치가 있긴 해요. 하지만 이건 숫자 배열 같은 단순한 데이터만 공유할 수 있어서, 복잡한 객체를 자유롭게 공유하기엔 한계가 뚜렷해요.
Bun이 하려는 건 '메모리를 통째로 공유'하는 거예요
Bun은 구글의 V8 엔진을 쓰는 Node와 달리, 애플 사파리(웹킷)의 엔진인 'JavaScriptCore(JSC)'를 사용해요. 이번 작업은 이 JSC를 직접 수정(fork)해서, 여러 스레드가 같은 메모리 공간(힙, heap)을 직접 공유하게 만드는 거예요. 복사 없이, 여러 일꾼이 같은 데이터를 동시에 보고 만질 수 있게 하는 거죠.
근데 이게 말처럼 쉬운 게 아니에요. 가장 큰 난관은 'GC(가비지 컬렉터, 쓰레기 수거기)'예요. 이게 뭐냐면, 자바스크립트가 더 이상 안 쓰는 메모리를 자동으로 청소해주는 기능인데요. 여러 스레드가 같은 메모리를 동시에 건드리는 상황에서 이 청소부가 안전하게 일하게 만드는 게 정말 까다로워요. 한 스레드가 쓰고 있는 메모리를 다른 쪽 청소부가 '안 쓰는 줄 알고' 치워버리면 프로그램이 그대로 터지거든요. 사실 V8이든 JSC든 원래는 '하나의 격리 공간(isolate)당 하나의 스레드'를 전제로 설계되어 있어서, 이 전제를 깨는 건 엔진 심장부를 뜯어고치는 대공사예요. Bun이 자체 엔진을 직접 손볼 수 있다는 점이 이런 과감한 시도를 가능하게 하는 거죠.
다른 언어, 다른 런타임과 비교하면
Java나 Go, Rust 같은 언어는 진작부터 여러 스레드가 메모리를 공유하며 동시에 일하는 게 기본이에요. 그래서 CPU를 풀로 쓰는 작업에 강하죠. 반면 자바스크립트는 태생이 브라우저용이라 이런 모델을 일부러 피해 왔어요. Node는 worker_threads로 우회했고, 클라우드플레어 같은 곳은 아예 가벼운 격리 공간을 잔뜩 띄우는 방식을 택했고요. Bun의 이번 시도는 '자바스크립트도 다른 언어처럼 제대로 된 공유 메모리 멀티스레드를 갖자'는, 꽤 야심 찬 방향인 거예요. 자바스크립트의 오래된 약점을 정면으로 건드리는 셈이죠.
한국 개발자에게 주는 시사점
만약 이게 안정적으로 자리 잡으면, 그동안 '이건 자바스크립트로는 좀 무리지'라고 여겼던 CPU 집약적인 작업들, 예컨대 대용량 데이터 가공, 이미지·영상 처리, 암호화 연산 같은 걸 JS 안에서 훨씬 효율적으로 병렬 처리할 수 있게 돼요. 백엔드를 Node나 Bun으로 짜는 분들에겐 선택지가 넓어지는 거죠.
다만 한 가지 꼭 짚고 싶어요. 이건 아직 '진행 중인 제안(PR)' 단계예요. 정식 기능으로 들어간다는 보장도 없고, 멀티스레드 공유 메모리는 잘못 쓰면 디버깅이 악몽이 되는 '경합 조건(race condition)' 같은 문제를 달고 다녀요. 그러니 지금 당장 실무에 쓸 건 아니고, '자바스크립트 생태계가 이런 방향으로 움직이고 있구나' 하고 흐름을 읽어두는 게 맞아요.
한줄 정리: Bun이 자바스크립트 엔진의 심장을 뜯어 진짜 멀티스레드를 심으려 하고 있어요. 성공한다면 'JS는 싱글스레드'라는 오랜 상식이 흔들릴 수도 있죠. 여러분은 자바스크립트에 이런 진짜 멀티스레드가 꼭 필요하다고 보세요, 아니면 지금의 단순함이 오히려 JS의 장점이라고 생각하세요?
🔗 출처: Hacker News
TTJ 코딩클래스 정규반
월급 외 수입,
코딩으로 만들 수 있습니다
17가지 수익 모델을 직접 실습하고, 1,300만원 상당의 자동화 도구와 소스코드를 받아가세요.
"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"
실제 수강생 후기- 비전공자도 6개월이면 첫 수익
- 20년 경력 개발자 직강
- 자동화 프로그램 + 소스코드 제공