각 시스템의 개발 동기는 기존 솔루션의 한계를 극복하고자 하는 필요에서 비롯되었습니다. Sidekiq의 마이크 팸은 Rescue의 단일 스레드 구조로 인한 과도한 메모리 사용 문제를 해결하기 위해 멀티스레딩 기반의 Sidekiq을 개발했습니다. Solid Queue의 로사는 David Heinemeier Hansson(DHH)의 요청으로, 기존 Rescue의 복잡성과 사용자 정의 젬 의존성을 벗어나 ‘즉시 작동하는’ 간소화된 솔루션을 목표로 했습니다. Karafka의 마시에이는 Kafka 드라이버의 낮은 개발 경험을 개선하고자 했으며, Shoryuken은 AWS SQS 플러그인 수용 거부로 인해 Sidekiq을 포크하며 시작되었습니다. Good Job의 벤 셸던은 Heroku의 저렴한 다이노에서 실행 가능하며, 기존 Que 시스템의 복잡성을 피할 수 있는 PostgreSQL 기반의 시스템을 구축하고자 했습니다.
개발 과정에서 예상치 못한 변화와 도전도 있었습니다. 마이크 팸은 루비 젬 기반의 상업적 모델이 커뮤니티에 의해 광범위하게 수용된 것에 놀라움을 표하며, 이는 장기적인 유지보수에 필수적이라고 언급했습니다. 로사는 Solid Queue가 트랜잭션 무결성을 포기해야 했던 점을 가장 큰 변화로 꼽았습니다. 이는 레일즈 코어 팀이 delayed_job 경험으로 인해 트랜잭션 내 큐잉에 강한 거부감을 가졌기 때문입니다. 마시에이는 Karafka Pro 버전의 성공과 루비/레일즈 커뮤니티가 Kafka 생태계의 우수성을 충분히 인지하지 못하는 점에 대한 아쉬움을 드러냈습니다. 벤 셸던은 Good Job이 처음에는 단순한 백그라운드 작업만을 목표로 했으나, 사용자들의 지속적인 크론, 배치, 동시성 제어 등 추가 기능 요구에 직면하며 시스템이 예상보다 훨씬 복잡해졌다고 토로했습니다.
사용자들이 가장 많이 오해하거나 어려워하는 부분에 대한 논의도 이어졌습니다. 마이크 팸은 Sidekiq의 Redis 의존성에 대한 사용자들의 막연한 주저함을 지적하며, Redis의 강력한 기능과 안정성을 강조했습니다. 로사는 Solid Queue의 멀티-데이터베이스 설정과 마이그레이션이 필요 없다는 점을 사용자들이 이해하는 데 어려움을 겪는다고 언급했습니다. 마시에이는 Kafka가 단순히 메시지 큐나 작업 큐로만 사용되는 오해와, 개발자들이 문서를 읽지 않는 문제를 꼬집었습니다. 벤 셸던은 작업 큐 이름을 기능(예: mailers_queue)이 아닌 지연 시간(예: 30_second_latency_queue)을 기준으로 명명해야 한다고 강력히 주장하며, 이는 서비스 품질 관리에 필수적이라고 강조했습니다.
향후 10년 후의 시스템 변화에 대한 비전도 제시되었습니다. 마이크 팸은 Sidekiq이 이미 높은 안정성 단계에 도달했으며, 미래에는 루비의 GIL(Global Interpreter Lock) 문제를 해결하기 위한 Ractors의 발전이 핵심이 될 것이라고 보았습니다. 로사는 Solid Queue가 현재 초기 단계이므로, 향후 10년간 더 성숙해지고 특히 동시성 제어 부분에서 성능 개선이 이루어지기를 희망했습니다. 마시에이는 Ractors의 개선과 함께, 레일즈 커뮤니티에 이벤트 중심 아키텍처를 도입할 수 있는 ActiveEvent와 같은 추상화 계층의 등장을 기대했습니다. 벤 셸던은 Active Job 인터페이스가 더 많은 관심을 받고, 동시성 제어와 같은 기능이 내장되어 더욱 강력하고 유연해지기를 바란다고 밝혔습니다. 또한, 패널리스트들은 모니터링, 에러 트래킹, 복잡한 워크플로우 툴링, 그리고 AI 관련 기능 등 루비 커뮤니티가 더 발전시킬 수 있는 새로운 라이브러리 개발 기회에 대해 논의하며, 좋은 개발자 경험과 UI의 중요성을 역설했습니다.