AWS Route 53 ALIAS에서 S3 버킷이 보이지 않는 문제, 원인부터 해결까지 총정리

Amazon Web Services(AWS)를 사용하여 서버 없이 정적 웹사이트를 운영하는 것은 매우 효율적이고 비용 효과적인 방법입니다. 핵심 서비스인 S3(Simple Storage Service)에 HTML, CSS, JavaScript, 이미지 등의 정적 파일을 업로드하고, Route 53을 통해 개인 도메인을 연결하면 몇 분 만에 전 세계 사용자를 대상으로 하는 웹사이트를 배포할 수 있습니다. 이 과정은 대부분 직관적이지만, 많은 개발자들이 특정 단계에서 예상치 못한 난관에 부딪힙니다. 바로 Route 53의 ALIAS 레코드 설정 화면에서, 분명히 생성해 둔 S3 버킷이 감쪽같이 사라져 목록에 나타나지 않는 문제입니다.

이 문제는 AWS 초심자뿐만 아니라 경험자에게도 당혹감을 안겨주곤 합니다. 설정이 거의 다 끝났다고 생각하는 마지막 단계에서 발생하는 이 미스터리한 현상은 사소한 설정 하나를 놓쳤을 때 발생하며, 원인을 모르면 몇 시간이고 헤맬 수 있습니다. 이 글에서는 해당 문제가 발생하는 근본적인 원인부터 시작하여, 단계별 점검 사항과 명확한 해결책을 제시합니다. 단순한 해결법 나열을 넘어, 왜 그렇게 설정해야만 하는지에 대한 AWS의 내부 동작 원리까지 깊이 있게 파헤쳐 보겠습니다. 이 글을 끝까지 따라오시면, 다시는 S3 버킷을 찾지 못해 시간을 낭비하는 일은 없을 것입니다.

1. 근본 원인: ALIAS 레코드는 왜 S3 버킷 이름을 따질까?

Route 53에서 ALIAS 레코드가 S3 버킷을 인식하지 못하는 문제의 90% 이상은 단 하나의 원인, 바로 'S3 버킷 이름'과 '연결하려는 도메인 이름'의 불일치에서 비롯됩니다. 이것은 단순한 AWS의 정책이나 권장 사항이 아니라, ALIAS 레코드가 내부적으로 동작하는 방식과 직접적으로 연관된 기술적 제약사항입니다.

우선, 일반적인 DNS 레코드 타입인 CNAME과 AWS 고유의 기능인 ALIAS 레코드의 차이점을 이해해야 합니다. CNAME(Canonical Name)은 하나의 도메인 이름을 다른 도메인 이름으로 연결하는 별칭과 같습니다. 예를 들어, `www.example.com`을 `example.com`으로 보내는 역할을 합니다. 하지만 CNAME은 루트 도메인(Zone Apex), 즉 `example.com` 자체에는 사용할 수 없다는 치명적인 제약이 있습니다. 많은 웹사이트가 `www` 없이 루트 도메인을 기본 주소로 사용하기 때문에 이는 큰 문제입니다.

이 문제를 해결하기 위해 AWS가 내놓은 것이 바로 ALIAS 레코드입니다. ALIAS 레코드는 CNAME과 유사하게 다른 리소스를 가리키지만, DNS 수준이 아닌 AWS 인프라 내부에서 작동합니다. 사용자가 ALIAS 레코드로 설정된 도메인에 접속하면, Route 53은 해당 도메인을 가리키는 AWS 리소스(예: ELB, CloudFront, S3 웹사이트 엔드포인트)의 IP 주소를 직접 조회하여 응답합니다. 이 방식 덕분에 CNAME의 제약 없이 루트 도메인에도 연결할 수 있고, AWS 리소스의 IP가 변경되어도 자동으로 반영되며, 쿼리 비용도 발생하지 않는 등 여러 이점을 가집니다.

바로 이 지점에서 '버킷 이름'이 중요해집니다. Route 53이 특정 도메인(`example.com`)에 대한 ALIAS 레코드 설정 요청을 받았을 때, 이 요청이 가리킬 수 있는 수많은 AWS 리소스 중에서 S3 웹사이트 엔드포인트를 찾아야 합니다. AWS는 이 식별 과정의 기준으로 'S3 버킷 이름'과 '도메인 이름'의 정확한 일치를 사용합니다. 즉, Route 53은 `example.com`에 대한 ALIAS 대상 목록을 보여줄 때, 이름이 정확히 `example.com`인 S3 버킷 중에서 '정적 웹사이트 호스팅' 기능이 활성화된 버킷만을 필터링하여 보여주는 것입니다. 만약 버킷 이름이 `my-website`나 `example-bucket`처럼 도메인과 다르다면, Route 53 입장에서는 이 버킷이 `example.com` 도메인을 위한 웹사이트라고 판단할 근거가 없으므로 목록에 아예 표시하지 않습니다.

• 정상 사례: 도메인이 `mydomain.com`이라면, S3 버킷 이름은 반드시 `mydomain.com`이어야 합니다.
• 오류 사례: 도메인이 `mydomain.com`인데, S3 버킷 이름이 `my-domain-s3` 또는 `website-for-mydomain`인 경우, Route 53 ALIAS 목록에 절대 나타나지 않습니다.

이것이 가장 핵심적인 원리입니다. 이제 이 원리를 바탕으로 실제 설정을 점검하고 문제를 해결하는 구체적인 단계를 살펴보겠습니다.

2. 문제 해결을 위한 단계별 체크리스트

S3 버킷이 보이지 않는 문제는 대개 여러 설정이 복합적으로 얽혀있을 때 발생합니다. 아래의 체크리스트를 순서대로 하나씩 점검하며 따라오시면 문제를 체계적으로 해결할 수 있습니다.

1단계: S3 버킷 이름 점검 및 재생성

가장 먼저 확인할 부분입니다. 이미 생성한 버킷의 이름이 연결하려는 도메인과 정확히 일치하는지 확인하세요.

1. AWS Management Console에 로그인하여 S3 서비스로 이동합니다.
2. 생성된 버킷 목록을 확인합니다.
   • 루트 도메인 `example.com`을 연결하고 싶다면, 이름이 정확히 `example.com`인 버킷이 있는지 확인합니다.
   • 서브도메인 `www.example.com`을 연결하고 싶다면, 이름이 정확히 `www.example.com`인 버킷이 있어야 합니다.
3. 만약 이름이 다르다면, 안타깝게도 S3 버킷의 이름은 생성 후에 변경할 수 없습니다. 기존 버킷의 데이터를 백업한 후 삭제하고, 올바른 이름으로 새 버킷을 생성해야 합니다.
   • 주의: 버킷을 삭제하면 내부의 모든 데이터가 영구적으로 사라지므로, 반드시 중요한 파일을 로컬 PC나 다른 버킷에 백업하세요. AWS CLI를 사용하면 `aws s3 sync` 명령어로 편리하게 데이터를 동기화할 수 있습니다.
4. 새 버킷을 생성할 때는 '버킷 이름' 필드에 연결할 도메인 주소(예: `your-awesome-site.com`)를 오타 없이 정확하게 입력합니다. AWS 리전은 서비스하려는 주 사용자층과 가까운 곳으로 선택하는 것이 좋습니다.

이 첫 단계를 통과했다면, 문제의 가장 큰 원인을 해결한 셈입니다. 하지만 아직 안심하긴 이릅니다. 버킷 이름 외에도 몇 가지 필수 설정이 더 남아있습니다.

2단계: 정적 웹사이트 호스팅 활성화

S3 버킷은 기본적으로 단순한 파일 저장소(객체 스토리지)입니다. 이 버킷을 웹 서버처럼 동작하게 만들려면 '정적 웹사이트 호스팅' 옵션을 명시적으로 활성화해야 합니다. 이 설정이 꺼져 있으면 Route 53은 해당 버킷을 웹사이트 엔드포인트로 간주하지 않습니다.

1. 해당 S3 버킷(`example.com`)을 클릭하여 세부 정보 페이지로 들어갑니다.
2. [속성(Properties)] 탭을 선택합니다.
3. 페이지 맨 아래로 스크롤하여 [정적 웹 사이트 호스팅(Static website hosting)] 섹션을 찾고, [편집(Edit)] 버튼을 클릭합니다.
4. 기본적으로 '비활성화(Disable)' 상태인 것을 '활성화(Enable)'로 변경합니다.
5. [호스팅 유형(Hosting type)]에서 '정적 웹 사이트 호스팅(Host a static website)'을 선택합니다.
6. [인덱스 문서(Index document)] 필드에 웹사이트의 첫 페이지 파일 이름을 입력합니다. 일반적으로 `index.html`입니다. 사용자가 도메인 루트(`http://example.com/`)에 접속했을 때 보여줄 파일입니다.
7. [오류 문서(Error document)] 필드에는 사용자가 존재하지 않는 경로에 접근했을 때 보여줄 오류 페이지 파일 이름을 입력합니다. 예를 들어 `error.html`을 지정할 수 있습니다. 이 설정은 선택 사항이지만, 사용자 경험을 위해 설정하는 것을 강력히 권장합니다.
8. [변경 사항 저장(Save changes)]을 클릭합니다.

설정을 저장하고 나면, '정적 웹 사이트 호스팅' 섹션에 해당 버킷의 고유한 웹사이트 엔드포인트(Website endpoint) 주소가 생성된 것을 볼 수 있습니다. 주소는 보통 `http://[버킷이름].s3-website.[리전].amazonaws.com` 형태입니다. 이 엔드포인트 주소를 클릭했을 때, 업로드한 `index.html` 파일이 정상적으로 보인다면 호스팅 설정은 성공적으로 완료된 것입니다. 만약 403 Forbidden 오류가 발생한다면, 다음 3단계를 진행해야 합니다.

3단계: 퍼블릭 액세스 차단 해제 및 버킷 정책 설정

최신 AWS 정책상, 새로 생성되는 모든 S3 버킷은 기본적으로 모든 퍼블릭 액세스가 차단되어 있습니다. 웹사이트는 불특정 다수의 대중(Public)에게 공개되어야 하므로, 이 차단 설정을 해제하고 방문자들이 파일에 접근할 수 있도록 권한을 명시적으로 부여해야 합니다.

3-1. 모든 퍼블릭 액세스 차단 해제

1. S3 버킷 세부 정보 페이지에서 [권한(Permissions)] 탭으로 이동합니다.
2. [퍼블릭 액세스 차단(모든 퍼블릭 액세스 차단)(Block public access (bucket settings))] 섹션을 찾고 [편집(Edit)] 버튼을 클릭합니다.
3. '모든 퍼블릭 액세스 차단(Block all public access)' 체크박스의 체크를 해제합니다.
4. "이 변경으로 인해 이 버킷과 그 안의 객체가 퍼블릭 상태가 될 수 있음을 확인합니다."라는 경고 메시지가 나타나면, 해당 확인란에 체크합니다.
5. [변경 사항 저장(Save changes)]을 클릭합니다. 이제 버킷 자체는 퍼블릭 상태가 될 준비가 되었지만, 아직 개별 파일에 대한 접근 권한은 부여되지 않았습니다.

3-2. 버킷 정책(Bucket Policy) 추가

버킷 정책은 JSON 형식으로 작성하여, 누가(Principal), 어떤 리소스(Resource)에 대해, 어떤 작업(Action)을 허용(Allow) 또는 거부(Deny)할지를 정의하는 강력한 규칙입니다. 정적 웹사이트의 경우, 인터넷상의 모든 사용자(`"Principal": "*"`)가 버킷 안의 모든 객체(`/*`)를 읽어갈 수 있도록 (`"Action": "s3:GetObject"`) 허용하는 정책이 필요합니다.

1. 같은 [권한(Permissions)] 탭에서 [버킷 정책(Bucket policy)] 섹션을 찾아 [편집(Edit)]을 클릭합니다.
2. 아래의 JSON 정책을 복사하여 정책 편집기에 붙여넣습니다.

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Sid": "PublicReadGetObject",
               "Effect": "Allow",
               "Principal": "*",
               "Action": "s3:GetObject",
               "Resource": "arn:aws:s3:::[YOUR-BUCKET-NAME]/*"
           }
       ]
   }

3. 위 정책에서 `[YOUR-BUCKET-NAME]` 부분을 자신의 실제 버킷 이름(예: `example.com`)으로 반드시 변경해야 합니다. `Resource` 끝에 붙는 `/*`는 버킷 안의 모든 객체를 의미합니다.
4. [변경 사항 저장(Save changes)]을 클릭합니다. 정책에 문법 오류가 없다면 성공적으로 저장되고, [권한] 탭 상단에 "공개적으로 액세스 가능(Publicly accessible)"이라는 빨간색 태그가 나타납니다.

이제 다시 S3 웹사이트 엔드포인트 주소(`http://[버킷이름].s3-website.[리전].amazonaws.com`)로 접속해보세요. 이전의 403 Forbidden 오류가 사라지고 웹페이지가 정상적으로 표시될 것입니다. 이 모든 단계가 완료되었다면, S3 버킷은 Route 53 ALIAS 레코드의 대상으로 선택될 모든 준비를 마친 상태입니다.

3. Route 53에서 ALIAS 레코드 최종 설정하기

이제 대망의 마지막 단계입니다. 모든 장애물을 제거했으니, Route 53에서 S3 버킷이 마법처럼 나타나는 것을 확인해 보겠습니다.

1. AWS Management Console에서 Route 53 서비스로 이동합니다.
2. 왼쪽 메뉴에서 [호스팅 영역(Hosted zones)]을 클릭하고, 연결하려는 도메인의 호스팅 영역(예: `example.com`)을 선택합니다.
3. [레코드 생성(Create record)] 버튼을 클릭합니다.
4. 레코드 생성 양식:
   • 레코드 이름(Record name): 루트 도메인(`example.com`)에 연결할 것이므로 이 필드를 비워 둡니다. 만약 `www.example.com`과 같은 서브도메인에 연결한다면 여기에 `www`를 입력합니다.
   • 레코드 유형(Record type): A - IPv4 주소 및 일부 AWS 리소스로 트래픽 라우팅을 선택합니다. ALIAS 레코드는 A 레코드 또는 AAAA 레코드 유형으로 생성할 수 있습니다.
   • 별칭(Alias) 토글 스위치: 이 스위치를 클릭하여 활성화(파란색)합니다.
   • 트래픽 라우팅 대상(Route traffic to):
     1. 첫 번째 드롭다운 메뉴에서 'S3 웹 사이트 엔드포인트에 대한 별칭(Alias to S3 website endpoint)'을 선택합니다.
     2. 두 번째 드롭다운 메뉴(리전 선택)에서 이전에 S3 버킷을 생성했던 동일한 리전을 선택합니다. (예: `ap-northeast-2 (Asia Pacific (Seoul))`)
     3. 세 번째 필드를 클릭하면... 드디어! 이전에 보이지 않던 S3 웹사이트 엔드포인트(`s3-website.ap-northeast-2.amazonaws.com`)가 목록에 나타날 것입니다. 이 항목을 선택합니다.
   • 라우팅 정책(Routing policy): '단순 라우팅(Simple routing)'을 그대로 둡니다.
   • [레코드 생성(Create records)] 버튼을 눌러 설정을 완료합니다.

DNS 변경 사항이 전 세계로 전파되는 데에는 몇 분에서 최대 48시간까지 걸릴 수 있지만, Route 53은 일반적으로 매우 빠르게 적용됩니다. 잠시 후 웹 브라우저 주소창에 자신의 도메인(`http://example.com`)을 입력하여 접속해보세요. S3에 업로드한 멋진 웹사이트가 여러분을 맞이할 것입니다.

4. 심화 학습: 'www' 서브도메인 처리 및 HTTPS 적용

기본적인 웹사이트 배포에 성공했다면, 여기서 한 걸음 더 나아가 사용자 경험과 보안을 향상시킬 수 있습니다.

'www' 서브도메인을 루트 도메인으로 리디렉션하기

사용자들은 `example.com`으로 접속하기도 하고, 습관적으로 `www.example.com`으로 접속하기도 합니다. 두 주소 모두 동일한 사이트를 보여주도록 설정하는 것이 표준적인 방법입니다. 가장 좋은 방법은 하나의 주소(보통 루트 도메인)를 기본으로 정하고, 다른 주소는 기본 주소로 리디렉션(redirection)하는 것입니다.

1. S3에서 새 버킷을 생성합니다. 이번에는 버킷 이름을 `www.example.com`으로 지정합니다.
2. 이 `www` 버킷에는 아무 파일도 업로드할 필요가 없습니다. 버킷 세부 정보의 [속성(Properties)] > [정적 웹 사이트 호스팅(Static website hosting)]으로 이동하여 [편집]을 클릭합니다.
3. '활성화(Enable)'를 선택하고, [호스팅 유형]에서 이번에는 '요청 리디렉션(Redirect requests for an object)'을 선택합니다.
4. [호스트 이름(Host name)] 필드에 리디렉션할 대상인 루트 도메인, 즉 `example.com`을 입력합니다.
5. [프로토콜(Protocol)]은 `http`로 설정하고 변경 사항을 저장합니다.
6. 이제 Route 53으로 돌아가, `www.example.com`에 대한 ALIAS 레코드를 하나 더 생성합니다. 과정은 위와 동일하며, '레코드 이름'에 'www'를 입력하고 '트래픽 라우팅 대상'에서 이 `www` 리디렉션 버킷의 엔드포인트를 선택하면 됩니다.

이렇게 설정하면, 사용자가 `www.example.com`으로 접속했을 때 S3가 자동으로 브라우저에게 `http://example.com`으로 이동하라는 응답을 보내주게 됩니다.

HTTPS 적용을 위한 CloudFront 도입

지금까지의 설정은 HTTP 프로토콜로만 통신합니다. 현대 웹 환경에서는 데이터 암호화와 신뢰성 확보를 위해 HTTPS가 필수적입니다. 하지만 S3 정적 웹사이트 호스팅 기능 자체는 HTTPS를 직접 지원하지 않습니다. S3 웹사이트 엔드포인트는 오직 HTTP만을 사용합니다.

S3 웹사이트에 HTTPS를 적용하는 가장 표준적이고 강력한 방법은 AWS의 CDN(Content Delivery Network) 서비스인 Amazon CloudFront를 도입하는 것입니다.

1. AWS Certificate Manager(ACM)을 사용하여 해당 도메인(`example.com` 및 `*.example.com`)에 대한 무료 SSL/TLS 인증서를 발급받습니다. (중요: CloudFront와 연동하려면 반드시 '버지니아 북부(us-east-1)' 리전에서 인증서를 생성해야 합니다.)
2. CloudFront에서 새 배포(Distribution)를 생성합니다.
3. [원본 도메인(Origin domain)]에 S3 버킷의 '웹사이트 엔드포인트' 주소를 직접 입력합니다. (주의: 드롭다운에서 제공하는 S3 버킷 ARN(`...s3.amazonaws.com`)을 선택하면 REST API 엔드포인트로 연결되어 리디렉션 등이 제대로 동작하지 않을 수 있습니다. 반드시 `[버킷이름].s3-website...` 형태의 주소를 사용하세요.)
4. [뷰어(Viewer)] 설정에서 'HTTP and HTTPS' 또는 'Redirect HTTP to HTTPS'를 선택하여 HTTPS를 강제할 수 있습니다.
5. [사용자 정의 SSL 인증서(Custom SSL certificate)] 섹션에서 ACM으로 발급받은 인증서를 선택합니다.
6. 배포가 완료되면, CloudFront는 `d12345abcdef.cloudfront.net`과 같은 고유한 도메인 이름을 제공합니다.
7. 이제 Route 53으로 돌아가 기존에 만들었던 S3를 가리키는 A 레코드를 수정합니다. '트래픽 라우팅 대상'을 S3 엔드포인트 대신 'CloudFront 배포에 대한 별칭'으로 변경하고, 새로 생성된 CloudFront 배포를 선택합니다.

CloudFront를 사용하면 HTTPS 적용뿐만 아니라, 전 세계에 분산된 엣지 로케이션에 콘텐츠를 캐싱하여 웹사이트 로딩 속도를 획기적으로 개선하고, S3로 직접 들어오는 트래픽을 줄여 비용을 절감하는 등 수많은 이점을 얻을 수 있습니다. 프로덕션 환경의 웹사이트라면 CloudFront 사용을 적극적으로 고려해야 합니다.

결론: 체계적인 점검이 핵심이다

AWS Route 53에서 S3 버킷이 보이지 않는 문제는 대부분 사소한 설정 누락에서 비롯되지만, 그 원리를 모르면 해결하기 매우 까다로운 문제처럼 느껴질 수 있습니다. 오늘 우리가 살펴본 내용을 다시 한번 요약하며 마무리하겠습니다.

1. 가장 중요한 원인: S3 버킷 이름(example.com)은 Route 53에서 연결할 도메인 이름(example.com)과 반드시, 정확하게 일치해야 합니다.
2. S3 버킷 필수 설정: 버킷 이름뿐만 아니라 정적 웹사이트 호스팅 활성화, 퍼블릭 액세스 차단 해제, 그리고 익명 사용자의 객체 읽기를 허용하는 버킷 정책 설정까지 모두 완료되어야 합니다.
3. Route 53 설정 확인: ALIAS 레코드 생성 시, 올바른 레코드 유형(A)을 선택하고, S3 버킷이 위치한 리전을 정확하게 지정해야만 해당 버킷의 엔드포인트가 목록에 나타납니다.

이 세 가지 핵심 포인트를 기억하고, 문제가 발생했을 때 오늘 다룬 단계별 체크리스트에 따라 차분히 점검한다면 앞으로 S3와 Route 53을 연동하는 과정에서 겪는 어려움을 크게 줄일 수 있을 것입니다. 서버리스 정적 웹 호스팅은 AWS를 활용하는 가장 기본적인 첫걸음이자, 강력한 클라우드 인프라의 가능성을 체험하는 최고의 방법입니다. 이 가이드가 여러분의 성공적인 AWS 여정에 든든한 디딤돌이 되기를 바랍니다.