자판기 통합 제어 보드와 원격 관제
하드웨어 · 펌웨어 · 클라우드2026.04
제조사마다 다른 자판기 통신 규격 세 가지를 한 보드에서 받고, 결제와 매출과 장애를 클라우드로 올리는 제어 모듈을 만들었습니다.

과제 배경
자판기는 제조사마다 통신 규격이 MDB, RS232, Pulse 로 갈립니다. 규격마다 보드를 따로 만들면 재고가 세 종류가 되고, 현장에 어느 것이 깔렸는지도 매번 확인해야 합니다. 게다가 자판기 안은 고전압에 노이즈가 심해서 일반 통신 보드를 그대로 넣으면 오래 버티지 못합니다.
주요 설계 결정
통신 규격
MDB, RS232, Pulse 프로토콜 스택을 한 보드에 모두 올렸습니다
보드를 규격별로 나누면 생산과 재고와 현장 대응이 세 벌이 됩니다. 부품값이 조금 오르는 대신 그 세 벌을 한 벌로 만들었습니다.
MCU 보호
외부 장치와 MCU 사이를 고속 포토커플러로 전기적으로 끊었습니다
자판기 내부의 고전압과 노이즈가 그대로 MCU 에 닿으면 현장에서 죽습니다. 회수 비용이 부품값보다 큽니다.
네트워크 스택
ESP32-S3 에 W5500 을 붙여 TCP/IP 를 하드웨어로 처리했습니다
소프트웨어 스택은 노이즈 환경에서 재접속이 잦습니다. 결제 명령이 오가는 구간이라 연결이 끊기면 상품이 안 나오거나 두 번 나옵니다.
펌웨어 배포
Dual Bank OTA 로 두 벌을 두고 실패하면 이전 것으로 되돌립니다
수천 대에 한 번에 나가는 배포입니다. 한 번 잘못 나가면 전량이 벽돌이 되고 그때는 사람이 다 찾아가야 합니다.
제공 기능
| 기능 | 내용 |
|---|---|
| 모바일 결제 연동 | 앱에서 승인이 나면 자판기 통신 규격에 맞는 배출 명령으로 바꿔 보냅니다. |
| 기기별 매출 추적 | MAC 주소와 시리얼 번호를 짝지어 어느 기기에서 얼마가 팔렸는지 가립니다. |
| 원격 장애 보고 | 에러가 나면 표준 코드를 실어 즉시 올립니다. 현장 점검을 나가기 전에 원인을 봅니다. |
| 일괄 OTA | 수천 대 단위로 펌웨어를 내보내고 실패한 기기만 따로 셉니다. |
수행 결과
- 자판기 모델이 달라도 보드를 새로 만들지 않습니다. 규격 세 가지를 한 보드가 받습니다.
- 펌웨어 배포가 실패해도 기기는 이전 버전으로 계속 팝니다. 배포 때문에 멈추는 시간이 없습니다.
- 결제와 매출 데이터가 오가는 구간 전체를 MQTTS 로 암호화했습니다.
- 장애를 표준 에러 코드로 올려서 현장에 가기 전에 무엇이 났는지 압니다.
시스템 구성도
점선은 외부 서비스를 사용하는 항목입니다.
설계 원칙
| 원칙 | 적용 방법 |
|---|---|
| 배포가 실패해도 기기는 계속 판다 | Dual Bank OTA. 부팅 실패면 이전 뱅크로 되돌립니다 |
| 결제 구간은 평문으로 오가지 않는다 | MQTTS 강제. 인증서 없는 기기는 브로커가 거부합니다 |
| 고전압이 MCU 에 닿지 않는다 | 포토커플러 절연. 회로에서 경로가 끊겨 있습니다 |
적용 기술
ESP32ESP32-S3W5500CC++AWS IoT CoreMQTTPCBOTA


