패키지 관리와 재현 가능한 빌드에 관심 있는 개발자라면 한 번쯤 Nix를 접해봤을 것이다. 그러나 Nix는 진입 장벽이 높기로 악명이 높다. 독자적인 함수형 언어, 전용 평가기, 그리고 /nix/store를 중심으로 돌아가는 독특한 모델까지, 기존 생태계와 쉽게 섞이지 않는다. 최근 공개된 jinx는 이 벽을 정면으로 넘지 않고 우회하는 접근을 택했다. jinx는 .nix 파일을 .ts 파일로 변환하는 트랜스파일러로, 개발자 fzakaria가 만들었다. 그는 자신을 "프런트엔드에 서툰 초보"라고 표현하면서도 이 아이디어가 탐구할 가치가 있다고 판단했다고 밝혔다.
jinx의 핵심 주장은 단순하다. nixpkgs 전체, 즉 23만 1,777개의 속성(attribute)을 전부 타입스크립트로 컴파일했고, 그 결과가 Nix가 산출하는 것과 정확히 동일한 drvPath를 만들어낸다는 것이다. 더 인상적인 점은 Nix가 어디에도 설치되어 있지 않은 상태, 심지어 브라우저 탭 안에서도 hello 같은 패키지를 평가할 수 있다는 것이다. 컴파일된 트리는 fzakaria/jinx-nixpkgs 저장소에 nixpkgs 리비전마다 커밋 하나씩 대응하는 형태로 올라가 있다.
마법은 언어가 아니라 스토어 모델에 있다
저자가 글에서 반복해 강조하는 통찰은, Nix에서 정작 중요한 것은 언어 자체가 아니라는 점이다. Nix 언어는 derivation이라는 원시 요소를 가진 작은 지연 평가 함수형 언어일 뿐이고, 비슷한 것을 주말에 하나 설계할 수도 있다고 그는 말한다. 진짜 재현성과 격리성(hermeticity)을 만들어내는 것은 스토어 모델이며, 같은 모델 위에 세운 어떤 도구든 동일한 성질을 갖게 된다. 바꿔 말해 언어나 평가기는 교체 가능하지만, 그 위에 쌓인 자산은 그렇지 않다.
그 자산이 바로 nixpkgs다. 2026년 10월 기준으로 14만 개가 넘는 패키지가 빌드되며, 그 안에는 20년간 쌓인 교차 컴파일 우회책, stdenv 단계 처리, 패치된 configure 스크립트, aarch64-darwin에서만 필요한 특정 플래그 같은 무수한 해결책이 Nix 언어로 녹아 있다. 문제는 이것이 동시에 함정이라는 점이다. 새로운 언어나 평가기, 새로운 에디터 경험으로 스토어 모델을 탐구하려는 사람은 패키지 0개에서 다시 시작해야 하고, 이것이 Nix의 재구현이나 포크가 번번이 사라져 간 이유다. jinx의 발상은 nixpkgs 트리 전체를 다른 생태계가 이미 이해하는 형태로 변환해, 20년 치 작업을 버리지 않고 스토어 모델을 다른 방향에서 탐색하자는 것이다.
번역이 충실하다는 증거
타입스크립트가 선택된 이유는 방대한 도구 생태계, 거의 모든 브라우저에서의 지원, 그리고 derivation의 형태와 Nix 지연 평가의 괴벽까지 표현할 수 있는 유연한 타입 시스템 때문이다. 변환 결과물은 비교적 읽을 만하다. 람다는 화살표 함수가 되고, let은 const 블록이, 속성 집합은 객체 리터럴이, import는 require가 된다. 다만 Nix가 지연 평가 언어인 탓에, thunk를 할당할 자리마다 표현식이 nix.thunk(() => ...)로 감싸진다. jinx 평가는 /nix/store에 아무것도 쓰지 않으며, jinx instantiate가 .drv 클로저를 기록하고 실제 빌드는 nix-store --realise가 맡는다.
저자는 변환의 충실성을 직접 검증했다. nixpkgs 자체 CI 설정인 ci/eval/outpaths.nix의 모든 속성을 jinx와 nix-eval-jobs로 각각 평가해 drvPath를 비교한 것이다. nixpkgs 6510408d 리비전에서 x86_64-linux, aarch64-linux, aarch64-darwin 세 플랫폼 모두 차이가 없었다. 양쪽에서 함께 실패한 2,714개는 지원하지 않는 플랫폼이거나 broken, insecure로 표시되어 Nix 스스로 평가를 거부하는 속성들이다. 즉 스토어 입장에서는 둘을 구분할 수 없고, 바로 이 지점이 다른 생태계에서 nixpkgs를 해금하는 열쇠다.
실무에서 무엇이 열리는가
jinx가 열어주는 작업들은 Nix 사용자에게 익숙한 불편을 상당 부분 해소한다. node --cpu-prof로 평가를 프로파일링하면 소스맵을 통해 모든 프레임이 nixpkgs의 코드 한 줄로 되짚어진다. 모든 속성에 대해 언어 서버 기반 자동 완성과 타입 검사가 공짜로 따라오고, 소스맵 덕분에 VS Code나 Chrome DevTools에서 package.nix의 특정 줄에 중단점을 걸어 stdenv.mkDerivation 내부로 들어가며 단계별로 추적할 수 있다. 또한 lib 함수나 패키지 정의는 그냥 모듈 안의 함수이므로 node:test로 단위 테스트를 작성할 수 있고, JSON 덤프를 jq로 파이프하던 주문을 외우지 않고도 REPL이나 스크립트로 nixpkgs를 탐색할 수 있다. 손으로 직접 쓰기 좋은 별도의 타입스크립트 패키지 작성 형식도 제공되며, 이는 stdenv.mkDerivation을 호출하고 pkgs의 무엇이든 의존할 수 있다.
물론 한계도 분명하다. 타입스크립트에서의 nixpkgs 평가는 약 3~5배 느리고, 모든 모듈을 처음 컴파일해야 하는 첫 평가는 3~10배까지 느려지며 thunk가 가비지 컬렉터에 부담을 주는 탓에 메모리도 2~4배 더 든다. 다만 저자는 20년간 다듬어진 C++ 인터프리터를 자바스크립트 엔진 위의 신생 컴파일러가 5배 차이로 쫓아가는 것이 "출발점으로는 괜찮다"고 본다. 목표는 Nix를 더 빠르게 만드는 것이 아니라 nixpkgs를 타입스크립트 생태계로 끌어오는 것이기 때문이다. jinx는 의존성도 네이티브 코드도 데몬도 없이 Node 24나 브라우저에서 돌아가며, 저자는 코드 상당 부분을 AI와 공동 작성했다고 먼저 밝혀 두었다. 손으로 쓰기 괴로운 자동 변환 결과물과 느린 평가 속도를 감안하더라도, 익숙한 도구 체계로 Nix의 스토어 모델을 들여다볼 수 있다는 점은 그 자체로 검토할 가치가 있다.