3. AI 에이전트의 두뇌 : LLM·RAG·Tool Use·Memory 구조 정리
- AI 에이전트는 LLM·RAG·Tool Use·Memory 네 가지 요소가 유기적으로 결합된 시스템입니다
- 기업에서 AI 에이전트가 제대로 작동하려면 RAG를 통한 신뢰할 수 있는 기업 데이터 연결이 핵심입니다
- 네 요소 중 하나라도 부실하면 비싸고 화려한 잘못된 결정 기계가 됩니다
자동차는 엔진·변속기·연료·전자제어장치가 함께 작동해야 제대로 달립니다. 엔진이 아무리 강력해도 연료가 불량이면 퇴보합니다. AI 에이전트도 마찬가지입니다.
1편에서 AI 에이전트가 무엇인지, 2편에서 여러 에이전트가 어떻게 협력하는지를 다뤘습니다. 이번 3편에서는 AI 에이전트가 실제로 어떻게 작동하는지, 그 내부 구조를 완전히 분해합니다. AI 에이전트의 핵심 구성요소인 LLM(두뇌)·RAG(지식)·Tool Use(행동)·Memory(기억)의 역할과 상호작용, 그리고 기업 적용 시 주의사항과 실전 설계 방법을 심층적으로 정리합니다.
이 네 가지를 제대로 이해하면 왜 어떤 AI 에이전트는 성공하고 어떤 것은 실패하는지가 명확해집니다. 그리고 우리 기업이 지금 무엇을 준비해야 하는지도 분명해집니다.
- AI 에이전트의 4대 구성요소 전체 구조
- LLM — 에이전트의 두뇌: 개념과 선택 기준
- LLM — 기업 현장에서의 실제 역할과 한계
- RAG — 에이전트의 지식 창고: 개념과 작동 원리
- RAG — 기업 데이터 연결 설계와 품질 관리
- Tool Use — 에이전트의 손발: 도구 유형과 설계
- Tool Use — Human-in-the-Loop와 안전 설계
- Memory — 에이전트의 기억: 4가지 유형
- Memory — 기억 설계와 개인정보 보호
- 4요소가 함께 작동하는 실전 시나리오
- 기업 도입 시 요소별 준비 체크리스트
- 국내 기업 현장에서 가장 취약한 요소
1. AI 에이전트의 4대 구성요소 전체 구조
AI 에이전트를 이해하는 가장 직관적인 방법은 사람과 비교하는 것입니다. 훌륭한 직원이 되려면 지능(두뇌), 전문 지식, 행동 능력, 그리고 경험의 축적이 필요합니다. AI 에이전트도 정확히 이 네 가지 요소로 구성됩니다.
| 구성요소 | 사람의 유사 기능 | AI 에이전트에서의 역할 | 없으면 어떻게 되나 |
|---|---|---|---|
| 🧠 LLM (대규모 언어모델) |
두뇌 — 이해·추론·판단 | 지시 이해, 상황 분석, 다음 행동 결정, 결과 생성 | 에이전트 자체 불가. 아무것도 할 수 없음 |
| 📚 RAG (검색 증강 생성) |
지식·경험 — 업무 전문성 | 기업 내부 데이터·문서를 실시간 검색하여 판단 근거 제공 | 일반 상식만 있는 신입. 기업 업무 처리 불가 |
| 🔧 Tool Use (도구 사용) |
손발 — 실제 행동 능력 | API 호출, DB 조회, 파일 생성, 이메일 발송, 시스템 제어 | 생각만 하고 행동 못 함. 결과물 없음 |
| 💾 Memory (기억) |
기억 — 연속성·학습 | 작업 진행 상황 유지, 고객 이력 기억, 과거 학습 활용 | 매번 처음부터 시작. 장기 업무 처리 불가 |
LLM이 없으면 에이전트 자체가 없고, RAG가 없으면 신입사원이고, Tool Use가 없으면 말뿐인 조언가이고, Memory가 없으면 매번 첫 출근하는 직원입니다. 네 가지가 모두 제대로 갖춰져야 진짜 업무를 처리하는 AI 에이전트가 됩니다.
특히 중요한 것은 네 요소 간의 상호작용입니다. LLM이 판단을 내리기 위해 RAG에서 데이터를 요청하고, Tool Use를 통해 외부 시스템에서 추가 정보를 가져오며, Memory에서 이전 경험을 참조합니다. 이 순환이 끊기면 에이전트는 편향되거나 불완전한 결정을 내립니다.
2. LLM — 에이전트의 두뇌: 개념과 선택 기준
LLM(Large Language Model, 대규모 언어 모델)은 수천억 개의 매개변수로 학습된 AI 모델로, 자연어를 이해하고 생성하는 능력을 갖습니다. GPT-4o·Claude·Gemini·LLaMA가 대표적입니다.
AI 에이전트에서 LLM이 수행하는 핵심 역할은 4가지입니다.
"이 고객의 계약을 갱신 준비해줘"라는 모호한 지시에서 핵심 의도를 파악하고, 필요한 작업 목록을 스스로 도출합니다. 규칙 기반 시스템은 이 과정이 불가능합니다. LLM은 언어의 맥락과 의도를 이해하기 때문에 가능합니다.
목표를 달성하기 위한 단계별 계획을 수립합니다. "계약 갱신을 위해 ①고객 정보 조회 ②기존 계약 조건 확인 ③갱신 조건 비교 ④갱신 제안서 작성 ⑤담당자 검토 요청" 순서를 스스로 결정합니다. Chain-of-Thought(사고 연쇄) 프롬프팅 기법이 이 능력을 극대화합니다.
계획대로 진행되지 않을 때 대안을 찾습니다. "고객 담당자가 휴가 중이니 대리인에게 연락하고, 계약 마감이 3일 후이므로 긴급 처리 플래그를 설정한다"는 판단을 스스로 내립니다. 규칙 기반 시스템이 처리할 수 없는 예외 상황을 처리하는 것이 LLM의 핵심 가치입니다.
최종적으로 자연어 보고서, 이메일 초안, 의사결정 요약, API 호출 파라미터 등 다양한 형태의 결과물을 생성합니다. 동일한 정보를 CEO를 위한 1페이지 요약과 실무자를 위한 상세 보고서로 각각 생성하는 것도 가능합니다.
기업에서 LLM 선택 시 고려 요소:
| 고려 요소 | 세부 항목 | 선택 가이드 |
|---|---|---|
| 언어 지원 | 한국어 이해·생성 품질 | 한국어 업무 비중 높으면 한국어 특화 모델 우선 검토 |
| 컨텍스트 윈도우 | 한 번에 처리 가능한 텍스트 양 | 긴 문서 처리 필요 시 100K+ 토큰 모델 선택 |
| 추론 능력 | 복잡한 논리 처리 | 법률·금융·의료 분야는 추론 특화 모델 선택 |
| 보안·데이터 주권 | 데이터가 외부로 나가는가 | 기밀 데이터 처리 시 온프레미스 또는 프라이빗 클라우드 |
| 비용 | 토큰당 처리 비용 | 대용량 처리는 소형 오픈소스 모델 조합 검토 |
| 속도 | 응답 지연 시간 | 실시간 고객 응대는 응답 속도 우선 |
3. LLM — 기업 현장에서의 실제 역할과 한계
LLM은 강력하지만 한계도 명확합니다. 기업에서 AI 에이전트를 설계할 때 LLM의 한계를 정확히 이해해야 과잉 기대를 피할 수 있습니다.
| LLM이 잘하는 것 | LLM이 못하는 것 | 기업 설계 시 대응 방법 |
|---|---|---|
| 자연어 이해·생성 | 정확한 수치 계산 | 수치 계산은 Tool Use로 파이썬 코드 실행 |
| 복잡한 추론·계획 | 최신 정보 파악 | 실시간 데이터는 RAG 또는 웹 검색 도구 연결 |
| 문서 요약·분석 | 기업 내부 정보 | 내부 데이터베이스를 RAG로 연결 |
| 다국어 처리 | 일관된 반복 실행 | 반복 작업은 규칙 기반 시스템과 조합 |
| 창의적 결과 생성 | 환각(Hallucination) | 중요 사실은 RAG로 검증, 출처 확인 필수 |
LLM은 모르는 것을 모른다고 하지 않고 그럴듯하게 만들어내는 환각 문제가 있습니다. 기업 환경에서는 이것이 치명적입니다. "A공급업체의 최근 납기 실적"을 물었는데 LLM이 없는 데이터를 만들어내면 잘못된 구매 결정으로 이어집니다. 이것이 RAG가 필수인 이유입니다. LLM의 일반 지식에 의존하지 않고 실제 기업 데이터로 검증하는 것이 핵심입니다.
국내 대기업에서 AI 에이전트 도입을 검토할 때 가장 많이 받는 질문이 "어떤 LLM을 써야 하나요?"입니다. 솔직히 말하면 LLM 선택은 세 번째 중요한 결정입니다. 첫 번째는 RAG에 연결할 데이터 품질, 두 번째는 Tool Use를 위한 API 정비입니다. 데이터와 도구가 준비되지 않은 상태에서 최고의 LLM을 써도 결과는 실망스럽습니다.
4. RAG — 에이전트의 지식 창고: 개념과 작동 원리
RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 LLM이 답변을 생성할 때 외부 데이터베이스나 문서에서 관련 정보를 실시간으로 검색하여 함께 활용하는 기술입니다.
왜 RAG가 필수인가: LLM은 학습 데이터 기반으로 일반 지식을 갖고 있지만 우리 회사의 내부 정보를 알지 못합니다. 우리 회사 고객 계약 조건, 내부 규정, 최신 제품 사양, 특정 공급업체와의 거래 이력은 LLM의 학습 데이터에 없습니다. RAG 없이 운영하는 AI 에이전트는 신입사원과 같습니다.
| RAG 없는 에이전트 | RAG 있는 에이전트 | 차이 |
|---|---|---|
| "일반적으로 계약 갱신은 30일 전 통보합니다" | "A사와의 계약 조항 4조에 따라 45일 전 통보가 필요합니다" | 일반 상식 vs 실제 계약 |
| "환불 정책은 보통 30일 이내입니다" | "고객 B는 VIP 등급으로 60일 환불 정책이 적용됩니다" | 일반 정책 vs 고객 맞춤 |
| "이 자재는 일반적으로 2주 납기입니다" | "C공급업체의 최근 3회 납기 실적이 평균 18일입니다" | 업계 평균 vs 실제 이력 |
| "신제품 사양은 업계 표준을 따릅니다" | "신제품 D의 공식 사양서 3페이지에 따르면..." | 추측 vs 정확한 문서 |
RAG의 작동 방식 단계별 설명:
기업 내부 문서(계약서·규정·매뉴얼·이메일 등)를 벡터(숫자) 형태로 변환하여 벡터 데이터베이스에 저장합니다.
② 쿼리 처리:
사용자 질문이 들어오면 질문도 벡터로 변환합니다.
③ 유사도 검색:
벡터 DB에서 질문과 가장 관련성 높은 문서 청크(chunk)를 검색합니다. 의미적으로 유사한 내용을 찾는 것이기 때문에 정확한 키워드가 없어도 관련 문서를 찾습니다.
④ 컨텍스트 주입:
검색된 문서 내용을 LLM의 프롬프트에 함께 전달합니다.
⑤ 답변 생성:
LLM이 자신의 일반 지식 + 검색된 기업 특화 정보를 결합하여 정확한 답변을 생성합니다.
5. RAG — 기업 데이터 연결 설계와 품질 관리
RAG를 제대로 구현하려면 단순히 문서를 벡터 DB에 넣는 것 이상이 필요합니다. 데이터 소스 선택, 청킹(Chunking) 전략, 메타데이터 관리, 업데이트 주기가 모두 중요합니다.
기업 RAG 데이터 소스 우선순위:
고객·자재·공급업체·직원 마스터 데이터. 에이전트의 모든 판단의 기반이 되는 핵심 데이터입니다. MDM 품질이 RAG의 품질을 결정합니다.
업무 절차서, 내부 규정, 계약 조건, 컴플라이언스 가이드라인. 에이전트가 "어떻게 해야 하는가"를 판단하는 기준이 됩니다.
주문·납기·클레임·응대 이력. 에이전트가 과거 패턴을 기반으로 더 정확한 예측과 추천을 할 수 있게 합니다.
업계 보고서, 규제 변경 사항, 시장 정보. 내부 데이터와 결합하여 더 풍부한 판단 기반을 제공합니다.
RAG는 연결된 데이터만큼만 정확합니다. 잘못된 데이터, 오래된 데이터, 파편화된 데이터를 RAG에 연결하면 에이전트가 자신 있게 틀린 답변을 합니다. 이것이 MDM(마스터 데이터 관리)이 AI 에이전트 도입의 전제 조건인 이유입니다. 데이터 정비 없는 RAG는 나쁜 정보를 빠르게 퍼뜨리는 도구가 됩니다.
RAG 데이터 품질 관리 체계:
| 관리 항목 | 기준 | 모니터링 방법 |
|---|---|---|
| 정확성 | 오류율 1% 이하 | 정기 샘플링 검증, 사용자 피드백 추적 |
| 최신성 | 데이터 지연 최대 24시간 | 업데이트 타임스탬프 모니터링 |
| 완전성 | 필수 필드 누락 0% | 필수 필드 자동 체크 |
| 일관성 | 동일 데이터 단일 출처 | 중복 데이터 탐지 알람 |
6. Tool Use — 에이전트의 손발: 도구 유형과 설계
Tool Use(도구 사용)는 AI 에이전트가 실제로 세상에 영향을 미칠 수 있게 하는 능력입니다. 이것이 AI 에이전트를 단순한 챗봇과 결정적으로 구분합니다. 챗봇은 말만 하지만, 에이전트는 실제로 행동합니다.
| 도구 유형 | 구체적 기능 | 기업 적용 예시 | 위험 수준 |
|---|---|---|---|
| 읽기 전용 API | 데이터 조회, 상태 확인, 검색 | 재고 확인, 고객 정보 조회 | 🟢 낮음 |
| 쓰기 API | 데이터 생성·수정·삭제 | 발주 등록, 계약 업데이트 | 🟡 중간 |
| 알림·메시지 | 이메일·Slack·Teams 발송 | 고객 알림, 내부 승인 요청 | 🟡 중간 |
| 코드 실행 | Python·SQL 실행, 계산 | 데이터 분석, 보고서 생성 | 🟡 중간 |
| 외부 시스템 제어 | 결제·환불·계약 체결 | 자동 결제 처리, 계약 서명 | 🔴 높음 |
| 웹 검색 | 인터넷 실시간 검색 | 경쟁사 가격, 규제 변경 | 🟢 낮음 |
Tool Use의 핵심 과제 — API 정비: 에이전트가 도구를 사용하려면 각 시스템이 API를 통해 표준화된 방식으로 접근 가능해야 합니다. 레거시 시스템, API 없는 시스템, 인증 체계가 파편화된 시스템에서는 Tool Use가 불가능합니다.
- ☐ ERP(SAP/Oracle)에 표준 API가 있는가?
- ☐ CRM 시스템이 REST API를 지원하는가?
- ☐ SCM·MES 시스템에 API 게이트웨이가 있는가?
- ☐ 여러 시스템 간 통합 API 허브(ESB/API 게이트웨이)가 있는가?
- ☐ API 인증(OAuth/API Key) 체계가 표준화됐는가?
- ☐ API 사용 권한 관리 체계가 있는가?
3개 미만 해당 시: AI 에이전트 Tool Use 구현 전 API 인프라 정비 선행 필요
7. Tool Use — Human-in-the-Loop와 안전 설계
Tool Use 설계에서 가장 중요하면서도 많이 간과되는 것이 Human-in-the-Loop(HITL, 인간 개입 루프) 설계입니다.
모든 도구 사용이 자동화될 필요는 없습니다. 그리고 자동화해서는 안 되는 것들이 있습니다.
| 자동화 수준 | 적합한 작업 | 이유 |
|---|---|---|
| 완전 자동화 | 읽기 전용 조회, 소액 반복 거래, 내부 알림 | 오류 영향 최소, 취소 가능, 반복성 높음 |
| 반자동화 (임계값 이상 승인) |
일정 금액 이상 발주, 계약 수정, 고객 환불 | 영향 크지만 패턴화 가능 |
| 인간 승인 필수 | 대규모 계약, 직원 채용·해고 관련, 법적 문서 | 취소 불가능하거나 법적·윤리적 책임 발생 |
2025년 글로벌 이커머스 기업에서 고객 응대 AI 에이전트가 HITL 없이 환불 요청을 자동 처리했습니다. AI가 환불 정책의 예외 조건을 잘못 해석하여 3시간 동안 수천 명의 고객에게 부적절한 환불을 처리했습니다. 손실 규모는 수십억 원. HITL이 있었다면 첫 번째 비정상 처리에서 인간이 개입하여 차단할 수 있었습니다.
HITL 설계 원칙 4가지:
- 취소 불가능한 행동은 반드시 승인: 이메일 대량 발송, 계약 체결, 대규모 발주는 사람이 확인 후 실행
- 임계값 기반 자동 에스컬레이션: 금액·수량·영향 범위가 기준을 초과하면 자동으로 담당자에게 알림
- 설명 가능한 승인 요청: AI가 "왜 이 행동을 하려는가"를 설명하여 승인자가 판단 가능하게
- 거부 사유 학습: 인간이 거부한 이유를 기록하여 에이전트의 향후 판단 개선에 활용
8. Memory — 에이전트의 기억: 4가지 유형
Memory(기억)는 AI 에이전트가 단순한 일회성 응답 도구가 아닌, 지속적으로 업무를 처리하는 디지털 동료가 될 수 있게 하는 요소입니다. 기억이 없으면 에이전트는 매번 처음부터 시작해야 합니다.
무엇인가: 현재 진행 중인 작업의 컨텍스트를 유지합니다. 현재 대화 내용, 이미 완료한 단계, 수집한 데이터가 여기에 포함됩니다. LLM의 컨텍스트 윈도우가 이 역할을 합니다.
특징: 작업이 끝나면 사라집니다. 용량 한계(컨텍스트 윈도우 크기)가 있습니다.
기업 활용: 복잡한 다단계 업무 처리, 멀티턴 고객 응대
무엇인가: 데이터베이스에 영구 저장되는 기억입니다. 고객 응대 이력, 과거 의사결정 내용, 학습된 선호도가 여기에 저장됩니다.
특징: 에이전트가 재시작해도 이전 맥락을 이어갈 수 있습니다.
기업 활용: 고객 이력 기반 개인화, 장기 프로젝트 진행 상황 추적
무엇인가: 비즈니스 규칙, 정책, 도메인 지식을 구조화하여 저장합니다. "VIP 고객에게는 무조건 당일 응대한다", "환경 기준 미달 공급업체는 자동 제외한다" 같은 규칙들입니다.
특징: 자주 업데이트되지 않지만 모든 판단의 기반이 됩니다.
기업 활용: 내부 규정 준수, 일관된 정책 적용, 예외 처리 기준
무엇인가: 과거에 비슷한 상황에서 어떻게 처리했는지의 경험을 기억합니다. "지난번에 A공급업체 납기 지연 시 B공급업체로 대체했더니 효과적이었다"는 경험이 축적됩니다.
특징: 시간이 지날수록 에이전트가 더 스마트해집니다. 조직의 암묵지를 AI가 학습하는 것입니다.
기업 활용: 문제 해결 패턴 학습, 의사결정 품질 향상
9. Memory — 기억 설계와 개인정보 보호
기억 설계에서 기업이 가장 많이 간과하는 것은 두 가지입니다. "무엇을 기억하고 무엇을 잊어야 하는가"와 "기억이 개인정보를 침해하지 않는가"입니다.
| 기억 항목 | 보존 기간 | 접근 권한 | 삭제 조건 |
|---|---|---|---|
| 고객 응대 이력 | 3년 (계약 기간 + 1년) | 담당자·팀장 | 계약 종료 후 1년 |
| 의사결정 로그 | 5년 (감사 목적) | 감사팀·경영진 | 법적 보존 기간 후 |
| 직원 성과 데이터 | 재직 기간 + 3년 | HR·직속 상관 | 퇴직 후 3년 |
| 개인 식별 정보 | 서비스 이용 기간 | 최소 권한 원칙 | 동의 철회 즉시 |
| 에이전트 학습 데이터 | 모델 버전 유지 기간 | AI 팀 | 모델 교체 시 |
한국 개인정보보호법과 EU GDPR은 "잊혀질 권리"를 보장합니다. 고객이 자신의 데이터 삭제를 요청하면 에이전트의 기억에서도 삭제해야 합니다. 이것을 기술적으로 구현하지 않은 채 AI 에이전트를 운영하면 법적 위험이 발생합니다. 기억 설계 단계에서 데이터 삭제 API와 연동하는 것이 필수입니다.
10. 4요소가 함께 작동하는 실전 시나리오
실제 업무에서 네 요소가 어떻게 유기적으로 작동하는지 두 가지 시나리오로 정리합니다.
시나리오 A: 구매 에이전트 — 재고 부족 대응
① LLM 판단: "재고 부족 + 대량 주문 = 납기 리스크 관리 필요"
② RAG 검색: A고객 계약서 납기 페널티 조항, 대체 공급업체 목록, 유사 상황 처리 사례
③ LLM 계획: "B공급업체 긴급 발주가 페널티보다 저렴" 판단 → 4단계 처리 계획 수립
④ Tool Use 실행: SCM에서 B공급업체 재고 조회 → 긴급 발주 요청 이메일 발송 → ERP 납기 변경 등록 → 고객 알림
⑤ Memory 저장: "재고 부족 시 B공급업체 대체 성공" 에피소드 저장 → 다음 유사 상황에서 더 빠른 판단
시나리오 B: 고객 응대 에이전트 — 복잡한 환불 요청
① Memory 조회: 이 고객의 과거 응대 이력, VIP 등급 여부, 이전 환불 이력
② RAG 검색: 제품 결함 관련 환불 정책, VIP 특별 정책, 해당 제품 알려진 결함 목록
③ LLM 판단: "고객 VIP 등급 + 제품 결함 인정 → 특별 환불 정책 적용 가능"
④ Tool Use: 환불 금액 계산(코드 실행) → HITL: 담당자에게 승인 요청 알림
⑤ 승인 후 Tool Use: 환불 처리 API 호출 → 고객에게 처리 완료 이메일
⑥ Memory 업데이트: 처리 결과 이력 저장, 해당 제품 결함 케이스 패턴 업데이트
11. 기업 도입 시 요소별 준비 체크리스트
| 요소 | 도입 전 준비사항 | 준비 난이도 | 소요 기간 | 선행 의존성 |
|---|---|---|---|---|
| LLM | 업무 도메인·언어·보안 요건에 맞는 모델 선정. 온프레미스 vs 클라우드 결정. 라이선스·비용 검토. 파인튜닝 필요 여부 판단 | ⭐⭐ 중간 | 1~2개월 | RAG, Tool Use 결정 후 |
| RAG | 연결할 내부 데이터 목록 정의. 데이터 품질 점검·정비(MDM). 벡터 DB 구축. 청킹 전략 설계. 데이터 업데이트 주기 설정. 검색 정확도 테스트 | ⭐⭐⭐⭐ 높음 | 3~6개월 | MDM 선행 필수 |
| Tool Use | 주요 시스템 API 목록화. 미비 API 개발. 통합 API 게이트웨이 구축. 보안·인증 체계 정비. HITL 설계. 권한 관리 체계 | ⭐⭐⭐⭐ 높음 | 3~9개월 | 시스템 현황 조사 선행 |
| Memory | 기억 유형별 저장소 설계. 보존 기간·삭제 정책 정의. 개인정보 처리 방침. 접근 권한 설계. GDPR·개인정보보호법 검토 | ⭐⭐⭐ 중상 | 2~4개월 | 법무·컴플라이언스 검토 |
RAG와 Tool Use의 준비 난이도와 소요 기간이 가장 깁니다. 이 두 가지가 AI 에이전트 도입의 실질적인 병목입니다. LLM 선정보다 데이터 정비와 API 정비에 더 많은 시간과 자원을 투자해야 합니다. 대부분의 기업이 LLM 선택에 과도한 시간을 쓰고 데이터·API 준비를 소홀히 하는 것이 실패의 원인입니다.
12. 국내 기업 현장에서 가장 취약한 요소
국내 대기업 현장에서 AI 에이전트 도입 프로젝트를 분석하면 공통적으로 취약한 요소가 명확하게 드러납니다.
고객·자재·공급업체 마스터 데이터가 ERP·CRM·SCM에 파편화되어 있고, 데이터 품질 관리 체계가 없는 경우가 많습니다. RAG에 연결할 "신뢰할 수 있는 단일 데이터"가 존재하지 않습니다. 이 상태에서 에이전트를 도입하면 잘못된 데이터를 기반으로 빠르게 잘못된 결정을 내립니다. 이것이 MDM(마스터 데이터 관리)이 AI 에이전트 도입의 전제 조건인 이유입니다.
레거시 ERP·MES·그룹웨어 시스템은 API가 없거나 표준화되지 않은 경우가 많습니다. 에이전트가 실제로 시스템을 제어하려면 모든 핵심 시스템에 API가 있어야 합니다. 이 정비 없이는 에이전트가 "말만 하는 조언가"로 끝납니다. API 게이트웨이와 통합 인증 체계 구축에 평균 6~12개월이 소요됩니다.
국내 기업 대부분이 Memory 설계를 나중에 생각합니다. 초기에는 작업 기억(In-Context)만으로 운영하다가 장기 기억의 필요성을 뒤늦게 깨닫고, 이미 구축된 시스템에 Memory를 추가하는 과정에서 아키텍처 재설계가 발생합니다. Memory는 처음부터 설계에 포함해야 합니다.
ChatGPT·Claude·Gemini API는 이미 저렴하고 접근하기 쉽습니다. LLM 자체는 더 이상 장벽이 아닙니다. 오히려 데이터와 시스템 연결이 진짜 장벽입니다. LLM에 과도하게 집중하고 데이터·API를 소홀히 하는 것이 가장 흔한 실수입니다.
LLM의 우수성이 아니라
그 에이전트에게 연결된
데이터의 품질과
시스템의 접근성으로 결정됩니다.
AI 에이전트 프로젝트 예산의
절반 이상을 데이터와 API 정비에
투자하는 것이 옳습니다."
- Gartner. (2026). How RAG Transforms AI Agents for Enterprise Accuracy. Gartner, Inc.
- AWS. (2026). RAG Best Practices for Enterprise AI Agents. Amazon Web Services.
- Anthropic. (2026). Tool Use in Claude: Building Effective AI Agents. Anthropic Documentation.
- Microsoft. (2026). Memory Architecture for Enterprise AI Agents. Azure AI Documentation.
- McKinsey & Company. (2026). Building the AI-ready enterprise: Data infrastructure for agentic AI. McKinsey Global Institute.
- LangChain. (2026). Memory Types in LangChain Agents. LangChain Documentation.
- IBM. (2026). Enterprise AI Agent Architecture: RAG and Tool Integration Guide. IBM Technology.
- DAMA International. (2017). DAMA-DMBOK 2nd Edition. Technics Publications.
- NIST. (2024). AI Risk Management Framework (AI RMF 1.0). National Institute of Standards and Technology.
Part 1. AI 에이전트 이해 (연재 중)
- AI 에이전트란 무엇인가
- Multi-Agent System
- LLM·RAG·Tool Use·Memory 구조 완전 정리 (현재 글)
- AI 에이전트 실패 7가지 이유 (예정)
- 2026 Agentic AI 글로벌 시장 현황 (예정)
댓글
댓글 쓰기