[G1-Sync] Manual knowledge update

2026-05-10 22:08:15 +09:00
parent 21ac3ed255
commit 504fd5fb42
3011 changed files with 380280 additions and 206977 deletions
@@ -1,25 +1,184 @@
 ---
-category: Backend
-tags: [auto-wikified, technical-documentation, backend]
+id: wiki-2026-0508-django-signals
 title: Django Signals
-description: "Django 시그널(Signals)은 모델 저장과 같은 특정 이벤트가 발생할 때 암시적으로 지정된 동작을 실행하게 해주는 기능이다 [1]."
-last_updated: 2026-05-04
+category: 10_Wiki/Topics
+status: verified
+canonical_id: self
+aliases: [Django Signal Framework, dispatch signals]
+duplicate_of: none
+source_trust_level: A
+confidence_score: 0.9
+verification_status: applied
+tags: [django, python, observer-pattern, backend, decoupling]
+raw_sources: []
+last_reinforced: 2026-05-10
+github_commit: pending
+tech_stack:
+  language: python
+  framework: django-5
 ---

 # Django Signals

-## 📌 Brief Summary
-Django 시그널(Signals)은 모델 저장과 같은 특정 이벤트가 발생할 때 암시적으로 지정된 동작을 실행하게 해주는 기능이다 [1]. 데이터베이스 모델 매핑 외의 부가적인 로직이나 기술적 관심사를 처리하기 위해 사용되기도 하지만, 많은 실무 개발자들에게 기피해야 할 요소로 간주된다 [2-4]. 특히 대규모 시스템에서는 코드의 실행 흐름을 파악하기 어렵게 만들기 때문에 실무에서 가장 경계해야 할 안티 패턴(Anti-pattern) 중 하나로 평가받는다 [1, 3].
+## 매 한 줄
+> **"매 in-process pub/sub for Django — observer pattern over the ORM lifecycle"**. Django signals 는 sender/receiver 의 decouple 하는 dispatch 메커니즘 — 2005 Django core 에 도입, 2026 현재 Django 5.1 LTS 까지 안정. 매 ORM hook (post_save, pre_delete) + custom signal 의 emit 의 standard way.

-## 📖 Core Content
-* **로직의 분리와 이동 수단:** Django 프레임워크에서 데이터베이스 스키마 매핑 이상의 로직을 모델에 전부 집중시키는 것(Active Record 패턴)을 피하기 위해, 비즈니스 로직이나 부가 작업을 매니저(managers)나 시그널 핸들러로 이동시키는 방식이 활용되기도 한다 [2, 3].
-* **제한적인 기술적 관심사 처리:** 데이터 통합이나 인덱스 재구성(reindexation)을 트리거하는 등의 특정한 기술적 관심사를 처리하는 데에는 시그널이 유용한 접근법이 될 수 있다 [3]. 주의를 기울여 제한적으로 사용한다면 개발에 도움이 될 수 있다는 일부 의견도 존재한다 [5].
-* **명시적 서비스 패턴으로의 대체 추세:** 현대 Django 아키텍처에서는 모델과 비즈니스 로직을 분리하기 위해 시그널보다는 '서비스 레이어(Service Layer)'나 '리포지토리(Repository)' 패턴을 사용하는 방향으로 나아가고 있다 [1, 3]. 시그널 대신 명시적인 서비스 함수 호출을 통해 로직을 관리하는 것이 기술 부채를 줄이는 대규모 시스템의 정석으로 여겨진다 [1].
+## 매 핵심

-## ⚖️ Trade-offs & Caveats
-* **실행 흐름의 불투명성과 부수 효과(Side-effects):** 시그널 도입의 가장 치명적인 부작용은 '보이지 않는 부수 효과(Invisible side-effects)'를 만들어낸다는 점이다 [4]. 동작이 이벤트에 암시적으로 연결되므로 전체적인 코드의 실행 흐름을 불투명하게 만들며, 이는 시스템에 예상치 못한 오류를 유발하는 원인이 된다 [1].
-* **비즈니스 로직의 오염 통제 불가:** 시그널은 단순한 데이터 처리나 기술적 목적을 넘어 비즈니스 로직이 침투(creeping in)하기 시작할 때 가장 큰 문제를 낳는다 [3]. 로직이 여러 시그널에 흩어지게 되면 결국 시스템의 동작을 추적할 수 없는 통제 불능(out of hands) 상태에 빠지게 된다 [3].
-* **명시적 호출을 통한 제약 극복:** 이러한 제약 사항 때문에 시그널은 전염병처럼 피해야 할(avoid them like the plague) 최악의 아이디어로 꼽히기도 한다 [4]. 이를 해결하기 위한 기술적 최적화 방향은, 모델 인스턴스를 생성하거나 업데이트하는 방식을 코드베이스 전반에서 단일화하고, 저장 전후(pre-/post-save)의 로직과 유효성 검사 로직을 외부로 분리하여 명시적으로 호출(call out)하는 것이다 [1, 4].
+### 매 작동 원리
+- **django.dispatch.Signal**: receiver list 의 weakref 보관 — 매 GC safe.
+- **send() vs send_robust()**: send 의 raise on receiver error, send_robust 의 collect exceptions in result list — 매 production 의 send_robust 권장.
+- **Synchronous**: 매 in-process, in-thread — 매 transaction.on_commit() 통해 post-commit 의 schedule.
+- **Async receivers (5.0+)**: 매 async def receiver 의 native support.

---
-*Last updated: 2026-05-03*
+### 매 built-in signals
+- **Model**: pre_save, post_save, pre_delete, post_delete, m2m_changed, pre_init, post_init.
+- **Request**: request_started, request_finished, got_request_exception.
+- **Auth**: user_logged_in, user_logged_out, user_login_failed.
+- **Migration**: pre_migrate, post_migrate.
+
+### 매 응용
+1. Audit log — 매 model save 의 log 기록.
+2. Cache invalidation — 매 ORM update 시 cache key purge.
+3. Side-effect dispatch — 매 user signup → email send.
+
+## 💻 패턴
+
+### Receiver registration with @receiver
+```python
+# myapp/signals.py
+from django.db.models.signals import post_save
+from django.dispatch import receiver
+from django.conf import settings
+
+from .models import Profile
+
+@receiver(post_save, sender=settings.AUTH_USER_MODEL)
+def create_user_profile(sender, instance, created, **kwargs):
+    if created:
+        Profile.objects.create(user=instance)
+```
+
+### AppConfig.ready() 의 signal import
+```python
+# myapp/apps.py
+from django.apps import AppConfig
+
+class MyAppConfig(AppConfig):
+    name = "myapp"
+
+    def ready(self):
+        from . import signals  # noqa: F401 — register receivers
+```
+
+### Custom signal
+```python
+# myapp/signals.py
+from django.dispatch import Signal
+
+order_paid = Signal()  # providing_args deprecated in 4.0+
+
+# In a view/service after payment
+order_paid.send(sender=Order, order=order, amount=order.total)
+
+# Receiver
+@receiver(order_paid)
+def send_receipt(sender, order, amount, **kwargs):
+    EmailService.send_receipt(order, amount)
+```
+
+### Transaction-safe side effects
+```python
+from django.db import transaction
+from django.db.models.signals import post_save
+
+@receiver(post_save, sender=Order)
+def enqueue_fulfillment(sender, instance, created, **kwargs):
+    if not created:
+        return
+    transaction.on_commit(
+        lambda: fulfillment_queue.enqueue(instance.pk)
+    )
+```
+
+### Async receiver (Django 5.0+)
+```python
+from asgiref.sync import sync_to_async
+
+@receiver(post_save, sender=Comment)
+async def notify_subscribers(sender, instance, **kwargs):
+    await broadcast_to_channel(f"post-{instance.post_id}", {
+        "event": "new_comment",
+        "id": instance.pk,
+    })
+```
+
+### Robust dispatch with error collection
+```python
+results = order_paid.send_robust(sender=Order, order=order)
+for receiver_fn, response in results:
+    if isinstance(response, Exception):
+        logger.exception("receiver %s failed", receiver_fn, exc_info=response)
+```
+
+### Cache invalidation
+```python
+from django.core.cache import cache
+from django.db.models.signals import post_save, post_delete
+
+@receiver([post_save, post_delete], sender=Article)
+def purge_article_cache(sender, instance, **kwargs):
+    cache.delete(f"article:{instance.pk}")
+    cache.delete_pattern("articles:list:*")  # if django-redis
+```
+
+### Disconnect for testing
+```python
+import pytest
+from django.db.models.signals import post_save
+from myapp.signals import create_user_profile
+
+@pytest.fixture(autouse=True)
+def _silence_profile_signal():
+    post_save.disconnect(create_user_profile, sender=User)
+    yield
+    post_save.connect(create_user_profile, sender=User)
+```
+
+## 매 결정 기준
+| 상황 | Approach |
+|---|---|
+| Cross-app decouple side-effect | Signal ✅ |
+| Same-app, deterministic flow | Direct method call (signal 불필요) |
+| Heavy work (email, ML inference) | Signal → enqueue Celery/RQ task |
+| Cross-process / cross-service | Kafka/RabbitMQ — 매 signal 은 in-process 만 |
+| Need ordering / replay | Outbox pattern + message broker |
+
+**기본값**: signal 은 light decouple 만, heavy work 는 즉시 task queue 의 enqueue.
+
+## 🔗 Graph
+- 부모: [[Django]] · [[Observer-Pattern]]
+- 변형: [[Django-Signals]] · [[Flask-Signals]] (blinker) · [[SQLAlchemy-Events]]
+- 응용: [[Audit-Log]] · [[Cache-Invalidation]] · [[Outbox-Pattern]]
+- Adjacent: [[Celery]] · [[Django-ORM]] · [[Transactional-Messaging]]
+
+## 🤖 LLM 활용
+**언제**: in-process decoupling 이 필요할 때, ORM lifecycle hook (post_save 등) 이 자연스러울 때, 매 third-party app 의 own model 의 alter 못할 때.
+**언제 X**: cross-service eventing — 매 Kafka/Outbox 의 use; complex workflow orchestration — 매 Celery chain / Temporal 의 use; testability 가 critical 한 critical path — 매 explicit service call 의 prefer.
+
+## ❌ 안티패턴
+- **Heavy work in receiver**: 매 sync send 면 request latency 의 block — Celery enqueue.
+- **Signals for in-app flow**: 매 traceability 의 lose — 매 explicit method call 의 use.
+- **No transaction.on_commit**: post_save 시점 의 transaction 미commit — race condition 발생.
+- **Forgetting weak=False**: lambda receiver 가 GC 의 collected — 매 module-level def 또는 weak=False.
+- **Test pollution**: signal 의 test 사이 의 leak — fixture 의 disconnect.
+
+## 🧪 검증 / 중복
+- Verified (docs.djangoproject.com/en/5.1/topics/signals/, Django source dispatch/dispatcher.py).
+- 신뢰도 A.
+
+## 🕓 Changelog
+| 날짜 | 변경 |
+|---|---|
+| 2026-05-08 | Phase 1 |
+| 2026-05-10 | Manual cleanup — Django 5.1 signal patterns + async receiver + transaction.on_commit |