RAG 실전 ① — 아키텍처, 그리고 "언제 RAG인가"

새 시리즈다. 이전에 RAG의 평가(LLM 평가 방법론 ⑨편)를 다뤘다면, 이번엔 구축 실전 — 파싱부터 청킹, 임베딩, 벡터 DB, 검색 품질, 생성, 운영까지 구체적인 설정값과 비용, 실패담으로 11편이다.

파이프라인은 2020년부터 그대로다

원조 RAG 논문(Lewis et al., NeurIPS 2020)의 뼈대 — 청크 인덱스에서 top-k 검색 후 생성 — 는 지금도 같다: ingest → parse → chunk → embed → index → retrieve → rerank → generate. 진화한 것은 각 단계의 정밀도와, 2026년의 무게중심 이동: 검색이 "고정 파이프라인의 한 단계"에서 "에이전트가 필요할 때 호출하는 도구"(agentic RAG)로 바뀌고 있다(Gao 서베이의 naive→advanced→modular 분류, Azure 공식 가이드도 2025년 말 agentic 판단 기준 편입). 단, 에이전트화는 비용·지연을 늘리므로 멀티스텝 추론·복수 소스 라우팅이 정말 필요할 때만 — ⑧편에서 자세히.

"롱컨텍스트가 RAG를 죽였다"는 데이터로 반박된다

• Self-Route (DeepMind, EMNLP 2024) — 자원이 충분하면 롱컨텍스트(LC)가 평균 성능은 이긴다. 그러나 비용이 수십 배라, 쉬운 쿼리는 RAG로 처리하고 실패 시에만 LC로 넘기는 라우팅으로 LC급 품질에 비용 39~65% 절감. 이분법이 아니라 라우팅이 답.
• OP-RAG (NVIDIA) — 검색 청크를 관련도순이 아니라 원문 등장 순서로 배치하는 것만으로, 48K 토큰이 117K 전체 컨텍스트보다 F1 13점 높았다. top-k는 클수록 좋은 게 아니라 역U자 스위트스팟이 있다.
• Context Rot (Chroma, 18개 프런티어 모델 실측) — 같은 정보라도 ~300토큰 집중 프롬프트가 ~113K 전체 프롬프트를 모든 모델에서 이겼다. 컨텍스트는 균일하게 처리되지 않는다 — 골라 넣는 것(retrieval)이 구조적으로 유리하다.

의사결정 프레임

• 지식이 크고 계속 바뀌고 출처가 중요하면 → RAG. 엔터프라이즈 채택률 51%로 지배적 패턴(Menlo 조사).
• 수십K 토큰 이하의 닫힌 코퍼스(사내 규정집, 매뉴얼)면 → 벡터 DB 없이 CAG: 전부 컨텍스트에 넣고 프롬프트 캐싱(캐시 입력 ~10% 가격) — 검색 시간 0, 생성 ~11배 단축. 더 싸고 단순하다.
• 형식·톤·도메인 어법 문제면 → 파인튜닝(채택률 9%). 단 경쟁이 아니라 보완 — Microsoft 농업 실험에서 FT +6%p 위에 RAG가 +5%p 추가.

실패는 운영 중에만 드러난다

Seven Failure Points(CAIN 2024)의 결론: "RAG 검증은 운영 중에만 가능하며, 견고함은 설계되는 게 아니라 진화한다." 7대 실패 지점(콘텐츠 부재/랭킹 누락/컨텍스트 미포함/추출 실패/형식 오류/구체성 불일치/불완전 답변)은 그대로 프로덕션 장애 triage 체크리스트다 — 사용자 불만이 오면 어느 FP인지 매핑하면 고칠 단계가 결정된다. 한국어 실전기로는 우아한형제들의 도입기가 이 판단 과정을 그대로 보여준다(교훈: "완벽함보다 검증 속도").

한 줄 요약: 화려한 에이전트보다 단순 파이프라인 + 평가 루프를 1일차부터 돌리는 팀이 이긴다. 다음 글: 그 파이프라인의 천장을 정하는 단계 — 문서 파싱.

— RAG 실전 시리즈 ① / 다음 글: 문서 파싱 — 파서가 RAG의 천장을 정한다