cheoran

사내 인프라 구축기: 서버 2대로 HA 환경 만들기

Thu, 19 Mar 2026 00:00:00 GMT

회사에서 사내 서비스 인프라를 처음부터 구축할 기회가 생겼다. ARM64 Ubuntu 서버 2대 위에 여러 서비스를 올리고, 외부에서 접근 가능하게 만들고, 배포와 모니터링까지 갖춰야 했다. DB 서버와 파일 서버(NFS)는 다른 분이 담당했고, 그 외 나머지를 내가 맡았다.

전체 구조

Cloudflare Edge (SSL 종단)
    ↓
Cloudflare Tunnel (HA 로드밸런싱)
    ↓
    ├→ Server A (192.168.0.31)
    └→ Server B (192.168.0.32)
       ↓
    Nginx (리버스 프록시)
       ↓
    ├→ 서비스 A Prod  (Backend + Frontend)
    ├→ 서비스 A Dev   (Backend + Frontend)
    └→ 서비스 B Dev   (Backend)
       ↓
    PostgreSQL (외부) + NFS (외부)

서버 2대에 같은 구성을 올리고, Cloudflare Tunnel이 트래픽을 자동 분산하는 Active-Active 구조다. 한쪽 서버가 죽어도 나머지가 받아준다.

Cloudflare Tunnel로 외부 접근 열기

사내 서버를 외부에 노출하는 방법으로 Cloudflare Tunnel을 선택했다. 보통은 포트 포워딩을 떠올리겠지만, 이 환경에서는 맞지 않았다.

포트 포워딩은 서버 IP가 외부에 노출되고, 라우터 설정에 의존하게 된다. 서버가 2대라 HA를 걸려면 앞단에 로드밸런서를 따로 둬야 하는데, 그러면 그게 또 SPOF가 된다. Cloudflare Tunnel은 서버가 먼저 Cloudflare에 아웃바운드 연결을 맺는 방식이라 인바운드 포트를 열 필요가 없다. 서버 IP를 완전히 숨길 수 있다.

결정적으로 좋았던 건 HA가 거저 따라온다는 점이다. 서버 A와 B에 같은 터널 토큰으로 cloudflared를 띄우면 Cloudflare가 알아서 분산하고, 한쪽이 죽으면 3분 내에 페일오버한다.

cloudflared:
  image: cloudflare/cloudflared:latest
  command: tunnel --no-autoupdate run --token ${CLOUDFLARE_TUNNEL_TOKEN}
  restart: unless-stopped

SSL 인증서도 Cloudflare 엣지에서 자동 발급/갱신해주니 서버에서 따로 관리할 게 없다.

리버스 프록시는 Nginx

SSL을 Cloudflare가 처리해주니까 리버스 프록시에서는 인증서 관리가 필요 없다. 이 시점에서 Traefik이나 Caddy의 자동 HTTPS라는 큰 장점이 의미가 없어진다. 그래서 가장 가볍고 검증된 Nginx를 골랐다.

Alpine 이미지 기반으로 128MB만 잡아도 충분하다. 서비스가 5개 안팎이라 Docker 라벨로 자동 감지하는 Traefik의 편의 기능이 딱히 필요하지도 않았고, 오히려 설정 파일이 눈에 보이는 게 디버깅할 때 편하다.

호스트 이름으로 라우팅하고, Docker 내부 DNS로 컨테이너 이름을 바로 쓴다:

server {
    listen 80;
    server_name service-a.example.com;

    location /api/ {
        proxy_pass http://service-a-backend:3001;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;

        # WebSocket
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }

    location / {
        proxy_pass http://service-a-frontend:3000;
    }
}

보안 헤더(X-Content-Type-Options, X-Frame-Options 등)는 글로벌 설정으로 한 번에 넣었다.

Docker Compose로 충분한 규모

서버 2대에 서비스 5개 — 이 규모에 Kubernetes를 올리면 컨트롤 플레인(etcd, API 서버, 스케줄러)이 잡아먹는 리소스가 실제 서비스보다 클 수 있다. 16GB ARM64 서버에서 그건 좀 아깝다.

Docker Compose면 YAML 하나로 서비스 정의, 리소스 제한, 헬스체크, 로그 로테이션까지 다 된다. 롤링 업데이트를 자체 지원하지 않는 건 사실인데, 배포 스크립트로 충분히 커버된다.

service-a-backend:
  image: service-a-backend:latest
  restart: unless-stopped
  deploy:
    resources:
      limits:
        cpus: "1.0"
        memory: 1G
  healthcheck:
    test: ["CMD", "curl", "-f", "http://localhost:3001/api/health"]
    interval: 30s
    timeout: 10s
    retries: 3
  logging:
    driver: json-file
    options:
      max-size: "10m"
      max-file: "3"

Compose 파일은 프로젝트별로 분리했다. 공유 인프라(Tunnel + Nginx), 서비스 A, 서비스 B — 세 스택이 독립적으로 관리된다. 서비스 A를 재배포해도 서비스 B에 영향이 없고, Nginx 설정을 바꿔도 앱 컨테이너를 재시작할 필요가 없다. infra-network라는 공유 Docker 네트워크로 연결만 해두면 서로 통신은 되지만 라이프사이클은 완전히 분리된다.

/opt/
├── shared/       # Tunnel + Nginx
├── service-a/    # 서비스 A (Backend + Frontend) × 2환경
└── service-b/    # 서비스 B (Backend)

배포: Self-hosted Runner + 순차 롤링

GitHub Actions Self-hosted Runner를 서버 A, B 각각에 systemd 서비스로 설치했다. GitHub으로 코드를 관리하고 있으니 CI/CD도 GitHub Actions가 자연스러운데, Private 레포에서 GitHub-hosted runner를 쓰면 분당 과금이 발생한다. 그리고 ARM64 네이티브 빌드가 안 된다 — GitHub-hosted runner는 x86이라 QEMU 에뮬레이션을 써야 하는데, 빌드 시간이 몇 배로 느려진다.

Self-hosted runner는 서버에 바로 설치하니 추가 비용이 0이고, ARM64 네이티브로 빌드하니 Docker 레이어 캐시도 완벽히 활용된다.

배포 전략은 단순하다:

Server A 배포 → 헬스체크 → 통과하면 Server B 배포
                            실패하면 A만 롤백, B는 안 건드림

배포 전에 현재 이미지를 :rollback 태그로 보존해두고, 헬스체크가 3회 연속 실패하면 자동 롤백한다. 서버 A가 실패하면 B는 배포 자체를 안 하기 때문에 최소 한 대는 항상 살아있다.

모니터링은 쉘 스크립트로

Prometheus + Grafana가 정석이긴 한데, 그것 자체가 하나의 인프라다.

대신 watchdog.sh라는 100줄짜리 쉘 스크립트를 만들어서 cron으로 5분마다 돌린다. 하는 일은 간단하다:

컨테이너 죽었으면 자동 재시작
Tunnel 연결 끊겼으면 Slack 알림
디스크 90%, 메모리 85% 넘으면 알림
쌓인 댕글링 이미지 자동 정리

핵심은 알려주기만 하는 게 아니라 직접 복구한다는 점이다. 새벽에 컨테이너가 죽었을 때 Prometheus는 "죽었습니다"라고 알려주지만, watchdog.sh는 알아서 재시작하고 "재시작했습니다"라고 알려준다. 이 차이가 운영 부담에서 크다.

알림은 문제가 있을 때만 보낸다. 정상 동작 중에 Slack이 울리면 그냥 노이즈다.

보안

별도 보안 제품 없이 레이어별로 기본기를 챙겼다.

네트워크: Cloudflare가 서버 IP를 가리고, UFW로 80/443 외에는 전부 닫고, fail2ban으로 SSH 무차별 대입을 막는다.

컨테이너: 전부 non-root(node/appuser)로 실행하고, 루트 파일시스템은 read-only로 마운트한다. 업로드 경로만 tmpfs로 쓰기를 허용했다. CPU/메모리 상한을 걸어서 하나가 폭주해도 서버 전체를 잡아먹지 못하게 한다.

마치며

돌이켜보면 모든 선택의 기준은 하나였다 — 지금 규모에 맞는가?

서버 2대, 서비스 5개인 환경에 K8s를 올리면 인프라 관리가 본업이 된다. 대신 Docker Compose + Cloudflare Tunnel + 쉘 스크립트 조합으로 HA, 자동 배포, 모니터링, 자동 복구를 다 갖췄다.

클라우드부터 IaaS, PaaS, SaaS까지 한 번에 이해하기

Wed, 11 Feb 2026 00:00:00 GMT

:::note[섹션 개요]

클라우드가 무엇인지 짧고 명확하게 이해한다.
IaaS, PaaS, SaaS의 차이를 책임 범위 중심으로 구분한다.
실제 상황에서 어떤 모델을 고를지 기준을 잡는다. :::

먼저, 클라우드가 뭔가?

클라우드는 서버, 스토리지, 네트워크, 소프트웨어 같은 IT 자원을 필요할 때 인터넷으로 빌려 쓰는 방식이다.

예전처럼 장비를 직접 구매하고 설치하지 않아도 된다. 대신 필요한 만큼 빠르게 만들고, 쓰는 만큼 비용을 낸다.

클라우드를 이해할 때 핵심은 3가지다.

온디맨드(On-demand): 필요할 때 바로 생성/삭제 가능
탄력성(Elasticity): 트래픽 증가에 따라 쉽게 확장 가능
사용량 기반 과금(Pay-as-you-go): 초기 투자 대신 운영비 중심

IaaS, PaaS, SaaS를 나누는 기준

<strong>누가 어디까지 관리하느냐(관리 책임 분담)</strong>에 있다.

그림 1. IaaS/PaaS/SaaS는 기능 차이보다 책임 범위 차이다.

IaaS (Infrastructure as a Service)

IaaS는 인프라(가상 서버, 네트워크, 디스크)를 서비스로 제공한다. 운영체제부터 애플리케이션까지는 사용자가 더 많이 책임진다.

제공자: 물리 서버, 가상화, 스토리지/네트워크 기반
사용자: OS 설정, 미들웨어, 런타임, 앱 배포/운영

이럴 때 적합하다

OS 레벨 제어가 필요할 때
커스텀 네트워크/보안 구성이 중요할 때
레거시 시스템 이전(리프트 앤 시프트)할 때

PaaS (Platform as a Service)

PaaS는 애플리케이션 실행 플랫폼까지 제공한다. 사용자는 주로 코드와 데이터에 집중하면 된다.

제공자: 인프라 + OS + 런타임 + 배포 환경
사용자: 애플리케이션 코드, 비즈니스 로직, 데이터

이럴 때 적합하다

빠른 개발/배포가 필요할 때
인프라 운영 인력이 적을 때
MVP나 내부 서비스처럼 출시 속도가 중요할 때

SaaS (Software as a Service)

SaaS는 완성된 소프트웨어를 구독형으로 쓰는 형태다. 사용자는 계정/권한/업무 설정 중심으로 관리한다.

제공자: 앱 전체(인프라부터 기능 업데이트까지)
사용자: 사용 정책, 데이터 입력, 운영 프로세스

이럴 때 적합하다

협업 도구, 메일, CRM처럼 공통 업무를 빠르게 도입할 때
구축보다 즉시 사용이 중요할 때

한눈 비교표

항목	IaaS	PaaS	SaaS
내가 주로 관리	OS, 미들웨어, 앱	앱, 데이터	사용자 설정, 데이터
인프라 제어력	높음	중간	낮음
개발 속도	중간	빠름	매우 빠름(즉시 사용)
운영 부담	큼	중간	작음
커스터마이징	매우 높음	높음(플랫폼 범위 내)	제한적
대표 사용 예	가상머신 기반 서비스	앱 백엔드/웹앱 배포	협업/메일/업무툴

실무에서 고르는 기준

정답은 하나가 아니라, 서비스별로 섞어 쓰는 것이 일반적이다.

인프라 제어가 중요하면 IaaS
개발 생산성이 최우선이면 PaaS
공통 업무를 빠르게 도입하려면 SaaS

예를 들면 이런 조합이 흔하다.

고객용 핵심 서비스: IaaS 또는 PaaS
사내 협업/문서/메일: SaaS
데이터/로그 분석: 관리형 PaaS + 일부 IaaS

자주 하는 오해 3가지

PaaS는 무조건 자유도가 낮다 실제로는 운영 부담을 줄이는 대신 제어 범위를 조정하는 선택이다.
IaaS가 항상 더 싸다 인프라 단가만 보면 그럴 수 있지만, 운영 인건비/장애 대응 비용까지 보면 달라진다.
SaaS는 기술팀이 필요 없다 도입 후 권한 정책, 데이터 거버넌스, 연동 설계는 여전히 중요하다.

결론

IaaS, PaaS, SaaS는 우열이 아니라 문제와 팀 상황에 맞는 도구 선택이다. 클라우드 설계의 핵심은 기술 스택보다 먼저 우리 팀이 어디까지 직접 운영할 것인가를 결정하는 데 있다.

네임스페이스 개념 정리와 cgroup 차이

Thu, 05 Feb 2026 10:22:12 GMT

:::note[섹션 개요]

네임스페이스의 개념과 역할을 정리한다.
cgroup과의 차이를 간단히 구분한다. :::

네임스페이스란?

네임스페이스(namespace)는 프로세스가 보는 세상(view)을 분리하는 커널 기능이다. 같은 호스트에서도 프로세스마다 PID, 네트워크, 마운트 등이 다르게 보이게 만든다. 그래서 컨테이너는 “진짜로 다른 컴퓨터”처럼 보이지만, 실제로는 호스트 커널을 공유한다.

네임스페이스는 “격리”에 집중한다. 접근 가능한 범위를 나누는 개념이다.
네임스페이스는 자원을 “제한”하지 않는다. 보이는 영역을 바꾼다.
네임스페이스는 프로세스 단위로 적용되며, 같은 네임스페이스를 공유할 수 있다.

자주 쓰는 네임스페이스 종류

pid: 프로세스 ID 격리
net: 네트워크 스택 격리
mnt: 마운트 포인트(파일시스템) 격리
uts: 호스트명/도메인명 격리
ipc: IPC 리소스 격리
user: UID/GID 격리(권한 매핑)
cgroup: cgroup 트리 뷰 격리

cgroup과의 차이

네임스페이스는 “보이는 세계를 나누는 것”, cgroup은 “자원을 나누고 제한하는 것”이다. 네임스페이스만으로는 CPU/메모리 제한이 안 되고, cgroup만으로는 네트워크/프로세스 보기가 분리되지 않는다. 그래서 컨테이너는 보통 네임스페이스 + cgroup을 같이 쓴다.

EC2 재부팅 vs 종료 후 시작 차이

Wed, 04 Feb 2026 00:00:00 GMT

:::note[섹션 개요]

재부팅과 종료 후 시작의 동작 차이를 정리한다.
왜 stop/start가 SSH 문제를 해결하는지 이해한다. :::

인스턴스가 비정상 상태여서 재부팅을 했는데 SSH가 계속 안 붙었다. 그래서 종료 후 시작(Stop/Start)하니 접속이 됐다. 이 차이를 정리해둔다.

차이 한눈에 보기

항목	재부팅(Reboot)	종료 후 시작(Stop/Start)
호스트	같은 호스트에서 OS 재시작	새 호스트로 이동(대부분)
Public IPv4	유지	새로 할당(Elastic IP 예외)
데이터	인스턴스 스토어 유지	RAM + 인스턴스 스토어는 소실, EBS는 유지
가능 대상	대부분	EBS 루트 볼륨 인스턴스만 가능
과금	새 과금 사이클 없음	다시 시작 시 1분 최소 과금 시작

왜 재부팅은 안 되고 stop/start는 됐을까

가능성이 큰 흐름은 두 가지다.

호스트 문제 재부팅은 같은 호스트에서 OS만 다시 올린다. 반면 stop/start는 대개 새 호스트로 이동한다. 즉, 호스트/네트워크 쪽 문제가 있었으면 stop/start가 해결될 수 있다.
Public IP 변경 stop/start는 Public IPv4가 바뀐다. 이때 기존 IP로 접속하면 당연히 실패한다. Elastic IP를 붙이거나, 새 IP로 접속해야 한다.

기억해둘 포인트

stop/start는 EBS 루트 인스턴스에서만 가능하다.
stop/start하면 RAM과 인스턴스 스토어 데이터는 날아간다.
Public IP가 바뀌는 걸 항상 염두에 둔다. 고정이 필요하면 Elastic IP를 쓴다.

Cgroups v1 vs v2

Wed, 04 Feb 2026 00:00:00 GMT

:::note[섹션 개요]

구조/경로/컨트롤러 차이를 한눈에 비교한다.
내 환경이 v1인지 v2인지 빠르게 확인한다. :::

실습중에 실습 내용은 v1 기준이고 내 환경은 v2라서, 명령어는 비슷한데 파일 위치가 자주 안 맞았다. 그때마다 흐름이 끊기는 게 싫어서 “구조가 다르면 경로와 파일 이름도 달라진다”부터 정리해 두기로 했다.

핵심 차이 4가지

1) 계층 구조 v1은 컨트롤러별로 여러 트리를 만든다. v2는 모든 컨트롤러가 하나의 트리(단일 계층)를 공유한다.

2) 경로 구조 v1은 /sys/fs/cgroup/ 아래에 cpu, memory, blkio 같은 디렉터리가 각각 존재한다. v2는 루트 하나에 공통 파일이 있고, 그 아래로 cgroup 디렉터리가 쌓인다.

3) 컨트롤러 활성화 방식 v2는 컨트롤러가 상위 cgroup에서 활성화되어야 자식에서 쓸 수 있다. 다만 systemd 환경에서는 루트나 slice에서 이미 켜 둔 경우가 많아, 직접 건드릴 일이 적다.

4) 파일 이름 차이 v1에서 CPU 제한은 cpu.cfs_quota_us + cpu.cfs_period_us로 설정하지만, v2에서는 cpu.max로 바뀐다. 또 v2에서는 tasks 파일이 사라지고 cgroup.procs 중심으로 다룬다. 자주 보는 것만 몇 개 더 적어두면 아래 정도다.

v1 cpu.shares → v2 cpu.weight
v1 memory.limit_in_bytes → v2 memory.max
v1 memory.soft_limit_in_bytes → v2 memory.high
v1 memory.usage_in_bytes → v2 memory.current
v1 blkio.* 계열 → v2 io.* 계열 (io.max, io.weight 등)

구조 변화에서 중요한 비교 포인트

A) 마운트/디렉터리 구조 v1은 컨트롤러마다 마운트가 따로 있고, 그 아래에 cgroup 디렉터리를 만든다. 그래서 cpu, memory, blkio가 각각 다른 트리를 가진다. v2는 /sys/fs/cgroup/ 하나의 트리로 통합된다. 모든 컨트롤러가 같은 경로를 공유한다. 즉, “트리가 여러 개냐 하나냐”가 핵심이다.

B) 프로세스 배치 방식 v1은 컨트롤러별 트리가 달라서 같은 프로세스가 컨트롤러마다 “다른 경로”에 있을 수 있다. v2는 프로세스가 하나의 cgroup 경로에 묶이고, 그 경로에 모든 컨트롤러가 적용된다. 상위 cgroup에는 프로세스를 두지 않는 원칙(일명 no internal process)이 기본이다. 그래서 실무에서는 서비스 프로세스를 보통 leaf cgroup에 둔다.

C) 컨트롤러 상속/활성화 흐름 v1은 해당 컨트롤러 트리에 들어가면 바로 제어 파일이 있다. v2는 부모에서 cgroup.subtree_control로 컨트롤러를 켜야 자식에서 제한 파일을 쓸 수 있다. 이 흐름을 모르면 자식에서 제한 파일이 안 먹는 이유를 놓치기 쉽다.

D) 컨트롤러 이름과 파일 체계 v1은 blkio 같은 컨트롤러 디렉터리 이름을 그대로 쓴다. v2는 io.* 계열로 단순화되었고, 공통 파일(cgroup.procs, cgroup.controllers)이 루트에 있다. 파일 이름을 외우기보다 바뀐 이유만 감 잡아두면 된다.

내 환경이 v1인지 v2인지 빠르게 확인

lin> stat -fc %T /sys/fs/cgroup

cgroup2fs면 v2
tmpfs면 v1

cgroup CPU 제한 실습 (stress)

Wed, 04 Feb 2026 00:00:00 GMT

:::note[섹션 개요]

cgroup이 무엇인지와 기본 구조를 이해한다.
cgroup 내부 파일의 의미를 정리한다.
stress로 부하를 걸고 top으로 확인한다. :::

cgroup

cgroup은 프로세스를 묶어서 CPU/메모리 같은 자원을 제한하거나 측정하는 커널 기능이다. /sys/fs/cgroup 아래의 디렉터리 하나가 곧 하나의 cgroup이고, 여기에 파일로 설정을 넣는다.

cgroup 내부 파일 구성(핵심)

파일은 크게 공통 메타 파일과 컨트롤러별 파일로 나뉜다. 읽으면 상태/통계를 보고, 쓰면 제한/정책을 설정한다.

공통 메타 파일:

cgroup.controllers: 상위 cgroup에서 자식으로 내려줄 수 있는 컨트롤러 목록
cgroup.subtree_control: 자식 cgroup에서 활성화할 컨트롤러 선택(+/-)
cgroup.procs: 이 cgroup에 포함된 PID 목록(여기에 PID를 쓰면 이동)
cgroup.events: OOM/Freeze 등 이벤트 상태 요약
cgroup.stat: cgroup 내부 기본 통계(자식 수 등)
cgroup.type: 도메인/스레드 모드 구분(환경에 따라 값이 다름)

컨트롤러별 파일(대표 예시):

CPU: cpu.max, cpu.weight, cpu.stat
Memory: memory.max, memory.high, memory.current, memory.stat
I/O: io.max, io.stat
PID: pids.max, pids.current

이 글의 실습만 보면 cgroup.controllers, cgroup.subtree_control, cgroup.procs, cpu.max 네 개면 충분하다. 하지만 운영/디버깅까지 생각하면 위의 통계/상태 파일들도 같이 보는 게 좋다.

실습

1) stress 설치

lin> sudo apt update
lin> sudo apt install -y stress

2) cgroup 생성 및 프로세스 이동

lin> sudo su
lin> cd /sys/fs/cgroup
lin> cat cgroup.controllers
lin> cat cgroup.subtree_control
# cpu가 보이지 않으면 활성화
lin> echo +cpu > cgroup.subtree_control
lin> mkdir utils
lin> cd utils
lin> echo $$ > cgroup.procs

3) CPU 제한 설정

lin> cat cpu.max
lin> echo "10000 100000" > cpu.max

cpu.max는 quota period 형식이다. 10000 100000이면 100ms 중 10ms만 CPU를 사용하게 되어 약 10% 제한이다.

4) 부하 테스트 및 확인

lin> stress -c 1

다른 터미널에서 확인:

lin> top

예시 출력:

top - 06:19:21 up 4:19,  2 users,  load average: 0.10, 0.06, 0.01
Tasks: 124 total,   2 running, 122 sleeping,   0 stopped,   0 zombie
%Cpu(s): 10.0 us,  0.0 sy,  0.0 ni, 90.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :  914.1 total,   76.0 free,  559.0 used,  279.1 buff/cache
MiB Swap:    0.0 total,    0.0 free,    0.0 used.  190.9 avail Mem

  PID USER   %CPU %MEM COMMAND
 9625 root   10.0  0.0 stress
 1505 ubuntu  0.7  5.0 node
 2896 ubuntu  0.3  0.6 cursor
 9657 ubuntu  0.3  0.4 top

트러블슈팅 도구

Sat, 17 Jan 2026 02:00:00 GMT

핵심 도구

ping: 연결 확인
traceroute: 경로 확인
dig/nslookup: DNS 확인
ss/netstat: 포트 확인
tcpdump: 패킷 캡처

실습: 웹 접속 실패 진단

단계 1: IP 확인

mac> ifconfig | grep inet

단계 2: DNS 확인

mac> dig example.com

단계 3: 포트 확인

mac> nc -vz example.com 443

단계 4: 경로 확인

mac> traceroute example.com

예상 증상 해석

DNS 실패: 이름 해석 불가
포트 실패: 방화벽/서버 문제
traceroute 중간 끊김: 라우팅 문제

장애 분류 표

증상	의심 계층	도구
IP 없음	L2/L3	ipconfig, ip
DNS 실패	L7	dig, nslookup
포트 연결 실패	L4	nc, telnet
경로 끊김	L3	traceroute

진단 순서 요약

IP 확인 (내가 네트워크에 있는가?)
DNS 확인 (이름을 IP로 바꿀 수 있는가?)
포트 확인 (서비스 포트가 열려 있는가?)
경로 확인 (중간에 끊기지 않는가?)

문제 진단 흐름

OS별 도구 설치 팁

macOS: brew install iperf3 tcpdump
Windows: choco install wireshark
Linux: sudo apt install iperf3 tcpdump

실전 사례

사례 1: DNS 실패 vs 포트 실패 구분.
사례 2: traceroute 중간 끊김 분석.
사례 3: tcpdump로 재전송 확인.

추가 장애 시나리오 (실제 로그 기반)

시나리오 1: DNS는 되는데 접속이 안 됨

mac> dig example.com
example.com. 86400 IN A 93.184.216.34
mac> nc -vz example.com 443
nc: connectx to example.com port 443 (tcp) failed: Operation timed out

해석: DNS 정상, 포트 차단 또는 서버 문제.

시나리오 2: 라우팅 문제

lin> ping -c 3 10.0.2.20
connect: Network is unreachable
lin> ip route
(default route 없음)

해석: 기본 게이트웨이 또는 라우팅 누락.

시나리오 3: 패킷 손실 증가

mac> ping -c 20 8.8.8.8
20 packets transmitted, 15 received, 25% packet loss

해석: 링크 품질 저하, 혼잡 가능성.

VPN과 터널

Sun, 11 Jan 2026 10:30:00 GMT

VPN(Virtual Private Network) 개념

VPN은 암호화된 터널을 통해 안전한 통신을 제공한다.

VPN이 왜 필요한가

공용 인터넷에서도 회사 내부망처럼 안전하게 접속하기 위해서다.

터널이란

원래 데이터를 암호화된 껍질로 감싸서 전달하는 방식이다.

VPN 터널 개념

사용 사례

회사 내부망 원격 접속
데이터 보호

WireGuard 개요

설정이 단순하고 성능이 좋음

실습: WireGuard 터널 구성

설치

vm1> sudo apt install -y wireguard
vm2> sudo apt install -y wireguard

키 생성

vm1> wg genkey | tee privatekey | wg pubkey > publickey
vm2> wg genkey | tee privatekey | wg pubkey > publickey

설정 파일

VM1 /etc/wireguard/wg0.conf

[Interface]
Address = 10.10.0.1/24
PrivateKey = <VM1_PRIVATE>

[Peer]
PublicKey = <VM2_PUBLIC>
AllowedIPs = 10.10.0.2/32
Endpoint = 10.0.2.20:51820

VM2 /etc/wireguard/wg0.conf

[Interface]
Address = 10.10.0.2/24
PrivateKey = <VM2_PRIVATE>

[Peer]
PublicKey = <VM1_PUBLIC>
AllowedIPs = 10.10.0.1/32
Endpoint = 10.0.1.10:51820

실행

vm1> sudo wg-quick up wg0
vm2> sudo wg-quick up wg0

테스트

vm1> ping -c 3 10.10.0.2

터널링과 캡슐화

원래 패킷을 다른 패킷 안에 넣어 전송
외부에서는 내부 주소가 보이지 않음

실전 시나리오

상황: 집에서 회사 내부망 접근

VPN 연결로 내부망 IP 접근 가능

OS별 WireGuard 상태 확인

Linux

lin> sudo wg show

Windows/macOS

WireGuard GUI에서 상태 확인

실전 사례

사례 1: VPN 연결되지만 특정 대역 안 됨 → AllowedIPs 누락.
사례 2: 연결이 자주 끊김 → MTU 조정 필요.
사례 3: 성능 저하 → 암호화 오버헤드 확인.

로드밸런싱

Sun, 11 Jan 2026 01:00:00 GMT

로드밸런서란

트래픽 분산
장애 시 자동 우회

로드밸런서 구조

로드밸런서가 필요한 이유

한 대의 서버가 감당 못 하는 트래픽을 여러 대로 나눠준다.
한 대가 죽어도 서비스가 계속된다.

대표 알고리즘

라운드 로빈: 순서대로 하나씩 분배 (균등 분산)
최소 연결: 현재 연결이 가장 적은 서버로 보냄 (불균형 트래픽에 유리)
해시 기반: 특정 값(클라이언트 IP 등)을 해시해 고정 분배 (세션 유지에 유리)

로드밸런싱 알고리즘 예시

L4 vs L7

L4: TCP/UDP 기반
L7: HTTP 기반 (URL, 헤더 조건 가능)

L4 vs L7 차이

L4는 포트/프로토콜 기준으로만 분배
L7은 URL/헤더/쿠키 등 내용을 보고 분배 가능

실습: 로컬 로드밸런싱(Nginx)

구성

VM2: 백엔드1 (8081)
VM3: 백엔드2 (8082)
VM1: 로드밸런서 (80)

VM2/VM3 서버 실행

vm2> python3 -m http.server 8081
vm3> python3 -m http.server 8082

VM1 Nginx 설치

vm1> sudo apt update
vm1> sudo apt install -y nginx

/etc/nginx/nginx.conf 예시

upstream backend {
    server 10.0.2.20:8081;
    server 10.0.2.30:8082;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend;
    }
}

테스트

vm1> curl http://10.0.1.10

예상 결과

요청이 백엔드로 번갈아 전달

세션 고정(Sticky Session)

특정 사용자를 항상 같은 백엔드로 보냄
상태 저장형 앱에 필요

실전 시나리오

상황: 로그인 세션이 자꾸 풀림

세션 고정 미사용
공유 세션 스토리지 필요

OS별 추가 실습: 헬스체크

Linux (curl)

lin> while true; do curl -s http://10.0.1.10 | head -n 1; sleep 1; done

헬스체크 설계

헬스체크는 단순 포트 확인이 아니라 앱의 정상 응답을 확인해야 한다.

예시

/health 엔드포인트
DB 연결 여부 확인

실전 사례

사례 1: 로그인 풀림 → 세션 고정 필요.
사례 2: 일부 서버만 과부하 → 알고리즘 문제.
사례 3: 헬스체크 실패 → 잘못된 엔드포인트.

방화벽과 NAT

Wed, 07 Jan 2026 00:30:00 GMT

방화벽 기본

인바운드/아웃바운드 규칙
기본 정책 (기본 차단 vs 기본 허용)

인바운드/아웃바운드란

인바운드: 외부 → 내부로 들어오는 트래픽
아웃바운드: 내부 → 외부로 나가는 트래픽

방화벽 비유

인바운드 예시

22/SSH 허용
80/HTTP 허용
그 외 차단

방화벽 룰 예시

방화벽 규칙 읽는 방법

조건: 출발지/목적지/포트/프로토콜
행동: 허용(Allow) 또는 차단(Deny)
보통 규칙은 위에서 아래로 검사한다.

방화벽 룰 읽기 쉬운 방법

"누가(출발지)" → "어디로(목적지)" → "무슨 문(포트)" → "허용/차단"

NAT(Network Address Translation)

사설 IP를 공인 IP로 변환하는 기술

NAT가 필요한 이유

내부 IP는 인터넷에서 직접 라우팅되지 않는다.
NAT가 공인 IP로 변환해 외부와 통신 가능하게 한다.

NAT 변환 개념

SNAT(Source Network Address Translation)

내부 → 외부 (출발지 주소를 공인 IP로 변경)

[10.0.0.5] --(SNAT)--> [1.2.3.4]

DNAT(Destination Network Address Translation)

외부 → 내부 (목적지 주소/포트를 내부로 변경 = 포트포워딩)

[1.2.3.4:8080] --(DNAT)--> [10.0.0.5:80]

실습 1: 로컬 방화벽 확인

macOS

mac> sudo pfctl -sr | head -n 20

Windows

win> Get-NetFirewallRule | select -First 5

Linux

lin> sudo iptables -L | head -n 20

실습 2: 포트 차단 테스트 (Linux VM)

VM2에서 8080 차단

vm2> sudo iptables -A INPUT -p tcp --dport 8080 -j DROP

VM1에서 접속

vm1> curl http://10.0.2.20:8080

예상 결과

연결 실패 또는 timeout

복구

vm2> sudo iptables -F

상태 기반 방화벽

연결 상태를 추적
응답 패킷은 자동 허용 가능

실전 시나리오

상황: 외부에서 내부 서비스 접속 필요

DNAT 설정

OS별 포트 리스닝 확인

macOS

mac> lsof -iTCP -sTCP:LISTEN | head -n 5

Windows

win> netstat -ano | find "LISTEN"

Linux

lin> ss -lntp | head -n 5

Stateless vs Stateful

Stateless: 패킷 단위 필터링
Stateful: 연결 상태를 추적

차이점

Stateful은 응답 트래픽을 자동 허용 가능
Stateless는 룰이 많아지고 관리가 어렵다

실전 사례

사례 1: 외부 접속 불가 → 포트 포워딩 누락.
사례 2: 내부 서비스 접근 실패 → 인바운드 차단.
사례 3: 특정 포트만 차단 → 룰 순서 문제.

NAT 심화: PAT(포트 주소 변환)

PAT는 여러 사설 IP를 하나의 공인 IP + 포트로 변환한다.

예시

내부 10.0.0.10:50000 → 공인 1.2.3.4:40001
내부 10.0.0.11:50001 → 공인 1.2.3.4:40002

실무 포인트

대부분 가정/기업 NAT는 PAT 방식
포트 충돌 관리가 중요

HTTP와 TLS

Sat, 03 Jan 2026 11:00:00 GMT

HTTP(Hypertext Transfer Protocol) 구조

브라우저가 서버에 요청을 보내고, 서버가 응답을 보내는 규칙이다.
요청: 메서드, 경로, 헤더, 바디
응답: 상태코드, 헤더, 바디

GET / HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html

주요 상태코드

200 OK
301 Redirect
404 Not Found
500 Server Error

TLS(Transport Layer Security)

통신 내용을 암호화하고, 서버가 진짜인지 검증한다.
인증서가 없거나 만료되면 보안 경고가 뜬다.
대칭키 + 공개키 혼합
인증서로 서버 신뢰 확인

TLS 흐름 요약

Client Hello
Server Hello + 인증서
키 교환
대칭키로 암호화 통신

HTTPS 통신 흐름

실습 1: HTTP 요청 확인

mac> curl -v http://example.com

예상 출력(요약)

> GET / HTTP/1.1
< HTTP/1.1 200 OK

실습 2: TLS 핸드셰이크 확인

mac> openssl s_client -connect example.com:443

예상 출력(요약)

Protocol  : TLSv1.3
Cipher    : TLS_AES_256_GCM_SHA384

HTTP Keep-Alive

하나의 TCP 연결로 여러 요청 처리
지연 감소

TLS 인증서 검증

체인 검증(루트 CA까지)
만료/호스트명 확인

OS별 실습: 인증서 확인

macOS

mac> openssl s_client -connect example.com:443 -servername example.com

Windows

win> openssl s_client -connect example.com:443 -servername example.com

Linux

lin> openssl s_client -connect example.com:443 -servername example.com

실전 사례

사례 1: HTTPS 오류 → 인증서 만료.
사례 2: 리다이렉트 반복 → 설정 오류.
사례 3: 응답 느림 → Keep-Alive 미사용.

TLS/PKI 기본 구조

TLS는 PKI(공개키 기반 구조) 위에서 동작한다.

구성 요소

CA: 인증서 발급 기관
인증서: 서버 신원 증명
공개키/개인키: 암호화/복호화

왜 필요한가

중간자 공격 방지
서버 신원 보장

실무 포인트

인증서 만료일 관리 필수
SAN(Subject Alternative Name) 확인 중요

TCP와 UDP

Sat, 03 Jan 2026 01:00:00 GMT

TCP/UDP 개요

TCP(Transmission Control Protocol): 신뢰성 중심, 연결 지향
UDP(User Datagram Protocol): 지연 최소화, 비연결

TCP 특징

연결 지향
신뢰성 보장 (순서/재전송)
흐름 제어/혼잡 제어
웹, 파일 전송에 적합

TCP 헤더 요약

헤더 필드 주석 예시

TCP 옵션 대표 예시

3-way handshake

TCP 3-way handshake

왜 필요한가

양쪽이 통신 준비가 되었는지 확인
초기 시퀀스 번호 동기화

TCP가 느리지만 안정적인 이유

데이터가 도착했는지 확인하고, 빠진 부분은 다시 보내기 때문이다.

UDP 특징

비연결
빠르지만 신뢰성 없음
실시간 스트리밍/VoIP/게임/통화에 적합

UDP 헤더 요약

UDP가 빠른 이유

확인 절차가 없어서 빠르지만, 손실이 생겨도 그대로 진행한다.

실습 1: TCP 핸드셰이크 관찰

준비

mac> sudo tcpdump -i en0 tcp port 80

실행

tcpdump 실행
브라우저로 http://example.com 접속

예상 출력(요약)

SYN
SYN, ACK
ACK

실습 2: UDP 테스트 (netcat)

터미널 1

lin> nc -u -l 9999

터미널 2

lin> echo "hello" | nc -u 127.0.0.1 9999

예상 출력

hello

TCP 혼잡 제어

슬로우 스타트: 처음엔 천천히 전송량 증가
혼잡 회피: 임계치 넘으면 증가 속도 완화
패킷 손실 감지: 재전송/윈도우 축소

시퀀스 다이어그램 (3-way handshake)

Client                Server
  | ---- SYN -------> |
  | <--- SYN,ACK ---- |
  | ---- ACK -------> |

OS별 실습: 연결 상태 확인

macOS

mac> netstat -an | grep ESTABLISHED | head -n 5

Windows

win> netstat -an | find "ESTABLISHED"

Linux

lin> ss -ant | head -n 5

슬라이딩 윈도우

TCP는 송신/수신 윈도우 크기를 조절해 전송 효율을 최적화한다.

핵심 개념

윈도우 크기가 크면 처리량이 좋아짐
네트워크 혼잡 시 윈도우를 줄여 안정성 확보

실전 사례

사례 1: TCP 연결 느림 → 혼잡 제어/손실 영향.
사례 2: UDP 스트리밍 깨짐 → 손실/지터 영향.
사례 3: 재전송 급증 → 링크 품질 문제.

DNS와 DHCP

Sun, 28 Dec 2025 11:30:00 GMT

DNS 구조

DNS(Domain Name System)는 이름을 IP로 바꾸는 분산 시스템이다.

DNS는 왜 필요한가

사람은 이름(example.com)을 기억하고, 컴퓨터는 IP를 사용한다.
DNS는 그 변환을 담당한다.

계층 구조

루트 서버
TLD 서버(.com, .net)
권한(Authoritative) 서버

조회 과정

로컬 캐시 확인
루트 서버 질의
TLD 서버 질의
권한 서버에서 최종 IP 획득

DNS 조회 흐름

DNS 레코드

A/AAAA: 도메인 → IP/IPv6)
CNAME: 도메인 별칭(다른 도메인으로 연결)
MX: 메일을 받을 서버
TXT: 정책/검증용 텍스트 정보
NS: 해당 도메인을 담당하는 네임서버

DHCP(Dynamic Host Configuration Protocol)

자동 IP 할당 프로토콜

DHCP는 자동 배정

IP/게이트웨이/DNS를 자동으로 나눠준다
없으면 모든 PC에 수동 입력해야 한다

DORA(Discover, Offer, Request, Acknowledge) 절차

Discover
Offer
Request
Ack

실습 1: DNS 조회

macOS/Linux

mac> dig example.com
lin> dig example.com

Windows

win> nslookup example.com

예상 출력

example.com.  86400  IN  A  93.184.216.34

실습 2: DHCP 동작 확인

macOS

mac> ipconfig getpacket en0

Linux

lin> sudo dhclient -r
lin> sudo dhclient

예상 출력

DHCPACK from 192.168.0.1
bound to 192.168.0.15

트러블슈팅

DNS 실패 시: /etc/resolv.conf 확인
DHCP 실패 시: 케이블/라우터 상태 확인

DNS 캐시와 TTL

DNS 응답에는 TTL이 포함됨
TTL 동안은 캐시에 저장되어 재질의 감소

실전 시나리오

상황: 도메인 변경했는데 접속이 안 됨

캐시 TTL 때문에 이전 IP가 남아 있음
해결: 캐시 flush 또는 TTL 대기

OS별 DNS 캐시 플러시

macOS

mac> sudo dscacheutil -flushcache
mac> sudo killall -HUP mDNSResponder

Windows

win> ipconfig /flushdns

Linux (systemd-resolved)

lin> sudo resolvectl flush-caches

Recursive vs Iterative

Recursive: 클라이언트 대신 DNS 서버가 끝까지 조회
Iterative: 서버가 다음 서버 정보를 알려줌

실무 포인트

로컬 DNS는 일반적으로 Recursive
권한 서버는 Iterative 응답

실전 사례

사례 1: 도메인 변경 후 접속 안 됨 → TTL 캐시 문제.
사례 2: IP 못 받음 → DHCP 서버 다운.
사례 3: 특정 DNS만 실패 → 권한 서버 장애.

L3 라우팅

Sun, 28 Dec 2025 01:00:00 GMT

라우터란 무엇인가

라우터는 서로 다른 네트워크 사이의 패킷을 전달한다.

라우팅 기본 구조

라우팅 테이블

라우터는 라우팅 테이블을 보고 패킷의 다음 홉을 결정한다.

라우팅 테이블 항목

목적지 네트워크
다음 홉(게이트웨이)
출력 인터페이스

기본 게이트웨이

목적지 네트워크가 명확하지 않을 때 나가는 길

:::note[기본 게이트웨이]

다른 네트워크로 나갈 때 반드시 필요하다.
없으면 외부 인터넷이 모두 끊긴다. :::

정적 vs 동적 라우팅

정적: 관리자가 직접 설정
동적: OSPF/BGP 같은 프로토콜로 자동 학습

:::note[OSPF / BGP 한 번에 이해]

OSPF(Open Shortest Path First)
- **내부망(같은 조직/회사)**에서 쓰는 대표적인 IGP(내부 라우팅 프로토콜)
- 라우터들이 서로 링크 상태를 공유하고, 최단 경로(비용/Cost) 기준으로 라우팅 테이블을 자동 구성
- 특징: 수렴이 빠르고, 한 회사/한 데이터센터/VPC 내부 같은 "안쪽" 네트워크에 적합
BGP(Border Gateway Protocol)
- 인터넷(서로 다른 조직/통신사/AS) 사이에서 쓰는 대표적인 EGP(외부 라우팅 프로토콜)
- "최단"보다는 정책(Policy) 기반: 어떤 경로를 선호/차단할지 운영자가 정할 수 있음
- 특징: 인터넷의 길찾기 표준, 대규모에 강함(대신 설정/운영 난이도 높음)

한 줄 비유

OSPF: "회사 내부 길찾기(최단/빠른 수렴)"
BGP: "회사 ↔ 회사/통신사 ↔ 인터넷 연결(정책/규모)"

:::

실습 1: 라우팅 테이블 확인

macOS

mac> netstat -rn | head -n 10

Windows (PowerShell)

win> route print

Linux

lin> ip route

예상 출력

default via 192.168.0.1 dev en0

실습 2: VM 라우터 구성

목표

VM1(10.0.1.0/24) ↔ VM2(10.0.2.0/24) 통신

구성도

VM1 (10.0.1.10) --\
                    [VM3 Router]
VM2 (10.0.2.20) --/

단계

VM3에 NIC 2개 설정 (intnet1, intnet2)
VM3에서 IP 포워딩 활성화

vm3> sudo sysctl -w net.ipv4.ip_forward=1

VM3에 IP 할당

vm3> sudo ip addr add 10.0.1.1/24 dev enp0s3
vm3> sudo ip addr add 10.0.2.1/24 dev enp0s8

VM1/VM2에 라우트 추가

vm1> sudo ip route add 10.0.2.0/24 via 10.0.1.1
vm2> sudo ip route add 10.0.1.0/24 via 10.0.2.1

테스트

vm1> ping -c 3 10.0.2.20

예상 출력

64 bytes from 10.0.2.20: icmp_seq=1 ttl=63 time=0.9 ms

트러블슈팅

ping 실패 → IP 포워딩 확인
라우트 누락 → ip route 재확인

라우팅 결정 순서

가장 긴 프리픽스(길이 긴 경로 우선)
우선순위/메트릭(관리 거리, 비용) 비교
기본 게이트웨이(::/0 또는 0.0.0.0/0)

실전 시나리오

상황: 특정 네트워크만 접근 불가

라우팅 테이블에 경로 없음
잘못된 넥스트홉

OS별 추가 실습: 라우트 추가/삭제

macOS

mac> sudo route -n add 10.0.2.0/24 192.168.0.1
mac> sudo route -n delete 10.0.2.0/24

Windows

win> route add 10.0.2.0 mask 255.255.255.0 192.168.0.1
win> route delete 10.0.2.0

Linux

lin> sudo ip route add 10.0.2.0/24 via 192.168.0.1
lin> sudo ip route del 10.0.2.0/24

Longest Prefix Match 예시

라우터는 가장 긴 프리픽스를 우선한다.

예시

10.0.0.0/8 → 게이트웨이 A
10.0.1.0/24 → 게이트웨이 B

목적지가 10.0.1.5라면 /24가 더 구체적이므로 B를 선택한다.

실전 사례

사례 1: 특정 대역 접근 불가 → 라우팅 테이블 누락.
사례 2: 간헐적 라우팅 루프 → 잘못된 경로 광고.
사례 3: 지연 급증 → 비효율 경로 선택.

L2 스위칭

Mon, 22 Dec 2025 10:00:00 GMT

MAC(Media Access Control) 주소

48비트 고유 식별자
같은 네트워크 안에서 장치를 구분

스위치 동작 원리

스위치는 MAC 주소 테이블을 만든다.

동작 흐름

프레임 수신
출발지 MAC을 테이블에 기록
목적지 MAC이 테이블에 있으면 해당 포트로 전달
없으면 플러딩

:::note[플러딩이란]

수신처 주소(MAC)를 모를 때, 스위치가 수신 포트를 제외한 모든 포트로 무조건 복사하여 전달. :::

[PC A] --\
          [SWITCH] ---- [PC B]
[PC C] --/

ARP(Address Resolution Protocol)

IP 주소만 알고 있을 때 MAC 주소를 얻는 프로토콜

ARP는 왜 필요한가

IP 주소로는 실제 장비를 찾을 수 없다.
같은 네트워크 안에서는 MAC 주소를 알아야 전송이 가능하다.

과정

ARP Request (브로드캐스트)
ARP Reply (유니캐스트)

A: "192.168.0.20 누구야?" (브로드캐스트)
B: "나야. MAC=aa:bb:cc:dd:ee:ff" (유니캐스트)

스위치와 ARP 브로드캐스트

실습 1: ARP 캐시 확인

macOS

mac> arp -a
mac> ping -c 1 192.168.0.1
mac> arp -a | head -n 5

Windows (PowerShell)

win> arp -a
win> ping 192.168.0.1
win> arp -a

Linux

lin> ip neigh
lin> ping -c 1 192.168.0.1
lin> ip neigh

예상 출력

? (192.168.0.1) at xx:xx:xx:xx:xx:xx on en0

실습 2: VM 두 대로 동일 서브넷 통신

단계

VM1, VM2 생성
둘 다 Internal Network (intnet1)
IP 지정

vm1> sudo ip addr add 10.0.1.10/24 dev enp0s3
vm2> sudo ip addr add 10.0.1.20/24 dev enp0s3

ping 테스트

vm1> ping -c 3 10.0.1.20

예상 출력

64 bytes from 10.0.1.20: icmp_seq=1 ttl=64 time=0.6 ms

브로드캐스트 도메인

스위치 내부는 하나의 브로드캐스트 도메인
라우터가 도메인을 분리

실전 시나리오

상황: ARP 폭주

증상: 네트워크 전체 느려짐
원인: 루프(Spanning Tree 미적용)

OS별 추가 실습: MAC 확인

macOS

mac> ifconfig en0 | grep ether

Windows

win> getmac /v

Linux

lin> ip link | grep ether

실전 사례

사례 1: ARP 테이블 오염 → 스푸핑 의심.
사례 2: 브로드캐스트 폭주 → 루프 발생.
사례 3: 특정 포트만 느림 → 스위치 포트 오류.

IPv6 기초

Mon, 15 Dec 2025 03:00:00 GMT

IPv6 주소 구조

IPv6 헤더 구조

IPv6는 128비트 주소 체계이며 16비트씩 8블록으로 표현한다.

예시:

2001:0db8:85a3:0000:0000:8a2e:0370:7334

단축 표기 규칙

연속된 0 블록은 ::로 축약 가능 (한 번만 사용 가능)
앞의 0은 생략 가능

예:

2001:db8:85a3::8a2e:370:7334

:::note[IPv6 필요 이유]

IPv4 주소는 부족 :::

주소 유형

유니캐스트: 하나의 대상
멀티캐스트: 여러 대상
애니캐스트: 가장 가까운 대상

주요 주소 범위(자주 보는 것만)

글로벌 유니캐스트: 2000::/3 (일반적인 공인 주소)
링크 로컬: fe80::/10 (같은 링크 내부 통신)
고유 로컬(ULA): fc00::/7 (사설 주소 개념)

듀얼스택

IPv4와 IPv6를 함께 사용하는 방식. 점진적 전환에 사용된다.

전환 방식 개요

듀얼스택: IPv4/IPv6 동시 운영
터널링: IPv4 망 위에 IPv6 캡슐화
NAT64/DNS64: IPv6에서 IPv4 서비스 접근

기본 라우팅 개념

기본 경로는 ::/0로 표현한다.
기본 게이트웨이는 보통 RA(라우터 광고)로 전달된다.

기본 실습

macOS

mac> ifconfig | grep inet6

Windows

win> ipconfig

Linux

lin> ip -6 addr show

NDP(Neighbor Discovery)

ARP 대신 NDP를 사용
ICMPv6 기반으로 동작
주요 메시지: NS/NA, RS/RA

실전 시나리오

상황: IPv6는 있는데 외부 접속이 안 됨

링크 로컬만 할당된 경우
기본 게이트웨이(RA) 수신 실패
방화벽에서 ICMPv6 차단

IP 주소와 서브넷

Tue, 09 Dec 2025 11:00:00 GMT

IPv4 구조

IPv4는 32비트 주소이며, 8비트씩 4구간으로 표현한다.

192.168.10.25
11000000.10101000.00001010.00011001

IPv4 헤더 요약

네트워크/호스트 구분

네트워크 비트: 네트워크 구분
호스트 비트: 장치 구분

IPv4 헤더에서 자주 보는 필드

서브넷과 직접 연결되는 건 아니지만, 네트워크 트러블슈팅에서 자주 마주친다.

TTL(Time To Live): 패킷이 지나갈 수 있는 최대 홉 수. 0이 되면 폐기된다.
DF/MF (단편화): MTU(Maximum Transmission Unit)보다 큰 패킷이 단편화 가능한지 여부.
Total Length: 패킷 전체 길이. MTU(Maximum Transmission Unit)/단편화 이슈 판단에 유용.
Protocol: 상위 프로토콜 식별 (TCP/UDP/ICMP 등).

CIDR(Classless Inter-Domain Routing) 표기

예: 10.0.0.0/24
/24는 네트워크 비트 24개

호스트 수 계산

사용 가능 호스트 = 2^(호스트 비트) - 2
이유: 네트워크 주소 + 브로드캐스트 주소

자주 쓰는 CIDR

/24: 256개 주소 (사용 254)
/26: 64개 주소 (사용 62)
/28: 16개 주소 (사용 14)

자주 쓰는 마스크 표

/24 → 255.255.255.0 → 블록 256
/25 → 255.255.255.128 → 블록 128
/26 → 255.255.255.192 → 블록 64
/27 → 255.255.255.224 → 블록 32
/28 → 255.255.255.240 → 블록 16
/29 → 255.255.255.248 → 블록 8
/30 → 255.255.255.252 → 블록 4
/32 → 255.255.255.255 → 단일 호스트

사설 IP 대역

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

사설 IP는 인터넷에서 라우팅되지 않으며 NAT가 필요하다.

왜 NAT가 필요한가

사설 IP는 공인 인터넷에서 직접 라우팅 불가
외부 통신을 위해 공인 IP로 변환이 필요
대역 충돌을 피하려면 주소 계획이 중요

실습 1: 서브넷 계산 문제

문제

192.168.10.0/26의 네트워크/브로드캐스트/호스트 범위?

풀이

/26 → 호스트 비트 6개
주소 블록 크기 = 64

네트워크: 192.168.10.0
브로드캐스트: 192.168.10.63
사용 가능: 192.168.10.1 ~ 192.168.10.62

실습 2: 내 IP 범위 확인

macOS

mac> ipconfig getifaddr en0
mac> ifconfig en0 | grep netmask

Windows (PowerShell)

win> ipconfig
win> Get-NetIPAddress

Linux

lin> ip addr show

실습 3: 서브넷 분할 예시

요구사항

192.168.1.0/24를 4개 네트워크로 분할

결과

/26 네트워크 4개

192.168.1.0/26
192.168.1.64/26
192.168.1.128/26
192.168.1.192/26

/24를 /26으로 분할

:::note[서브넷이 왜 필요한가]

네트워크를 잘게 나눠 충돌/혼잡을 줄이고 보안을 강화하기 위해서다.
IP: 특정 집의 주소
서브넷: 같은 동네(같은 네트워크) :::

실무 팁: 주소 계획 기본 원칙

향후 확장을 고려해 여유 블록을 남겨둔다.
사설 대역 사용 시 중복 충돌을 피하도록 기록한다.
동일 환경에서 규칙적인 CIDR 패턴을 유지한다.

서브넷팅 직관

/24 → 마지막 옥텟이 호스트
/25 → 절반으로 나뉨 (0~127, 128~255)
/26 → 64 단위 블록

빠른 계산 팁

블록 크기 = 256 - 서브넷 마스크 마지막 값
예: /26 마스크는 255.255.255.192 → 블록 64

헷갈리기 쉬운 포인트

/31: 포인트 투 포인트 링크에서는 사용 가능 (일반 호스트용은 비권장)
/32: 단일 호스트 라우팅에 사용
브로드캐스트 주소는 항상 마지막 주소

OS별 실습: 서브넷 확인

macOS

mac> ifconfig en0 | grep inet
mac> ipcalc 192.168.10.25/26

Windows

win> ipconfig
win> powershell "ipcalc 192.168.10.25/26"

Linux

lin> ip addr show
lin> ipcalc 192.168.10.25/26

실전 시나리오

상황: 서로 다른 팀이 IP 충돌

서브넷 경계 계산 실수
주소 계획 문서화 필요

추가 시나리오: MTU/단편화 문제

큰 패킷이 중간 장비에서 드롭
해결: MTU 확인, DF 플래그 체크, 경로 MTU 탐지

바이너리 계산 예시

IP는 2진수로 계산하면 정확도가 높다.

예시: 192.168.10.25/26

192 = 11000000
168 = 10101000
10  = 00001010
25  = 00011001
/26 → 마지막 옥텟의 상위 2비트가 네트워크

실전 팁

블록 크기만 기억하면 빠른 계산 가능
/26 → 블록 64 → 0,64,128,192

실전 사례

사례 1: 서로 다른 팀 IP 충돌 → 서브넷 설계 오류.
사례 2: 특정 서브넷만 통신 불가 → 라우팅 누락.
사례 3: 브로드캐스트 폭주 → 서브넷 과도하게 큼.

계층과 프로토콜

Tue, 09 Dec 2025 02:00:00 GMT

OSI(Open Systems Interconnection) 7계층과 TCP/IP(Transmission Control Protocol/Internet Protocol)

OSI 7계층 (교육용 개념 모델)

물리(Physical)
데이터링크(Data Link)
네트워크(Network)
전송(Transport)
세션(Session)
표현(Presentation)
응용(Application)

TCP/IP

네트워크 인터페이스
인터넷
전송
응용

OSI 7계층과 TCP/IP 매핑

왜 두 모델이 있는가

OSI: 교육/분석용으로 세분화
TCP/IP: 현실에서 동작하는 단순 모델

계층별 핵심 역할 (실무 관점)

물리 계층

케이블, 전기 신호, 무선
증상: 케이블 불량, 링크 다운

데이터링크 계층

MAC 주소, 프레임 전달, 스위칭
증상: ARP 실패, 브로드캐스트 폭주

네트워크 계층

IP 주소, 라우팅
증상: 다른 네트워크 접근 불가

전송 계층

TCP/UDP, 포트, 세션
증상: 특정 포트 접속 불가

응용 계층

HTTP, DNS, SSH
증상: 서비스 자체 오류

계층 분리의 이점

문제 진단이 빠르고 명확해짐
변경 영향 범위를 최소화

예시

웹 접속 실패 →

물리: 링크 연결 확인
네트워크: IP 할당 확인
전송: 포트 차단 확인
응용: 서버 상태 확인

실습 1: 계층 흐름 관찰

목표

DNS → TCP → TLS → HTTP 흐름을 직접 확인한다.

macOS / Linux

mac> dig example.com
mac> curl -v https://example.com

Windows (PowerShell)

win> nslookup example.com
win> curl -v https://example.com

예상 출력 (요약)

*   Trying 93.184.216.34:443...
* Connected to example.com (93.184.216.34)
* TLS handshake, Client hello
> GET / HTTP/1.1
< HTTP/1.1 200 OK

해석

DNS: 이름 → IP
TCP: 연결 수립
TLS: 암호화 세션
HTTP: 응답 수신

실습 2: 포트/계층 문제 구분

목표

포트가 막혔을 때와 DNS가 실패했을 때 증상을 비교한다.

단계

DNS 확인

mac> dig example.com

포트 확인

mac> nc -vz example.com 443

예상 결과

DNS 실패: IP 자체가 안 나옴
포트 실패: 연결 시도 후 timeout

캡슐화/역캡슐화

데이터는 상위 계층에서 하위 계층으로 내려갈 때 헤더가 붙는다. 이를 캡슐화라 하고, 수신 측에서는 역으로 역캡슐화가 진행된다.

HTTP 데이터
→ TCP 헤더 추가
→ IP 헤더 추가
→ 이더넷 헤더 추가
→ 전송

캡슐화 과정

OS별 실습: 계층별 문제 진단 순서

macOS

mac> ifconfig | grep status
mac> ping -c 3 8.8.8.8
mac> dig example.com
mac> nc -vz example.com 443

Windows

win> Get-NetAdapter | ft Name, Status
win> ping -n 3 8.8.8.8
win> nslookup example.com
win> Test-NetConnection example.com -Port 443

Linux

lin> ip link
lin> ping -c 3 8.8.8.8
lin> dig example.com
lin> nc -vz example.com 443

진단 순서

링크/Wi-Fi 연결 확인 (물리)
IP 할당 확인 (네트워크)
DNS 확인 (응용)
포트 확인 (전송)
서비스 상태 확인 (응용)

실전 시나리오

상황: 특정 사이트만 접속 안 됨

물리/네트워크는 정상
DNS는 정상
443 포트가 차단되거나 서버 정책 문제 가능

캡슐화와 MTU

캡슐화 과정에서 헤더가 계속 붙기 때문에 실제 전송 가능 데이터(페이로드)는 줄어든다. 예를 들어 MTU가 1500바이트일 때, TCP/IP 헤더(최소 40바이트)를 제외하면 실제 데이터는 약 1460바이트만 실을 수 있다.

:::note[MTU 설명] MTU: 한 번에 전송 가능한 최대 크기. 이더넷 기준 보통 1500B이며, IP/TCP 헤더 때문에 앱 데이터는 대략 1460B 수준이 된다(옵션 없을 때). :::

핵심 포인트

MTU가 너무 작으면 분할(Fragmentation) 발생 가능
분할은 성능 저하와 오류 원인이 될 수 있음

실전 사례

사례 1: 링크 다운 → 물리 계층 케이블 불량.
사례 2: DNS는 되지만 서비스 접속 실패 → 전송/응용 문제.
사례 3: IP는 있음, 외부 접속 불가 → 라우팅 문제.

네트워크 기초 개념

Wed, 03 Dec 2025 01:30:00 GMT

네트워크란 무엇인가

네트워크는 여러 장치가 데이터를 주고받기 위한 연결과 규칙의 집합이다.

네트워크의 3가지 목적

연결성(Connectivity): 장치 간 통신 가능
신뢰성(Reliability): 데이터가 손실 없이 도착
확장성(Scalability): 트래픽 증가에도 유지

현실 예시

회사 인트라넷이 느리다 → 대역폭/혼잡 문제
화상회의가 끊긴다 → 지터/손실 문제
게임 핑이 높다 → 지연 문제

성능 지표 4가지

대역폭(Bandwidth)

초당 전송 가능한 최대 데이터량
비유: 도로의 차선 수

대역폭 비유

지연(Latency)

패킷이 목적지까지 가는 시간(왕복: RTT)
비유: 도로의 길이

지연 비유

손실(Loss)

중간 경로에서 패킷 유실
손실이 많으면 재전송 증가 → 체감 속도 저하

지터(Jitter)

지연이 불규칙하게 흔들리는 현상
실시간 스트리밍/통화에 치명적

네트워크 구성 요소

노드(Node): PC, 서버, 라우터, 스위치
링크(Link): 케이블/무선
프로토콜(Protocol): TCP/IP, HTTP, DNS 등

[PC] --- (케이블/Wi-Fi) --- [스위치] --- [라우터] --- (인터넷)

네트워크 기본 구성 요소

네트워크 유형

LAN: 근거리 네트워크 (집/회사)
WAN: 광역 네트워크 (도시/국가)
인터넷: 전세계 WAN의 결합
VPC/VNet: 클라우드의 가상 네트워크

실습 1: 내 네트워크 정보 확인

목표

IP, 게이트웨이, DNS를 확인한다.

macOS

mac> ifconfig | grep inet
mac> route -n get default
mac> scutil --dns | head -n 20

Windows (PowerShell)

win> ipconfig /all
win> Get-NetIPConfiguration

Linux

lin> ip addr show
lin> ip route
lin> resolvectl status | head -n 20

예상 출력 (요약)

inet 192.168.0.15 netmask 0xffffff00 broadcast 192.168.0.255
route to: default
    gateway: 192.168.0.1

확인 포인트

IP가 사설 대역인지 확인
게이트웨이가 같은 네트워크인지 확인

자주 발생하는 문제

IP가 169.254.x.x → DHCP 실패
DNS가 비어 있음 → 이름 해석 불가

속도 vs 체감 품질

대역폭이 넓어도 지연이 크면 체감은 느릴 수 있다.
지연이 낮아도 손실이 크면 재전송으로 체감이 나빠진다.

쉬운 비유

대역폭: 한 번에 많은 차를 보내는 고속도로
지연: 톨게이트까지 거리
손실: 중간에서 차가 탈락

실전 시나리오

상황: 영상 회의가 끊긴다

지연/지터 측정 (핑, 지속적인 패킷)
Wi-Fi → 유선 전환
백그라운드 다운로드 중지

문제 해석

지터가 크면 음성이 끊김
손실이 높으면 화면이 깨짐

추가 실습: 네트워크 품질 측정

macOS

mac> ping -c 20 8.8.8.8
mac> traceroute 8.8.8.8

Windows

win> ping -n 20 8.8.8.8
win> tracert 8.8.8.8

Linux

lin> ping -c 20 8.8.8.8
lin> traceroute 8.8.8.8

예상 출력 해석

time=XX ms가 크게 변동 → 지터 가능성
중간 홉에서 응답 없음 → 방화벽일 수도 있음

실전 사례

사례 1: 사내 파일 전송이 느림 → 대역폭 포화, 백업 스케줄 분산 필요.
사례 2: 영상 통화가 끊김 → 지터/손실 증가, Wi-Fi 간섭 확인.
사례 3: 게임 핑 급증 → 라우팅 경로 변경, ISP 경로 추적 필요.