대부분의 앱은 필요 이상으로 느리다 — 그 이유는 (Live Demo🛸)

Source: Dev.to

위 링크에 있는 전체 텍스트를 제공해 주시면, 해당 내용을 한국어로 번역해 드리겠습니다.

브라우저는 UI 레이어 그 이상

우리는 21세기의 4분기째에 살고 있으며, 브라우저는 조용히 UI 레이어를 넘어선 무언가로 진화했습니다. 브라우저는 다음을 수행할 수 있습니다:

• 복잡한 연산 실행,
• GPU 활용,
• 오디오 처리,
• 물리 시뮬레이션, 그리고
• 머신러닝 모델 실행까지.

그럼에도 불구하고… 대부분의 경우 우리는 여전히 브라우저를 양식과 대시보드용 도구로만 취급합니다.

플랫폼이 이미 제공하는 기능을 실제로 활용했을 때 어떤 일이 일어나는지 보여주고 싶었습니다.

이벤트 간단 요약

볼로냐에서 열린 jsday 컨퍼런스가 막 끝났으며, 솔직히 정말 놀라웠습니다. 이런 행사에 참석할 가치가 있는지 궁금하시다면 — 전혀 의심할 여지가 없습니다. 기사나 튜토리얼에서 얻을 수 있는 것보다 훨씬 더 무한한 영감을 제공합니다.

시간이 조금 있다면, 제 LinkedIn 게시물에 좋아요를 눌러주시면 정말 감사하겠습니다.

WebGPU + WebAssembly: 왜 함께 이야기할까?

내가 이전에 올린 글들을 따라오셨다면, 내 발표가 WebGPU와 WebAssembly에 관한 것이었고, 브라우저에서 이들을 사용함으로써 얻을 수 있는 이점에 대해 다루었다는 것을 아실 겁니다.

• WebAssembly는 CPU에서 실행되며, 저수준의 컴파일된 코드를 브라우저에서 직접 실행할 수 있게 해줍니다.
• WebGPU는 이름 그대로 GPU에 접근할 수 있게 해주며—추상화되고 제한된 방식이 아니라 비교적 직접적이고 강력한 형태로 제공합니다.

두 기술은 설계상 서로 보완적입니다.

추가 읽을거리

• Will WebAssembly Kill JavaScript? Let’s Find Out (Live Demo)
• Why WebGPU Feels Like the Future of the Web (Live Demo)

Source: …

구체적인 예시

각 기술을 별도로 이야기하는 대신, 두 기술을 결합한 작은 데모를 만들었습니다.

• Repo:
• Live demo:

무엇을 하나요?
입력 필드에 텍스트를 입력하면, 텍스트가 입자로 변환되고 마우스를 클릭‑드래그하면… 텍스트가 폭발합니다.

완전히 쓸모없나요? 네.
조금 중독성 있나요? 역시 그렇습니다 😅

Step 1 – Canvas 2D

입력된 텍스트는 순수 JavaScript와 Canvas 2D를 사용해 이미지 비트맵으로 렌더링됩니다. 이는 고전적인 브라우저 API만으로도 충분히 처리할 수 있는 전형적인 작업이며, 특히 이런 데모에서는 다른 곳으로 옮길 필요가 없습니다.

Step 2 – WebAssembly

비트맵은 WebAssembly로 전달되고, 여기서 의도적으로 “다소 과도하게 설계된” 알고리즘이 이미지를 입자로 매핑합니다. WASM이 실제로 의미 있는 일을 하게 하고 싶었고, 솔직히 말해 이렇게 하면 더 멋져 보이기도 합니다.

벤치마크: WebAssembly는 동등한 JavaScript 구현보다 대략 2–3배 빠릅니다 (JS 버전을 크게 최적화한 뒤에도).

이 데모에서는 차이가 크게 중요하지 않는데, 그 단계가 재구성 시 한 번만 실행되기 때문입니다. 하지만 수백·수천 번 수행해야 할 경우, 자릿수 차이의 성능 향상이 결정적이 됩니다.

Step 3 – WebGPU

입자들은 WebGPU로 전달됩니다 — 여기서 브라우저가 진정으로 힘을 발휘합니다.

같은 브라우저, 같은 앱, 같은 머신 — 하지만 작업에 맞는 올바른 도구를 사용함으로써 완전히 다른 수준의 성능을 얻을 수 있습니다.

언제 필요할까?

이것은 일반적인 프론트엔드 CRUD 설정이 아닙니다. 대시보드나 폼을 만들기 위해 WebGPU가 필요할 가능성은 낮으며, 많은 경우 실제 병목 현상은 계산이 아니라 네트워크입니다.

하지만 이 접근 방식이 큰 차이를 만드는 문제 영역이 전체적으로 존재합니다:

• 실시간 데이터 시각화
• 물리 시뮬레이션
• 그래픽이 많이 필요한 인터페이스
• 오디오 처리
• 게임
• 이미지 또는 비디오 변환
• 매트릭스 중심 작업(예: 머신 러닝, LLM) 을 브라우저에서 직접 실행

그리고 재미있는 점은, 이게 필요하지 않다고 생각하다가 어느 순간 갑자기 필요해진다는 것입니다. 제품이 진화하고, 요구사항이 늘어나며, 성능이 문제가 되거나 백엔드의 일부 작업을 클라이언트로 옮기고 싶을 때가 바로 그때입니다. 그때부터 상황이 흥미로워지기 시작합니다.

데모는 어떻게 구성되어 있나요?

저장소를 살펴보면 중요한 점을 알 수 있습니다: 이것은 일반적인 React 앱일 뿐입니다.

• 이색적인 아키텍처도 없고, “다른 행성에서 온” 스택도 없습니다.
• Rust가 WASM으로 컴파일되고 WebGPU 셰이더가 포함되어 있지만, 이는 표준 프론트엔드 설정에 단순히 삽입된 것입니다.
• 나머지 앱은 내일 프로젝트에서 바로 시작할 수 있는 것과 똑같이 보입니다.

이는 의도된 설계였습니다. 이 것이 특정 니치 용도에만 예약된 먼 실험용 놀이터가 아니라는 것을 보여주고 싶었습니다. 실제로 필요할 때 점진적으로 실제 애플리케이션에 통합할 수 있는 것입니다.

Note: WebGPU는 아직 보편적으로 지원되지 않으므로 대체 전략이 필요합니다. 하지만 많은 사용자에게는 이를 탐색하기 시작하지 않을 이유가 거의 없습니다.

요점

브라우저는 이제 단순히 UI를 렌더링하는 장소가 아닙니다.
그 자체가 강력한 컴퓨팅 플랫폼이며, 기본적으로 CPU와 GPU 모두에 접근할 수 있습니다.

• 모든 프로젝트에 WebAssembly나 WebGPU가 필요한 것은 아닙니다. 대부분의 경우 이들 없이도 충분히 잘 동작합니다.
• 성능 한계에 부딪히거나, 문제의 성격이 단순 UI에서 무거운 연산으로 바뀔 때 이 도구들이 게임 체인저가 됩니다.

“데이터를 옮기는 것”에서 “실제로 계산을 수행하는 것”으로… 플랫폼이 이미 해결책을 가지고 있었다는 것을 깨달을 수 있습니다.
그리고 우리가 해야 할 일은 그것을 사용하는 것뿐이었습니다. 🚀