예전에는 WebUSB/Bluetooth를 이념적인 이유로 꽤 싫어했지만, 클라이밍 보드 제어 앱이나 USB로 미니디스크에 전송하는 netMD 같은 사례를 보고 생각이 바뀌었음. 이런 용도에 네이티브 앱 설치는 과하다고 느꼈고, 이제 Firefox에서도 선택지가 생긴 점이 반가움
나도 비슷했음. 처음엔 회의적이었지만, 기계식 키보드 설정용 웹앱에서 WebUSB로 브라우저 안에서 바로 펌웨어 플래시까지 해보니 꽤 편하고 괜찮다고 느꼈음. ZSA flash처럼 예전엔 레이아웃 파일을 내려받아 전용 프로그램으로 구워야 했던 작업을 이제는 Chromium 기반 브라우저만으로 끝낼 수 있어 훨씬 간단해졌음
나는 오히려 그 점 때문에 WebUSB를 원치 않음. 하드웨어 제조사가 업데이트와 설정을 웹앱에만 의존하게 되면, 언젠가 서비스가 사라지거나 로컬 실행이 불가능해졌을 때 오래된 장비가 멀쩡해도 설정조차 못 하게 될까 걱정됨. 10년 넘게 쓰는 카메라, 악기, 오디오 인터페이스 같은 장비를 생각하면 특히 더 아쉬운 시나리오임
지금까지 Windows 전용이던 각종 도구가 webusb 덕분에 어떤 OS에서든 돌아갈 수 있게 되는 점이 정말 큰 개선이라고 봄
지금은 네이티브 앱 설치가 과하다고 느낄 수 있지만, 20년 뒤 그 장비를 관리하던 웹사이트가 사라지면 같은 불편을 다시 겪게 될 수 있다고 생각함
GrapheneOS를 폰에 설치할 때 WebUSB가 사실상 핵심 경로라는 점도 인상적이었음
나는 WebUSB가 정말 훌륭하다고 느낌. 플랫폼별 차이를 일일이 처리하지 않고도 하드웨어에 접근하는 크로스플랫폼 앱을 배포할 수 있고, 드라이버도 적당히 샌드박싱할 수 있기 때문임. 보안을 더 강화하려면 WebUSB descriptor가 있는 장치만 기본 허용하고, 그 외에는 추가 경고를 주는 방식도 괜찮아 보임
최근 산 감열식 프린터들에서 Chromebook 지원이라는 이름의 WebUSB 지원이 구매 결정에 큰 영향을 줬음. 기본 프린터 드라이버 지원이 애매한 장치에서, 시스템 전체에 접근하는 수상한 드라이버 대신 권한이 제한된 Chrome 확장으로 처리할 수 있어 훨씬 안심됐음. RTL-SDR 앱도 소스 빌드 없이 바로 시험해볼 수 있어서 좋았고, WebUSB나 Web Serial 때문에 Firefox에서 Chrome으로 넘어가야 할 때마다 꽤 답답함
그 제한은 너무 강하다고 봄. 많게는 경고를 띄우는 정도면 충분하고, retrocomputing 같은 활용은 태그 없는 장치도 많이 써서 막히면 곤란함
최근 3개월만 봐도 FlipperZero, Android, 중국산 휴대용 무전기 등을 플래시하면서 샌드박스 밖의 수상한 앱을 설치하지 않아도 됐음. 이건 정말 혁신에 가깝다고 느낌
최근 친구 Pixel에 GrapheneOS를 설치해줬는데, 브라우저에서 WebUSB만으로 전 과정을 끝낼 수 있다는 점이 꽤 놀라웠음. 단점이라면 Chromium을 띄워야 했다는 점 정도였음
Pixel에서 다른 Pixel로도 GrapheneOS를 설치할 수 있어서 PC조차 필요 없었음. 이 경험이야말로 WebUSB의 실용성을 확신하게 만든 사례였고, GOS 기기라면 Chrome 대신 Vanadium을 쓸 수도 있음
Web USB와 Web Bluetooth 둘 다 정말 훌륭하다고 느낌. Web MiniDisc로 미니디스크를 다뤄봤고, Xiaomi BLE 온습도계용 커스텀 펌웨어도 웹에서 플래시해 Home Assistant와 연동했음. 수상한 스크립트나 로컬 바이너리를 돌리지 않고도 이런 작업이 가능해진 점이 특히 마음에 듦
나는 Firefox에서도 두 번 문제없이 써봤음. 라우터에 nextdns를 써서 도움이 됐는지는 확실치 않지만 어쨌든 동작했음
GrapheneOS, ESPHome, Meshtastic 같은 프로젝트가 이미 WebUSB를 잘 활용하고 있고, Google도 Stadia 컨트롤러를 일반 Bluetooth 입력 장치로 바꾸는 데 썼음. 키보드 제조사들의 설정 도구도 마찬가지임. 사용자가 장치를 명시적으로 선택해야 하니 보안 모델도 합리적이라고 보고, Mozilla가 이를 네이티브로 거부하는 태도는 지난 10년간 보여온 모습과 비슷하게 아쉽게 느껴짐
솔직히 이런 기능은 확장 프로그램이 가장 적절한 형태라고 봄. USB나 Bluetooth 스택에 웹사이트가 직접 접근하는 일은 너무 틈새 사용처라 기본 탑재보다 opt-in이 맞다고 생각함. iOS의 Bluetooth browser 같은 별도 앱처럼, 필요할 때만 쓰는 분리된 경로가 오히려 공격면과 브라우저 비대화를 줄이는 좋은 엔지니어링이라고 느낌. 이런 거대한 JS 웹 API는 더 많이 플러그인화됐으면 좋겠음
요즘은 심지어 로컬 앱조차 Chrome 전용 html & js 형태로 배포되는 경우가 늘고 있음. 브라우저가 USB에 접근하는 게 마음에 드는지와 별개로, 예전 IE 강제 시대처럼 다시 Chrome 사용을 강요받는 흐름은 더 싫음
나는 여전히 kitchen sink 없는 하이퍼텍스트 문서 리더로 웹을 다시 만들고 싶다는 생각을 함. 요즘은 LLM 덕분에 이런 프로토타입도 예전보다 현실적이라고 느낌
BBC Microbit 같은 교육용 하드웨어 플랫폼에서 WebUSB는 게임 체인저였음. 학생들에게 하드웨어를 소개할 때 그냥 잘 동작하고, MakeCode 같은 웹 IDE와 코드 참조 URL 덕분에 공유와 디버깅도 쉬워짐
이 구현은 훌륭한 proof of concept처럼 보임. 브라우저 옆에서 별도 실행 파일을 돌리는 방식이 내가 원하는 WebUSB의 최종형은 아니지만, 누군가 실제로 이 문제를 풀려고 작업 중이라는 점 자체는 반가움
반대로 나는 USB는 브라우저 안에서 직접 다루는 방식 자체가 썩 마음에 들지 않음
내 첫 반응은 이게 끔찍한 아이디어라는 쪽이었음. 웹사이트가 하드웨어에 접근하는 일 자체가 싫고, 웹캠 접근만으로도 이미 충분히 불편함
나는 조금 다르게 봄. 예전엔 장치 펌웨어를 올리려면 랜덤한 C++ 앱을 내려받아 내 시스템 사용자 권한 전체를 통째로 줘야 했음. 반면 WebUSB에선 사이트에 들어가 샌드박스 안의 플로우를 실행하고, 브라우저가 요청할 때 내가 딱 그 USB 장치 하나만 선택해 권한을 줄 수 있음. 다른 USB 장치, 파일시스템, 시스템 API, 시작 프로그램 등록, 자동 업데이트 설치 같은 건 못 하게 막혀 있으니 보안 자세가 오히려 더 낫다고 느낌
좋든 싫든 앱과 웹페이지의 경계는 이미 많이 흐려졌고, 앞으로도 더 흐려질 거라고 봄. 로컬 앱조차 Python과 Qt 대신 브라우저를 인터프리터처럼 활용하는 형태가 점점 흔해지고 있음
이 문제는 간단함. 접근 권한을 주지 않으면 됨. 다만 다른 사람이 자기 하드웨어에서 무엇을 할지까지 막으려 하지는 않았으면 함. 기업식 폐쇄 생태계만 남는 세상은 더 나쁜 방향이라고 느낌
싫다면 장치를 선택하지 말고 allow 버튼도 누르지 않으면 된다고 생각함
웹사이트는 이미 CPU와 RAM을 쓰고 있음. 그게 바로 동작 방식이라는 점도 같이 봐야 한다고 느낌
나는 아직은 사양이 draft 상태이고, 보안 측면의 우려가 충분히 해소될 때까지는 브라우저에 들어오는 걸 반기지 않음
반대로 WebUSB가 없을 때의 보안 문제는, USB 장치를 쓰려 할 때마다 신뢰하기 어려운 네이티브 드라이버를 설치해야 한다는 점이라고 봄
그렇다면 스마트폰 플래싱처럼 원래도 네이티브 프로그램을 내려받아야 하는 경우와 비교해, WebUSB가 추가로 만드는 보안 함의가 정확히 무엇인지 궁금함
사양이 아직 draft인 건 Apple이 전진을 막고 있어서라는 해석에 동의함. WebUSB, WebBluetooth 같은 API가 App Store와 경쟁하게 되니 수익 측면에서 꺼리는 것 같음. 실제 보안 모델은 사용자가 사이트별로 장치 접근을 명시적으로 허용해야 해서 다른 권한형 브라우저 API와 크게 다르지 않다고 봄
그래서 나는 Firefox가 이런 기본 기능을 안 넣을 때를 대비해, 필요할 때만 쓰는 Chrome 인스턴스를 따로 켜두고 있음
WebUSB와 WebBLE이 어디서나 지원되면 내 IoT 앱을 웹만으로 배포할 수 있어서 생산성이 크게 오를 것 같음. 앱 스토어 관련 번거로움도 줄어드는 점이 특히 매력적임
방금 이걸 처음 알게 됐고, 내 머릿속의 CCTV DVR가 휴대폰에 웹앱을 제공하면서 영상 스트리밍까지 할 수 있을지 궁금해졌음. 검색할 때는 webble 대신 Web Bluetooth API로 찾아야 좀 더 잘 나옴
Hacker News 의견들
예전에는 WebUSB/Bluetooth를 이념적인 이유로 꽤 싫어했지만, 클라이밍 보드 제어 앱이나 USB로 미니디스크에 전송하는 netMD 같은 사례를 보고 생각이 바뀌었음. 이런 용도에 네이티브 앱 설치는 과하다고 느꼈고, 이제 Firefox에서도 선택지가 생긴 점이 반가움
나는 WebUSB가 정말 훌륭하다고 느낌. 플랫폼별 차이를 일일이 처리하지 않고도 하드웨어에 접근하는 크로스플랫폼 앱을 배포할 수 있고, 드라이버도 적당히 샌드박싱할 수 있기 때문임. 보안을 더 강화하려면 WebUSB descriptor가 있는 장치만 기본 허용하고, 그 외에는 추가 경고를 주는 방식도 괜찮아 보임
최근 친구 Pixel에 GrapheneOS를 설치해줬는데, 브라우저에서 WebUSB만으로 전 과정을 끝낼 수 있다는 점이 꽤 놀라웠음. 단점이라면 Chromium을 띄워야 했다는 점 정도였음
GrapheneOS, ESPHome, Meshtastic 같은 프로젝트가 이미 WebUSB를 잘 활용하고 있고, Google도 Stadia 컨트롤러를 일반 Bluetooth 입력 장치로 바꾸는 데 썼음. 키보드 제조사들의 설정 도구도 마찬가지임. 사용자가 장치를 명시적으로 선택해야 하니 보안 모델도 합리적이라고 보고, Mozilla가 이를 네이티브로 거부하는 태도는 지난 10년간 보여온 모습과 비슷하게 아쉽게 느껴짐
요즘은 심지어 로컬 앱조차 Chrome 전용 html & js 형태로 배포되는 경우가 늘고 있음. 브라우저가 USB에 접근하는 게 마음에 드는지와 별개로, 예전 IE 강제 시대처럼 다시 Chrome 사용을 강요받는 흐름은 더 싫음
BBC Microbit 같은 교육용 하드웨어 플랫폼에서 WebUSB는 게임 체인저였음. 학생들에게 하드웨어를 소개할 때 그냥 잘 동작하고, MakeCode 같은 웹 IDE와 코드 참조 URL 덕분에 공유와 디버깅도 쉬워짐
이 구현은 훌륭한 proof of concept처럼 보임. 브라우저 옆에서 별도 실행 파일을 돌리는 방식이 내가 원하는 WebUSB의 최종형은 아니지만, 누군가 실제로 이 문제를 풀려고 작업 중이라는 점 자체는 반가움
내 첫 반응은 이게 끔찍한 아이디어라는 쪽이었음. 웹사이트가 하드웨어에 접근하는 일 자체가 싫고, 웹캠 접근만으로도 이미 충분히 불편함
나는 아직은 사양이 draft 상태이고, 보안 측면의 우려가 충분히 해소될 때까지는 브라우저에 들어오는 걸 반기지 않음
WebUSB와 WebBLE이 어디서나 지원되면 내 IoT 앱을 웹만으로 배포할 수 있어서 생산성이 크게 오를 것 같음. 앱 스토어 관련 번거로움도 줄어드는 점이 특히 매력적임