IoT 디바이스 소프트웨어 테스트: 핵심 과제와 해결책

'수잔 해리스가 혼자 집에 있는데 갑자기 문이 잠기고 창문이 쾅 닫히고 전화가 작동하지 않습니다. 수잔은 침입자에게 갇혔습니다. 하지만 이것은 평범한 폭력배가 아닙니다. 대신 침입자는 프로테우스(Proteus)라는 컴퓨터, 추론을 학습한 인공 두뇌입니다. 그리고 공포를 주죠…’

1977년 영화 '데몬 시드(Demon Seed)'는 AI가 폭주해 인간에게 가하는 위험을 다소 멜로드라마틱하게 그렸지만, 홈 오토메이션과 그 잠재적 오작동에 대한 예리한 통찰을 담고 있었습니다.

의료, 홈 오토메이션, 운송, 석유 가스 산업에서 IoT는 급속히 성장하고 있습니다. 가트너 연구자들은 2020년까지 204억 IoT 디바이스가 인터넷에 연결될 것으로 예측했습니다.

당신이 스마트워치로 영화를 보고, 집에 선호 온도로 데우라고 하고, 토스터와 뭐가 '탄 것'인지 협상하는 동안, 테스터들을 생각해 보세요. 이들 디바이스가 의도대로 실제로 작동하는지 보장하기 위해 닫힌 문 뒤에서 고군분투하는 남녀들입니다.

그렇다면 소프트웨어 테스터가 IoT 디바이스 테스트 시 직면하는 과제는 무엇일까요?

첫째, 명백한 것 — 안전한가?

보안

IoT를 빠르게 검색하면 IoT 보안 우려를 논하는 수많은 기사가 나옵니다. 하지만 주전자가 당신을 염탐할까 걱정하는 대신, 신뢰할 수 있는 네트워크에 새롭거나 침해 가능한 디바이스를 추가하는 매우 실질적인 우려가 있습니다. 노트북이나 컴퓨터엔 소프트웨어를 설치해 디바이스를 보호할 수 있지만, IoT 디바이스는 지원이 미약합니다. 많은 디바이스가 일반 사용자가 절대 바꾸지 않는 기본 사용자명과 비밀번호를 가져 취약합니다.

테스터는 IoT 디바이스가 인터넷 보안에 미칠 더 넓은 영향도 고려해야 합니다. 미라이 봇넷 공격이 디지털 카메라와 비디오 레코더 같은 물품을 사용해 미국 인터넷 상당 부분을 대혼란에 빠뜨려 넷플릭스, 트위터, CNN, 레딧 같은 사이트를 마비시킨 것을 되돌아보기만 하면 됩니다.

테스터라면 디바이스 간 데이터 흐름, 데이터 암호화, 테스트 소프트웨어 무결성(자동화 시) 등이 모두 핵심 관심사입니다.

때로는 테스터가 단순히 사용자가 네트워크를 보호하길 의존해야 합니다. 그러나 저가 라우터가 종종 안전 조치를 덜 포함하므로, 이는 IoT 테스터에게 또 다른 이슈, 즉 아이템이 작동할 환경을 복제하는 문제로 이어집니다.

환경 복제

웹사이트 테스트 시 테스터가 페이지를 돌려보는 건 쉽습니다. 인기 브라우저에서 페이지를 열고, 노트북, 태블릿, 스마트폰에서 실행하면 사용자 90%가 어떻게 쓸지 꽤 많이 테스트한 셈입니다.

그러나 IoT 디바이스로 사용자 환경을 복제하는 건 훨씬 더 어렵습니다. 디바이스가 집에서 쓰일까요, 직장에서 쓰일까요? 인터넷 속도는 빠를까요, 느릴까요? 이 네트워크에 알 수 없는 다른 디바이스가 몇 개나 연결돼 있을까요? 디바이스가 네트워크를 떠났다가 다시 합류해야 할까요?

기술적 측면을 잊고, 디바이스가 어떤 가구 위에 놓일까요? 애플 홈팟(HomePods)이 처리되거나 바니시 칠해진 나무 테이블에 흰 고리를 남긴다는 것이 문서화됐습니다. 엄격한 소프트웨어 테스터 이슈는 아니지만, 환경의 광범위한 다양성이 테스터의 조건 복제 작업을 얼마나 어렵게 만드는지 보여줍니다.

이 때문에 테스터는 제품에 대한 강한 이해를 확보하고, 디바이스가 다른 것들과 어떻게 작동할지 포함해 가능한 한 많은 다양한 시나리오를 테스트에 포괄하려 노력해야 합니다.

다른 디바이스와의 작동 방식

호환성 테스트는 항상 테스터의 골칫거리지만, IoT 세계에선 무수한 과제가 됩니다. IFTTT를 지원하는 디바이스에서 생성될 수 있는 겉보기엔 끝없는 상호작용만 봐도 — 모든 디바이스를 모든 환경에서 모든 릴리스마다 분석하고 테스트하기엔 체스판의 수가 너무 많습니다.

테스터가 이 작업을 시작할 수 있는 유일한 방법은 가장 인기 있는 운영체제와 통신 방식(예: 블루투스), 가장 인기 있는 디바이스에 초점을 맞춰 노력의 도달 범위를 최대한 넓힌 뒤, 더 틈새 아이템으로 넘어가는 것입니다.

비용

또 다른 과제는 아마도 가장 명백한 것 — 비용입니다. 웹사이트 같은 더 단순한 것 테스트는 꽤 빠르고 저렴합니다. 하지만 서로 다른 환경, 서로 다른 통합으로 IoT 디바이스를 테스트하는 건 매우 비용이 많이 들 수 있습니다. 시간은 큰 요소입니다. 테스터가 너무 많은 베이스를 커버해야 하니까요. 또 다른 이슈는 전문 테스트 소프트웨어가 필요할 가능성입니다. 몇몇 연구는 보안 결함에 대해 코드를 검토하지 않는 개발자 부족과 IoT 앱의 철저한 테스트 부족이 결합돼 테스트가 매우 복잡해진다고 암시했습니다. 그리고 복잡함과 함께 비용이 옵니다.

전원 및 백업

가장 흔한 IT 솔루션인 껐다 켜기와 달리, 일부 IoT 디바이스는 갑작스러운 전원 손실 시 어려움을 겪을 수 있습니다. 테스터는 전원 손실 후 디바이스가 어떻게 변하는지 테스트해야 합니다. 특히 의료나 산업 분야 아이템의 경우 그렇습니다.

무선 전력이 계속 성장하면 이 문제는 덜해지겠지만, 그때까지 변수들을 고려해야 합니다. 스마트 침입 경보기나 보안 카메라를 고려해 보세요. 버그나 전원 또는 연결 저하로 시스템이 실패하면 본질적으로 무용지물입니다.

디바이스가 백업하는 방식이나 백업 여부도 또 다른 이슈입니다. 특히 새거나 업데이트된 소프트웨어가 오래된 데이터에 어떻게 반응할지 고려할 때 그렇습니다.

업데이트

펌웨어는 많은 IoT 디바이스의 필수적 부분이며, 개발자들이 새 업데이트를 푸시하는 것보다 좋아하는 건 없습니다. 하지만 테스터에겐 업데이트가 버그라는 기념비적 두통을 가져올 수 있습니다. 표준 컴퓨터에 놓친 버그가 들어가면 보통 너무 큰 피해 전에 단순 테스트와 수정이 가능합니다. 하지만 IoT 디바이스에 버그가 들어가면 훨씬 더 생리적 파급효과를 가질 수 있습니다.

2016년 1월 네스트(Nest) 온도조절기 이슈를 예로 들어보세요. 이전 12월 소프트웨어 업데이트로 일부 온도조절기 배터리 수명이 소모돼 시스템이 비활성화되는 버그가 생겼습니다. 결국 회사는 사용자를 위한 9단계 수정안을 내놨지만, 적절하고 철저한 테스트였다면 사용자의 추위와 회사의 체면을 구할 수 있었을 것입니다.

우리가 데몬 AI 프로테우스처럼 집이 위험해지는 건 아니지만, 소프트웨어 테스터가 적절한 예방조치를 취하지 않으면 추위에 떨게 될 위험이 있습니다.