프론트엔드 배포 알아보기(feat. AWS 실습)
주디2025.12.26
loading ...
프론트엔드 배포는 무엇이고 왜 필요할까?
1. 배포란 무엇이며, 왜 필요할까?
우리가 프론트엔드 개발을 할 때 작성하는 코드(JSX, TypeScript 등)는 대부분 브라우저가 바로 이해할 수 없다. 브라우저가 직접 이해할 수 있는 언어는 HTML, CSS, JavaScript로 제한되어 있기에, 빌드 과정을 통해 HTML, CSS, JavaScript로 변환해야한다. 또한, 변환된 결과물이 사용자가 언제든 접근할 수 있는 공간에 올라가야한다.
여기서 어디에, 어떻게 올리고, 어떻게 제공하는지 가 배포이다.
배포가 필요한 이유
1) 24시간 켜져 있는 공간
사용자가 내 PC가 꺼져 있어도, 전 세계 어디서든, 내가 만든 웹사이트에 접근할 수 있어야 한다. 이를 위해선 항상 켜져 있는 서버나 스토리지 공간이 필요하다
2) 보안과 접근 제어
내 컴퓨터를 그대로 노출하면 IP 주소가 외부에 공개되기에, 클라우드 서비스는 이런 인프라 보안을 대신 관리해주고, HTTPS 인증서 적용도 쉽게 할 수 있다.
3) 전 세계 사용자에게 빠르게 전달
한국에만 파일이 있다면 다른 해외 사용자에게는 느릴 수 밖에 없다. 정적 파일을 CDN(Content Delivery Network) 으로 전 세계에 복제해두면, 가장 가까운 지점에서 파일을 내려주기 때문에 웹사이트 접속 속도가 확연히 빨라진다.
즉, 정적 파일 = 완성된 웹사이트,배포 = 그 파일을 안전하고 빠르며 안정적으로 사용자에게 전달하는 과정이라고 볼 수 있다.
2. HTML 요청을 둘러싼 기본 원리
결국 웹페이지는 HTML 을 요청하고 다운로드하는 과정으로 시작하는 것이다.
- 로컬 환경에서는
- 파일 경로(폴더 구조)를 알면
- 브라우저가 바로 HTML을 연다
- 리모트(서버) 환경에서는
- 리모트 URL을 통해 접근해야 하고
- HTTP 프로토콜로 요청/응답을 주고받는다
| 환경 | 접근 방식 | 프로토콜 |
| 로컬(Local) | 파일 경로로 접근 | file:// |
| 리모트(Remote 서버) | URL로 접근 | HTTP/HTTPS |
따라서 로컬 브라우저는 HTML의 위치만 알면되지만, 서버는 URL과 프로토콜을 알아야 접근할 수 있다.
배포 플랫폼은 결국 아래 세가지를 보장해줘야한다.
HTML 위치를 찾아갈 수 있어야 한다 (URL) HTML을 웹에서 요청할 수 있어야 한다 (HTTP) HTML이 의도대로 동작해야 한다
3. 정적 웹사이트와 동적 웹사이트
정적 웹사이트란?
정의
- 내용이 변하지 않는 HTML 콘텐츠
배포 플랫폼의 역할
- 작동
리모트 URL을 파악 → 웹 서버가 HTTP GET 요청을 이해 → HTML 파일을 내려줌
→ 웹서버가 브라우저가 보낸 HTTP GET 요청을 처리한다
→ 정적 웹사이트는 단순한 웹 서버만으로도 배포 플랫폼을 구축할 수 있다 (변하는 데이터 X)
동적 웹사이트란?
정적 웹사이트는 누구에게나 동일한 HTML만 제공하지만,
동적 웹사이트는 사용자마다 개인화된 다른 콘텐츠를 제공하고자할 때 필요하다.
웹서버의 한계
웹 서버는 파일만 내려주는 역할이라, 동적인 처리까지 하면 부하가 커지고 복잡해진다
→ HTTP 요청을 받아서 동적인 작업을 처리하는 웹 애플리케이션 서버 추가
웹 애플리케이션 서버 (WAS)
- HTTP 요청을 받아 동적 페이지를 생성하는 작업을 처리한다
- 웹 서버가 WAS에게 요청을 전달 → WAS가 HTML 수정 후 반환 → 웹 서버가 클라이언트에 응답
→ 동적 웹사이트는 웹 서버 + 웹 애플리케이션 서버가 함께 있어야 배포 플랫폼이 완성된다.
4. SPA
1) 기존 방식의 한계
모든 화면 전환에 HTML 을 새로 로드해야했다.
따라서, UI/UX 측면에서 계속 새로고침 발생 → 느린 UI/UX → 화면 표시와 데이터 처리의 강한 결합 발생
2) AJAX 등장
이러한 불편함을 해소하기 위해 AJAX가 나왔다. 이후 브라우저 재로딩없이도 서버와 데이터를 주고받을 수 있게 되었다.
웹 서버에서 HTML을 받아온 후, 브라우저는 데이터 전달을 위해 또 다른 웹 서버에 요청을 보내 데이터를 받을 수 있는 구조로 발전하게 된다.
AJAX의 등장으로 SPA이 떠오르게 되었다.
SPA에서는
- HTML이 단순 문서가 아닌JS와 CSS를 받아오는 통로(entry point)로 동작하게 된다.
- JS는 UI와의 상호작용을 제어한다.
→ SPA에서 HTML은 통로가 되고, JS가 화면/상태/라우팅을 담당한다
3) SPA의 배포 플랫폼의 핵심 조건
SPA는 초기 로딩 시 정적 자원을 한 번 내려받고, 이후 화면 전환/라우팅 등을 모두 클라이언트쪽 JS가 담당하게 된다.
이때 서버는 라우팅을 모르기에 사용자가 서브 경로로(/mypage , /profile) 접근하면 서버가 대응되는 파일을 찾아 응답해줄 수 없다.
전통적인 웹사이트는 서브 경로에 맞는 HTML 을 서버가 동적으로 만들어 내려주지만, SPA는 필요한 화면 구조가 모두 JS에 포함되어 있기에 서버가 따로 만들어줄 페이지가 없다.
따라서 SPA 배포 플랫폼은 아래 조건을 만족해야한다.
- HTTP GET 요청에 대해 HTML, JS, CSS 등의 정적 자원을 모두 웹 서버가 제공
- 모든 하위 경로에 대해 index.html 응답 (404 not found 발생 → index.html)
→ 서브 경로 요청 시 서버는 파일을 찾지 못해 원래는 404 반환, SPA 에서는 무조건 404 대신 index.html을 반환해야 한다
5. SPA를 위한 배포 플랫폼의 성능 최적화
SPA는 초기 로딩 시 모든 파일을 요청하기에 초기 로딩이 무겁다.
HTML GET → JS GET → CSS GET → … 이러한 과정이 연속적으로 발생하여, 워터폴 현상이 발생할 수 있다.
1) HTTP 캐시 제어
HTTP의 헤더를 사용하여 성능 최적화를 한다. 그중 Cache-Control를 활용해서 기존에 받은 HTML,JS,CSS 를 재활용할 수 있다.
예를 들어 아래와 같이 사용한다. (HTML,JS 모두 사용 가능)
Cache-Control: max-age=60 → HTML을 60초 동안 캐시하고, 만료되면 서버로 검증하세요
2) JS 캐시 제어
빌드를 할 때 빌드 도구를 사용해 HTML에 JS와 CSS 를 통합한다. 이 과정에서 번들링은 자바스크립트 해시값을 추가한다.
정적 배포에서는 파일명에 해시(hash)를 붙여서 변경 여부를 식별하는 방식을 사용하는 것이다.
빌드 시 무엇이 일어날까?
빌드 도구(예: Vite, Webpack, CRA)는 JS/CSS 파일을 다음과 같이 변환한다.
main.a7c391.jsstyle.42fb20.css
- a7c391, 42fb20 같은 값이 내용 기반 해시값
- 이 해시값이 바뀌면
왜 해시를 붙일까?
브라우저는 파일명을 캐시 키로 사용한다. 즉, 파일명 = 이 파일의 버전
- 파일 내용이 바뀌지 않으면 해시값이 동일 → 브라우저 캐시 재사용 (빠른 로딩)
- 파일 내용이 바뀌면 해시값이 변경 → 새로운 파일로 인식하고 다시 다운로드
내용이 같으면 캐시를 쓰고, 바뀌면 자연스럽게 최신 파일을 받는다.
6. 캐시정책에 따른 버전 정책
SPA HTML이 foo.js → bar.js 로 변경되었을 때,
이전 HTML이 foo.js 를 요청하면 404 오류가 발생할 수 있다.
→ SPA는 파일 버전 관리를 하지 않으면 HTML이 최신 JS를 가리키지 못해 동작 보장을 못하게 된다.
따라서 SPA 배포 플랫폼은
- HTTP GET 요청에 대해 HTML, JS, CSS 등의 정적 자원을 모두 웹 서버가 제공
- 모든 하위 경로에 대해 index.html 응답 (404 not found 발생 → index.html)
- HTTP 헤더를 사용한 성능 최적화 (Cache-Control 사용 시, 캐싱 정책에 따른 버전 정책 활용)
7. CDN(Content Delivery Network)
리모트 서버에서만 파일을 받으면 위치가 멀수록 응답시간이 길어진다.
CDN은 전 세계 여러 서버에 캐싱하여, 가까운 곳에서 빠르게 응답이 가능하다.
또한, 요청이 필요할 때 캐시된 응답을 제공하여 HTTP 응답 속도를 개선할 수 있다.
동작 : 브라우저 → CDN 서버 → 필요한 경우 오리진 서버
이러한 CDN 캐시는 배포 이후에도 남아있을 수 있기에, 새로운 배포시 CDN 퍼지(purge)를 통해 CDN 캐시를 무효화할 수 있다.
CDN은 SPA뿐만이 아닌 정적 웹사이트 성능 최적화에도 적용 가능.
아래에서는 실제 정적 배포 방식을 AWS에서 어떻게 진행할 수 있을지를 알아보고자 한다.
AWS 기반으로 하는 정적 프론트엔드 배포
아래 과정은 React 프로젝트를 기반으로 한 내용이다.
1. 로컬 프로젝트 빌드
본인 프로젝트에 맞는 명령어를 통해 build를 하여 정적인 파일들을 생성한다.
npm run build
2. S3 버킷 생성 및 빌드 파일 업로드
앞선 프로젝트 빌드 후 생성된 정적 파일을 저장할 공간이 필요하다. 이러한 공간이 바로 S3이다.
S3는 원래 객체 스토리이지 서비스이지만, 정적 웹사이트 배포에서는 HTML,CSS,JS 등의 정적 파일을 저장해두고 사용자가 요청할 때 제공하는 웹 서버의 역할도 할 수 있다.
즉, 정적 파일을 저장해두고 사용자가 접근하고자할 때 사용자에게 전달해주는 과정을 S3가 해줄 수 있다!
하지만, 라우팅/캐싱/속도 등에 한계가 있어 CloudFront를 S3와 함께 사용한다.
[AWS 실습] S3로 버킷 생성하기
- 버킷 이름 생성
- 퍼블릭 액세스 차단 설정 해지 및 퍼블릭 상태 확인 체크
S3 만으로 배포를 하고자한다면 퍼블릭 액세스 차단을 해지하여, S3 버킷만으로 다른 사용자가 접근가능하도록 해야한다.
하지만 우리는 이후 CloudFront를 통해 접속할 것이기 때문에, S3를 외부에 열어두지 않고 private 하게 관리하는 것이 좋다. 따라서 액세스 차단을 허용해두어 CloudFront 를 통해 사용자가 접근하면, CloudFront가 S3 객체를 가져가 호스팅할 수 있도록 해야한다.
- 기본 세팅값 유지 후 버킷 만들기
- S3 객체 업로드
빌드 후 생성된 정적 파일들(build 폴더 내부에 있는 파일/폴더들)을 빨간 박스에 업로드한다.
3. CloudFront
CloudFront는 AWS의 CDN(Content Delivery Network) 이다.
전 세계 여러 지역(엣지 로케이션, PoP)에 파일을 미리 캐싱해두고, 사용자에게 가장 가까운 위치에서 빠르게 제공하는 글로벌 분산 캐시 서버 라고 할 수 있다.
즉, 사용자의 입장에서 가장 가까운 곳에서 제공하여 속도와 안정성을 높일 수 있게 한다.
[AWS 실습] CloudFront 로 웹 호스팅하기
- 기본 정보
Distribution name - 배포를 식별하기 위한 이름으로 본인이 구분하기 위한 용도로 적으면 된다.
Description 은 말그대로 해당 cloudFront 에 대한 설명을 추가하는 것이므로 생략해도 된다.
이후 AWS의 도메인 관리 서비스인 Route53에 등록된 도메인이 있다면 배포할 사이트의 도메인을 바로 설정해주면 된다. 현재 등록이 되어있지 않다면 패스!
- CloudFront 의 원본 지정
현재 빌드 파일을 S3에 저장했기에 origin type 을 S3로 선택한다.
Browse S3 버튼을 통해 만들어둔 S3 버킷을 선택하면 해당 버킷의 주소가 자동으로 입력된다.
origin path 는 S3 버킷 내부에서 버킷의 최상위가 아닌 곳에 빌드 파일을 넣었다면 해당 경로를 추가해주면된다. 이전 과정처럼 루트에 바로 넣었다면 패스!
Allow private S3 bucket access to CloudFront - 활성화
- 이 옵션을 통해 S3의 퍼블릭 액세스를 차단한 상태에서도 S3에게 CloudFront가 접근할 수 있게 해준다.
- WAF 보안
웹 방화벽(WAF)을 통해 공격을 막을지 등의 옵션이다.
WAF 는 추가 비용이 발생할 수 있기에 상황에 따라 적절하게 선택하면 된다!
- 생성
이후 지금까지 적용한 옵션들을 확인한 후 create 를 완료하면 된다.
- S3 버킷 정책 업데이트
생성 후 S3 버킷 정책을 업데이트 해야한다는 경고가 뜰 것이다. 그때 정책을 복사하여 이전에 생성한 S3로 이동한다.
그럼 이제 cloudfront 에 배포된 URI로 접근을 할 수 있다
배포 후 다른 페이지가 안 들어가진다면 ..
배포 후 다른 페이지가 안 들어가진다면 오류 페이지 설정해볼 것.
cloudfront → 배포 → 오류 페이지에 들어간 다음, 사용자 정의 오류 응답 생성
지금까지는 웹 호스팅을 위한(정적인 파일을 사용자들이 URL을 통해 접근할 수 있도록) 작업이었다. 아래는 우리가 원하는 도메인으로 연결할 수 있는 과정이다
도메인 연결 과정에 대한 과정은 아래 포스팅을 참고하면 좋을 것 같고, 이후 내용에서는 내부에서 사용되는 용어나 과정이 왜 필요한지를 간단하게 알아가고자 한다.
TODO : 도메인 연결 .. 토요일안에 채우겟습니다 ..
도메인 연결 과정에 대한 과정은 아래 포스팅을 참고하면 좋을 것 같고, 이후 내용에서는 내부에서 사용되는 용어나 과정이 왜 필요한지를 간단하게 알아가고자 한다.
4. Route53
본인이 원하는 도메인을 구매한 후 (구매처는 자유) Route 53을 생성해야한다.
Route 53은 특정 도메인을 CloudFront 주소로 연결해주는 DNS 역할을 위한 것이다.
Route53 에서 호스팅 영역을 만들면 DNS 레코드 관리가 가능하다.
여기서 DNS 레코드는 도메인 이름과 실제 리소스(IP, 다른 도메인 등)를 연결하는 규칙이라고 볼 수 있다.
- 주요 DNS 레코드 종류
레코드 의미 연결 대상 예시 A IPv4 주소로 연결 123.45.67.89 example.com → 123.45.67.89 AAAA IPv6 주소로 연결 2001:db8::1 example.com → 2001:db8::1 CNAME 다른 도메인으로 연결 target.example.com www.example.com → example.com NS
5. AWS Certificate Manager
HTTPS를 적용하기 위해서는 SSL 인증서가 필요하다.
ACM은 AWS에서 인증서를 만들고 CloudFront에 적용할 수 있도록 해준다
6. 최종적인 AWS 흐름
[사용자의 브라우저]│example.com 요청│┌──── DNS 조회 ────┐│ 로컬 캐시 확인 │ (최근 방문했으면 DNS 캐시 사용)│ 없으면 ISP DNS │ → 루트 DNS → TLD DNS → NS 조회└──────────────────┘│Route 53 (Hosted Zone
- 브라우저가 example.com을 해석하려고 한다
- Route 53의 NS 서버로 간다
(이 도메인에 대한 설정은 Route 53이 가지고 있음을 알려줌)
- Hosted Zone 안에 있는 레코드 목록에서 A 레코드 확인
→ CloudFront 배포 주소 반환
- 브라우저가 CloudFront 로 요청을 보낸다
- CloudFront가 캐시된 정적 파일이 있으면 바로 응답, 없으면 S3에서 가져온다
- 브라우저가 응답받은 HTML/JS/CSS를 실행해 화면을 그린다
- SPA라면 JS가 실행되면서 라우팅·인터랙션이 이루어진다
- 참고
