Node.js에서 EventEmitter와 작업 큐는 어떻게 다른가요?

Question

IT Interview Practice · Accepted Answer

EventEmitter와 작업 큐는 **작업이 어디에서 실행돼야 하고 프로세스가 멈추면 어떻게 돼야 하는지**에 따라 선택합니다.

EventEmitter는 한 Node.js 프로세스의 리스너에게 알립니다. 영속 큐는 워커가 나중에 처리할 작업을 저장합니다. 둘 다 책임을 분리하지만 장애 시 동작은 다릅니다.

## 1. 로컬 알림 흐름을 봅니다

컴포넌트 초기화가 끝나 같은 프로세스의 다른 컴포넌트가 반응해야 한다고 합시다. 리스너를 등록하고 이벤트를 발생시키는 EventEmitter가 자연스럽습니다.

```text
[One process]
emit("ready") -> Listener A
              -> Listener B
```

Node.js는 등록 순서대로 리스너를 동기 호출합니다. 이벤트 자체는 나중에 등록할 리스너를 위해 저장되지 않으며, 미완료 작업도 프로세스 장애 후 남지 않습니다. [Node.js Events](https://nodejs.org/api/events.html).

알림이 로컬이며 유실되거나 재구성돼도 괜찮다면 적합합니다. 발신자가 멈춰도 작업이 살아 있어야 한다면 부족합니다.

## 2. async 리스너가 바꾸는 것을 이해합니다

Async 리스너는 비동기 작업을 시작할 수 있지만 emit은 반환된 promise를 기다리지 않습니다. 호출 순서가 완료 순서라는 보장은 없습니다.

리스너 안의 CPU 집약적 동기 코드는 여전히 프로세스를 지연시킵니다. 예외와 promise 거부를 명시적으로 처리합니다. captureRejections는 거부를 오류 처리로 보낼 수 있지만 작업을 저장하거나 재시도하지는 않습니다.

Async는 리스너의 실행 방식을 바꿉니다. 메모리 이벤트를 영속 큐로 바꾸지는 않습니다.

## 3. 큐 작업의 흐름을 봅니다

주문 저장 후 반드시 청구서를 생성해야 한다고 합시다. 큐는 워커가 없거나 바쁠 때 지시를 보관할 장소를 제공합니다.

```text
[Producer] -> [Durable queue] -> [Available worker]
                    |                   |
              [Pending work]      [Result / retry]
```

생산자가 작업을 제출하고 워커는 한 번의 시도를 처리해 결과를 기록합니다. 워커는 API와 별도로 배포하고 확장할 수 있습니다. 영속성은 큐의 저장소와 설정에 달려 있습니다.

일반적인 경쟁 워커 큐에서는 시도마다 한 워커가 처리합니다. 모든 EventEmitter 리스너에게 방송하는 것과 다릅니다. 여러 독립 구독자가 각각 이벤트를 받아야 한다면 그 요구를 지원하는 전달 모델을 선택하거나 설정합니다.

## 4. 저장과 큐 제출 사이의 공백을 확인합니다

EventEmitter는 주문 저장 후 이벤트 발생 전에 죽으면 청구 지시를 잃을 수 있습니다. 영속 큐는 받은 뒤의 작업을 보호하지만, 앞선 데이터베이스 커밋과 제출 사이를 자동으로 보호하지 않습니다.

Outbox는 주문과 지시를 같은 데이터베이스 트랜잭션에 저장해 이 공백을 닫습니다. 발행자가 outbox를 읽어 나중에 작업을 보냅니다.

발행자가 확인 응답을 잃으면 전달이 반복될 수 있습니다. 청구서 생성에 안정적인 업무 키와 고유 제약 또는 다른 멱등 구현을 적용합니다. 재시도가 두 번째 청구서를 만들면 안 됩니다. [멱등 작업](https://docs.bullmq.io/patterns/idempotent-jobs).

## 5. 실제 요구와 비교합니다

| 요구 | EventEmitter | 영속 작업 큐 |
| --- | --- | --- |
| 한 프로세스의 컴포넌트 알림 | 직접적이고 가벼움 | 보통 불필요한 인프라가 추가됩니다. |
| 발신자 종료 후 작업 유지 | 내장 영속 기록 없음 | 적절한 저장과 복구로 가능합니다. |
| 재시도와 적체 확인 | 앱이 구현해야 함 | 일반적인 큐 기능이며 설정이 필요합니다. |
| 다른 머신에서 실행 | 담당 역할이 아님 | 워커가 독립 실행할 수 있습니다. |

초기화 예시에는 EventEmitter를 쓰겠습니다. 실패에서 복구해야 하는 청구 생성에는 영속 큐를 쓰고 데이터베이스 인계와 중복 시도까지 처리하겠습니다.

제출 전, 접수 후, 업무 효과 발생 후에 프로세스를 멈춰 시험합니다. 결과는 사용자가 기대하는 보장과 맞아야 합니다.

**기억할 점:** 로컬 알림은 EventEmitter, 복구 가능한 백그라운드 작업은 영속 큐입니다. 중요한 효과에는 인계와 멱등성도 설계합니다.

요구	EventEmitter	영속 작업 큐
한 프로세스의 컴포넌트 알림	직접적이고 가벼움	보통 불필요한 인프라가 추가됩니다.
발신자 종료 후 작업 유지	내장 영속 기록 없음	적절한 저장과 복구로 가능합니다.
재시도와 적체 확인	앱이 구현해야 함	일반적인 큐 기능이며 설정이 필요합니다.
다른 머신에서 실행	담당 역할이 아님	워커가 독립 실행할 수 있습니다.

1. 로컬 알림 흐름을 봅니다

2. async 리스너가 바꾸는 것을 이해합니다

3. 큐 작업의 흐름을 봅니다

4. 저장과 큐 제출 사이의 공백을 확인합니다

5. 실제 요구와 비교합니다

관련 질문