서버 주소를 사람이 읽을 수 있게 바꾸기
지난 장까지 우리는 EC2 여러 대를 ALB 뒤에 두고, Auto Scaling Group으로 서버 수를 자동 조절하는 구조를 살펴보았다. 이제 사용자는 브라우저에서 어디로 접속해야 할까?
ALB에는 긴 DNS 이름이 붙는다. 예를 들면 my-alb-123456.ap-northeast-2.elb.amazonaws.com 같은 형태다. 동작은 하지만 서비스 주소로 쓰기에는 불편하다. 사용자는 example.com이나 www.example.com처럼 짧고 기억하기 쉬운 이름을 기대한다.
여기서 필요한 것이 DNS다. DNS는 Domain Name System의 약자로, 도메인 이름을 실제 접속 가능한 주소로 바꿔 주는 인터넷의 주소록이다. 사용자가 브라우저에 www.example.com을 입력하면, 브라우저와 운영체제는 DNS에 "이 이름은 어디로 가야 하나요?"라고 묻는다. DNS는 해당 이름이 가리키는 IP 주소나 다른 도메인 이름을 알려 준다. 그다음 브라우저는 실제 서버, 로드 밸런서, CDN 같은 대상에 접속한다.
도메인은 간판이고, DNS는 간판을 보고 실제 건물 위치를 알려 주는 안내 데스크라고 생각하면 쉽다.
AI 생성 이미지
DNS가 동작하는 기본 흐름
DNS 조회 과정은 복잡해 보이지만 핵심은 단순하다.
사용자가
www.example.com을 입력한다.브라우저가 DNS 해석기에 주소를 물어본다.
DNS는 이 도메인을 관리하는 권한 있는 서버를 찾는다.
해당 서버가
www.example.com이 가리키는 대상 값을 알려 준다.브라우저가 그 대상에 접속한다.
이때 DNS 응답은 일정 시간 동안 저장된다. 이를 캐시라고 한다. 캐시는 매번 주소록을 다시 찾지 않아도 되게 해 속도를 높인다. 하지만 도메인 설정을 바꿨을 때 즉시 반영되지 않는 이유도 캐시 때문이다.
TTL도 함께 알아 두자. TTL은 Time To Live의 약자로, DNS 응답을 얼마 동안 캐시에 보관할지 정하는 값이다. TTL이 300초라면 DNS 응답을 대체로 5분 정도 재사용할 수 있다는 뜻이다. 운영 중 도메인 대상을 자주 바꿀 예정이라면 TTL을 너무 길게 잡지 않는 것이 좋다. 반대로 안정적인 운영 환경에서는 적절히 긴 TTL이 DNS 조회 부담을 줄이는 데 도움이 된다.
DNS 변경은 "저장 버튼을 누르는 순간 전 세계에서 바로 바뀐다"기보다는, 기존 캐시가 사라지고 새 응답을 받아 가면서 점차 반영된다고 이해하면 된다.
Route 53은 AWS의 DNS 관리 서비스다
Route 53은 AWS에서 제공하는 DNS 서비스다. 도메인을 구매하거나, 이미 가지고 있는 도메인의 DNS 레코드를 관리하거나, AWS 리소스와 도메인을 연결할 때 사용한다.
Route 53에서 가장 먼저 만나는 개념은 호스팅 영역이다. 호스팅 영역은 특정 도메인의 DNS 설정을 담는 공간이다. 예를 들어 example.com이라는 도메인을 운영한다면, example.com에 대한 호스팅 영역을 만들고 그 안에 여러 레코드를 추가한다.
레코드는 "이 이름은 어디를 가리킨다"라는 규칙이다.
자주 쓰는 레코드는 다음과 같다.
A레코드: 도메인 이름을 IPv4 주소로 연결한다.AAAA레코드: 도메인 이름을 IPv6 주소로 연결한다.CNAME레코드: 한 도메인 이름을 다른 도메인 이름으로 연결한다.TXT레코드: 도메인 소유권 검증, 이메일 보안 설정 등에 쓰이는 텍스트 값을 저장한다.NS레코드: 이 도메인을 어떤 DNS 서버가 관리하는지 나타낸다.
AWS를 사용할 때는 Alias 레코드도 중요하다. Alias는 Route 53이 제공하는 특별한 연결 방식이다. 일반적인 A 레코드는 IP 주소를 적지만, AWS에서는 ALB나 CloudFront처럼 뒤에서 사용하는 IP가 바뀔 수 있는 리소스가 많다. 이때 Alias를 사용하면 example.com을 ALB나 CloudFront 배포에 직접 연결할 수 있다.
조금 더 정확히 말하면, Alias는 별도의 표준 DNS 레코드 타입이라기보다는 Route 53이 A 또는 AAAA 레코드에서 제공하는 확장 기능에 가깝다. 사용자는 IP 주소를 직접 관리하지 않고 AWS 리소스를 대상으로 선택할 수 있다.
특히 example.com처럼 앞에 www가 없는 루트 도메인은 일반적인 CNAME으로 연결하기 어렵다. 이때 Route 53의 Alias가 유용하다.
도메인을 ALB에 연결하는 흐름
ALB 앞에 도메인을 붙이는 기본 흐름은 다음과 같다.
도메인을 준비한다.
Route 53에 퍼블릭 호스팅 영역을 만든다.
도메인의 네임서버를 Route 53 호스팅 영역의 NS 값으로 설정한다.
www.example.com또는example.com레코드를 만든다.레코드 대상을 ALB로 지정한다.
브라우저에서 도메인으로 접속해 확인한다.
여기서 퍼블릭 호스팅 영역은 인터넷 사용자들이 조회할 수 있는 DNS 영역이다. 반대로 프라이빗 호스팅 영역은 VPC 내부에서만 쓰는 이름을 관리할 때 사용한다. 이 장에서는 외부 사용자에게 웹 서비스를 공개하는 상황이므로 퍼블릭 호스팅 영역을 기준으로 생각하면 된다.
도메인을 Route 53에서 구매했다면 네임서버 연결이 자동으로 맞춰져 있는 경우가 많다. 반대로 다른 등록기관에서 구매한 도메인이라면, 그 등록기관의 관리 화면에서 네임서버 값을 Route 53 호스팅 영역의 NS 값으로 바꿔야 한다. 이 설정이 맞지 않으면 Route 53에 레코드를 잘 만들어도 인터넷 사용자는 그 값을 조회하지 못한다.
중요한 점은 DNS가 보안을 대신하지 않는다는 것이다. 도메인을 연결했다고 해서 ALB나 서버가 안전해지는 것은 아니다. ALB의 보안 그룹은 필요한 포트만 열어야 하고, EC2는 가능한 한 직접 공개하지 않는 구조가 좋다. 사용자는 도메인으로 ALB에 접속하고, ALB만 프라이빗 서브넷의 애플리케이션 서버로 요청을 전달하는 구성이 더 안전하다.
CDN은 사용자 가까이에 콘텐츠를 둔다
도메인을 연결하면 접속은 쉬워진다. 하지만 사용자가 전 세계에 있다면 속도 문제가 생긴다.
예를 들어 애플리케이션 서버가 서울 리전에 있는데, 미국이나 유럽 사용자가 접속한다고 생각해 보자. 요청과 응답은 먼 거리를 오가야 한다. HTML, 이미지, CSS, JavaScript 파일처럼 자주 바뀌지 않는 정적 콘텐츠까지 매번 원본 서버에서 받아 오면 속도가 느려지고 서버 부담도 커진다.
CDN은 Content Delivery Network의 약자로, 콘텐츠 전송 네트워크라는 뜻이다. CDN은 전 세계 여러 지점에 콘텐츠를 임시로 저장해 두고, 사용자와 가까운 위치에서 응답한다. AWS에서는 CloudFront가 이 역할을 한다.
CloudFront에서 사용자 가까이에 있는 지점을 엣지 로케이션이라고 부른다. 사용자가 이미지를 요청하면 CloudFront는 먼저 가까운 엣지 로케이션에 그 이미지가 있는지 확인한다. 있으면 바로 응답한다. 없으면 원본으로 가서 가져온 뒤 엣지에 저장하고 사용자에게 전달한다.
원본은 오리진이라고 부른다. 오리진은 S3 버킷일 수도 있고, ALB일 수도 있고, 외부 HTTP 서버일 수도 있다.
CloudFront가 필요한 대표 상황
CloudFront는 단순히 "빠르게 해 주는 서비스"로만 이해하면 부족하다. 실제 웹 서비스에서는 다음 이유로 자주 사용한다.
첫째, 정적 파일 전송을 빠르게 한다. 이미지, 동영상, CSS, JavaScript 파일은 사용자와 가까운 엣지에서 제공하면 체감 속도가 좋아진다.
둘째, 원본 서버의 부담을 줄인다. 모든 요청이 ALB나 S3로 직접 가지 않고 CloudFront 캐시에서 처리되면 원본 요청 수가 줄어든다.
셋째, HTTPS 적용 지점을 단순화할 수 있다. 사용자는 CloudFront에 HTTPS로 접속하고, CloudFront가 뒤쪽 오리진과 통신한다.
넷째, 공개 범위를 제어하기 쉽다. S3 버킷을 직접 공개하지 않고 CloudFront를 통해서만 접근하게 만들 수 있다. 이때는 S3 퍼블릭 액세스 차단을 유지하고, CloudFront의 Origin Access Control 같은 기능으로 CloudFront만 S3 객체를 읽게 구성한다.
다만 CloudFront도 비용이 발생한다. 데이터 전송량, 요청 수, 무효화 요청 등에 따라 과금될 수 있다. 실습 후에는 배포, S3 객체, ALB 같은 관련 리소스를 함께 확인해야 한다.
캐시는 빠르지만 변경 반영을 늦출 수 있다
CloudFront의 핵심은 캐시다. 캐시는 자주 쓰는 데이터를 가까운 곳에 저장해 두는 방식이다. 같은 파일을 여러 사용자가 요청하면 매번 원본에서 가져오지 않고 CloudFront가 저장해 둔 사본을 응답한다.
문제는 파일을 수정했는데 사용자가 예전 파일을 받을 수 있다는 점이다. 예를 들어 app.js를 새로 배포했지만 CloudFront 엣지에는 이전 app.js가 남아 있을 수 있다.
이를 해결하는 방법은 두 가지다.
첫째, 파일 이름에 버전을 붙인다. 예를 들어 app.js 대신 app.a1b2c3.js처럼 배포할 때마다 파일 이름을 바꾸면 브라우저와 CDN이 새 파일로 인식한다. 실제 프런트엔드 빌드 도구들이 자주 사용하는 방식이다.
둘째, CloudFront 무효화를 사용한다. 무효화는 "이 캐시 파일은 더 이상 쓰지 말고 새로 가져오라"고 알려 주는 작업이다. 급하게 잘못된 파일을 교체해야 할 때 유용하다. 하지만 무효화는 남발하지 않는 것이 좋다. 무효화 요청은 비용이 발생할 수 있고, 많은 파일을 자주 무효화하는 방식은 운영도 번거롭다. 설계상으로는 파일 버전 관리가 더 안정적이다.
API 응답처럼 자주 바뀌는 데이터는 캐시 시간을 짧게 가져가거나 캐시하지 않는 편이 안전하다. 반대로 이미지, 폰트, 빌드된 JavaScript 파일처럼 파일명이 바뀌는 정적 자산은 더 길게 캐시해도 문제가 적다.
HTTPS는 선택이 아니라 기본이다
브라우저 주소창에서 자물쇠 아이콘을 본 적이 있을 것이다. 이것이 HTTPS 연결이다. HTTPS는 사용자의 브라우저와 서비스 사이의 통신을 암호화한다. 로그인, 결제, 개인정보 입력이 있는 서비스라면 필수다. 요즘은 단순한 소개 페이지라도 HTTPS가 기본에 가깝다.
HTTPS를 사용하려면 인증서가 필요하다. 인증서는 "이 도메인은 이 서비스가 사용해도 된다"는 신뢰 증명서와 비슷하다. AWS에서는 ACM, 즉 AWS Certificate Manager로 인증서를 발급하고 관리할 수 있다.
기본 절차는 다음과 같다.
ACM에서 도메인 이름에 대한 인증서를 요청한다.
DNS 검증 방식을 선택한다.
Route 53에 검증용 CNAME 레코드를 추가한다.
인증서가 발급될 때까지 기다린다.
발급된 인증서를 CloudFront 또는 ALB에 연결한다.
CloudFront에 사용할 인증서는 미국 동부(버지니아 북부, us-east-1) 리전에서 발급해야 한다. 반면 ALB에 연결할 인증서는 ALB가 있는 리전에서 준비해야 한다. 초보자가 자주 헷갈리는 부분이므로, 인증서를 만들 때 "어디에 연결할 인증서인가"를 먼저 정하고 시작하는 것이 좋다.
HTTPS를 적용할 때는 사용자가 HTTP로 접속해도 HTTPS로 보내는 리디렉션 설정도 함께 고려한다. 사용자가 http://example.com으로 들어와도 최종적으로 https://example.com에 접속하게 만드는 것이다. CloudFront를 앞에 둔다면 Viewer Protocol Policy에서 HTTP 요청을 HTTPS로 리디렉션하도록 설정할 수 있고, ALB를 직접 사용할 때는 ALB 리스너 규칙에서 리디렉션을 구성할 수 있다.
S3, ALB, CloudFront를 조합한 공개 구조
이제 앞에서 배운 요소를 하나의 웹 서비스 구조로 연결해 보자.
가장 단순한 정적 웹사이트라면 S3와 CloudFront만으로도 충분하다. HTML, CSS, JavaScript, 이미지 파일을 S3 버킷에 저장한다. S3 버킷은 직접 공개하지 않는다. CloudFront를 앞에 두고, 사용자는 CloudFront 도메인이나 연결된 사용자 도메인으로 접속한다. Route 53은 www.example.com을 CloudFront로 연결한다. ACM 인증서는 CloudFront에 붙여 HTTPS를 제공한다.
논리적인 흐름은 다음과 같다.
사용자 → DNS 조회(Route 53) → CloudFront → S3
실제 웹 트래픽이 Route 53을 지나서 흐르는 것은 아니다. Route 53은 사용자가 접속할 CloudFront 주소를 알려 주고, 이후 요청은 사용자의 브라우저와 CloudFront 사이에서 오간다. 처음에는 이 차이를 엄격하게 외우기보다 "Route 53은 이름을 찾아 주고, CloudFront는 콘텐츠를 전달한다" 정도로 이해하면 충분하다.
동적인 기능이 있는 웹 서비스라면 ALB가 함께 들어간다. 정적 파일은 S3에서 제공하고, API 요청은 ALB 뒤의 EC2 또는 Auto Scaling Group으로 보낸다. CloudFront는 경로에 따라 요청을 나눌 수 있다. 예를 들어 /assets/*는 S3로 보내고, /api/*는 ALB로 보내는 식이다.
논리적인 흐름은 다음과 같다.
사용자 → DNS 조회(Route 53) → CloudFront → S3 또는 ALB → EC2
이 구조의 장점은 명확하다. 사용자는 하나의 도메인으로 접속한다. 정적 콘텐츠는 빠르게 전달된다. 애플리케이션 서버는 ALB 뒤에서 확장된다. S3는 직접 공개하지 않아도 된다. HTTPS는 CloudFront에서 일관되게 처리할 수 있다.
실습으로 생각해 보는 연결 순서
실제로 구성할 때는 다음 순서로 접근하면 이해하기 쉽다.
먼저 S3에 간단한 index.html과 이미지 파일을 올린다. 버킷은 기본적으로 비공개로 둔다. 다음으로 CloudFront 배포를 만들고 오리진을 S3로 지정한다. S3를 비공개로 유지하려면 CloudFront에서 Origin Access Control을 설정하고, S3 버킷 정책도 CloudFront가 읽을 수 있도록 맞춰야 한다. 그런 다음 CloudFront 주소로 접속해 파일이 보이는지 확인한다.
그다음 ACM에서 www.example.com 인증서를 요청한다. CloudFront에 붙일 인증서라면 us-east-1 리전에서 요청해야 한다. DNS 검증을 위해 Route 53에 검증 레코드를 추가한다. 인증서가 발급되면 CloudFront에 연결하고, 대체 도메인 이름에 www.example.com을 추가한다.
마지막으로 Route 53에서 www.example.com 레코드를 만들고 CloudFront 배포를 Alias 대상으로 선택한다. 이제 사용자는 CloudFront의 긴 주소를 몰라도 도메인으로 접속할 수 있다.
동적 서버가 필요하다면 이후 ALB를 추가한다. ALB 뒤에는 지난 장에서 만든 Auto Scaling Group을 연결한다. CloudFront의 오리진을 하나 더 추가해 API 경로를 ALB로 보내면 된다.
공개 서비스에서 함께 확인할 것
도메인과 CDN을 붙이면 서비스가 그럴듯해 보인다. 하지만 공개되는 순간 확인할 것도 늘어난다.
보안 측면에서는 S3 버킷이 실수로 전체 공개되어 있지 않은지 확인해야 한다. ALB 보안 그룹은 80번과 443번처럼 필요한 포트만 열고, EC2는 ALB에서 오는 트래픽만 받게 제한하는 것이 좋다. 관리자 접속용 SSH를 인터넷 전체에 열어 두는 구성은 피해야 한다.
비용 측면에서는 CloudFront 데이터 전송량, ALB 실행 시간, Route 53 호스팅 영역 비용, DNS 쿼리 수, S3 요청 수를 확인해야 한다. 각각은 작아 보여도 공개 서비스가 되면 누적될 수 있다. 학습용이라면 실습 후 CloudFront 배포 비활성화와 삭제, S3 객체와 버킷 정리, ALB 삭제, Route 53 호스팅 영역 정리까지 확인하자. 단, 실제로 사용하는 도메인과 DNS 레코드를 지우면 서비스 접속이 끊기므로 학습용 리소스와 운영 리소스를 구분해야 한다.
운영 측면에서는 캐시 정책을 조심해야 한다. 자주 바뀌는 API 응답을 너무 오래 캐시하면 사용자가 오래된 데이터를 볼 수 있다. 반대로 거의 바뀌지 않는 이미지 파일을 매번 원본에서 가져오면 CDN의 장점을 살리지 못한다. 콘텐츠 성격에 따라 캐시 시간을 다르게 설정하는 것이 좋다.
이번 장의 핵심 정리
도메인은 사용자가 서비스를 쉽게 찾게 해 주는 이름이다. DNS는 그 이름을 실제 리소스로 연결한다. Route 53은 AWS에서 도메인과 DNS 레코드를 관리하는 서비스다.
CloudFront는 사용자 가까운 엣지 로케이션에서 콘텐츠를 제공해 속도를 높이고 원본 부담을 줄인다. S3의 정적 파일, ALB 뒤의 애플리케이션 서버와 함께 사용하면 공개 웹 서비스의 기본 구조를 만들 수 있다.
ACM 인증서를 사용하면 HTTPS를 적용할 수 있다. CloudFront용 인증서는 us-east-1에서 준비하고, ALB용 인증서는 ALB가 있는 리전에서 준비한다. 공개 서비스에서는 HTTPS가 기본이며, S3 공개 범위, ALB 보안 그룹, CloudFront 캐시, 비용 알림까지 함께 확인해야 한다.
이제 우리는 사용자가 도메인으로 접속하고, CDN을 통해 빠르게 콘텐츠를 받고, ALB 뒤의 서버로 안정적으로 요청이 전달되는 구조를 만들 수 있게 되었다. 다음 단계에서는 서버를 직접 관리하지 않고도 코드를 실행하는 서버리스 방식을 살펴본다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.