Day 4 - 콘텐츠 전송과 DNS: CloudFront, Route 53, 엣지 서비스

어제까지 서버·스토리지·네트워크라는 "내부 인프라"를 봤다. 오늘은 그 인프라가 만든 콘텐츠를 전 세계 사용자에게 빠르게 전달하는 바깥쪽 서비스다. 핵심은 두 가지 질문이다 — "어떻게 하면 멀리 있는 사용자에게도 빠르게 줄까(CloudFront)"와 "사용자가 도메인 이름을 쳤을 때 어디로 보낼까(Route 53)". 이 둘이 함께 "엣지(Edge)" 서비스를 이룬다.

오늘은 CDN의 원리(CloudFront), DNS의 원리(Route 53), 그리고 둘이 어떻게 협력하는지를 입문 수준으로 정리한다.

거리의 문제: 왜 엣지가 필요한가

서버가 미국 버지니아에 있고 사용자가 서울에 있다면, 데이터는 태평양을 건너 왕복해야 한다. 빛의 속도에도 한계가 있어 물리적 거리는 곧 지연(latency)이 된다. 매번 이미지·동영상·웹페이지를 지구 반대편에서 가져오면 느리다.

이게 왜 큰 문제인지 감이 잘 안 올 수 있다. 한 번 왕복하는 시간은 눈 깜짝할 사이니까. 하지만 웹페이지 하나를 여는 데 필요한 왕복은 한 번이 아니다. HTML을 받아 오면 그 안에 CSS·JavaScript·이미지·폰트가 줄줄이 걸려 있고, 브라우저는 그것들을 또 요청한다. 게다가 연결을 맺는 과정(주소 확인, 연결 수립, 암호화 협상)에서도 왕복이 여러 번 일어난다.

즉 왕복 한 번의 지연이 수십 배로 증폭된다. 거리가 멀면 아무리 서버 성능이 좋아도, 회선이 굵어도 이 왕복 시간은 줄지 않는다. 물리 법칙이기 때문이다.

[ 서울 사용자 → 미국 서버 ]        [ 서울 사용자 → 서울 엣지 ]

  요청 ─── 태평양 ───►             요청 ──► (같은 도시)
  응답 ◄── 태평양 ────             응답 ◄──
  이 왕복이 페이지 하나에          같은 횟수를 왕복해도
  수십 번 반복된다                 누적 지연이 훨씬 작다

해법은 단순하다 — 콘텐츠를 사용자 가까이 미리 가져다 둔다. 이를 위해 AWS는 전 세계에 엣지 로케이션(Edge Location)이라는 작은 거점을 수백 개 운영한다. 사용자는 멀리 있는 본 서버 대신 가장 가까운 엣지에서 콘텐츠를 받는다.

엣지 로케이션은 리전(Region)이나 가용 영역(AZ)과 다른 개념이다. 리전·AZ는 실제 데이터와 연산이 사는 큰 데이터센터 클러스터이고, 엣지 로케이션은 콘텐츠를 캐싱(임시 저장)해 사용자에게 가깝게 전달하는 훨씬 작고 훨씬 많은 거점이다.

CDN 이전과 이후

CDN이 없던 시절, 전 세계 사용자를 상대하는 회사에게는 두 가지 선택지뿐이었다. 하나는 참는 것 — 서버를 본사 근처 한 곳에 두고 먼 나라 사용자는 느린 걸 감수한다. 다른 하나는 나라마다 서버를 직접 세우는 것이다. 미국·유럽·아시아에 데이터센터를 빌리고, 같은 파일을 세 벌 올려 두고, 파일이 바뀔 때마다 세 곳을 모두 갱신한다. 비용도 크지만 무엇보다 "어디를 갱신했고 어디를 안 했는지"를 사람이 관리해야 했다.

CDN은 이 둘을 모두 대체한다. 원본은 한 곳에만 두고, 복제는 CDN이 알아서 하며, 원본이 바뀌면 캐시가 만료되면서 자연스럽게 새 내용으로 갈린다.

국내 쇼핑몰이 해외 진출을 준비한다고 가정한다. 상품 이미지 수십만 장이 서울 리전의 S3에 있다. 해외에 서버를 새로 세우는 대신 CloudFront를 앞에 붙이면, 원본은 그대로 서울에 두고도 미국·유럽 사용자가 자기 나라 엣지에서 이미지를 받는다. 앞단에 한 겹을 얹은 것뿐인데 체감 속도가 달라진다.

CloudFront: AWS의 CDN

CloudFront는 AWS의 CDN(Content Delivery Network)이다. CDN은 콘텐츠를 전 세계 엣지 로케이션에 캐싱해 사용자에게 가까운 곳에서 빠르게 전달하는 서비스다.

동작을 한 흐름으로 보면:

1. 사용자가 콘텐츠(예: 이미지)를 요청한다.
2. 가장 가까운 엣지 로케이션이 그 콘텐츠를 캐시에 가지고 있으면 즉시 준다(캐시 히트).
3. 없으면 엣지가 원본(Origin, 예: S3 버킷이나 EC2)에서 한 번 가져와 사용자에게 주고, 동시에 캐시에 저장해 둔다.
4. 다음 사용자는 엣지의 캐시에서 빠르게 받는다.

CloudFront의 이점은 속도만이 아니다. 원본 서버의 부하를 줄여 주고(요청을 엣지가 흡수), HTTPS·DDoS 방어(AWS Shield) 같은 보안 기능도 엣지에서 제공한다.

동영상 스트리밍 서비스가 인기 영상을 전 세계에 빠르게 제공하려 한다. 원본 영상은 S3에 두고 CloudFront를 앞에 붙이면, 서울 사용자는 서울 인근 엣지에서, 런던 사용자는 런던 인근 엣지에서 받는다. 원본 S3는 처음 한 번씩만 부담하고, 이후 대부분의 트래픽은 엣지가 흡수한다.

CloudFront는 정적 콘텐츠(이미지·동영상·CSS)뿐 아니라 동적 콘텐츠도 전달할 수 있고, AWS Shield(DDoS 방어)·AWS WAF(웹 방화벽)와 결합해 보안 계층 역할도 한다. 입문 수준에서는 "CloudFront = 빠른 전달 + 원본 보호"로 기억하면 된다.

캐시 히트·미스와 TTL

CloudFront를 이해하는 데 필요한 개념은 사실상 이 두 단어로 끝난다.

캐시 히트(Cache Hit)는 사용자가 요청한 콘텐츠가 이미 엣지에 있어서 곧바로 응답하는 경우다. 원본까지 갈 필요가 없으니 가장 빠르고, 원본 서버는 아무 일도 하지 않는다.

캐시 미스(Cache Miss)는 엣지에 없어서 원본까지 다녀오는 경우다. 느리지만 그 대가로 콘텐츠가 엣지에 저장되므로 다음 사람부터는 히트가 된다.

여기서 TTL(Time To Live)이 등장한다. 엣지에 저장한 콘텐츠를 얼마 동안 "아직 최신"이라고 믿을지 정하는 시간이다.

그래서 실무에서는 성격에 따라 TTL을 다르게 준다. 로고 이미지처럼 거의 안 바뀌는 파일은 길게, 자주 갱신되는 페이지는 짧게 잡는다. 그리고 급하게 바꿔야 할 때는 "무효화(Invalidation)"로 캐시를 강제로 비운다.

⚠️ 함정: "웹사이트를 수정했는데 반영이 안 된다"는 CDN 초보자가 가장 자주 겪는 일이다. 원본은 이미 바뀌었지만 엣지의 캐시가 아직 살아 있어서 옛 파일이 나가는 것이다. 서버 문제도 배포 실패도 아니며, TTL이 지나기를 기다리거나 무효화를 실행하면 해결된다.

CloudFront는 속도만이 아니다 — 보안이라는 두 번째 얼굴

CloudFront를 "빠르게 해 주는 것"으로만 기억하면 시험에서 절반을 놓친다. 엣지가 사용자와 원본 사이에 서면 보안 관문이 하나 생기기 때문이다.

• HTTPS 암호화: 사용자와 엣지 사이 통신을 암호화하고, 인증서를 엣지에서 처리한다.
• AWS Shield(DDoS 방어): 대량 트래픽 공격이 원본에 닿기 전에 엣지에서 흡수된다. 기본 수준의 보호는 CloudFront에 기본 적용된다.
• AWS WAF(웹 방화벽) 연계: SQL 인젝션 시도 같은 악성 요청을 엣지에서 걸러 낸다.
• 원본 감추기: 사용자는 CloudFront 주소만 알고 원본 S3·서버 주소는 모른다. 원본이 CloudFront를 통해서만 접근되도록 막을 수도 있다.

이 구조가 보장하는 것은 "공격도, 트래픽도 원본까지 오지 못한다"는 것이다. 원본은 엣지가 캐시 미스로 물어볼 때만 일한다. 그래서 CloudFront는 성능 서비스이면서 동시에 원본 보호 장치이고, "원본 부하를 줄이고 싶다"거나 "DDoS로부터 보호하고 싶다"는 표현에도 답이 될 수 있다.

Route 53: AWS의 DNS

사용자는 54.239.28.85 같은 IP 주소가 아니라 example.com 같은 이름으로 사이트를 찾는다. 이 도메인 이름을 실제 IP 주소로 바꿔 주는 전화번호부가 DNS(Domain Name System)이고, AWS의 DNS 서비스가 Route 53이다.

Route 53이 하는 세 가지 큰 일:

"Route 53"이라는 이름의 53은 DNS가 사용하는 표준 포트 번호(53번)에서 왔다. DNS는 인터넷의 가장 기초 인프라 중 하나로, 이름을 주소로 바꾸는 첫 단계다.

DNS를 처음부터 — 인터넷의 전화번호부

DNS가 생소하다면 전화번호부를 떠올리면 정확하다. 사람 이름은 기억하기 쉽지만 번호는 어려워서, 우리는 이름을 찾아 번호를 얻는다. 인터넷도 똑같다. 컴퓨터끼리는 숫자 주소(IP)로만 통신하는데 사람은 그 숫자를 외울 수 없다. 그래서 이름을 주소로 바꿔 주는 조회 시스템이 필요했고, 그것이 DNS다.

주소창에 www.example.com을 치고 엔터를 누르면 실제로는 이런 일이 벌어진다.

1. 브라우저 "www.example.com이 어디죠?"
2. DNS가 조회해서 응답  "93.184.x.x 입니다"
3. 브라우저가 그 주소로 실제 연결을 맺고 페이지를 받아 온다

중요한 것은 DNS가 페이지를 주지 않는다는 점이다. DNS는 주소만 알려 주고 물러난다. 콘텐츠를 실제로 주고받는 것은 그 다음 단계다. 이 구분이 뒤에서 CloudFront와 Route 53을 가르는 기준이 된다.

도메인 이름은 오른쪽에서 왼쪽으로 읽으면 구조가 보인다.

그리고 "이 이름을 무엇으로 연결할지" 적어 둔 항목을 레코드(Record)라고 부른다. 입문 수준에서는 종류를 다 외울 필요 없이 "이름 → 대상"을 적어 둔 한 줄이라고 이해하면 충분하다.

도메인은 사는 것이 아니라 빌리는(등록하는) 것이다. 보통 1년 단위로 등록비를 내며 사용권을 갱신한다. Route 53은 이 등록까지 한 곳에서 처리할 수 있어서, 도메인을 사고 DNS를 설정하고 AWS 자원에 연결하는 과정이 하나로 이어진다.

⚠️ 함정: DNS 설정을 바꿔도 즉시 전 세계에 반영되지는 않는다. 각 레코드에도 TTL이 있어 여러 DNS 서버와 사용자 기기가 그 시간 동안 이전 응답을 기억하기 때문이다. "DNS를 바꿨는데 왜 아직 옛 서버로 가는가"의 답은 거의 항상 캐싱된 응답이 아직 만료되지 않았다는 것이다.

라우팅 정책 — 어디로 보낼지 정하는 규칙

Route 53은 단순히 이름을 주소로 바꾸는 데 그치지 않고, "같은 도메인을 상황에 따라 다른 곳으로 보내는" 정책을 제공한다. 입문 수준에서는 종류가 있다는 것만 알면 된다.

🎯 시나리오: "미국과 유럽 양쪽에 서버를 두고, 각 사용자를 가장 빠른 쪽으로 보내고 싶다." → Route 53의 지연 시간(Latency) 기반 라우팅. 사용자에게 응답이 가장 빠른 리전으로 자동 연결한다. "주 서버가 죽으면 예비로 넘기고 싶다"면 장애 조치(Failover) 정책이다.

각 정책이 태어난 상황

표만 봐서는 다섯 개가 비슷비슷해 보인다. 각각이 어떤 곤란함을 풀려고 생겼는지 상황으로 붙여 두면 헷갈리지 않는다.

단순(Simple) — "서버가 한 대뿐이다." 이름 하나에 대상 하나. 작은 사이트는 대개 여기서 시작한다.

가중치(Weighted) — "새 버전을 전체 사용자에게 한 번에 열기는 무섭다." 트래픽의 10%만 새 버전으로 보내 보고, 문제가 없으면 30%, 50%로 올린다. 서버 성능이 달라 부하를 다르게 나눌 때도 쓴다.

지연 시간(Latency) — "각 사용자를 가장 빠른 서버로 보내고 싶다." 사용자의 위치가 아니라 실제 응답 속도를 기준으로 고른다는 점이 핵심이다.

장애 조치(Failover) — "주 서버가 죽어도 서비스는 계속돼야 한다." 상태 확인과 짝을 이뤄 주 서버가 응답하지 않으면 예비로 넘긴다. 재해 복구 구성의 기본형이다.

지리(Geolocation) — "나라별로 다른 것을 보여 줘야 한다." 언어가 다르거나, 나라별 법규 때문에 콘텐츠를 나눠야 할 때 쓴다.

함정: 지연 시간 기반과 지리 기반을 혼동하기 쉽다. 지연 시간은 "가장 빠른 곳으로 보낸다"이고, 지리는 "어느 나라에서 왔는지에 따라 정해진 곳으로 보낸다"이다. 문항에 "성능·지연 최소화"가 있으면 지연 시간, "국가별 콘텐츠·규정 준수"가 있으면 지리다.

게임 회사가 한국과 북미에 각각 서버를 둔다고 가정한다. 접속 속도만 생각하면 지연 시간 기반이 맞다. 그런데 국가별로 게임 등급과 결제 방식이 달라 반드시 자국 서버에 접속해야 한다면 지리 기반이 답이다. 같은 인프라라도 요구사항이 "빠르게"냐 "규정대로"냐에 따라 정책이 달라진다.

CloudFront + Route 53: 함께 일하는 그림

두 서비스는 따로가 아니라 보통 함께 쓰인다. 흐름을 합쳐 본다.

사용자가 도메인을 입력하면 → Route 53이 "이 이름은 CloudFront로 가라"고 안내하고 → CloudFront가 가장 가까운 엣지에서 콘텐츠를 주며 → 엣지에 없을 때만 원본(S3·EC2)을 찾아간다. 이 조합으로 "이름 해석은 Route 53, 빠른 전달은 CloudFront, 원본 보관은 S3"라는 역할 분담이 완성된다.

함정: CloudFront(CDN)와 Route 53(DNS)을 혼동하기 쉽다. CloudFront는 "콘텐츠를 빠르게 전달"하고, Route 53은 "이름을 주소로 변환"한다. 둘 다 엣지 인프라를 쓰지만 하는 일이 다르다. "지연 시간을 줄이려 콘텐츠를 캐싱" = CloudFront, "도메인을 가장 가까운 리전으로 라우팅" = Route 53.

AWS Global Accelerator — 세 번째 이름

엣지 이야기에서 하나 더 등장하는 이름이 AWS Global Accelerator다. CloudFront와 헷갈리기 쉬우니 자리만 잡아 둔다.

CloudFront가 콘텐츠를 엣지에 복사해 두는 방식이라면, Global Accelerator는 복사하지 않고 가는 길만 개선하는 방식이다. 사용자는 가까운 엣지로 진입한 뒤 AWS의 글로벌 네트워크를 타고 원본 리전까지 간다. 붐비는 일반 인터넷 대신 전용 고속도로를 타는 것에 가깝다.

입문 수준에서는 "캐싱이라는 단어가 보이면 CloudFront, 캐싱할 게 없는 실시간·비HTTP 트래픽이면 Global Accelerator" 정도의 구분이면 충분하다. CLF-C02에서 Global Accelerator는 깊게 나오지 않지만, 보기에 함께 등장할 때 흔들리지 않으려면 이 한 줄을 알고 있어야 한다.

시험에 이렇게 나온다 — 키워드 → 정답 매핑

엣지 서비스 문항은 키워드 대응이 특히 잘 통한다.

함정: 헷갈리기 쉬운 지점은 "가장 가까운 곳으로 보낸다"는 표현이다. 이 말만으로는 CloudFront와 Route 53을 가를 수 없다. 콘텐츠를 저장해 두고 주는 이야기면 CloudFront, 어느 주소로 갈지 알려 주는 이야기면 Route 53이다.

정리

오늘의 두 주인공은 거리 문제를 푸는 한 쌍이다. CloudFront는 CDN — 콘텐츠를 전 세계 엣지 로케이션에 캐싱해 사용자에게 가까운 곳에서 빠르게 전달하고, 동시에 원본 서버를 보호한다. Route 53은 DNS — 도메인 이름을 IP·AWS 자원으로 바꿔 주며, 가중치·지연 시간·장애 조치 같은 라우팅 정책으로 트래픽을 똑똑하게 보낸다. 둘은 보통 "Route 53이 안내하고 CloudFront가 전달"하는 형태로 협력한다.

오늘 더한 것들을 한 줄씩 붙여 둔다. CloudFront는 캐시 히트가 늘수록 빨라지고 원본은 한가해지며, 그 캐시가 얼마나 오래 사는지를 정하는 것이 TTL이고, 급할 땐 무효화로 비운다. "수정했는데 반영이 안 된다"의 범인은 대개 이 캐시다. 그리고 CloudFront는 성능뿐 아니라 HTTPS·Shield·WAF·원본 감추기라는 보안의 얼굴도 함께 가진다.

DNS 쪽에서는 DNS가 주소만 알려 주고 콘텐츠는 주지 않는다는 점이 모든 구분의 출발점이다. 그래서 "캐싱·전달"이면 CloudFront, "이름 해석·어디로 보낼지"면 Route 53이다. 라우팅 정책 다섯 가지는 이름을 외우기보다 각각이 풀려던 곤란함(한 대뿐 / 조금씩 열기 / 가장 빠르게 / 죽으면 넘기기 / 나라별로)으로 기억하는 편이 훨씬 오래간다.

내일은 이번 주에 배운 핵심 서비스 1(컴퓨팅·스토리지·네트워크·엣지)을 한 장의 큰 그림으로 묶어 복습한다.

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

전 세계 사용자에게 이미지와 동영상을 낮은 지연 시간으로 전달하기 위해, 콘텐츠를 사용자와 가까운 거점에 캐싱하려고 한다. 가장 적합한 서비스는?

• AAmazon Route 53
• BAmazon CloudFront
• CAmazon EBS
• DAWS Lambda

문제 2

사용자가 입력한 도메인 이름(example.com)을 실제 IP 주소나 AWS 자원으로 연결해 주는 AWS 서비스는?

• AAmazon CloudFront
• BAmazon S3
• CAmazon Route 53
• DAmazon VPC

문제 3

미국과 유럽에 각각 서버를 두고, 각 사용자를 응답이 가장 빠른 리전으로 자동 연결하려고 한다. 가장 적합한 Route 53 라우팅 정책은?

• A단순(Simple) 라우팅
• B지연 시간(Latency) 기반 라우팅
• C가중치(Weighted) 라우팅
• D장애 조치(Failover) 라우팅

문제 4

엣지 로케이션(Edge Location)에 대한 설명으로 가장 정확한 것은?

• A리전·가용 영역과 동일한 대형 데이터센터다
• B콘텐츠를 캐싱해 사용자에게 가까이 전달하는, 전 세계에 많이 분산된 거점이다
• C데이터베이스를 영구 저장하는 전용 스토리지다
• DEC2 인스턴스를 실행하는 기본 단위다

문제 5

CloudFront와 Route 53의 역할 차이를 가장 정확히 구분한 것은?

• A둘 다 도메인 이름을 IP로 변환한다
• BCloudFront는 콘텐츠를 캐싱·전달하고, Route 53은 도메인 이름을 주소로 변환한다
• CCloudFront는 DNS이고, Route 53은 CDN이다
• D둘 다 블록 스토리지를 제공한다