비콘(Beacon): iBeacon과 Eddystone 중 무엇을 쓸지 결정하기 전에

비콘(Beacon)은 좌표를 보내지 않는다. 주기적으로 BLE 광고 프레임(advertising packet)을 내보내고, 스마트폰이나 게이트웨이가 이를 스캔해 비콘 ID를 인지하는 순간 "근처에 있다"는 신호 근접성만으로 컨텍스트가 매핑된다. 비콘 하드웨어가 Tx Power·Interval 설정에 따라 프레임을 송신하면 모바일 OS가 스캔하고, 앱이 프레임을 파싱해 ID를 콘텐츠에 매핑한 뒤 알림·화면 전환·로깅 같은 트리거를 실행하는 흐름이다.

프로토콜의 차이

iBeacon(Apple): UUID+Major+Minor로 네임스페이스를 구성한다. MFG Data 기반이며 iOS 백그라운드 인식이 특히 안정적이다.
Eddystone(Google): UID, URL(브로드캐스트 링크), TLM(진단), EID(회전식 보안 ID) 네 가지 프레임 타입을 지원한다. Google Nearby 연계 기능은 계속 바뀌므로 최신 정보를 확인해야 한다.
AltBeacon(Radius Networks): 오픈 규격으로 안드로이드 생태계에서 커스텀 확장이 자유롭다.

OS 백그라운드 스캔 정책과 플랫폼 지원 범위도 계속 바뀌는 영역이라 배포 전 최신 정책을 확인하는 편이 안전하다.

신호 모델과 거리 추정

RSSI와 Tx Power 교정을 기반으로 근사 거리를 산출하지만, 금속·인체 흡수·다중경로 같은 전파 환경 요인 때문에 오차가 크다. 그래서 절대 거리 대신 영역화(near/immediate/far)와 이벤트 윈도우링(연속 n회 감지)으로 안정성을 확보하고, 칼만 필터나 EMA 스무딩, 채널 호핑 보정을 함께 적용한다.

앱·OS 권한과 백엔드 매핑

위치·블루투스(스캔) 권한과 백그라운드 위치 권한이 필요하고, iOS는 백그라운드 스캔에 제약이 있으며 안드로이드는 버전마다 스캔 제약이 강화되는 추세다. 최초 실행 온보딩에서 목적과 효익을 명시하는 옵트인 설계, 권한 거부 시 대체 플로우 제공이 UX 측면의 기본이다.

백엔드에서는 Beacon ID→콘텐츠/액션/세그먼트 매핑 테이블을 CMS나 Feature Flag로 동적 제어하고, 수집한 이벤트를 정제·세션화해 분석 대시보드로 보낸다. 이 파이프라인에는 스푸핑·리플레이 같은 이상치 탐지가 포함되어야 한다.

하드웨어와 전력 설계

BLE SoC, 안테나, 전원(코인셀/AA/유선), 펌웨어(프레임 포맷, Tx/Interval, 롤링 ID)로 구성되며 방진·방수와 벽체 반사를 고려한 하우징 설계가 중요하다. Tx Power(-20~+4 dBm)와 Interval(100~~1000ms)은 지연과 배터리 소모의 트레이드오프 관계다. 예를 들어 CR2477 배터리를 Tx -4dBm, 1000ms Interval로 운영하면 배터리 수명이 1.5~~2.5년 수준이지만 이는 환경에 따라 달라진다. 배터리 수명 예측, 원격 설정(DFU, 배치 변경), 텔레메트리(온도·전압) 수집을 지원하면 운영이 한결 쉬워진다.

동작 흐름

⤢✕

입력은 BLE 광고 프레임(RSSI, TxPower, Frame Type)이고, 권한·상태 점검→프레임 검증/파싱→신호 보정→중복 억제/쿨다운→서버 매핑/정책 평가 순으로 처리된다. 출력은 사용자 액션(알림/화면), 텔레메트리/로그, 운영 알림이며 권한 거부·블루투스 비활성·신호 소실·스푸핑 탐지 같은 예외에는 재시도 백오프와 대체 UX를 준비해야 한다.

프로토콜 비교

지표	iBeacon	Eddystone	AltBeacon
성능	iOS에서 감지 지연 낮음, 백그라운드 안정적	프레임 다양, 감지 성능은 구현 의존	안드로이드 최적화 용이, 성능 튜닝 자유도 높음
확장성	UUID 네임스페이스로 대규모 분류 용이	UID/EID로 대규모/보안 네임스페이스	오픈 포맷, 커스텀 확장 유리
일관성	iOS 우수, Android는 제조사 편차	Google Nearby 변화 영향, 최신 정보 확인 필요	플랫폼간 균형, 앱 레벨 구현 품질 의존
안정성	제조 생태계 넓고 성숙	URL/TLM 혼합 시 간섭 주의	구현 자유도에 따른 편차 발생 가능
운영 편의	상용 관리 솔루션 풍부	텔레메트리(TLM) 운영 가시성 우수	오픈소스·툴 다수, 표준화는 상대적으로 약함

용도별 적용

리테일 인스토어 마케팅은 입구·핫스팟에 비콘을 배치하고 앱 내 세그먼트 규칙(재방문·장바구니 연동)에 따라 근접 시 인앱 메시지·쿠폰을 노출하는 구조다. 관측 사례로는 오프라인 전환율 5~~15%, 체류시간 8~~12%, 푸시 오픈율 10~20%p 상승이 있다.

실내 길안내·전시 가이드는 존 단위로 비콘 ID를 POI에 매핑하고 스캔 신뢰구간 기반 스냅-투-존으로 오디오·텍스트 가이드를 전환한다. 고정밀이 필요하면 UWB나 와이파이 RTT를 섞는 편이 낫다.

출입·체크인·근태는 게이트 비콘과 시간 창 윈도우링, 중복 억제·위치 위변조 규칙, 서버 서명 토큰 발급으로 구성한다. 보안은 Eddystone-EID나 롤링 UUID, 디바이스 바인딩, 서버 측 위변조 탐지에 달려 있다.

자산 인벤토리·텔레메트리는 자산에 비콘을 태깅하고 주기 스캔 게이트웨이로 재고·상태 대시보드를 갱신한다. TLM으로 배터리·온도를 수집해 교체 주기를 최적화한다.

현장 구축 절차

요구사항 단계에서는 이벤트(진입·체류·이탈) 정의, 쿨다운·빈도 제한, 프라이버시 정책과 함께 프로토콜(iBeacon/Eddystone)과 네임스페이스(UUID, Major/Minor 전략)를 정한다. 배치·현장 튜닝 단계에서는 RF 서베이로 반사·차폐를 확인하고 높이·각도·간격(2.0~~2.5m 높이, 5~~10m 피치)을 가이드로 삼아 Tx Power를 1m 기준으로 캘리브레이션한다.

앱·OS 통합에서는 권한 온보딩과 백그라운드 동작 정책(iOS region monitoring, Android 스캔 윈도우·듀티사이클)을 반영하고 Android Beacon Library나 CoreLocation/CoreBluetooth 같은 SDK를 채택한다. 백엔드는 ID→콘텐츠/정책 룰엔진과 이벤트 스트림 처리(Kafka/Kinesis)를 DWH·대시보드로 연결하고, 서명된 매핑·전송 TLS·재플레이 방지 토큰으로 보안을 갖춘다. 운영 단계에서는 텔레메트리(TLM·앱 피드백) 수집, 배터리 예측, 장애 알림과 함께 A/B 테스트로 RSSI 임계값·윈도우 크기를 튜닝한다.

보안·프라이버시

위협 모델은 스푸핑(가짜 비콘), 리플레이, 위치 추적 과다수집, 앱 권한 오남용이다. 대응은 Eddystone-EID·롤링 UUID, 프레임 서명·서버 검증, 시간·공간 상식 규칙, 앱-디바이스 바인딩이 기본이다. 개인정보보호 측면에서는 옵트인, 목적 제한, 최소 수집, 투명 고지, 보관기간·파기 정책을 갖추고 GDPR·개인정보보호법을 준수해야 한다.

운영 팁

신호 안정화는 EMA·칼만 필터, 스캔 윈도우 3~~5회 평균, 쿨다운 30~~120초로 다룬다. 여러 비콘을 동시에 운용할 때는 광고 채널 간 겹침을 최소화하고 송출 간격을 랜덤화해 간섭을 줄인다. 유지보수는 배터리 교체 라운드-로빈, DFU 윈도우 예약, 자산 라벨링·재고 관리로 이어진다.

코드로 보는 iBeacon 스캔 (Android)

Android 12+(API 31)에서는 BLUETOOTH_SCAN/BLUETOOTH_CONNECT 런타임 권한과 위치 권한이 필요하다.

// build.gradle: minSdk 26+, targetSdk 34 권장
private val scanner by lazy {
    BluetoothAdapter.getDefaultAdapter().bluetoothLeScanner
}

private val callback = object : ScanCallback() {
    override fun onScanResult(callbackType: Int, result: ScanResult) {
        val data = result.scanRecord?.manufacturerSpecificData ?: return
        // Apple MFG ID 0x004C, iBeacon 레이아웃: 0x02 0x15 + 16B UUID + Major(2) + Minor(2) + Tx(1)
        val apple = data.get(0x004C) ?: return
        if (apple.size >= 23 && apple[0] == 0x02.toByte() && apple[1] == 0x15.toByte()) {
            val rssi = result.rssi
            // 간단 EMA 스무딩 예시
            emaRssi = if (emaRssi == null) rssi.toDouble() else 0.7 * emaRssi!! + 0.3 * rssi
            // TODO: UUID/Major/Minor 파싱 → 매핑/쿨다운 → 액션
        }
    }
}

fun startScan(context: Context) {
    val filter = ScanFilter.Builder()
        .setManufacturerData(0x004C, byteArrayOf(0x02, 0x15)) // 프리픽스 매칭
        .build()
    val settings = ScanSettings.Builder()
        .setScanMode(ScanSettings.SCAN_MODE_LOW_LATENCY)
        .build()
    scanner.startScan(listOf(filter), settings, callback)
}

fun stopScan() {
    scanner.stopScan(callback)
}

제조사별 BLE 스택 편차가 있어 배터리 영향을 고려해 SCAN_MODE_BALANCED로 운영 전환하는 편이 낫고, iOS 백그라운드 정책과 Android 전력 정책은 주기적으로 최신 정보를 확인해야 한다.

도입할 때 남는 숫자들

리테일 매장 사례에서는 온오프라인 전환율이 5~~15%p, 오퍼 응답률이 10~~30% 오르고 매장 동선이 가시화되면서 운영 비용을 5~~10% 절감한 경우가 있었다. 배터리 교체 주기는 환경·설정에 따라 12~~30개월 사이에서 갈린다. 정량 지표보다 더 중요한 것은 현장 맥락 기반 개인화와 공간 데이터 자산화가 쌓이면서 실험(테스트앤런)을 빠르게 돌릴 수 있게 된다는 점이다. 프로토콜 선택과 권한·정책 대응, 신호 품질·보안 설계를 먼저 체계화한 뒤 파일럿에서 확장으로 넘어가는 순서를 권한다.