기업용 RAG가 프로덕션 단계에 도달하기 전 실패하는 이유

모두가 저에게 똑같은 기업용 RAG 데모를 보여줍니다. 세 가지 질문에 답하고, 깔끔해 보이죠. 사람들은 미소 짓습니다. 하지만 제가 테스트해 본 결과는 틀렸습니다.

데모는 시스템이 아닙니다. 데모는 예고편일 뿐입니다. 규제 산업(Regulated industries)을 위한 프로덕션 환경의 RAG는 완전히 다른 차원의 문제이며, 매우 까다롭습니다. 저는 제 개인 랙(Rack)에서, 실제 코퍼스(Corpora)를 사용하여, 거짓말을 하지 않는 평가 루프(Eval loops)와 함께 검색 증강 생성 (RAG)을 실행합니다. 제가 발견한 사실은 다음과 같습니다. 데모는 결코 어려운 부분이 아니었습니다.

이 글은 정확한 설정, 신화를 폭로한 실패 사례, 제가 확인한 수치, 그리고 제가 이제 어떤 기업용 RAG 제안도 신뢰하기 전에 사용하는 규칙을 보여줍니다.

올해의 용감한 결정: 완벽한 PDF 40개로 구축된 데모를 신뢰하는 것. 틀렸습니다.

프로덕션 단계의 RAG를 위한 나의 실험실 설정 (LAB SETUP)

저는 이것을 슬라이드 덱(slide deck)으로 테스트하지 않았습니다. 제 개인 장비(metal)로 직접 테스트했습니다.

구성(rig)은 다음과 같습니다. 중고 RTX 3090 두 개. 벡터 검색 (vector search)을 위한 pgvector가 포함된 Postgres. 4,000개의 지저분한 문서들. 120만 개의 청크 (chunks). 네트워크 외부로 아무것도 나가지 않도록 로컬 임베딩 모델 (local embedding model)을 사용했습니다. 그리고 제가 직접 수작업으로 라벨링한 300개의 질문-답변 쌍으로 구성된 골든 세트 (golden set)에 RAGAS 스타일의 평가 하네스 (eval harness)를 적용했습니다. 직접 말입니다. 그 과정은 정말 고통스러웠습니다.

왜 로컬인가요? 은행이 느끼는 방식 그대로 데이터 거주성 (data residency)을 체감하고 싶었기 때문입니다. 이론이 아니라, 제 실험실에서 말이죠. 데이터가 국가를 떠날 수 없다는 규칙이 적용될 때, 여러분의 클라우드 벤더 데모는 갑자기 쓸모없게 됩니다. 그들은 플러그 앤 플레이 (plug-and-play)라고 말했지만, 제 네트워크 규칙은 거부했습니다.

솔직히 말해서, 이 설정은 지루합니다. 지루함이 핵심입니다. 지루한 것이 살아남습니다. 실험실에서 검증된 (LAB-PROVEN) 방식입니다.

검색 (RETRIEVAL)은 거짓말을 했고 로그는 상관하지 않았다

모델이 먼저 환각 (hallucinate)을 일으킨 것이 아닙니다. 검색 (retrieval)이 먼저 거짓말을 했습니다.

증거를 보십시오. 저의 충실도 점수 (faithfulness score)는 매우 훌륭해 보였습니다. 0.91. 대시보드는 초록색이었습니다. 거의 배포할 뻔했습니다. 그러다 문맥 재현율 (context recall)을 확인했습니다. 0.58이었습니다. 답변에 필요한 사실 중 3분의 2 미만이 검색된 청크 (retrieved chunks)에 실제로 나타났습니다.

다시 읽어보십시오. 답변은 근거가 있는 것처럼 들렸습니다. 하지만 그것은 '잘못된' 문맥에 근거한 것이었습니다. 청커 (chunker)가 핵심 조항을 두 개의 청크로 나누어 버리는 바람에, 사용자가 필요로 했던 정책 버전이 프롬프트 (prompt)에 포함되지 못했습니다. 모델은 쓰레기에 충실했습니다. 충실했습니다. 쓰레기에 말이죠.

이것이 바로 데모 시어터 (Demo Theater)가 절대 보여주지 않는 부분입니다. 연구자들은 동일한 함정을 측정했습니다. 검색 (retrieval) 단계가 생성기 (generator)를 오도하기 때문에, 충실도 (faithfulness)는 높게 유지되는 반면 의사결정 품질은 조용히 부패합니다 (Deepchecks, 2026). 미세한 RAG 진단 결과, 강력한 스택을 사용하더라도 실제 환각 (hallucination) 비율은 높은 한 자릿수 수치로 나타났으며, 더 많은 청크 (chunks)를 밀어 넣을수록 노이즈 민감도가 상승합니다 (RagChecker, 2024). 더 많은 컨텍스트 (context)는 더 많은 노이즈를 의미합니다. 결코 공짜가 아닙니다.

대시보드는 "정상"이라고 말했습니다. 로그는 "문제가 있다"라고 말했습니다. 나는 대시보드를 믿었습니다. 그것이 재앙에 기여한 나의 역할이었습니다. 망가졌습니다 (BROKEN).

규제 산업: 거버넌스가 파일럿 프로젝트를 망치는 곳

거버넌스 (GOVERNANCE)는 서류 작업이 아닙니다. 거버넌스는 관문입니다.

상황은 이렇습니다. 규제 산업에서는 모델이 정답을 맞히는 것만으로는 충분하지 않습니다. 그것이 정답이었다는 것을 증명해야 합니다. 감사 추적 (audit trail)이 필요합니다. 지정된 책임자가 필요합니다. 규제 기관에 어떤 소스 문장이 어떤 답변을 생성했는지 보여주어야 합니다. 데모 시어터 (Demo Theater)는 결코 그런 것을 구축하지 않습니다. 락인 시어터 (Lock-In Theater)는 상황을 더 악화시킵니다.

락인 시어터 (Lock-In Theater)는 나의 지원 측면에서의 적입니다. 그것은 "그저 우리의 관리형 스택 (managed stack)을 사용하세요"라고 속삭입니다. 그러고 나면 당신의 데이터는 국외로 유출되고, 비용은 급증하며, 다음 모델이 승리했을 때 모델을 교체할 수 없게 됩니다. 청구서가 도착하기 전까지는 아무도 이에 대해 이야기하지 않습니다. 2026년의 한 벤치마크에 따르면, 기업의 51%가 벤더 락인 (vendor lock-in), 예상치 못한 비용, 또는 품질 문제로 인해 현재 AI 역량을 자체적으로 재구축하고 있습니다 (State of Enterprise AI 2026). 모델 불가지론 (Model-agnostic)은 사치가 아닙니다. 그것은 생존입니다.

그리고 거버넌스(Governance)에 대한 실태는 참혹합니다. Gartner에 따르면 성숙한 AI 거버넌스를 갖춘 기업은 단 9%에 불과합니다. 2025년 EY 설문조사에 따르면, 기업의 99%가 AI 리스크 사고와 관련된 재정적 손실을 보고했으며, 기업당 평균 손실액은 440만 달러에 달했습니다 (NSSG, 2025). EU AI 법(EU AI Act)의 집행 권한은 2026년 8월에 활성화됩니다. 이것은 언젠가 일어날 일이 아닙니다. 확정된 날짜입니다.

최악의 아이디어 명예의 전당: 감사 추적(Audit trail)도 없이 은행에 제품을 출시하고, 규제 기관이 분위기(Vibes)를 좋게 봐주길 바라는 것. 한심합니다.

살아남은 규칙: 평가(EVAL), 가드레일(GUARDRAILS), 인간 참여(HUMAN-IN-THE-LOOP)

평가가 없으면 출시도 없습니다. 이것이 규칙의 전부입니다.

그렇다면 시련 속에서 무엇이 살아남았을까요? 네 가지입니다. 지루하지만 강력한 것들입니다.

첫째, 모든 변경 사항에 대해 실행되는 골든 세트(Golden set) 기반의 평가 루프(Eval loops)입니다. 한 번이 아니라 매번 실행되어야 합니다. 청킹(Chunking) 방식을 수정한 후 재현율(Recall)이 떨어졌을 때, 사용자가 발견하기 전에 평가(Eval)가 이를 잡아냈습니다. 이것이 승패를 결정짓는 핵심입니다.

둘째, 기권(Abstention) 기능이 포함된 가드레일(Guardrails)입니다. 검색(Retrieval) 신뢰도가 낮다면, 시스템은 확신에 찬 거짓말을 지어내는 대신 "모릅니다"라고 말해야 합니다. 검색 결과가 비어 있다면 허구가 아닌 침묵을 유도해야 합니다. 저를 믿으세요. 언제 입을 다물어야 할지 아는 시스템이 항상 대답하는 시스템보다 훨씬 가치 있습니다.

셋째, 관찰 가능성(Observability)입니다. 검색(Retrieval), 재순위화(Reranking), 생성(Generation) 단계에 대해 규제 기관이 읽을 수 있는 감사 추적(Audit trail)과 연결된 스팬(Span) 수준의 트레이싱(Tracing)이 필요합니다. 볼 수 없는 것은 고칠 수 없습니다. 추적할 수 없는 것은 방어할 수 없습니다.

넷째, 고위험 결정에 대한 인간 참여(Human-in-the-loop)입니다. 비상용 밸브로서가 아니라, 하나의 기능(Feature)으로서 말입니다. 인간은 답변이 고객에게 닿기 전 마지막 관문입니다. 그리고 맞습니다, 바로 이 지점에서 에이전틱 RAG(Agentic RAG)가 위험해집니다. 왜냐하면 그 관문 없이 행동하는 에이전트는 당신이 실수를 바로잡기도 전에 실수를 더 빠르게 확산시키기 때문입니다. 이것이 저의 다음 글 주제입니다.

모델이 중요하지 않다는 말이 아닙니다. 모델은 쉬운 20%에 불과하다는 뜻입니다. 평가 루프 (eval loop), 가드레일 (guardrails), 감사 추적 (audit trail), 그리고 사람이 실제 배포(ship)를 결정짓는 80%입니다. 평가(Eval) 없이는 배포(Ship)도 없습니다.

복구(restore)할 수 없는 백업은 백업이 아닙니다. 평가 (eval) 없는 RAG는 시스템이 아닙니다. 그것은 조명만 좋은 데모일 뿐입니다. 생존 완료.

기업용 RAG에 대한 판결

여기 최종 판결이 있습니다. 이것은 확정적입니다.

기업용 RAG가 실패하는 이유는 모델이 약해서가 아닙니다. 데모가 어려운 부분들을 숨겼기 때문에 실패하는 것입니다. 검색 (Retrieval)은 거짓을 말했습니다. 거버넌스 (Governance)에는 관문이 없었습니다. 데이터 레지던시 (Data residency)에는 계획이 없었습니다. 평가 루프 (eval loop)는 존재하지 않았습니다. 데모 시어터 (Demo Theater)가 예고편을 팔았다면, 실험실은 영화를 상영했습니다. 그리고 그 영화는 엉망이었습니다.

깨끗한 데모가 곧 프로덕션에 가까워졌음을 의미한다는 가정은 이제 고이 잠드십시오.
사망 원인: 데모 시어터 (Demo Theater).
생존자: 나의 로그, 나의 평가 하네스 (eval harness), 그리고 실제로 작동하는 슬로건.

그렇다면 오늘 밤 무엇을 해야 할까요? 준비도 점수판 (readiness scoreboard)을 돌리십시오. 충실도 (faithfulness)뿐만 아니라 컨텍스트 재현율 (context recall)을 확인하십시오. 규제 기관이 요구하기 전에 감사 추적 (audit trail)을 구축하십시오. 시스템을 중단시킬 수 있는 사람을 지정하십시오. 그리고 평가 루프 (eval loop)가 데모 데이터가 아닌 실제 데이터에서 통과(green)될 때까지는, 규제 대상 환경에 검색 증강 생성 (RAG)을 배포하지 마십시오.

기업용 RAG는 실재하며, 작동합니다. 하지만 지루하고, 추하고, 실제적인 테스트를 견뎌낼 때만 작동합니다. 데모가 아니라 검색 (retrieval)을 믿으십시오. 평가 (Eval) 없이는 배포 (Ship)도 없습니다.

규제 대상 환경에 배포하려고 시도했을 때, 어떤 기업용 RAG 조언이 가장 먼저 무너졌나요? 여러분의 실패 사례를 들려주세요. 증거(receipt)를 원합니다.

출처: Enterprise RAG