사내 인터넷 끊김은 회선보다 DHCP·IP 충돌부터 잡아야 합니다

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

특정 직원의 PC만 인터넷이 끊기거나, 회의실에 사람이 몰린 뒤부터 사내 네트워크가 느려진다면 통신 회선부터 의심하기 쉽습니다. 하지만 외부 회선이 정상인데도 일부 단말에서만 문제가 반복된다면 DHCP 주소 부족, 고정 IP 중복, 잘못 연결된 공유기가 원인일 가능성이 큽니다.

이런 장애는 잠시 기다리거나 PC를 재부팅하면 사라지는 것처럼 보여 더 까다롭습니다. 증상이 사라졌다고 해결된 것은 아닙니다. 주소 임대 시간이 지나거나 충돌한 장비의 전원이 꺼진 것뿐일 수 있으므로, 발생 범위를 좁히고 DHCP 서버와 단말 정보를 대조하는 순서가 필요합니다.

먼저 회선 장애와 내부 IP 문제를 구분해야 합니다

끊기는 범위가 첫 번째 단서입니다

장애 접수와 동시에 인터넷 속도 측정부터 하면 중요한 흔적을 놓칠 수 있습니다. 먼저 같은 층, 같은 스위치, 같은 무선 AP에 연결된 사용자에게 증상이 있는지 확인하세요. 모든 부서가 동시에 외부 사이트에 접속하지 못한다면 회선이나 방화벽을 살펴야 하지만, 한두 대만 끊기거나 새 장비를 연결한 자리에서 시작됐다면 내부 주소 할당 문제를 우선 확인하는 편이 빠릅니다.

사용자에게는 단순히 “인터넷이 안 되나요?”라고 묻지 말고 사내 그룹웨어, 파일 서버, 프린터, 외부 웹사이트 중 무엇이 안 되는지 나눠 물어야 합니다. 예를 들어 사내 서버에는 접속되지만 외부 웹만 열리지 않으면 DNS나 게이트웨이 설정을 의심할 수 있습니다. 반대로 사내 서비스와 외부 인터넷이 모두 끊겼고 IP 주소가 169.254로 시작한다면 DHCP에서 정상 주소를 받지 못했을 가능성이 높습니다.

• 전사 동시 장애: 인터넷 회선, 방화벽, 코어 스위치와 전원 상태를 먼저 확인합니다.
• 한 구역 동시 장애: 해당 층 스위치, VLAN, 업링크와 DHCP 릴레이 구성을 확인합니다.
• 일부 PC만 장애: IP 충돌, 임대 실패, 랜 케이블과 네트워크 어댑터를 점검합니다.
• 무선에서만 장애: DHCP 주소 풀과 AP 수용량, 비인가 공유기 연결 여부를 확인합니다.

정상 단말과 고장 단말을 나란히 비교합니다

장애 PC 한 대만 들여다보면 잘못된 값을 정상으로 오해할 수 있습니다. 같은 부서에서 정상 작동하는 PC의 IP 주소, 서브넷 마스크, 기본 게이트웨이, DNS 서버를 함께 기록하세요. 장애 PC의 값이 다른 대역에 있거나 게이트웨이가 가정용 공유기 주소로 바뀌어 있다면 원인 범위가 크게 줄어듭니다.

현장 팁: 장애 시각, 사용자 위치, 유선·무선 여부, IP 주소, 게이트웨이, MAC 주소를 한 줄로 남기세요. 이 다섯 가지가 쌓이면 재현하기 어려운 간헐 장애도 특정 스위치나 시간대로 묶을 수 있습니다.

DHCP 주소 부족은 사용자가 늘어난 시간에 드러납니다

주소 풀과 임대 시간을 함께 계산합니다

DHCP는 단말에 IP 주소와 네트워크 설정을 자동 배포하지만, 배포할 수 있는 주소가 무한한 것은 아닙니다. 예를 들어 직원용 대역에서 실제 할당 가능한 주소가 200개인데 노트북, 휴대전화, 태블릿, 무선 전화기까지 230대가 접속하면 늦게 들어온 장비는 주소를 받지 못합니다. 평소에는 정상인데 월요일 오전, 교육일, 외부 방문객이 많은 날에만 장애가 생기는 이유가 여기에 있습니다.

주소 사용량은 직원 수만으로 계산하면 부족합니다. 직원 한 명이 노트북과 휴대전화를 동시에 연결하고, 회의실 장비와 프린터도 DHCP를 사용하기 때문입니다. 여기에 퇴사자 장비나 일회성 방문 단말의 임대가 오래 유지되면 실제 접속 대수보다 사용 중인 주소가 많아집니다. 최대 동시 접속 수에 20~30%의 여유를 더해 주소 풀을 설계하는 것이 안전합니다.

대역 확장 전에 숨은 낭비를 제거합니다

주소가 부족하다고 곧바로 서브넷을 크게 바꾸면 게이트웨이, 방화벽 정책, 접근제어 목록과 서버 설정까지 수정해야 할 수 있습니다. 먼저 DHCP 임대 목록에서 장기간 보이지 않은 MAC 주소, 폐기된 장비의 예약, 지나치게 넓은 제외 범위를 찾으세요. 프린터나 출입통제 장비에 고정 IP를 직접 입력해 놓고 같은 주소를 DHCP에서도 배포하는 구성도 자주 발견됩니다.

업무 단말과 방문객 단말이 같은 주소 풀을 쓰고 있다면 게스트 VLAN을 분리하는 것이 효과적입니다. 게스트망은 짧은 임대 시간을 적용하고 내부 서버 접근을 차단할 수 있어 주소 부족과 보안 문제를 함께 줄입니다. 다만 임대 시간을 지나치게 짧게 하면 갱신 요청이 늘어날 수 있으므로, 실제 체류 시간과 DHCP 서버 처리량을 근거로 조정해야 합니다.

1. 최근 일주일의 시간대별 최대 임대 수를 확인합니다.
2. 활성 단말, 예약 주소, 제외 주소를 각각 집계합니다.
3. 직원망·서버망·게스트망이 같은 풀을 공유하는지 확인합니다.
4. 불필요한 예약을 정리한 뒤에도 부족하면 VLAN 또는 서브넷 확장을 설계합니다.

IP 충돌은 재부팅보다 충돌한 장비 식별이 먼저입니다

ARP와 MAC 주소로 실제 사용자를 추적합니다

IP 충돌은 서로 다른 두 장비가 같은 주소를 사용할 때 발생합니다. 한쪽 장비의 통신이 간헐적으로 끊기거나, 접속하려던 프린터 대신 다른 관리 화면이 열리고, 서버 연결이 몇 분마다 살아났다 끊기는 증상으로 나타날 수 있습니다. 운영체제의 “IP 주소 충돌” 경고가 없더라도 네트워크 장비의 ARP 테이블에서 같은 IP에 대응하는 MAC 주소가 계속 바뀐다면 충돌을 의심해야 합니다.

장애가 발생한 IP를 확보했다면 게이트웨이 또는 L3 스위치의 ARP 정보에서 MAC 주소를 확인하고, 액세스 스위치의 MAC 주소 테이블을 따라 연결 포트를 찾습니다. 무선 단말이라면 무선 컨트롤러나 AP 관리 화면에서 해당 MAC 주소의 접속 이력을 확인하세요. 이 과정을 거치면 막연히 전 부서에 공지하지 않고도 충돌 장비가 연결된 위치와 포트를 좁힐 수 있습니다.

• 같은 IP의 MAC 주소가 짧은 간격으로 바뀌는지 확인합니다.
• DHCP 임대 목록에서 해당 IP를 받은 정상 단말을 찾습니다.
• 스위치 포트 또는 AP 접속 기록으로 다른 MAC 주소의 위치를 추적합니다.
• 장비 라벨, 사용자, 자산 번호를 확인한 뒤 임의 고정 IP를 해제합니다.

서버와 프린터는 예약 방식으로 통일합니다

서버, NAS, 프린터처럼 주소가 바뀌면 안 되는 장비는 관리 방식이 일관되어야 합니다. 장비마다 고정 IP를 직접 입력하는 방식은 초기에는 간단하지만, 담당자가 바뀌면 어느 주소를 누가 사용 중인지 알기 어렵습니다. DHCP 예약을 중심으로 운영하면 MAC 주소와 IP의 대응 관계를 서버에서 확인할 수 있고, 게이트웨이와 DNS 변경도 한곳에서 관리하기 쉽습니다.

물론 모든 장비가 DHCP 예약에 적합한 것은 아닙니다. DHCP 서비스 자체를 제공하는 서버, 핵심 네트워크 장비, 장애 시 독립적으로 접근해야 하는 관리 인터페이스는 정적 주소가 필요할 수 있습니다. 중요한 것은 방식보다 주소 대장, DHCP 설정, 실제 장비 설정이 서로 일치하는 상태입니다. 서버의 기본 개념과 역할은 네이버 지식백과의 서버 설명에서도 확인할 수 있으며, 역할별 장비를 식별한 뒤 주소 정책을 정하는 데 참고할 만합니다.

고정 IP를 새로 배정할 때는 빈 주소로 보인다는 이유만으로 즉시 사용하지 마세요. DHCP 범위, 예약 목록, ARP 기록, 자산 대장을 모두 확인해야 휴가 중인 장비와의 충돌을 막을 수 있습니다.

비인가 공유기와 DHCP 서버가 장애를 더 복잡하게 만듭니다

잘못 연결된 공유기는 다른 게이트웨이를 배포합니다

회의실 포트가 부족하다는 이유로 직원이 가정용 공유기를 연결하면 이 공유기의 DHCP 기능이 사내망에 주소를 배포할 수 있습니다. 특히 공유기의 LAN 포트를 사내 벽면 포트와 연결하면 동일한 브로드캐스트 구간에 두 DHCP 서버가 존재하게 됩니다. 단말은 먼저 응답한 서버의 설정을 받기 때문에 어떤 PC는 정상 게이트웨이를, 다른 PC는 공유기의 사설 주소를 받는 불규칙한 장애가 발생합니다.

이때 공식 DHCP 서버만 검사해서는 이상이 보이지 않을 수 있습니다. 장애 PC가 받은 DHCP 서버 식별자, 게이트웨이 주소, DNS 주소를 정상 PC와 비교해야 합니다. 192.168.0.1이나 192.168.1.1처럼 사내 표준에 없는 게이트웨이가 발견되면 해당 IP의 MAC 주소를 추적해 연결 포트를 찾으세요. 포트를 무작정 차단하기 전 IP 전화기나 업무 장비가 함께 연결되어 있는지도 확인해야 서비스 영향이 없습니다.

1. 장애 단말에서 현재 임대 정보와 DHCP 서버 주소를 기록합니다.
2. 승인된 DHCP 서버 목록과 비교해 비인가 응답을 확인합니다.
3. 게이트웨이의 ARP 정보와 스위치의 MAC 주소 테이블로 물리 포트를 찾습니다.
4. 연결 장비를 확인하고 공유기의 DHCP 기능을 끄거나 승인된 스위치로 교체합니다.
5. 조치 후 기존 임대를 갱신하고 정상 주소, DNS, 게이트웨이가 배포되는지 검증합니다.

스위치에서 재발 방지 장치를 적용합니다

현장에서 공유기를 제거해도 포트 확장 수요가 남아 있으면 같은 문제가 반복됩니다. 소형 스위치를 승인 절차에 따라 지급하고, 회의실과 임시 좌석의 포트 수요를 조사해 사용자가 개인 장비를 연결할 이유를 줄이세요. 관리형 스위치에서는 신뢰할 수 있는 포트에서만 DHCP 응답을 허용하는 DHCP 스누핑을 검토할 수 있습니다.

DHCP 스누핑은 강력하지만 설정 오류가 나면 정상 주소 배포까지 막을 수 있습니다. DHCP 서버가 다른 VLAN에 있고 릴레이를 거치는 환경에서는 업링크와 신뢰 포트를 정확히 정의해야 합니다. 먼저 한 구역에서 시험하고, 임대 갱신과 신규 연결을 모두 검증한 뒤 확대 적용하는 편이 안전합니다.

• 포트 보안: 한 포트에서 허용할 MAC 주소 수를 제한해 임의 확장을 감지합니다.
• DHCP 스누핑: 비인가 포트에서 들어오는 DHCP 서버 응답을 차단합니다.
• 네트워크 접근제어: 승인되지 않은 단말을 별도 구간으로 격리합니다.
• 구성 백업: 스위치 정책 변경 전후 설정을 보관해 장애 시 되돌릴 근거를 만듭니다.

복구 순서는 서비스 영향과 재발 가능성으로 결정합니다

당장 살리는 조치와 원인 제거를 분리합니다

사용자의 업무를 빠르게 복구해야 할 때는 정상 예비 포트나 임시 VLAN으로 단말을 이동하고, 올바른 주소를 다시 받게 하는 조치가 필요할 수 있습니다. 그러나 IP를 임의로 바꾸거나 DHCP 임대를 삭제하는 것만으로 사건을 닫으면 같은 장비가 다시 연결되는 순간 장애가 재발합니다. 임시 복구 조치에는 종료 시각을 정하고, 반드시 원인 장비 식별과 구성 수정 작업을 이어 붙이세요.

장애 기록에는 “인터넷 끊김 해결”처럼 결과만 남기지 않는 것이 좋습니다. 발생 시각, 영향 사용자 수, 잘못 배포된 주소, 충돌한 MAC 주소, 연결 포트, 변경한 설정과 검증 결과를 포함해야 다음 대응이 빨라집니다. 장비와 담당자, 설치 위치를 연결해 관리하는 개념은 IT자산관리시스템 용어 설명과도 맞닿아 있습니다. 네트워크 기록을 자산 정보와 연결하면 반복되는 비인가 장비와 노후 단말을 찾기 쉬워집니다.

• 1순위 서비스 영향: 서버망, 결제·생산·고객 응대처럼 중단 비용이 큰 구간을 먼저 복구합니다.
• 2순위 원인 격리: 비인가 DHCP 서버나 충돌 장비가 확인되면 다른 사용자의 피해가 늘지 않게 포트를 격리합니다.
• 3순위 주소 안정화: DHCP 풀 사용률, 예약 및 제외 범위를 바로잡고 임대 갱신을 검증합니다.
• 4순위 재발 방지: 포트 보안, DHCP 스누핑, 게스트 VLAN과 승인 장비 지급 절차를 적용합니다.
• 5순위 운영 기록: 자산 대장과 네트워크 구성도에 장비 위치, MAC 주소, IP 정책 변경 사항을 반영합니다.

해결 여부는 재부팅이 아니라 반복 시험으로 판단합니다

한 번 웹페이지가 열린다고 정상으로 판정하면 안 됩니다. 장애 단말에서 주소 반납과 재할당을 수행하고, 같은 구역의 다른 단말도 신규 접속시켜 올바른 DHCP 서버에서 주소를 받는지 확인하세요. 사내 DNS 조회, 기본 게이트웨이 통신, 내부 서버 접속, 외부 인터넷 접속을 순서대로 시험하면 어느 계층까지 복구됐는지 명확해집니다.

최종 판단 기준은 단순합니다. 먼저 업무 중단 범위를 줄이고, 다음으로 충돌 장비나 비인가 서버를 물리적으로 식별해 격리해야 합니다. 그다음 주소 풀과 임대 정책을 바로잡고, 재접속 시험으로 정상 배포를 확인하며, 마지막에 자산 대장과 스위치 보호 정책을 갱신하세요. 이 우선순위를 지키면 사내 인터넷 끊김을 회선 탓으로 돌리는 데 시간을 쓰지 않고 실제 고장 지점에 빠르게 도달할 수 있습니다.