---
title: "커스텀 저장 시스템 작성하기"
version: 2.2
locale: ko
source: https://docs.djangoproject.com/ko/2.2/howto/custom-file-storage/
canonical: https://djangodocs.dev/ko/2.2/howto/custom-file-storage/
---
# 커스텀 저장 시스템 작성하기

만일 사용자 정의 파일 스토리지를 제공하고자 하는 경우 – 흔한 예로 원격 시스템에 파일을 저장할 때 – 사용자 정의 스토리지 클래스를 정의하면 됩니다. 다음 단계들을 진행해주세요.

1. 당신의 커스텀 저장소 시스템은 `django.core.files.storage.Storage`의 하위 클래스여야만 합니다.

   ```
   from django.core.files.storage import Storage

   class MyStorage(Storage):
       ...
   ```
2. Django는 어떤 인자없이도 너의 저장 시스템을 인스턴스화 할 수 있습니다. 이는 “django.conf.settings”로 부터 설정을 받아 사용한다는 것을 의미합니다.

   ```
   from django.conf import settings
   from django.core.files.storage import Storage

   class MyStorage(Storage):
       def __init__(self, option=None):
           if not option:
               option = settings.CUSTOM_STORAGE_OPTIONS
           ...
   ```
3. 당신의 저장 클래스는 적절한 다른 메소드와 함께 :meth:’\_open()’과 :meth:’\_save()’ 메소드로 구현돼야합니다. 더 많은 메소드를 아래에서 볼 수 있습니다.

   추가적으로, 만약 당신의 클래스가 로컬 파일 저장을 하면 “path()” 메소드로 오버라이드 되어야만 합니다.
4. Your storage class must be [deconstructible](/ko/2.2/topics/migrations/#custom-deconstruct-method)
   so it can be serialized when it’s used on a field in a migration. As long
   as your field has arguments that are themselves
   [serializable](/ko/2.2/topics/migrations/#migration-serializing), you can use the
   `django.utils.deconstruct.deconstructible` class decorator for this
   (that’s what Django uses on FileSystemStorage).

디폴트로, 다음의 메소드는 ‘NotImplementedError’를 일으키고, 일반적으로 오버라이드 되어야 합니다.

- [`Storage.delete()`](/ko/2.2/ref/files/storage/#django.core.files.storage.Storage.delete)
- [`Storage.exists()`](/ko/2.2/ref/files/storage/#django.core.files.storage.Storage.exists)
- [`Storage.listdir()`](/ko/2.2/ref/files/storage/#django.core.files.storage.Storage.listdir)
- [`Storage.size()`](/ko/2.2/ref/files/storage/#django.core.files.storage.Storage.size)
- [`Storage.url()`](/ko/2.2/ref/files/storage/#django.core.files.storage.Storage.url)

하지만 앞의 모든 메소드들이 필수적인 것은 아니며, 자율적으로 생략될 수 있다는 것을 유의하십시오. 그럴 경우에 각 메소드를 미구현 상태로 내버려 두면서도 작동하는 저장소를 만들 수 있습니다.

한 예시로, 만약 특정 콘텐츠를 지니고 있는 리스트를 백엔드에 저장하는게 고비용이 될 경우 당신은 ‘Storage.listdir’을 구현하지 않아도 된다.

다른 예시로 파일을 쓰기만 하는 백엔드가 있는 경우 당신은 위의 메소드를 구현할 필요가 없을 수 있다.

궁극적으로, 어떠한 메소드가 구현될 것인가는 당신이 정할 수 있습니다. 몇 몇의 메소드를 미구현 상태로 내버려둔다면 완전하지 않은(혹은 망가진) 인터페이스를 낳을 것입니다.

당신은 또한 커스텀 저장 객체를 위해 특별히 제작된 훅을 사용하고 싶을 것입니다. 이것들은:

#### `_open(name, mode='rb')`

**필수**.

Called by `Storage.open()`, this is the actual mechanism the storage class
uses to open the file. This must return a `File` object, though in most cases,
you’ll want to return some subclass here that implements logic specific to the
backend storage system.

#### `_save(name, content)`

Called by `Storage.save()`. The `name` will already have gone through
`get_valid_name()` and `get_available_name()`, and the `content` will be a
`File` object itself.

Should return the actual name of name of the file saved (usually the `name`
passed in, but if the storage needs to change the file name return the new name
instead).

#### `get_valid_name(name)`

Returns a filename suitable for use with the underlying storage system. The
`name` argument passed to this method is either the original filename sent to
the server or, if `upload_to` is a callable, the filename returned by that
method after any path information is removed. Override this to customize how
non-standard characters are converted to safe filenames.

The code provided on `Storage` retains only alpha-numeric characters, periods
and underscores from the original filename, removing everything else.

#### `get_available_name(name, max_length=None)`

Returns a filename that is available in the storage mechanism, possibly taking
the provided filename into account. The `name` argument passed to this method
will have already cleaned to a filename valid for the storage system, according
to the `get_valid_name()` method described above.

The length of the filename will not exceed `max_length`, if provided. If a
free unique filename cannot be found, a [`SuspiciousFileOperation`](/ko/2.2/ref/exceptions/#django.core.exceptions.SuspiciousOperation) exception is raised.

If a file with `name` already exists, an underscore plus a random 7 character
alphanumeric string is appended to the filename before the extension.