(번역) 자바스크립트의 역설

원문: https://dev.to/this-is-learning/the-javascript-paradox-2njj

자바스크립트만큼 혐오스럽지만 널리 사용되는 언어가 있었는지 잘 모르겠습니다.

저는 자바스크립트를 혐오하는 편이 아닙니다. 저는 자바스크립트를 꽤나 좋아합니다. 자바스크립트가 조금 별나고 단점들이 존재해도요. 어떤 스킴을 기반으로 구축되었든 간에 자바스크립트는 가장 널리 퍼진 프로그래밍 언어가 될 운명이었습니다.

자바스크립트는 스크립트 언어이자 웹 언어로 페이지의 작은 상호 작용을 지원하기 위해 사소한 작업을 수행하기 위한 짝이 되도록 설계되었습니다.

그러나 웹은 원래 설계했던 것 이상으로 훨씬 더 많이 성장했습니다. 컴퓨터, 휴대폰, 텔레비전, 시계와 모든 종류의 IoT 장치 그리고 단순한 콘텐츠 사이트에서 몰입형 가상현실 비디오 게임까지 모든 종류의 경험과 장치를 포함하게 되었습니다.

그리고 자바스크립트도 그것들과 함께하게 되었습니다.

경이로운 코스믹 파워와 자그마한 생활 공간

웹 기반이 우리에게 반복적으로 보여준 한 가지는 네트워크가 리소스로서 얼마나 중요한지입니다. 대부분의 프로그래밍은 메모리나 디스크 속도와 관련이 있지만 웹은 항상 네트워크와 관련이 있습니다. 이는 모든 플랫폼에서 사용 할 수 있고 실제로 유일하게 사용 가능한 선택지입니다. 이점은 자바스크립트를 가장 독특하게 개발하게끔 이끌었습니다.

자바스크립트는 어떻게 보나 동적으로 타입이 지정되는 인터프리터 스크립트 언어이지만, 이제는 트랜스파일러, DSL의 용광로(melting pot), 그리고 모든 툴체인이 되었습니다. 자바스크립트의 기계는 영혼을 잃은지 오래입니다. 모든이에게 모든 것이 되어야 하지만 눈에 띄지 않을 정도로 작고 적은 리소스를 소비해야 합니다.

역주: 용광로로 번역된 melting pot은 다양한 인종 또는 생각이 함께 뒤 섞여있는 장소 또는 상황을 뜻합니다.

자바스크립트로 애플리케이션을 개발하려 검토할 떄 가장 극명한 사실은 궁극적으로 애플리케이션의 잠재력이 얼마나 크더라도 결국 가장 낮은 장치 성능과 네트워크 속도에서도 잘 동작할 수 있게 하는 것이 가장 중요하다는 것 입니다. 이는 우리가 따라야 할 물리 법칙이며 피할 수 없는 진실입니다.

자바스크립트 프레임워크의 역할

개발자가 원하는 성능을 달성하는 데 도움이 되는 언어나 프레임워크는 흔합니다. 그렇다면 우리의 코드를 지워보는 것은 어떨까요? 대부분의 성능 지향적인 자바스크립트 프레임워크는 적은 자바스크립트를 실행하는 것에 집착합니다.

자바스크립트 프레임워크는 아마도 누구보다 자바스크립트 코드를 적게 생성하는데 더 관심 있을 것입니다. Svelte나 Solid 같은 프레임워크가 Stimulus나 Alpine 보다 더 작은 것을 보면 알 수 있습니다. Marko, Astro 그리고 Qwik이 부분 하이드레이션에 집중하는 것을 보고도 알 수 있죠. React 서버 컴포넌트 또한 이러한 관심을 반영합니다.

우리는 필요하지 않은 코드를 단 한 비트도 남기지 않기 위해 번들러와 컴파일러에 크게 의존합니다. 이를 통해 우리의 템플릿에서 실행되는 마지막 한 비트까지 모두 최적화하는 것을 목표로합니다. 프레임워크 제작자들은 이 모든 것을 가능케 하도록 의도가 더 잘 드러나는 명확한 언어를 만듭니다. 앱을 분석해 서버에서만 실행 가능한 코드와 양쪽 모두에서 실행되는 코드를 분리하고 이 정보를 이용해 데이터 직렬화 비용을 줄입니다.

우리는 재개 가능성(resumability)과 같은 새로운 개념을 통해 브라우저에서 어떻게 부팅 비용을 줄일지 알려주도록 서버 사이드 렌더링을 활용하기도 합니다. 서버에서 애플리케이션을 실행하면 컴파일 시 미리 처리하지 못하는 차이를 줄일 수 있습니다.

everything OK babe? you’ve barely touched the newest JS framework

— Madison Kanna (@Madisonkanna) August 4, 2022

우리가 이야기하고 있는 와중에도 매주 새로운 자바스크립트 프레임워크가 등장하고 있습니다. 한계를 뛰어넘고 혁신하기 위한 끝없는 투쟁. 결코 만족할 수 없는 배경지식들이 이 공간을 맴돌고 있습니다. 심지어 이를 지칭하는 자바스크립트 피로(JavaScript Fatigue)라는 용어도 존재합니다. 선택과 학습의 복잡성에 파묻혀 끝없는 언데드의 흐름처럼 계속 솟아오르고 있습니다. 과거의 잔재 위에 세워진 건물과 같습니다.

이것이 반드시 나쁘다는 이야기가 아닙니다. 이는 할 일이 더 많아질 징조입니다. 현상을 유지하는 것이 10점 만점에 8점이 아니라 10점 만점에 4점에 가깝다는 관점으로 달리 바라보면 이 중 어느 것도 놀라운 일이 아닙니다. 자바스크립트 피로는 현실이 기대를 충족하지 못하기 때문에 발생합니다. 그 기대에 대해 좀 더 이야기해 봅시다.

자바스크립트의 역설

우리는 네트워크에 크게 의존하지 않고 더 많은 상호작용과 더 좋은 사용자 경험을 열망해 해결하려는 문제를 만들었습니다. 모든 방식의 웹 사이트와 애플리케이션을 구축할 수 있는 단일 툴셋을 만들길 원합니다.

하지만 이는 그 이상입니다. 우리는 백엔드 언어를 선택하고 자바스크립트를 그 위에 뿌려놓을 수 있습니다. 그리고 한동안은 괜찮을 수도 있습니다. 기계적으로 말하면 이것이 우리가 원하는 전부입니다. 하지만 지난 10년 동안 우리가 겪었던 개발자 경험을 되돌리는 것은 사실상 불가능합니다. 서버 애플리케이션 위의 자바스크립트를 꾸준히 성장하지만 원치 않게 버려진 아이처럼 있게 하는 대신 단일 애플리케이션으로 작성할 수 있는 기능이 필요합니다.

프런트와 백 사이의 경계를 줄임으로써 어떤 것이든 더 많은 이점을 얻을 수 있습니다. 자바스크립트를 풀스택으로 사용하는 것은 논란의 여지없이 자바스크립트를 덜 제공하는 가장 좋은 방법입니다.

다른 언어 런타임을 사용하면 10ms를 절약할 수 있지만 서버에서 자바스크립트를 사용했을 때 대상 장치의 최종 사용자에게 미치는 영향을 고려하면 100ms가 될 수 있습니다. 이는 최종 사용자에게 더 큰 영향을 미칩니다.

하지만 이는 분명히 당신의 최종 결정에 영향을 미칠 수 있습니다. 자바스크립트의 유일한 존재 목적은 브라우저였으며 이제 우리는 그것을 모든 곳으로 가져왔습니다.

우리는 막다른 길에 다다른 걸까요?

글쎄요. 적어도 지금 현재는 그렇습니다. 이는 브라우저의 유일한 언어인 자바스크립트의 직접적인 확장입니다. WASM은 일부 영역에서 가능성을 보여주지만 아직 사용자 인터페이스 측면에는 영향을 미치지 못하고 있습니다. 극복해야 할 내재적 비용이 존재합니다.

So I don't think perf is a super compelling reason to use a WASM frontend framework.

And that's also why rewriting React/Svelte/SolidJS/etc. in WASM won't really amount to significant performance gains, if any.

— zack (@zack_overflow) July 27, 2022

최종 사용자의 장치와 네트워크가 중요 경로에 있는 경우 이를 최적화하는 것이 우리가 할 수 있는 가장 효과적인 방법일 수 있습니다. 그리고 자바스크립트를 퇴치하는 가장 좋은 방법은 우리가 더 많은 자바스크립트를 사용하는 것입니다.

누군가는 LiveView 또는 HTMX와 같은 서버 중심 아키텍처를 말할 것입니다. 그리고 거기엔 비용 절감에 대한 훌륭한 접근 방식이 포함되어 있습니다. 이러한 아키텍처들은 서버 중심 관점을 유지하기 위해 개발자로부터 자바스크립트의 일부를 추상화합니다. 그러나 클라이언트에서 상호 작용을 원할 때 자바스크립트가 유일한 선택지인 경우(오프라인 등 어떤 이유로든...)에는 자바스크립트를 선택할 수밖에 없습니다.

자바스크립트를 위한 도구는 Rust, Go 그리고 Zig로 이동했습니다. 더 나은 성능과 이를 활용하여 모든 자바스크립트에 대한 저작 경험을 허용하는 더욱 창의적인 방법에 대한 열망이 있습니다.

은탄환을 찾아서

오해하지 마세요. 언제든지 HTML 사이트를 구축하고 필요에 따라 자바스크립트 추가할 수 있습니다. 이 모든 동기는 단일 앱 사고방식의 개발을 확장하려는 곳에서 비롯됩니다. 이것은 모든 프로젝트의 관심사가 아닙니다.

그러나 제가 찾게된 한가지 흥미로운 사실은 검색을 통해 저가형 장치 및 네트워크에 대한 문제에 접근하는 방법이 한 가지 이상 있다는 것 이었습니다. 저는 지하철과 같이 간헐적으로 중단되는 빠른 네트워크에 익숙한 사용자의 경우, 방정식을 변경하지 않고 일부 기본 사례에 대해 최적화하는 방법이 쉽다고 했었습니다.

eBay had a big year of performance optimization: https://t.co/dQTHvE2Tib ~ smaller payloads, smart prefetching & edge-caching had an impact.

For every 100ms improvement in search page loading time, they saw a 0.5% increase in Add to Cart count! ⚡️ pic.twitter.com/4z4OPo0Vfp

— Addy Osmani (@addyosmani) January 28, 2020

Amazon이나 eBay와 같은 거대한 글로벌 이커머스가 어떻게 운영되는지, Google 검색과 같은 서비스가 어떻게 이를 다루고 있는지 살펴보면 그것을 확인할 수 있습니다. 작게, 가볍게 구축하며 서버를 영리하게 활용하여 가장 빠른 초기 로드 및 상호 작용을 얻습니다. 이것이 수익에 어떤 영향을 미치는지 보여주는 충분한 연구가 있습니다.

그러나 중국과 인터넷 환경이 고르지 못한 일부 다른 지역에서는 완전히 다른 모델을 채택했습니다. 기존 모바일 앱에 플러그인 방식의 하위 앱으로 로드되는 PWA와 조금 유사한 미니 프로그램으로 일종의 지역화된 앱 스토어입니다.

초기 페이지 로드를 최적화하는 대신 백그라운드 데이터 로드를 최적화해 네트워크나 장치 리소스에 관계없이 앱을 최대한 잘 실행할 수 있도록 합니다. 향후의 네트워크 요청을 절약하기 위해 종종 더 많은 자바스크립트를 가져오는 것은 매우 유익한 걸로 보입니다. 서버 활용과 전혀 관계없는 제한된 환경의 전체 웹 애플리케이션 생태계입니다.

중요한 사실은 네트워크나 장치 리소스에 관계없이 앱이 잘 실행되도록 하는 것이 항상 그렇게 단순하지는 않다는 겁니다. 만약 이 격차를 해소할 방법이 있다면 아마 오늘날에도 자바스크립트를 더 많이 사용하는 것일 것입니다.

결론

이 주제는 우리에게 많은 질문을 던집니다. 자바스크립트가 백엔드를 계속 잠식해야 할까요? 자바스크립트로 다른 언어와 플랫폼을 활용할 수 있는 더 나은 방법이 있을까요? 우리가 웹에 대한 통일된 비전을 추구해야 할까요?

아니 어쩌면 우리 모두에게 어떻게 이런 독점이 일어나도록 내버려 두었는가에 대해 되물어야 할까요?

웹 사이트와 애플리케이션을 구축하는 방법에는 무한한 선택지가 있지만 자바스크립트는 상당한 이점이 있습니다. 때문에 실제로 고객에게 적게 전달하는 것이 가장 좋은 방법일 것입니다. 그리고 제겐 일종의 미친 짓입니다.

논의

원문의 Discussion에 저자가 작성한 첫번째 댓글 내용입니다.

네 그게 제가 결론에서 언급했던 것입니다. 하지만 Fresh(그리고 Marko, Qwik 그리고 Astro 등과 같은)와 같은 것에서도 백엔드 사고방식으로 자바스크립트에 대해 이야기하고 있습니다. 페이지 렌더링을 위한 자바스크립트 작성 솔루션입니다.

SPA 대 non-SPA나 SSR 및 SSG에 대한 이야기가 아닙니다. 저는 이 경계가 흐려지길 기대합니다. 이는 JS대 non-JS 그리고 서버에서의 JS에 대한 의문입니다. 프레임워크에서 인프라 제공자에 이르기깨지 모두 새로운 캐싱 메커니즘과 Edge/CDN 하이브리드에 대한 해법을 찾고 있지만 JS 앱 작성이 해답이라고 생각합니다. 이것이 양쪽 이점을 모두 가져갈 수 있는 방법입니다. 그리고 서버측에서는 SPA의 구별의 중요성이 떨어지며, 특히 캐싱이 서버사이드 렌더링에 최적화된 프레임워크의 경우 더욱 더 그렇습니다. 저는 이 주제에 대해 Vercel의 Guillermo 그리고 Netlify의 Mathias와 대화를 나눴고 엣지 캐싱이 대화의 핵심이었습니다. Dynamic은 새로운 정적 캐싱 서스펜스 바운더리 또는 부분 템플릿 등의 엣지 스티칭입니다.

저는 이 대화에서 어떻게 하면 최고의 경험을 전달할 수 있을까에 대해 SolidJS의 저자, Netlify의 직원, 그리고 20년 넘게 웹을 구축해 오며 스스로 찾아낸 것을 말하고 있을 뿐입니다. 저는 백엔드 개발자로 프로 경력을 시작했고, 그 후 8년간 프로덕션에서 SPA를 유지하며 보냈으며, eBay에서 몇 년 동안 2014년 자바스크립트 프레임워크에서 아일랜드를 개척한 오픈 소스 프레임워크 Marko 관련 업무를 했습니다. 그리고 우리가 어떻게 하든, 누가 대화에 참여하든, 우리는 다시 이 결론으로 돌아올 것입니다. 모든 지표는 자바스크립트를 가리키고 있습니다.

저는 모든 지표가 하나의 솔루션을 가리킬 때 늘 주의합니다. 저는 생각을 밀어붙이는 것에 대해 반대되는 주장이 있길 원하지만 현재 이러한 반대 주장은 존재하지 않고 실제로 지난 몇 년 간 존재하지 않았습니다. 솔루션의 범위를 가장 잘 처리하는 솔루션이 있지만 전체 스펙트럼을 처리하는 데에는 자바스크립트 만한 것이 없습니다. 이는 제가 모든 노력들이 너무 과한게 아닌가 의심하게 만듭니다. 저는 제 가설을 검증하기 위해 벤치마킹 하는 경향이 있는데,
이 문제는 규모가 크고 모든 조각들을 함께 보기 전까지는 알 수 없기 때문에 여기서 우리는 우리가 필요한 것을 우선 구축한 뒤 조정해야합니다.

🚀 한국어로 된 프런트엔드 아티클을 빠르게 받아보고 싶다면 Korean FE Article(https://kofearticle.substack.com/)을 구독해주세요!