브라우저가 하드웨어를 만나다: Web 블루투스 연결 테스트 완벽 가이드

별도의 네이티브 앱을 빌드하고 스토어 심사를 기다리는 과정은 이제 구시대적인 낭비입니다. 브라우저 창 하나만으로 주변 하드웨어를 직접 스캔하고 데이터를 주고받는 시대, Web Bluetooth API 가 현실이 되었습니다.

하지만 막상 개발자 도구를 켜고 navigator.bluetooth.requestDevice() 를 호출해 보면 좌절감부터 밀려옵니다. "장치 없음"이라는 메시지가 뜨거나, 연결은 되는데 데이터는 오가지 않는 경우가 비일비재하죠. 이는 API 의 결함이 아니라, 우리가 하드웨어와의 통신 프로토콜을 너무 소프트웨어 관점에서만 접근했기 때문입니다.

1 단계: 권한 획득과 장치 필터링의 미묘한 균형

대부분의 실패는 여기서 시작됩니다. 사용자가 '연결' 버튼을 누르는 순간 브라우저가 팝업을 띄우지만, 정작 목록은 비어 있습니다. 근본 원인은 대부분 과도하게 엄격한 필터링 조건 혹은 누락된 서비스 UUID 에 있습니다.

단순히 acceptAllDevices: true 로 설정하는 것은 보안 정책상 제한적으로しか 작동하지 않으며, 특정 서비스를 명시해야 하는 경우가 상당한 수준으로 많습니다. 예를 들어, heart rate monitor 를 대상으로 한다면 optionalServices 배열에 'heart_rate' 를 반드시 포함시켜야 합니다. 이 과정을 생략하면 연결 자체는 성공해도 실제 특성 (Characteristic) 에 대한 읽기/쓰기 작업을 수행할 수 없게 됩니다.

코드 조각에서 보듯, filters 와 optionalServices 의 조합은 단순한 옵션이 아니라 하드웨어 펌웨어가 노출하는 GATT 프로필과의 정확한 정렬을 의미합니다. 개발자는 자신이 다루는 기기가 어떤 Service UUID 를 광고하고 있는지 datasheet 를 뒤져서 확인하는 번거로운 작업을 선행해야 합니다. 귀찮다고 넘기면 이후 디버깅 지옥이 펼쳐집니다.

// 잘못된 예: 필수 서비스를 optionalServices 에 넣지 않아 접근 불가
const badOptions = {
  filters: [{ services: ['battery_service'] }],
  // 'battery_service' 에 대한 접근 권한이 명시되지 않음
};

// 올바른 구현: 명시적 서비스 선언을 통해 접근 권한을 확보하다
const goodOptions = {
  filters: [{ services: ['battery_service'] }],
  optionalServices: ['battery_service'], // 접근하려는 서비스를 반드시 여기에 추가
};

try {
  const device = await navigator.bluetooth.requestDevice(goodOptions);
  // 연결 성립 후 서버 객체 획득을 위한 대기 작업 수행
  const server = await device.gatt.connect(); 
} catch (error) {
  console.error('장치 선택 또는 연결 과정에서 오류 발생:', error);
}

2 단계: GATT 서버 연결 및 서비스 탐색의 깊이

장치가 선택되었다고 해서 끝난 게 아닙니다. 이제부터가 진짜 기술적 상호작용이 시작되는 구간입니다. device.gatt.connect() 메서드는 블루투스 저에너지 (BLE) 프로토콜 스택과의 복잡한 핸드셰이크 과정을 수행하며, 이 작업이 완료될 때까지 비동기적으로 대기해야 합니다.

많은 초보 개발자가 간과하는 점은, 연결이 되었다고 바로 데이터를 읽을 수 있다고 착각한다는 것입니다. 실제로는 연결된 GATT 서버로부터 원하는 Primary Service 를 찾아내고 (getPrimaryService), 다시 그 서비스 안에 포함된 특정 Characteristic 을 찾아내는 (getCharacteristic) 계층적 탐색 작업을 차례로 수행해야 합니다. 이 과정이 제대로 이루어지지 않으면, 마치 주소는 알지만 문짝을 찾지 못한 채 헤매는 것과 다름없습니다.

특정 IoT 기기 제조사들은 표준 UUID 대신 벤더 고유의 128 비트 UUID 를 사용하는 경우가 빈번합니다. 이때는 문자열 형태의 UUID 를 정확히 입력하지 않으면 탐색 자체가 불가능해집니다. 오타 하나, 대소문자 구분 하나가 전체 통신 링크를 끊어버립니다.

탐색 로직을 구현할 때는 에러 핸들링을 철저하게 수행해야 합니다. 네트워크 불안정이나 기기의 절전 모드 진입 등으로 인해 중간 단계에서 연결이 끊어질 수 있기 때문입니다. 단순히 try-catch 로 감싸는 것을 넘어, 각 단계별로 연결 상태를 검증하고 필요시 재연결을 시도하는 회복 탄력성을 갖춘 로직을 구축하는 것이 바람직합니다.

3 단계: 실시간 데이터 스트리밍과_notify_ 이벤트 처리

이제 핵심인 데이터 교환 단계입니다. 대부분의 센서 데이터는 폴링 (polling) 방식이 아닌, 기기가 변화가 있을 때 스스로 알려주는 notify 또는 indicate 방식을 통해 전송됩니다. 여기서 characteristic.startNotifications() 호출은 선택이 아닌 필수 사항입니다.

이 메서드를 호출하면 브라우저는 백그라운드에서 해당 특성에 대한 구독을 등록하고, 하드웨어로부터 패킷이 도착할 때마다 characteristicvaluechanged 이벤트를 발생시킵니다. 중요한 건, 이 이벤트 리스너 내에서 수신된 DataView 객체를 어떻게 해석하느냐입니다.

블루투스 패킷은 바이트 배열로 날아옵니다. 이를 그대로 쓰면 의미가 없습니다. 기기 프로토콜 명세서에 따라 엔디안 (Endianness) 을 고려하여 getInt16, getUint8 등의 메서드로 적절한 오프셋에서 값을 추출해 내는 변환 작업을 수행해야 비로소 온습도나 가속도 값이라는 의미를 갖게 됩니다.

characteristic.addEventListener('characteristicvaluechanged', event => {
  const value = event.target.value;
  // DataView 객체로부터 실제 수치 값을 추출하는 해석 작업 수행
  // 예: 첫 번째 바이트와 두 번째 바이트를 결합하여 16 비트 정수 생성
  const temperature = value.getInt16(0, true); // little-endian 가정
  
  // 추출된 데이터를 기반으로 UI 갱신 또는 로그 기록 작업 진행
  console.log(`실시간 온도 데이터 수신됨: ${temperature / 100}°C`);
});

// 알림 구독 활성화를 위한 명령 전송
await characteristic.startNotifications();

종종 데이터가 끊기거나 지연되는 현상이 발생하는데, 이는 브라우저의 스케줄링 문제보다는 BLE 기기의 광고 간격 (Advertising Interval) 이나 연결 파라미터 설정에 기인하는 경우가 많습니다. 개발자는 브라우저 콘솔만 들여다볼 게 아니라, nRF Connect 같은 전용 툴로 기기 자체의 설정 값을 먼저 점검하는 이중 검증 절차를 거치는 것이 효율적입니다.

맺음말: 하드웨어 제어의 새로운 지평

Web Bluetooth API 는 완벽하지 않습니다. iOS 의 사파리에서는 아직 지원되지 않으며, 백그라운드 실행에도 제약이 따릅니다. 하지만 크롬과 엣지를 중심으로 한 생태계가 빠르게 성장하면서, 펌웨어 업데이트 (OTA) 나 간단한 진단 도구 정도는 웹 페이지 하나로 충분히 대체 가능한 수준에 도달했습니다.

이 기술을 도입한다고 해서 모든 문제가 사라지는 건 아닙니다. 오히려 하드웨어의 변덕스러운 응답 시간과 브라우저의 보안 샌드박스 사이에서 균형을 잡는 더 섬세한 설계가 요구됩니다. 그렇기에 표면적인 기능 구현에만 급급하지 말고, 연결 해제 시 리소스를 정리하는 device.removeEventListener 작업까지 꼼꼼하게 구현하여 메모리 누수를 방지하는 완성도 높은 코드를 작성해야 합니다.

이제 당신의 브라우저가 단순한 문서 뷰어가 아니라, 주변의 물리적 세계와 직접 소통하는 강력한 게이트웨이가 되었습니다. 이 잠재력을 어떻게 활용하느냐는 전적으로 당신의 손에 달려 있습니다.