자판기를 뜯지 않는다는 조건에서 시작했습니다: 통합 제어 모듈 개발기
"기기가 멈춘 걸 현장에 가서야 압니다." 이 한 문장이 저희가 받은 요구의 전부였습니다. 신형으로 바꾸면 되는 문제인데, 이미 깔린 물량 때문에 그 답은 처음부터 후보가 아니었습니다. 교체하지 않는다는 조건 하나가 나머지 설계를 어떻게 끌고 갔는지에 대한 기록입니다.
OpenIoT 플랫폼팀
기존에 설치된 자판기를 교체하지 않고 원격 제어와 운영 관리 기능을 추가하는 통합 제어 모듈을 만들었습니다. 전용 하드웨어 기판 설계부터 펌웨어까지 저희가 했고, 고객사 검수를 마친 뒤 실제 자판기에 붙여 동작까지 확인했습니다.
멈춘 것을 가서야 아는 것이 문제였습니다
무인 판매 사업의 구조적인 약점은 단순합니다. 기기가 멈췄다는 사실을 현장에 가서야 알게 되면, 멈춘 시점부터 확인한 시점까지가 그대로 팔지 못한 시간으로 남습니다. 무인으로 운영할수록 그 사이가 길어집니다.
해결책 자체는 명확했습니다. 통신 기능이 있는 신형으로 바꾸면 됩니다. 그런데 이 사업자에게는 그것이 답이 아니었습니다. 이미 깔린 물량이 많아, 전부 교체하는 순간 비용과 운영 중단 부담이 사업 계산을 넘어섭니다.
기기를 바꾸지 않고 통신 기능만 더하는 쪽으로 정하고 나니, 다음 벽이 바로 나왔습니다. 제조사와 생산 시기에 따라 통신 방식이 서로 달랐습니다.
자판기는 오래 쓰는 장비라 한 사업자가 운영하는 물량 안에도 연식이 여러 갈래로 섞여 있습니다. 같은 제조사 제품이어도 생산 시기가 다르면 통신 방식이 다를 수 있고, 그 목록은 사업자 쪽에서도 정확히 파악하고 있지 않은 경우가 많습니다.
이 조건이 뒤따르는 설계를 거의 다 결정했습니다. 어떤 기기를 만날지 미리 알 수 없다면, 만나서 확인한 뒤에 맞추는 방식이 아니라 무엇을 만나든 붙는 방식이어야 하기 때문입니다.
직접 설계해 제작한 전용 제어 기판입니다. 시리얼과 유선 네트워크, 기기 배선으로 나가는 커넥터가 각각 따로 나와 있어 한 장으로 여러 통신 방식을 받습니다.
기종마다 만드는 안을 계산해 봤습니다
먼저 검토한 것은 기종별로 전용 제어 장치를 만드는 방식이었습니다. 한 종류씩 보면 설계가 단순하고 검증할 조합도 적어서, 착수 시점만 놓고 보면 가장 빠른 길입니다.
| 방식 | 초기 비용 | 막힌 지점 |
|---|---|---|
| 통신 기능을 갖춘 신형으로 교체 | 가장 큼 | 이미 설치된 물량을 전부 바꿔야 해서 사업이 성립하지 않습니다 |
| 기종마다 전용 제어 장치를 제작 | 중간 | 기종이 늘 때마다 개발이 따라붙고, 재고 종류와 설치 실수도 같이 늘어납니다 |
| 여러 통신 방식을 한 모듈에서 지원 | 중간 | 설계와 검증이 무거워지지만, 붙이는 쪽은 한 종류만 다루면 됩니다 |
계산해 보니 둘째는 기종이 늘어날 때마다 비용이 처음부터 다시 발생하는 구조였습니다. 게다가 현장에 나간 사람이 기종을 확인하고 맞는 장치를 골라야 한다는 절차 자체가 실수가 생기기 좋은 조건입니다. 앞에서 본 것처럼 그 기종 목록조차 정확하지 않은 상태였습니다.
아래쪽에서는 현장에 나가는 사람이 기종을 따지지 않아도 됩니다. 설치 실수와 재고 관리가 함께 줄어드는 것이 이 선택의 실제 효과입니다.
모듈을 붙이는 대상입니다. 기기는 그대로 두고 안쪽에 모듈만 더하므로 겉에서 보이는 것은 달라지지 않습니다.
"그러면 모듈 하나가 비싸지지 않나요"
자연스럽게 따라오는 질문이고, 답은 「그렇습니다」입니다. 설계와 검증에 들어가는 몫이 분명히 늘어납니다.
다만 그 비용은 한 번만 발생합니다. 기종마다 만드는 방식은 기종이 늘어날 때마다 다시 발생하므로, 다루는 기종이 몇 가지를 넘어가면 어느 쪽이 싼지는 금방 갈립니다. 운영 중인 기종이 한두 가지로 고정돼 있고 늘어날 계획이 없다면, 저희도 기종별 제작을 권했을 것입니다.
통신 규격이 아예 없는 기기가 남았습니다
지원 대상으로 자판기 표준 규격과 범용 시리얼 통신을 먼저 잡았습니다. 앞의 것은 자판기 업계에서 쓰는 방식이고, 뒤의 것은 기기끼리 신호를 주고받을 때 널리 쓰이는 방식입니다.
이 둘로 상당수 기종을 덮을 수 있었는데, 목록을 훑다 보니 통신 규격 자체를 갖추지 않은 기기가 그대로 남았습니다. 오래된 기기이거나 애초에 통신을 전제하지 않고 만들어진 기기들이었습니다.
동전 투입 신호를 만들어 내기로 했습니다
여기서 방향을 한 번 더 바꿨습니다. 명령을 주고받을 방법이 없다면, 그 기기가 원래 알아듣는 신호를 만들어 주면 됩니다.
펄스 출력은 동전이 투입된 신호를 전기적으로 생성하는 구조입니다. 기기 입장에서는 누군가 동전을 넣은 것과 구분되지 않습니다.
기기가 원래 알고 있던 신호를 그대로 만들어 준다는 것이 요점입니다. 통신 규격이 없어도, 심지어 오래된 기기여도 붙일 수 있는 이유가 여기 있습니다.
기존 기기에 들어 있는 지폐인식기입니다. 투입 신호를 기기로 보내는 장치가 원래 이 자리에 있고, 모듈은 같은 모양의 신호를 만들어 냅니다.
설명만으로는 되는지 알 수 없어서 실제로 확인했습니다. 게임기에 펄스를 출력해 코인이 투입된 것으로 인식하는 동작까지 본 다음에야 지원 목록에 넣었습니다.
펄스 출력을 확인한 게임기입니다. 모듈이 만든 신호를 이 기기가 동전 투입으로 받아들이는지까지 보고 나서 지원 목록에 넣었습니다.
이 검증을 굳이 한 이유는 펄스 방식이 기기 쪽 사양서에 적혀 있는 통신 규격이 아니기 때문입니다. 표준 규격이나 시리얼 통신은 문서를 보고 맞추면 되지만, 펄스는 기기가 어떤 모양의 신호를 동전으로 받아들이는지가 기종마다 조금씩 다를 수 있습니다. 실물에 붙여 보기 전에는 된다고 말할 근거가 없었습니다.
나가 보니 멀쩡했던 경우를 줄여야 했습니다
붙이는 방식을 정리하고 나니, 원격 관리 자체보다 더 중요한 항목이 보였습니다. 무인 판매 사업은 설치 지점이 흩어져 있을수록 돈을 버는 구조인데, 같은 이유로 한 번 나갈 때마다 비용이 큽니다.
그래서 실제로 공을 들인 것은 사람이 나가야 하는 상황을 얼마나 없앨 수 있는가였습니다. 모듈은 클라우드 서버와 지속적으로 연결된 상태에서 설정값을 받고, 출고 완료와 오류 발생, 생존 신호를 실시간으로 올립니다.
세 가지 신호가 답하는 질문이 각각 다릅니다. 출고 완료는 「방금 그 결제가 실제 상품으로 나갔는가」에, 오류는 「지금 문제가 생겼는가」에, 생존 신호는 「이 기기가 아직 살아 있는가」에 답합니다. 앞의 둘만 있으면 아무 신호도 오지 않을 때 해석이 갈립니다.
생존 신호는 고장을 잡으려고 두는 것이 아니라 고장이 아닌 경우를 걸러내려고 둡니다. 가 보니 아무 문제도 없었던 경우가 쌓이면 원격 관리를 붙인 의미가 사라집니다.
유선 연결을 함께 지원한 것도 현장을 보고 정한 항목입니다. 자판기가 놓이는 자리는 사업자가 고를 수 있는 것이 아니라 건물 안쪽이나 지하처럼 무선 환경이 나쁜 곳도 많고, 무선만 지원하면 설치할 수 있는 지점이 그만큼 줄어듭니다.
앞에서 본 「교체하지 않는다」는 조건이 여기서도 그대로 작동합니다. 기기를 새로 놓는 것이라면 통신이 잘 되는 자리를 골라 놓으면 되지만, 이미 놓인 기기에 붙이는 것이라면 자리는 이미 정해져 있고 통신 조건이 나쁘다고 옮길 수도 없습니다.
소프트웨어도 현장에 가지 않고 갱신합니다
같은 이유로 원격 펌웨어 업데이트를 넣었습니다. 관리자는 설치 장소를 방문하지 않고도 운영 중인 기기의 소프트웨어를 일괄 업데이트할 수 있습니다.
갱신이 서버에서 시작해 서버에서 끝납니다. 설치 대수가 적을 때는 있으나 마나 한 기능이지만, 전국 단위로 운영하면 성격이 달라집니다. 방문 일정을 잡는 것부터가 일이 되고, 도는 동안에는 서로 다른 버전이 현장에 섞여 있게 됩니다.
버전이 섞이면 그다음 문제가 따라옵니다. 어떤 기기에서 문제가 났을 때 그것이 소프트웨어 때문인지 그 기기만의 사정인지 판단하려면 같은 버전을 돌고 있다는 전제가 필요한데, 현장이 섞여 있으면 그 전제부터 확인해야 합니다.
붙이는 방식이라 못 하는 것도 있습니다
교체하지 않는다는 조건은 이점만 주지 않았습니다. 저희가 만든 것은 기존 기기 옆에 붙는 장치이므로, 원래 기기가 하지 않는 일은 모듈을 붙여도 하게 만들 수 없습니다.
기기가 제공하지 않는 정보는 모듈도 알 수 없고, 기기가 지원하지 않는 동작은 모듈이 시킬 수 없습니다. 신형으로 교체하는 방식이라면 기기 쪽 기능부터 정의할 수 있지만, 붙이는 방식은 원래 기기가 가진 범위 안에서 움직입니다. 도입을 검토하신다면 이 경계를 먼저 확인하시는 편이 좋습니다.
여러 방식을 한 모듈에 담은 대가도 그대로 남았습니다. 검증할 조합이 늘었고, 통신 방식 하나를 추가할 때마다 기존 조합이 여전히 도는지 다시 봐야 합니다.
확인된 범위도 정확히 적겠습니다. 고객사 검수를 마쳤고 실제 자판기에 붙여 동작을 확인했으며, 펄스 출력으로 코인 투입을 인식시키는 동작과 원격 펌웨어 갱신도 각각 검증했습니다. 다만 지원 통신 방식은 위에 적은 세 가지까지이며, 목록에 없는 기종은 그때 다시 확인해야 합니다. 원격 구매나 결제 서비스와의 연동은 이번 범위에 들어 있지 않습니다.
기판과 펌웨어를 같은 팀에서 맡은 것은 여기서 이점이 됐습니다. 통신 방식마다 동작이 어긋날 때 회로를 고칠지 펌웨어를 고칠지 그때그때 정할 수 있었고, 나눠 발주했다면 어느 쪽 문제인지 가리는 데 먼저 시간을 썼을 부분입니다.
특히 펄스 출력처럼 문서가 아니라 실물로 맞춰야 하는 항목에서 차이가 났습니다. 신호 모양을 조금씩 바꿔 가며 기기가 받아들이는 지점을 찾아야 하는데, 회로와 펌웨어를 각각 다른 곳이 맡고 있으면 한 번 바꿀 때마다 요청과 대기가 붙습니다.
다음은 설치 절차를 줄이는 일입니다
지금 보고 있는 것은 지원 통신 규격을 넓히는 일, 설치 절차를 단순화하는 일, 그리고 원격 구매와 결제 서비스 연동입니다.
이 중에서 저희가 가장 비중 있게 보는 것은 설치 절차입니다. 절차가 단순해질수록 한 사람이 하루에 붙일 수 있는 대수가 늘어나고, 이 항목은 기능이 아니라 도입 기간과 직접 연결됩니다. 물량이 많은 사업자일수록 「되느냐」보다 「얼마나 걸리느냐」를 먼저 묻기 때문입니다.
