최근 개발자 커뮤니티를 중심으로 타입스크립트가 별도의 자바스크립트 런타임 없이 직접 네이티브 실행파일로 변환된다는 소식이 주목받고 있습니다. 기존에 타입스크립트는 자바스크립트로 변환된 뒤 V8 같은 엔진에서 실행되는 것이 정석이었으나, 페리라는 새로운 프로젝트가 이 경계를 허무는 시도를 단행했습니다. 이 프로젝트는 SWC 를 파싱 도구로, LLVM 을 코드 생성 도구로 활용하여 타입스크립트 소스를 macOS, iOS, Android, Windows 등 다양한 플랫폼에서 바로 실행 가능한 바이너리로 만들어냅니다. 이 과정에서 노드.js 나 V8 같은 런타임 의존성이 제거되고, 결과물이 2~5MB 크기의 단일 파일로 배포된다는 점이 기술적 혁신으로 평가받으며 화제의 중심에 섰습니다.
이러한 접근 방식이 주목받는 가장 큰 이유는 개발 워크플로우의 단순화와 배포 효율성 때문입니다. 기존 크로스 플랫폼 개발에서는 각 플랫폼에 맞는 빌드 환경을 구축하거나, 웹 기술을 래핑하는 데 많은 리소스가 소모되었습니다. 페리는 이를 해결하기 위해 네이티브 UI 위젯을 직접 컴파일하여 0ms 에 가까운 시작 속도를 달성했다고 주장합니다. 실제로 깃허브 저장소와 공식 웹사이트를 보면, 파일 시스템, 암호화, 자식 프로세스 등 노드.js 의 핵심 API 를 네이티브 구현체로 대체하여 런타임 오버헤드를 줄였으며, 병렬 처리를 위한 OS 스레드를 직접 지원한다는 점을 강조하고 있습니다. 이는 특히 모바일이나 임베디드 환경에서 타입스크립트의 성능 한계를 극복하려는 시도로서 큰 의미를 가집니다.
하지만 기술적 기대감 이면에는 신중한 검증이 필요한 지점들도 명확히 존재합니다. 일부 개발자들은 공식 웹사이트에 기재된 ‘런타임 없음’이라는 문구가 실제 사용 사례를 모두 포괄하지는 않을 수 있다고 지적합니다. 예를 들어, 익스프레스 같은 순수 자바스크립트 기반 라이브러리를 사용할 경우, 타입스크립트 컴파일러가 타입 정보만으로는 해당 코드를 처리하지 못해 여전히 자바스크립트 런타임이 필요할 수 있다는 논리가 제기되었습니다. 또한, 복잡한 제네릭이나 유틸리티 타입을 완벽하게 처리하기까지의 여정, 그리고 AI 가 생성한 듯한 웹사이트 설명의 신뢰도 문제도 커뮤니티 내에서 논의되고 있습니다. 이는 프로젝트가 가진 잠재력이 크지만, 아직 초기 단계에서 발생하는 불확실성이 존재함을 시사합니다.
앞으로 주목해야 할 점은 이 프로젝트가 단순한 기술 데모를 넘어 실제 대규모 프로젝트에 적용될 수 있는지의 여부입니다. 현재는 특정 예제나 간단한 유틸리티 도구에서 네이티브 컴파일의 효과를 입증하는 단계에 머물러 있습니다. 만약 복잡한 npm 생태계와의 호환성을 V8 런타임 옵션 없이도 자연스럽게 해결하거나, 기존 자바스크립트 라이브러리를 네이티브 코드로 매끄럽게 변환하는 기술적 장벽을 넘을 수 있다면 타입스크립트 생태계의 판도가 바뀔 수 있습니다. 개발자들은 이 프로젝트가 제시한 ‘단일 바이너리 배포’가 실제 생산 환경에서 얼마나 견고하게 작동하는지, 그리고 성능 향상이 실제 체감 가능한 수준인지 지켜봐야 할 것입니다.
작성자 소개
