DHCP

사무실에 노트북 100대가 있고 매일 사람들이 들고 오고 나가는 환경을 생각해 보면, IP를 손으로 넣는 방식이 왜 금방 한계에 부딪히는지 금방 보입니다. 누군가는 이미 쓰고 있는 주소를 중복으로 입력해 충돌을 일으키고, 누군가는 게이트웨이 주소를 잘못 넣어 인터넷이 안 됩니다. 장치가 켜질 때 필요한 설정을 자동으로 받아오는 메커니즘이 없으면, 네트워크 담당자가 장치 한 대씩 붙잡고 설정해야 하는 운영이 반복됩니다. 특히 스마트폰처럼 수시로 연결이 바뀌는 장치까지 늘어나면 수동 관리는 현실적으로 불가능해집니다. DHCP는 이 반복 작업을 자동화하고, 주소 충돌이 생기지 않도록 중앙에서 관리하는 방법입니다.

초기 ARPANET 환경에서는 네트워크에 연결된 장비 수가 수십 대에 불과했고, 관리자가 주소를 손으로 넣어도 충분히 감당할 수 있었습니다. 1980년대 후반 들어 이더넷이 사무실로 들어오고 PC 대수가 빠르게 늘면서 상황이 달라졌습니다. RARP, BOOTP 같은 초기 방식이 있었지만 IP 외에 게이트웨이와 DNS 정보까지 함께 배포하거나, 주소를 일정 시간 후 회수해 재사용하는 기능을 갖추지 못했습니다. 이 한계를 해결하기 위해 1993년 RFC 1531로 DHCP가 표준화됐습니다. 이후 와이파이, 모바일, 클라우드 가상 네트워크까지 장치 수가 기하급수적으로 늘어난 환경에서 자동 주소 배정은 더 이상 선택이 아닌 기본 인프라가 됐습니다.

장치가 네트워크에 처음 연결될 때 자기 IP를 모르므로, 255.255.255.255로 브로드캐스트하며 DHCP 서버를 찾습니다. 이 Discover 메시지를 받은 서버는 사용 가능한 IP 주소와 서브넷 마스크, 게이트웨이, DNS 정보를 담아 Offer로 응답합니다. 같은 네트워크에 서버가 여러 대 있으면 여러 Offer가 올 수 있는데, 장치는 그중 하나를 선택해 Request를 보냅니다. 선택된 서버는 ACK로 임대를 확정하고, 장치는 이때 받은 정보로 네트워크 설정을 마칩니다. 이 DORA 절차를 거친 뒤에야 장치는 올바른 IP로 인터넷에 나갈 수 있습니다. 임대 시간이 절반쯤 지나면 장치가 자동으로 갱신을 요청하고, 주소 풀은 임대가 만료된 주소를 회수해 다음 장치에 재사용합니다.

DHCP와 DNS는 둘 다 네트워크 설정을 사람이 직접 다루지 않게 도와주지만 역할이 전혀 다릅니다. DHCP는 장치가 자기 주소와 게이트웨이를 받게 해 네트워크에 참여할 수 있도록 만들고, DNS는 사람이 입력한 도메인 이름을 IP 주소로 바꿔 통신 대상을 찾게 합니다. 순서로 보면 장치가 처음 붙을 때 DHCP가 먼저 필요하고, 그렇게 받은 DNS 서버 주소를 써서 외부 서비스 이름을 찾는 것이 DNS입니다. DHCP가 없으면 장치가 아예 네트워크에 참여하지 못하고, DNS가 없으면 IP는 있어도 도메인 이름으로 서비스를 찾지 못합니다. 만능이 아닙니다. 항상 같은 주소가 필요한 서버나 핵심 인프라 장비는 DHCP 동적 배정보다 고정 주소나 MAC 기반 예약 임대를 함께 써야 합니다.

와이파이 접속 장치가 수시로 바뀌는 사무실, 학교, 카페 같은 환경에서 DHCP는 없어서는 안 됩니다. 클라우드 VPC에서도 새로 생성된 인스턴스가 사설 IP를 자동으로 받는 것은 DHCP가 동작하고 있기 때문입니다. 운영 관점에서는 DHCP 서버가 단일 장애 지점이 되지 않도록 이중화를 고려해야 합니다. DHCP가 중단되면 새 장치는 네트워크에 붙어도 IP를 받지 못해 통신을 시작할 수 없고, 임대가 만료된 기존 장치도 갱신에 실패해 순서대로 연결이 끊어집니다. 또한 인증 없이 브로드캐스트 기반으로 동작하기 때문에, 내부 네트워크에 악의적인 DHCP 서버를 두고 잘못된 게이트웨이 정보를 배포하는 DHCP Spoofing 공격에 주의해야 합니다.