백그라운드 작업과 cron: 예약 실행·주기 작업을 안정적으로 돌리는 4가지 방법

먼저 작업의 성격부터 나누기

백그라운드 작업은 사용자가 버튼을 누른 뒤 바로 끝나지 않아도 되는 일을 뜻합니다. 매일 데이터를 정리하거나, 예약 메일을 보내거나, 외부 API 결과를 동기화하는 일이 대표적입니다. 중요한 것은 cron을 먼저 고르는 것이 아니라 작업의 성격을 분리하는 것입니다.

시간 기준으로 실행하는 작업

정해진 시각이나 간격에 한 번 실행하면 되는 작업은 cron과 잘 맞습니다. 예를 들어 매일 새벽 통계 집계, 만료 데이터 정리, 주기적인 캐시 갱신이 여기에 해당합니다. 다만 실행 시간이 길거나 실패한 항목만 다시 처리해야 한다면 단순 cron만으로는 부족할 수 있습니다.

이벤트에 반응하는 작업

사용자 가입, 결제 완료, 파일 업로드처럼 사건이 발생할 때 처리해야 하는 일은 큐와 워커 구조가 더 자연스럽습니다. 예약 실행이 아니라 작업 단위의 추적과 재처리가 필요하기 때문입니다. 실제 운영에서는 cron이 큐에 작업을 넣고, 워커가 하나씩 처리하는 조합도 자주 고려할 만합니다.

4가지 실행 방식 비교

1. 서버리스 cron

호스팅 플랫폼의 예약 호출 기능으로 특정 API나 함수를 실행하는 방식입니다. 인프라를 직접 관리할 부분이 적어 작은 서비스의 정기 작업을 시작하기 좋습니다. 반면 실행 시간, 동시 실행, 로그 보관 정책은 플랫폼마다 다를 수 있으므로 공식 문서에서 확인해야 합니다. 호출 주소를 외부에 노출한다면 비밀 토큰이나 서명 검증도 함께 설계하세요.

2. 외부 스케줄러

별도의 스케줄 서비스가 내 API를 호출하게 만드는 방식입니다. 애플리케이션 배포 환경과 예약 실행을 분리할 수 있어 관리가 편해질 수 있습니다. 대신 외부 서비스 장애, 인증 정보 관리, 호출 실패 확인이라는 운영 지점이 늘어납니다. 환경변수와 비밀키 관리 가이드를 참고해 호출용 키를 코드에 직접 넣지 않는 편이 안전합니다.

3. 컨테이너 안의 cron

항상 실행 중인 서버나 컨테이너 내부에서 cron 프로세스를 돌리는 방식입니다. 실행 환경을 세밀하게 통제할 수 있고 기존 스크립트를 재사용하기 쉽습니다. 하지만 컨테이너가 재시작되거나 여러 복제본으로 늘어나면 작업이 중복될 수 있습니다. 배포 구조가 바뀔 때 cron 프로세스의 단일 실행 여부를 다시 점검해야 합니다.

4. 큐 기반 워커

작업을 큐에 넣고 별도의 워커가 꺼내 처리하는 구조입니다. 실패한 작업 재시도, 처리 상태 기록, 작업량에 따른 워커 조절이 중요한 경우 가장 유연합니다. 초기에는 구성 요소가 많아 보이지만 이미지 처리, 대량 동기화처럼 실행 시간이 들쭉날쭉한 작업에는 오히려 사고 원인을 찾기 쉽습니다. 시스템을 여러 서비스로 나누기 전에는 모놀리식으로 시작하는 기준도 함께 검토해 보세요.

상황별로 선택하는 간단한 기준

작고 짧은 정기 작업

실행 시간이 짧고 실패해도 다음 실행 때 다시 시도할 수 있다면 서버리스 cron부터 검토합니다. 단, 실행 횟수나 제한은 사용하는 플랫폼의 공식 문서에서 확인하세요.

외부 API와 긴 작업

처리 시간이 길거나 부분 실패가 잦다면 큐 기반 워커가 적합합니다. 한 번에 전체를 처리하려 하지 말고 항목별 작업으로 쪼개면 재시도 범위도 작아집니다.

이미 운영 중인 단일 서버

컨테이너 cron이 가장 빠른 선택일 수 있지만, 복제본이 생길 가능성이 있다면 분산 락이나 단일 실행 전용 프로세스를 미리 고려해야 합니다. 배포 환경을 바꾸는 시점에는 배포·호스팅을 갈아타는 타이밍도 함께 점검하세요.

안정성을 만드는 세 가지 설계 원칙

멱등성

같은 작업이 두 번 실행되어도 결과가 망가지지 않게 만드세요. 예를 들어 중복 메일 발송을 막기 위해 대상과 작업 종류를 조합한 처리 키를 저장하고, 이미 완료된 키는 건너뛰는 식입니다. 데이터베이스 변경을 포함한다면 상태 전이를 명확히 기록하는 것이 좋습니다.

실패 재시도

모든 실패를 같은 방식으로 재시도하면 안 됩니다. 일시적인 네트워크 오류는 잠시 기다렸다가 다시 시도할 수 있지만, 잘못된 입력이나 권한 오류는 계속 실패할 가능성이 큽니다. 최대 재시도 횟수, 재시도 간격, 영구 실패 상태를 정하고 로그에 남기세요.

중복 실행 방지

예약 작업은 이전 실행이 끝나기 전에 다음 실행이 시작될 수 있습니다. 실행 시작 시 락을 획득하고 일정 시간이 지나면 만료되게 하거나, 작업별 고유 키로 중복 처리를 차단하는 방법을 사용할 수 있습니다. 락을 잡은 채 프로세스가 죽는 상황까지 가정해야 합니다.

출시 전 운영 체크리스트

• 작업마다 예상 실행 시간과 최대 처리량을 적었는가?
• 같은 요청이 두 번 와도 안전한가?
• 일시 오류와 영구 오류를 구분하는가?
• 실패한 작업을 사람이 다시 확인할 수 있는가?
• 실행 시작·종료·실패 원인을 로그로 남기는가?
• 인증된 호출만 작업을 실행할 수 있는가?
• 작업이 중복되거나 멈췄을 때 알림을 받을 방법이 있는가?

조코헌트에 출시된 프로덕트가 364개라는 사실은, 백그라운드 작업도 결국 작은 제품의 운영 품질을 좌우한다는 점을 보여주는 규모입니다. 처음부터 복잡한 시스템을 만들 필요는 없지만, 멱등성·실패 처리·중복 방지만큼은 첫 작업부터 체크해 두세요. 출시 후 첫 24시간 안에 반응을 받은 프로덕트가 45%인 만큼, 초기에 들어오는 피드백과 운영 로그를 함께 보며 작업 구조를 다듬는 흐름이 현실적입니다.