차단기 앞에서 기다리게 하지 않으려고: 온라인과 오프라인을 함께 설계한 무인주차 앱
관리 인력을 상주시키지 않기로 했는데, 그 사람이 하던 일은 사라지지 않았습니다. 지하 주차장 입구는 통신이 가장 약한 자리이고, 차단기 앞에 선 사람은 기다릴 여유가 없습니다. 통신이 되든 안 되든 문은 열려야 한다는 조건에서 경로를 어떻게 나눴는지에 대한 기록입니다.
OpenIoT 플랫폼팀
국내 무인주차 관리 서비스 사업자와 함께, 스마트폰으로 주차장 차단기를 제어하고 방문 차량을 관리하는 서비스를 만들었습니다. 고객사 검수를 마치고 지금은 운영을 준비하고 있습니다. 이 글은 통신이 닿는 상황과 닿지 않는 상황을 둘 다 정상 동작으로 놓고 만들면서 정한 것들에 대한 기록입니다.
사람을 빼도 그 사람이 하던 일은 남습니다
무인 운영으로 바꾼다는 말은 결국 사람이 하던 판단을 어딘가로 옮긴다는 뜻입니다. 관리 인력이 서 있던 자리에서 벌어지던 일은 두 가지였습니다.
| 하던 일 | 무인으로 바꾸면 |
|---|---|
| 차단기를 여닫는다 | 이용자가 직접 열어야 합니다 |
| 처음 보는 차량이 들어와도 되는지 판단한다 | 미리 초대한 사람만 들어오게 만들어야 합니다 |
옮길 곳은 두 군데뿐입니다. 시스템이 대신 판단하게 만들거나, 이용자가 직접 하게 만드는 것입니다.
차단기를 여는 일은 뒤쪽이 자연스러웠습니다. 지금도 실제로 여는 사람은 차 안에 앉아 있고, 시스템이 대신 판단하려면 번호판을 읽거나 차량을 미리 등록해 두는 절차가 따로 필요합니다. 방문 차량 확인도 초대한 사람이 있다면 뒤쪽으로 넘길 수 있었습니다.
둘 다 이용자 쪽으로 넘기기로 하고 나니, 조건 하나가 걸렸습니다. 주차장은 대개 지하에 있습니다.
익숙한 구조를 먼저 만들었고, 지하에서 막혔습니다
처음 잡은 구조는 서버를 경유하는 방식이었습니다. 앱이 서버에 요청을 보내고 서버가 현장 장비에 명령을 내리는 순서인데, 관리 화면에서 이력을 보기에도 편하고 구현도 익숙해서 저희도 자연스럽게 여기서 출발했습니다.
문제는 이 경로가 스마트폰이 서버에 닿는다는 것을 전제로 한다는 점이었고, 지하 주차장 입구는 그 전제가 가장 약한 장소입니다.
곤란한 것은 실패 자체보다 실패가 벌어지는 자리였습니다. 뒤차가 서 있고 경사로에 멈춘 상태라 앱을 껐다 켜서 다시 시도하는 것이 실질적으로 어렵고, 무인 운영이니 물어볼 사람도 없습니다. 사무실에서 테스트할 때는 몇 초 지연이 그냥 지연이지만, 경사로 위에서는 같은 몇 초가 완전히 다른 경험이 됩니다.
이용자가 재시도할 수 없는 자리라면, 처음부터 실패할 조건을 만들지 않는 편이 낫다고 판단했습니다.
| 방식 | 통신이 약한 곳에서 | 남는 문제 |
|---|---|---|
| 서버를 거쳐 차단기에 명령 | 응답이 늦거나 실패 | 이용자가 차단기 앞에서 대기하게 됩니다 |
| 리모컨이나 전용 카드 배포 | 영향 없음 | 발급과 회수, 분실 대응이 다시 사람 일로 돌아옵니다 |
| 개방은 근거리로, 나머지는 서버로 | 영향 없음 | 이력을 올리는 경로를 따로 두어야 합니다 |
둘째를 버린 이유는 단순한데, 리모컨이나 카드를 나눠 주기 시작하면 발급과 회수, 분실 대응이 따라붙어서 무인으로 바꾸려고 시작한 일이 다시 사람 일로 돌아오기 때문입니다.
통신이 되든 안 되든 열리게 만들었습니다
셋째로 갔습니다. 스마트폰과 차단기가 근거리에서 직접 신호를 주고받으므로 문을 여는 동작은 이동통신 환경의 영향을 받지 않습니다. 서버 경로를 없앤 것이 아니라 개방만 따로 뗀 것이고, 이력과 초대, 요금 정책은 통신이 닿는 동안 서버 쪽에서 그대로 돕니다.
아래쪽에는 경로가 둘입니다. 문을 여는 일은 통신을 타지 않는 쪽에 두고, 통신이 닿을 때 해야 하는 일은 서버 쪽에 두었습니다. 한쪽이 안 되는 상황에서 나머지가 함께 멈추지 않는 것이 이 구성의 요점입니다.
지하 주차장 입구에서 차 안에 앉은 채로 차단기를 여는 장면입니다. 개방은 근거리 경로로 처리하므로 이 자리에서 통신이 약해도 문은 열립니다.
기기와 서버를 같은 팀이 잡고 있어서 고를 수 있었던 구성이기도 합니다. 앱만 맡는 자리였다면 차단기 쪽이 무엇을 받아 주느냐가 주어진 조건이 되고, 기기만 맡는 자리였다면 이력과 초대를 서버에서 어떻게 이어 붙일지를 함께 설계할 수 없습니다. 경로를 둘로 나누려면 양쪽 끝을 동시에 만질 수 있어야 했습니다.
그러면 어느 쪽을 기본으로 두느냐
두 경로를 다 두더라도 문이 열리는 순간에 무엇을 먼저 쓸지는 정해야 합니다. 저희는 근거리 쪽을 기본으로 잡았습니다.
무인 주차에서 문을 여는 사람이 대부분 현장에 서 있기 때문입니다. 서버를 먼저 거치게 해 두면 통신이 약한 날에 매일 벌어지는 일이 함께 느려지고, 하필 그 자리가 이용자가 재시도하기 가장 어려운 자리입니다.
바꿔 말하면 지상 주차장처럼 통신이 잘 닿는 현장이라면 이렇게 나눌 이점이 크지 않습니다. 제어와 이력이 같은 경로로 흐르는 편이 단순하고 관리하기도 쉽습니다. 어느 쪽을 기본으로 둘지는 설치 환경이 정합니다.
방문객은 시스템에 등록돼 있지 않은 사람입니다
차단기를 정리하고 나니 방문 차량이 남았습니다. 실제 운영에서 손이 가장 많이 가던 쪽이고, 관리사무소가 하던 등록 절차가 없어지면 방문객은 아예 들어오지 못합니다.
여기서 막힌 지점이 조금 특이했습니다. 방문객은 오기로 한 날이 되어서야 존재를 알게 되는 사람입니다. 정기 이용자는 미리 등록해 두면 되지만 방문객은 미리 등록할 방법 자체가 없습니다.
번호판을 읽어 판단하게 만드는 방법도 있지만, 그러려면 카메라와 인식 장비가 들어가고 그때부터는 차단기 하나 여는 일이 아니게 됩니다. 앞에서 경로를 나눴던 것과 같은 이유로, 여기서도 장비를 늘리지 않는 쪽을 먼저 봤습니다.
등록을 미리 해 둘 수 있는 유일한 사람은 그를 부른 입주민이었습니다. 그래서 초대라는 절차를 만들고 그 일을 이용자에게 맡겼습니다.
등장인물이 초대하는 쪽과 들어오는 쪽뿐입니다. 사람이 상주해야 돌아가던 절차를 앱 두 개로 옮긴 것이 이번 건의 뼈대입니다.
멤버스 앱의 방문차량 등록 화면입니다. 초대하는 입주민이 차량 번호와 연락처를 넣고 입차 예정 시각까지 직접 지정합니다.
입차 예정 일자를 고르는 화면입니다. 날짜와 시각을 함께 지정하므로 지정한 구간을 벗어나면 이 초대로는 더 이상 열리지 않습니다.
초대에 시간을 붙인 것도 무인 운영이라는 조건에서 나왔습니다. 한 번 등록하면 계속 열리는 방식이면 관리사무소가 언젠가는 목록을 정리해야 하는데, 정리하는 사람이 없는 것이 이 서비스의 전제입니다. 유효한 시간이 지나면 저절로 만료되게 두면 아무도 치우지 않아도 목록이 불어나지 않습니다.
이런 식으로 「누가 이 일을 계속 해 줄 것인가」를 되묻는 과정이 이번 건 내내 반복됐습니다. 무인 운영에서는 사람이 주기적으로 손봐야 유지되는 구조가 하나라도 남아 있으면, 그 구조가 결국 시스템 전체의 수명을 정하기 때문입니다.
앱을 하나로 합치지 않은 이유
정기 이용자를 위한 멤버스 앱과 방문객을 위한 게스트 앱을 따로 만들었습니다. 하나로 합치면 배포와 유지보수가 줄어드니 당연히 먼저 검토했습니다.
나누기로 한 이유는 두 가지인데, 첫째는 같은 앱에 두 역할을 넣으면 방문객에게도 정기 이용자용 화면이 노출되고 그 화면을 가리는 조건이 늘어날수록 잘못 보일 자리도 함께 늘어난다는 것이었습니다. 둘째는 쓰는 빈도가 다르다는 점으로, 정기 이용자는 매일 여닫지만 방문객은 하루 쓰고 지웁니다.
위쪽에는 분기가 있고 아래쪽에는 없습니다. 조건으로 화면을 갈라 두면 그 조건이 틀렸을 때 남에게 보여서는 안 될 것이 보입니다.
정기 이용자용 멤버스 앱의 메인 화면입니다. 등록한 차량을 좌우로 넘겨 고르고, 아래 탭에 방문차량 초대와 프로필이 함께 있습니다.
방문객용 게스트 앱의 메인 화면입니다. 초대받은 차량 한 대만 있고 탭이 없으며, 그 자리에 입차와 출차를 한 번씩만 쓸 수 있다는 유의사항이 들어갑니다.
정책이 바뀌는 주기가 심사보다 짧았습니다
만들고 나서 운영 쪽 이야기를 듣다가 나온 항목입니다. 주차 서비스는 요금 정책이나 방문 규정이 수시로 바뀌는데, 화면이 바뀔 때마다 앱 마켓 심사를 다시 기다려야 하면 결정한 날과 반영되는 날 사이가 벌어집니다.
심사에서 실제로 곤란한 것은 통과 여부가 아니라 며칠이 걸릴지 미리 알 수 없다는 점이었습니다. 계절 요금이나 행사 기간 방문 규정처럼 며칠 단위로 적용했다 거두는 항목이 있는데, 반영에 며칠이 걸리면 적용 기간보다 대기가 길어지는 경우가 생깁니다.
아래쪽에는 길이를 알 수 없는 구간이 없습니다. 차단기에 직접 닿는 부분과 이용자가 보는 화면을 분리해 두었기 때문에 가능한 구성입니다.
이 구조가 앞에서 경로를 나눈 결정과도 맞물립니다. 차단기에 직접 닿는 부분은 한 번 검증하면 자주 손댈 일이 없는 영역이고, 요금표와 방문 규정처럼 매달 바뀌는 것은 서버와 화면 쪽에 몰려 있습니다. 바뀌는 속도가 다른 두 가지를 같은 배포 주기에 묶어 두면, 느린 쪽이 빠른 쪽의 발목을 잡습니다.
경로를 나눈 값도 같이 적어 둡니다
지금까지는 고른 쪽의 이야기이므로, 대가도 적어 두겠습니다.
개방 신호가 서버를 지나가지 않으니 이력을 올리는 경로를 따로 두어야 했고, 그만큼 구조가 하나 늘었습니다. 한 경로로만 만들었다면 제어와 이력이 같은 길로 흘러 애초에 생기지 않았을 작업이라, 이 부분은 두 경로를 다 두기로 한 대가입니다.
문을 여는 기본 경로가 근거리 쪽이라는 점도 그대로 남습니다. 무인 운영에서는 원격 개방이 예외적인 상황이라 이렇게 잡았지만, 원격 개방을 자주 쓰는 현장이라면 기본을 반대로 두는 편이 맞습니다.
확인된 범위도 정확히 적어 두면, 검수를 마쳤다는 것은 고객사가 요구한 기능이 확인됐다는 뜻이고 현장에 설치해 오래 운영한 데이터는 그다음 단계에서 쌓입니다. 지하 환경에서 개방 성공률을 따로 측정한 수치도 제시하지 않습니다. 개방이 근거리 경로로 처리되므로 이동통신 환경의 영향을 받지 않는다는 것은 이 방식의 성질에서 나오는 설명이며, 현장별 결과는 단말기가 붙는 위치와 주변 구조에 따라 달라지기 때문입니다.
차단기 제조사가 여러 곳이라 기종별 연동 범위도 이번 건에서 다룬 데까지만 확인됐고, 상가나 오피스처럼 방문 유형이 다른 시설에서의 동작은 검증 대상에 들어 있지 않았습니다.
다음은 방문의 성격이 다른 시설입니다
지금 보고 있는 것은 차단기 제조사별 연동을 넓히는 일과 주차 정산 시스템 연계, 그리고 시설 유형에 따라 방문 관리를 다시 잡는 일입니다.
시설이 달라지면 방문의 성격부터 달라집니다. 아파트는 사는 사람이 정해져 있고 방문객이 예외지만, 상가는 오는 사람 대부분이 방문객입니다. 아파트에서 만든 초대 방식을 상가에 그대로 옮길 수 있는지가 저희가 먼저 확인할 항목입니다.
