[🛠] IT Operations #1: 내가 회사 공유기 ‘인터넷 연결 없음’ 이슈를 해결한 방법 (feat. Codex)

✨ GPT-5.6 Sol의 요약 　

휴대폰은 2층 공유기에, Mac 브라우저는 회사 공유기에 연결해 Codex가 실제 장비를 직접 진단하도록 만들고, 그 과정을 보며 네트워크를 실시간으로 배워 장애까지 복구한 기록.

오늘 회사 2층 Wi-Fi가 이상했다. 신호는 아주 잘 잡히는데 인터넷은 안 됐다. 공유기는 켜져 있고 휴대폰도 연결됐는데 화면에는 계속 인터넷에 연결되어 있지 않음이 떴다.

눈앞의 공유기는 전원도 들어와 있고 LAN 표시등도 움직였다. 겉만 봐서는 어디가 막혔는지 알 수 없었다.

예전 같았으면 공유기 전원을 몇 번 껐다 켜고, 랜선이 잘못 꽂혔나 확인하고, 그래도 안 되면 검색부터 했을 것이다. 그런데 이틀 전 AI를 적극 활용할 줄 알면 할 수 있는 일이 무궁무진해진다를 쓰면서 새로운 작업 방식을 하나 익혔다.

내가 실제 장비와 화면을 AI에게 연결해주면 된다.

이번에는 그 방식을 그냥 바로 써먹었다. 휴대폰을 USB로 Mac에 연결하고 ADB를 열었다. 휴대폰은 문제가 생긴 2층 Wi-Fi에 붙였다. 휴대폰 Chrome에는 2층 공유기 관리자 화면을 열고 로그인했다. Mac Chrome에는 회사 공유기 관리자 화면을 열고 로그인했다. 그리고 Codex에게 말했다.

핵심은 내가 공유기 설정을 전부 직접 알아낸 것이 아니라, Codex가 실제로 작업할 수 있도록 물리 장비와 명령 실행 환경, 로그인된 관리자 화면을 먼저 셋업했다는 점이다.

현재 상황부터 파악해. 함부로 바꾸면 문제 있을 수도 있으니까. 웬만하면 커맨드로 먼저 해결 시도해보고.

이제 Codex는 설명만 해주는 챗봇이 아니었다. 휴대폰의 네트워크 상태를 명령어로 읽고, 내가 로그인해둔 두 관리자 화면을 Computer Use로 오가며 실제 설정을 확인하고 바꿀 수 있었다.

휴대폰과 브라우저를 연결해 두 네트워크를 한꺼번에 보여줬다

처음에는 192.168.0.1이 왜 열리지 않는지도 몰랐다. 확인해보니 두 공유기는 서로 다른 역할을 하고 있었다.

회사 공유기 192.168.0.1
  └─ 2층 ipTIME WAN 192.168.0.86
       └─ 2층 Wi-Fi / LAN 192.168.1.x
            └─ 2층 공유기 관리 화면 192.168.1.1

Mac은 회사망에 붙어 있으니 회사 공유기 192.168.0.1을 열 수 있었다. 반면 2층 Wi-Fi에 붙은 휴대폰은 192.168.1.x 주소를 받고 192.168.1.1을 게이트웨이로 사용했다. 그래서 Mac 브라우저에는 회사 공유기를, 휴대폰 브라우저에는 2층 공유기를 열어둔 것이다.

화면만 보여준 것도 아니다. ADB가 붙어 있으니 Codex는 휴대폰이 받은 IP와 route를 읽고, 2층 Wi-Fi 인터페이스를 지정해서 직접 통신을 검사했다. 휴대폰은 Wi-Fi가 끊겨도 모바일 데이터로 인터넷 요청을 성공시킬 수 있어서, 그냥 ping을 날리면 결과를 잘못 볼 수 있었다.

adb shell "ping -I wlan0 -c 3 -W 2 192.168.1.1"
adb shell "ping -I wlan0 -c 3 -W 2 192.168.0.1"
adb shell "ping -I wlan0 -c 3 -W 2 1.1.1.1"

adb shell "curl --interface wlan0 -k -sS -o /dev/null \
  -w '%{http_code}' --connect-timeout 5 --max-time 10 \
  https://www.google.com/generate_204"

결과는 이랬다.

• 휴대폰에서 2층 공유기 192.168.1.1까지는 응답했다.
• 회사 공유기 192.168.0.1부터 응답하지 않았다.
• 외부 IP 1.1.1.1도 응답하지 않았다.
• HTTPS 검사는 000으로 끝났다.

나는 이 과정을 옆에서 그대로 봤다. Wi-Fi 신호가 잡힌다는 건 휴대폰과 2층 공유기 사이가 연결됐다는 뜻일 뿐이었다. 문제는 그다음, 2층 공유기의 WAN이 회사망으로 나가는 구간에 있었다.

네트워크 책을 먼저 펼쳐서 LAN, WAN, 게이트웨이, 이중 NAT를 순서대로 공부한 게 아니다. 실제 장애를 Codex가 하나씩 잘라 검사하는 걸 보면서 192.168.0.1과 192.168.1.1이 왜 둘 다 존재하는지 바로 이해했다.

DHCP 임대가 정상이어도 통신은 막힐 수 있었다

같은 날 개발 NAS와 데이터 NAS의 IP도 바뀌어 있었다. 회사 공유기의 DHCP 클라이언트 목록에서 현재 주소와 MAC 주소를 찾고, 두 NAS가 다음에도 같은 주소를 받도록 예약했다. 앞서 NAS로 옮긴 연차 자동화로 들어오던 HTTP·HTTPS 포트 포워딩도 새 주소를 가리키게 맞췄다.

그 과정에서 DHCP가 무엇인지도 필요해진 순간에 바로 배웠다.

• 일반 DHCP 할당은 남는 IP를 장치에 빌려준다.
• DHCP 예약은 특정 MAC 주소가 접속할 때 같은 IP를 주게 한다.
• 장비 자체에 고정 IP를 넣는 것과 공유기에서 DHCP 예약을 거는 것은 다르다.

그런데 2층 공유기 문제는 DHCP 예약만으로 설명되지 않았다. ipTIME 관리 화면에는 외부 IP가 192.168.0.86으로 표시됐고 상태도 인터넷에 연결됨이었다. 회사 공유기에도 같은 IP를 현재 ipTIME에 임대한 기록이 있었다.

중간에 Codex가 DHCP 목록의 현재 페이지만 보고 .86이 없다고 잘못 판단했다. 클라이언트가 90대가 넘어서 목록이 여러 페이지로 나뉘어 있었는데, 나는 다른 페이지에서 해당 행을 이미 보고 있었다.

있는데?

내가 MAC 주소와 .86 임대 행을 다시 보여주자 조사 방향이 바뀌었다. IP를 못 받은 문제가 아니라, IP를 받은 뒤의 통신을 막는 설정을 찾아야 했다.

WAN 연결을 해제했다가 다시 연결해도 결과는 같았다. 접속 제어 기능은 켜져 있었지만 블랙리스트는 비어 있었다. 그러다 IP&MAC 바인딩 화면에서 원인이 나왔다. .86이 현재 ipTIME WAN MAC이 아니라 예전에 쓰던 데스크톱 MAC에 묶여 있었다.

DHCP 서버: 현재 ipTIME에 192.168.0.86을 임대
IP&MAC 바인딩: 192.168.0.86은 예전 PC MAC이라고 기록

DHCP는 현재 장치에 주소를 줬지만, 보안 설정은 그 주소의 주인이 다른 장치라고 보고 있었다. 그래서 ipTIME은 관리자 화면에서 IP를 받은 것처럼 보이면서도 회사 공유기와 통신하지 못했다.

IP를 받았다와 그 IP로 통신할 수 있다는 같은 말이 아니었다. 이것도 장애를 따라가다 보니 자연스럽게 이해됐다.

오래된 바인딩 한 건만 지우고 실제 Wi-Fi에서 다시 검증했다

공유기의 보안 기능 전체를 끄지는 않았다. 문제가 된 .86의 오래된 IP–MAC 바인딩 한 건만 삭제하고, ipTIME의 WAN 연결을 다시 협상했다.

이번에는 바로 달라졌다.

192.168.0.1  ping 성공
1.1.1.1      ping 성공
HTTPS        204
Android Wi-Fi VALIDATED

복구 뒤에는 현재 ipTIME WAN MAC이 항상 .86을 받도록 DHCP 주소 예약을 추가했다. DHCP 예약은 현재 장치에 같은 주소를 계속 주고, IP–MAC 바인딩은 그 주소를 쓸 수 있는 장치를 강제한다. 이번 장애는 두 기록이 서로 다른 장치를 가리켜서 생겼다.

인터넷은 살아났지만 2층 ipTIME이 회사망 아래에 별도 192.168.1.x 네트워크를 만드는 이중 NAT 구조는 그대로다. AP·허브 모드로 바꾸려면 DHCP와 관리 IP뿐 아니라 실제 랜선이 WAN과 LAN 중 어디에 꽂혔는지도 함께 바꿔야 한다. 원격에서 섣불리 손대면 관리 화면과 2층 장비를 한꺼번에 잃을 수 있어서, 오늘은 확인된 인터넷 장애 원인만 고쳤다.

네트워크를 다 배운 뒤 고친 게 아니라, 고치는 과정을 보며 배웠다

오늘 내가 한 일의 핵심은 네트워크 지식을 미리 다 공부해서 공유기를 고친 것이 아니다.

문제가 생기자 7월 22일에 발견한 작업 방식을 바로 꺼냈다. 내가 아니면 할 수 없는 물리적인 연결과 로그인을 먼저 했다. 휴대폰을 2층 Wi-Fi에 붙이고 USB로 Mac에 연결했다. 두 공유기 관리자 화면을 각각 열어뒀다. 변경 범위를 정하고, Codex가 놓친 DHCP 행이 보이면 다시 짚었다.

그다음부터는 Codex가 움직일 수 있었다. 명령어로 어느 구간까지 통신하는지 확인하고, Computer Use로 두 관리자 화면의 설정을 읽고, 가능한 원인을 하나씩 지운 뒤, 필요한 한 건만 수정하고 같은 휴대폰에서 다시 검증했다.

온갖 네트워크 지식을 따로 공부한 뒤 실전에 들어간 게 아니다. 지금 필요한 개념이 실제 화면과 명령 결과에 붙어서 바로 들어왔다. DHCP, MAC 주소, 게이트웨이, LAN과 WAN, IP–MAC 바인딩, 이중 NAT가 외워야 할 용어가 아니라 눈앞의 장애가 왜 생겼는지를 설명하는 도구가 됐다.

AI가 처음부터 항상 맞는 것도 아니었다. .86을 놓친 것처럼 틀린 판단도 했다. 하지만 내가 실제 화면을 보고 이상한 지점을 다시 던지면, Codex는 곧바로 다음 검사로 넘어갔다. 나는 모든 명령어와 설정 메뉴를 미리 알 필요는 없었지만, 결과가 이상한지 보고 목표를 다시 잡는 역할은 계속해야 했다.

이틀 전에는 AI에게 브라우저와 휴대폰을 연결하면 내가 직접 다룰 수 있는 영역이 넓어진다는 걸 처음 깨달았다. 오늘은 그 깨달음을 실제 회사 장애에 적극적으로 써먹었다.

모르는 분야를 몇 주 공부한 뒤 언젠가 실전에 적용하는 방식만 있는 게 아니었다. 실제 문제를 AI와 같이 해결하면서 그 순간 필요한 만큼 배우고, 바로 결과까지 만드는 방식도 있었다.