.png)
LLM에 Tool Calling만 붙인다고 AI Agent가 되지 않는 이유
기획연재 1편 : 챗봇의 성공 공식이었던 'LLM + RAG'는 실행형 AI Agent에 그대로 통하지 않는다. 프로덕션 Agent의 성패는 더 똑똑한 모델이 아니라 업무 시스템·권한·의미 구조·검증·비용 통제가 가른다.
📚 연재 안내 | 이 글은 2부작 연재의 1편입니다.
① LLM에 Tool Calling만 붙인다고 Agent가 되지 않는 이유(현재 글)
② 실무에 AI Agent를 넣는 법 — 설정 Copilot 패턴
AI Agent를 만든다고 하면 머릿속에 자연스레 그려지는 그림이 있습니다. 성능 좋은 모델을 하나 고르고, 사내 문서를 벡터로 임베딩해 RAG로 붙이고, 도구 몇 개를 API로 열어 줍니다. 그러면 Agent가 알아서 업무를 처리해 줄 것 같습니다.
챗봇이라면 이 그림이 꽤 잘 맞습니다. 사용자가 질문하고, AI가 관련 문서를 찾아 답하고, 최종 판단은 사람이 합니다.
그래서 많은 분이 같은 방식으로 Agent에 접근합니다.
"좋은 LLM에 RAG랑 Tool Calling만 붙이면 Agent 아닌가?"
이 질문은 자연스럽습니다. 하지만 프로덕션 환경에서 실제로 일을 시키는 Agent를 만들어 보면, 이 접근이 어디서 무너지는지가 금방 드러납니다. 결론부터 말씀드리면, 프로덕션 AI Agent는 '똑똑한 챗봇'이 아니라, 업무 시스템 안에서 LLM을 안전하고 경제적으로 사용하는 방식입니다.
한 가지 짚고 시작하겠습니다. 이 글에서 말하는 AI Agent는 단순 질의·응답형 Agent가 아니라, 외부 도구를 호출해 업무 시스템의 상태를 바꿀 수 있는 실행형 프로덕션 Agent를 뜻합니다. 물론 챗봇에도 도구 실행이나 승인 흐름이 들어갈 수 있지만, 이 글의 초점은 '실행'이 곧 부수효과가 되는 Agent에 있습니다.
모델은 두뇌일 뿐입니다. 프로덕션 Agent는 업무 시스템이라는 '운동장' 안에서 비로소 안전하게 일합니다.
챗봇의 실수는 사람이 거르지만, Agent의 실수는 시스템에 남는다
챗봇과 Agent의 가장 큰 차이는 모델 성능이 아닙니다. 출력이 무엇을 만드는가입니다.
챗봇은 답변을 만듭니다. Agent는 실행을 만듭니다. 고객을 선별하고, 쿠폰을 발행하고, 메시지를 보내고, CRM 상태를 바꾸고, 외부 API를 호출하고, 비용을 발생시킵니다.
여기서 결정적인 차이가 생깁니다. 챗봇이 틀린 답을 하면 사용자는 "이건 좀 아닌 것 같은데?" 하고 걸러낼 수 있습니다. 하지만 Agent가 잘못된 고객에게 쿠폰을 발행하거나, 수신 동의가 없는 고객에게 메시지를 보내거나, 예산을 초과해 캠페인을 실행하면, 그 순간 업무 시스템에는 이미 되돌리기 어려운 흔적이 남습니다.
그래서 프로덕션 AI Agent 개발은 프롬프트를 잘 쓰는 문제가 아닙니다. 업무 시스템 안에서 AI의 판단을 어디에 배치하고, 무엇을 제한하고, 어떤 실행을 검증할 것인가의 문제입니다.
💡 핵심 요약 · 챗봇과 Agent는 무엇이 다른가
① 챗봇의 출력은 '판단 보조 자료' — 실수해도 사람이 읽고 거른다
② Agent의 출력은 '부수효과를 가진 실행' — 실수하면 시스템에 흔적이 남는다
③ 그래서 Agent에 필요한 건 더 똑똑한 답변이 아니라 권한·예산·중복 방지·수신 동의·감사로그·실패 복구 → 이 차이가 뒤에서 이야기할 '업무 시스템과의 결합'이 필요한 이유입니다.
챗봇의 성공 공식이 그대로 통하지 않는 이유
사내 문서 Q&A처럼 범위가 제한된 챗봇의 목적은 대부분 '답변'입니다. "이 정책이 뭐야?", "지난 회의 내용을 요약해줘" 같은 질문에는 성능 좋은 LLM에 적절한 지식 베이스를 붙이고 RAG를 구성하면 상대적으로 만족스러운 사용자 경험을 만들기 쉽습니다. 이 구조에서 AI의 역할은 검색·요약·설명·추천·초안 작성, 즉 '판단 보조'입니다. 실수가 있어도 사람이 읽고 판단하니, LLM + RAG 공식이 잘 맞습니다.
문제는 이 공식을 그대로 Agent에 가져갈 때 시작됩니다.
같은 질문도 챗봇과 Agent에게는 전혀 다른 일이 됩니다. "최근 제품 A에 관심이 높은 고객군을 알려줘" 라고 챗봇에게 물으면, 챗봇은 후보와 근거를 설명해 주고 사용자가 직접 대상을 고릅니다. 하지만 "최근 제품 A에 관심이 높은 고객에게 할인 쿠폰을 발행해줘" 라고 Agent에게 지시하면, 이제 AI는 대상을 고르고, 금액을 정하고, 발행 API를 호출하고, 메시지를 보낼 수 있습니다.
이때 필요한 것은 '더 똑똑한 답변'이 아닙니다. 권한, 예산, 중복 방지, 수신 동의, 감사 로그, 실패 복구입니다.
Agent의 출력은 '답변'이 아니라 부수효과를 가진 실행 후보로 다뤄야 합니다. 이 한 줄이 챗봇과 프로덕션 Agent를 가르는 출발점입니다.
챗봇의 출력은 '답변'이지만, Agent의 출력은 부수효과를 가진 '실행'입니다. 그래서 권한·검증·감사가 필요합니다.
Hermes Agent가 보여주는 변화: Agent는 '운영 런타임'이 되어 가고 있다
Hermes Agent는 이 변화를 설명하기 좋은 사례입니다. Hermes Agent는 LLM을 감싼 단순 챗봇이 아니라, 장기 기억·스킬(절차 문서)·예약 실행·하위 Agent 위임처럼 '실제로 업무를 수행하기 위한' 런타임 기능을 갖춘 에이전트 시스템입니다[1]. 즉 Agent가 실제로 '일하기 위해' 무엇이 필요한지를 잘 보여 주는 사례입니다.
지속 기억(Persistent Memory):
MEMORY.md, USER.md 같은 장기 기억 파일과 세션 검색을 구분해 다루고, 과거 대화는 SQLite FTS5 기반으로 검색합니다.
스킬(Skill):
필요할 때만 로드되는 지식 문서로, When to Use, Procedure, Pitfalls, Verification 같은 구조를 갖습니다.
예약 실행(Cron):
자연어나 cron 표현식으로 반복 작업을 예약하고, 필요하면 LLM 없이 스크립트 전용 모드로도 실행합니다.
하위 Agent 위임(Subagent Delegation):
격리된 컨텍스트와 제한된 도구를 가진 자식 Agent를 만들고, 최종 요약만 부모 컨텍스트로 돌려보냅니다.
이것이 시사하는 바는 명확합니다. Hermes Agent가 보여 주는 것은 "좋은 LLM을 붙이면 Agent가 된다" 가 아니라, Agent가 실제로 일하려면 기억·절차·스케줄·도구·위임·제한이 필요하다는 사실입니다.
직관적으로 비유하면 이렇습니다. LLM이 두뇌라면, Hermes Agent 같은 런타임은 두뇌가 일하도록 수첩·작업 매뉴얼·알람·도구 상자·보조 인력·작업 공간을 갖춰 주는 환경입니다.
그런데 여기서 더 중요한 질문이 생깁니다. Agent가 기억하고, 학습하고, 예약 실행하고, 하위 Agent에게 일을 나눌 수 있다면 우리는 무엇을 허용하고 무엇을 막아야 할까요? 이 질문이 바로 프로덕션 AI Agent 개발의 진짜 출발점입니다.
Hermes Agent의 자율성만으로는 프로덕션이 되지 않는다
Hermes Agent는 최신 Agent 패턴을 이해하기에 좋은 사례지만, 기업 업무 시스템에 그대로 넣기에는 부족합니다.
개인이나 팀 단위 Agent가 내 파일을 정리하고 정기 리포트를 만드는 것과, 엔터프라이즈 SaaS 안에서 고객 데이터와 캠페인 예산을 다루는 것은 전혀 다른 문제이기 때문입니다. 기업 환경에서는 다음 질문에 답할 수 있어야 합니다.
따라서 Agent 개발의 핵심은 Agent를 더 자유롭게 만드는 것이 아닙니다. 자율성을 업무 시스템의 경계 안에 넣는 것입니다.
팔란티어 FDE가 시사하는 것: Agent에는 '업무의 운동장'이 필요하다
이 지점에서 팔란티어(Palantir)의 FDE(Forward Deployed Engineer) 개념은 좋은 비유가 됩니다. FDE는 본래 고객사 현장에 직접 들어가, 그들의 데이터·업무 프로세스·시스템에 맞춰 소프트웨어를 구축하고 통합하는 엔지니어를 가리킵니다.
프롬프트 엔지니어가 "말을 잘하는 AI" 를 훈련하는 사람이라면, FDE는 AI가 사내 데이터와 권한 속에서 사고 치지 않고 일하도록 업무의 운동장을 설계하는 사람에 가깝습니다.
팔란티어의 AI FDE는 자연어 요청을 Foundry 작업으로 변환해 데이터 파이프라인 수정, 코드 저장소 관리, Ontology 생성·유지 같은 일을 수행하는 대화형 Agent로 설명됩니다[2]. 중요한 점은 이 Agent가 사용자의 기존 권한을 따르고, 사용자의 세션 안에서 동작하며, 기존 거버넌스와 감사 로그의 적용을 받는다는 것입니다. 즉 "LLM이 알아서 운영 시스템을 바꾼다" 가 아니라, 자연어를 업무 플랫폼의 작업 단위로 변환해 권한·도구·검증·리뷰 체계 안에서 실행한다는 메시지입니다.
팔란티어의 Ontology 문서도 같은 방향을 가리킵니다. Ontology를 단순 데이터 모델이 아니라 기업의 의사결정을 표현하는 시스템으로 보고, 의사결정을 Data, Logic, Action, Security의 결합으로 설명합니다. 이 프레임은 프로덕션 AI Agent에 그대로 적용됩니다.
Agent가 이해해야 하는 것은 단순 데이터가 아니라 업무의 의미 구조입니다. 고객·상품·캠페인·세그먼트·쿠폰·예산·수신 동의·발급 이력 같은 개념이 시스템 안에서 명확히 정의되어 있어야, Agent가 "무엇을 해도 되는지" 와 "무엇을 하면 안 되는지" 를 구분할 수 있습니다.
Agent가 이해해야 할 것은 단순 데이터가 아니라, Data·Logic·Action·Security로 짜인 업무의 '의미 구조'입니다.
RAG 공식도 Agent 시대에는 다시 봐야 한다
여기서 RAG 이야기도 다시 봐야 합니다. "RAG가 필요 없다" 는 뜻이 아닙니다. RAG는 여전히 중요합니다. 다만 챗봇 시대의 RAG 공식 — "비슷한 문서를 찾아 모델에 넣으면 된다" — 이 실행형 Agent에 그대로 통하지는 않습니다.
챗봇에서는 의미적으로 유사한 문서가 유용합니다. 하지만 Agent에서는 비슷한 정보보다 정확한 원문, 현재 상태, 권한, 실행 계약이 더 중요할 때가 많습니다.
최근 검색 연구도 이 변화를 뒷받침합니다. 다만 결론은 "직접 검색이 늘 벡터 검색보다 우월하다" 가 아니라, 검색 성능이 Agent 실행 환경(harness)과 도구 결과 전달 방식에 크게 좌우된다는 쪽에 가깝습니다. 대화 기록(장기 기억)을 대상으로 한 Is Grep All You Need? [3]는 grep과 벡터 검색을 Claude Code·Codex·Gemini CLI 등 여러 harness에서 비교했는데, 여러 조건에서 grep이 벡터 검색보다 나은 결과를 보였지만 전체 점수는 어떤 harness와 도구 호출 방식을 쓰느냐에 따라 크게 달라졌습니다. 저장소 수준 코드 검색을 다룬 GrepRAG [4]에서도 LLM이 ripgrep 명령을 생성해 원문을 찾는 단순한 방식이 그래프 기반 기준 모델과 견줄 만한 성능을 보였습니다.
이 흐름의 핵심은 "벡터 검색을 버리자" 가 아닙니다. 핵심은 이것입니다.
Agent 개발에서 중요한 것은 "벡터 DB를 붙였는가" 가 아니라, Agent가 업무에 필요한 정확한 컨텍스트에 어떤 해상도로 접근하는가입니다.
문서 Q&A에는 벡터 검색이 적합할 수 있습니다. 코드 수정에는 원문 검색과 심볼 탐색이 더 중요할 수 있습니다. 캠페인 실행에는 고객 상태·발급 이력·수신 동의·예산·정책 엔진이 더 중요할 수 있습니다. 프로덕션 Agent는 단일 RAG 파이프라인이 아니라, 업무 시스템의 상태와 의미 구조를 읽는 여러 도구를 필요로 합니다.
덧붙이면, RAG가 사라지는 것은 아닙니다. 오히려 더 정확하고 효율적인 검색으로 진화하고 있습니다. 특히 데이터를 복사·이동 없이 원본 위치에서 접근하는 제로카피(zero-copy) 기반 RAG는 대규모 업무 데이터를 다루는 Agent에서 비용과 지연을 줄이는 핵심 기법이 될 수 있는데, 이는 별도의 후속 글에서 자세히 다루겠습니다.
오케스트레이션 만능주의의 함정: Agent를 늘리면 비용도 늘어난다
최근 agentic AI 설계에서는 Planner / Executor / Critic / Verifier / Reviewer Agent를 줄줄이 붙이는 패턴이 자주 보입니다. 데모에서는 매우 설득력 있어 보입니다. Agent가 실수할 수 있으니 또 다른 Agent가 검토하게 만드는 것이니까요.
하지만 실제 업무에 적용하면 가장 먼저 부딪히는 문제는 정확도가 아니라 비용과 속도입니다. 검증 Agent도 결국 또 하나의 LLM 호출입니다. 검증 Agent가 원문을 다시 검색하고, 도구를 다시 호출하고, 실패 시 재시도까지 수행하면, 하나의 업무 실행이 여러 개의 Agent 실행 흐름으로 불어납니다.
이 경고는 데이터로도 뒷받침됩니다. Gartner는 agentic 모델이 표준 생성형 AI 챗봇보다 작업당 5~30배 많은 토큰을 요구할 수 있고, 토큰 단가가 낮아지더라도 사용량 증가가 더 빠르면 전체 추론 비용은 오히려 늘 수 있다고 전망했습니다[5]. 그러면서 루틴하고 고빈도인 작업은 더 작은 모델이나 도메인 특화 모델로 라우팅하고, 비싼 frontier 추론은 고부가가치 복잡 추론에만 제한하라고 제안합니다.
현장 사례도 같은 경고를 줍니다. Fortune 보도에 따르면 Uber는 2026년 AI 코딩 도구에 책정한 연간 예산을 약 4개월 만에 소진했는데, 직원들의 도구 사용량을 사내 순위로 독려하면서 Claude Code 사용이 빠르게 늘어난 결과였습니다. Uber의 사장 겸 COO Andrew Macdonald는 Claude Code 사용량 증가가 실제 소비자 기능의 증가로 직접 이어지는지는 아직 분명하지 않다고 지적했습니다[6]. 토큰 단가가 떨어져도 사용량이 더 빠르게 늘면 총비용은 오히려 증가하는, 이 글이 짚어 온 비용 구조가 현장에서도 그대로 드러난 셈입니다.
💡 핵심 요약 · Agent는 공짜 실행 단위가 아니다
① 검증 Agent를 하나 더 붙일 때마다 LLM 호출·도구 호출·재시도·로그 비용이 함께 늘어난다
② 토큰 단가는 떨어져도 사용량이 더 빨리 늘면 총비용은 증가할 수 있다
③ 더 많은 토큰이 더 나은 결과를 보장하지 않는다 → 프로덕션에서는 자율성뿐 아니라 '비용과 속도'도 아키텍처의 일부입니다.
검증 Agent를 하나 더 붙일 때마다 토큰·도구 호출·재시도 비용이 함께 늘어납니다. 자율성은 공짜가 아닙니다.
프로덕션 Agent는 LLM이 아니라 업무 시스템과 조화되는 실행 컴포넌트다
결국 프로덕션 AI Agent의 핵심은 더 똑똑한 LLM을 고르는 일이 아닙니다. LLM은 Agent의 일부일 뿐입니다. 진짜 Agent는 업무 시스템의 데이터 모델·권한 체계·이벤트 흐름·자동화 엔진·검증 규칙·감사 로그와 결합될 때 만들어집니다.
이 구조는 저희가 ICE Platform과 MetaFlyer를 설계하며 얻은 엔지니어링 결론이기도 합니다. ICE Platform은 LLM/RAG/Agent를 별도 시스템으로 붙이는 방식이 아니라 KB, KG, Agent, MCP, A2A를 플랫폼 features로 내장하고, NodeHistory·Event log·KG Evidence 같은 운영 추적 구조를 같은 노드 모델 위에 남기는 방향을 택했습니다. AI Insight Studio 역시 단순 챗봇이 아니라 KB·KG·Ontology·Agent Builder·Automation 실행 엔진·Analytics 자산을 하나의 Canvas 안에서 질문 → 분석 → 검증 → 리포트 → 자동 실행으로 잇는 환경으로 정의됩니다.
AI Agent를 실제 업무에 넣으려면, Agent를 따로 띄우는 것이 아니라 업무 시스템 안으로 넣어야 합니다. 데이터 모델을 이해하고, 권한을 지키고, 실행 경로를 따르고, 검증 결과를 남기고, 비용을 통제해야 합니다.
마치며: Agent는 '똑똑한 챗봇'이 아니다
AI Agent는 똑똑한 챗봇이 아닙니다. LLM에 Tool Calling을 붙인 것도, RAG를 더한 도구 호출 앱도 아닙니다. 프로덕션 AI Agent는 업무 시스템과 조화를 이루는 지능형 실행 컴포넌트입니다.
Hermes Agent는 Agent가 기억하고, 절차를 축적하고, 예약 실행하고, 하위 Agent에게 일을 나누는 방향을 보여 줍니다. 팔란티어의 FDE와 Ontology는 그 Agent가 실제 업무 현장에 들어가려면 무엇이 필요한지 보여 줍니다. Gartner와 Uber 사례는 오케스트레이션이 비용 구조와 조화되지 않으면 프로덕션에서 지속되기 어렵다는 점을 보여 줍니다.
정리하면 이렇습니다.
AI Agent는 LLM이 아닙니다. AI Agent는 업무 시스템 안에서 LLM을 안전하고 경제적으로 사용하는 방식입니다.
🚀 다음 글 예고
1편이 "왜 LLM에 Tool Calling만 붙여서는 AI Agent가 되지 않는가" 라는 관점의 문제였다면, 다음 2편에서는 이 관점을 실무에 넣는 법으로 바꿔, 특히 Agent를 실행자가 아니라 설정 Copilot으로 두는 패턴을 다룹니다. 특정 제품 홍보 페이지를 방문한 고객 중 구매 가능성이 높은 사람에게 할인 쿠폰을 발행하는 시나리오를 예로 들어, 좋은 설계와 나쁜 설계를 나란히 비교하겠습니다. Agent에게 모든 것을 맡기면 왜 위험한지, 업무 시스템 안에 Agent 판단 노드를 넣는다는 것이 무엇인지, 그리고 더 실용적으로 Agent가 룰과 자동화 설정을 어떻게 제안·검증·고도화할 수 있는지를 살펴보겠습니다.
참고자료
[1] Hermes Agent 공식 문서 — Memory · Skills · Cron · Subagent Delegation, Nous Research (https://hermes-agent.nousresearch.com/docs)
[2] Palantir — AI FDE Overview (https://palantir.com/docs/foundry/ai-fde/overview/)
[3] Is Grep All You Need? How Agent Harnesses Reshape Agentic Search — arXiv:2605.15184 (https://arxiv.org/abs/2605.15184)
[4] GrepRAG: An Empirical Study and Optimization of Grep-Like Retrieval for Code Completion — arXiv:2601.23254 (https://arxiv.org/abs/2601.23254)
[5] Gartner — By 2030, Inference on a 1-Trillion-Parameter LLM Will Cost GenAI Providers Over 90% Less Than in 2025, 2026.03.25 (https://www.gartner.com/en/newsroom/press-releases/2026-03-25-gartner-predicts-that-by-2030-performing-inference-on-an-llm-with-1-trillion-parameters-will-cost-genai-providers-over-90-percent-less-than-in-2025)
[6] Fortune — Uber burned through its entire 2026 AI budget in four months, 2026.05.26 (https://fortune.com/2026/05/26/uber-coo-ai-spending-tokens-claude-code/)
