Vercel은 한 달에 한 번꼴로 화제성 프로젝트를 내놓으며 신뢰성과 존재감을 유지하려는 듯함. 진지한 회사나 프로젝트가 scriptc를 쓸 것 같지는 않음
기여자들은 존중하지만, 코드는 Claude로 생성한 티가 강한데 Claude가 기여자로 표시되지 않아 더 의심스러움

전형적인 Vercel식 프로젝트임. 공개한 지 5일, 전부 바이브 코딩, 이유 없이 별 1,500개를 받았지만 누구의 문제도 해결하지 않으며, 길어야 몇 달 뒤에는 유지보수가 중단될 듯함

비판만 하기보다 로컬의 여러 프로젝트에 직접 적용해 봤지만, 모두 코드 범위 분석에서 수백 개 오류가 발생해 사실상 쓸 수 없었음
외부 라이브러리 없이 처음부터 작성하면 바이너리로 컴파일할 수 있겠지만, 그렇다면 Rust, Go, Zig, D, C, V, Ada, C++, Nim, Swift, Kotlin Native, Haskell처럼 애초에 제대로 된 컴파일을 목표로 설계된 언어를 쓰지 않을 이유가 없음

TypeScript의 장점은 표현력뿐 아니라 거대한 npm 생태계와의 호환성임. 대부분의 패키지는 타입 선언으로 인터페이스만 정의하고 실제 코드는 JavaScript로 배포하므로, 패키지를 사용하려면 현실적으로 JavaScript 엔진이 필요함
처음부터 새로 시작하고 npm 패키지를 전혀 쓰지 않을 계획이라면 AssemblyScript를 쓰는 편이 나음. Node는 TypeScript로 패키지를 배포하지 말라고 명시적으로 권고하는데, TypeScript는 부 버전 사이에서도 하위 호환되지 않고 컴파일러 설정 역시 패키지 간 이식성이 없기 때문임

scriptc는 이런 의존성을 실행해야 할 때 선택적으로 620KB quickjs-ng 엔진을 번들에 넣는 방식으로 해결하는 듯함

의존성이 많은 코드보다는, 더 큰 TypeScript 프로젝트와 코드를 공유해야 하는 용도가 명확한 명령줄 도구에 사용하고 싶음

타입 없는 라이브러리를 배포해야 할 근거는 되지만, 그 이유가 타입의 가치를 능가한다는 결론은 이해하기 어려움

이런 프로젝트 하나면 HN 같은 서비스의 첫 페이지에 계속 노출될 수 있음. 토큰을 투자해 아무도 원하지 않는 그럴듯한 프로젝트를 만들고 공개로 도달 범위를 넓힌 뒤 반복하는 성장 전략임
12개월 뒤에는 오픈소스 프로젝트의 90%가 실제 사용자 없이 흥미로워 보이기만 하는 바이브 코딩 결과물이 될 수도 있음. 이제 완전한 컴파일러도 쉽게 생성할 수 있지만 핵심은 장기 유지보수와 공동체이며, 눈길을 끄는 제목만으로 사용자가 남지는 않음
Vercel이 진지하다면 실제 비용과 위험을 감수해 자사의 실험적 런타임으로 채택해야 함

아주 훌륭한 문제 영역임. AI로 런타임 코드를 최적화하는 컴파일러를 만드는 비슷한 작업을 Zod에 적용했음: zod-compiler
Zod 스키마를 빌드 시점에 단순 불리언 연산 체인으로 컴파일해 코드 변경 없이 2~74배 빠르게 만들며, 플러그인이 Zod 호출을 컴파일된 파싱으로 교체함. 최적화 대부분은 Claude가 100회 넘게 반복하며 작성했음
실제 Zod와 결과를 비교할 수 있어 정확성을 주관적으로 판단할 필요가 없다는 점이 scriptc와 같음. 기준 구현과 벤치마크가 있는 컴파일러, 직렬화 도구, 포매터, 질의 계획기 등에 모두 적용 가능함

Claude로 scriptc와 Node 벤치마크를 실행했음. 가장 유리한 바이트 배열 결과에서도 scriptc는 전용 최적화 후 Node 24보다 약 7.5배 느림
대신 실행 파일 시작은 12배 빠르고(1.5ms 대 18.6ms), 메모리는 72배 적게 사용하며(2.5MiB 대 181MiB), 런타임 의존성 없는 단일 370KB 실행 파일로 만들어짐

작고 빠른 네이티브 실행 파일이 필요하다는 점을 인정한 것은 좋지만, Java가 수십 년간 겪은 과정을 보면 실용성에는 회의적임. 1990년대의 GCJ는 기술적으로 괜찮았어도 생태계 지원이 없었음
이후 GraalVM Native가 문제를 더 종합적으로 다루면서 주요 라이브러리와 프레임워크가 호환성 확보에 나섰지만, 지금도 간단한 기존 애플리케이션조차 네이티브로 완벽히 실행하기가 매우 어려움. scriptc 같은 시도는 반갑지만 실용화까지 길고 험난할 듯함

Graal 팀도 비슷한 메타 인터프리터 접근법을 시도한 것으로 알고 있음. 네이티브 실행이 처리할 수 없는 동적 바이트코드 로딩이나 리플렉션은 Espresso Java 구현으로 해석하려 했음

GCJ는 늘 프로토타입에 가까웠음. 진지한 사용자라면 Excelsior JET, BEA JRockit 등 AOT 도구를 갖춘 상용 JDK를 구매했을 것임
Excelsior가 사라진 이유 중 하나는 GraalVM과 OpenJ9이 무료로 제공되기 때문일 가능성이 큼. PTC와 Aicas는 관심받지 못하는 임베디드·실시간 고객층 덕분에 여전히 잘 운영되고 있음

개발이 지속된다면 .NET AOT급의 큰 성과가 될 잠재력이 있음. 공개된 지 며칠뿐이라 지금은 가볍게 시험하는 정도지만, 버려지지 않고 계속 발전한다면 생태계에 상당한 도움이 될 수 있음
AI로 만든 코드도 사람이 만든 코드처럼 품질 범위가 넓음. 중요한 소프트웨어라면 직접 작성할 때와 같은 기준으로 생성하고 모든 코드를 검토해야 하며, 그렇게 쓴다면 훌륭한 방식임. 검토가 부족한 프로젝트는 품질과 개발자의 책임감이 낮을 가능성이 있어 채택하기가 더 어려움
온라인 논의는 “전부 AI로 생성”과 “절대 AI를 쓰지 않음”이라는 양극단으로 흐르지만, 현실에서는 사려 깊은 판단을 가속하는 중간 지점이 합리적임. 그렇지 않은 소프트웨어는 낮은 품질이나 방치될 위험 때문에 사용을 꺼리게 됨