JavaScript를 Erlang 슈퍼비전 트리 안에서 돌린다고? QuickBEAM이 여는 새로운 가능성

두 세계의 만남: JavaScript + Erlang/OTP

JavaScript와 Erlang, 이 두 언어를 한 문장에 넣으면 뭔가 어색하죠? 하나는 웹 브라우저에서 태어나 세상에서 가장 널리 쓰이는 언어가 됐고, 다른 하나는 통신 장비 위에서 "절대 죽지 않는 시스템"을 만들기 위해 태어난 언어거든요. 그런데 이 둘을 결합하는 오픈소스 프로젝트가 등장했어요. 바로 QuickBEAM인데요, JavaScript 코드를 Erlang/OTP의 슈퍼바이저(supervisor) 프로세스 아래에서 실행할 수 있게 해주는 도구예요.

Elixir 생태계의 elixir-volt 팀이 만든 이 프로젝트는, 쉽게 말하면 "JavaScript로 작성한 비즈니스 로직을 Erlang이 감시하고 관리하는 구조로 돌리겠다"는 건데요. 이게 왜 의미 있는지, 차근차근 살펴볼게요.

Erlang/OTP 슈퍼비전 트리가 뭐길래

먼저 Erlang/OTP의 핵심 개념을 좀 알아야 이 프로젝트가 왜 흥미로운지 이해할 수 있어요. Erlang에는 슈퍼비전 트리(Supervision Tree)라는 게 있는데요, 이게 뭐냐면 프로세스들을 트리 구조로 관리하면서, 어떤 프로세스가 죽으면 자동으로 다시 살려주는 시스템이에요.

일상적인 비유를 들어볼게요. 놀이공원에서 관리자가 놀이기구들을 감독하고 있다고 생각해보세요. 한 놀이기구가 고장 나면, 관리자가 바로 알아차리고 수리하거나 다시 가동시키죠. 이 관리자가 바로 슈퍼바이저예요. 그리고 관리자들도 더 상위의 관리자가 감독하는 구조, 이게 슈퍼비전 트리인 거예요. 덕분에 Erlang으로 만든 시스템은 일부가 죽어도 전체가 무너지지 않고, 알아서 복구돼요. WhatsApp이 수십억 메시지를 안정적으로 처리할 수 있었던 것도 이 구조 덕분이에요.

Elixir도 Erlang VM(BEAM) 위에서 동작하니까 같은 혜택을 누리는데요, 문제는 이 멋진 장애 허용(fault-tolerance) 능력이 BEAM 위의 언어들에만 국한됐다는 거예요.

QuickBEAM은 어떻게 동작하나요

QuickBEAM의 핵심 아이디어는 간단해요. JavaScript 런타임을 BEAM 프로세스 안에 내장(embed)하는 거예요. 각 JavaScript 실행 단위가 Erlang의 프로세스로 래핑되고, 이 프로세스가 슈퍼비전 트리에 등록되는 구조죠.

그러니까 JavaScript 코드가 예외를 던지거나 무한 루프에 빠지더라도, Erlang 슈퍼바이저가 해당 프로세스를 감지하고 정해진 전략에 따라 재시작해줄 수 있어요. "한 번 죽으면 다시 살리기", "같은 그룹 전체를 다시 시작하기" 같은 전략을 슈퍼바이저 레벨에서 설정할 수 있거든요.

기술적으로 보면, JavaScript 엔진을 NIF(Native Implemented Function)나 포트(Port)를 통해 BEAM에 연결하는 방식일 텐데요, 이렇게 하면 JavaScript 코드가 BEAM의 스케줄러와 협력해서 동작할 수 있어요. BEAM은 원래 수십만 개의 경량 프로세스를 동시에 돌리는 데 특화돼 있으니까, JavaScript 워커들도 이 스케줄링의 혜택을 받을 수 있는 거죠.

특히 Elixir 프로젝트에서 사용할 때 매력적인 부분은, 기존 Elixir 애플리케이션의 슈퍼비전 트리에 JavaScript 프로세스를 자연스럽게 끼워 넣을 수 있다는 점이에요. Elixir로 작성된 웹 서버가 있고, 특정 데이터 처리 로직만 JavaScript로 돌리고 싶다면, 그 JavaScript 로직을 supervised 프로세스로 추가하면 되는 거예요.

왜 JavaScript를 BEAM 위에서 돌리려 하는 걸까

"그냥 Elixir로 다 쓰면 되지 않나?"라는 의문이 들 수 있어요. 맞는 말이긴 한데, 현실은 좀 다르거든요.

첫째, JavaScript 생태계의 라이브러리를 활용하고 싶은 경우가 있어요. npm에는 수백만 개의 패키지가 있는데, 이 중 상당수는 다른 언어 생태계에 동등한 대안이 없어요. 예를 들어 특정 데이터 파싱 라이브러리나, 특수한 암호화 라이브러리 같은 것들이요.

둘째, 팀 구성의 문제예요. 많은 회사에서 백엔드를 Elixir로 운영하면서도, 프론트엔드 팀은 JavaScript/TypeScript를 쓰잖아요. 서버 사이드 렌더링(SSR)이나 공유 검증 로직처럼, 프론트와 백 양쪽에서 같은 코드를 돌려야 하는 상황이 있는데요, 이때 Elixir 서버 안에서 JavaScript를 직접 실행할 수 있으면 아키텍처가 훨씬 단순해져요.

셋째, 점진적 마이그레이션 시나리오예요. Node.js 기반 시스템을 Elixir로 옮기는 과정에서, 모든 걸 한 번에 재작성하는 건 현실적으로 어렵잖아요. JavaScript 로직을 BEAM 위에서 supervised 프로세스로 먼저 옮기고, 시간이 나면 하나씩 Elixir로 전환하는 전략을 쓸 수 있어요.

비슷한 시도들과 비교해보면

사실 다른 언어를 BEAM 위에서 돌리려는 시도는 QuickBEAM이 처음이 아니에요. Lumen 프로젝트는 Erlang/Elixir 코드를 WebAssembly로 컴파일하려는 시도였고, Caramel은 OCaml을 BEAM 바이트코드로 컴파일하는 프로젝트였어요. Gleam은 BEAM 위에서 돌아가는 타입 안전 언어로 꽤 인기를 얻고 있고요.

하지만 JavaScript를 직접 BEAM의 supervised 프로세스로 돌리는 접근은 좀 독특해요. Gleam이나 Caramel은 "BEAM에 맞는 새 언어를 만들자"는 쪽이라면, QuickBEAM은 "이미 있는 JavaScript를 BEAM의 장점과 결합하자"는 쪽이거든요. 실용적인 관점에서 보면 후자가 진입 장벽이 훨씬 낮아요.

Node.js 생태계에서도 비슷한 문제를 풀려는 시도가 있어요. PM2 같은 프로세스 매니저가 Node 프로세스를 감시하고 재시작해주긴 하지만, Erlang의 슈퍼비전 트리처럼 세밀하고 계층적인 관리와는 차원이 달라요. Erlang의 "let it crash" 철학, 즉 "죽게 놔두고 깔끔하게 다시 시작하자"는 접근은 수십 년간 검증된 방법론이니까요.

한국 개발자에게 어떤 의미가 있을까

국내에서도 Elixir와 Phoenix 프레임워크를 사용하는 팀이 조금씩 늘고 있어요. 특히 실시간 기능이 중요한 서비스, 예를 들어 채팅이나 라이브 스트리밍 백엔드에서 Elixir를 채택하는 사례가 있는데요, 이런 팀에서 QuickBEAM은 꽤 실용적인 도구가 될 수 있어요.

당장 프로덕션에 쓰기엔 프로젝트 성숙도를 좀 더 지켜봐야 하겠지만, 몇 가지 실험해볼 만한 시나리오가 있어요. Elixir 기반 서비스에서 SSR을 직접 처리하고 싶을 때, 또는 JavaScript로만 제공되는 라이브러리를 서버 사이드에서 써야 할 때요. 외부 Node.js 서비스를 별도로 운영하는 대신 BEAM 안에서 직접 돌리면 인프라 복잡도를 줄일 수 있거든요.

그리고 Erlang/OTP를 아직 접해보지 않은 분들에게도 이 프로젝트는 좋은 학습 소재가 될 수 있어요. 익숙한 JavaScript로 코드를 작성하면서 슈퍼비전 트리의 장애 복구 메커니즘을 체험해볼 수 있으니까요. "프로세스가 죽으면 어떻게 되는지" 직접 눈으로 보면, 분산 시스템의 안정성에 대한 감각이 확 달라질 거예요.

마무리

QuickBEAM은 "세상에서 가장 많이 쓰이는 언어"와 "세상에서 가장 안정적인 런타임"을 연결하려는 흥미로운 실험이에요. JavaScript의 거대한 생태계와 Erlang/OTP의 검증된 장애 허용 아키텍처를 동시에 활용할 수 있다면, 그 조합의 가치는 상당하겠죠.

여러분은 다른 런타임의 장점을 빌려오는 이런 하이브리드 접근에 대해 어떻게 생각하시나요? 실무에서 Elixir와 JavaScript를 함께 써야 했던 경험이 있다면, 그때 이런 도구가 있었으면 어땠을지 이야기해주세요.