기술 블로그

"기기가 멈춘 걸 현장에 가서야 압니다." 이 한 문장이 저희가 받은 요구의 전부였습니다. 신형으로 바꾸면 되는 문제인데, 이미 깔린 물량 때문에 그 답은 처음부터 후보가 아니었습니다. 교체하지 않는다는 조건 하나가 나머지 설계를 어떻게 끌고 갔는지에 대한 기록입니다.

관리 인력을 상주시키지 않기로 했는데, 그 사람이 하던 일은 사라지지 않았습니다. 지하 주차장 입구는 통신이 가장 약한 자리이고, 차단기 앞에 선 사람은 기다릴 여유가 없습니다. 통신이 되든 안 되든 문은 열려야 한다는 조건에서 경로를 어떻게 나눴는지에 대한 기록입니다.

인증은 보통 제품을 다 만든 뒤에 준비합니다. 기능이 먼저고 인증은 그다음이라는 순서가 자연스럽기 때문입니다. 그런데 저장 데이터 보호나 디버깅 인터페이스 차단처럼 하드웨어 구조에 걸리는 항목은 그 순서로는 붙지 않습니다. 요구사항 정의 단계에서 보안 항목만 따로 떼어 낸 이유와, 그렇게 해서 잃은 것을 적습니다.

"휴게시간을 자율로 바꿨는데, 실제로 얼마나 쓰는지를 알 방법이 없습니다." 저희가 받은 요구는 이 한 문장이었고, 처음 나온 답은 이미 깔려 있는 출입 통제 기록을 쓰자는 것이었습니다. 그 답을 버리고 인식기를 새로 만들기까지, 그리고 만든 뒤에 새로 나온 문제들에 대한 기록입니다.

앱에서 조명 밝기를 조절하면 즉시 반응해야 하고, 앱을 꺼둔 새벽 2시에도 예약 실행은 돌아야 합니다. 이 둘은 사실 서로 다른 요구여서 하나의 길로 억지로 묶으면 반드시 한쪽이 망가지는데, 저희가 길을 어떻게 나눴는지 정리했습니다.

이미 고객 손에 있는 기기의 소프트웨어를 원격으로 바꾸는 일은 IoT에서 가장 위험한 작업이라, 잘못 만들면 한 번의 버튼 클릭이 전량 회수로 이어집니다. 벽돌이 되지 않게, 가짜 펌웨어가 들어오지 않게, 취약한 옛 버전으로 되돌아가지 않게 만든 구조를 정리했습니다.

남편이 거실 조명을 켜면 아내 휴대폰 화면의 스위치도 같이 켜져야 하는데, 당연해 보이는 이 동작이 실제로는 IoT 플랫폼에서 가장 먼저 무너지는 지점입니다. 기기를 사람에 묶을지 장소에 묶을지를 정하는 데 가장 오래 걸렸고, 결국 나머지 설계가 대부분 그 한 줄에서 따라 나왔습니다.

한 플랫폼 위에 여러 고객사가 올라가는데, 데이터가 섞이면 그 순간 신뢰가 끝나고 되돌릴 방법도 없습니다. 격리를 "개발자가 조심하는 것"이 아니라 구조로 만든 과정과, 고객사마다 다른 조직 구조를 코드 수정 없이 받아내는 권한 설계를 정리했습니다.

국내에서 IoT 기기를 상용 출시하려면 보안 인증이 필요한데, 인증기준을 한 줄씩 읽어보면 평범하게 잘 짠 코드가 이미 기준을 위반하고 있는 경우가 있습니다. 이걸 나중에 발견하지 않으려고 인증 대응을 플랫폼 기본값과 자동 검사에 심은 이야기입니다.

온습도계 하나가 10초마다 값을 보내면 하루 8,640건이고 기기가 1,000대면 하루 864만 건인데, 이걸 전부 보관하면 요금이 계속 오르고 보관하지 않으면 "지난 한 달 평균"을 보여줄 수 없습니다. 저희가 이 둘 사이에서 무엇을 골랐고 무엇을 못 하기로 정했는지 정리했습니다.

고객사마다 제품이 다르고 같은 고객사도 모델을 계속 추가하는데, 그때마다 앱을 새로 만들거나 다시 스토어 심사를 받으면 IoT 사업은 앱 개발 일정에 묶입니다. 앱을 한 벌만 만들어 놓고 제품이 늘어나는 것을 받아내는 구조를 어떻게 짰는지 정리했습니다.

상자를 열고 앱에서 "기기 추가"를 누르면 몇 초 만에 등록이 끝나지만, 그 몇 초 안에 공장·클라우드·앱이 각자 다른 일을 하고 있습니다. 여기서 한 가지만 어긋나면 옆집 사람이 내 기기를 가져가거나 훔친 기기가 새 주인을 갖게 되는데, 그걸 어떻게 막았는지 정리했습니다.

화면에 초록 점이 켜져 있다는 것과 그 기기가 실제로 명령을 받을 수 있다는 것은 다른 이야기인데, 이 둘을 일치시키는 일이 생각보다 훨씬 까다로웠습니다. 결국 신호를 두 종류로 나눠 쓰게 됐고, 왜 그렇게까지 해야 했는지를 순서대로 적었습니다.