1-1-4 블루투스 통신, 스마트폰 앱 프로그래밍

블루투스 통신

블루투스(영어: Bluetooth)는 1994년에 에릭슨이 최초로 개발한 개인 근거리 무선 통신을 위한 산업 표준이다. 1999년 5월 20일에 공식적으로 발표되었다. 블루투스라는 이름은 10 세기 덴마크와 노르웨이의 국왕 하랄드 블라톤의 이름을 영어식으로 바꾼 것이다. 제안을한 사람은 JIM KARDACH인데, 계기는 소설가 프란스 G. 벵 트손의 ‘바이킹’이라는 소설과 하랄드 블라톤의 관한 역사 소설 ‘The Long Ships’를 읽고 있어서 제안했다. 하랄드 블라톤이 스칸디나비아를 통일한 것처럼 무선통신도 블루투스로 통일하자는 의미인 것이다. 1998년에는 Bluetooth Special Interest Group이라는 블루투스에 관한 동맹이 결성되 면서 에릭슨을 비롯한 인텔, 레노버, 마이크로소프트, 애플, 노키아, 도시바, IBM이 참여하 였다. 블루투스는 다양한 기기들이 안전하고 저렴한 비용으로 전 세계적으로 이용할 수있는 무선 주파수를 이용해 서로 통신할 수 있게 한다. 또 IEEE 802.15.1 규격을 사용하는 블루투스는 PANs의 산업 표준 중 하나이다. 블루투스는 ISM 대역인 2.45 GHz를 사용한다. 버전 1.1과 1.2의 경우 속도가 723.1 kbps에 달하며 버전 2.0의 경우 EDR을 특징으로 하는데, 이를 통해 2.1Mbps의 속도를 낼 수 있다. 블루투스는 유선 USB를 대체하는 개념이며, 와이파이는 이더넷을 대체하는 개념이다. 암호화에는 SAFER을 사용한다. 장치끼리 믿음직한 연결을 성립하려면 키워드를 이용한 페어링이 이루어지는데, 이 과정이 없는 경우도 있다.

• 사양과 특징

(1) 1.X 가장 초기에 나온 1.0부터 2002년에 등장한 1.1을 거쳐 1.2까지 개선되었다. 다만 최대 전송 속도가 723 Kbps라서 대용량 데이터를 전송하기에는 조금 부적절했었다.

(2) 2.X + EDR (enhanced data rate)
2004년 10월에 [그림 3-1]과 같은 2.0이 표준화되었으며, 기존의 최대 전송 속도였던 721 Kbps를 3 Mbps로 끌어올렸다. 다만 실제 최대 전송 속도는 2.1 Mbps 정도 된다. 2007년 7월 26일에 2.1이 발표되었으며, 2.0과의 가장 눈에 띄는 차이는 페어링이 더손쉽게 가능하도록 SSP(secure simple pairing) 기능이 추가된 것이다.

그 외 커넥션 시필터링이 쉽도록 EIR(extended inquiry response)이 강화되고, Low Power 모드에서 소비전류를 줄이는 기능이 추가되었다. 안드로이드를 사용한 대다수의 초기 스마트폰과 태블릿 컴퓨터, 게임기와 노트북 등에 탑재되어 있는 버전이다.

[그림 1] 블루투스 BR/EDR (버전 1.0, 2.0) 프로토콜 스택

 

(3) 3.0 + HS(high speed)
2009년 4월 21일에 발표되었으며 이론적으로 24 Mbps이라는 전작에 비해 매우 빠른 속도를 제공한다. 다만 3.0 + HS(high speed)만 24 Mbps를 지원하며, 지원하지 않으면 2.X와 똑같은 속도를 낸다. Bluetooth Link는 접속에만 관여하고, 실제 고속 데이터 통신은 802.11 Wi-Fi 쪽에 추가된 PAL(protocol adaptation layer)를 이용하기 때문이다.

(4) 4.0
[그림 2]와 같은 4.0은 2010년 6월 30일에 채택되었으며, Bluetooth Low Energy(BLE)라는 새로운 프로토콜이 추가되어 기존 버전들보다 전력을 적게 소모하는 것이 장점이다. 기술에 따라 3가지로 나눠지는데, 클래식 블루투스(Classic Bluetooth)는 1.0부터 2.1로 이어져온 기존 블루투스 기술이고, 고속 블루투스(Bluetooth High Speed)는 3.0에서 더해진 Wi-Fi를 활용한 HS 고속 전송 기술의 연장이고, 저전력 블루투스(Bluetooth Low Energy) 는 전력 소모를 최소화하고 배터리 수명을 연장하는데 중점을 둔 새로운 표준이다.
그 중 저전력 블루투스(Bluetooth Low Energy)는 전지로 몇 년을 지속할 수 있는 주변 기기가 주요 타깃이기 때문에, 속도는 다른 무선 전송 규격보다 상대적으로 느린 편이 다. BLE만 지원되는 칩은 Single Mode라고 부르고, 단방향 전송만 지원되고 칩이 탑재된 제품을 Bluetooth SMART라고 부르며, 앞서 설명한 클래식 블루투스(Classic Bluetooth)와 함께 들어있는 칩은 Dual Mode라 부르며, 양방향 전송이 지원되며 탑재된 제품을 Bluetooth SMART READY라고 부른다. 심장 박동 검사기 같은 주변 기기는 Single Mode 솔루션이 탑재되고, 스마트폰 등에는 Dual Mode 솔루션이 탑재된다. 각각 1Mbps와 3Mbps를 지원한다. HS를 지원한다면 24Mbps도 지원한다.

 

[그림 2] 블루투스 BLE 프로토콜 스택과 BR/EDR 프로토콜 스택의 비교

(5) 4.1
2013년 12월 4일에 블루투스 4.1이 발표되었으며, 주요 특징은 다음과 같다.
(가) 공존성(coexistence) 향상
블루투스와 LTE 무선이 서로 통신 상태를 조정해 가까운 대역폭으로 인한 간섭 현상을 줄여준다.
(나) 더 나은 연결(better connections)

블루투스 연결 장치끼리의 거리가 멀어져 잠시 연결이 끊어지게 되면, 블루투스 4.1 장치는 거리 내로 되돌아올 시 자동으로 재연결된다.
(다) 데이터 전송 개선(improved data transfer)
블루투스를 사용하는 액세서리 장치(헬스 기구) 등과의 통신 전송 상태를 보다 효율적으로 개선하였다.
(라) 개발자에게 더 많은 유연성 제공(more flexibility to developers)
앞으로 있을 웨어러블 기기 붐에 대비한 업데이트로, 블루투스 연결을 통해 웨어러블 기기가 스마트폰의 주변장치이자 동시에 다른 장치와의 허브 역할도 할 수 있게 해 준다. 또 장래를 위해 사물 인터넷(the internet of things)을 위한 새로운 IPv6 사용 표준도 들어가 있다. 또 128비트 AES 암호화가 추가되어 보안성이 증가 되었다.

 

(6) 4.2
2014년 12월 4일에 블루투스 4.2가 발표되었다. 블루투스 4.2의 핵심 업데이트 내용은 크게 세 가지로 요약된다.
(가) 더욱 빨라진 전송 속도
블루투스 SIG의 보도 자료에 따르면, 블루투스 4.2 버전은 기존 4.0 규격 대비 전송 속도가 2.5배 증가했다. 특히, 한 번에 보낼 수 있는 패킷 용량이 10배로 늘어나 전송 오류와 배터리 소비를 동시에 잡았다. 그래프만 보면 250배나 빨라진 것으로 보일 수 있으나 데이터를 주고받는 빈도를 조금 줄이는 대신 한 번에 더 많은 정보를 전송해 전반적으로 2.5배의 전송 속도 향상과 효율적인 데이터 전송을 한다.
(나) 사물 인터넷을 위해 연결성 강화
IPv6나 6LoWPAN을 통해 인터넷에 직접 접속할 수 있다. 블루투스 4.2와 함께 올해말 승인 예정인 ‘IPSP(Internet Protocol Support Profile)' 기술이 채택되었기 때문 인데, 기존 IP 인프라를 갈아엎을 필요 없이 사물인터넷 기기나 스마트 디바이스가 인터넷에 직접 접속할 수 있어 이전보다 좀 더 유연하게 스마트홈을 구현할 수 있게 될 것으로 예상된다.
(다) 개인 정보 강화
사용자의 허락 없이 블루투스 기기 위치를 추적할 수 없게 했는데, 예를 들어 애플의 아이비콘(iBeacon) 기술을 도입한 매장을 방문하더라도 사용자가 허용하지 않는한 매장이 사용자의 위치를 마음대로 추적할 수 없게 된다. 미 IT매체 아스테크니 카가 취재한 바에 따르면 2.5배의 데이터 전송속도 향상은 새로운 하드웨어가 필요 하지만, 개인정보보호는 기존 블루투스 기기에 대한 펌웨어 업데이트만으로도 대응할 수 있게 될 예정이다.

(7) 5.0

2016년 6월 17일에 공개되었으며, 2016년 말에서 2017년 초에 정식으로 출시될 예정이 다. 기존과 비교해 전송 범위는 4배, 속도 2배, 비연결 데이터 브로드캐스트 용량은 8 배가 향상되었다.

 

스마트폰 앱 프로그래밍

스마트폰 애플리케이션(이후 앱으로 지칭)은 네이티브 앱, 웹 앱, 하이브리드 앱으로 나눌수 있다.

• 네이티브 앱

네이티브 앱은 모바일 기기에 직접 다운로드하여 로컬(기기)에 저장되는 바이너리 실행 파일이다. 사용자가 직접 설치하거나 경우에 따라 기업의 관리자가 설치할 수 있다. 네이티브 앱은 애플사의 앱스토어(App Store), 안드로이드의 마켓플레이스(Marketplace), 블랙베리 사의 앱 월드(App World) 등과 같은 공용 앱스토어에서 다운로드하면 되나, 모바일 공급업 체에서 직접 제공하는 경우도 있다. 모바일 기기에 앱을 설치한 후에는 기기에서 제공하는 다른 서비스처럼 사용자가 앱을 실행한다. 초기화할 경우 네이티브 앱 인터페이스는 중개 요소나 컨테이너 없이 모바일 운영체제와 직접 통신한다. 네이티브 앱은 모바일 OS에서 제공하는 모든 API에 액세스할 수있으며, 대부분 해당 모바일 OS의 고유 기능을 활용한다. 네이티브 앱을 만들려면 개발자가 사람이 읽을 수 있는 형식으로 소스 코드를 작성하고, 이미지, 오디오, 다양한 OS별 선언 파일 등의 리소스를 만들어야 한다. 이러한 리소스를 개발한 후 모바일 OS에서 제공하는 툴을 이용해 소스 코드를 컴파일하고 배포할 수 있는 바이너리 형태의 실행 파일을 만든다. 이러한 툴 및 기타 유틸리티/파일을 일반적으로 모바일 OS의 소프트웨어 개발 키트(SDK) 라고 한다. 네이티브 앱 개발 과정은 모바일 운영체제 특성을 타지 않고 모두 비슷하지만, SDK는 OS별로 다르며, 모바일 OS별로 고유 툴을 제공한다. <표 3-1>은 주요 모바일 OS에서 제공하는 툴, 언어, 패키징 형식, 앱 배포 방법을 보여준다. 모바일 OS에서 제공하는 언어, 툴 등이 다르다는 점이 네이티브 앱 개발 방식의 가장 큰단점이다. 예를 들어 애플 iOS용으로 작성된 코드를 안드로이드에서는 사용할 수가 없다. 그러므로 멀티 플랫폼을 지원하는 네이티브 앱을 개발하려면 개발 기간도 많이 걸리고 비용도 많이 든다. 이런 단점에도 불구하고 기업들이 네이티브 방식을 선호하는 이유는 애플리케이션 프로그 래밍 인터페이스(이하 API) 때문이다. 모바일 기기에 네이티브 앱을 설치하고 실행하면, 앱은 모바일 운영 체제에서 제공하는 전용 API를 호출해 모바일 운영체제와 통신한다. 모바일 운영 체제에서 제공하는 API는 로우 레벨(low level) API와 하이 레벨(high level) API로 구분된다.

 

(1) 로우 레벨 API
앱은 로우 레벨 API를 호출해 터치스크린이나 키보드와 직접 입출력을 하고, 그래픽을 렌더링하며, 네트워크를 연결한다. 또 마이크를 통해 수신한 오디오를 처리하고, 스피 커나 헤드폰을 통해 사운드를 재생하며, 카메라로부터 이미지나 동영상 등을 수신해 저장한다. GPS(global positioning system) 액세스, 방향 정보 수신, 반도체 디스크 또는 상용 하드웨어의 파일 읽기 및 쓰기 등도 로우 레벨 API 호출로 이뤄진다.

(2) 하이 레벨 API
모바일 운영 체제는 로우 레벨 하드웨어 액세스 서비스 이외에, 개개인의 사용자 경험에 영향을 미치는 하이 레벨 서비스도 제공한다. 하이 레벨 서비스는 웹 검색, 일정및 연락처 관리, 사진 앨범 관리 및 전화 또는 문자 메시지 송수신 기능 등을 일컫는다. 대부분의 모바일 OS는 이러한 서비스를 수행할 수 있는 일련의 애플리케이션을 내장 하고 있지만, 네이티브 앱에서는 퍼블릭하게 공개된 하이 레벨 API를 불러 사용할 수도 있다. 다운로드가 가능한 앱은 다른 API를 통해 OS 업체가 제공하는 푸시 알림이나 인앱(In App) 구매와 같은 다양한 클라우드 기반의 서비스에 액세스할 수 있다.

(3) 그래픽 사용자 인터페이스(GUI) 툴킷
OS 업체에서 제공하는 또 다른 중요한 API 세트는 GUI 툴킷이다. 주요 모바일 OS는 버튼, 입력 필드, 슬라이더, 메뉴, 탭 바, 대화 상자와 같은 OS 고유의 사용자 인터페 이스 구성 요소를 제공한다. 이러한 구성 요소들은 해당 모바일 OS의 기능이 그대로 전이되므로 사용자가 앱을 쉽게 사용하고 즐길 수 있다. 각각의 모바일 플랫폼은 고유의 사용자 인터페이스(UI) 구성 요소를 가지고 있다. 따라서 여러 운영 체제에서 작동하는 앱을 설계하려면 설계자가 각 OS의 서로 다른 UI 구성 요소에 대해 잘 알고 있어야 한다. API가 OS별로 다르므로 여러 개의 네이티브 앱을 개발하려면 개발시간도 많이 걸리고 비용도 많이 들지만, 모바일 기기가 제공하는 모든 기능을 제대로 활용하는 모바일 앱을 개발하기 위해서는 API 활용은 반드시 필요하다.

<표 1> 주요 모바일 OS에서 제공하는 툴, 언어, 패키징 형식, 앱 배포 방법

출처: IBM 소프트웨어(2014). 모바일 앱 개발 방식 비교: 네이티브, 웹, 하이브리드.

 

• 모바일 웹 앱

최신 모바일 기기는 HTML5의 최신 기능, Cascading Style Sheets 3(CSS3) 및 고급 JavaScript를 지원하는 브라우저로 구성되어 있다. 이러한 최신 기능과 함께 HTML5는 페이지 정의 언어에서 브라우저 기반의 풍부한 기능을 가진 애플리케이션을 개발하는 표준 으로 자리잡고 있다. HTML5는 유려한 UI 구성 요소, 다양한 미디어 형식 액세스, 위치 정보 서비스, 네트워크가 끊긴 상태에서도 오프라인으로 사용할 수 있는 다양한 기능을 지원한다. 이러한 HTLM5 기술과 현재 개발 중인 많은 기능을 사용하여 개발자들은 웹 기술만으로 고품질의 애플리케이션을 만들 수 있다. 모바일 웹 앱 개발을 위하여 dojox.mobile, Sencha Touch, jQuery Mobile 등의 JavaScript 툴킷이 개발되었다. 이러한 툴킷은 네이티브 앱과 같은 사용자 인터페이스를 생성한다. 이들 모두 모바일 디바이스의 브라우저에서 실행되고 모바일 브라우저에서 지원하는 JavaScript, CSS 및 HTML5 기능을 활용한다.

 

• 하이브리드 앱

하이브리드 방식은 네이티브 개발과 웹 기술을 혼합한 것이다. 이 방식을 사용하면 개발 자가 모바일 플랫폼과 상관없이 웹 기술로 애플리케이션을 개발할 수 있으며, 필요 시 네이티브 API에 직접 액세스할 수 있다. 애플리케이션의 네이티브 부분은 운영체제 API를 사용하여 브라우저와 디바이스 API 간에 연결고리 역할을 하는 임베디드 HTML 렌더링 엔진을 만든다. 이 연결고리를 통해 하이브 리드 앱은 최신 디바이스가 제공하는 모든 기능을 활용할 수 있다. 앱 개발자는 이 기능을 직접 코딩하거나 PhoneGap과 같은 기존 솔루션을 활용할 수 있다. PhoneGap은 모든 모바일 운영체제에 일관된 단일 JavaScript 인터페이스를 제공하는 오픈 소스 라이브러리이다. 앱의 네이티브 부분은 독립적으로 개발할 수 있지만, 일부 솔루션들은 네이티브 컨테이너를 제품의 구성 요소로 제공하기도 한다. 따라서 개발자는 웹 언어만을 사용하여 모든 디바이스 기능을 활용하는 고급 애플리케이션을 개발할 수 있다. 경우에 따라 개발자가 기업의 고유한 요구 사항에 따라 네이티브 컨테이너를 직접 지정할 수 있도록 허용하는 솔루션도 있다.

 

• 세 가지 개발 방식 비교

<표 2>는 세 가지 개발 방식을 비교 요약한 것이다.
네이티브 방식은 성능과 디바이스의 액세스 가용성을 높이지만 높은 비용과 업데이트 문제가 단점이다. 웹 방식은 상대적으로 간단하고 비용이 적게 들며 업데이트가 쉽지만, 기능상 제한이 따르므로 네이티브 API 호출을 사용하여 제공할 수 있는 우수한 사용자 환경을 제공하기 어렵다. 하이브리드 방식은 이 두 방식의 절충안으로, 여러 기업들이 선택하고 있으며 특히, 여러 운영체제를 한 번에 지원해야 할 경우 선호되는 방식이다.

<표 3-2> 주요 모바일 OS에서 제공하는 툴, 언어, 패키징 형식, 앱 배포 방법

출처: IBM 소프트웨어(2014). 모바일 앱 개발 방식 비교: 네이티브, 웹, 하이브리드.