Ant, 경량 JavaScript 런타임과 생태계

 (antjs.org)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 자체 개발한 Ant Silver 엔진으로 실제 npm 패키지를 실행하며, 약 8.6MB의 단일 바이너리와 빠른 시작 속도를 내세움
  • V8·JSC·SpiderMonkey를 감싼 구조가 아니며, compat-table 100% 와 WinterTC 준수를 표시하고 Hono·Elysia·TypeScript·React·Rolldown·Wasm 등을 지원함
  • Hono를 불러와 라우트 2개를 등록한 뒤 종료하는 콜드 스타트 측정에서 5.4ms를 기록해 Bun 12.8ms, Deno 24.8ms, Node.js 31.1ms보다 짧았음
  • 패키지를 npm보다 최대 40배 빠르게 설치하며, TypeScript 직접 실행과 기본 fetch export 서빙으로 별도 빌드나 프레임워크 어댑터가 필요 없음
  • 신뢰할 수 없는 코드를 위한 VM 격리 샌드박스와 npm 프로토콜 호환 공개 레지스트리 ants.land를 제공하며, macOS·Linux의 arm64 및 x86_64에서 별도 툴체인 없이 사용할 수 있음

자체 엔진과 빠른 개발 흐름

  • Ant는 처음부터 구축한 고성능 JavaScript 런타임으로, Ant Silver 엔진을 포함한 약 8.6MB의 휴대용 단일 바이너리로 배포됨
    • V8·JSC·SpiderMonkey 기반 래퍼가 아님
    • compat-table에서 100%를 기록하며 WinterTC Conformant로 표시됨
    • Hono·Elysia·TypeScript·React·Rolldown·WinterTC·Wasm 생태계를 실행함

  • 콜드 스타트 성능

    • Hono를 불러오고 라우트 2개를 등록한 뒤 종료해 모듈 해석과 초기화 비용만 측정함
    • Ant: 5.4ms
    • Bun: 12.8ms
    • Deno: 24.8ms
    • Node.js: 31.1ms

  • 패키지 설치

    • ant i hono 명령으로 패키지를 설치할 수 있으며, 예시에서는 hono@latest 1개 설치가 155ms에 끝남
    • npm보다 최대 40배 빠른 설치 속도를 내세우며, 별도 패키지 관리 도구를 설정할 필요가 없음

  • 서버와 TypeScript 실행

    • 파일의 기본 fetch export를 서버로 제공하므로 Hono 같은 프레임워크를 어댑터 없이 실행할 수 있음
    • TypeScript 파일은 ant app.ts로 직접 실행 가능함
      • tsconfig 조정이나 번들러, dist 디렉터리, tsc && node dist/app.js 단계가 필요 없음

격리 실행과 패키지 생태계

  • VM 기반 샌드박스

    • ant:sandbox의 Sandbox는 단순한 권한 확인을 넘어 VM 격리 경계 안에서 신뢰할 수 없는 JavaScript를 실행함
    • 각 샌드박스는 독립적인 KVM 또는 Hypervisor.framework VM을 사용함
    • 파일시스템 마운트는 명시적으로 쓰기 권한을 부여하지 않으면 읽기 전용으로 유지됨
    • 네트워크는 기본적으로 모두 차단되고 지정한 포트만 전달함

  • 공개 패키지 레지스트리

    • ants.land는 Ant용 공개 패키지 레지스트리임
    • npm 프로토콜을 사용해 Ant뿐 아니라 npm·Yarn·pnpm·Bun에서도 접근 가능함
    • 패키지는 스코프 또는 일반 이름으로 설치하며, esm.ants.land를 통해 브라우저에서도 사용할 수 있음
    • ant land login으로 로그인하고 ant land publish로 패키지를 배포함
    • 레지스트리 정보에는 문서·라이선스·호환성을 반영한 0~100점이 포함됨
    • macOS와 Linux의 arm64 및 x86_64를 지원하며 별도 툴체인이 필요 없음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 나는 매일 하루 종일 AI로 코딩하지만, 지난 3월 제기된 이 문제는 짚고 넘어갈 가치가 있다고 봄
    이후 코드를 다시 작성했다고 해도, 기존 AGPL 코드베이스가 초기 작업의 상당 부분을 차지했다는 점에서 “처음부터 직접 만들었다”는 표현은 다소 거슬림
    해당 스레드에 따르면 예전 버전을 폐기한 뒤 원작자들은 크게 개의치 않은 듯하고, 현재 코드는 형태와 구조가 달라 실제로 재작성된 것으로 보임. 전반적인 작업은 정말 좋아하니 계속하되 모두 조심할 필요가 있음

    • 하지만 이 글은 JavaScript 엔진을 직접 구현한 사람이 쓴 글처럼 보이지 않음
      다른 JavaScript 엔진의 코드를 가져온 것으로 보이는 LLM의 Git 기록을 또 다른 LLM에게 블로그 글로 작성해 달라고 한 듯한 인상이라, 무슨 일이 벌어진 건지 이해하기도 어렵고 프로젝트를 신뢰하기는 더 어려움
    • 그 문제는 프로젝트가 지금과 전혀 달랐던 2025년 12월의 코드를 가리킨 것임
      2월 무렵 기존 코드베이스를 사실상 삭제하고 훨씬 신뢰성 높은 시스템을 처음부터 설계했음. 당시 코드가 거의 전적으로 저품질 AI 생성물이라는 점은 알고 있었지만 가장 큰 우선순위는 아니었고, 지금은 검토와 테스트를 거치지 않은 코드가 하나도 통과하지 않게 관리함

  • 이미 Apache의 Ant가 있는데 왜 “Antjs”나 “Ant.js”가 아니라 Ant라고 이름 붙였는지 의문임: https://ant.apache.org

    • JavaScript 생태계에서도 이미 규모가 큰 Ant Design이 이름을 차지하고 있음: https://ant.design/
    • 수십 년 이상 코딩한 사람에게 첫인상을 나쁘게 만들고 싶을 때나 Ant라는 이름을 선택할 듯함
    • James가 Apache Ant를 넘겨줬을 때 Sun Microsystems 외부의 첫 사용자이자 기여자였지만, 다른 누군가가 같은 이름을 쓰는 것은 전혀 개의치 않음
    • Alibaba의 Ant Group에서 나온 프레임워크인 줄 알았음. Ant Design도 그곳에서 나왔기 때문임

  • 첫 버전을 한 달 만에 만든 과정은 첫 번째 글에, 몇 달 뒤 후속 과정은 두 번째 글에 담겨 있음
    새로운 런타임과 생태계를 처음부터 만드는 일이 경제적으로 성립하는지는 모르겠지만, 과거에는 팀 전체가 필요했던 소프트웨어를 이제 개발자 한 명이 만드는 단계에 이미 들어선 듯하며 아직 시작에 불과함

    • “엔진인 Ant Silver는 직접 제작했다”고 명시돼 있음
    • LLM이 학습 데이터에서 익힌 코드를 쏟아내는 것이라면 그다지 인상적이지 않음
      개인 개발자가 팀 단위로도 이전에 만들지 못했던 새로운 소프트웨어를 만드는 모습을 보고 싶음. AI에는 매우 우호적이지만 끊임없는 과장 홍보에는 진력이 남

  • Anthropic의 ant CLI가 Apache ant를 신경 쓰지 않는다는 농담을 했는데, 이제는 JavaScript의 ant까지 등장함

    • Apache Ant를 기억하는 사람이 나뿐인 줄 알았음. 이름이 고갈되고 있긴 하지만 Ant는 매우 영향력 있었던 기반 도구였음
    • Anthropic의 ant CLI를 사용하는 사람은 한 명도 본 적이 없음

  • JavaScript 생태계나 런타임을 깊이 알지는 못하지만, 더 작은 크기와 빠른 시작, 샌드박싱, 경쟁력 있는 성능을 모두 내세우는 데는 다소 놀랐음
    이미 성숙하고 고도로 최적화된 JavaScript 스택보다 이런 이점을 얻도록 해준 핵심 통찰이나 설계 선택, 큰 기술적 승부수가 무엇인지 궁금함

    • 스레드의 다른 부분에서 다뤘듯 이 프로젝트는 2019년에 시작된 Elk를 LLM으로 재작성한 것으로 보임: https://github.com/cesanta/elk
    • Deno는 여기서 보이는 기능을 사실상 모두 제공하면서도 성숙하고 진지한 프로젝트이며, LLM 이전에 작성됐고 탄탄한 팀이 뒷받침함
      가장 빠르지는 않지만 “X보다 빠르다”는 이유만으로 새 런타임을 도입하기는 어려움. 이 프로젝트의 설계 선택은 Claude나 Codex가 Elk 코드베이스의 상당 부분을 복사한 결과처럼 보임

  • 런타임과 엔진, Colony를 통한 수익화는 이해하지만 별도 레지스트리, 별도 패키지 관리자, Ant Desktop, 샌드박스, 정체를 알기 어려운 treatjs까지 필요한지는 모르겠음
    JavaScript 런타임이라면 JavaScript 실행이라는 한 가지 일만 잘했으면 좋겠는데, 모두가 왜 통합 도구 상자를 지향하는지 의문이며 이 프로젝트는 벌써 복잡해 보임

  • “V8에 가까운 속도”라고 하지만 zoo.js 벤치마크에서는 거리가 매우 멀어 보임: https://zoo.js.org/
    2026년 2월 10일 이후 성능이 크게 향상된 것이 아니라면 이 표현은 맞지 않음

    • 2월 이후 엔진을 사실상 완전히 재작성해 성능이 많이 개선됐음
      당시에는 대부분 인터프리터로 동작했고 여러 JIT 연산도 빠져 있었으며, 곧 nightly 빌드에도 벤치마크를 포함할 예정임

  • 가장 먼저 눈에 들어온 것은 샌드박싱임. Node와 npm이 왜 이를 기본 제공하지 않는지 모르겠으며, 웜과 공급망 공격을 크게 줄이는 데 도움이 될 것임

    • 페이지 아래쪽 설명에 따르면 “VM 격리 샌드박스”의 VM은 JavaScript 가상 머신이 아니라 하이퍼바이저를 뜻함
      이미 가상 머신 안에서 실행 중이라 중첩 가상화가 필요하다면, 지원 여부조차 불확실하고 속도나 효율도 좋기 어려워 보임
    • Deno에는 이미 그 기능이 있음. 관계자는 아니고 만족하며 쓰는 사용자임

  • 웹사이트에 사용된 세리프 글꼴이 무엇인지 궁금함. ant_serif로 이름을 바꾸고 다른 식별자는 모두 제거한 듯한데 상당히 보기 좋음

    • 이것이 원작자의 반복되는 방식처럼 보임. 즉 훔쳐 쓰는 것임

  • 콜드 스타트 벤치마크는 있는데, 실행 성능 벤치마크를 Node, Deno, Bun, QuickJS 등과 비교한 자료는 왜 없는지 궁금함

답변달기