[Log] 우리 집 인터넷이 죽었다

5월 8일 밤 11시.
알바 퇴근하고 집에 들어와 맥북을 열었는데, 인터넷이 안 됐다.

 

가장 먼저 한 건 macOS의 networkQuality 명령어로 속도 측정. 평소에도 Wifi가 좀 이상하다 싶을 때 바로 꺼내는 명령어다. 근데 딜레이가 있더니, 그냥 끊겼다. 측정 자체가 안 됐다.

---

공유기 점검

종종 공유기가 맛이 가는 경우가 있으니까, 일단 인터넷 포트에 꽂힌 랜선을 뺐다가 다시 껴봤다. 재측정. 역시 안 됐다. 공유기 재부팅, 초기화, 전원 뽑았다 다시 켜기. 다 해봤다. 다 안 됐다.

 

그래서 게이트웨이로 ping을 날려봤다. 패킷 손실이 몇 개 있긴 했지만, ping 자체는 통했다. 근데 ping 8.8.8.8, ping google.com은 전부 막혔다. 외부와 연결이 아예 안 되는 상태였다.

마지막으로, 쓰지 않던 서브 공유기로도 테스트해봤는데, 증상이 똑같았다.

 

DHCP 문제?

공유기 내부 DHCP가 맛이 간 건 아닐까 싶었다. 서브 공유기에 연결해보니 대역이 다른 사설 IP가 잘 할당됐다. DHCP 문제는 아니었다. 일단 '공유기 자체 문제는 아닌 것 같다'는 결론을 내렸다.

 

AI와 함께 디버깅: 공유기의 공인 IP

이때부터 퍼플렉시티, ChatGPT의 도움을 받기 시작했다. AI가 공유기 관리 페이지에서 WAN IP랑 DNS 서버 할당 상태를 확인해보라고 했다.

 

관리 페이지에 들어가자마자 로그인부터 해야지 싶어서 시도했는데, 로그인이 안 됐다. 오타인가 싶었는데, 오타 문제는 아니었다.

 

그런데 알고 보니 로그인 창 바로 위에 WAN IP랑 DNS 서버 정보가 이미 떠 있었다. 외부 IP와 DNS 서버 항목이 전부 0.0.0.0이었다.

 

AI와 분석한 결과, '공유기가 공인 IP를 할당받지 못하고 있다'는 결론이 나왔다. 즉, 공유기 WAN 인터페이스가 ISP 측 DHCP 응답을 받지 못하고 있는 것.

 

직결 테스트

직접 연결해봐야겠다 싶었다. 공유기에 꽂혀있던 랜선의 반대쪽 끝을 따라가봤는데, 예상과 달리 벽의 랜 포트가 없었다. 선이 그냥 벽 안에서 나오고 있었다. 구축 아파트라 랜 포트가 없고, 배선이 직접 연결된 구조였다.

 

근데 이상한 점이 하나 더 있었다.

 

랜선이 끝에서 두 갈래로 나뉘어 있었는데:

• 하나는 맥북에서 아예 인식이 안 됐고
• 나머지 하나만 링크가 살아있었다.

두 갈래로 나뉘어져 있는 랜선...

 

인식되는 선으로 맥북에 직접 연결해보니, 이번엔 공인 IP가 직접 할당됐다.

 

그래서 바로 networkQuality를 실행했다. 처음엔 측정이 안 되는 듯하다가, 잠깐 기다리니까 결과가 떴다.

• Uplink capacity: 79 Mbps
• Downlink capacity: 측정되지 않음

 

평소라면 Uplink/Downlink 둘 다 표시되는데, 이번엔 Downlink 항목 자체가 나타나지 않았다. 송신은 일부 가능했지만, 수신 쪽은 사실상 정상 동작하지 못하는 상태처럼 보였다.

 

Idle Latency도 평소보다 비정상적으로 높게 측정됐다. 평소에는 수십 ms 정도가 나오는데, 위 결과를 보면 약 1초 수준까지 올라갔다.

단순히 인터넷이 안 되는 수준이 아니라, 회선 자체가 매우 불안정한 상태처럼 보였다.

 

이 순간부터 느낌이 왔다.

"아 이거 공유기 문제가 아니라, 물리 계층 쪽 문제 같은데...?"

 

이거... 물리 계층 문제 같다...

AI와 결과를 계속 공유하면서 같이 좁혀갔는데, 결론은 거의 같았다. 건물 배선, 혹은 외부 라인 문제 가능성이 높다는 것.

 

근거는 세 가지였다.

1. 메인 공유기와 서브 공유기 증상이 동일함
2. DHCP는 정상 동작함
3. 직결 상태에서도 다운로드/업로드 속도가 비정상적으로 벌어짐

특히 세 번째가 결정적이었다. 정상적인 회선이라면 다운로드와 업로드 속도가 이렇게 극단적으로 벌어지기 어렵다. 수치 자체가 이상했다.

 

근데 내가 할 수 있는 건 없었다.

 

시간은 새벽 1시가 넘어갔고, 경비실도 연락이 안 됐다. 결국 그날은 포기하고 잠들었다.

 

"라인 문제 확인됐습니다"

다음 날 아버지께 상황을 말씀드렸다.

 

아버지가 통신사에 바로 문의하셨고, 통신사 쪽에서 "라인 문제 확인됐다"는 답변을 받으셨다.

 

장애 발생 하루 전에 옆옆집이 이사를 왔었다. 정확한 원인은 모르지만, 이사 과정에서 배선을 건드린 게 아닐까 싶었다.

 

OSI 모델을 몸으로 쓰다

A/S 기사님은 5월 11일에 방문하시기로 했다. 5월 9일, 나는 알바 퇴근 후 집에 바로 가지 않고 편의점에 남아서 이 포스팅 초안을 정리했다.

9일에는 사진을 남기지 않았다... 5월 10일에도 퇴근 후 편의점에서 작업했다.

 

예전이었으면 '인터넷 왜 안 돼!!' 하면서 바로 통신사에 전화했을 것 같다. 근데 리눅스 마스터 공부하면서 네트워크를 조금씩 알게 됐고, 인프라 공부를 이어오다 보니 '직접 해결해보고 싶다'는 욕구가 먼저 올라왔다.

 

돌아보면 이 과정에서 OSI 모델을 자연스럽게 사용하고 있었다.

• 웹 접속 불가 (L7)
• DHCP 정상 동작 (L7 기반 프로토콜, 로컬 IP 설정은 정상 할당)
• 공유기 WAN IP 0.0.0.0 (L3)
• 구축 아파트 배선 의심 (L1)

예전엔 "OSI 계층 외워야지"에 가까웠다면, 이번엔 달랐다. 어느 계층에서 문제가 발생했는지 추론하고, 범위를 좁혀가는 과정 자체가 네트워크 디버깅이라는 걸 몸으로 느꼈다.

 

앞으로 인프라 작업할 때도 이 감각을 계속 써먹을 수 있을 것 같다.

 

그리고 인터넷이라는 게 평소엔 너무 당연해서 의식조차 안 하는데, 막상 장애가 생기니까 수많은 계층과 장비, 프로토콜 위에 올라타 있었다는 게 실감났다.

---

5월 11일, 인터넷 복구

기사님은 오후 12시쯤 방문 예정이었다.

 

근데 오전 11시쯤, 아파트 주차장에 통신사 차량 몇 대가 보였다. 순간 "설마?" 싶어서 공유기 전원을 다시 켜고 networkQuality를 실행해봤다. 정상으로 돌아와 있었다.

 

바로 기사님께 연락드렸다. 사실 오시면 이것저것 여쭤보고 싶었다. 원인이 정확히 뭐였는지, 배선 문제였는지, 다른 집도 같은 증상이었는지. 근데 이미 정상으로 작동하는데 굳이 오시게 하기가 죄송해서 그냥 연락드렸다 ㅎㅎ..

 

내 추측이지만:

• 통신사에서 "라인 문제 확인됐다"고 했던 점
• 실제로 통신사 차량들이 단지에 와있었던 점
• 공유기 교체 여부와 관계없이 동일 증상이 발생했던 점

이걸 보면 아파트 단지 전체 혹은 일부 라인에 문제가 있었던 것 같다.

 

어쨌든 해결돼서 다행이었다. 진짜 많이 답답했는데, 인터넷이 다시 연결되는 순간 속이 시원했다.