‘클라우드 IoT 플랫폼’을 선택하는 방법

InfoWorld
IoT는 현재 컴퓨팅 분야에서 유달리 뜨거운 개념이다. 이 가운데서도 클라우드 IoT 플랫폼을 둘러싼 마케팅 활동이 활발하다. IoT와 클라우드 IoT 플랫폼을 정의하는 한편, 클라우드 IoT 플랫폼에서 필요한 것과 선택하는 방법에 대해 살펴본다.
 
ⓒ Getty Images Bank

IoT는 쉽게 말해 인터넷에 연결된 물리적인 사물이다. 이런 사물은 다양한 파라미터를 측정하는 센서를 내장했고, 인터넷을 통해 원격 또는 인근의 ‘엣지(Edge)’ 서버로 데이터를 전송한다. 인터넷 사물은 또한 인터넷을 통해 지시를 받고 동작할 수 있다. 

예를 들어, ‘스마트’ 인터넷 연결 토양 수분 센서는 측정값을 주기적으로 보고할 수 있으며, 밭의 토양이 너무 건조할 때마다 인터넷에 연결된 배수 밸브가 열릴 수 있다. 토양 수분이 적당하면 밸브가 다시 닫힌다.

수분 센서와 배수 밸브는 같은 ‘엣지 컴퓨팅’ 장치 또는 인터넷과 통신하는 노드에 연결될 수 있거나 서로 다른 노드에 연결될 수 있다. 왜냐하면 많은 토양 수분 센서가 넓은 밭에서 사용되고 각 밭에 1개의 중앙 관개 시스템만 필요할 가능성이 높기 때문이다.

IoT는 클라우드와 어떤 관련성을 가질까?
‘인터넷’은 데이터를 전송하는 네트워크들의 상호 연결 집합이다. IoT의 경우 원격 종점이 사설 데이터센터의 단일 서버보다는 클라우드 서버에 위치하고 있는 경우가 많다. 여러 상황에서 클라우드와 연결하는 것이 유용할 수 있기 때문이다.

가령 센서가 토양 수분뿐 아니라 토양 온도, 기온, 대기 습도도 측정한다고 가정해보자. 또 서버가 수천 개의 센서로부터 데이터를 가져오고 날씨 서비스의 일기예보 피드를 읽는다고 가정해보자. 이 서버를 클라우드로 운용하면 모든 데이터를 클라우드 스토리지에 저장하고 이를 활용하여 머신러닝 예측을 통해 최적의 물 흐름을 이용할 수 있다. 이 모델은 정교하고 원하는 대로 확장할 수 있다.

또한 클라우드 안에서 구동하면 경제성이 있다. 센서 보고서가 시간 단위로 유입된다면 서버가 나머지 시간 동안 활성화되어 있을 필요가 없다. ‘서버리스’ 클라우드 구성을 이용해 수신 데이터를 저장한 후 자원을 해제하는 식이다. 마찬가지로 필요에 따라 관개수 흐름 설정 값을 변경한 후 자원을 해제할 수 있다.

로컬 vs. 원격 IoT 피드백 루프
앞선 관개의 예에서는 클라우드 서버의 응답시간이 한 시간인 경우에도 큰 문제가 없다. 그러나 시간 지연이 문제가 될 수 있는 상황도 흔하다.

예를 들어, 자율주행 자동차를 생각해 보자. 도로를 지속적으로 확인하고 장애물을 식별하며 위치를 측정한다. 또한 데이터를 클라우드로 지속적으로 전송하지만 원격 서버에 의존하여 스로틀, 브레이크, 스티어링 등을 조절할 수 없다. 이들은 로컬로 수행되어야 한다.

이것이 제어 시스템 엔지니어링 교과 과정에서 다루는 상황 중 하나다. 제어 피드백 루프를 가능한 최저 수준으로 낮춘다. 그렇다. 원격 감독 시스템이 대상 설정 값 또는 경로 계획을 변경할 수 있지만 자동차 스스로 시간에 민감한 각종 작동을 관리해야 한다.

필수적인 클라우드 IoT 기능
클라우드 IoT 플랫폼은 IoT 종점과 이벤트 스트림을 모니터링하고 엣지 및 클라우드에 있는 데이터를 분석하고 애플리케이션 개발 및 배치를 지원해야 한다. 거의 모든 IoT 프로젝트에 필수적인 기능들이기 때문이다. 

또 클라우드 데이터 분석 및 애플리케이션 개발을 가능하게 하려면 IoT 플랫폼이 클라우드 스토리지에 액세스할 수 있어야 한다. 산업용 IoT 장치와 차량의 경우 많은 데이터를 저장해야 할 수 있다. 물론, 장기적인 분석을 위해 필터링하거나 취합할 수 있기는 하다. 산업용 IoT는 네트워크 및 프로토콜 변환 측면에서 문제를 야기할 수 있다. 구식 산업용 프로그램 가능 컨트롤러는 이더넷과 TCP/IP에 맞추어 개발되지 않았다.

퍼즐의 또 다른 조각은 엣지 장치에서 클라우드 플랫폼으로 데이터를 이동하는 것이다. 실내 애플리케이션의 경우 유선 이더넷이나 무선랜를 사용할 수 있는 경우가 많다. 농업에서의 활용 시나리오 등 실외 애플리케이션의 경우 값비싼 스마트폰 요금제 대신에 셀룰러 M2M 요금제 등 셀룰러 데이터를 사용하는 것이 일반적이다.

관리형 IoT 연결성(Managed IoT connectivity) 서비스가 여기에 도움이 될 수 있다. 이런 서비스 중 일부는 SIM 카드와 관련된 데이터의 관리가 핵심이며, 더욱 광범위한 IoT 연결성 플랫폼도 엣지 장치 운영체제와 에이전트를 처리한다. 단 일부 M2M 서비스는 실질적인 IoT 기능 없이 브랜딩에 ‘IoT’를 추가하기도 한다는 점에 주의할 필요가 있다.

IoT 플랫폼 고려사항
매력적으로 들린다는 이유만으로 클라우드 IoT 플랫폼에 편승하는 대신에 우선 자체적인 요건을 파악하고 이를 충족할 수 있는 몇 가지 모니터링, 분석, 제어, 애플리케이션 아키텍처를 검토할 필요가 있다. 사용자 경험, 데이터, 비즈니스 부분을 파악해야 한다.

아울러 특정 장치, 장치 OS, 게이트웨이, 엣지 플랫폼, 네트워크, 통신 프로토콜, 클라우드 플랫폼, 클라우드 브랜드 등에 맞춰 시스템을 구축하지 않도록 주의해야 한다. 특히 초기에는 범용적인 기술들로 설계할 필요가 있다. 애플리케이션에 어떤 기능이 가장 중요한지 파악하고 해당 목록을 이용해 플랫폼을 선택해야 한다. 다시 말해, 이것은 하나의 프로세스이다.

클라우드 IoT 비용은 예측하기 어려우며 과소평가하기 쉽다. 클라우드 가격이 내재적으로 복잡하다는 문제가 있다. (클라우드 애플리케이션 비용을 실제로 파악하는 유일한 방법은 한 달 동안 운용하고 청구서를 받아 보는 것인 경우가 많다.) 

클라우드 IoT 플랫폼 다수가 초기 할인을 제공한다는 점도 문제이다. 초기 가격에만 신경쓴다면 가격이 올랐을 때 후회할 수 있다. 마지막으로, 데이터 스토리지 비용을 간과하기 쉽다. 오래되고 중요하지 않은 데이터를 버리는 것에 대한 장기적인 전략도 마련해야 한다. 

이 프로세스의 또 다른 어려운 점은 자신의 역량을 평가하는 것이다. 장치와 센서 관리 전문 지식이 있는가? 통신 프로토콜 및 네트워크는? 클라우드 애플리케이션 아키텍처, 운영, 관리는? 직원들이 IoT 애플리케이션 구축에 전념할까? 아니면 진행 중인 중요한 업무가 있는가? 새로운 사람을 고용해야 할까? 적절한 기술을 갖춘 새로운 사람을 고용할 수 있을까?

이런 평가가 전 기능 또는 베어본 클라우드 IoT 플랫폼 선택에 영향을 미친다. 일부 벤더는 애플리케이션 니즈에 맞추어 손쉽게 사용자 정의할 수 있는 탄탄하고 거의 완전한 플랫폼을 제공한다. 필요한 것 중 일부만 제공하지만 내부적으로 또는 컨설턴트를 통해 추가적인 통합 및 사용자 정의를 수행해야 하는 벤더도 있다.

첫 클라우드 IoT를 도입할 때는 개념 증명을 반드시 수행해야 한다. 소프트웨어 개발이 수반되는 다른 프로젝트와 마찬가지로 첫 프로젝트가 실패할 때를 대비한 계획이 있어야 실수로부터 배우고 다음 번에 제대로 구축할 수 있다. 개념 증명이 성공한 후에만 확장을 시작할 수 있다. 
 
* 인포월드 기고 편집자이자 리뷰어인 Martin Heller는 웹 및 윈도우 프로그래밍 컨설턴트 경력을 보유자다. 1986년부터 2010년까지는 데이터베이스, 소프트웨어, 웹사이트 개발자로 일했으며 그 이후에는 알파 소프트웨어의 기술 및 교육 부사장, 튜브파이의 의장이자 CEO를 역임했다. ciokr@idg.co.kr