주피터 노트북은 과학자와 학생, 엔지니어가 코드를 조금 쓰고 실행한 뒤 결과를 살피며 아이디어를 다듬는 대화형 도구다. 그런데 전통적인 방식에서는 노트북 하나마다 서버나 사용자 PC에서 파이썬 프로세스가 돌아가야 했다. JupyterLite는 이 구조를 바꿔, WebAssembly를 이용해 커널을 브라우저 안에서 직접 실행한다. 그 결과 정적 웹사이트만으로도 완전한 계산 환경을 제공할 수 있고, 사용자마다 서버를 붙이지 않아도 되니 문서·교육·데모용 노트북을 대규모로 공유하기가 훨씬 쉽고 저렴해진다.
다만 브라우저 기반 과학 파이썬 생태계에는 오랫동안 빠진 조각이 하나 있었다. 바로 JIT 컴파일러 넘바(Numba)다. QuantStack은 이번에 emscripten-forge와 JupyterLite 위에서 넘바가 브라우저 안에서 완전히 동작하는 첫 버전을 공개했다. 소개된 예제에서 넘바는 WebAssembly 환경에서 표준 파이썬 대비 약 250배(249배) 빨라졌는데, 네이티브 환경의 약 90배보다 오히려 상대적 이득이 컸다. 브라우저에서는 파이썬 인터프리터 오버헤드를 걷어내는 효과가 더 크게 나타나기 때문이라는 설명이다.
왜 브라우저에서 넘바가 어려웠나
넘바를 브라우저에 올리는 일이 어려웠던 이유는 단순히 패키징이 안 되어 있어서가 아니다. 넘바는 컴파일러이며, 그 실행 모델은 llvmlite와 LLVM에 의존한다. 네이티브 환경에서는 생성된 기계어를 실행 가능한 메모리에 얹어 곧바로 호출할 수 있지만, 브라우저는 보안상 애플리케이션이 실행 가능한 메모리를 생성하거나 수정하는 것을 의도적으로 막는다. 이 요청은 2018년 numba/numba#3284 이슈에서 이미 등장했고, Pyodide 커뮤니티도 pyodide-recipes#192에서 패키징 난제를 추적해 왔다. 결국 필요한 것은 빌드 설정 수정이 아니라, WebAssembly를 이해하는 llvmlite용 실행 엔진, 브라우저 프로세스 안에서 LLVM 링커를 호출하는 방법, 그리고 생성된 코드를 지속되는 파이썬 런타임에 동적으로 적재하는 지원이었다.
해법의 실마리는 이전 작업에 있었다. QuantStack은 앞서 Xeus-Cpp를 통해 Clang-Repl C++ 인터프리터를 브라우저로 가져오면서, LLVM의 통상적인 JIT 방식을 쓸 수 없는 WebAssembly 환경을 위한 별도의 실행 모델을 만들었다. 각 입력이 실행 중인 프로그램을 점진적으로 확장하고, 새로 적재된 사이드 모듈이 메인 애플리케이션과 메모리를 공유하며, 그 심볼을 이후 모듈이 참조할 수 있게 하는 구조다. 같은 아키텍처를 llvmlite에 적용할 수 있다는 것이 이 프로젝트의 핵심 착안이었다.
파이프라인은 어떻게 작동하는가
새 엔진은 llvmlite가 만든 LLVM 모듈을 받아 WebAssembly 객체를 내보내고, LLVM 링커 LLD를 인프로세스 재진입 드라이버로 호출한 뒤 결과를 Emscripten 사이드 모듈로 적재한다. 브라우저 안에서는 wasm-ld를 별도 프로세스로 띄울 수 없기 때문에 LLD를 프로세스 내에서 쓰는 것이 필수적이다. 사용자가 평범한 파이썬 함수에 @jit 또는 @njit을 붙이면, 넘바는 바이트코드를 읽어 자체 중간 표현(IR)을 만들고 타입을 추론한 뒤 llvmlite를 통해 LLVM IR로 낮춘다. 네이티브라면 이 결과가 LLVM JIT로 넘어가지만, JupyterLite에서는 새 WebAssembly 엔진으로 넘어가 컴파일·링크되고 Xeus-Python 커널에 적재되어 함수 테이블을 통해 노출된다. 하나의 사용자 함수가 여러 모듈을 필요로 할 수 있어, 넘바 런타임(NRT) 같은 지원 코드부터 컴파일러 생성 헬퍼, 사용자 함수와 CPython 호출용 래퍼까지 심볼 해석 순서에 맞춰 차례로 적재된다.
여기에 @njit(cache=True)를 통한 영속적 객체 캐싱도 더해졌다. 캐시가 켜진 함수를 다음 브라우저 세션에서 다시 쓰면, 넘바는 JupyterLite의 영속 파일시스템에서 컴파일 데이터를 복원하고 llvmlite는 해당 WebAssembly 객체를 재사용하면서 새 커널 프로세스에 사이드 모듈을 다시 링크해 적재한다. 즉 넘바를 흉내 낸 인터프리터도, 노트북 뒤에 숨은 원격 서비스도 아닌 진짜 넘바 컴파일과 실행이 브라우저에서 이뤄진다는 뜻이다. 배포 측면은 emscripten-forge가 담당한다. conda/mamba와 conda-forge 위에 세운 이 WebAssembly 소프트웨어 배포판에는 NumPy·SciPy·LLVM·Clang·LLD 등 과학 스택이 포함되며, 이제 넘바도 등록되어 mamba로 손쉽게 설치할 수 있다.
실무자에게 주는 의미와 한계
하나의 컴파일러를 여는 일은 패키지 하나 이상의 파장을 낳는다. 넘바를 직접 쓰거나 자체 컴파일 백엔드로 활용하는 상위 라이브러리들이 함께 열리기 때문이다. 실제 데모는 넘바 기본 예제와 수치 배열 커널에서 시작해 PyTensor, PyMC, Interpolation.py, Dolo.py로 이어지며, 통계·확률·경제학·과학 계산 라이브러리가 실행 모델 전체를 JupyterLite로 가져올 길을 보여준다. 서버 없이 배포 가능한 대화형 교재나 재현 가능한 연구 데모를 고민하는 실무자라면, 그동안 WebAssembly를 아예 배제하던 프로젝트들을 이제 브라우저 지원 대상으로 재평가할 수 있다는 점이 특히 눈여겨볼 대목이다.
다만 이것은 종단 간 아키텍처를 확립한 첫 단계라는 점을 분명히 해 둘 필요가 있다. 개발팀은 변경 사항을 상류(upstream)에 반영하고, 넘바·llvmlite 테스트 커버리지를 넓히며, 성능과 영속 캐싱을 개선하고 더 많은 생태계 패키지를 검증해야 할 과제를 남겨 두고 있다. SIMD 같은 WebAssembly 타깃 기능은 수치 커널 가속의 유망한 방향으로 언급된다. 정교한 컴파일러 스택이 브라우저의 경계에서 멈출 이유가 없음을 보여준 이번 작업은, JupyterLite를 가벼운 파이썬 환경을 넘어 본격적인 컴파일 과학 계산 플랫폼으로 키울 수 있는 토대를 마련했다는 데 의미가 있다.