커스텀 user model은 애플리케이션의 요구에 맞게 Django의 기본 User를 대체합니다—필드 추가, 로그인 식별자 변경(예: username 대신 email), 동작 커스터마이징. 결정적이고 자주 반복되는 조언: 아직 변경이 필요 없더라도 프로젝트의 맨 처음에 커스텀 user model을 설정하세요. 나중에 변경하는 것은 극도로 고통스럽기 때문입니다.
기본 User는 고정된 필드(username, email, first/last name)를 가지며
USERNAME을 로그인 필드로 사용. 실제 앱은 종종 필요로 함:
✓ 이메일 기반 로그인(username 없음)
✓ user 자체에 추가 필드(전화번호, 아바타, 역할, 환경설정)
✓ 커스텀 인증 동작
⚠️ migration이 존재한 후 user model을 변경하는 것은 매우 어려움 — User model은
인증, admin, 세션, 데이터베이스 전반의 외래 키에서 참조됨.
나중에 교체하려면 복잡하고 위험한 데이터 migration이 필요.
→ 프로젝트 시작 시(첫 migration 전) 항상 커스텀 user model을 정의,
비어 있더라도, 나중에 자유롭게 확장할 수 있도록. Django 문서는
모든 새 프로젝트에 이를 강력히 권장.
이것이 핵심 실용 교훈입니다: 첫날에 커스텀 user model을 설정하는 데는 거의 비용이 들지 않지만, 확립된 프로젝트에 하나를 나중에 끼워넣는 것은 주요하고 오류 잦은 작업입니다—따라서 보험으로 미리 합니다.
# models.py — 필드 추가, Django의 인증 동작 유지
from django.contrib.auth.models import AbstractUser
class User(AbstractUser):
phone = models.CharField(max_length=20, blank=True)
avatar = models.ImageField(upload_to="avatars/", blank=True)
is_premium = models.BooleanField(default=False)
# settings.py — Django에게 사용하라고 알림
AUTH_USER_MODEL = "myapp.User"
AbstractUser는 Django의 모든 기본 필드와 인증 기계를 유지합니다—단지 필드를 추가하면 됩니다. 가장 단순하고 흔한 접근입니다.
from django.contrib.auth.models import AbstractBaseUser, BaseUserManager, PermissionsMixin
class User(AbstractBaseUser, PermissionsMixin):
email = models.EmailField(unique=True)
USERNAME_FIELD = "email" # username 대신 EMAIL로 로그인
REQUIRED_FIELDS = []
objects = CustomUserManager() # create_user/create_superuser를 정의하는 매니저
AbstractBaseUser는 user model에 대한 완전한 제어를 제공합니다(예: 이메일 전용 로그인을 위해 username을 완전히 제거)—더 많은 작업이 필요하지만 최대의 유연성을 줍니다.
from django.conf import settings
from django.contrib.auth import get_user_model
# model에서 — settings.AUTH_USER_MODEL을 통해 참조
author = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE)
# 코드에서 — 활성 user model을 동적으로 가져옴
User = get_user_model() # 기본 User를 직접 import하지 않음
항상 settings.AUTH_USER_MODEL(model에서)과 get_user_model()(코드에서)을 통해 user model을 참조하고, 기본 User를 직접 import하지 마세요—그래야 코드가 커스텀 model과 동작합니다.
커스텀 user model을 사용하는 것은 모든 Django 개발자가 내면화해야 할, 결정적이고 자주 강조되는 실용 교훈을 가진 중요한 지식입니다: 모든 프로젝트의 맨 처음에 설정하세요.
이것이 그토록 중요한 이유는 난이도의 심각한 비대칭성 때문입니다—첫날에 커스텀 user model을 정의하는 것(빈 AbstractUser 서브클래스라도)은 거의 비용이 들지 않고 귀중한 유연성을 제공하는 반면, 프로젝트가 migration과 데이터를 가진 후에 커스텀 user model로 전환하는 것은 극도로 고통스럽고 위험합니다. User model이 Django 전반(인증, admin, 세션)과 전체 데이터베이스의 외래 키에서 깊이 참조되어, 변경하려면 복잡하고 오류 잦은 데이터 migration이 필요하기 때문입니다.
이것이 Django 자체 문서가 즉각적인 필요와 관계없이 모든 새 프로젝트에 커스텀 user model을 강력히 권장하는 이유입니다—미래의 migration 악몽에 대한 보험입니다.
이 결정적인 타이밍 조언을 넘어, 커스텀 user model을 어떻게 만드는지 이해하는 것—Django의 인증 동작을 유지하면서 단순히 필드를 추가하는 AbstractUser(흔하고 쉬운 경우), 이메일 기반 로그인 같은 완전한 제어를 위한 AbstractBaseUser(username 완전 제거)—은 실제 애플리케이션 요구사항(추가 user 필드, 대체 로그인 식별자, 커스텀 인증)을 충족하는 데 가치가 있습니다.
마찬가지로 중요한 것은 user model을 올바르게 참조하는 것을 아는 것입니다(직접 import가 아닌 settings.AUTH_USER_MODEL과 get_user_model()을 통해), 그래야 코드가 어떤 user model이 구성되든 동작합니다.
거의 모든 실제 애플리케이션이 Django 기본값을 넘어서는 사용자 특화 요구를 가지고(그렇지 않은 것도 유연성에서 이득을 보며), 이를 일찍 설정하지 않는 비용이 매우 높으므로, 커스텀 user model—특히 프로젝트 시작 시 하나를 확립하는 명령—을 이해하는 것은 흔하고 심각한 프로젝트 수준 실수를 방지하는 중요하고 실용적으로 결정적인 지식이며, 자주 인용되는 Django 모범 사례 지혜입니다.