Django signal이란 무엇인가요?

Question

Accepted Answer

**signal**은 Django의 옵저버 패턴 구현입니다. 특정 **이벤트**(model이 저장되거나 삭제되는 것 같은)가 발생할 때 특정 발신자가 수신자 집합에 알리게 해줍니다. 이는 **느슨하게 결합된** 코드를 가능하게 합니다: 앱의 한 부분이 직접적인 결합 없이 다른 부분의 이벤트에 반응합니다.

## 흔한 내장 signal

```text
pre_save / post_save      → model 인스턴스 저장 전 / 후
pre_delete / post_delete  → model 인스턴스 삭제 전 / 후
m2m_changed               → ManyToMany 관계 변경
request_started / finished→ 요청 수명주기
user_logged_in / out      → 인증 이벤트
```

## signal에 수신자 연결하기

```python
from django.db.models.signals import post_save
from django.dispatch import receiver

# User가 생성될 때마다 자동으로 Profile 생성
@receiver(post_save, sender=User)
def create_profile(sender, instance, created, **kwargs):
    if created:                          # 매 저장이 아닌 생성 시에만
        Profile.objects.create(user=instance)
```

`@receiver` 데코레이터는 특정 발신자에 대한 signal에 함수를 연결합니다. `User`가 저장되면 Django가 이 함수를 호출하며, 여기서는 관련 `Profile`을 자동 생성합니다. `created` 플래그는 생성과 업데이트를 구분합니다.

## 전형적인 사용 사례

```python
@receiver(post_save, sender=Order)
def send_order_confirmation(sender, instance, created, **kwargs):
    if created:
        send_email(instance.customer.email, "Order confirmed")
# Order 생성 코드는 이메일에 대해 알 필요가 없음 → 느슨한 결합
```

Order를 생성하는 코드는 Order에 집중하고, 이메일 로직은 별도로 존재하며 이벤트에 반응합니다. 관심사를 느슨하게 결합된 상태로 유지합니다.

## signal이 유용한 경우

```text
✓ 다른 app/모듈의 model 이벤트에 반응(디커플링)
✓ 관련 객체 자동 생성(User 생성 시 Profile)
✓ 저장/삭제 시 캐시 무효화, 검색 인덱스 업데이트, 감사 로깅
✓ 핵심 로직에 임베드하고 싶지 않은 횡단적 반응
```

## 중요한 주의점: signal은 명료성을 해칠 수 있음

```python
# ⚠️ signal은 암묵적인 "원격 작용" 동작을 만듭니다:
# Order 저장이 다른 어딘가에서 이메일을 유발 — 저장 호출에서 명확하지 않음.
# 이는 코드를 따라가고 디버깅하기 더 어렵게 만들 수 있음.
```

```text
signal보다 명시적 코드를 선호해야 할 때:
  ✗ 로직이 명백히 같은 흐름에 속한다면 → 직접 호출(더 읽기 쉬움)
  ✗ signal 남용 → 숨겨지고 추적하기 어려운 동작, 디버깅 곤란
  ✓ 흔한 대안: model의 save() 메서드를 재정의하거나, 작업에 밀접히 결합된
    로직에는 서비스 함수 사용
signal은 주로 진정한 디커플링(app 경계를 넘는 반응)에 사용하고,
모든 post-save 로직의 기본값으로 사용하지 마세요.
```

## 왜 중요한가

signal은 코드를 **디커플링**하는 유용한 Django 기능입니다. 애플리케이션의 다른 부분들이 직접적인 의존성 없이 이벤트(model 저장/삭제, 인증 이벤트)에 반응하게 해주며, 관련 객체 자동 생성, 캐시 무효화, 감사 로깅, app 경계를 넘는 이벤트 반응 같은 횡단 관심사에 가치가 있습니다.

이를 이해하는 것은 적절히 *사용하기* 위해서도, 기존 코드베이스에서 *인식하기* 위해서도 중요합니다(signal은 "왜 이런 일이 일어났지?"라는 혼란의 흔한 원인입니다).

그러나 signal을 특히 중요한 주제로 만드는 것은 **언제 사용할지에 대한 미묘한 판단**입니다: signal은 우아한 디커플링을 가능하게 하지만, 코드를 따라가고 디버깅하기 더 어렵게 만드는 **암묵적인 "원격 작용" 동작**도 만듭니다(객체를 저장하면 다른 곳에서 정의된 효과가 신비롭게 유발됨).

성숙한 Django 개발자는 이 트레이드오프를 이해합니다. *진정한* 디커플링(소스에 결합해서는 안 되는 이벤트에 모듈/app 경계를 넘어 반응)에는 signal을 사용하되, 로직이 명백히 같은 흐름에 속할 때는 **명시적 코드**(로직을 직접 호출, `save()` 재정의, 서비스 함수 사용)를 선호합니다. 명시적 코드가 더 읽기 쉽고 추적 가능하기 때문입니다.

signal이 동작하는 방식(수신자 연결, `created` 플래그, 흔한 signal), 정당한 사용 사례, 그리고 결정적으로 **언제 사용하지 말아야 하는지**(숨겨지고 디버깅하기 어려운 동작 회피)를 아는 것은 유지보수 가능한 Django 코드를 작성하는 개발자와 signal을 남용하여 얽히고 불투명한 애플리케이션을 만드는 개발자를 구분하는 실용적이고 숙련된 이해를 반영합니다.