배포하기

Angular 애플리케이션을 원격 서버에 배포할 준비가 되었다면 다양한 방법 중에서 선택할 수 있습니다.

CLI로 자동 배포하기

Angular CLI의 ng deploy 명령어는 프로젝트에 연결된 deploy CLI 빌더를 실행합니다. 여러 서드 파티 빌더가 다양한 플랫폼으로 배포하는 기능을 제공합니다. 이러한 빌더는 ng add로 프로젝트에 추가할 수 있습니다.

배포 기능을 제공하는 패키지를 추가하면 워크스페이스 설정(angular.json 파일)에서 선택한 프로젝트에 deploy 항목이 자동으로 추가됩니다. 그러면 ng deploy 명령어로 해당 프로젝트를 배포할 수 있습니다.

예를 들어 다음 명령어는 프로젝트를 Firebase에 자동으로 배포합니다.

ng add @angular/fire
ng deploy

이 명령어는 대화형으로 실행됩니다. 이 경우 Firebase 계정을 가지고 있거나 새로 만든 뒤 해당 계정으로 인증해야 합니다. 명령어는 배포할 Firebase 프로젝트를 선택하도록 안내한 뒤 애플리케이션을 빌드하고 프로덕션 리소스를 Firebase에 업로드합니다.

다음 표는 다양한 플랫폼으로 배포하는 기능을 제공하는 도구입니다. 각 패키지의 deploy 명령어는 서로 다른 명령줄 옵션을 요구할 수 있습니다. 아래 패키지 이름의 링크에서 자세한 내용을 확인하세요:

직접 관리하는 서버에 배포하거나 원하는 클라우드 플랫폼용 빌더가 없다면 ng deploy 명령어를 사용할 수 있도록 빌더를 만들거나, 이 가이드를 계속 읽고 애플리케이션을 수동으로 배포하는 방법을 알아보세요.

원격 서버에 수동으로 배포하기

애플리케이션을 수동으로 배포하려면 프로덕션 빌드를 생성하고 빌드 결과물을 호스팅 환경에 배포합니다. ng build는 기본적으로 production 설정을 사용합니다. 빌드 설정을 직접 변경했다면 배포하기 전에 프로덕션 최적화가 적용되는지 확인하는 것이 좋습니다.

ng build는 기본적으로 빌드 결과물을 dist/my-app/에 출력하지만, @angular/build:application 빌더의 outputPath 옵션으로 이 경로를 변경할 수 있습니다. 배포할 대상은 애플리케이션의 렌더링 방식에 따라 달라집니다:

• 정적 호스팅(클라이언트 측 렌더링 또는 outputMode: "static"): dist/my-app/browser/ 디렉터리를 웹 서버나 콘텐츠 전송 네트워크(CDN)에 복사하고, 해당 디렉터리의 파일을 제공하도록 설정합니다.
• 서버 측 렌더링(outputMode: "server"): dist/my-app/browser/와 dist/my-app/server/ 디렉터리를 모두 서버에 복사한 다음, node dist/my-app/server/server.mjs를 실행합니다.

자세한 내용은 서버 및 하이브리드 렌더링을 참고하세요.

최소한의 배포 방법은 이렇지만, 서버가 Angular 애플리케이션을 올바르게 제공하려면 몇 가지 요건을 충족해야 합니다.

서버 설정

이 섹션에서는 Angular 애플리케이션을 실행하기 위해 서버에서 변경해야 할 수 있는 설정을 알아봅니다.

라우팅을 사용하는 앱은 index.html로 대체 응답해야 합니다

클라이언트에서 렌더링하는 Angular 애플리케이션은 모든 콘텐츠가 정적이고 빌드 시점에 생성되기 때문에 정적 HTML 서버로 제공하기에 적합합니다.

애플리케이션에서 Angular 라우터를 사용한다면 서버에 없는 파일을 요청받았을 때 애플리케이션의 호스트 페이지(index.html)를 반환하도록 서버를 설정해야 합니다.

라우팅을 사용하는 애플리케이션은 "딥 링크"를 지원해야 합니다. 딥 링크(deep link) 는 애플리케이션 내부 컴포넌트의 경로를 지정하는 URL입니다. 예를 들어 http://my-app.test/users/42는 id가 42인 사용자를 표시하는 사용자 상세 페이지의 딥 링크 입니다.

사용자가 처음에 인덱스 페이지를 불러온 뒤 실행 중인 클라이언트 안에서 해당 URL로 이동할 때는 문제가 없습니다. Angular 라우터는 클라이언트 측에서 화면을 전환하며 새로운 HTML 페이지를 요청하지 않습니다.

하지만 이메일의 딥 링크를 클릭하거나 브라우저 주소창에 입력하거나 딥 링크로 연결된 페이지에서 브라우저를 새로고침하면, 실행 중인 애플리케이션 밖에서 브라우저 자체가 이를 처리합니다. 브라우저는 Angular 라우터를 거치지 않고 서버에 /users/42를 직접 요청합니다.

정적 서버는 보통 http://my-app.test/ 요청을 받으면 index.html을 반환합니다. 하지만 대부분의 서버는 기본적으로 http://my-app.test/users/42 요청을 거부하고 404 - Not Found 오류를 반환합니다. 이를 대신해서 index.html을 반환하도록 설정해야 합니다. 서버의 대체 라우팅 규칙이나 404 페이지를 index.html로 설정하면 딥 링크 요청에도 Angular가 제공되어 올바른 라우팅 규칙의 화면을 표시할 수 있습니다. 일부 서버는 이러한 대체 응답 방식을 "단일 페이지 애플리케이션"(SPA) 모드라고 부릅니다.

브라우저가 애플리케이션을 불러오면 Angular 라우터가 URL을 읽어서 현재 페이지를 판단하고 /users/42를 올바르게 표시합니다.

http://my-app.test/does-not-exist와 같은 "실제" 404 페이지를 위해 서버에 추가 설정을 할 필요는 없습니다. Angular 라우터로 구현한 404 페이지가 올바르게 표시됩니다.

다른 서버에서 데이터 요청하기(CORS)

웹 개발자는 애플리케이션을 호스팅하는 서버가 아닌 다른 서버로 네트워크 요청을 보낼 때 교차 출처 리소스 공유 오류를 만날 수 있습니다. 브라우저는 서버가 명시적으로 허용하지 않는 한 이러한 요청을 차단합니다.

Angular나 클라이언트 애플리케이션에서 이러한 오류를 해결할 수는 없습니다. 애플리케이션의 요청을 받아들이도록 서버를 설정해야 합니다. 서버별 CORS 활성화 방법은 enable-cors.org를 참고하세요.

운영 환경 최적화

별도로 설정하지 않으면 ng build는 production 설정을 사용합니다. 이 설정은 다음 빌드 최적화 기능을 활성화합니다.

CLI 빌드 옵션과 그 효과는 ng build를 참고하세요.

개발 전용 기능

ng serve로 애플리케이션을 로컬에서 실행하면 Angular는 실행 시점에 개발 설정을 사용하며 다음 기능을 활성화합니다:

• expression-changed-after-checked 감지 등의 추가 안전 검사.
• 더 자세한 오류 메시지.
• 디버깅 함수를 제공하는 전역 ng 변수와 Angular DevTools 지원 등의 추가 디버깅 도구.

이러한 기능은 개발할 때 유용하지만 앱에 추가 코드가 필요하기 때문에 프로덕션에는 적합하지 않습니다. 최종 사용자에게 전달하는 번들 크기에 영향을 주지 않도록 Angular CLI는 프로덕션 빌드에서 개발 전용 코드를 제거합니다.

ng build로 애플리케이션을 빌드하면 기본적으로 production 설정을 사용하며, 번들 크기를 최적화하기 위해 출력 결과에서 이러한 기능을 제거합니다.

--deploy-url

--deploy-url은 이미지, 스크립트, 스타일시트와 같은 리소스의 상대 URL을 해석할 기준 경로를 컴파일 시점에 지정하는 명령줄 옵션입니다.

ng build --deploy-url /my/assets

--deploy-url의 효과와 용도는 <base href>와 겹칩니다. 둘 다 초기 스크립트, 스타일시트, 지연 로딩 스크립트, CSS 리소스에 사용할 수 있습니다.

<base href>는 실행 시점에 한 곳에서 정의할 수 있지만 --deploy-url은 빌드 시점에 애플리케이션에 하드코딩해야 합니다. 가능하면 <base href>를 사용하세요.