[무인정산기]는 어떻게 동작할까? 차량 조회·요금 계산·할인·결제·출차 승인 흐름

무인정산기는 어떻게 동작할까? 차량 조회·요금 계산·할인·결제·출차 승인 흐름#

1장 무인정산기에서 결제 버튼을 누르면 어떤 일이 일어날까#

운전자가 무인정산기 앞에서 차량번호를 입력하거나 주차권을 스캔했다고 하겠습니다.

사용자 화면에서는 단순합니다.

차량 조회
↓
주차요금 표시
↓
카드 결제
↓
결제 완료

하지만 실제 시스템에서는 여러 서버와 장비가 연결됩니다.

운전자
↓
무인정산기
↓
차량·입차 기록 조회
↓
요금 계산
↓
할인 조회
↓
최종 결제금액 확정
↓
결제 단말·결제 시스템
↓
승인 결과
↓
주차 Server
↓
출차 가능 상태 반영
↓
출구 차단기

따라서 다음 상태는 모두 다릅니다.

차량을 찾았다.

요금을 계산했다.

결제를 요청했다.

결제가 승인됐다.

Server에 정산 결과를 저장했다.

출차 가능 상태가 됐다.

차량이 실제로 출차했다.

현장 장애를 분석할 때는 이 상태들을 하나의 결제 완료로 묶어버리지 않는 것이 중요합니다.

2장 무인정산기는 여러 시스템을 연결하는 중간 지점이다#

무인정산기는 단순한 카드 결제기가 아닙니다.

일반적으로 다음 요소와 연결됩니다.

차량번호인식 Server

주차권 시스템

주차요금 Server

할인 System

결제 단말

영수증 Printer

중앙 주차관제 Server

출구 Controller

역할을 나누면 다음처럼 볼 수 있습니다.

차량 식별#

차량번호

Ticket ID

Barcode

QR Code

회원 정보

등을 이용해 어떤 차량을 정산할 것인지 결정합니다.

주차요금 계산#

입차시간과 요금 정책을 이용해 현재 요금을 결정합니다.

할인 적용#

무료시간, 쿠폰, 매장 할인, 회원 할인 등의 조건을 적용합니다.

결제#

최종 금액을 결제 단말 또는 결제 시스템으로 전달하고 승인 결과를 받습니다.

출차 가능 상태 반영#

정상 결제가 완료되면 해당 차량을 일정 조건에서 출차 가능한 상태로 변경합니다.

즉 무인정산기는 차량 정보·요금·할인·결제·출차 제어를 연결하는 업무 단말이라고 볼 수 있습니다.

3장 첫 번째 단계는 차량 조회다#

무인정산기가 가장 먼저 알아야 하는 것은:

누구의 주차요금을 계산할 것인가?

입니다.

차량을 찾는 방법은 여러 가지입니다.

차량번호 직접 입력

LPR 검색

주차권 Barcode

QR Code

Ticket ID

RFID·회원정보

예를 들어 차량번호 기반이라면:

12가3456
↓
Parking Server
↓
입차 기록 검색

이 이루어집니다.

Server는 다음과 같은 정보를 반환할 수 있습니다.

{
  "parkingId": "P-20260924-00125",
  "vehicleNumber": "12가3456",
  "enteredAt": "2026-09-24T08:31:12+09:00",
  "laneId": "IN-02",
  "status": "PARKED"
}

여기서 중요한 것은 차량번호 문자열 하나만으로 모든 것을 판단하지 않는 것입니다.

같은 차량에 여러 기록이 존재할 수 있으므로 실제 시스템에서는:

Parking ID

입차시간

현재 상태

Site

Lane

같은 정보를 함께 사용해야 합니다.

4장 요금 조회는 단순히 시간에 단가를 곱하는 작업이 아니다#

입차 기록을 찾았다면 현재 주차요금을 계산해야 합니다.

가장 단순한 계산은:

주차시간
×
시간당 요금

처럼 보이지만 실제 주차요금 정책은 훨씬 복잡할 수 있습니다.

예:

최초 30분 무료

기본 30분 1,000원

추가 10분당 500원

일 최대 20,000원

야간 요금

주말 요금

정기권

회차 차량

무료 회차 시간

따라서 일반적으로는:

입차 기록
↓
요금 정책 조회
↓
주차시간 계산
↓
기본요금 계산
↓
할인 적용
↓
최종 금액

순서로 처리합니다.

요금 계산은 어디에서 할까#

두 가지 구조가 가능합니다.

Server 계산#

Kiosk
↓
요금 조회 요청
↓
Server
↓
최종 요금 반환

장점은 모든 무인정산기가 동일한 정책을 사용하기 쉽다는 것입니다.

Kiosk 계산#

Server
↓
요율 정보 동기화
↓
Kiosk
↓
Local 계산

Network가 단절된 상황에 대응하기 쉬울 수 있지만 요금 정책 Version 관리가 중요해집니다.

실무에서는 어느 시스템이 요금 계산의 최종 권한을 갖는지 명확하게 정하는 것이 중요합니다.

5장 할인은 결제 전에 확정해야 한다#

주차 할인은 다양한 출처에서 들어올 수 있습니다.

매장 할인

방문객 할인

회원 할인

쿠폰

무료주차권

정기권

장애인·운영 정책 할인

예를 들어 기본 요금이:

8,000원

이고 매장 할인이:

3,000원

이면:

최종 결제
5,000원

이 될 수 있습니다.

하지만 할인 처리에서는 단순 금액 계산보다 사용 상태 관리가 중요합니다.

예를 들어 쿠폰 하나를 동시에 두 Kiosk에서 적용하면:

쿠폰 1장
↓
Kiosk A 적용

동시에

Kiosk B 적용

같은 문제가 발생할 수 있습니다.

따라서 할인에는 다음 정보가 필요할 수 있습니다.

Discount ID

적용 대상

사용 가능 여부

사용 시각

적용 금액

중복 가능 여부

취소 가능 여부

결제가 실패했을 때 이미 사용 처리한 할인을 다시 복구해야 하는지도 정책으로 정해야 합니다.

6장 최종 금액이 확정된 뒤 결제를 요청한다#

차량과 요금, 할인이 모두 확정되면 최종 결제 금액이 만들어집니다.

예:

기본 주차요금
8,000원

할인
-3,000원

결제금액
5,000원

그다음 결제 단계로 넘어갑니다.

개념적으로:

Kiosk
↓
Payment Request
↓
결제 단말·결제 시스템
↓
승인 처리
↓
Payment Response

결제 결과에는 시스템에 따라 다음 정보가 포함될 수 있습니다.

Transaction ID

승인 여부

승인번호

승인시간

결제금액

결제수단

오류 코드

무인정산기 Application이 카드번호 전체를 직접 취급하도록 설계하기보다 결제 단말과 결제 사업자가 제공하는 안전한 Interface를 이용해 결제정보 노출을 최소화하는 것이 중요합니다.

7장 결제 승인이 왔다고 출차가 끝난 것은 아니다#

이 부분이 무인정산기 설계에서 매우 중요합니다.

결제 단말에서:

APPROVED

가 반환됐다고 하겠습니다.

아직 전체 업무는 끝나지 않았습니다.

Payment APPROVED
↓
거래 결과 저장
↓
Parking 상태 변경
↓
출차 유효시간 설정
↓
Exit Server 동기화
↓
출구 차량 인식
↓
출차 허용
↓
Barrier OPEN
↓
실제 차량 통과

따라서:

PAYMENT_APPROVED

와:

EXIT_ALLOWED

그리고:

VEHICLE_EXITED

는 모두 다른 상태입니다.

예를 들어 결제는 성공했는데 Parking Server 저장에 실패한다면 운전자는 결제했지만 출구에서는:

미정산 차량

으로 인식될 수 있습니다.

이런 경우를 대비한 복구 정책이 필요합니다.

8장 상태를 세분화하면 장애 추적이 쉬워진다#

단순히:

PAID

하나만 저장하기보다 처리 단계를 세분화할 수 있습니다.

예:

PARKED

FEE_CALCULATED

PAYMENT_REQUESTED

PAYMENT_APPROVED

PAYMENT_RECORDED

EXIT_ALLOWED

EXITED

실패 상태도 별도로 관리할 수 있습니다.

VEHICLE_NOT_FOUND

FEE_ERROR

DISCOUNT_ERROR

PAYMENT_FAILED

SYNC_PENDING

EXIT_AUTH_FAILED

그러면 장애가 발생했을 때:

결제가 안 됐다.

가 아니라:

결제 승인은 성공했지만
Parking Server에 거래 반영이 실패했다.

까지 구체적으로 확인할 수 있습니다.

9장 API에서는 Transaction ID와 Idempotency가 중요하다#

현대적인 시스템에서는 Kiosk와 Server가 HTTPS API로 통신할 수 있습니다.

예를 들어 요금 조회:

POST /api/parking/fee
Content-Type: application/json

{
  "parkingId": "P-20260924-00125",
  "vehicleNumber": "12가3456"
}

응답:

{
  "parkingId": "P-20260924-00125",
  "baseAmount": 8000,
  "discountAmount": 3000,
  "payableAmount": 5000,
  "currency": "KRW"
}

결제 완료 등록에는 별도의 Transaction ID를 사용할 수 있습니다.

{
  "transactionId": "TX-20260924-003421",
  "parkingId": "P-20260924-00125",
  "amount": 5000,
  "paymentStatus": "APPROVED"
}

왜 Transaction ID가 중요한가#

Kiosk가 요청을 보냈습니다.

Kiosk
↓
결제 결과 저장 요청
↓
Server

Server에서는 정상 처리했습니다.

하지만 Response가 Network에서 유실됐습니다.

Kiosk 입장에서는:

Timeout

입니다.

같은 요청을 다시 전송하면 Server가 이를 새로운 거래로 판단할 수도 있습니다.

그래서:

Transaction ID

Request ID

Idempotency Key

등을 이용해 동일 요청을 식별할 수 있게 합니다.

핵심 원칙은:

재전송은 허용하되 업무 결과는 중복 적용되지 않도록 설계하는 것입니다.

10장 Offline Mode는 단순히 인터넷 없이 결제하는 기능이 아니다#

현장에서는 중앙 Server나 Network가 일시적으로 끊길 수 있습니다.

Kiosk
X
Central Server

이때 운영 정책에 따라 Limited Offline Mode를 사용할 수도 있습니다.

예를 들어 Local에 다음 정보를 Cache할 수 있습니다.

최근 입차 기록

요금 정책

할인 정책 일부

미전송 거래

하지만 Offline 처리는 상당히 조심해야 합니다.

특히:

결제 승인

할인 사용

출차 허용

거래 정산

은 데이터 정합성이 중요합니다.

Network 복구 후에는:

Local Queue
↓
Server 재전송
↓
Transaction ID 검사
↓
중복 제거
↓
Conflict 확인
↓
동기화 완료

과정이 필요할 수 있습니다.

모든 무인정산기가 반드시 Offline 결제를 지원해야 하는 것은 아니며 결제 방식과 운영 정책에 따라 지원 범위를 결정해야 합니다.

11장 영수증 출력도 별도의 완료 상태다#

결제가 승인되면 영수증을 출력할 수 있습니다.

하지만:

결제 성공

과:

영수증 출력 성공

도 다른 상태입니다.

예:

Payment
APPROVED

Receipt Printer
PAPER_EMPTY

상황이 발생할 수 있습니다.

이때 이미 승인된 결제를 Printer 오류 때문에 다시 결제하면 안 됩니다.

따라서:

PAYMENT_APPROVED
↓
RECEIPT_PRINT_REQUESTED
↓
RECEIPT_PRINTED

처럼 별도로 처리하는 편이 안전합니다.

Printer 실패 시에는:

재출력

전자영수증

관리자 호출

등의 운영 정책을 사용할 수 있습니다.

12장 출차 승인은 차단기 OPEN 명령과도 다르다#

결제 완료 후 Server가:

EXIT_ALLOWED

로 상태를 변경했다고 하겠습니다.

아직 차단기가 열린 것은 아닙니다.

출구에서는 다시:

차량 접근
↓
차량번호 인식
↓
Parking Record 조회
↓
EXIT_ALLOWED 확인
↓
Gate Controller
↓
OPEN Command
↓
Barrier OPENED
↓
차량 통과

과정이 이어질 수 있습니다.

따라서 다음 세 상태를 구분합니다.

정산 완료

출차 허용

차단기 개방

그리고 최종적으로:

실제 차량 출차

까지 확인해야 하나의 주차 Transaction이 완전히 종료됩니다.

13장 장애는 업무 단계별로 추적한다#

무인정산기에서:

결제가 안 됩니다.

라는 신고가 들어왔다고 하겠습니다.

처음부터 카드 단말기를 의심하지 않습니다.

차량 조회 단계#

Ticket ID 정상?

차량번호 정상?

입차 Record 존재?

Server 연결 정상?

요금 단계#

입차시간 정상?

요금 정책 Version 정상?

무료시간 계산 정상?

할인 적용 정상?

결제 단계#

결제 단말 연결?

Payment Request 생성?

승인 Response?

Transaction ID?

저장 단계#

결제 결과 DB 저장?

Parking 상태 변경?

Queue 적재?

출차 단계#

EXIT_ALLOWED?

출구 Server 동기화?

LPR 조회?

Gate Controller 정상?

이렇게 보면 하나의 장애를 단계별로 좁힐 수 있습니다.

14장 로그에는 한 거래를 다시 조립할 수 있는 정보가 있어야 한다#

무인정산기 장애는 여러 시스템에 걸쳐 발생합니다.

따라서 단순한:

Payment success

로그만으로는 부족합니다.

예:

10:15:01.100
SESSION
S-00123

10:15:02.020
VEHICLE_LOOKUP
12가3456

10:15:02.130
PARKING_FOUND
P-000998

10:15:02.180
FEE_CALCULATED
8000

10:15:05.410
DISCOUNT_APPLIED
3000

10:15:10.200
PAYMENT_REQUEST
TX-00872

10:15:11.410
PAYMENT_APPROVED
5000

10:15:11.510
PAYMENT_RECORDED

10:15:11.530
EXIT_ALLOWED

처럼 하나의 거래가 연결되어야 합니다.

유용한 식별자는 다음과 같습니다.

Session ID

Parking ID

Transaction ID

Request ID

Vehicle ID

Kiosk ID

분산 시스템이라면 Trace ID를 함께 사용해 여러 Server의 Log를 연결하는 것도 유용합니다.

15장 결제와 개인정보는 다른 장비보다 더 엄격하게 다룬다#

무인정산기는:

차량번호

입출차 시간

결제 정보

할인 정보

거래 기록

등 민감할 수 있는 정보를 다룹니다.

따라서 다음 원칙이 중요합니다.

필요한 정보만 수집

통신 암호화

접근 권한 최소화

관리자 인증

Log Masking

보존 기간 관리

Audit Log

특히 카드번호 전체나 보안코드 같은 민감한 결제정보를 Application Log에 그대로 남기는 방식은 피해야 합니다.

결제정보 처리는 사용하는 결제 단말·결제 사업자의 보안 구조를 따르고, Kiosk Application이 불필요하게 카드정보를 직접 저장하지 않도록 설계하는 것이 중요합니다.

관리용 Interface 역시 일반 이용자 Network와 분리하고 불필요한 원격 접근을 제한하는 것이 좋습니다.

16장 자기 점검#

무인정산기가 가장 먼저 해야 하는 일은 무엇인가#

차량번호나 Ticket ID 등을 이용해 현재 정산하려는 차량의 유효한 입차 기록을 찾는 것입니다.

요금 계산은 반드시 Kiosk가 해야 하는가#

아닙니다. 중앙 Server가 계산할 수도 있고 정책을 내려받아 Kiosk에서 계산할 수도 있습니다. 중요한 것은 어느 쪽이 최종 기준인지 명확하게 정하는 것입니다.

결제 승인과 출차 승인은 같은 것인가#

아닙니다. 결제가 승인된 뒤 거래 저장과 Parking 상태 변경 등이 완료되어야 출차 가능 상태가 될 수 있습니다.

Timeout이 발생하면 같은 요청을 다시 보내도 되는가#

재전송 자체는 필요할 수 있지만 Transaction ID나 Idempotency Key 등을 이용해 업무 결과가 중복 적용되지 않도록 해야 합니다.

결제가 됐는데 영수증 Printer가 고장 나면 다시 결제해야 하는가#

아닙니다. 결제 결과와 영수증 출력 상태를 별도로 관리하고 재출력 등의 복구 절차를 사용해야 합니다.

17장 이 글을 마치며#

무인정산기의 전체 업무 흐름을 정리하면 다음과 같습니다.

운전자
↓
차량번호 / Ticket 입력
↓
차량 조회
↓
입차 Record
↓
요금 계산
↓
할인 조회·적용
↓
최종 금액 확정
↓
Payment Request
↓
Payment Approved
↓
거래 결과 저장
↓
Parking 상태 변경
↓
EXIT_ALLOWED
↓
출구 차량 인식
↓
Barrier OPEN
↓
차량 출차

특히 다음 내용을 기억하면 됩니다.

무인정산기는 단순한 결제 단말이 아니라 차량 식별·요금 계산·할인·결제·주차 상태·출차 제어를 연결하는 업무 시스템입니다.

차량 조회·요금 계산·할인 적용·결제 승인·거래 저장·출차 승인은 각각 다른 처리 단계이며 하나의 성공 여부로 합쳐 판단해서는 안 됩니다.

결제와 같은 중요한 요청은 Network Timeout 때문에 동일 요청이 다시 전송될 수 있으므로 Transaction ID·Request ID·Idempotency를 이용한 중복 방지 구조가 중요합니다.

결제가 승인됐다고 실제 출차가 완료된 것이 아니며 결제 결과 저장 → 출차 허용 → 차단기 개방 → 차량 통과까지 별도의 상태로 추적해야 합니다.

Offline Mode를 지원한다면 Local Queue와 Cache만 만드는 것으로 끝나지 않고 Network 복구 후 재전송·중복 제거·충돌 해결까지 함께 설계해야 합니다.

결국 무인정산기를 이해한다는 것은 카드 결제 API 하나를 이해하는 것이 아닙니다.

차량이 누구인지 찾는 순간부터 요금을 확정하고 돈을 받은 뒤, 그 사실을 주차관제 시스템 전체에 일관되게 반영해 실제 차량이 출구를 통과할 수 있도록 만드는 하나의 Transaction 흐름을 이해하는 것이 핵심입니다.

[무인정산기]는 어떻게 동작할까? 차량 조회·요금 계산·할인·결제·출차 승인 흐름