다양한 디바이스를 사용한 서비스 통합 설계
안드로이드 OS, 키오스크, 태블릿, 스마트폰, PC, 블루투스 까지
1.
최근 진행했던 서비스 기획 중 하나는 일반적인 앱이나 웹을 넘어서서, 여러 IoT 디바이스를 연계한 형태의 서비스였다. 별도 키오스크와 태블릿, PC 웹을 포함해 블루투스 지원 기기들까지. 여러 사람이 하나의 ID를 바탕으로, 여러 의료 데이터를 취합해야했다. 일반적인 서비스라면 스마트폰에 연결된 개인 기기를 통해 데이터를 취합하겠지만, 이 경우에는 한 사람당 사용해야하는 장비가 3~4가지를 넘었다. 게다가 불특정 다수가 QR 코드를 바탕으로 자신의 기록을 확인해야하는, 특수한 상황이었다. 처음에 상대 측에서는 개별 측정기기에 QR코드를 연결하면 된다는 식으로 이야기를 했지만, 조사 결과 진행이 불가능한 방식이라는걸 알게됐다. 그래서 안드로이드 OS에 블루투스 기반의 기기를 연동시켜, 개별 기록을 재고, 그 정보를 다시 DB에 전송하는 방식으로 설계를 진행하기로 했다.
처음에 내가 확인하려했던 내용은, QR 코드에 대한 정확한 정의였다. QR기반으로 무슨 정보까지 전달할 수 있는지. OS에서 스캔된 QR 정보를 다시 앱이나 웹 규격에 표출할 수 있는지. 그 정보를 DB로 보내는게 가능한지 같은 - 기초적인 내용에 가까웠다. 이후에는 바코드 관련되어 안드로이드OS 기준으로 어느 범위까지 처리가 가능한가에 대한 내용을 알아보기 시작했다.
바코드도 전세계 기준 다양한 기준이 있다바코드에 대해서 확인한 것은, 일단 일반 바코드에도 여러가지 규격이 존재한다는 사실이었다. EN, ITF 방식 등은 단순 숫자만 표현이 가능했고, CODE 39나 CODE 128 기준부터 아스키 코드나 알파벳 대소문자 표기가 가능했다. 이런 이유 때문에 서비스 설계시 QR코드를 써야할지, 바코드를 써야할지에 대한 고민이 생겼다. 회원의 ID 정보를 알려주는 데에는 단순히 숫자 넘버링도 상관은 없지만, 일반적으로 영문자 표기와 숫자가 조합되어야 관리가 편하기 때문이다. 또한 QR / 바코드 인식시 특정 컨텐츠나, 서비스 URL을 보내는 등의 처리가 가능할지도 고민을 해봐야했다.
기존에 정리해둔 QR코드의 두가지 사용방식
https://brunch.co.kr/@clay1987/351
안드로이드에서 바코드 스캔을 진행할때, 인식 가능한 범위에 대한 정리문서
https://developers.google.com/ml-kit/vision/barcode-scanning/android?hl=ko
안드로이드 OS에서 지원되는 바코드 인식타입
Code 128 (FORMAT_CODE_128)
Code 39 (FORMAT_CODE_39)
Code 93 (FORMAT_CODE_93)
Codabar (FORMAT_CODABAR)
EAN-13 (FORMAT_EAN_13)
EAN-8 (FORMAT_EAN_8)
ITF (FORMAT_ITF)
UPC-A (FORMAT_UPC_A)
UPC-E (FORMAT_UPC_E)
QR 코드 (FORMAT_QR_CODE)
PDF417 (FORMAT_PDF417)
아즈텍 (FORMAT_AZTEC)
Data Matrix (FORMAT_DATA_MATRIX)
2.
이후에 고려해야할 지점들 중 하나는 키오스크와 태블릿 앱에 대한 내용이었다. 이 서비스는 관리자를 제외한 일반 사용자는 OS기본 기능에 접속이 가능하면 안되는 형태였다. 그래서 화면 Lock에 대한 권한을 처리하기 위해, 안드로이드 자체의 소프트웨어 key (뒤로가기, 홈, 더보기) 를 비활성처리해야했다. 심지어 키오스크와 태블릿에서 QR 코드나 바코드를 인식해서 개별 측정기기의 데이터를 뽑아올 수도 있어야했다. 그러니 와이파이같은 네트워크 환경에 동시에 연결되어있는 상태가 바탕이 되어야했다. 그래서 가장 간단하게 생각한 것이 안드로이드 OS 기반 키오스크와 태블릿이었다.
안드로이드 키오스크의 장점
- PC OS에 비해 가볍고, 전력소모율이 낮음. 설치 및 실행, 재부팅도 빠르게 처리가능
- OS가 설치되는 기판 가격이 저렴하고, 다른 모듈 (예: 통신모듈) 들을 연결하기 쉬움
- OS 자체에 대한 커스터마이징도 가능하고, 앱이나 웹을 띄우는 형식으로 키오스크 구현이 쉬움
- 태생 자체가 터치 스크린 기반의 OS이기 떄문에, 키오스크로 구현해도 조작에 문제없음
- QR 리더기 기능을 OS 자체에서 지원하기에, 별도 리더기 없이도 전면카메라로 QR 스캔 사용가능
안드로이드 태블릿 기반의 전면카메라로 QR인증을 구현한 사례안드로이드 OS 기반 블루투스 기기 관리 / 연결
https://www.google.com/search?client=firefox-b-d&q=android+bluetooth+connection
3.
안드로이드 기기 하나당 여러 블루투스 기기를 동시에 연결할 수 있는지도 체크해봤다. 다만 이 과정에서 최대 5~7개 정도의 기기만을 연결할 수 있다는걸 알게됐다. 물리적으로 그 이상의 기기를 연동할 수는 있겠으나, 개인 회원별 데이터 처리가 쉽지않은 것 또한 문제가 있었다. 그래서 QR 기반의 로그인 이후, 3~4개 정도의 기기만을 연동처리하는 식으로 연계범위를 바꾸기로했다. 1개의 안드로이드 태블릿에 3~4개의 블루투스 기기를 연결하여 1 세트를 만든 것이다. 이런 세트 단위를 늘리는건, 키오스크보다 가격도 저렴하니, 쉽게 처리가 가능했다.
이후에 정리하게된 내용들은 '여러 사람이 동시다발적으로' QR을 통해 로그인을 하고, 특정 기능만 처리한 이후 로그아웃하는 형태였다. 별도의 앱에서 기본기능을 사용할 수 있지만, 나이가 많은 노인층을 위한 QR 로그인 + 태블릿 기반의 기능구현이 필요했다. 일반적인 서비스들에서는 나오기 힘든 규격이지만, 이번 서비스에서는 꼭 필요한 방식이었다. 규격이 변칙적이다보니 DB로 데이터를 전송하는 시점이나, 알림이 발생하기 위한 단계도 flow차트로 정리가 필요했다. 그 과정에서 팀원분에게 이 단계를 설명하고, 가설을 세우고, 직접 자료를 찾아 전달하기까지 오랜 시간이 걸렸던 것 같다.
4.
결국 정리해보면, 개별 PC웹, 모바일앱, 안드로이드 기반 키오스크용 앱, 안드로이드 태블릿 앱, 블루투스 기기들까지. 통합 연계하는 형태가 되어있었다. 예상했던 것보다 구조가 복잡한데다, 처리해야할 기능이 많아서 팀원분이 고생하는 경우가 많았다. 다만 결과적으로 전체 서비스 구조는 만족스럽게 처리된 것 같다. 일반적인 서비스가 아니다보니, 무슨 플랫폼이 어떤 역할을 해야할지에 대해 정리하는 과정이 꼭 필요했다. 그리고 그 과정에서 어떤 기능들이 단계별로, 어떤 유저타입에 의해 처리되는지. 그 과정을 모두 flow차트 상에 담아줘야했다. 심지어 그런 과정을 다시 팀원이 작업을 진행하기위해 다양한 기술적 설명과, flow차트 작성 방식까지 알려줘야했다. 하지만 내가 진행한 설명이 과연 충분했을까 - 라는 의문도 함께 남아있는 상태다.
마치 새로운 부품들을 조합해 새로운 디바이스를 만들듯이. 어떤 기능들이 무슨 역할을 해야하는지. 각 디바이스별로 통일된 규격은 무엇이 있는지. 어떤 형태로 통신을 해서 어떤 시점에 데이터를 DB로 보내야하는지. 그런 지점들을 일일히 체크해야하다보니, 머리가 아플 상황이 많았던 것 같다. 심지어 그런 설계를 하는 근거와, 이유까지 상대에게 설명을 해야하다보니 더욱 과정이 복잡했다. IT 기반 지식이 많지 않은 사람에게 이 과정을 설명해야하다보니, 매번 문서로 전달한 내용 이후에도 2~30분씩 기나긴 전화통화를 하는 경우가 대부분이었다. 물론 이런 과정이 필요하다는 건 부정할 수 없지만. 그것이 효율적인 방식이었는가에 대해서는 여전히 의문이 남는다.
-
그래도 일단 이런 경험을 해보는것 자체가, 추후에 있을 변형 케이스나, 여러 디바이스들을 연계하는 설계에 도움이 될거라고 생각한다. 내 지식의 얕음을 스스로 깨닫는 또다른 계기가 된것 같다.
