RAG에서
AI 에이전트로 From RAG to AI Agents

프로그램된 지능에서
학습된 추론으로

소프트웨어 에이전트의 정의는 1970~1980년대 분산 AI와 컴퓨터과학에서 처음 등장했다. 그 토대가 된 개념이 1973년 칼 휴잇이 제안한 액터 모델이다. 비동기 메시지 전달로 소통하는 자기완결적이고 상호작용하는 구성요소, 즉 “액터”를 정의했다. 처음부터 “에이전트”라 불리지는 않았지만 액터는 자율성과 동시 작동이라는 핵심 원리를 구현했다.

1980년대에 연구자들은 특정한 특성을 가진 소프트웨어 실체를 서술하기 위해 “에이전트”라는 용어를 썼다. 그것은 자율적이고(자기 행동을 통제한다), “사회적” 능력을 갖고(다른 에이전트와 상호작용할 수 있다), 반응적이고(환경에 반응한다), 능동적이었다(목표를 달성하기 위해 주도권을 잡는다). 이 초기 에이전트는 심볼릭 AI에서 나왔고, 고도로 구조화되고 제한된 환경 안에서 “손으로 코딩한” 규칙과 논리적 추론으로 작동했다.

1990년대는 “지능 에이전트의 시대”가 되었다. 핵심 발전이 신념–욕구–의도(BDI) 모델이었다. 에이전트에 더 인간에 가까운 추론 구조를 부여한 아키텍처다. 에이전트는 세계 상태에 관한 신념을 유지하고, 달성할 목표인 욕구를 갖고, 실행을 약속한 계획인 의도를 형성한다. 이 시기에 이메일을 걸러내거나 초기 데이터베이스를 검색하는 정보 에이전트 같은 초기의 실용적 에이전트가 등장했고, 물류와 제조와 통신에서 복잡한 문제를 함께 푸는 첫 다중 에이전트 시스템(MAS)도 나왔다.

그러나 이 시스템들은 여전히 부서지기 쉬웠다. 그 지능은 학습된 것이 아니라 프로그램된 것이었고, 진정한 자연어 이해는 전혀 없었다. 2000년대 인터넷 붐과 API의 부상은 에이전트에게 행동할 훨씬 큰 세계를 제공했다. 웹 서비스로 실세계 데이터와 기능에 접속할 수 있게 되었지만 핵심 논리는 대체로 프로그램적으로 남았다.

이 시기의 주요한 사용자 대면 진화는 2010년대 시리와 알렉사 같은 AI 조수와 함께 왔다. 자연어를 일차 인터페이스로 도입한, 접근성의 거대한 도약이었다. 그러나 원래의 에이전틱 구상에는 미치지 못했다. 압도적으로 반응적이었고, 단일하고 잘 정의된 명령을 실행했다. “샌프란시스코 날씨는?” “오전 7시 15분에 알람을 맞춰줘” 같은 것들이다. 기억과 맥락과 계획 능력이 제한적이었고, 진정으로 자율적인 조수보다는 음성으로 작동하는 리모컨에 가까웠다.

ReAct(reason + act) 같은 프레임워크는 LLM에게 자율적 순환을 만들도록 프롬프트를 줄 수 있음을 보였다. 목표에 대해 추론하고, 웹 검색 도구나 RAG 도구 같은 도구를 고르고, 그 도구로 행동을 수행하고, 결과를 관찰해 다음 단계를 결정한다. 수십 년 전 구상했던 능동적이고 목표 지향적인 행동이 마침내 가능해졌다. 심볼릭 AI가 결코 이루지 못한 유동성과 적응성까지 갖추고서 말이다. 그 결과가 오늘날 우리가 아는 AI 에이전트다.

고전적 RAG에서 정보가 하나의 질의에 답하기 위해 검색된다면, AI 에이전트는 LLM 두뇌로 자기에게 지식의 공백이 있음을 판단하고, 조사를 통해 그것을 메울 계획을 세우고, 여러 도구 호출을 실행하고, 발견을 종합해 새 지식을 응답에 통합한다. 이것을 흔히 에이전틱 RAG라 부른다.

AI 에이전트란 무엇인가

AI 에이전트는 LLM을 핵심 추론 엔진으로 삼는 자율적 또는 반자율적 소프트웨어 시스템으로 이해하는 것이 가장 좋다. 어떤 면에서 RAG의 확장이며, 검색이라는 핵심 개념을 정적인 탐색에서 동적이고 목표 지향적인 추론 과정으로 진화시킨 것이다.

AI 에이전트는 “LLM 두뇌”를 활용해 어디서 정보를 검색할지, 어떤 도구를 쓸지, 그 단계들을 어떤 순서로 실행하는 것이 최적인지 정확히 결정한다. 그다음 이 다양한 출력을 모아 최종 응답을 만든다. 과제에 대해 추론하고 즉석에서 계획을 정의하는 능력, 그리고 실시간 정보를 제공하는 도구에 대한 접근이 에이전트가 진짜 힘을 얻는 지점이며, 다양한 질문에 더 높은 정확도로 답하는 데 대단한 유연성을 준다.

에이전틱 스택

AI 에이전트 분야는 꽤 빠르게 진화해, 에이전틱 스택이라 불리는 아키텍처가 빠르게 부상했다. 다음 세 구성요소로 이루어진다.

단일 에이전트 대
멀티 에이전트 시스템

에이전틱 AI 애플리케이션이 계속 진화하면서 이제 분명해진 것이 있다. 단일 에이전트는 단순한 문제를 상대적으로 낮은 지연으로 풀 수 있지만, 더 복잡한 워크플로는 규모에서 정확성과 신뢰성을 유지하기 위해 협업적인 멀티 에이전트 접근을 요구하는 일이 많다. 그래서 두 개의 주요 설계 패러다임이 자리 잡았다.

멀티 에이전트 시스템에는 두 가지 주요 토폴로지가 있다. 감독자(supervisor) 아키텍처에서는 감독자나 리더 에이전트가 프로젝트 관리자처럼 행동해 목표를 하위 과제로 분해하고, 각 하위 과제를 가장 적합한 전문 작업자 에이전트에게 위임한다. 반면 협업(collaborative) 아키텍처에서는 에이전트들이 P2P 방식으로 서로 직접 소통할 수 있고, 어떤 에이전트든 다음에 어떤 에이전트를 호출할지 결정할 수 있어 더 동적이고 유연하며 창발적인 문제 해결 전략이 가능해진다.

이런 오버헤드 때문에 멀티 에이전트 접근은 단일 에이전트가 다음 한계 가운데 하나에 부딪힐 때 대체로 정당화된다.

이런 구체적 제약을 풀고 있는 것이 아니라면, 견고하고 프롬프트가 잘 설계된 단일 에이전트에서 시작하는 것이 안정적이고 비용 효율적인 프로덕션 배포를 위한 권장 경로다.

많은 팀에게 멀티 에이전트 설계로 들어가는 안정적인 길은 오케스트레이터–워커 패턴이다. 중앙의 오케스트레이터 에이전트가 과제를 분해해 전문 하위 에이전트를 (병렬로) 호출하고, 하위 에이전트끼리의 직접 통신은 허용하지 않는다. 이 중간지대는 더 예측 가능한 오케스트레이션을 가능하게 하고, 진정한 P2P 에이전트의 “창발적 혼돈”을 피하며, 각 하위 에이전트가 필요한 데이터만 보게 하는 맥락 격리를 제공해 컨텍스트 창을 깨끗하고 추론을 예리하게 유지한다.

에이전틱 활용 사례

어떤 신기술이든 진짜 척도는 실질적인 사업 가치를 전달하는 능력이다. AI 에이전트도 다르지 않고, 이미 이론적 잠재력을 넘어 광범위한 산업과 사용 사례에서 측정 가능한 영향을 만들어내고 있다.

고객 서비스

고객 서비스 챗봇은 새롭지 않다. 기업 웹사이트에서 꽤 오래 봐왔지만 압도적인 평가는 “괜찮다”이고 “훌륭하다”는 아니다. 일차적 이유는, 몇 예외를 빼면 전통적 챗봇이 고정된 수작업 워크플로로 설계되어 꼼꼼히 만들고 계속 갱신해야 했다는 점이다. 다시 말해 미리 정해진 질문 집합에 어떻게 응답할지 결정하는 거대한 “if-then-else” 뭉치였다.

LLM 기술로 이것이 빠르게 바뀌고 있고, AI 에이전트는 고객 서비스를 반응적이고 비용 집약적인 기능에서 능동적이고 개인화되고 효율적인 브랜드 차별화 요소로 바꾸고 있다. 관련 콘텐츠를 검색하는 도구를 갖춘 에이전트만으로도 극적으로 나은 경험을 만들어 고객 만족을 높이고 실시간 인간 상담원의 필요를 줄일 수 있다.

환각 완화에 더해 사용자 경험도 고려해야 한다. 챗봇을 개인화하면 환각을 줄이는 것만이 아니라 훌륭한 사용자 경험을 만드는 데도 크게 기여한다. 은행이라면 일반적인 은행 정보만이 아니라 고객의 개인 금융 기록에 근거해 그의 구체적 상황에 맞춘 “금융 조수” 챗봇을 만들 수 있다.

금융 서비스

투자 분석, 실사, 컴플라이언스 감시 같은 핵심 금융 프로세스는 전통적으로 수작업이고 시간을 잡아먹으며 인간 오류에 취약하다. 금융 서비스 기업들은 이 워크플로를 놀라운 효율로 자동화하는 전문 금융 에이전트를 만들고 있다.

의료

의료에서 에이전트의 핵심 응용은 임상 문서화의 무거운 부담이 낳는 의사 소진을 덜어 주는 일이다. 에이전트가 의사–환자 대화를 실시간으로 들어 임상 노트, 요약, 처방 지시를 자동 생성하고, 의사가 빠르게 검토해 승인할 진료 후 요약 초안을 만들어낸다.¹

AI 코딩 에이전트

최근까지 코딩 조수는 개발자의 생산성을 돕기 위해 비교적 단순한 코드 제안과 구문 강조를 제공했다. LLM의 등장으로 이 지형이 급격히 바뀌었다. ChatGPT가 공개되자 코드 생성이 이 모델들이 뛰어난 과제 가운데 하나임이 즉시 분명해졌고, 이후 세대는 정확도가 진화하면서 더 나은 성능을 보였다.

이 돌파는 깃허브 코파일럿의 도입으로 빠른 도약으로 이어졌다. 별도의 챗봇을 쓰는 대신, 개발자는 통합개발환경(IDE) 안에 자연어 서술로 코드 블록 전체를 생성할 수 있는 에이전트를 갖게 되었다. 모델이 단순한 참조 도구에서 코딩 과정의 능동적 참여자로 바뀌었고, 개발자의 즉각적 워크플로 안에서 실시간 생성과 리팩터링이 가능해졌다.

이는 곧 더 통합되고 야심 찬 도구로 이어졌다. Cursor나 Windsurf(현재 Antigravity)가 AI 네이티브 IDE로 등장했고, Claude Code, Gemini CLI, OpenAI Codex 같은 AI 명령줄(CLI) 도구도 나왔다. IDE가 시각적 작성 경험의 향상에 집중하는 반면, CLI 기반 에이전트는 더 큰 자율성으로의 이동을 대표한다. 터미널에서 독립적 기여자로 작동하며 셸 명령을 실행하고 테스트 스위트를 돌리고 최소한의 감독으로 복잡한 워크플로를 관리한다.

주된 효과는 소프트웨어 엔지니어의 생산성이 크게 오르는 것이다. 보일러플레이트 코드 작성, 단위 테스트 생성, 대규모 리팩터링 지원, 즉각적 디버깅 제안을 자동화한다. 이 가속은 개발자가 루틴 코딩보다 고수준 시스템 설계와 아키텍처와 복잡한 문제 해결에 더 집중하게 해준다. 결과적으로 소프트웨어 엔지니어의 역할은 순수한 “코더”에서 “코드 디렉터” 또는 “리뷰어”로 진화하고 있다. 에이전트를 안내하고, 그 출력의 정확성과 보안을 검증하고, 생성된 구성요소를 더 큰 시스템에 통합하는 사람이다.

코딩 에이전트는 신제품의 시장 출시 시간을 단축하는 것만이 아니라, 일관된 테스트와 절차 준수를 보장함으로써 전반적인 소프트웨어 품질과 신뢰성도 개선한다. 더 나아가 엔지니어링과 제품 관리 사이의 역학을 바꾼다. 앤드루 응이 이것을 아주 간결하게 표현했다.

과거에 제품 관리자가 엔지니어링 팀과 함께 기능을 만들 때 완료까지 2주가 걸렸다면, 유능한 코딩 에이전트가 있으면 이제 두 시간이나 하루가 걸릴 수 있다. 얼마가 걸리든 반복 주기가 훨씬 짧아지고, 엔지니어링과 제품의 상호작용은 아주 다른 양상을 띤다.

에이전틱 루프

혼자 일하는 단일 에이전트든 멀티 에이전트 시스템의 일부든, 모든 AI 에이전트의 심장에는 연속적이고 반복적인 과정이 있다. 흔히 에이전틱 루프라 불리며 세 개의 구별된 단계로 이루어진다.

1. 관찰 — 루프는 에이전트가 현재 상태와 환경에 관한 정보를 수집하는 데서 시작한다. 이 최초 입력은 사용자 질의(“내 근처에서 평점이 가장 높은 이탈리안 식당을 찾아 줘”)일 수 있고, 이후 순환에서는 앞서 실행한 행동의 출력(웹 검색 도구 호출의 결과)일 수 있다.
2. 추론과 계획 — 최신 정보를 손에 쥔 에이전트의 LLM 두뇌가 추론에 들어간다. 최초 목표, 지난 단계의 기억, 새 관찰이라는 전체 맥락을 처리해 진척을 평가하고 다음의 논리적 단계를 결정한다. 그다음 계획을 세우고 목표 달성을 위해 어떤 도구를 어떤 인자로 호출할지 정한다.
3. 행동 — 오케스트레이션 계층이 계획을 실행한다. LLM의 도구 호출 요청을 해석해 주어진 인자로 실행하고, 그 결과를 LLM에 되돌려 준다. 도구는 검색이나 RAG 파이프라인을 호출하거나, 관계형 데이터베이스에 질의하거나, 내부·외부 API를 호출할 수 있다.

루프가 완료되면 에이전트는 도구 호출의 결과를 관찰하고, 이 순환은 추론 LLM이 전체 목표가 성공적으로 달성되었다고 판단할 때까지 반복된다. 에이전틱 루프의 단계를 이해하는 일이 에이전트를 성공적으로 디버깅하는 열쇠다. 루프가 반복적이기 때문에 “행동”의 실패는 다음 순환의 결함 있는 “관찰”로 연쇄되고, 적절한 계측 없이는 근본 원인을 짚어내기 어렵다.

도구 호출

도구 호출(함수 호출이라고도 한다)은 LLM이 에이전틱 워크플로의 능동적 참여자가 되게 하는, 최근에 생긴 역량이다. 2023년 초 메타 AI는 이 분야에서 가장 영향력 있는 논문 가운데 하나인 「Toolformer: Language Models Can Teach Themselves to Use Tools」를 발표했다. 연구자들은 Toolformer 모델을 학습시켜, 어떤 API를 호출할지, 언제 호출할지, 어떤 파라미터를 쓸지, 결과를 출력에 어떻게 반영하는 것이 최선인지 스스로 결정하게 만들었다.

또 하나의 결정적 발전이 2023년 구글 브레인 연구자들이 소개한 ReAct 프레임워크다. LLM이 추론과 행동 단계를 교차시키는 패러다임을 제안했다. 모델이 질의에 답하기 위해 무엇을 해야 할지에 관한 생각을 생성하고, 검색 엔진에 질의하는 등의 행동을 수행하고, 그 결과를 관찰해 다음 생각과 이어지는 행동을 결정한다. 추론과 행동의 이 반복 과정은 광범위한 과제에서 대단히 효과적임이 입증되어 도구 호출 LLM 개발의 토대 개념이 되었다.

연구가 이 개념들을 탐색해 온 동안, 실무적 채택은 상용 LLM에 통합되면서 왔다. 2023년 중반 OpenAI가 API에 함수 호출을 도입한 것이 그 분수령이었다. 도구 호출은 개발자가 모델에 함수를 서술하고, 모델이 필요한 인자를 담은 JSON 객체를 응답으로 생성하게 하는 구조화된 방법을 제공했다.

도구 호출이 어떻게 작동하는지 예를 본다. 먼저 get_weather라는 도구를 JSON으로 정의한다.

from openai import OpenAI

weather_tool = {
    "type": "function",
    "name": "get_weather",
    "description": """Get current temperature for provided coordinates in
                      Celsius.""",
    "parameters": {
        "type": "object",
        "properties": {
            "latitude":  {"type": "number"},
            "longitude": {"type": "number"}
        },
        "required": ["latitude", "longitude"],
        "additionalProperties": False
    },
}

def get_weather(latitude: float, longitude: float):
    # 실제로 날씨를 가져온다
    ...

client = OpenAI()
response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "user", "content": "What's the weather like in Oakland today?"}
    ],
    functions=[weather_tool],
    function_call={"name": "get_weather"}
)
response.choices[0].message.function_call

LLM의 응답은 이렇다. get_weather 도구를 위도 37.8044, 경도 -122.2711로 호출하라. 정확히 오클랜드의 위치다. 오케스트레이션 계층은 이제 이 도구 호출을 실행해 오늘 오클랜드의 실제 날씨를 얻고, 그 정보를 LLM에 되돌려 주며, LLM은 그것으로 사용자에게 갈 최종 응답을 만든다.

초기 구현은 흔히 사용자 질의당(또는 멀티턴 세션의 한 “턴”당) 하나의 도구 호출로 제한되었다. 그러나 더 복잡하고 효율적인 상호작용의 필요가 곧 분명해져 병렬 도구 호출이 개발되었다. LLM이 한 턴에 여러 도구를 호출하기로 결정할 수 있게 된 것이다. 엔비디아의 2021년, 2022년, 2023년 매출을 비교하려 한다면, 에이전트는 get_revenue(year, ticker) 도구를 ticker='NVDA'와 서로 다른 연도 값으로 세 번 병렬 호출할 수 있다. 이 호출들은 서로 독립적이기 때문이다.

도구 호출이 실패하는 방식과 완화

강력하지만 도구 호출은 완벽하지 않고, 프로덕션에서 쓰려면 도구의 세심한 설계가 필요하다. 에이전트의 핵심 실패 유형 하나가 잘못된 도구 사용이다. LLM이 잘못된 도구를 고르거나 인자에 잘못된 값을 넣어 호출하는 경우다. 도구 이름이나 설명이 겹치거나 모호할 때 특히 일어난다.

• 출력 검증 — 도구 이름과 인자가 유효한지 확인한다.
• 재시도 로직 — 도구 호출 오류 메시지를 LLM에 되먹인다.
• 실행 제약 — “최대 턴 수” 같은 제약으로 통제되지 않는 비용을 막는다.

그러나 신뢰성은 모델 선택에도 달려 있다. 서로 다른 LLM은 도구 사용에서 서로 다른 행동을 보인다. 같은 계열 안에서 버전을 올리거나(GPT-4에서 GPT-5로) 공급자를 바꾸면(GPT에서 Gemini나 앤스로픽으로) 동일한 도구 설명이 다른 결과를 촉발할 수 있다. 결국 프로덕션에서의 도구 사용 신뢰성은 도구 호출을 정화해야 할 예측 불가능한 입력으로 취급하는 일, 그리고 자기 도구 집합에 대해 정확성을 시험해 본 LLM을 고르는 일에 달려 있다.

에이전틱 도구의 효용이 분명해지면서 채택이 빠르게 가속되었다. 그러나 이 전문 도구의 폭발은 새 난제를 드러냈다. 에이전트가 그것들과 상호작용하는 통일된 방법의 부재다. 이 단편화가 모델 컨텍스트 프로토콜(MCP)의 무대를 마련했다.

모델 컨텍스트 프로토콜

MCP는 LLM이 도구를 호출하고 데이터에 접근하는 방식을 표준화하는 개방 프로토콜이며, 에이전트를 그것이 쓰는 도구의 구체적 구현 세부로부터 분리한다. 이 표준화가 어떤 데이터 소스나 API든 보편적 인터페이스를 통해 “에이전트 준비된” 상태가 되게 한다. 이를 위해 프로토콜은 MCP 서버가 자기 역량을 구조화된 방식으로 노출하는 세 개의 핵심 프리미티브를 정의한다.

MCP 아키텍처

MCP 아키텍처는 고전적인 클라이언트–서버 모델에 기반하며, AI 애플리케이션의 관심사와 도구 제공자의 관심사를 깔끔하게 분리한다. 세 개의 핵심 구성요소가 있다.

MCP는 메시지의 구조와 의미를 정의하면서 여러 전송 메커니즘을 지원한다. 로컬 프로세스를 위한 stdio(표준 입출력)와 원격 서버를 위한 Streamable HTTP가 여기 포함된다. 명세의 이전 버전은 HTTP 위의 서버 전송 이벤트(SSE)를 썼는데, 이제 MCP에서 레거시 접근으로 간주된다.

엔터프라이즈에서 MCP의 가치

MCP의 기술적 토대가 설득력 있지만, 엔터프라이즈 배포에서의 진짜 의미는 그것이 전달하는 구체적 사업 가치에 있다. MCP는 단순한 통합 프로토콜이 아니라 안전하고 확장 가능한 에이전틱 AI 애플리케이션을 만드는 토대적 조력자다.

에이전트 간 통신

MCP가 에이전트에게 도구에 대한 거버넌스된 접근을 준다면, A2A(Agent2Agent)는 에이전트끼리 소통하고 조율하게 하는 다른 프로토콜을 정의하며 MCP의 핵심 역량을 직접 보강한다. “프로젝트 관리자” 에이전트가 고수준 목표를 받아 A2A로 “데이터베이스 질의” 에이전트와 “보고서 작성” 에이전트에 하위 과제를 위임하는 식이다. 이는 MCP의 재사용성을 강화한다. 도구만 재사용 가능한 것이 아니라, 전문화된 에이전트 자체가 더 큰 지능 시스템의 모듈화되고 재사용 가능한 구성요소가 된다.

이것이 프로덕션의 벤더 상호운용성에 중요하다. 단편화된 엔터프라이즈 스택에서 “프로젝트 관리자” 에이전트는 구글 클라우드에 살고, “데이터베이스” 에이전트는 Salesforce의 전문 도구이고, “보고서 작성” 에이전트는 자체 구축한 내부 서비스일 수 있다. A2A는 이 서로 다른 환경 사이의 “보편적 통역사”로 기능한다. 표준 프로토콜을 따르면 벤더 쌍마다 부서지기 쉬운 맞춤 통합을 짜지 않고도 협업할 수 있다.

이 개방 프로토콜은 원래 구글이 Atlassian, Box, Cohere, Salesforce, SAP와 협력해 개발했고 지금은 리눅스 재단이 호스팅한다. 에이전트가 서로의 역량을 발견하고, 정보를 교환하고, 단일 에이전트가 혼자 다루기에는 너무 복잡한 과제를 합심해 수행하게 한다.

HTTP와 JSON 표준 위에 세워진 A2A의 핵심 구성요소 하나가 이른바 에이전트 카드(Agent Card)다. 각 에이전트의 디지털 프로필로 기능하며, 그의 구체적 기량, 수행할 수 있는 과제 유형, 처리할 수 있는 데이터를 서술한다. 어떤 에이전트가 도움이 필요하면 이 에이전트 카드를 참조해 필요한 역량을 가진 다른 에이전트를 검색하고 식별할 수 있다. 적합한 에이전트를 찾으면 안전하고 구조화된 대화를 시작해 과제를 위임하고 데이터를 공유하고 진척을 감시할 수 있다.

에이전틱 프레임워크 실습

LangChain으로 만드는 ReAct 챗봇

첫 예제는 LangChain으로 만드는 AI 챗봇이다. GPT-2 논문 「Language Models Are Unsupervised Multitask Learners」의 내용으로 질문에 답한다. 에이전트의 추론을 구동하는 데 ReAct 접근을 쓴다. 먼저 FAISS 검색기와 재순위기 없이, OpenAI 임베딩과 GPT-4o로 간단한 RAG 파이프라인을 만든다.

llm = ChatOpenAI(model="gpt-4o", temperature=0)
embeddings = OpenAIEmbeddings()

loader = PyPDFLoader("language_models_are_unsupervised_multitask_learners.pdf")
docs = loader.load_and_split()
text_splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=100)
texts = text_splitter.split_documents(docs)

vectorstore = FAISS.from_documents(texts, embeddings)
retriever = vectorstore.as_retriever()

rag_prompt = ChatPromptTemplate.from_template("""
Answer the question based only on the following context:
{context}
Question: {question}
""")

def format_docs(docs):
    return "\n\n".join(doc.page_content for doc in docs)

rag_chain = (
    {"context": retriever | format_docs, "question": RunnablePassthrough()}
    | rag_prompt | llm | StrOutputParser()
)

@tool
def rag_gpt_tool(question: str) -> str:
    """Use this tool to answer questions about the 'GPT-2' paper. It can answer
    any question related to this topic from that original paper."""
    return rag_chain.invoke(question)

tools = [rag_gpt_tool]
agent = create_react_agent(llm, tools)

question = ("What is the size of GPT-2 in terms of number of weights? "
            "How does that influence its performance?")

# 중간 이벤트를 스트리밍해 추론 단계를 관찰한다
for chunk in agent.stream({"messages": [("user", question)]}):
    ...

도구 설명이 결정적임을 유념할 만하다. rag_gpt_tool의 독스트링이 곧 에이전트가 이 도구의 쓸모를 판단하는 근거다. 실행 결과를 보면 ReAct 에이전트가 복잡한 질문을 두 개의 하위 질문으로 쪼갠 것이 드러난다.

ReAct 알고리즘은 각 하위 질문에 대해 관찰로 응답하고, 마지막으로 에이전트가 두 관찰에 근거해 최종 답을 조립한다. 물론 이것은 아주 단순한 사용 사례다. 프로덕션에서는 실패에 견디도록 여러 메커니즘을 더해야 한다. 타임아웃과 재시도 정책, (디버깅과 감사 가능성을 위한) 모든 도구 호출의 광범위한 트레이싱과 로깅, 그리고 도구 호출의 무한 루프를 피하기 위한 에이전트 실행 감시가 필요하다.

LlamaIndex로 만드는 문서 생성 에이전트

다음은 세 개의 도구를 쓰는 더 진전된 에이전트다. Tavily 서비스를 이용한 웹 검색 도구, 임의의 수식을 계산하는 계산 도구, 그리고 같은 GPT-2 논문에 근거해 응답을 생성하는 RAG 도구다. LlamaIndex의 FunctionAgent 클래스로 에이전트를 정의하고 앤스로픽의 Claude Sonnet 4.5를 두뇌로 쓴다.

from tavily import AsyncTavilyClient
from llama_index.core.tools import FunctionTool

TAVILY_API_KEY = os.getenv("TAVILY_API_KEY")

async def web_search(query: str) -> str:
    """Use the web to get up-to-date information and sources."""
    client = AsyncTavilyClient(api_key=TAVILY_API_KEY)
    result = await client.search(
        query, search_depth="advanced", include_raw_content=False
    )
    return str(result)

web_search_tool = FunctionTool.from_defaults(
    fn=web_search,
    name="web_search",
    description="""Search the web for fresh information and return relevant
                      results with links.""",
)

model_name = "claude-sonnet-4-5"
llm = Anthropic(model=model_name)
Settings.llm = llm

agent = FunctionAgent(
    tools=tools,
    llm=llm,
    system_prompt=(
        "You are a research & planning assistant. "
        "Use tools when helpful. Prefer rag_tool for questions about GPT-2 "
        "When using web_search, summarize concisely and include source links. "
        "Show brief, actionable plans."
    ),
)

ctx = Context(agent)
q1 = (
    "I'm planning a day trip to Santa Cruz this Saturday. "
    "Find 2-3 must-do activities (with links), estimate total ticket costs for "
    "two adults if needed, and suggest a 6-hour itinerary. Keep it tight."
)

handler = agent.run(user_msg=q1, ctx=ctx)

# 이벤트를 스트리밍해 도구 호출까지 관찰한다
async for event in handler.stream_events():
    if isinstance(event, ToolCall):
        print(f"\nToolCall: {event.tool_name} args={event}")
    elif isinstance(event, ToolCallResult):
        print(f"ToolResult ({event.tool_name}): {str(event.tool_kwargs)[:1000]}...")
    elif isinstance(event, AgentOutput):
        print(f"\nFinal: {event.response.content}\n")

두 가지를 주목할 만하다. 첫째, LlamaIndex 에이전트에는 질의만이 아니라 컨텍스트(ctx)도 제공한다. 질의와 응답 이력이 자동으로 저장되는 곳이다. 둘째, stream_events() 메서드로 도구 호출을 포함해 워크플로가 만들어내는 모든 이벤트를 순회하며 에이전트가 정확히 어떻게 행동하는지 볼 수 있다.

이 예제에서 에이전트는 여러 도구를 불러 과제를 해결했다. 먼저 web_search로 활동과 비용 정보를 얻고, 이어 계산 도구로 비용을 합산해 사용자에게 보고했다. LangChain이나 LlamaIndex 같은 오케스트레이션 프레임워크는 에이전트 구축의 추상화를 제공하지만, 에이전트 코드를 만들고 그것을 호스팅하고 실행할 기저 인프라를 관리하는 책임은 결국 자기 것이다.

Vectara로 만드는 에이전트

반면 Vectara 같은 에이전틱 플랫폼은 다른 접근을 제공한다. 에이전트 실행 전체가 관리되는 완전 관리형 플랫폼이며, 배포나 규모 운영을 걱정하지 않고 애플리케이션 로직에만 집중하게 해준다. Agents API가 에이전틱 루프의 복잡성을 추상화한다. 도구와 에이전트 서술과 지시를 정의하면 플랫폼이 LLM 상호작용과 오케스트레이션 로직을 대신 관리한다.

tool_configurations = {
    "rag_search": {
        "type": "corpora_search",
        "query_configuration": {
            "search": {
                "limit": 50,
                "corpora": [{"corpus_key": VECTARA_CORPUS_KEY,
                             "lexical_interpolation": 0.01}],
                "context_configuration": {"sentences_before": 2,
                                            "sentences_after": 2},
                "reranker": {"type": "customer_reranker",
                              "reranker_name": "Rerank_Multilingual_v1",
                              "cutoff": 0.3}
            },
        }
    },
}

create_agent_obj = {
    "key": "my-agent",
    "name": "GPT-2 Agent",
    "description": """This agent handles queries and conversations
                      related to the original GPT-2 paper about transformers.""",
    "tool_configurations": tool_configurations,
    "model": {"name": 'gpt-4o'},
    "first_step": {
        "type": "conversational",
        "instructions": [{
            "type": "inline",
            "name": "A Simple agent to ask questions about GPT-2 paper",
            "template": """
                You are a chatbot that can answer questions about the GPT-2
                paper. Only answer questions related to GPT-2 and the
                original paper, and based on information provided by the
                tools. Always respond to the user in English.
            """
        }],
        "output_parser": {"type": "default"}
    }
}

response = requests.post("https://api.vectara.io/v2/agents",
                         json=create_agent_obj, headers=headers)

고유 키를 가진 에이전트를 만들면 사용은 두 단계로 끝난다. 에이전트 세션을 만들고, 입력 질의를 보낸다.

# 1) 세션 생성
url = f"https://api.vectara.io/v2/agents/{agent_key}/sessions"
payload = json.dumps({"key": "session-1", "name": "A GPT-2 session",
                      "description": "Help users with questions about GPT-2",
                      "enabled": True})
requests.request("POST", url, headers=headers, data=payload)

# 2) 질의 전송
url = f"https://api.vectara.io/v2/agents/{agent_key}/sessions/{session_key}/events"
payload = json.dumps({
    "type": "input_message",
    "messages": [{"type": "text", "content": "What is GPT-2?"}],
    "stream_response": False
})
response = requests.request("POST", url, headers=headers, data=payload)
print(response.json()['events'][-1])

CrewAI로 만드는 멀티 에이전트 시스템

CrewAI는 여러 에이전트를 오케스트레이션해 복잡한 과제를 함께 수행하게 하는 프레임워크다. 핵심에서 멀티 에이전트 시스템은 각자 구별되는 역할과 배경 서술과 역량·도구 집합을 가진 전문 에이전트를 정의하고, 사용자 목표를 “크루” 안의 적절한 에이전트에게 배정된 구체적 과제로 분해해 집단적으로 해결하는 데 의존한다.

예제에서는 두 에이전트를 정의한다. 하나는 시장 조사 애널리스트 역할, 다른 하나는 기술 콘텐츠 전략가 역할이다. AI와 LLM의 신흥 트렌드 상위 세 가지에 관한 블로그 글을 쓰는 과제를 함께 맡긴다. 먼저 “리서치 에이전트”가 그 분야를 조사해 보고서를 작성하고, 그다음 “작성자 에이전트”가 그 보고서로 블로그 글을 만든다.

from crewai import Agent, Task, Crew, Process

# Agent 1: 시장 조사 애널리스트
researcher = Agent(
    role="Senior Market Research Analyst",
    goal="""Find groundbreaking and emerging trends in the field of
             Artificial Intelligence.""",
    backstory=(
        "You are an expert market research analyst with a keen eye for "
        "emerging technological trends. You continuously scan the "
        "horizon for a major technological shift..."
    ),
    verbose=True, allow_delegation=False,
)

# Agent 2: 기술 콘텐츠 전략가
writer = Agent(
    role="Technology Content Strategist",
    goal="""Craft a compelling and informative blog post based on research
             findings.""",
    backstory=(
        "You are a renowned content strategist known for simplifying complex "
        "technological topics into engaging narratives..."
    ),
    verbose=True, allow_delegation=False,
)

research_task = Task(
    description=(
        "Identify and analyze the top 3 most significant emerging trends in AI "
        "for the current year. Focus on trends related to large language "
        "models (LLMs), generative AI, and real-world applications..."
    ),
    expected_output=(
        "A detailed report containing three emerging AI trends. Each trend "
        "section must include: 1. Trend Title. 2. Concise summary. "
        "3. Explanation of potential market impact. 4. Key companies involved."
    ),
    agent=researcher
)

# context 파라미터로 의존 관계를 정의한다.
# 크루는 research_task를 먼저 완료해 그 출력을 writer_task에 넘긴다.
writer_task = Task(
    description=(
        "Using the research findings provided as context, write an engaging "
        "blog post suitable for a general tech audience..."
    ),
    expected_output=(
        "A well-structured and polished blog post of at least 500 words, "
        "formatted in Markdown."
    ),
    agent=writer,
    context=[research_task]
)

ai_trends_crew = Crew(
    agents=[researcher, writer],
    tasks=[research_task, writer_task],
    process=Process.sequential,
    verbose=True,
)
result = ai_trends_crew.kickoff(inputs={'topic': 'AI trends'})

과제를 여러 전문 에이전트에 분배하면 정보를 처리하고 행동을 실행하는 일을 병렬로 할 수 있어 흔히 더 빠른 문제 해결로 이어진다. 이 분배는 회복력도 만든다. 에이전트 하나의 실패가 반드시 시스템 전체의 실패를 낳지는 않으며, 단일 실패점을 가진 모놀리식 시스템과 뚜렷이 대비된다.

에이전틱 메모리

AI 에이전트의 맥락에서 메모리는 단계와 세션과 상호작용을 넘어 정보를 보유하고 활용하는 능력을 가리킨다. 에이전트가 상태 없는 “한 번 응답” 기계가 아니라 지속적이고 맥락을 아는 존재로 느껴지게 하는 것이 메모리다. 프로덕션 환경에서 메모리는 생애 주기와 목적에 따라 두 계층으로 나뉜다.

메모리는 모든 에이전트의 핵심 역량이 되어 가고 있다. 개인화(사용자의 과거 행동에 맞춘 행동), 연속성(과거 상호작용을 “기억”해 이후 과제가 더 자연스럽게 흐른다), 효율(질문을 반복하거나 도구로 정보를 다시 모으는 일을 피한다) 같은 중요한 역량을 제공하기 때문이다. 장기 메모리를 구현하기로 하는 결정은 에이전트를 일시적 도구에서 영구적인 데이터 관리자로 옮기며, 단순한 저장을 넘어 능동적인 “메모리 관리”로의 이동을 요구한다.

에이전틱 RAG로 메모리를 구현하기

단기 세션 이력(또는 세션 요약)과 깊은 시맨틱 조회의 균형을 잡으면, 역사적 잡음에 압도되지 않으면서 맥락적으로 예리한 에이전트를 만들 수 있다.

엔터프라이즈 가드레일 — 프라이버시와 완전성

세션 기반 저장과 시맨틱 조회의 결합이 더 정교한 에이전트 경험의 인지적 토대를 제공하는 동시에, 민감한 상호작용의 영구적 기록을 만들어낸다. 메모리의 지속성은 데이터 거버넌스와 보안에 관한 책임을 들여온다. 엔터프라이즈 환경에서 메모리 아키텍처는 세 가지 결정적 위험을 다뤄야 한다.

궁극적으로 정보를 장기적으로 지속시킬지의 결정은 그 정보가 재사용 가능한 것인지, 단지 과도적인 것인지에 따라 결정되어야 한다.

AI 에이전트의 평가와 관측성

에이전트를 프로덕션에 배포할 때 이해해야 할 점이 있다. 1990~2000년대의 규칙 기반 에이전트라는 결정론적 선조들과 달리, 이들은 새롭고 까다로운 실패 유형의 지형을 갖는다. 결함 있는 코드 한 줄로 추적되는 전통적 소프트웨어 버그가 아니다. 에이전트의 복잡성과, 워크플로에서 비결정적 LLM이 담당하는 내재적 역할에서 발생하는 체계적이고 행동적인 문제다.

전통적 관측성 도구는 결정론적 시스템의 건강과 성능을 감시하도록 설계되었다. CPU와 메모리 사용률, 네트워크 처리량, 애플리케이션 오류율, 요청 지연 같은 잘 정의된 시스템 수준 지표의 추적에 뛰어나다. 이 지표들은 인프라 건강 평가에 결정적이며, 시스템의 기능적 정확성을 그 운영적 안정성으로부터 추론할 수 있다는 가정 위에 세워져 있다. 에이전트에서 이 가정은 완전히 무너진다.

에이전틱 관측성

업계는 전통적 모니터링을 넘어 더 포괄적인 패러다임, AI 에이전트 관측성으로 빠르게 이동하고 있다. 이 접근은 에이전트가 내부적으로 어떻게 작동하는지 깊이 들여다볼 가시성을 제공하려 하며, 디버깅과 거버넌스와 지속적 개선에 필요하다.

핵심은 에이전트의 완전한 종단간 행동을 감시하고 이해하고 분석하는 역량이다. 내부 추론, 의사결정 과정, 그리고 (직접 또는 MCP 서버를 통한) 도구와의 상호작용까지 포함한다. 관측성의 전통적 세 기둥인 지표, 로그, 트레이스가 에이전트가 무엇을 하고 있는지에 관한 원시 텔레메트리를 제공하고, 그 위에 에이전트에 특수한 두 역량이 더해진다.

• 평가(evaluations)는 정성적·정량적 평가의 계층을 더해 이 질문에 답한다. “에이전트가 자기 과제를 얼마나 잘 수행하고 있는가?”
• 거버넌스(governance)는 규칙과 정책의 틀을 제공해 이 질문에 답한다. “에이전트가 안전하게, 규정된 경계 안에서 작동하고 있는가?”

이 패러다임의 궁극적 목표는 투명성이다. 에이전트를 헤아릴 수 없는 “불투명한 상자”에서 더 이해 가능한 “유리 상자”로 바꾸는 일이다. 이 투명성이 신뢰와 책임성과 신뢰성에 중요하다. 그것이 없으면 실패의 근본 원인을 두고 추측만 하게 되고, 에이전트의 결정을 확신할 수도, 미션 크리티컬한 응용에 자율 시스템을 책임 있게 배포할 수도 없다.

에이전트를 트레이싱하기

관측성의 모든 구성요소가 중요하지만 트레이싱은 에이전트 행동을 이해하는 초석 기법으로 두드러진다. 트레이스는 단일 요청의 전체 실행 흐름을 최초 사용자 입력에서 최종 출력까지, 스팬(span)이라 불리는 구조화된 계층적 이벤트 연쇄로 포착한다. 각 스팬은 워크플로 안의 이산적 작업 단위를 나타낸다. 추론을 위한 LLM 호출, RAG 도구 질의, text2SQL 도구 호출 같은 것들이다.

이 (잠재적으로 중첩된) 스팬을 시각화하면 어떤 상호작용에서든 에이전트의 사고 연쇄를 효과적으로 재구성해 분석할 수 있다. 이 단계별 조망은 다음 질문에 직접 답을 주므로 디버깅과 최적화에 값을 매길 수 없다.

• 각 추론 단계에서 LLM에 보낸 정확한 프롬프트는 무엇이었는가.
• 에이전트는 어떤 도구를 어떤 파라미터로 호출하기로 결정했는가.
• 도구는 어떤 데이터를 돌려주었고, 에이전트는 그것을 어떻게 해석했는가.
• 각 단계는 얼마나 걸렸고, 지연 병목은 어디인가.

이 세밀한 가시성이 표면에서는 보이지 않을 실패 유형을 정확히 식별하게 한다. 최적 항공편을 찾는 과제를 받은 에이전트가 search_flights 도구를 잘못된 인자로 호출하다가 다섯 번째 시도에서야 성공했다고 하자. 최종 출력의 단순한 로그는 이 비효율을 드러내지 않지만, 트레이스는 연속된 여러 개의 search_flights 스팬을 명확히 보여 잘못된 도구 호출을 즉시 부각시킨다. 트레이싱은 성능 문제도 드러낸다. 각 스팬의 지속 시간을 살펴보면 22초의 총 응답 시간이 네 개 도구 연쇄 가운데 느린 API 호출 하나 때문이었음을 식별하고, 실행 흐름을 더 디버깅하고 최적화할 수 있다.

에이전틱 관측성 지표

트레이스가 개별 실행에 대한 정성적이고 깊은 조망을 제공한다면, 지표는 시간에 걸친 성능의 정량적이고 집계된 조망을 제공한다.

이 지표들을 관측 스위트에서 측정할 수 있게 되면, 주 단위나 월 단위로 추적해 시간에 따른 변화를 식별하고 회귀를 잡아내는 일이 중요하다.

에이전틱 관측성 도구

에이전트의 빠른 부상은 필요한 관측성을 제공하도록 설계된 전문 도구 생태계의 발전을 낳았다. 이 지형은 개방 표준을 중심으로 응집하면서 오픈소스와 상용 플랫폼의 경쟁적 배열을 함께 갖추고 있다.

이 분야의 결정적 발전이 OpenTelemetry(OTel)를 통한 AI 텔레메트리의 표준화다. OTel은 벤더 중립적인 오픈소스 프로젝트로, 애플리케이션을 계측해 텔레메트리 데이터(트레이스, 지표, 로그)를 생성하고 내보내는 통일된 API와 SDK와 도구를 제공한다. OTel 안의 GenAI 특별관심그룹(SIG)이 AI에 특화된 의미 규약을 정의해, LLM 호출과 도구 사용과 벡터 데이터베이스 질의 같은 연산을 서술하는 공통 언어를 만들고 있다. 이 표준화는 결정적이다. 벤더 종속을 막고, 어떤 OTel 호환 프레임워크로든 에이전트를 만들어 어떤 OTel 호환 백엔드로든 텔레메트리를 보낼 수 있게 해 상호운용적이고 경쟁적인 도구 시장을 키운다.

Vectara 같은 AI 에이전트 플랫폼은 이 수준의 관측성을 플랫폼 자체에 포함하고 API로 접근을 제공한다. 어떤 제품을 쓰든, OpenTelemetry라는 공통 표준으로 통일된 강력한 에이전틱 관측성이 있으면 프로덕션 배포 요구를 진전시키는 동안 엔터프라이즈 에이전트를 지탱할 수 있다.