쏘카프레임 블루투스 모듈의 호스트·리모트 추상화 (2026-01)

서버와 블루투스를 섞어 쓰는 기기 제어

쏘카 앱은 차량 문 열기·잠금, 비상등, 경적은 물론 일레클과 따릉이의 잠금·해제·반납까지 제어합니다. 각 이동수단 안에 데이터를 주고받는 단말이 들어 있기 때문입니다. 앱과 단말이 통신하는 길은 서버를 거치는 방법과 블루투스를 쓰는 방법, 두 가지입니다.

쏘카 차량에는 STS(Socar Telematics System) 단말이 있고, 서버나 블루투스로 “문을 열어라"는 명령을 받으면 정합성과 보안성을 검사한 뒤 문을 엽니다. 이 단말이 차량 안에서 맡는 역할은 관제 장치 글에서 다룹니다. 원문에 따르면 블루투스가 서버 통신보다 신뢰성이 있어서, 블루투스가 가능하면 먼저 쓰고 안 될 때 서버로 넘어갑니다. 쏘카, 일레클, 따릉이 기능이 모두 쓰는 공통 코드가 쏘카프레임의 블루투스 모듈입니다.

플랫폼 API가 남긴 두 가지 파편화

첫째는 기기의 맥락이 흩어진다는 점입니다. 개발자는 STS라면 CarID를 포함한 식별 정보, 핸드셰이크 규칙, 상태 리포팅 기능이 한 클래스에 모여 있기를 기대합니다. 그러나 iOS의 CBPeripheral과 Android의 BluetoothDevice는 맥락을 담지 못하는 저수준 인터페이스입니다. 스캔, 연결, 송수신 콜백이 따로 놀고 의미 없는 원시 데이터만 오기 때문에 기기의 맥락을 앱 개발자가 직접 재구성해야 합니다.

둘째는 두 플랫폼의 동작 차이입니다. iOS의 스캔 API는 스캔 도중 새 스캔을 허용하지 않고, Android는 허용합니다. 쏘카프레임은 가상 스캔 매니저를 두어 앱 안의 여러 스캔 요청을 논리적으로 합친 뒤, OS에는 최적화된 요청 하나만 전달합니다.

호스트와 리모트, 스펙과 핸들

연결 관리자는 BluetoothHost, 연결 대상은 BluetoothRemote로 추상화했습니다. 호스트는 블루투스 매니저 역할과 함께 리모트 목록을 관리하고 생명주기 콜백을 호출합니다. 리모트를 호스트에 등록하면 가상 스캔이 시작되고, 스캔에 성공하면 생성 콜백이, 연결을 끊으면 종료 콜백이 불립니다. STS, 일레클, 따릉이가 모두 리모트이므로 같은 이벤트만 호출해도 기기에 맞는 루틴이 시작됩니다. 새 기기는 리모트 인터페이스만 따르면 기존 비즈니스 로직을 건드리지 않고 붙습니다. 연결 상태 관리가 필요한 기기를 위해 BluetoothRemote 위에 ConnectfulRemote 같은 층을 얹는 수직 확장도 가능합니다.

기기 정보는 정적인 정체성과 동적인 행동으로 나눴습니다. BluetoothSpec은 CarID, BikeID, UUID처럼 무엇을 찾을지를, BluetoothHandle은 STS의 주기적 aliveMessage 전송이나 커맨드 재발급 같은 행동 방식을 담습니다. 스펙이 같으면 같은 기기로 간주하므로, 앱은 차량과의 물리적 연결을 유지한 채 비즈니스 로직만 교체할 수 있습니다.

원문의 의사 코드는 차이를 보여 줍니다. 플랫폼 코드만 쓰면 기기 종류마다 switch로 초기화, 명령 형식, 응답 파싱, 재시도 정책을 분기해야 하고 킥보드를 추가하려면 곳곳을 고쳐야 합니다. 쏘카프레임에서는 핸들을 호스트에 등록한 뒤 연결 확인, 리모트 획득, 명령 요청, 에러 처리를 이어 쓰는 정도로 줄어듭니다.

원문이 꼽은 다섯 가지 가치

원문은 모듈의 효과를 다섯 가지로 정리했습니다.

• 새 기기는 구현체만 추가하면 되는 수평 확장과, 상속으로 층을 쌓는 수직 확장이 가능합니다.
• 스캔, 연결, 세션 유지 같은 인프라 로직이 모듈 안으로 숨고 앱은 어떤 기기에 어떤 명령을 내릴지만 작성합니다.
• iOS와 Android가 같은 구조를 공유해 설계 논의가 빨라지고 일정 산정이 쉬워집니다.
• 하드웨어 의존이 끊겨 Mock 객체를 쓸 수 있고, 연결 끊김이나 패킷 유실 같은 예외를 코드로 검증합니다.
• 순수 플랫폼 로직인 BluetoothCore와 쏘카 전용 로직인 BluetoothCommon을 분리해 두어, 앞쪽을 오픈소스로 공개할 가능성을 열어 둡니다.