현장에서 발생하는 통신 장애의 원인을 전기적으로 분석하는 방법

현장에서 발생하는 통신 장애의 원인을 전기적으로 분석하는 방법#

1. 통신 장애는 왜 현장에 도착하면 사라질까#

현장에서 가장 찾기 어려운 장애는 완전히 고장 난 장비가 아니라 가끔 고장 나는 장비입니다.

예를 들어 주차관제 시스템에서 이런 현상이 발생한다고 가정해보겠습니다.

평소
차량 인식 → 서버 확인 → 차단기 OPEN → 정상

새벽 특정 시간
차량 인식 → 서버 확인 → 차단기 응답 없음

몇 초 후
다시 정상

운영 서버에는 다음 정도의 기록만 남을 수 있습니다.

02:13:41 Gate01 Timeout
02:13:42 Retry
02:13:43 Gate01 Online

개발자가 이 로그만 보면 가장 먼저 네트워크나 프로그램을 의심할 수 있습니다.

하지만 현장에서는 전혀 다른 일이 발생했을 수도 있습니다.

전원 순간 강하
↓
컨트롤러 재부팅
↓
통신 포트 초기화
↓
응답 중단
↓
서버 Timeout

또는 다음과 같은 과정일 수도 있습니다.

커넥터 부식
↓
진동 발생
↓
순간적인 접촉 불량
↓
RS-485 데이터 손상
↓
CRC Error
↓
응답 폐기
↓
Timeout

서버가 기록한 Timeout은 원인이 아니라 장애가 최종적으로 나타난 결과입니다.

따라서 간헐적인 통신 장애를 제대로 분석하려면 서버 화면에서 시작해 아래쪽으로 내려가는 것이 아니라, 실제 데이터가 만들어지고 이동하는 전체 경로를 봐야 합니다.

2. 통신은 전기에서 시작해서 애플리케이션에서 끝난다#

산업 장비의 통신 흐름을 단순화하면 다음과 같습니다.

전원
↓
장비 전자회로
↓
통신 Transceiver
↓
Connector
↓
Cable
↓
전기 신호
↓
Bit
↓
Byte
↓
Frame
↓
Protocol
↓
Application

가장 아래쪽에서 발생한 문제는 위쪽에서 전혀 다른 오류로 나타날 수 있습니다.

예를 들어:

전원 불안정
↓
MCU Reset
↓
통신 중단
↓
TCP Connection 종료
↓
Application Timeout

이 경우 애플리케이션의 Timeout 값을 1초에서 5초로 늘려도 근본적인 문제는 해결되지 않습니다.

따라서 현장에서 통신 장애를 분석할 때는 다음 원칙이 중요합니다.

아래 계층이 정상이라는 증거를 확보한 뒤 위 계층으로 올라간다.

3. 가장 먼저 육안으로 확인한다#

복잡한 측정 장비를 꺼내기 전에 먼저 장비와 배선을 직접 확인합니다.

의외로 많은 단서를 눈으로 찾을 수 있습니다.

확인할 항목은 다음과 같습니다.

전원 LED 상태
통신 LED 상태
커넥터가 완전히 체결되어 있는지
Terminal Screw가 느슨하지 않은지
Cable 피복이 눌리거나 찢어졌는지
습기가 들어간 흔적이 있는지
Connector에 부식이 있는지
최근 장비나 Cable이 교체됐는지
배선 Label과 실제 장비가 일치하는지

특히 지하주차장이나 옥외 설비에서는:

습기
먼지
온도 변화
진동
차량 충격
설비 공사

등이 배선 상태에 지속적으로 영향을 줄 수 있습니다.

복잡한 Protocol 분석 전에 눈에 보이는 물리적 문제부터 제거하는 것이 현장 진단의 기본입니다.

4. 두 번째는 전원을 확인한다#

장비의 LED가 켜져 있다고 해서 전원이 정상이라고 판단해서는 안 됩니다.

중요한 것은:

장비가 실제로 동작하는 동안에도 필요한 전압이 안정적으로 유지되는가?

입니다.

예를 들어 24V DC Controller가 있다고 가정해보겠습니다.

대기 상태에서는:

24.1V

로 정상일 수 있습니다.

하지만 Motor나 Relay가 동작하는 순간:

24.1V
↓
19.3V
↓
24.0V

처럼 순간적으로 전압이 내려갈 수도 있습니다.

Controller의 허용범위를 벗어나면 MCU가 Reset될 수 있습니다.

그 결과 서버에서는 단순히:

No Response

라고 보일 뿐입니다.

5. 무부하 전압만 측정하면 놓치는 문제가 있다#

현장에서 흔히 다음과 같이 측정합니다.

장비 정지 상태
24.0V

→ 정상

하지만 실제 장애는 장비가 동작할 때 발생합니다.

따라서 중요한 것은 부하 상태에서의 전압입니다.

예를 들어:

대기
24.0V

Relay ON
23.8V

Motor 구동
20.2V

Motor 정지
24.0V

처럼 상태별로 비교해야 합니다.

짧은 순간의 전압 변화는 일반적인 Multimeter 화면에서 보이지 않을 수도 있기 때문에 장애 특성에 따라 Min/Max 기록 기능이나 적절한 파형 측정 장비가 필요할 수 있습니다.

6. 전압 강하는 왜 발생할까#

대표적인 원인은 다음과 같습니다.

Power Supply 용량 부족
긴 전원 Cable
도체 굵기 부족
Connector 접촉저항
Terminal 체결 불량
동시에 동작하는 부하 증가
노후화된 Power Supply
높은 주변 온도

전원선에도 저항이 존재하기 때문에 전류가 흐르면 전압 강하가 발생합니다.

개념적으로 보면:

Power Supply
24V
↓
Cable
↓
Connector
↓
Cable
↓
장비 입력
22.8V

처럼 될 수 있습니다.

장비가 많은 시스템에서는 단순히 전원 공급기의 정격 출력만 볼 것이 아니라 가장 불리한 동작 조건에서 장비 입력단에 실제로 얼마의 전압이 도착하는지 확인해야 합니다.

7. Ripple도 확인해야 한다#

DC Power Supply의 출력은 이상적으로 일정해야 합니다.

────────────
24V DC

하지만 실제 출력에는 작은 AC 성분이나 Switching 성분이 남을 수 있습니다.

~~~~~24V~~~~~

이를 Ripple이라고 합니다.

장비가 허용하는 수준을 넘어서는 Ripple은 상황에 따라:

MCU 오동작
ADC 값 불안정
통신 회로 오류
Reset

등과 연관될 수 있습니다.

허용 Ripple은 장비마다 다르기 때문에 절대값을 임의로 적용하기보다 제조사의 전원 입력 사양을 기준으로 판단해야 합니다.

8. 전원 문제인지 확인할 수 있는 중요한 단서#

전원 문제가 의심된다면 통신 로그만 보지 말고 다음 항목도 확인합니다.

Device Uptime

Boot Log

Reset Reason

Power Alarm

Watchdog Reset

Brownout 기록

예를 들어:

02:13:40 Device Uptime 3d 12h
02:13:41 통신 끊김
02:13:43 Device Uptime 2s

라면 장비가 중간에 재부팅됐을 가능성을 강하게 의심할 수 있습니다.

이런 정보는 단순 Ping 테스트보다 훨씬 중요한 증거가 될 수 있습니다.

9. Surge와 순간적인 과도전압#

Surge는 짧은 시간 동안 발생하는 과도전압입니다.

대표적인 발생 원인은 다음과 같습니다.

낙뢰 영향
Motor Switching
Relay
Contactor
대용량 부하의 On/Off
전원 계통 Switching

개념적으로는:

정상

────────────

Surge

──────▲─────
      │

같은 형태입니다.

서지는 항상 장비를 즉시 완전히 고장 내는 것은 아닙니다.

보호회로나 Transceiver가 부분적으로 손상되어:

평상시 정상
↓
특정 조건에서 오류
↓
시간이 지나면서 장애 증가

처럼 나타날 수도 있습니다.

10. ESD도 통신 장애를 만들 수 있다#

ESD는 Electrostatic Discharge, 즉 정전기 방전입니다.

카드리더, 키오스크, 출입통제 장치처럼 사람이 직접 접촉하는 장비에서는 특히 고려할 필요가 있습니다.

정전기 방전은 매우 짧지만 전자회로에는 큰 스트레스를 줄 수 있습니다.

결과적으로:

사용자 접촉
↓
ESD
↓
장비 순간 Reset
↓
통신 끊김
↓
자동 복구

같은 간헐 장애가 나타날 수 있습니다.

그래서 다음과 같은 패턴도 기록할 가치가 있습니다.

특정 사용자가 단말기에 접촉하는 순간에만 Reset이 발생하는가?

11. 다음으로 Ground와 기준 전압을 본다#

디지털 통신에서도 전압을 판단하기 위한 기준이 필요합니다.

특히 서로 멀리 떨어진 장비가 통신할 때 두 위치의 전기적 기준이 완전히 같다고 가정할 수는 없습니다.

예를 들어:

장비 A 기준 전위
      │
      │
통신 Cable
      │
      │
장비 B 기준 전위

사이에 차이가 존재할 수 있습니다.

차이가 커지면 통신 Transceiver가 허용하는 Common-mode 범위를 벗어날 수 있습니다.

12. Ground Loop는 무엇인가#

두 장비 사이에 Ground 전류가 흐를 수 있는 경로가 여러 개 존재하면 Loop가 형성될 수 있습니다.

개념적으로:

장비 A
│     \
│      \
통신선   시설 접지
│        \
│         \
장비 B ────

이 경로를 따라 의도하지 않은 전류가 흐르면 Noise나 통신 불안정에 영향을 줄 수 있습니다.

다만 여기서 중요한 점이 있습니다.

Ground 문제를 해결한다며 임의로 보호접지를 끊어서는 안 됩니다.

보호접지는 사람과 설비의 안전과 관련됩니다.

접지 문제는 장비 제조사 규격과 시설 전기 설계를 기준으로 판단하고 필요한 경우 전기 담당자와 함께 점검해야 합니다.

13. Shield Ground도 무조건 한쪽이 정답은 아니다#

현장에서 자주 듣는 말이 있습니다.

차폐선은 한쪽만 접지해야 한다.

일부 저주파 환경에서는 Ground Loop를 줄이기 위해 한쪽 접지 방식이 사용될 수 있습니다.

하지만 높은 주파수의 EMI를 제어하는 EMC 설계에서는 양단 Chassis Bonding이 더 적절한 경우도 있습니다.

따라서:

무조건 한쪽

또는:

무조건 양쪽

이라고 외우는 것은 적절하지 않습니다.

다음 조건을 함께 봐야 합니다.

통신 규격
장비 설계
Cable Shield 구조
주파수 환경
Chassis 구조
시설 Grounding

14. Cable은 완전히 끊어지지 않아도 장애를 만든다#

Cable 문제라고 하면 완전 단선을 떠올리기 쉽습니다.

실제 현장에서는 다음과 같은 부분적인 문제가 더 까다롭습니다.

내부 도체 손상
반복적인 굽힘
눌림
피복 손상
습기 침투
압착 불량
Connector 부식
Terminal 체결 불량

예를 들어:

평상시 접촉
↓
진동
↓
순간적으로 접촉 저항 증가
↓
Signal 품질 저하
↓
Frame Error

처럼 간헐적인 장애가 발생할 수 있습니다.

15. Connector는 꽂혀 있는지만 보면 안 된다#

Connector가 연결되어 있어도 내부 접촉 상태가 나쁠 수 있습니다.

확인할 항목은 다음과 같습니다.

Pin 변형
부식
습기
먼지
압착 상태
Latch 손상
Terminal 체결 상태

전원 Connector의 접촉저항이 증가하면 Voltage Drop으로 이어질 수 있고, 통신 Connector라면 신호 품질 저하로 이어질 수 있습니다.

따라서:

Connector가 꽂혀 있다.

와

Connector가 정상적인 전기적 접촉을 유지한다.

는 다른 의미입니다.

16. 장애가 진동이나 온도와 관련되는지도 확인한다#

간헐 장애라면 주변 환경 변화도 기록합니다.

예:

차단기 동작
↓
진동 발생
↓
통신 끊김

또는:

낮은 온도
→ 정상

장비 내부 온도 상승
→ 장애 발생

같은 패턴입니다.

이 경우 소프트웨어보다:

Connector
Solder Joint
Power Supply
Cable
Terminal

등을 먼저 의심할 근거가 됩니다.

17. EMI 문제는 발생 시간과 함께 본다#

EMI는 Electromagnetic Interference, 즉 전자기 간섭입니다.

다음 장비는 대표적인 Noise 발생원이 될 수 있습니다.

Motor
Inverter
Relay
Contactor
Transformer
Switching Power Supply
EV Charger

중요한 것은 단순히 주변에 Motor가 있다는 사실이 아닙니다.

Motor가 동작하는 순간과 통신 장애가 실제로 일치하는가를 확인해야 합니다.

예:

시간	이벤트
10:21:18.120	Barrier Motor ON
10:21:18.143	RS-485 CRC Error
10:21:18.510	Retry
10:21:18.620	정상 응답

이런 패턴이 반복된다면 EMI 또는 전원 영향의 우선순위를 높일 수 있습니다.

18. 전원 Cable과 통신 Cable 경로를 확인한다#

통신 Cable 자체가 좋은 제품이라도 설치 방법이 좋지 않으면 문제가 생길 수 있습니다.

예를 들어:

Motor Power Cable
========================

RS-485 Cable
========================

두 Cable이 긴 구간 동안 매우 가까이 평행하게 배선되어 있다면 전자기적 결합이 증가할 수 있습니다.

따라서 현장에서는 Cable 종류뿐 아니라:

Cable Route
↓
전력선과의 거리
↓
교차 방식
↓
Metal Duct
↓
Shield 처리

까지 확인해야 합니다.

19. RS-485에서는 Topology를 먼저 확인한다#

RS-485 장애라면 단순히 A/B만 보면 안 됩니다.

최소한 다음을 확인합니다.

A/B 또는 D+/D- 정의
Cable 종류
Bus 길이
Node 수
Topology
Termination
Bias
Stub 길이
Ground Reference

RS-485는 일반적으로 하나의 Trunk를 따라 장비가 연결되는 Bus 형태가 자연스럽습니다.

Device ─ Device ─ Device ─ Device

긴 Stub가 여러 방향으로 뻗으면 Signal Reflection 문제를 증가시킬 수 있습니다.

20. RS-485 Termination의 역할#

Cable 끝에서 임피던스가 크게 달라지면 신호 에너지 일부가 되돌아오는 Reflection이 발생할 수 있습니다.

송신 Signal
──────────────→

Cable 끝
          ↓

Reflection
←─────────────

반사된 Signal이 뒤따르는 데이터와 겹치면 Waveform이 왜곡되고 수신 오류가 발생할 수 있습니다.

Termination은 이러한 반사를 줄이기 위해 Cable의 특성 임피던스와 맞추는 방식입니다.

RS-485에서는 약 120Ω의 특성 임피던스를 가진 Twisted Pair가 일반적이어서 120Ω 종단이 널리 사용됩니다. TI 역시 RS-485의 대표적인 종단값 120Ω이 Bus Cable의 명목 특성 임피던스에서 나온다고 설명합니다.

21. 120Ω을 모든 장비에 설치하는 것은 아니다#

전형적인 RS-485 Bus에서는 Cable의 물리적인 양 끝에 Termination을 배치하는 구성이 일반적입니다.

120Ω                          120Ω
 │                              │
[Node]──[Node]──[Node]──[Node]

모든 Node에 120Ω 저항을 추가하면 전체 Bus 부하가 지나치게 낮아질 수 있습니다.

따라서:

통신이 불안정하다
↓
120Ω 추가
↓
또 추가

처럼 접근하면 안 됩니다.

먼저 실제 Bus 구조를 확인해야 합니다.

22. Termination이 없다고 항상 통신이 안 되는 것도 아니다#

짧은 Cable과 낮은 Signal Rate에서는 종단 없이도 정상적으로 동작하는 경우가 있습니다.

그래서 오래된 현장에서:

종단저항이 없는데 몇 년 동안 잘 됐어요.

라는 말을 들을 수도 있습니다.

이것이 이상한 것은 아닙니다.

Reflection이 다음 Bit 판정에 영향을 줄 정도로 크지 않은 조건에서는 정상적으로 동작할 수 있기 때문입니다.

하지만 Cable 길이와 Signal Rate가 증가하면서 전송선 효과가 중요해지면 적절한 Termination이 훨씬 중요해집니다.

23. Bias와 Fail-safe도 확인한다#

RS-485 Bus에서 아무 Driver도 송신하지 않는 순간에는 Receiver 입력이 불확실한 상태가 될 수 있습니다.

이를 안정적인 상태로 유지하기 위해 Fail-safe Bias를 사용할 수 있습니다.

개념적으로:

아무 장치도 송신하지 않음
↓
Bus Idle
↓
Bias 회로
↓
Receiver가 정의된 상태 유지

다만 최신 RS-485 Transceiver 중에는 내부 Fail-safe 기능을 제공하는 제품도 있습니다. 따라서 외부 Pull-up·Pull-down 저항을 무조건 추가하지 말고 실제 Transceiver와 장비 회로를 확인해야 합니다.

24. CRC Error는 중요한 전기적 단서가 될 수 있다#

예를 들어 Modbus RTU Frame이 다음과 같다고 가정해보겠습니다.

01 03 00 00 00 02 CRC_L CRC_H

전송 과정에서 한 Bit가 잘못되면:

정상
01 03 00 00 00 02

수신
01 03 00 08 00 02
         ↑

CRC가 맞지 않게 됩니다.

수신기는 Frame을 버립니다.

그 결과:

전기적 Noise
↓
Bit Error
↓
CRC Error
↓
Frame 폐기
↓
응답 없음
↓
Timeout

이 됩니다.

따라서 Timeout만 보는 것보다 CRC Error가 먼저 증가하고 있는지 확인하는 것이 훨씬 유용합니다.

25. Ethernet에서도 물리 오류를 확인할 수 있다#

Ethernet Switch나 NIC에는 여러 Error Counter가 존재할 수 있습니다.

대표적으로:

FCS Error
CRC Error
Alignment Error
Drop
Link Down
Interface Reset

등입니다.

FCS Error가 계속 증가한다면 Cable, Port, NIC 같은 물리적인 문제를 의심할 근거가 됩니다. Cisco 역시 FCS 오류의 일반적인 원인으로 Cable, Port, NIC 같은 물리적 문제와 Duplex 불일치를 설명합니다.

예:

09:00 FCS Error 0
09:30 FCS Error 3
10:00 FCS Error 18
10:30 FCS Error 74

처럼 증가한다면 그냥 지나칠 숫자가 아닙니다.

26. TCP Retransmission이 많다고 TCP가 원인은 아니다#

Wireshark에서 다음 메시지를 볼 수 있습니다.

TCP Retransmission

이것만 보고 TCP 설정을 문제라고 판단하면 안 됩니다.

하위 계층에서 Frame이 손실돼도:

Ethernet Frame Loss
↓
TCP Segment 미도착
↓
ACK 미수신
↓
TCP Retransmission

으로 나타날 수 있습니다.

즉 TCP Retransmission은 원인이라기보다 결과일 수도 있습니다.

그래서 다음을 함께 봅니다.

TCP Retransmission
+
Switch Error Counter
+
Link 상태
+
Cable 상태
+
NIC 상태

27. Duplex 설정도 오래된 설비에서는 확인한다#

현대 Ethernet에서는 Auto-Negotiation을 사용하는 것이 일반적입니다.

하지만 오래된 산업 장비나 과거에 강제로 설정된 Port가 존재한다면 Speed와 Duplex 설정을 확인할 필요가 있습니다.

예:

Device
100 Mbps Full

Switch
설정 불일치

Duplex 문제가 있으면 충돌이나 성능 저하 같은 현상이 나타날 수 있습니다. Cisco 문서에서도 과도한 Collision이나 FCS 오류가 Duplex 불일치와 관련될 수 있다고 설명합니다.

28. PoE 장비는 데이터와 전원을 함께 본다#

IP Camera가 통신되지 않는다고 해서 항상 Ethernet 문제인 것은 아닙니다.

PoE 환경에서는 같은 Cable을 통해 데이터와 전원이 함께 전달됩니다.

따라서 다음을 모두 확인합니다.

Switch PoE 지원
↓
Port PoE 상태
↓
PoE Budget
↓
장비 요구 전력
↓
Cable 상태
↓
장비 동작

특히 Switch의 각 Port가 PoE를 지원해도 Switch 전체가 공급할 수 있는 총전력에는 한계가 있을 수 있습니다.

29. 밤에만 Camera가 끊기는 이유도 전원일 수 있다#

다음과 같은 현상을 생각해볼 수 있습니다.

낮
IR 기능 OFF
↓
Camera 정상

밤
IR 기능 ON
↓
소비전력 증가
↓
PoE 조건 한계
↓
Camera Reset

따라서:

밤에만 네트워크가 끊긴다.

고 해서 무선 간섭이나 Traffic만 의심해서는 안 됩니다.

다음을 함께 확인합니다.

Camera 최대 소비전력
PoE Class
Switch PoE Budget
Port Event Log
Cable 길이와 상태
주변 온도

PoE는 고전력 구성이 될수록 Cable Bundle의 발열도 고려해야 하며, 실제 허용 조건은 도체 굵기와 온도 등 설치 조건에 영향을 받습니다.

30. Packet Capture와 전기 측정은 역할이 다르다#

Packet Capture는 다음과 같은 질문에 답하기 좋습니다.

요청을 보냈는가?
응답이 왔는가?
재전송이 있었는가?
Connection이 Reset됐는가?

Oscilloscope는 다른 질문에 답합니다.

전압은 정상인가?
Noise가 있는가?
Spike가 있는가?
Reflection이 있는가?
Signal Level이 정상인가?

따라서 둘 중 하나가 다른 하나를 대신하는 것이 아닙니다.

Packet Analyzer
+
전기 측정

을 필요에 따라 결합해야 합니다.

31. 가장 강력한 방법은 시간축을 맞추는 것이다#

간헐 장애에서 중요한 것은 모든 기록을 같은 시간축으로 놓는 것입니다.

예:

시간	관찰 내용
02:14:31.100	Barrier Motor ON
02:14:31.118	Power Voltage Drop
02:14:31.135	Controller Reset
02:14:31.160	RS-485 응답 중단
02:14:31.500	Server Timeout
02:14:33.020	Controller Online

이런 자료가 있다면:

서버에서 Timeout이 발생했다.

보다 훨씬 강한 결론을 내릴 수 있습니다.

핵심은 시간의 선후관계를 확인하는 것입니다.

32. 장애 기록에는 무엇을 남겨야 할까#

가능하면 다음 정보를 함께 기록합니다.

발생 시각
장비 ID
차로 ID
장비 상태
통신 Error
전원 상태
Interface Counter
주변 설비 상태
변경 이력
운영자 조치
복구 시각

예:

Time       : 02:14:31.135
Lane       : Entrance-02
Device     : GateController-02
Error      : RS485 CRC Error
Motor      : ON
Power      : 순간 저하 관찰
Recovery   : 2.1s 후 자동 복구

이 기록이 누적되면 간헐 장애도 패턴을 찾기 쉬워집니다.

33. 장애 분석에서는 변경 이력도 중요하다#

문제가 어느 날 갑자기 시작됐다면 다음 질문을 해봅니다.

최근 장비를 교체했는가?
Cable 공사가 있었는가?
Switch를 교체했는가?
Power Supply가 바뀌었는가?
Firmware가 변경됐는가?
근처에 새로운 Motor가 설치됐는가?
EV Charger가 추가됐는가?

예를 들어 장애 발생 하루 전:

기존 Cable Route 변경

이 있었다면 매우 중요한 단서입니다.

기술적인 측정만큼 변경 이력이 중요한 이유입니다.

34. 한 번에 여러 가지를 바꾸지 않는다#

장애가 발생하면 급한 마음에 다음을 한꺼번에 변경하는 경우가 있습니다.

Cable 교체
+
Termination 추가
+
Baud Rate 변경
+
Power Supply 교체
+
Timeout 변경

문제가 사라질 수는 있습니다.

하지만 무엇이 원인이었는지 알 수 없습니다.

더 좋은 방법은:

관찰
↓
가설 설정
↓
한 가지 변경
↓
동일 조건 재시험
↓
변경 전후 비교

입니다.

35. 사례 1 — 차단기가 새벽에만 멈춘다#

증상:

주간 정상
새벽 간헐 Reset

처음에는 서버 또는 Network 문제를 의심했습니다.

하지만 장애 시간을 비교해보니 특정 설비의 자동 운전 시간과 일치했습니다.

진단 흐름:

장애 시간 확보
↓
주변 설비 동작 기록 비교
↓
전원 측정
↓
특정 부하 동작 시 Voltage Drop 확인
↓
전원 계통 점검

이 경우 TCP Timeout을 늘리는 것은 해결책이 아닙니다.

36. 사례 2 — RFID Reader가 하루에 몇 번 사라진다#

구성은 다음과 같습니다.

Controller
↓
RS-485
↓
RFID Reader

로그는:

정상
정상
CRC Error
Timeout
정상

으로 나타납니다.

현장을 확인했더니 Connector Terminal 일부가 부식되어 있다고 가정해보겠습니다.

부식
↓
접촉 상태 변화
↓
Signal 품질 저하
↓
CRC Error
↓
Frame 폐기
↓
Timeout

이런 장애는 현장에 도착했을 때 정상일 가능성이 높기 때문에 Error 발생 시각과 물리 상태를 함께 기록하는 것이 중요합니다.

37. 사례 3 — Motor가 움직일 때만 통신 Error가 발생한다#

다음 패턴이 반복됩니다.

Motor OFF
→ 정상

Motor ON
→ CRC Error 증가

Motor OFF
→ 다시 정상

이 경우 확인할 순서는 다음과 같습니다.

Cable Route
↓
전원 Cable과의 근접 여부
↓
Shield 구조
↓
Ground 구조
↓
Termination
↓
실제 Signal

필요하다면 적절한 계측 장비를 사용해 실제 Signal 품질을 확인합니다.

단순히 더 좋은 Cable로 교체하기 전에 왜 Motor 동작과 장애가 연결되는지 증거를 확보하는 것이 중요합니다.

38. 사례 4 — 야간에만 IP Camera가 재부팅된다#

증상:

낮
정상

야간
Camera Offline
Camera Boot
다시 Online

확인할 항목:

IR 기능 활성화 시 소비전력
↓
PoE Port 상태
↓
PoE Budget
↓
Cable 상태
↓
Camera Log

이 경우 Network Packet을 아무리 분석해도 실제 원인이 PoE 전원 조건이라면 답을 찾기 어렵습니다.

39. Multimeter는 무엇을 확인하는 장비인가#

Multimeter는 현장에서 가장 기본적인 측정 도구입니다.

대표적으로:

DC Voltage
AC Voltage
Resistance
Continuity

등을 확인할 수 있습니다.

통신 장애에서는:

전원 입력
Cable Continuity
Connector 연결

등을 확인하는 데 사용할 수 있습니다.

하지만 빠른 Noise나 짧은 Spike를 Multimeter만으로 확인하기에는 한계가 있습니다.

40. Oscilloscope는 무엇을 확인할까#

Oscilloscope는 시간에 따라 전압이 어떻게 변하는지를 관찰합니다.

통신 장애에서는 상황에 따라 다음을 볼 수 있습니다.

Ripple
Spike
Overshoot
Ringing
Differential Signal
Common-mode Voltage
Signal Level
Timing

특히 RS-485 Reflection이나 전원 순간 변화를 확인할 때 유용할 수 있습니다.

41. Logic Analyzer와 Oscilloscope는 다르다#

Logic Analyzer는:

0
1
Byte
Frame
Protocol Timing

처럼 디지털 논리 상태를 관찰하는 데 유리합니다.

Oscilloscope는:

실제 Voltage
Noise
Waveform
Signal Integrity

를 보는 데 유리합니다.

따라서:

Byte 자체가 이상하다
→ Logic Analyzer 활용 가능

왜 Byte가 깨지는지 Signal이 의심된다
→ Oscilloscope 활용

처럼 사용할 수 있습니다.

42. Oscilloscope 측정은 안전 지식이 필요하다#

특히 Bench Oscilloscope는 Probe Ground가 보호접지와 연결된 구조일 수 있습니다.

잘못된 지점에 Ground Clip을 연결하면:

단락
장비 손상
측정 장비 손상
감전 위험

이 생길 수 있습니다.

따라서 Floating Circuit이나 Differential Signal을 측정할 때는 회로 구조에 맞는 측정 방법과 적절한 Probe를 사용해야 합니다.

측정 경험이 부족한 경우 전기 담당자나 장비 전문가와 함께 진행하는 것이 좋습니다.

43. 운영 장비에서 고의로 장애를 만들지 않는다#

원인을 찾기 위해 운영 중인 RS-485 Cable을 일부러 단락시키거나 접지를 임의로 변경하는 실험은 적절하지 않습니다.

대신 분리된 Test Bench를 사용합니다.

Test Power Supply
↓
Test Controller
↓
Test Cable
↓
Simulator

이 환경에서:

Cable 길이
Termination
Baud Rate
Frame Error
Timeout

등의 조건을 바꿔볼 수 있습니다.

운영 시스템과 장애 재현 시험을 분리하는 것이 안전합니다.

44. tcpdump와 Wireshark는 상위 현상을 확인하는 도구다#

Ethernet 기반 장비라면 허가된 환경에서 Packet Capture를 이용할 수 있습니다.

예를 들어 Modbus TCP 테스트 환경에서:

tcpdump -i eth0 'port 502' -w modbus_capture.pcap

처럼 Traffic을 저장할 수 있습니다.

Wireshark에서는:

요청과 응답
TCP Retransmission
Connection Reset
응답시간
Packet Loss 징후

등을 확인할 수 있습니다.

다만 Packet Capture는 전원 Voltage Drop이나 RS-485 Waveform 자체를 측정하는 도구가 아닙니다.

각 도구가 알려주는 범위를 구분해야 합니다.

45. 현장 진단의 가장 효율적인 순서#

간헐적인 통신 장애가 발생했다면 다음 순서로 범위를 좁혀볼 수 있습니다.

1. 장애 발생 시각 확인
        ↓
2. 장비와 배선 육안 점검
        ↓
3. 장비 Reset 여부 확인
        ↓
4. 전원 상태 확인
        ↓
5. Cable / Connector 확인
        ↓
6. 주변 EMI 발생원 확인
        ↓
7. Ground / Shield 구조 확인
        ↓
8. RS-485라면 Topology / Termination / Bias 확인
        ↓
9. Ethernet이라면 Port Error Counter 확인
        ↓
10. PoE라면 Power Budget 확인
        ↓
11. Protocol / Packet Log 분석
        ↓
12. 필요한 경우 Signal 측정

이 순서의 핵심은 값을 무작정 변경하기 전에 먼저 증거를 모으는 것입니다.

46. 장애 원인과 증상을 한눈에 정리하기#

원인	현장에서 보이는 현상	우선 확인
전원 부족	Reset·Offline	동작 중 입력 전압
Voltage Drop	특정 부하 동작 시 Reset	Power·Cable·Connector
Ripple	불규칙한 오동작	전원 Waveform
Surge	사건 이후 장비 불안정	보호회로·전원 계통
ESD	접촉 순간 Reset	ESD 보호 구조
Cable 손상	Link Down·CRC Error	Cable Test
Connector 부식	간헐적 연결	접점·Terminal
EMI	Motor 동작 시 Error	Cable Route·Shield
Ground 문제	Noise·통신 불안정	Ground 구조
RS-485 Termination	CRC·Frame Error	Bus 양 끝·Cable
RS-485 Bias	Idle 상태 오류	Fail-safe 구성
Ethernet 물리 오류	FCS·CRC Error	Cable·Port·NIC
Duplex 문제	Collision·성능 저하	Speed·Duplex
PoE 부족	Camera Reset	PoE Budget·PD 요구전력

47. 자기 점검#

Q1. 장비가 켜져 있으면 전원은 정상이라고 봐도 될까?#

아닙니다. 대기 상태에서는 정상이어도 부하가 증가하는 순간 전압이 떨어질 수 있습니다. 실제 장애가 발생하는 동작 조건에서 확인해야 합니다.

Q2. RS-485에서 120Ω Termination은 모든 장비에 설치해야 할까?#

아닙니다. Cable 특성 임피던스와 Bus 구조를 기준으로 사용하며 전형적인 Bus에서는 물리적인 양 끝에 설치하는 방식이 일반적입니다.

Q3. TCP Retransmission이 많으면 TCP 설정부터 바꿔야 할까?#

그렇지 않습니다. Ethernet Frame 손실이나 Cable·Port 문제로 인해 상위 계층에서 TCP 재전송이 발생할 수도 있습니다.

Q4. PoE Camera가 밤에만 꺼진다면 Network 문제일까?#

가능성 중 하나일 뿐입니다. 야간 IR 기능 등으로 소비전력이 증가할 수 있으므로 PoE Budget과 Port 전력 상태도 확인해야 합니다.

Q5. 간헐 장애에서 가장 중요한 자료는 무엇일까?#

발생 시각입니다. 전원, 장비 상태, Motor 동작, Error Counter, Packet Log 등 여러 자료를 같은 시간축으로 연결해야 원인과 결과를 구분할 수 있습니다.

48. 현장에서 기억해야 할 핵심 원칙#

첫째, Timeout은 원인이 아닐 수 있습니다.

Timeout은 상대방이 정해진 시간 안에 정상 응답하지 않았다는 결과일 뿐입니다.

둘째, 장비가 켜져 있다고 전원이 정상인 것은 아닙니다.

실제 부하 조건에서 확인해야 합니다.

셋째, Cable이 연결되어 있다고 물리 계층이 정상인 것은 아닙니다.

부분 단선, 부식, 접촉저항, EMI, Reflection 같은 문제가 존재할 수 있습니다.

넷째, Packet Error는 Protocol만의 문제가 아닐 수 있습니다.

Bit가 물리적으로 잘못 전달되면 CRC Error와 Timeout으로 이어질 수 있습니다.

다섯째, 간헐 장애는 시간축으로 분석해야 합니다.

전기적 변화
↓
장비 상태 변화
↓
통신 Error
↓
Application Error

의 순서를 찾아야 합니다.

49. 이 글을 마치며#

통신 장애를 분석할 때 가장 위험한 접근은 화면에 나타난 마지막 오류 메시지를 곧바로 원인이라고 판단하는 것입니다.

예를 들어:

서버 화면
Timeout

이라는 한 줄 아래에는 실제로 다음과 같은 과정이 숨어 있을 수 있습니다.

Power Connector 접촉 불량
↓
순간 Voltage Drop
↓
Controller Reset
↓
RS-485 응답 중단
↓
Gateway Timeout
↓
Server Timeout

또는:

Motor 동작
↓
EMI 증가
↓
RS-485 Signal 왜곡
↓
CRC Error
↓
Frame 폐기
↓
Retry
↓
응답 지연

일 수도 있습니다.

따라서 현장에서는 단순히:

통신이 안 됩니다.

라고 기록하지 않는 것이 중요합니다.

대신 다음 질문에 답할 수 있어야 합니다.

언제 발생했는가?

어떤 장비에서 발생했는가?

그 직전에 무엇이 동작했는가?

장비가 재부팅됐는가?

전원은 안정적이었는가?

Cable과 Connector는 정상인가?

Error Counter가 증가했는가?

Raw Frame은 정상인가?

어느 단계에서 처음 이상이 나타났는가?

결국 통신 장애 진단의 핵심은 전기적 현상과 통신 로그를 따로 보는 것이 아니라 하나의 시간 흐름으로 연결하는 것입니다.

전원, 접지, Cable, Connector, Signal, Frame, Protocol, Application을 순서대로 확인하면 단순한 Timeout이라는 메시지 뒤에 숨어 있는 실제 원인을 훨씬 빠르게 좁혀갈 수 있습니다.

현장에서 발생하는 통신 장애의 원인을 전기적으로 분석하는 방법