React로 빌드된 것과 같은 현대적인 JavaScript 애플리케이션의 배포 방식은 크게 진화했습니다. 이제 정적 파일을 서비스하기 위해 복잡한 서버나 가상 머신을 유지 관리할 필요가 없습니다. 2026년 현재, 모든 전문적인 싱글 페이지 애플리케이션(SPA)의 표준 아키텍처는 Amazon S3를 오리진 스토리지로, Amazon CloudFront를 콘텐츠 전송 네트워크(CDN)로 사용하는 것입니다.
이 기술 가이드에서는 React 프로젝트를 세계적 수준의 인프라로 구축하고, 비용을 최적화하며, 최종 사용자의 로딩 속도를 극대화하는 데 필요한 각 단계를 상세히 설명합니다.
왜 React 호스팅에 S3 + CloudFront를 선택해야 할까요?
기술적인 설정을 시작하기 전에, Heroku, Vercel, VPS 서버와 같은 기존 솔루션과 비교하여 이 아키텍처가 갖는 장점을 이해하는 것이 중요합니다.
- 무한한 확장성: 사용자 수를 걱정할 필요가 없습니다. AWS는 대규모 트래픽 급증을 자동으로 처리합니다.
- 비용 효율성: 스토리지 비용(JS/HTML 파일의 경우 최소화)과 전송된 대역폭에 대해서만 비용을 지불합니다. 소규모 프로젝트의 경우 AWS 프리 티어 범위 내에서 운영이 가능합니다.
- 글로벌 성능: CloudFront는 전 세계 400개 이상의 엣지 로케이션(Edge Locations)에 파일을 복제하여 지연 시간을 최소화합니다.
- 강력한 보안: 코드를 실행하는 서버가 없으므로 일반적인 공격 벡터를 차단할 수 있습니다.
1단계: React 애플리케이션 준비
S3에 배포하려면 먼저 정적 프로덕션 파일을 생성해야 합니다. Vite 또는 Create React App을 사용하는 경우 프로세스는 표준화되어 있습니다.
# Vite 프로젝트의 경우 (2026년 권장)
npm run build
# 또는 클래식 CRA를 사용하는 경우
npm run build
이 명령은 index.html 파일, 압축된 JavaScript 번들 및 에셋(CSS, 이미지)이 포함된 dist/ 또는 build/ 폴더를 생성합니다. 이 파일들이 클라우드에 업로드할 유일한 파일들입니다.
2단계: Amazon S3 설정 (스토리지)
Amazon Simple Storage Service(S3)는 우리의 "파일 데이터베이스" 역할을 합니다. 올바르게 설정하려면 다음 단계를 따르세요.
1. 버킷 생성
AWS 콘솔에 접속하여 새 버킷을 생성합니다. 이름은 전 세계적으로 고유해야 합니다. 예: my-react-project-prod.
2. 퍼블릭 액세스 차단 해제 (일시적)
CloudFront가 파일을 읽을 수 있도록 하거나 S3의 직접 정적 웹사이트 호스팅을 사용하려면 "모든 퍼블릭 액세스 차단" 옵션을 해제해야 합니다.
3. 버킷 정책 구성
"권한" 탭에서 다음 정책을 추가하여 전 세계에서 파일을 읽을 수 있도록 허용합니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicReadGetObject",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::버킷-이름/*"
}
]
}
3단계: Amazon CloudFront 설정 (CDN)
S3에서 직접 서비스하는 것도 가능하지만 전문적이지는 않습니다. CloudFront를 사용하면 HTTPS, 맞춤형 도메인 및 글로벌 캐싱을 사용할 수 있습니다.
1. 배포(Distribution) 생성
CloudFront 콘솔에서 새 배포를 생성하고 S3 버킷을 "Origin Domain"으로 선택합니다.
2. 라우팅 처리 (SPA의 문제)
React 애플리케이션은 클라이언트 측 라우팅(React Router)을 사용합니다. 사용자가 /dashboard에서 페이지를 새로고침하면, S3는 dashboard라는 물리적 파일을 찾게 되고, index.html만 존재하기 때문에 404 오류를 반환합니다.
해결책: CloudFront에서 "Error Responses" 탭으로 이동하여 사용자 지정 규칙을 생성합니다.
- HTTP Error Code: 404 (Not Found)
- Customize Error Response: Yes
- Response Page Path:
/index.html - HTTP Response Code: 200 (OK)
이렇게 하면 모든 요청이 React로 전달되어 내부 라우터가 탐색을 처리할 수 있게 됩니다.
4단계: Infrastructure as Code (IaC)를 통한 자동화
AWS 콘솔에서 이러한 단계를 수동으로 수행하는 것은 오류가 발생하기 쉽고 재현하기 어렵습니다. 이 지점에서 Terraform이나 AWS CLI와 같은 도구가 필수적입니다.
코드에 집중하고 싶고 AWS의 수십 개의 화면을 수동으로 설정하고 싶지 않은 개발자라면, 당사의 도구인 React2AWS를 사용하는 것이 좋습니다.
React2AWS가 제공하는 혜택: 다음을 위한 필수 설정 파일(Terraform 또는 Bash 스크립트)을 즉시 생성합니다.
- 올바른 보안 정책이 적용된 버킷 생성.
- React용 404 오류 핸들러가 포함된 CloudFront 배포 구성.
- 정적 파일에 최적화된 캐시 헤더 설정.
프로젝트 이름만 입력하면 즉시 실행 가능한 전문적인 블루프린트를 얻을 수 있습니다.
최적화 및 베스트 프랙티스
배포 수준을 높이려면 다음 사항을 고려하세요.
1. Gzip 및 Brotli 압축
CloudFront에서 "객체 자동 압축"이 활성화되어 있는지 확인하세요. 이렇게 하면 JS 번들 크기가 최대 70%까지 줄어들어 로딩 시간이 획기적으로 개선됩니다.
2. 캐시 무효화 (Invalidation)
S3에 앱의 새 버전을 업로드할 때마다 CloudFront는 캐시가 만료될 때까지 엣지 노드에서 이전 버전을 계속 서비스합니다. 글로벌 업데이트를 강제하려면 경로 /*로 "무효화(Invalidation)"를 생성해야 합니다.
3. OAC (Origin Access Control)를 통한 보안
S3 버킷을 공개로 두는 대신, 버킷을 닫고 CloudFront만 파일을 읽을 수 있도록 허용하는 것이 이상적입니다. 이렇게 하면 사용자가 CDN을 우회하여 스토리지에 직접 액세스하는 것을 방지할 수 있습니다.
결론
AWS S3와 CloudFront에 React 애플리케이션을 배포하는 것은 확장성과 저비용을 추구하는 프로젝트를 위한 가장 현명한 결정입니다. 초기 설정이 복잡해 보일 수 있지만, 보안과 글로벌 성능 측면에서 얻는 이점은 그만한 가치가 충분합니다.
수동 설정 시간을 절약하고 일반적인 AWS 권한 오류를 피하고 싶다면, 당사의 인프라 생성기를 사용하여 단 몇 초 만에 전체 프로세스를 자동화하세요.
관련 기사
파일을 최적화할 준비가 되셨나요?
React2AWS 생성기 도구를 사용해 보세요. 100% 무료이며 개인 정보가 보호되며 서버 업로드 없이 브라우저에서 직접 모든 작업을 처리합니다.