Docker 네트워크 모드 선택 실전: bridge, host, overlay 의사결정 가이드

실제 장애 사례에서 시작하기

새벽 두 시, 운영 환경의 API 서비스가 갑자기 타임아웃되기 시작했습니다.

컨테이너는 분명히 떠 있었습니다. docker ps에는 running으로 표시됐고, 방화벽도 꺼져 있었고, 포트 매핑도 제대로 설정되어 있었으며, 컨테이너 로그에도 오류가 없었습니다. 그런데도 30분 넘게 파고들다 보니 거의 멘탈이 나갈 지경이었습니다. 결국 원인은 Docker 네트워크 모드를 잘못 선택한 데 있었습니다. 우리는 기본 bridge를 쓰고 있었지만, 서비스는 다른 노드의 데이터베이스에 호스트 간으로 접근해야 했습니다. bridge는 단일 호스트 통신만 가능해서 호스트를 넘어갈 수 없었습니다.

이 사례는 꽤 흔한 문제를 드러냅니다. 많은 개발자가 Docker에 bridge, host, overlay 세 가지 네트워크 모드가 있다는 것은 알지만, 언제 어떤 모드를 써야 하는지는 명확히 모릅니다. 솔직히 저도 처음에는 이 함정에 빠진 적이 있습니다.

이 글을 끝까지 읽으면 세 가지 네트워크 모드의 전체 의사결정 흐름도와 성능 기준 비교표를 얻을 수 있습니다. 다음에 네트워크 문제가 생겼을 때 먼저 “단일 호스트인가, 호스트 간 통신인가”부터 판단하면, 예전의 저처럼 엉뚱한 곳을 헤매지 않아도 됩니다.

---

Bridge: 기본 선택, 단일 호스트 통신의 왕

Bridge는 Docker의 기본 네트워크 모드입니다.

docker run을 실행할 때 --network를 지정하지 않으면 컨테이너는 자동으로 이 모드에 붙습니다. 핵심 원리는 단순합니다. Docker가 호스트에 docker0라는 가상 브리지를 만들고, 각 컨테이너에 독립 IP를 할당한 뒤(보통 172.17.x.x), veth pair(가상 네트워크 케이블)를 통해 브리지에 연결합니다.

조금 추상적으로 들리나요? 사실은 컨테이너를 독립된 가상 머신처럼 보고, 사설 IP를 하나 배정한 다음 NAT(포트 매핑)를 통해 외부와 통신하게 만드는 방식입니다.

적합한 사용 사례

단일 호스트의 다중 컨테이너 배포라면 Bridge가 첫 번째 선택입니다.

개발 환경, 테스트 환경은 물론이고 호스트 간 통신이 필요 없는 일부 운영 환경도 Bridge면 충분합니다. 단순하고 안전하며 추가 설정도 거의 필요 없습니다.

설정 예시

기본값이 Bridge이므로 사실 따로 지정할 필요도 없습니다.

# 기본 bridge, IP 자동 할당, -p로 포트 매핑 필요
docker run -d -p 8080:80 nginx

다만 문제가 하나 있습니다. 기본 bridge에서는 컨테이너끼리 컨테이너 이름이 아니라 IP로만 통신할 수 있습니다. 컨테이너 두 개를 띄운 뒤 서로 접근하게 하려면 IP를 직접 확인해야 해서 꽤 번거롭습니다.

어떻게 확인할까요? docker inspect를 사용합니다.

# 컨테이너 두 개 실행
docker run -d --name web nginx
docker run -d --name db redis

# web 컨테이너의 IP 확인
docker inspect web | grep IPAddress
# 출력: 172.17.0.2

# db 컨테이너 안에서 web에 ping 보내기(IP만 사용 가능)
docker exec db ping 172.17.0.2

보시다시피 통신할 때마다 먼저 IP를 확인해야 합니다. 컨테이너가 재시작되면 IP가 바뀔 수도 있어서 더 번거롭습니다.

권장하는 방법은 사용자 정의 bridge를 만드는 것입니다.

# 사용자 정의 네트워크 생성
docker network create --subnet=192.168.100.0/24 my-net

# 컨테이너를 사용자 정의 네트워크에 연결해 실행
docker run -d --network my-net --name web nginx
docker run -d --network my-net --name db redis

# web 컨테이너가 db를 직접 ping할 수 있음(DNS 자동 해석)
docker exec web ping db

이렇게 하면 컨테이너 이름을 도메인처럼 사용할 수 있어 훨씬 편합니다. 솔직히 이 부분은 저도 처음에 꽤 놀랐습니다. 수동으로 DNS를 설정해야 할 줄 알았는데 Docker가 기본으로 제공하고 있었으니까요.

---

Host: 최고의 성능, 가장 약한 격리

Host 모드는 조금 “직접적”입니다. 컨테이너가 호스트의 네트워크 스택을 그대로 사용합니다.

독립 IP도 없고, NAT 변환도 없고, veth pair도 없습니다. 컨테이너 안의 네트워크 인터페이스가 곧 호스트의 네트워크 인터페이스입니다. 성능은 네이티브에 가깝고 오버헤드는 거의 없습니다.

이렇게 직접 붙이면 성능이 가장 좋지 않을까 생각할 수 있습니다. 실제로 그렇습니다. 다만 그 대가는 격리의 상실입니다.

적합한 사용 사례

네트워크 성능에 민감한 상황에서는 Host가 최적의 선택입니다.

예를 들어 게임 서버, 실시간 통신(WebSocket, 비디오 스트리밍), 고빈도 거래 시스템처럼 수십 마이크로초의 지연도 중요한 애플리케이션에서는 Host 모드가 이런 오버헤드를 제거해 줍니다.

네트워크 디버깅에도 유용합니다. 컨테이너 안에서 tcpdump를 실행하면 별도 설정 없이 호스트의 트래픽을 바로 캡처할 수 있어 문제를 추적하기 쉽습니다.

설정 예시

설정은 더 단순합니다. -p도 필요 없습니다.

# host 모드, 컨테이너가 호스트의 80번 포트를 직접 점유
docker run -d --network host nginx

실행 후 호스트의 80번 포트에 바로 접속하면 컨테이너 안의 nginx에 접근하게 됩니다.

위험 요소

하지만 주의해야 할 함정이 몇 가지 있습니다.

포트 충돌: 호스트에서 이미 nginx가 실행 중이고 80번 포트를 점유하고 있다면, 80번 포트를 쓰려는 host 모드 컨테이너를 다시 실행할 때 바로 오류가 나며 시작되지 않습니다.

오류 메시지는 대략 다음과 비슷합니다.

docker: Error response from daemon: driver failed programming external connectivity on endpoint xxx: Bind for 0.0.0.0:80 failed: port is already allocated.

확인 방법은 간단합니다. 먼저 호스트의 포트 점유 상태를 확인합니다.

# 포트 점유 확인
netstat -tuln | grep :80
# 또는
ss -tuln | grep :80

# 프로세스 확인
lsof -i :80

프로세스가 포트를 점유하고 있다면 해당 서비스를 중지하거나 컨테이너 포트를 바꿔야 합니다. 다만 Host 모드에서는 -p를 사용할 수 없으므로, 컨테이너 안의 애플리케이션 설정을 바꿔야 합니다. 예를 들어 nginx가 8080을 리스닝하도록 바꾸는 식입니다.

보안성: 컨테이너는 호스트의 모든 네트워크 인터페이스를 볼 수 있습니다. 내부망, 외부망, 심지어 VPN 연결까지 포함됩니다. 컨테이너가 침해되면 공격자는 호스트의 모든 네트워크 자원에 접근할 수 있습니다. 운영 환경에서는 이 점을 반드시 신중하게 봐야 합니다.

솔직히 Host 모드는 자주 쓰는 편은 아닙니다. 대부분의 상황에서는 Bridge로 충분합니다. 하지만 성능 병목을 만났거나 정말 낮은 지연 시간이 필요하다면 Host는 고려할 만한 선택지입니다. 전제는 격리 비용을 감수할 수 있어야 한다는 것입니다.

---

Overlay: 호스트 간 통신의 정답

Bridge는 단일 호스트 통신만 가능하고, Host는 성능이 좋지만 역시 호스트를 넘어갈 수 없습니다. 그렇다면 여러 서버에 있는 컨테이너는 어떻게 서로 접근할까요? 이때 필요한 것이 Overlay입니다.

Overlay 네트워크는 VXLAN 터널 기술을 기반으로 서로 다른 호스트에 분산된 컨테이너를 하나의 가상 LAN 안으로 끌어옵니다. 마치 모든 컨테이너가 같은 머신 위에 있는 것처럼 동작합니다.

핵심 원리

VXLAN은 Overlay의 핵심입니다.

컨테이너 트래픽 바깥에 한 겹을 더 씌워 “터널”을 통해 다른 호스트로 전송하고, 도착한 뒤에는 그 포장을 풀어 대상 컨테이너에 전달합니다. 이 캡슐화와 역캡슐화 과정은 VTEP(VXLAN Tunnel Endpoint)가 담당하며, Docker Swarm에서는 자동으로 관리됩니다.

비유하자면 이렇습니다. 서울에서 부산으로 택배를 보낼 때 택배사가 당신의 물건을 큰 상자에 넣고 물류망을 통해 부산으로 보낸 뒤, 상자를 열어 수취인에게 물건을 전달합니다. VXLAN은 그 “큰 상자”이고, 컨테이너 트래픽은 당신의 “물건”이며, VTEP는 택배사의 포장과 개봉 과정입니다.

VXLAN의 장점은 하위 물리 네트워크가 어떻게 연결되어 있든 컨테이너 입장에서는 같은 가상 LAN만 보인다는 점입니다. IP가 통일되고 통신도 단순해집니다.

전제가 하나 있습니다. Overlay 네트워크에는 Swarm 클러스터 또는 Consul 같은 외부 KV store가 필요합니다. 단일 호스트 Docker만으로는 만들 수 없고, 반드시 여러 노드의 협력이 필요합니다.

왜 Swarm이 필요할까요? Overlay 네트워크는 여러 호스트의 컨테이너 IP, VTEP 연결, 라우팅 정보를 관리해야 합니다. 이런 정보에는 중앙화된 조정자가 필요하며, Swarm이 바로 그 역할을 합니다. Swarm을 쓰지 않는다면 Consul이나 Etcd를 KV store로 쓸 수 있지만 설정은 더 복잡합니다.

적합한 사용 사례

Docker Swarm 클러스터에서는 Overlay가 유일한 선택입니다.

예를 들어 Web 서비스는 노드 A에 있고 데이터베이스는 노드 B에 있는 호스트 간 마이크로서비스 배포에서는 두 서비스가 서로 접근해야 합니다. Overlay는 이들을 하나의 가상 네트워크로 묶어 컨테이너 이름만으로 통신하게 해 주며, IP를 따로 설정할 필요가 없습니다.

Kubernetes에도 비슷한 개념(CNI 네트워크)이 있지만 설정 방식은 다릅니다. 주로 K8s를 사용하더라도 이 글의 Overlay 개념은 K8s 네트워크 원리를 이해하는 데 도움이 됩니다.

설정 예시(전체 흐름)

Overlay 설정은 Bridge나 Host보다 복잡하며, 먼저 Swarm을 초기화해야 합니다.

# 1. 첫 번째 호스트에서 Swarm 초기화
docker swarm init --advertise-addr 192.168.1.10

# join token이 출력됨. 예:
# docker swarm join --token SWMTKN-xxx 192.168.1.10:2377

# 2. 다른 호스트에서 Swarm에 참여(위 명령 복사)
docker swarm join --token SWMTKN-xxx 192.168.1.10:2377

# 3. Overlay 네트워크 생성
docker network create --driver overlay --subnet=10.0.1.0/24 my-overlay

# 4. 서로 다른 호스트에서 컨테이너를 실행하고 같은 Overlay에 연결
# 노드 A에서
docker run -d --network my-overlay --name web nginx

# 노드 B에서
docker run -d --network my-overlay --name db redis

# 5. 통신 테스트(web이 호스트를 넘어 db에 ping 가능)
docker exec web ping db

제가 처음 Overlay를 설정할 때 빠뜨린 것이 있었습니다. Swarm 초기화를 잊은 채 곧바로 overlay 네트워크를 만들려고 했더니 “This node is not a swarm manager”라는 오류가 났습니다. 나중에야 Overlay가 반드시 Swarm에 의존한다는 것을 이해했습니다.

또 하나의 세부 사항은 --subnet=10.0.1.0/24입니다. /24 서브넷 블록(256개 IP)을 추천합니다. 다른 네트워크와 충돌을 피하기 쉽기 때문입니다. 규모가 큰 클러스터라면 /16을 쓸 수도 있지만, IP 범위를 미리 잘 계획해야 합니다.

---

성능 기준 비교: 데이터로 보기

세 가지 네트워크 모드는 실제로 성능 차이가 얼마나 날까요? 몇 가지 실측 데이터를 정리해 직관적으로 비교해 보겠습니다.

핵심 데이터(72시간 부하 테스트)

CSDN의 운영 환경 실측 보고서에 따르면, 세 가지 모드는 부하 테스트에서 다음과 같은 성능을 보였습니다.

핵심 발견

몇 가지 숫자가 꽤 흥미롭습니다.

Host는 Bridge보다 꽤 빠릅니다. 평균 지연 시간이 128μs에서 32μs로 낮아져 96μs 차이가 납니다. 약 14%의 성능 향상입니다. 처리량 측면에서 Host는 네이티브에 가깝고 Bridge는 대략 80% 수준입니다. 애플리케이션이 초당 수천 건의 요청을 처리한다면 이 차이는 꽤 분명하게 드러납니다.

Bridge의 NAT 오버헤드는 작지 않습니다. CPU 사용량이 0.9코어에서 1.8코어로 올라가 거의 두 배가 됩니다. 외부 요청마다 NAT 변환을 거쳐야 하므로 처리 단계가 하나 더 생기기 때문입니다.

Overlay의 VXLAN 캡슐화는 더 무겁습니다. 호스트 간 통신에서는 캡슐화와 역캡슐화가 필요하므로 Bridge보다 지연 시간이 더 높고 CPU 사용량도 더 큽니다. 분산 환경에는 적합하지만 고성능 단일 호스트에는 적합하지 않습니다.

실제 영향

이 숫자들은 추상적으로 보일 수 있지만 실제 상황에서는 차이가 큽니다.

예를 들어 고빈도 거래 시스템에서는 매 마이크로초가 중요합니다. Host의 32μs와 Bridge의 128μs 차이가 주문을 잡을 수 있느냐를 가를 수도 있습니다. 반면 일반적인 Web 애플리케이션에서는 사용자 요청 왕복 지연이 원래 수백 밀리초 수준이므로 수십 마이크로초 차이는 거의 체감되지 않습니다.

따라서 숫자만 보지 말고 자신의 상황과 함께 판단해야 합니다. 성능에 민감하면 Host를 우선 고려합니다. 보안이 우선이면 기본 Bridge가 적합합니다. 호스트 간 통신이 반드시 필요하면 Overlay를 쓰고 성능 비용을 받아들입니다.

내 환경에서 테스트하는 방법

자신의 환경에서 성능 차이를 측정하고 싶다면 몇 가지 간단한 방법이 있습니다.

지연 시간 테스트: ping 또는 iperf3 사용

# 컨테이너 A에서 컨테이너 B로 ping 보내기(bridge 모드)
docker exec container-a ping container-b

# iperf3로 처리량 테스트(먼저 iperf3 설치 필요)
docker exec container-a iperf3 -c container-b

CPU 사용량 모니터링: docker stats 사용

# 컨테이너 CPU 사용량 확인
docker stats --no-stream

네트워크 트래픽 모니터링: tcpdump로 패킷 캡처 및 분석

# 호스트 네트워크 트래픽 캡처(host 모드는 직접 캡처)
docker exec -it container-host tcpdump -i eth0

# bridge 네트워크 트래픽 캡처(브리지 지정 필요)
tcpdump -i docker0

운영 환경에 올리기 전에는 먼저 한 차례 부하 테스트를 돌려 선택한 네트워크 모드가 트래픽을 버틸 수 있는지 확인하는 것을 권합니다. 운영 이후에야 문제를 발견하면 너무 늦습니다.

---

의사결정 흐름도: 상황에서 모드 선택까지

많이 설명했지만 결국 어떻게 고르면 될까요? 간단한 의사결정 로직을 정리해 보겠습니다.

3단계 의사결정 흐름

네트워크 설정을 마주하면 다음 흐름대로 판단합니다.

1단계: 호스트 간 통신이 필요한가?

여러 컨테이너가 서로 다른 서버에 분산되어 있고 서로 접근해야 한다면, 예를 들어 Web은 노드 A에 있고 데이터베이스는 노드 B에 있다면 호스트 간 통신이 필요합니다.

• YES -> 2단계
• NO -> 3단계

2단계: Swarm을 사용하는가?

호스트 간 통신에는 두 가지 길이 있습니다. Docker Swarm(Overlay 사용) 또는 수동 라우팅 설정(Host + iptables 사용)입니다.

• YES -> Overlay 네트워크(가장 단순하며 Swarm이 자동 관리)
• NO -> Macvlan 또는 Host + 라우팅 설정 고려(복잡하며 특수한 상황에 적합)

3단계: 네트워크 성능에 민감한가?

애플리케이션이 지연 시간이나 처리량에 민감하다면, 예를 들어 고빈도 거래, 실시간 통신, 게임이라면 성능을 우선합니다.

• YES -> Host 모드(단, 보안 위험 평가 필요)
• NO -> Bridge 모드(기본적이고 안전한 선택)

상황별 추천표

조금 더 직관적으로 보면, 흔한 상황의 추천은 다음과 같습니다.

상황	추천 모드	이유
단일 호스트 Web 애플리케이션	Bridge	안전하고 단순하며 기본값으로 충분
고빈도 거래 서비스	Host	지연 시간에 민감하고 성능이 가장 좋음
Swarm 마이크로서비스 클러스터	Overlay	호스트 간 통신에 필요
개발 디버깅 환경	Bridge(사용자 정의)	DNS 지원, 컨테이너 이름 통신
완전 격리 테스트	None	네트워크 없음, 완전 격리

작은 조언 하나

처음부터 “어떤 모드가 최적인가”에 너무 매달리지 마세요.

대부분의 상황에서는 Bridge로 충분합니다. 문제가 생기면 그때 조정하면 됩니다.

• 서비스 발견이 번거롭다 -> 사용자 정의 Bridge로 변경
• 성능이 정말 부족하다 -> Host 고려, 단 보안 비용 평가
• 호스트 간 통신이 필요하다 -> Overlay 사용, VXLAN 성능 오버헤드 수용

저는 많은 팀이 처음부터 Host를 설정했다가 포트 충돌과 보안 취약점에 시달리는 것을 보았습니다. 사실 Bridge 기본값만으로도 90%의 상황은 해결됩니다. 과도하게 최적화할 필요는 없습니다.

---

운영 환경 모범 사례

세 가지 모드에는 각각 장단점이 있습니다. 운영 환경에서는 어떻게 써야 안정적일까요? 몇 가지 실전 경험을 정리했습니다.

Bridge: 사용자 정의 네트워크 + DNS

기본 bridge에는 큰 문제가 하나 있습니다. 컨테이너가 이름이 아니라 IP로만 통신할 수 있다는 점입니다.

운영 환경에서는 사용자 정의 bridge 생성을 권장합니다.

# 사용자 정의 네트워크 생성, 서브넷 지정(충돌 방지)
docker network create --subnet=192.168.100.0/24 --name my-app-net

# 서비스를 사용자 정의 네트워크에 연결해 실행
docker run -d --network my-app-net --name web-server nginx
docker run -d --network my-app-net --name redis-cache redis

# web-server가 redis-cache에 직접 접근 가능(DNS 자동 해석)
docker exec web-server ping redis-cache

이렇게 하면 서비스 발견을 위해 IP를 수동 설정할 필요가 없습니다. 컨테이너 이름을 도메인처럼 쓸 수 있어 훨씬 편합니다.

또 하나 중요한 점은 서브넷 계획입니다. 기본 172.17.x.x는 회사 내부망과 충돌하기 쉽기 때문에 피하는 것이 좋습니다. 192.168.100.0/24 또는 10.10.10.0/24 같은 범위를 추천하며, 운영팀과 미리 IP 범위를 조율하는 것이 좋습니다.

Host: 보안 강화는 빼놓을 수 없습니다

Host 모드는 성능이 좋지만 보안성은 낮습니다. 컨테이너가 호스트의 모든 네트워크 인터페이스를 볼 수 있으며, 내부망, 외부망, VPN까지 포함됩니다.

운영 환경에서 Host를 쓴다면 최소한 두 가지는 해야 합니다.

첫째: 컨테이너 권한 제한. --cap-drop으로 불필요한 Linux capabilities를 제거합니다. 예를 들어 CAP_NET_RAW를 제거하면 컨테이너가 임의로 패킷을 캡처하는 것을 막을 수 있습니다.

docker run -d --network host --cap-drop NET_RAW nginx

둘째: 이상 트래픽 모니터링. 컨테이너의 네트워크 동작을 모니터링해야 합니다. 갑자기 대량의 외부 연결이 발생하거나 내부망의 민감한 인터페이스에 접근하면 알림이 가야 합니다. Prometheus + Grafana를 사용할 수도 있고, 전용 네트워크 보안 도구를 사용할 수도 있습니다.

솔직히 운영 환경에서 Host 모드는 자주 쓰지 않습니다. 정말 성능 병목이 있을 때가 아니라면 대부분 Bridge + 사용자 정의 네트워크로 충분합니다.

Overlay: 서브넷 크기 + Swarm 안정성

Overlay 네트워크의 핵심은 VXLAN 캡슐화이며, 오버헤드가 작지 않습니다.

몇 가지 최적화 포인트가 있습니다.

서브넷 크기 제어: /24(256개 IP)를 추천합니다. 규모가 큰 클러스터에서는 /16(약 6만 개 IP)을 사용할 수 있지만, 충돌을 피하려면 미리 계획해야 합니다.

# 추천: /24 서브넷 블록
docker network create --driver overlay --subnet=10.0.1.0/24 my-overlay

CPU 사용률 모니터링: VXLAN 캡슐화는 CPU 오버헤드를 늘립니다. 특히 트래픽이 많은 상황에서 그렇습니다. docker stats나 Prometheus로 모니터링하고, CPU가 지나치게 높으면 MTU 조정이나 호스트 간 통신 감소 같은 최적화를 제때 해야 합니다.

Swarm 노드 간 네트워크 안정성 우선: Overlay는 Swarm에 의존합니다. 노드 간 네트워크가 불안정하면 Overlay도 문제가 생깁니다. 운영 환경에서 Overlay를 쓴다면 Swarm 노드 간 네트워크 지연이 낮고 패킷 손실이 적어야 하며, 가능하면 내부 전용망을 사용하는 것이 좋습니다.

---

정리: 세 가지 핵심 원칙만 기억하기

많이 이야기했지만 결국 세 문장으로 정리할 수 있습니다.

1. 단일 호스트는 기본 Bridge

90%의 상황에서는 Bridge로 충분합니다. 안전하고 단순하며 기본값으로 바로 사용할 수 있습니다. 서비스 발견이 번거롭다면 사용자 정의 Bridge로 바꾸면 컨테이너 이름으로 통신할 수 있습니다.

2. 성능에 민감하면 Host

지연 시간에 민감하거나 처리량이 중요한 상황에서는 Host가 최적의 선택입니다. 하지만 기억해야 합니다. 성능은 가장 좋고 격리는 가장 약합니다. 운영 환경에서 Host를 쓴다면 보안 강화를 해야 합니다.

3. 호스트 간 통신은 반드시 Overlay

여러 서버의 컨테이너가 서로 접근해야 한다면 Overlay가 유일한 정답입니다. 전제는 Swarm 클러스터입니다. 설정은 Bridge나 Host보다 복잡하지만 호스트 간 통신에는 필요합니다.

실전 조언

다음에 Docker 네트워크 문제를 만나면 먼저 스스로에게 한 가지를 물어보세요. 단일 호스트인가, 호스트 간 통신인가?

단일 호스트라면 기본 Bridge를 사용합니다. 성능이 부족하면 Host를 고려하되 보안 비용을 평가합니다. 호스트 간 통신이라면 Overlay를 사용하고 VXLAN의 성능 오버헤드를 받아들입니다.

처음부터 “어떤 모드가 최적인가”에 매달리지 말고 Bridge에서 시작한 뒤 문제가 생기면 조정하세요. 저는 예전에 순서를 반대로 잡았습니다. 먼저 Overlay를 설정했지만 단일 호스트 상황에서는 애초에 필요가 없어서 괜히 시간을 낭비했습니다.

bridge/host/none/container의 기본 원리가 아직 익숙하지 않다면, 이 시리즈의 11번째 글인 “Docker 네트워크 모드 상세 해설”을 먼저 읽는 것을 권합니다. 기초를 잡고 이 심화 내용을 보면 훨씬 더 매끄럽게 이해할 수 있습니다.

---

참고 자료

"Docker는 bridge, host, overlay, macvlan 등 다양한 네트워크 드라이버를 제공하며 각 모드는 서로 다른 상황에 적합합니다. 공식 문서는 각 모드의 설정 방법과 사용 사례를 자세히 설명합니다."

"Overlay 네트워크는 VXLAN 터널 기술을 기반으로 하며 Swarm 클러스터 또는 외부 KV store 지원이 필요합니다. 호스트 간 컨테이너 통신에 적합합니다. 공식 문서는 전체 설정 흐름을 제공합니다."

"Swarm 네트워크 관리 가이드입니다. overlay 네트워크 생성, 서비스 네트워크 관리, 호스트 간 통신 모범 사례를 포함합니다."

"Docker 네트워크 설정 모범 사례(운영 환경 무손실 실측 보고서)는 72시간 부하 테스트 데이터를 제공합니다. Host, Bridge, Overlay 세 가지 모드의 지연 시간, 처리량, 패킷 손실률 비교가 포함되어 있습니다."

"Docker Network Tests under Host/Bridge Mode는 Host와 Bridge 모드의 성능 차이를 자세히 비교하고, 지연 시간 테스트 방법과 실험 데이터를 제공합니다."