DNS는 인터넷의 주소록

사람은 example.com 같은 이름을 기억하지만, 컴퓨터는 실제로 IP 주소를 보고 통신합니다. DNS는 사람이 읽는 이름을 컴퓨터가 이해하는 주소로 바꿔주는 시스템이며, 흔히 인터넷의 전화번호부에 비유됩니다.

예를 들어 친구 집 주소를 "서울시 어딘가"가 아니라 정확한 도로명 주소로 찾아가듯이, 브라우저도 도메인을 실제 서버 주소로 바꿔야 접속할 수 있습니다. 그래서 사용자는 도메인만 입력하지만, 내부적으로는 DNS 조회가 먼저 일어납니다.

우리가 기억하기 쉬운 이름과, 컴퓨터가 통신하기 쉬운 숫자 주소 사이를 연결해주는 기본 인프라가 바로 DNS입니다.

CDN의 역할

CDN은 Content Delivery Network의 약자로, 사용자와 가까운 위치에서 콘텐츠를 전달하기 위한 분산 네트워크입니다. 쉽게 말해 본사 창고 하나에서 전국 배송을 다 처리하는 대신, 여러 지역 물류센터에 자주 쓰는 물건을 미리 배치해 두는 방식이라고 보면 됩니다.

예를 들어 한국 서버에 있는 이미지 파일을 미국 사용자가 요청하면 멀리 있는 원본 서버까지 왕복해야 해서 느릴 수 있습니다. 하지만 CDN이 있으면 미국 근처 엣지 서버가 캐시된 이미지를 바로 전달해서 속도를 크게 줄일 수 있습니다.

CDN은 특히 아래 같은 정적 자산에서 효과가 큽니다.

• 이미지
• CSS
• JavaScript
• 폰트
• 동영상 일부 콘텐츠

즉, CDN은 서버를 대체하는 것이 아니라 서버 앞에서 "무거운 정적 파일 배달"을 대신해주는 역할에 가깝습니다. 그래서 서버 부하를 줄이고, 사용자 체감 속도를 높이고, 글로벌 접속 성능을 개선하는 데 매우 중요합니다.

클라우드플레어(Cloudflare)

많은 사람이 Cloudflare를 그냥 CDN 회사 정도로만 생각하지만, 실제로는 DNS, CDN, 보안, 애플리케이션 서비스까지 포함한 넓은 플랫폼에 가깝습니다. Cloudflare는 DNS, 캐싱, 보안 서비스뿐 아니라 Workers, R2 같은 개발자용 서비스도 함께 제공합니다.

쉽게 비유하면 Cloudflare는 내 서버 앞에 서 있는 거대한 스마트 경비실입니다. 누가 들어오려는지 먼저 확인하고, 자주 찾는 파일은 대신 꺼내주고, 이상한 공격은 막고, 필요하면 간단한 로직도 앞단에서 실행합니다.

그래서 Cloudflare를 이야기할 때는 보통 아래 개념이 함께 따라옵니다.

• DNS 관리
• CDN 및 캐싱
• WAF(웹 방화벽)
• DDoS 방어
• Workers (서버리스 엣지 실행)
• R2 (오브젝트 스토리지, 전송 요금 없음)

즉, Cloudflare는 "서버 컴퓨터를 빌려주는 회사"라기보다 인터넷 앞단을 빠르고 안전하게 만들어주는 플랫폼으로 이해하는 편이 더 정확합니다.

로드밸런서의 역할

서버가 1대뿐이면 모든 요청이 그 서버 하나로 들어갑니다. 이 방식은 단순하지만, 접속자가 늘어나면 그 서버가 버티지 못하거나 죽는 순간 서비스 전체가 멈춥니다.

로드밸런서는 들어오는 요청을 여러 서버에 나눠주는 장치입니다. 은행 창구에서 한 곳에 줄이 몰리면 안내 직원이 다른 창구로 사람들을 분산시키는 것과 비슷합니다.

예를 들어 서버가 3대 있다면 로드밸런서는 상황에 따라 이런 결정을 합니다.

• 지금 CPU가 여유 있는 서버로 보냅니다.
• 응답 속도가 빠른 서버로 보냅니다.
• 죽은 서버에는 보내지 않습니다.
• 특정 사용자를 같은 서버로 유지시킵니다.

이 개념이 중요한 이유는 "서버를 여러 대 두는 것"과 "트래픽을 여러 대에 잘 나눠 보내는 것"은 다른 문제이기 때문입니다. 서버를 늘렸는데 분산 장치가 없으면 사실상 의미가 반감됩니다.

클라우드에서 인스턴스란?

클라우드에서 자주 나오는 인스턴스라는 말은 어렵게 들리지만, 사실상 "가상 컴퓨터 한 대"라고 이해하면 됩니다. 즉, 물리 서버를 직접 사는 대신 클라우드 업체가 가상화해서 빌려주는 서버 1대를 인스턴스라고 부릅니다.

예를 들어 아래는 모두 인스턴스입니다.

• 리눅스가 설치된 가상 서버 1대
• CPU 2코어, RAM 4GB인 서버 1대
• 퍼블릭 IP가 붙은 VM 1대

중요한 건 인스턴스는 그냥 빈 작업장이라는 점입니다. 그 위에 직접 프로그램을 설치할 수도 있고, 도커를 설치해서 컨테이너를 띄울 수도 있고, 쿠버네티스의 노드로 등록할 수도 있습니다.

즉, 인스턴스는 역할이 정해진 기술이 아니라 기반이 되는 컴퓨터 한 대라고 생각하면 됩니다.

도커의 필요성

도커가 등장하기 전에는 이런 문제가 흔했습니다.

• 내 컴퓨터에서는 실행됩니다.
• 서버에서는 라이브러리 버전이 달라서 안 됩니다.
• 운영체제 차이 때문에 동작이 다릅니다.
• 배포할 때마다 환경 세팅이 꼬입니다.

도커는 이런 문제를 줄여줍니다. 애플리케이션, 라이브러리, 설정을 하나의 이미지로 묶고, 그 이미지를 컨테이너로 실행하면 어느 서버에서나 거의 같은 방식으로 동작합니다.

쉽게 말하면, 도커 이미지는 조리법과 재료가 모두 담긴 밀키트이고, 컨테이너는 그 밀키트를 실제로 조리해서 돌아가는 주방이라고 볼 수 있습니다.

그래서 도커의 핵심 장점은 다음과 같습니다.

• 실행 환경 일관성
• 배포 편의성
• 빠른 재현성
• 서비스 분리
• 확장성 기반 마련

도커 컴포즈

서비스는 보통 하나의 컨테이너로 끝나지 않습니다. 프론트엔드, 백엔드, DB, Redis처럼 여러 구성 요소가 함께 필요합니다.

이럴 때 Docker Compose를 쓰면 한 파일 안에 여러 서비스를 정의하고 한 번에 올릴 수 있습니다. 즉, "웹 1개, API 1개, DB 1개, 캐시 1개"를 각각 손으로 입력하지 않고 묶어서 실행하는 방식입니다.

초기 개발이나 소규모 운영에서는 이 방식이 매우 강력합니다. 구성이 단순하고, 디버깅이 쉽고, 학습 난이도도 낮아서 개인 프로젝트나 MVP에 특히 잘 맞습니다.

쿠버네티스란?

컨테이너가 2개, 3개일 때는 손으로 관리할 수 있습니다. 하지만 서비스가 커져서 컨테이너가 수십 개, 수백 개가 되면 사람이 직접 관리하는 방식은 곧 한계에 부딪힙니다.

그래서 필요한 것이 Kubernetes입니다. 쿠버네티스는 컨테이너를 여러 서버에 자동으로 배치하고, 죽으면 다시 띄우고, 필요하면 개수를 늘리고 줄이는 오케스트레이션 플랫폼입니다.

즉, 도커가 "상자를 만드는 기술"이라면, 쿠버네티스는 "그 상자들을 대규모로 배치하고 운영하는 시스템"입니다. 이 둘은 경쟁 관계라기보다 역할이 다른 계층이라고 보는 편이 이해에 가깝습니다.

노드, 파드, 디플로이먼트

쿠버네티스를 이해할 때 가장 많이 헷갈리는 부분이 여기입니다. 용어를 너무 추상적으로 외우면 어렵지만, 역할로 보면 생각보다 단순합니다.

노드는 쿠버네티스 클러스터에 소속된 서버 1대입니다. 클라우드에서는 인스턴스 1대가 노드 1개와 거의 대응한다고 보면 됩니다.

파드는 쿠버네티스가 컨테이너를 배포하는 최소 단위입니다. 실무에서는 "컨테이너를 직접 뿌린다"기보다 "파드를 만든다"는 표현을 더 많이 씁니다.

디플로이먼트는 원하는 상태를 선언하는 객체입니다. 예를 들어 "백엔드 파드를 항상 3개 유지해라" 같은 지시를 쿠버네티스에게 전달하는 문서라고 생각하면 됩니다.

즉, 노드는 서버, 파드는 실행 단위, 디플로이먼트는 유지해야 할 목표 상태입니다.

마스터 노드와 워커 노드

쉽게 말하면 역할은 이렇습니다.

컨트롤 플레인(마스터 노드)

• 클러스터의 두뇌입니다.
• 전체 상태를 관리합니다.
• 스케줄링 결정을 내립니다.
• API 서버를 제공합니다.
• 원하는 상태와 실제 상태를 비교합니다.

워커 노드

• 실제 애플리케이션을 실행합니다.
• 파드가 올라가는 서버입니다.
• CPU와 메모리를 직접 사용합니다.
• 사용자 요청을 실제로 처리합니다.

여기서 중요한 포인트는 마스터 노드가 사용자 요청을 직접 처리하는 메인 실행 서버가 아니라는 점입니다. 즉, 워커 노드가 현장 직원이라면, 마스터 노드는 본사 통제실에 가깝습니다.

서비스와 인그레스

쿠버네티스에서는 파드가 자주 재생성되고 IP도 바뀔 수 있습니다. 이 상태에서 외부가 파드 하나하나를 직접 바라보면 연결이 매우 불안정해집니다.

그래서 Service라는 개념이 필요합니다. Service는 여러 파드를 하나의 고정된 접근 지점처럼 묶어주는 역할을 합니다.

그리고 외부 HTTP 요청을 좀 더 정교하게 라우팅할 때는 Ingress를 씁니다. 예를 들어 /api는 백엔드로 보내고, /admin은 관리자 서비스로 보내는 식의 규칙을 인그레스 계층에서 관리할 수 있습니다.

즉, Service는 내부 연결의 안정성을 주고, Ingress는 외부 HTTP 진입 규칙을 담당한다고 보면 됩니다.

쿠버네티스의 진짜 강점

쿠버네티스를 배우는 이유는 단순히 있어 보여서가 아닙니다. 실제로 운영에서 가장 큰 장점은 자동 확장과 자동 복구입니다.

예를 들면 이런 상황이 가능합니다.

• 백엔드 파드 1개가 죽으면 새 파드를 자동 생성합니다.
• CPU 사용량이 높아지면 파드 수를 자동으로 증가시킵니다.
• 노드 1대가 죽으면 다른 노드로 재배치합니다.
• 배포 중 일부 장애가 생겨도 롤백합니다.

이런 특성 때문에 서비스가 커질수록 쿠버네티스의 가치가 높아집니다. 반대로 서버 1대, 컨테이너 몇 개 수준이라면 오히려 도입 비용이 더 크게 느껴질 수도 있습니다.

1단계: 로컬에서 도커

가장 먼저는 로컬 PC에 Docker를 설치하고 컨테이너 1~2개를 띄워보는 단계입니다. 이 단계에서 이미지, 컨테이너, 볼륨, 네트워크 개념을 익히는 것이 중요합니다.

권장 스펙입니다.

• 최소 CPU: 4코어
• 최소 RAM: 8GB
• 권장 RAM: 16GB
• 저장장치: SSD 권장

2단계: Docker Compose

그다음에는 프론트엔드, 백엔드, DB를 Compose로 묶어봅니다. 이 단계에서 "서비스 여러 개가 함께 돌아가는 운영 감각"을 익힐 수 있습니다.

이 시점부터는 16GB RAM이 있으면 훨씬 편합니다. 브라우저, IDE, DB 컨테이너, 백엔드, 프론트엔드까지 같이 띄우면 8GB는 꽤 빠듯해집니다.

3단계: 로컬 쿠버네티스

이후 minikube, kind, k3s, Docker Desktop Kubernetes 같은 도구로 쿠버네티스를 경험해봅니다. 이 단계에서는 Pod, Deployment, Service, Ingress 같은 쿠버네티스 객체를 직접 만져보는 것이 핵심입니다.

권장 스펙입니다.

• CPU: 6~8코어 이상
• RAM: 16GB 이상
• 여유가 있으면 32GB가 훨씬 쾌적합니다.
• SSD는 필수에 가깝습니다.

4단계: 홈랩 멀티 노드

구조를 제대로 체감하고 싶다면 소형 PC 여러 대로 멀티 노드 환경을 만드는 방법도 있습니다. 예를 들어 N100 기반 미니 PC 3대를 두고 1대는 컨트롤 플레인, 2대는 워커 노드로 구성하는 식입니다.

대략 이런 감각으로 보면 됩니다.

• 컨트롤 플레인: 4코어 / RAM 4~8GB
• 워커 노드: 각 4코어 / RAM 8GB 이상
• 전체적으로 SSD가 훨씬 안정적입니다.

언제 도커만으로 충분하고, 언제 쿠버네티스를 고민해야 할까요

도커만으로 충분한 경우

• 서버가 1대 또는 소수입니다.
• 트래픽이 크지 않습니다.
• 운영 인원이 적습니다.
• 배포와 구성 단순성이 중요합니다.
• 빠른 개발과 실험이 우선입니다.

쿠버네티스를 고민할 시점

• 서버가 여러 대로 늘어납니다.
• 서비스가 여러 개로 분리됩니다.
• 무중단 배포가 중요합니다.
• 자동 복구와 자동 확장이 필요합니다.
• 운영 표준화가 필요합니다.

즉, 쿠버네티스는 무조건 상위 호환이라기보다 운영 복잡도를 다루기 위한 도구입니다. 그래서 작은 서비스에선 과한 무기가 될 수 있고, 큰 서비스에선 필수 장비가 됩니다.

총 정리

지금까지 나온 개념을 가장 짧게 다시 정리하면 이렇습니다.

• DNS는 이름을 주소로 바꿔줍니다.
• CDN은 가까운 곳에서 파일을 빠르게 전달합니다.
• Cloudflare는 DNS, CDN, 보안, 엣지 서비스를 묶은 앞단 플랫폼입니다.
• 로드밸런서는 요청을 여러 서버로 분산합니다.
• 인스턴스는 클라우드에서 빌린 컴퓨터 1대입니다.
• Docker는 앱 실행 환경을 컨테이너로 포장합니다.
• Kubernetes는 그 컨테이너들을 대규모로 운영합니다.
• 컨트롤 플레인은 관리, 워커 노드는 실행을 담당합니다.

결국 인프라라는 것은 어려운 단어의 집합이 아닙니다. "사용자의 요청을 얼마나 빠르고 안정적으로 받아서, 적절한 곳에서 처리하고, 장애가 나도 서비스가 계속되게 만들 것인가"에 대한 답을 기술적으로 쌓아 올린 구조입니다.

처음에는 용어가 많아 복잡해 보이지만, DNS는 길 찾기, CDN은 가까운 창고, 로드밸런서는 안내 직원, 인스턴스는 컴퓨터, 도커는 포장 상자, 쿠버네티스는 총괄 관리자라고 생각하면 큰 흐름이 훨씬 쉽게 잡힙니다.