RAG는 모델만 붙인다고 끝나지 않습니다. 실제 운영에서는 ingestion, chunking, embedding, retrieval, reranking, evaluation, monitoring이 모두 연결돼 있어야 합니다.
이 글은 배포 전에 확인해야 하는 운영 체크리스트를 중심으로, 어떤 항목을 빠뜨리면 실패하는지 정리한 문서입니다.
개요 #
RAG 운영 체크리스트는 “정확히 답하는가"만 보는 문서가 아닙니다. 검색 품질, 응답 품질, 비용, 지연 시간, 실패 복구까지 함께 봐야 합니다.
운영 전에 최소한 아래 네 축은 분리해서 확인해야 합니다.
- 문서가 제대로 들어오는가
- 검색이 예상한 문서를 찾는가
- 답변이 문서 근거를 유지하는가
- 문제를 추적하고 복구할 수 있는가
왜 중요한가 #
RAG가 실패하는 가장 흔한 이유는 모델 성능이 아니라 운영 누락입니다.
- 최신 문서가 안 들어온다
- chunk가 너무 크거나 작다
- embedding과 retrieval이 따로 논다
- reranking 이후 품질이 떨어진다
- trace가 없어 원인을 못 찾는다
이런 문제는 배포 후에 발견하면 비용이 커집니다. 그래서 체크리스트가 필요합니다.
운영 포인트 #
운영 체크리스트는 다음 단계별로 나누는 것이 좋습니다.
- Ingestion: 문서 형식, 갱신 주기, 실패 재시도
- Chunking: 크기, overlap, 문서 타입별 규칙
- Retrieval: hybrid search, filter, top-k 설정
- Generation: groundedness, citation, fallback
- Evaluation: offline dataset, regression test
- Monitoring: latency, cost, query failure, trace
RAG 검색 계층은 Hybrid Search와 Retrieval Quality Metrics를 같이 봐야 안정적입니다. 운영 전체는 RAG Ops를 기준으로 잡으면 정리하기 쉽습니다.
아키텍처 도식 #
운영 아키텍처는 보통 다음 순서로 봅니다.
- 문서 수집
- 전처리와 chunking
- 벡터화와 인덱싱
- 검색과 reranking
- 답변 생성
- 평가와 모니터링
이 흐름이 끊기는 지점을 먼저 찾으면, 장애와 품질 저하를 빠르게 분리할 수 있습니다.
체크리스트 #
- 문서 소스별 갱신 주기가 정의돼 있는가
- chunk 규칙이 문서 타입별로 분리돼 있는가
- top-k와 reranking 조합이 검증됐는가
- 실패 시 fallback 경로가 있는가
- trace와 로그로 query 단위 추적이 가능한가
- evaluation dataset이 실제 질의 분포를 반영하는가
- 배포 후 회귀 테스트가 자동으로 도는가
- 비용과 latency를 주간 단위로 보는가
결론 #
RAG 운영 체크리스트는 “기능 확인"이 아니라 “서비스 생존 조건"입니다. 검색, 생성, 평가, 모니터링을 따로 보지 말고 하나의 운영 체계로 묶어야 합니다.
운영의 출발점은 단순합니다. 문서가 최신인지, 검색이 맞는지, 답변이 근거를 유지하는지, 문제가 생기면 추적 가능한지부터 확인하면 됩니다.