저는 Google에서 개발자 애드보킷으로 일하는 Dave입니다. 사물 인터넷 (IoT) 플랫폼 팀에서 일하며, 이번 강연에서는 안드로이드 Things 에 대해 말씀드리고자 합니다.

IoT를 모르는 분은 없겠죠? 많은 사람이 IoT에 대해 각기 다른 정의를 내리고 있지만, 저는 스마트 연결 기기를 구축하는 것 이라 정의하겠습니다. 스마트 기기 란 어떤 애플리케이션 소프트웨어로 프로그래밍할 수 있는 장치입니다. 연결 기기 란 오픈 웹이나 클라우드에 연결할 수 있는 기기죠. 가정 내에서 이더넷 네트워크나 Wifi 네트워크에 연결될 수도 있겠지만, 핵심은 특정 클라우드 서비스에 직접 연결한다는 것입니다. 즉, 공공 웹에 직접 연결될 필요는 없는 디바이스입니다. 기기가 IoT 용어로는 게이트웨이나 브리지라고 부르는 중간 장치에 연결돼 있을 수도 있습니다. 이는 기기 자체에 실제로 라디오나 직접 연결하는 네트워크 인터페이스가 없는 경우에 사용합니다. 혹은 Zibgee나 Thread와 같은 저전력 메쉬 라디오가 있지만 다른 기기를 통해 간접적으로 인터넷에 연결하는 기기일 수도 있습니다. 어떤 방식이든 잠재적으로 중앙 클라우드에 연결될 수 있는 말단 기기를 에지 디바이스라고 칭합니다.

안드로이드 Things란 무엇일까요?

운영체제인 안드로이드는 등장 이후 다양한 폼 팩터를 확장했습니다. 처음에는 모바일 폰이나 태블릿 등의 기기를 위해 고안됐지만, 이제 웨어러블 기기, 안드로이드 TV, 안드로이드 Auto 등으로 진화했죠. 이제 안드로이드 플랫폼은 안드로이드 Things라는 새 확장 즉, Google이 특정 유스 케이스를 위해 지원하는 또 다른 안드로이드의 폼 팩터까지 보유하게 됐습니다. 안드로이드 Things는 임베디드나 IoT 유스 케이스에 특화됐고, 이런 기기 개발에 안드로이드 프레임워크를 적용할 수 있습니다. 이전에도 가능하긴 했지만, 중요한 것은 Google이 이런 노력들을 지원하기 시작했다는 사실입니다.

프로토타입에서 상용 앱으로

전반적인 플랫폼을 한 번 살펴보겠습니다. 안드로이드 Things는 실제로 기기에 있는 운영체제로 중요한 역할이긴 하지만 결정적인 부분은 아니며, 이를 둘러싼 환경이 더 중요할 수 있습니다.

Google은 개발자가 모바일 앱을 개발하는 방식처럼 임베디드 기기나 제품을 개발할 수 있도록 돕고자 합니다. 인프라스트럭처와 서비스를 통해 개발자에게 필요한 것을 쉽게 제공할 수 있습니다. 몇 가지 방식을 좀 더 자세히 설명하겠습니다.

첫 번째 방법은 기기 상에서 제공하는 것입니다. 앱을 개발할 때는 모든 안드로이드 프레임워크 를 사용할 수 있죠. 카메라나 블루투스, 미디어, 오디오 재생이나 녹음 등 개발자들이 익히 아는 API를 그대로 재사용하되 다른 방식을 사용하게 됩니다. 최근 IoT에서 주목받는 방식의 유스 케이스입니다.

이미 안드로이드 스튜디오 를 익숙하게 디버그와 배포에 사용하고 있을 겁니다. 앱을 개발하면서 기존의 개발 폰을 사용하듯 보유하고 있는 안드로이드 Things 기기를 컴퓨터에서 ADB로 연결하면 같은 방식으로 기기에 앱을 배포할 수 있습니다. 특별히 추가로 배워야 할 과정이 없습니다.

사실 임베디드 공간에서 안드로이드를 사용한다는 것이 새로운 방식은 아닙니다. 안드로이드는 오픈 소스이며 초반부터 여러 사람이 기기에 올리거나 수정하고 빌드해서 사용해 왔습니다. 하지만 이전에는 안드로이드 오픈 소스의 일부로 제공되는 API나 프레임워크만을 사용해야 했습니다. 모바일 앱 개발자가 사용하는 것처럼 오픈 소스 플랫폼이 아니었기 때문에 자주 활용하는 Google 서비스에 접근할 수 없었던 것이죠. 하지만 이제 안드로이드 Things는 공식 안드로이드 변형이므로 Google 서비스 역시 사용할 수 있고, Google의 Play services, Firebase, Google Cloud 등 Google 서비스에 연결된 모든 API도 사용할 수 있습니다. 따라서 이전에는 임베디드 안드로이드에서 접근할 수 없었던 것을 안드로이드 Things 내에서 접근할 수 있습니다. 이런 장치를 온라인에 연결해서 백엔드와 클라우드 서비스 관련 작업을 할 수 있다는 것은 크나큰 장점입니다.

기기 외에도 더 많은 지원이 있습니다. 예를 들어 Google의 Play Store에서 제공하는 배포 메커니즘은 앱 생태계를 통해 개발자가 누리는 장점이라 할 수 있습니다. 훌륭한 프레임워크를 사용해서 앱을 개발할 수 있을 뿐만 아니라 다른 사람들에게 이 소프트웨어를 배포하고 업데이트하는 메커니즘을 사용할 수 있습니다. 어떤 사용자가 앱을 처음 설치하도록 하거나, 기존 사용자의 앱을 업데이트하도록 돕는 작업을 Play Store가 해주므로 이런 인프라스트럭처를 직접 작성하고 유지 보수할 필요가 없습니다.

Google과 개발자의 관리 범위

IoT 생태계에서도 비슷한 작업을 하려고 합니다. Play Store 자체가 안드로이드 Things를 지원하지는 않지만, 유사한 기능을 제공하려는 생각이 있습니다. IoT 개발자 콘솔을 개발자에게 제공하려 하는데, 애플리케이션을 빌드하고 콘솔에 업로드해서 시장에 출시된 다양한 기기에 배포할 수 있도록 하는 Google Play와 비슷한 공간입니다. 차이점은 각각의 기기에 앱을 설치하지 않는다는 점입니다. IoT 개발자 콘솔은 코드를 가지고 우리가 관리해야 하는 코드, 기본적으로는 모든 핵심 운영 체제로 패키지화하고, 전체 시스템에 대한 무선 업데이트를 통해 빌드할 예정입니다. 안드로이드 폰에서 이미지를 패키지화하고 사이닝해서 디바이스에 전달하는 것과 같은 방식이죠. 개발자가 관리해야 하는 것은 기존 작업과 같은 애플리케이션 레벨뿐이고 드라이버에 대한 사항들도 볼 수 있습니다.

저희는 플랫폼 측면의 업데이트를 책임집니다. 안드로이드의 보안 업데이트나 월간 보안 패치가 있다면 이미지를 다시 빌드해서 보안 픽스가 적용된 기기에 자동으로 배포하며, 개발자는 특별한 조치를 하지 않아도 됩니다. 플랫폼 업데이트가 있다면 새 디바이스를 신규 안드로이드 플랫폼 버전으로 올리는 것을 도와 드립니다. 운영 체제 관리는 Google이 하므로 개발자는 앱만 관리하면 됩니다. 이런 관점은 Play Store와 비슷합니다. 직접 관리하지 않아도 전체 시스템 스택에 자연스럽게 참여하게 되죠.

또한 Google은 이미 안드로이드가 설치된 기기에 안드로이드 버전을 설치하거나 업데이트하는 기존 인프라를 활용하고 있습니다. Google이 사인한 이미지는 기존 OTA 업데이터 메커니즘으로 전달되므로 이미지가 신뢰할 수 있고 사인이 됐으며 다운로드 과정에서 손상되지 않았는지 기기에서 확신할 수 있는 부팅 기능이 존재합니다. 또한 안드로이드 내에 A/B 업데이트 메커니즘이 있어서 다운로드가 백그라운드에서 조용히 처리되면서 기기에 미치는 영향을 최소화하도록 합니다. 이런 기능은 안드로이드 폰에서도 효율적이지만 사용자가 기기를 정기적으로 확인하지 않는 IoT라면 필수 기능이라 할 수 있습니다. 모든 인프라스트럭처를 저희가 책임지면서, 사용자에게 제공하고 앱을 출시하고 현장에서 최신 버전으로 유지하면서 관리할 수 있도록 개발자를 돕고 있습니다.

하드웨어

소프트웨어 서비스 외에도 Google은 실제로 지원되는 하드웨어 플랫폼을 활용해서 물리 장치를 구축하는 프로세스를 단순화하고 있습니다. Raspberry Pi 3 와 같은 하드웨어 플랫폼을 지원하고 있는데, 많은 사람이 사용하며 메이커 마켓이나 취미 생활을 위한 훌륭한 플랫폼입니다. 가격도 저렴하고 프로토타입을 만들기도 쉽습니다. 하지만 하드웨어 측면이나 전자 설계 관점에서 볼 때 대량 구축이 힘들므로 생산 면에서는 어려울 수 있습니다.

안드로이드 Things와 같은 플랫폼을 사용해서 제품을 시장에 출시하려면 다른 옵션을 선택하는 것이 좋습니다. 저희가 지원하는 Intel 2개, NXP 2개 등 다른 플랫폼은 디자인 면에서 시스템 온 모듈(SOM) 기반 아키텍처를 사용한다는 공통 패턴이 있습니다. 모든 핵심 전자 장치, CPU, 메모리, WiFi 인터페이스 등 모든 복잡한 부분이 개발자 키트로 구입할 수 있는 대형 보드에 작은 모듈로 존재한다는 디자인 아이디어입니다.

Edison 모듈과 NXP 모듈의 사진을 보면, 실제로 다른 보드의 위에 올려진 것을 볼 수 있습니다. 개발자 키트를 구입하면 코어 모듈이 캐리어 보드나 브레이크아웃 보드 등의 다른 보드 위에 놓이고 복잡한 전자장치를 작업하기 쉬운 커넥터로 분리하는 형태를 볼 수 있습니다. USB를 플러그인하거나 버튼, LED 등 다른 주변 장치에 쉽게 연결할 수 있습니다. 하지만 프로토타입을 제품 제작 단계로 옮기면 베이스 보드를 제품 디자인에 맞게 대체해야 합니다. 물론 Intel과 NXP가 이미 제공하므로 CPU를 직접 설치하는 것 같이 전자 제품을 직접 건드릴 필요는 없습니다. 커스터마이징해야 하는 보드나 디자인은 전자 제품 관점에서는 단순합니다. 또한, 애플리케이션도 필요 이상으로 복잡하게 만들 필요가 없습니다.

예를 들어 스마트 양초 기기를 만들어서 글로벌 시장에 공급한다고 가정해 보겠습니다. 전체 생태계에 익숙한 안드로이드 개발자로서 안드로이드 Things를 사용하는 것이 좋겠죠. 웹사이트에 가서 어떤 개발자 키트가 있는지 탐색한 다음 Intel Edison으로 결정하고 Edison 개발자 키트를 사서 아이디어를 프로토타이핑하기 시작합니다. 양초이니 LED가 두 개쯤 필요할 겁니다. 오른쪽 핀에 LED를 연결하고 밝기를 조절할 수 있게 하고 레스토랑에서 볼 수 있는 양초처럼 깜박이는 효과도 넣어봅니다.

여러분도 비슷한 과정을 거치게 되겠죠. 개발자 키트를 사고 아이디어를 프로토타이핑해봅니다. 애플리케이션 코드를 만들어서 모든 것이 잘 동작하는 단계에 이르면 다음으로는 양초에 맞는 크기로 바꿔야 합니다. 하지만 개발자 키트의 보드는 양초 크기에 맞지 않으므로 개발 프로토타입을 걸맞는 하우징에 맞게 줄여야 하겠죠. 위 그림에서 제가 들고 있는 것을 보시면 같은 Intel Edison 소프트웨어가 돌고 있지만, 하드웨어가 애플리케이션에 맞게 커스터마이징된 것을 볼 수 있습니다. 모든 것을 축소했고 보드 위에 올라가는 것도 15개 이하로 줄였으며, 깜박이게 만든 LED도 있습니다. 기존 보드에 있던 필요 없는 모듈들은 없앴습니다.

모듈들이 처리해주므로 CPU, 메모리, 안테나를 라우팅하는 방법을 알 필요는 없습니다. 단지 제 앱에 필요한 인터페이스를 만들고 파워를 넣고, 불빛을 깜박이게만 하면 됩니다. 이를 제 애플리케이션에 맞게 커스터마이징한 보드에 올리고 나서 기존 개발자 키트에 있던 불필요한 복잡한 모듈들을 제외하고 필요한 부품들만 디자인에 맞게 하우징에 넣습니다. 이로써 모든 소프트웨어 포트가 끝납니다. 우리가 제공한 BSP와 애플리케이션은 모듈 자체를 대상으로 하므로 구입한 키트와 반드시 일치하지는 않습니다. 여러분이 새로운 디자인을 만들어도 기존과 같은 소프트웨어가 실행되므로 빠르게 변화를 이끌어 낼 수 있습니다. SOM 기반 아키텍처는 제품을 상용화하고 실제로 프로덕션 레벨로 구축하는 데 유리합니다. 이들 모듈은 작고 소량 혹은 대량으로 구입할 수 있으며, 다른 모든 구성 요소를 포함해서 전체 임베디드 시스템을 구축하는 것보다 간단하게 커스터마이징할 수 있습니다.

TensorFlow

하지만 LED 두어 개를 깜박이게 하는데 정말 듀얼 코어 x86 프로세서까지 필요하진 않겠죠? 데모하기에는 좋지만 꼭 필요한 것은 아닙니다. 실제로 이런 제품을 만든다면 Intel Edison이나 안드로이드 Things platform처럼 강력한 성능을 필요로 하진 않을 겁니다. 안드로이드 Things를 쓰기 좋은 유스 케이스는 이전에 말씀드린 게이트웨이 스타일의 기기나 상당한 양의 계산 처리가 필요한 에지 기기입니다. 네트워크 연결이 항상 필요하지 않거나, 기기에서 LED를 깜박이는 것보다 집중적인 처리를 하고 싶은 분들도 있겠죠? 그런 분들을 위해 다음 예제를 준비했습니다.

최근 프리뷰에서 공개한 TensorFlow 예제는 안드로이드 Things와 TensorFlow를 사용합니다. 클라우드에 연결되는 초인종 예제는 기기의 카메라에서 이미지를 저장해서 클라우드 비전 API에 보냅니다. 클라우드 비전 API는 이미지를 다양한 정보를 추가해서 다시 앱으로 돌려줍니다. 하지만 이런 기능을 네트워크 연결 없이도 하고 싶다면 어떨까요?

미리 훈련된 TensorFlow 모델을 사용해서 이미지를 로컬 디바이스에서 분류해주는 비슷한 TensorFlow 예제가 있습니다. 예제에서는 개의 이미지를 분류해줍니다. TensorFlow 모델을 미리 훈련해서 사진으로 개의 품종을 파악하고 보고합니다. 로컬 기기에서 동작하므로 네트워크 연결도 필요하지 않죠. 이런 계산 유형은 안드로이드급의 시스템이 필요합니다. 자신의 유스 케이스를 파악하고 안드로이드 Things와 같은 플랫폼에 이를 지원할 수 있는 하드웨어가 있는지 판단해야 합니다.

개발자 API

안드로이드 Things와 안드로이드는 비슷합니다. 앞서 안드로이드 프레임워크를 사용할 수 있다고 말씀드렸는데 이는 대부분 사실입니다. 하지만 이제부터는 이 플랫폼에서 개발을 시작한다면 기대와 다를 수 있을 부분들을 알려드리겠습니다.

안드로이드 운영 체제의 기본 스택 다이어그램입니다. 코어 부분이 아래에 있고, 초록색에 애플리케이션 프레임워크가 있습니다. 여기가 전력 관리, 액티비티 등 시스템에서 여러분의 코드가 건드리는 부분입니다. 그다음 빌트인 애플리케이션이 맨 위에 올라갑니다. 전화 앱, 컨텍스트 앱 등 안드로이드 기기에 미리 설치되는 앱들이죠. 일반적인 안드로이드 모바일 기기는 이런 구조입니다.

안드로이드 Things는 위와 같은 구조입니다. 코어 앱이 모두 사라지고, 기기에서 유일하게 여러분의 앱만 돌게 되죠. 사용자 측면에서 백그라운드에 몇몇 서비스가 있긴 하지만 기존의 빌트인 애플리케이션이 모두 필요하지는 않기 때문에 빠집니다. 여러분이 만든 앱은 기기에서 실행될 유일한 앱입니다. 또한 안드로이드 Things의 차별성 때문에 프레임워크도 조금 변경됩니다.

안드로이드 Things는 화면이 필요 없습니다. 반면, 안드로이드 폰이나 태블릿은 화면이 있다는 전제가 있죠. 앞서 보여드린 양초의 경우에는 UI도 있고 깜박이는 불빛도 있지만, 화면은 없습니다. 안드로이드 Things는 이런 상황을 지원합니다. 현재 지원하는 플랫폼 중 Raspberry Pi와 Jewel만이 디스플레이 기능을 갖추고 있고 대부분은 디스플레이 기능이 없습니다.

화면이 없는 애플리케이션을 만든다면 뷰와 같은 요소들을 사용하지 않겠지만, 사용할 가능성이 없어지는 것까지는 아니므로 해당 요소들은 계속 남아있습니다. UI가 있는 앱을 만들 수도, 없는 앱을 만들 수도 있습니다. 뷰 시스템은 레이아웃과 버튼 등을 사용하든 하지 않든 남아있습니다. 하지만 어떤 시스템 레벨 기능 중 일부는 디스플레이할 수 없다고 가정하므로 시스템 UI 기능은 제거했습니다.

안드로이드 기기의 화면에서 시스템 서비스가 제어하는 여러 시각적 요소를 시스템 UI라고 합니다. 맨 위의 상태 바나 맨 아래 내비게이션 버튼, 알림 창의 그림자 등이 시스템 UI라는 패키지에서 나오죠. 즉, 이런 것들이 안드로이드 Things에서는 제거된 것입니다. 그래서 화면이 있더라도 앱이 화면의 전체 공간을 차지하게 됩니다. 이 경우 Google에서 알림 시스템 등의 정보를 표시할 공간이 없기 때문에 이런 API가 무의미해진다는 부작용이 있습니다. 따라서 안드로이드 Things에서는 노티피케이션 매니저 API가 중지됩니다.

비슷한 이유로 디스플레이는 선택 사항이기 때문에 시스템이 사용자에게 대화 상자를 표시하려고 할 때 화면이 있다고 가정할 수 없습니다. 대부분 런타임 권한을 요청하기 위해 대화 상자를 표시하려 하는데, 안드로이드 Things의 권한 모델은 이전 안드로이드 버전처럼 앱 설치 시의 권한 모델을 사용합니다. 안드로이드 Things에서 앱 매니페스트 내에서 권한을 요청하면 안드로이드의 최종 버전을 기반으로 하더라도 시스템에서 자동으로 수락됩니다. 대화 상자 자체가 표시될 수 없는 경우가 있으므로 대화 상자로는 사용자에게 권한을 요청할 수 없습니다. USB API 경우 시스템 대화상자를 보여줄 수 있긴 하지만 어떤 방법이든 대화 상자는 사라지게 됩니다.

Home Activity

몇몇 사용자 시스템 대화 상자를 위해 화면이 있다고 가정하는 API를 사용하는 경우 안드로이드 Things에 앱을 빌드하게 되면 어떤 모습이 될까요? 애플리케이션 프로젝트를 평범하게 시작합니다. 내부에 액티비티가 있고 이 액티비티가 애플리케이션의 진입점이 됩니다.

처음에는 화면도 없고 뷰도 없는데 액티비티는 왜 필요한지 의아하게 생각할 수도 있습니다. 하지만 액티비티는 디스플레이 창보다 많은 역할을 합니다. 액티비티는 현재 사용자가 집중하는 행위를 나타내는 구성 요소입니다. 디스플레이와 관련이 없는 액티비티를 거치는 시스템 이벤트도 있습니다. 예를 들어 키 이벤트, 외부 게임 컨트롤러의 모션 이벤트, 혹은 뭔가 연결된 이벤트 등은 전경 액티비티가 무엇이든 간에 라우팅 됩니다. 따라서 UI에 상관없이, 화면이 없더라도 액티비티가 필요합니다. 컨트롤러든 버튼이든 모든 이벤트가 여전히 해당 구성 요소로 들어오니까요.

앱에 포함하는 최상단 디펜던시인 새 서포트 라이브러리도 있습니다. 이 서포트 라이브러리는 이미지에 내장되며, 코어 프레임워크 외부에 있으므로 디펜던시에 추가해야 앱이 컴파일됩니다. 앱 안으로 복사할 필요는 없고 앱 디펜던시에 다른 서포트 라이브러리를 추가하는 것처럼 빌드 문서의 Gradle 파일에 컴파일 키워드를 넣으면 됩니다.

메인 액티비티를 만들고 나면 하나 이상의 액티비티가 IoT 런처 인텐트 필터를 가지고 있어야 합니다. 일반적인 안드로이드 기기에 있는 일반적인 시작 타입과는 다르며, 사용자가 앱을 시작해서 고를 수 있도록 하지 않습니다. 즉, 사용자가 선택하는 대신 시스템이 부팅된 다음 자동으로 애플리케이션을 시작해 주며, 시스템은 어떤 앱과 어떤 액티비티를 맨 먼저 시작할지 인텐트 필터를 사용해서 검색합니다.

정리하자면 기존에 해왔던 것처럼 액티비티 기반 앱을 만들고, 디펜던시를 추가하고, 메인 혹은 최초의 액티비티를 인텐트 필터로 지정해주면 됩니다.

API

API는 크게 두 가지 카테고리로 분류됩니다. 먼저 주변 장치 IO API 라고 명명한 API로, 시스템에 연결하는 다양한 주변 기기와 낮은 수준에서 상호작용할 수 있게 하는 여러 다른 API를 추가했습니다. 예를 들어 GPIO, PWM, I2C, SPI, UART로 ee에는 해당 인터페이스의 용도와 일반적 위치를 알려주는 설명서가 있습니다. 마켓에서 구입한 센서나 기타 주변 장치가 호스트 시스템과 통신하는 데 사용하는 일반적인 인터페이스라고 생각하면 됩니다. PI, I2C, UART는 온도 센서나 가속도계 등 기기에 부착한 것과 통신할 수 있는 직렬 프로토콜입니다.

다음으로 사용자 드라이버 라고 명명한 API도 만들었습니다. 애플리케이션에 따라 사용할 수도, 사용하지 않을 수도 있는 API입니다. 실제 주변 장치와 통합하는 것 외에도 주변 장치의 데이터를 가져와서 기존 프레임워크 서비스에 추가할 수도 있습니다. 입력 시스템, 센서 시스템, GPS, 세 가지 카테고리를 지원합니다.

몇 가지 예를 들어 볼까요? 어떤 커스텀 기기에 자신의 GPS 모듈을 추가했지만 GPS에서 바로 원본 데이터를 읽지 않고 안드로이드의 위치 관리 API를 사용해서 데이터에 접근하고 싶다고 가정해 보겠습니다. 이렇게 할 수는 있지만 GPS를 추가한 것을 안드로이드가 파악할 수는 없습니다. 따라서 낮은 수준의 데이터를 모듈에서 가져오고 이를 프레임워크에 적용해서 해당 요소와 연관된 위치 업데이트가 브로드캐스트되도록 사용자 드라이버를 작성해야 합니다. 안드로이드 센서 관리자 프레임워크는 이런 작업을 해주는 API를 이미 가지고 있긴 하지만, 센서를 인식하지 못하므로 하드웨어에서 가져온 데이터를 시스템에 주입해서 다른 API와 작용할 수 있도록 해야 합니다.

이처럼 해야 하는 이유는 뭘까요? 기존 애플리케이션을 이식하는 경우 이미 작성된 API로 코드를 작업하는 것이 더 쉬울 수도 있습니다. 혹은 함께 작업하는 개발자가 새 주변 장치 API를 다루는 것보다 인터페이스를 작업하는 것을 선호할 수도 있습니다. 또한 안드로이드 프레임워크는 이 데이터를 사용해서 추가 비트를 처리하므로 데이터를 직접 읽는 경우라면 쉽게 얻기 힘든 정보를 줄 수도 있습니다. GPS와 위치 정보를 생각해보면, 프레임워크가 GPS 업데이트 정보를 아는 경우 이 정보를 fuse 위치 공급자에 첨부해서 앱에서 더욱 정확하게 위치 업데이트를 제공할 수 있도록 해줍니다. 안드로이드가 해당 데이터를 GPS에서 오는 것으로 인식한다면 이런 동작을 해주겠지만, 인식하지 못한다면 GPS 모듈에서 원본 데이터를 읽어와야 합니다. 주변 장치가 무엇인지 실제로 알 필요가 없는 경우라도 이렇게 데이터를 프레임워크에 적용해서 추가 혜택을 얻는 편이 좋습니다.

마지막으로, 서포트 라이브러리에 포함된 내용은 아니지만, 오픈 소스인 주변 장치 드라이버 라이브러리 도 있습니다. Adafruit, SparkFun, Seeed 등 표준 리테일러에서 구입할 수 있는 일반적인 주변 장치를 위해 제공하는 드라이버의 호스트입니다. 여기에는 구입한 일반 GPS 칩이나 센서 혹은 스타터 키트에 있는 주변 장치를 위해 미리 만들어진 드라이버가 포함되므로 바로 작업을 시작하고 기기를 연결해서 추가 드라이브들에 로딩한 후, I2C 프로토콜에 대해 공부할 필요 없이 단 몇 줄의 코드만으로 작업할 수 있습니다.

얼마나 쉬운지 예제 코드를 보여드리겠습니다. 앞서 본 양초의 두 LED들은 0에서 100%까지 조절할 수 있는 출력값인 2개의 PWM(pulse with modulation)에 각각 연결됩니다. 안드로이드 앱 코드에서는 주변 장치 관리 서비스를 통해 이들 API에 접근합니다. 초기화 작업만 살짝 다를 뿐, 안드로이드 프레임워크에서 사용하는 다른 매니저와 비슷하죠. 그다음 각 PWM과의 연결을 엽니다. API로 원하는 대로 상태를 초기화할 수 있습니다. 앞서 언급했듯 PWM은 값을 변화할 수 있는 출력값이므로 작업 사이클 등을 설정해서 얼마나 자주 값이 출력돼야 하는지 설정할 수 있습니다. 25는 25% 정도 켜져야 한다는 뜻으로 LED에서는 희미한 빛이 나겠죠. 이 값을 100%으로 올리면 가장 밝은 빛이 납니다. 이런 식으로 양초의 불을 제어할 수 있습니다. 안드로이드의 다른 하드웨어 리소스와 마찬가지로 더 이상 사용하지 않는 경우 맨 아랫줄처럼 닫아야겠죠.

간단한 주변 장치 I/O

간단한 주변 장치 I/O 관점에서는 보신 것처럼 간단합니다. 서비스를 초기화하고 핀에 대한 연결을 열거나 닫아서 설정할 수 있습니다. 그렇다면 안드로이드와 같은 프레임워크에서는 어떤 작업을 더 할 수 있을까요?

마이크로 컨트롤러나 다른 임베디드 시스템에서 이런 예제를 작성한다면 깜박임 효과를 만들기 위해 타이머나 루프 혹은 밝깃값을 확인할 무언가를 만들고 지속해서 값을 설정해야 할 겁니다. 하지만 안드로이드를 사용하는 우리는 밝기 속성을 만들고 시간에 따라 이 값을 변경하는 작업에 애니메이션을 사용할 수 있습니다. 하드웨어의 속성을 움직인다면 애니메이션 API를 사용해서 애니메이션을 만드는 것이 좋습니다. 코드가 정말 간단해지죠!

하드웨어 애니메이팅

위 예제에서는 brightness라는 새 애니메이션 속성을 만들어서 PWM를 0에서 100% 사이로 조절하는 작업 사이클을 업데이트하도록 했습니다. 이렇게 만든 래퍼를 기존 애니메이션 API, 여기서는 오브젝트 애니메이터에 붙이고 PWM 값을 25에서 100 사이로 애니메이트하도록 했습니다. 애니메이션 API 기능을 통해 이런 작업을 쉽게 할 수 있죠. 오토 리버스를 이용해서 밝다가 희미하다가 다시 밝도록 할 수도 있고, interpolator를 사용해서 깜박이는 효과를 낼 수도 있습니다. 특히 바운스 interpolator는 애니메이션 값을 받아서 안정값에 도달하기 전에 살짝 진동하도록 해주는데, 이를 LED 양초의 깜박임 효과로 활용할 수 있습니다.

간단하게 코드를 작성하고 PWM을 생성하기 전에 필요한 것과 연계한 다음 애니메이션을 시작하기만 하면 됩니다. 타이머도, 루프도, 핸들러도 아무것도 필요하지 않습니다. 제가 중단하기 전까지는 애니메이션 프레임워크가 모든 것을 처리해줄 겁니다. 수백 번 사용해왔던 기존 API이고, 여전히 속성을 애니메이팅하지만, 실제 디스플레이가 아닌 물리적 하드웨어를 애니메이팅했습니다.

요약

안드로이드 Things 플랫폼에 대해 요약하자면 이렇습니다. 안드로이드 Things는 안드로이드의 능력 을 임베디드나 IoT 스타일 개발에 활용할 수 있도록 하는 플랫폼입니다. (덧붙여 플레이 서비스 등과 같은 것도 제공되므로 Google의 능력도 사용할 수 있습니다.) AOSP를 직접 포크 해서 사용할 때와 달리, 업데이트 관리와 디바이스 푸시를 지원받을 수 있으며 Google 서비스도 사용할 수 있습니다. 그뿐만 아니라 보안 업데이트 도 Google이 담당합니다. 보안 패치 형태의 플랫폼 업데이트가 있으면 이를 기기에 자동으로 적용합니다. IoT 기기를 개발할 때 이 문제를 해결하기 위한 수많은 시도가 있었지만 이제 여러분이 이미 가지고 있는 안드로이드 지식을 사용해서 해결할 수 있는 플랫폼이 등장한 것이죠.

안드로이드 Things SDK와 문서는 안드로이드 개발자 사이트에서 볼 수 있습니다. 예제 코드와 드라이버 라이브러리 등은 GitHub을 확인하세요. 저를 포함한 개발자 애드보킷, 팀 엔지니어들은 항상 G Plus의 IoT 개발자 커뮤니티에서 질문에 응답해드립니다. 커뮤니티에서 여러분의 멋진 작업을 공유하고, 커뮤니티의 다른 개발자 작업도 확인해 보세요.