안녕하세요,

"생각의 웹"입니다.


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

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

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


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의 레인할트와 같은 전문가의 언급처럼 기기 제조업체들에게 경제적 인센티브를 통해 그들이 만든 기기의 제어권과 기기가 생성한 데이터에 대한 접근권을 공유하도록 하는 것입니다.

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


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


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


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


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

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


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


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


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


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

+ Recent posts