왜 우리는 오픈소스 산업용 BLE 프로토콜 (AltessaBeacon)을 만들었는가

발행: (2026년 2월 4일 오전 01:14 GMT+9)
10 분 소요
원문: Dev.to

Source: Dev.to

Bluetooth Low Energy (BLE)는 저전력·단거리 통신을 위한 널리 채택된 무선 표준입니다. 광고 메커니즘이 단순하고 유연하기 때문에 iBeacon이나 Eddystone과 같은 많은 비콘 포맷이 이를 기반으로 구축되었습니다.

하지만 실제 시스템—산업용 추적, 협조된 디바이스 네트워크, 혹은 장기 배포—을 구축할 때 기존 비콘 포맷이 너무 제한적이라는 것을 발견했습니다. 이들은 정의가 좁고 단순 식별에 초점을 맞추며, 진화를 위한 구조가 거의 없습니다. 이러한 프로토콜 명확성의 부족은 시스템이 복잡해짐에 따라 일관된 구현을 어렵게 만듭니다.

이를 해결하기 위해 우리는 AltessaBeacon을 개발하고 오픈소스로 공개했습니다: 명확한 사양, 명시적인 버전 관리, 구조화된 페이로드, 그리고 정의된 확장 정책을 갖춘 BLE 광고 프로토콜입니다.

https://github.com/altessa-s/altessabeacon-protocol

왜 표준 비콘 포맷이 우리에게 맞지 않았는가

실제로 일반적인 비콘 포맷은 경직되어 있습니다. 페이로드가 고정되어 있고, 버전 관리 옵션이 제한적이며, 호환성을 깨뜨리지 않고 확장하기 어렵습니다. 보안이 전혀 없거나 부족한 경우가 많아 스푸핑과 재생이 쉬워집니다. 또한 디바이스 상태, 우선순위, 제어된 동작 변화와 같은 공식적인 개념이 없으며—모든 것이 단순히 반복 방송일 뿐입니다.

산업 환경에서는 이러한 제한이 더욱 두드러집니다. 간섭, 밀집 배치, 금속 구조물, 그리고 엄격한 배터리 제약으로 인해 패킷 손실이 예외가 아니라 정상입니다. 비콘이 단순 ID가 아닌 구조화된 데이터를 전달하기 시작하면, 이러한 문제는 운영 위험으로 전환됩니다.

Source:

설계 접근 방식

AltessaBeacon는 BLE 광고를 제한적이지만 중요한 통신 채널로 취급합니다. 이 프로토콜은 손실, 중복 및 부분 수신을 가정하고, 이러한 조건에서도 파싱 가능하고 의미 있는 상태를 유지하도록 설계되었습니다.

핵심적으로 AltessaBeacon는 TLV 기반 프레이밍 모델을 사용합니다. 이를 통해 페이로드가 기존 수신기를 깨뜨리지 않고 시간이 지남에 따라 진화할 수 있습니다. 명시적인 버전 관리는 혼합 배포와 점진적인 업그레이드를 지원하며, 이는 장기간 운영되는 산업 시스템에 필수적입니다.

보안은 선택적인 부가 기능이 아니라 프로토콜 설계의 일부로 간주됩니다. 프레이밍 모델은 인증 및 암호화된 페이로드와 재생 방지를 일관되게 구현할 수 있도록 합니다.

프로토콜, 단순한 페이로드가 아니라

AltessaBeacon은 공급업체에 종속적인 형식이나 느슨하게 정의된 프레임 레이아웃이 아닙니다. 광고 데이터가 어떻게 구조화되는지, 필드가 어떻게 식별되는지, 수신기가 이를 어떻게 해석해야 하는지를 명시한 문서화된 프로토콜입니다.

이 사양은 예측 가능성을 강조합니다. 프레임은 명시적으로 버전이 지정되고, 필드는 공식적으로 정의되며, 확장 규칙이 문서화됩니다. 이를 통해 독립적인 구현체들이 문서에 없는 가정이나 암묵적인 관례에 의존하지 않고도 상호 운용할 수 있습니다.

예를 들어, 착용형 안전 장치는 낙상을 감지하면 주기적인 상태 방송에서 고우선순위 긴급 알림으로 전환할 수 있으며—수신기는 맞춤 로직 없이도 이 상태 변화를 해석하는 방법을 알고 있습니다.

주요 프로토콜 메커니즘

사양은 프레임 구조와 해석을 관리하는 여러 명명된 메커니즘을 도입합니다.

  • EET (Extended Event Transmission) – 프로토콜 데이터가 광고 이벤트와 어떻게 연관되는지를 정의하며, 수신기가 관련 전송을 개별 패킷이 아닌 단일 논리적 컨텍스트의 일부로 처리할 수 있게 합니다.
  • BAIS (Beacon Adaptive Information Set) – 광고되는 정보 집합이 장치 상태나 운영 컨텍스트에 따라 어떻게 변할 수 있는지를 정의하면서도 일관된 구조를 유지합니다.
  • SCF (Structured Control Fields) – 페이로드 내부의 표준화된 제어 및 신호 필드를 정의하여, 애플리케이션 별 해석이 아닌 명시적인 프로토콜 수준 의미를 제공합니다.

이 메커니즘들을 통해 AltessaBeacon은 광고 데이터뿐만 아니라 해당 데이터가 어떻게 해석되어야 하는지도 설명할 수 있습니다.

버전 관리 및 확장성

AltessaBeacon는 프로토콜 버전 관리와 페이로드 내용을 명확히 분리합니다. 이를 통해 프레이밍 수준에서 하위 호환성을 유지하면서 프로토콜을 시간에 따라 발전시킬 수 있습니다.

확장은 새로운 필드가 어떻게 도입되고 문서화되는지를 정의하는 공개 레지스트리와 정책에 의해 관리됩니다. 수신자는 알려진 필드를 계속 처리하면서도 알 수 없는 필드를 안전하게 무시할 수 있으며, 이는 장기 운영에 필수적입니다.

설계에 따른 오픈 사양

AltessaBeacon은 완전히 오픈이며 벤더 중립적입니다. 저장소에는 다음이 포함됩니다:

  • 프로토콜 개요
  • 공식 사양
  • 레지스트리 및 확장 정책
  • 참조 C 헤더

이 사양은 단일 스택이나 제품에 얽매이지 않고 독립적으로 구현될 것을 목표로 합니다. 이러한 개방성은 상호 운용성, 검토 및 장기 유지 보수를 가능하게 합니다.

마무리 생각

BLE 광고는 종종 최소한의 방송 메커니즘으로 간주됩니다. AltessaBeacon는 다른 접근 방식을 취하여, 광고를 정의된 의미와 진화 규칙을 가진 구조화된 통신 채널로 간주합니다.

이 프로토콜은 개방형이며, 문서화되어 있고, 범위가 의도적으로 보수적입니다. 구조화된 BLE 광고 데이터를 위한 명확하고 확장 가능한 기준이 필요하다면, AltessaBeacon가 바로 그것을 제공하는 것을 목표로 합니다.

https://github.com/altessa-s/altessabeacon-protocol

Back to Blog

관련 글

더 보기 »

AI가 당신에게 뺨을 때릴 때

AI가 당신을 뺨 때릴 때: Adama에서 Claude가 생성한 코드 디버깅 AI에게 복잡한 기능을 “vibe‑code”하게 맡겨본 적이 있나요? 그 결과 미묘한 버그를 디버깅하느라 몇 시간을 보내게 됩니다.