이벤트와 리스너는 어떻게 동작하나요?

Question

Accepted Answer

Laravel의 **이벤트와 리스너(events and listeners)**는 옵저버 패턴을 구현합니다 — 주목할 만한 일이 발생하면 **이벤트를 디스패치(dispatch)**하고, 하나 이상의 **리스너(listener)**가 그에 반응합니다. 이는 코드를 분리합니다: 이벤트 발생원은 누가 응답하는지 알 필요가 없어 관심사의 깔끔한 분리가 가능합니다.

## 이벤트와 리스너 정의

```php
// 이벤트 — "무언가 발생했다"를 위한 단순한 데이터 운반체
class OrderShipped {
    public function __construct(public Order $order) {}
}

// 리스너 — 이벤트에 반응
class SendShipmentNotification {
    public function handle(OrderShipped $event): void {
        Mail::to($event->order->customer)->send(new ShipmentMail($event->order));
    }
}
// 생성: php artisan make:event / make:listener
```

## 이벤트 디스패치

```php
// 주문이 배송되면 이벤트를 디스패치 — 모든 리스너가 실행됨
OrderShipped::dispatch($order);
// 또는: event(new OrderShipped($order));
```

이벤트를 디스패치하면 등록된 모든 리스너가 트리거됩니다. 주문 배송 코드는 무슨 일이 일어났는지 알릴 뿐 — 이메일, 분석, 기타 반응이 일어나는 것을 알지도(신경 쓰지도) 않습니다.

## 하나의 이벤트에 여러 리스너 (분리)

```php
// 하나의 이벤트는 많은 리스너를 가질 수 있음 — 각각 별도의 관심사
OrderShipped → SendShipmentNotification    // 이메일
            → UpdateInventory               // 재고 조정
            → RecordAnalytics               // 이벤트 로깅
// 주문 배송 코드를 수정하지 않고 반응 추가
```

이것이 핵심 이점입니다: 이벤트를 디스패치하는 코드를 건드리지 않고 이벤트에 새로운 반응(리스너)을 추가할 수 있습니다 — 깔끔하고 확장 가능한 분리입니다.

## 큐에 쌓인 리스너 (비동기)

```php
class SendShipmentNotification implements ShouldQueue {   // 리스너를 백그라운드에서 실행
    public function handle(OrderShipped $event): void { ... }
}
```

`ShouldQueue`를 구현하면 리스너가 큐를 통해 **비동기적으로** 실행됩니다 — 느린 반응(이메일 전송)이 응답을 지연시키지 않습니다.

## 왜 중요한가

이벤트와 리스너는 코드를 **분리**하는 데 유용한 Laravel 기능입니다 — 애플리케이션의 서로 다른 부분이 강한 결합 없이 발생에 반응하게 하며, 이는 횡단 반응과 코드를 유지보수 가능하게 유지하는 데 가치가 있습니다.

이를 이해하는 것은 사용하는 것과 코드베이스에서 인식하는 것 모두에 도움이 됩니다: 이 패턴은 중요한 일이 발생하면(주문 배송, 사용자 가입) 이벤트를 디스패치하고 여러 독립적인 리스너가 반응(이메일 전송, 재고 업데이트, 분석 기록)하게 하며, 각각 별도의 관심사를 처리합니다.

핵심 이점은 **분리를 통한 확장성**입니다 — 이벤트를 디스패치하는 코드를 수정하지 않고 리스너를 등록하여 새로운 반응을 추가할 수 있어, 관심사를 분리하고 디스패치 코드를 집중된 상태로 유지합니다.

리스너를 **큐에 쌓이게(`ShouldQueue`)** 만들어 비동기적으로 실행하는 능력도 중요하며, 느린 반응(이메일, 외부 API 호출)이 사용자의 응답을 지연시키지 않고 백그라운드에서 일어나게 합니다.

이벤트/리스너가 어떻게 동작하는지, 그 분리 이점, 그리고 비동기 처리를 위한 큐에 쌓인 리스너를 아는 것은 잘 구조화되고 확장 가능한 Laravel 애플리케이션을 구축하는 데 가치 있는 지식입니다. (다른 프레임워크의 시그널과 마찬가지로, 주의할 점은 이벤트가 추적하기 어려운 암묵적이고 원격적인 동작을 만든다는 것입니다 — 따라서 모든 동작 후 로직을 위한 기본값이 아니라 진정한 횡단 분리에 사용하는 것이 가장 좋으며, 명시적인 코드가 흔히 더 명확합니다.)