RubyLLM: 주요 AI 제공자를 하나로 묶는 Ruby 프레임워크

RubyLLM이 의외로 좋았고, 사용성 면에서는 Vercel의 AI 프레임워크에 가까움
바로 동작하는 편의성과 유연성 사이에서 균형을 잡으려 하는데, 그만큼 어려움도 있지만 전반적으로 괜찮았음
실제로 겪은 큰 불편은 캐시가 항상 동작하지 않는다는 점임. 예를 들어 xAI는 completions API만 지원하고 thought signature가 잘못 반환돼 문제가 생김

RubyLLM을 프로덕션에서 쓰고 있고 아주 좋아함. 훌륭하고 쓰기 쉬운 프레임워크임
Responses API가 기본 지원되지 않는 점은 다른 사람 말처럼 답답했는데, 큰 누락처럼 보였음. 다른 개발자가 만든 커넥터가 있긴 하지만 버그가 있고 메인 gem만큼 품질이 높지는 않음
앞으로의 개발, 특히 2.0이 기대됨. 이제 Responses API가 네이티브로 들어갔다면 꼭 확인해볼 생각임

Claude만 바라보는 무언가를 만들고 있고, Anthropic 생태계를 벗어날 계획은 없음. 이런 경우에도 RubyLLM이 Anthropic의 Ruby SDK를 직접 쓰는 것보다 이점이 있는지 궁금함
다르게 말하면 이 선택이 Fog와 aws-sdk-s3 사이의 선택에 가까운지, 아니면 Active Storage와 aws-sdk-s3 사이의 선택에 가까운지 궁금함

Active Storage와 aws-sdk-s3의 관계에 더 가깝다고 봄
RubyLLM에서 좋은 점은 ActiveRecord처럼 메서드를 체이닝할 수 있는 DSL, 에이전트·도구·프롬프트를 정리하는 구조, Anthropic에서 DeepSeek으로 쉽게 테스트하고 옮겨 비용을 90% 넘게 줄일 수 있었던 이식성임 bin/rails generate ruby_llm:install만으로 각 채팅을 데이터베이스에 저장할 수 있는 ActiveRecord 통합도 좋음. 저장된 채팅 이력을 주기적으로 내려받아 claude code에 주고 에이전트 지시문을 다듬게 하는 것도 큰 도움이 됐음

나중에 어떤 제공자든 선택할 수 있는 도구가 있는데 굳이 한 제공자에 종속되도록 만들 이유가 있나 싶음
장애 대응만 봐도, 꼭 서비스가 필요한 날 Anthropic API가 내려가면 어떻게 할 건지 생각해야 함

RubyLLM을 프로덕션에서도 쓰고 있는데, 지금까지 본 이 분야 라이브러리 중 가장 우아한 라이브러리임
이슈 트래커 운영 방식도 좋았음. “Feature Request”를 선택하면 우회 방법을 어떻게 찾아봤는지, 왜 RubyLLM에 들어가야 한다고 보는지 등을 설명하게 해서 범위가 끝없이 커지는 걸 막음