Docker 네트워크 모드 완벽 해설: bridge/host/none/container 성능 비교와 상황별 선택

터미널에 초록색으로 Container started가 떴고 서비스도 분명 실행됐는데, curl은 계속 timeout이 납니다. docker logs를 세 번이나 살펴봐도 오류가 없고, -p 8080:80 포트 매핑도 설정했으며 라우팅에도 문제가 없고 방화벽까지 껐습니다. 도대체 어디가 문제일까요?

나중에야 네트워크 모드를 잘못 사용했다는 것을 알았습니다. docker run -p만 실행하면 끝이라고 생각했지, Docker에 bridge, host, none, container라는 네 가지 네트워크 모드가 있다는 사실은 몰랐습니다.

여러분도 ‘컨테이너는 실행됐는데 도무지 접속되지 않는’ 상황을 겪었거나 Docker 네트워크 설정을 어렴풋이만 알고 있다면, 이 글에서 네 가지 네트워크 모드의 차이, 원리, 사용 사례를 가장 쉬운 말로 설명해 드리겠습니다. 복잡한 Linux 네트워크 네임스페이스 이론 대신 실전에서 정말 알아야 할 내용만 다룹니다.

먼저 Docker 네트워크의 ‘기초’인 docker0 브리지를 이해하기

docker0란? 컨테이너의 ‘단지 관리 게이트웨이’

Docker를 설치하면 시스템에 docker0라는 가상 네트워크 인터페이스가 자동으로 생깁니다. 아파트 단지의 관리 게이트웨이라고 생각하면 됩니다. 모든 컨테이너(입주자)는 인터넷에 접속하기 위해 이곳을 거쳐야 합니다.

터미널에서 다음 명령어를 실행해 보세요.

ip addr show docker0

다음과 비슷한 출력이 나타납니다.

docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0

172.17.0.1이 보이나요? 이것이 docker0의 IP 주소입니다. Docker는 새로 만든 각 컨테이너에 172.17.0.0/16 대역의 IP를 할당합니다. 예를 들면 172.17.0.2, 172.17.0.3 같은 주소입니다.

Docker 네트워크 목록도 살펴보겠습니다.

docker network ls

NETWORK ID     NAME      DRIVER    SCOPE
7f8a2b3c9d4e   bridge    bridge    local

이 기본 bridge 네트워크는 내부적으로 docker0 브리지를 사용합니다.

veth pair: 컨테이너 네트워크의 ‘무전기’

docker0만으로는 충분하지 않습니다. 컨테이너는 자체 ‘독립된 방’, 전문 용어로 네트워크 네임스페이스 안에 있는데 어떻게 docker0와 통신할까요?

정답은 veth pair입니다. 한 쌍의 무전기와 같습니다. 한쪽 끝은 컨테이너 안에서 eth0라고 부르고, 다른 한쪽 끝은 호스트에서 vethXXX(예: veth9a7b4c)라고 부릅니다. 양쪽 끝이 서로 데이터를 주고받습니다.

컨테이너 하나를 실행해 보겠습니다.

docker run -d --name test-nginx nginx

호스트에서 네트워크 인터페이스를 확인합니다.

ip addr | grep veth

그러면 veth로 시작하는 장치가 하나 더 생긴 것을 볼 수 있습니다. 컨테이너 안에서도 확인해 보세요.

docker exec test-nginx ip addr

컨테이너 안에는 IP가 172.17.0.2인 eth0 인터페이스가 있습니다. 이 eth0와 호스트의 vethXXX가 한 쌍입니다. 패킷은 eth0에서 나와 곧바로 vethXXX에 도착하고, docker0를 거친 뒤 호스트 네트워크 인터페이스(예: eth0 또는 ens33)를 통해 외부 네트워크로 나갑니다.

전체 경로는 다음과 같습니다.

컨테이너 내부(172.17.0.2)
  ↓ eth0
  ↓ (veth pair)
  ↓ vethXXX
  ↓
docker0 브리지(172.17.0.1)
  ↓ NAT 전달
  ↓
호스트 네트워크 인터페이스(예: 192.168.1.100)
  ↓
외부 네트워크

조금 복잡해 보이지만 실제로는 매우 빠르게 작동합니다. 컨테이너 IP에 ping을 보내 보면 지연 시간은 보통 0점 몇 밀리초에 불과합니다.

솔직히 저도 veth pair라는 개념을 처음 봤을 때 한동안 어리둥절했습니다. 나중에 이해하고 보니 단지 가상 네트워크 케이블일 뿐이었습니다. 한쪽은 컨테이너에, 다른 쪽은 docker0에 꽂혀 있습니다. 그게 전부입니다.

Bridge 모드: Docker의 ‘기본 선택’

왜 bridge가 기본일까요?

네트워크 모드를 지정하지 않으면 Docker는 자동으로 bridge 모드를 사용합니다. 이유는 간단합니다. 격리성과 사용 편의성 사이의 균형점이기 때문입니다.

Railway - 현대적인 배포 플랫폼, 번거로운 운영 없이 몇 분 만에 라이브

지금 시작 →광고

bridge 모드에서는 각 컨테이너가 독립된 IP를 가지므로 포트가 충돌하지 않습니다. 동시에 -p 옵션으로 서비스를 호스트에 쉽게 노출할 수 있습니다. 대부분의 상황에는 이것으로 충분합니다.

예를 들어 Nginx 컨테이너 두 개를 실행해 보겠습니다.

docker run -d -p 8080:80 --name web1 nginx
docker run -d -p 8081:80 --name web2 nginx

두 컨테이너 모두 80번 포트를 수신하지만 서로 독립된 네트워크 공간에 있으므로 충돌하지 않습니다. 호스트에서는 8080번과 8081번 포트로 접속할 수 있고, 그 뒤에서는 Docker가 NAT 포트 포워딩을 수행합니다.

docker inspect web1으로 네트워크 설정을 살펴보겠습니다.

"Networks": {
    "bridge": {
        "IPAddress": "172.17.0.2",
        "Gateway": "172.17.0.1"
    }
}

보시다시피 컨테이너는 172.17.0.2라는 사설 IP를 할당받았고, 게이트웨이는 docker0의 172.17.0.1입니다.

기본 bridge와 사용자 정의 bridge의 중요한 차이

여기에는 한 가지 함정이 있습니다. 기본 bridge 네트워크, 즉 docker0에서는 컨테이너끼리 IP로만 통신할 수 있고 컨테이너 이름을 해석하지 못합니다.

다음을 실행해 보세요.

docker run -d --name db mysql
docker run -it --name app alpine ping db

ping이 되지 않을 것입니다. ping 172.17.0.2처럼 IP를 직접 지정해야 합니다.

하지만 사용자 정의 bridge 네트워크를 만들면 이야기가 달라집니다.

docker network create mynet
docker run -d --name db --network mynet mysql
docker run -it --name app --network mynet alpine ping db

이번에는 연결됩니다. 사용자 정의 bridge 네트워크에는 DNS 조회 기능이 기본 제공되므로 컨테이너 이름을 도메인 이름처럼 바로 사용할 수 있습니다.

이것이 바로 프로덕션 환경에서 기본 docker0 대신 사용자 정의 네트워크를 권장하는 이유입니다. 서비스 디스커버리가 훨씬 편해지고 IP를 하드코딩할 필요가 없습니다.

-p 옵션의 비밀: NAT 포워딩

-p 8080:80을 사용하면 Docker는 실제로 호스트의 iptables에 NAT 규칙 하나를 추가합니다.

iptables -t nat -L -n | grep 8080

다음과 비슷한 출력이 나타납니다.

DNAT  tcp  --  0.0.0.0/0  0.0.0.0/0  tcp dpt:8080 to:172.17.0.2:80

호스트의 8080번 포트로 들어오는 모든 트래픽을 컨테이너의 172.17.0.2:80으로 전달한다는 뜻입니다.

외부에서 http://호스트IP:8080으로 접속해 컨테이너 안의 서비스를 이용할 수 있는 이유가 바로 이것입니다. Docker가 주소 변환 계층을 하나 처리해 줍니다.

Bridge 모드가 적합한 상황

정리하면 bridge 모드는 다음과 같은 상황에 적합합니다.

• 마이크로서비스 아키텍처: 여러 컨테이너가 협력하며, 격리된 상태로 서로 통신해야 할 때(사용자 정의 bridge 네트워크 사용)
• 개발 환경: 서비스를 빠르게 실행해 테스트할 때는 기본 bridge만으로 충분합니다.
• 포트 매핑이 필요한 Web 애플리케이션: 블로그나 API 서비스를 실행하는 경우

성능 측면에서 bridge 모드에는 NAT와 veth pair로 인한 오버헤드가 어느 정도 있습니다. 하지만 솔직히 대부분의 애플리케이션에서는 이 정도 손실을 무시해도 됩니다. 실제로 성능 병목이 생기는 경우는 많지 않으니 처음부터 걱정할 필요는 없습니다.

Host 모드: ‘성능 우선’ 선택

Host 모드란? 네트워크를 직접 ‘공유’하기

Host 모드는 가장 단순하고 과감합니다. 컨테이너의 독립 네트워크를 없애고 호스트의 네트워크 스택을 바로 사용합니다.

컨테이너를 실행할 때 --net=host를 추가합니다.

docker run -d --net=host --name web nginx

이때 컨테이너에는 독립된 IP나 eth0 네트워크 인터페이스가 없으며 호스트의 네트워크 인터페이스를 직접 공유합니다. 컨테이너 안에서 보는 네트워크 인터페이스 설정은 호스트에서 실행한 ip addr 출력과 똑같습니다.

더 중요한 점은 -p를 통한 포트 매핑이 필요 없다는 것입니다. 컨테이너의 서비스가 80번 포트를 수신하면 외부에서 곧바로 호스트IP:80으로 접속할 수 있습니다.

성능상 이점은 어디에서 올까요?

Host 모드는 docker0 브리지와 veth pair를 건너뛰고 NAT 포워딩도 필요하지 않습니다. 패킷이 호스트 네트워크 인터페이스로 바로 드나드므로 호스트에서 프로세스를 직접 실행하는 것과 같습니다.

일부 테스트에서는 동시 요청이 많은 상황에서 host 모드가 bridge 모드보다 약 5~10% 빠른 것으로 나타났습니다. 큰 차이가 아닌 것처럼 들리지만, 고빈도 거래나 실시간 게임 서버처럼 지연 시간에 극도로 민감한 애플리케이션에는 의미 있는 차이입니다.

예전에 Nginx를 리버스 프록시로 사용해 초당 수만 건의 요청을 처리한 사례가 있었습니다. host 모드로 바꾸자 P99 지연 시간이 12ms에서 9ms로 줄었습니다. 3밀리초밖에 줄지 않았지만 그 프로젝트에는 수만 위안의 가치가 있는 3밀리초였습니다.

Host 모드의 함정과 대가

성능은 좋아지지만 함정도 적지 않습니다.

함정 1: 포트 충돌

호스트의 포트를 직접 사용하므로 같은 포트를 수신하는 컨테이너를 여러 개 실행하면 바로 오류가 발생합니다.

docker run -d --net=host nginx  # 80번 포트 수신
docker run -d --net=host nginx  # 다시 80번 포트 수신, 오류: Address already in use

호스트에서 Nginx 두 개를 직접 실행하는 것과 다르지 않습니다. 인스턴스를 여러 개 실행하려면 컨테이너 내부의 수신 포트를 바꾸거나 host 모드를 사용하지 않아야 합니다.

Alibaba Cloud - 개발자 클라우드 1순위, Lighthouse 서버 15% 할인

15% 할인 받기 →광고

함정 2: 컨테이너 내부 서비스는 반드시 0.0.0.0에서 수신해야 함

컨테이너 안의 서비스가 127.0.0.1에서만 수신하면 외부에서 접속할 수 없습니다. 외부 접속을 허용하려면 반드시 0.0.0.0에서 수신해야 합니다.

한번은 Node.js 서비스를 host 모드로 실행했는데, 코드에 app.listen(3000, 'localhost')라고 작성해 둔 탓에 외부에서 아무리 해도 연결되지 않았습니다. app.listen(3000, '0.0.0.0')으로 바꾸고 나서야 해결됐습니다.

함정 3: 네트워크 격리 상실

컨테이너가 호스트의 모든 네트워크 리소스에 직접 접근할 수 있어 보안 위험이 큽니다. 컨테이너에서 신뢰할 수 없는 서드파티 코드를 실행한다면 host 모드는 스스로 함정을 파는 셈입니다.

Host 모드는 언제 사용해야 할까요?

솔직히 말해 실제로 성능 병목이 생겼을 때만 host 모드를 고려해야 합니다. 대부분의 상황에서는 bridge 모드의 오버헤드가 전혀 문제가 되지 않습니다.

Host 모드는 다음과 같은 상황에 적합합니다.

• 모니터링 도구: 호스트 네트워크 리소스에 직접 접근해야 하는 Prometheus, Grafana, ELK 등
• 고성능 프록시: 지연 시간을 극도로 줄이려는 Nginx, HAProxy 로드 밸런싱
• 데이터베이스: 네트워크 성능에 민감한 MySQL, Redis 같은 서비스(단, 보안에 유의해야 합니다.)

애플리케이션의 초당 요청 수가 수천 건 이하라면 host 모드에 매달릴 필요가 없습니다. bridge로 충분합니다.

None과 Container 모드: ‘특수 상황 전용’

None 모드: 네트워크가 완전히 끊긴 샌드박스

None 모드는 말 그대로 컨테이너에 네트워크가 전혀 없는 모드입니다.

docker run -it --net=none alpine sh

컨테이너 안에서 ip addr를 실행하면 loopback 인터페이스(lo) 하나만 보입니다. 외부 네트워크에 연결할 수도 없고 다른 컨테이너에서도 이 컨테이너에 접근할 수 없습니다.

None 모드는 언제 사용하나요?

솔직히 실제 업무에서 none 모드를 사용한 적은 거의 없습니다. 활용 범위가 매우 좁습니다.

• 보안 테스트: 신뢰할 수 없는 코드를 실행하면서 데이터 유출을 막기 위해 네트워크를 완전히 격리할 때
• 오프라인 데이터 처리: 컨테이너가 로컬 연산만 수행하고 네트워크 통신은 전혀 필요하지 않을 때
• 수동 네트워크 설정: 네트워크 설정을 완전히 사용자 정의해야 하는 극히 드문 상황(예: pipework 같은 도구로 veth를 수동 설정)

보안 연구를 하거나 특별한 네트워크 설정이 필요한 것이 아니라면 none 모드를 사용할 일은 거의 없습니다.

Container 모드: 두 컨테이너가 ‘네트워크 공유’

Container 모드에서는 한 컨테이너가 다른 컨테이너의 네트워크 네임스페이스를 사용합니다. 복잡하게 들리지만 예제를 보면 바로 이해할 수 있습니다.

# 먼저 컨테이너 하나를 실행합니다.
docker run -d --name web nginx

# 두 번째 컨테이너가 web의 네트워크를 공유합니다.
docker run -it --net=container:web alpine sh

이제 두 컨테이너는 IP 주소, 포트 공간, 네트워크 인터페이스 설정 등 동일한 네트워크 구성을 공유합니다. 두 번째 컨테이너 안에서 localhost:80으로 nginx에 접속할 수 있습니다.

Container 모드의 대표 사례: Kubernetes Pod

Kubernetes의 Pod는 사실 container 모드로 구현됩니다. 하나의 Pod 안에 여러 컨테이너가 있고, 이들은 하나의 ‘pause’ 컨테이너 네트워크를 공유합니다.

예를 들어 하나의 Pod에서 애플리케이션 컨테이너와 로그를 수집하는 sidecar 컨테이너를 함께 실행하면, 두 컨테이너는 외부에 포트를 노출하지 않고도 localhost를 통해 통신할 수 있습니다.

하지만 Kubernetes가 아니라 Docker만 단독으로 사용한다면 container 모드를 쓸 일은 많지 않습니다. bridge 모드와 사용자 정의 네트워크를 조합해도 컨테이너 간 통신을 구현할 수 있고 더 유연하기 때문입니다.

두 모드의 역할

결국 none과 container는 일상적인 솔루션이라기보다 ‘저수준 기능’에 가깝습니다. 특수 상황에 유연성을 제공하지만 80%의 경우에는 필요하지 않습니다.

다음 두 가지만 기억하세요.

• None 모드: 네트워크를 완전히 격리해야 할 때 사용합니다(매우 드묾).
• Container 모드: Kubernetes 같은 오케스트레이션 도구에서 흔하며 Docker만 단독으로 쓸 때는 거의 사용하지 않습니다.

실전 결정: 알맞은 네트워크 모드를 선택하는 방법

결정 흐름도 한 장으로 보기

구체적인 프로젝트에서 어떤 네트워크 모드를 써야 할까요? 간단한 결정 흐름을 정리해 봤습니다.

네트워크 격리가 필요한가?
│
├─ No → 성능 병목이 있는가?
│       │
│       ├─ Yes → Host 모드 사용(보안 위험에 유의)
│       └─ No  → Bridge 모드 사용(더 안전함)
│
└─ Yes → 컨테이너끼리 이름으로 통신해야 하는가?
        │
        ├─ Yes → 사용자 정의 Bridge 네트워크
        └─ No  → 기본 Bridge 네트워크

특수 상황:

• 네트워크가 전혀 필요하지 않음 → None 모드
• Kubernetes Pod 내부의 컨테이너 → Container 모드

상황별 추천 요약표

흔한 오해 세 가지

오해 1: ‘Host 모드가 항상 최고다’

그렇지 않습니다. Host 모드는 격리성과 유연성을 희생해 성능을 높입니다. 그리고 그 성능 향상은 많은 상황에서 무시해도 될 정도입니다.

모든 컨테이너를 host 모드로 실행했다가 포트 충돌과 보안 문제를 잔뜩 겪는 사람을 본 적이 있습니다. 측정해 보니 성능은 실제로 조금 빨라졌지만 유지 보수 비용은 열 배로 늘었습니다.

진실: 애플리케이션의 80%는 bridge 모드로 충분합니다. ‘더 좋은 성능’이라는 말에 현혹되지 마세요.

오해 2: ‘기본 bridge로 충분하다’

KiloClaw - 기업용 매니지드 OpenClaw, AI Agent 오케스트레이션 및 스마트 라우팅

시작하기 →광고

프로덕션 환경에는 권장하지 않습니다. 기본 bridge는 컨테이너 이름 조회를 지원하지 않으므로 여러 서비스가 통신할 때 IP를 하드코딩하거나 환경 변수로 IP를 전달해야 합니다. 매우 취약한 방식입니다.

사용자 정의 bridge 네트워크는 간단하게 만들 수 있습니다.

docker network create mynet
docker-compose.yml에서 network를 지정하면 됩니다.

진실: 사용자 정의 네트워크를 설정하는 데 2분만 더 쓰면 몇 시간의 문제 해결 시간을 아낄 수 있습니다.

오해 3: ‘컨테이너 네트워크 문제는 모두 모드를 잘못 선택해서 생긴다’

항상 그런 것은 아닙니다. 방화벽, iptables 설정, DNS가 원인인 경우도 많습니다.

문제 해결 순서는 다음과 같습니다.

1. 먼저 컨테이너 안에서 게이트웨이(docker0의 IP)에 ping이 되는지 확인합니다.
2. 다음으로 호스트의 외부 네트워크 IP에 ping이 되는지 확인합니다.
3. iptables 규칙에 DROP이 있는지 확인합니다.
4. Docker daemon 설정(/etc/docker/daemon.json)을 확인합니다.

진실: 모드는 첫 단계일 뿐이며 네트워크 문제는 체계적으로 진단해야 합니다.

고급 팁

팁 1: 하나의 컨테이너를 여러 네트워크에 연결하기

때로는 컨테이너가 두 네트워크에 동시에 연결되어야 합니다. 예를 들어 프론트엔드 네트워크와 백엔드 네트워크에 함께 연결해야 한다면 다음과 같이 설정할 수 있습니다.

docker network create frontend
docker network create backend

docker run -d --name web --network frontend nginx
docker network connect backend web

이제 web 컨테이너는 frontend와 backend 두 네트워크에 동시에 연결됩니다.

팁 2: IP 할당 정밀 제어하기

사용자 정의 네트워크를 만들 때 서브넷과 게이트웨이를 지정할 수 있습니다.

docker network create \
  --driver bridge \
  --subnet 192.168.10.0/24 \
  --gateway 192.168.10.1 \
  mynet

docker run -d --network mynet --ip 192.168.10.100 nginx

방화벽 허용 목록처럼 고정 IP가 필요한 상황에 유용합니다.

팁 3: 네트워크 문제 해결에 유용한 도구

컨테이너 안에서 네트워크 문제를 진단할 때는 다음 도구가 유용합니다.

# 네트워크 도구 설치
docker exec -it <container> apk add curl netcat-openbsd

# 연결 테스트
docker exec <container> nc -zv <host> <port>

# 라우팅 테이블 확인
docker exec <container> ip route

# 패킷 캡처 분석(호스트 권한 필요)
docker exec <container> tcpdump -i eth0

결론

지금까지 살펴본 네 가지 네트워크 모드를 빠르게 정리해 보겠습니다.

• Bridge 모드: 기본 선택으로 대부분의 상황에 적합하며, 프로덕션 환경에서는 사용자 정의 bridge 네트워크를 권장합니다.
• Host 모드: 성능을 우선하지만 격리성을 희생하므로 실제 병목이 있을 때만 사용합니다.
• None 모드: 네트워크를 완전히 차단하며 거의 사용하지 않습니다.
• Container 모드: 네트워크를 공유하며 주로 Kubernetes에서 사용합니다.

한 가지만 기억하세요. 최고의 모드는 없고 가장 알맞은 모드만 있습니다.

Docker를 처음 접한다면 기본 bridge 모드부터 시작하면 됩니다. 구체적인 문제가 생길 때 조정하세요. 서비스 디스커버리가 번거로우면 사용자 정의 bridge로 바꾸고, 성능이 정말 부족할 때 host를 고려하면 됩니다. 처음부터 어떤 모드가 ‘최적’인지 고민하지 마세요.

직접 실습해 보는 것을 권합니다. 사용자 정의 네트워크를 만들고 컨테이너 몇 개를 실행한 뒤, 컨테이너 이름으로 서로 통신할 수 있는지 테스트해 보세요. 실제로 한 번 실행해 보는 것이 글 열 편을 읽는 것보다 낫습니다.

실제 프로젝트에서 Docker 네트워크 문제를 겪었다면 댓글로 함께 이야기해 주세요. 이 분야는 생각보다 깊지만 이런 기본 개념을 익히면 문제의 80%는 스스로 해결할 수 있습니다.