TypeScript를 실행 파일로 직접 컴파일하는 Perry: SWC와 LLVM의 만남

TypeScript가 네이티브 실행 파일이 된다고?

TypeScript로 개발해본 분들이라면 한 번쯤 이런 생각 해보셨을 거예요. "내 TS 코드가 Node.js 없이 그냥 실행되면 얼마나 좋을까?" 보통 TypeScript를 배포할 때는 Node.js 런타임이나 Bun, Deno 같은 환경이 필요하잖아요. 그런데 이번에 등장한 Perry라는 프로젝트는 좀 다른 접근을 시도하고 있어요. TypeScript 코드를 직접 네이티브 실행 파일(.exe 같은)로 컴파일해버리는 거예요.

Perry의 핵심은 두 가지 기술의 결합이에요. SWC는 Rust로 작성된 초고속 JavaScript/TypeScript 컴파일러로, Vercel이 만들었고 Next.js 같은 데서 쓰이고 있어요. LLVM은 Clang, Rust, Swift 같은 언어가 모두 사용하는 강력한 컴파일러 백엔드예요. Perry는 SWC로 TS를 파싱한 다음 LLVM IR(중간 표현)로 변환하고, 거기서 네이티브 머신 코드로 컴파일해요. 비유하자면 한국어를 영어로 번역(SWC)한 다음, 영어를 다시 음성 파일(LLVM)로 만들어내는 거예요.

기존 TypeScript 실행 방식과 뭐가 다른가요?

현재 TypeScript를 실행하는 방법은 크게 세 가지예요. 첫째, tsc로 JS로 변환한 다음 Node.js에서 실행하는 가장 일반적인 방식이에요. 둘째, Deno나 Bun처럼 TypeScript를 직접 실행해주는 런타임을 쓰는 방식이에요. 셋째, pkg나 Bun의 --compile 옵션처럼 런타임과 코드를 묶어서 단일 실행 파일로 만드는 방식이에요.

세 번째 방식도 "단일 실행 파일"을 만들긴 하지만, 사실은 Node.js나 Bun 런타임 전체를 통째로 안에 집어넣는 거예요. 그러다 보니 "Hello World"만 출력하는 프로그램도 수십 메가바이트가 나와요. 시작 속도도 런타임 초기화 때문에 느리고요.

Perry는 여기서 완전히 다른 길을 가요. 런타임을 통째로 포함하지 않고, 코드를 진짜 머신 코드로 컴파일해요. C나 Rust 컴파일러가 하는 것처럼요. 그래서 결과물 크기가 작고, 시작 속도도 빠르고, V8 같은 자바스크립트 엔진 없이 그냥 OS에서 바로 실행돼요.

어떻게 동작하는 걸까요?

원리를 좀 더 자세히 살펴볼까요? Perry는 먼저 SWC로 TypeScript 코드를 AST(추상 구문 트리)로 파싱해요. AST가 뭐냐면, 코드를 컴퓨터가 이해하기 쉬운 트리 구조로 분해해놓은 거예요. 예를 들어 const x = 1 + 2라는 코드를 "변수 선언" 노드 아래에 "이름: x", "값: 더하기 연산자, 왼쪽 1, 오른쪽 2" 식으로 펼쳐놓는 거죠.

그다음 이 AST를 분석해서 타입 정보를 활용해 LLVM IR로 변환해요. LLVM IR은 어셈블리 비슷한 저수준 중간 언어인데, 다양한 CPU 아키텍처(x86, ARM 등)와 OS(Windows, macOS, Linux)로 변환하기 좋은 형태예요. 그리고 마지막에 LLVM이 이걸 실제 머신 코드로 변환해서 실행 파일을 만들어요.

여기서 중요한 게 타입 정보의 활용이에요. JavaScript는 동적 타입 언어라 x + y가 숫자 덧셈인지 문자열 합치기인지 런타임에만 알 수 있어요. 그래서 V8 같은 엔진은 매번 타입을 확인하느라 오버헤드가 있어요. 그런데 TypeScript는 정적 타입이라 컴파일 시점에 "이건 number고, 저건 string이다"를 알 수 있어요. Perry는 이 정보를 활용해서 C++ 수준의 효율적인 코드를 생성하는 걸 목표로 해요.

물론 한계도 명확해요. JavaScript/TypeScript의 모든 기능을 네이티브로 변환하는 건 어려워요. 동적 객체 속성, 프로토타입 체인, eval 같은 건 완전히 정적으로 처리하기 힘들거든요. 그래서 Perry가 처음부터 "TypeScript 전체"가 아니라 "TypeScript의 정적 처리 가능한 부분집합"을 타깃으로 한다고 보는 게 정확해요.

업계 흐름 속에서 보면

이런 "동적 언어를 네이티브로 컴파일" 시도는 사실 오랜 역사가 있어요. Static Hermes는 Meta가 React Native용으로 만든 정적 컴파일 JS 엔진이고, AssemblyScript는 TypeScript 비슷한 문법으로 WebAssembly를 만들어주는 컴파일러예요. Porffor라는 프로젝트도 비슷하게 JS를 직접 WASM이나 네이티브로 컴파일하려는 시도를 하고 있고요. 더 야심차게는 TypeScript의 마이크로소프트 본가도 Go로 컴파일러를 다시 쓰는 작업을 진행 중이에요(이건 컴파일러 자체의 성능 개선 목적이긴 하지만요).

이 흐름의 배경에는 "Node.js의 무게가 부담스럽다"는 공감대가 있어요. 컨테이너 환경에서 빠른 콜드 스타트가 필요한 서버리스, 가벼운 CLI 도구, 임베디드 환경 등에서는 50MB짜리 바이너리와 100ms 시작 지연이 큰 부담이거든요. Go나 Rust로 쓰면 좋겠지만, TypeScript 자산이 이미 많은 팀에선 쉽지 않은 결정이에요. Perry 같은 도구는 그 간극을 메우려는 시도라고 볼 수 있어요.

한국 개발자에게 주는 시사점

실무에서 당장 쓸 수 있는 도구냐고 묻는다면, 솔직히 아직은 "실험적"이라고 답해야 해요. 프로덕션에 바로 투입하긴 어렵고, 지원하는 TypeScript 기능도 제한적일 거예요. 하지만 다음 시나리오에서는 주목할 가치가 충분해요. CLI 도구를 만들 때(Node.js 설치 없이 배포 가능), AWS Lambda 콜드 스타트가 중요한 서버리스 환경, Electron 대신 가벼운 데스크톱 앱을 만들고 싶을 때 같은 경우예요.

학습 가치도 커요. SWC, LLVM, 컴파일러 백엔드 같은 기술을 한꺼번에 들여다볼 수 있는 좋은 케이스 스터디거든요. 특히 "인터프리터 vs 컴파일러", "동적 타입 vs 정적 타입의 런타임 영향" 같은 주제를 실제 코드로 이해할 수 있는 기회예요. 컴파일러에 관심 있는 분이라면 Perry의 소스를 한번 읽어보시는 것도 추천해요.

또 한국에서는 토스나 카카오 같은 회사들이 TypeScript를 메인 언어로 쓰는 경우가 많은데, 이런 곳에서 내부 도구나 빌드 파이프라인을 더 빠르게 만들고 싶을 때 이런 기술이 점점 유용해질 거예요.

마무리

Perry는 "TypeScript를 JavaScript의 옷에서 벗겨내서 진짜 시스템 언어처럼 쓸 수 있을까?"라는 질문에 대한 흥미로운 답이에요. 모든 TS 코드를 다 컴파일할 순 없겠지만, 정적으로 잘 짜인 코드라면 C++ 수준의 성능을 노려볼 수 있다는 가능성을 보여줘요.

여러분은 어떻게 생각하세요? TypeScript가 Go나 Rust 같은 시스템 언어의 자리를 일부 차지할 수 있을까요? 아니면 결국 "적절한 도구는 따로 있다"는 결론으로 갈까요?