2026년 지금, 가장 조용하지만 가장 빠르게 일어나고 있는 변화가 있다. AI가 서버에서 브라우저 안으로 이동하고 있다는 사실이다. 배경 제거, 이미지 처리, 텍스트 생성—불과 2년 전만 해도 GPU 서버를 필요로 했던 이 작업들이 지금은 <script> 태그 하나로 사용자의 디바이스 위에서 돌아간다. 단순한 기술 트렌드가 아니다. 이것은 프론트엔드 설계의 책임 범위 자체가 바뀌는 신호다.
캔버스 없이 만든 그래픽 에디터—DOM이 렌더링 엔진이 된다
dev.to에 공개된 SMM Turbo 사례는 흥미로운 반란에서 시작한다. 웹 기반 그래픽 에디터를 만들 때 우리가 당연히 선택하는 경로는 HTML5 Canvas 또는 Fabric.js, Konva 같은 라이브러리다. 그런데 이 프로젝트는 Canvas를 아예 쓰지 않는다. 대신 <div>와 <span>, <img>를 절대 좌표로 배치하고, CSS의 -webkit-background-clip, text-shadow, transform: rotate() 등을 조합해 그라디언트 텍스트·외곽선·원형 배치 같은 타이포그래피 효과를 구현한다.
이 선택이 흥미로운 이유는 단순히 '다른 방법'이어서가 아니다. CSS가 픽셀 연산 없이도 복잡한 시각 표현을 처리할 수 있다는 사실을 프로덕트 관점에서 적극 활용했기 때문이다. 물론 DOM 기반 렌더링은 최종적으로 이미지를 저장할 때 문제가 생긴다. 해법은 html-to-image 라이브러리로 DOM 노드를 Canvas로 변환한 뒤 WebP/JPEG로 내보내고, JSZip으로 슬라이드 전체를 아카이브하는 방식이다. 렌더링은 DOM, 내보내기는 Canvas—역할을 분리해 두 방식의 장점만 취한 구조다.
Svelte 5의 $state 룬(rune)은 이 구조를 더욱 매끄럽게 만든다. 에디터의 모든 상태—슬라이드 목록, 활성 요소, 실행취소/다시실행 히스토리—를 단일 반응형 객체로 관리하면서, 언어 변경 같은 전역 이벤트도 컴포넌트 리렌더링 없이 즉시 반영된다. React에서 i18next를 붙이고 Provider를 감싸는 것과 비교하면, 코드 복잡도의 차이가 실감난다. 빠른 프로토타이핑 단계에서 이런 간결함은 실제로 의사결정 속도에 영향을 준다.
WASM으로 배경 제거를—AI가 디바이스 안에서 돌아갈 때
SMM Turbo에서 가장 주목할 지점은 배경 제거 기능이다. 보통 이 기능은 유료 구독 또는 서버 API 호출로 제공된다. 사진이 외부 서버로 전송되고, GPU가 처리하고, 결과가 돌아온다. 이 프로젝트는 @imgly/background-removal 라이브러리를 사용해 신경망 모델을 WebAssembly 포맷으로 브라우저에 직접 로드한다. 사용자의 사진은 네트워크를 한 번도 타지 않고 디바이스 위에서 처리된다.
구현 코드는 놀랍도록 단순하다. 라이브러리를 동적으로 임포트하고, removeBackground(imageBlob)를 호출하면 끝이다. 무거운 모델 파일은 첫 실행 시 캐싱되고, 이후 호출은 빠르게 처리된다. 구독 없음, 업로드 제한 없음, 프라이버시 위험 없음—세 가지를 동시에 해결하는 UX가 된다. 사용자 입장에서는 그냥 버튼을 누르면 되지만, 그 뒤에서 WASM이 로컬 추론을 실행하고 있다는 사실 자체가 프론트엔드의 책임 영역이 얼마나 넓어졌는지를 보여준다.
Canvas API로 픽셀을 직접 만진다—프레임워크 없이 충분한 이유
또 다른 사례는 더욱 원초적이다. dev.to에 소개된 네거티브 이미지 변환기는 HTML Canvas API만으로 구현됐다. 수식은 하나다: 255 - 원본 픽셀값. getImageData()로 픽셀 배열을 읽고, 루프를 돌려 R·G·B 채널 각각에 연산을 적용하고, putImageData()로 다시 쓴다. 라이브러리 없음, 프레임워크 없음, 순수 브라우저 API만으로 20MB 이미지를 밀리초 단위로 처리한다.
이 사례가 WASM+AI 배경 제거와 함께 놓여야 하는 이유가 있다. 둘 다 '클라이언트사이드 처리'라는 같은 철학에서 출발하기 때문이다. 데이터가 서버를 경유하지 않는다. 사용자의 파일은 사용자의 디바이스 안에서 태어나고 처리되고 저장된다. 복잡도의 수준은 다르지만—하나는 순수 수학 연산, 다른 하나는 신경망 추론—프라이버시와 비용 구조에서 얻어지는 이점은 동일하다. 그리고 이것이 사용자 신뢰의 근거가 된다.
로컬 AI가 다시 돌아오는 경제학
브런치에 게재된 분석은 이 기술적 흐름 뒤의 경제 논리를 정밀하게 해부한다. 핵심 명제는 이것이다: 토큰 비용은 가격표가 아니라 문제 해결의 반경이다. 클라우드 AI가 아무리 강력해도, 사용자가 비용을 의식하는 순간 그는 '문제를 밀어붙이는 사람'이 아니라 '호출량을 관리하는 사람'이 된다. AI가 사고의 증폭기가 아니라 예산 항목이 되는 순간이다.
이 분석이 제시하는 개념이 'steamroll'이다. 문제를 섬세하게 쪼개고 라우터로 분류하는 기존 AI wrapper 방식과 달리, 압도적으로 싼 지능을 대량 투입해 문제 전체를 평탄화하는 방식이다. 매물 50개, 계약서, 관리비 내역, 이사업체 견적서를 한꺼번에 넣고 AI가 수십 번 반복 검증하게 하는 것. 이 방식이 가능하려면 지능 비용이 '수도처럼' 흘러야 한다. 쓸 때마다 단가를 계산하지 않아도 되는 상태.
클라우드 AI 가격이 내려가도 로컬 AI의 정당성이 사라지지 않는 이유도 여기에 있다. 가격은 언제나 상대적이다. 클라우드가 5달러에 해결할 수 있는 문제를 로컬이 3달러 전기료로 해결한다면, 사용량이 많아질수록 그 차이는 생활비·운영비·연구비의 핵심 항목이 된다. 결정적으로 로컬 AI는 반복과 실패를 두려워하지 않게 만든다. 실패해도 다시 돌리면 된다. 이 심리적 자유가 steamroll을 가능하게 하는 진짜 조건이다.
프론트엔드 설계가 다시 써야 할 것들
세 사례를 엮어보면 하나의 큰 방향이 보인다. 브라우저가 AI를 실행하는 환경이 되고 있다. 이것은 단지 기술 스택의 선택 문제가 아니다. 프론트엔드 개발자가 설계해야 할 것들이 달라진다는 의미다.
첫째, 모델 로딩과 캐싱 전략이 중요해진다. WASM 기반 모델은 첫 실행 시 수십~수백 MB를 내려받는다. Service Worker와 Cache API를 활용한 프리로드 전략, 로딩 상태의 UX 처리가 핵심 설계 요소가 된다.
둘째, 처리 중 피드백 설계가 차별점이 된다. 서버 응답을 기다리는 스피너와 로컬 추론 중 표시하는 프로그레스는 맥락이 다르다. 사용자가 '내 디바이스가 일하고 있다'는 감각을 갖도록 마이크로인터랙션을 설계해야 한다.
셋째, 하이브리드 아키텍처가 현실적인 선택이 된다. SMM Turbo도 배경 제거는 WASM 로컬로, 텍스트 생성은 Groq API를 통한 클라우드 Llama 3.1로 처리한다. 모든 것을 로컬로 고집하거나 모든 것을 클라우드에 올리는 게 아니라, 프라이버시 민감도·응답 속도·모델 품질 요구사항에 따라 실행 위치를 선택하는 설계가 필요하다.
'빠른 프로토타이핑 → 사용자 검증 → 고도화' 흐름에서 이 변화가 갖는 의미는 명확하다. 클라이언트사이드 AI는 프로토타입 단계에서 서버 인프라 없이도 AI 기능을 사용자 앞에 세울 수 있게 해준다. 백엔드 없이도 배경 제거 에디터를 배포하고, 실제 사용 패턴을 확인하고, 그 다음 단계를 결정할 수 있다. 이것은 검증 비용을 낮추는 동시에 프라이버시라는 가치를 기본값으로 제공하는 설계다.
WebGPU의 성숙, Transformers.js의 확산, WASM SIMD 최적화의 발전—브라우저 안에서 돌릴 수 있는 모델의 크기와 종류는 계속 늘어나고 있다. 로컬 모델이 클라우드를 완전히 대체하는 시대가 오지 않더라도, '브라우저가 AI의 실행 환경 중 하나'가 되는 시대는 이미 왔다. 프론트엔드 개발자가 모델 추론 레이턴시와 WASM 번들 최적화를 고민해야 하는 시대. 그 설계의 책임이 이제 우리 쪽으로 넘어오고 있다.