스프레드시트 기반 관리의 한계와 문제점
많은 개발 팀이 초기에는 스프레드시트를 사용하여 프롬프트와 모델 구성을 추적합니다. 하지만 프로젝트 규모가 커짐에 따라 다음과 같은 심각한 문제들이 발생합니다.
- 데이터 파편화: 여러 사용자가 복사본을 만들면서 ‘단일 진실 공급원(Single Source of Truth)’이 사라지고 협업이 어려워집니다.
- 구조적 강제성 부재: 기능마다 포맷이 달라져 지표를 일관되게 비교하기 어렵고, 새로운 기능을 추가할 때마다 형식을 재설계해야 합니다.
- 코드와의 단절: 스프레드시트에서 수정된 프롬프트가 실제 소스 코드에 반영되지 않아 발생하는 ‘프롬프트 드리프트(Prompt Drift)’ 현상이 빈번해집니다.
- 회귀 테스트의 어려움: 새로운 모델이나 프롬프트를 도입했을 때 기존 성능을 유지하는지 판단할 기준점이 모호하여 배포에 대한 불확실성이 커집니다.
RubyLLM::Evals: Rails를 위한 프롬프트 평가 엔진
SINAPTIA에서 개발한 RubyLLM::Evals는 Rails 엔진 형태로 제공되어 애플리케이션 내부에서 직접 프롬프트를 테스트하고 개선할 수 있도록 설계되었습니다. 이 도구의 핵심 추상화 개념은 다음과 같습니다.
- Prompts (프롬프트): 모델 제공자, 모델명, 시스템 지침, Liquid 변수가 포함된 메시지 템플릿, 도구(Tools), 출력 스키마 등 전체 구성을 캡슐화합니다. 기존 앱의 스키마를 재사용할 수 있는 유연성을 제공합니다.
- Samples (샘플): 테스트 케이스를 정의하며, 평가 유형(정확히 일치, 포함 여부, 정규 표현식, LLM 판정, 인간 판정)과 예상 결과값을 포함합니다.
특히 LLM-as-judge를 일급 시민(First-class) 평가 유형으로 채택한 점이 특징입니다. 요약이나 모호한 경계의 분류 작업에서는 단순 문자열 비교가 어렵기 때문에, 다른 LLM 모델을 활용해 응답의 적절성을 평가함으로써 빠른 피드백 루프를 형성합니다. 이는 완벽하지는 않지만 반복적인 개발 과정에서 실용적인 대안이 됩니다.
실제 운영 데이터 활용 및 워크플로우
RubyLLM::Evals의 가장 큰 장점 중 하나는 Rails의 ActiveRecord 모델과 직접 연결하여 실제 운영 데이터를 테스트 샘플로 즉시 변환할 수 있다는 점입니다.
- 실제 데이터 기반 테스트: 합성 데이터(Synthetic Data)가 아닌, 실제 운영 중인 이미지나 텍스트 데이터를 ActiveRecord를 통해 가져와 샘플로 등록하고 이를 바탕으로 프롬프트를 최적화할 수 있습니다.
- 큐레이션 전략: 수백 개의 무작위 샘플보다는 엣지 케이스와 일반적인 케이스가 혼합된 20~30개의 정밀한 샘플 세트가 초기 개발 속도를 높이는 데 효과적입니다. 성능이 안정화되면 점진적으로 샘플을 확장합니다.
- 버전 관리 및 배포: 최적화된 프롬프트 구성은 데이터베이스에 저장되며, 애플리케이션 코드 내에서 슬러그(Slug)를 통해 즉시 호출할 수 있습니다. 이는 A/B 테스트나 이전 버전으로의 롤백을 매우 간편하게 만듭니다.
지속적인 모니터링과 프롬프트의 생명주기
프롬프트는 한 번 작성하고 끝나는 정적인 코드가 아닙니다. 모델 제공자가 예고 없이 모델을 업데이트하거나, 사용자 데이터의 분포가 변하면 성능이 저하되거나 비용이 급증할 수 있습니다.
따라서 RubyLLM::Monitoring과 연계하여 운영 환경에서의 정확도와 비용을 지속적으로 추적하는 것이 중요합니다. 성능 저하가 감지되면 해당 사례를 새로운 샘플로 추출하여 평가 세트에 추가하고, 다시 프롬프트를 조정하는 선순환 구조를 구축해야 합니다. 이러한 ‘지속적 테스트’ 문화는 AI 기능을 프로덕션 수준으로 유지하는 데 필수적입니다.