Medium
자바스크립트 도구를 "더 빠른" 언어로 다시 작성하는 것에 대해 회의적인 이유
Rolldown·Oxlint·Biome 의 등장에는 "언어가 빨라서"가 아니라 "성능을 의식한 재작성"이라는 또 다른 이유가 섞여 있다. JIT·바이트코드 캐시·기여 가능성까지 고려한 회의론.
핵심 요약
Rolldown(Rollup), Oxlint(ESLint), Biome(Prettier) 등 네이티브 언어로의 재작성이 늘고 있다. 회의론의 골자는 (1) 성능 격차의 원인은 언어가 아닐 수 있다 — 재작성 자체가 알고리즘/구조를 다시 보는 기회를 만든다, (2) JIT·바이트코드 캐시(Node NODE_COMPILE_CACHE) 같은 JS 측 최적화는 아직 충분히 활용되지 않았다, (3) 기여·디버깅 가능성이 떨어진다 — 일반 JS 개발자가 node_modules 를 직접 패치하던 흐름이 막히고, 에러 메시지도 친숙한 스택 트레이스 대신 세그폴트가 된다. 결론은 "새 도구 환영, 그러나 JS 생태계의 표면만 긁고 있다"는 균형 잡힌 입장.
도구 성능 = 언어 + 알고리즘 + 캐시. Rust/Go 라서 빠르다 는 단순 도식은 (a) 알고리즘 개선, (b) 재작성 시 더 많은 정보, (c) 자바스크립트 자체의 미탐색 최적화 여지 같은 변수를 무시한다. 동시에 "기여·디버깅 가능성"이라는 사람의 차원도 도구의 장기 가치에 들어간다.
면접에서 "왜 esbuild/swc 가 빠른가요?" 같은 질문이 나올 때 "Rust 라서 / Go 라서"로 답하면 얕다. 글의 회의론은 성능 격차의 원인을 분해해서 설명할 수 있는 능력을 키워준다. 단순한 "새 도구 = 좋다"가 아니라 트레이드오프를 평가하는 시각.
학습 포인트
면접 답변으로 연결할 학습 포인트입니다.
재작성이 빠른 이유는 "언어"가 아닐 수 있다
라이언 카르니아토 의 지적: "재작성이 빠른 건 재작성이기 때문"이다. 두 번째 만들 때는 (a) 더 많이 알고, (b) 성능을 의식하고, (c) 같은 테스트를 재활용할 수 있다. 같은 언어로 다시 짰어도 비슷한 향상이 나올 수 있다는 가설.
"새 도구가 빠르다 = 언어 덕분"으로 단정. 알고리즘/아키텍처 개선의 기여분을 분리하지 않는 분석은 약하다.
JIT 와 바이트코드 캐시는 JS의 비밀 무기
Node 스크립트는 매번 처음부터 파싱·컴파일되어 바이트코드 캐시 이점을 못 받는다. 그러나 Joyee Cheung 의 컴파일 캐시 도입으로:
export NODE_COMPILE_CACHE=~/.cache/nodejs-compile-cache
으로 즉시 빨라진다. JIT 도 함수가 "핫"해질 정도로 자주 실행되면 네이티브 수준 성능을 낼 수 있다.
"JS 는 인터프리터라 느리다"는 1999년 식 이미지. 모던 V8 은 핫 함수를 기계어로 컴파일한다.
기여 가능성은 "성능 외 가치"다
node_modules 안의 JS 코드는 누구나 console.log 찍어 디버그할 수 있다. Rust/Go 빌드 도구로 가면 진입 장벽이 올라가 일반 개발자가 "고치고 PR"하던 흐름이 끊긴다. "의존성을 디버깅·수정할 수 있다"는 사실은 무료가 아니다.
"속도가 모든 것"이라고 가정. 장기 유지보수성과 커뮤니티 규모가 조용한 비용이다.
디버깅 표면 — 세그폴트 vs 스택 트레이스
JS 도구가 실패하면 라인 번호 있는 스택 트레이스가 나오지만, 네이티브/Wasm 도구는 세그폴트나 "unreachable executed" 같은 친숙하지 않은 에러를 던질 수 있다. 주니어 개발자에게 "문제 해결 포기"를 학습시키는 부작용 가능성.
에러 메시지의 친숙성을 별것 아닌 디테일로 보는 것. 학습 곡선과 채용·온보딩 비용에 직접 영향.
읽는 순서
- 1이론
JIT, 바이트코드 캐시, AOT, Wasm 의 동작 원리를 정리. 동일 코드가 V8 에서 어떻게 핫 패스가 되는지 그림으로.
- 2구현
사내 빌드/린트 파이프라인에서
VitevsRolldown,ESLintvsOxlint를 같은 코드베이스로 측정. 빌드 시간뿐 아니라 메모리·CI 큐 시간도 함께. - 3실무
도입 결정 시 "리스크 매트릭스"(이득 / 호환성 / 디버깅 / 롤백 비용)를 작성해 팀 공유. 단계 도입(개발 도구 → 빌드 → 린트 순)을 권장.
- 4설명
"왜 esbuild/swc 가 빠른가" 를 언어/알고리즘/재작성 효과 세 축으로 설명할 수 있도록 정리.
면접 연결 질문
[감점 답변] "Go/Rust 라서 빠르다". [좋은 답변] (1) 언어 차이: 컴파일된 네이티브 코드, 병렬화 용이. (2) 알고리즘 차이: 단일 패스 파서, 더 단순한 모듈 그래프. (3) 재작성 효과: 기존 도구의 누적 이슈를 처음부터 피함. (4) 트레이드오프: 플러그인 생태계·디버깅 가능성·통합 도구 수에서 손해. 면접관이 듣고 싶은 건 "트레이드오프 인식"이다.
[감점 답변] "빠른 컴퓨터 쓴다". [좋은 답변] (1) NODE_COMPILE_CACHE 환경변수로 바이트코드 캐시 활성화, (2) --enable-source-maps 같은 디버그 옵션을 프로덕션에서 끄기, (3) 의존성 줄여 모듈 해석 비용 감소, (4) import 트리 정리로 불필요 로딩 방지, (5) 진정 무거우면 AOT 컴파일(Bun/Porffor 등) 검토.
[감점 답변] "벤치마크 빠른지만 본다". [좋은 답변] (1) 벤치마크: 우리 코드베이스에서 직접 측정. (2) 호환성: 기존 Rollup/Vite 플러그인 대비. (3) 안정성: 마이너 릴리스 빈도·이슈 회전. (4) 운영: 디버깅·로그·소스맵 품질. (5) 롤백 비용: 마이그레이션이 단방향인가. 새 기술은 "안정성 검증 후 도입"이라는 원칙.
자기 점검
JS = 느림 단순 도식. 실측 데이터 없이 단정하면 안 된다.
단점 = 학습 곡선 정도로 축소. 실제로는 OSS 기여 흐름·온보딩 비용 같은 구조적 영향이 있다.