두 RAG 시스템은 사용자 문서를 업로드하면 시스템이 임베딩 및 저장하고, 질의 시 가장 관련성 높은 콘텐츠를 검색하여 LLM(대규모 언어 모델)이 답변을 생성하는 동일한 기능을 수행합니다. 기술 스택은 FastAPI 버전의 경우 FastAPI, Celery, SQLAlchemy를 사용했고, Rails 버전은 Rails API, React 프론트엔드, Sidekiq, ActiveRecord를 활용했습니다. OpenAI API와 pgvector는 두 버전 모두 동일하게 사용되었으며, AI 로직 자체는 동일했습니다. 아키텍처 역시 문서 업로드부터 텍스트 추출, 청킹, 임베딩 생성(OpenAI), 벡터 저장(Postgres with pgvector), 질문 처리(질문 임베딩, 유사 청크 검색, GPT-4로 답변 생성)까지 동일한 흐름을 따랐습니다. 그러나 개발 과정에서 다음과 같은 차이가 드러났습니다.
FastAPI 버전의 개발 어려움
-
백그라운드 작업: Celery 설정 및 디버깅에 많은 시간을 할애했으며, API 타임아웃, 속도 제한 등으로 인한 실패 작업의 재시도 로직을 수동으로 구현해야 했습니다.
-
데이터베이스 세션 관리: 비동기 엔드포인트마다 세션 관리에 주의를 기울여야 했고, 세션 누수나 연결 풀 문제로 인해 테스트가 불규정하게 실패하는 경우가 발생했습니다.
-
배포의 취약성: 비동기 워커, 작업 큐, 재시도 정책, 모니터링 대시보드, 데이터베이스 연결 풀 등을 수동으로 구성해야 했습니다.
Rails 버전의 개발 효율성
-
백그라운드 작업: Sidekiq을 통해 웹 UI, 자동 재시도, 데드 잡 큐, 성능 지표, 원클릭 작업 재시도 등 완벽하게 갖춰진 기능을 즉시 활용할 수 있었습니다.
-
데이터베이스 접근: ActiveRecord가 세션 관리를 자동으로 처리하여 개발자는 데이터베이스 세션에 대해 전혀 고민할 필요 없이 비즈니스 로직에 집중할 수 있었습니다.
-
디버깅 용이성: Sidekiq UI에서 실패한 작업을 확인하고 재시도하거나, Rails 콘솔을 통해 실시간 데이터 및 작업을 디버깅하는 것이 매우 직관적이었습니다.
-
풍부한 생태계:
ruby-openaigem,neighborgem, Postgres의pgvector확장 등 필요한 도구들이 Rails 생태계 내에서 잘 통합되어 있어 호환성 문제가 없었습니다. -
통합된 개발자 워크플로우: 강력한 Rails 콘솔, 간단하고 버전 관리되는 데이터베이스 마이그레이션, 예측 가능한 테스트 환경 등 통합된 개발 환경이 빠른 피드백 루프를 제공하여 개발 속도를 극대화했습니다.
결론적으로, AI 프리미티브 자체는 프레임워크에 독립적이며, Rails는 AI 모델을 더 똑똑하게 만들지는 않지만, 시스템을 이해하고 운영하며 변경하기 쉽게 만들어 제품 엔지니어의 생산성을 크게 향상시켰습니다.