쏘카프레임 - Bluetooth 모듈

쏘카, 일레클, 따릉이 제어는 각 이동수단 내부의 단말이 앱과 데이터를 주고받기 때문에 가능하다. 쏘카는 이 통신을 서버와 Bluetooth 두 경로로 나눠 쓰되, 신뢰성이 높은 Bluetooth를 우선 활용한다.

플랫폼 API는 기기의 맥락을 충분히 담지 못하고, iOS와 Android 사이의 동작 차이도 크다. 특히 iOS의 scanForPeripherals(withServices:options:)는 스캔 중 추가 스캔을 허용하지 않는 반면, Android의 startScan(filters, settings, callback)는 이를 허용한다. 이를 해결하려고 쏘카프레임은 가상 스캔 매니저를 두어 여러 스캔 요청을 하나로 병합한다.

핵심 구조는 BluetoothHost와 BluetoothRemote다.

• BluetoothHost: 리모트 목록을 관리하고, 생성·연결·종료 생명주기 콜백을 제어한다.
• BluetoothRemote: 실제 블루투스 기기를 추상화한 객체로, 기기별 루틴을 캡슐화한다.
• BluetoothSpec: CarID, BikeID, UUID 같은 정적 정체성을 담는다.
• BluetoothHandle: aliveMessage, issueCommands처럼 바뀔 수 있는 동적 행동을 담는다.

이 구조 덕분에 앱 개발자는 스캔, 연결, 재연결, 에러 처리, 프로토콜 분기까지 신경 쓰지 않고 "문 열기 명령을 보내줘" 같은 의도만 표현하면 된다. 기기 종류에 따른 처리는 모듈 안으로 숨겨지고, 새 기기가 추가돼도 기존 코드 수정을 최소화할 수 있다.

예시 의사 코드에서는 플랫폼 코드만 쓸 경우 기기 타입마다 switch로 연결 루틴, 명령 전송 방식, 응답 파싱, 에러 정책을 모두 분기해야 한다. 반대로 쏘카프레임을 쓰면 BluetoothHandle을 등록하고 bluetoothHost.checkIsConnected(...).getBluetoothRemote().request(...)처럼 일관된 흐름으로 제어할 수 있다.

이 아키텍처가 주는 가치는 5가지로 정리된다.

• 수평/수직 확장성: 새 블루투스 기기를 추가할 때 기존 BluetoothHost를 고치지 않고 구현체만 더하면 된다.
• 인프라와 비즈니스 분리: 앱은 하드웨어 복잡성을 모르고도 명령만 내릴 수 있다.
• 비즈니스 유연성: iOS와 Android가 같은 구조를 공유해 요구사항 대응과 일정 산정이 쉬워진다.
• 테스트 용이성: 하드웨어 의존성이 줄어 Mock 테스트와 예외 상황 검증이 쉬워진다.
• 오픈소스 가능성: BluetoothCore와 BluetoothCommon을 분리해, 핵심 플랫폼 로직을 외부에 공개할 여지를 만든다.

결국 쏘카프레임은 파편화된 플랫폼 Bluetooth API 위에 한 겹의 추상화를 더해, 차량·자전거·킥보드 같은 다양한 이동수단을 같은 방식으로 다룰 수 있게 만든다. 그 결과 앱 팀은 저수준 통신 구현 대신 서비스 의도와 확장성에 집중할 수 있다.