왜 당신의 RAG는 실패하는가 - 온톨로지, 지식 그래프, 그리고 제대로 된 아키텍처의 조건

소규모 기업을 위한 제대로 된 RAG 시스템 [1/4]

"벡터DB에 문서를 잘라서 넣고, 사용자 질문으로 유사한 청크를 검색하고, 그걸 프롬프트에 붙여서 LLM에 보냅니다. 이렇게 만들었는데 왜 결과가 형편없는 겁니까?"

최근 개발자 커뮤니티에서 이런 질문이 부쩍 늘었습니다. 질문한 사람의 상황은 대부분 비슷합니다. OpenAI API와 벡터DB를 연결해서 사내 문서 검색 시스템을 만들었는데, 처음 몇 개 문서로 테스트할 때는 괜찮았습니다. 문서가 수백, 수천 개로 늘어나자 답변 품질이 급격히 나빠졌습니다. 엉뚱한 문서를 가져오고, 맥락이 잘려서 이상한 답변을 만들어내고, 심지어 존재하지 않는 내용을 자신있게 답하기도 합니다.

27년 동안 IT 업계에서 일하면서 비슷한 패턴을 여러 번 봤습니다. 새로운 기술이 나오면 "Hello World" 수준의 데모가 폭발적으로 퍼지고, 그걸 보고 프로덕션에 적용했다가 벽에 부딪히는 패턴입니다. RAG도 그렇습니다. 튜토리얼에서 보여주는 "기본 RAG"는 프로덕션에서 거의 살아남지 못합니다. Python 기술 블로그 Plain English는 여러 기업 사례를 종합해 RAG 구현의 70%가 프로덕션에서 실패한다고 주장합니다. 이 수치의 정확한 표본과 방법론이 공개되어 있지는 않지만, Gartner가 2025년에 발표한 보고서에서도 AI 프로젝트의 프로덕션 전환율이 30% 미만이라고 밝힌 것과 방향은 일치합니다.

이 글은 소규모 기업이 사내 문서 검색, 고객 지원, 지식 관리를 위해 "제대로 된" RAG 시스템을 구축하기 위한 아키텍처 시리즈의 첫 번째 편입니다. 이론 소개가 아니라, DoorDash, LinkedIn, Royal Bank of Canada 같은 곳에서 실제로 작동하고 있는 아키텍처를 분석하고, 그걸 소규모 기업의 예산과 인력으로 구현할 수 있는 형태로 재설계합니다. 최종 목표는 이 시스템을 MCP 서버로 만들어서 Claude가 회사의 지식을 직접 활용하게 하는 것입니다.

먼저, 당신의 RAG가 왜 실패하는지부터 정확히 짚겠습니다.

기본 RAG는 왜 실패하는가

기본 RAG의 구조는 단순합니다. 문서를 일정 크기로 자르고, 각 조각을 임베딩 벡터로 변환해서 벡터DB에 저장하는 거죠. 사용자가 질문하면 질문도 벡터로 변환하고, 벡터DB에서 가장 유사한 청크 몇 개를 가져와서 LLM에 프롬프트와 함께 보냅니다. LLM이 그 컨텍스트를 보고 답변을 만들어냅니다.

이 구조가 데모에서는 작동합니다. 문서가 10~20개이고, 질문이 간단한 팩트 조회일 때는 꽤 괜찮습니다. 문제는 이 구조의 취약점이 근본적이라서, 데이터가 조금만 많아져도 급격히 무너진다는 겁니다.

왜 실패하는지, 메커니즘을 하나씩 짚어보겠습니다.

다음 그림은 기본 RAG 파이프라인의 각 단계와 실패가 발생하는 지점을 보여줍니다.

문서를 고정 크기로 잘라 벡터로 변환하고 유사도 검색으로 가져오는 단순한 파이프라인에서, 청킹 시 문맥 손실, 의미적 검색만의 한계, 데이터 증가에 따른 검색 품질 저하, 잘못된 컨텍스트로 인한 환각, 오래된 데이터 문제가 동시에 작용합니다.

첫째, 청킹 과정에서 이미 정보가 손실됩니다. 문서를 500자, 1000자 단위로 기계적으로 자르면 문맥이 잘립니다. "3분기 매출은 전년 대비 15% 증가했습니다"라는 문장이 "3분기 매출은 전년 대비"와 "15% 증가했습니다"로 나뉘면, 각각은 의미가 없습니다. CDC 정책 문서를 대상으로 한 2025년 연구에서 단순 고정 크기 청킹은 faithfulness(충실도) 점수 0.47~0.51을 기록했습니다. 절반도 안 되는 정확도입니다. 같은 문서에 시맨틱 청킹을 적용하자 0.79~0.82로 올랐습니다. RAG 실패의 80%가 청킹 결정에서 비롯된다는 분석이 있을 정도입니다.

둘째, 벡터 검색은 "의미적 유사성"만 봅니다. 사용자가 "2025년 3분기 매출"을 물었을 때, 벡터 검색은 "매출"이라는 의미와 유사한 모든 청크를 가져옵니다. 2024년 매출, 2023년 매출, 이익률, 비용 구조까지 비슷한 벡터 공간에 있기 때문에 전부 검색됩니다. 정작 "2025년 3분기"라는 정확한 조건은 벡터 유사도에서 제대로 반영되지 않습니다. 키워드 매칭이 필요한 상황에서 벡터 검색만 쓰는 것은, 그물을 던져서 특정 물고기 한 마리를 잡으려는 것과 같습니다.

셋째, 데이터가 늘어나면 검색 품질이 조용히 하락합니다. AI Accelerator Institute의 분석에서 "Retrieval Decay"라고 부르는 현상입니다. PoC에서 잘 작동하던 시스템이 50배 큰 코퍼스로 확장되면, ANN(Approximate Nearest Neighbor) recall이 0.95에서 0.71로 떨어집니다. 문제는 이 하락이 에러 메시지 없이 조용히 진행된다는 점입니다. 시스템은 여전히 답변을 생성합니다. 단지 틀린 답변을 자신있게 말할 뿐입니다. 이를 탐지하려면 정기적인 품질 평가가 필요합니다. 3편에서 RAGAS 프레임워크를 이용해 검색 품질을 모니터링하고 하락을 조기에 감지하는 방법을 다룹니다.

넷째, 과도한 컨텍스트가 LLM을 혼란시킵니다. 관련 없는 청크가 프롬프트에 포함되면 LLM은 그 정보를 "제공된 것이니 관련이 있을 것"이라고 판단하고 답변에 활용합니다. 이것이 RAG 환경에서의 할루시네이션입니다. LLM 자체의 문제가 아니라, 잘못된 컨텍스트를 건네준 검색 시스템이 원인이죠.

다섯째, 지식이 변경되는데 시스템은 과거에 머물러 있습니다. Mastercard의 RAG 시스템 사례를 보면, 데이터베이스 구조가 변경된 후에도 시스템이 이미 존재하지 않는 테이블을 조회하는 쿼리를 생성했습니다. 문서가 업데이트되었지만 벡터DB의 임베딩은 여전히 이전 버전을 가리키고 있었기 때문입니다.

이 다섯 가지가 동시에 작용합니다. 그리고 각 단계가 95% 정확도라 해도 5단계를 거치면 전체 시스템 신뢰도는 0.95의 5승, 약 77%까지 떨어집니다. 튜토리얼에서는 절대 보여주지 않는 현실입니다.

현업에서 RAG를 운영하는 엔지니어에게 들어보면, 공통적으로 하는 말이 있습니다. "RAG 프로젝트의 60%는 RAG가 필요한 것이 아니라 더 나은 검색이 필요한 겁니다." Towards Data Science의 프로덕션 RAG 교훈 시리즈에서도 같은 결론을 내립니다. 문제는 RAG라는 개념 자체가 아니라, "기본 RAG"로 충분하다고 생각하는 것입니다.

잠깐, RAG가 아예 필요 없을 수도 있습니다

한 가지 먼저 확인하고 넘어갈 것이 있습니다. 당신의 사내 문서 규모에 따라, RAG 자체가 과도한 해법일 수 있습니다.

2025년 2월, ACM Web Conference에서 발표된 논문 "Don't Do RAG"는 Cache-Augmented Generation이라는 접근법을 제시했습니다. 관련 자료를 전부 LLM의 확장 컨텍스트에 미리 넣어두고, 검색 과정을 완전히 건너뛰는 방식입니다.

벤치마크 결과가 주목할 만합니다. 논문에서 비교 대상으로 삼은 것은 기본적인 Naive RAG 구성(고정 크기 청킹 + 단순 벡터 검색)이며, 이 조건에서 CAG는 40.5배 빠른 응답 시간(2.33초 vs 94.35초)과 80% 비용 절감을 보여줬습니다. 검색 오류가 원천적으로 발생하지 않으니 정확도도 약간 더 높습니다. 다만 이 비교는 하이브리드 검색이나 리랭킹을 적용한 Advanced RAG와의 비교가 아니므로, 최적화된 RAG 시스템과의 성능 차이는 이보다 줄어들 수 있습니다.

조건이 있습니다. 전체 문서 분량이 100만 토큰 이하이고, 업데이트 주기가 주 1회 이하일 때 CAG가 적합합니다. 100만 토큰이면 대략 A4 기준 750~1,000페이지 분량이고, 소규모 기업의 사내 규정집, 제품 매뉴얼, FAQ 정도라면 이 범위 안에 들어갈 수 있습니다.

직접 점검해보는 것이 좋겠습니다. 사내 문서를 전부 합쳤을 때 100만 토큰 이하이고, 문서가 자주 바뀌지 않는다면 RAG보다 CAG가 나은 선택입니다. Claude의 20만 토큰 컨텍스트 윈도우나 Gemini의 100만 토큰 컨텍스트 윈도우에 문서를 통째로 넣는 것만으로 충분할 수 있습니다.

이 시리즈의 나머지 내용은 "CAG로 해결이 안 되는 규모"를 전제로 합니다. 문서가 수천 개이고, 부서별로 다른 문서가 있고, 매일 업데이트되는 데이터가 있는 상황입니다. 이 경우에는 제대로 된 RAG가 필요합니다.

온톨로지, 그게 뭡니까

RAG를 검색하다 보면 "온톨로지"라는 용어를 만나게 됩니다. 철학에서 빌려온 용어라 처음 보면 거창하게 느껴지는데, 실제 의미는 단순합니다.

온톨로지는 "특정 영역의 개념과 관계를 정의한 구조"입니다. 쉽게 말해, 데이터베이스의 ERD와 비슷합니다. ERD가 테이블과 테이블 사이의 관계를 정의하듯이, 온톨로지는 개념과 개념 사이의 관계를 정의합니다. 다만 ERD와 다른 점이 하나 있습니다. 온톨로지는 추론이 가능합니다. "김철수는 A팀 소속이다"와 "A팀은 개발부 소속이다"라는 두 관계가 있으면, "김철수는 개발부 소속이다"를 자동으로 추론할 수 있습니다. ERD에서는 이런 추론을 위해 JOIN 쿼리를 직접 작성해야 하지만, 온톨로지 기반 시스템은 관계 경로를 자동으로 탐색합니다.

예를 들어 보겠습니다. "프로젝트"라는 개념이 있습니다. 프로젝트에는 "담당자"가 있고, "고객사"가 있고, "기술 스택"이 있고, "문서"가 있습니다. 담당자는 "부서"에 소속되어 있고, 고객사에는 "계약"이 있고, 기술 스택에는 "버전"이 있습니다. 이런 개념 사이의 관계 구조 전체가 온톨로지입니다.

기본 RAG가 온톨로지 없이 작동하는 방식을 보겠습니다. "프로젝트 알파의 백엔드 담당자가 누구입니까?"라는 질문이 들어옵니다. 벡터 검색은 "프로젝트 알파", "백엔드", "담당자"와 의미적으로 유사한 청크를 찾습니다. 프로젝트 알파에 대한 기획서 조각, 백엔드 기술 문서 조각, 인사 배치표 조각이 섞여서 올 수 있습니다. 이 조각들 사이의 관계를 벡터 검색은 모릅니다. "김철수"라는 이름이 프로젝트 알파의 백엔드 담당자인지, 아니면 프로젝트 베타의 프론트엔드 담당자인지, 벡터 유사도만으로는 구분이 안 됩니다.

온톨로지가 있으면 달라집니다. "프로젝트 알파 → 담당자 → 김철수(역할: 백엔드)"라는 관계가 구조화되어 있으니, 질문에 정확히 대응하는 정보를 찾을 수 있습니다. 이것이 지식 그래프의 핵심입니다.

EMNLP 2025 메인 컨퍼런스에서 발표된 OG-RAG 논문이 이걸 수치로 보여줍니다. 도메인 온톨로지를 활용해 문서를 하이퍼그래프로 표현했을 때, 일반 RAG 대비 팩트 회수가 55% 증가했고, 응답 정확도가 40% 향상되었습니다. 4개의 다른 LLM에서 모두 같은 패턴이 나타났으니 특정 모델에 의존하는 결과가 아닙니다.

Nature Scientific Reports에 게재된 KG-RAG 연구는 한 발 더 나아갑니다. 이중 채널 검색을 제안하는데, 첫 번째 채널은 기존 벡터 검색으로 비구조화된 텍스트에서 유사 청크를 찾고, 두 번째 채널은 지식 그래프에서 개념 간 관계 경로를 따라 구조적 검색을 수행합니다. 두 결과를 합치면 한쪽만 쓸 때보다 품질이 눈에 띄게 올라갑니다.

정리하면, 온톨로지는 "이 문서들 사이에 어떤 관계가 있는가"를 구조화한 것이고, 지식 그래프는 온톨로지에 따라 실제 데이터를 노드와 엣지로 연결한 것입니다. 이게 왜 중요한지, 다음 섹션에서 전체 그림을 보면서 살펴보겠습니다.

RAG 성숙도 모델 - 당신은 어디에 있고, 어디로 가야 하는가

Applied AI의 엔터프라이즈 RAG 아키텍처 가이드는 RAG 시스템을 네 단계로 분류합니다. 이 분류가 쓸모 있는 이유는, 지금 자기 시스템이 어디쯤에 있고 다음에 뭘 해야 하는지 바로 보이기 때문입니다.

다음 그림은 RAG 시스템의 4단계 성숙도 모델을 보여줍니다. 소규모 기업이라면 2단계 Advanced RAG에서 시작하는 것을 권장합니다.

아래에서 위로, Naive RAG(튜토리얼 수준)에서 Advanced RAG(프로덕션 표준), GraphRAG(복잡한 질의 처리), Agentic RAG(AI 에이전트 기반)로 올라갑니다. 각 단계를 하나씩 살펴보겠습니다.

첫 번째 단계는 Naive RAG입니다. 대부분의 튜토리얼이 보여주는 방식이고, 이 글의 첫머리에서 설명한 "기본 RAG"가 바로 이것입니다. 문서를 고정 크기로 자르고, 벡터로 변환하고, 유사도 검색으로 가져와서 LLM에 넘깁니다. Applied AI의 표현을 빌리면, "프로덕션에서 거의 살아남지 못합니다."

두 번째 단계는 Advanced RAG입니다. 이것이 프로덕션의 현실적 표준입니다. Naive RAG의 약점을 하나씩 기술로 보완하는 방식인데, 핵심이 세 가지 있습니다.

하이브리드 검색은 벡터 검색과 키워드 검색(BM25)을 동시에 실행하고 결과를 합칩니다. 벡터 검색이 "의미"를 잡고, BM25가 "정확한 단어"를 잡습니다. Reciprocal Rank Fusion이라는 알고리즘으로 두 결과를 병합합니다. 이것만으로 검색 정확도가 15~30% 향상됩니다.

리랭킹은 검색 결과를 한 번 더 정렬합니다. 검색으로 후보 20~50개를 가져온 뒤, 크로스인코더 모델이 질문과 각 청크를 쌍으로 읽어서 관련도 순으로 다시 정렬합니다. 정확도 20~35% 추가 향상을 가져오지만, 200~500ms의 추가 레이턴시가 발생합니다.

Anthropic이 2024년에 발표한 Contextual Retrieval은 청킹 단계에서 각 청크에 문맥 설명을 추가하는 기법입니다. 문서 전체와 개별 청크를 LLM에 보내서 "이 청크는 전체 문서에서 어떤 맥락에 있는가"를 50~100 토큰으로 요약해서 청크 앞에 붙입니다. Contextual Embeddings만으로 검색 실패율이 35% 줄고, BM25를 더하면 49%, 리랭킹까지 추가하면 67%까지 줄어듭니다. 이 수치는 Anthropic의 공식 문서에서 확인할 수 있습니다.

세 번째 단계는 GraphRAG입니다. 앞에서 설명한 지식 그래프가 여기에서 등장합니다. 문서에서 엔티티(사람, 프로젝트, 기술, 정책 등)를 추출하고, 엔티티 간의 관계를 그래프로 구축합니다. 검색할 때 벡터 유사도뿐 아니라 그래프의 관계 경로를 따라 정보를 찾습니다.

Microsoft의 GraphRAG는 이 접근법의 대표적 구현체입니다. 문서를 수집하고, 엔티티와 관계를 추출해서 그래프를 구축하고, 커뮤니티(밀접하게 연결된 엔티티 그룹)를 감지해서 요약 리포트를 생성합니다. "알파 프로젝트의 3분기 기술 이슈를 요약해주세요" 같은, 여러 문서에 걸쳐 있는 넓은 질문에 대해 Naive RAG보다 훨씬 정확한 답변을 생성합니다.

수치로 보면 확실합니다. 전통적 RAG 대비 검색 정밀도가 20~35% 향상되고, 특히 여러 소스를 합성해야 하는 복잡한 질문에서 차이가 두드러집니다. LinkedIn은 과거 이슈 티켓으로부터 지식 그래프를 구축해서 고객 기술 지원 시스템에 적용했고, 이슈별 중간 해결 시간이 28.6% 단축되었습니다.

다만, GraphRAG의 단점도 있습니다. 그래프 구축에 LLM 호출이 많이 필요하고, 엔티티 해상도(같은 개념이 다른 이름으로 언급된 것을 통합하는 작업)의 정확도가 85% 이하이면 전체 시스템이 불안정해집니다. 2026년 기준 실무자 가이드에서도 이 점을 강조하고 있습니다. GraphRAG를 도입하겠다면 엔티티 해상도 정확도를 먼저 확보해야 합니다.

네 번째 단계는 Agentic RAG입니다. 검색 자체를 하나의 도구로 취급하고, AI 에이전트가 질문을 분석해서 어떤 검색 전략을 쓸지 스스로 결정합니다. 예를 들어 "프로젝트 알파의 백엔드 담당자가 누구입니까?"라는 질문이 들어오면, 에이전트는 이것이 구조적 관계 질문임을 파악하고 지식 그래프를 먼저 조회합니다. "최근 3개월간 서버 장애 패턴을 분석해주세요"라는 질문에는 벡터 검색으로 관련 장애 보고서를 찾은 뒤, 시계열 데이터를 추가로 조회하고, 여러 결과를 종합하는 다단계 전략을 선택합니다. 에이전트가 "이건 단순 팩트 질문이니 벡터 검색만 하자", "이건 여러 문서를 종합해야 하니 단계적으로 검색하자"를 스스로 판단하는 것입니다. 가장 강력하지만 가장 복잡하고, 아직 프로덕션에서 안정적으로 운영되는 사례가 적습니다. 이 시리즈의 4편에서 MCP를 활용해 Claude가 검색 도구를 직접 선택하고 호출하는 Agentic RAG를 구현합니다.

소규모 기업에게 현실적으로 필요한 수준은 2단계 Advanced RAG에 3단계 GraphRAG의 핵심 요소를 선택적으로 추가하는 것입니다. 모든 것을 한 번에 구현할 필요는 없습니다. 하이브리드 검색과 리랭킹만으로도 기본 RAG 대비 체감 품질이 크게 달라집니다.

성공 사례에서 배우는 것

이론만으로는 아키텍처를 확신할 수 없습니다. 실제로 작동하고 있는 시스템에서 공통 패턴을 뽑아보겠습니다.

DoorDash는 배달원(Dasher) 지원 자동화를 위한 RAG 기반 챗봇을 운영합니다. 수십만 건의 일일 지원 요청을 2.5초 레이턴시로 처리합니다. 이 시스템의 핵심은 2단계 가드레일입니다. 첫 번째 단계에서 저비용 시맨틱 유사도로 답변을 평가하고, 이 단계를 통과하지 못하면 두 번째 단계에서 LLM이 근거성, 대화 일관성, 정책 준수를 심층 리뷰합니다. 결과는 할루시네이션 90% 감소, 심각한 규정 위반 99% 감소입니다. DoorDash가 사용하는 LLM은 Claude 3 Haiku(Amazon Bedrock)로, 가장 비싼 모델이 아닙니다.

DoorDash 시스템에서 주목할 점이 하나 더 있습니다. 캐싱입니다. 임베딩 캐시(1시간 TTL), 검색 캐시(30분 TTL), 시맨틱 응답 캐시를 운영합니다. 같은 유형의 질문이 반복되는 고객 지원 시나리오에서 이 캐싱이 비용과 레이턴시를 크게 줄여줍니다.

LinkedIn은 앞서 언급한 대로 지식 그래프를 활용했습니다. 단순히 과거 이슈 티켓을 벡터DB에 넣은 것이 아니라, 이슈 간 관계를 그래프로 구조화했습니다. "이 이슈는 저 이슈의 원인이었다", "이 해결법이 저 상황에서도 적용 가능하다" 같은 관계가 그래프에 인코딩되어 있습니다. 소비자 쿼리를 파싱하고, 지식 그래프에서 관련 서브그래프를 검색해서 맥락을 구성합니다.

Royal Bank of Canada의 Arcane 시스템은 소규모 기업에게 시사하는 바가 큽니다. 수천 명의 뱅킹 전문가가 웹 플랫폼, 독점 소스, PDF, Excel 등에 분산된 정책 문서를 검색하는 시스템입니다. 핵심 과제는 "데이터가 여기저기 흩어져 있다"는 것이었고, 이를 통합하는 데이터 수집 파이프라인이 시스템의 가장 큰 기술적 도전이었습니다. 소규모 기업도 마찬가지입니다. 사내 문서가 구글 드라이브, 노션, 위키, 공유 폴더에 흩어져 있는 것이 현실입니다.

Harvard Business School의 ChatLTV는 교육 환경에서의 RAG 사례입니다. 코스 자료(사례 연구, 노트, 서적, 블로그, Slack Q&A)를 벡터DB에 넣고 OpenAI API와 연결했습니다. Slack에 통합되어 공개/비공개 모드로 운영됩니다. 규모가 작은 편이라 비교적 단순한 아키텍처로도 작동합니다. 문서 규모가 작고 도메인이 한정된 경우에는 Advanced RAG까지 갈 필요 없이 잘 튜닝된 기본 RAG도 효과적이라는 사례입니다.

이 사례들에서 공통으로 발견되는 패턴이 있습니다.

첫째, 검색 단계에 가장 많은 투자를 합니다. LLM 선택보다 검색 품질 개선이 전체 답변 품질에 더 큰 영향을 줍니다. 둘째, 가드레일이 있습니다. 답변을 그대로 사용자에게 보내지 않고, 근거성을 검증하는 추가 단계가 있습니다. 셋째, 데이터 수집 파이프라인이 전체 프로젝트에서 가장 큰 비중을 차지합니다. Stratagem Systems의 비용 분석에 따르면 데이터 정리와 전처리가 프로젝트 비용의 30~50%를 차지합니다. 넷째, 가장 비싼 모델이 아닌, 용도에 맞는 모델을 씁니다.

이 시리즈에서 구축할 아키텍처

이제 전체 그림을 보겠습니다. 이 시리즈에서 구축할 아키텍처는 네 개의 계층으로 구성됩니다. 각 계층은 필요하면 따로 교체할 수 있게 설계합니다.

다음 그림은 4개 계층의 전체 구조와 각 편에서 다루는 범위를 보여줍니다.

맨 아래 데이터 수집 계층(2편)이 시스템 품질의 80%를 결정하고, 그 위로 인덱싱/검색 계층과 생성/검증 계층(3편), 맨 위에 MCP 서버를 통한 외부 연동 계층(4편)이 올라갑니다.

데이터 수집 계층이 맨 아래에 있습니다. 여러 소스(PDF, 워드, 노션, 구글 드라이브, 웹페이지)에서 문서를 가져오고, 전처리하고, 청킹합니다. Anthropic의 Contextual Retrieval을 적용해서 각 청크에 문맥 정보를 추가합니다. 선택적으로 지식 그래프를 구축합니다. 이 계층이 전체 시스템 품질의 80%를 결정합니다. 2편에서 상세히 다룹니다.

인덱싱과 검색 계층이 그 위에 있습니다. 벡터 인덱스(시맨틱 검색)와 키워드 인덱스(BM25)를 동시에 유지하는 하이브리드 구조입니다. 검색 결과를 크로스인코더로 리랭킹하고, 쿼리를 변환(HyDE 등)해서 검색 품질을 높입니다. 3편에서 다룹니다.

생성과 검증 계층이 있습니다. LLM이 답변을 생성하고, 가드레일 시스템이 답변의 근거성을 검증합니다. 답변에 출처를 명시하고, 확신도가 낮은 경우 사용자에게 알립니다. RAGAS 프레임워크로 시스템 전체의 품질을 정기적으로 측정합니다. 이것도 3편에서 다룹니다.

외부 연동 계층이 맨 위에 있습니다. MCP 서버로 포장해서 Claude가 이 시스템을 도구로 사용합니다. LLM 백엔드를 어댑터 패턴으로 추상화해서 OpenAI, Claude, Gemini, Ollama 중 필요에 따라 교체합니다. 4편에서 다룹니다.

기술 스택은 비용 효율을 최우선으로 선택합니다. 임베딩은 Ollama의 nomic-embed-text 또는 mxbai-embed-large를 씁니다. Ollama 공식 문서에 따르면 이 모델이 OpenAI의 text-embedding-ada-002와 text-embedding-3-small보다 성능이 우수하면서 무료입니다. 벡터DB는 pgvector(이미 PostgreSQL을 쓰고 있다면)나 ChromaDB(단독 사용 시)를 씁니다. 오케스트레이션은 LlamaIndex로 수집/인덱싱/검색을, LangChain으로 전체 플로우를 관리합니다. 평가는 RAGAS, 관측성은 Langfuse(오픈소스)를 사용합니다. 외부 연동은 FastMCP로 MCP 서버를 구축합니다.

월간 운영 비용을 추정하면, Ollama 로컬로만 운영하는 최소 구성은 기존 서버를 활용할 경우 추가 비용이 사실상 없습니다. 일반 쿼리는 Ollama로 처리하고 고품질이 필요한 쿼리만 클라우드 API로 보내는 하이브리드 구성에서, 문서 5,000건 규모에 일일 300~500건 쿼리 기준으로 월 50~120달러 정도입니다. GraphRAG를 추가하고 ArangoDB를 사용할 경우에도 벡터DB 기반 RAG 대비 50% 비용 절감이 가능합니다. Microsoft GraphRAG 팀의 ArangoDB 벤치마크에서 1만 쿼리/일 기준 연 1,825달러 대 3,650달러라는 비교 결과가 나와 있습니다.

마무리

기본 RAG가 왜 실패하는지, 온톨로지와 지식 그래프가 무엇이고 왜 필요한지, 프로덕션에서 검증된 아키텍처가 어떤 모습인지 살펴봤습니다.

핵심을 다시 짚겠습니다. 기본 RAG의 실패는 LLM 성능 문제가 아닙니다. 검색 품질 문제이고, 더 정확히는 데이터를 어떻게 준비하고 검색하느냐의 문제입니다. 가장 좋은 LLM을 써도 엉뚱한 컨텍스트를 넣으면 엉뚱한 답변이 나옵니다. 반대로 검색이 정확하면 비교적 저렴한 모델로도 충분한 품질의 답변을 얻을 수 있습니다.

다음 편에서는 이 시스템의 기초 공사에 해당하는 데이터 파이프라인을 다룹니다. 문서를 어떻게 전처리하고, 어떤 전략으로 나누고, 청크에 어떤 메타데이터를 추가하고, 어떤 임베딩 모델을 선택할지. 선택적으로 지식 그래프를 구축하는 방법까지. "쓰레기를 넣으면 쓰레기가 나온다"는 오래된 격언이 RAG에서도 그대로 적용됩니다. 데이터 파이프라인이 전체 시스템 품질의 80%를 결정한다는 것을 구체적인 벤치마크와 함께 보여드리겠습니다.

---

참고 자료

• Why 70% of RAG Implementations Fail - Python Plain English
• Why RAG Fails in Production (And How to Fix It) - AI Accelerator Institute
• Seven Failure Points When Engineering a RAG System - arXiv 2401.05856
• Don't Do RAG: When Cache-Augmented Generation is All You Need - ACM Web Conference 2025
• OG-RAG: Ontology-Grounded RAG - EMNLP 2025
• Knowledge Graph-Based RAG Models - Nature Scientific Reports
• Microsoft GraphRAG - GitHub
• Anthropic Contextual Retrieval - Anthropic 공식 문서
• Enterprise RAG Architecture: A Practitioner's Guide - Applied AI
• LlamaIndex Production RAG - LlamaIndex 공식 문서
• Graph RAG in 2026: A Practitioner's Guide - Medium
• Six Lessons Learned Building RAG Systems in Production - Towards Data Science
• DoorDash RAG-Based Support System - ZenML
• LinkedIn GraphRAG Technical Support - Evidently AI
• RAG Implementation Cost and ROI Analysis - Stratagem Systems
• Ollama Embeddings - Ollama 공식 문서

---

다음 편: [2편] 데이터가 전부입니다 - 문서를 지식으로 바꾸는 파이프라인