Rails 백그라운드 작업 2026: Sidekiq vs Good Job 비교 및 면접 질문

Rails 백그라운드 작업은 Rails 8.x와 Solid Queue의 기본 도입으로 크게 발전했습니다. Sidekiq, Good Job, Solid Queue 중 어떤 것을 선택할지는 처리량 요구사항, 인프라 구성, 필요한 기능에 따라 결정됩니다.

Active Job을 통한 백그라운드 처리 통합

Active Job은 Rails에서 백그라운드 작업을 선언, 큐잉, 실행하기 위한 표준 인터페이스를 제공합니다. 이 프레임워크는 큐 백엔드 간의 차이를 추상화하여 Sidekiq, Good Job, Solid Queue 또는 다른 어댑터 간에 코드 이식성을 유지할 수 있습니다.

# app/jobs/payment_processor_job.rb
class PaymentProcessorJob < ApplicationJob
  queue_as :critical
  retry_on Stripe::RateLimitError, wait: :polynomially_longer, attempts: 5
  discard_on Stripe::InvalidRequestError

  def perform(order_id)
    order = Order.find(order_id)
    PaymentService.process(order)
    OrderMailer.confirmation(order).deliver_later
  end
end

retry_on과 discard_on 콜백은 백엔드별 코드 없이 일시적인 실패와 영구적인 오류를 처리합니다. queue_as 지시문은 우선순위를 할당하며, 각 백엔드는 자체 큐 처리 전략에 따라 이를 해석합니다.

Sidekiq 8.x: Redis 기반 고처리량

Sidekiq은 Rails 백그라운드 작업의 성능 기준으로 자리 잡고 있습니다. 8.x 릴리스 시리즈는 Ruby 3.2 이상, Rails 7.0 이상, Redis 7.2 이상이 필요합니다(Redis가 라이선스를 변경했기 때문에 Valkey와 Dragonfly가 드롭인 대체품으로 작동합니다).

# config/initializers/sidekiq.rb
Sidekiq.configure_server do |config|
  config.redis = { url: ENV.fetch('REDIS_URL') }
  config.concurrency = 10
end

Sidekiq.configure_client do |config|
  config.redis = { url: ENV.fetch('REDIS_URL') }
end

Sidekiq 8에서는 세 가지 주요 변경 사항이 도입되었습니다. Web UI가 완전히 재작성되어 CSS가 160KB에서 16KB로 줄었고 평균 페이지 렌더링 시간이 55ms에서 3ms로 단축되었습니다. Vernier를 사용한 작업 프로파일링이 새로운 Profiles 탭에서 사용 가능해졌으며, 작업 메트릭이 최대 72시간 동안 유지됩니다.

Sidekiq이 적합한 경우

Sidekiq은 지속적인 처리량, 서브밀리초 작업 픽업 지연 시간, 또는 속도 제한 및 고유 작업과 같은 엔터프라이즈 기능이 Redis 운영을 정당화하는 워크로드에 적합합니다. 7.0에서 도입되어 현재 표준이 된 Capsules를 통해 하나의 Sidekiq 프로세스에서 자체 동시성과 큐를 가진 여러 격리된 스레드 풀을 실행할 수 있습니다.

# config/sidekiq.yml
:concurrency: 10
:queues:
  - [critical, 3]
  - [default, 2]
  - [low, 1]

# 격리 처리를 위한 Capsules
:capsules:
  imports:
    :concurrency: 2
    :queues:
      - imports

임베딩 API를 통해 Solid Queue의 Puma 플러그인과 유사하게 소규모 애플리케이션에서 Sidekiq을 Puma 프로세스 내에서 실행할 수도 있습니다.

Good Job 4.x: PostgreSQL 네이티브 배치 및 고유성

Good Job은 작업 픽업에 PostgreSQL의 LISTEN/NOTIFY를, 한 번만 실행 보장에 어드바이저리 락을 사용합니다. 버전 4.19.x(2026년 9월 현재)는 Rails 6.1 이상과 Ruby 3.0 이상을 지원합니다.

# config/application.rb
config.active_job.queue_adapter = :good_job

# config/initializers/good_job.rb
Rails.application.configure do
  config.good_job.execution_mode = :async
  config.good_job.max_threads = 5
  config.good_job.poll_interval = 5
  config.good_job.shutdown_timeout = 25
end

Good Job은 Sidekiq이 유료 라이선스로 제공하는 배치 및 고유 작업 기능을 오픈 소스 버전에서 제공합니다. perform_later 호출은 호출 코드와 동일한 데이터베이스 트랜잭션 내에서 good_jobs 테이블에 행을 삽입하므로 트랜잭션이 롤백되면 작업이 생성되지 않습니다.

라이선스 없는 배치 처리

# app/jobs/batch_import_job.rb
class BatchImportJob < ApplicationJob
  def perform(batch, params)
    batch.on(:finish, ImportCompletionJob, params)
    
    params[:file_ids].each do |file_id|
      batch.add do
        ProcessFileJob.perform_later(file_id)
      end
    end
  end
end

# 배치 큐잉
GoodJob::Batch.enqueue do |batch|
  BatchImportJob.perform_later(batch, file_ids: [1, 2, 3])
end

멱등성을 위한 고유 작업

# app/jobs/sync_inventory_job.rb
class SyncInventoryJob < ApplicationJob
  include GoodJob::ActiveJobExtensions::UniqueJob

  good_job_control_concurrency_with(
    perform_limit: 1,
    key: -> { "sync_inventory_#{arguments.first}" },
    duration: 1.hour
  )

  def perform(warehouse_id)
    InventorySync.run(warehouse_id)
  end
end

perform_limit: 1 제약 조건은 각 창고에서 동시에 하나의 동기화만 실행되도록 하여 동일한 작업이 여러 번 큐에 추가될 때 중복 작업을 방지합니다.

Solid Queue: Rails 8 기본값

Solid Queue는 PostgreSQL과 MySQL 기능인 FOR UPDATE SKIP LOCKED를 사용하여 일반 테이블을 작업 큐로 변환하고 애플리케이션 데이터베이스에 작업을 저장합니다. 새로운 Rails 8 애플리케이션은 Solid Queue가 기본 설정된 상태로 제공됩니다.

# config/solid_queue.yml
production:
  dispatchers:
    - polling_interval: 1
      batch_size: 500
  workers:
    - queues: "*"
      threads: 5
      polling_interval: 0.1

Solid Queue는 SOLID_QUEUE_IN_PUMA=true로 Puma 웹 서버 프로세스 내에서 실행할 수 있어 전용 워커 프로세스가 필요 없는 애플리케이션의 배포를 단순화합니다. 작업은 데이터베이스 테이블에 영구 저장되어 외부 의존성 없이 프로세스 재시작과 배포를 견딥니다.

기능 비교표

Rails 백그라운드 작업 면접 질문

기술 면접에서는 작업 신뢰성, 재시도 전략, 아키텍처 결정에 대한 이해를 자주 평가합니다. 다음은 경험 많은 지원자를 구분하는 질문들입니다.

Q1: retry_on과 백엔드별 재시도 로직의 차이점은 무엇입니까?

retry_on은 모든 백엔드에서 작동하는 Active Job 콜백입니다. 특정 예외를 캐치하고 대기 전략(:polynomially_longer는 지수 백오프)을 적용하며 작업을 다시 큐에 넣습니다. Sidekiq의 sidekiq_retry_in과 같은 백엔드별 재시도 로직은 해당 백엔드에서만 작동하며 Active Job의 동작을 재정의할 수 있습니다.

# Active Job 재시도(이식 가능)
class ApiSyncJob < ApplicationJob
  retry_on Net::OpenTimeout, wait: :polynomially_longer, attempts: 8
  
  def perform(record_id)
    ExternalApi.sync(record_id)
  end
end

Q2: 작업을 큐에 넣은 데이터베이스 트랜잭션이 롤백되면 작업은 어떻게 됩니까?

데이터베이스 기반 큐(Good Job, Solid Queue)에서는 작업 행이 트랜잭션의 일부이므로 다른 모든 것과 함께 롤백됩니다. Redis 기반 큐(Sidekiq)에서는 트랜잭션이 완료되기 전에 작업이 이미 Redis에 있어 고아 작업이 생성됩니다. 해결책은 after_commit 콜백입니다.

# Sidekiq의 올바른 패턴
class Order < ApplicationRecord
  after_commit :enqueue_confirmation, on: :create

  private

  def enqueue_confirmation
    OrderConfirmationJob.perform_later(id)
  end
end

Q3: Good Job이 Sidekiq보다 나은 경우는 언제입니까?

Good Job은 Redis의 운영 비용이 처리량 이점을 초과할 때 Sidekiq보다 우수합니다. 하루 5만 건 미만의 작업을 처리하는 애플리케이션에서는 PostgreSQL 기반 큐가 별도의 Redis 클러스터의 인프라, 모니터링, 장애 조치 복잡성을 피할 수 있습니다. Good Job은 라이선스 비용 없이 배치와 고유 작업도 제공하여 예산 내에서 이러한 기능이 필요한 팀에게 중요합니다.

Q4: 작업 멱등성과 재시도에 중요한 이유를 설명하세요

멱등성은 동일한 작업을 여러 번 실행해도 한 번 실행한 것과 같은 결과를 생성한다는 것을 의미합니다. 네트워크 장애, 프로세스 충돌 또는 타임아웃 처리로 인해 중복 실행이 발생할 수 있으므로 작업은 반드시 멱등해야 합니다. 기법에는 데이터베이스의 고유 제약 조건, 처리 전 기존 결과 확인, 결제 API용 외부 멱등성 키 사용이 포함됩니다.

# 멱등한 결제 처리
def perform(order_id, idempotency_key)
  return if Payment.exists?(idempotency_key: idempotency_key)
  
  Payment.create!(
    order_id: order_id,
    idempotency_key: idempotency_key,
    amount: Order.find(order_id).total
  )
end

Q5: 분산 워커에서 작업을 정확히 한 번만 실행하려면 어떻게 해야 합니까?

분산 락이 동시 실행을 방지합니다. Good Job은 PostgreSQL 어드바이저리 락을 사용합니다. Sidekiq Enterprise는 고유 작업을 제공합니다. 수동 구현의 경우 Redis SETNX 또는 PostgreSQL pg_try_advisory_lock을 사용합니다.

class ExclusiveJob < ApplicationJob
  def perform(resource_id)
    lock_key = "exclusive_job:#{resource_id}"
    
    ActiveRecord::Base.connection.execute(
      "SELECT pg_try_advisory_lock(hashtext('#{lock_key}'))"
    ).first['pg_try_advisory_lock'] or return
    
    begin
      process_resource(resource_id)
    ensure
      ActiveRecord::Base.connection.execute(
        "SELECT pg_advisory_unlock(hashtext('#{lock_key}'))"
      )
    end
  end
end

Rails 백그라운드 작업에 적합한 백엔드 선택

• 스택에 아직 Redis가 없는 새로운 Rails 8 프로젝트에서는 Solid Queue로 시작한다
• 작업량이 하루 5만 건을 초과하거나 100ms 미만의 픽업 지연 시간이 중요한 경우 Sidekiq으로 전환한다
• 라이선스 비용 없이 배치 처리, 고유 작업 또는 Cron 스케줄링이 필요한 PostgreSQL 전용 배포에는 Good Job을 선택한다
• Sidekiq으로 작업을 큐에 넣을 때 after_commit 콜백을 사용하여 트랜잭션 롤백 시 고아 작업을 방지한다
• 재시도와 분산 처리로 인해 중복 실행이 발생할 수 있으므로 모든 작업을 멱등하게 만든다
• 면접에서는 트랜잭션 내 작업 큐잉, 재시도 전략, 분산 락 패턴에 대한 이해를 보여주는 것이 중요하다