버셀 랩스(vercel-labs)가 공개한 실험적 프로젝트 Scriptc는 타입스크립트를 네이티브 실행 파일로 곧바로 컴파일하는 도구다. 핵심은 결과 바이너리 안에 Node.js도, V8도, 어떤 자바스크립트 엔진도 들어가지 않는다는 점이다. 기존의 여러 접근이 런타임을 통째로 실행 파일에 묶어 넣는 방식이었다면, Scriptc는 자바스크립트 실행 엔진 자체를 제거한 '제로 런타임' 결과물을 지향한다. 결과적으로 작고 빠른 단일 네이티브 바이너리가 만들어진다.
주목할 만한 특징은 개발자가 코드를 바꿀 필요가 없다는 것이다. 별도의 애노테이션이나 방언(dialect) 없이, Node에서 그대로 돌리던 평범한 타입스크립트를 입력으로 받는다. 타입 검사는 자체 구현이 아니라 실제 타입스크립트 컴파일러가 담당하며, 그 위에서 네이티브 코드로 낮춰(lowering) 변환한다. 프로젝트 측은 컴파일에 성공한 코드는 Node에서 실행할 때와 '바이트 단위로 동일하게' 동작하도록 맞춘다고 설명한다.
정적으로 다룰 수 있는 범위
Scriptc의 전제는 "대다수의 타입스크립트는 생태계가 가정하는 것보다 훨씬 더 정적(static)"이라는 판단이다. 즉 실행 시점의 동적 성격이 강조되곤 하지만, 실제 프로그램에서 쓰이는 상당 부분은 컴파일 시점에 확정할 수 있다는 것이다. 이 도구는 언어 구성 요소를 하나하나 뜯어보며 무엇을 네이티브로 컴파일할 수 있는지 판단하고, 그 결과를 개발자에게 알려준다. 지원 범위는 실제 프로그램이 사용하는 언어 기능과 표준 라이브러리를 포괄하도록 설계됐다.
타입 검사는 타입스크립트의 실제 es2025 표준 라이브러리를 기준으로 이뤄지며, 프로젝트에 @types/node가 있으면 이를 함께 반영한다. 검사기의 엄격도는 사용자의 tsconfig.json 설정을 그대로 따른다. 중요한 점은, 변환 규칙이 정의되지 않은 기능에 도달하면 조용히 넘어가거나 예기치 못한 동작을 내는 대신 정확한 진단 메시지로 알려준다는 것이다. 어디까지 되고 어디부터 안 되는지가 명시적으로 드러나는 셈이다.
Node와의 차이, 그리고 검증 방식
Scriptc는 Node와의 동작 차이를 숨기지 않는다. 의도적으로 남겨둔 차이가 수십 개 존재하는데, 대부분 타이밍 관련 내부 처리나 에러 객체의 속성과 같은 영역에 몰려 있다. 이들 차이는 문서화되어 있고 번호가 매겨져 있어, 어떤 부분이 왜 다른지를 추적할 수 있다. '조용히 갈라지는' 동작이 없도록 하겠다는 원칙이 반영된 부분이다. 실무 관점에서 보면, 이식성을 판단할 때 막연한 불확실성이 아니라 열거된 예외 목록을 놓고 검토할 수 있다는 뜻이다.
품질 보증의 축은 차등 테스트(differential test)다. 모든 변경에는 두 가지 강제 검증 장치가 돌아가며, 새 기능이 들어올 때마다 차등 테스트가 함께 추가된다. 두 검증 레인이 모두 통과해야만 병합이 허용된다는 것이 이 프로젝트의 기준선이다. 성능 역시 Apple M 시리즈 환경에서 Node, Go, Rust, Zig와 동일한 워크로드로 측정했으며, 이때 모든 결과물이 바이트 단위로 동일한 출력을 낸다는 점을 확인했다고 밝힌다. 다만 공개된 설명에는 구체적인 수치가 제시되어 있지 않아, 상대적 우위의 정도는 실제 벤치마크 자료로 따로 확인해야 한다.
실무적 의미와 한계
플랫폼 지원은 macOS arm64가 1차 대상이며, 리눅스와 윈도우용 바이너리는 크로스 컴파일로 만들어지고 각각 자체 차등 테스트 레인으로 검증된다. 빌드에는 clang이 필요한데, 이는 Xcode 명령줄 도구를 설치하면 기본으로 포함된다. 정리하면 이 도구가 매력적인 지점은 명확하다. 배포 산출물에서 런타임 의존성을 걷어내 실행 파일 크기와 시작 비용을 줄이고, 기존 코드를 손대지 않은 채 CLI 도구나 소규모 서비스 같은 정적 성격이 강한 프로그램을 네이티브로 뽑아낼 수 있다는 점이다.
동시에 한계도 분명하다. Scriptc는 버셀 랩스 산하의 실험적 저장소로 공개된 단계이며, 지원 범위가 '정적으로 낮출 수 있는 부분'으로 제한된다. 동적 성격이 강한 코드나 아직 변환 규칙이 없는 기능을 쓰면 컴파일이 거부되고 진단으로 돌아온다. Node 대비 예외 항목이 수십 개 존재한다는 점도 그대로 이해하고 접근해야 한다. 따라서 프로덕션 도입을 검토한다면, 자신의 코드베이스가 이 정적 표면 안에 얼마나 들어오는지, 문서화된 차이가 자신의 사용 시나리오에 영향을 주는지를 먼저 확인하는 것이 현실적인 출발점이다.