라이트테라피 조명 제어 앱으로 복습하는 BLE 기반 IoT 앱 서비스 구조

과거 프로젝트로 작업해봤던 라이트테라피 조명 제어 앱을 복습하며, BLE 기기 탐색·연결·Service/Characteristic 기반 데이터 처리 흐름을 정리했다.

iOS 백그라운드 제약, BLE/UWB/NFC 차이, 위치 기반 자동 체크인처럼 IoT 서비스로 확장할 때 필요한 센서 융합 구조도 함께 살펴본다.
마지막으로 이런 기능을 SDK로 패키징하고 REST API 서버·운영자 대시보드까지 설계하는 전체 구조를 정리한다.

 

개념설명예시

개념	설명	예시
Central	주변 BLE 기기를 찾고 연결하는 쪽	iPhone 앱
Peripheral	자신을 광고하고 데이터를 제공하는 쪽	조명, 비콘, 심박계
Service	기능 묶음	조명 제어 서비스
Characteristic	실제 읽고 쓰는 데이터 단위	밝기, 색온도, 전원 상태
Advertising	Peripheral이 “나 여기 있다”고 방송하는 신호	비콘 신호
Scan	Central이 주변 BLE 신호를 찾는 동작	앱에서 주변 장치 검색
Connect	특정 Peripheral과 연결	Olly 조명 연결
Read	값을 읽음	현재 밝기 읽기
Write	값을 씀	밝기 70%로 변경
Notify	값 변경을 구독	조명 상태 변경 수신

 

iOS 네이티브 기준으로 개발한 BLE 앱 구현 흐름은 다음과 같다.

 

1. CBCentralManager 생성
2. Bluetooth 권한/상태 확인
3. scanForPeripherals 실행
4. 원하는 Service UUID를 가진 Peripheral 발견
5. connect
6. discoverServices
7. discoverCharacteristics
8. read/write/notify 설정
9. 연결 끊김 처리
10. 재연결 처리

 

BLE 백그라운드 동작 특징

 

원래 iOS에서는 앱이 백그라운드에 들어가있으면 suspended 상태가 된다.

그 상태에서는 아무 코드나 실행하는게 불가능하다.

 

그렇지만 CoreBluetooth는 특정 조건에서 백그라운드 이벤트를 처리할 수 있다.

info.plst에서 UIBackgroundMode에 bluetooth-central 또는 bluetooth-peripheral 을 선택하고,

• bluetooth-central—The app communicates with Bluetooth low energy peripherals using the Core Bluetooth framework.
• bluetooth-peripheral—The app shares data using the Core Bluetooth framework.

 

연결, 데이터 수신, 상태 변경 같은 블루투스 이벤트가 있을때 백그라운드에서도 앱으 ㄹ깨워서 처리할 수가 있다.

 

그러나 Apple의 경우 백그라운드에서 깨어난 앱은 대략 짧은 시간 안에 관련 작업만 처리해야한다. 

• Upon being woken up, an app has around 10 seconds to complete a task. Ideally, it should complete the task as fast as possible and allow itself to be suspended again. Apps that spend too much time executing in the background can be throttled back by the system or killed.

 

BLE vs UWB

Ultra Wibeband 즉 UWB의 경우엔 몇십 cm수준의 정밀하한 거리와 방향이닉이 됨.

Apple도 Nearby Interaction 프레임워크를 통해 UWB 칩이 있는 iPhone/Apple Watch 및 액세서리의 위치·상대 방향을 활용할 수 있다고 설명한다. (https://developer.apple.com/nearby-interaction/) 

 

항목	BLE	UWB
주 용도	저전력 연결, 비콘, 센서 데이터	정밀 거리/방향 측정
거리 추정	RSSI 기반이라 오차 큼 (가까운 것 같다 정도를 추정)	Time-of-Flight 기반이라 정밀 (특정 의도 범위정하는데 유용함)
장점	싸고 보급률 높음	오탐 감소, 정밀 위치
단점	위치 정확도 낮음	지원 기기/칩/액세서리 제한
활용 방법	비콘 근접 감지	승하차/출입구/좌석 근접 정확도 개선

 

BLE는 주변 장치 탐색과 저전력 데이터 통신에 좋지만, RSSI 기반 거리 추정은 환경 영향을 많이 받아 정확도가 낮을 있다.

 

UWB는 정밀 ranging에 강해서 사용자가 실제로 게이트를 통과했는지, 특정 차량이나 출입구에 충분히 가까운지 판단하는 데 더 유리하다. 거리 및 특정 의도를 했는지 여부를 구체적으로 알아야할 때는 GPS, BLE, UWB, IMU를 조합해 오탐을 줄이는 구조가 필요하다.

 

RFID / NFC

 

RFID는 RAdio Frequency Identification, 즉 무선 주파수로 태그를 식별하는 기술이다.

이건 교통카드, 출입카드, 물류 태그, 재고관레 등에 쓰인다. (회사에서 진행한 프로젝트의 명함 공유 서비스에도 사용되었다)

 

NFC는 RFID 계열 중에서도 매우 짧은 거리에서 동작하는 표준화된 근거리 통신 기술로 보면 됨. NFC Forum은 NFC를 몇 cm 거리의 기기 간 안전한 통신을 가능하게 하는 단거리 무선 기술이며 13.56MHz에서 동작한다고 설명한다.

 

 

항목	RFID	NFC
거리	수 cm ~ 수 m 이상 가능	보통 수 cm
방향	주로 리더가 태그를 읽음	양방향 통신 가능
예시	물류 태그, 출입카드, 교통카드	스마트폰 태그, 모바일 결제, 전자명함
앱 개발	스마트폰에서 일반 RFID 전체를 다루긴 제한적	iOS/Android NFC API로 일부 가능

 

백그라운드 관련 이슈

 

 

iOS에서 앱이 마음대로 항상 백그라운드에서 실행되는 것은 불가능함.
가능한 건 Apple이 허용한 background mode 또는 시스템 이벤트에 의해 제한적으로 깨어나는 것임.

 

방식	설명	적용 시
Standard Location Updates	정확도 높은 지속 위치 추적 (카카오 맵에서 위치 실시간 허용하면 이거 사용하는 듯 함)	배터리 소모 큼
Significant Location Change	큰 위치 변화가 있을 때 앱 깨움	저전력 Wake Up 후보
Region Monitoring	특정 지오펜스 진입/이탈 감지	장소/역/골프장 진입 감지
Visit Monitoring	사용자가 특정 장소에 방문/체류했는지 감지	체크인 후보 판단
BLE Background	BLE 이벤트로 앱 깨움	비콘/디바이스 기반 체크인

 

 

호텔에서 자동 체크인 기능 혹은 카페 자동 결제 기능을 개발 한다면?

 

단순 GPS만으로 체크인하면 위험함.

예를 들어 사용자가 호텔 앞을 지나가기만 했는데 체크인되면 안 됨.
카페 앞을 지나갔는데 결제되면 큰 문제임.

 

하나의 센서보다 센서 융합이 필요할 것 같다.

GPS 반경 진입
+ BLE 비콘 RSSI 감지
+ IMU 이동 패턴
+ 체류 시간
+ 속도 변화
+ 이전 상태
= 체크인 후보

 

예를 들면,

1. 사용자가 장소 반경 100m 안에 들어옴
2. BLE beacon RSSI가 -70 이상으로 15초 이상 유지됨
3. GPS accuracy가 30m 이하임
4. 이동 속도가 차량/도보 패턴과 일치함
5. 동일 세션이 이미 없으면 CHECK_IN 생성

 

자동 체크인에서 가장 중요한 건 오탐 방지라고 보인다. GPS 반경 진입만으로 바로 체크인하면 플랫폼에 들어갔다 바로 나오는 케이스나 근처를 지나가는 케이스를 구분하기 어렵다. 그래서 위치 정확도, 체류 시간, BLE RSSI, 이동 속도, IMU 기반 이동 패턴, 이전 세션 상태를 함께 보고 candidate 상태를 거친 뒤 체크인 확정하는 구조가 필요하다고 생각합니다.

 

 

 

이 모든걸 패티징하여 SDK를 만든다면?

 

우선 레이어를 정해야할 것 같다. Public 레이어 단에서 보여줄 수 있는 것과 내부 로직으로 숨길 것.

 

내부 구조는 대략

TestSdk
 ├─ AuthInterceptor
 ├─ EventQueue
 ├─ RetryPolicy
 ├─ LocationTracker
 ├─ BleScannerBridge
 ├─ SessionClient
 └─ PaymentClient

 

 

고객사(파트너 사가) REST API를 직접 전부 호출하게 하면 인증, 재시도, 세션 상태, 에러 처리를 각자 구현해야 해서 연동 품질이 흔들릴 수 있다. 그래서 SDK에서 API Key 인증, 위치/BLE 이벤트 전송, 로컬 큐, 네트워크 재시도, 세션 상태 동기화를 감싸고, 고객사 앱은 initialize, trackLocation, checkIn, checkOut 같은 단순 인터페이스만 호출하게 만드는 게 좋을 것 같다.

 

 

그렇다면 이 SDK 와 관련된 API 서버 구조는 어떻게 될까?

모바일 SDK에서 올라오는 위치/BLE 이벤트를 REST API로 수신하고, 세션/결제/정산 상태를 PostgreSQL에 저장한 뒤, 운영자 대시보드에서는 체크인 누락, 결제 실패, 정산 상태, 파트너별 이벤트 로그를 조회할 수 있게 설계할 것 같다.

서버에서 처리 할 일 

1. 사용자 인증
2. 고객사 API Key 인증
3. 위치/BLE 이벤트 수신
4. 체크인/체크아웃 세션 생성(결제 세션 생성 등)
5. 결제 상태 관리
6. 정산 데이터 생성
7. 운영자 대시보드 API 제공
8. 고객사 Webhook 발송
9. 로그/감사 추적

 

 

주요 테이블은 대략 

users
partners
places
devices
device_events
checkin_sessions
payments
settlements
webhook_logs
admin_users

 

 

API 예시 

POST /sdk/events/location
POST /sdk/events/ble
POST /sessions/check-in
POST /sessions/check-out
GET /sessions/me

GET /admin/dashboard/summary
GET /admin/sessions
GET /admin/payments
GET /admin/settlements
GET /admin/device-events