안녕하세요, 멘토 김부장입니다. 사이트 주소 앞에 붙는 자물쇠 표시(https), 다들 한 번쯤 보셨죠? 이게 없으면 요즘 브라우저는 주소창 옆에 "주의 요함" 또는 "안전하지 않음"이라는 경고를 띄웁니다. 어렵게 만든 사이트에 손님이 들어오자마자 빨간 경고 문구를 보면, 대부분 무섭다고 그냥 나가버려요. 그 자물쇠를 달아주는 게 바로 SSL 인증서입니다.
저도 처음엔 "인증서? 무슨 자격증 같은 건가? 돈 주고 사야 하나?" 하고 겁부터 먹었어요. 그런데 막상 해보니 AWS에서는 무료로, 그것도 버튼 몇 번이면 발급이 끝나더라고요. 오늘은 그 과정을 비개발자 눈높이에서, 화면에서 무엇을 누르는지까지 하나하나 손잡고 가보겠습니다.
좋은 소식: AWS에선 이 인증서를 무료로 발급해줍니다. 바로 ACM(AWS Certificate Manager)입니다. "인증서 관리소" 정도로 이해하시면 됩니다.
1. 자물쇠(https)가 대체 뭐길래
먼저 용어부터 쉽게 풀어볼게요. 주소창에 http://로 시작하는 주소와 https://로 시작하는 주소가 있어요. 마지막에 붙은 s 한 글자가 바로 "secure(안전한)"의 s입니다. 이 s가 붙으면 주소창에 작은 자물쇠 아이콘이 뜨고요.
비유를 하나 들어볼게요. 편지를 부친다고 생각해봅시다. http는 엽서예요. 우체부도, 중간에 거쳐가는 모든 사람도 내용을 훤히 들여다볼 수 있죠. 반면 https는 봉인된 등기 우편입니다. 봉투를 뜯을 수 있는 열쇠는 보내는 사람과 받는 사람만 가지고 있어요. 중간에서 누가 편지를 가로채도, 안에는 알아볼 수 없는 암호 덩어리만 들어 있습니다.
한 줄 요약: http는 훤히 보이는 엽서, https는 열쇠로 봉인된 등기 우편입니다. 손님의 비밀번호·카드번호가 오가는 사이트라면 반드시 봉인된 편지를 써야겠죠.
왜 이게 중요할까요? 로그인 비밀번호, 카드번호, 전화번호 같은 민감한 정보가 http로 오가면, 같은 카페 와이파이를 쓰는 옆 사람이 마음만 먹으면 그 정보를 훔쳐볼 수 있습니다. 무섭죠? 그래서 구글 크롬을 비롯한 모든 최신 브라우저가 http 사이트에 "안전하지 않음" 경고를 붙이기 시작한 거예요.
브라우저의 "주의 요함" 경고가 주는 진짜 손해
이 경고는 단순히 보기 싫은 문제가 아닙니다. 실제로 세 가지 손해가 생겨요.
- 신뢰 하락 — 손님 입장에서 "안전하지 않음"이라 쓰인 가게에 카드를 꺼내고 싶을까요? 특히 결제·회원가입 페이지라면 이탈률이 확 올라갑니다.
- 검색 순위 불이익 — 구글은 오래전부터 https 사이트를 검색 결과에서 조금 더 우대한다고 공식적으로 밝혔습니다. http면 손해를 볼 수 있어요.
- 일부 기능 차단 — 위치 정보, 카메라, 결제 API 같은 최신 브라우저 기능은 아예 https에서만 동작합니다. http면 "이 기능은 안전한 연결에서만 됩니다"라며 막혀요.
2. SSL/TLS가 하는 일 — 요리사 비유로
인증서를 발급받기 전에, 이 자물쇠가 안에서 무슨 일을 하는지 아주 얕게만 알아둡시다. 몰라도 발급은 되지만, 알면 나중에 문제가 생겼을 때 훨씬 덜 당황하거든요.
SSL과 TLS는 사실상 같은 걸 부르는 옛 이름과 새 이름입니다. 원래 SSL(Secure Sockets Layer)이라 부르다가, 개량되면서 TLS(Transport Layer Security)로 이름이 바뀌었어요. 지금 실제로 쓰이는 건 전부 TLS인데, 사람들이 습관적으로 "SSL 인증서"라고 부릅니다. 그래서 이 글에서도 편하게 "SSL 인증서"라고 부를게요. 둘은 사실상 같은 말이라고 생각하시면 됩니다.
이 SSL/TLS가 하는 일은 딱 두 가지입니다.
암호화 — 내용을 아무도 못 읽게 봉인
손님 브라우저와 내 서버 사이에 오가는 모든 데이터를 자물쇠로 잠급니다. 중간에서 누가 가로채도 뜻 모를 암호 덩어리만 보여요. 마치 둘만 아는 암호로 편지를 주고받는 것과 같습니다.
신원 확인 — "이 가게가 진짜 그 가게 맞아"
인증서는 "이 도메인은 진짜 이 사람 것이 맞다"는 일종의 신분증 역할도 합니다. 가짜 사이트가 내 주소를 흉내 내는 걸 어렵게 만들어줘요.
요리로 비유해볼게요. 손님이 주방에 "간장게장 하나요!" 하고 주문을 넣습니다. 이 주문서를 남들이 못 알아보게 암호로 적어서 주방에 전달하고(암호화), 주방은 진짜 우리 가게 주방이 맞다는 도장이 찍힌 그릇에 담아 내옵니다(신원 확인). 그래서 옆 테이블 손님이 주문서를 훔쳐봐도 무슨 메뉴인지 모르고, 가짜 배달원이 엉뚱한 음식을 끼워 넣지도 못하는 거죠.
http와 https, 한눈에 비교
| 구분 | http (자물쇠 없음) | https (자물쇠 있음) |
|---|---|---|
| 주소창 표시 | "주의 요함 / 안전하지 않음" 경고 | 자물쇠 아이콘 |
| 데이터 전송 | 암호화 안 됨 (엽서처럼 노출) | 암호화됨 (봉인된 등기) |
| 도청 위험 | 같은 와이파이면 훔쳐볼 수 있음 | 가로채도 암호라 못 읽음 |
| 손님 신뢰 | 결제·가입에서 이탈 증가 | 안심하고 정보 입력 |
| 검색(SEO) | 불이익 가능 | 소폭 우대 |
| 최신 브라우저 기능 | 위치·카메라·결제 등 차단 | 정상 사용 |
결론은 명확합니다. 오늘날 http는 "미완성 사이트"처럼 보이고, https는 "제대로 된 사이트"의 최소 조건입니다. 이제 그 자물쇠를 진짜로 달아봅시다.
3. ACM이 뭐고, 왜 무료인가
ACM(AWS Certificate Manager)은 이름 그대로 AWS의 "인증서 관리소"입니다. 여기서 인증서를 무료로 받아, AWS 안의 로드밸런서나 CloudFront에 붙일 수 있어요.
"공짜라니 뭔가 함정이 있는 거 아냐?" 하실 수 있어요. 저도 그랬습니다. 결론부터 말하면 함정 없습니다. 이유는 이렇습니다.
- 원래도 인증서를 무료로 발급해주는 공인 기관(대표적으로 Let's Encrypt 같은 곳)이 존재합니다. 인증서 발급 자체가 이제는 공공재처럼 무료가 대세예요.
- AWS는 인증서를 무료로 주는 대신, 그 인증서를 AWS 서비스(로드밸런서·CloudFront 등) 안에서만 쓰게 합니다. 즉 AWS를 계속 쓰게 만드는 것이 그들의 이득이죠. 서로 손해 볼 게 없는 구조입니다.
- 대신 ACM에서 받은 인증서는 파일로 내려받아서 다른 회사 서버에 옮겨 붙일 수는 없습니다(딱 한 가지, 유료의 "프라이빗 CA" 경우는 예외지만 초보자와는 무관해요). AWS 안에서 쓰는 조건으로 공짜인 셈이에요.
4. 발급 준비 — 전체 그림 먼저 보기
실전 클릭으로 들어가기 전에, 우리가 앞으로 밟을 흐름을 지도처럼 한 번 펼쳐볼게요. 큰 그림을 알고 있으면 중간에 헤매지 않습니다.
ACM에서
내 주소
소유 확인
몇 분 대기
443 리스너
준비물은 딱 세 가지입니다.
- 도메인 — 예:
myapp.com. 아직 없으면 다음 편(Route 53)에서 사도 됩니다. 이미 있다면 그걸 쓰면 돼요. - 로드밸런서(ALB) — 앞 편에서 만든 그것. 인증서를 붙일 대상입니다.
- 같은 리전 — ALB가 서울 리전에 있다면, 인증서도 서울 리전에서 발급받아야 합니다. (이 부분은 아래 주의점에서 크게 다룹니다.)
5. 따라 하기 — ACM으로 인증서 발급 실전 가이드
자, 이제 진짜 화면을 보며 따라 해봅시다. 저는 서울 리전(ap-northeast-2) 기준으로 설명할게요. 여러분의 로드밸런서가 있는 리전으로 바꿔서 보시면 됩니다.
리전부터 맞춘다 (가장 중요)
AWS 콘솔 오른쪽 위에 지역 이름이 있습니다. 클릭해서 내 로드밸런서가 있는 리전(예: 아시아 태평양(서울))으로 먼저 바꿉니다. 이걸 안 맞추면 발급은 되는데 나중에 ALB에 인증서가 안 보여서 멘붕이 옵니다. 첫 단추부터 확실히!
ACM 서비스 열기
콘솔 위쪽 검색창에 ACM 또는 Certificate Manager를 입력해 들어갑니다. 첫 화면에서 "인증서 요청(Request a certificate)" 파란 버튼을 누릅니다.
공인 인증서 선택
"퍼블릭 인증서 요청(Request a public certificate)"을 고르고 다음으로 넘어갑니다. (프라이빗은 사내용 유료라 우리와 무관해요.) 이게 인터넷 아무나 접속하는 사이트용, 무료 인증서입니다.
도메인 이름 입력
"완전히 정규화된 도메인 이름(FQDN)"란에 내 주소를 적습니다. 예: myapp.com. 여기서 팁 하나 — 아래 "다른 이름 추가"를 눌러 www.myapp.com도 같이 넣거나, 한 번에 여러 서브도메인을 커버하려면 와일드카드 *.myapp.com을 입력하면 편합니다. (와일드카드는 "myapp.com 아래 모든 방 이름"을 한꺼번에 커버하는 만능 열쇠라고 보시면 돼요.)
검증 방식 = DNS 검증 선택
"검증 방법"에서 DNS 검증(DNS validation)을 고릅니다. (이메일 검증도 있지만, DNS 검증이 자동 갱신까지 되기 때문에 훨씬 편합니다. 차이는 아래에서 자세히!)
요청 완료 → "검증 대기" 상태
"요청" 버튼을 누르면 인증서가 목록에 생기는데, 상태가 "검증 대기 중(Pending validation)"으로 뜹니다. 아직 "이 도메인 진짜 네 거 맞아?"를 확인하는 단계예요. 여기서 멈추지 말고 다음 단계로!
Route 53에 검증 레코드 자동 생성
인증서 상세 화면으로 들어가면 "Route 53에서 레코드 생성(Create records in Route 53)"이라는 버튼이 보입니다. 도메인을 Route 53에서 관리 중이라면 이 버튼 한 번으로 검증용 CNAME 레코드가 자동 등록됩니다. 손으로 복사·붙여넣기 할 필요가 없어요. (Route 53이 아니라 다른 곳에서 도메인을 관리하면, 화면에 나온 CNAME 이름·값을 그 업체 DNS 설정에 직접 넣어주면 됩니다.)
"발급됨" 될 때까지 대기
몇 분 정도 기다리면 상태가 "발급됨(Issued)" 초록색으로 바뀝니다. 보통 5분 안팎이지만, 길면 조금 더 걸릴 수도 있어요. 커피 한 잔 하고 오시면 됩니다. 여기까지가 인증서 "만들기"의 끝입니다.
6. 따라 하기 — 로드밸런서에 인증서 연결하고 자물쇠 켜기
이제 발급받은 인증서를 로드밸런서(ALB)의 443번 문(https)에 달아줍니다. 문(포트) 번호가 헷갈릴 텐데, 아주 쉽게 정리하면 이래요. 80번은 자물쇠 없는 문(http), 443번은 자물쇠 달린 문(https)입니다. 건물에 문이 두 개 있는데, 하나는 그냥 문이고 하나는 자물쇠 달린 문이라고 생각하세요.
EC2 → 로드밸런서 화면 열기
콘솔에서 EC2로 들어가, 왼쪽 메뉴의 "로드 밸런서(Load Balancers)"를 클릭하고 내 ALB를 선택합니다.
리스너 탭에서 HTTPS:443 추가
아래 "리스너(Listeners)" 탭으로 가서 "리스너 추가"를 누릅니다. 프로토콜은 HTTPS, 포트는 443으로 설정해요. (리스너 = "이 문으로 들어오는 손님을 받겠다"고 귀 기울이는 설정입니다.)
기본 동작 = 기존 대상 그룹으로 전달
"기본 작업"에서 손님을 어디로 보낼지 고릅니다. 앞 편에서 만든 대상 그룹(target group), 즉 내 EC2 서버를 가리키는 그룹을 선택하면 됩니다.
인증서 선택 = 방금 발급한 그 인증서
맨 아래 "기본 SSL/TLS 인증서"에서 "ACM에서(From ACM)"를 고르고, 방금 발급받은 인증서를 드롭다운에서 선택합니다. 목록에 안 보이면 십중팔구 리전이 다른 것입니다(4장 1번 참고). 여기서 자물쇠와 로드밸런서가 짝이 맺어지는 순간이에요.
저장 → 443 리스너 완성
저장하면 이제 https://내주소로 접속했을 때 자물쇠가 뜹니다! 한번 브라우저 주소창에 https://를 붙여 직접 들어가 보세요. 자물쇠 아이콘이 보이면 성공입니다.
80 → 443 자동 리다이렉트 설정
마지막으로, 자물쇠 없는 80번 문으로 들어온 손님도 자동으로 자물쇠 문으로 안내해줍시다. 기존 HTTP:80 리스너를 선택해 편집하고, 기본 작업을 "리디렉션(URL로 리디렉션)"으로 바꿔 HTTPS 443으로 보내도록 설정합니다. 이렇게 하면 누가 http로 들어와도 항상 자물쇠 걸린 주소로 튕겨줍니다.
http를 쳐도 문 앞에서 정중하게 "이쪽 자물쇠 문으로 오세요" 하고 안내해주는 셈이죠.7. 꼭 알아야 할 주의점 3가지 (깊게)
원본 글에서 짧게 언급했던 세 가지 주의점, 이게 사실 초보자가 가장 많이 넘어지는 지점입니다. 그래서 하나하나 제대로 파보겠습니다.
주의점 ① — 인증서는 EC2가 아니라 ALB/CloudFront에 붙인다
가장 많이 하는 착각이 "인증서니까 서버(EC2)에 직접 넣으면 되겠지?"입니다. 그런데 ACM 인증서는 EC2 서버에 직접 못 붙입니다. 오직 로드밸런서(ALB)나 CloudFront 같은 AWS의 "앞잡이" 서비스에만 붙어요.
왜 그럴까요? 비유하자면, 인증서 검사는 건물 정문 경비실에서 하는 일이기 때문입니다. 손님은 정문(로드밸런서)을 통해 들어오고, 경비실에서 신분 확인(암호화 처리)을 마친 뒤, 안쪽 사무실(EC2)로 안내됩니다. 사무실 문마다 경비를 세울 필요 없이, 정문 한 곳에서 자물쇠를 처리하는 게 훨씬 효율적이죠. 앞 편에서 로드밸런서를 먼저 세워둔 이유가 바로 여기에 있습니다.
주의점 ② — 리전을 반드시 맞춰라
AWS는 지역(리전)마다 창고가 따로 나뉘어 있습니다. 서울 창고, 도쿄 창고, 버지니아 창고… 이런 식이에요. 그런데 인증서도 이 창고에 소속됩니다. 서울 창고에서 발급한 인증서는 서울 로드밸런서에만 붙일 수 있어요. 도쿄 로드밸런서엔 안 붙습니다.
그래서 ALB 리스너에서 인증서 목록을 열었는데 방금 만든 게 안 보인다면, 99%는 다른 리전에서 발급받은 것입니다. 콘솔 오른쪽 위 리전을 확인해보세요.
| 붙이는 대상 | 인증서를 발급받아야 할 리전 |
|---|---|
| ALB (로드밸런서) | ALB가 있는 바로 그 리전 (예: 서울이면 서울) |
| CloudFront | 무조건 버지니아 북부(us-east-1) — 유일한 예외! |
외우기 팁: "ALB는 옆 동네 것끼리, CloudFront는 무조건 버지니아(us-east-1)." CloudFront만 예외적으로 버지니아 리전 인증서를 요구한다는 것, 이거 하나만 기억하면 리전 사고의 절반은 막습니다.
주의점 ③ — 자동 갱신, 손 안 대도 되지만 조건이 있다
ACM의 가장 큰 장점입니다. 일반 인증서는 보통 1년마다 만료돼서, 개발자가 날짜 챙겨가며 손으로 갱신해야 해요. 깜빡하면 어느 날 갑자기 사이트 전체에 "인증서 만료" 경고가 뜨는 대참사가 벌어집니다. 저도 예전에 이걸로 밤에 식은땀 흘린 적 있어요.
ACM 인증서는 만료 전에 알아서 자동 갱신됩니다. 한 번 달아두면 신경 쓸 일이 없어요. 단, 자동 갱신에는 조건이 하나 있습니다.
- DNS 검증으로 발급받았을 것 — 그리고 아까 자동 생성한 검증용 CNAME 레코드를 지우지 말 것. AWS가 갱신할 때 이 레코드로 "여전히 네 도메인 맞지?"를 다시 확인하거든요. 이 레코드가 사라지면 자동 갱신이 실패합니다.
- 인증서가 실제로 어딘가에 붙어 있을 것 — ALB나 CloudFront에 연결돼 사용 중인 인증서라야 자동 갱신 대상이 됩니다.
8. DNS 검증 vs 이메일 검증 — 무엇이 다른가
5장 5번에서 "DNS 검증을 고르라"고 했는데, 왜 그런지 짚고 넘어갈게요. AWS가 "이 도메인 진짜 네 거 맞아?"를 확인하는 방법이 두 가지거든요.
👍 DNS 검증 (추천)
- 도메인 설정에 지정한 CNAME 레코드를 넣어 소유를 증명
- Route 53이면 버튼 한 번에 자동 등록
- 자동 갱신이 되므로 한 번 하고 잊으면 됨
- 이메일 계정 상태와 무관하게 안정적
👎 이메일 검증
- 도메인 관리자 이메일로 온 확인 링크를 클릭해야 함
- 그 관리자 메일함에 접근할 수 있어야 함 (없거나 못 받으면 막힘)
- 자동 갱신이 매끄럽지 않음 — 갱신 때마다 다시 메일 확인이 필요할 수 있음
- 사람이 매번 개입 → 깜빡할 위험
쉽게 비유하면, DNS 검증은 내 집 대문에 "이 집 주인은 나요"라는 표찰을 붙여두는 방식이고, 이메일 검증은 집으로 온 편지를 받아 회신하는 방식입니다. 표찰은 한 번 붙여두면 계속 유효하지만, 편지는 올 때마다 받아서 답장해야 하죠. 그래서 저는 무조건 DNS 검증을 권합니다.
9. 자주 묻는 질문 (FAQ)
Q. 인증서가 정말 완전 무료인가요? 나중에 청구서 안 오나요?
A. ACM의 퍼블릭 인증서 자체는 무료이고, 갱신도 무료입니다. 다만 인증서를 붙이는 로드밸런서(ALB)나 CloudFront 같은 서비스는 원래대로 사용 요금이 붙습니다. 이건 인증서 값이 아니라 그 서비스 값이에요. 요금은 변동될 수 있으니 결제 전에는 항상 AWS 공식 요금 페이지에서 확인하시길 권합니다.
Q. 발급 요청했는데 몇 시간째 "검증 대기 중"에서 안 넘어가요.
A. 십중팔구 검증용 CNAME 레코드가 아직 도메인에 반영되지 않은 경우입니다. Route 53에서 자동 생성 버튼을 눌렀는지, 다른 DNS 업체라면 이름·값을 정확히 복사해 넣었는지 확인하세요. 앞뒤 공백이나 마침표 하나 차이로도 실패합니다.
Q. 도메인이 아직 없는데 인증서부터 받을 수 있나요?
A. 순서상 도메인이 먼저입니다. 소유하지 않은 도메인은 검증을 통과할 수 없어요. 다음 편 Route 53에서 도메인을 마련한 뒤 이 과정을 진행하시면 딱 맞습니다.
Q. www.myapp.com과 myapp.com 둘 다 자물쇠가 필요해요.
A. 인증서 요청 시 "다른 이름 추가"로 두 개를 모두 넣거나, 와일드카드 *.myapp.com을 함께 넣으면 됩니다. 참고로 와일드카드는 서브도메인(www, blog 등)은 커버하지만 myapp.com 자체(맨 앞에 아무것도 없는 것)는 별도로 넣어줘야 해요.
Q. 이미 다른 회사에서 산 유료 인증서가 있어요. 그걸 쓸 수 있나요?
A. 가능합니다. ACM에 인증서를 "가져오기(import)"할 수 있어요. 다만 가져온 인증서는 자동 갱신이 안 됩니다. 만료 때마다 직접 다시 넣어야 하죠. 특별한 이유가 없다면 ACM 무료 발급이 훨씬 편합니다.
Q. 인증서를 파일로 받아서 회사 다른 서버에 쓰고 싶어요.
A. ACM 퍼블릭 인증서는 파일로 내보낼 수 없습니다. AWS 서비스 안에서만 쓰는 조건이라 그래요. 외부 서버에 자유롭게 옮길 인증서가 필요하면 Let's Encrypt 같은 외부 무료 인증서를 별도로 쓰는 편이 맞습니다.
10. 초보가 흔히 하는 실수 & 해결법
제가 직접 겪었거나, 주변에서 가장 자주 본 실수 세 가지입니다. 미리 알아두면 시간을 아낄 수 있어요.
실수 1 — 리전 불일치로 인증서가 목록에 안 뜸
증상: ALB 리스너에서 인증서를 고르려는데 방금 만든 게 안 보임. 원인: ALB와 다른 리전에서 발급함. 해결: 콘솔 오른쪽 위 리전을 ALB와 같게 바꾸고, 그 리전에서 인증서를 다시 발급받으세요. CloudFront용이라면 반대로 버지니아(us-east-1)에서 받아야 합니다.
실수 2 — 검증 레코드를 안 넣거나 지워버림
증상: 발급이 안 되거나(검증 대기 무한), 잘 되던 게 갱신 때 실패. 원인: 검증용 CNAME 레코드를 등록하지 않았거나, 정리한다고 삭제함. 해결: Route 53에서 자동 생성 버튼을 누르고, 그 레코드는 절대 지우지 마세요. 자동 갱신의 생명줄입니다.
실수 3 — EC2에 직접 붙이려다 실패
증상: "인증서를 서버에 넣는 법"을 아무리 찾아도 안 나옴. 원인: ACM 인증서는 EC2에 직접 못 붙임. 해결: 로드밸런서(ALB)나 CloudFront를 앞에 두고 거기에 붙이세요. 앞 편에서 ALB를 만든 게 바로 이걸 위해서입니다.
11. 마무리 체크리스트
여기까지 잘 따라오셨습니다. 마지막으로, 자물쇠가 제대로 달렸는지 스스로 점검해봅시다. 아래 항목에 다 "예"라고 답할 수 있으면 완성입니다.
- ✅ 콘솔 리전을 로드밸런서(ALB)와 같은 곳으로 맞췄나요?
- ✅ ACM에서 퍼블릭 인증서를, DNS 검증으로 요청했나요?
- ✅ Route 53(또는 내 DNS 업체)에 검증용 CNAME 레코드를 넣었나요?
- ✅ 인증서 상태가 "발급됨(Issued)" 초록색으로 바뀌었나요?
- ✅ ALB에 HTTPS:443 리스너를 추가하고 그 인증서를 연결했나요?
- ✅ HTTP:80 → 443 리다이렉트를 설정했나요?
- ✅ 브라우저에서
https://내주소로 들어가 자물쇠 아이콘을 눈으로 확인했나요? - ✅ 검증용 레코드를 지우지 않고 그대로 두었나요? (자동 갱신용)
축하합니다! 이제 여러분의 사이트는 "안전하지 않음" 경고 대신 당당한 자물쇠를 답니다. 손님이 안심하고 정보를 입력할 수 있는, 제대로 된 사이트가 된 거예요.
12. 이제 주소만 남았다
자물쇠까지 달았으니, 마지막은 사람들이 기억할 수 있는 내 주소(도메인)입니다. 아무리 좋은 사이트라도 주소가 13.125.xxx.xxx 같은 숫자 덩어리면 아무도 못 외우겠죠. myapp.com처럼 예쁘고 기억하기 쉬운 이름을 붙이는 일, 그리고 그 이름이 우리 로드밸런서를 정확히 가리키게 연결하는 일. 다음 편, Route 53에서 마무리합니다. 오늘 자동으로 검증 레코드를 넣어준 그 Route 53이, 다음 편의 주인공이에요.
(2026년 8월 기준 작성 · AWS 콘솔 화면 구성과 요금은 시점에 따라 달라질 수 있으니, 결제·발급 전 반드시 AWS 공식 페이지에서 최신 정보를 확인하세요.)
← 기술 블로그 목록으로