iBeacon: 개념, 비콘 작동 원리 및 BLE 설정

iBeacon이란?

iBeacon은 Apple이 개발하여 WWDC 2013에서 발표한 실내 측위 기술입니다. 건물 내에서 작동하지 않는 GPS와 달리, iBeacon은 Bluetooth Low Energy 비콘을 사용합니다. 이는 고정 식별 패킷을 전송하는 소형 배터리 구동 장치입니다. iOS 및 Android 기기는 이러한 패킷을 수신하고 신호 레벨(RSSI)을 기반으로 비콘까지의 대략적인 거리를 계산합니다.

역사 및 발전

iBeacon 프로토콜은 Apple이 2013년 iOS 7에서 출시한 최초의 대규모 BLE 비콘 표준이 되었습니다. 초기에는 소매업에서 사용되었습니다: Apple Store는 특정 영역에 진입하는 고객에게 할인 정보를 제공하기 위해 iBeacon을 도입했습니다. 2025년까지 iBeacon 인프라는 전 세계적으로 수백만 개의 설치된 비콘을 보유하고 있지만, Google의 Eddystone과 오픈 소스 AltBeacon 같은 대체 프로토콜도 등장했습니다.

적용 분야

iBeacon은 다섯 가지 주요 시나리오에서 사용됩니다: 실내 내비게이션(쇼핑몰, 공항, 박물관), 상황별 알림(매장 진입 시 할인), 워크플로 자동화(출석 표시), 물류 및 창고 관리, 그리고 물체에 접근하면 자동으로 콘텐츠를 재생하는 관광 가이드. ABI Research(2025)에 따르면, BLE 비콘 시장은 32억 대의 운영 기기로 평가됩니다.

iBeacon 프로토콜 구조 및 패킷 형식

iBeacon 패킷은 2402, 2426 및 2480 MHz의 BLE 광고 채널에서 전송되는 Advertising PDU(프로토콜 데이터 단위)입니다. 패킷 형식은 고정되어 있으며 Apple iBeacon 접두사(0x4C000215), 16바이트 UUID, 2바이트 Major, 2바이트 Minor 및 거리 보정용 1바이트 TX Power의 네 가지 필드로 구성됩니다. 총 데이터 크기는 30바이트로, 하나의 BLE Advertising PDU에 들어갑니다.

UUID, Major 및 Minor 계층 구조

iBeacon 식별자는 3단계 계층 구조를 형성합니다. UUID는 조직(예: 매장 체인)에 할당되고, Major는 특정 매장이나 층에, Minor는 영역 내 특정 지점(계산대, 제품 부서)에 할당됩니다. 이 계층 구조를 통해 앱은 다양한 컨텍스트 수준에 유연하게 대응할 수 있습니다: 매장에 진입하면(UUID + Major) 앱이 층 지도를 로드하고, 특정 부서에 접근하면(Minor) 제품 정보를 표시할 수 있습니다.

TX Power 및 보정

TX Power 필드는 비콘으로부터 1미터 거리에서의 신호 레벨(RSSI) 기준값입니다. 패킷을 수신하면 기기는 실제 RSSI를 기록하고 공식에 따라 거리를 계산합니다: distance = 10^((TX_Power - RSSI) / (10 * n)), 여기서 n은 매체의 감쇠 계수(일반적으로 2-4)입니다. 측위 정확도를 위해서는 TX Power의 올바른 보정이 중요합니다: 1dBm 오류는 5미터 거리에서 최대 30%의 부정확성을 초래합니다.

근접 영역: Immediate, Near, Far

iOS는 비콘까지의 계산된 거리를 기반으로 세 가지 근접 영역을 정의합니다: Immediate(0.5미터 미만), Near(0.5~3미터) 및 Far(조건에 따라 3~30~50미터). 정확한 거리는 알려지지 않으며 범주만 제공됩니다. 이는 의도적인 것으로, RSSI는 간섭, 신호 반사 및 인체의 영향을 받기 쉽기 때문에 범주가 더 안정적인 위치 파악을 제공합니다.

Immediate — 직접 근접

Immediate는 기기가 비콘에서 수 센티미터 이내에 있는 직접 접촉 영역입니다. 최대 정확도가 필요한 시나리오(터미널 결제, 디지털 잠금 해제, 검문소 인증)에 사용됩니다. Immediate 영역에서 RSSI는 일반적으로 -30~-60dBm입니다.

Near — 중간 거리

Near 영역은 iBeacon의 주요 작동 영역으로, 0.5~3미터의 거리를 포괄합니다. 실내 내비게이션에 사용됩니다. 예를 들어, 제품 진열대에 접근하면 앱이 상세 정보를 표시합니다. Near 영역에서 TX Power = -59dBm 보정 시 RSSI는 -60~-80dBm 범위에서 변동합니다.

Far — 원거리

Far는 비콘 신호 감지의 최대 영역입니다. 지역 진입 모니터링(예: 쇼핑몰 진입)에 사용됩니다. Far 거리에서 RSSI는 일반적으로 -80dBm보다 약하며, 거리 결정 정확도가 크게 떨어집니다. 진입 모니터링에는 정확한 영역 결정 대신 시스템 API region monitoring이 사용됩니다.

iOS에서 지역 모니터링

iBeacon 지역은 UUID(및 선택적으로 Major + Minor)로 정의되는 가상 영역입니다. iOS는 CLLocationManager를 사용하여 최대 20개의 지역을 동시에 모니터링할 수 있습니다. 지역에 진입하면 시스템이 백그라운드 또는 종료 상태에서도 앱을 깨우고 locationManager:didEnterRegion 델리게이트를 통해 알림을 보냅니다. 지역을 벗어나면 locationManager:didExitRegion이 호출됩니다.

import CoreLocation

let locationManager = CLLocationManager()
let region = CLBeaconRegion(
    uuid: UUID(uuidString: "E2C56DB5-DFFB-48D2-B060-D0F5A71096E0")!,
    identifier: "myBeaconRegion"
)
locationManager.delegate = self
locationManager.requestAlwaysAuthorization()
locationManager.startMonitoring(for: region)

Ranging — 정확한 영역 결정

영역(Immediate, Near, Far)을 결정하기 위해 ranging — 실시간 비콘 스캐닝이 사용됩니다. 모니터링과 달리 ranging은 앱의 활성 모드에서만 작동하며 위치 접근 권한이 필요합니다. locationManager:didRangeBeacons:inRegion 메서드는 proximity(CLProximity.immediate, .near, .far, .unknown), accuracy(미터 단위 보정 거리) 및 rssi 필드가 있는 CLBeacon 배열을 반환합니다.

func locationManager(
    _ manager: CLLocationManager,
    didRangeBeacons beacons: [CLBeacon],
    in region: CLBeaconRegion
) {
    for beacon in beacons {
        switch beacon.proximity {
        case .immediate:
            print("즉시 근접")
        case .near:
            print("가까운 근접")
        case .far:
            print("먼 근접")
        default:
            print("알 수 없는 근접")
        }
    }
}

Android의 iBeacon: AltBeacon 및 크로스 플랫폼 통합

Android에는 iBeacon에 대한 기본 지원이 없습니다. 프로토콜이 Apple의 독점 솔루션이기 때문입니다. 그러나 Radius Networks(현재 Open Beacon 조직의 일부)의 AltBeacon과 같은 타사 라이브러리를 사용하여 개발자는 Android 앱에 iBeacon을 통합할 수 있습니다. AltBeacon 라이브러리는 BLE 패킷 스캐닝, iBeacon 형식 파싱 및 iOS API와 유사한 ranging 및 지역 모니터링 에뮬레이션을 구현합니다.

val beaconManager = BeaconManager.getInstanceForApplication(context)
beaconManager.beaconParsers.add(
    BeaconParser().setBeaconLayout(
        "m:2-3=0215,i:4-19,i:20-21,i:22-23,p:24-24"
    )
)
beaconManager.backgroundBetweenScanPeriod = 5000
beaconManager.foregroundScanPeriod = 1100
beaconManager.bind(this)

Android에서 iBeacon 패킷 파싱

AltBeacon 라이브러리의 iBeacon 파싱 형식은 layout 문자열로 정의됩니다: “m:2-3=0215” — iBeacon 마커의 2바이트 확인, “i:4-19” — 16바이트 UUID, “i:20-21” — Major, “i:22-23” — Minor, “p:24-24” — TX Power. 동일한 형식이 Eddystone 및 다른 프로토콜에서도 지원되어 AltBeacon을 Android에서 BLE 비콘 작업을 위한 범용 라이브러리로 만듭니다.

Android의 제한 사항

Android에서 iBeacon 작업에는 세 가지 주요 제한 사항이 있습니다: 백그라운드 스캐닝이 제조업체에 의해 제한되고(Xiaomi, Huawei, Samsung은 자주 백그라운드 프로세스를 종료함), BLE 스택 차이로 인해 RSSI 정확도가 iOS보다 낮으며, Android 6.0부터 ACCESS_FINE_LOCATION, Android 12부터 BLUETOOTH_SCAN 권한이 필요합니다.

iBeacon 대 Eddystone: 비콘 프로토콜 비교

Eddystone은 2015년에 발표된 Google의 오픈 BLE 비콘 프로토콜입니다. iBeacon과 달리 Eddystone은 네 가지 패킷 유형을 지원합니다: Eddystone-UID(고정 식별자), Eddystone-URL(Physical Web용 URL 전송), Eddystone-TLM(비콘 원격 측정 — 배터리 잔량, 온도) 및 Eddystone-EID(클로닝 방지를 위한 암호화된 식별자). Google이 2022년에 Physical Web 개발을 중단했지만, Eddystone 프로토콜은 기업 솔루션에서 계속 사용되고 있습니다.

프로젝트를 위한 프로토콜 선택

iBeacon과 Eddystone의 선택은 대상 플랫폼과 사용 시나리오에 따라 달라집니다. iBeacon은 CoreLocation과의 기본 통합 및 백그라운드 지역 모니터링으로 인해 iOS 앱에 선호됩니다. Eddystone은 Android 중심 프로젝트와 비콘이 앱 설치 없이 URL을 전송하는 Physical Web 시나리오에 더 적합합니다. 크로스 플랫폼 프로젝트에서는 두 프로토콜을 모두 지원하는 AltBeacon이 자주 사용됩니다.

일반적인 iBeacon 문제 및 제한 사항

iBeacon을 구현할 때 개발자는 아키텍처 설계 단계에서 고려해야 할 여러 제한 사항에 직면합니다. 이러한 요소를 잘못 평가하면 내비게이션 불안정, 오작동 및 예상보다 빠른 비콘 배터리 소진으로 이어집니다.

RSSI에 대한 환경의 영향

신호 레벨 RSSI는 벽 반사, 금속 구조물, 사람의 존재 및 2.4GHz 대역의 다른 무선 기기로 인해 상당한 변동을 겪습니다. 실내에서는 동일한 비콘의 RSSI 변동이 분당 10~15dBm에 달할 수 있어, 필터(이동 평균, 칼만 필터)를 사용하지 않으면 거리 계산이 부정확해집니다.

지역 모니터링 제한

iOS는 앱당 최대 20개 지역의 동시 모니터링을 지원합니다. 넓은 지역(공항, 경기장) 커버리지가 필요한 프로젝트에는 충분하지 않습니다. 해결책은 동적 지역 전환을 사용하는 것입니다: 한 지역에 진입하면 인접 지역이 활성화되고 원격 지역은 비활성화됩니다.

모니터링 응답 시간

지역 진입과 알림 수신 사이의 지연은 조건에 따라 1~30초 범위일 수 있습니다. iOS는 배터리 절약을 위해 주기적으로 비콘을 스캔하므로 즉각적인 반응을 기대해서는 안 됩니다. 시간에 민감한 시나리오(문 접근 시 열림)에서는 Immediate ranging 사용이 권장되지만, 앱의 활성 모드에서만 작동합니다.