클라우드와 컨테이너 네트워크
현대 서비스는 대부분 클라우드 위에서 운영됩니다. AWS, GCP, Azure 같은 클라우드 환경에서 네트워크를 구성하는 방법은 물리 네트워크와 개념은 같지만, 가상화라는 추상화 계층이 추가됩니다. Docker와 Kubernetes 같은 컨테이너 환경은 또 다른 네트워크 추상화를 제공합니다.
AWS VPC 기본 구성
VPC를 생성할 때 CIDR 블록을 지정합니다. 10.0.0.0/16이라면 65,536개의 IPv4 주소 범위를 가진 가상 네트워크가 만들어집니다. 실제 EC2에 할당 가능한 주소 수는 서브넷마다 AWS가 예약하는 주소가 있기 때문에 CIDR 전체 개수와 정확히 같지는 않습니다.
VPC 안에 서브넷을 만듭니다. 퍼블릭 서브넷은 라우팅 테이블에 인터넷 게이트웨이로 가는 경로가 있는 서브넷입니다. 여기에 있는 인스턴스가 실제로 인터넷에서 접근 가능하려면 퍼블릭 IPv4 또는 IPv6 주소, 보안 그룹/NACL 허용 규칙도 필요합니다. 프라이빗 서브넷은 인터넷 게이트웨이로 직접 나가는 기본 경로가 없는 서브넷입니다. 웹 진입점이나 로드 밸런서는 퍼블릭에, 데이터베이스는 프라이빗에 배치하는 것이 일반적입니다.
인터넷 게이트웨이(IGW)는 VPC를 인터넷에 연결합니다. 퍼블릭 서브넷의 라우팅 테이블에 0.0.0.0/0 → IGW를 추가하면, 해당 서브넷의 인스턴스가 인터넷과 통신할 수 있습니다.
NAT 게이트웨이는 프라이빗 서브넷의 인스턴스가 인터넷으로 나가는 트래픽(소프트웨어 업데이트 다운로드 등)을 허용하되, 인터넷에서 프라이빗 인스턴스로 새 연결을 시작하는 것은 허용하지 않습니다. 운영 환경에서는 AZ별 NAT 게이트웨이와 라우팅을 분리해 단일 AZ 장애가 전체 아웃바운드 장애로 번지지 않게 설계합니다.
보안 그룹과 NACL
| 비교 | 보안 그룹 | NACL |
|---|---|---|
| 적용 대상 | ENI/인스턴스 수준 | 서브넷 수준 |
| 상태 | Stateful | Stateless |
| 규칙 유형 | 허용 규칙만 | 허용 + 거부 규칙 |
| 규칙 평가 | 허용 규칙의 합집합 | 낮은 번호부터 첫 매칭 적용 |
| 반환 트래픽 | 자동 허용 | 인바운드/아웃바운드 모두 명시 필요 |
| 기본값 | 기본 SG는 내부 통신 허용, outbound 허용 | 기본 NACL은 허용, custom은 거부 |
일반적으로 보안 그룹으로 주요 접근 제어를 하고, NACL은 서브넷 레벨의 추가 방어벽으로 사용합니다. NACL은 stateless라서 응답 트래픽의 ephemeral port 범위까지 고려해야 하며, 규칙 번호를 10, 20, 30처럼 여유 있게 두면 나중에 중간 규칙을 넣기 쉽습니다.
Docker 네트워크
Docker 컨테이너는 격리된 네트워크 네임스페이스를 가집니다. 컨테이너 안에서는 자기만의 인터페이스, 라우팅 테이블, DNS 설정이 있는 것처럼 보이고, 호스트는 bridge, NAT, port publishing 같은 장치로 외부와 연결합니다.
| 드라이버 | 설명 | 사용 시나리오 |
|---|---|---|
| bridge | 단일 호스트 가상 브리지, NAT/포트 게시 | 일반적인 단일 호스트 컨테이너 |
| host | 호스트 네트워크 네임스페이스 공유 | 네트워크 격리보다 성능/단순성 |
| none | 네트워크 인터페이스 거의 없음 | 완전 격리, 배치 처리 |
| overlay | 여러 Docker 호스트를 가로지르는 네트워크 | Swarm, 멀티 노드 통신 |
| macvlan | 컨테이너가 물리 네트워크의 별도 호스트처럼 보임 | 레거시 L2 연동 |
기본 bridge보다 사용자 정의 bridge 네트워크를 만드는 편이 보통 더 낫습니다. 컨테이너 이름 기반 DNS, 네트워크별 격리, 명시적인 연결 관리가 쉬워지기 때문입니다.
Kubernetes 네트워크 모델
Kubernetes는 Docker보다 한 단계 높은 추상화를 제공합니다. 핵심 네트워크 모델은 다음과 같습니다.
- 모든 파드(Pod)는 고유한 IP 주소를 가집니다.
- 모든 파드는 NAT 없이 다른 파드와 직접 통신할 수 있어야 합니다.
- 노드의 에이전트(kubelet 등)는 해당 노드의 모든 파드와 통신할 수 있어야 합니다.
이 규칙을 구현하는 것이 CNI(Container Network Interface) 플러그인입니다. CNI는 파드 네트워크 인터페이스를 만들고 IP를 할당하며, 플러그인에 따라 NetworkPolicy, 암호화, eBPF 관측성 같은 기능을 제공합니다.
| CNI 플러그인 | 특징 | 적합한 사용처 |
|---|---|---|
| Calico | 라우팅/BGP, NetworkPolicy 지원 | 정책 중심 클러스터 |
| Flannel | 단순한 overlay 네트워크 | 소규모, 학습용 |
| Cilium | eBPF 기반 네트워킹, 보안, 관측성 | 보안, 관측 중시 |
| AWS VPC CNI | 파드가 VPC IP를 직접 사용 | EKS, AWS 통합 |
Service는 여러 파드를 하나의 안정적인 이름과 가상 IP(ClusterIP)로 묶습니다. 파드가 생성되고 삭제될 때마다 IP가 바뀌지만, Service의 ClusterIP와 DNS 이름은 유지됩니다. 실제 대상 파드 목록은 EndpointSlice로 추적됩니다.
| Service 타입 | 접근 범위 | 사용 사례 |
|---|---|---|
| ClusterIP | 클러스터 내부만 | 내부 마이크로서비스 |
| NodePort | 노드IP:포트로 외부 접근 | 개발, 테스트 |
| LoadBalancer | 클라우드 LB 자동 생성 | 프로덕션 외부 서비스 |
| ExternalName | DNS CNAME 매핑 | 외부 서비스 참조 |
Ingress는 외부 HTTP/HTTPS 트래픽을 클러스터 내부 서비스로 라우팅하는 규칙입니다. 실제 동작에는 NGINX Ingress Controller, AWS Load Balancer Controller 같은 Ingress Controller가 필요합니다. 최근에는 더 표현력이 높은 Gateway API도 함께 사용됩니다.
결국 VPC의 서브넷, Docker의 브리지 네트워크, Kubernetes의 Service 모두 앞서 배운 네트워크 기본 개념 — IP 주소, 서브넷, NAT, 라우팅, 로드 밸런싱 — 의 가상화된 적용입니다.
다음 장에서는 네트워크 문제를 체계적으로 진단하는 트러블슈팅 방법론과 도구를 다루겠습니다.