네트워킹 101 #6. Subnets, CIDR & NAT

Source: Dev.to

Note: 이 시리즈는 전문가가 작성한 것이 아닙니다 — 초보자가 큰소리로 배우면서 공유합니다:

• 내가 이해한 것,
• 나를 혼란스럽게 하는 것,
• 그리고 그 과정에서 배운 것.
  목표는 일관성, 명확성을 구축하고 토론을 유도하는 것입니다.

📌 이 블로그에서 다루는 내용

이 포스트에서는 다음을 다룹니다:

1. 서브넷이란 무엇인가
2. 퍼블릭 서브넷 vs 프라이빗 서브넷
3. CIDR이란 무엇인가
4. NAT이란 무엇인가
5. 서브넷 관련 문제점

📂 GitHub 저장소

이 시리즈를 위한 모든 노트, 다이어그램 및 학습 자료는 여기에서 확인할 수 있습니다:

[GitHub repo link](add your URL)

저장소는 제가 계속 학습하면서 업데이트됩니다.

📚 학습 노트

1️⃣ First: 왜 서브넷이 존재할까?

Question: 왜 모든 컴퓨터를 하나의 큰 네트워크에 두지 않을까?

Answer:

• 보안에 취약하다
• 혼란스럽다
• 확장성이 없다

따라서 네트워크는 **서브넷(subnet)**이라고 불리는 작은 네트워크들로 분할됩니다.

2️⃣ 서브넷이란?

서브넷은 같은 내부 네트워크에 속하는 IP 주소들의 그룹입니다. 그게 전부입니다.

예시:

10.0.0.0 – 10.0.0.255

이 범위에 포함된 모든 머신은:

• 서로 직접 통신할 수 있다
• 동일한 프라이빗 네트워크에 속한다

3️⃣ 클라우드 제공자가 서브넷 사용을 강제하는 이유

AWS, GCP, Azure 같은 클라우드 플랫폼에서는 **“평면(flat) 네트워크”**를 제공하지 않습니다. 반드시 다음을 생성해야 합니다:

• VPC(Virtual Private Cloud)
• 그 안에 서브넷

왜일까?

• 보안 격리
• 라우팅 제어
• 확장성

그래서 VM을 만들 때 항상 서브넷 선택 화면이 나타납니다.

4️⃣ CIDR(무서운 /24 표기) 이란?

CIDR은 겉보기엔 무섭지만 사실 간단합니다.

예시:

10.0.0.0/24

CIDR은 이 네트워크에 포함된 IP 개수를 알려줍니다.

4.1 수학 없이 CIDR (약속)

• / 뒤의 숫자가 작을수록 → 네트워크가 크다
• / 뒤의 숫자가 클수록 → 네트워크가 작다

DevOps 입문자에게는 이 정도면 충분합니다.

4.2 /24가 실제로 의미하는 바

10.0.0.0/24

• 네트워크 시작 주소: 10.0.0.0
• 네트워크 종료 주소: 10.0.0.255
• 전체 ≈ 256 IP (클라우드 제공자는 내부적으로 몇 개를 예약함)

5️⃣ CIDR이 실제 DevOps 작업에 중요한 이유

CIDR은 다음을 결정합니다:

• 몇 대의 서버를 운영할 수 있는가
• 네트워크 격리 수준은 어느 정도인가
• 서비스 간 통신이 가능한가

흔한 실수: 너무 작은 서브넷을 선택 → IP가 부족해진다.

6️⃣ 퍼블릭 서브넷 vs 프라이빗 서브넷

6.1 퍼블릭 서브넷

• 인터넷으로 가는 라우트가 존재한다
• 사용처:
  • 로드 밸런서
  • 베스천 호스트
  • 외부에 노출되는 서비스

6.2 프라이빗 서브넷

• 인터넷 직접 접근이 없음
• 사용처:
  • 애플리케이션 서버
  • 데이터베이스
  • 내부 서비스

베스트 프랙티스: 공개가 반드시 필요한 것만 외부에 노출한다.

7️⃣ 프라이빗 서브넷은 어떻게 인터넷에 접근할까?

여기서 NAT(Network Address Translation)가 등장합니다.

7.1 NAT란?

NAT는 프라이빗 IP → 인터넷 은 가능하게 하면서 인터넷 → 프라이빗 IP 접근은 차단합니다.
기본적으로 단방향입니다.

7.2 NAT를 간단히 설명하면

• 프라이빗 서버: 10.0.1.5
• 접근하고 싶은 대상: google.com

흐름:

10.0.1.5 → NAT Gateway → Internet

인터넷에서는 요청이 NAT 게이트웨이의 공인 IP에서 온 것으로 보이며, 응답은 NAT를 통해 다시 프라이빗 서버로 돌아갑니다.

8️⃣ 보안에 있어 NAT가 중요한 이유

• NAT 없을 경우: 모든 프라이빗 서버가 공인 IP를 가져야 하므로 모두 노출된다.
• NAT 있을 경우: 서버는 프라이빗 상태를 유지하고, 아웃바운드 트래픽만 허용된다.

그래서 데이터베이스는 거의 항상 프라이빗 서브넷에 배치됩니다.

9️⃣ 일반적인 DevOps 아키텍처

Internet
   ↓
Load Balancer (Public Subnet)
   ↓
App Servers (Private Subnet)
   ↓
Database (Private Subnet)

• NAT가 가능하게 하는 것:
  • App → Internet (업데이트, 외부 API)
  • Database → 인터넷 접근 없음

🔟 서브넷 문제는 실제로 어떻게 나타날까?

대부분의 “네트워크 문제”는 서브넷 혹은 NAT 설정 오류에서 비롯됩니다.

1️⃣1️⃣ 간단한 손‑머리 연습

스스로에게 물어보세요:

• 이 서비스는 퍼블릭인가, 프라이빗인가?
• 인바운드 접근이 필요한가?
• 아웃바운드 인터넷 접근이 필요한가?

이 답변이 결정합니다:

• 서브넷 종류
• NAT 필요 여부
• 보안 규칙

1️⃣2️⃣ 머리 속으로 떠올리는 설계 연습 (계속)

odel upgrade

Your networking stack now looks like:

Internet
   ↓
Public Subnet
   ↓
Private Subnet
   ↓
Service

Subnets decide who can talk to whom.

✅ 핵심 요점

• Subnets은 IP를 그룹화합니다.
• CIDR은 서브넷 크기를 제어합니다.
• Public subnets은 인터넷에 노출됩니다.
• Private subnets은 숨겨진 상태를 유지합니다.
• NAT는 안전한 아웃바운드 접근을 허용합니다.
• 대부분의 클라우드 네트워킹 문제는 서브넷과 관련됩니다.

💬 피드백 및 토론

💡 피드백을 기다리고 있어요!
다음과 같은 점을 발견하면:

• 누락된 도구 카테고리,
• 잘못된 가정,
• 더 나은 학습 경로,

아래에 댓글을 남겨 주세요. 배우고 있습니다.

⭐ 학습 여정을 지원해 주세요

If you found this blog useful:

⭐ GitHub 저장소에 별표를 달아 주세요 — 이는 제가 계속 학습하고 공개적으로 공유하도록 큰 동기가 됩니다.

🐦 최신 소식 받기

Follow me on [Twitter/X] (add your handle) for updates on future posts in this series.

# 📚 Networking for DevOps – 101

👋 소개

저는 Twitter/X에서 학습 여정을 공유하는 DevOps Engineer입니다. 정기적으로 업데이트, 노트, 진행 상황을 게시합니다.

---

🔜 What’s Next

다음 포스트에서는 다음 내용을 다룰 예정입니다:

• Firewalls, Security Groups & “Connection Refused”가 발생하는 이유
• 진행 상황에 따라 GitHub 저장소 지속 업데이트

---

📘 공개 학습

• Repo:
• Twitter/X:

💬 피드백 환영 — 뭔가 이상하면 댓글 달아 주세요.
⭐ 유용하면 레포에 별을 주세요.