# 배포: 내부 살펴보기

이 문서는 Wagtail 호스팅 개념에 대한 기술적 심층 분석을 제공합니다. 대부분의 경우, 대신 [호스팅 제공업체를 선택](index.md)하고 싶을 것입니다.

Wagtail은 Django를 기반으로 구축되었으므로 Django 배포에 대한 배포 단계 및 고려 사항의 대부분이 Wagtail에도 동일하게 적용됩니다. Django의 ["Django 배포 방법"](inv:django#howto/deployment/index) 문서를 읽는 것을 권장합니다.

## 인프라 요구 사항

Wagtail 사이트 호스팅을 위한 인프라를 설계할 때 몇 가지 기본 요구 사항이 있습니다:

### WSGI / ASGI 서버

> 웹 프레임워크인 Django는 작동하기 위해 웹 서버가 필요합니다. 대부분의 웹 서버는 기본적으로 Python을 사용하지 않으므로 통신이 이루어지도록 인터페이스가 필요합니다.

Wagtail은 [WSGI](inv:django#howto/deployment/wsgi/index) 또는 [ASGI](inv:django#howto/deployment/asgi/index)를 사용하여 배포할 수 있지만, Wagtail은 기본적으로 비동기 뷰나 미들웨어를 구현하지 않으므로 WSGI를 권장합니다.

### 정적 파일

모든 Django 프로젝트와 마찬가지로, 정적 파일은 개발 중에 `manage.py runserver` 명령을 통해 실행할 때 Django 애플리케이션 서버에 의해서만 제공됩니다. 프로덕션 환경에서는 웹 서버 수준에서 별도로 처리해야 합니다.
[Django의 정적 파일 배포에 대한 문서](inv:django#howto/static-files/deployment)를 참조하세요.

Wagtail 관리자에 사용되는 자바스크립트 및 CSS 파일은 Wagtail 릴리스 간에 자주 변경됩니다 - 브라우저 또는 서버 측 캐싱으로 인해 오래된 버전의 파일이 제공되는 것을 피하는 것이 중요합니다. 이는 진단하기 어려운 문제를 일으킬 수 있습니다.
`STORAGES["staticfiles"]` 설정에서 [ManifestStaticFilesStorage](django.contrib.staticfiles.storage.ManifestStaticFilesStorage)를 활성화하는 것을 권장합니다 - 이렇게 하면 다른 버전의 파일에 고유한 URL이 할당됩니다.

(user_uploaded_files)=

### 사용자 업로드 파일

Wagtail은 [Django의 업로드 파일 관리 규칙](inv:django#topics/files)을 따릅니다.
따라서 기본적으로 Wagtail은 Django의 내장 `FileSystemStorage` 클래스를 사용하여 `MEDIA_ROOT` 설정에 지정된 디렉터리에 있는 사이트 서버에 파일을 저장합니다.
또는 Amazon S3와 같은 클라우드 스토리지 서비스에 업로드된 이미지와 문서를 저장하도록 Wagtail을 구성할 수 있습니다.
이는 [django-storages](https://django-storages.readthedocs.io/)와 같은 애드온 패키지와 함께 [`STORAGES["default"]`](inv:django#STORAGES) 설정을 통해 수행됩니다.

#### 보안

사용자 업로드 파일을 허용하는 모든 시스템은 잠재적인 보안 위험입니다. 예를 들어, HTML 파일을 업로드할 수 있는 사용자는 해당 파일을 보는 사용자에 대해 [사이트 간 스크립팅 공격](https://owasp.org/www-community/attacks/xss/)을 시작할 수 있습니다. Wagtail 관리자에 액세스할 수 있는 모든 사용자가 완전히 신뢰할 수 있는 경우(예: 당신이 유일한 편집자인 개인 사이트) 이는 문제가 되지 않을 수 있습니다. 이를 염두에 두고 Wagtail은 기본적으로 보안 구성을 제공하는 것을 목표로 하지만, 개발자는 아래에 자세히 설명된 위험을 이해한다면 더 허용적인 설정을 선택할 수 있습니다.

#### 이미지

`FileSystemStorage` 를 사용할 때 이미지 URL은 `MEDIA_URL` 에 지정된 경로에서 시작하여 구성됩니다.
대부분의 경우, 웹 서버가 `MEDIA_ROOT` 의 `images` 하위 디렉터리에서 직접 이미지 파일을 제공하도록 구성하고(Django/Wagtail을 통하지 않고) `original_images` 하위 디렉터리에 대한 액세스를 차단해야 합니다.
[](svg_images)가 활성화된 경우, 사용자가 파일을 직접 볼 때 실행되는 스크립트가 포함된 SVG 파일을 업로드할 수 있습니다. 이것이 우려되는 경우, 이를 피하기 위한 몇 가지 방법이 [](svg_security_considerations)에 자세히 설명되어 있습니다.

클라우드 스토리지 백엔드 중 하나를 사용하는 경우, 이미지 URL은 클라우드 스토리지 파일 URL로 직접 이동합니다.
별도의 자산 서버나 CDN에서 이미지를 제공하려면 [이미지 제공 뷰를 구성](image_serve_view_redirect_action)하여 대신 리디렉션할 수 있습니다.

#### 문서

문서 제공은 [WAGTAILDOCS_SERVE_METHOD](wagtaildocs_serve_method) 메서드에 의해 제어됩니다.
`FileSystemStorage` 를 사용하는 경우, 문서는 사이트의 `MEDIA_ROOT` 내 `documents` 하위 디렉터리에 저장됩니다. 이 경우 `WAGTAILDOCS_SERVE_METHOD` 는 기본적으로 `serve_view` 이며, Wagtail은 개인 정보 보호 검사를 시행하는 Django 뷰를 통해 문서를 제공합니다.

대체 제공 방법인 `'direct'` 및 `'redirect'` 는 `MEDIA_ROOT` 에서 직접 문서를 제공하여 작동합니다. 이는 `documents` 하위 디렉터리에 대한 직접 액세스를 차단할 수 없음을 의미합니다.

원격("클라우드") 스토리지 백엔드를 사용하는 경우, 제공 방법은 기본적으로 `'redirect'` 가 되며 문서는 클라우드 스토리지 파일 URL에서 직접 제공됩니다. 이 경우(그리고 `'direct'` 의 경우), Wagtail은 파일이 제공되는 방식에 대한 제어가 적어 추가 구성이 필요할 수 있습니다.

사용자 업로드 파일을 허용하는 모든 시스템은 잠재적인 보안 위험입니다. `WAGTAILDOCS_SERVE_METHOD` 가 `serve_view` 로 설정되면, Wagtail은 문서가 안전하게 제공되도록 보장하고 권한 확인을 시행하며 사이트 간 스크립팅을 방지합니다. 대체 제공 방법인 `'direct'` 및 `'redirect'` 는 구성된 스토리지 백엔드를 통해 `MEDIA_ROOT` 에서 직접 문서를 제공하여 작동합니다. 이러한 경우, 업로드된 파일이 안전하게 제공되도록 추가적인 주의를 기울여야 합니다. 업로드된 문서를 보호하기 위한 몇 가지 접근 방식이 [](documents_security_considerations)에 자세히 설명되어 있습니다.


#### 클라우드 스토리지

원격 스토리지를 설정해도 파일 처리 작업이 애플리케이션 서버에서 완전히 오프로드되지는 않는다는 점에 유의하세요. 일부 Wagtail 기능은 애플리케이션 서버에서 파일을 다시 읽어야 합니다.
특히, 새 크기 조정된 렌디션이 생성될 때마다 원본 이미지 파일을 다시 읽어야 하며, 문서는 권한 확인을 시행하기 위해 Django 뷰를 통해 제공되도록 구성될 수 있습니다( [WAGTAILDOCS_SERVE_METHOD](wagtaildocs_serve_method) 참조).

```{note}
django-storages Amazon S3 백엔드(`storages.backends.s3boto.S3BotoStorage` 및 `storages.backends.s3boto3.S3Boto3Storage`)는 기본 구성에서 **중복 파일 이름을 올바르게 처리하지 못합니다**. 이러한 백엔드를 사용할 때는 `AWS_S3_FILE_OVERWRITE` 를 `False` 로 설정해야 합니다.
```

### 캐시

Wagtail은 페이지 로드를 가속화하기 위해 사용 가능할 때 Django의 [캐시 프레임워크](inv:django#topics/cache)를 활용하도록 설계되었습니다. 캐시는 특히 기존의 CDN 캐싱을 활용할 수 없는 Wagtail 관리자에 유용합니다.

Wagtail은 Django의 모든 캐시 백엔드를 지원하지만, Django가 실행 중인 특정 프로세스나 환경에 연결된 것(예: `FileBasedCache` 또는 `LocMemCache`)은 사용하지 않는 것이 좋습니다.

## 배포 팁

Wagtail, 그리고 확장하여 Django는 다양한 플랫폼에서 다양한 방법으로 배포될 수 있습니다. 배포하는 "최고의" 방법은 없지만, 사이트를 가능한 한 안정적이고 유지 관리 가능하게 만들기 위한 몇 가지 팁이 있습니다:

### Django의 배포 체크리스트 사용하기

Django에는 Django 애플리케이션을 배포하기 전에 수행했어야 하거나 알아야 할 모든 것을 실행하는 [배포 체크리스트](inv:django#howto/deployment/checklist)가 있습니다.

### 성능 최적화

프로덕션 사이트는 가능한 한 빠르고 성능이 좋아야 합니다. Wagtail이 가능한 한 잘 수행되도록 하는 방법에 대한 팁은 [성능 팁](performance_overview)을 참조하세요.

(deployment_examples)=

## 배포 예시

몇몇 호스팅 플랫폼에서의 배포 예시는 [](/advanced_topics/third_party_tutorials)에서 찾을 수 있습니다. 이는 Wagtail을 실행할 수 있는 플랫폼의 전체 목록이 아니며, 거기서 Wagtail을 실행하는 유일한 방법도 아닙니다.

프로덕션 Wagtail 사이트의 예로는 Heroku에서 실행되는 [guide.wagail.org](https://guide.wagtail.org/)가 있으며, 이는 [오픈 소스](https://github.com/wagtail/guide)입니다. 호스팅 환경에 대한 자세한 정보는 [해당 문서](https://github.com/wagtail/guide/blob/main/docs/hosting-environment.md)에서 찾을 수 있습니다.

플랫폼이나 인프라에 Wagtail을 성공적으로 설치했다면, 이 문서에 여러분의 노트를 [기여](../contributing/index)해주세요!