LLM System Lab

문제 정의

"RAG 프로토타입은 1주일이면 만들 수 있지만, 프로덕션에서 안정적으로 운영하려면 6개월이 걸린다."

많은 팀이 RAG 프로토타입을 빠르게 구축하지만, 실제 서비스에 투입하면 품질 불안정, 비용 폭증, 모니터링 부재 등의 문제에 직면한다. 이 사례는 프로토타입에서 프로덕션으로 전환하는 과정에서 겪은 교훈을 정리한다.

프로토타입 vs 프로덕션의 차이

영역	프로토타입	프로덕션
데이터	100개 문서	10만+ 문서
트래픽	개발자 5명	일 1,000+ 요청
품질	"대체로 괜찮음"	SLA 99.5%
비용	월 $50	월 $5,000 예산 제한
모니터링	로그 파일	실시간 대시보드
장애 대응	재시작	자동 복구 + 알림

시스템 구조

┌─────────── Ingestion Pipeline ───────────┐
│                                          │
│  Document Sources → ETL → Chunking →     │
│  Embedding → Vector DB + Metadata Store  │
│                                          │
│  [Scheduler: 매 6시간 / Webhook 실시간]   │
└──────────────────────────────────────────┘

┌─────────── Query Pipeline ───────────────┐
│                                          │
│  User Query                              │
│    → Query Router (단순/복잡 분류)         │
│    → Query Rewriting (의도 명확화)         │
│    → Hybrid Search (Dense + BM25)         │
│    → Reranker                             │
│    → Context Selection (Top-3)            │
│    → Prompt Builder                       │
│    → LLM Inference                        │
│    → Response + Citation                  │
│                                          │
│  [Cache Layer: Redis, TTL 24h]            │
└──────────────────────────────────────────┘

┌─────────── Observability Layer ──────────┐
│                                          │
│  Request Logging → Quality Evaluation →  │
│  Cost Tracking → Alert → Dashboard       │
│                                          │
└──────────────────────────────────────────┘

핵심 기술 선택 이유

Query Router

모든 질문에 동일한 파이프라인을 적용하면 비효율적이다. 단순 질문("회의실 예약 방법")은 가벼운 검색으로, 복잡한 질문("분기별 매출 추이 분석")은 풀 파이프라인으로 라우팅한다.

단순 질문 (60%): Embedding Search + GPT-4o-mini → 레이턴시 1초, 비용 $0.001
복잡 질문 (40%): Hybrid Search + Reranker + GPT-4o → 레이턴시 3초, 비용 $0.01

Hybrid Search

Dense Retrieval만으로는 고유명사, 코드명, 약어 검색에 취약했다.

Dense (Embedding): 의미 기반 검색
Sparse (BM25): 키워드 정확 매칭
결합 비율: Dense 0.7 + Sparse 0.3 (실험으로 최적화)

캐싱 전략

동일 질문이 반복되는 패턴을 발견 (전체 트래픽의 30%가 중복 질문).

Redis 기반 의미 캐싱: 쿼리 Embedding의 유사도 0.95 이상이면 캐시 히트
TTL 24시간: 문서 업데이트 주기 고려
캐시 적중률: 약 25%, 비용 절감 효과 큼

운영 시 발생한 이슈

1. 인덱싱 파이프라인 장애

문서 수가 10만 개를 넘어가면서 전체 재인덱싱에 8시간 소요. 인덱싱 중 검색 서비스 품질 저하.

해결:

증분 인덱싱 도입 (변경된 문서만 처리)
Blue-Green 인덱스 전략 (새 인덱스 구축 완료 후 전환)
인덱싱 파이프라인 모니터링 (실패한 문서 추적, 재시도 큐)

2. 응답 품질 편차

같은 질문에도 컨텍스트 선택에 따라 답변 품질이 크게 달라지는 문제.

해결:

LLM-as-Judge 자동 평가: Faithfulness, Relevance, Completeness 3개 축 평가
품질 점수 3.0 미만 응답 자동 플래깅
주간 품질 리포트 생성 (저품질 패턴 분석)

3. 비용 관리

초기 예산 $1,000/월 → 실제 $4,500/월 발생.

해결 전략:

최적화	절감 효과
Query Router (단순 질문은 mini 모델)	-35%
의미 캐싱	-25%
Prompt 최적화 (불필요한 컨텍스트 제거)	-15%
배치 Embedding (실시간→배치)	-10%
총 절감	약 60%

4. 레이턴시 관리

P95 레이턴시가 8초를 넘어가면서 사용자 이탈 증가.

해결:

스트리밍 응답 도입 (첫 토큰까지 1.5초)
Reranker 타임아웃 설정 (500ms 초과 시 Skip)
프리페치: 사용자 입력 중 쿼리 Embedding 미리 계산

모니터링 대시보드 구성

┌─────────────────────────────────────┐
│  RAG System Dashboard               │
├─────────────────────────────────────┤
│  [요청량]     [P95 레이턴시]         │
│   1,200/day    3.2s                 │
│                                     │
│  [품질 점수]  [캐시 적중률]          │
│   4.2/5.0     25%                   │
│                                     │
│  [일일 비용]  [Embedding 소진량]     │
│   $120        85,000 tokens         │
│                                     │
│  [검색 정밀도] [할루시네이션 비율]    │
│   82%          3.5%                 │
└─────────────────────────────────────┘

핵심 지표:

Retrieval Precision@5: 상위 5개 검색 결과 중 관련 문서 비율
Faithfulness: 응답이 검색된 문서에 근거하는 비율
Hallucination Rate: 출처 없는 정보를 생성한 비율
Cost per Query: 쿼리당 평균 비용
P95 Latency: 95번째 백분위 응답 시간

개선 포인트

Evaluation Pipeline 자동화: 매일 자동으로 샘플 평가 실행
A/B 테스트 인프라: 새로운 Chunking 전략, Embedding 모델을 안전하게 실험
Multi-turn 대화 지원: 이전 질문 맥락을 유지하는 대화형 인터페이스
문서 권한 관리: 사용자별 접근 가능한 문서만 검색

핵심 교훈

프로토타입 ≠ 프로덕션: 프로토타입에서 작동하는 것이 프로덕션에서도 작동한다는 보장은 없다
모니터링이 먼저다: 모니터링 없이 배포하면 문제를 인지하기까지 수일이 걸린다
비용은 설계의 일부다: 비용을 나중에 최적화하려면 아키텍처를 바꿔야 할 수 있다. 초기부터 고려하라
품질 측정을 자동화하라: 수동 평가는 확장되지 않는다. LLM-as-Judge로 자동화하라
점진적 개선: 모든 것을 한 번에 최적화하지 말고, 가장 큰 병목부터 해결하라

운영 가능한 RAG 시스템