BullMQ의 장단점은 무엇이며 언제 사용하나요?

Question

IT Interview Practice · Accepted Answer

BullMQ는 Redis 기반의 Node.js 작업 큐입니다. 적합성을 판단할 때는 **HTTP 응답 뒤에 완료해도 되며 추적이나 재시도가 필요한 작업**부터 살펴봅니다.

큰 보고서를 생각해 봅시다. 요청 안에서 생성하면 사용자가 timeout까지 기다릴 수 있습니다. 큐를 사용하면 작업을 접수하고 작업 ID를 반환한 뒤 별도로 처리할 수 있습니다.

## 1. 큐로 옮기면 무엇이 달라지는지 봅니다

```text
[User] -> [API: submit job] -> [Redis / BullMQ] -> [Worker]
                |                                   |
          [Return job ID]                       [Saved report]
```

생산자는 작업을 제출하고 워커는 실행합니다. 사용자는 진행 상태를 확인하다 준비된 보고서를 내려받습니다.

보고서를 처리하는 시간은 여전히 필요합니다. 개선점은 작업 수명이 열린 HTTP 요청에 의존하지 않고, 워커를 API 서버와 별도로 관리할 수 있다는 것입니다.

## 2. 장점을 요구와 연결합니다

| 필요 | BullMQ 기능 | 앱이 결정할 사항 |
| --- | --- | --- |
| 일시적 실패에서 복구 | 지연을 둔 재시도 | 재시도할 오류와 중단 시점. |
| 나중에 또는 정해진 시간 실행 | 지연 작업과 스케줄링 | 필요한 시간 정확도와 중단 후 동작. |
| 처리 부하 제어 | 동시성 및 속도 제한 | 데이터베이스와 외부 서비스의 안전 한도. |
| 백그라운드 용량 확대 | 워커 추가 | 다음 의존 서비스가 추가 부하를 감당하는지. |

보고서에서는 작업 상태와 재시도 장치를 직접 구현하지 않아도 됩니다. 진행 확인과 실패 조사에 필요한 상태 정보도 얻습니다. 워커 추가는 의존 서비스를 압도하지 않고 완료 시간을 줄일 때만 유용합니다.

## 3. 정확성의 핵심 책임을 이해합니다

워커가 보고서를 저장한 뒤 완료 표시 전에 죽을 수 있습니다. 재시도는 작업을 반복할 수 있습니다. 결제나 알림에서는 같은 패턴의 영향이 더 큽니다.

요청한 작업에 안정적인 업무 식별자를 씁니다. 같은 식별자를 반복하면 효과를 추가하지 말고 의도한 결과를 재사용하거나 안전하게 교체해야 합니다. 이것이 멱등성입니다. 외부 효과에는 제공자의 지원 기능을 활용하고 불확실한 결과를 대조합니다. [멱등 작업](https://docs.bullmq.io/patterns/idempotent-jobs).

데이터베이스 저장과 작업 생성이 함께 필요하면 두 쓰기 사이의 공백을 고려합니다. Outbox는 업무 레코드와 같은 트랜잭션에 지시를 기록하고, 발행자가 나중에 큐로 보냅니다. 전달은 반복될 수 있어 워커의 멱등성이 여전히 필요합니다.

## 4. Redis와 워커 운영 비용도 포함합니다

Redis는 대기 작업을 보관하므로 영속성, 메모리 정책, 복구 계획이 중요합니다. 큐에는 noeviction을 설정합니다. 메모리 확보를 위해 키를 조용히 제거하는 것은 유지해야 할 작업에 부적합합니다. 앱 재시작 안전성이 Redis의 모든 장애를 해결한다고 가정하지 말고 복구를 시험합니다. [운영 환경 안내](https://docs.bullmq.io/guide/going-to-production).

큰 보고서 파일은 적절한 저장소에 두고 작업에는 참조를 전달합니다. 완료 및 실패 작업의 보존 기간을 정해 Redis 사용량을 통제합니다.

CPU 작업이 워커의 이벤트 루프를 막으면 잠금 갱신에 지장을 줄 수 있습니다. 작업이 정지된 것으로 간주돼 다시 처리될 수 있습니다. 적절한 워커 스레드나 격리된 프로세서를 사용하고 정지 작업을 모니터링합니다. [정지 작업](https://docs.bullmq.io/guide/jobs/stalled).

## 5. 조건에 따라 권장합니다

- Node.js 앱에 관찰 가능한 백그라운드 작업, 재시도, 별도 확장 워커가 필요하고 팀이 Redis를 안정적으로 운영할 수 있다면 BullMQ를 선택합니다.
- 영속 추적이나 독립 실행이 필요 없는 작은 로컬 동작은 단순하게 유지합니다.
- 큐 작업 완료보다 여러 독립 소비자의 장기 재생이 핵심이면 영속 이벤트 로그를 검토합니다.

보고서 예시에서는 의존 서비스 실패, 결과 저장 직후 워커 장애, 서비스 중단 후 복구를 시험합니다. 사용자가 신뢰할 상태를 보고 재시도가 서로 충돌하는 결과를 만들지 않는지 확인합니다.

**기억할 점:** BullMQ는 작업을 조정합니다. 업무 정확성은 앱이 보장하고, 큐 운영 책임은 팀에 남습니다.

필요	BullMQ 기능	앱이 결정할 사항
일시적 실패에서 복구	지연을 둔 재시도	재시도할 오류와 중단 시점.
나중에 또는 정해진 시간 실행	지연 작업과 스케줄링	필요한 시간 정확도와 중단 후 동작.
처리 부하 제어	동시성 및 속도 제한	데이터베이스와 외부 서비스의 안전 한도.
백그라운드 용량 확대	워커 추가	다음 의존 서비스가 추가 부하를 감당하는지.

1. 큐로 옮기면 무엇이 달라지는지 봅니다

2. 장점을 요구와 연결합니다

3. 정확성의 핵심 책임을 이해합니다

4. Redis와 워커 운영 비용도 포함합니다

5. 조건에 따라 권장합니다

관련 질문