소프트웨어 엔지니어가 꼭 알아야 할 Networking 핵심 개념 (Single Server에서 Kubernetes까지, TravelBody 성장 스토리로 끝내기)

Networking을 처음 마주하면 머리가 복잡해지기 쉽습니다. IP address, DNS, ports, subnets, routing, firewall, NAT, VPC, gateways, Docker networking, Kubernetes… 용어만 잔뜩 나오니까요.

그래서 많은 사람이 “일단 외워야 하나?”라고 생각합니다. 그런데 현실에서는 외우기보다 필요해지는 순간에 이해하는 방식이 훨씬 잘 붙습니다.

이 글은 그 방식으로 갑니다.

하나의 가상 서비스가 작은 서버 1대에서 시작해, 점점 커지면서 cloud, containers, Kubernetes로 발전해 가는 과정을 그대로 따라가 볼 거예요. 시스템이 커질 때마다 “새로운 Networking 문제”가 등장하고, 그 순간에 정확히 필요한 개념만 딱 배웁니다.

우리 주인공은 TravelBody입니다.

TravelBody는 여행 예약 웹사이트라고 상상해 주세요. “왜 이런 Networking 구성요소가 생겼는지”, “무슨 문제를 해결하려고 만들어졌는지”를 이야기처럼 풀어가겠습니다.

 

왜 소프트웨어 엔지니어에게 Networking이 중요할까

 

---

왜 소프트웨어 엔지니어에게 Networking이 중요할까

개발은 코드로 끝나지 않습니다. 서비스는 항상 “연결”로 살아 움직여요.

브라우저와 통신하고, API를 호출하고, database에 붙고, payment provider와 연결하고, containers끼리 대화하고, 서버 간 트래픽도 오갑니다.

장애가 났을 때도 마찬가지입니다.

문제가 꼭 코드에만 있는 건 아니거든요. 요청이 어디선가 막혔거나, 잘못된 경로로 빠졌거나, 접근이 차단됐거나, 서비스가 서로를 못 찾는 경우가 생각보다 흔합니다.

그런데 다행인 점이 하나 있습니다.

Networking은 끝없는 암기가 아니라, 몇 가지 기초 개념만 제대로 잡으면 나머지가 줄줄이 이해됩니다.

그럼 TravelBody와 함께 시작해 봅시다.

 

 

---

Chapter 1. Single Server에서 시작하기 (IP address, DNS)

1) 첫 출시: 서버 1대, 끝

TravelBody 초창기에는 서버 한 대에 전부 올렸습니다. 단순하죠.

그런데 서비스 오픈하자마자 바로 질문이 튀어나옵니다.

“사용자는 이 서버를 어떻게 찾아오지?”

 

2) IP address: 네트워크 세계의 ‘주소’

네트워크에 연결된 모든 장치는 식별자가 필요합니다. 그래야 다른 장치가 데이터를 보낼 수 있죠.

그 식별자가 바로 IP address입니다.

집 주소가 있어야 택배가 오듯, IP address가 있어야 요청이 도착합니다.

그래서 TravelBody 서버에는 public IP address를 붙였습니다. 예를 들면:

• 203.0.113.10

이 숫자 하나만 알면, 인터넷 어디서든 이 서버로 요청을 보낼 수 있습니다.

 

3) DNS: 숫자 대신 이름으로 접속하게 해주는 장치

하지만 여기서 현실적인 문제가 하나 더 생기죠.

누가 203.0.113.10 같은 숫자를 외우고 다닐까요? 거의 아무도 안 합니다.

그래서 등장하는 게 DNS입니다.

DNS는 사람이 기억하기 쉬운 도메인 이름을 IP address로 바꿔 줍니다.

사용자가 브라우저에:

• travelbody.com

을 입력하면 DNS가 뒤에서 IP address를 찾아 연결을 만들어 줍니다.

비유를 하나 들어볼게요.

• 휴대폰에서 전화할 때, 숫자 전체를 치지 않죠.
• “엄마”라고 저장된 이름을 누르면 전화가 걸립니다.

DNS도 비슷합니다. 이름은 사람이 쓰고, 숫자는 시스템이 처리합니다.

이제 사용자는 TravelBody 서버에 잘 찾아옵니다.

그런데 서비스가 커지면 또 다른 문제가 나타납니다.

 

 

---

Chapter 2. 서버 한 대에 앱이 여러 개라면? (ports)

1) 기능이 늘어나면서 한 서버에 세 가지가 들어감

TravelBody는 곧 서버 한 대에 이런 구성으로 돌아가게 됩니다.

1. 사용자가 보는 website
2. 예약 정보를 저장하는 database
3. 결제를 처리하는 payment processing service

모두 같은 IP address를 씁니다.

그럼 새로운 질문이 생기죠.

“요청이 서버에 도착했는데, 어느 application으로 보내야 하지?”

 

2) ports: 같은 IP address 안에서 ‘문’을 구분하는 번호

이때 해결책이 ports입니다.

ports는 서버 안에서 트래픽이 들어오는 “채널 번호”라고 생각해도 좋습니다. 범위는 1부터 65,535까지.

각 application은 서로 다른 port를 열고 기다립니다.

TravelBody의 예시는 이렇게 잡을 수 있습니다.

• website: port 80 (웹 표준)
• secure web: port 443 (보안 웹 표준)
• MySQL database: port 3306
• custom payment service: port 9090

 

사용자가 travelbody.com에 접속하면 브라우저는 보통 port 80 또는 port 443으로 붙습니다. 서버는 목적지 port를 보고 “아, 이건 website로 가야겠네”라고 판단합니다.

비유로 정리하면 이해가 빠릅니다.

• IP address = 건물 주소
• ports = 호수(문 번호)

같은 건물이라도 문이 다르면 다른 공간으로 들어가듯, ports가 트래픽을 분리해 줍니다.

이제 멀티 앱도 깔끔히 운영됩니다.

하지만 성장에는 늘 다음 난관이 따라옵니다.

 

 

---

Chapter 3. 보안과 분리의 시대 (subnets, routing, firewall)

1) 민감 정보가 생기면 구조가 바뀐다

TravelBody는 어느 순간부터 credit card와 personal data를 다루기 시작합니다.

이때 “전부 한 서버에 몰아넣기”는 꽤 위험합니다.

만약 공격자가 그 서버 하나를 뚫으면?

• website도
• database도
• payment service도

한 번에 다 노출될 수 있습니다.

그래서 우리는 분리를 시작합니다.

이걸 network segmentation이라고 부릅니다.

 

2) subnets: 네트워크를 ‘구역’으로 쪼개는 방법

subnets는 네트워크를 섹션으로 나누는 도구입니다.

병원 건물을 떠올려 보세요.

• 산부인과는 한 층
• 수술실은 다른 층
• 중환자실은 또 다른 구역

섞이지 않게 구역을 나누는 이유는 안전과 관리 때문이죠.

네트워크도 똑같습니다.

예를 들면 이렇게 나눌 수 있습니다.

• public-facing front-end servers → subnet A (특정 IP range)
• application servers → subnet 2 (다른 IP range)
• database servers → 또 다른 subnet

이제 영역은 나눴습니다.

그런데 여기서 다음 질문이 생깁니다.

“website가 database와 어떻게 통신하지?”

 

3) routing: 구역과 구역을 연결해 주는 ‘길 찾기’

구역을 나눴으면, 필요한 통신은 이어줘야 합니다.

이때 쓰는 개념이 routing입니다.

routing은 서로 다른 subnets 사이로 트래픽이 갈 수 있게 경로를 잡아 줍니다.

설명은 이렇게 하면 직관적입니다.

• routing은 네트워크 트래픽의 내비게이션 같은 역할을 합니다.
• A에서 B로 갈 때 “어느 길로 갈지” 결정해 줍니다.

이제 website가 database subnet으로 요청을 보낼 수 있습니다.

그런데 또 한 가지가 남습니다.

 

4) firewall: 갈 수 있다고 해서 다 가게 두면 안 된다

routing은 길을 열어 줍니다.

하지만 “길이 열린 것”과 “무조건 통과해도 되는 것”은 완전히 다른 이야기입니다.

구역을 나눠 놓고 모든 문을 활짝 열어두면 분리한 의미가 약해집니다.

그래서 firewall이 필요합니다.

firewall은 규칙에 따라 트래픽을 검사하고 허용 또는 차단합니다. 현실에서는 출입 통제 직원이나 보안 게이트 같은 역할이라고 생각하면 됩니다.

그리고 여기에는 두 레벨이 있습니다.

 

(1) host firewall: 서버 한 대를 지키는 방어선

각 서버 자체를 보호합니다.

예를 들어 database 서버에 규칙을 둡니다.

• port 3306만 허용
• 그리고 front-end subnet의 IP address range에서 오는 요청만 허용
• 나머지는 전부 차단

 

(2) network firewall: subnet 사이 또는 외부-내부 경계에서 필터링

네트워크 구간 중간에 놓고 트래픽을 걸러냅니다.

예를 들어:

• 인터넷 ↔ front-end subnet 사이에 network firewall 배치
• inbound는 port 80과 port 443만 허용
• 나머지 inbound는 전부 block

그래서 front-end subnet에 다른 프로그램이 이상한 port로 열려 있어도, 애초에 외부에서 접근이 막힙니다.

이 ‘겹겹이’ 구성은 실제로 매우 중요합니다.

공격자는:

• network firewall을 통과해야 하고,
• 그 다음 host firewall도 통과해야 하죠.

보안은 한 장으로 끝내기보다, 여러 겹으로 만드는 편이 훨씬 강합니다.

이제 TravelBody는 꽤 그럴듯한 네트워크 보안 구역을 가졌습니다.

그런데, 성장 속도가 빨라지면 또 다른 문제가 튀어나옵니다.

 

 

---

Chapter 4. private IP address의 딜레마 (NAT)

1) 백엔드 서버가 50대가 됨

TravelBody는 어느새 backend server가 수십 대로 늘었습니다. 예를 들어 50대라고 해 봅시다.

보안을 위해 이 서버들은 private subnet 안에 넣었습니다.

IP address는 이런 식입니다.

• 10.0.25
• 10.0.26
• 10.0.27
• …

private IP address는 내부 통신에는 좋습니다.

하지만 인터넷에서 직접 접근할 수는 없습니다.

회사로 치면 이런 느낌이에요.

• 사내 extension number는 회사 안에서는 잘 걸립니다.
• 그런데 집에서 그 extension number로 바로 전화는 못 하죠.

이게 보안적으로는 장점입니다.

그런데 운영을 하다 보면 이런 일이 생깁니다.

 

2) 백엔드도 인터넷이 필요하다

backend 서버가 외부로 나가야 할 일이 꽤 많습니다.

• software update 다운로드
• external payment API 연결
• third-party service로 데이터 전송

그렇다고 서버마다 public IP address를 붙이면?

• 비용이 올라가고
• 관리가 복잡해지고
• 50개나 운영해야 하니 번거롭습니다.

그래서 등장하는 해결책이 NAT (Network Address Translation) 입니다.

 

3) NAT: 내부는 숨기고, 외부 연결은 가능하게

NAT의 핵심은 이겁니다.

• 여러 private IP address 장치가
• 하나의 public IP address를 공유해서
• 인터넷으로 나갈 수 있게 해 준다

동작 흐름을 TravelBody 예시로 보면 이렇게 됩니다.

1. backend server 10.0.25가 외부 사이트에 요청을 보냄
2. 요청은 NAT device로 향함
3. NAT device가 source IP를 자기 public IP address로 바꿔서 인터넷으로 전송
4. 응답이 돌아오면 NAT device가 “이건 10.0.25가 요청했지”라고 기억하고 내부로 전달

비유를 하자면:

• NAT는 회사의 ‘대표번호’를 관리하는 안내 담당자 같은 역할입니다.
• 직원이 밖으로 전화할 때는 회사 대표번호로 나가고,
• 응답은 다시 해당 직원에게 연결됩니다.

이제 backend 서버들은 외부로 나갈 수 있지만, 외부에서 직접 들어오기는 어렵습니다.

즉, “안전하면서도 실용적인 구조”가 됩니다.

여기까지 오면 기반은 탄탄합니다.

하지만 또 다른 현실 문제가 있죠.

서버를 직접 운영하는 게 너무 힘듭니다.

 

 

---

Chapter 5. Cloud Networking으로 옮기기 (VPC, subnets, gateways, route tables, NAT gateway)

1) 물리 서버 운영의 피로

물리 서버를 계속 들고 가면 이런 일들이 쌓입니다.

• 한 달 뒤 트래픽을 예측해야 함
• 서버를 구매해야 함
• 설치하고 세팅해야 함
• 고장 나면 유지보수해야 함

특히 용량이 더 필요해질 때 “몇 주”가 걸리는 경우도 생깁니다.

그래서 TravelBody는 cloud로 이동합니다.

 

2) cloud의 장점: 빌려 쓰고, 빠르게 늘리고 줄이기

cloud는 하드웨어를 내가 소유하는 게 아니라 빌리는 방식입니다.

cloud provider가 물리 장비 관리를 맡고, 우리는 필요할 때 capacity를 “분 단위”로 늘리고 줄일 수 있습니다.

 

3) 중요한 포인트: 개념은 그대로다

이 부분이 특히 중요합니다.

cloud로 간다고 해서 IP address가 사라지지 않습니다.

ports도 필요하고,
subnets도 필요하고,
routing도 있고,
firewall도 있고,
NAT도 여전히 등장합니다.

단지 cloud가 이런 것들을 managed service로 제공할 뿐입니다.

 

4) VPC: cloud 안에 내 전용 네트워크 구역 만들기

cloud에서는 보통 VPC (Virtual Private Cloud) 를 만듭니다.

VPC는 cloud provider 네트워크 안에서, 내가 사용하는 “격리된 공간”입니다.

감으로 이해하면 이런 느낌이에요.

• 큰 빌딩 안에 여러 회사가 들어가 있지만,
• 우리는 특정 층(혹은 구역)을 임대하고,
• 그 구역은 우리만 씁니다.
• 같은 건물에 있어도 함부로 들어올 수 없습니다.

 

5) VPC 안에서도 subnets는 계속 필요함

VPC 안에는 subnets를 구성합니다.

• 인터넷에 노출되는 시스템은 public subnets
• 보호해야 할 시스템은 private subnets

이 구조 자체는 온프레미스에서도 익숙했던 그림입니다.

 

6) internet gateway: public subnets의 ‘출입구’

public subnets가 인터넷과 통신하려면 internet gateway가 필요합니다.

말 그대로 “메인 입구” 같은 역할입니다.

 

7) route tables: 트래픽의 표지판

트래픽이 어디로 갈지 알려주는 게 route tables입니다.

각 subnet은 route table을 가지고 있고, 패킷이 어떤 경로로 이동할지 규칙을 담습니다.

 

8) NAT gateway: cloud에서 제공하는 NAT

private subnets에서 외부로 나가려면 NAT가 필요하다고 했죠.

cloud에서는 이것을 보통 NAT gateway 형태로 제공합니다.

일반적인 배치 방식은 이렇습니다.

• NAT gateway를 public subnet에 두고
• private subnets의 outbound 트래픽이 NAT gateway를 타고 나가게 routing 설정

결과적으로, 온프레미스에서 만들었던 “안전한 구조”를 cloud에서도 그대로 구현할 수 있습니다.

자, 이제 인프라는 cloud스러워졌습니다.

하지만 앱 구조가 또 바뀝니다.

 

 

---

(중간 이야기) Infrastructure as Code와 Pulumi

여기까지 보면 이런 생각이 듭니다.

“VPC, subnets, security groups 같은 걸… 이걸 다 어떻게 정의하고 관리하지?”

바로 여기서 Infrastructure as Code가 중요한 이유가 나옵니다.

이 구간에서 소개된 도구가 Pulumi입니다.

Pulumi의 포인트는 “내가 이미 쓰는 프로그래밍 언어”로 인프라를 정의할 수 있다는 점입니다.

예를 들면:

• TypeScript
• Python
• Go
• Java

같은 언어로 인프라 코드를 작성할 수 있습니다.

이 방식이 주는 장점은 꽤 큽니다.

• 익숙한 IDE 사용
• error checking
• autocomplete
• refactoring
• debugging

같은 개발 경험을 그대로 가져갈 수 있거든요.

그리고 Pulumi는 최근 Pulumi Neo라는 agentic AI도 출시했다고 소개됩니다.

설명에 따르면 Neo는:

• 인프라 구성을 전체적으로 이해하고
• 조직 정책을 존중하며
• 복잡한 작업을 end-to-end로 처리하고
• 자연어로 요구를 말하면 code를 생성하고
• pull request를 review하고
• deployment 디버깅도 돕는다

Pulumi는 open source라서 무료로 시작할 수 있고,
enterprise 기능을 시험해 보고 싶다면 NA 500 코드를 사용하면 $500 크레딧을 받을 수 있다고 합니다.

이제 다시 TravelBody의 성장 단계로 돌아가 볼게요.

 

 

---

Chapter 6. Container Networking (Docker bridge network, port mapping, overlay network)

1) microservices로 가면 배포가 더 복잡해진다

서비스가 커지면 기능이 쪼개집니다.

• 서비스가 늘고
• dependency가 늘고
• 설치와 설정이 복잡해지고

그리고 microservices로 전환하면 “배포 단위”가 더 많아집니다.

이때 정말 자주 나오는 말이 있죠.

“내 노트북에서는 되는데, 운영에서는 안 돼요.”

이건 팀을 지치게 합니다. 속도도 떨어지고, 장애 대응도 더 빡빡해져요.

 

2) containers: 실행 환경을 통째로 묶어서 들고 다니기

그래서 containers를 씁니다.

container는 application에 필요한 요소를 한 덩어리로 묶습니다.

• code
• runtime
• libraries
• settings

결과적으로 어디서 실행해도 비슷하게 동작합니다.

비유를 바꾸어 말하면 이렇습니다.

• container는 “준비물 다 들어있는 이동형 운영 키트” 같은 느낌

반대로 전통적인 설치 방식은 “현장에 가서 하나하나 세팅해야 하는 방식”에 가깝습니다.

TravelBody는 Docker로 서비스를 containerize합니다.

그래서 같은 container를:

• 개발자 노트북
• 테스트 서버
• 운영 서버

어디서든 거의 동일하게 실행할 수 있게 됩니다.

그런데 containers를 쓰면 Networking도 새로 이해해야 합니다.

 

3) Docker bridge network: 한 서버 안에서 containers끼리 통신

Docker는 기본적으로 bridge network를 만듭니다.

이건 그 서버 안에서만 존재하는 private network입니다.

같은 bridge network에 붙은 containers는 서로 통신할 수 있고, container name으로도 서로를 찾을 수 있습니다.

단일 호스트에서의 서비스 간 통신이 훨씬 편해집니다.

 

4) port mapping: container 내부 port를 host로 노출하기

containers는 내부적으로 또 다른 네트워크를 가집니다.

예를 들어 payment service container가 내부에서 port 9090으로 대기한다고 해 봅시다.

외부 요청이 그 port로 바로 들어가지는 않습니다.

그래서 port mapping이 필요합니다.

Docker의 docker run 옵션으로:

• host의 특정 port로 들어온 트래픽을
• container 내부의 port로 전달하도록 설정합니다.

소개된 예시 흐름은 이런 느낌입니다.

• host의 port 1990으로 들어온 요청을
• payment container의 port 1990으로 포워딩

핵심은 “두 네트워크를 이어주는 변환”이라는 점입니다.

이 감각이 NAT와도 닮아 있습니다.

 

5) overlay network: 여러 서버에 있는 containers를 같은 네트워크처럼

규모가 더 커지면 한 서버로는 부족합니다.

containers를 여러 서버에 걸쳐 실행하게 되죠.

그러면 microservices끼리 “서버를 넘어” 통신해야 합니다.

이때 Docker의 overlay network가 도움을 줍니다.

overlay network는 여러 호스트에 걸친 가상 네트워크를 만들고, 서로 다른 서버의 containers가 마치 한 네트워크에 있는 것처럼 통신하도록 해 줍니다.

하지만 여기서 더 큰 문제가 등장합니다.

containers가 수백 개가 되면, 사람이 직접 운영하기가 너무 어렵습니다.

그래서 Kubernetes로 넘어갑니다.

 

 

---

Chapter 7. Kubernetes Networking (pods, Services, DNS, Ingress)

1) 컨테이너가 너무 많아지면 ‘관리’가 본게임

TravelBody는 성공했습니다.

이제 수백 개의 containers가 수십 대 서버에서 돌아갑니다.

이 단계에서는 질문이 폭발합니다.

• 새 container는 어느 서버에 띄우지?
• container가 죽으면 어떻게 복구하지?
• 장애가 나면 어디부터 추적하지?
• 죽은 줄도 모르고 지나가면 어떡하지?
• containers가 계속 이동하는데 서로를 어떻게 찾지?

이때 등장하는 것이 Kubernetes입니다.

 

2) Kubernetes: 컨테이너 운영을 자동화하는 관리자

Kubernetes는 container 관리 자동화 플랫폼입니다.

이미지로 떠올리면:

• 아파트 단지를 운영하는 자동화 관리자
• 입주(배치)도 정하고
• 고장(크래시) 나면 수리(재생성)하고
• 단지 전체가 안정적으로 돌아가게 관리합니다.

 

3) pods: Kubernetes의 기본 단위

Kubernetes에서 기본 단위는 pod입니다.

pod는 하나 이상의 containers 묶음입니다.

대부분의 경우 1 pod = 1 container로 운영되기도 합니다.

각 pod는 자기 IP address를 가집니다.

비유하자면:

• pod는 한 세대(한 집)
• 그 집 주소(IP address)를 공유하면서 내부 구성원이 같이 움직이는 느낌

 

4) 문제: pods는 ephemeral이고 IP address가 바뀐다

Kubernetes의 pod는 영원하지 않습니다.

업데이트를 하거나,
pod가 죽거나,
노드가 바뀌거나,
스케일링이 일어나면,

Kubernetes는 pod를 없애고 새로 만들 수 있습니다.

그리고 새 pod는 새로운 IP address를 받을 수 있습니다.

만약 website pod가 database pod의 IP address를 직접 찍고 붙어 있었다면,

database pod가 재생성되는 순간 연결이 끊길 수 있습니다.

그래서 Kubernetes에서는 pod IP address를 안정적인 식별자로 믿으면 위험합니다.

 

5) Services: 변하는 pods 앞에 고정된 ‘대표 주소’ 만들기

이 문제를 해결하는 것이 Kubernetes Services입니다.

Service는:

• stable IP address
• stable DNS name

을 제공합니다.

뒤에 있는 pods는 바뀌어도, Service는 그대로 남습니다.

그래서 database pods 앞에 Service를 하나 둡니다.

예시처럼:

• database-service

같은 DNS name을 만들 수 있습니다.

이제 website pod는 database pod에 직접 붙지 않고, database-service로 연결합니다.

Service는 내부에서 건강한 pod로 트래픽을 전달합니다.

pod 하나가 죽고 새로 생겨도,
website pod는 “아무 일도 없었던 것처럼” 계속 연결을 유지할 수 있습니다.

비유하면 이렇습니다.

• 회사에 “영업팀 대표번호”가 있고
• 담당자는 바뀌어도
• 대표번호는 계속 유지되는 느낌

Kubernetes에서 이 안정성은 정말 중요합니다.

 

6) Ingress: 외부 트래픽을 클러스터 내부로 안내하는 관문

이제 외부 사용자가 TravelBody를 이용하려면, 인터넷에서 Kubernetes cluster 안으로 들어와야 합니다.

그런데 cluster 안에는 여러 Services가 있습니다.

외부 요청을 상황에 맞게 내부 서비스로 보내는 역할이 필요합니다.

이때 쓰는 것이 Ingress입니다.

Ingress는 “접수/안내 데스크”처럼 동작합니다.

요청의 host나 path 규칙에 따라 올바른 Service로 라우팅합니다.

예시 규칙은 이런 식으로 구성할 수 있습니다.

• travelbuddy.com으로 들어오는 요청 → website service
• travel.com/api/booking으로 들어오는 요청 → booking service
• payment 관련 URL 요청 → payment service

Ingress 덕분에 외부 트래픽 진입점을 한 곳으로 정리하면서도, 내부 서비스로는 똑똑하게 분배할 수 있습니다.

 

 

---

Recap: 결국 끝까지 따라오는 5가지 Networking 기초

TravelBody의 성장 과정을 따라오면서, 우리는 중요한 사실 하나를 확인했습니다.

환경이 바뀌어도 핵심 개념은 거의 변하지 않는다.

physical servers든,
cloud든,
Docker든,
Kubernetes든,

본질은 같습니다.

여기서 다시 핵심 5가지를 정리해 봅시다.

1) IP address

네트워크에서 통신하려면 각 장치는 고유한 주소(IP address)가 필요합니다.

2) DNS

사람이 쓰는 이름을 IP address로 바꿔주는 시스템이 DNS입니다.

3) ports

하나의 서버(IP address) 안에서 여러 application이 공존할 때, 트래픽을 구분하는 ‘번호’가 ports입니다.

4) subnets + routing

subnets로 네트워크를 구역화하고,
routing으로 필요한 통신 경로를 연결합니다.

5) firewall + NAT

firewall은 허용할 트래픽만 통과시키는 통제 장치이고,
NAT는 private IP address를 가진 시스템이 외부로 나갈 수 있게 돕는 방식입니다.

 

도구는 바뀌지만 원리는 유지된다

우리는 physical router에서 VPC로 옮겼고,
physical firewall에서 security groups 같은 개념으로 이동했지만,

결국 “왜 필요한지”는 같았습니다.

이 기초를 잡아두면, 어떤 규모의 시스템이든 이해가 빨라집니다.

장애 상황에서도 덜 흔들리고,
설계 토론에서도 더 정확해지고,
서비스 확장도 더 자신감 있게 할 수 있습니다.

 

---

마지막으로, 작은 제안 하나

혹시 이 글이 도움이 됐다면, 팀에서 한 사람에게만 공유해 주세요.

Networking은 개인기처럼 보이지만, 사실은 팀 전체가 같은 언어로 말할 때 힘이 생깁니다.

다 같이 기본기를 공유하면:

• 장애 대응이 덜 공포스럽고
• 의사소통이 더 빠르고
• 설계가 더 안전해집니다.

읽어주셔서 감사합니다.

TravelBody의 성장 스토리는, 여러분 서비스가 커질 때마다 어떤 Networking 문제가 먼저 튀어나올지 예측하는 체크리스트로도 쓸 수 있을 거예요.

그리고 그게 바로 “기초를 이해하는 가치”입니다.