Django 6의 내장 작업 프레임워크: 테스트 후 첫인상

2025년 9월 28일

Django 6에 기본 작업 프레임워크가 생겼다는 소식을 처음 들었을 때 솔직히 회의적이었습니다. Celery 구성과 씨름하고, Redis/RabbitMQ 설정을 처리하고, 불가사의한 작업자 문제를 디버깅하는 데 몇 년을 보낸 후, 더 간단한 무언가가 약속된 것은 거의 믿기 어려웠습니다. 하지만 지난 한 주 동안 새로운 프레임워크를 살펴본 후, Django 생태계에서 어디에 적합한지, 그리고 어디에 적합하지 않은지 알기 시작했습니다.

Django의 새로운 작업 프레임워크는 정확히 무엇입니까?

Django 6.0 알파 릴리스에 포함된 새로운 작업 프레임워크는 Django가 백그라운드 작업을 처리하는 방식에 있어 근본적인 변화를 의미합니다. Django는 처음으로 HTTP 요청-응답 주기 외부에서 실행해야 하는 작업을 정의하고 대기열에 넣는 기본 방법을 제공합니다.

개념은 아름다울 정도로 간단합니다. 제가 사용하고 있는 기본 패턴은 다음과 같습니다.

from django.core.mail import send_mail
from django.tasks import task

@task
def email_users(emails, subject, message):
    return send_mail(subject, message, None, emails)

작업을 정의했으면 대기열에 넣는 것은 간단합니다.

email_users.enqueue(
    emails=["[email protected]"],
    subject="You have a message",
    message="Hello there!",
)

제가 즉시 느낀 것은 Celery를 설정하는 것에 비해 얼마나 자연스럽게 느껴지는가였습니다. 별도의 Celery 앱을 만들거나, 브로커를 구성하거나, 복잡한 직렬화 설정을 관리할 필요가 없습니다. 잘 작동합니다. 뭐, 그런 셈이죠.

함정: 여전히 작업자가 필요합니다.

여기서 상황이 흥미로워집니다(그리고 일부에게는 잠재적으로 실망스러울 수 있습니다). Django의 작업 프레임워크는 작업 생성 및 대기열 처리를 처리하지만, 작업자 메커니즘은 의도적으로 제공하지 않습니다. 즉, 작업을 실제로 실행하려면 여전히 외부 인프라가 필요합니다.

이번 릴리스에 포함된 두 가지 기본 백엔드는 주로 개발 및 테스트용입니다. 프로덕션 환경에서는 자체 작업자 솔루션을 구현하거나 기존 작업 처리 시스템과 통합해야 합니다. 이 설계 결정은 생각해 보면 타당합니다. Django는 모든 인프라 문제를 해결하려고 하기보다는 웹 프레임워크에 계속 집중합니다.

Celery와 비교: 사과와 오렌지?

모두가 묻는 질문은 이것이 Celery를 대체할 수 있는지 여부입니다. 둘 다 광범위하게 테스트한 후, 제 생각에는 대답이 단순한 예 또는 아니오보다 더 미묘합니다.

Celery는 복잡한 분산 작업 처리를 위한 헤비급 챔피언으로 남아 있습니다. 다음과 같은 기능을 제공합니다.

여러 브로커 백엔드(Redis, RabbitMQ 등)
정교한 라우팅 및 우선순위 시스템
지수 백오프가 있는 내장 재시도 메커니즘
작업 체인 및 워크플로
포괄적인 모니터링 도구

반면에 Django의 작업 프레임워크는 완전한 솔루션이라기보다는 기반처럼 느껴집니다. 전체 Celery 설정의 오버헤드 없이 이메일 보내기 또는 업로드 처리와 같은 기본 작업을 오프로드하려는 더 간단한 사용 사례에 적합합니다.

"CMS 또는 전자 상거래 시스템과 같은 복잡한 애플리케이션의 경우 Celery는 백그라운드 작업에 여전히 완벽한 선택입니다. 구성이 더 간단한 대안보다 복잡할 수 있지만 프로젝트는 앞으로 더 강력해질 것입니다."

최근 비교에서 발췌한 이 인용문은 제 경험과 일치합니다. 개인 프로젝트와 소규모 클라이언트 작업의 경우 Django의 작업 프레임워크가 제가 가장 선호하는 방법이 되고 있습니다. 하지만 대용량 처리 요구 사항이 있는 엔터프라이즈 애플리케이션의 경우 Celery는 어디에도 가지 않을 것입니다.

제 테스트 설정 및 초기 결과

몇 가지 일반적인 시나리오로 프레임워크를 테스트하고 있습니다.

이메일 알림

위의 이메일 예제는 제 개발 환경에서 완벽하게 작동하고 있습니다. 즉시 백엔드는 작업을 동기적으로 처리하며 이는 테스트에 완벽합니다.

데이터 처리

CSV 처리 및 보고서 생성을 위한 작업을 만들었습니다. 데코레이터 구문을 사용하면 기존 기능을 쉽게 변환할 수 있습니다.

@task
def process_user_data(user_id):
    # Heavy processing logic here
    pass

예약된 유지 관리

Django의 프레임워크에는 Celery Beat와 같은 스케줄링 기능이 포함되어 있지 않지만, 특정 간격으로 작업을 대기열에 넣는 cron 작업을 실험하고 있습니다.

구성 및 백엔드 옵션

구성은 Django 설정 파일의 TASKS 설정을 통해 이루어집니다. 프레임워크는 확장 가능하도록 설계되었으므로 Redis, 데이터베이스 큐 및 AWS SQS와 같은 클라우드 서비스에 대한 커뮤니티 개발 백엔드를 곧 볼 수 있을 것으로 예상합니다.

제가 높이 평가하는 것은 유연성입니다. 특정 인프라 선택에 얽매이지 않습니다. 이는 기본값을 제공하면서 사용자 정의를 허용하는 Django의 철학과 잘 부합합니다.

Django 개발자를 위한 실질적인 정보

일주일 동안 실험한 후, 제 조언은 다음과 같습니다.

Django 작업을 사용하는 경우

간단한 이메일 보내기 및 알림
기본 파일 처리 및 업로드
가벼운 데이터 변환
개발 및 테스트 환경
추가 인프라를 피하고 싶은 프로젝트

Celery를 고수하는 경우

대용량 작업 처리
복잡한 워크플로 및 작업 종속성
작업 모니터링 및 관리 UI 필요
여러 서버에서 분산 처리
보장된 배송이 필요한 미션 크리티컬 백그라운드 작업

마이그레이션 전략

현재 Celery를 사용 중이고 전환을 고려 중인 경우, 작게 시작하는 것이 좋습니다. 가장 간단한 백그라운드 작업을 식별하고 먼저 마이그레이션하십시오. Django의 프레임워크가 요구 사항을 충족하는지 평가하는 동안 복잡한 워크플로에는 Celery를 유지하십시오.

앞으로의 전망

Django 6에 기본 작업 프레임워크가 도입된 것은 자연스러운 진화처럼 느껴집니다. 전체 작업 큐 시스템의 복잡성 없이 기본 백그라운드 처리가 필요한 개발자의 격차를 해소합니다. 복잡한 사용 사례에서 Celery를 대체하지는 않겠지만 많은 Django 프로젝트를 단순화하는 데 도움이 되는 훌륭한 추가 기능입니다.

저는 특히 커뮤니티가 이 기반 위에 무엇을 구축할지 기대됩니다. 확장 가능한 백엔드 시스템은 Django의 단순성과 Celery의 강력함 사이의 간극을 메우는 혁신적인 솔루션을 보게 될 것임을 의미합니다.

지금은 일반적인 구성 문제 없이 Django 프로젝트에 백그라운드 작업을 추가하는 단순함을 즐기고 있습니다. 때로는 적은 것이 더 좋습니다.