안녕하세요. 

"생각의 웹"입니다.


지난 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 하시면서 비용도 줄이고 건강도 챙기는 일석이조의 효과 얻기를 바랍니다.

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


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


  1. 파이팅건맨 2014.11.28 22:56 신고

    오울, 좋아요!

  2. 2015.01.01 12:12

    비밀댓글입니다

    • 생각의 웹 WebofThink 2015.01.01 13:10 신고

      반갑습니다. 아내되시는 분이 비염이 심하다고 하시니 처음 뵙고도 공감대가 형성되네요. 궁금하신 구현은 남겨주신 연락처로 회신드릴께요. 새해 복 많이 받으세요 ^^

  3. 2015.01.07 14:27

    비밀댓글입니다

    • 생각의 웹 WebofThink 2015.01.07 14:30 신고

      안녕하세요. 블로그를 살펴보시면 구현 방법과 코드 등이 상세히 설명되어 있는 편(?)입니다. 살펴 보시고 추가 질의하실 부분이 있다면 webofthink@tistory.com 혹은 페이스북/doiotyourself 에 남겨주세요 ^^

"생각의 웹"입니다.


지난 Do IoT Yourself 강연 시 가장 널리 알려진 MySQL를 이용해서 data logging를 했으나 

프로그래밍에 문외한인 분들에게 교육하기 어려운 점과 

MySQL과 같은 RDMS (관계형 데이터 베이스 시스템)과 JavaScript의 궁합이 썩 맞지 않는 면들이 있었습니다.

불편한 점들을 나열하면 다음과 같습니다.


- MySQL 설치가 까다롭다.

- database를 설정하고 schema를 만드는 과정에서 실수하기 쉽다. (error-prone)

- JavaScript 객체 (JSON)의 속성들을 일일히 DB 스키마에 맞춰 저장한 뒤 읽어 들일 때 JSON 객체로 만들어 주는 과정이 필요하다.

- JavaScript Date 객체와 DB의 Date 객체는 호환되지 않는다.

 


따라서, NoSQL 중 하나인 mongoDB를 대안으로 사용하기로 결정했습니다. 그 이유는 다음과 같습니다.


- database를 설정하고 schema를 만드는 과정이 필요 없다.

- JSON 객체로 저장하고 읽어 들인다.


제 개발환경인 windows 8.1에서는 msi 형태의 설치 파일을 통해 별도의 설정 없이 손쉽게 설치가 가능했으나 

실행 환경인 raspberry PI는 조금 복잡하고 오랜 과정이 필요했습니다.


다음은 설치 과정을 정리한 포스팅입니다.


http://c-mobberley.com/wordpress/2013/10/14/raspberry-pi-mongodb-installation-the-working-guide/


영어의 압박이 있어 보이지만 순서대로 따라하면 큰 무리 없이 설치가 가능합니다.

다만, 어디서나 mongo 콘솔을 사용할 수 있도록 설정하는 부분이 빠진 것 같아 다음과 같이 추가합니다.


sudo ln -s /opt/mongo/bin/mongo /usr/bin/mongo


설치된 mongoDB 버전이 2.1.1 에 불과하다는 포스팅도 있으나 사용하고자 하는 기능에는 크게 무리가 없을 듯 합니다.


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

감사합니다.

  1. 생각의 웹 WebofThink 2015.07.06 17:17 신고

    종종 raspberry PI가 비정상 종료될때 mongodb가 제대로 실행되지 않습니다.
    이떄 아럐 링크를 참조하여 수정 후 실행해야 합니다.
    http://stackoverflow.com/questions/9884233/mongodb-service-is-not-starting-up

    sudo rm /var/lib/mongodb/mongod.lock
    mongod --repair
    sudo service mongodb start



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


앞서 라즈베리 파이에 WiFi USB dongle 설치한 포스팅을 공유한 바 있습니다.

라즈베리 포럼을 뒤지다 당시 라즈베리안 커널 버전에 맞는 드라이버를 컴파일해서 dropbox로 제공해준 MrEngMan 덕분에 일단 사용할 수 있게 되었지요.


그러나, 문제는 커널이 업그레이드 될 때마다 해당 커널 버전으로 빌드한 드라이버를 구해서 수작업 설치를 해야 한다는 문제가 있었습니다.

무심코 아래와 같이 라즈베리파이의 커널 업그레이드 후 재부팅을 하니 더 이상 와이파이 동글이 사용할 수 없는 상태가 되어 버렸습니다. ㅠ.ㅠ.


sudo apt-get update
sudo apt-get upgrade
sudo reboot -t NOW


문제의 원인을 찾기 위해 로깅 메세지를 보니 MrEngMan이 제공한 드라이버가 커널과 호환되지 않았습니다.

당시엔 (지금도) 드라이버를 빌드하기 위해 필요한 절차를 이해하지 못하고 있었기 때문에 제가 할 수 있는 최선은 라즈베리파이 포럼에 해당 버전에 맞춰 드라이버를 컴파일해 달라는 읍소형 댓글을 다는 것 뿐이였습니다.


그런데 안타깝게도 몇 달이 지나도록 댓글이 달리지 않더군요.


결국 어쩔 수 없이 Ethernet으로 연결하여 사용하던 중 다시 와이파이가 필요한 상황이 되어 다시 한번 (용기를 내어) 구글링하기 시작했습니다.


그 결과, 다행히 N150UA에 사용된 WiFi 칩셋인 MediaTek-MT7601의 드라이버를 라즈베리파이에서 빌드하는 법을 정리한 포스팅을 발견해 기쁜 마음에 링크를 공유합니다.


http://groenholdt.net/Computers/RaspberryPi/MediaTek-MT7601-USB-WIFI-on-the-Raspberry-Pi/MediaTek-MT7601-USB-WIFI-on-the-Raspberry-Pi.html


상기 포스팅 내용을 한글로 재 정리하면 다음과 같습니다.

// root 계정으로 변경
sudo -s

// 최신 version download
apt-get update
apt-get upgrade
rpi-update

// 리눅스 커널 소스 코드 다운로드
cd /usr/src
git clone https://github.com/raspberrypi/linux.git
sudo ln -s /usr/src/linux /lib/modules/`uname -r`/build
cd linux

// 현재 수행 중인 시스템 커널 설정으로 지정
make mrproper
zcat /proc/config.gz > .config
cp .config .config.org
make modules_prepare


// 커널 모듈 심볼 다운로드 (커널 재 컴파일을 막기 위함)
wget https://raw.github.com/raspberrypi/firmware/master/extra/Module.symvers

// MT7601 USB 드라이버를 압축해제
cd ~ 
tar -xvjpf DPO_MT7601U_LinuxSTA_3.0.0.4_20130913.tar.bz2 
cd DPO*


드라이버에서 엄청난 양의 로그를 뱉기 때문에 이를 막기 위해서 os/linux/rt_linux.c 파일에서 다음 문장을 수정합니다.

ULONG RTDebugLevel = RT_DEBUG_TRACE; 
ULONG RTDebugLevel = 0; // RT_DEBUG_TRACE; 

마지막으로 드라이버를 빌드하고 인스톨 합니다.

make
make install


혹시 이전 제 포스팅에서 설명한 방식대로 driver를 설치하신 분은 최종 설치 과정 (make install) 전에 이전 드라이버를 삭제해 주셔야 합니다.

제거 명령은 다음과 같습니다.


sudo rm -rf /etc/Wireless/RT2870STA

감사합니다.

  1. 이재용 2014.11.20 09:25

    제가 원하던 정보를 공유해 주셔서 감사합니다.
    허나 저는 git clone https://github.com/raspberrypi/linux.git 이 부분에서 다운로딩 하는데 8시간 정도 걸려서 다 받고나서 resolve objects 중 index-pack died of signal 993878 이렇게 오류가 떠버리네요ㅠㅠ
    라즈베리에 바로 동글이를 달아서 와이파이를 잡아서 다운을 받아서 그런가 속도가 매우 느렸습니다. 긴 시간을 기다리고 다운받았던 것이 한순간에 날아갔습니다.
    이 오류가 왜 뜨는지 궁금해서 질문 올려봅니다. 저 좀 구제시켜 주시길 바랍니다 ㅠㅠ

    • 생각의 웹 WebofThink 2014.11.20 17:14 신고

      안녕하세요,
      제가 경험하지 않은 현상이라 저도 원인을 알기 힘들어 조심스럽게 몇 가지 확인해보길 권합니다.

      1. 라즈비안을 최신 버전으로 업그레이드 하셨나요? (apt-get upgrade)

      2. 댓글에서 WiFi 로 산딸기 사용 중이라고 하셨는데 해당 버전에서 WiFi 동글이 동작한다면 굳이 드라이버를 재 설치할 필요가 있나요? 저는 동글이 제대로 동작하지 않아 이더넷으로 네트워크 설정 후 사용했습니다.

      라즈베리파이 커널 파일을 받고 오류가 생긴 것으로 보아 받은 파일들과 쓰고 있는 커널이 맞지 않은 게 아닐까 생각됩니다.
      부디 문제를 잘 해결하시길!

  2. 라즈 2015.01.09 03:28

    안녕하세요.
    저는 지금 3.12.35+ 버전 커널을 사용중인데
    lsmod 를 아무리해도 모듈이 없네요..
    포스팅 링크가 사라져 댓글납깁니다!

    • 생각의 웹 WebofThink 2015.01.09 07:53 신고

      안녕하세요. 진짜 원본 링크가 사라졌군요. T.T 시간이 지나 드라이버 빌드 순서는 기억하지 못해 재 검색 결과 유사한 내용의 포스팅을 찾아 공유합니다. http://va3paw.com/2014/03/16/hsmm-mesh-on-raspberry-pi/ 기억 상으로는 유사한데 이대로 제가 해보지 않아 정상 동작 여부는 보장하지 못하는 점 양해바랍니다. ^^;;

    • 라즈 2015.01.09 11:27

      어후 아닙니다~ 이렇게 다시 찾아주신게 감사할 따름입니다.
      아...제발 됬으면 좋겠네요.
      iptime n150ua 를 많이 쓴다하여 산건데 파란불은 나오는데
      왜 안되는지 모르겠습니다 ㅠㅠ 시도해보겠습니다.!
      감사합니다. 새해 복 많이 받으세요!

    • 생각의 웹 WebofThink 2015.01.09 11:34 신고

      저도 라즈 책에 지원하는 동글 모델로 나와서 비싸게 샀다가 된통 당했죠 -_-;;

  3. KangBom 2015.05.06 02:13

    안녕하세요 글 잘 보았습니다. 한 가지 여쭤볼 것이 있는데 make 명령어 실행 중에 rt_linux.o 에서 에러가 발생했습니다. 해서 rt_linux.c를 gcc -c 컴파일을 하였는데 헤더파일(c 파일에 include된 헤더파일)이 없다는 에러가 떴습니다. github에서 해당되는 헤더파일을 다운로드 받았더니 더 많은 에러가 뜨길래 컴파일은 그만두었습니다. rt_linux.o 에러가 발생하는 이유는 무엇일까요?

  4. AlphaFactory 2015.07.02 19:55

    안녕하세요. 게시글이 많은 도움이 되었습니다.
    다만 최근 라즈비안의 커널 버전이 4.0.X로 업데이트됨에 따라 일부 맞지 않는 부분이 있어 추가를 부탁드리고 싶습니다.

    zcat /proc/config.gz > ./config

    명령어를 실행하기 이전에, 이제는

    sudo modprobe configs

    를 실행해주어야만 config.gz 파일이 생성된다고 합니다.

    해당 이슈는 라즈베리파이 Github Issue Tracker에서 발견하였습니다.

    https://github.com/raspberrypi/firmware/issues/442

    이 부분에서 막히는 분도 있을거라 생각되어 댓글 남깁니다.

  5. AlphaFactory 2015.07.02 20:31

    추가로 리눅스 커널 3.13 이후로는 소스 일부분을 수정해야 제대로 컴파일 되는 것으로 보입니다. 관련 내용은 아래 링크에 있습니다.

    http://www.arnelborja.com/compiling-rt2870-wifi-driver-in-fedora/

  6. 생각의 웹 WebofThink 2015.07.02 20:32 신고

    공유 감사합니다 ^^

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


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

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

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


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


http://arest.io/


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




아직 사이트의 컨텐츠가 모두 완성되지 않은 상태로 보이나 (docs 메뉴에 가보면 under construction으로 되어 있습니다)
공개된 소스 코드의 README 파일이나 블로그에 포스팅 된 내용으로 보아 충분히 사용 가능한 수준으로 보입니다.

간략하게 정리하면 먼저 이 프로젝트는 다음과 같은 특성을 가지고 있습니다.



- REST API를 통한 아두이노 제어 가능

// 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이 모든 소스코드와 함께 빌드 방법까지 공개해야 하는 점을 유념하시기 바랍니다.  



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

감사합니다.

  1. 생각의 웹 WebofThink 2014.11.15 00:49 신고

    자세한 개발 사례는 다음 블로그 포스팅을 참고하시기 바랍니다. https://learn.adafruit.com/a-rest-api-for-arduino-and-the-cc3000-wifi-chip/overview

안녕하세요,

"생각의 웹"입니다.


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

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


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

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

부속 프로젝트인 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일)을 마지막으로 대장정의 마무리를 내립니다.


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

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



이번 마지막 강연에서는 지난 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 코드에 대한 설치 가이드자주 나온 질문들을 링크와 같이 정리했습니다. 참고하시기 바랍니다.

 

+ Recent posts