1. 배경: 작업 중단이 초래하는 비용 문제
전통적인 환경에서 10만 건의 CSV 데이터를 처리하는 작업이 60% 진행된 시점에 배포가 발생하면, 해당 작업은 처음부터 다시 시작됩니다. 이는 이미 소모된 20~30분의 컴퓨팅 자원을 완전히 낭비하게 만들며, 멱등성(Idempotency)이 보장되지 않은 설계라면 데이터 중복 기록의 위험까지 초래합니다. 특히 Kamal과 같은 컨테이너 기반 배포 도구는 셧다운 신호 후 짧은 대기 시간만을 허용하므로, 긴 작업들은 빈번하게 중단되고 재시작되는 악순환에 빠지기 쉽습니다. 이러한 중복 처리는 클라우드 비용 상승의 직접적인 원인이 됩니다.
2. Active Job Continuations의 핵심 메커니즘
Rails 8.1은 비디오 게임의 ‘세이브 포인트’와 유사한 체크포인트 시스템을 도입했습니다. ActiveJob::Continuable 모듈을 포함하면 작업을 논리적인 단계(step)로 분할할 수 있습니다. 각 단계가 완료될 때마다 상태가 저장되며, 서버 재시작이나 타임아웃으로 작업이 중단되더라도 다음 실행 시 마지막으로 성공한 단계부터 즉시 재개됩니다. 이는 전체 작업 시간을 단축시키고 불필요한 리소스 낭비를 원천적으로 차단합니다.
3. 실제 구현 방법 및 코드 구조
구현은 매우 직관적이며 기존 Job 구조를 크게 해치지 않습니다.
- 모듈 포함: include ActiveJob::Continuable을 통해 기능을 활성화합니다.
- 단계(Step) 정의: step :process_data와 같이 로직을 블록으로 감싸 체크포인트를 생성합니다.
- 커서(Cursor) 활용: step.advance!(from: record.id)를 사용하여 루프 내에서 현재 진행 위치를 정밀하게 추적할 수 있습니다.
- 중첩 구조 지원: 복잡한 데이터 구조를 처리할 때도 다중 커서를 지원하여 정교한 재개 지점을 설정할 수 있습니다.
4. 도입 시 얻을 수 있는 주요 이점
- 인프라 비용 최적화: 중복 연산을 제거함으로써 실제 컴퓨팅 사용량에 비례하는 비용 절감이 가능합니다. 중소 규모 앱에서도 월 수백 달러의 절감 효과를 볼 수 있습니다.
- 예측 가능한 리소스 사용: 작업이 선형적으로 진행되므로 서버 부하 예측이 쉬워지고 용량 계획(Capacity Planning)이 용이해집니다.
- 데이터베이스 부하 감소: 이미 처리된 레코드를 다시 조회하거나 수정하지 않으므로 DB I/O 스트레스가 현저히 줄어듭니다.
- 개발 생산성 향상: Redis나 별도 테이블을 이용해 직접 구현하던 체크포인트 로직을 프레임워크 레벨에서 표준화된 방식으로 제공받게 됩니다.
5. 적용 가이드 및 주의사항
모든 작업에 이 기능을 적용할 필요는 없습니다. 5초 미만의 짧은 작업이나 원자성(Atomicity)이 반드시 보장되어야 하는 단일 트랜잭션 작업은 제외하는 것이 좋습니다. 또한 step 블록 외부의 코드는 작업이 재개될 때마다 매번 실행되므로, 초기화 로직은 가급적 첫 번째 단계 안에 배치하거나 재실행에 안전하도록 설계해야 합니다. 현재 Solid Queue와 최신 버전의 Sidekiq이 이 기능을 완벽하게 지원하며, Rails 8.1로의 업그레이드 시 가장 먼저 고려해야 할 기능 중 하나입니다.