Ant, 경량 JavaScript 런타임과 생태계
요약
본 글은 새로운 경량 JavaScript 런타임과 생태계를 구축한 프로젝트에 대한 비판적 분석을 담고 있습니다. 작성자는 AI가 생성한 코드의 과장된 홍보와 기술적 깊이에 의문을 제기하며, 실제 혁신적인 설계 선택이나 근거를 요구하고 있습니다.
핵심 포인트
- AI 기반 코딩과 과장된 홍보는 경계해야 합니다.
- 새로운 런타임 도입을 위해서는 명확한 성능 우위가 필요합니다.
- 프로젝트의 복잡성이 지나치게 커져 핵심 기능에 집중하기 어렵습니다.
- 성숙한 JavaScript 스택 대비 차별화된 기술적 승부수가 궁금합니다.
나는 매일 하루 종일 AI로 코딩하지만, 지난 3월 제기된 이 문제는 짚고 넘어갈 가치가 있다고 봄
이후 코드를 다시 작성했다고 해도, 기존 AGPL 코드베이스가 초기 작업의 상당 부분을 차지했다는 점에서 “처음부터 직접 만들었다”는 표현은 다소 거슬림
해당 스레드에 따르면 예전 버전을 폐기한 뒤 원작자들은 크게 개의치 않은 듯하고, 현재 코드는 형태와 구조가 달라 실제로 재작성된 것으로 보임. 전반적인 작업은 정말 좋아하니 계속하되 모두 조심할 필요가 있음
하지만 이 글은 JavaScript 엔진을 직접 구현한 사람이 쓴 글처럼 보이지 않음
다른 JavaScript 엔진의 코드를 가져온 것으로 보이는 LLM의 Git 기록을 또 다른 LLM에게 블로그 글로 작성해 달라고 한 듯한 인상이라, 무슨 일이 벌어진 건지 이해하기도 어렵고 프로젝트를 신뢰하기는 더 어려움
그 문제는 프로젝트가 지금과 전혀 달랐던 2025년 12월의 코드를 가리킨 것임
2월 무렵 기존 코드베이스를 사실상 삭제하고 훨씬 신뢰성 높은 시스템을 처음부터 설계했음. 당시 코드가 거의 전적으로 저품질 AI 생성물이라는 점은 알고 있었지만 가장 큰 우선순위는 아니었고, 지금은 검토와 테스트를 거치지 않은 코드가 하나도 통과하지 않게 관리함
수십 년 이상 코딩한 사람에게 첫인상을 나쁘게 만들고 싶을 때나 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 스택보다 이런 이점을 얻도록 해준 핵심 통찰이나 설계 선택, 큰 기술적 승부수가 무엇인지 궁금함
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 등과 비교한 자료는 왜 없는지 궁금함
AI 자동 생성 콘텐츠
본 콘텐츠는 RSS: GeekNews (한국어)의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기