Kwangmin Kim - Custom RAG vs 범용 Agent 선택 전략

1 도입

사내 특화 챗봇을 개발할 때 가장 먼저 부딪히는 질문이 있다. “직접 RAG 파이프라인을 구축해야 하는가, 아니면 Claude Code나 GPT 같은 범용 Agent에 문서를 업로드해서 쓰면 되는가?”

이 질문은 단순한 기술 선택 문제가 아니다. 통제권 vs 속도 vs 정확도의 트레이드오프를 어떻게 설계할 것인가에 대한 전략적 판단이다. 한쪽으로 몰아가는 선택은 거의 항상 손해를 가져온다.

이 글에서는 두 접근의 본질적 차이를 분석하고, 실무에서 활용할 수 있는 의사결정 프레임워크와 Hybrid 아키텍처를 제시한다.

2 두 접근의 본질 차이

2.1 범용 Agent (Claude Code, GPT 등)

범용 Agent는 문서를 업로드하면 즉시 사용할 수 있는 형태의 서비스다.

구분	내용
핵심 특징	문서 업로드 후 바로 사용, 별도 RAG 설계 불필요, 최신 모델 성능 그대로 활용
장점	개발 속도 압도적으로 빠름, 유지보수 부담 낮음, 최신 기능 자동 반영
한계	retrieval 통제 불가, 검색 품질 튜닝 어려움, 내부 데이터 구조 반영 제한, 평가/지표 설계 어려움

2.2 Custom RAG (Self/Agentic 포함)

Custom RAG는 retrieval, ranking, evaluation을 직접 설계하는 방식이다.

구분	내용
핵심 특징	retrieval / ranking / evaluation 파이프라인을 직접 설계하고 운영
장점	정확도 컨트롤 가능, domain 특화 최적화, explainability 확보, 내부 시스템과 깊은 연동
한계	초기 비용이 큼, 유지보수 부담, 지속적인 tuning 필요

2.3 본질적 차이 요약

범용 Agent는 “모델의 능력에 위임”하는 접근이고, Custom RAG는 “검색의 품질을 직접 설계”하는 접근이다. 전자는 속도를, 후자는 정확도와 통제권을 우선한다.

3 의사결정 프레임워크

다음 4가지 질문에 순서대로 답하면 어떤 접근이 적합한지 판단할 수 있다.

3.1 질문 1: 정확도가 비즈니스 리스크로 직결되는가?

YES → Custom RAG 필요
NO → 범용 Agent로 충분

예시:

법무 / 의료 / 제조 공정 문서 → 오답이 법적, 안전상 리스크를 초래하므로 RAG 필수
사내 위키 검색, 일반 지식 공유 → 오답의 영향이 제한적이므로 Agent로 충분

3.2 질문 2: 문서 구조가 복잡한가?

DB + API + PDF + 로그가 혼합 → Custom RAG
단순 문서 묶음 → 범용 Agent

문서 소스가 다양하고 구조가 이질적일수록 범용 Agent의 단순 업로드 방식으로는 검색 품질을 보장하기 어렵다.

3.3 질문 3: 검색 품질을 수치로 관리해야 하는가?

precision/recall 측정, audit 필요 → Custom RAG
정성적 만족도면 충분 → 범용 Agent

규제 산업이나 품질 인증이 필요한 환경에서는 검색 결과에 대한 정량적 평가 체계가 필수다.

3.4 질문 4: 내부 시스템과 액션 연결이 필요한가?

업무 자동화, API 호출 연동 필요 → Agentic RAG
단순 질의응답 → 범용 Agent

검색 결과를 기반으로 후속 액션(티켓 생성, DB 업데이트 등)까지 수행해야 한다면 Custom RAG에 Agent 기능을 결합한 Agentic RAG가 적합하다.

3.5 의사결정 플로우차트

4 아키텍처 유형별 설계

4.1 Agent-only 아키텍처

사용자 → LLM Agent (Claude / GPT) → 문서 업로드 기반 검색 → 응답

적합한 경우: 사내 위키 검색, 일반 Q&A, PoC 단계
특징: 개발 비용 최소, 검색 품질 블랙박스
한계: retrieval 로직을 제어할 수 없고, 검색 누락 시 디버깅 불가

4.2 RAG-only 아키텍처

사용자 → Query Processing → Vector DB / Search → Retrieval → LLM → 응답

적합한 경우: 정확도가 핵심인 도메인, 규제 환경
특징: 검색 품질을 precision/recall로 관리 가능, 문서 grounding 보장
한계: 최신 모델 활용이 느리고, 개발/운영 비용이 높음

4.3 Hybrid 아키텍처 (권장)

현재 업계의 주류 트렌드는 다음 한 문장으로 정리된다:

“Agent를 쓰되, 핵심 데이터는 RAG로 통제한다.”

4.3.1 역할 분리

구성 요소	역할
Agent	질문 이해, multi-step reasoning, tool 선택
RAG	검색 정확도 책임, 문서 grounding, score 제공

이 구조에서 Agent는 “두뇌” 역할을, RAG는 “기억” 역할을 수행한다.

4.4 Hybrid 아키텍처 코드 예시

Agent가 Custom RAG를 tool로 호출하는 LangGraph 기반 구현 예시다.

from langchain_core.tools import tool
from langchain_openai import ChatOpenAI
from langgraph.prebuilt import create_react_agent


@tool
def search_internal_docs(query: str) -> str:
    """사내 문서에서 정보를 검색한다.

    정책 문서, 기술 표준, 업무 매뉴얼 등 사내 핵심 문서를 대상으로
    Custom RAG 파이프라인을 통해 검색한다.
    """
    # Custom RAG 파이프라인 호출
    from custom_rag import RAGPipeline

    pipeline = RAGPipeline(
        vector_store="azure_ai_search",
        embedding_model="text-embedding-3-large",
        reranker="cross-encoder"
    )

    results = pipeline.retrieve(
        query=query,
        top_k=5,
        score_threshold=0.7  # 신뢰도 기반 필터링
    )

    # 검색 결과를 구조화된 형태로 반환
    context_parts = []
    for doc in results:
        context_parts.append(
            f"[출처: {doc.metadata['source']}] "
            f"(신뢰도: {doc.score:.2f})\n{doc.content}"
        )

    return "\n---\n".join(context_parts)


@tool
def query_internal_db(sql_description: str) -> str:
    """사내 데이터베이스에서 정보를 조회한다."""
    # 내부 DB 조회 로직
    pass


# Agent 구성: LLM + Custom RAG Tool
llm = ChatOpenAI(model="gpt-4o")
tools = [search_internal_docs, query_internal_db]

agent = create_react_agent(llm, tools)

# 실행
response = agent.invoke({
    "messages": [
        {"role": "user", "content": "사내 보안 정책에서 외부 API 호출 시 필요한 인증 절차는?"}
    ]
})

이 구조의 핵심은 Agent가 “언제 RAG를 호출할지”를 판단하고, RAG가 “어떤 문서를 어떤 순서로 반환할지”를 통제한다는 점이다.

5 Hybrid 아키텍처가 강력한 이유

5.1 미래 대응

모델은 계속 바뀐다 → Agent만 교체하면 된다
데이터는 유지된다 → RAG는 그대로 동작한다

5.2 Vendor Lock-in 방지

Agent를 Claude에서 GPT로 교체해도 RAG 파이프라인은 영향받지 않는다
반대로 Vector DB를 Pinecone에서 Azure AI Search로 변경해도 Agent 로직은 그대로다

5.3 성능 안정성

hallucination이 감소한다: RAG가 제공하는 문서 근거 기반으로 답변을 생성하기 때문
retrieval 품질을 수치로 관리할 수 있다: precision, recall, MRR 등 지표 적용 가능

6 한쪽에만 의존하면 생기는 문제

6.1 전부 Agent에 의존하는 경우

“왜 이 답이 나왔는가?” 설명 불가
검색 품질 디버깅 불가 (블랙박스)
특정 문서 누락이 발생해도 원인 파악 어려움
모델 업데이트 시 답변 품질이 예측 불가능하게 변동

6.2 전부 RAG로 구축하는 경우

개발 속도가 현저히 느림
최신 모델의 reasoning 능력 활용이 늦어짐
유지보수 부담이 지속적으로 증가
multi-step reasoning이 필요한 복잡한 질문에 취약

7 단계별 도입 전략

현실적으로 가장 합리적인 전략은 4단계에 걸친 점진적 도입이다.

7.1 Phase 1: 빠른 구축 (1-2주)

목표: 사용성 검증 및 초기 피드백 수집

항목	내용
접근	Claude/GPT Agent + 문서 업로드
산출물	프로토타입 챗봇, 사용자 피드백 보고서
핵심 지표	사용자 만족도, 질문 유형 분류

이 단계에서는 완벽한 정확도보다 “사용자가 실제로 무엇을 물어보는가”를 파악하는 것이 목적이다.

7.2 Phase 2: 문제 발견 (2-4주)

목표: Agent의 한계 지점 식별

항목	내용
접근	오답/누락 케이스 체계적 수집
산출물	실패 케이스 데이터셋, 문제 유형 분류표
핵심 지표	오답률, 누락률, 실패 패턴 분석

잘못된 답변과 검색 누락 케이스를 수집하여 Custom RAG가 필요한 영역을 정확하게 식별한다.

7.3 Phase 3: 부분 RAG 도입 (4-8주)

목표: 핵심 데이터에 대한 검색 품질 확보

항목	내용
접근	중요 데이터만 선별적 RAG 구축 (정책 문서, 핵심 DB 등)
산출물	Custom RAG 파이프라인, 평가 지표 대시보드
핵심 지표	precision@k, recall@k, MRR

Phase 2에서 발견된 실패 케이스 중 비즈니스 임팩트가 큰 영역부터 RAG를 도입한다.

7.4 Phase 4: 고도화 (지속)

목표: 자동화된 품질 관리 체계 구축

항목	내용
접근	Agentic RAG + Self-RAG + 자동 평가 시스템
산출물	통합 Agent 시스템, 자동 평가 파이프라인, 운영 대시보드
핵심 지표	end-to-end 정확도, 응답 시간, 비용 효율성

8 비용-효과 분석

항목	Agent-only	RAG-only	Hybrid
초기 개발 시간	1-2주	8-12주	4-8주 (단계적)
월간 운영 비용	낮음 (API 비용)	높음 (인프라 + 인력)	중간
검색 정확도	중간 (통제 불가)	높음 (직접 관리)	높음 (핵심 영역)
유지보수 부담	낮음	높음	중간
확장 유연성	낮음	높음	높음
디버깅 가능성	낮음	높음	높음 (RAG 영역)
Vendor Lock-in	높음	낮음	낮음

9 실무에서 많이 쓰는 조합

현재 업계에서 가장 일반적으로 채택하는 기술 스택 조합은 다음과 같다.

계층	기술
UI/Agent	Claude / GPT (LLM Agent)
Retrieval	Azure AI Search / Pinecone / Weaviate
Orchestration	LangGraph / custom agent framework
Evaluation	RAGAS / LangSmith / custom metric

대기업의 경우 보안 요구사항에 따라 Azure AI Search + Azure OpenAI의 조합을 선호하는 경향이 있으며, 스타트업은 Pinecone + OpenAI API의 경량 조합을 많이 채택한다.

10 정리

Custom RAG와 범용 Agent의 선택은 이분법적 판단이 아니다. 핵심은 다음 원칙이다:

“Agent는 두뇌, RAG는 기억이다. 기억을 외주 주면 결국 품질을 잃는다.”

범용 Agent로 빠르게 시작하되, 정확도가 비즈니스 리스크인 영역에는 Custom RAG를 도입한다
Hybrid 아키텍처에서 Agent와 RAG의 역할을 명확히 분리한다
단계적으로 도입하여 실패 케이스를 기반으로 RAG 영역을 확장한다
비용과 품질의 균형점은 조직마다 다르므로, Phase 1-2의 데이터를 기반으로 판단한다