JVM 없이 도는 클로저: Chez 스킴 위에 올린 Jolt의 설계와 현실적 쓸모

클로저(Clojure)는 함수형 프로그래밍과 견고한 불변 자료구조로 국내외 백엔드 개발자에게 꾸준히 지지를 받아왔지만, 태생적으로 JVM 위에서 돌아간다는 전제가 늘 따라붙었다. Jolt는 바로 이 전제를 걷어낸 클로저 구현이다. JVM 대신 스킴(Scheme)을 실행 기반으로 삼아, 네이티브 환경에서는 Chez Scheme 위에서, 자바스크립트로 내보낼 때는 Gambit을 거쳐 동작한다. 클로저 소스를 읽어들여 호스트에 종속되지 않는 중간표현(IR)으로 분석한 뒤 스킴 코드를 생성해 실행하는 구조다. 흥미로운 점은 컴파일러 자체가 클로저로 작성되어 스스로를 컴파일하는 셀프 호스팅 방식이라는 것이다.

무엇을 노렸나

JVM 위의 클로저가 오래 지적받아온 약점은 두 가지다. 하나는 프로세스 시작이 느리다는 것이고, 다른 하나는 배포 시 런타임 의존성이 무겁다는 점이다. Jolt의 jolt build 명령은 런타임과 표준 라이브러리, 애플리케이션 코드, 그리고 의존성까지 한데 묶어 하나의 자립형 실행 파일로 미리(ahead-of-time) 컴파일한다. 이렇게 만들어진 바이너리는 실행에 Chez도, JVM도, 심지어 원본 소스도 필요로 하지 않는다. 설치 역시 런타임·컴파일러·표준 라이브러리를 모두 품은 단일 jolt 바이너리를 내려받는 것으로 끝난다. 소스를 클론해 쓰는 경로도 열려 있는데, 이 경우 Chez Scheme만 있으면 되고 별도 빌드 단계 없이 부트스트랩 시드가 저장소에 함께 들어 있어 바로 돌릴 수 있다.

클로저의 핵심 의미론을 얼마나 지켰나

실행 기반을 통째로 바꾼 구현에서 가장 먼저 의심스러운 부분은 언어의 세부 의미론이 얼마나 보존되느냐다. Jolt는 이 지점에서 상당히 공격적인 목표를 내세운다. 32-way 트라이로 구현한 불변 벡터, cons 리스트, HAMT 기반의 맵과 셋이 클로저의 값 의미론을 그대로 따르고, 트랜지언트(transient)는 실제로 변경 가능한 임시 컬렉션으로 동작한다. 수치 체계도 정수와 임의 정밀도 정수(bignum), 정확한 유리수((/ 1 2)가 1/2로 유지됨), 부동소수점 double을 구분해 다룬다. 동등성 비교에서 =는 범주를 인식하고 ==는 값 동등성을 판정하는 클로저의 관례도 유지된다. 지연·무한 시퀀스, 트랜스듀서, 구조 분해, 멀티메서드, 프로토콜과 레코드, 메타데이터, 네임스페이스, 런타임 eval, 전체 리더(reader)까지 포괄한다고 밝힌다.

동시성 모델도 눈여겨볼 만하다. future, promise, agent, pmap이 공유 힙 위의 OS 스레드로 돌아가 JVM의 의미론과 맞아떨어지도록 설계됐고, core.async는 채널과 go 블록을 제공한다. 클로저의 동시성 프리미티브에 익숙한 개발자라면 상당 부분을 재학습 없이 옮겨올 수 있다는 의미다. 프로젝트 측 설명에 따르면 이식성 있는 클로저 코드 대부분은 수정 없이 그대로 실행된다고 한다.

실무자가 따져봐야 할 것

한국의 클로저 사용 조직에게 Jolt가 주는 실질적 매력은 배포 형태의 단순함이다. 단일 실행 파일로 떨어지고 시작 오버헤드가 없는 특성은 CLI 도구, 짧게 뜨고 지는 서버리스 함수, 컨테이너 이미지 경량화 같은 시나리오와 잘 맞는다. Gambit을 통한 자바스크립트 타깃은 동일한 클로저 코드를 다른 실행 환경으로 확장할 여지를 준다. 개발 경험 측면에서도 살아 있는 프로세스에 붙어 작업하는 REPL 주도 개발을 그대로 지원한다고 안내한다.

다만 냉정하게 볼 지점도 분명하다. 원문 스스로 "진짜 차이(genuine divergences)"가 존재한다고 언급하면서도 구체 목록은 이 발췌본에서 잘려 있어, 어떤 JVM 클로저 코드가 깨지는지는 문서를 직접 확인해야 판단할 수 있다. 클로저 생태계의 큰 자산인 방대한 자바 상호운용(interop) 라이브러리는 JVM을 벗어난 순간 그대로 쓸 수 없다는 점도 근본적 제약이다. Jolt가 호스트 상호운용을 어떤 형태로 제공하는지는 별도 문서로 안내되지만, 기존 자바 의존성에 깊게 묶인 프로덕션 코드베이스를 옮기는 일과 새 프로젝트를 Jolt로 시작하는 일은 난이도가 전혀 다르다. 결국 지금 시점에서 Jolt는 JVM 없는 클로저를 원하는 명확한 동기가 있는 팀이 소규모 도구나 실험적 서비스부터 검증해볼 만한 선택지에 가깝다.