탑재되는 키오스크 SW는 Flutter를 이용하여 개발하였다. 이유는 UI 간소화, AIO 설계 (Service 규모로 나눠서) 진행이 가능하다는 점이다. 시리얼을 서비스로 건드릴 수 있다는 점 또한 장점이다. 단 상대적으로 무거운 SW 때문에 24시간에 한번정도는 자동으로 재시작한다.
2. 시스템 아키텍처 (Software Layer)
- 결제: Local TCP/IP 또는 Serial을 통해 Smartro EVCAT 모듈과 통신.
- 주차 정보: REST API (차량 조회, 입차 정보 갱신).
- 관제: Firebase RTDB (실시간 상태값 송수신).
3. 결제 모듈 연동: Smartro EVCAT과 대화
저번 화에서 언급했듯이, 사용자가 결제를 하면 바로 SW가 처리하는 것이 아니라, V-CAT이라는 소프트웨어가 카드 정보를 받고 - 카드사와 통신을 한다. ‘나는 어떤 가맹점이다. 이 항목에 대한 얼마에 대한 결제를 부탁한다’ 라고 V-CAT에게 부탁만 하면 된다. V-CAT은 ‘결제 성공’, ‘결제 실패’ 등의 메세지를 보내게 되고, 이를 통해 등록 과정으로 잇고, 로깅하면 된다. (주의 : 카드 번호 및 Holder Name은 개인정보보호법의 영향을 받으므로, Plain-Text로 저장하면 안되며, 3개월 이후 삭제를 하도록 되어있다)
Smartro 버전의 V-CAT은 EVCAT으로, 다음과 같은 UI로 구성되어 있다. 보안 인증이나 정보 처리를 직접 담당하고, 개발자는 로컬 서버에 문자열 데이터를 송신하면 된다. 이때 한국어 인코딩을 확실하게 처리해줘야 문자가 깨지지 않는다 (UTF-8 with BOM).
<결제 프로세스>
 |
 |
4. 백엔드 연동: 주차장 REST API & Firebase
현재 사용하고 있는 주차장 업체에서는 REST API를 사용하여 주차장 DB 접근이 가능하다. 기본적으로는 닫혀있기 때문에, 개발팀에 연락하여 수동 개방을 요청해야한다. 내부 DB에서 정기권, 일반권 등의 다단계 구조로 설정이 되어 있기 때문에, Query 파이프라인을 확실하게 잡아야 민감한 DB를 건드리는 문제나, 중복 처리나 예외 처리를 최소화 할 수 있다.
 |
 |
Firebase RTDB를 통해 1분마다 Heart Beat로 시스템 생존 신고를 보내, 관리자 웹에서는 온라인임을 확인할 수 있다. 각 결제, 오류, 부팅을 로컬 / 원격 DB에 로깅하고, 개인정보보호법에 저촉되는 민감 정보는 로컬에 암호화 저장한다.
5. 유지보수 자동화 로직
로컬 로그 파일은 상술한 개인정보보호법 준수를 위해 3개월 이후 자동 삭제하도록 만들었고, 하드 코딩 된 날짜 시스템 대신 config 파일 수정을 통해 날짜나 1일, 말일 오차 범위 등을 조정할 수 있다. 프로그램 Startup 배치 파일과 24시간 이후 Self Refresh 기능도 갖고 있어 어느정도 자체 검증이 가능하다.
6. 마무리 및 예고
제품의 가장 어려운 부분은 유지보수이다. 다음 편에는 실제 배포를 하며 오류 처리, DB Docs 문제, Windows OS 버전 호환성, 결제 오류, 영수증 PEBKAC 문제까지 다뤄보겠다.