안녕하세요 Web of Think 입니다.

몇 년만에 작성하는 포스트인지 모르겠네요.

대략 5년여 전부터 web technology 기반으로 사물인터넷 세상(IoT world)이 구현될 것이라는 상상을 블로그에 적어 내려가기 시작했습니다. 이후로 많은 시간이 지나 관심사도 많이 변했지만, 컨넥티드 사물들(connected things)를 실생활에서 만날 기회가 생길 때마다 이렇게 다시 글을 쓰게 되네요.  

오늘은 제 인생의 첫 차와 예약 구매로 아직 제품이 도착하지 않은 블랙박스, 그리고 NB-IoT 모듈에 관한 이야기를 적어 보려고 합니다.

가장 먼저 필요한 준비물은 흔하게 볼 수 있는 연결끊긴 이동형 기기(unconnected mobile device) 입니다. (아래 사진은 관련이 있습니다) 

테슬라조차 아직까지 완전하 자동으로 움직이지 않지만 자동차라는 별명으로 알려진 이 기기는 놀랍게도 이미 백 년 전에 1.5시간 만에 완성시킬 수 있는 생산 최적화(e.g., 모델-T)를 이뤄 냈습니다. Oh My Ford! 그럼에도 불구하고, 원더키디 2020년 현재 코로나19와 같은 소소한(?) 이유로 배송하는 데만 일주일이 넘게 걸리는 마법(?)을 보여줍니다. 

사족이지만 더욱 놀라운 사실(!)은 이 기기를 구매하는 대부분의 사람들은 몇 가지에 불과한(?) 옵션 만을 선택할 수 있음에도 불구하고, 제품을 받기까지 길게는 7주까지 기다리는 인내력을 발휘한다고 하더군요. 전 어떻게든 빠르고 싸게 사겠다는 욕망에 영맨의 제고 관리 프로그램에서 우연히 발견한 하나뿐인 재고(?) 신차를 줍줍하였습니다. 이 기기의 추가 옵션에 블랙박스나 네비처럼 커넥티드 서비스(connected service)를 끼워팔기(bundling)하지만, 제가 7주의 인내력을 가질 수 없는 상황이기도 하고 비싸기도 해서 과감히 제외하고 요즘 신차 기본 옵션이라 불리는 슬기 운전(드라이브 와이즈) 구성만을 장착해 둔 것을 장바구니에 넣었습니다.     

오랫만에 글을 쓰니 (사실은 차를 처음 사보니) 사설이 길었네요. 양해 바랍니다;; 

두 번째 준비물은 어쩌다 찾은 할인 예약 구매한 제품인 아이나비 FXD5000 입니다.  (아래 광고 사진 및 야간 촬영 영상)

선택의 배경은 이렇습니다. 장기렌트로 빌려 타던 차량에는 (영맨이 서비스로 부착해 준) 어떤 블랙박스가 있었는데 촬영 품질이나 사용성 모두 너무 나빠서 차를 구매하면 절대 번들링하지 않겠다고 생각했습니다. 그래서, 서비스를 마다하고 직접 알아보았는데 블랙박스 제품들의 촬영 품질과 사용성을 검토해보니 품질이 조금 좋아질 수록 가격이 많이 오르더군요. (귀차니즘과 후회의 연속) 그래서 아직 변변한 사용기조차 없지만 제작사가 공개한 주행 영상이 보여주는 품질만 보고 예약 구매에 낚길 수 밖에 없었습니다. 

사실 블랙박스의 품질보다도 개인적인 바램이 자동차가 여전히 스스로 움직이지 못하더라도, 스마트폰으로 간접적인 대화라도 할 수 있었으면 했습니다. 특히 스마트 앱의 핵심은 유지보수라는 점에 착안해서 소프트웨어(도) 직접 만드는 금방 망하지 않을 것 같은 브랜드의 블랙박스를 선택하게 된 거죠.

FXD5000 언박싱입니다. 예약 주문 배송 건이라 출발 메시지는 늦었지만 정말 신속하게 배송되었네요.

마지막 준비물로 이번 포스트의 가장 핵심 모듈이지만 의외로 별매인 '커넥티드 PKG' 입니다.

앞서 블랙박스 예약 구매 할인 혜택으로 아낀 비용을 투자해서 2년 간 NB-IoT 통신 요금을 포함한 핵심 장치를 위메프에서 다나외 최적가인 6만원 미만으로 구매하였습니다. 이 장치를 달아야만 '아이나비 커넥티드'라는 모바일 앱으로 원격 접속이 가능해 진다네요. 

이 놀라운 물건은 LG U+에서 제공하는 통신망에 연결할 수 있는 유심을 포함한 일종의 모뎀에 불과한데 무료 기간인 2년이 지나고 계속 사용하면 매년 2만원 정도의 통신료가 청구됩니다. (아니면 그냥 GPS로 동작) 통신망의 빠른 발전으로 스마트폰 구매 주기가 2년 여에 불과했었는데 이런 통신 장치 역시 이런 방식으로 빠르게 발전해 갈지가 제 관전 포인트입니다.

이 장치와 연동되는 소물인터넷 통신망의 대역폭에 맞춰 가격과 앱이 제공하는 기능 - 고속(Pro)과 저속(Standard) -이 꽤 다릅니다. 자세한 내용은 판매자의 블로그 링크에 잘 정리되어 있네요.

역시 곁다리이지만 여기에 쓰인 NB-IoT 기술과 M2M 네트워크 기술들에 대한 내용은 이 블로그에서 잘 정리하고 있습니다. 

이제 본격적으로 조립기를 작성해야 할 시점이지만 블랙박스 설치는 관심사가 아니므로(?) 윈도우 틴팅을 하면서 겸사 겸사 설치를 위탁했네요..;;;

이제 본격적인 설치를 해봅니다.

NANO USIM 칩을 통신 모듈 후면에 장착하고 GPS 연결 단자와 연결하면 끝인 줄 알았습니다.

블랙박스 설명서에서 커넥티드 모듈에 대한 설명이 부족하여 몇 가지 의구심이 생기는 문제 단계에 진입했습니다.

• 검색 결과에 따르면, 이전 제품들에서는 GPS 신호 픽토그램(pictogram)과 네트워크 연결 픽토그램이 각각 표시되는 것 같은데 이 제품은 GPS 신호로 보이는 픽토그램만 계속 점멸됩니다. 네트워크 연결 픽토그램이 나타나지 않으니 커넥티드 모듈 혹은 유심칩 연결에 문제가 있는 건지 모르겠네요.
• 설명서에 따르면 몇 분 내에 네트워크에 연결된다고 하는데 생각보다 꽤 걸리더군요. 아마 지하 주차장에서의 통신 상황이 여의치 않아 그럴 수 있겠다는 생각이 듭니다.
• 등록하라는 팝업 창이 나타났는데 확인을 누르니 다시 이전 상태로 돌아 갑니다. 여전히 네트워크 연결 픽토그램이 보이지 않아서 네트워크에 연결된 건지 알기 어렵습니다. 

아이나비 커넥티드 앱을 스마트폰에 설치하고 로그인하면 위와 같이 등록할 수 있는 메뉴가 나타납니다. 블랙박스 등록 버튼을 누르면 유심칩에 기재된 전화번호(?)를 입력해 등록을 진행할 수 있습니다. 등록 절차는 스마트 폰에서 요청하고 블랙박스 디스플레이에서 확인하는 블루투스 같은 프로세스입니다.

블루투스와 확실히 다른 점(?)은 근거리가 아닌 원거리 통신 프로토콜(NB-IoT)을 쓴다는 점이죠.  

여기서 블랙박스의 다양한 사용사례(?)에 대한 의문점들이 떠오릅니다.

• 블랙박스 등록 시, 앱에서 로그인한 계정만 블랙박스에 연결할 수 있는가? 다시 말하면 여러 계정이 하나의 블랙박스를 공유할 수 없나?
• 블랙박스 등록 계정을 해지하고 다시 등록할 수 있는가?
• 블랙박스의 촬영 데이터 사용자 구분 및 개인정보 보호가 가능한가?  

첫 번째, 패밀리 카처럼 운전자가 두 명 이상일 경우, 가족 계정이라는 개념이 필요합니다. 즉, 사건 사고  발생 시 알람을 공유할 수 있으면 보다 빠른 조치가 가능할 것으로 보입니다.

반면 두 번째는 사용 중인 블랙박스를 재판매하거나 이전하는 경우입니다. 스마트폰이 그러하듯 여기에도 초기화라는 개념이 필요합니다.

세 번째는 앞서 든 두 가지의 사례의 확장인데 운전정보보호 개념입니다. 운전 중에 블랙박스로 촬영된 영상이 동선을 노출하기 때문에 프라이버시에 민감한 분들을 위해 이를 보호할 방법이 필요합니다. 더불어 앞서 다중 운전자의 사례처럼 기존의 영상 구분 방법 외에도 운전자에 따라 촬영 데이터가 분리될 필요성도 있습니다. 

쓰다보니 많이 엇나간 듯 하지만 한줄 정리하면, 커넥티드 기기가 되면, 기존에 없던 사용 사례들이 가능해지고 이에 따른 고려사항들이 생긴다는 것입니다. 유선 전화기와 데스크톱 PC에서 진화하여 스스로는 못 움직이지만 움직이게 된 스마트폰 역시 그런 과정을 통해 오늘에 이른 것입니다.

다시 사용기로 돌아와서, standard 버전에서는 위와 같이 블랙박스 전원 on/off 버튼, 차량 배터리 전압 표시, 그리고 현재 날씨 정보가  제공됩니다. '나의 주행'이나 '실시간' 감시와 같은 고급(?) 기능은 pro 버전을 쓰라고 되어 있고요. 그리고 standard 버전은 충격이나 충돌 이벤트 시 전면 카메라의 스틸샷(still shot)이 핸드폰에 전송됩니다. 문을 닫았을 뿐인데도 충격 이벤트가 오네요. 정밀도(precision)보다 재현율(recall)에 맞춰 셋팅된 것으로 보입니다. 아무래도 블랙 박스를 달았는데 사건 사고 발생 시에도 기록이 없다면 소송감(?)일테니 말이죠. 

스마트 폰 앱은 pro 버전 사용자의 사용자 경험에 최적화한 것 같습니다. 차라리 standard 버전을 기준으로 설계하고 pro 버전은 별도 앱 혹은 옵션에서 확장할 수 있도록 하는게 낮지 않을까 싶네요. 나를 기준으로 맞춰주세요.  

차량에 설치된 블랙박스의 기능과 UI는 크게 도드라지지도 떨어지지도 않는 것 같습니다. full HD 영상이지만 디스플레이의 터치 반응 속도도 빨라서 블랙박스에서도 빠르게 촬영된 이벤트들을 검토해볼 수 있었습니다.

지금까지 긴 글 읽어 주셔서 감사합니다. 총평은 자잘한 아쉬움(?)이 있긴 하지만 오래된 아이나비 브랜드에 걸맞는 완성도를 보여준다고 할 수 있을 것 같네요. 더욱 진화되어 connectable이 connnected one에서 connected all이 되면 좋겠네요.  

역설적이게도 보험처럼 돈 낭비(?)가 되겠지만 부디 아무런 사건 사고 없이 블랙박스를 뒤질 일 없이 안전 운행하길 기원해 봅니다.  

p.s. 앞서 밝힌 것과 다르게 글을 쓰는 동기가 순수하지만은 않아 늦었지만 양심 고백(?)합니다. 사실 예약구매 사은품 조건으로 후기 작성 시 주유권(충전도 가능) 제공 이벤트가 있길래 이렇게 후기도 아닌데 서둘러 글을 썼네요. 놀랍게도!! 이벤트 담당자 분께서 업데이트 약속을 믿고 미리 모바일 상품권을 보내 주셨습니다!!! ㅠ.ㅠ 따라서, 전 아니지만 다른 유명 블로그들처럼 이 포스트는 아이나비의 사은품 후원을 받았음을 밝힙니다.         

안녕하세요. 

"생각의 웹"입니다.

지난 AppIN 세미나를 통해 소개했던 Do IoT Yourself 프로젝트를 기반으로 

thermistor 대신 온습도 센서(DHT11)를 달아 며칠 간 안방의 온습도 트랜드를 측정해 보았습니다.

먼저, 검색해 보니 계절 별로 생활하기 적정한 온/습도에 관련 내용이 있더군요.

실내 적정 온도와 습도

 지금과 같이 겨울철에는 적정온도 18~21도, 습도 40% (알레르기 비염환자의 경우 50%)라고 하는군요.

사실, 이 프로젝트를 적극적으로 시작한 계기는 

제 아내와 아이들이 알레르기 비염 증상이 있어 잠자는 도중에 재채기를 심하게 하는 경우가 많아서 입니다.

(가끔 저도 같은 증상을 겪기도 했습니다.)

비염을 예방하기 위해서 가.성.비가 탁월하다는 공기청정기를 구매해 사용하니 

방 안 먼지 때문에 나오는 재채기는 줄어 들었으나 

잠자는 도중 하는 재채기가 줄어들지 않더군요.

따라서 잠자는 도중 하는 재채기의 원인을 온,습도의 변화로 지목하고

제 때 물 갈기가 귀찮아서 사놓고 방치했던 가습기를 켠 상태에서 

방 안의 온, 습도를 모니터링하기로 결정했습니다.

다음은 날짜 별로 온습도 변경 기록 및 요약입니다.

11월 18일

- 시스템 설치 첫 날 오후 2시 경부터 온습도 기록을 시작했습니다. 온도는 23도에서 +- 2도 정도의 변화를 보였습니다. 

   보일러의 목표 온도가 22도로 맞추어져 있기 때문에 추워지면 보일러가 돌아간 것으로 보입니다. 

- 가습기의 목표 습도를 50%로 설정하고 잠자리에 들기 전부터 가동했습니다.

- 가습기를 가동한 저녁부터 습도가 34%에서 37%로 증가했습니다.

  가습기 자체에 습도계가 있어 목표 습도인 50%가 되면 습기량이 줄어들고 

  습도가 다시 낮아지면 습기량이 느는 동작을 반복합니다.

- 다행히도 가습기를 튼 당일부터 잠자는 도중 하던 재채기가 사라졌습니다. 

  적용 첫날부터 효과가 있는 걸로 보아 기침의 원인은 습도였나 봅니다. ^^

11월 19일

- 밤, 새벽 시간 온도는 22도 수준을 유지하다 낮에는 24도 수준으로 올라갔습니다.

- 가습기가 동작하던 오전 9시 경까지 습도가 36~37%를 유지하다 가습기를 끈 낮에는 34% 수준으로 떨어졌습니다.

- 가습기가 동작한 저녁 8시부터 습도가 다시 2% 정도 증가했습니다. (여전히 목표 습도는 50% 입니다.)

11월 20일

- 11월 19일과 유사한 환경에서 오전만 측정했습니다. 

   (오후에는 시스템 개선 작업을 진행하느라 잠시 꺼두었습니다. ^^a )

- 밤 12시에 24도에서 점차 떨어져 새벽 6시 경에는 21도가 되었다가 해가 뜨니 25도까지 올랐습니다.

- 가습기가 동작한 밤에는 습도가 37% 수준에서 유지되다가 아침에 가습기를 끄니 34% 수준으로 떨어졌습니다.

11월 21일

- 온도가 밤부터 새벽 시간에는 23도에서 머무르다 낮이 되니 25도까지 올랐다가 다시 밤에는 23도로 돌아왔습니다.

- 가습기가 동작할때의 습도는 35~37%, 가습기를 끄면 34%까지 내려갑니다. 

  안방의 습도는 34% 수준에서 평형을 유지하는가 봅니다. 

11월 22일

- 온도가 밤부터 아침까지 22도에서 24도로 올랐다가 낮에 25도가 되었습니다.

  그날 따뜻했는지 21일보다 1도 정도가 더 높네요.

- 습도는 가습기가 동작하는 밤에는 37%였다가 가습기를 꺼두어도 35~36% 수준을 유지했습니다.

11월 23일

- 온도가 새벽 2시부터 올라 23도에서 26도까지 올랐습니다. 아침 10시경 외출했더니 낮임에도 불구하고 23도로 내려왔습니다.

- 가습기의 목표 습도를 60%로 설정하고 동작했음에도 습도는 35~6% 수준에서 

  머물러 있습니다. 

마무으리~로 지난 시험의 결과를 요약해 보면

- 방 안의 온도가 겨울철 적정 온도(18~21도)보다 3~5도가 높아서 너무 따뜻하게 지내는 것일 수 있을 듯 합니다.

  난방비를 생각해서 희망 온도를 22도에서 20도로 줄이는 걸 고려해 봐야 겠습니다.     

- 습도는 가습기를 동작시켜도 적정 습도인 40%에는 부족한 37% 수준까지만 올라갑니다. 

  희망 습도를 60%으로 올리더라도 습도 변화에 큰 차이가 없는 걸 보니 가습기의 습도계를 믿어선 안될 듯 싶네요.

  비염 환자를 위한 적정 습도인 50%까지 올리려면 지속적으로 가습기를 켜 두어야 할 것 같습니다.

이 측정을 하기 전에는 

바닥에서 자는 아내가 새벽에 코가 시릴 정도로 춥다고 해서 난방 온도를 올리는 방향으로 결정했으나 

측정 결과, 난방 온도를 올리면 상대적으로 습도가 낮아지고 온도 차에 의한 순환 때문에 외풍이 부는 것처럼 느껴지는게 아닐까 하는 의심이 들었습니다.

따라서, 오늘 밤부터는 난방을 줄이고 가습을 더 하는 방향으로 시험해서 체감 온도를 느껴봐야 겠습니다.

이처럼 단순히 온도 (+습도)를 측량하는 간단한 D.IoT.Y 기기만으로도 작지만 의미있는 일들을 

(가정에서 부터) 시작할 수 있습니다.

여러 분들도 손쉽게 D.IoT.Y 하시면서 비용도 줄이고 건강도 챙기는 일석이조의 효과 얻기를 바랍니다.

여기까지 읽어 주셔서 감사합니다.

행복한 (그리고 건강한) 겨울철 보내시길!

안녕하세요, "생각의 웹"입니다.

앞서 아두이노 보드와 Node.js를 이용해 RESTful Web API와 JavaScript API를 제공하는 Do IoT Yourself 프로젝트를 소개한 바 있습니다.

문득 누군가 이와 유사한 프로젝트를 이미 하지 않을까 하는 생각이 들어 'arduino rest api'로 구글링해 보았습니다.

(친절한 구글 신은 자동 완성 기능을 통해 이런 프로젝트가 존재할 것이라는 제 예상에 힘을 실어 주었습니다.)

그 결과 발견한 프로젝트가 바로 aREST - arduino REST의 축약으로 보입니다. - 입니다.

http://arest.io/

상세 내용에 앞서 이 프로젝트를 통해 가능한 데모 영상 하나 보시죠. 

// 1. Connect a LED & resistor to pin number 8 of your Arduino board
GET 192.168.2.2/mode/8/o  // 2. Set the pin 8 as an output
GET 192.168.2.2/digital/8/1 // 3. Turn on LED

- 다양한 아두이노 보드 지원

  : Uno, Mega, Due, Yun and Teensy 3.x.

- 다양한 connectivity 지원

  : USB나 XBee를 통한 Serial 통신

  : CC3000 WiFi chip를 통한 HTTP 통신

  : Ethernet shield를 통한 HTTP 통신

  : nRF8001 chip를 통한 Bluetooth Low Energy 통신

- multicast DNS 프로토콜 지원으로 discovery 가능

  : Bonjour 서비스 필요

http://arest.io/ 를 보면 arduino library, Node.js module, JavaScript client 세 프로젝트로 구분되어 있는데 각각의

코드를 상세 검토(deep dive) 해 보면 다음과 같이 요약할 수 있습니다.

- arduino library: aREST의 핵심 모듈입니다. arduino IDE 프로젝트 파일 (*.ino)로 다양한 connectivity 하에서 

http server 기능을 C/C++로 구현하고 있습니다. 

- Node.js module: serial 통신을 통해 연결된 arduino 보드와의 gateway server 역할

- JavaScript client: aREST의 API를 호출하는 AJAX 코드

마무~으리로 이 프로젝트의 장/단점을 정리해 보겠습니다.  

- 장점

  : 다양한 connectivity를 지원합니다. 필요한 요구사항에 맞춰 가져다 쓸 수 있다는 점은 매우 매력적입니다.

  : 아두이노 보드(+ Ethernet or WiFi chip) 만으로도 독립된 인터넷 노드를 만들 수 있습니다.

  : 통신 시 전송량이 적은 JSON respresentation를 사용합니다.

- 단점

  : 보다 복잡한 기능을 추가하기 위해서는 arduino IDE를 통해 펌웨어를 업데이트해야 합니다.

    아두이노 펌웨어에 올릴 수 있는 코드 용량이 한정되어 있는 것으로 알고 있기에 제한을 받으리라 보입니다.

  : 제공하는 REST API의 성숙도 수준이 낮습니다. 

    상태를 변경시키는 unsafe 행위(e.g. LED를 켬)를 GET 명령으로 수행하고 있습니다.

    앞서 포스팅한 리처드슨 REST 성숙도 모델에 따르면 Level 1에 해당하며 클라이언트 프로그래밍 시 오류를

    야기시킬 수 있습니다.

  : 라이센스가 GPL입니다. 상업적인 목적으로 사용하시려는 분은 GPL이 모든 소스코드와 함께 빌드 방법까지 공개해야 하는 점을 유념하시기 바랍니다.  

이번 포스팅은 여기까지 입니다.

감사합니다.

안녕하세요,

"생각의 웹"입니다.

혹시 이 블로그에 방문한 분 중 이 블로그의 제목인 "생각의 웹"이 어디서 유래했을까 궁금했던 분이 있을까 싶습니다.

(사실 그런 건 저만의 지나친 기대에 불과하다는 걸 잘 알면서도 혹시나 해서... ^^;)

먼저 블로그의 취지를 말씀드리면 이 블로그는 웹 기술과 사물 인터넷에 대해 공유하는 목적으로 만들었습니다. 

좀 더 살을 붙여 말하자면 지난 몇 년간 기업 연구소에서 모바일 및 가전 기기를 위한 웹 기술에 대해 연구해 온 것들을 정리하고 이를 통해 멀지 않은 미래에 도래할 초연결 사회의 기술적 기반인 사물인터넷에 대해 논의하면서 함께 만들어 가고 싶었습니다.

부속 프로젝트인 Do IoT Yourself 역시 그런 맥락으로 진행된 것이고요.

질문의 답은 web of think는 internet of things의 응용 계층(application layer)에 해당하는 web of things의 발음에 유사한 점을 착안해서 만들었습니다. (이걸 맞추신 분들과는 서로 '통'하였다는 기쁨을 나누고 싶군요.  :-) )

사실 오래 전부터 '스스로 사고하는 웹'으로써 semantic web이라는 기술 영역이 존재하고 이에 관련된 많은 연구들이 진행되어 왔습니다.

주로 '정보'와 '정보'의 관계를 온토롤지(onthology)로 구축함으로써 컴퓨터가 정보의 의미(semantics)를 사고(reasoning)하는 방향으로 흘러가고 있습니다.

하지만 사물 인터넷 상에서 사물들이 서로 대화하기 위한 생각으로써는 어떨까요? 아마도 semantic web를 포함한 그 무엇인가가 더 필요하지 않을까요?

다음의 포스트는 앞서 번역한 사물인터넷을 지탱하는 것에 이어 사물 인터넷 기기들이 어떻게 생각하게 될지에 대한 내용입니다.

앞서 번역한 것과 같이 오역이 심한 번역이지만 이 글을 통해 제가 얻은 통찰을 공유하고픈 마음에 공유드립니다.  

영어 능력자 분들은 되도록 원문을 참고하시기 바랍니다. (: 

원문 : http://readwrite.com/2013/07/15/how-the-internet-of-things-will-think

사물인터넷은 어떻게 생각할 수 있게 될까?

스마트 기기들이 동일한 언어로 말할 수 있게 된다고 할지라도 사물 인터넷에는 여전히 ‘무엇을 이야기 할지’에 대한 문제가 남는다.

업체, 개발자 그리고 사용자가 스마트 기기가 보편화된 미래를 향해 나아가는 것을 소위 사물 인터넷이라고 할 때, 그들은 사물인터넷 관련 핵심 이슈들을 산더미처럼 쏟아내기 시작했습니다. 이는 어떻게 사물인터넷에 연결된 다양한 기기들이 서로 대화하게 될까에 대한 질문에서 시작합니다.

그러나 설사 이 사물인터넷에서 기기들이 동일한 언어로 대화할 수 있도록 할 수 있게끔 한다 하더라도 실제로 이 세상에서 기기들이 서로 대화할 수 있게 만들 수 있는가에 대한 더 큰 도전에 직면하게 됩니다. 

말, 말, 말 그런데 할 말이 없다.

앞서 포스팅에서 대략 언급한 바와 같이, 사물인터넷은 기기들 사이의 대화를 위해 제조업체들이 만든 다량의 상호 호환성 없는 프로토콜들에 붙잡혀 있습니다. 

이런 프로토콜들은 각기 효율적이지만 서로 상이한 언어들이죠. 그 결과 인터넷에 연결된 기기들은 서로 대화하길 원함에도 불구하고 서로 대화할 수 없습니다.

이런 대화를 막는 방해물은 궁극적으로 기업 간의 의견 수렴을 통해 정의된 표준 프로토콜로 제거할 수 있습니다. 혹은 인터프리터 역할을 하는 집중된 “공통 지식”을 만듦으로써 상호 운용할 수 없는 다수의 기기들을 상호 대화할 수 있도록 만들 수 있습니다.

이 문제를 이렇게 가정해 봅시다. 이제 이런 스마트 기기들 – 스마트 폰, TV, 냉장고, 자동차, 시계, 스마트 의복과 이외 어떤 기기 – 가 무엇이든 간에 대화하게 될까요? 볼품 없는 질문 같지만 이런 단순한 예가 이 문제를 해결하기에 얼마나 교묘한지를 보여 줍니다. 

거실로 다시 초대합니다.

지난 포스팅에서 소개했던 네스트 온도조절기, 스파크 내장 조명 그리고 마키타 커튼 조절기로 이뤄진 스마트 거실에서의 상상 실험으로 돌아갑시다. 각각의 기기를 원격으로 제어하는 건 가능하기에 이를 위해 이런 기기들이 보유한 다양한 센서에서 값을 직접 읽어 들여 다른 기기에게 알려줄 수 있다고 가정해 봅시다. 

온도 조절기에서는 방 안 온도와 하루 중 원하는 온도에 대한 센서 값을 알려줄 수 있습니다. 조명기기는 주변의 기기에게 자신이 켜져 있는지 여부와 방안의 조도를 알려줄 수 있습니다. 커튼 조절기는 앞서 두 기기에 비해 상대적으로 부족하지만 커튼의 개, 폐 혹은 그 정도를 알려 줄 수 있겠네요.

그래서 온도 조절기는 열심히 센서 값을 조명기기와 커튼 조절기에게 알려주겠죠. 

여기서 첫 번째 질문입니다: 도대체 이 기기들이 고려하는 바가 무얼까요? 전 은하수를 여행하는 히치하이커를 위한 안내서에 나온 살인 경악이자 Paranoid Android인 마빈이 등장하자 the Heart of Gold을 향해 가는 문이 유쾌히 열리는 시나리오를 빗대어 상상하고 있습니다. 

커튼 조절기가 방안의 온도를 아는 것이 얼마나 중요한 지 알아야 하는지를 심각하게 고민해 봅시다. (지금껏 거의 고려해 본적이 없을 겁니다.) 조명기기도 유사합니다. 만일 조명기기가 지각 능력이 있다면 커튼에 불이 붙어 집이 전소하는 절망적인 상황에서 받을 과부하를 상상할 수 있습니다. 

물론 조명 기기들에게 지각 능력이 있다면 아마도 직관적으로 현재 시각과 온도가 기본적으로 규정된 온도 값에 비해 높다는 걸 인지하고 조명을 킬 것입니다. 문제는 기기에게 이런 ‘의미’를 넘겨 줄 수 있느냐겠죠.

거실의 지식 구조

스테판 웨이츠(Stefan Weitz) 그리고 맷 월레츠(Matt Wallaert)는 두 말할 것 없는 괴짜들입니다. 내가 그들에게 말을 걸었을 때는 최신 스타트렉 영화 개봉에 앞서 Bing(Bing) 검색 엔진에 클리곤(Klingon) 언어를 추가한 엔지니어들을 위한 기념회를 막 마쳤을 때였습니다. Bing에서 일하는 행동 과학자인 월레츠는 클리곤 언어의 관용구인 콰플라(Qapla') – 성공이라는 의미 – 를 머리 속에 새겨 넣었습니다. 

괴짜 항목에 이런 단어들을 추가하는 것은 그들의 스타트랙에 대한 애정뿐만은 아닙니다. 그들은 Bing과 보편적인 검색 엔진들의 미래에 대해 깊게 생각해 본 것입니다. 그들은 구글을 걷어 찰 미래에 대해 괘념치 않고 다른 다양한 것들을 상상하고 있습니다.

이런 친구들에게는 인터넷에 연결된 기기의 숫자가 증가한다는 것은 엄청난 데이터를 생성할 플랫폼을 의미하고 Bing 검색엔진과 이를 활용할 서비스들에게 큰 기회가 있다는 의미입니다. 

“어떤 형태의 제어 기기에서든 데이터를 제공할 수 있습니다”라고 마이크로소프트의 검색엔진 수석 이사인 웨이츠가 말했습니다. 

“어떤 기기의 어떤 신호나 어떤 입력이라도요.”  

실제 많은 정보를 산출하기에는 너무 잡음이 많아서 이런 건 진짜 불협화음처럼 들립니다. 그러나, Bing 엔지니어들은 이런 기기들이 더 많은 데이터를 만들어내기 위해 만드는 엄청난 잡음들을 제거하는 데 Bing 검색엔진이 중요한 역할을 할 수 있다고 봅니다.  

웨이츠와 월레츠는 의도적으로 스마트 거실 가설에 대해 반박합니다. 

온도 조절기가 이런 것들에 관심을 두도록 프로그래밍되었다는 가정한다면, 그들이 제안했던 바처럼, 온도 조절기는 날마다 방이 점점 더 더워지는 일정 시간을 기록할 것입니다.

평소대로라면 온도 조절계는 이런 종류의 이벤트에 대한 반응으로 에어컨을 켜거나 난로를 꺼는 동작을 취할 것입니다. 

그러나 웨이츠의 제안은 방이 하루 특정 시간에 더워지는 이유를 조사하도록 온도조절계를 프로그래밍할 수 있다는 것입니다.

이것은 기기들의 현재 설계가 어떻게 바뀌어야 할지에 대한 두드러진 변화가 될 것입니다. 

온도 변화를 받아 들이는 것으로 집안의 냉/난방기를 조절하는 건 시작에 불과합니다. 온도 조절기의 목표 변수들을 넘어서서 솔루션을 찾아야 합니다.

언젠가는 월레츠가 제안한 바와 같이, 온도 조절기가 햇빛이 창문을 통해 방안으로 쏟아지는 것과 동시에 온도가 올라간다는 것이 서로 관련이 있음을 알아야 할 것입니다. 그러면 (Bing과 같은) 인터넷 데이터 플랫폼을 통해 가능한 솔루션들을 검색할 수 있을 겁니다.   

그리고 나서 이런 솔루션들을 면밀히 검토해 보고 거기서 비현실적인 것들 – 예를 들어, 반 융합(anti-fusion) 기기로 태양에 핵 공격을 가하는 것 같은 – 을 제거하고 나면 올바른 것이 도출될 수 있을 겁니다. 

그러나 한 여름에 오후 2시부터 몇 시간 동안 커튼을 치는 건 어떤가요? 

이제 이게 하나의 방안이 되었습니다. 

결국, 온도조절기는 방 안의 두꺼운 커튼을 치라는 신호를 보낼 겁니다. 

조명기기는 방안의 조도가 낮아지는 것을 확인하고 방 안에 사람이 있을 경우에만 조명을 킬 겁니다.   

하나의 사례만 보더라도 꽤 직관적임을 알 수 있습니다. 왜냐하면 사람들은 이런 솔루션을 꽤 빨리 찾아낼 수 있기 때문이죠. 

그러나 잠시 멈춰 지금껏 일어났던 일들을 생각해 봅시다. 

사람들과 인터넷에 연결된 다른 기기로의 데이터와 정보를 이용해 볼 수도 없는 온도 조절기가 연동 가능한 다른 기기로 차단이 가능한 열원의 존재에 대해 배웠습니다. 

몹쓸 스마트 온도조절기 하나

그러면 된 것 아니냐고요? 이 온도조절기는 그 배후에 인터넷 자원이 있다고 하더라도 이 기기는 말도 안되게 복잡해야 합니다. 

독립적으로 대안을 찾고 지각에 대한 인터넷의 경계에 존재하는 지식으로부터 배워야 하는 능력  때문에 말입니다.

더 유사하게는 이 온도조절기의 프로그래밍은 다음과 같이 판단 호출을 만들기 위한 제약된 조건들을 고려해야 합니다. 

먼저 지역 날씨 데이터, 주변 조도 센서 값, 전력 소모량 (아마 누군가 원격 제어가 안 되는 난방기를 돌리고 있고 있을 수 있으니까요.) 그리고 아마도 (점유 기간을 측정하기 위한) 이산화탄소 농축도에 대한 정보를 수집해야 하고 그것을 통해 냉/난방 여부를 결정하는 데 쓸 것입니다. 

만일 햇볕 좋은 날에는 커튼을 칠 것이고 만일 방 안에 많은 사람들이 있다면 에어컨을 키고 커튼은 열어 놓을 겁니다.   

이렇게 즉각적인 결정을 내리기 위해 정보를 수집하도록 프로그래밍된 어떤 기기든지 인터넷에서 이와 관련된 상관관계를 만들 수 있도록 공개된 정보로 인해 이득을 얻을 수 있게 됩니다. 웨이츠에 따르면, 데이터 과학자들은 지식 패브릭(knowledge fabric) 혹은 융합 네트워크(mesh network)로써 이런 종류의 저장소를 참고합니다. 

“이런 저장소는 완전히 새로운 정보 구조가 될 것입니다.”

웰레츠가 첨언하기를 “사물을 위한 바벨 피쉬” 처럼 동작할 데이터 변역 서비스입니다. 

변화를 가져올 정보가 필요한 기기들은 자신의 프로그래밍에 기반하여 지식 패브릭에 접속해 이에 따라 제어를 조정하게 될 것입니다.  

Bing 엔지니어로써, 지식 패브릭을 생성하는 것은 최고의 검색 결과를 찾는 것보다 원대한 목표를 의미합니다. 

웰레츠는 구글과는 다르게 Bing은 “현상을 이해하는 계층(layer)을 만드는 것”이라고 주창합니다. 

이로써 Bing은 단순히 검색 결과 대신 데이터에 행위(action)을 적용하는 기술로써 자리매김할 것입니다.

이것이 바로 사물 인터넷이 동작하게 하는 기술입니다.

명령과 제어

Zonoff의 CEO인 마이크 해리스에게 사물인터넷에 대한 개인적 견해에 대해 물었더니 그는 몇 가지 반대 의견들을 조심스레 꺼냈습니다. 

그 첫 번째로 해리스는 스마트 기기 제조업체들 간 경쟁의 합의로 하나의 지식 패브릭을 사용하기로 한다는 것을 상상하기 힘들다고 합니다. 

그들이 누구든지 기업 간 경쟁에서 경쟁 우위의 업체들은 합의를 깨뜨릴 가능성이 높습니다. 

해리스는 “현실에는 많은 수의 기업들이 ‘그들의 데이터를 소유’하고자 한다”고 말합니다.” 

그리고 그 결과에 따른 마찰은 Bing 팀이 말했던 것 같은 기술적 진보를 방해할 가능성이 있습니다.

그러나, 해리스는 사물인터넷은 어쨌든 진보할 것이라고 보았습니다. 

다양한 가전 업체들의 제품을 제어하는 스마트 홈 오토메이션 기기 업체로써 스마트 홈 영역에서 중요한 역할을 하는 Zonoff를 찾았을 때처럼 놀라운 소식은 아니겠지만요.

해리스는 기계 학습을 통한 지식 패브릭의 개념은 흥미롭지만 지금으로써는 보다 실제적인 접근법을 통해 회사를 이끌고 있다고 합니다: 홈 오토메이션 기기들을 위한 중앙 형 명령/제어 시스템을 다루는 소프트웨어 플랫폼을 만드는 것이죠. 

해리스가 Zonoff의 홈 제어 시스템을 설명하는데 사용한 비유는 Bing 팀이 Bing을 가정의 두뇌로 사용하는 것과 크게 다르지는 않습니다. 

Wi-Fi 혹은 Z-Wave (홈 오토메이션을 위해 설계된 저 대역 주파수) 표준을 통해 기기들을 네트워크에 연결하고 프로토콜을 정렬해서 관련 명령과 응답을 조율합니다.

후자는 지금껏 출시된 기기의 종류와 그 기기 간의 조합 가능성을 생각해 보면 엄청난 일이 아닐 수 없습니다. 

그럼에도 여기 약간의 영리함이 있습니다: Zonoff 시스템은 기술적 지식이 없는 집주인들이 스마트 기기를 손쉽게 프로그래밍할 수 있는데 기기를 추가 설치한 후 환경 설정을 향상할 수 있도록 보다 학습된 피드백을 사용자에게 제공하기 위해 기기 실제 사용 빈도를 모니터링합니다.

데이터 분석과 크라우드 소싱 데이터가 조합하면, 예를 들어 문을 잠그고 알람을 켜고 가전 기기들을 절약 모드로 바꾸는 “잘 자” 명령 생성이 가능합니다.

이런 시스템은 심지어 집주인의 생활 습관 – 아이들이 있나요? 애완동물은요? - 에 대해 질의해서 홈 오토메이션 시스템에 더 나은 피드백을 반영할 수 있는 관련 규칙을 적용할 수 있습니다.   

스카이넷이 도래하는가?

사물인터넷을 향한 “지식 패브릭”에 까지는 도달하지 못했다고 하더라도 Zonoff 같은 컨트롤 허브들은 이미 출시되었고 머지 않은 미래에는 홈 오토메이션 시장에서 독점하리라고 보입니다.

그러나 기계 학습을 통한 지식 패브릭에 대한 비전은 주목하지 않을 수 없습니다. 기계가 많은 것을 배우지 못했던 오랫동안 이 기술은 이 지구 상의 인간들과 관련된 반쯤만 탁월한 아이디어들을 만들어 냈습니다.

이런 연유로 이 기술을 물리쳐서는 안되나 이를 위해 해결해야 할 기술적 문제가 많다는 것은 인정해야 합니다. 

경제학자 안드류 맥아피가 최근 TED 강의에서 냉소적으로 말했던 것처럼요:

기계가 스스로 인지하게 되고 우리를 대적하여 반란을 일으키도록 결정하면서 일어나는 상황에 대한 디스토피아적인 예측은 끊임이 없습니다. 저는 이런 미래를 컴퓨터가 프린터를 인식하기 시작하면서부터 우려하기 시작했습니다.

안녕하세요.

"생각의 웹"입니다.

앞서 '사물인터넷을 지탱하는 것' 이라는 포스팅에서 다음과 같이 레인할트의 말을 인용한 바 있습니다.

"모든 기술이 정의되지 않은 상태이고 사물 인터넷에 대해 개똥 철학과 전문 용어들만이 난무할 뿐이다."

따라서 이번 포스팅에서는 사물 인터넷 기술을 정의하기 위해 인텔과 삼성이 주도하고 있는 Open Interconnect Consortium (이하 OIC) 에 대해 소개드릴까 합니다. 

먼저, OIC의 비전 영상을 하나 공유합니다.

지금까지 사물인터넷에 대해 관심을 가지고 지켜 보신 분들에게는 뻔한 시나리오겠지만 기술을 만드는 것보다 실 생활에 실현하는 것이 더 가치있는 일이 아닐 수 없기에 OIC의 비전을 과소 평가하기는 섣부를 수 있다고 생각합니다. 단, OIC라는 이름과 걸맞지 않게 공식 사이트인 http://openinterconnect.org/ 에서 관련 상세 정보를 일반인(?)들은 볼 수 없다는 점이 매우 아쉽습니다. (먼저, 다짜고자 멤버쉽부터 가입하라는데 과연 이를 너그러히 받아들일 사람 (단체 말고)은 얼마나 될까요? :-( )

따라서, 지난 9월 16~7일 개최한 삼성 오픈소스 컨퍼런스 (Samsung Open Source CONferernce - SOSCON) 에서 OIC에 관해 공개된 내용을 이 포스팅을 통해 소개드리고자 합니다.

OIC에 대해서는 인텔 측과 삼성 측에서 각각 한 세션 씩 두 번 발표했기에 두 세션을 나누어 공유합니다.

첫번째, 인텔의 David G Brenner가 발표한 내용입니다.

발표 자료:  http://soscon.net/file/(4)SOSCON_1day_tr2-4.pdf

다음은 제가 요약한 발표 내용입니다. (대부분 발표 자료에 기록된 내용이지만 요약 차원에서 도움이 되길 바라며 공유합니다. ;-) )

Complex Ecosystem requires Simplicity

- N dimension problem :

  : There is no single OS, standard, radio tech. -> very complex now -> need common framework!

Challangings 

- Unboxing & provisioning 

- Device/User Identity & Grouping 

- Discovery

- Connectivity

Create Single common Interoperable solution

- OIC will deliver Specification

- Open source reference implementation

- interoperability compliance

- build on existing standards (WiFi, bluetooth, ...)

OIC covers

- protocols for discovery and connectivity across multiple D2D (device to device) transports

- security and identity

- service-level protocols

Core Tech.

- Intel Common Connectivity Framework Concept.

  : identity (as a key in managing security)

  : discovery (abstract and aggregate radio specific tech.)

  : connection initiation and control (invitation/responder process, socket )

How developers can participate with OIC?

- Git clone code at OIC web site & contribute it

- Join as a member

- Lead work group

두 번째는 삼성전자 정진국 수석이 발표한 내용입니다.

발표자료: http://soscon.net/file/(5)SOSCON_1day_tr2-5.pdf

IoT 정의들의 공통점

- Identification

- Connection

- Communication

사물의 99%는 여전히 연결되지 않음.

IoT is Son of Internet 

- key is 'INTER'. and 'OPEN' to connect billions of devices

- "Open source & Standard" two track community 

OIC 철학

- Resource oriented architecture (based on the Principle of RESTful arch.)

- Web을 IoT에 확장 적용하는 개념 (CRUD & N (push) operation)

인텔은 CCF (Common Connectivity Framework), 삼성은 TGM (Things Graph Manager), SSM (Soft Sensor Manager), NM (notification manager)로 OIC 기여

- TGM: 기기 그룹화, 동시 제어 등을 제공

- SSM: 센서 데이터 저장 및 특정 상황에 따라 알람. 개발자의 편의를 위해 센서의 위치, 종류와 상관없이 추상화 제공

- NM: notification broker로 고사양 기기(스마트폰)을 이용

legacy,  proprietary plugin 지원을 위한 binary  plugin (*.so) 지원하는 architecture 

발표하신 정 수석님은 다음과 같이 한 줄로 OIC를 요약했습니다.

OIC는 connection among various things의 첫 걸음!

마지막으로 OIC에 대한 제 의견입니다.

첫 번째,'열기 상호 컨소시엄' 이라는 제목에 걸맞게 (저 번역은 제가 임의로 한게 아닙니다.  -_-;;  SOSCON 자료에 의거한 제목입니다.) 좀 더 열린 자세로 표준화에 임하면 어떨까 싶습니다.

아래 컨소시엄 마일스톤을 보면 빠르게 1.0을 공개하고 이후 의견을 수렴하겠다는 (사실은 표준을 주도하겠다는 뜻으로 봐야 겠지요.) 모습이 역력합니다. 이는 표준이 가져야 할 제 1 덕목인 합의성을 약화시켜 멤버쉽에 가입한 기업들조차도 OIC 표준을 기반으로 상품화 하겠다는 동기를 갖지 못합니다. 물론 퀄컴 등이 주도하는 Allseen Alliance보다 시작이 늦었기 때문에 급한 마음이 들겠지만 그럴수록 진정성을 갖춘 열린 표준으로 경쟁력을 갖춤으로써 차별화해야 할 것으로 보입니다.

지난 25년 간 웹의 성장이 보여주듯 개방과 공유를 통한 혁신은 몇몇 글로벌 업체들의 '주도한' (이라고 쓰고 '말로 만'이라고 읽습니다.) 혁신보다 인류 사회의 발전에 기여한 바가 큽니다. 이는 권력의 집중은 기술의 요구사항이 특권 계층의 필요에만 머무르게 되고 반면 다수를 차지하는 계층의 요구는 외면하게 됨으로써 필연적으로 변화의 속도를 더디게 만들기 때문이 아닌가 싶습니다. 

사물 인터넷을 통해 꿈꾸는 초 연결 사회는 (인종과 국적 및 취향이 다른) 사람들 뿐 아니라 (제조 사와 제품의 스펙, 가격 등이 다른) 사물들이 함께 어우러져 운용될 수 있는 기반에 대한 합의가 우선되어야 합니다. 

두 번째, 일정 상으로는 preview나 spec 0.5에 관련된 내용이 내부 릴리즈 된 것으로 보이나 앞서 말씀드린 바와 같이 일반 개발자에게는 공개되지 않았습니다.

따라서, 인텔이 이미 공개한 CCF (Common Connectivity Framework)를 통해 기술적 상세를 살펴 볼 수 있을 듯 한데 관련 사이트에 가보면 SDK를 받기 위해 CCF Developer Program에 동의가 필요합니다. 굳이 SDK를 다운로드 하지 않더라도 안드로이드에서 CCF 이용해 구현하기 같은 기사가 있어 살펴 보니 SDK라기 보다는 라이브러리 정도의 지원으로 보입니다. 성급한 판단이지만 이런 기술적 장벽을 추상화해서 개발자들이 손쉽게 진입하는 노력이 지속되어야 할 듯 싶습니다.

이후 OIC 외의 다른 사물인터넷 표준화 단체들의 진행 방향에 대해서도 살펴 볼 계획이지만 부디 엔지니어링 이슈에 대한 논쟁이나 옹졸한 비즈니스 정책 때문에 미래를 여는 기회를 스스로 차 버리는 오류를 범하지 않기를 바랍니다.

지금껏 읽어 주셔서 감사합니다.

행복한 하루 되시길!         

안녕하세요.

"생각의 웹"입니다.

사물인터넷에 대해 여러분들과 보다 적극적으로 소통하고자 하는 목적으로 (라고 쓰고 박인효님의 제안으로 라고 읽습니다.)
페이스 북에 팬 페이지를 개설했습니다.

https://www.facebook.com/doiotyourself 

부담없이 강연 및 소스 관련해서 궁금하신 점이나 사용 상 문제가 있는 부분 혹은 개선해야 할 점을 이곳에 공유해 주시면 지속적으로 발전시켜 나가도록 하겠습니다.

감사합니다.

행복한 하루 되시길!  

안녕하세요, 

'생각의 웹'입니다.

앞서 포스팅한 강연들의 결과물로써 만든 서비스를 아래 github에 MIT 라이센스 조건 하에 공개합니다.

(MIT 라이센스는 출처만 명확히 밝히시는 조건으로 마음껏 사용할 수 있습니다.) 

https://github.com/hyunghunny/DIoTY

• 설치 가이드
• 자주 나온 질문들

이 서비스가 제공하는 기능은 다음과 같습니다.

• 1. 현재 온도 측정 (My thermometer)
• 2. 지금까지 측정한 모든 온도 데이터를 line chart로 도식화 (Temperature Trend)
• 3. JavaScript API 문서
• 4. TypeScript API 구현체
• 5. JavaScript API 구현체

이 서비스에 대한 스크린 샷은 다음과 같습니다.

이전다음

012345

이상입니다. 

감사합니다.

안녕하세요,

"생각의 웹"입니다.

오늘 저녁 강연을 마지막으로 예정된 사물 인터넷 만들기 과정의 마무리를 합니다.

사실 스스로도 강연을 통해 어떤 메세지를 던져야 하는가에 대해 고민이 많았던 중에 아래 블로그 포스팅에서 영감을 받아 에필로그 삼아 번역하여 공유합니다.

오역의 소지가 다분하니 보다 올바른 의미를 느끼고픈 분들은 아래 원문을 참고하시기 바랍니다.

http://readwrite.com/2013/06/14/whats-holding-up-the-internet-of-things    

사물 인터넷을 지탱하는 것

- 문제는 사실 상  우리가 스마트 기기들 간의 대화에 대해서는 전혀 알지 못한다는 것.

사물인터넷 – 일용품들이 똑똑해지고 연결되면서 다양한 새로운 서비스들을 만들 수 있는 – 이 교통 체증, 환경 문제 등을 해결하는 스마트 시티로의 발전에 대한 청사진을 제시합니다. 문제는 많은 과학 기술자들이나 신 기술 추종자들이 사물 인터넷에 대해 떠벌리고 일부 이미 제품 화된 것들이 있다고 해도 진정한 의미의 사물 인터넷은 존재하지 않는다는 겁니다.
확실히 데이터를 수집해서 다른 기기에게 전송하는 스마트 기기들 – 예를 들면 가정용 경보기, 카메라, 난방 센서와 비중계 같은 - 이 시장에 많이 존재합니다.
 그러나 아마 이미 알고 있겠지만 냉장고가 우유가 떨어진 걸 인식하고 자동으로 주문을 한다거나, 슈트케이스가 스스로 일정표를 확인해서 출장 건이 있으면 이에 맞는 여벌의 옷이 준비되었는지를 확인하는 등의 시나리오가 가능하게 되려면 한참은 더 기다려야 합니다.
 여기에 그 이유가 있습니다.

공용어가 존재하지 않는다.

기본적으로 인터넷은 어떤 기기와 다른 기기 간을 연결해주는 네트워크에 지나지 않습니다.
이런 연결만으로는, 이런 기기들이 서로 어떻게 대화할 지를 알게 될 것이라는 걸 의미한다 할지라도, 기기 간에 무언가를 말하게 될 것에 비하면 터무니 없이 부족합니다.
언젠가 기기 간에 대화할 수 있을 때가 된다면 이는 일반적으로 하나 혹은 이상의 ‘프로토콜’ 혹은 특정한 작업을 다루기 위한 전문화된 언어를 통해 이뤄질 것입니다.
그 중 인터넷에서 가장 유명한 프로토콜인 HTTP (하이퍼텍스트 전송 프로토콜) – 브라우저 주소 창에서 “http://”으로 시작되는 걸 봤다면 바로 그것입니다. – 은 한 번쯤은 들어봤을 겁니다.
HTTP는 컴퓨터로 다양한 파일들과 이미지 그리고 비디오를 웹을 통해 다른 컴퓨터에게 전송할 수 있게 해 줍니다.
 HTTP외에도 e-mail 전송을 위해 SMTP, POP 그리고 IMAP과 같은 프로토콜을 사용한다거나, 파일 전송을 위해 FTP프로토콜을 사용하는 것처럼 특정한 통신 목적에 따라 다양한 프로토콜들이 사용되고 있습니다.
이런 특정한 목적의 프로토콜은 일반적으로 잘 동작해 왔고 웹이 시작된 이후로 메일, FTP 서버는 보통 상호 간에 통신할 일이 거의 없었습니다. (만일 그런 일들이 필요하다면 단순 변환 S/W가 이 역할을 하겠죠.)
웹이 진화한 것처럼, 여러 개의 단순하고 안정화된 특정 목적의 프로토콜을 사용하는 것이 이런 프로토콜들을 묶어서 보다 복잡한 프로토콜로 만드는 것보다 유지하기 쉬웠습니다. 여기서부터 문제가 보일 겁니다. 사물 인터넷 상의 기기들은 아마 다양한 임무들을 수행해야 할 것이며 이를 위해 사용하는 프로토콜에 대해 합의가 전혀 없습니다. 즉 다른 말로 표현하면, 여기서부터는 대화가 안됩니다. 

클라우드 관리 시스템 스타트업 회사인 레이어 7의 제품 아키텍트인 홀거 레인할트(Holger Reinhardt)는 “모든 기술이 정의되지 않은 상태이고 사물 인터넷에 대해 개똥 철학과 전문 용어들만이 난무할 뿐이다.” 라고 말합니다.

하나의 바벨 탑

그러므로 오늘날의 초기 사물 인터넷 기기들은 사물간 직접 대화하는 것보다는 관련 개발자나 회사에 의해 제어되는 중앙 서버와 주로 대화하게 됩니다. 이는 고리타분한 방식으로 현재로써는 잘 동작하겠지만 상호간 완벽히 대화할 수 있는 기기들로만 이뤄진 분할된 여러 서브네트워크로 이끌 것이고 결국 사실 상 다른 서브 네트워크의 기기들과는 대화할 수 없게 만들 겁니다.

포드 포커스라는 차량을 예로 들죠. 이 차량은 인터넷을 통해 포드 서비스나 데이터 센터로 자신의 데이터를 보내서 완벽하게 대화할 수 있습니다.
만일 부품 교체가 필요하다면, 이 차량의 시스템이 대신 차량 소유주에게 통보하는 포드 서비스에 보고하게 됩니다. 

 그런데 주행 중 발생한 실시간 위급 상황에 대해 경고를 전파해 주고 싶다고 해봅시다.
당신이 타고 있는 포드 자동차는 다른 포드 자동차에게만 대화할 수 있도록 만들어져 있기에 주변의 혼다, 포르쉐, 테슬라 차량에게는 전파하지 못할 겁니다.
왜냐하면 이 차량은 공용어로 대화할 수 없기 때문이죠.
따라서, 예를 들어 어떤 멍청한 녀석이 90 마일 이상의 속도로 차를 몰아 아직 건설 중인 도로를 향해 달려가고 있을 때 데이지 체인(daisy-chain) 경고를 알려 주기 힘듭니다.
 이런 문제들 중의 일부는 단순히 네트워크 구조에 관한 것입니다. 즉 기기들 간에 어떤 통신 방식 – 블루투스, NFC 등- 으로 대화할 지에 관련된 것입니다.
이런 문제는 상대적으로 쉽게 바꿀 수 있습니다. 

반면 프로토콜 이슈는 사물 인터넷에 대한 직접적인 방해물이 됩니다.
왜냐하면 그 기기를 보유한 특정 업체들 간에서만 대화 가능한 사일로(silo) 형태의 기기들 때문에 인터넷을 만들지 못할 겁니다.
(단순히 사물 컴퓨서브(CompuServe) 혹은 캐치(Catchy)로 끝나겠죠. 아닐까요?)

너무나 다양한 방언들

이제 심지어 경쟁이 치열한 차량 메이커 업체 사이에서도 사업 상 유익함 때문에 하나의 공용 데이터 프로토콜이 필요하다고 인식하게 될 겁니다.
그렇다고 해서 프로토콜 문제가 해결된 것이 아닙니다.
이것은 단지 모든 신규 차량이 포함되는 큰 사일로(silo)를 만든 것 뿐이죠.
여전히 엄청난 양의 차량과 대화하고 싶으나 대화 할 수 없는 다른 종류의 기기들 (말하자면 톨 게이트의 요금 징수기부터 가스 펌프 같은)이 있습니다.
이런 기기들은 서로 다른 기기들은 알아 들을 수 없는 방언으로 대화 합니다.

인터넷에 연결된 세 가지 기기들 - 네스트(Nest) 자동 온도 조절기, 스파크 내장 조명, 마키타(Makita) 자동 커튼 조절기 - 로 이뤄진 스마트 거실 사례를 들어 좀 더 상세히 살펴 보죠.
 각각의 기기들은 데이터를 수집해서 제조사에게 보내어 그 결과 아주 제한된 동작만을 할 수 있습니다.
만일 방이 너무 덥다면 네스트는 곧 에어컨을 가동 시킬 겁니다.
또 만일 밖이 어둡다면 마키타 제어기는 커튼을 닫을 겁니다.
만일 누군가가 방안에 있고 충분히 어둡다면 스파크는 조명을 켤 수 있습니다.

혹시 일어나지 않는 것이 무엇인지 아시겠어요?
네스트, 스파크, 마키타는 서로 대화할 수 없습니다.
따라서 최선은 허브 형태의 가전 제어 시스템을 통해 이 기기들을 제어하는 겁니다.
그러나 이런 컨트롤러도 종종 가정용 TV 만능 리모컨의 설치 과정에서 발생했던 동일한 문제에 사로잡히게 됩니다.
이런 기기들이 인터넷에 연결되었는지 여부는 중요치 않습니다.
온라인이라 함은 오직 기기들 각각을 여러분의 스마트폰으로 제어할 수 있다는 의미에 불과하니까요.

엔니지어들의 범람을 탓할 수도 있겠습니다.
새로운 기술들이 표준을 채택하는 대신에 그들만의 방식을 추구하는 개발자들 사이에서 황야의 무법자 같은 태도를 불러일으키고 있으니까요.
그 결과 기기 간 대화를 위한 미친 듯이 많은 프로토콜들 – IBM의 MQTT, OMG의 AMQP 기반 DDS, RESTful HTTP, XMPP, CoAP, NanoIP 그리고 SSL - 을 보유하게 되었습니다.

솔직히, 몇 가지 다른 프로토콜 방언들이 존재하는 이유가 있습니다.
HTTP 같은 경우는 실시간 요청-응답이라는 양 방향 웹 통신 형식의 웹 서버에서 잘 동작합니다.
사물 인터넷 상의 모든 기기들이 기기 간 대화를 위해 존재하지는 않을 겁니다.
베터리로 동작하거나 신호가 불규칙하거나 약한 곳에서 동작하는 기기들은 실시간 HTTP 요청을 항상 응답할 수 없습니다.
이것이 바로 다른 프로토콜들 – 예로 하나 들면 기회가 있을 때 하나의 기기에서 다른 기기로 메시지를 전달하는 – 을 의지하려는 이유지요.
(여기에 예를 들어 MQTT가 포함된 PubSub 류의 프로토콜이 있습니다.)
여전히 이런 방언들이 사물 인터넷에 대한 새로운 도전이 되고 있습니다.

우리에게 돈을 주세요

진짜 연결된 사물 인터넷이 동작하게 만드는 유일한 방법은 레이어7의 레인할트와 같은 전문가의 언급처럼 기기 제조업체들에게 경제적 인센티브를 통해 그들이 만든 기기의 제어권과 기기가 생성한 데이터에 대한 접근권을 공유하도록 하는 것입니다.

유의미한 방법을 통해 스마트 기기간 대화할 수 있도록 하려면 엄청난 노력이 들 겁니다. 

레인할트는 공원의 스마트 쓰레기 통을 예로 듭니다.
만일 쓰레기 수거업체가 쓰레기 통에서 데이터를 받고자 할 때 (예를 들어, 통이 가득 찼는지 등) 쓰레기 통 제조업체는 먼저 수거 업체의 시스템과 쓰레기 통이 통신할 수 있는지 확인해야 합니다.
그 후, 쓰레기 통의 데이터를 접근할 수 있는 허가권을 수거 업체에게 요청해야 합니다.

오늘날에는 이 첫 번째 단계에서도 많은 시간 소요와 어려움이 많이 발생합니다.
결국 이런 비용이 쓰레기 통 소유자가 얼마나 자주 이런 과정을 무시하게끔 하는 트집거리가 됩니다.
또한 이는 쓰레기통 자체보다는 근무자들이 언제 통을 수거해야 하는지 결정하기 원하는 수거 업체로부터 해당 데이터를 얻기 힘들게 만듭니다.

이제 쓰레기 통이 쓰레기 수거 업체의 시스템과 별도로 통신할 수 있다고 가정해 봅시다.
그러면 쓰레기 통 제조업체들은 통의 버튼만 누르면 그 데이터를 누구에게나 손쉽게 전송할 수 있도록 만들 수 있습니다.
데이터 공유를 가능케 하는 절차를 쉽게 복제할 수 있다면 기기 제조업체들은 수익 추구를 위해 데이터를 공유하는데 더욱 관심을 보일 겁니다.

연결된 사일로냐 섬들의 인터넷이냐?

궁극적으로 사물인터넷은 둘 중 하나의 모습을 취하게 될 것입니다.
현재의 경향이 지속된다면 앞서 스마트 홈 사례에서 보듯 기기에서의 혹은 기기로의 데이터는 집중화된 사일로 내에 갇힐 것입니다.
결국 회사들과 업체들이 이런 사일로들을 연결하게 될 것이고 프로토콜 간의 차이를 서로 상이하게 다듬게 되겠죠.
그러면 경제적 인센티브 역시 줄줄이 일어날 겁니다.

그러나 데이터는 보다 훨씬 공유하기 힘든 형태로 남을 것이며 사일로 간의 연결을 새로 만드는데 주어진 필요만큼만 공유될 겁니다.
이런 형태는 데이터 획득을 위해 데이터는 훨씬 먼 거리를 여행해야 하고 허브에서는 혼잡을 발생시킬 수 있으므로 서비스를 지연시킬 겁니다. 
그리고 집중화된 데이터는 보안과 사생활에 관련된 우려를 일으킬 겁니다.
여전히 이런 배치가 지금 상태보다 진정한 사물인터넷에 가까울지도 모르겠습니다.

이에 반해 강력하면서 보다 보편적으로 쓰이는 프로토콜을 사물 인터넷 기기에 사용하는 것으로써 레인할트의 표현을 빌려 속칭 “섬들의 인터넷”을 만들어 낼 수 있습니다.
방 안의 기기들은 서로 직접 대화할 수 있게 되고 이런 식으로 집과 이웃집 사이에서 대화가 가능합니다.
데이터는 이런 작은 영역에서 머무르게 되며 서비스는 빨라지고 사생활은 강화될 것입니다.

이 후자 형태의 네트워크는 보다 유연하고 반응적인 사물인터넷을 의미합니다.
서로 다른 기기들과 자유롭게 대화하는 다양한 기기들을 허용한다면 자동화된 시스템이 이 세계 속에서 무슨 일들이 벌어지는 지 학습해서 사람의 필요에 맞도록 순응합니다.

현재의 나쁜 기술 경향과 근시안적인 경제 정책이 사물인터넷을 올바른 방향으로 이끌지 못하고 있습니다.

안녕하세요,

'생각의 웹'입니다.

4주 차에 걸쳐 진행된 직접 IoT 만들기(Do IoT Yourself!) App In 세미나가 이번 주 금요일(2014년 10월 24일)을 마지막으로 대장정의 마무리를 내립니다.

짧지 않은 시간동안 평일 저녁과 주말을 포함해 여러 회에 걸쳐 진행된 강연이였기에 참석조차 쉽지 않으셨을 텐데 빠지지 않고 참석해 주신 분들께 감사드립니다.

강사 또한 참석자 분들의 배움의 열정에 감탄을 금치 못했으며 가르침을 통해 배움 못지 않은 많은 깨달음을 얻었습니다. 

• 1주차 - IoT, 기술의 혁신과 미래 그리고 통찰
• 2주차 - Intuitive Understanding of Arduino for IoT
• 3주차 - 사물 간 연결을 위한 Open API

이번 마지막 강연에서는 지난 3주 차 강연에서 만들어 본 RESTful Web API를 손쉽게 사용할 수 있도록 JavaScript API로 만들어 보고 이 API를 이용해서 현재 온도를 알려주는 온도계와 지금까지의 온도 변화를 보여주는 경향(trend) 그래프(graph)를 google chart API를 이용해 만들어 봅니다.

지난 번 강의 시, 제가 시간 관리를 제대로 하지 못해 다음 예정된 강의에 지장을 초래할 정도로 지연되었는데 

부디 이번 강의에서는 제 시간에 끝났으면 합니다.

(그런데 초안 슬라이드를 작성해 보니 2시간 내에 제대로 다루기에는 벅찬 느낌이 들기도 하네요. ^^;; )

마지막으로 다시 한번 매 강연마다 호평을 아끼지 않으시고 적극적으로 참여해주신 참석자 분들께 다시 한번 감사의 말씀 전합니다.

또한 강연 자리를 마련해 주시고 값 비싼 아두이노 호환 보드 세트를 원가에 못 미치는 가격에 참석자 분들께 제공해 주신 AppCenter 분들께도 감사드립니다.

제 소망은 초 연결 미래 사회를 향한 이 작은 발걸음들을 통해 새로운 통찰을 얻고 비즈니스에 적용하여 미래를 만들어 가는 분들이 등장하는 것입니다.

사물 인터넷의 시대, 여러분들의 아이디어를 직접 만들어 평가하고 공개하고 개선해서 멋진 서비스로 발전시켜 가시길 바랍니다!

P.S. 이 모든 자료는 크리에이티브 커먼스(Creative Commons) 3.0에 의거하여 출처를 밝히는 조건 하에서 자유롭게 사용하실 수 있습니다. 

P.S. 2. github에 공개한 DIoTY 코드에 대한 설치 가이드와 자주 나온 질문들을 링크와 같이 정리했습니다. 참고하시기 바랍니다.

안녕하세요, 

생각의 웹입니다.

지난 2번의 Do IoT Yourself 세미나에 이어 오는 10월 18일에 발표할 세 번째 강연의 슬라이드를 아래와 같이 선 공개 합니다.

혹시 참석하지 못하신 블로거 분들은 지난 세미나 관련 정보를 아래 링크를 통해 확인하실 수 있습니다.

• IoT, 기술의 혁신과 미래 그리고 통찰
• Intuitive Understanding of Arduino for IoT

이번 강의에서 다룰 내용은 웹을 구성하는 기술들에 대한 배경 지식과 개념들이 필요하기 때문에 이 분야에 경험이 전무하신 분들에게 조금 난해할 수 있겠다는 생각을 합니다. (특히 프로그래밍 경험이 전무한 비전공자 분들에게는요.)

이 자료의 초기 버전 (initial draft version)을 지인에게 공유했을 때에도 이해하기 힘들다는 피드백이 있어 개념을 전달하기 위해 몇 장의 슬라이드를 추가 보강했습니다.

혹시 자료를 보시고 난해한 부분이 있다면 댓글로 의견 주시면 추가 반영하여 보다 이해하기 쉽도록 개선하겠습니다.

(강의 중 Q&A 로 슬라이드에 잘 표현되지 않은 부분이 있다는 의견이 있어 추가 반영한 버전으로 슬라이드를 교체했습니다. ;-) )

짧은 시간에 내용을 제대로 전달하는데 무리가 있을 것 같은 우려에도 불구하고 이 내용을 포함시키고자 하는 이유는 이것이 사물 인터넷의 핵심 중 하나이기 때문입니다.

많은 미래학자들이나 관련 연구를 하시는 오피니언 리더 분들의 의견을 들어보면 사물 인터넷은 '사물'이 아닌 '인터넷'에 주안점을 두어야 하기에 특히, 다양한 사물 간의 대화를 가능케 하는 표준화된 인터페이스(interface)와 API의 중요성을 강조합니다.

History Does Not Repeat Itself, But It Rhyme

역사는 스스로 반복되지 않지만 운율이 있다는 뜻입니다.

이 격언을 인용한 이유는 인터넷을 보급한 핵심 서비스는 다름 아닌 웹이였고 웹의 HTTP, URL, HTML 세가지 기술은 전 세계 사람들을 연결하는 데 그 역할을 훌륭히 해 냈습니다. 따라서 사 반세기를 통해 검증되고 보급된 이 웹 기술들이 이제는 그 운율이 되어 사물 간, 그리고 만물 간의 인터넷에도 적용될 것이라는 기대와 확신이 저에게는 있습니다.

또한 여기서 설명하고 있는 RESTful Web API는 웹 서비스를 위해 도입된 다소 무겁고 폐쇄적인 WS-* 기술이 아닌 기존의 HTTP만으로도 웹 서비스가 가능하도록 만든 API 설계 원칙이고 이런 하위 호환성의 장점을 기반으로 사람 뿐 아니라 기계가 이해하고 사용할 수 있는 형태의 hypermedia API로 진화하는 중에 있기에 그 미래가 밝다라고 봅니다.

REST API에 대한 보다 기술적이고 자세한 내용이 궁금하신 분들은 이 블로그의 다음 포스팅을 참고하시기 바랍니다.

• [공유] REST API 이해와 설계 - 조대협의 블로그
• RESTful Web API 설계 절차 - RESTful Web API에서 발췌

가진 지식을 나누며 생각을 키워 가는 것이 참 즐거운 일임을 오프라인 세미나를 통해서 다시 깨닫습니다.
온라인에서도 다양한 블로거 분들과 즐겁게 소통하며 함께 성장해 나가길 기대합니다.

읽어 주시고 관심가져 주셔서 감사합니다.

행복한 하루 되시길!

P.S. github의 DIoTY 프로젝트에 대한 설치 가이드 와 자주 나온 질문들을 위키 페이지로 정리했습니다. 참고하시기 바랍니다.