당신의 Celery 작업은 두 번 실행됩니다. 안전하게 만드는 방법은 다음과 같습니다.

(dev.to)

Dev.to WebDev2026년 10월 2일개발자 도구

당신의 Celery 작업은 두 번 실행됩니다. 안전하게 만드는 방법은 다음과 같습니다.

Celery 작업이 중복 실행되는 문제를 방지하기 위해 '정확히 한 수 실행'이라는 불가능한 목표 대신, 데이터베이스의 유니크 제약 조건을 활용해 중복 실행 시 아무 작업도 수행하지 않도록 만드는 멱등성(Idempotency) 설계의 중요성을 다룹니다.

이 글의 핵심 포인트

1Celery는 작업의 '정확히 한 번(Exactly-once)' 실행을 보장할 수 없으며, 중복 실행 가능성을 항상 염두에 두어야 함
2acks_late=True 설정 시 작업 중 워커가 종료되면 브로커가 작업을 재전송하여 중복 실행이 발생함
3해결책은 중복 실행을 막는 것이 아니라, 두 번째 실행이 아무런 동작도 하지 않도록 '멱등성(Idempotency)'을 확보하는 것임
4데이터베이스의 유니크 제약 조건(Unique Constraint)을 활용해 작업 로그를 먼저 생성함으로써 중복 실행을 효과적으로 차단할 수 있음
5task_reject_on_worker_lost 사용 시 무한 재전송 루프에 빠질 위험이 있으므로 전달 횟수 제한이나 타임아웃 설정이 필요함

이 글에 대한 공공지능 분석

왜 중요한가?

결제나 알림 같은 민감한 비즈니스 로직이 중복 실행될 경우 사용자 신뢰도 하락과 직접적인 금전적 손실을 초래할 수 있기 때문입니다. 분산 시스템에서 '정확히 한 번' 실행은 이론적으로 매우 어렵기에, 시스템의 안정성을 확보하는 방어적 설계 패턴을 아는 것이 필수적입니다.

어떤 배경과 맥락이 있나?

Celery와 같은 비동기 작업 큐는 네트워크 오류, 워커 프로세스 종료, 타임아웃 등 다양한 이유로 메시지를 재전송할 수 있는 구조를 가집니다. 특히 `acks_late=True` 설정은 작업 유실을 막아주는 장점이 있지만, 동시에 작업 완료 전 장애 발생 시 중복 실행의 가능성을 높이는 트레이드오프를 가집니다.

업계에 어떤 영향을 주나?

백엔드 엔지니어링의 표준이 '실행 보장'에서 '결과 보장(멱등성)'으로 이동하고 있음을 보여줍니다. 이는 마이크로서비스 아키텍처(MSA) 환경에서 서비스 간 데이터 정합성을 유지하기 위한 핵심적인 설계 원칙으로 자리 잡고 있습니다.

한국 시장에 어떤 시사점이 있나?

결제 및 금융 서비스 비중이 높은 한국 스타트업 생태계에서, 시스템 장애 시 발생할 수 있는 중복 결제나 알림 오류는 치명적인 운영 리스크입니다. 따라서 인프라의 안정성뿐만 아니라 애플리케이션 레벨에서의 멱등성 설계 역량이 엔지니어링 팀의 핵심적인 기술 경쟁력이 될 것입니다.

이 글에 대한 큐레이터 의견

분산 시스템을 설계할 때 'Exactly-once execution'이 불가능하다는 사실을 인정하고 'Exactly-once effect'를 목표로 삼는 것은 매우 현실적이고 성숙한 엔지니어링 접근법입니다. 데이터베이스의 유니크 제약 조건을 활용한 방식은 구현이 단순하면서도 강력한 정합성을 보장할 수 있는 가장 확실한 방어 기제입니다.

다만, 이러한 멱등성 설계에는 '데이터베이스 부하 증가'라는 트레이드오프가 존재합니다. 모든 중요한 작업마다 로그 테이블을 조회하고 쓰기 작업을 수행해야 하므로, 트래픽이 폭증하는 상황에서는 DB 병목 현상의 원인이 될 수 있습니다. 따라서 모든 작업에 적용하기보다는 결제, 이메일 발송 등 비즈니스 임팩트가 큰 핵심 로직에 선별적으로 적용하는 전략적 판단이 필요합니다. 창업자들은 개발 팀이 단순히 기능을 구현하는 것을 넘어, 이러한 예외 상황에 대비한 방어적 설계(Defensive Design)를 구축할 수 있도록 기술적 부채 관리에 집중해야 합니다.

원문 보기 →