BackgroundTasks는 어떻게 동작합니까?

Question

Accepted Answer

FastAPI의 **`BackgroundTasks`**는 **응답을 반환한 후** 작업을 실행할 수 있게 합니다. 클라이언트는 빠른 응답을 받고, 가벼운 후속 작업(이메일 전송, 로깅, 정리)은 백그라운드에서 일어납니다. 내장되어 있으며 간단하고, 가벼운 작업을 위한 것입니다.

## BackgroundTasks 사용하기

```python
from fastapi import BackgroundTasks

def send_email(address: str, message: str):
    # 클라이언트가 기다릴 필요 없는 다소 느린 작업
    email_client.send(address, message)

@app.post("/signup")
def signup(user: User, background_tasks: BackgroundTasks):   # BackgroundTasks 주입
    save_user(user)
    background_tasks.add_task(send_email, user.email, "Welcome!")   # 작업 등록
    return {"message": "User created"}    # 응답이 지금 반환되고, 이메일은 이후에 전송됨
```

`BackgroundTasks` 매개변수를 주입하고 `add_task(func, *args)`를 호출합니다. FastAPI는 먼저 응답을 보낸 다음, 등록된 작업을 실행합니다. 따라서 사용자는 이메일을 기다리지 않습니다.

## 다중 작업과 의존성과의 사용

```python
@app.post("/order")
def create_order(order: Order, bg: BackgroundTasks):
    bg.add_task(send_confirmation, order.email)
    bg.add_task(update_analytics, order.id)     # 여러 작업이 응답 후 순서대로 실행됨
    return {"status": "created"}
```

## 결정적 제한: 무겁거나 중요한 작업에는 부적합

```text
BackgroundTasks는 웹 서버와 같은 프로세스에서 실행됩니다:
  ✗ 영속성 없음 — 서버가 크래시/재시작되면 등록된 작업이 손실됨
  ✗ 재시도, 스케줄링, 분산 없음
  ✗ 무거운 CPU 작업은 워커 프로세스를 여전히 묶어둠
→ 적합: 빠르고 비중요한 fire-and-forget 작업 (이메일, 로깅, 가벼운 정리)
→ 무겁고 중요하며 재시도 가능하거나 스케줄링된 작업 → Celery / ARQ(진짜 작업 큐) 사용
```

## 어느 것을 언제 사용할지

```text
BackgroundTasks → 요청에 묶인 간단하고 가벼운 best-effort 작업 (추가 인프라 불필요)
Celery / ARQ    → 내구성 있고 재시도/스케줄링/분산되는 작업 (브로커/워커 필요)
```

## 왜 중요한가

`BackgroundTasks`는 클라이언트를 기다리게 하지 않고 후속 작업을 하는 흔한 필요—환영 이메일 전송, 로그 작성, 가벼운 정리—를 위한 편리한 내장 도구로, 사용자의 응답 시간을 개선합니다.

추가 인프라가 필요 없으므로 이러한 일상적인 가벼운 경우에 유용합니다.

하지만 **가장 중요한 점**은 그 **제한**을 아는 것입니다: 웹 서버와 같은 프로세스에서 실행되기 때문에 영속성이 없고(크래시/재시작 시 작업 손실), 재시도와 스케줄링이 없으며, 무겁거나 중요한 작업에 적합하지 않습니다.

이 경계를 인식하는 것—빠르고 비중요한 fire-and-forget 작업에는 `BackgroundTasks`를, 내구성 있고 재시도 가능하며 스케줄링되거나 무거운 백그라운드 작업에는 **Celery/ARQ** 같은 진짜 작업 큐를 사용하는 것—은 손실되어서는 안 되는 작업에 BackgroundTasks를 의존하는 흔한 실수를 방지하는 핵심 판단이며, 신뢰할 수 있는 애플리케이션을 구축하기 위한 중요한 실용 지식입니다.