BLE란 무엇인가? 클래식 블루투스와의 주요 차이점 설명

Bluetooth와 BLE 한눈에 보기

Bluetooth는 단거리 개인 영역 무선 기술로, 몇 미터 내에서 케이블 없이 장치 간 직접 통신하도록 설계되었습니다. 무선 헤드폰, 키보드, 차량 핸즈프리 시스템, 근거리 파일 전송 등에 널리 사용됩니다.

BLE는 Bluetooth Low Energy의 약자입니다. 이것은 같은 Bluetooth 브랜드 안에 속하는 별개의 무선 프로토콜로, 주로 매우 낮은 전력으로 작고 드문 데이터 버스트를 처리하도록 설계되었습니다. 클래식 블루투스가 연속적인 데이터 스트림(예: 오디오)을 목표로 하는 반면, BLE는 센서와 소형 배터리로 수개월·수년 동작해야 하는 장치에 최적화되어 있습니다.

둘 다 Bluetooth SIG에 의해 규격화되며 스택의 일부를 공유하고 "Bluetooth" 로고를 사용하지만, 기술적으로 BLE와 클래식 블루투스는 동일하지 않습니다. 서로 다른 무선 절차, 데이터 모델을 사용하고 각자 다른 용도에 최적화되어 있습니다.

전형적인 BLE 장치

일상에서 종종 눈치채지 못하게 BLE 기술과 상호작용합니다:

• 피트니스 트래커와 스마트워치
• 심박 스트랩과 의료 웨어러블
• 스마트 잠금장치와 태그
• 상점이나 행사장의 비콘
• 환경 센서 및 기타 IoT 노드

이 가이드의 초점

이 글은 BLE와 클래식 블루투스의 차이를 실무 관점에서 설명합니다: 무선 동작, 전력 소비, 범위, 처리량, 지연, 보안, 데이터 모델(GATT 등) 측면에서의 차이입니다. BLE가 뛰어난 영역(예: IoT 센서, 웨어러블, 비콘)과 클래식 블루투스가 여전히 우위인 영역(오디오, HID, 일부 레거시 액세서리)을 살펴보고, 다음 제품이나 프로젝트에 적합한 기술을 선택할 수 있도록 돕습니다.

처음에 BLE가 만들어진 이유

블루투스의 원래 목적: 케이블 대체

초기 블루투스(1.x, 2.x, 3.0)는 주로 짧은 케이블의 무선 대체로 설계되었습니다: 오디오 잭 대신 헤드셋, USB 대신 키보드와 마우스, 시리얼 대신 근거리 파일 전송 등.

당시 환경은 상대적으로 전원이 넉넉한 장치를 전제로 했습니다. 휴대폰, 노트북, 자동차 시스템은 오디오 스트리밍이나 대용량 파일 전송을 위해 라디오를 장시간 유지할 수 있었습니다.

소형 장치의 전력 문제

무선 센서, 웨어러블, 비콘, 의료 기기가 등장하면서 클래식 블루투스의 전력 특성은 한계로 드러났습니다.

클래식 블루투스 링크를 유지하려면 빈번한 무선 활동과 비교적 복잡한 프로토콜 스택이 필요합니다. 스마트워치, 동전형 배터리 센서, 도어 센서처럼 수개월·수년 지속되어야 하는 장치에는 에너지 소모가 너무 큽니다.

독자적인 2.4 GHz 저전력 링크도 있었지만(BLE 이전의 일부 프로프라이어터리 솔루션 등), 블루투스의 상호운용성과 생태계가 부족했습니다.

Bluetooth 4.0과 BLE의 등장

Bluetooth 4.0은 클래식 모드와 병존하는 새로운 모드로 **Bluetooth Low Energy(BLE)**를 도입했습니다.

BLE는 다른 가정에서 설계되었습니다: 많은 장치가 짧게 깨어나 작은 데이터를 보내거나 받고 다시 잠드는 패턴입니다. 예를 들어 "심박수 72 bpm", "문이 열림", "온도 21.3 °C" 같은 간단한 상태 업데이트를 목표로 합니다.

연결은 가볍고 광고(advertising)는 효율적이며, 라디오는 대부분의 시간 꺼져 있을 수 있습니다.

듀얼모드 칩: 양쪽의 장점

현대 블루투스 칩은 대개 BLE와 클래식을 모두 지원합니다. 스마트폰은 하나의 무선 모듈로 클래식 블루투스 헤드폰과 BLE 피트니스 트래커를 동시에 처리할 수 있습니다.

BLE의 동작(상위 개념)

BLE는 연속적인 고처리량 스트림이 아니라 짧고 효율적인 작은 패킷 교환을 중심으로 구성됩니다. 큰 그림에서 광고(발견) 단계와 구조화된 데이터 모델(GATT)을 통한 데이터 전송의 두 단계로 나뉩니다.

광고(Advertising)와 발견

대부분의 BLE 상호작용은 광고에서 시작합니다. 주변 장치(예: 센서나 비콘)는 특정 채널에서 주기적으로 작은 브로드캐스트 패킷을 전송합니다. 이러한 광고 패킷은:

• 장치 존재를 알리고
• 선택적으로 작은 페이로드(식별자, 플래그 또는 몇 바이트의 센서 데이터)를 포함하며
• 중앙(central)이 어떻게, 언제 연결할 수 있는지를 나타냅니다

중앙(central) 장치(보통 폰, 태블릿, 게이트웨이)는 이러한 패킷을 스캔합니다. 흥미로운 주변 장치를 발견하면 브로드캐스트된 데이터만 읽거나(비연결 모드), 연결을 시작할 수 있습니다.

연결 지향 vs 비연결

BLE는 다음을 지원합니다:

• 비연결(브로드캐스트) 모드 – 주변 장치는 계속 광고하고 중앙은 수신만 합니다. 비콘, 일방향 텔레메트리, 존재 감지에 적합합니다.
• 연결 지향 모드 – 중앙이 주변 장치와 링크를 수립하면, 그들은 일정에 따라 패킷을 교환하며 확인 응답과 보안이 동반됩니다.

GATT, 서비스와 특성

연결되면 BLE는 **Generic Attribute Profile(GATT)**을 사용해 구조화된 데이터 교환을 수행합니다. GATT는 다음을 정의합니다:

• 서버(보통 주변 장치)가 데이터를 노출하고
• 클라이언트(보통 중앙)가 그 데이터를 읽거나 씁니다

데이터는 다음과 같이 구성됩니다:

• 서비스 – 기능별 그룹(예: Heart Rate, Battery)
• 특성(Characteristic) – 서비스 내 개별 데이터 항목

각 특성은 읽기, 쓰기 또는 알림(subscribe)으로 동작할 수 있습니다.

전형적인 BLE 속성 값은 작으며, 수 바이트에서 수십 바이트 정도입니다. 큰 블록을 연속적으로 스트리밍하기보다 많은 짧고 표적화된 트랜잭션(읽기, 쓰기, 알림)을 수행합니다.

클래식 블루투스(간단 정리)

클래식 블루투스는 원래 표준으로, 지속적인 데이터 스트림이 필요하고 라디오를 장시간 유지할 수 있는 장치를 위해 설계되었습니다. 목표는 BLE보다 높은 데이터율로 신뢰성 있는 연속 링크를 제공하는 것입니다.

BLE가 짧은 버스트와 긴 슬립을 중시한다면, 클래식은 라디오가 더 자주 활성 상태인 것을 전제로 합니다. 이 때문에 오디오나 실시간 입력에 더 적합하지만 전력 소비가 더 큽니다.

두 기술 모두 2.4 GHz ISM 대역을 사용하지만 위에서 다른 전략을 씁니다. 클래식은 지속 연결과 스트리밍에 최적화된 주파수 호핑을 사용하고, BLE는 짧고 효율적인 교환을 위해 조정되어 있습니다.

흔한 클래식 블루투스 프로파일

클래식은 표준화된 많은 프로파일을 정의합니다:

• A2DP – 고음질 오디오 스트리밍(헤드폰, 스피커).
• HFP – 핸즈프리 프로파일(통화용).
• HID – 키보드, 마우스, 게임 컨트롤러.
• SPP – 시리얼 포트 프로파일(시리얼 케이블 에뮬레이션).

전형적 사용 사례

설계 목표와 프로파일 때문에 클래식 블루투스는 다음에 적합합니다:

• 음악 및 음성 오디오 스트리밍(헤드폰, 스피커, 차량 스테레오).
• 키보드와 마우스 같은 빈번한 입력 전송이 필요한 장치.
• 게임 컨트롤러처럼 낮은 지연과 연속 통신이 요구되는 장치.

이 시나리오들은 대부분 휴대폰, 노트북, 차량 시스템처럼 안정적인 전원 공급을 가정합니다.

내부 구조: 무선 및 데이터 흐름의 차이

변조, 채널, 호핑

클래식(BR/EDR)과 BLE는 같은 2.4 GHz 대역을 공유하지만 채널 구성과 변조 방식이 다릅니다.

• 클래식 블루투스

  • 79개 채널, 각 1 MHz 폭(2.402–2.480 GHz).
  • Base Rate (BR): GFSK 1 Mb/s.
  • Enhanced Data Rate (EDR): π/4-DQPSK(2 Mb/s), 8DPSK(3 Mb/s).
  • 초당 1,600회 채널을 호핑합니다.

• BLE

  • 40채널, 각 2 MHz 폭.
  • 기본 PHY: GFSK 1 Mb/s (LE 1M).
  • 선택적 PHY: 2 Mb/s (LE 2M) 및 Coded PHY(장거리, 낮은 유효 비트레이트).
  • 호핑은 여전히 발생하지만 더 작은 채널 집합과 저전력 운영에 적합한 채널 선택 알고리즘을 사용합니다.

BLE의 넓은 채널과 단순화된 변조는 저전력·짧은 버스트 전송에 최적화되어 있어 연속 높은 처리량 스트리밍에는 적합하지 않습니다.

연결 토폴로지와 데이터 흐름

• 클래식 블루투스

  • 피코넷(piconet) 사용: 하나의 마스터와 최대 7개의 액티브 슬레이브.
  • 여러 피코넷은 스캐터넷을 형성할 수 있으나 실제 제품에서의 지원은 제한적입니다.
  • 데이터는 비교적 연속 스트림으로 취급되는 경우가 많습니다(예: 오디오).

• BLE

  • 간단한 스타 토폴로지: 하나의 중앙과 다수의 주변 장치.
  • 중앙(폰, 게이트웨이)은 수십 개의 저듀티 사이클 링크를 유지할 수 있습니다.
  • 데이터는 짧은 연결 이벤트(connection events) 또는 광고 패킷을 통해 교환됩니다.

데이터율과 지연 특성

• 클래식 BR/EDR 처리량

  • 물리 계층 이론치: 최대 3 Mb/s.
  • 실제 애플리케이션 페이로드: 보통 1–2 Mb/s 수준.
  • 오디오 경로는 종종 수십 밀리초 수준의 종단간 지연을 달성합니다.

• BLE 처리량

  • LE 1M PHY 이론치: 1 Mb/s; 실제 애플리케이션 페이로드는 MTU, 연결 간격, 스택에 따라 보통 0.1–0.8 Mb/s 수준.
  • LE 2M은 원시 전송률을 대략 두 배로 늘릴 수 있으나 프로토콜 오버헤드는 남아 있습니다.
  • 지연은 이벤트 기반: 7.5 ms 연결 간격이면 단일 패킷 지연은 수 ms가 될 수 있지만, 절전 모드를 위해 긴 간격을 쓰면 지연이 늘어납니다.

요약: 클래식은 지속적·고처리량·저지연 스트림에 유리하고, BLE는 짧고 드문 버스트로 전력-지연 절충을 유연하게 조절하는 데 최적입니다.

동일 칩/폰에서의 공존

대부분의 폰과 모듈은 듀얼모드입니다: 하나의 RF 전면부와 안테나를 BR/EDR과 BLE 컨트롤러가 공유합니다.

칩 내부적으로는:

• 단일 무선 트랜시버를 시간 분할해 클래식과 BLE를 처리합니다.
• 컨트롤러 펌웨어는 두 개의 링크 계층을 실행하며 전송/수신 스케줄링을 담당합니다.
• 호스트 스택(OS 측)은 하나의 Bluetooth 정체성을 노출하면서 내부적으로 BR/EDR 또는 BLE로 트래픽을 라우팅합니다.

스케줄러는 클래식 오디오 스트림에 필요한 타이밍을 확보하면서 BLE 연결과 광고를 그 사이사이에 삽입해 애플리케이션 레벨에서 양쪽 프로토콜이 동시에 동작하도록 합니다.

전력 소비와 배터리 수명 비교

BLE의 가장 큰 장점은 라디오를 켜두는 시간이 극히 짧다는 점입니다. 프로토콜 전반이 매우 낮은 듀티 사이클에 맞춰져 있어 짧은 활동 버스트와 긴 슬립을 반복합니다.

BLE가 전력을 적게 쓰는 이유

BLE 장치는 대부분의 시간에 딥슬립 상태에 머물며 다음 동작에서만 깨어납니다:

• 광고 패킷 송신/수신
• 짧은 연결 이벤트 동안 데이터 교환

각 이벤트는 보통 수 밀리초 정도 지속합니다. 이벤트 사이에는 라디오와 대부분의 MCU가 꺼져 마이크로암페어 단위 전류만 소모합니다. 반면 클래식은 연결을 유지하기 위해 자주 라디오가 깨어나 평균 전류가 훨씬 높습니다.

광고 간격 및 슬립 모드

BLE 전력은 얼마나 자주 깨어나는가에 의해 지배됩니다:

• 광고 간격: 비콘은 100 ms, 500 ms, 수초 등으로 광고할 수 있습니다. 간격이 길수록 평균 전류가 급격히 줄어듭니다.
• 연결 간격: 연결 후 장치들은 고정 간격(예: 7.5 ms–4 s)으로 만납니다. 각 회의는 짧고 그 사이에 주변 장치는 잠들 수 있습니다.
• 슬립 상태: 최신 BLE SoC는 약 1–3 µA 수준의 딥슬립 전류를 가집니다. 라디오가 켜졌을 때 피크는 10–20 mA지만 보통 수 ms 동안만 지속됩니다.

예: 장치가 100 ms마다 3 ms 동안 15 mA를 소비하면 듀티 사이클은 3%이고 평균 전류는 대략 0.45 mA(450 µA)입니다. 간격을 1 s로 늘리면 듀티 사이클은 0.3%로 떨어져 평균 전류가 10배 줄어듭니다.

BLE vs 클래식: 전류 소모 대략치

대략적인 수치(하드웨어와 설정에 따라 다름):

• 클래식 블루투스 오디오 헤드셋: 스트리밍 중 20–30 mA; 유휴 상태에서도 수 mA 범위.
• BLE 센서(주기적 연결): 짧은 연결 이벤트 동안 10–20 mA; 평균적으로 수십~수백 µA.
• BLE 비콘: 중간 전력과 1 s 광고 간격에서 보통 <20–50 µA 평균.

이 정도의 차이가 클래식 제품은 보통 재충전식인 반면 BLE 주변 장치는 동전형 배터리로 작동하는 이유입니다.

배터리 수명에 진짜로 영향을 주는 요소

BLE에서 수명에 큰 영향을 주는 파라미터:

• 연결 간격: 간격이 길수록 깨어나는 횟수가 줄어들어 평균 전류 감소(단, 지연 증가).
• 슬레이브 레이턴시(slave latency): 주변 장치가 일부 연결 이벤트를 건너뛰어 에너지를 절약.
• MTU와 데이터 청크화: 큰 MTU는 한 번의 연결 이벤트에서 더 많은 데이터를 옮겨야 하기 때문에 주어진 데이터 볼륨에 대해 총 깨어난 횟수를 줄임.
• 송신 전력 수준: 높은 TX 전력은 이벤트당 전류를 늘리지만 더 긴 범위나 재전송 감소로 보상될 수 있음.
• MCU 및 센서의 전력 상태: 라디오는 최적화되어 있어도 센서나 MCU가 예산을 지배할 수 있으므로 모든 요소를 슬립시키는 것이 중요.

동전형 전지로 수개월~수년

신중한 튜닝으로 BLE 장치는 작은 배터리로도 매우 오래 동작할 수 있습니다:

• CR2032(≈220 mAh) 비콘

  • 평균 전류 ~15 µA(낮은 TX, 1–2 s 광고)
  • 이론상 수명: 220 mAh / 0.015 mA ≈ 14,600 시간 → 약 1.5–2년(실제는 누설, 온도, 배터리 노화로 더 짧음).

• CR2477(≈1000 mAh) 환경 센서

  • 1분마다 깨어나 읽고 짧은 BLE 연결로 전송
  • 평균 전류 20–30 µA 설계 가능
  • 이론상 수명: 약 3–5년.

• 웨어러블(예: 피트니스 트래커)

  • 디스플레이, 진동 모터, 센서 등으로 인해 더 높은 듀티 사이클
  • BLE 라디오는 전체 예산 중 일부일 수 있으며 일반적으로 며칠~몇 주마다 충전.

클래식 블루투스는 정상 사용에서 동전형으로 이 수준의 수명을 달성하기 어렵습니다. BLE의 저듀티 설계와 공격적인 슬립이 IoT 및 센서 애플리케이션에서 다월~수년 작동을 가능하게 합니다.

범위, 처리량, 지연의 트레이드오프

실제 환경에서의 범위

이론적으로 BLE와 클래식은 10 m에서 100+ m까지 범위를 표기하지만 실제로는:

• 실내(사무실, 가정): 둘 다 보통 5–15 m에서 안정적
• 개활지(가시선): 30–50 m가 흔함; 좋은 하드웨어로 더 가능

BLE 5.x는 Coded PHY를 사용하면 이상적인 조건에서 수백 미터도 가능하지만 이는 데이터율 감소를 수반합니다.

실제 범위는 프로토콜보다는 구현(안테나, 송수력 등)에 더 크게 좌우됩니다.

범위에 진짜로 영향 주는 요소

• 송신 전력(dBm): 전력이 높을수록 범위↑, 배터리 사용↑
• 수신 감도: 수신기가 약한 신호를 더 잘 수신할수록 범위↑
• 안테나 설계 및 방향성
• 장애물과 재료: 콘크리트, 벽, 금속, 사람 등은 2.4 GHz 신호를 감쇠시킴
• 간섭: Wi‑Fi, 전자레인지 등 2.4 GHz 장치
• PHY와 데이터율: 낮은 데이터율은 감도와 범위를 개선함

BLE는 여러 PHY(1M, 2M, Coded)를 제공해 데이터율과 범위 간의 트레이드오프를 선택할 수 있다는 장점이 있습니다.

처리량: 버스트 vs 스트림

BLE는 작은 효율적 버스트에 최적화되어 있습니다.

• BLE 4.x: 실제 처리량 약 100–300 kbps
• BLE 5 (1M / 2M PHY): 이상 조건에서 ~700–900 kbps
• BLE Coded PHY: 훨씬 낮은 처리량, 대신 장거리 가능

클래식 블루투스(BR/EDR)는 연속적이고 고대역폭 스트림에서 여전히 우세합니다:

• 실제 처리량: 보통 1–2 Mbps
• 오디오 코덱과 연속 데이터 흐름에 최적화됨

따라서 헤드폰, 스피커, 일부 레거시 데이터 링크는 여전히 클래식을 사용합니다.

지연: 제어 vs 오디오

BLE 연결은 7.5 ms와 같은 짧은 연결 간격을 사용할 수 있어 버튼, 센서, HID 같은 제어 작업에 대해 즉각적인 체감 응답을 제공할 수 있습니다.

그러나 BLE는 연속적 저지연 오디오에는 덜 적합합니다. 패킷 스케줄링, 재전송, 전통적인 오디오 프로파일 부재로 인해 BR/EDR 오디오가 달성하는 <100 ms의 안정적 지연을 맞추기 어렵습니다.

요약:

• BLE: 인터랙티브 제어, 텔레메트리, 이벤트 중심 트래픽에 적합
• 클래식: 높은 처리량과 안정적 지연이 필요한 연속 미디어 스트림에 적합

프로파일, GATT, 데이터 모델 차이

블루투스에서의 "프로파일" 의미

프로파일은 코어 라디오와 링크 레이어 위에 자리한 표준화된 사용 패턴을 의미합니다. 프로파일은:

• 장치 역할(예: 소스 vs 싱크)
• 사용할 프로토콜
• 데이터 형식과 교환 방법

클래식 블루투스는 프로파일에 크게 의존합니다. 같은 프로파일을 구현하면 보통 별도 앱 로직 없이 상호운용됩니다.

BLE의 GATT: 채널이 아닌 속성 기반 모델

BLE는 "프로파일" 개념을 유지하지만 속성(attribute)-기반 데이터 모델로 전환했습니다:

• ATT (Attribute Protocol): 핸들, UUID, 값, 권한을 가진 속성 테이블을 노출하는 낮은 수준 프로토콜
• GATT: 클라이언트가 서비스를 발견하고 읽고 쓰며 알림을 구독하는 방법을 정의

데이터는 다음으로 그룹화됩니다:

• 서비스: 논리적 그룹(예: 심박수)
• 특성: 개별 데이터 포인트(예: 심박수 측정 값)
• 디스크립터: 특성에 대한 메타데이터(단위 등)

BLE 프로파일은 이제 서비스·특성·동작의 조합으로 정의됩니다.

표준 대 커스텀 BLE 서비스

Bluetooth SIG는 많은 표준 GATT 서비스를 제공합니다:

• Heart Rate Service (HRS)
• Device Information Service (DIS)
• Battery Service (BAS)

표준 서비스를 사용하면 상호운용성이 향상됩니다. 적합한 표준이 없을 경우 벤더는 128비트 UUID를 사용하는 커스텀 서비스를 정의합니다.

클래식 프로파일 vs BLE GATT: 핵심 대비

클래식 블루투스:

• 프로파일은 특정 사용 사례와 프로토콜에 묶여 있는 경우가 많음(A2DP/코덱 등).
• 데이터는 스트림/채널로 교환되며 해석은 애플리케이션이나 상위 규격에 맡겨짐.
• 상호운용성은 양쪽이 정확히 동일한 프로파일을 구현하는지에 크게 의존.

BLE:

• 애플리케이션에서 보이는 모든 것은 속성(서비스, 특성, 디스크립터)으로 모델링됨.
• 프로파일은 속성 집합과 절차를 설명하며, 긴-lived 스트림 대신 작은 속성 단위의 작업에 초점.
• 상호운용성은 공통 GATT 서비스와 특성에 의해 주도됨.

실제 장치의 데이터 모델링 예

심박수 센서는 일반적으로:

• Heart Rate Service에 Heart Rate Measurement 특성을 노티파이로 노출
• Device Information Service에 모델명·펌웨어 버전
• Battery Service에 배터리 레벨

일반 센서 노드는:

• Sensor Service라는 커스텀 서비스와 Temperature, Humidity, Config 같은 특성
• Temperature, Humidity는 읽기/노티파이, Config는 읽기/쓰기 등

앱/펌웨어 엔지니어에게 주는 시사점

펌웨어 엔지니어는 GATT 데이터베이스를 설계해야 합니다:

• 어떤 데이터 포인트를 특성으로 만들지 결정
• 가능한 표준 서비스를 선택해 상호운용성 확보
• 특성 속성(읽기/쓰기/노티파이)과 권한(암호화, 인증)을 정밀히 설정

앱 개발자는 BLE와의 상호작용이 소켓 기반이 아니라 다음과 같은 작업 중심임을 이해해야 합니다:

• 서비스·특성 발견
• 작은 데이터 조각 읽기/쓰기
• 변경 사항에 대한 노티파이 구독

속성 중심 모델은 커스텀 바이너리 프로토콜을 클래식 SPP 위에 만드는 것보다 이해하기 쉽지만, UUID와 데이터 포맷을 알아야 하고 비동기 노티피케이션과 연결 상태를 다뤄야 합니다.

요컨대, 클래식은 채널/스트림 기반의 프로파일을 제공하고, BLE는 GATT라는 표준 속성 모델을 통해 프로파일을 구성하는 방식입니다.

보안, 페어링, 프라이버시 차이

보안은 클래식과 BLE 사이의 실무적 차이 중 하나로, 라디오는 유사하지만 페어링 플로우, 키 관리, 프라이버시 도구가 다릅니다.

클래식 블루투스: 페어링·본딩 개요

클래식 장치는 일반적으로:

1. 발견(inquiry + scan)
2. 페어링: 레거시 PIN 기반 페어링 또는 Secure Simple Pairing(SSP)
   • Just Works: 사용자 검증 없음, MITM에 취약
   • Passkey Entry: 사용자가 6자리 코드 입력
   • Numeric Comparison: 숫자 일치 확인
   • Out-of-Band (OOB): NFC 등 다른 채널 사용
3. 링크 키 유도 후 128-bit AES-CCM 암호화 활성화
4. 필요시 본딩으로 링크 키 저장(자동 재연결)

클래식은 주소가 정적이어서 내장된 프라이버시 기능은 거의 없습니다.

BLE: 보안 모드, LE Secure Connections, 프라이버시

BLE는 명시적인 보안 모드/레벨을 정의합니다:

• Security Mode 1 (링크 보안)
  • 레벨 1: 보안 없음
  • 레벨 2: 인증되지 않은 암호화
  • 레벨 3: 인증된 암호화
  • 레벨 4: LE Secure Connections(ECDH 기반)
• Security Mode 2: AES-CMAC 기반 데이터 서명

페어링 방식:

• LE Legacy Pairing: 오래된 방식, STK(Short Term Key) 사용으로 MITM에 취약
• LE Secure Connections: P-256 ECDH로 LTK를 유도, 권장되는 방식

BLE는 또한 프라이버시 기능을 도입했습니다:

• 주기적으로 변경되는 Resolvable Private Addresses
• 신뢰된 장치가 서로를 인식할 수 있게 하는 Identity Resolving Key (IRK)

이를 통해 장치 추적을 어렵게 하면서 페어링 관계는 유지할 수 있습니다.

UX 차이: 프롬프트, PIN, 페어링 플로우

사용자 관점:

• 클래식은 보통 헤드폰/스피커/차량 키트 연결 시 페어링 대화상자를 보여주며 숫자 비교 또는 고정 PIN(예: 0000)을 요구할 수 있습니다.
• BLE 장치는 일부 데이터 교환을 페어링 없이 수행하거나 민감 특성에 접근할 때만 페어링을 요구할 수 있습니다.
• 많은 BLE 기기(센서, 비콘)는 화면이나 키패드가 없어 Just Works 또는 OOB(예: QR/NFC/인쇄된 코드)를 사용합니다.

이 유연성은 강력하지만 UX와 보안은 프로토콜뿐 아니라 앱과 장치 설계에 크게 좌우됩니다.

암호화 강도와 프라이버시 비교

• 두 기술 모두 링크 암호화에 128‑bit AES-CCM을 사용합니다.
• 주요 차이는 키를 어떻게 수립하고 MITM에 대비하느냐입니다:
  • 클래식 레거시 PIN은 약할 수 있음.
  • LE Secure Connections는 ECDH와 인증 페어링으로 강력한 보장 제공.
• BLE의 주소 랜덤화와 IRK 기반 해상 기능은 장기 추적을 어렵게 하여 프라이버시에서 우위입니다.

보안 레벨 선택 모범 사례

엔지니어에게 권장하는 설정:

• BLE가 가능하면 LE Secure Connections를 선호하고 레거시 페어링을 비활성화하세요.
• 인증된 페어링(Numeric Comparison, Passkey)을 다음에 적용하세요:
  • 의료 데이터
  • 접근 제어(자물쇠, 차량)
  • 결제·자격 증명
• UI가 없으면 Just Works를 피하고 OOB를 고려하세요.
• 식별·제어·설정 데이터를 읽기·쓰기하기 전에는 암호화를 요구하세요.
• **BLE 프라이버시(Resolvable Private Addresses)**를 활성화하고 광고에 직접적인 사용자 식별자를 포함하지 마세요.
• 본딩은 필요한 장치에만 제한하세요(본드가 많으면 관리해야 할 장기 키가 증가).

적절히 구성하면 BLE는 클래식 수준의 보안을 제공하거나 능가하고 더 나은 프라이버시 제어를 제공합니다.

전형적 사용 사례: BLE 또는 클래식을 언제 쓸까

BLE가 빛나는 곳

BLE는 작은 버스트 데이터를 보내고 몇 달·몇 년 동안 작은 배터리로 동작해야 하는 장치에 적합합니다.

전형적인 BLE 활용처:

• 센서: 온도, 습도, 모션, 도어/윈도우, 토양 센서
• 비콘: 자산 추적 태그, 근접 비콘
• 웨어러블: 피트니스 밴드, 스마트워치(스텝, 심박, 알림)
• 스마트 잠금·출입 제어: 도어락, 자전거 잠금, 배지

이 경우 앱은 빠르게 연결해 몇 바이트를 동기화한 뒤 양측이 잠들어 긴 배터리 수명을 확보합니다.

클래식 블루투스가 적합한 경우

클래식은 연속적이고 높은 처리량의 스트림에 맞춰져 있습니다.

대표적 사용 사례:

• 오디오: 헤드폰, 스피커, 차량 키트, 일부 보청기(현대 일부 보청기는 제어에 BLE, 스트리밍에 LE Audio를 사용)
• HID 장치: 키보드, 마우스, 게임 컨트롤러(특히 낮은 지연이 중요할 때)
• 테더링/모뎀: 휴대폰-노트북 인터넷 라우팅

사용자는 전력 소비가 더 높더라도 안정적이고 끊김 없는 스트리밍을 기대하기 때문에 클래식을 선택합니다.

회색지대: 둘 다 가능한 경우

몇몇 제품은 양쪽을 모두 선택할 수 있습니다:

• 작은 로그나 설정 파일 전송: 전송이 드물고 용량이 작다면 BLE로 충분; 많은 MB를 자주 옮기면 클래식이 더 나음.
• PC 주변기기: BLE 키보드·마우스는 동전형으로 더 오래가지만, 클래식이 반응성·호환성 면에서 유리할 수 있음.
• 리모컨: BLE는 전력 절약과 풍부한 데이터 전송에 유리; 레거시 TV에서는 클래식이 더 빨리 재연결될 수 있음.

사용자 경험에 영향을 미치는 요소:

• 설정 시간: BLE는 앱 기반 설정이 자연스러울 수 있으나 앱 의존성이 생깁니다.
• 재연결: 클래식은 페어링 후 안정적 링크 유지 경향, BLE는 절전을 위해 적극적으로 끊었다가 필요 시 연결.
• 안정성: 스트림에는 클래식이 예측 가능성이 높고, BLE는 펌웨어가 너무 적극적으로 슬립하면 "버스트" 느낌이 날 수 있습니다.

간단한 규칙

• 데이터 패턴이 버스트성이고 경량이면 BLE를 선택하세요.
• 오디오나 연속 스트림이 필요하면 클래식(또는 지원 시 LE Audio)을 선택하세요.
• 동전형 배터리로 수개월+ 운영해야 하면 BLE를 강하게 추천합니다.
• 최신 폰/OS를 강제할 수 있고 양 끝단을 제어할 수 있다면 BLE로 유리합니다.
• 레거시 노트북·차량·TV를 지원해야 하면 클래식 호환성이 더 중요할 수 있습니다.

전력 예산과 데이터 패턴을 1차 필터로 삼고 타깃 플랫폼과 사용자 충전 허용도를 고려해 선택하세요.

호환성, 듀얼모드 장치, 실제상의 특이점

지난 10년간 팔린 거의 모든 폰·태블릿·노트북은 클래식과 BLE를 모두 지원합니다. "Bluetooth 4.0" 이상이면 BLE가 클래식과 함께 제공되는 경우가 거의 확실합니다.

듀얼모드 칩의 실제 동작

대부분 제품은 하나의 Bluetooth SoC를 사용해 두 스택을 구현합니다:

• 하나의 라디오와 안테나
• 클래식과 BLE 간 시간 분할 스케줄링
• 공통 기반대(baseband)와 컨트롤러, 논리적 스택은 분리

앱이나 펌웨어 관점에서는 두 얼굴처럼 보이지만 실제로는 같은 칩이 패킷을 스케줄링합니다. 일부 OS는 클래식과 BLE에 대해 별도 API를 제공하며 모든 프로파일에 동일하게 접근하지 못하는 경우가 있습니다.

블루투스 버전별 상호호환성

버전은 대체로 하위호환성을 갖지만 세부가 중요합니다:

• BLE는 Bluetooth 4.0+ 하드웨어가 필요합니다.
• 새로운 기능(장거리, 2M PHY, LE Audio)은 5.x 하드웨어와 스택 지원 필요.
• 클래식 전용 장치는 BLE를 전혀 못할 수 있습니다.

무선 버전이 맞더라도 프로파일 호환성이 중요합니다: 두 장치는 같은 프로파일(클래식)이나 같은 서비스/특성(BLE GATT)을 지원해야 작동합니다.

펌웨어, 인증, 프로파일 동작

실제 문제의 다수는 라디오보다 소프트웨어 때문입니다:

• 펌웨어 업데이트로 페어링 버그, 연결 끊김, 상호운용성 문제를 해결할 수 있습니다.
• Bluetooth SIG Qualification은 규격 준수를 보장하지만 모든 폰과 완벽한 동작을 보장하지는 않습니다.
• 제조사는 프로파일의 일부만 구현하거나 커스텀 동작을 추가해 일부 스택과 충돌할 수 있습니다.

제품을 출시하면 펌웨어 버전을 관리하고 블루투스 관련 변경 사항을 릴리스 노트에 기록하세요.

다양한 폰·OS 버전으로 테스트하기

블루투스 동작은 플랫폼과 OS 빌드마다 다를 수 있습니다. 좋은 테스트 관행:

• 주요 폰(iOS, Android 제조사별)과 Windows/macOS 호스트의 테스트 매트릭스 유지
• 각 플랫폼에서 페어링, 재연결, 본딩 삭제(장치 잊기) 테스트
• 화면 잠금·앱 백그라운드 상태·Wi‑Fi 전환·비행기 모드 상황에서 테스트
• OS 업데이트 후 재테스트 – Bluetooth 스택이 자주 변합니다

BLE의 경우 특히 주의할 점:

• 연결 간격과 MTU 기본값 차이
• 스캔/필터링과 백그라운드 스캔 제한
• OS 기반 재연결 시나리오와 관련된 특이동작

듀얼모드와 폭넓은 호환성을 설계하려면 라디오 자체는 문제없다는 가정하에 스택과 OS 동작이 플랫폼마다 다르다는 점을 전제로 테스트하세요.

BLE와 클래식 사이를 선택하는 방법

선택은 제품의 제약과 사용 사례에 대해 솔직해지는 것에서 시작해야 합니다. 요구사항에서 출발하세요.

1단계: 전송할 내용 분명히 하기

• 얼마나 많은 데이터인가? 연속 오디오나 대용량 파일은 보통 클래식. 작은 빈번하지 않은 텔레메트리는 BLE.
• 얼마나 자주? 라디오가 대부분 잠들어 있다가 가끔 깨어나면 BLE가 이상적. 거의 지속 연결이 필요하면 클래식을 고려.
• 얼마나 빠른가? 수백 kbps를 지속해서 필요로 하면 BLE의 실제 처리량(보통 50–300 kbps)을 검증하세요.

2단계: 배터리와 폼팩터

• 배터리 크기와 교체 비용: 동전형이나 에너지 수확 장치는 BLE 추천.
• 충전이 쉽다면? 일일 충전이나 플러그 인이 쉬운 제품(헤드셋, 스피커)은 클래식 사용 가능.

전력 예산(배터리 용량, 목표 수명, 라디오에 허용된 평균 소비)을 문서화하고 클래식 링크의 항상-온 비용을 비교하세요.

3단계: 타깃 기기와 생태계

• 어떤 폰/PC/허브를 지원해야 하나? 최신 폰은 BLE를 지원하지만 일부 작은 게이트웨이/MCU는 클래식 오디오 프로파일을 지원하지 않을 수 있습니다.
• 필요한 프로파일·API: 표준 오디오 프로파일이 필요하면 클래식이 주류지만, 데이터 지향 제품은 BLE GATT와 툴링이 성숙합니다.

초기 단계에서 OS API와 인증 요구사항을 확인하세요; 이는 선택을 좌우할 수 있습니다.

4단계: 미래 대비

• 제품을 수년간 팔 계획이라면 Bluetooth 5.x 기능(장거리, 2M PHY, Coded PHY)을 고려하세요.
• LE Audio 채택을 주시하세요(오디오가 필요하면 향후 클래식을 대체 가능성).

하드웨어를 모듈식으로 설계해 향후 펌웨어나 모듈 교체로 새로운 표준을 수용하기 쉽게 만드세요.

5단계: 개발 노력과 복잡성

클래식 스택과 프로파일은 무겁고 복잡할 수 있고, BLE의 GATT 모델은 모바일 앱과 프로토타이핑하기 쉬운 경우가 많습니다. 다만 연결 파라미터와 보안을 튜닝해야 합니다.

팀 역량을 고려하세요:

• 팀이 익숙한 스택은 무엇인가?
• 기존에 보유한 툴(프로토콜 분석기, SDK, 테스트 스위트)은?

때로는 "더 쉬운" 선택은 팀이 빨리 디버그·인증할 수 있는 쪽입니다.

6단계: 확정 전 문서화

모듈이나 SoC를 확정하기 전에 다음을 캡처하세요:

• 요구되는 데이터율과 허용 지연
• 전형적 듀티 사이클과 배터리 목표
• 지원해야 할 호스트 플랫폼(OS 버전, 하드웨어)
• 보안 수준(페어링, 본딩, 프라이버시)
• 제품 수명 주기와 업그레이드 경로

이 체크리스트로 BLE 전용, 클래식 전용, 듀얼모드 옵션을 비교하세요. BLE가 데이터 요구를 충족하고 배터리가 제한적이면 BLE 선택. 오디오나 무거운 스트리밍이 핵심이면 클래식(또는 BLE와 병행)을 선택. 일찍 문서화하면 설계 말기에 무선 변경으로 인한 비용을 절감할 수 있습니다.

엔지니어를 위한 실무 구현 노트

하드웨어, RF, 인증

BLE 전용 칩, 듀얼모드 칩, 또는 사전 인증된 모듈 중에서 초기에 결정하세요. 모듈은 RF 설계와 규제 승인(인증)을 단순화하지만 비용이 늘고 유연성이 줄 수 있습니다.

PCB 레이아웃에서 안테나, 그라운드 플레인, 참조 설계를 따르는 것이 중요합니다. 작은 인클로저 변경이나 근접 금속이 범위를 크게 떨어뜨릴 수 있으므로 OTA(real over-the-air) 테스트와 RF 튜닝을 계획하세요.

인증(FCC/IC, CE, Bluetooth SIG qualification)을 설계 초기부터 고려하세요. 인증된 모듈을 쓰면 전체 시험 대신 등재·문서화로 작업이 줄어듭니다.

OS 지원과 API

iOS는 Core Bluetooth를 통해 BLE를 제공하며 클래식 블루투스는 시스템 기능과 MFi 액세서리에 주로 예약돼 있습니다. Android는 클래식과 BLE를 모두 지원하지만 서로 다른 API와 권한 모델을 사용합니다.

백그라운드 스캔 제한, 제조사별 Android 차이, 전력 관리로 인한 스캔/연결 중단 등 특이사항을 대비하세요.

아키텍처와 패턴

일반 패턴:

• 주변 센서는 BLE로 폰에 연결하고 폰이 클라우드로 동기화.
• 게이트웨이(Wi‑Fi 또는 셀룰러)가 다수의 BLE 주변 장치를 브리지.
• 로컬 제어에 BLE, 원격 백엔드에 LTE-M/NB‑IoT 같은 셀룰러 사용.

디버깅 도구와 마찰 줄이기

페어링 또는 GATT 이슈가 불명확할 때는 프로토콜 스니퍼(nRF Sniffer, Ellisys, Frontline 등)를 사용하세요. nRF Connect, LightBlue 같은 테스트 앱과 플랫폼 로그(Xcode, Android logcat)를 보완 도구로 사용하세요.

연결 문제와 사용자 마찰을 줄이려면:

• 보수적 기본 연결 파라미터로 시작하고 다양한 폰에서 테스트.
• 페어링·재연결 재시도 및 명확한 오류 처리를 구현.
• 권한, 블루투스 상태, 위치 프롬프트를 깔끔하게 처리.
• 특성은 작게 유지하고 폴링 대신 노티파이/인디케이트를 사용.
• 잡음이 많은 RF 환경에서 테스트.

흔한 오해, FAQ, 빠른 요약

흔한 오해

“BLE는 항상 더 긴 범위를 가진다.”

• 그렇지 않습니다. 범위는 라디오 전력, 안테나, 환경, PHY 선택에 더 크게 좌우됩니다. BLE는 장거리(Coded PHY) 옵션을 제공하지만 데이터율이 낮아집니다.

“클래식 블루투스는 쓸모없다.”

• 클래식은 여전히 오디오(헤드폰, 스피커, 차량 키트)와 많은 HID 장치에서 기본입니다. BLE는 센서·IoT로 점차 확산 중이나 클래식은 오디오가 필요할 때 계속 중요합니다.

“LE Audio가 모든 클래식 오디오를 대체했다.”

• LE Audio는 BLE 라디오 상에서 동작하지만 LC3 코덱 등 별도 프로파일을 사용합니다. 보급에는 시간이 걸리며 많은 기기가 당분간 두 기술을 모두 지원할 것입니다.

FAQ: BLE와 클래식을 함께 사용할 때

한 제품에서 둘 다 쓸 수 있나요?

• 예. 듀얼모드 칩은 같은 2.4 GHz 라디오에서 클래식과 BLE를 모두 지원합니다. 일반 패턴: BLE는 제어·프로비저닝·로깅, 클래식은 고대역 오디오.

대가(트레이드오프)는?

• 통합·테스트·인증 복잡성 증가, RAM/플래시 요구 증가, 라디오 시간 스케줄링 필요.

빠른 문제 해결 팁

• 양쪽에서 기존 본딩을 삭제하고 재페어하세요.
• 기대하는 서비스를 광고하고 있는지, 보안 설정이 호환되는지 확인하세요.
• 연결 파라미터를 확인하세요; 매우 긴 간격은 알림 지연이나 느린 반응으로 느껴질 수 있습니다.

요약 및 결정 체크리스트

• BLE 사용: 저전력 센서, 웨어러블, 비콘, 구성 앱, 대부분의 IoT 링크.
• 클래식 사용: 레거시/현행 오디오(A2DP/HFP)와 연속 스트림.
• 둘 다 사용: 앱 제어·텔레메트리와 클래식 오디오가 동시에 필요할 때.

핵심 기준: 전력 예산, 데이터율, 오디오 필요성, 생태계/호환성. 이 제약에 맞는 모드를 선택하세요.