[PYTHON] Django Signals 사용 시점과 3가지 회피 방법 및 성능 차이 분석

Django Signals

 

 

장고(Django) 프레임워크를 사용하여 복잡한 비즈니스 로직을 설계하다 보면, 특정 모델의 변화에 따라 부수적인 작업(Side Effects)을 처리해야 할 때가 많습니다. 이때 가장 먼저 떠오르는 도구가 바로 Signals(시그널)입니다. 하지만 시그널은 양날의 검과 같습니다. 잘못 사용하면 코드의 흐름을 추적하기 어렵게 만들고 유지보수 지옥을 선사하기 때문입니다. 오늘 이 글에서는 시그널의 근본적인 메커니즘을 파헤치고, 언제 시그널을 사용해야 하며, 언제 반드시 피해야 하는지에 대한 명확한 기준과 해결 방법을 제시합니다.

---

1. Django 시그널의 본질: 옵저버 패턴의 구현

시그널은 장고 내부의 디스패처(Dispatcher)를 통해 특정 이벤트가 발생했을 때 등록된 수신자(Receiver)들에게 알림을 보내는 방식입니다. 이는 디자인 패턴 중 옵저버 패턴(Observer Pattern)에 해당하며, 프레임워크 내의 서로 다른 앱들이 서로의 존재를 모른 채로 소통할 수 있게 돕는 '느슨한 결합(Loose Coupling)'을 지향합니다.

주요 시그널 종류

• post_save: 모델의 save() 메서드가 호출된 직후 발생
• pre_delete: 모델 인스턴스가 삭제되기 직전 발생
• m2m_changed: Many-to-Many 관계가 변경될 때 발생
• user_logged_in: 사용자가 로그인을 완료했을 때 발생

---

2. 시그널 사용 vs 메서드 오버라이딩 차이점 비교

모델의 저장 로직을 커스텀할 때 가장 많이 고민하는 부분이 save() 메서드 오버라이딩과 post_save 시그널의 선택입니다. 두 방식의 결정적인 차이를 표로 정리했습니다.

비교 항목	모델 save() 오버라이딩	Django Signals (post_save)
결합도	강한 결합 (해당 모델 내부에 로직 위치)	낮은 결합 (외부 앱에서도 정의 가능)
가독성	매우 높음 (코드 흐름이 명확함)	낮음 (어디서 호출되는지 찾기 어려움)
실행 보장	일부 대량 작업(bulk_create) 시 무시됨	bulk 작업 시 시그널도 발생하지 않음
추천 용도	자기 자신의 필드 값 변경 및 가공	타 앱과의 연동, 제3자 라이브러리 확장

---

3. 시그널을 사용해야 하는 최적의 시점 (Use Cases)

시그널은 다음과 같은 '독립적인 부수 효과'가 필요할 때 가장 빛을 발합니다.

(1) 서드파티 라이브러리 커스텀

우리가 직접 수정할 수 없는 장고 내장 라이브러리(예: django.contrib.auth의 User 모델)의 이벤트에 반응해야 할 때 시그널은 유일한 대안입니다.

(2) 여러 앱 간의 통신

주문 앱(Orders)에서 결제가 완료되었을 때 알림 앱(Notifications)에 로그를 남겨야 한다면, 주문 앱이 알림 앱의 모델을 직접 참조하는 것보다 시그널을 통해 이벤트를 던지는 것이 아키텍처적으로 깨끗합니다.

---

4. 시그널 사용을 피해야 하는 치명적인 이유와 해결 방법

실무에서 시그널은 가급적 지양하는 것이 좋습니다. 그 이유는 다음과 같습니다.

문제점 1: '보이지 않는' 마법 (Hidden Logic)

새로운 개발자가 투입되었을 때, user.save() 코드를 보고 프로필이 자동으로 생성되는 로직을 찾지 못해 혼란에 빠질 수 있습니다. 시그널은 명시적이지 않습니다.

문제점 2: 순환 참조(Circular Import) 발생

서로 다른 앱이 시그널을 주고받다 보면 파이썬의 고질적인 문제인 순환 참조 에러에 빠지기 쉽습니다.

해결 방법 (Alternatives)

1. 서비스 레이어(Service Layer) 도입: 비즈니스 로직을 모델이나 시그널에 두지 않고, 별도의 함수(예: create_user_with_profile())로 분리하여 명시적으로 호출합니다.
2. Celery를 통한 비동기 처리: 알림 전송과 같은 무거운 작업은 시그널 대신 메시지 큐를 사용하여 백그라운드에서 처리합니다.

---

5. [Sample Example] 올바른 시그널 등록 패턴

시그널을 사용하기로 결정했다면, 앱이 로드될 때 확실히 등록되도록 apps.py와 signals.py를 분리하는 것이 정석입니다.

# signals.py
from django.db.models.signals import post_save
from django.dispatch import receiver
from django.contrib.auth.models import User
from .models import Profile

@receiver(post_save, sender=User)
def create_user_profile(sender, instance, created, **kwargs):
    if created:
        Profile.objects.create(user=instance)

# apps.py
from django.apps import AppConfig

class UsersConfig(AppConfig):
    name = 'users'

    def ready(self):
        import users.signals  # ready 메서드에서 임포트하여 등록

---

6. 성능 주의사항: 시그널은 비동기가 아닙니다!

많은 개발자들이 착각하는 부분 중 하나가 시그널이 백그라운드에서 실행된다는 생각입니다. Django 시그널은 기본적으로 동기(Synchronous) 방식으로 작동합니다. 즉, 시그널 내부 로직이 5초 걸리면 사용자 응답도 5초 지연됩니다. 무거운 작업은 반드시 비동기 작업 큐로 넘겨야 합니다.

---

7. 내용의 출처 및 참고 문헌

• Django Software Foundation: "Signals - Official Documentation"
• Two Scoops of Django (Audrey Feldroy, Daniel Roy Greenfeld): "Best Practices for Signals"
• Simple is Better Than Complex: "How to Create Django Signals"
• High Performance Django (Lincoln Loop): "Architecture and Signals Management"