GN⁺: JavaScript 도구를 "더 빠른 언어"로 재작성 하는 것에 대한 회의적인 시각
(nolanlawson.com)- 최근 Node.js 툴을 Rust, Zig, Go 등의 더 빠른 언어로 다시 작성하려는 경향이 걱정스러우며, 객관적인 우려사항들을 정리함
[성능]
- JavaScript 툴의 속도를 높이기 위한 가능성이 아직 다 발굴되지 않았다고 봄
- ESLint, Tailwind 등에서 쉽게 개선할 수 있는 부분이 많이 존재함
- 브라우저에서 JavaScript는 대부분의 워크로드에 대해 "충분히 빠름"
- CLI 툴에서는 왜 JavaScript를 버리려 하는 것일까?
대대적인 재작성
- 오랫동안 JavaScript 툴 생태계는 "동작하는 것"에 초점을 맞추어 왔음
- 이제 API가 대부분 안정화되어 모두가 "같은 것을, 더 빠르게" 원하는 상황
- 성능을 고려해 새로 작성되고, API가 이미 정해져 있어 개발 시간을 아낄 수 있기 때문에 새 툴이 더 빨라질 수 있음
- A에서 B로 재작성하면 속도 향상이 있는데, 이는 B가 A보다 빠르다고 주장하기 쉬움
- 하지만 재작성 자체가 더 빠른 이유일 수 있음 (두 번째에는 더 많이 알고, 성능에 더 신경 쓰기 때문)
바이트코드와 JIT
- 브라우저에서는 당연하게 여기지만 바이트코드 캐시와 JIT(Just-In-Time 컴파일러)의 혜택을 받음
- JavaScript가 올바르게 캐시되면, 브라우저는 소스 코드를 바이트코드로 파싱하고 컴파일할 필요가 없음
- 자주 실행되는 함수는 기계어로 더 최적화됨 (JIT)
- Node.js 스크립트에서는 바이트코드 캐시의 혜택을 전혀 받지 못함
- 하지만 이제 Node에서도 컴파일 캐시를 사용할 수 있게 됨 (
NODE_COMPILE_CACHE환경변수 설정) - JIT는 함수를 여러 번 실행해야 "뜨거워지기" 때문에 일회성 스크립트에서는 혜택을 보기 어려움
- Pinafore에서 JavaScript 기반 blurhash 라이브러리를 Rust(Wasm) 버전으로 교체하려 했으나, 5번째 반복에 이르면 성능 차이가 사라짐
- Porffor와 같은 도구로 Node 스크립트를 AOT 컴파일하는 것을 고려해 볼 수 있음
- Wasm을 사용하면 순수 네이티브 툴에 비해 성능 저하가 있음
[기여도 및 디버깅 용이성]
- "모든 것을 네이티브로 다시 작성하기" 운동에 대한 주된 회의론임
- JavaScript는 관대한 타입, 쉬운 습득, 브라우저 지원 등으로 인해 대중적인 언어임
- 오랫동안 JavaScript 생태계에서는 라이브러리 작성자와 사용자 모두 JavaScript를 사용해 왔음
- 이는 기여의 장벽을 낮추는 데 도움이 됨
- 하지만 JavaScript 라이브러리 작성자가 다른 언어를 사용하면 이 점이 깨짐
- 또한 JavaScript 의존성을 로컬에서 수정하는 것이 간단함 (node_modules에서 직접 수정)
- 반면 네이티브 언어로 작성된 경우에는 소스 코드를 직접 체크아웃하고 컴파일해야 함
- JavaScript 라이브러리를 디버깅할 때는 익숙한 브라우저 개발자 도구나 Node.js 디버거를 사용할 수 있음
- Wasm에서도 디버깅이 불가능한 것은 아니지만, 다른 기술 세트가 필요함
[결론]
- JavaScript 생태계를 위한 새로운 세대의 툴이 나오고 있는 것은 좋은 일임
- 기존의 툴들이 매우 느리고 경쟁으로부터 혜택을 볼 것으로 보임
- 하지만 JavaScript 자체가 본질적으로 느리다거나, 개선의 여지가 없다고 생각하지는 않음
- Chromium 개발자 도구의 최근 개선사항을 보면 아직 갈 길이 멀다는 생각이 듦
- Rust와 Zig 개발자들만의 전유물이 되는 세상이 어떨지 우려됨
- 평균적인 JavaScript 개발자가 빌드 툴의 버그에 직면했을 때 무력감을 느낄 수 있음
- 젊은 웹 개발자들에게 배운 무기력함을 가르치는 셈이 될 수 있음
- 이는 알려지지 않은 길을 가는 것이며, 의도치 않은 결과를 초래할 수 있음
- 반면 덜 위험하면서도 거의 같은 결과를 얻을 수 있는 다른 길이 있음
- 하지만 현재의 흐름은 둔화될 기미가 보이지 않음
GN⁺의 의견
- Rust나 Zig 등으로 재작성하는 것이 항상 최선은 아닐 수 있음. Compile cache 등 JavaScript에서 개선할 여지가 더 있어 보임
- 초보개발자들에게 세그폴트 같은 복잡한 문제를 마주하게 하는 것이 과연 좋은 지 의문. 오히려 무기력함 만 가르칠 수도
- 오랫동안 JavaScript로 구축해온 생태계의 장점(라이브러리 간 자유로운 수정, 익숙한 디버깅 환경 등)을 희생하면서까지 속도를 높이는 것이 과연 좋은 방향일지 고민해 봐야 함
- 기존 JavaScript 라이브러리들의 개선 노력도 지속되어야 할 것으로 보임. 아직 JavaScript의 가능성이 다 발굴되지 않은 상태
- 비록 대세는 거스를 수 없어 보이지만, 이런 방향성에 대해서는 커뮤니티 차원의 진지한 토론과 고민이 더 필요해 보임
구멍가게와 대형매장의 운영방식이 좀 다를 수 있죠. 바꾸는 자체에 비판적 자세보단 이러한 현상의 의미를 생각해 보는게 건전한 생각이라 봅니다
취향이나 유행타서 바꿀수 있어 보이기도 하지만 기업이 보통 그렇게 의사 결정을 하진 않잖아요
필자가 SPA와 자바스크립트 도구 개발에 둘다 자바스크립트가 쓰이므로 그외에 필요한 제반 역량도 같다고 착각하는 것처럼 보입니다. 자바스크립트 도구에는 시스템 프로그래밍과 컴파일러 분야 역량이 필요하다고 생각합니다
오랫동안 JavaScript 생태계에서는 라이브러리 작성자와 사용자 모두 JavaScript를 사용해 왔음
이는 기여의 장벽을 낮추는 데 도움이 됨
하지만 JavaScript 라이브러리 작성자가 다른 언어를 사용하면 이 점이 깨짐
언어가 같더라도 실행 환경이 브라우저와 NodeJS로 다르고 그 간극을 넘을 수 있는 사람만 자바스크립트 도구에 기여할 수 있을텐데요. 실행 환경이 다르니 다른 생태계라고 봐야하지 않을까 합니다
평균적인 JavaScript 개발자가 빌드 툴의 버그에 직면했을 때 무력감을 느낄 수 있음
젊은 웹 개발자들에게 배운 무기력함을 가르치는 셈이 될 수 있음
이것도 마찬가지로 SPA 개발과 자바스크립트 도구 개발의 경계를 넘을 수 있는 사람의 수를 과대평가한 지점이라고 생각합니다. 프론트엔드 개발자에게 시스템 프로그래밍에 준하는 지식을 요구하는 건 무리입니다. 도구 사용자는 표면적인 에러메시지나 현상만 이해할 수 있지 않나요? 언어만 알아서 해결되는 문제가 아니라고 생각합니다
파이썬이나 자바스크립트 자체가 느린가? 에는 그렇다고 할 수 없더라도
자주 사용되는 파이썬이나 자바스크립트를 이용한 툴이 느린가? 는 Yes라고 생각합니다.
저전력 기기 여러 대를 사용 중인데 정말 분통 터지게 느린 도구들 많아요..
도구와 라이브러리를 섞어서 말하고 있는것 같네요. 라이브러리에 대해서는 어느 정도 공감할 수 있지만, 도구는 글쎄요..
다른 언어 개발자들도 도구는 네이티브로 작성되어 있는데 익숙할텐데요.
개인적으로는 도구던 라이브러리던 자바스크립트로 작성이 되어 있다면 자바스크립트에 익숙한 개발자들이 그것들을 디버깅하고 필요하다면 기여를 할 수있습니다. 그런데 러스트로 재작성 되어버리면 오픈소스 기여는 러스트 개발자들만 할 수 있게 되어버리는거죠. 자바스크립트 개발자의 파이가 러스트이 비해 압도적으로 크기 때문에 오픈소스 생태계에서 툴이던 라이브러리던 자바스크립트로 작성되는 것이 더 유리할 수있다는 거죠.
자바스크립트 파이가 크다고 해서 컴파일러 / 트랜스파일러 코드베이스에 기여할 수 있는 개발자가 더 많을지는 의문입니다. 라이브러리 프레임워크와 기반 도구는 전혀 다른 영역이라고 생각합니다.
자바스크립트는 브라우저와 NodeJS 로 실행환경이 파편화되어 있고, 따라서 언어 사용자 수 사이의 단순 비교는 논거로서 한계가 있다고 생각합니다. 백엔드 스프링 개발자와 JDK 개발자, 리액트/앵귤러/뷰 개발자와 자바스크립트 도구 개발자는 관심사와 입장이 다르며 소비자와 생산자의 관계입니다
자바스크립트 도구의 성능과 사용성 개선 목표를 위해서라면 수단인 구현 언어를 바꾸는 것도 선택 가능한 선택지라고 개인적으로 생각합니다
저는 개발 툴의 소비자와 생산자를 명확하게 구분하기 어렵다고 생각합니다. 회사가 규모가 생기면서 툴체인에 대한 커스텀이나 추가 플러그인들을 본인들이 원하는 규칙에 맞게 커스텀하거나 구현하는 경우가 많은데, 이 경우 동일 언어를 사용하는 것 만으로도 큰 이점이 있다고 생각합니다.
툴의 사용자가 툴 자체의 개선사항이나 구현에 관심을 가져 자연스럽게 기여를 하게 되는 경우도 많구요.
툴체인 커스터마이징에 관심이 생기거나 그 업무를 수행하는 사람은 소비자의 역할을 넘어서 프로슈머 내지는 생산자의 역할을 수행하고 있다고 생각하고요. 플러그인의 경우에는 생산자와 소비자 사이의 플러그인 규약 안에서 움직인다고 봅니다. 해당 상황에서 같은 언어를 사용하는 것이 별도의 설정파일 형식이나 확장포인트를 제공하는 것보단 기술적으로나 의사소통 비용에서나 도움이 되는 것은 저도 동의합니다
다만 자바스크립트 도구의 성능 문제 내지는 NodeJS의 JIT 지연 문제가 소비자의 의사결정 범위에 있다고 생각하지는 않습니다. 그런 아키텍처와 동작 명세를 만든 주체는 툴 생산자와 런타임 개발자들이기 때문입니다
파이썬 커뮤니티쪽에서도 거의 똑같은 래퍼토리의 이야기가 반복되고 있습니다.
자바스크립트는 자바스크립트로 작성되지 않았지만, 대부분의 자바스크립트 개발자들은 그 부분에 대해 신경쓰지 않습니다. "초보개발자", "젊은 웹 개발자"들에게 자바스크립트가 자바스크립트로 작성되지 않은 것은 문제가 되지 않지만 자바스크립트 개발도구는 자바스크립트로 작성되지 않은게 문제가 된다는 것은 앞뒤가 잘 맞지는 않는 이야기입니다. 오히려 그런 걸 신경쓰는 개발자들은 양 쪽 그룹 가운데의 극소수가 존재할 뿐이지요.
충분한 최적화를 거치면 거의 비슷한 속도를 낼 수 있다는 점을 부정하지 않더라도, 정말 그럴 가치가 있을까요?
그저 한 때 개발도구를 C++로 작성하지 않고 자바스크립트로 작성하는게 더 경제적이 되었던 시대에서 자바스크립트로 작성하는 것보다 Rust로 작성하는 것이 더 경제적인 시대로의 전환이 도래한 것이고요.
흐름을 되돌릴 방법은 더 많은 비용을 들여서 자바스크립트로 최적화하기 운동을 전개하는 것이 아니라 더 적은 개발비용을 들이고도 효율적인 자바스크립트 도구를 개발할 수 있도록 만들어내는 쪽이지요. (비슷한 말처럼 보일수도 있겠지만 노력을 어디에 들이냐에서 차이가 있습니다)
동의합니다. 경제성을 도구 사용자 중심으로 재정의해야 한다고 생각합니다.
그동안 경제성은 도구 사용자보다는 도구 개발자를 고려한 지표이지 않았나 싶습니다. 도구 사용자들이 경험해야 하는 비효율성과 성능 문제는 우선순위에서 비교적 뒷전으로 밀려있던 느낌입니다. 개인적으로 uv나 vite를 잘 쓰고 있고 가능하다면 pip나 create-react-app 같은 도구는 피하고 싶네요
CLI 도구는 런타임 없이 동작가능해야한다고 생각해서 동의하기 어렵네요.
WASM 단독실행 파일 만들 수 있지 않냐고 하면 본문에서도 말하듯 성능 저하가 있을거고요.
Java로 CLI 짜는게 보편적이지 않은 것처럼 JavaScript도 동일하다고 생각합니다.
매우 선택적이기 때문에 이 분의 말에는 공감합니다.
다만, 또 다른 차원에서 JS 말고도 다양한 해법이 존재한다는 것은 기술 진보 차원에서 매우 중요한 요소이기 때문에 그 반대 상황에 대해서도 존중받아야한다고 생각해요!
Hacker News 의견
-
JavaScript는 본질적으로 느리다는 의견이 있음. 많은 엔지니어들이 이를 빠르게 만들기 위해 노력했지만, 여전히 정적 타입 언어보다 느림. 대규모 프로그램에서는 타입이 명확한 언어가 더 적합함
- Rust와 Go는 도구 개발에 적합하며, TypeScript로 프로토타입을 만들지만 대규모 동시성 작업에는 다른 언어를 사용함이 바람직함
- Rust의 타입 시스템은 도구 개발에 자신감을 주며, Go의 타입 시스템은 개선이 필요하다고 생각함
-
JavaScript는 배우기 쉽지 않으며, 복잡한 프로토타입과 타입 시스템을 가짐. TypeScript가 이를 보완하지만, 여전히 복잡함
- JavaScript 생태계는 복잡하고 도구 사용이 어려움. Go는 배우기 쉬우며, 도구 사용이 간단함
- JavaScript에서 동시성을 구현하려면 복잡한 개념을 이해해야 함
-
언어 변경만으로도 성능이 크게 향상될 수 있음. 기존 시스템을 JS와 PHP에서 Go로 변경했을 때 8-10배의 성능 향상을 경험함
-
병렬 처리의 중요성이 간과되고 있음. Rust는 병렬 코드 작성에 적합하며, JS는 병렬 코드 작성에 적합하지 않음
- Rust는 스레드 안전성을 보장하여 유지보수 문제를 줄임
-
JavaScript는 이제 Java와 비슷한 속도를 가지며, C++보다 2-4배 느림. 성능을 높이려면 편안한 영역을 벗어나야 함
- 성능에 대한 개발자들의 반응이 극단적이어서 다른 직업으로 전향함
-
Rust, Zig, Go 프로그램은 소스 코드를 확인하고 컴파일하기 쉬움. 새로운 언어를 배우면 문제 해결 방식에 영향을 줌
-
JavaScript 도구의 성능을 높일 가능성을 다 소진하지 않았다고 생각함. 더 나은 기반 위에 구축하는 것이 더 효율적임
-
Rspack은 Rust로 작성된 Webpack의 호환 가능한 재작성 버전으로, 성능이 5-10배 향상됨. Webpack을 쉽게 대체할 수 있음
-
JavaScript 의존성을 로컬에서 수정하는 것이 쉽지만, Rust는 버그가 적어 수정할 필요가 적음. Rust는 배우기 어렵지만, 이를 통해 다른 언어에서도 더 나은 프로그래머가 될 수 있음
- 속도보다 정확성이 더 중요하며, 버그가 있는 라이브러리를 배포하면 사용자들의 시간을 낭비하게 됨