「RAG를 도입했는데 왜인지 LLM이 엉뚱한 답변을 한다」, 「외부 API와 연동했더니 할루시네이션 (Hallucination)이 빈번하게 발생해 곤란하다」

많은 엔지니어가 AI 에이전트 개발에서 직면하는 이 문제는, RAG와 외부 API 연동의 조합 방식에 본질적인 원인이 있습니다. 단순히 정보를 검색해서 전달하는 것만으로는 LLM이 가진 자율적인 판단력과 외부 리소스를 활용하는 능력을 끌어낼 수 없습니다.

이 기사에서는 RAG와 외부 API 연동을 결합하여, 자율적으로 태스크를 실행하는 AI 에이전트의 구체적인 구축 절차를 해설합니다. LangChain이나 LangGraph를 활용한 핸즈온 형식으로, 실용적인 AI 애플리케이션 개발의 첫걸음을 내디뎌 봅시다.

이 섹션에서는 AI 에이전트의 개념과, 그 능력을 극대화하는 RAG·API 연동의 역할에 대해 해설합니다.

AI 에이전트는 주어진 목표에 대해 자율적으로 계획을 세우고, 도구(함수나 API)를 호출하며, 태스크를 실행하는 시스템입니다. 기존의 RPA가 정형 업무의 자동화에 특화되어 있었던 것과 달리, AI 에이전트는 비정형적이고 복잡한 태스크에도 대응할 수 있다는 점에서 크게 다릅니다.

하지만 LLM 단독으로는 「학습 데이터에 없는 최신 정보」나 「실시간 외부 데이터」에 액세스할 수 없습니다. 여기서 중요해지는 것이 다음의 두 가지 기술입니다.

RAG (Retrieval-Augmented Generation): 외부 지식 베이스(Knowledge Base)에서 관련 정보를 검색하여 LLM에 제시함으로써, 할루시네이션 (Hallucination, 오정보 생성)을 억제하고 답변의 정확성을 향상시킵니다. -
API 연동: 외부 서비스(일기 예보, EC 사이트, 사내 시스템 등)의 API를 호출하여 실시간 데이터 취득이나 액션 실행을 가능하게 합니다. 이를 통해 AI 에이전트의 적용 범위가 비약적으로 넓어집니다.

이 두 기술을 결합함으로써 AI 에이전트는 「최신 정보를 참조하면서 동시에 외부 시스템을 조작할 수 있게」 되어, 진정으로 자율적인 태스크 실행이 가능해집니다.

이 섹션에서는 AI 에이전트 개발에서 이용되는 주요 프레임워크와, 그 기반이 되는 LLM에 대해 해설합니다.

AI 에이전트 구축에는 다양한 프레임워크가 존재합니다. 각각의 특징을 이해하고 프로젝트의 요구사항에 맞는 것을 선택합시다.

LangGraph: LangChain의 기능을 확장하여 멀티 에이전트 워크플로우 (Multi-agent Workflow)를 효율적으로 구축할 수 있는 프레임워크입니다. 상태 관리나 조건 분기를 적은 코드로 기술할 수 있어 복잡한 에이전트 연동에 적합합니다. -
Microsoft Agent Framework: Microsoft가 제창하는 에이전트 개발 프레임워크로, Semantic Kernel이나 AutoGen의 사상을 도입하고 있습니다. Workflow 기반 설계로 에이전트 간의 연동이나 실행 상황 모니터링이 용이합니다. -
AutoGen (Microsoft): 여러 에이전트가 각각의 역할(예: 프로그래머, 테스터)을 분담하여 협조하며 태스크를 해결하는 「멀티 에이전트 시스템 (Multi-agent System)」 구축에 뛰어납니다. -
CrewAI: AutoGen과 마찬가지로 멀티 에이전트 시스템에 특화되어 있으며, 보다 직관적인 API로 에이전트 간의 연동을 정의할 수 있습니다.

본 기사에서는 유연한 워크플로우 구축이 가능한 LangGraph를 기반으로 한 AI 에이전트 구축 사고방식을 중심으로 해설합니다.

AI 에이전트의 추론 능력은 기반이 되는 LLM의 성능에 크게 의존합니다.

GPT-4o (OpenAI): 높은 추론 능력과 멀티모달 (Multimodal) 대응이 특징입니다. 복잡한 태스크나 다양한 데이터 형식에 대응해야 하는 경우에 적합합니다. -
Claude 3.5 Sonnet (Anthropic): OpenAI의 모델과 나란히 매우 높은 추론 능력을 가진 모델입니다. 특히 장문 독해나 복잡한 지시 이해에 뛰어납니다. -
Gemini 1.5 Pro (Google): 대규모 컨텍스트 윈도우 (Context Window)와 높은 추론 능력을 겸비하고 있습니다. 동영상이나 음성과 같은 멀티모달 입력에도 대응 가능합니다. -
Anthropic Claude 3 Haiku: 빠른 응답성과 비용 효율성이 요구되는 경우에 적합합니다.

이 모델들은 각각 특기 분야와 비용이 다릅니다. 개발할 AI 에이전트의 요구사항(응답 속도, 정밀도, 예산 등)에 맞춰 최적의 모델을 선정하는 것이 중요합니다.

이 섹션에서는 RAG가 어떻게 작동하여 LLM의 답변 정밀도를 향상시키는지, 그리고 그 최소 구성 구현 예시에 대해 설명합니다.

RAG는 「검색 (Retrieval)」과 「생성 (Generation)」을 결합함으로써, LLM이 가진 기존 지식에 더해 외부의 최신 정보나 전문 지식을 참조하여 답변을 생성하는 기술입니다.

검색 단계 (Retrieval Phase): 사용자의 쿼리가 입력되면, 먼저 외부의 지식 베이스 (문서, 데이터베이스 등)에서 관련성이 높은 정보를 검색합니다. 이때 벡터 데이터베이스 (Vector Database)나 전문 검색 엔진 (예: Amazon Kendra)이 이용됩니다. -
생성 단계 (Generation Phase): 검색된 정보 (컨텍스트 (Context))가 사용자의 쿼리와 함께 LLM에 프롬프트 (Prompt)로서 전달됩니다. LLM은 이 컨텍스트를 기반으로 답변을 생성하기 때문에, 환각 (Hallucination) 현상이 억제되고 더욱 정확하며 근거 있는 답변을 기대할 수 있습니다.

LangChain과 벡터 DB (예: Chroma DB)를 사용하면 RAG의 기본적인 파이프라인을 구축할 수 있습니다.

pip install langchain_community langchain_openai chromadb tiktoken python-dotenv

.env

파일에 OpenAI API 키를 설정합니다.

OPENAI_API_KEY="your_openai_api_key_here"

다음 Python 코드는 LangChain과 ChromaDB를 사용한 RAG의 최소 구성입니다.

import os
from dotenv import load_dotenv
from langchain_community.document_loaders import TextLoader
...

이 코드에서는 다음과 같은 단계로 RAG를 구현하고 있습니다.

문서 로드 (Document Loading): 외부 정보원으로부터 텍스트 데이터를 로드합니다. -
청크 분할 (Chunk Splitting): 긴 문서를 LLM의 컨텍스트 윈도우 (Context Window)에 들어갈 적절한 크기의 청크 (Chunk)로 분할합니다. RecursiveCharacterTextSplitter는 의미 있는 구분점을 유지하면서 분할하는 데 도움이 됩니다. -
임베딩 벡터 생성 (Embedding Vector Generation): 각 청크를 수치 벡터 (임베딩 (Embedding))로 변환합니다. 이를 통해 의미적으로 유사한 청크가 벡터 공간 상에서 가깝게 배치됩니다. -
벡터 스토어 저장 (Vector Store Storage): 생성된 임베딩 벡터를 벡터 데이터베이스 (ChromaDB)에 저장합니다. -
리트리버 생성 (Retriever Creation): 사용자의 질문과 가장 관련성이 높은 청크를 벡터 스토어에서 검색하기 위한 컴포넌트를 준비합니다. -
프롬프트 템플릿 정의 (Prompt Template Definition): LLM에 전달할 프롬프트를 정의하고, 검색 결과가 삽입될 플레이스홀더 (Placeholder)를 설정합니다. "검색 결과만을 사용하여 답변할 것"과 같은 제약을 두어 환각 (Hallucination)을 억제합니다.

RAG를 도입하더라도 기대하는 정밀도가 나오지 않을 수 있습니다. 주요 원인과 회피책은 다음과 같습니다.

검색 정밀도 저하:-
함정 (Pitfall): 임베딩 모델 선정 오류, 검색 알고리즘 최적화 부족, 데이터 포맷 불비. -
회피책 (Workaround):-
임베딩 모델 선택: text-embedding-ada-002 (OpenAI)와 같은 고성능 모델이나 태스크에 특화된 모델을 선정합니다. -
쿼리 확장 (Query Expansion): 사용자의 질문을 LLM으로 확장하여 더 많은 관련 정보를 검색할 수 있도록 합니다. -
재순위화 (Re-ranking): 검색을 통해 얻은 상위 N개의 문서를 별도의 LLM이나 모델로 다시 스코어링하여 가장 관련성이 높은 것을 선택합니다. -
적절한 청크 분할: LangChain의 TextSplitters 도구 등을 활용하여 의미 있는 단위로 청크를 분할합니다. 청크가 너무 길면 노이즈가 많아지고, 너무 짧으면 문맥이 손실됩니다.

환각 (Hallucination) 발생:-
함정 (Pitfall): 검색 결과가 불충분하거나, LLM이 검색 결과 이외의 정보를 보완하려고 할 때 발생합니다. -
회피책 (Workaround):-
프롬프트를 통한 제약: "검색 결과만을 사용하여 답변할 것", "모르는 경우에는 '모릅니다'라고 답변할 것"과 같은 명확한 지시를 프롬프트에 포함합니다. -
데이터 품질 향상: 지식 베이스의 정보를 항상 최신 상태로 정확하게 유지하고 포괄성을 높입니다.

이 섹션에서는 AI 에이전트가 외부 API를 이용하여 실시간 정보를 취득하거나 액션(Action)을 실행하는 방법에 대해 해설합니다.

AI 에이전트가 외부 API를 이용하려면 HTTP 요청(HTTP Request)을 전송하는 기능이 필요합니다. Python에서는 requests 라이브러리가 표준적으로 사용됩니다.

import requests
import os
from dotenv import load_dotenv
...

이 코드에서는 다음 사항에 주의하십시오.

API 키 관리: API 키는 환경 변수(.env 파일과 python-dotenv)로 관리하며, 코드에 직접 작성하지 않도록 합니다. -
에러 핸들링 (Error Handling): response.raise_for_status()를 사용하여 HTTP 상태 코드를 확인하고, 에러가 발생한 경우 적절하게 예외 처리를 수행합니다. -
헤더와 페이로드 (Header & Payload): API 사양에 따라 headers 및 json (POST의 경우)을 설정합니다.

AI 에이전트가 API를 "도구 (Tool)"로 이용하는 경우, LLM이 어떤 API를 어떤 인자(Argument)로 호출해야 하는지 판단할 수 있도록 해야 합니다. 이는 LangChain의 Tool이나 Function Calling 기능을 사용하여 구현할 수 있습니다.

from langchain.tools import tool
import requests
# 외부 API를 호출하는 함수를 도구로 정의
...

이 예시에서는 @tool 데코레이터를 사용하여 Python 함수를 LangChain의 도구로 등록하고 있습니다. LLM은 프롬프트와 이용 가능한 도구 리스트를 제공받음으로써, 사용자의 질문에 따라 적절한 도구를 선택하고 인자를 생성하여 호출할 수 있습니다.

API 연동은 외부 서비스에 의존하기 때문에 특유의 과제가 있습니다.

외부 서비스 의존 및 트러블:
함정 (Pitfall): 연동 대상 서버 장애, 서비스 중단, 사양 변경이 자사 시스템에 영향을 미침. -
회피책:
이용 조건 사전 파악: 요금 체계, 요청 제한 (Rate Limit), 데이터 전송량을 확인합니다. -
에러 핸들링 및 재시도 처리 (Retry): 네트워크 에러나 API 측의 에러에 대비하여 적절한 에러 처리와 재시도 메커니즘을 구현합니다. -
캐시 (Cache) 활용: 자주 변경되지 않는 데이터는 캐싱함으로써 API 호출 횟수를 줄이고 가용성을 향상시킵니다. -
신뢰할 수 있는 제공처 선택: Google, Amazon, Microsoft 등 신뢰성이 높은 기업이 제공하는 API를 이용하는 것이 바람직합니다.

보안 리스크 (Security Risk):
함정 (Pitfall): API 키 유출, 부정 액세스. -
회피책:
API 키의 엄격한 관리: 환경 변수나 시크릿 관리 서비스 (AWS Secrets Manager, Azure Key Vault 등)를 이용하며, 코드에 직접 작성하지 않습니다. -
OAuth 2.0 등의 인증 및 인가: 적절한 인증/인가 플로우를 도입하고 최소 권한의 원칙을 따릅니다. -
API Gateway 활용: API Gateway에서 인증, 인가, 레이트 리밋 (Rate Limit) 등을 일원적으로 관리하여 보안을 강화합니다.

유지보수 공수 고려:
함정 (Pitfall): 연동 대상 API의 업데이트에 맞춰 접속 프로그램의 개수가 필요함. -
회피책:
버전 관리 전략 수립: 연동 대상 API의 버전 관리 정책을 이해하고, 자사 시스템도 이에 맞춰 버전 관리 전략을 세웁니다. -
자동 테스트 도입: API 연동 부분의 테스트를 자동화하여 사양 변경 시의 영향을 조기에 감지할 수 있도록 합니다.

이 섹션에서는 RAG와 API 연동을 통합한 AI 에이전트의 구체적인 구축 절차를 LangGraph의 개념을 곁들여 해설합니다.

RAG와 API 연동을 결합하는 경우, AI 에이전트는 다음과 같은 워크플로우 (Workflow)로 동작합니다.

• 사용자 질문 접수: AI 에이전트가 사용자의 질문을 받습니다.

• 태스크 계획 (Task Planning): LLM이 질문 내용을 분석하여 RAG를 통한 정보 검색이 필요한지, 외부 API 호출이 필요한지, 혹은 둘 다 필요한지를 판단합니다.

  • 예: "〇〇에 대해 알려줘" → RAG로 정보 검색
  • 예: "〇〇의 현재 날씨는?" → 날씨 API 호출
  • 예: "〇〇의 현재 날씨와 그 역사에 대해 알려줘" → 날씨 API와 RAG를 모두 이용

• 도구 실행 (RAG 또는 API 호출):

  • RAG의 경우: 지식 베이스 (Knowledge Base)에서 관련 정보를 검색하여 결과를 가져옵니다.
  • API 연동의 경우: 적절한 API를 호출하여 결과를 가져옵니다.

• 결과 통합 및 답변 생성: 검색 결과나 API 실행 결과를 LLM에 전달하여 사용자에게 전달할 최종 답변을 생성합니다.

• 피드백 및 개선: 사용자의 피드백이나 에이전트의 실행 로그를 분석하여 에이전트의 성능을 지속적으로 개선합니다.

LangGraph는 LLM 애플리케이션을 "그래프 (Graph)"로 정의함으로써, 복잡한 상태 전이 (State Transition)나 에이전트 간의 연동을 관리하기 쉽게 만듭니다.

• 노드 (Node): 그래프의 각 단계를 나타냅니다. 이는 LLM 호출, RAG 검색, API 호출 등의 처리 단위입니다.
• 에지 (Edge): 노드 간의 연결을 나타냅니다. 조건부 에지 (Conditional Edge)를 사용하면 이전 노드의 출력에 따라 다음에 실행할 노드를 동적으로 결정할 수 있습니다.
• 상태 (State): 워크플로우 전체에서 공유되는 데이터입니다. 사용자의 질문, LLM의 사고 과정, 도구의 실행 결과 등이 포함됩니다.

# from langgraph.graph import StateGraph, END
# from langchain_core.messages import HumanMessage
# from langchain_openai import ChatOpenAI
...

이 LangGraph의 개념적인 코드는 LLM이 "사고"하고 (call_llm 노드), 필요에 따라 "도구를 실행"하며 (call_tool 노드), 그 결과를 바탕으로 다시 "사고"하는 에이전트의 자율적인 루프를 나타냅니다. should_continue 함수가 LLM이 도구를 호출할지, 아니면 최종 답변을 생성할지를 판단하여 그래프의 실행 경로를 결정합니다.

AI 에이전트 개발의 트레이드오프 (Trade-off):

• 지능 (정밀도·판단력) vs 속도 (응답 속도) vs 가성비 (비용): 고성능 LLM은 똑똑하지만 응답이 느리고 비용이 높아지는 경향이 있습니다. 비즈니스 요구사항에 맞춰 이러한 균형을 최적화해야 합니다.
• 완전 자동화의 어려움: 에이전트 간의 연동에서 오류가 연쇄적으로 증가할 리스크나, 중요한 태스크에는 인간의 확인이 필요한 현 상황을 이해하고, 적절한 휴먼 인 더 루프 (Human-in-the-Loop) 메커니즘을 도입해야 합니다.

RAG의 베스트 프랙티스 (Best Practices):

• 데이터의 품질과 구조화: 지식 베이스의 품질과 명확성을 향상시키고, 문서를 제목 및 소제목으로 적절히 구조화함으로써 LLM이 관련 정보에 접근하기 쉽게 만듭니다.
• 검색 쿼리 최적화: 쿼리 확장 (Query Expansion)이나 재순위화 (Re-ranking) 등을 사용하여 검색 정밀도를 극대화합니다.
• 지속적인 테스트와 조정: 작게 시도하며 개선을 거듭함으로써 더욱 정확한 답변으로 이어지게 합니다.

API 설계의 베스트 프랙티스 (Best Practices):

• RESTful API 원칙: 일관성 있는 API 설계를 지향하고, OpenAPI/Swagger를 통해 문서를 명확하게 기술합니다.
• 보안 바이 디자인 (Security by Design): 인증, 인가, 액세스 제어, 암호화 등 모든 API에 요구되는 보안 요구사항을 명확히 하여 설계 단계부터 포함시킵니다.
• API 게이트웨이 (API Gateway) 활용: API 엔드포인트를 일원 관리하여 보안, 성능, 모니터링을 향상시킵니다.
• SDK 제공: 개발자가 API를 쉽게 이용할 수 있도록 SDK (소프트웨어 개발 키트)를 제공하는 것도 검토합니다.

이 기사에서는 RAG와 외부 API 연동을 결합한 AI 에이전트 구축에 대해 해설했습니다.

• AI 에이전트는 RAG (Retrieval-Augmented Generation)를 통한 정보 검색과 API 연동을 통한 외부 시스템 조작을 결합함으로써, 자율적인 태스크 실행 능력을 향상시킵니다.
• RAG 구현에는 LangChain과 벡터 데이터베이스 (Vector Database)가, API 연동에는 Python의 requests 라이브러리나 LangChain의 Tool 기능이 유효합니다. - LangGraph와 같은 프레임워크는 복잡한 AI 에이전트의 워크플로우 (Workflow)를 효율적으로 정의하고 관리하는 데 도움이 됩니다.
• 개발 시에는 검색 정밀도 저하, 할루시네이션 (Hallucination), 외부 서비스 의존성 등의 과제에 대해 적절한 회피책과 설계상의 베스트 프랙티스 (Best Practice)를 적용하는 것이 성공의 열쇠입니다.

AI 에이전트는 2025년 이후에도 멀티 에이전트 시스템 (Multi-Agent System)이나 Agentic RAG, GUI 조작 연동 등 더욱 큰 진화가 기대되는 분야입니다. 본 기사에서 소개한 내용을 발판 삼아, 꼭 여러분만의 AI 에이전트 개발 프로젝트에 도전해 보시기 바랍니다.

다음 단계로서, LangGraph의 공식 문서를 참조하여 더욱 복잡한 에이전트 워크플로우 구축에 도전해 보시는 것을 추천합니다.