랜선을 뺐다 꽂으면 왜 장비가 다시 살아날까? RS-232에서는 드물었던 LAN 통신 장애의 원인
1장. 랜선을 뺐다 꽂으면 왜 장비가 다시 살아날까?#
현장에서 시작하는 질문#
현장에서 장비 연동을 오래 하다 보면 설명하기 묘한 경험을 하게 됩니다.
RS-232로 연결된 장비는 한 번 설치해 놓으면 몇 년 동안 별문제 없이 돌아가는 경우가 많았습니다. 그런데 LAN으로 연결된 장비에서는 이상하게 다음과 같은 상황을 더 자주 만났습니다.
어제까지 멀쩡하던 장비가 갑자기 통신되지 않는다.
프로그램을 확인해도 특별한 문제가 없다.
장비 전원도 들어와 있다.
스위치도 정상처럼 보인다.
그런데 랜 케이블을 한 번 뺐다가 다시 꽂으면 정상으로 돌아온다.
처음 이런 상황을 만나면 대개 이렇게 생각합니다.
"랜선이 헐거워졌나?"
실제로 그럴 수도 있습니다.
하지만 Ethernet에서는 랜 케이블을 뺐다가 다시 꽂는 행동이 단순히 접촉을 다시 만드는 것 이상의 변화를 일으킵니다.
그렇기 때문에 다음과 같은 질문이 필요합니다.
정말 랜 케이블의 접촉 문제였을까, 아니면 케이블을 다시 꽂으면서 Ethernet 링크 자체가 초기화된 것일까?
이 차이를 이해하면 현장에서 반복되는 수많은 간헐적 통신 장애를 바라보는 방식이 달라집니다.
RS-232는 괜찮았는데 왜 LAN에서는 이런 일이 더 자주 느껴졌을까?#
이 글에서 이야기하는 것은 "Ethernet은 RS-232보다 신뢰성이 낮다"는 뜻이 아닙니다.
현대 Ethernet은 충분히 안정적인 통신 기술입니다.
하지만 필자가 실제 장비 연동 현장에서 경험했을 때는 RS-232 장비보다 LAN으로 연결된 장비에서 간헐적인 통신 장애를 만나는 일이 확실히 더 많았습니다.
여기에는 몇 가지 이유가 있습니다.
가장 먼저 보이는 차이는 커넥터입니다.
RS-232 장비에서 흔히 사용되는 DB9 커넥터는 양쪽에 나사가 있습니다.
장비
│
└── DB9
├── 나사
├── 핀
└── 나사한번 제대로 체결하면 사람이 의도적으로 풀지 않는 이상 쉽게 움직이지 않습니다.
반면 일반적인 Ethernet 장비는 RJ45 커넥터를 사용합니다.
장비
│
└── RJ45
└── 작은 플라스틱 래치RJ45 역시 정상적으로 체결하면 쉽게 빠지는 구조는 아니지만, 장비가 설치되는 환경은 사무실 책상 위와 다릅니다.
케이블이 아래로 길게 늘어져 있을 수도 있고, 제어반 문을 열고 닫으면서 움직일 수도 있습니다. 장비에서 진동이 발생하거나 사람이 정비하면서 케이블을 건드릴 수도 있습니다.
산업 환경의 Ethernet 배선에서는 실제로 진동, 반복적인 굽힘, 습기, 온도 변화, 전자기 간섭 등이 간헐적인 연결 장애를 일으킬 수 있습니다. 산업용 네트워크에서는 이런 환경 요인을 기계적 영향, 오염·습기, 기후, 전자기 환경으로 구분해 관리하기도 합니다.
즉 문제는 단순히 "랜선이 잘 빠진다"가 아닙니다.
LAN 연결은 현장 환경의 영향을 받을 수 있는 요소가 더 많습니다.
랜 케이블이 시간이 지나면서 정말 헐거워질 수 있을까?#
가능합니다.
하지만 조금 더 정확하게 표현할 필요가 있습니다.
LAN 케이블 전체가 느슨해지는 것이 아니라 RJ45 플러그와 포트 사이의 접촉 상태가 나빠지는 것에 가깝습니다.
커넥터 내부에는 여러 개의 금속 접점이 있습니다.
RJ45
┌───────────────────┐
│ 1 2 3 4 5 6 7 8 │
└───────────────────┘
↓
금속 접점처음 설치했을 때는 정상적으로 접촉하고 있더라도 시간이 지나면서 여러 환경 요인이 영향을 줄 수 있습니다.
- 지속적인 진동
- 케이블 무게와 장력
- 반복적인 케이블 움직임
- 먼지와 오염
- 습기
- 온도 변화
- 커넥터 품질
- 포트 접점 노후
- 케이블 내부 손상
특히 산업 환경에서는 진동이나 온도 변화 때문에 평소에는 정상인 연결이 특정 순간에만 높은 저항이나 순간적인 단선을 보일 수 있습니다. 이런 문제는 일반적인 연속성 검사에서는 정상으로 나오는 경우도 있습니다.
이 때문에 더 골치 아픕니다.
완전히 고장 난 케이블이라면 오히려 찾기 쉽습니다.
하지만 이런 장애는
정상
↓
정상
↓
정상
↓
가끔 패킷 오류
↓
다시 정상
↓
통신 장애처럼 나타납니다.
현장 엔지니어 입장에서는 가장 싫은 유형입니다.
그런데 랜선을 다시 꽂으면 왜 살아날까?#
여기서부터가 중요합니다.
랜선을 뺐다가 다시 꽂는 행동은 두 가지 효과를 동시에 만들 수 있습니다.
첫 번째는 물리적인 접점을 다시 만드는 것이다#
RJ45를 빼고 다시 삽입하면 플러그의 금속 접점과 포트 내부 접점이 다시 맞닿게 됩니다.
접촉 상태가 좋지 않았다면 이것만으로 상태가 좋아질 수 있습니다.
접점 불량
Port ─╳─ RJ45
↓ 재삽입
Port ─── RJ45그래서 정말 커넥터나 케이블 문제였다면 랜선을 다시 꽂는 것만으로 당분간 정상 작동할 수 있습니다.
하지만 문제가 해결됐다고 생각해서는 안 됩니다.
며칠 또는 몇 달 후 동일 증상이 다시 발생할 가능성이 있기 때문입니다.
두 번째는 Ethernet 링크 자체가 다시 시작된다는 것이다#
이쪽이 더 흥미롭습니다.
케이블을 뽑으면 장비와 스위치는 물리적인 연결이 사라진 것을 감지합니다.
Link Up
↓
케이블 제거
↓
Link Down다시 연결하면 새로운 연결 과정이 시작됩니다.
케이블 연결
↓
신호 감지
↓
링크 설정
↓
속도와 Duplex 협상
↓
Link UpAuto-Negotiation을 사용하는 Ethernet에서는 양쪽 장치가 지원하는 통신 조건을 협상합니다. Cisco 역시 Ethernet 연결 문제를 진단할 때 케이블 변경, 다른 포트 사용, 포트 초기화와 함께 Auto-Negotiation 상태를 확인하도록 안내하고 있습니다.
따라서 케이블을 다시 꽂아서 살아났다고 해서 반드시 접촉 불량이었다고 볼 수 없습니다.
실제로는
케이블 재삽입 → Link Down → Link Up → 링크 재협상 → 정상화
가 이루어졌을 수도 있습니다.
우리가 흔히 했던 잘못된 결론#
현장에서 이런 일이 생기면 대화는 대개 짧습니다.
"랜선 한번 뺐다 꽂아보세요."
그리고 살아납니다.
"됐네요."
문제는 여기서 끝납니다.
하지만 장애 분석 관점에서는 아무것도 해결되지 않았습니다.
우리가 확인한 것은 단 하나입니다.
랜선을 재삽입했더니 정상화됐다.
원인은 아직 모릅니다.
가능한 원인은 여러 가지입니다.
랜 케이블 재삽입
│
┌───────────────┼───────────────┐
↓ ↓ ↓
접점 복구 Link 재설정 장비 상태 변화
│ │ │
↓ ↓ ↓
RJ45 / Cable Auto-Negotiation NIC / Driver그래서 다음부터는 조금 다른 방식으로 확인할 필요가 있습니다.
랜선을 뽑기 전에 먼저 Link LED를 본다#
현장 장애가 발생했을 때 가장 먼저 랜선을 뽑아버리면 중요한 증거 하나가 사라집니다.
바로 Link 상태입니다.
LAN 포트에는 일반적으로 Link 또는 Activity LED가 있습니다.
통신이 안 되는 순간에 이것을 먼저 확인해야 합니다.
Link LED가 꺼져 있다#
물리 계층 문제일 가능성이 커집니다.
[장비] ───── [Switch]
Link Down확인 대상은 다음과 같습니다.
- 랜 케이블
- RJ45 커넥터
- 장비 LAN 포트
- 스위치 포트
- 케이블 내부 단선
- 전원 상태
Cisco가 2026년 갱신한 포트 플랩 진단 문서에서도 반복적인 링크 Up/Down의 원인으로 불량 케이블, 협상 문제, 단말 동작, 기타 물리 계층 문제 등을 제시합니다.
Link LED는 살아 있는데 통신이 안 된다#
상황이 조금 달라집니다.
물리적인 Link는 형성되어 있다는 뜻입니다.
이때는 범위를 위쪽으로 올려야 합니다.
Physical Link OK
↓
Ethernet ?
↓
IP ?
↓
TCP/UDP ?
↓
Application ?Ping이 되는지, ARP가 정상인지, TCP 연결이 만들어지는지, 장비 애플리케이션이 정상인지 차례로 확인해야 합니다.
이것이 케이블을 바로 뽑으면 안 되는 이유입니다.
뽑는 순간 기존 Link 상태라는 중요한 장애 증거가 사라집니다.
스위치 포트를 바꿨더니 해결되는 경우#
현장에서 또 자주 사용하는 방법이 있습니다.
Switch Port 1
↓
통신 불량
Switch Port 2
↓
정상이 경우 많은 사람이 바로 이렇게 판단합니다.
"1번 포트가 고장 났네."
가능성은 높아졌지만 아직 확정은 아닙니다.
케이블을 옮기는 과정에서 RJ45가 다시 체결됐고 Ethernet 링크도 재협상됐기 때문입니다.
따라서 가능하면 조건을 하나씩 바꾸는 것이 좋습니다.
1단계
같은 케이블 + 같은 포트
2단계
다른 케이블 + 같은 포트
3단계
같은 케이블 + 다른 포트
4단계
다른 케이블 + 다른 포트이렇게 해야 장애 범위를 좁힐 수 있습니다.
케이블이 멀쩡해 보여도 문제가 될 수 있다#
겉으로 랜 케이블을 보면 아무 문제가 없어 보일 수 있습니다.
피복도 멀쩡합니다.
RJ45도 정상입니다.
테스터로 찍어봐도 연결되어 있다고 나옵니다.
그런데 실제 통신에서는 오류가 발생합니다.
이런 현상이 가능한 이유는 Ethernet이 단순히 전선이 연결되어 있느냐만 검사하는 통신이 아니기 때문입니다.
신호의 품질이 중요합니다.
산업 Ethernet에서는 진동, 습기, 온도 변화 등으로 특정 선의 저항이 순간적으로 높아지면서 간헐적인 패킷 손실이 생길 수 있습니다. 또한 기본적인 continuity 검사만으로는 이런 접촉 문제를 잡아내지 못할 수도 있습니다.
그래서
"테스터 찍어봤는데 랜선 정상인데요?"
라는 말이 항상 랜선이 완벽하다는 의미는 아닙니다.
장비가 설치된 장소도 반드시 봐야 한다#
네트워크 장애를 서버실 관점에서만 보면 놓치는 것이 있습니다.
장비가 어디에 설치되어 있는지입니다.
예를 들어 다음과 같은 장소라면 이야기가 달라집니다.
- 주차장
- 공장
- 물류센터
- 생산라인
- 옥외 함체
- 엘리베이터 주변
- 차단기 내부
- 모터 주변
- 전력 설비 주변
이런 환경에서는 일반 사무실에서 거의 고려하지 않는 요소들이 등장합니다.
진동#
모터나 기계 움직임 때문에 지속적인 미세 진동이 발생할 수 있습니다.
온도#
여름과 겨울 또는 장비 작동 상태에 따라 온도 변화가 클 수 있습니다.
케이블과 커넥터 역시 온도 변화의 영향을 받습니다.
습기와 먼지#
접점과 장비 내부에는 좋지 않은 조건입니다.
전자기 간섭#
모터, VFD, 릴레이, 용접기 등의 장비에서는 전자기 노이즈가 발생할 수 있습니다.
산업 Ethernet 관련 표준과 테스트 지침이 기계적 영향, 습기와 오염, 기후, 전자기 환경을 별도로 다루는 이유도 여기에 있습니다.
그래서 산업 현장에는 M12 같은 커넥터가 존재한다#
일반적인 사무실에서는 RJ45가 매우 훌륭한 커넥터입니다.
하지만 진동이나 충격이 심한 환경에서는 다른 선택지가 사용됩니다.
대표적인 것이 M12입니다.
M12 Ethernet 커넥터는 회전 잠금 구조를 사용하기 때문에 진동과 충격이 있는 환경에서 사용할 수 있습니다.
산업 Ethernet에서도 더 강한 충격과 진동 환경을 위해 M12와 같은 잠금식 커넥터를 활용합니다.
재미있는 점은 결국 다시 RS-232에서 보았던 특징으로 돌아간다는 것입니다.
DB9
└─ 나사 체결
산업용 M12
└─ 잠금 체결
일반 RJ45
└─ 래치 체결현장이 거칠어질수록 통신 프로토콜만큼 커넥터의 기계적인 고정 방식도 중요해집니다.
RS-232와 Ethernet은 장애가 발생하는 범위 자체가 다르다#
RS-232는 비교적 단순합니다.
장비 A
│
RS-232
│
장비 B주로 확인할 것은 다음과 같습니다.
- TX
- RX
- GND
- Baud Rate
- Data Bit
- Parity
- Stop Bit
Ethernet 장비는 구조가 훨씬 커질 수 있습니다.
장비
│
RJ45
│
랜 케이블
│
Switch
│
Network
│
Server
│
Application그리고 그 사이에는 여러 상태가 존재합니다.
Physical
↓
Ethernet
↓
ARP
↓
IP
↓
TCP / UDP
↓
Application Protocol따라서 현장에서 사람이 느끼는 장애 가능 지점도 많아집니다.
RS-232 통신에서 문제가 없었다고 해서 Ethernet이 열등한 것은 아닙니다.
Ethernet이 제공하는 기능과 연결 범위 자체가 훨씬 넓기 때문에 문제가 발생했을 때 확인해야 할 영역 역시 훨씬 넓어진 것입니다.
현장에서 실제로 사용했던 가장 강력한 방법#
비싼 분석 장비가 없어도 가장 먼저 할 수 있는 테스트가 있습니다.
랜 케이블을 새것으로 바꿔보는 것입니다.
하지만 중요한 것은 순서입니다.
기존 케이블을 바로 버리지 않습니다.
먼저 장애 상태를 기록합니다.
1. Link LED 확인
2. Ping 확인
3. 장비 접속 확인
4. Switch Port 상태 확인
5. 기존 케이블 상태 기록그다음 케이블을 교체합니다.
기존 Cable
↓
통신 장애
새 Cable
↓
정상그리고 며칠 또는 일정 기간 관찰합니다.
새 케이블에서 동일 장애가 발생하지 않는다면 기존 케이블 또는 커넥터에 대한 의심이 크게 높아집니다.
반대로 새 케이블에서도 다시 발생하면 다른 곳을 봐야 합니다.
Cable 교체
↓
문제 재발
↓
Switch Port
↓
장비 NIC
↓
Network
↓
Application장애 분석에서 중요한 것은 한 번에 여러 가지를 바꾸지 않는 것입니다.
현장에서 기억해야 할 체크리스트#
LAN 장비가 갑자기 통신되지 않는다면 랜선을 바로 뽑기 전에 다음 순서로 확인합니다.
1. Link LED#
켜져 있는가?
2. Activity LED#
패킷이 오가는 흔적이 있는가?
3. Ping#
IP 통신이 가능한가?
4. 다른 장비에서 접근#
서버 한 대만의 문제인가?
5. Switch Port 상태#
Link Down이나 반복적인 Up/Down 기록이 있는가?
6. Error Counter#
CRC 또는 기타 인터페이스 오류가 증가하는가?
7. 케이블을 움직였을 때 변화#
케이블이나 RJ45를 건드리면 Link가 끊어지는가?
8. 다른 케이블#
케이블을 변경하면 문제가 사라지는가?
9. 다른 스위치 포트#
동일 케이블을 다른 포트에 연결하면 정상인가?
10. 랜선을 재삽입#
마지막으로 재삽입했을 때 정상화되는지 확인한다.
이 순서가 중요한 이유가 있습니다.
처음부터 랜선을 뽑으면 장애가 발생했던 순간의 증거를 스스로 지워버릴 수 있기 때문입니다.
"랜선을 한번 뺐다 꽂아보세요"는 해결책이 아니다#
현장에서는 굉장히 효과적인 말입니다.
실제로 수많은 문제가 이것으로 해결됩니다.
하지만 장애 분석에서는 조금 다르게 생각해야 합니다.
랜선을 다시 꽂았다는 것은
접점을 다시 만들었고
+
물리 링크를 끊었다가
+
Ethernet 링크를 다시 만들었고
+
네트워크 상태 일부를 변화시켰다는 뜻입니다.
즉 여러 조건을 한꺼번에 바꿔버린 것입니다.
그래서 정상화됐다고 해서 원인을 알게 된 것은 아닙니다.
복구와 원인 규명은 다른 작업입니다.
RS-232는 몇 년씩 괜찮았는데 LAN은 왜 이랬을까#
필자의 현장 경험에서는 분명한 차이가 있었습니다.
RS-232 장비는 설치 후 거의 신경 쓰지 않고 사용하는 경우가 많았습니다.
LAN 장비에서는 간헐적으로
통신 장애
→ 랜선 재삽입
→ 정상화되는 상황을 더 많이 경험했습니다.
그 경험은 충분히 설명 가능합니다.
RS-232는 상대적으로 단순한 Point-to-Point 구조이고 DB9를 사용하는 장비라면 나사로 단단하게 고정됩니다.
반면 Ethernet은 RJ45와 케이블뿐 아니라 PHY, Link, Auto-Negotiation, Switch Port, IP 네트워크, NIC 등 훨씬 많은 요소가 연결에 참여합니다.
여기에 현장의 진동, 온도, 습기, 먼지와 전자기 환경까지 더해집니다.
따라서 LAN에서 장애가 더 자주 느껴졌던 것은 단순히 랜선 하나가 약해서가 아니라 장애가 만들어질 수 있는 조건과 경로가 더 많았기 때문이라고 보는 것이 합리적입니다.
현장에서는 작은 물리적 문제가 거대한 소프트웨어 장애처럼 보인다#
개발자는 통신 장애가 발생하면 자연스럽게 프로그램부터 봅니다.
로그를 확인합니다.
Socket을 확인합니다.
Timeout을 확인합니다.
Server를 재시작합니다.
장비 프로그램도 의심합니다.
몇 시간을 소스 코드에서 헤맬 수도 있습니다.
그런데 결국 누군가 장비 앞으로 가서 말합니다.
"잠깐만요. 랜선 한번 뺐다 꽂아볼게요."
그리고 살아납니다.
허탈합니다.
하지만 이것이 장비 연동의 현실입니다.
소프트웨어와 네트워크는 결국 물리적인 세계 위에서 움직입니다.
케이블 하나, 커넥터 하나, 포트 하나가 전체 시스템을 멈출 수 있습니다.
그래서 장비 연동에서 가장 중요한 습관 중 하나는 이것입니다.
코드를 의심하기 전에 물리 계층부터 확인한다.
그리고 한 단계 더 나아가야 합니다.
랜선을 다시 꽂아 살아났다면 해결됐다고 생각하지 말고, 무엇이 다시 초기화됐는지를 생각한다.
그 순간부터 단순한 장애 대응이 장애 분석으로 바뀝니다.