사내 DHCP 서버를 분리 운영한 지 한 달, IP 충돌이 사라졌다

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

회의실 무선 인터넷이 갑자기 끊기고, 멀쩡하던 복합기가 오프라인으로 바뀌며, 일부 직원만 그룹웨어에 접속하지 못한다면 회선부터 의심하기 쉽습니다. 하지만 현장에서 반복적으로 발견되는 원인은 의외로 단순한 IP 주소 충돌입니다. 특히 공유기와 서버가 동시에 IP를 배포하거나 고정 IP와 DHCP 할당 범위가 겹친 환경에서는 재부팅할 때마다 문제가 다른 장비로 이동합니다.

한 중소기업의 사내 네트워크에서 DHCP 역할을 별도 서버로 모으고 주소 정책을 다시 설계해 한 달간 운영해봤습니다. 간헐적으로 발생하던 접속 장애는 사라졌고, 장애가 생겨도 사용자·단말·스위치 포트를 찾는 시간이 크게 줄었습니다. 핵심은 고가 장비를 추가하는 것이 아니라 누가 어떤 주소를 언제 배포하는지 통제하는 구조를 만드는 데 있었습니다.

재부팅하면 잠시 살아나는 장애부터 추적했습니다

IP 충돌은 회선 장애처럼 보입니다

IP 주소는 네트워크 안에서 장비를 구별하는 번호입니다. 서로 다른 두 장비가 같은 주소를 사용하면 스위치와 단말이 목적지를 안정적으로 판단하지 못해 통신이 끊겼다가 다시 연결됩니다. 서버가 네트워크 요청에 응답하는 장치라는 기본 개념은 서버 용어 설명에서도 확인할 수 있으며, DHCP 서버는 이 주소와 게이트웨이, DNS 정보를 단말에 자동으로 전달하는 역할을 합니다.

문제는 증상이 일정하지 않다는 점입니다. 같은 IP를 먼저 차지한 장비가 정상처럼 보이고 나중에 연결된 장비만 장애를 겪을 수 있습니다. 노트북을 재부팅하거나 랜선을 다시 꽂으면 새로운 주소를 받아 잠시 회복되므로 사용자는 “인터넷이 가끔 느리다”고 신고합니다. 담당자가 현장에 도착했을 때 이미 정상화되어 원인을 놓치는 경우도 많습니다.

이번 환경에서는 직원용 공유기, 방화벽의 DHCP 기능, 윈도우 기반 DHCP 서버가 서로 다른 구간에서 동시에 동작하고 있었습니다. 여기에 복합기와 출입통제 장비에 수동 입력한 고정 IP가 자동 할당 범위 안에 섞여 있었습니다. 한 번의 설정 실수가 아니라 여러 장비가 주소 관리 권한을 나눠 가진 구조가 고장의 뿌리였습니다.

• 주소 충돌: 특정 PC를 켜면 복합기나 NAS가 동시에 끊깁니다.
• 잘못된 게이트웨이: 내부 장비에는 접속되지만 인터넷만 열리지 않습니다.
• 잘못된 DNS: IP로는 접속되지만 도메인 이름을 입력하면 실패합니다.
• 비인가 DHCP: 같은 좌석에서도 재접속할 때마다 서로 다른 대역을 받습니다.
• 임대 주소 고갈: 방문자나 모바일 단말이 많은 시간대에 신규 접속만 실패합니다.

장애 PC에서 재부팅부터 하지 말고 현재 IP, 게이트웨이, DNS, DHCP 서버 주소를 먼저 기록해야 합니다. 재부팅은 증상을 없애는 동시에 가장 중요한 단서도 지울 수 있습니다.

DHCP 서버 한 대보다 주소 정책을 먼저 세웠습니다

자동 할당과 고정 주소의 경계를 분리했습니다

DHCP 서버를 새로 설치한다고 충돌이 자동으로 해결되지는 않습니다. 기존 공유기의 DHCP 기능이 남아 있거나 관리자가 임의로 고정 IP를 입력하면 같은 문제가 반복됩니다. 먼저 VLAN과 업무 목적별로 주소 대역을 구분하고, 각 대역에서 자동 할당 범위와 인프라 장비용 고정 범위를 명확히 나눴습니다.

예를 들어 사용자 PC에는 10.20.10.50부터 10.20.10.220까지를 자동 배포하고, 스위치·무선 AP·복합기·NAS 같은 관리 대상에는 10.20.10.2부터 10.20.10.49까지를 남겨두는 방식입니다. 서버는 별도 VLAN으로 옮겨 사용자 단말의 브로드캐스트 영향을 줄였습니다. 네트워크 규모가 작더라도 주소 끝자리만 보고 용도를 짐작할 수 있는 규칙을 정하면 긴급 상황에서 판단이 빨라집니다.

자산 이름도 함께 통일했습니다. DHCP 예약 목록에 MAC 주소만 적으면 몇 달 뒤 누구의 장비인지 알기 어렵습니다. 장비명, 부서, 사용자, 설치 위치, 스위치 포트, 보증 만료일을 연결했고, 자산 관리 범위를 잡을 때는 IT자산관리시스템의 개념도 참고할 수 있습니다. 주소 정책은 네트워크 설정표가 아니라 자산 정보와 함께 유지해야 효과가 오래갑니다.

1. 대역 조사: 라우터, 방화벽, 서버, 공유기에서 현재 DHCP 활성 여부와 할당 범위를 수집합니다.
2. 용도 분류: 사용자, 서버, 전화기, CCTV, 게스트 무선망을 업무 영향도에 따라 나눕니다.
3. 제외 범위 지정: 게이트웨이와 네트워크 장비, 프린터가 사용할 구간을 자동 배포 대상에서 뺍니다.
4. 예약 정책 적용: 반드시 같은 주소가 필요한 단말은 수동 입력보다 DHCP 예약을 우선 사용합니다.
5. 문서 연결: IP, MAC, 사용자, 위치, 포트 정보를 하나의 자산대장에 기록합니다.

임대 시간은 길수록 좋은 것이 아니었습니다

DHCP 임대 시간은 장비가 주소를 사용할 수 있는 기간입니다. 고정 좌석 위주의 사무실이라면 하루에서 일주일 정도로 길게 운영해도 주소 소모가 크지 않습니다. 반면 방문자가 계속 바뀌는 게스트 무선망에서 임대 시간을 일주일로 설정하면 이미 떠난 단말이 주소를 오래 점유해 풀 고갈이 발생할 수 있습니다.

이번에는 직원 유선망은 3일, 업무용 무선망은 1일, 게스트망은 4시간으로 다르게 설정했습니다. 무조건 따라야 하는 숫자는 아닙니다. 사용 가능한 주소 개수, 하루 신규 단말 수, 평균 체류 시간을 함께 보고 결정해야 하며, 주소 사용률이 평소 70%를 넘는다면 대역 확장이나 VLAN 분리를 먼저 검토하는 편이 안전합니다.

운영 중단 없이 네 단계로 DHCP를 전환했습니다

기존 서버를 바로 끄지 않고 응답 경로를 검증했습니다

업무 시간에 기존 DHCP 기능을 끄고 새 서버를 켜는 방식은 간단하지만 위험합니다. 잘못된 VLAN 설정이나 DHCP 릴레이 누락이 있으면 기존 주소의 임대 시간이 끝나는 순간부터 부서 전체가 접속하지 못합니다. 그래서 테스트 단말과 소규모 VLAN부터 새 서버로 이동한 뒤 범위를 넓혔습니다.

첫 단계에서는 각 VLAN의 게이트웨이에 설정된 DHCP 릴레이 주소를 확인했습니다. DHCP 요청은 기본적으로 브로드캐스트이므로 서버가 다른 VLAN에 있으면 라우터나 L3 스위치가 요청을 전달해야 합니다. 새 서버에서 주소가 충분히 남아 있어도 릴레이가 예전 서버를 가리키면 단말은 응답을 받지 못합니다. 방화벽의 UDP 67·68 통신 허용 여부도 함께 점검했습니다.

둘째 단계에서는 노트북 한 대의 기존 임대를 해제하고 새로 갱신해 IP, 서브넷 마스크, 게이트웨이, DNS, 임대 서버가 설계값과 일치하는지 확인했습니다. 셋째 단계에서는 프린터와 업무용 단말의 예약 주소를 옮겼고, 마지막 단계에서 기존 공유기와 방화벽의 DHCP 기능을 비활성화했습니다. 각 단계 사이에 최소 한 번의 실제 업무 테스트를 넣어 설정 오류가 다음 구간으로 번지지 않게 했습니다.

1. 시험 범위 생성: 운영 대역과 겹치지 않는 작은 풀을 만들고 테스트 단말만 연결합니다.
2. 옵션 검증: 기본 게이트웨이, 내부 DNS, 도메인 접미사, NTP 옵션이 정확한지 확인합니다.
3. 예약 주소 이전: 복합기와 전화기처럼 주소 변경에 민감한 장비를 우선 등록합니다.
4. 릴레이 전환: VLAN별 전달 목적지를 새 DHCP 서버로 바꾸고 응답 로그를 확인합니다.
5. 기존 기능 종료: 다른 장비가 주소를 배포하지 못하도록 설정과 관리자 권한을 정리합니다.
6. 롤백 기준 기록: 신규 할당 실패율이나 주요 서비스 오류가 기준을 넘으면 원래 경로로 되돌립니다.

전환 성공 여부는 “인터넷이 된다”만으로 판단하면 부족합니다. 사내 DNS 조회, 파일 서버 접속, 프린터 출력, IP 전화, VPN 연결까지 실제 업무 흐름으로 시험해야 합니다.

장애가 다시 생겨도 원인을 찾을 로그를 남겼습니다

전환 후에는 DHCP 감사 로그와 스위치의 MAC 주소 테이블을 함께 보관했습니다. 특정 IP가 언제 어떤 MAC 주소에 할당됐는지 확인하고, 해당 MAC이 어느 스위치 포트에서 관찰됐는지 연결하면 문제 단말의 위치를 빠르게 좁힐 수 있습니다. 여러 부서가 하나의 IT 시스템을 이용하는 구조에서는 서비스와 운영 주체의 관계를 함께 관리해야 하며, IT 서비스 시스템 사례처럼 구성 요소를 서비스 관점에서 바라보는 접근도 도움이 됩니다.

모니터링에는 주소 풀 사용률, DHCP 요청 대비 성공 응답, 거절된 요청, 서버 서비스 상태를 포함했습니다. 사용률 80%에서 경고하고 90%에서는 긴급 알림이 울리도록 구간을 나눴습니다. 단순히 프로세스가 실행 중인지 확인하는 것보다 실제 테스트 단말이 정상 옵션을 받아 내부 서비스에 접근하는지 주기적으로 검증하는 편이 훨씬 신뢰할 만합니다.

DHCP로 해결되지 않는 구간은 따로 남겨뒀습니다

이중화와 보안은 별도의 설계가 필요합니다

한 달간 IP 충돌이 나타나지 않았다고 모든 네트워크 문제가 끝난 것은 아닙니다. DHCP 서버를 한 대로 통합하면 관리 지점은 단순해지지만 해당 서버나 가상화 호스트가 멈췄을 때 새 단말의 접속이 어려워질 수 있습니다. 기존에 주소를 받은 단말은 임대 기간 동안 동작할 가능성이 크지만, 장애가 길어지면 갱신 실패가 누적됩니다.

업무 중단 비용이 큰 환경에서는 DHCP 장애 조치 기능, 분할 범위, 이중 서버를 검토해야 합니다. 다만 두 서버에 주소 범위를 임의로 절반씩 넣는 방식은 예약 정보와 옵션이 어긋나기 쉽습니다. 제품이 제공하는 공식 이중화 기능을 사용하고 설정 복제 상태, 시간 동기화, 장애 전환 시험까지 운영 절차에 포함해야 합니다.

비인가 단말을 막는 문제도 DHCP만으로 해결할 수 없습니다. 사용자가 고정 IP를 직접 입력하면 DHCP 기록 없이 네트워크에 접근할 수 있기 때문입니다. 보안 요구가 높다면 DHCP 스누핑, IP Source Guard, 동적 ARP 검사, 802.1X 인증을 스위치 기능과 함께 설계해야 합니다. 단, 장비 지원 여부와 기존 IP 전화·산업용 단말의 호환성을 먼저 확인하지 않으면 정상 장비까지 차단할 수 있습니다.

• 소규모 단일 사무실: 설정 백업과 예비 장비, 복구 절차를 마련한 단일 DHCP 서버가 현실적일 수 있습니다.
• 24시간 운영 조직: 서로 다른 호스트나 전원 계통에 DHCP 이중화를 배치하고 정기적으로 전환 시험을 수행합니다.
• 지점이 많은 기업: 본사 회선 장애 때 지점의 신규 단말까지 멈추지 않도록 로컬 생존 방식을 검토합니다.
• 제조·의료 환경: IP 변경에 민감한 장비는 제조사 권고와 유지보수 계약을 확인한 뒤 이전합니다.
• IPv6 병행 환경: DHCPv4만 손봐서는 부족하며 SLAAC, DHCPv6, 라우터 광고 정책을 별도로 점검합니다.

클라우드와 특수 장비에는 같은 처방을 적용하지 않았습니다

클라우드 가상 네트워크는 사업자가 주소 할당 기능을 관리하는 경우가 많아 사내 DHCP 서버를 그대로 연결할 수 없습니다. 또한 부팅 단계에서 네트워크로 운영체제를 설치하는 PXE, 특정 옵션을 요구하는 IP 전화기, 폐쇄망 장비는 일반 PC와 다른 DHCP 옵션이 필요합니다. 이런 예외는 기본 풀에 억지로 섞기보다 전용 VLAN과 별도 정책으로 격리해야 변경 영향을 줄일 수 있습니다.

이번 방식 역시 모든 조직의 정답은 아닙니다. 네트워크가 평면 구조로 남아 있거나 스위치가 릴레이와 보안 기능을 지원하지 않는다면 장비 교체 또는 VLAN 재설계가 선행돼야 합니다. 이미 고정 IP가 수백 대에 입력된 현장은 한 번에 자동 할당으로 바꾸기보다 영향도가 낮은 단말부터 순차 이전해야 합니다. DHCP 통합의 경계는 주소 배포까지이며, 회선 품질·루프·무선 간섭·DNS 장애는 각각 별도의 진단이 필요합니다.