'주차관제 장비가 안 됩니다'를 기술적 장애로 구체화하는 방법

'주차관제 장비가 안 됩니다'를 기술적 장애로 구체화하는 방법#

1장 “차단기가 안 열립니다”는 장애 원인이 아니다#

1.1 사용자가 보는 것은 마지막 결과다#

주차장 관리자에게 다음과 같은 연락을 받았다고 가정해보겠습니다.

1번 입구 차단기가 안 열립니다.

사용자 입장에서는 충분한 설명입니다.

하지만 기술적으로는 원인을 판단할 수 없습니다.

실제로는 다음 중 하나일 수 있습니다.

차량 감지 Sensor가 차량을 감지하지 못했다.

LPR Camera가 차량을 촬영하지 못했다.

Camera는 촬영했지만 번호판 인식에 실패했다.

번호판은 인식했지만 Server로 전송되지 않았다.

Server는 정보를 받았지만 차량 조회에 실패했다.

무료 차량이나 등록 차량 판단에 실패했다.

Server가 OPEN 명령을 보내지 않았다.

OPEN 명령은 보냈지만 Controller가 받지 못했다.

Controller가 명령을 받았지만 Relay가 동작하지 않았다.

Relay는 동작했지만 Barrier Motor가 움직이지 않았다.

Barrier는 열렸지만 Open Sensor가 상태를 확인하지 못했다.

실제로는 정상 동작했지만 관제 화면 상태만 갱신되지 않았다.

사용자는 이 모든 상황을:

차단기가 안 열린다.

라고 표현할 수 있습니다.

따라서 장애 분석의 첫 번째 작업은 장비 교체나 재부팅이 아닙니다.

차량 한 대의 처리 과정에서 어느 단계까지 정상이고 어디부터 실패했는지를 확인하는 것입니다.

2장 주차관제 장애는 하나의 사건을 따라가야 한다#

2.1 차량 한 대가 입차하는 과정#

일반적인 자동 입차 과정을 단순화하면 다음과 같습니다.

차량 접근
↓
Loop Sensor 감지
↓
LPR Camera Trigger
↓
차량 이미지 촬영
↓
번호판 인식
↓
인식 결과 Server 전송
↓
등록 차량·할인·권한 조회
↓
입차 허용 판단
↓
Gate OPEN 명령
↓
Gate Controller 수신
↓
Relay 출력
↓
Barrier Motor 동작
↓
Open Sensor 감지
↓
입차 Event 저장
↓
관제 화면 상태 갱신

어느 하나만 실패해도 최종적으로는:

입차가 안 된다.

라는 신고가 들어올 수 있습니다.

2.2 장애 분석의 핵심 질문#

따라서 가장 중요한 질문은 다음입니다.

이 차량 사건에서 마지막으로 정상 확인된 단계는 어디인가?

그리고:

처음 비정상이 확인된 단계는 어디인가?

예를 들어:

Loop Sensor 감지      정상
Camera 촬영           정상
번호판 인식           정상
Server 전송           정상
등록 차량 조회        정상
OPEN 명령 생성        정상
Controller 수신       정상
Relay 출력            실패

라면 LPR Camera나 Server Network를 계속 확인하는 것은 우선순위가 낮습니다.

장애 영역은:

Controller 출력
↓
Relay
↓
Barrier Interface

쪽으로 좁혀집니다.

3장 좋은 주차관제 장애 설명은 무엇이 다른가#

3.1 나쁜 장애 설명#

입구 차단기 고장.

분석에 필요한 정보가 거의 없습니다.

3.2 조금 나아진 설명#

오전부터 1번 입구 차단기가 자동으로 열리지 않습니다.

시간과 위치는 알 수 있습니다.

하지만 아직 부족합니다.

3.3 분석 가능한 장애 설명#

2026-09-24 08:42부터
B1 입구 1차로에서
LPR-01은 차량번호를 정상 인식하고
Parking Server에도 차량번호가 등록되지만
GATE-01로 OPEN 명령이 전달된 뒤
Barrier가 실제로 열리지 않는다.

관제 화면에는 OPEN CMD 전송 기록이 있으며
수동 OPEN 버튼으로도 동일하게 동작하지 않는다.

이 문장에는 상당한 정보가 있습니다.

발생 시각
→ 08:42

위치
→ B1 입구 1차로

장비
→ LPR-01 / GATE-01

정상 지점
→ 번호판 인식, Server 등록, OPEN 명령 생성

실패 지점
→ Barrier 물리 동작

추가 증거
→ 수동 OPEN도 실패

이제 Camera 인식이나 차량 DB보다 Gate Controller 이후의 영역을 우선 확인할 수 있습니다.

4장 주차관제 장애를 정의할 때 반드시 적어야 할 정보#

4.1 차로 ID#

예:

ENT-B1-01
EXIT-B2-02

주차장에서는 동일한 장비가 여러 차로에 반복 배치되기 때문에 단순히:

입구 Camera

라고 기록하면 나중에 어느 장비인지 찾기 어렵습니다.

4.2 장비 ID#

가능하다면 다음을 함께 기록합니다.

LPR-01

GATE-01

LOOP-01

KIOSK-02

SERVER-PARK-01

SW-B1-01

4.3 차량 식별 정보#

장애 사건을 찾을 때 차량번호가 매우 중요한 Correlation Key가 될 수 있습니다.

예:

차량번호
12가3456

발생 시각
10:31:24

차로
ENT-B1-01

다만 차량번호는 개인정보에 해당할 수 있으므로 내부 정책에 따라 Masking이나 접근 제한을 적용해야 합니다.

4.4 발생 시각#

예:

2026-09-24 10:31:24

가능하면:

대략 오전 10시쯤

보다 정확한 시각을 확보합니다.

4.5 기대 결과와 실제 결과#

예:

기대 결과
등록 차량이므로 Barrier 자동 OPEN

실제 결과
차량번호 인식 후 Barrier CLOSE 유지

이 차이가 장애 정의의 핵심입니다.

5장 차량 한 대를 Correlation ID처럼 사용한다#

주차관제에서는 하나의 차량 사건이 여러 시스템에 흔적을 남깁니다.

예:

차량번호
12가3456

시각
10:31:24

차로
ENT-B1-01

이 세 정보를 기준으로 여러 Log를 연결할 수 있습니다.

LPR Log
12가3456 인식

Parking Server
12가3456 조회

Access Logic
등록 차량 확인

Gate Command Log
OPEN GATE-01

Controller Log
OPEN CMD received

Barrier Sensor
OPEN status

즉 차량 한 대의 사건을 여러 시스템 Log에서 다시 조립하는 것이 핵심입니다.

6장 가장 먼저 영향 범위를 확인한다#

6.1 한 차량만 실패하는가#

예:

12가3456 X

다른 차량 O

라면:

차량 등록 정보

번호판 인식 결과

할인·권한

Black/White List

차량 DB

등 업무 데이터 문제일 가능성을 확인할 수 있습니다.

6.2 특정 차로만 실패하는가#

예:

입구 1차로 X

입구 2차로 O

출구 O

이면 해당 차로의:

LPR

Loop Sensor

Gate Controller

Switch Port

Cable

Relay

Barrier

등 독립적인 구성요소를 우선 확인합니다.

6.3 모든 입구가 동시에 실패하는가#

예:

입구 1차로 X
입구 2차로 X
입구 3차로 X

이 경우 공통 요소를 봅니다.

Parking Server

Database

Core Switch

Firewall

Authentication Service

License Server

6.4 입차는 되는데 출차만 안 되는가#

이런 기능 범위도 중요합니다.

입차 O

출차 X

라면:

출차 요금 계산

결제 연동

출차 Gate Controller

출차 Network

정산 Server

등 출차에만 존재하는 구성요소를 확인할 수 있습니다.

7장 “번호판 인식이 안 됩니다”도 여러 문제다#

LPR 장애 신고는 특히 세분화해야 합니다.

7.1 Camera 영상 자체가 없다#

Camera Offline

영상 없음

확인 영역:

Power

PoE

Cable

Switch Port

Camera Boot

7.2 영상은 있는데 차량이 촬영되지 않는다#

확인 영역:

Trigger Sensor

Detection Area

Camera Angle

Exposure

Trigger Signal

7.3 차량은 촬영됐지만 번호판을 못 읽는다#

확인 영역:

영상 품질

조명

Shutter

Focus

OCR / LPR Engine

번호판 각도

오염

7.4 번호판은 인식했는데 Server에 없다#

확인 영역:

LPR Application

Network

API

TCP

HTTP

Authentication

Server

즉:

번호판 인식 실패

와:

인식 결과 전송 실패

는 완전히 다른 문제입니다.

8장 “차단기가 안 열립니다”도 세분화한다#

8.1 OPEN 명령 자체가 생성되지 않았다#

확인:

차량 인식

등록 여부

요금 상태

업무 Rule

Server Logic

8.2 Server에서 OPEN 명령은 생성됐다#

다음 질문입니다.

Controller까지 도착했는가?

확인:

Server Log

Packet Capture

Controller Log

8.3 Controller는 명령을 받았다#

그렇다면:

Relay 출력이 발생했는가?

를 확인합니다.

8.4 Relay까지 정상이다#

다음은:

Barrier Motor

Limit Sensor

Safety Sensor

전원

제어 배선

영역입니다.

전체를 연결하면:

OPEN 판단
↓
OPEN Command
↓
Network
↓
Controller
↓
Relay
↓
Barrier
↓
Open Sensor

입니다.

9장 “정산이 안 됩니다”도 단계로 나눈다#

정산기에서:

결제가 안 됩니다.

라는 신고가 들어왔다고 가정합니다.

실제 과정은:

차량 조회
↓
입차 기록 조회
↓
주차 시간 계산
↓
요금 계산
↓
할인 적용
↓
결제 요청
↓
PG / VAN 통신
↓
승인
↓
결제 결과 저장
↓
출차 가능 상태 변경

입니다.

따라서 질문해야 합니다.

차량 조회는 되는가?

요금은 표시되는가?

카드 입력은 되는가?

승인 요청이 나가는가?

승인 결과가 오는가?

Server에 결제 결과가 저장되는가?

10장 마지막 정상 지점과 최초 실패 지점을 찾는다#

정산 장애 예:

차량 조회            O
입차 기록            O
요금 계산            O
카드 입력            O
결제 승인 요청       O
PG 응답              O
결과 DB 저장         X

이라면 카드 Reader나 Network Cable보다:

Application

Database

Transaction 처리

를 우선 확인합니다.

11장 로그는 장비 하나만 보면 안 된다#

차량 한 대가 입차하는 과정에는 여러 Log가 존재할 수 있습니다.

Loop Controller Log
↓
LPR Log
↓
Switch / Network Log
↓
Parking Server Log
↓
Database Log
↓
Gate Controller Log
↓
Barrier Event Log

이것을 같은 시간축에서 연결합니다.

12장 LPR Log에서 무엇을 확인할까#

대표적으로:

Trigger 시각

촬영 시각

인식 차량번호

인식 신뢰도

Image 저장 위치

Server 전송 여부

Server 응답

등을 볼 수 있습니다.

예:

10:31:24.120
trigger

10:31:24.240
plate=12가3456

10:31:24.310
POST /api/entry

10:31:24.350
HTTP 200

이런 Log가 있다면 Camera에서 Server까지 상당 부분 정상임을 확인할 수 있습니다.

13장 Parking Server Log에서 무엇을 확인할까#

예:

Request 수신

차량번호

차로 ID

차량 조회 결과

입차 허용 여부

할인·정기권

OPEN Command 생성

Controller 전송

Response

예:

10:31:24.350
ENTRY EVENT
plate=12가3456

10:31:24.370
vehicle=REGISTERED

10:31:24.380
access=ALLOW

10:31:24.390
OPEN GATE-01

입니다.

14장 Gate Controller Log에서 무엇을 확인할까#

예:

Server Connection

Command 수신

Command ID

Relay Output

Sensor Input

Error Code

예:

10:31:24.405
CMD OPEN received

10:31:24.408
RELAY1 ON

10:31:24.900
OPEN SENSOR timeout

라면 Network보다 Barrier Hardware나 Sensor 영역을 우선 확인할 수 있습니다.

15장 한 사건의 시간축을 만들어보자#

예를 들어 다음과 같습니다.

10:31:24.100
Loop Sensor ON

10:31:24.120
LPR Trigger

10:31:24.240
Plate 12가3456

10:31:24.310
Server Request

10:31:24.350
Server Receive

10:31:24.370
Vehicle Registered

10:31:24.390
OPEN Command

10:31:24.405
Controller Receive

10:31:24.408
Relay ON

10:31:25.500
Open Sensor Timeout

그러면 장애 위치가 상당히 명확해집니다.

인식
O

Server
O

Network
O

Controller
O

Relay
O

Barrier Open 확인
X

16장 주차관제에서는 시간 동기화가 특히 중요하다#

각 장비 시간이 다르면 같은 차량 사건을 연결하기 어렵습니다.

예:

LPR
10:31:24

Server
10:29:52

Gate Controller
10:34:01

이 상태에서는 Log Correlation이 매우 어렵습니다.

따라서:

NTP

Timezone

Clock Drift

를 확인합니다.

16.1 모든 장비가 NTP를 지원하지 않을 수도 있다#

산업용 Controller나 오래된 장비는 시간 동기 기능이 제한될 수 있습니다.

이 경우:

Server 수신 시각

Switch Log 시각

장비 Local 시각

의 차이를 기록해 보정하여 분석할 수 있습니다.

17장 재현할 때 차량과 조건을 고정한다#

재현할 때 매번 다른 차량으로 테스트하면 조건이 달라질 수 있습니다.

가능하면 시험 환경에서:

동일 차량

동일 차로

동일 시간대 조건

동일 등록 상태

동일 할인 조건

으로 테스트합니다.

예:

Test Vehicle
99가9999

Lane
ENT-B1-01

Vehicle Type
등록 차량

처럼 조건을 명확히 합니다.

18장 수동 동작과 자동 동작을 비교하면 범위가 줄어든다#

예를 들어 자동으로 Gate가 열리지 않는다고 하겠습니다.

자동 OPEN#

차량 감지
↓
LPR
↓
Server
↓
OPEN
↓
실패

관제 화면 수동 OPEN#

Operator
↓
Server
↓
OPEN
↓
성공

이면 Barrier Hardware 자체는 정상일 가능성이 높아집니다.

문제 범위는:

LPR

차량 판단

자동 OPEN Logic

쪽으로 이동합니다.

18.1 수동 OPEN도 실패한다면#

자동 OPEN X
수동 OPEN X

이면:

Gate Controller

통신

Relay

Barrier

등 공통 영역을 확인합니다.

비교 테스트는 장애 범위를 빠르게 줄이는 강력한 방법입니다.

19장 정상 차로와 장애 차로를 비교한다#

예:

ENT-01
정상

ENT-02
장애

다음 항목을 비교합니다.

Firmware

IP

VLAN

Switch Port

LPR 설정

Server Endpoint

Controller 설정

Protocol Version

Cable

PoE

정상 장비와 장애 장비의 차이가 중요한 단서가 됩니다.

20장 네트워크 장애인지 확인할 때 Ping만 보지 않는다#

예:

LPR → Server
Ping 성공

이라고 하더라도:

HTTP API 실패

할 수 있습니다.

왜냐하면:

ICMP O

TCP 443 X

일 수도 있기 때문입니다.

따라서:

Link
↓
VLAN
↓
IP
↓
Gateway
↓
TCP / UDP
↓
Port
↓
Application

순으로 확인합니다.

21장 TCP 장애라면 Handshake 위치를 확인한다#

LPR Camera가 TCP Server에 연결한다고 가정합니다.

SYN
↓
SYN/ACK
↓
ACK

이 정상이라면 TCP Connection은 성립했습니다.

그 이후 HTTP 500이 반환됐다면:

Cable 문제

보다:

Application

Database

Server

쪽을 확인하는 것이 맞습니다.

22장 UDP 장비는 다르게 확인한다#

일부 Controller나 Sensor가 UDP를 사용할 수 있습니다.

UDP는 TCP처럼 Connection 상태가 없기 때문에:

Sender에서 Datagram이 나갔는가?
↓
Controller까지 도착했는가?
↓
Destination Port는 맞는가?
↓
Payload가 맞는가?
↓
Application ACK가 있는가?

를 확인해야 합니다.

23장 주차관제에서 자주 보는 Network 장애#

23.1 잘못된 VLAN#

장비는 켜져 있지만 Server와 통신되지 않을 수 있습니다.

23.2 IP 충돌#

장비가:

됐다 안 됐다

하는 간헐 장애처럼 보일 수 있습니다.

ARP Table에서 같은 IP의 MAC이 변하는지 확인할 수 있습니다.

23.3 Default Gateway 오류#

같은 Subnet 장비와는 통신하지만 중앙 Server에는 접속하지 못할 수 있습니다.

23.4 Switch Port 문제#

CRC Error

Link Flap

Speed 문제

PoE Event

등을 확인합니다.

24장 PoE 문제는 Camera 장애처럼 보일 수 있다#

LPR Camera가 하루에 몇 번 Offline이 됩니다.

Server에서는:

Camera Connection Lost

라고만 보입니다.

하지만 Switch에서는:

PoE power removed

Port Down

Port Up

이 반복될 수 있습니다.

Camera Log에서는:

System Boot

이 같은 시각에 남습니다.

전체 흐름은:

PoE 문제
↓
Camera Power Reset
↓
Link Down
↓
Camera Boot
↓
LPR Offline
↓
Reconnect

입니다.

이 경우 Network Application 설정을 계속 바꿔도 해결되지 않습니다.

25장 Camera 영상과 LPR 인식은 분리해서 본다#

영상은 정상인데 번호판 인식만 실패할 수 있습니다.

확인:

Camera 영상 O

Trigger O

Image Capture O

OCR X

이면 다음을 봅니다.

Camera Angle

Focus

Exposure

IR Lighting

Shutter

차량 속도

번호판 반사

LPR Engine 설정

26장 밤에만 장애가 발생한다면 환경 조건도 본다#

예:

주간 정상

야간 인식률 저하

라면 Network보다:

IR

조명

Headlight

반사

Exposure

Shutter

를 확인해야 할 수 있습니다.

26.1 비가 올 때만 장애가 발생한다면#

가능한 확인 항목:

Lens 오염

물방울

Connector 방수

Cable

Ground

Sensor 오동작

현장 장애는 Software와 Network만의 문제가 아닙니다.

27장 Loop Sensor 장애를 분리해보자#

차량이 들어왔는데 LPR Trigger가 발생하지 않습니다.

먼저:

Loop Sensor가 차량을 감지했는가?

를 확인합니다.

가능한 흐름:

차량
↓
Loop
X
↓
Camera Trigger 없음
↓
번호판 촬영 없음

Camera가 정상이어도 Sensor 단계에서 실패하면 아무 이미지도 생성되지 않습니다.

28장 안전 Sensor도 Gate 동작에 영향을 줄 수 있다#

Barrier가 내려가지 않는다고 해서 Motor 고장이라고 단정해서는 안 됩니다.

Safety Sensor가:

차량 있음

상태로 계속 감지하고 있으면 Controller가 안전을 위해 CLOSE 동작을 차단할 수 있습니다.

확인:

Loop 상태

Safety Beam

Photo Sensor

Controller Input

등입니다.

29장 결제는 승인과 업무 완료를 구분한다#

결제 Terminal에서:

결제 성공

이라는 화면이 나왔다고 해도 내부적으로 여러 상태가 있습니다.

승인 요청

승인 응답

Parking Server 저장

Receipt

출차 가능 상태 변경

예를 들어 카드 승인은 성공했지만 Parking Server DB 저장이 실패하면 고객 카드에는 승인됐는데 Gate는 열리지 않는 상황도 발생할 수 있습니다.

따라서:

Payment Approved
≠
Parking Transaction Completed

입니다.

30장 Gate OPEN도 여러 완료 상태로 나눈다#

가능하면 Log를 다음처럼 구분합니다.

OPEN_SENT

OPEN_RECEIVED

OPEN_ACCEPTED

RELAY_ON

BARRIER_MOVING

OPEN_SENSOR_ON

OPEN_COMPLETED

이 구조가 있으면:

OPEN 명령을 보냈는데 왜 안 열렸지?

라는 문제를 훨씬 정확하게 분석할 수 있습니다.

31장 Server Log의 “성공”을 과신하지 않는다#

Server가:

OPEN COMMAND SENT

라고 기록했다고 가정합니다.

이것은:

Server가 전송 동작을 수행했다.

는 의미일 수 있습니다.

반드시:

Gate Controller가 받았다.

Barrier가 열렸다.

는 의미는 아닙니다.

각 경계의 완료 상태를 분리해야 합니다.

32장 TCP ACK도 Gate 동작 완료는 아니다#

TCP 기반 Gate Controller라면:

TCP ACK

를 볼 수 있습니다.

하지만 이는 기본적으로 TCP 데이터 수신과 관련된 확인입니다.

실제 과정은:

TCP 수신
↓
Application Parsing
↓
Command Validation
↓
Relay
↓
Motor
↓
Open Sensor

입니다.

따라서 업무적으로는 별도의 Application 상태가 필요합니다.

33장 재부팅 전에 증거를 확보한다#

주차관제 장애에서:

Camera 재부팅

Controller 재부팅

Switch 재부팅

Server 재부팅

을 먼저 해버리기 쉽습니다.

하지만 재부팅하면:

Socket 상태

메모리 상태

현재 Error

Temporary Log

Network 상태

가 사라질 수 있습니다.

따라서 가능하면:

현재 화면 Capture
↓
장비 Log
↓
Server Log
↓
Network 상태
↓
Uptime
↓
Error Counter
↓
그다음 재부팅

순서가 좋습니다.

34장 변경 이력을 반드시 확인한다#

장애 발생 전에 다음 작업이 있었는지 확인합니다.

Camera Firmware Update

LPR Engine Update

Server 배포

DB 작업

Switch 교체

VLAN 변경

Firewall 변경

IP 변경

Gate Controller 교체

전원 공사

정산기 Update

34.1 장비 교체 후 문제라면#

다음 항목을 비교합니다.

IP

MAC

Port

Protocol

Firmware

Device ID

Server Registration

인증 정보

예전 장비의 IP를 그대로 사용했는데 ARP Cache나 Server의 Device Binding이 남아 있을 수도 있습니다.

35장 시간대별 장애는 Scheduled Job도 확인한다#

예:

매일 새벽 02:00~02:20
관제 Server 응답 느림

이라면:

DB Backup

Log Rotation

Batch

Antivirus Scan

Storage Backup

System Maintenance

같은 작업을 확인할 수 있습니다.

장애 발생 시간과 작업 시간을 겹쳐보는 것이 중요합니다.

36장 현장에서 바로 확보해야 할 자료#

차량 사건#

차량번호

발생 시각

입·출차

차로 ID

장비#

LPR ID

Gate Controller ID

Kiosk ID

Switch / Port

Firmware

Network#

IP

MAC

VLAN

Gateway

Server IP

TCP / UDP Port

Log#

LPR Log

Parking Server Log

Gate Controller Log

Switch Log

Firewall Log

Database Log

운영#

마지막 정상 시각

최근 변경

재현 여부

영향 범위

37장 좋은 주차관제 장애 Ticket 예#

제목
B1 입구 1차로 등록차량 자동 OPEN 실패

발생 시각
2026-09-24 08:42

차로
ENT-B1-01

장비
LPR-01
GATE-01

차량
12가3456

증상
번호판 인식 및 Server 등록은 정상이나
Barrier가 자동 OPEN되지 않음

수동 OPEN
실패

영향 범위
해당 차로만 발생

확인 결과
LPR 정상
Server 차량 조회 정상
OPEN Command 생성 정상
Controller Command 수신 정상
Relay Output 정상
Open Sensor Timeout 발생

최근 변경
전날 Barrier 정비

현재 의심 범위
Barrier Motor / Sensor / 제어 배선

이런 Ticket이면 Network 담당자, Server 개발자, 장비 업체가 같은 사건을 훨씬 쉽게 이해할 수 있습니다.

38장 장애 원인과 관찰 사실을 섞지 않는다#

예:

관찰
LPR에서 HTTP 500 수신

가설
Parking Server Application 오류 가능성

확인 필요
Server Application Log

좋습니다.

반면:

Server 오류 때문에 차단기가 안 열림

이라고 증거 없이 작성하면 판단이 고정될 수 있습니다.

39장 TCP Retransmission도 원인으로 단정하지 않는다#

Packet Capture에서:

TCP Retransmission

이 보였다고:

Network Cable 불량

이라고 바로 결론 내리면 안 됩니다.

가능한 원인은:

Packet Loss

Queue Drop

WAN 지연

Server 부하

Capture Loss

Network 경로 변화

등 다양합니다.

Packet Capture는 원인 그 자체가 아니라 경계를 좁히는 증거입니다.

40장 정상 차로와 비교하는 것이 빠르다#

주차관제는 동일한 구성이 여러 차로에 반복되는 경우가 많습니다.

이 특성을 적극 활용할 수 있습니다.

정상
ENT-01

장애
ENT-02

두 차로를 비교합니다.

항목 정상 차로 장애 차로
LPR Firmware 동일 동일
Controller Firmware 동일 동일
VLAN 20 20
Switch SW-01 SW-01
Port Error 없음 증가
PoE Event 없음 반복
Server 설정 동일 동일

차이가 나는 부분이 강력한 단서입니다.

41장 장애를 계층별로 분류하자#

41.1 차량 감지#

Loop

Radar

Sensor

Trigger

41.2 영상·인식#

Camera

Image

LPR

OCR

41.3 Network#

Cable

Switch

VLAN

IP

Routing

TCP / UDP

41.4 Server#

API

Business Logic

Authentication

Application

41.5 Data#

Vehicle DB

Entry Record

Payment

Discount

Database

41.6 Controller#

Gate Controller

Relay

I/O

41.7 Physical Device#

Barrier

Motor

Sensor

Mechanical Part

41.8 Monitoring#

관제 화면

Event Log

Alarm

Status Update

이 구조로 나누면 장애 영역을 체계적으로 찾을 수 있습니다.

42장 주차관제 장애 진단의 기본 흐름#

차량 사건 확인
↓
차로 ID 확인
↓
발생 시각 확인
↓
차량 감지 여부
↓
LPR 촬영 여부
↓
번호판 인식 여부
↓
Server 전송 여부
↓
Server 판단 결과
↓
명령 생성 여부
↓
Controller 수신 여부
↓
Relay 출력 여부
↓
Barrier 동작 여부
↓
Sensor 상태 확인
↓
Event 저장 여부
↓
관제 화면 반영 여부

이 흐름만 기억해도 상당수의 장애를 빠르게 좁힐 수 있습니다.

43장 증상별 우선 확인 영역#

증상 우선 확인
Camera Offline 전원·PoE·Cable·Switch
영상 없음 Camera·Network·Streaming
영상 정상, 번호 인식 실패 촬영 조건·LPR
번호 인식 정상, Server 미수신 Network·API
Server HTTP 500 Application·DB
등록 차량인데 OPEN 명령 없음 차량 DB·업무 Logic
OPEN 명령은 있음, Controller 미수신 Network·Protocol
Controller 수신, Relay 없음 Controller
Relay ON, Barrier 안 열림 Barrier·Motor·배선
Barrier 열림, 화면은 닫힘 Sensor·상태 전송·UI
모든 차로 장애 공통 Server·Network·DB
특정 차로 장애 해당 차로 장비·Port·배선
야간에만 LPR 실패 조명·IR·Exposure
간헐적 Camera Offline PoE·전원·Link

44장 재현하지 말아야 하는 장애도 있다#

다음 문제는 운영 환경에서 반복 실험하면 위험할 수 있습니다.

Barrier Safety Sensor 장애

Motor 이상

Payment Transaction

Emergency Gate

전원 이상

차량 충돌 위험

이런 상황에서는 억지로 재현하기보다:

기존 Log

Video

Event History

Controller I/O History

Test Bench

Simulator

를 이용합니다.

45장 개인정보와 보안을 함께 고려한다#

주차관제 Log에는 다음 정보가 포함될 수 있습니다.

차량번호

방문자 정보

전화번호

결제 정보

Token

관리자 계정

Camera Image

따라서 Log와 Packet Capture를 외부 업체에 전달할 때는:

차량번호 Masking

민감정보 제거

접근 권한 제한

암호화 저장

보관기간 관리

등의 정책이 필요합니다.

46장 설정 변경 전에 Rollback 방법을 확보한다#

예:

LPR 설정 변경

Controller Firmware Update

VLAN 변경

IP 변경

Firewall Rule 변경

을 수행하기 전에:

기존 설정 Backup

변경 항목

변경 시간

작업자

Rollback 방법

을 기록합니다.

현장 장애를 해결하다가 더 큰 장애를 만드는 것을 방지하기 위해서입니다.

47장 현장에서 가장 먼저 던질 질문#

어떤 차로인가#

입구?

출구?

몇 번 차로?

어떤 차량인가#

차량번호?

등록 차량?

방문 차량?

정산 차량?

언제 발생했는가#

정확한 시각?

마지막 정상 시각?

어디까지 정상인가#

감지?

촬영?

인식?

Server 전송?

OPEN Command?

Barrier?

한 차로만 문제인가#

한 장비?

한 차로?

한 구역?

전체 주차장?

최근 무엇이 바뀌었는가#

Firmware?

Server?

Network?

Gate?

전원?

DB?

48장 주차관제 장애 접수 체크리스트#

항목 기록 내용
현장 주차장·건물
차로 ID 입구·출구·번호
장비 ID LPR·Gate·Kiosk·Sensor
차량번호 필요 시 Masking
발생 시각 가능한 정확하게
마지막 정상 시각 비교 기준
증상 관찰된 사실
기대 동작 정상 상태
실제 동작 발생 결과
재현 여부 항상·간헐
영향 범위 차로·구역·전체
수동 동작 성공·실패
Network 상태 IP·Link·VLAN
Server 상태 API·DB
최근 변경 Firmware·설정·공사
관련 로그 확보 여부
임시 조치 수행 내역

49장 자기 점검#

49.1 “차단기가 안 열린다”고 하면 가장 먼저 무엇을 확인할까#

차량 감지부터 실제 Barrier 동작까지 처리 흐름을 나누고 마지막 정상 지점과 최초 실패 지점을 확인합니다.

49.2 LPR이 차량번호를 정상 인식했다면 Camera는 모두 정상이라고 볼 수 있는가#

번호판 인식 단계는 정상이라고 볼 수 있지만 Server 전송, Network, API, 업무 처리까지 정상이라는 의미는 아닙니다.

49.3 Server에서 OPEN 명령을 기록했다면 Barrier가 열렸다고 볼 수 있는가#

아닙니다.

Controller 수신, Relay 출력, Motor 동작, Open Sensor 확인까지 별도로 확인해야 합니다.

49.4 특정 차로만 장애라면 무엇을 먼저 볼까#

해당 차로만 사용하는:

Camera

Sensor

Controller

Switch Port

Cable

Barrier

등을 정상 차로와 비교합니다.

49.5 모든 차로가 동시에 장애라면 무엇을 먼저 볼까#

여러 차로가 공유하는:

Parking Server

Database

Core Network

Firewall

공통 전원

등을 우선 확인합니다.

50장 이 글을 마치며#

주차관제 장애는 사용자에게 매우 단순하게 보입니다.

차단기가 안 열려요.

번호판이 안 읽혀요.

정산기가 안 돼요.

Camera가 끊겨요.

하지만 실제 시스템은 여러 단계가 연결되어 있습니다.

자동 입차 하나만 해도:

차량 감지
↓
Camera Trigger
↓
영상 촬영
↓
번호판 인식
↓
Server 전송
↓
차량 조회
↓
업무 판단
↓
OPEN Command
↓
Controller
↓
Relay
↓
Barrier
↓
Sensor
↓
상태 저장

과정을 거칠 수 있습니다.

따라서 좋은 장애 분석은:

Camera 문제인가?

Server 문제인가?

Network 문제인가?

Gate 문제인가?

를 처음부터 추측하는 것이 아닙니다.

먼저 차량 한 대의 사건을 기준으로:

발생 시각
↓
차로 ID
↓
장비 ID
↓
차량번호
↓
각 단계의 Log

를 연결합니다.

그리고:

마지막 정상 지점
↓
최초 실패 지점

을 찾습니다.

그 두 지점 사이가 실제로 집중해서 분석해야 할 장애 영역입니다.

특히 다음 네 가지를 기억하면 됩니다.

주차관제의 장애는 장비 하나가 아니라 차량 한 대의 전체 처리 흐름으로 봐야 합니다.

“차단기가 안 열린다”는 원인이 아니라 처리 과정의 최종 증상입니다.

LPR·Server·Network·Controller·Barrier의 로그를 같은 시간축으로 연결해야 합니다.

정상 차로와 장애 차로를 비교하면 장애 범위를 매우 빠르게 좁힐 수 있습니다.

결국 주차관제 장애 진단은 특정 장비를 많이 아는 것만으로 해결되는 문제가 아닙니다.

차량 한 대의 사건을 감지부터 물리 동작과 기록까지 다시 조립하고, 최초로 흐름이 끊어진 지점을 찾아내는 능력이 핵심입니다.

이 페이지의 목차