푸른영혼의별

네트워크 기본이지만, 서버 운영에서는 전략이 된다

네트워크 설정을 하다 보면 “DHCP 자동”과 “수동 IP 설정”을 선택하게 된다.
겉으로는 단순한 옵션처럼 보이지만, 개발 환경·서버 운영·인프라 안정성에 직접적인 영향을 준다.

이번 글에서는 DHCP의 동작 원리와 자동/수동 설정의 차이, 그리고 개발자 입장에서 언제 무엇을 선택해야 하는지 정리한다.

1. DHCP란 무엇인가?

DHCP (Dynamic Host Configuration Protocol) 는
네트워크 장비(공유기 또는 DHCP 서버)가 클라이언트에게 IP 주소를 자동으로 할당해주는 프로토콜이다.

동작 과정은 다음과 같다.

이 과정을 통해 자동으로 다음 정보가 내려온다.

• IP 주소
• 서브넷 마스크
• 기본 게이트웨이
• DNS 서버

2. DHCP 자동 설정 (Automatic)

개념

IP 설정을 네트워크 장비에 위임하는 방식이다.

특징

• 사용자가 별도 설정할 필요 없음
• 네트워크 환경 변경 시 자동 대응
• IP가 재부팅 시 바뀔 수 있음

사용 사례

• 일반 PC
• 노트북
• 회사 업무용 단말기
• 모바일 환경

장점

• 관리가 쉽다
• 네트워크 충돌 위험이 낮다
• 유지보수 부담이 적다

단점

• IP가 변경될 수 있다
• 서버 운영에는 부적합

3. 수동 IP 설정 (Static IP)

개념

사용자가 직접 네트워크 값을 입력하는 방식이다.

직접 설정해야 할 항목

• IP 주소
• 서브넷 마스크
• 기본 게이트웨이
• DNS 서버

예시:

특징

• IP가 고정됨
• 서버 접근 주소가 변하지 않음
• 네트워크 설계가 필요함

4. 개발자 관점에서의 선택 기준

1) 일반 개발 환경

로컬 개발 PC는 DHCP 자동이 적절하다.
IP가 바뀌더라도 큰 문제가 없다.

2) 내부 테스트 서버 (Ubuntu, Docker Host 등)

수동 IP 설정이 권장된다.

이유:

• SSH 접속 안정성 확보
• 포트포워딩 유지
• 내부 API Gateway 매핑 유지
• CI/CD 서버 접근 고정

IP가 변경되면 다음 문제가 발생한다.

3) 실무 서버 운영

운영 서버는 반드시 고정 IP 전략을 가져간다.

방법은 두 가지:

1. 서버 OS에서 직접 Static 설정
2. 공유기에서 DHCP Reservation 설정 (MAC 기반 고정 IP)

실무에서는 2번을 더 선호한다.
운영 편의성과 충돌 방지 측면에서 안정적이다.

5. DHCP 자동 vs 수동 비교 정리

6. 실무 팁

1️⃣ 서버는 “완전 수동”이 아니라 “DHCP Reservation”을 쓰는 것이 안전하다

공유기에서 MAC 주소 기반으로 고정 IP를 할당하면:

• 장비 설정은 자동 유지
• IP는 고정 유지
• 충돌 위험 감소

2️⃣ 클라우드 환경에서는 DHCP를 직접 다루지 않는다

AWS, GCP, Azure는 내부적으로 DHCP 기반이지만
개발자가 직접 설정할 필요는 거의 없다.

대신:

• Elastic IP
• VPC 설계
• Subnet 전략

이 더 중요하다.

7. 결론

• 일반 단말기 → DHCP 자동
• 서버 / NAS / 개발 인프라 → 고정 IP
• 운영 안정성 확보가 목적이라면 DHCP Reservation 전략 권장

DHCP는 단순한 네트워크 옵션이 아니라
인프라 안정성과 직결되는 설계 요소다.

특히 개발자가 서버를 직접 운영하는 환경이라면
IP 전략부터 명확히 가져가는 것이 좋다.

왜 패킷은 거짓말을 안 하냐

패킷은 딱 이것만 합니다.

• 어디서 왔는지 (src IP/port)
• 어디로 가는지 (dst IP/port)
• 어떤 프로토콜인지
• 도착했는지 / 거절됐는지 / 사라졌는지

👉 사실만 남깁니다. 해석을 안 합니다.

장애가 꼬이는 진짜 이유는 “사람의 가정”

실무에서 제일 흔한 가정들입니다.

• “WEB이니까 WAS로 당연히 갈 수 있겠지”
• “SG 열었으니까 됐겠지”
• “NAT 있으니까 외부 통신 되겠지”
• “DNS는 어제까지 됐으니까 오늘도 되겠지”
• “서버 살아 있으니까 네트워크 문제는 아니겠지”

👉 이 가정들이 전부 틀릴 수 있습니다.

패킷은 이런 가정을 전혀 고려하지 않습니다.

패킷 기준으로 보면 장애는 항상 단순해짐

예시 1: “안 된다”

사람의 질문:

“왜 안 되지?”

패킷의 질문:

“어디까지 가고, 어디서 끊겼지?”

• SYN이 나갔는가?
• SYN-ACK이 돌아왔는가?
• 중간에서 DROP인가?
• RST인가?
• 타임아웃인가?

👉 여기서 이미 원인 범위가 절반으로 줄어듦

예시 2: “방화벽 문제 같아요”

사람의 가정:

“방화벽일 듯”

패킷의 사실:

• ICMP unreachable → 라우팅/ACL
• TCP RST → 서비스/포트
• 타임아웃 → 방화벽/NACL/DROP
• 응답 정상 → 애플리케이션 문제

👉 추측이 아니라 증거

그래서 좋은 네트워크/운영의 기준은 이거임

사람이 추측하지 않아도
패킷만 보면 답이 보이게 만드는 구조

• 경계가 명확하고
• 차단 방식이 일관되고
• 실패가 “조용히 숨지 않도록” 설계된 네트워크

이게 우리가 말한:

• 좋은 네트워크
• 좋은 방화벽 설계
• 좋은 경계 분리
• 좋은 장애 대응

전부의 공통점입니다.

tcpdump는 거짓말을 하지 않는다.

최종 정리

좋은 시스템이란
패킷이 답을 말하게 만들고,
사람이 추측하지 않아도 되는 시스템이다.

네트워크의 목적은 사실 두 가지입니다.

1. 연결
2. 가시성(Visibility)

속도는 그 다음입니다.

나쁜 네트워크의 특징 (실제 장애 패턴)

• 방화벽/ACL/NACL 경계가 중첩됨
• 경로가 문서화 안 됨
• ICMP 차단
• 로그 없음
• 타임아웃만 발생

이런 환경에서 장애가 나면 로그는 항상 이겁니다.

👉 원인은 안 보이고 증상만 보임

좋은 네트워크의 특징

1️⃣ 실패 지점이 명확하다

• 여기까지는 된다
• 여기부터 안 된다

예:

• WEB → WAS ❌
• WAS → DB ⭕
  → 경계가 바로 드러남

2️⃣ 실패 방식이 “다르다”

• 차단이면 즉시 거부(Connection refused)
• 미개방이면 ICMP unreachable
• 장애면 타임아웃

👉 증상만 봐도 원인 추정 가능

3️⃣ 계층별로 책임이 분리된다

• 네트워크 문제인지
• OS 문제인지
• 애플리케이션 문제인지

👉 문제 소유자가 바로 보임

그래서 이 문장은 이렇게 해석하면 딱 맞음

좋은 네트워크란
장애를 숨기는 네트워크가 아니라,
장애의 위치를 드러내는 네트워크다.

왜 “속도”가 아니라 “경로”냐

속도는 보통 나중 문제입니다.

• 대역폭
• 지연(latency)
• 처리량(throughput)

하지만 장애의 80%는 여기서 안 납니다.

실제 장애는 여기서 납니다

• 어디서 어디로 가는가
• 그 길이 열려 있는가
• 중간에 누가 통제하는가

👉 즉, 경로(Path)

그리고 “경계”가 핵심인 이유

네트워크에서 경계는 이런 지점들입니다.

• Public ↔ Private
• WEB ↔ WAS
• WAS ↔ DB
• 내부 ↔ 외부 API
• Zone ↔ Zone
• VPC ↔ VPC

이 경계마다 항상 붙는 게 뭡니까?

• 방화벽
• ACL
• Security Group
• NACL
• NAT
• Proxy

👉 장애는 거의 항상 ‘경계’에서 터집니다.

속도는 느려도 된다, 경로가 틀리면 끝이다

실무에서 자주 보는 장면입니다.

• 서버 성능 충분
• CPU 여유
• 메모리 여유
• 디스크 여유

그런데:

• 안 붙음
• 안 나감
• 안 들어옴

이때 로그는 늘 같습니다.

👉 속도가 아니라 길이 없는 상태

그래서 이 문장은 이렇게 해석해야 정확함

네트워크 설계란
얼마나 빠르게 보내느냐가 아니라,
어디까지 허용하고 어디서 차단할지를 정하는 일이다.

✅ 마무리

네트워크 장애는 대역폭이 아니라
경계 설계의 결과로 발생한다.

1️⃣ DNS가 왜 “단순해 보이냐”

DNS는 보통 이렇게 인식됩니다.

• IP 주소 알려주는 것
• 설정 한 번 하면 끝
• 거의 안 만지는 영역

2️⃣ 근데 DNS는 “모든 것의 입구”다

현실의 서비스 흐름은 이렇습니다.

👉 DNS는 0번 단계

여기서 DNS가 깨지면?

• HTTP 요청 ❌
• HTTPS ❌
• API 호출 ❌
• 헬스체크 ❌
• 내부 연동 ❌

👉 아무 것도 시작조차 안 됨

3️⃣ DNS 장애의 무서운 점

① 로그가 거의 없다

• 애플리케이션 로그 ❌
• WAS 로그 ❌
• 서버는 “정상처럼 보임”

하지만 사용자는:

“사이트 접속 안 됨”

② 장애가 “랜덤”처럼 보인다

• 어떤 사람은 됨
• 어떤 사람은 안 됨
• 회사에선 됨, 집에선 안 됨

👉 TTL + 캐시 지옥

③ 복구가 느리다

• 설정 바꿔도 바로 안 바뀜
• TTL 남아 있으면 기다려야 함
• 잘못하면 수 시간 지속

4️⃣ DNS 장애는 왜 “모든 걸 멈추냐”

DNS 장애의 본질은 이겁니다.

서비스는 살아 있는데
찾아갈 수 없게 만든다

그래서:

• 서버는 정상
• 모니터링도 정상
• 근데 사용자는 전부 실패

👉 운영자 멘탈이 먼저 터짐

DNS는 단순해 보이지만,
장애가 나면 서비스의 입구 자체를 닫아버린다.

1️⃣ 방화벽은 “문제 원인”이 아니라 “문제 은닉기”

• DB 연결 안 됨
• WAS 헬스체크 실패
• 내부 API 호출 타임아웃
• SSH 안 붙음
• 외부 연동 먹통

로그에는 보통...

👉 진짜 원인

• 방화벽 정책 누락
• 포트 미개방
• 방향(outbound/inbound) 반대
• IP 대역 오해

하지만 방화벽은 아무 말도 안 해줍니다.

2️⃣ “보안을 지킨다”는 말의 이면

방화벽이 잘 동작할수록:

• ❌ 장애가 빨리 드러나지 않음
• ❌ 문제 재현 어려움
• ❌ 원인 추적 시간 증가

그래서 이런 말이 나옵니다.

“서버는 정상인데 왜 안 되지?”

3️⃣ 그래서 방화벽은 문제를 “같이 지킨다”

방화벽이 지키는 것들:

• 공격 ⭕
• 비인가 접근 ⭕
• 잘못된 네트워크 설계 ⭕
• 문서 없는 연동 구조 ⭕
• 암묵적 의존성 ⭕

👉 방화벽은
보안뿐 아니라 설계 실수까지 보호합니다.

4️⃣ 이번 장애 맥락에서 보면 더 정확해짐

이번 케이스처럼:

• OS 깨짐
• 네트워크 명령 불가
• 내부 접근 불가

이 상황에서 방화벽이 있으면:

• 접근도 안 되고
• 진단도 안 되고
• “그냥 안 된다”만 남음

👉 문제는 방화벽 뒤에 안전하게 숨습니다.

방화벽은 공격을 막는 동시에,
문제의 원인을 보이지 않게 만든다.