[Angular 마스터하기] Day 19 - 배포하기, 내 앱을 세상에!
![[Angular 마스터하기] Day 19 - 배포하기, 내 앱을 세상에!](/assets/img/posts/angular/angular-day-19.png)
이제와서 시작하는 Angular 마스터하기 - Day 19 “완성한 앱을 세상에 공개해봅시다! 🌍”
오늘 배울 내용
- 빌드 프로세스
- GitHub Pages 배포 설정
- Netlify/Vercel 배포
- 환경별 설정 관리
- 배포 전 점검 체크리스트
1. 프로덕션 빌드
1
2
3
4
# 프로덕션 빌드
ng build
# 결과물은 dist/ 폴더에 생성됨
Angular CLI의 프로덕션 빌드는 기본적으로 최적화 옵션을 적용합니다. 코드 압축, Tree shaking, AOT 컴파일, CSS 최적화가 함께 동작해 브라우저에 전달되는 파일 크기를 줄입니다.
빌드 후에는 dist/프로젝트명/browser 폴더를 확인합니다. 최신 Angular 프로젝트는 SSR/Prerender 설정 여부에 따라 browser 하위 폴더가 만들어질 수 있으므로, 배포 플랫폼의 publish directory를 실제 결과물 위치와 맞추는 것이 중요합니다.
1
2
# 번들 크기 확인에 유용한 통계 파일 생성
ng build --stats-json
번들 크기가 지나치게 크다면 Lazy Loading, 이미지 최적화, 사용하지 않는 라이브러리 제거를 먼저 확인하세요.
2. GitHub Pages 배포
GitHub Pages는 정적 파일 배포에 적합합니다. 프로젝트가 저장소 루트가 아닌 /저장소명/ 경로 아래에서 제공되므로 base-href 설정이 핵심입니다.
1
2
3
4
5
6
# angular-cli-ghpages 설치
npm install -g angular-cli-ghpages
# 빌드 및 배포
ng build --base-href="/프로젝트명/"
ngh --dir=dist/프로젝트명/browser
체크할 부분:
- 저장소 이름과
--base-href값이 일치하는지 확인합니다. - GitHub Pages 설정에서 배포 브랜치가 맞는지 확인합니다.
- 라우터를 쓰는 SPA라면 새로고침 시 404가 발생할 수 있으므로, 플랫폼별 fallback 설정을 확인합니다.
규모가 있는 프로젝트라면 전역 설치보다 npm script로 배포 명령을 고정하는 편이 재현성이 좋습니다.
1
2
3
4
5
6
{
"scripts": {
"build:pages": "ng build --base-href=/my-angular-app/",
"deploy:pages": "ngh --dir=dist/my-angular-app/browser"
}
}
3. Netlify와 Vercel 배포
Netlify와 Vercel은 GitHub 저장소를 연결하면 push를 기준으로 자동 배포를 구성할 수 있습니다.
기본 설정:
- Build command:
ng build - Publish directory:
dist/프로젝트명/browser - Node.js version: 프로젝트에서 사용하는 버전과 맞추기
SPA 라우팅을 사용하는 경우, 직접 URL로 접근했을 때도 index.html로 돌아가도록 rewrite 설정이 필요합니다.
Netlify 예시:
1
2
# public/_redirects 또는 배포 결과물에 포함되는 _redirects
/* /index.html 200
Vercel 예시:
1
2
3
4
5
{
"rewrites": [
{ "source": "/(.*)", "destination": "/index.html" }
]
}
4. 환경별 설정 관리
Angular에서는 빌드 구성별로 다른 파일을 교체하거나, 런타임 설정 파일을 별도로 불러오는 방식으로 환경값을 관리합니다. 간단한 앱에서는 environment 파일로 충분하지만, 배포 후 값을 바꿔야 하는 서비스라면 런타임 설정 방식도 고려해야 합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// environment.ts
export const environment = {
production: false,
apiUrl: 'http://localhost:3000'
};
// environment.prod.ts
export const environment = {
production: true,
apiUrl: 'https://api.example.com'
};
// 사용
import { environment } from '../environments/environment';
@Injectable()
export class ApiService {
apiUrl = environment.apiUrl;
}
주의할 점:
- 프론트엔드 환경값은 브라우저에 노출됩니다.
- API 키, 비밀 토큰, DB 비밀번호는 절대 Angular 앱에 넣지 않습니다.
- 공개 가능한 API 주소, 기능 플래그, Sentry DSN 같은 값만 사용합니다.
5. CI/CD 기본 예시
GitHub Actions로 빌드 검증을 자동화하면 배포 전에 문제를 빠르게 잡을 수 있습니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
name: Angular CI
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
cache: npm
- run: npm ci
- run: npm test -- --watch=false
- run: npm run build
팀 프로젝트에서는 배포 전에 최소한 테스트와 빌드가 모두 통과하도록 보호 규칙을 두는 것이 좋습니다.
6. 실습: 배포 전 점검하기
배포 직전 아래 순서로 확인해보세요.
ng test --watch=false로 테스트를 한 번 실행합니다.ng build로 프로덕션 빌드를 만듭니다.dist폴더의 실제 publish directory를 확인합니다.- 라우팅이 있는 페이지를 새로고침해도 깨지지 않는지 확인합니다.
- API 주소가 운영 환경을 바라보는지 확인합니다.
- 브라우저 개발자 도구에서 콘솔 오류와 네트워크 404를 확인합니다.
📝 정리
배포 플랫폼
- GitHub Pages: 문서, 포트폴리오, 정적 SPA에 적합
- Netlify: 정적 사이트와 간단한 CI/CD 설정에 편리
- Vercel: 프론트엔드 프로젝트 배포 경험이 좋고 preview 배포가 강점
- Firebase Hosting: Firebase 생태계와 함께 쓸 때 유용
체크리스트
- 프로덕션 빌드를 할 수 있나요?
- publish directory가 실제 빌드 결과물과 일치하나요?
- SPA 라우팅 fallback을 설정했나요?
- 테스트와 빌드를 CI에서 확인하나요?
- 브라우저에 노출되면 안 되는 비밀값을 제거했나요?
- 운영 API 주소와 CORS 설정을 확인했나요?
📚 다음 학습
“배포는 개발의 완성입니다!” 🌍