# Firefox용 WebUSB 확장

> Clean Markdown view of GeekNews topic #28745. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=28745](https://news.hada.io/topic?id=28745)
- GeekNews Markdown: [https://news.hada.io/topic/28745.md](https://news.hada.io/topic/28745.md)
- Type: GN+
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2026-04-21T13:11:06+09:00
- Updated: 2026-04-21T13:11:06+09:00
- Original source: [github.com/ArcaneNibble](https://github.com/ArcaneNibble/awawausb)
- Points: 2
- Comments: 1

## Topic Body

- Firefox에서 **WebUSB 기능**을 사용할 수 있게 하는 확장으로, 브라우저 확장과 컴퓨터에 설치하는 **native stub**를 함께 사용하는 구조
- **Chrome의 WebUSB 구현 호환**을 목표로 하지만, API는 메인 페이지에서만 노출되며 **Web Workers**에서는 사용할 수 없음
- **Android는 native messaging 부재** 때문에 지원 대상에서 제외되며, 사전 빌드 바이너리는 macOS, Linux, Windows의 지정된 아키텍처에 제공됨
- 시스템 요구사항으로 macOS 10.15 이상, Windows 10 이상, Linux kernel 4.8 이상이 제시되며, Linux에서는 **`USBDEVFS_DISCONNECT_CLAIM`** 지원과 `/dev`, `/sys`, udev 호환 데몬 필요
- native stub는 **Rust 기반**으로 소스 빌드 가능하며, 브라우저가 바이너리를 찾으려면 운영체제별 위치 또는 Windows 레지스트리에 **native manifest** 설정 필요

---

### 기능 지원
- Chrome의 WebUSB 구현과 **호환**을 목표로 하며, 차이로 인해 소프트웨어가 동작하지 않는 경우 보고 요청
- Chrome과 달리 이 API는 **메인 페이지에서만 노출**되며, **Web Workers**에서는 사용할 수 없음
- Android는 **native messaging 기능 부재** 때문에 지원 대상에서 제외됨

### 설치
- ## 확장 설치
  - 서명된 버전은 GitHub Releases의 바이너리를 내려받아 **.xpi 파일**을 Firefox에서 열어 설치 가능
  - Firefox Developer Edition에서 테스트 버전을 로드하려면 `about:debugging`에서 "This Firefox" 선택 후 "Load Temporary Add-on…"을 사용하고 `extension/` 디렉터리의 `manifest.json` 지정 필요
- ## native stub 설치
  - 사전 빌드 바이너리 사용 시 모든 파일의 압축을 푼 뒤 Linux 또는 macOS에서는 `./install.sh`, Windows에서는 `install.bat` 실행 필요
  - 설치 스크립트는 적절한 위치로 파일을 자동 복사하고, 브라우저가 찾을 수 있도록 **native manifest** 설정 시도
  - 사전 빌드 바이너리 제공 플랫폼은 **macOS x86_64/ARM64**, **Linux x86_64/aarch64**, **Windows AMD64/ARM64**
  - 사전 빌드 바이너리를 사용하지 않을 경우 아래의 소스 빌드 절차 참고 필요
- ## 비표준 구성
  - 서로 다른 CPU 아키텍처를 가진 여러 컴퓨터 간 **Unix 계열 홈 디렉터리 공유** 구성에서 기본 설치 프로그램 문제가 알려져 있음
  - 서로 다른 CPU 아키텍처를 가진 컴퓨터 간 **Windows roaming user profile** 구성에서도 동일한 문제가 알려져 있음
  - 원인으로 native manifest 메커니즘의 설계 한계가 언급되며, 예시로 **절대 경로 사용** 포함
  - 이런 구성에서는 사용자가 임시방편의 **ad-hoc workaround**를 직접 마련해야 함

### 시스템 요구사항
- ## macOS
  - **macOS 10.15 이상** 필요
  - Firefox 시스템 요구사항과 일치
  - 더 오래된 시스템은 테스트가 충분하지 않으며, **macOS 12**가 더 현실적인 기준선으로 언급됨
- ## Windows
  - Rust 플랫폼 지원 요구사항 때문에 **Windows 10 이상** 필요
  - Firefox 시스템 요구사항과도 일치
  - **Windows 8/8.1**로의 백포팅은 이론적으로 가능할 수 있으나, 그보다 오래된 버전은 **WinUSB 제한** 때문에 동작할 것으로 기대되지 않음
- ## Linux
  - **Linux kernel 4.8 이상** 필요
  - 더 구체적으로는 커밋 `5cce438`와 `USBDEVFS_CAP_REAP_AFTER_DISCONNECT`를 포함한 커널 강력 권장
  - `USBDEVFS_DISCONNECT_CLAIM` 지원 커널 필수
  - 시스템에는 `/dev`와 `/sys`가 마운트되어 있어야 함
  - USB 장치 연결 감지를 위해 **udev** 또는 호환 데몬 필요
  - 구체적으로 `NETLINK_KOBJECT_UEVENT` 그룹 `2`에서 **`0xfeedcafe` 형식 메시지**를 브로드캐스트하는 데몬 필요

### 소스에서 빌드
- ## 일반 사항
  - native stub는 전반적으로 **Rust만으로 작성**되었으며 `native-stub` 디렉터리에서 `cargo build`로 빌드 가능
  - **크로스 컴파일** 지원되며, 지원 플랫폼에 대한 기본 설정 포함
- ## macOS
  - 저장소에 최종 바이너리 링크에 필요한 모든 **`.tbd` 파일의 vendored copy** 포함
  - 이 구성이 문제를 일으킬 경우 `.cargo/config.toml`의 관련 항목 비활성화 가능
  - 해당 항목을 비활성화하면 **macOS SDK 설치** 필요
- ## Linux
  - Linux 사전 빌드 바이너리는 **musl libc**와 Rust 기본값인 **정적 링크** 사용 구성
  - 목표는 어떤 배포판에서도 동작하는 바이너리 생성
  - 원하지 않을 경우 적절한 **`RUSTFLAGS` 변경** 필요
  - **glibc 빌드**는 동작할 것으로 예상되지만 테스트되지는 않음
- ## Windows
  - Windows 사전 빌드 바이너리는 **mingw-w64**를 사용해 **UCRT 대상**으로 빌드되도록 구성
  - Rust의 `*-windows-gnullvm` 타깃에 해당
  - Windows는 주로 Windows 외 플랫폼에서의 **cross-build**로 테스트됨
  - Windows 자체에서의 빌드는 가능하도록 되어 있으나 **`rust-mingw` 컴포넌트** 추가가 필요할 수 있음
  - Windows가 아닌 시스템에서 빌드할 경우 mingw-w64의 **`.lib` 파일**을 별도로 확보해야 함
  - 예시 확보 경로로 `Dockerfile`에 포함된 단계 언급
  - `.cargo/config.toml`에는 이 라이브러리 탐색을 위한 **하드코딩된 경로**가 있어 점검 또는 수정 필요
  - **MSVC toolchain** 빌드는 지원되지 않음
    - 근본적으로 불가능한 것은 아니지만 테스트되지는 않았다고 명시

### native manifest 설정
- 브라우저가 컴파일된 바이너리를 찾으려면 컴퓨터의 특정 위치에 **manifest 파일** 설치 필요
- manifest는 짧은 **JSON 파일**이며 운영체제에 따라 지정 위치가 달라짐
- ## macOS
  - 전역 위치 `/Library/Application Support/Mozilla/NativeMessagingHosts/awawausb_native_stub.json`
  - 사용자 로컬 위치 `~/Library/Application Support/Mozilla/NativeMessagingHosts/awawausb_native_stub.json`
- ## Linux
  - 전역 위치 `/usr/lib/mozilla/native-messaging-hosts/awawausb_native_stub.json`
  - 전역 위치 `/usr/lib64/mozilla/native-messaging-hosts/awawausb_native_stub.json`
  - 사용자 로컬 위치 `~/.mozilla/native-messaging-hosts/awawausb_native_stub.json`
- ## Windows
  - manifest 파일은 어느 위치에 두어도 되지만, 해당 파일을 가리키는 **레지스트리 키** 설정 필요
  - 전역 키 `HKLM\SOFTWARE\Mozilla\NativeMessagingHosts\awawausb_native_stub`
  - 사용자 로컬 키 `HKCU\SOFTWARE\Mozilla\NativeMessagingHosts\awawausb_native_stub`
  - 올바르게 설정된 레지스트리 항목의 스크린샷 포함
- ## native manifest 내용
  - JSON에는 `name`, `description`, `path`, `type`, `allowed_extensions` 필드 포함
  - `name` 값은 `awawausb_native_stub`
  - `description` 값은 `Allows WebUSB extension to access USB devices`
  - `path` 값은 실행 파일 경로인 `/path/to/awawausb-native-stub`
  - `type` 값은 `stdio`
  - `allowed_extensions` 값은 `["awawausb@arcanenibble.com"]`
  - Windows에서는 전체 경로가 필수가 아니며 `"awawausb-native-stub.exe"`만으로도 충분

### 개발자 문서
- 시작점으로 `Documentation/architecture.md` 경로의 **architecture 문서** 안내

## Comments



### Comment 55969

- Author: neo
- Created: 2026-04-21T13:11:08+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47832969) 
- 예전에는 **WebUSB/Bluetooth**를 이념적인 이유로 꽤 싫어했지만, 클라이밍 보드 제어 앱이나 USB로 미니디스크에 전송하는 [netMD](https://web.minidisc.wiki/) 같은 사례를 보고 생각이 바뀌었음. 이런 용도에 네이티브 앱 설치는 과하다고 느꼈고, 이제 Firefox에서도 선택지가 생긴 점이 반가움
  - 나도 비슷했음. 처음엔 회의적이었지만, 기계식 키보드 설정용 웹앱에서 **WebUSB**로 브라우저 안에서 바로 펌웨어 플래시까지 해보니 꽤 편하고 괜찮다고 느꼈음. [ZSA flash](https://www.zsa.io/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](https://web.minidisc.wiki/)로 미니디스크를 다뤄봤고, [Xiaomi BLE 온습도계용 커스텀 펌웨어](https://github.com/pvvx/ATC_MiThermometer)도 웹에서 플래시해 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](https://makecode.microbit.org/) 같은 웹 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로 찾아야 좀 더 잘 나옴