RAG와 에이전트: 개발자가 체감하는 “똑똑함”의 차이

“모델이 답은 잘하는데, 우리 서비스 문서를 모르네?” 이 지점에서 많은 개발자가 RAG를 붙입니다. 그런데 막상 만들고 나면 또 이런 요구가 나옵니다. “그럼 사용자가 ‘환불 처리’라고 말하면, 정책 확인하고 주문 조회해서 실제로 처리까지 해줘.” 여기서부터는 에이전트(Agent)의 영역입니다. 둘 다 AI 기능을 강화하지만, 어디까지를 모델이 ‘생각’하고 어디부터를 ‘행동’하게 할지가 완전히 달라집니다.

RAG와 에이전트, 한 문장으로 구분하기

RAG(Retrieval-Augmented Generation)

• 모델이 답변을 만들 때 외부 지식(문서/DB 검색 결과)을 끼워 넣어 더 정확하게 말하도록 돕는 방식
• 핵심: “근거를 찾아서 잘 말하기”

에이전트(Agent)

• 모델이 목표를 달성하기 위해 도구를 선택·호출하고, 중간 결과를 보고 다음 행동을 결정하는 방식
• 핵심: “일을 끝내기 위해 움직이기” 정리하면, RAG는 지식 보강, 에이전트는 작업 수행에 가깝습니다.

언제 RAG가 정답인가

RAG는 특히 다음 상황에서 효과가 좋습니다.

1) 사내 문서/가이드/정책이 자주 바뀔 때

모델 자체를 다시 학습시키는 대신, 문서를 쪼개서 저장하고(벡터화) 질문마다 찾아 붙이면 됩니다. 예: 고객센터 챗봇이 최신 환불 규정을 인용해 안내

2) “근거 있는 답변”이 중요한 서비스

RAG는 검색 결과 문단을 함께 사용하므로 답의 출처가 내부 문서에 있다는 안정감이 생깁니다. 예: 개발 위키 기반 Q&A, 장애 대응 런북 안내

3) 데이터는 많은데 구조가 제각각일 때

PDF, 노션, 위키, 마크다운이 섞여 있어도 “검색 → 요약/정리” 흐름으로 흡수 가능합니다.

언제 에이전트가 필요해지는가

에이전트는 “말”보다 “일”이 중요할 때 빛납니다.

1) 여러 시스템을 오가며 처리해야 할 때

예: 주문 조회 → 재고 확인 → 환불 승인 요청 → 고객에게 결과 안내 이건 단순 답변이 아니라 워크플로우 자동화입니다.

2) 조건 분기가 많고, 단계적 판단이 필요할 때

예: “VIP 고객 + 구매 30일 이내 + 개봉 여부”에 따라 처리 경로가 달라짐 에이전트는 매 단계에서 결과를 보고 다음 도구를 고를 수 있습니다.

3) 사람의 ‘손’이 들어가던 반복 업무를 줄이고 싶을 때

예: 슬랙에서 “이번 주 장애 요약 만들어줘” → 이슈 트래커 조회 → 로그 요약 → 보고서 초안 생성

실전 설계: RAG + 에이전트 조합이 강력한 이유

가장 흔한 형태는 에이전트가 RAG를 도구처럼 사용하는 구조입니다.

• 에이전트: “환불 처리” 목표를 받음
• RAG 도구: 환불 정책/예외 규정을 검색해 근거 제공
• 다른 도구: 주문 DB 조회, 티켓 생성 API 호출
• 최종: 사용자에게 처리 결과와 근거를 함께 안내 즉, RAG가 “지식”, 에이전트가 “행동”을 담당하면서 서로의 약점을 메웁니다.

간단 예시 코드: RAG를 ‘도구’로 쓰는 에이전트 골격

아래는 개념을 잡기 위한 최소 예시입니다. 실제 제품에서는 인증/권한/로깅/레이트리밋이 필수입니다.

from typing import Dict, Any, List

def retrieve_docs(query: str) -> List[Dict[str, Any]]:
    # 실제로는 벡터DB/검색엔진을 호출
    return [
        {"title": "환불 정책", "snippet": "구매 7일 이내 미개봉은 전액 환불... 예외: 디지털 상품은..."},
        {"title": "VIP 예외 규정", "snippet": "VIP는 14일 이내 개봉 시에도 부분 환불 가능..."}
    ]

def get_order(order_id: str) -> Dict[str, Any]:
    # 실제로는 주문 DB/API 호출
    return {"order_id": order_id, "days_since_purchase": 10, "opened": True, "is_vip": True}

def create_refund_ticket(order_id: str, reason: str) -> str:
    # 실제로는 티켓/결제 시스템 호출
    return f"TICKET-{order_id}-001"

def agent_refund_flow(user_message: str, order_id: ) -> [, ]:
    
    docs = retrieve_docs()

    
    order = get_order(order_id)

    
    eligible = (order[]  order[] <= )  \
               (order[] <=    order[])

     eligible:
        ticket_id = create_refund_ticket(order_id, reason=user_message)
         {
            : ,
            : ticket_id,
            : docs
        }
    :
         {
            : ,
            : ,
            : docs
        }

result = agent_refund_flow(, order_id=)
(result)

포인트는 단순합니다. 문서 검색(근거) + 시스템 조회(사실) + 처리(행동)가 한 흐름으로 이어지면, 사용자는 “답변”이 아니라 “완료”를 받게 됩니다.

개발 관점 체크리스트: 실패를 줄이는 기준

RAG에서 자주 깨지는 지점

• 문서가 길고 복잡한데 잘게 쪼개지지 않음 → 엉뚱한 문단이 붙음
• 최신 문서 반영이 느림 → “그거 예전 규정인데요?” 발생
• 질문이 모호함 → 검색 품질이 흔들림 (질문 재구성/필터링이 도움이 됨)

에이전트에서 자주 깨지는 지점

• 도구 권한이 과함 → 실수 한 번이 사고로 이어짐
• 실패 처리/재시도 전략이 없음 → 중간 단계에서 멈추고 사용자 경험이 붕괴
• 로그/추적이 부실함 → “왜 이렇게 행동했지?”를 재현 못함

마무리: 무엇부터 붙일까?

• “우리 데이터를 근거로 잘 설명하고 싶다” → RAG 먼저
• “여러 시스템을 건드려서 업무를 끝내게 하고 싶다” → 에이전트 중심
• 대부분의 실전 서비스 → RAG + 에이전트 조합 결국 개발에서 중요한 건 멋진 용어가 아니라, 사용자가 원하는 결과를 안정적으로 내는 구조입니다. RAG로 지식을 단단히 하고, 에이전트로 실행력을 붙이면 “말 잘하는 챗봇”을 넘어 “일 잘하는 기능”에 가까워집니다.