브라우저에서 실제로 작동하는 AI 기능 5가지

AI 요약

저자는 Transformers.js 4.3.1을 React와 TypeScript 앱에 적용해 브라우저에서 모델 추론을 실행하는 데모 다섯 가지를 만들었습니다. 모델은 필요할 때 내려받으며 WebGPU를 지원하면 GPU에서 추론하고, 가능한 환경에서는 WebAssembly 기반 CPU 실행으로 대체합니다. 추론을 위해 AI 서버에 데이터를 보내지 않으며, 모델을 내려받아 캐시한 뒤에는 앱이 오프라인 작동을 지원하는 경우 오프라인에서도 쓸 수 있습니다. 다만 모델 다운로드와 추론에 시간이 들고, 일반 브라우저에서 대형 모델을 실행하는 방식은 아닙니다.

다섯 가지 데모

첫째는 RMBG-1.4를 이용한 이미지 배경 제거입니다. 약 4,400만 개의 파라미터를 가진 모델로, 저자가 사용한 설정에서는 약 170MB를 내려받습니다. 결과를 투명 PNG로 저장하며, 전자상거래나 경매 서비스에서 판매자가 상품 사진의 배경을 직접 제거하는 기능으로 활용할 수 있다고 제안합니다. 상용 배포 전에는 모델 라이선스를 확인해야 합니다.

둘째는 Florence-2-base-ft로 이미지 설명을 생성하는 기능입니다. 약 2억 3,000만 개의 파라미터를 가진 비전 모델이며, 기기에 따라 약 350~450MB를 받습니다. 대체 텍스트(alt text) 초안을 만들 때 쓸 수 있지만, 이미지의 목적과 맥락을 모델이 파악하지 못하거나 세부 내용을 놓치고 만들어낼 수 있어 사람이 검토해야 합니다. 추가 맥락을 입력하는 기능도 구현했지만, 모델이 이를 이미지 이해에 반영하지 않고 생성된 설명 뒤에 덧붙이는 방식에 그쳤습니다.

셋째는 자연어 불만을 고객 지원 티켓으로 바꾸는 기능입니다. 약 5억 개의 파라미터를 가진 Qwen2.5-0.5B-Instruct를 사용하며, 양자화 가중치만 약 786MB에 토크나이저 파일도 필요합니다. 저자는 일정한 필드와 올바른 JSON을 만들고 정보를 지어내지 않도록 프롬프트를 조정하고, 출력 파싱과 Zod 스키마 검증을 추가했습니다. 사용자가 티켓 내용을 수정한 뒤 복사하거나 제출하도록 구성했습니다.

넷째는 지원 티켓 의미 검색입니다. all-MiniLM-L6-v2가 티켓과 검색어를 벡터로 바꾸고 코사인 유사도를 비교합니다. 생성형 대규모 언어 모델(LLM)은 쓰지 않습니다. CPU용 양자화 모델은 약 23MB, WebGPU용 모델은 약 90MB이며, 저자는 빠르고 유용한 결과를 얻었다고 설명합니다. 데모에서는 임베딩을 메모리에 보관하지만, 데이터가 커지면 인덱싱과 저장, 성능을 고려해야 합니다.

다섯째는 LFM2.5-VL-450M을 이용한 웹캠 장면 설명과 시각 질의응답입니다. 약 4억 5,000만 개의 파라미터를 가진 모델이며, 설정에 따라 약 350~400MB를 내려받습니다. 카메라 화면을 주기적으로 설명하거나 특정 프레임을 멈춘 뒤 질문할 수 있습니다. 저자는 결과가 완벽하지 않다며 아직 신뢰할 만한 접근성 도구로 보지는 않습니다.

성능과 운영상의 제약

WebGPU는 추론 속도에 큰 영향을 주지만 브라우저와 운영체제, GPU, 드라이버에 따라 지원과 성능이 다릅니다. WebGPU를 쓸 수 없는 환경에서는 일부 모델이 WebAssembly 기반 CPU 추론으로 대체되지만 속도가 크게 느려질 수 있습니다. 저자의 Samsung Galaxy S24 FE에서는 티켓 생성과 카메라 데모가 시간 초과로 작동하지 않았습니다. 나머지 기능은 실행됐고 데스크톱보다 느렸습니다. 예외적으로 임베딩 모델은 WebAssembly 대체 경로를 사용했는데도 데스크톱과 거의 비슷한 속도로 실행됐습니다.

모델 크기도 사용자 경험을 좌우합니다. 데모 모델은 의미 검색용 양자화 모델 약 23MB부터 티켓 모델 약 786MB까지 차이가 납니다. 브라우저 캐시 덕분에 재방문 시 다시 내려받지 않을 수 있지만, 첫 다운로드는 모바일 데이터 비용과 시간을 요구하며 저장 파일이 계속 유지된다고 보장할 수 없습니다. 저자는 이미지 문자 인식도 시험했으나 원하는 수준의 신뢰도를 얻지 못해 데모에서 제외했습니다. 음성 인식은 이번에 시험하지 않았습니다.

저자는 브라우저 AI를 필수 기능이나 업무상 중요한 작업의 유일한 기반으로 삼기보다, 전자상거래와 접근성, 고객 지원의 선택 기능으로 붙이는 방식을 제안합니다. 코드는 GitHub 저장소와 라이브 데모에서 확인할 수 있습니다.

dev.to 반응

• @gramli — 좋은 글이고 정말 흥미로운 주제입니다. 하지만 흔한 개발자 환경을 떠올리지 않을 수 없습니다. Chrome 창을 여러 개 띄우고 각 창에 탭을 열 개 넘게 둔 채, 그중 몇 개에서 로컬 AI 모델까지 실행하는 모습 말입니다. 고객 중에는 오래된 하드웨어를 쓰는 사람도 있으니 Chrome이 PC 성능을 크게 잡아먹을 수 있습니다. AI가 없어도 가끔 그러니까요. 물론 하드웨어와 모델 사용 방식에 따라 다릅니다. 지금은 휴대전화로 보고 있지만 데모를 꼭 써보고 싶습니다. 배경 제거가 있다면 배경 추가도 있겠죠? 그럼 FrontKon 사진을 지어낸 게 아닌지 어떻게 알 수 있나요? 농담입니다!
  • @sylwia-lask — 맞습니다. 이런 기능은 특정 상황에서 선택적으로 제공하는 편이 좋고, 모든 사용자가 실행해야 하는 기능이어서는 안 됩니다. 그래도 Chrome은 이미 약 4GB짜리 Gemini Nano 모델을 내려받아 비슷한 일을 하고 있습니다. 신기한 작은 AI 모델을 내려받는 일이 완전히 새로운 건 아니죠. 사진 이야기도 맞습니다. 요즘은 사진만으로는 아무것도 증명하지 못합니다. 백악관 앞에 서 있는 제 사진을 만들어서 거기 다녀왔다고 주장할 수도 있으니까요.
• @technogamerz — 왜 그런지는 모르겠지만 이 이미지들을 보니 기분이 좋아집니다.
  • @sylwia-lask — 정말 다정한 말이네요. 그때 정말 행복했습니다.
• @dannwaneri — 코드와 라이브 데모를 공유해줘서 고맙습니다. 곧 시험해보겠습니다. 저는 티켓 모델보다 임베딩 모델을 먼저 배포하겠습니다. 4번 데모의 임베딩 모델은 약 23MB라 사용자 부담이 거의 없지만, 티켓 모델은 786MB로 부담이 훨씬 큽니다. 많은 사용자에게 모바일 데이터는 공짜가 아니라 실제 비용이 듭니다. 브라우저 모델은 아직 시험하지 않았지만 완전 오프라인으로 작동하는 제 프로젝트 StacksNG에서는 파일 크기가 중요합니다. 휴대전화에서 시간 초과된 데모 두 가지는 무엇인가요? 의미 검색은 작동했나요? 제가 알아낸 결과도 알려드리겠습니다.
  • @sylwia-lask — 맞습니다. 모바일 데이터는 공짜가 아니며 중요한 지적입니다. 와이파이에서만 모델을 내려받도록 허용하는 방법도 있을 수 있습니다. 이런 모델을 업무상 중요한 기능에 의존하기에는 아직 이르다고 보는 이유이기도 합니다. 휴대전화에서 작동하지 않은 두 가지는 티켓 생성과 카메라 데모입니다. 나머지는 작동했지만 데스크톱보다 눈에 띄게 느렸습니다. 임베딩 모델은 예외로 데스크톱과 거의 비슷한 속도였습니다. 다만 WebAssembly 대체 경로를 사용했다는 점은 감안해야 합니다. 시험 결과를 기다리겠습니다.
• @sinarezaei — 오프라인 제품이라면 임베딩을 우선하는 접근이 타당합니다. 다만 로컬 인덱스가 커질 때 검색 파이프라인이 어떻게 작동하는지 살펴보겠습니다. 임베딩 생성 비용이 낮더라도 저장과 오래된 벡터 갱신, 순위 매기기가 실제 병목이 될 수 있습니다. 지원 티켓 시스템이라면 사용자가 같은 버그를 전혀 다른 표현으로 설명하는 경우를 포함해 실제 질의에서 검색 품질도 측정해야 합니다. 데모에서 인상적으로 보이는 큰 모델보다 올바른 티켓을 꾸준히 찾아주는 작은 모델이 훨씬 유용할 수 있습니다.

원문: dev.to / 번역·요약: Trawling