처리중입니다. 잠시만 기다려주세요.
TTJ 코딩클래스
정규반 단과 자료실 테크 뉴스 코딩 퀴즈
테크 뉴스
Hacker News 2026.06.21 36

자바스크립트에 '진짜 멀티스레드'를? Bun이 JavaScriptCore에 공유 메모리 스레드를 심으려는 이유

Hacker News 원문 보기
자바스크립트에 '진짜 멀티스레드'를? Bun이 JavaScriptCore에 공유 메모리 스레드를 심으려는 이유

자바스크립트는 원래 '한 줄로 일하는' 언어예요

자바스크립트를 좀 다뤄본 분들은 '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만원 상당의 자동화 도구와 소스코드를 받아가세요.

144+실전 강의
17개수익 모델
4.9수강생 평점
정규반 자세히 보기

"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"

실제 수강생 후기
  • 비전공자도 6개월이면 첫 수익
  • 20년 경력 개발자 직강
  • 자동화 프로그램 + 소스코드 제공

매일 AI·개발 뉴스를 받아보세요

주요 테크 뉴스를 매일 아침 이메일로 전해드립니다.

스팸 없이, 언제든 구독 취소 가능합니다.