# Django 6.0.7 문서

# 시스템 점검 프레임워크

시스템 검사 프레임워크는 Django 프로젝트의 유효성을 검사하기 위한 일련의 정적 검사입니다. 일반적인 문제를 감지하고 해결 방법에 대한 힌트를 제공합니다. 프레임워크는 확장 가능하므로 자체 검사를 쉽게 추가할 수 있습니다.

자신의 검사를 추가하고 Django의 시스템 검사와 통합하는 방법에 대한 자세한 내용은 :doc:`System check topic guide </topics/checks>`을 참조하십시오.

## API 레퍼런스

### “체크 메세지”

class CheckMessage(level, msg, hint=None, obj=None, id=None)

  시스템 검사에서 발생하는 경고 및 오류는 ``CheckMessage``의 인스턴스여야 합니다. 인스턴스는 보고 가능한 단일 오류 또는 경고를 캡슐화합니다. 또한 메시지에 적용할 수 있는 컨텍스트 및 힌트와 필터링 목적으로 사용되는 고유 식별자를 제공합니다.

  생성자 인수는 다음과 같습니다:

  “레벨”

    The severity of the message. Use one of the predefined values: `DEBUG` , `INFO`, `WARNING`, `ERROR`, `CRITICAL`. If the level is greater or equal to `ERROR`, then Django will prevent management commands from executing. Messages with level lower than `ERROR` (i.e. warnings) are reported to the console, but can be silenced.

  “msg”

    문제를 설명하는 짧은(80자 미만) 문자열입니다. 문자열은 개행 문자를 포함하지 않아야 합니다.

  “힌트”

    문제 해결을 위한 힌트를 제공하는 한 줄 문자열입니다. 힌트를 제공할 수 없거나, 오류 메시지에서 힌트가 자명한 경우 힌트를 생략하거나 `None` 값을 사용할 수 있습니다.

  “오브젝트”

    선택 사항. 메시지에 대한 컨텍스트를 제공하는 객체(예: 문제가 발견된 모델). 객체는 모델, 필드, 관리자 또는 `__str__()` 메서드를 정의하는 다른 객체여야 합니다. 이 메서드는 모든 메시지를 보고할 때 사용되며 그 결과가 메시지보다 우선합니다.

  “아이디”

    선택적 문자열. 문제의 고유 식별자. 식별자는 `applabel.X001` 패턴을 따라야 합니다. 여기서 `X``는 메시지 심각도를 나타내는 ``CEWID` 문자 중 하나입니다(중요의 경우 `C`, 오류의 경우 `E`). 등등). 번호는 애플리케이션에서 할당할 수 있지만, 해당 애플리케이션 내에서 고유한 값이어야 합니다.

공통 수준으로 메시지를 더 쉽게 만들 수 있는 하위 클래스가 있습니다. 그것들을 사용할 때 `level` 인수는 클래스 이름에 의해 암시되기 때문에 생략할 수 있습니다.

class Debug(msg, hint=None, obj=None, id=None)

class Info(msg, hint=None, obj=None, id=None)

class Warning(msg, hint=None, obj=None, id=None)

class Error(msg, hint=None, obj=None, id=None)

class Critical(msg, hint=None, obj=None, id=None)

## 내장되어있는 태그들

Django의 시스템 체크들은 다음의 태그들을 사용하여 정리되어 있습니다.

- `admin`: 관리 사이트 선언을 확인합니다.

- `async_support`: 비동기 관련 구성을 확인합니다.

- `caches`: 캐시 관련 구성을 확인합니다.

- `호환성`: 버전 업그레이드와 관련된 잠재적인 문제를 표시합니다.

- `commands`: 구성과 관련된 사용자 지정 관리 명령을 확인합니다.

- `database`: Checks database-related configuration issues. Database checks are not run by default because they do more than only static code analysis as most regular checks do. They are only run by the `migrate` command or if you specify configured database aliases using the `--database` option when calling the `check` command.

- `files`: 파일 관련 구성을 확인합니다.

- `mail`: Checks email related configuration.

- `models`: 모델, 필드 및 관리자 정의를 확인합니다.

- `security`: 보안 관련 구성을 확인합니다.

- `signals`: 신호 선언 및 처리기 등록을 확인합니다.

- `sites`: `django.contrib.sites` 구성을 확인합니다.

- `staticfiles`: `django.contrib.staticfiles` 구성을 확인합니다.

- `templates`: 템플릿 관련 구성을 확인합니다.

- `translation`: 번역 관련 설정을 확인합니다.

- `urls`: URL 구성을 확인합니다.

일부 확인은 여러 태그로 등록될 수 있습니다.

## 핵심 시스템 체크

### 비동기 지원

다음 검사는 :doc:`/topics/async`에 대한 설정을 확인합니다:

- async.E001: 배포 시 `DJANGO_ALLOW_ASYNC_UNSAFE` 환경 변수를 설정하면 안 됩니다. 설정하면 :ref:`비동기 안전 보호 <async-safety>`이 비활성화됩니다.

### 이전 버전과의 호환성

호환성 검사는 Django를 업그레이드한 후 발생할 수 있는 잠재적 문제에 대해 경고합니다.

- 2_0.W001: URL 패턴 ``<pattern>``에는 ``(?P<``를 포함하거나 ``^``로 시작하거나 ``$``로 끝나는 ``route``가 있습니다. 이것은 ``url()``에서 :func:`~django.urls.path`로 마이그레이션할 때 발생한 오류일 것입니다.

- 4_0.E001: Django 4.0부터 `CSRF_TRUSTED_ORIGINS` 설정의 값은 스킴(보통 `http://` 또는 `https://`)로 시작해야 하지만 ‘<hostname>’을 찾았습니다.

### 캐시들

다음 검사는 `CACHES` 설정이 올바르게 구성되었는지 확인합니다:

- caches.E001: `CACHES` 설정에서 `'default'` 캐시를 정의해야 합니다.

- caches.W002: `<cache>` 구성은 해당 `LOCATION <CACHES-LOCATION>`가 :setting:`MEDIA_ROOT`/`STATIC_ROOT`/:setting:`STATICFILES_DIRS`와 일치/내부에 있음/포함하고 있기 때문에 캐시를 노출하거나 데이터 손상으로 이어질 수 있습니다.

- caches.W003: `<cache>` 캐시 :setting:`LOCATION <CACHES-LOCATION>`는 상대적입니다. 대신 절대 경로를 사용하십시오.

### 데이터베이스

#### MySQL 과 MariaDB

MySQL 또는 MariaDB를 사용하는 경우, 다음 검사가 수행됩니다:

- mysql.E001: MySQL/MariaDB는 고유한 `CharField`s가 `max_length` > 255를 갖는 것을 허용하지 않습니다. 이 검사는 실제 최대 크기는 여러 요인에 따라 달라지므로 Django 3.1에서*``mysql.W003``*으로 변경되었습니다.

- mysql.W002: 데이터베이스 연결 ``<alias>``에 대해 MySQL/MariaDB Strict Mode가 설정되지 않았습니다. :ref:`mysql-sql-mode`를 참조하십시오.

- mysql.W003: MySQL/MariaDB는 고유한 `CharField`s가 `max_length` > 255를 갖는 것을 허용하지 않을 수 있습니다.

### Mail

The following checks verify that your `MAILERS` setting is correctly configured:

- mail.E001: Your `MAILERS` setting uses a development-only email backend in the `'default'` entry (`<backend>`). (Only checked when the `check --deploy` option is used.)

- mail.W001: Your `MAILERS` setting has no `'default'` entry. Sending email without a valid mailer will fail.

### 파일 관리하기

다음 검사는 :doc:`/topics/files`에 대한 설정을 확인합니다:

- files.E001: `FILE_UPLOAD_TEMP_DIR` 설정은 존재하지 않는 디렉토리 ``<path>``을 참조합니다.

### 모델 필드들

- fields.E001: 필드 이름은 underscore로 끝나서는 안됩니다.

- fields.E002: 필드 이름들은 ``”__”``을 포함해서는 안됩니다.

- fields.E003: ``pk``는 필드 이름으로 사용될 수 없는 예약어입니다.

- fields.E004: `choices` must be a mapping (e.g. a dictionary) or an ordered iterable (e.g. a list or tuple, but not a set).

- fields.E005: `choices``는 실제 값을 사람이 읽을 수 있는 이름에 매핑한 것이거나 ``(actual value, human readable name)` 튜플로 이루어진 이터러블이어야 합니다.

- fields.E006: `db_index``는 ``None`, `True` 또는 `False` 중 하나여야 합니다.

- fields.E007: Primary key는 ``null=True``여서는 안됩니다.

- fields.E008: 모든 ``validators``는 호출 가능해야 합니다.

- fields.E009: `max_length``가 너무 작아 ``choices``(``<count>` 문자)의 가장 긴 값에 맞지 않습니다.

- fields.E010: `<field>` 기본값은 모든 필드 인스턴스 간에 공유되지 않도록 인스턴스 대신 콜러블이어야 합니다.

- fields.E011: `<database>``은 표현식을 사용하는 기본 데이터베이스 값(``db_default`)을 지원하지 않습니다.

- fields.E012: ``<expression>``은 ``db_default``에서 사용할 수 없습니다.

- fields.E013: ``CompositePrimaryKey``의 이름은 ``pk``여야 합니다.

- fields.E100: ``AutoField``는 primary_key=True로 설정되어야 합니다.

- fields.E110: `BooleanField`s는 null 값을 허용하지 않습니다. 이 검사는 Django 2.1에서 null 값 지원이 추가되기 전에 나타났습니다.

- fields.E120: `CharField``는 ``max_length` 속성을 정의해야 합니다.

- fields.E121: ``max_length``는 양의 정수여야 합니다.

- fields.W122: ``max_length``는 ``<integer field type>``과 함께 사용할 때 무시됩니다.

- fields.E130: `DecimalField`s는 `decimal_places` 속성을 정의해야 합니다.

- fields.E131: ``decimal_places``는 음이 아닌 정수여야 합니다.

- fields.E132: `DecimalField`s는 `max_digits` 속성을 정의해야 합니다.

- fields.E133: ``max_digits``는 양의 정수여야 합니다.

- fields.E134: ``max_digits``는 ``decimal_places``보다 크거나 같아야 합니다.

- fields.E135: `DecimalField`’s `max_digits` and `decimal_places` must both be defined or both omitted.

- fields.E140: `FilePathField`s에는 `allow_files` 또는 ``allow_folders``가 True로 설정되어 있어야 합니다.

- fields.E150: `GenericIPAddressField`s는 ``null=False``인 경우 ``blank=True``를 가질 수 없습니다. 빈 값은 null로 저장되기 때문입니다.

- fields.E160: `auto_now`, `auto_now_add` 및 `default` 옵션은 상호 배타적입니다. 이러한 옵션 중 하나만 존재할 수 있습니다.

- fields.W161: 고정된 기본값이 제공됩니다.

- fields.W162: `<database>``은 ``<field data type>` 열에 대한 데이터베이스 인덱스를 지원하지 않습니다.

- fields.W163: `<database>` 은 열에 대한 설명을 지원하지 않습니다. (`db_comment`).

- fields.E170: ``BinaryField``의 ``default``는 문자열일 수 없습니다. 대신 바이트 콘텐츠를 사용하세요.

- fields.E180: `<database>``은 ``JSONField`s를 지원하지 않습니다.

- fields.E190: `<database>``은 ``<field_type>`s에서 데이터베이스 데이터 정렬을 지원하지 않습니다.

- fields.E220: `<database>``는 ``GeneratedField`s를 지원하지 않습니다.

- fields.E221: `<database>``는 영구 저장되지 않는 ``GeneratedField`s를 지원하지 않습니다.

- fields.E222: `<database>``는 영구 저장되는 ``GeneratedField`s를 지원하지 않습니다.

- fields.E223: ``GeneratedField.output_field``에 오류가 있습니다: …

- fields.W224: ``GeneratedField.output_field``에 경고가 있습니다: …

- fields.W225: `null` has no effect on `GeneratedField`.

- fields.E900: 이전 마이그레이션 지원을 제외하고 ``IPAddressField``가 제거되었습니다.

- fields.W900: ``IPAddressField``는 더 이상 사용되지 않습니다. 이에 대한 지원(이전 마이그레이션 제외)은 Django 1.9에서 제거됩니다. 이 검사는 Django 1.7 및 1.8에서 나타납니다.

- fields.W901: ``CommaSeparatedIntegerField``는 더 이상 사용되지 않습니다. 이에 대한 지원(이전 마이그레이션 제외)은 Django 2.0에서 제거됩니다. 이 검사는 Django 1.10 및 1.11에서 나타납니다.

- fields.E901: ``CommaSeparatedIntegerField``는 이전 마이그레이션 지원을 제외하고 제거되었습니다.

- fields.W902: ``FloatRangeField``는 더 이상 사용되지 않으며 Django 3.1에서 제거됩니다. 이 검사는 Django 2.2 및 3.0에서 나타납니다.

- fields.W903: ``NullBooleanField``는 더 이상 사용되지 않습니다. 이에 대한 지원(이전 마이그레이션 제외)은 Django 4.0에서 제거됩니다. 이 검사는 Django 3.1 및 3.2에서 나타납니다.

- fields.E903: 이전 마이그레이션 지원을 제외하고 ``NullBooleanField``가 제거되었습니다.

- fields.W904: ``django.contrib.postgres.fields.JSONField``는 더 이상 사용되지 않습니다. 이에 대한 지원(이전 마이그레이션 제외)은 Django 4.0에서 제거됩니다. 이 검사는 Django 3.1 및 3.2에서 나타납니다.

- fields.E904: ``django.contrib.postgres.fields.JSONField``는 이전 마이그레이션 지원을 제외하고 제거되었습니다.

- fields.W905: ``django.contrib.postgres.fields.CICharField``는 더 이상 사용되지 않습니다. 이에 대한 지원(이전 마이그레이션 제외)은 Django 5.1에서 제거됩니다. 이 검사는 Django 4.2 및 5.0에서 나타납니다.

- fields.E905: 이전 마이그레이션 지원을 제외하고 ``django.contrib.postgres.fields.CICharField``가 제거되었습니다.

- fields.W906: ``django.contrib.postgres.fields.CIEmailField``는 더 이상 사용되지 않습니다. 이에 대한 지원(이전 마이그레이션 제외)은 Django 5.1에서 제거됩니다. 이 검사는 Django 4.2 및 5.0에서 나타납니다.

- fields.E906: 이전 마이그레이션 지원을 제외하고 ``django.contrib.postgres.fields.CIEmailField``가 제거되었습니다.

- fields.W907: ``django.contrib.postgres.fields.CITextField``는 더 이상 사용되지 않습니다. 이에 대한 지원(이전 마이그레이션 제외)은 Django 5.1에서 제거됩니다. 이 검사는 Django 4.2 및 5.0에서 나타납니다.

- fields.E907: 이전 마이그레이션 지원을 제외하고 ``django.contrib.postgres.fields.CITextField``가 제거되었습니다.

#### 파일 필드

- fields.E200: ``unique``는 ``FileField``에 대한 유효한 인수가 아닙니다. 이 검사는 Django 1.11*에서 제거되었습니다.

- fields.E201: ``primary_key``는 ``FileField``에 대한 유효한 인수가 아닙니다.

- fields.E202: `FileField``의 ``upload_to` 인자는 절대 경로가 아닌 상대 경로여야 합니다.

- fields.E210: Pillow가 설치되지 않았기 때문에 ``ImageField``를 사용할 수 없습니다.

#### 관련된 필드

- fields.E300: 필드는 설치되지 않았거나 추상적인 모델 ``<model>``과의 관계를 정의합니다.

- fields.E301: 필드는 교체된 모델 ``<app_label>.<model>``와의 관계를 정의합니다.

- fields.E302: ``<app_label>.<model>.<field name>``에 대한 역 접근자 ``<related model>.<accessor name>``가 필드 이름 ``<app_label>.<model>.<field name>``과 충돌합니다.

- fields.E303: ``<app_label>.<model>.<field name>``에 대한 역방향 쿼리 이름이 필드 이름 ``<app_label>.<model>.<field name>``과 충돌합니다.

- fields.E304: ``<app_label>.<model>.<field name>``에 대한 역방향 접근자 ``<related model>.<accessor name>``가 ``<app_label>.<model>.<field name>``에 대한 역방향 접근자와 충돌합니다.

- fields.E305: ``<app_label>.<model>.<field name>``에 대한 역방향 쿼리 이름이 ``<app_label>.<model>.<field name>``에 대한 역방향 쿼리 이름과 충돌합니다.

- fields.E306: 필드 `<model>.<field name>``에 대한 ``<name>` 이름이 유효하지 않은 ``related_name``입니다.

- fields.E307: 필드 ``<app label>.<model>.<field name>``이 ``<app label>.<model>``에 대한 지연 참조로 선언되었지만 앱 ``<app label>``이 설치되지 않았거나 모델 ``<model>``을 제공하지 않습니다. ``.

- fields.E308: 역방향 쿼리 이름 ``<related query name>``은 밑줄로 끝나지 않아야 합니다.

- fields.E309: 역방향 쿼리 이름 ``<related query name>``에는 ``’__’``이 포함되지 않아야 합니다.

- fields.E310: 모델 `<model>``에 있는 ``<field1>`, `<field2>`, … 필드의 하위 집합이 고유하지 않습니다.

- fields.E311: ``<model>.<field name>``는 ``ForeignKey``에 의해 참조되기 때문에 고유해야 합니다.

- fields.E312: `to_field` ``<field name>``이 관련 모델 ``<app label>.<model>``에 존재하지 않습니다.

- fields.E320: Field specifies `on_delete=<set null option>`, but cannot be null.

- fields.E321: Field specifies `on_delete=SET_DEFAULT`, but has no `default` value.

- fields.E322: Field specifies `on_delete=DB_SET_DEFAULT`, but has no `db_default` value.

- fields.E323: Field specifies database/Python-level on_delete variant, but referenced model uses python/database-level variant.

- fields.E324: `<database>` does not support `<database delete option>`.

- fields.E330: `ManyToManyField`s는 고유할 수 없습니다.

- fields.E331: 필드는 설치되지 않은 모델 ``<model>``을 통해 다대다 관계를 지정합니다.

- fields.E332: 중간 테이블이 있는 다대다 필드는 대칭이 아니어야 합니다. 이 검사는 Django 3.0 이전에 나타났습니다.

- fields.E333: 이 모델은 `<model>``에 의해 중간 모델로 사용되지만 ``<model>``에 대한 외래 키가 2개 이상이므로 모호합니다. Django가 ``through_fields` 키워드 인수를 통해 사용해야 하는 두 개의 외래 키를 지정해야 합니다.

- fields.E334: 이 모델은 `<model>``에 의해 중간 모델로 사용되지만 ``<model>``의 외래 키가 두 개 이상 있어 모호합니다. ``through_fields` 키워드 인수를 통해 Django가 사용해야 하는 외래 키를 지정해야 합니다.

- fields.E335: 이 모델은 `<model>``에 의해 중간 모델로 사용되지만 ``<model>``에 대한 외래 키가 두 개 이상 있어 모호합니다. ``through_fields` 키워드 인수를 통해 Django가 사용해야 하는 외래 키를 지정해야 합니다.

- fields.E336: 모델은 `<model>``에 의해 중간 모델로 사용되지만, ``<model>` 또는 ``<model>``에 대한 외래 키가 없습니다.

- fields.E337: 필드는 ``through_fields``를 지정하지만 ``<model>``을 통한 관계에 사용해야 하는 두 링크 필드의 이름을 제공하지 않습니다.

- fields.E338: 중간 모델 `<through model>``에는 ``<field name>` 필드가 없습니다.

- fields.E339: `<model>.<field name>` 는 ``<model>``에 대한 외래키가 아닙니다.

- fields.E340: 필드의 중간 테이블 `<table name>``이 ``<model>`/`<model>.<field name>` 테이블 이름과 충돌합니다.

- fields.W340: ``null``은 ``ManyToManyField``에 영향을 미치지 않습니다.

- fields.W341: `ManyToManyField` 는 ``validators``를 지원하지 않습니다.

- fields.W342: ``ForeignKey``에 ``unique=True``를 설정하는 것은 ``OneToOneField``를 사용하는 것과 같은 효과를 냅니다.

- fields.W343: `limit_choices_to``는 ``through` 모델을 사용하는 ``ManyToManyField``에 영향을 미치지 않습니다. 이 검사는 Django 4.0 이전에 나타났습니다.

- fields.W344: 필드의 중간 테이블 `<table name>``이 ``<model>`/`<model>.<field name>` 테이블 이름과 충돌합니다.

- fields.W345: ``related_name``은 대칭 관계를 가진 ``ManyToManyField``에 영향을 주지 않습니다. (예: “self”)

- fields.W346: `db_comment` 는 ``ManyToManyField``에 영향을 미치지 않습니다.

- fields.E347: 이 필드는 ``CompositePrimaryKey``를 가진 모델 ``<model>``과의 관계를 정의하고 있으며, 이러한 관계는 지원되지 않습니다.

- fields.E348: ``<model>.<field name>``의 관련 이름 ``<related_name>``이 모델 매니저 이름과 충돌합니다.

### 모델

- models.E001: `<swappable>``은 ``app_label.app_name` 형식이 아닙니다.

- models.E002: ``<SETTING>``은 설치되지 않았거나 추상적인 ``<model>``를 참조합니다.

- models.E003: 모델은 중간 모델 ``<app_label>.<model>``를 통해 두 개의 동일한 다대다 관계를 가집니다.

- models.E004: ``id``는 필드가 ``primary_key=True``도 설정한 경우에만 필드 이름으로 사용할 수 있습니다.

- models.E005: 상위 모델 `<model>``의 ``<field name>` 필드가 상위 모델 `<model>``의 ``<field name>` 필드와 충돌합니다.

- models.E006: 필드 ``<field name>``이 모델 ``<model>``의 필드 ``<field name>``와 충돌합니다.

- models.E007: 필드 ``<field name>``에는 다른 필드에서 사용하는 열 이름 ``<column name>``가 있습니다.

- models.E008: ``index_together``은 리스트 또는 튜플이어야 합니다. 이 검사는 Django 5.1 이전에 추가되었습니다.

- models.E009: 모든 `index_together` 요소는 리스트 또는 튜플이어야 합니다. 이 검사는 Django 5.1 이전에 추가되었습니다.

- models.E010: ``unique_together``는 반드시 리스트 이거나 투플이어야 합니다.

- models.E011: 모든 `unique_together` 요소는 목록 또는 튜플이어야 합니다.

- models.E012: ``constraints/indexes/unique_together``는 존재하지 않는 필드 ``<field name>``을 참조합니다.

- models.E013: `constraints/indexes/unique_together``는 ``ManyToManyField` `<field name>``을 참조하지만 해당 옵션에서는 ``ManyToManyField`s를 지원하지 않습니다.

- models.E014: ``ordering``은 (하나의 필드로만 주문하려는 경우에도) 튜플 또는 리스트이어야 합니다.

- models.E015: ``ordering``은 존재하지 않는 필드, 관련 필드 또는 조회 ``<field name>``을 나타냅니다.

- models.E016: ``constraints/indexes/unique_together``는 모델 ``<model>``에 속하지 않는 필드 ``<field_name>``를 참조합니다.

- models.E017: 프록시 모델 ``<model>``에는 모델 필드가 포함되어 있습니다.

- models.E018: 자동 생성된 열 이름이 필드 ``<field>``에 비해 너무 깁니다. 데이터베이스 ``<alias>``의 최대 길이는 ``<maximum length>``입니다.

- models.E019: M2M 필드 ``<M2M field>``에 대해 자동 생성된 열 이름이 너무 깁니다. 데이터베이스 ``<alias>``의 최대 길이는 ``<maximum length>``입니다.

- models.E020: `<model>.check()` 클래스 메서드가 현재 재정의되었습니다.

- models.E021: `ordering` 및 ``order_with_respect_to``는 함께 사용할 수 없습니다.

- models.E022: ``<function>``에는 ``<app label>.<model>``에 대한 지연 참조가 포함되어 있지만 앱 ``<app label>``는 설치되지 않았거나 모델 ``<model>``를 제공하지 않습니다.

- models.E023: 모델 이름 ``<model>``은 쿼리 조회 구문과 충돌하므로 밑줄로 시작하거나 끝날 수 없습니다.

- models.E024: 모델 이름 ``<model>``은 쿼리 조회 구문과 충돌하므로 이중 밑줄을 포함할 수 없습니다.

- models.E025: 속성 ``<property name>``이 관련 필드 접근자와 충돌합니다.

- models.E026: 모델은 ``primary_key=True``인 필드를 두 개 이상 가질 수 없습니다.

- models.W027: ``<database>``은 검사 제약 조건을 지원하지 않습니다.

- models.E028: `db_table` `<db_table>``은 여러 모델에서 사용됩니다: ``<model list>`.

- models.E029: 인덱스 이름 ``<index>``은 모델 ``<model>``에 고유하지 않습니다.

- models.E030: 인덱스 이름 `<index>``은 모델 간에 고유하지 않습니다: ``<model list>`.

- models.E031: 구속조건 이름 ``<constraint>``은 모델 ``<model>``에 대해 고유하지 않습니다.

- models.E032: 제약 조건 이름 `<constraint>``은 모델 간에 고유하지 않습니다: ``<model list>`.

- models.E033: 인덱스 이름 ``<index>``은 밑줄이나 숫자로 시작할 수 없습니다.

- models.E034: 인덱스 이름 `<index>``은 ``<max_length>` 문자보다 길 수 없습니다.

- models.W035: `db_table` `<db_table>``은 여러 모델에서 사용됩니다: ``<model list>`.

- models.W036: ``<database>``은 조건이 있는 고유 제약 조건을 지원하지 않습니다.

- models.W037: ``<database>``은 조건이 있는 인덱스를 지원하지 않습니다.

- models.W038: ``<database>``은 지연 가능한 고유 제약 조건을 지원하지 않습니다.

- models.W039: ``<database>``은 키가 아닌 열이 있는 고유 제약 조건을 지원하지 않습니다.

- models.W040: ``<database>``은 키가 아닌 열이 있는 인덱스를 지원하지 않습니다.

- models.E041: ``constraints``는 조인된 필드 ``<field name>``을 참조합니다.

- models.E042: ``<field name>``은 복합 기본 키에 포함될 수 없습니다.

- models.W042: 기본 키 유형을 정의하지 않은 경우 기본적으로 ``django.db.models.AutoField``가 사용되는 자동 생성 기본 키입니다. 이 검사는 Django 3.2–5.2에서 추가되었습니다.

- models.W043: ``<database>``은 식에 대한 인덱스를 지원하지 않습니다.

- models.W044: ``<database>``은 식에 대한 고유 제약 조건을 지원하지 않습니다.

- models.W045: 검사 제약 조건 `<constraint>``에는 ``RawSQL()` 표현식이 포함되어 있으며 모델 `full_clean()` 동안 유효성이 검사되지 않습니다.

- models.W046: `<database>` 는 테이블에 대한 설명을 지원하지 않습니다.(`db_table_comment`).

- models.W047: `<database>` does not support `UniqueConstraint.nulls_distinct`.

- models.E048: `constraints/indexes/unique_together` refers to a `CompositePrimaryKey` `<field name>`, but `CompositePrimaryKey`s are not supported for that option.

- models.E049: `constraints/indexes/unique_together` refers to a `ForeignObject` `<field name>` with multiple `from_fields`, which is not supported for that option.

- models.E050: The model cannot have related fields with both database-level and Python-level `on_delete` variants.

### Management Commands

The following checks verify custom management commands are correctly configured:

- commands.E001: The `migrate` and `makemigrations` commands must have the same `autodetector`.

### 보안

보안 검사는 사이트를 안전하게 만들지 않습니다. 코드를 감사하거나, 침입 탐지를 수행하거나, 특히 복잡한 작업을 수행하지 않습니다. 오히려, 사이트의 보안을 개선하는 데 도움이 될 수 있는 자동화된 간단한 체크리스트를 수행하는 데 도움이 됩니다.

이러한 검사 중 일부는 특정 배포 구성에 적합하지 않을 수 있습니다. 예를 들어 로드 밸런서에서 HTTP에서 HTTPS로의 리디렉션을 수행하는 경우 :setting:`SECURE_SSL_REDIRECT`를 활성화하지 않은 것에 대해 지속적으로 경고를 받으면 짜증이 날 것입니다. 불필요한 검사를 중지하려면 :setting:`SILENCED_SYSTEM_CHECKS`를 사용하세요.

`check --deploy` 옵션을 사용하는 경우, 다음 검사가 실행됩니다:

- security.W001: `MIDDLEWARE`에 :class:`django.middleware.security.SecurityMiddleware`가 없으므로 :setting:`SECURE_HSTS_SECONDS`, `SECURE_CONTENT_TYPE_NOSNIFF`, :setting :SECURE_REFERRER_POLICY, `SECURE_CROSS_ORIGIN_OPENER_POLICY` 및 `SECURE_SSL_REDIRECT` 설정은 적용되지 않습니다.

- security.W002: `MIDDLEWARE`에 :class:`django.middleware.clickjacking.XFrameOptionsMiddleware`가 없으므로 페이지가 ``’x-frame-options’``와 함께 제공되지 않습니다. 헤더. 사이트를 프레임으로 제공해야 하는 타당한 이유가 없는 한, 이 헤더를 활성화하여 클릭재킹 공격을 방지하는 것이 좋습니다.

- security.W003: 현재 미들웨어(`django.middleware.csrf.CsrfViewMiddleware` 가 `MIDDLEWARE` 안에 없습니다)를 통한 Django에 내재된 사이트 간 요청 위조 보호 기능을 사용하지 않는 것 같습니다. 미들웨어를 활성화하는 것이 허점을 남기지 않도록 하는 가장 안전한 방법입니다.

- security.W004: `SECURE_HSTS_SECONDS` 설정에 대한 값을 설정하지 않았습니다. 전체 사이트가 SSL을 통해서만 제공되는 경우 값을 설정하고 :ref:`HTTP Strict Transport Security <http-strict-transport-security>`을 활성화하는 것이 좋습니다. 설명서를 먼저 읽으십시오. 부주의하게 HSTS를 활성화하면 돌이킬 수 없는 심각한 문제가 발생할 수 있습니다.

- security.W005: `SECURE_HSTS_INCLUDE_SUBDOMAINS` 설정을 ``True``로 설정하지 않았습니다. 이것이 없으면, 귀하의 사이트는 하위 도메인에 대한 안전하지 않은 연결을 통한 공격에 잠재적으로 취약합니다. 도메인의 모든 하위 도메인이 SSL을 통해서만 제공되어야 한다고 확신하는 경우에만 ``True``로 설정하십시오.

- security.W006: `SECURE_CONTENT_TYPE_NOSNIFF` 설정이 ``True``로 설정되지 않았으므로 페이지가 ``’X-Content-Type-Options: nosniff’``와 함께 제공되지 않습니다. 헤더. 브라우저가 콘텐츠 유형을 잘못 식별하지 않도록 이 헤더를 활성화하는 것을 고려해야 합니다.

- security.W007: `SECURE_BROWSER_XSS_FILTER` 설정이 `True``로 설정되어 있지 않으므로 페이지에 ``'X-XSS-Protection: 1; mode=block'` 헤더. 브라우저의 XSS 필터링을 활성화하고 XSS 공격을 방지하려면 이 헤더를 활성화하는 것을 고려해야 합니다. 이 검사는 Django 3.0에서 * ``X-XSS-Protection`` *헤더가 최신 브라우저에서 더 이상 인정되지 않으므로 제거되었습니다.

- security.W008: `SECURE_SSL_REDIRECT` 설정이 ``True``로 설정되지 않았습니다. SSL 및 비 SSL 연결 모두에서 사이트를 사용할 수 있어야 하는 경우가 아니면 이 설정을 ``True``로 설정하거나 로드 밸런서 또는 리버스 프록시 서버를 구성하여 모든 연결을 HTTPS로 리디렉션할 수 있습니다.

- security.W009: `SECRET_KEY`의 문자가 50자 미만이거나, 고유 문자가 5자 미만이거나, Django에서 자동으로 생성되었음을 나타내는 ``’django-insecure-‘`` 접두사가 붙습니다. 긴 무작위 값을 생성하십시오. 그렇지 않으면 Django의 보안에 중요한 많은 기능이 공격에 취약합니다.

- security.W010: 설정:`INSTALLED_APPS`에 :mod:`django.contrib.sessions`가 있지만, :setting:`SESSION_COOKIE_SECURE`를 ``True``로 설정하지 않았습니다. :setting:`SESSION_COOKIE_SECURE`를 ``True``로 설정하면 네트워크 트래픽 스니퍼가 사용자 세션을 하이재킹하기가 더 어려워집니다.

- security.W011: :setting:`MIDDLEWARE`에 :class:`django.contrib.sessions.middleware.SessionMiddleware`가 있지만 :setting:`SESSION_COOKIE_SECURE`를 ``True``로 설정하지 않았습니다. 보안 전용 세션 쿠키를 사용하면 네트워크 트래픽 스니퍼가 사용자 세션을 하이재킹하기가 더 어려워집니다.

- security.W012: :setting:`SESSION_COOKIE_SECURE`가 ``True``로 설정되지 않았습니다. 보안 전용 세션 쿠키를 사용하면 네트워크 트래픽 스니퍼가 사용자 세션을 하이재킹하기가 더 어려워집니다.

- security.W013: :setting:NSTALLED_APPS`에 django.contrib.sessions가 있지만 설정:SESSION_COOKIE_HTTPONLY`를 ``True``로 설정하지 않았습니다. ``HttpOnly` 세션 쿠키를 사용하면 크로스 사이트 스크립팅 공격이 사용자 세션을 하이재킹하는 것이 더 어려워집니다.

- security.W014: `MIDDLEWARE`에 :class:`django.contrib.sessions.middleware.SessionMiddleware`가 있지만 :setting:`SESSION_COOKIE_HTTPONLY`를 ``True``로 설정하지 않았습니다. . ``HttpOnly`` 세션 쿠키를 사용하면 크로스 사이트 스크립팅 공격이 사용자 세션을 하이재킹하는 것이 더 어려워집니다.

- security.W015: `SESSION_COOKIE_HTTPONLY`가 ``True``로 설정되지 않았습니다. ``HttpOnly`` 세션 쿠키를 사용하면 크로스 사이트 스크립팅 공격이 사용자 세션을 하이재킹하는 것이 더 어려워집니다.

- security.W016: :setting:`CSRF_COOKIE_SECURE`가 ``True``로 설정되지 않았습니다. 보안 전용 CSRF 쿠키를 사용하면 네트워크 트래픽 스니퍼가 CSRF 토큰을 훔치기가 더 어려워집니다.

- security.W017: `CSRF_COOKIE_HTTPONLY`가 ``True``로 설정되지 않았습니다. ``HttpOnly`` CSRF 쿠키를 사용하면 교차 사이트 스크립팅 공격이 CSRF 토큰을 훔치기가 더 어려워집니다. 이 검사는 Django 1.11에서 `CSRF_COOKIE_HTTPONLY` 설정이 실질적인 이점을 제공하지 않기 때문에 제거되었습니다.

- security.W018: 배포 시 :setting:`DEBUG`를 ``True``로 설정하면 안 됩니다.

- security.W019: `MIDDLEWARE`에 :class:`django.middleware.clickjacking.XFrameOptionsMiddleware`가 있지만 :setting:`X_FRAME_OPTIONS`가 ``’DENY’``로 설정되지 않았습니다. 귀하의 사이트가 프레임의 다른 부분을 제공해야 할 타당한 이유가 없다면 ``’DENY’’로 변경해야 합니다.

- security.W020: :setting:`ALLOWED_HOSTS`는 배포 시 비어 있으면 안 됩니다.

- security.W021: `SECURE_HSTS_PRELOAD` 설정을 ``True``로 설정하지 않았습니다. 이것이 없으면 사이트를 브라우저 사전 로드 목록에 제출할 수 없습니다.

- security.W022: `SECURE_REFERRER_POLICY` 설정을 지정하지 않았습니다. 이것이 없으면 귀하의 사이트는 Referrer-Policy 헤더를 보내지 않습니다. 사용자 개인 정보를 보호하려면 이 헤더를 활성화하는 것을 고려해야 합니다.

- security.E023: `SECURE_REFERRER_POLICY` 설정을 잘못된 값으로 설정했습니다.

- security.E024: `SECURE_CROSS_ORIGIN_OPENER_POLICY` 설정을 잘못된 값으로 설정했습니다.

- security.W025: `SECRET_KEY_FALLBACKS[n] <SECRET_KEY_FALLBACKS>`의 문자가 50자 미만이거나 고유 문자가 5자 미만이거나 Django에 의해 자동으로 생성되었음을 나타내는 ``’django-insecure-‘`` 접두사가 붙어 있습니다. 길고 임의의 값을 생성하십시오. 그렇지 않으면 Django의 보안에 중요한 많은 기능이 공격에 취약합니다.

다음 검사는 보안 관련 설정이 올바르게 구성되었는지 확인합니다:

- security.E100: `DEFAULT_HASHING_ALGORITHM``은 ``'sha1'` 또는 ``’sha256’``이어야 합니다. 이 검사는 Django 3.1 및 3.2에서 나타납니다.

- security.E101: CSRF 실패 뷰 ``’path.to.view’``가 올바른 수의 인수를 사용하지 않습니다.

- security.E102: CSRF 실패 뷰 ``’path.to.view’``를 가져올 수 없습니다.

- security.E026: The CSP setting `<SETTING_NAME>` must be a dictionary (got `<value>` instead).

- security.W027: Your Content Security Policy includes `CSP.NONCE` and `ContentSecurityPolicyMiddleware` is enabled, but `django.template.context_processors.csp` is not configured.

### 시그널

- signals.E001: `<handler>``이 발신자 ``<app label>.<model>``에 대한 지연 참조로 ``<signal>` 시그널에 연결되었지만, 앱 ``<app label>``가 설치되지 않았거나, 모델 `<model>`을 제공하지 않습니다.

### 템플릿

다음 검사는 `TEMPLATES` 설정이 올바르게 구성되었는지 확인합니다:

- templates.E001: You have `'APP_DIRS': True` in your `TEMPLATES` but also specify `'loaders'` in `OPTIONS`. Either remove `APP_DIRS` or remove the `'loaders'` option. This check is removed in Django 5.1 as system checks may now raise `ImproperlyConfigured` instead.

- templates.E002: `string_if_invalid` in `TEMPLATES` `OPTIONS <TEMPLATES-OPTIONS>`은 문자열이어야 하지만 다음과 같았습니다: ``{value}`` (`{type}`) .

- templates.E003:`<name>``은 여러 템플릿 태그 모듈에 사용됩니다: ``<module list>`. *이 검사는 Django 4.1.2*에서 *``templates.W003``으로 변경되었습니다.

- templates.W003:`<name>``은 여러 템플릿 태그 모듈에 사용됩니다: ``<module list>`.

### 번역

변환 구성에서 다음 검사가 수행됩니다:

- translation.E001: `LANGUAGE_CODE` 설정에 잘못된 값을 제공했습니다: `<value>`.

- translation.E002: `LANGUAGES` 설정: ``<value>``에 잘못된 언어 코드를 제공했습니다.

- translation.E003: `LANGUAGES_BIDI` 설정: ``<value>``에 잘못된 언어 코드를 제공했습니다.

- translation.E004: `LANGUAGES` 설정에 없는 값을 `LANGUAGE_CODE` 설정에 제공했습니다.

### URL들

URL 구성에서 다음 검사가 수행됩니다:

- urls.W001: URL 패턴 ``<pattern>``은 ``$``로 끝나는 ``route``와 함께 :func:`~django.urls.include`를 사용합니다. URL을 포함한 문제를 피하기 위해 ``route``에서 달러 기호를 제거하십시오.

- urls.W002: URL 패턴 ``<pattern>``에 ``/``로 시작하는 ``route``가 있습니다. 이 슬래시는 불필요하므로 제거하십시오. 이 패턴이 `include()` 패턴 뒤에 ``/``가 있는지 확인하십시오.

- urls.W003: URL 패턴 ``<pattern>``에 ``:``을 포함하는 ``이름``이 있습니다. 모호한 네임스페이스 참조를 방지하려면 콜론을 제거하십시오.

- urls.E004: URL 패턴 ``<pattern>``이 잘못되었습니다. ``urlpatterns``가 `path()` 및/또는 `re_path()` 인스턴스의 목록인지 확인하십시오.

- urls.W005: URL 네임스페이스 ``<namespace>``이 고유하지 않습니다. 이 네임스페이스의 모든 URL을 되돌릴 수 없을 수도 있습니다.

- urls.E006: `MEDIA_URL`/ `STATIC_URL` 설정은 슬래시로 끝나야 합니다.

- urls.E007: 사용자 지정 `handlerXXX` 보기 ``’path.to.view’``가 올바른 수의 인수를 사용하지 않습니다(…).

- urls.E008: 사용자 지정 `handlerXXX` 보기 ``’path.to.view’``를 가져올 수 없습니다.

- urls.E009: URL 패턴 `<pattern>``에 유효하지 않은 보기가 있습니다. ``<view>` 대신 ``<view>.as_view()``를 전달하십시오.

- urls.W010: Your URL pattern `<pattern>` has an unmatched `<angle bracket>`.

## “contrib” 앱 체크들

### `관리자`

관리 검사는 모두 `admin` 태그의 일부로 수행됩니다.

관리 사이트에 등록된 :class:`~django.contrib.admin.ModelAdmin`(또는 하위 클래스)에서 다음 검사가 수행됩니다:

- admin.E001: `raw_id_fields` 값은 리스트 또는 튜플이어야 합니다.

- admin.E002: `raw_id_fields[n]` 값은 `<model>` 필드가 아닌 ``<field name>``을 나타냅니다.

- admin.E003: `raw_id_fields[n]` 값은 외래 키 또는 다대다 필드여야 합니다.

- admin.E004: `fields` 값은 리스트 또는 튜플이어야 합니다.

- admin.E005: ``fieldsets``와 ``fields``가 모두 지정되었습니다.

- admin.E006: `fields` 값에 중복 필드가 포함되어 있습니다.

- admin.E007: `fieldsets` 값은 리스트 또는 튜플이어야 합니다.

- admin.E008: `fieldsets[n]` 값은 리스트 또는 튜플이어야 합니다.

- admin.E009: ``fieldsets[n]``의 값은 길이가 2여야 합니다.

- admin.E010: `fieldsets[n][1]` 값은 사전이어야 합니다.

- admin.E011: `fieldsets[n][1]` 값은 `fields` 키를 포함해야 합니다.

- admin.E012: ``fieldsets[n][1]``에 중복된 필드가 있습니다.

- admin.E013: The value of `fields[n]/filter_horizontal[n]/filter_vertical[n]/fieldsets[n][m]` cannot include the `ManyToManyField` `<field name>`, because that field manually specifies a relationship model.

- admin.E014: `exclude` 값은 리스트 또는 튜플이어야 합니다.

- admin.E015: `exclude` 값에 중복 필드가 포함되어 있습니다.

- admin.E016: `form` 값은 ``BaseModelForm``에서 상속되어야 합니다.

- admin.E017: `filter_vertical` 값은 리스트 또는 튜플이어야 합니다.

- admin.E018: `filter_horizontal` 값은 리스트 또는 튜플이어야 합니다.

- admin.E019: `filter_vertical[n]/filter_horizontal[n]` 값은 `<model>` 필드가 아닌 ``<field name>``을 참조합니다.

- admin.E020: `filter_vertical[n]/filter_horizontal[n]` 값은 다대다 필드여야 합니다.

- admin.E021: `radio_fields` 값은 사전이어야 합니다.

- admin.E022: `radio_fields` 값은 ``<model>``의 필드가 아닌 ``<field name>``을 참조합니다.

- admin.E023: `radio_fields` 값은 `ForeignKey` 인스턴스가 아닌 `<field name>``을 참조하며 ``choices` 정의가 없습니다.

- admin.E024: `radio_fields[<field name>]` 값은 `admin.HORIZONTAL` 또는 ``admin.VERTICAL``이어야 합니다.

- admin.E025: `view_on_site` 값은 호출 가능하거나 부울 값이어야 합니다.

- admin.E026: `prepopulated_fields` 값은 사전이어야 합니다.

- admin.E027: `prepopulated_fields` 값은 `<model>` 필드가 아닌 ``<field name>``을 참조합니다.

- admin.E028: `prepopulated_fields` 값은 `<field name>``을 참조하며, ``DateTimeField`, `ForeignKey`, `OneToOneField` 또는 `ManyToManyField` 필드가 아니어야 합니다.

- admin.E029: `prepopulated_fields[<field name>]` 값은 목록 또는 튜플이어야 합니다.

- admin.E030: `prepopulated_fields` 값은 ``<model>``의 필드가 아닌 ``<field name>``을 참조합니다.

- admin.E031: `ordering` 값은 리스트 또는 튜플이어야 합니다.

- admin.E032: `ordering` 값에는 무작위 순서 마커 ``?``가 있지만, 다른 필드도 포함합니다.

- admin.E033: `ordering` 값은 `<model>` 필드가 아닌 ``<field name>``을 나타냅니다.

- admin.E034: `readonly_fields` 값은 목록 또는 튜플이어야 합니다.

- admin.E035: The value of `readonly_fields[n]` refers to `<field_name>`, which is not a callable, an attribute of `<ModelAdmin class>`, or an attribute of `<model>`.

- admin.E036: `autocomplete_fields` 값은 리스트 또는 튜플이어야 합니다.

- admin.E037: `autocomplete_fields[n]` 값은 `<model>` 필드가 아닌 ``<field name>``을 참조합니다.

- admin.E038: `autocomplete_fields[n]` 값은 외래 키 또는 다대다 필드여야 합니다.

- admin.E039: 모델 ``<model>``에 대한 관리자는 ``<modeladmin>.autocomplete_fields``에 의해 참조되도록 등록되어야 합니다.

- admin.E040: ``<modeladmin>``은 ``<other_modeladmin>.autocomplete_fields``에 의해 참조되기 때문에, ``search_fields``를 정의해야 합니다.

- admin.E041: The value of `delete_confirmation_max_display` must be a non-negative integer or `None`.

#### `모델 관리자`

관리 사이트에 등록된 :class:`~django.contrib.admin.ModelAdmin`에서 다음 검사가 수행됩니다:

- admin.E101: `save_as` 값은 부울이어야 합니다.

- admin.E102: `save_on_top` 값은 부울이어야 합니다.

- admin.E103: `inlines` 값은 리스트 또는 튜플이어야 합니다.

- admin.E104: ``<InlineModelAdmin class>``은 ``InlineModelAdmin``에서 상속해야 합니다.

- admin.E105: `<InlineModelAdmin class>``에는 ``model` 속성이 있어야 합니다.

- admin.E106: `<InlineModelAdmin class>.model` 값은 ``Model``이어야 합니다.

- admin.E107: `list_display` 값은 리스트 또는 튜플이어야 합니다.

- admin.E108: The value of `list_display[n]` refers to `<label>`, which is not a callable or attribute of `<ModelAdmin class>`, or an attribute, method, or field on `<model>`.

- admin.E109: The value of `list_display[n]` must not be a many-to-many field or a reverse foreign key.

- admin.E110: `list_display_links` 값은 리스트, 튜플 또는 ``None``이어야 합니다.

- admin.E111: `list_display_links[n]` 값은 ``list_display``에 정의되지 않은 ``<label>``을 참조합니다.

- admin.E112: `list_filter` 값은 리스트 또는 튜플이어야 합니다.

- admin.E113: ``list_filter[n]``의 값은 ``ListFilter``에서 상속되어야 합니다.

- admin.E114: ``list_filter[n]``의 값은 ``FieldListFilter``에서 상속되어야 합니다.

- admin.E115: ``list_filter[n][1]``의 값은 ``FieldListFilter``에서 상속되어야 합니다.

- admin.E116: `list_filter[n]` 의 값은 필드를 참조하지 않는 ``<label>``을 참조합니다.

- admin.E117: `list_select_related``의 값은 부울, 튜플 또는 리스트여야 합니다.

- admin.E118: ``list_per_page``의 값은 정수여야 합니다.

- admin.E119: ``list_max_show_all``의 값은 정수여야 합니다.

- admin.E120: ``list_editable``의 값은 리스트 또는 튜플이어야 합니다.

- admin.E121: ``list_editable[n]``의 값은 ``<model>``의 필드가 아닌 ``<label>``을 나타냅니다.

- admin.E122: ``list_editable[n]``의 값은 ``list_display``에 포함되지 않은 ``<label>``을 참조합니다.

- admin.E123: `list_editable[n]``의 값은 ``list_editable``과 ``list_display_links` 모두에 있을 수 없습니다.

- admin.E124: `list_editable[n]``의 값은 ``list_display` (`<label>`)의 첫 번째 필드를 참조하며, ``list_display_links``를 설정하지 않으면 사용할 수 없습니다.

- admin.E125: ``list_editable[n]``의 값은 관리자를 통해 편집할 수 없는 ``<field name>``을 참조합니다.

- admin.E126: ``search_fields``의 값은 리스트 또는 튜플이어야 합니다.

- admin.E127: ``date_hierarchy``의 값은 필드를 참조하지 않는 ``<field name>``를 참조합니다.

- admin.E128: `date_hierarchy``의 값은 ``DateField` 혹은 ``DateTimeField``여야한다.

- admin.E129: ``<modeladmin>``는 ``<action>``동작에 대한 ``has_<foo>_permission()``메서드를 정의해야합니다.

- admin.E130: ``<modeladmin>``에 정의된 동작의 ``__name__``특성은 고유해야 합니다. 이름 ``<name>``는 고유하지 않습니다.

#### `InlineModelAdmin`

다음 검사는 :class:`~django.contrib.admin.ModelAdmin`에 인라인으로 등록된 모든 :class:`~django.contrib.admin.InlineModelAdmin`에 대해 수행됩니다.

- admin.E201: 필드 ``<field name>``은 상위 모델``<app_label>.<model>``의 외부 키이기 때문에 제외할 수 없습니다.

- admin.E202: `<model>` has no `ForeignKey` to `<parent model>`./ `<model>` has more than one `ForeignKey` to `<parent model>`. You must specify a `fk_name` attribute.

- admin.E203: ``extra``의 값은 정수여야 합니다.

- admin.E204: ``max_num``의 값은 정수여야합니다.

- admin.E205: ``min_num``의 값은 정수여야합니다.

- admin.E206: ``formset``의 값은 ``BaseModelFormSet``에서 상속되어야 합니다.

#### `GenericInlineModelAdmin`

다음 검사는 :class:`~django.contrib.admin.ModelAdmin`에 인라인으로 등록된 모든 :class:`~django.contrib.contenttypes.admin.GenericInlineModelAdmin`에 대해 수행됩니다.

- admin.E301: `<model>` has no `GenericForeignKey`.

- admin.E302: `'ct_field'` references `<label>`, which is not a field on `<model>`.

- admin.E303: `'ct_fk_field'` references `<label>`, which is not a field on `<model>`.

- admin.E304: ``<model>``에는 내용 유형 필드 ``<field name>``와 객체 ID 필드 ``<field name>``을 사용하는 ``GenericForeignKey``가 없습니다.

#### `AdminSite`

디폴트 `AdminSite`:에 대해 다음 검사가 수행됩니다.

- admin.E401: 관리 응용 프로그램을 사용하려면 :mod:`django.contrib.contenttypes`가 :setting:`INSTALLED_APPS`에 있어야 합니다.

- admin.E402: `django.contrib.auth.context_processors.auth` must be enabled in `DjangoTemplates` (`TEMPLATES`) if using the default auth backend in order to use the admin application.

- admin.E403: A `django.template.backends.django.DjangoTemplates` instance must be configured in `TEMPLATES` in order to use the admin application.

- admin.E404: `django.contrib.messages.context_processors.messages` must be enabled in `DjangoTemplates` (`TEMPLATES`) in order to use the admin application.

- admin.E405: `django.contrib.auth` must be in `INSTALLED_APPS` in order to use the admin application.

- admin.E406: `django.contrib.messages` must be in `INSTALLED_APPS` in order to use the admin application.

- admin.E408: `django.contrib.auth.middleware.AuthenticationMiddleware` must be in `MIDDLEWARE` in order to use the admin application.

- admin.E409: `django.contrib.messages.middleware.MessageMiddleware` must be in `MIDDLEWARE` in order to use the admin application.

- admin.E410: `django.contrib.sessions.middleware.SessionMiddleware` must be in `MIDDLEWARE` in order to use the admin application.

- admin.W411: `django.template.context_processors.request` must be enabled in `DjangoTemplates` (`TEMPLATES`) in order to use the admin navigation sidebar.

### `auth`

- auth.E001: ``REQUIRED_FIELDS``는 리스트 혹은 튜플이어야 합니다.

- auth.E002: 사용자 지정 모델에 대해 ``USERNAME_FIELD``로 명명된 필드는 ``REQUIRED_FIELDS``에 포함되어서는 안 됩니다.

- auth.E003: ``<field>``은 ``USERNAME_FIELD``로 명명되므로 고유해야 합니다.

- auth.W004: ``<field>``은 ``USERNAME_FIELD``로 명명되지만 고유한 이름은 아닙니다.

- auth.E005: The permission codenamed `<codename>` clashes with a builtin permission for model `<model>`.

- auth.E006: The permission codenamed `<codename>` is duplicated for model `<model>`.

- auth.E007: The `verbose_name` of model `<model>` must be at most 244 characters for its builtin permission names to be at most 255 characters.

- auth.E008: The permission named `<name>` of model `<model>` is longer than 255 characters.

- auth.C009: `<User model>.is_anonymous` must be an attribute or property rather than a method. Ignoring this is a security issue as anonymous users will be treated as authenticated!

- auth.C010: `<User model>.is_authenticated` must be an attribute or property rather than a method. Ignoring this is a security issue as anonymous users will be treated as authenticated!

- auth.E011: The name of model `<model>` must be at most 93 characters for its builtin permission names to be at most 100 characters.

- auth.E012: The permission codenamed `<codename>` of model `<model>` is longer than 100 characters.

- auth.E013: In order to use `django.contrib.auth.middleware.LoginRequiredMiddleware`, `django.contrib.auth.middleware.AuthenticationMiddleware` must be defined before it in MIDDLEWARE.

### `contenttypes`

모델에 `GenericForeignKey` 또는 `GenericRelation`:가 포함된 경우 다음 검사가 수행됩니다.

- contenttypes.E001: `GenericForeignKey` 객체 ID는 존재하지 않는 필드``<field>``을 참조합니다.

- contenttypes.E002: `GenericForeignKey` 내용 유형은 존재하지 않는 필드 ``<field>``을 참조합니다.

- contenttypes.E003: ``<field>``은 ``ForeignKey``가 아니다.

- contenttypes.E004: ``<field>``은 ``contenttypes.ContentType``에 대한``ForeignKey``가 아닙니다.

- contenttypes.E005: 모델 이름은 최대 100자여야 합니다.

- contenttypes.E006: `<field>` cannot use the database-level `on_delete` variant.

### `postgres`

The following checks are performed on `django.contrib.postgres` model fields, indexes, and constraints:

- postgres.E001: Base field for array has errors: …

- postgres.E002: 배열의 기본 필드는 관련 필드일 수 없습니다.

- postgres.E003: `<field>` default should be a callable instead of an instance so that it’s not shared between all field instances. This check was changed to `fields.E010` in Django 3.1.

- postgres.W004: Base field for array has warnings: …

- postgres.E005: `'django.contrib.postgres'` must be in `INSTALLED_APPS` in order to use `<django.contrib.postgres feature>`.

### `sites`

다음 점검은 `CurrentSiteManager`:를 사용하여 모든 모델에서 수행됩니다.

- sites.E001: ``CurrentSiteManager``에서 ``<field name>``이라는 이름의 필드를 찾을 수 없습니다.

- sites.E002: ``CurrentSiteManager``는 외부 키 또는 다대다 필드가 아니므로 ``<field>``을 사용할 수 없습니다.

다음 검사를 통해 :mod:`django.contrib.sites`가 확인됩니다.

- sites.E101: The `SITE_ID` setting must be of type `<type>`. or The `SITE_ID` setting failed to validate: `<error>`.

### `staticfiles`

다음 검사를 통해 :mod:`django.contrib.staticfiles`가 올바르게 구성되어 있는지 확인합니다:

- staticfiles.E001: :setting:`STATICFILES_DIRS`설정은 튜플 또는 목록이 아닙니다.

- staticfiles.E002: `STATICFILES_DIRS` 설정에는 :setting:`STATIC_ROOT`설정이 포함되지 않아야 합니다.

- staticfiles.E003: `STATICFILES_DIRS` 설정의 접두사 ``<prefix>``은 슬래시로 끝날 수 없습니다.

- staticfiles.W004: :setting:`STATICFILES_DIRS`의 디렉토리 ``<directory>``은 존재하지 않습니다.

- staticfiles.E005: The `STORAGES` setting must define a `staticfiles` storage.