RAG vs 에이전트형 AI: IBM이 설명하는 LLM 데이터 연결 원리

핵심 메시지

• 에이전트형 AI와 RAG는 가장 많이 쓰이는 AI 유행어지만, 무엇이 최선인지는 '경우에 따라' 다르다.
• 에이전트형 AI는 인지 → 추론 → 행동 → 관찰의 순환 구조로 도구를 호출하며 자율적으로 목표를 수행한다.
• RAG는 문서를 청크·임베딩해 벡터 DB에 저장하는 오프라인 단계와, 질문에 맞는 조각을 검색해 LLM에 전달하는 온라인 단계로 나뉜다.
• 무작정 많은 데이터를 검색해 넣으면 정확도가 오히려 떨어지고 비용과 대기 시간이 늘어난다.
• 데이터 큐레이션과 '컨텍스트 엔지니어링'(하이브리드 검색·재정렬·청크 결합)이 품질을 좌우한다.

쉽게 이해하기

IBM의 두 전문가가 대화 형식으로 요즘 가장 뜨거운 두 유행어, 에이전트형 AI와 RAG를 풀어낸다. '에이전트는 코딩 전용', 'RAG가 언제나 최선' 같은 선입견에 대해 컨설턴트의 단골 답변 '경우에 따라 다르다'를 꺼내며, 정확히 무엇에 따라 달라지는지를 설명하겠다고 운을 뗀다.

에이전트형 AI는 환경을 인지하고 판단해 행동하는 멀티 에이전트 워크플로다. 인지 → 메모리 참조 → 추론 → 행동 → 관찰로 이어지는 루프를 돌며, 각 에이전트는 애플리케이션 수준에서 도구를 호출하고 서로 소통한다. 가장 흔한 사례는 코딩 에이전트(아키텍트·구현·리뷰어 역할 분담)이며, 기업의 지원 티켓·HR 요청 처리에도 쓰인다. 도구 호출은 MCP 같은 프로토콜로 표준화된다.

문제는 에이전트가 외부 정보에 안정적으로 접근하지 못하면 환각하거나 잘못된 판단을 내린다는 점이다. 이를 줄이는 방법이 RAG다. RAG는 두 단계로 나뉜다. 오프라인 단계에서는 문서를 청크로 나눠 임베딩 모델로 벡터화해 벡터 데이터베이스에 저장한다. 온라인 단계에서는 사용자 질문을 같은 임베딩 모델로 변환해 유사도 검색을 수행하고, 가장 관련 있는 상위 K개 조각을 찾아 LLM에 전달한다.

규모가 커지면 함정이 드러난다. 검색해 넣는 토큰이 많아질수록 LLM이 정보를 회상하기 어려워지고 비용과 대기 시간이 늘며, 어느 지점을 넘으면 잡음과 중복 때문에 정확도가 오히려 떨어진다. 그래서 모든 것을 컨텍스트에 쏟아붓기보다 의도적인 데이터 큐레이션이 필요하다. Docling 같은 오픈소스로 PDF를 표·그래프·이미지까지 포함해 마크다운 등 기계가 읽기 좋은 형태로 변환하라고 권한다.

검색 단계는 곧 '컨텍스트 엔지니어링'이다. 시맨틱 의미와 키워드를 함께 쓰는 하이브리드 회상으로 후보를 모으고, 상위 K개를 관련도 순으로 재정렬하며, 연관된 조각을 결합해 하나의 일관된 근거로 만든다. 결과적으로 정확도는 오르고 추론은 빨라지며 비용은 낮아진다. 마지막으로 vLLM·llama.cpp 같은 도구로 로컬 모델을 돌리면 데이터 주권을 지키면서 KV 캐시 튜닝으로 속도까지 끌어올릴 수 있다고 덧붙인다.

주요 인사이트

• 검색하는 토큰이 많아질수록 성능이 오르다가 어느 지점 이후 잡음·중복으로 정확도가 떨어진다 — '많이 넣기'가 답이 아니다.
• 에이전트가 외부 정보에 안정적으로 접근하지 못하면 환각하거나 잘못된 판단을 내리며, RAG가 이를 줄여준다.
• 시맨틱 검색과 키워드 검색을 함께 쓰는 하이브리드 회상 후 재정렬하면 더 정확하고 저렴한 결과를 얻는다.
• PDF를 그대로 넣는 대신 표·그래프·이미지까지 마크다운으로 변환해 미리 데이터를 풍부하게 만드는 것이 중요하다.
• 오픈소스 도구로 로컬 모델을 돌리면 데이터를 사내에 두면서 속도까지 끌어올릴 수 있다.

자주 묻는 질문

관련 AI 소식