AWS S3 & CloudFront 로 프론트엔드 정적 웹 호스팅하기 + SPA 라우팅 에러 해결

dvnchi·2025년 8월 24일

S3 cloudfront spa

Inhu

목록 보기

3/4

Inhu는 인하대 후문의 술집, 밥집, 카페 등 여러 장소를 소개하고 추천해주는 서비스입니다.

안녕하세요. Inhu 프로젝트의 백엔드 개발을 담당하고 있는 팀원입니다.
오늘은 AWS S3와 CloudFront를 이용하여 프론트엔드 정적 웹 호스팅을 하는 과정에서 발생했던 문제들에 대해 이야기하고자 합니다.

✍️ 서론

프론트엔드 배포를 하는 방법은 다음과 같은 방법들이 있습니다.

Vercel, Netlify: 간편 배포, GitHub 연동 강점. 다만 무료 요금제 제한이 있고, 프로젝트 성격에 따라 제약이 생길 수 있음.
GitHub Pages: 간단하고 무료지만, 커스텀 도메인 연결이나 HTTPS 관리가 다소 불편.
AWS EC2 + Nginx: 직접 서버를 올려 배포 가능하지만, 관리 포인트가 늘어나고 비용이 커짐.
AWS S3 + AWS CloudFront : 정적 파일 저장소 + 빠르고 안전하게 배포 가능

Inhu 프로젝트에서는 서버 관리 없이 저렴하고 빠르게 배포하고자 S3 + CloudFront 방법을 사용하였습니다.

📦 간략한 배포 과정

S3 버킷을 생성한 후 정적 웹 사이트 호스팅 활성화를 해줍니다.
CloudFront 배포 생성을 합니다. 원본 생성에서 정적 웹 사이트 호스팅 활성화를 해준 S3 버킷을 연결해줍니다.
CloudFront OAC를 생성하여 S3 버킷의 버킷 정책에 추가합니다.

🔎 문제 상황

S3 버킷을 생성하고 정적 웹 사이트 호스팅을 활성화한 뒤, CloudFront를 연결했습니다.
처음에는 정상적으로 동작하는 것처럼 보였으나, 다음과 같은 문제가 발생했습니다.

메인 페이지(inhu.co.kr) 접속 → 정상 동작
메인 페이지에서 내부 경로 이동(inhu.co.kr → place/1) → 정상 동작
내부 경로 직접 접속(inhu.co.kr/place/1) → 404 에러 발생

이는 SPA(Single Page Application) 특성상 새로고침이나 직접 경로 접근이 불가해 생긴 문제였습니다.

🛠 원인 분석

1.SPA란?

SPA(Single Page Application)는 이름 그대로 하나의 HTML 페이지(index.html)를 기반으로 동작하는 애플리케이션입니다.
SPA는 처음 접속 시 서버에서 index.html과 JS/CSS 파일들을 내려받습니다.
이후 페이지 이동은 서버 요청이 아니라, 브라우저 안에서 JavaScript 라우터가 담당합니다.
예를 들어, React Router나 Vue Router 같은 라이브러리가 URL을 보고 클라이언트 측에서 화면을 바꿔줍니다.
즉, 서버 입장에서는 /place/1 같은 경로를 알 필요가 없습니다. 브라우저가 알아서 index.html을 불러와 앱을 띄우고, JS 라우터가 /place/1 화면을 보여주면 되는 구조입니다.

2.404 에러가 발생하는 이유

문제는 브라우저 주소창에 직접 경로를 입력했을 때 발생합니다.

사용자가 inhu.co.kr/place/1 에 접근하는 경우
→ 브라우저는 서버(S3/CloudFront)로 요청
→ S3에 /place/1 파일이 없음
→ CloudFront도 찾지 못하고 404 Not Found
→ index.html 내려주지 못함

반면,

사용자가 inhu.co.kr 으로 접속하는 경우
→ index.html 정상적으로 내려받음
→ 버튼 클릭으로 /place/1 이동
→ 클라이언트 라우터 동작
→ 화면 정상 표시

결국 직접 접근 시 서버가 경로를 알 수 없기 때문에 404 에러가 발생하게 됩니다.

3.결론

SPA는 서버가 라우팅을 알지 못합니다.
서버는 정적 파일만 내려줄 뿐이고, /place/1 같은 경로는 실제로 존재하지 않습니다.
따라서 새로고침이나 직접 접근 시 서버가 해당 경로를 찾지 못하고 404를 반환하는 문제가 발생합니다.

🔧 문제 해결

CloudFront의 오류 페이지에서 404 에러에 대해 응답을 index.html 로 리다이렉트하도록 설정해주었습니다.

이렇게 하면 직접 경로 접근 시에도 항상 index.html을 불러오게 되고, 클라이언트 라우터가 해당 URL을 처리하게 됩니다.

403도 처리한 이유
-> CloudFront 뒤에 있는 S3 버킷은 보통 퍼블릭 접근 차단 + Origin Access Control(OAC) 방식으로 접근합니다.
이때 존재하지 않는 경로로 요청이 들어오면 S3가 404가 아니라 403 Forbidden을 반환하는 경우가 있다하여 이 경우도 추가하였습니다.