Chapter 4. AI Agent & Agentic AI
Ch.1에서 AI 모델의 원리를, Ch.2에서 모델에게 "어떻게 말할까"(Prompt Engineering)를, Ch.3에서 "무엇을 줄까"(Context Engineering)를 다루었습니다. 이번 챕터에서는 이 세 가지 기반 위에서 스스로 판단하고, 도구를 활용하며, 다단계 작업을 자율적으로 수행하는 AI Agent의 세계로 나아갑니다. AI Agent는 LLM의 추론 능력(Ch.1)을 핵심 두뇌로, 프롬프트(Ch.2)를 지시 체계로, 컨텍스트(Ch.3)를 지식 공급원으로 활용하여 복잡한 목표를 달성합니다. (**수정)
1 AI 에이전트의 개념
1.1 AI 에이전트란?
1.1.1 AI 에이전트의 정의
**AI 에이전트(AI Agent)**란 주어진 목표를 달성하기 위해 자율적으로 환경을 인식하고, 판단하며, 행동을 수행하는 AI 시스템입니다. 기존의 LLM이 사용자의 질문에 단순히 응답하는 것과 달리, AI 에이전트는 스스로 계획을 세우고, 외부 도구를 활용하며, 여러 단계의 작업을 연속적으로 수행할 수 있습니다.
예를 들어, "다음 주 서울 출장 일정을 잡아줘"라는 요청을 받으면:
- 일반 LLM: "출장 일정을 잡으려면 항공편과 호텔을 예약하세요"라고 텍스트 응답만 생성
- AI 에이전트: 캘린더를 확인하고 → 항공편을 검색하고 → 호텔을 예약하고 → 캘린더에 일정을 등록하는 일련의 행동을 자율적으로 수행
[출처: Anthropic, "Building Effective Agents" (anthropic.com); Gartner, "Agentic AI Predictions 2025-2028"]
1.1.2 에이전트와 기존 AI 챗봇의 차이
| 비교 항목 | 기존 AI 챗봇 | AI 에이전트 |
|---|---|---|
| 동작 방식 | 질문-응답(Q&A) 방식 | 목표 기반 자율 행동 |
| 외부 도구 사용 | 불가 또는 매우 제한적 | 다양한 도구(API, DB, 파일 등) 활용 가능 |
| 계획 수립 | 없음 | 작업을 분해하고 실행 계획을 수립 |
| 다단계 작업 | 한 번의 요청에 한 번의 응답 | 여러 단계의 작업을 연속적으로 수행 |
| 오류 처리 | 사용자가 직접 수정 | 결과를 평가하고 스스로 수정 |
| 예시 | 일반 ChatGPT 대화 | 코딩 에이전트, 업무 자동화 에이전트 |
1.1.3 핵심 구성 요소: 인식, 추론, 행동, 메모리
AI 에이전트는 다음 네 가지 핵심 구성 요소로 이루어집니다.
- 인식(Perception): 사용자 입력, 환경 상태, 도구 실행 결과 등을 파악하는 능력
- 추론(Reasoning): 현재 상황을 분석하고, 다음에 수행할 행동을 판단하는 능력. LLM의 언어 이해·생성 능력이 핵심
- 행동(Action): 외부 도구 호출, API 요청, 파일 읽기/쓰기 등 실제 작업을 수행하는 능력
- 메모리(Memory): 이전 대화 내용, 실행 결과, 학습된 정보를 저장하고 활용하는 능력
- 단기 메모리(Short-term): 현재 대화/작업 세션 내의 정보
- 장기 메모리(Long-term): 세션 간에 유지되는 지식과 경험
1.2 Agentic AI의 정의와 특징 (**추가)
1.2.1 Agentic AI란? (**추가)
Agentic AI는 단순히 하나의 AI 에이전트를 지칭하는 것이 아니라, AI 시스템이 자율성(Autonomy), 적응성(Adaptability), **주도성(Proactivity)**을 갖추고 복잡한 목표를 독립적으로 달성하는 패러다임 전체를 의미합니다.
Gartner는 2025년 전략 기술 트렌드에서 Agentic AI를 다음과 같이 정의하였습니다:
"자체적으로 목표를 설정하고, 계획을 수립하며, 환경 변화에 적응하면서 행동하는 AI 시스템"
Agentic AI의 핵심은 인간의 개입 없이도 다단계 의사결정과 실행을 자율적으로 수행할 수 있다는 점입니다. 이는 단순한 자동화(Automation)를 넘어, AI가 상황을 판단하고 최적의 전략을 선택하는 자율적 의사결정(Autonomous Decision-Making) 단계로의 진화를 의미합니다.
[출처: Gartner, "Top Strategic Technology Trends 2025: Agentic AI" (https://www.gartner.com/en/articles/top-technology-trends-2025); McKinsey, "Why agents are the next frontier of generative AI" (https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/why-agents-are-the-next-frontier-of-generative-ai)]
1.2.2 AI Agent vs. Agentic AI: 차이점 (**추가)
| 구분 | AI Agent (에이전트) | Agentic AI (에이전틱 AI) |
|---|---|---|
| 범위 | 특정 작업을 수행하는 개별 소프트웨어 단위 | 자율적 AI 시스템의 설계 철학·패러다임 전체 |
| 자율성 수준 | 정해진 도구와 규칙 내에서 행동 | 목표 자체를 재해석하고 전략을 스스로 수정 |
| 적응성 | 사전 정의된 워크플로우에 의존 | 환경 변화에 실시간으로 적응 |
| 학습 | 제한적 (세션 내 컨텍스트 유지) | 경험으로부터 지속적으로 학습·개선 |
| 협업 | 단독 또는 제한된 협업 | 다수 에이전트 간 동적 협업 (Multi-Agent) |
| 비유 | 숙련된 직원 한 명 | 자율적으로 운영되는 팀 전체 |
쉽게 말하면, **AI Agent는 Agentic AI를 구현하기 위한 구성 요소(building block)**이고, Agentic AI는 이러한 에이전트들이 자율적으로 협업하여 복잡한 비즈니스 목표를 달성하는 시스템적 접근 방식입니다.
[출처: Google Cloud, "What is agentic AI?" (https://cloud.google.com/discover/what-is-agentic-ai); IBM, "What are AI Agents?" (https://www.ibm.com/think/topics/ai-agents)]
1.2.3 Agentic AI의 성숙도 단계 (**추가)
Agentic AI는 다음과 같은 성숙도 단계를 거쳐 발전합니다:
- Level 1 - Rule-based Agent: 사전 정의된 규칙에 따라 동작하는 단순 에이전트 (예: 챗봇의
IF-THEN로직) - Level 2 - LLM-powered Agent: LLM을 기반으로 자연어를 이해하고 도구를 사용하는 에이전트 (예: ChatGPT with Plugins)
- Level 3 - Autonomous Agent: 스스로 계획을 수립하고 다단계 작업을 자율적으로 수행하는 에이전트 (예:
Devin,Claude Code) - Level 4 - Collaborative Multi-Agent: 여러 에이전트가 역할을 분담하여 복잡한 목표를 협업으로 달성하는 시스템
- Level 5 - Self-Evolving Agent: 경험을 통해 스스로 학습하고 능력을 확장하는 자기 발전형 에이전트 (연구 단계)
참고: 현재(2025-2026년) 업계는 Level 2~3 단계에 집중하고 있으며, Level 4로의 전환이 활발히 진행 중입니다.
[출처: Anthropic, "Building Effective Agents" (https://www.anthropic.com/research/building-effective-agents); Andrew Ng, "Agentic Design Patterns" (https://www.deeplearning.ai/the-batch/how-agents-can-improve-llm-performance/)]
2 AI 에이전트의 핵심 패턴
AI 에이전트가 작업을 수행하는 방식에는 여러 가지 패턴이 있습니다. 대표적인 패턴들을 살펴보겠습니다.
2.1 ReAct 패턴 (Reasoning + Acting)
ReAct는 **추론(Reasoning)**과 **행동(Acting)**을 번갈아 수행하며 문제를 해결하는 패턴입니다.
- 동작 방식:
사고(Thought)→행동(Action)→관찰(Observation)→ 사고 → ... 반복 - 예시 (고객 주문 조회):
| 단계 | 유형 | 내용 |
|---|---|---|
| 1 | 사고 | "고객 ID 12345의 최근 주문을 조회해야 한다" |
| 2 | 행동 | 주문 DB 조회 API 호출 |
| 3 | 관찰 | 주문 #A100, #A101, #A102 반환됨 |
| 4 | 사고 | "가장 최근 주문 #A102의 상세 정보를 확인해야 한다" |
| 5 | 행동 | 주문 상세 API 호출 |
| 6 | 관찰 | 주문 상세 정보 반환 |
| 7 | 완료 | 최종 응답 생성 |
- 장점: 각 단계의 사고 과정이 명확하여 디버깅과 해석이 용이
[출처: Yao et al. "ReAct: Synergizing Reasoning and Acting in Language Models" (arXiv:2210.03629)]
2.2 Plan-and-Execute 패턴
작업을 먼저 전체 계획으로 분해한 후, 각 단계를 순차적으로 실행하는 패턴입니다.
- 동작 방식: 전체 계획 수립 → 단계별 실행 → 필요 시 계획 수정
- 예시:
- 계획 수립: (1) 데이터 수집 → (2) 데이터 정제 → (3) 분석 수행 → (4) 보고서 작성
- 각 단계를 순차적으로 실행하되, 중간 결과에 따라 계획을 수정 가능
- 장점: 복잡한 작업을 체계적으로 분해하여 실행, 진행 상황 추적이 용이
- 단점: 초기 계획 수립에 시간이 소요, 예상치 못한 상황에 유연한 대응이 어려울 수 있음
2.3 Tool Use (도구 사용)
AI 에이전트의 핵심 능력 중 하나는 **외부 도구(Tool)**를 사용하는 것입니다.
- 도구의 종류:
- 검색 도구: 웹 검색, 데이터베이스 조회
- 코드 실행:
Python,SQL등의 코드 실행 - API 호출: 외부 서비스 연동 (이메일 발송, 캘린더 관리 등)
- 파일 처리: 문서 읽기, 파일 생성/수정
- 동작 방식: LLM이 현재 상황에 적합한 도구를 선택 → 도구 호출에 필요한 파라미터 생성 → 도구 실행 → 결과를 다음 추론에 활용
- 핵심 개념: LLM은 도구의 **설명(Description)**을 읽고 적절한 도구를 자율적으로 선택함
[출처: OpenAI, "Function Calling" (platform.openai.com); Anthropic, "Tool Use" (docs.anthropic.com)]
2.4 Multi-Agent 협업
여러 AI 에이전트가 역할을 분담하여 하나의 복잡한 작업을 협력적으로 해결하는 패턴입니다.
- 구조:
- 오케스트레이터(Orchestrator): 전체 작업을 조율하는 중앙 에이전트
- 전문 에이전트(Specialist): 특정 역할을 담당하는 개별 에이전트 (예: 코딩 에이전트, 리서치 에이전트, 검증 에이전트)
- 예시: 소프트웨어 개발 에이전트 팀
- 기획 에이전트: 요구사항 분석 및 설계
- 코딩 에이전트: 코드 작성
- 테스트 에이전트: 테스트 코드 작성 및 실행
- 코드 리뷰 에이전트: 코드 품질 검토
- 장점: 복잡한 작업을 병렬로 처리 가능, 각 에이전트가 전문 역할에 집중
- 단점: 에이전트 간 소통 비용 발생, 설계가 복잡
2.5 Agent 설계 패턴 심화 (**추가)
Andrew Ng이 제시한 Agentic Design Patterns를 포함하여, 실무에서 활용되는 주요 에이전트 설계 패턴을 심층적으로 살펴봅니다.
2.5.1 Reflection 패턴 (**추가)
에이전트가 자신의 출력을 스스로 평가하고 개선하는 패턴입니다.
- 동작 방식: 초기 출력 생성 → 자체 비평(Self-Critique) → 개선된 출력 생성 → 반복
- 예시 (코드 생성):
- 에이전트가 코드를 작성
- 작성된 코드를 스스로 리뷰: "이 코드에 에러 처리가 부족하고, 변수명이 불명확하다"
- 피드백을 반영하여 코드를 개선
- 다시 리뷰하여 품질이 충분한지 확인
- 장점: 단일 LLM 호출 대비 출력 품질이 크게 향상됨
- 구현 방식: 단일 에이전트가 "생성자"와 "비평가" 역할을 번갈아 수행하거나, 별도의 비평 에이전트를 둠
[출처: Madaan et al., "Self-Refine: Iterative Refinement with Self-Feedback" (arXiv:2303.17651); Shinn et al., "Reflexion: Language Agents with Verbal Reinforcement Learning" (arXiv:2303.11366)]
2.5.2 Orchestrator-Worker-Evaluator 패턴 (**추가)
Multi-Agent 시스템에서 가장 널리 사용되는 아키텍처 패턴으로, 세 가지 역할을 명확히 분리합니다.
- Orchestrator (오케스트레이터): 사용자의 요청을 분석하고, 하위 작업으로 분해하여 적절한 Worker에게 할당하는 역할. 전체 워크플로우의 진행을 관리합니다.
- Worker (워커): 오케스트레이터로부터 할당받은 구체적인 작업을 실행하는 역할. 각 Worker는 특정 도메인 또는 기능에 특화됩니다.
- Evaluator (평가자): Worker의 출력물을 검증하고 품질을 평가하는 역할. 품질 기준에 미달하면 재작업을 요청합니다.
아키텍처 흐름 예시:
[사용자 요청]
↓
[Orchestrator] ──→ 작업 분해 & 할당
↓ ↓ ↓
[Worker-A] [Worker-B] [Worker-C]
(리서치) (분석) (작성)
↓ ↓ ↓
└────────────────┴──────────────┘
↓
[Evaluator] ──→ 품질 검증
↓
(통과 시) 최종 결과 반환
(미달 시) Orchestrator에 피드백 → 재작업- 장점: 역할 분리로 인한 책임 명확화, 품질 보증 내장, 확장성 우수
- 단점: 시스템 복잡도 증가, 에이전트 간 통신 오버헤드
[출처: LangChain, "Multi-Agent Architectures" (https://blog.langchain.dev/langgraph-multi-agent-workflows/); Microsoft, "AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation" (arXiv:2308.08155)]
2.5.3 Handoff 패턴 (**추가)
하나의 에이전트가 작업 중 **자신의 전문 영역을 벗어나는 요청을 감지하면, 적합한 다른 에이전트에게 대화와 컨텍스트를 전달(Handoff)**하는 패턴입니다.
- 동작 방식: 에이전트 A가 작업 수행 중 → 전문 영역 밖의 요청 감지 → 에이전트 B에게 컨텍스트와 함께 전달 → 에이전트 B가 이어서 처리
- 예시: 고객 서비스에서 일반 상담 에이전트가 기술 지원이 필요한 문의를 받으면, 기술 지원 전문 에이전트에게 핸드오프
- 장점: 각 에이전트가 자신의 전문 영역에 집중할 수 있고, 사용자는 끊김 없는 경험을 받음
- 적용 사례: OpenAI Agents SDK의 핵심 기능으로 내장되어 있으며, 고객 상담, 기술 지원, 주문 처리 등에서 활용
[출처: OpenAI, "Agents SDK - Handoffs" (https://openai.github.io/openai-agents-python/handoffs/)]
3 에이전트 프레임워크
AI 에이전트를 효율적으로 개발하기 위한 다양한 프레임워크가 제공되고 있습니다.
3.1 LangGraph (LangChain)
- 개발사: LangChain
- 특징: 그래프 기반으로 에이전트의 워크플로우를 정의, 상태 관리와 조건 분기를 유연하게 구현 가능
- 적합 용도: 복잡한 멀티 스텝 에이전트, 조건 분기가 많은 워크플로우
- 언어:
Python,JavaScript/TypeScript
[출처: LangChain, "LangGraph Documentation" (langchain-ai.github.io/langgraph)]
3.2 Autogen (Microsoft)
- 개발사: Microsoft
- 특징: 여러 에이전트 간의 대화 기반 협업을 지원, 멀티 에이전트 시스템 구축에 특화
- 적합 용도: 다수의 에이전트가 토론/협업하여 문제를 해결하는 시나리오
- 언어:
Python
[출처: Microsoft, "AutoGen" (microsoft.github.io/autogen)]
3.3 CrewAI
- 특징: 에이전트에게 **역할(Role), 목표(Goal), 배경(Backstory)**을 부여하여 팀처럼 협업하도록 설계
- 적합 용도: 역할 기반 멀티 에이전트 시스템, 비즈니스 프로세스 자동화
- 언어:
Python
[출처: CrewAI Documentation (docs.crewai.com)]
3.4 OpenAI Agents SDK
- 개발사: OpenAI
- 특징: OpenAI 모델과 통합된 에이전트 개발 SDK, 도구 사용과 핸드오프(Handoff) 기능 내장
- 적합 용도: OpenAI 생태계 기반의 에이전트 개발
- 언어:
Python
[출처: OpenAI, "Agents SDK" (openai.github.io/openai-agents-python)]
3.5 에이전트 프레임워크 심층 비교 (**추가)
3.5.1 확장 비교표 (**추가)
| 프레임워크 | 개발사 | 핵심 특징 | 멀티 에이전트 | 상태 관리 | Human-in-the-Loop | 스트리밍 | 적합 시나리오 |
|---|---|---|---|---|---|---|---|
| LangGraph | LangChain | 그래프 기반 워크플로우, 조건 분기 | 지원 | 내장 (체크포인트) | 내장 | 지원 | 복잡한 워크플로우, 상태 기반 에이전트 |
| AutoGen | Microsoft | 대화 기반 협업, 코드 실행 | 핵심 기능 | 대화 히스토리 | 지원 | 지원 | 에이전트 간 토론/협업, 코드 생성 |
| CrewAI | CrewAI | 역할 기반 팀 협업, 직관적 API | 핵심 기능 | 작업 컨텍스트 | 지원 | 지원 | 비즈니스 프로세스 자동화, 역할 기반 |
| OpenAI Agents SDK | OpenAI | OpenAI 생태계 통합, 핸드오프 | 지원 | 세션 기반 | 지원 | 지원 | OpenAI 모델 기반 에이전트, 가드레일 |
| Google ADK | Gemini 생태계 통합, 멀티모달 | 지원 | 세션 기반 | 지원 | 지원 | Google Cloud 환경, 멀티모달 에이전트 |
(**추가)
3.5.2 프레임워크 선택 가이드 (**추가)
프레임워크 선택 시 고려해야 할 핵심 기준:
- 복잡도와 유연성: 복잡한 조건 분기와 상태 관리가 필요하면 LangGraph, 간단한 역할 기반 협업이면 CrewAI
- 에이전트 간 협업 패턴: 자유로운 대화 기반 협업이 필요하면 AutoGen, 구조화된 핸드오프가 필요하면 OpenAI Agents SDK
- 모델 종속성: 특정 모델에 종속되지 않으려면 LangGraph 또는 CrewAI, OpenAI 생태계에 집중하려면 OpenAI Agents SDK
- 학습 곡선: 빠른 프로토타이핑이 필요하면 CrewAI (직관적 API), 세밀한 제어가 필요하면 LangGraph
- 프로덕션 준비도: 엔터프라이즈 수준의 안정성이 필요하면 LangGraph (
LangSmith와 연계) 또는 OpenAI Agents SDK
[출처: LangChain Blog, "Comparing AI Agent Frameworks" (https://blog.langchain.dev/); CrewAI Docs (https://docs.crewai.com/); Google ADK (https://google.github.io/adk-docs/)]
4 MCP (Model Context Protocol)
MCP는 Ch.3에서 다룬 Context Engineering 체계의 '동적 컨텍스트(Tool/API 연동)' 구성 요소를 표준화된 프로토콜로 구현한 것입니다. Context Engineering이 "무엇을 줄까"의 설계 원칙이라면, MCP는 그 원칙을 실현하는 기술 표준입니다. (**수정)
4.1 MCP 개념
**MCP(Model Context Protocol)**는 AI 에이전트가 외부 도구와 데이터 소스에 표준화된 방식으로 접근하기 위한 프로토콜입니다.
기존에는 각 도구마다 개별적인 연동 방식을 구현해야 했지만, MCP를 통해 하나의 표준 인터페이스로 다양한 도구와 데이터에 접근할 수 있습니다.
MCP는 흔히 **"AI 에이전트의 USB-C 포트"**에 비유됩니다. USB-C가 다양한 기기를 하나의 포트로 연결하듯, MCP는 다양한 도구를 하나의 프로토콜로 연결합니다.
[출처: Anthropic, "Model Context Protocol Specification" (modelcontextprotocol.io)]
4.2 MCP 구조
MCP는 Client-Server 구조로 동작합니다.
- MCP Client (클라이언트): AI 에이전트 또는 LLM 애플리케이션이 MCP 서버에 연결하여 도구를 사용하는 측
- 예:
Claude Desktop,Cursor,Claude Code등
- 예:
- MCP Server (서버): 특정 도구나 데이터 소스를 MCP 프로토콜로 제공하는 측
- 예: GitHub MCP Server, Slack MCP Server, DB 접근 MCP Server 등
- Transport (전송 계층): Client와 Server 간의 통신 방식
- Stdio: 로컬 프로세스 간 통신 (로컬 환경)
- SSE (Server-Sent Events): HTTP 기반 원격 통신 (네트워크 환경)
MCP Server가 제공하는 세 가지 기능:
| 기능 | 설명 | 예시 |
|---|---|---|
| Tools (도구) | 에이전트가 호출할 수 있는 실행 가능한 기능 | 파일 읽기, API 호출 |
| Resources (리소스) | 에이전트가 참조할 수 있는 데이터 | 파일 목록, DB 스키마 |
| Prompts (프롬프트) | 미리 정의된 프롬프트 템플릿 | 분석 요청 템플릿 |
4.3 MCP 기업 활용
- 사내 시스템 통합: ERP, CRM, HR 시스템 등을 MCP Server로 구축하여 AI 에이전트가 접근 가능하도록 함
- 데이터베이스 연동: 사내 DB를 MCP Server로 래핑하여 AI 에이전트가 안전하게 데이터를 조회/분석
- 문서 관리: Confluence, SharePoint 등의 문서 시스템과 연동
- 개발 도구 연동: GitHub, Jira, Jenkins 등의 개발 도구를 MCP로 통합
4.4 MCP 현황
- 개발: Anthropic이 2024년 11월 오픈소스로 공개
- 채택 현황: OpenAI, Google, Microsoft를 포함한 주요 AI 기업들이 MCP 지원을 발표
- 의의: AI 에이전트 생태계의 상호운용성(Interoperability) 표준으로 자리잡는 중
- 전망: MCP 서버 마켓플레이스 등장, 기업 내 MCP 서버 구축이 새로운 SI 사업 영역으로 부상
[출처: Anthropic MCP Specification (modelcontextprotocol.io); OpenAI MCP 지원 발표 (2025.03)]
5 에이전트 간 상호운용성 프로토콜 (**추가)
AI 에이전트가 단일 시스템을 넘어 서로 다른 벤더·프레임워크·조직의 에이전트들과 협업하려면 표준화된 통신 프로토콜이 필수적입니다. MCP가 "에이전트 ↔ 도구" 연결을 표준화했다면, 이 섹션에서 다루는 프로토콜들은 "에이전트 ↔ 에이전트" 간 소통을 표준화합니다. (**추가)
5.1 A2A (Agent-to-Agent Protocol) (**추가)
5.1.1 A2A란? (**추가)
**A2A(Agent-to-Agent Protocol)**는 Google이 2025년 4월 Google Cloud Next에서 발표한 오픈 프로토콜로, 서로 다른 프레임워크·벤더·서버에서 동작하는 AI 에이전트들이 표준화된 방식으로 소통하고 협업할 수 있도록 설계되었습니다.
A2A의 핵심 철학은 **불투명성(Opacity)**입니다. 각 에이전트를 블랙박스로 취급하여, 상대 에이전트의 내부 상태·메모리·도구에 접근하지 않고도 협업할 수 있습니다.
**MCP가 "AI 에이전트의 USB-C 포트"라면, A2A는 "AI 에이전트의 외교 프로토콜"**입니다. MCP는 에이전트가 도구를 사용하는 방법을 표준화하고, A2A는 에이전트가 다른 에이전트와 대화하는 방법을 표준화합니다.
설계 원칙:
| 원칙 | 설명 |
|---|---|
| 발견(Discovery) | Agent Card를 통해 상대 에이전트의 능력을 동적으로 탐색 |
| 유연성(Flexibility) | 동기(요청/응답), 스트리밍(SSE), 비동기(웹훅) 통신 모두 지원 |
| 보안(Security) | 인증·인가·서명된 Agent Card를 통한 신원 검증 |
| 단순성(Simplicity) | HTTP, JSON-RPC 2.0, SSE 등 기존 웹 표준을 재사용 |
[출처: Google Developers Blog, "A2A: A new era of agent interoperability" (https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/); A2A Specification (https://a2a-protocol.org/latest/specification/)]
5.1.2 A2A 핵심 구성 요소 (**추가)
① Agent Card (에이전트 카드)
Agent Card는 A2A 서버가 /.well-known/agent-card.json 경로에 게시하는 JSON 메타데이터 문서로, 에이전트의 신원과 능력을 선언합니다.
| 필드 | 설명 | 예시 |
|---|---|---|
id, name, description | 에이전트 신원 정보 | "travel-booking-agent" |
capabilities | 지원 기능 (스트리밍, 푸시 알림 등) | { "streaming": true } |
skills | 수행 가능한 작업 목록과 입·출력 형식 | "항공편 검색", "호텔 예약" |
securitySchemes | 인증 방식 (OAuth 2.0, API Key 등) | "oauth2" |
interfaces | 지원 프로토콜 바인딩 | JSON-RPC, gRPC, HTTP/REST |
v0.3부터 Agent Card에 암호화 서명을 적용하여 신원 위변조를 방지할 수 있습니다.
② Task (작업 단위)
Task는 A2A의 기본 작업 단위로, 고유 ID를 가지며 상태(State)를 거쳐 진행됩니다.
[Task 상태 흐름]
submitted → working → completed
↓ ↑
input-required ──┘
↓
failed / canceled / rejected| 상태 | 설명 |
|---|---|
submitted | 작업 생성됨 (아직 처리 시작 전) |
working | 에이전트가 작업을 처리 중 |
input-required | 추가 정보가 필요하여 클라이언트에 요청 |
auth-required | 인증/인가 정보가 필요 |
completed | 작업 성공적으로 완료 |
failed | 오류로 인해 작업 실패 |
canceled | 클라이언트가 작업 취소 |
rejected | 서버가 작업을 거절 |
③ Message & Artifact
| 객체 | 역할 | 구성 |
|---|---|---|
| Message | 에이전트 간 대화 단위 | role(user/agent) + parts(텍스트, 파일, 구조화 데이터) |
| Artifact | 작업 결과물 | 파일, 구조화 데이터, 미디어 등 |
| Part | 최소 콘텐츠 단위 | text, data(JSON), uri(파일 참조) |
④ 통신 프로토콜
A2A는 HTTP(S) 위에서 세 가지 바인딩을 지원합니다:
| 바인딩 | 설명 | 용도 |
|---|---|---|
| JSON-RPC 2.0 | 기본 바인딩. SendMessage, GetTask 등 11개 메서드 정의 | 범용 통신 |
| gRPC | v0.3에서 추가. Protocol Buffers 기반 고성능 통신 | 저지연·고처리량 시나리오 |
| HTTP/REST | RESTful 엔드포인트 (POST /tasks, GET /tasks/{id}) | 간단한 통합 |
[출처: A2A Specification (https://a2a-protocol.org/latest/specification/); A2A Key Concepts (https://a2a-protocol.org/latest/topics/key-concepts/)]
5.1.3 A2A 동작 예시 (**추가)
시나리오: 여행 계획 에이전트가 항공편 에이전트와 호텔 에이전트에게 작업을 위임
[사용자] → "서울 출장 일정 잡아줘"
↓
[여행 계획 에이전트 (A2A Client)]
│
├─ 1. Agent Card 조회: 항공편 에이전트의 /.well-known/agent-card.json 확인
│ → skills: ["항공편 검색", "예약 생성"]
│
├─ 2. Task 생성 (A2A → 항공편 에이전트)
│ → { role: "user", parts: [{ text: "2/28 서울행 항공편 검색" }] }
│ → 상태: submitted → working → completed
│ → Artifact: 항공편 목록 반환
│
├─ 3. Agent Card 조회: 호텔 에이전트 확인
│ → skills: ["호텔 검색", "예약 생성"]
│
├─ 4. Task 생성 (A2A → 호텔 에이전트)
│ → { role: "user", parts: [{ text: "서울 강남 2/28~3/2 호텔 검색" }] }
│ → 상태: submitted → working → input-required ("예산 범위?")
│ → 추가 입력 제공 → working → completed
│ → Artifact: 호텔 목록 반환
│
└─ 5. 결과 종합 → 사용자에게 출장 일정 제안5.1.4 A2A vs. MCP: 상호 보완 관계 (**추가)
A2A와 MCP는 경쟁이 아닌 보완 관계입니다. A2A 공식 문서에서는 자동차 정비소 비유를 사용합니다:
- A2A = 고객↔매니저, 매니저↔정비사 간의 대화 (에이전트 간 협업)
- MCP = 정비사가 진단 장비와 부품 DB를 사용하는 것 (에이전트가 도구 사용)
| 비교 항목 | A2A | MCP |
|---|---|---|
| 상호작용 유형 | 에이전트 ↔ 에이전트 (Peer-to-Peer) | 에이전트 → 도구/리소스 (Client-Server) |
| 목적 | 자율적 에이전트 간 협업 | 모델과 외부 도구·데이터 연결 |
| 상태 관리 | Stateful (Task 라이프사이클 관리) | 대체로 Stateless (도구 호출 단위) |
| 투명성 | 불투명 (상대 에이전트 내부 상태 비공개) | 투명 (도구 인터페이스가 정의됨) |
| 개발사 | Google (2025년 4월) | Anthropic (2024년 11월) |
| 거버넌스 | Linux Foundation | Linux Foundation (AAIF) |
실무 적용: 하나의 A2A 서버 에이전트가 내부적으로 MCP를 사용하여 도구에 접근하면서, 외부적으로는 A2A를 통해 다른 에이전트와 소통하는 구조가 일반적입니다.
[출처: A2A and MCP (https://a2a-protocol.org/latest/topics/a2a-and-mcp/)]
5.1.5 A2A 현황 및 생태계 (**추가)
| 항목 | 내용 |
|---|---|
| 최신 버전 | v0.3.0 (2025년 7월 30일 릴리스) |
| 스펙 상태 | RC v1.0 (릴리스 후보) |
| 거버넌스 | Linux Foundation (2025년 6월 기부) |
| 공식 SDK | Python, Go, JavaScript, Java, .NET (5개 언어) |
| 지원 조직 | 150개 이상 |
| GitHub Stars | 22,200+ |
주요 지원 기업:
| 분류 | 기업 |
|---|---|
| 클라우드/AI | Google, AWS, Microsoft, Salesforce, SAP, ServiceNow |
| 기술 파트너 | Atlassian, Box, Cohere, LangChain, MongoDB, PayPal |
| 컨설팅/SI | Accenture, BCG, Capgemini, Cognizant, Deloitte, KPMG, McKinsey, PwC, TCS, Wipro |
[출처: Google Cloud Blog, "Agent2Agent protocol is getting an upgrade" (https://cloud.google.com/blog/products/ai-machine-learning/agent2agent-protocol-is-getting-an-upgrade); Linux Foundation Press Release (https://www.linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project-to-enable-secure-intelligent-communication-between-ai-agents)]
5.2 에이전트 상호운용성 생태계 (**추가)
A2A와 MCP 외에도 에이전트 상호운용성을 위한 다양한 표준화 노력이 진행되고 있습니다.
5.2.1 Agentic AI Foundation (AAIF) (**추가)
2025년 12월, Anthropic·OpenAI·Google·Microsoft·AWS 등 주요 AI 기업이 함께 **Linux Foundation 산하에 Agentic AI Foundation(AAIF)**을 설립하였습니다. 이는 에이전트 관련 오픈 표준을 통합 관리하기 위한 거버넌스 조직입니다.
| 항목 | 내용 |
|---|---|
| 설립일 | 2025년 12월 9일 |
| 거버넌스 | Linux Foundation |
| Platinum 멤버 | AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, OpenAI |
| Gold 멤버 | Cisco, Datadog, Docker, IBM, JetBrains, Oracle, Salesforce, SAP, Shopify 등 |
AAIF에 기부된 핵심 프로젝트:
| 프로젝트 | 기부사 | 설명 |
|---|---|---|
| MCP | Anthropic | AI 모델과 도구·데이터를 연결하는 표준 프로토콜 (10,000+ MCP 서버 배포) |
| goose | Block | 오픈소스 로컬 AI 에이전트 프레임워크 |
| AGENTS.md | OpenAI | 프로젝트별 에이전트 가이드를 위한 Markdown 표준 (60,000+ 프로젝트 채택) |
[출처: Linux Foundation, "Agentic AI Foundation" (https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation); Anthropic, "Donating the Model Context Protocol" (https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation)]
5.2.2 AGNTCY (에이전시) (**추가)
AGNTCY는 Cisco의 Outshift 팀이 2025년 3월 오픈소스로 공개한 에이전트 인프라 플랫폼으로, "에이전트의 인터넷(Internet of Agents)"을 목표로 합니다.
| 핵심 구성 요소 | 역할 |
|---|---|
| OASF (Open Agent Schema Framework) | 에이전트 속성·능력·메트릭을 기술하는 스키마로, 에이전트 발견(Discovery) 지원 |
| ACP (Agent Connect Protocol) | 네트워크 기반 에이전트 통신 프레임워크 (인증, 인가, 설정, 오류 처리) |
| SLIM | 멀티모달·Human-in-the-Loop·양자 안전 메시징 계층 |
| Agent Identity | 암호학적으로 검증 가능한 에이전트 신원 및 접근 제어 |
| Agent Observability | 벤더 간 에이전트의 End-to-End 모니터링·디버깅 |
A2A·MCP와의 관계: AGNTCY는 프로토콜 중립적 인프라입니다. A2A 에이전트와 MCP 서버를 AGNTCY 디렉토리에서 발견하고, AGNTCY 관측성 도구로 모니터링할 수 있습니다. A2A/MCP를 대체하는 것이 아니라, 이들이 필요로 하는 **주변 인프라(레지스트리, 신원, 관측성)**를 제공합니다.
[출처: AGNTCY (https://agntcy.org/); Linux Foundation, "AGNTCY Project" (https://www.linuxfoundation.welcomes-the-agntcy-project)]
5.2.3 W3C·IETF 표준화 동향 (**추가)
W3C AI Agent Protocol Community Group:
- 2025년 설립, 190명 이상 참여
- 웹 네이티브 에이전트 프로토콜 개발이 목표
- 에이전트 간 통신, 에이전트 신원 모델, 메타데이터 표준화, 보안·프라이버시, 기존 웹 표준과의 호환성 등 5개 영역에 집중
- 2025년 8월 프로토콜 스펙 초안 및 유스케이스 문서 게시
IETF (Internet Engineering Task Force):
- 에이전트 프로토콜 표준화를 위한 워킹 그룹 설립 논의 중
- AI 에이전트 네트워크 프레임워크, 크로스 디바이스 통신 프레임워크 등 다수의 Internet-Draft 진행
- 아직 RFC(공식 표준)는 아닌 초기 단계
[출처: W3C AI Agent Protocol Community Group (https://www.w3.org/community/agentprotocol/); IETF Blog, "Agentic AI Standards" (https://www.ietf.org/blog/agentic-ai-standards/)]
5.3 에이전트 상호운용성 전체 지형도 (**추가)
| 프로토콜/표준 | 유형 | 범위 | 개발사 | 거버넌스 | 상태 |
|---|---|---|---|---|---|
| A2A | 통신 프로토콜 | 에이전트 ↔ 에이전트 | Linux Foundation | RC v1.0 | |
| MCP | 통신 프로토콜 | 에이전트 ↔ 도구 | Anthropic | Linux Foundation (AAIF) | 10K+ 서버 배포 |
| AGENTS.md | 규약/포맷 | 에이전트 프로젝트 가이드 | OpenAI | Linux Foundation (AAIF) | 60K+ 프로젝트 |
| AGNTCY | 인프라 플랫폼 | 발견·신원·관측성 | Cisco (Outshift) | Linux Foundation | 80+ 지원 조직 |
| W3C CG | 표준 프로세스 | 웹 네이티브 에이전트 프로토콜 | ANP 커뮤니티 | W3C | 초안 (2025.08) |
| IETF Drafts | 표준 프로세스 | 네트워크 수준 에이전트 통신 | 다수 | IETF | Internet-Draft |
핵심 인사이트: 업계는 A2A(에이전트 간) + MCP(에이전트→도구) 두 축으로 수렴하고 있으며, AGNTCY가 인프라를, AAIF가 거버넌스를 담당하는 구조입니다. 주요 AI 기업 모두가 AAIF에 참여하여, 에이전트 상호운용성이 단일 기업이 아닌 업계 공동 표준으로 자리잡고 있습니다. (**추가)
[출처: IBM, "What is Agent2Agent Protocol?" (https://www.ibm.com/think/topics/agent2agent-protocol); OpenAI, "Agentic AI Foundation" (https://openai.com/index/agentic-ai-foundation/)]
6 Agentic RAG (**추가)
6.1 Agentic RAG란? (**추가)
기존의 **RAG(Retrieval-Augmented Generation)**는 사용자 질의에 대해 고정된 파이프라인(검색 → 컨텍스트 주입 → 생성)으로 동작합니다. 반면 Agentic RAG는 AI 에이전트가 RAG 파이프라인 자체를 동적으로 제어하는 고급 패턴입니다.
Agentic RAG에서 에이전트는 다음을 자율적으로 판단합니다:
- 검색 여부: 이미 충분한 정보가 있으면 검색을 건너뜀
- 검색 전략: 키워드 검색, 시맨틱 검색, SQL 쿼리 등 최적의 검색 방법을 선택
- 검색 소스: 어떤 데이터 소스(벡터DB, 관계형DB, 웹 등)에서 검색할지 결정
- 검색 결과 평가: 검색 결과가 충분한지 판단하고, 불충분하면 쿼리를 재작성하여 재검색
- 다단계 검색: 첫 번째 검색 결과를 바탕으로 추가 질문을 생성하여 심층 검색 수행
6.2 기존 RAG vs. Agentic RAG 비교 (**추가)
| 구분 | 기존 RAG (Naive RAG) | Agentic RAG |
|---|---|---|
| 검색 결정 | 항상 검색 수행 | 필요 여부를 에이전트가 판단 |
| 검색 전략 | 고정된 단일 전략 | 상황에 따라 최적 전략 동적 선택 |
| 쿼리 최적화 | 사용자 입력 그대로 사용 | 에이전트가 쿼리를 재작성·분해 |
| 결과 검증 | 검증 없이 바로 사용 | 에이전트가 관련성·충분성 평가 |
| 다중 소스 | 단일 벡터 DB | 복수 데이터 소스를 동적으로 선택 |
| 반복 검색 | 단일 검색 | 결과 부족 시 자동으로 재검색 |
| 도구 활용 | 검색만 수행 | 검색 + 계산 + API 호출 등 복합 활용 |
6.3 Agentic RAG 아키텍처 예시 (**추가)
[사용자 질의]
↓
[라우터 에이전트] ──→ 질의 유형 분석
↓
┌──────────────────────────────────────┐
│ "검색 필요" "검색 불필요" │
│ ↓ ↓ │
│ [검색 전략 결정] [직접 응답 생성] │
│ ↓ │
│ [멀티 소스 검색] │
│ ├─ 벡터 DB │
│ ├─ SQL DB │
│ └─ 웹 검색 │
│ ↓ │
│ [결과 평가 에이전트] │
│ ↓ │
│ 충분? ─No→ 쿼리 재작성 → 재검색 │
│ Yes↓ │
│ [응답 생성 에이전트] │
└──────────────────────────────────────┘
↓
[최종 응답 + 출처 제공]6.4 Agentic RAG 실무 적용 사례 (**추가)
- 기업 내부 지식 검색: 사내 문서, 위키, 메신저 기록 등 다양한 소스를 통합하여 복합 질의에 대응
- 금융 리서치: 재무제표(SQL DB) + 애널리스트 보고서(벡터DB) + 실시간 뉴스(웹)를 결합한 투자 분석
- 고객 지원: 고객 이력(CRM DB) + 제품 매뉴얼(문서DB) + FAQ를 종합하여 맥락에 맞는 상담 제공
- 법률 자문: 판례 검색 + 법령 DB + 계약서 분석을 결합한 법률 리서치
[출처: LlamaIndex, "Agentic RAG" (https://docs.llamaindex.ai/en/stable/use_cases/agents/); LangChain, "Agentic RAG with LangGraph" (https://blog.langchain.dev/agentic-rag-with-langgraph/)]
7 SI 기업에서의 AI 에이전트 활용
7.1 업무 자동화 에이전트
- 문서 처리 자동화: 계약서 검토, 보고서 생성, 이메일 분류 및 응답
- 데이터 처리 자동화: 정기 보고서 생성, 데이터 마이그레이션, ETL 파이프라인 관리
- 워크플로우 자동화: 승인 프로세스, 작업 할당, 일정 관리
7.2 코딩 에이전트
소프트웨어 개발 과정을 AI가 지원하는 에이전트로, SI 기업의 핵심 생산성 도구입니다.
- GitHub Copilot: IDE 내에서 코드 자동 완성 및 제안, GitHub 생태계와 통합
- Cursor: AI 네이티브 IDE로, 코드 편집·생성·리팩토링을 AI가 통합 지원
- Claude Code: Anthropic의 CLI 기반 코딩 에이전트로, 파일 편집·터미널 명령·Git 작업을 자율적으로 수행
- 활용 분야: 코드 생성, 코드 리뷰, 버그 수정, 테스트 작성, 문서화, 레거시 코드 현대화
[출처: GitHub Copilot (github.com/features/copilot), Cursor (cursor.com), Anthropic Claude Code]
7.3 고객 상담 에이전트
- 지능형 고객 상담: FAQ 응답을 넘어 고객의 계정 조회, 주문 처리, 환불 요청 등을 자율적으로 처리
- 옴니채널 지원: 전화, 채팅, 이메일 등 다양한 채널을 통합하여 일관된 고객 경험 제공
- 에스컬레이션: 에이전트가 처리할 수 없는 복잡한 문제는 사람 상담원에게 자동 전달
7.4 데이터 분석 에이전트
- 자연어 기반 데이터 분석: "지난 분기 매출 상위 10개 제품을 보여줘"와 같은 자연어 질의를 SQL로 변환하여 실행
- 자동 보고서 생성: 데이터 분석 결과를 차트와 함께 보고서로 자동 작성
- 이상 탐지: 데이터의 이상 패턴을 자동으로 감지하고 알림
7.5 실무 적용 사례 심화 (**추가)
7.5.1 코드 생성 에이전트 실무 사례 (**추가)
코딩 에이전트는 단순 코드 완성을 넘어 전체 소프트웨어 개발 라이프사이클을 지원하는 방향으로 발전하고 있습니다.
SWE-Agent 및 Devin 사례:
- SWE-Agent (Princeton NLP): GitHub 이슈를 읽고 → 코드를 분석하고 → 버그를 수정하고 → PR을 제출하는 전 과정을 자율적으로 수행.
SWE-bench벤치마크에서 실제 오픈소스 이슈의 12.5%를 자율적으로 해결 (2024년 기준) - Devin (Cognition AI): "세계 최초의 AI 소프트웨어 엔지니어"로 소개되며, 요구사항 분석부터 배포까지 전 과정을 자율 수행. 터미널, 브라우저, 코드 에디터를 직접 조작
- Claude Code (Anthropic): CLI 환경에서 코드베이스 전체를 이해하고, 파일 생성/수정, 테스트 실행, Git 커밋까지 자율적으로 수행
기업 도입 효과:
| 지표 | 효과 |
|---|---|
| 코드 작성 시간 | 평균 30~55% 단축 (GitHub 자체 조사, 2024) |
| 코드 리뷰 시간 | 약 15~20% 감소 |
| 생산성 평준화 | 주니어 개발자의 생산성이 시니어 수준으로 향상 |
[출처: Yang et al., "SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering" (arXiv:2405.15793); GitHub, "Research: Quantifying GitHub Copilot's impact on developer productivity" (https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/)]
7.5.2 고객 서비스 에이전트 실무 사례 (**추가)
기업들이 실제로 도입하고 있는 고객 서비스 에이전트의 구체적 사례입니다.
- Klarna (핀테크): AI 에이전트가 고객 상담의 2/3를 처리, 700명의 상담원 업무를 대체. 평균 응답 시간 11분에서 2분으로 단축, 반복 문의 25% 감소
- Sierra AI: 대화형 AI 에이전트 플랫폼으로, 주문 추적, 반품 처리, 구독 관리 등의 고객 서비스 업무를 자율적으로 처리. WeightWatchers, SiriusXM 등 대형 브랜드에서 도입
- 국내 사례: 카카오, 네이버 등 주요 기업에서 AI 에이전트 기반 고객 상담 시스템을 도입하여 단순 문의 처리율 60% 이상 달성
핵심 설계 원칙:
- 가드레일: 결제, 환불 등 민감한 작업은 반드시 사람의 승인을 거치도록 설계
- 투명성: 고객에게 AI와 대화 중임을 명확히 고지
- 에스컬레이션 경로: 에이전트가 처리 불가능한 상황에서 사람 상담원에게 원활하게 전환
[출처: Klarna, "Klarna AI assistant handles two-thirds of customer service chats" (https://www.klarna.com/international/press/klarna-ai-assistant-handles-two-thirds-of-customer-service-chats-in-its-first-month/); Sierra AI (https://sierra.ai/)]
7.5.3 데이터 분석 에이전트 실무 사례 (**추가)
데이터 분석 에이전트는 비기술 직군의 데이터 활용 역량을 획기적으로 높이고 있습니다.
- Julius AI: 자연어로 데이터 분석을 요청하면
Python/R코드를 생성·실행하여 시각화까지 자동 수행. CSV, Excel 파일을 업로드하면 즉시 분석 가능 - Microsoft Copilot in Power BI: 자연어로 "이번 달 지역별 매출 트렌드를 보여줘"라고 질의하면 자동으로 적절한 차트를 생성하고 인사이트를 도출
- Pandas AI:
Python라이브러리 형태로,DataFrame에 자연어 질의를 통해 데이터를 분석하고 결과를 반환
에이전트 기반 데이터 분석 파이프라인 예시:
- 사용자가 자연어로 분석 요청
- 에이전트가 데이터 소스를 파악하고 접근 방법을 결정
- SQL 쿼리 또는
Python코드를 생성하여 실행 - 결과를 검증하고, 오류가 있으면 자동으로 쿼리를 수정
- 분석 결과를 시각화하고 인사이트를 요약하여 보고서 형태로 제공
[출처: Julius AI (https://julius.ai/); Microsoft, "Copilot in Power BI" (https://learn.microsoft.com/en-us/power-bi/create-reports/copilot-introduction)]
8 AI 에이전트의 한계와 고려사항
AI 에이전트는 강력한 가능성을 가지고 있지만, 실제 도입 시 다음과 같은 한계와 고려사항이 있습니다.
(1) 신뢰성과 예측 가능성
- AI 에이전트의 행동이 항상 예측 가능하지 않으며, 잘못된 판단으로 의도하지 않은 결과를 초래할 수 있음
- 보완: 중요한 행동에 대해 사람의 승인을 요구하는 Human-in-the-Loop 설계 필요
(2) 보안 위험
- 에이전트가 외부 도구에 접근할 수 있으므로, 과도한 권한 부여 시 보안 사고 발생 가능
- 보완: 최소 권한 원칙(Principle of Least Privilege) 적용, 도구 접근 범위를 명확히 제한
(3) 비용 관리
- 에이전트가 여러 단계의 LLM 호출과 도구 사용을 반복하면 토큰 사용량과 API 비용이 급증할 수 있음
- 보완: 실행 단계 수 제한, 비용 모니터링, 효율적인 프롬프트 설계
(4) 디버깅과 모니터링
- 에이전트의 자율적 행동 과정을 추적하고 디버깅하는 것이 복잡함
- 보완: 실행 로그 상세 기록, 관찰 가능성(Observability) 도구 도입
(5) 환각(Hallucination) 전파
- 에이전트가 잘못된 추론을 기반으로 행동하면, 잘못된 결과가 연쇄적으로 확산될 수 있음
- 보완: 각 단계의 결과를 검증하는 가드레일(Guardrail) 구현
8.1 에이전트 평가와 거버넌스 (**수정)
AI 에이전트의 성능과 안전성을 체계적으로 관리하기 위한 평가 프레임워크와 거버넌스 원칙이 중요합니다.
→ Agent의 다차원적 평가 지표(Task Completion Rate, Accuracy, Latency, Cost 등), LLM-as-a-Judge 방법론, SWE-bench 등의 벤치마크, 그리고 다계층 테스트 전략은 Ch.5 Section 1에서 상세히 다룹니다. (**수정)
여기서는 에이전트 도입 시 조직 차원에서 점검해야 할 거버넌스 체크리스트를 소개합니다. (**수정)
8.1.1 에이전트 거버넌스 체크리스트 (**수정)
- [ ] 에이전트의 권한 범위가 최소 권한 원칙에 따라 설정되어 있는가?
- [ ] 민감한 작업(결제, 데이터 삭제, 외부 발송 등)에 Human-in-the-Loop가 적용되어 있는가?
- [ ] 에이전트의 모든 행동이 **감사 로그(Audit Log)**로 기록되는가?
- [ ] 에이전트 실행 비용에 대한 **모니터링과 상한(Cap)**이 설정되어 있는가?
- [ ] 에이전트의 출력에 대한 품질 검증 메커니즘이 존재하는가?
- [ ] 에이전트 장애 시 폴백(Fallback) 절차가 정의되어 있는가?
- [ ] 정기적인 에이전트 성능 평가와 개선 프로세스가 운영되고 있는가?
[출처: NIST, "AI Risk Management Framework" (https://www.nist.gov/artificial-intelligence/executive-order-safe-secure-and-trustworthy-artificial-intelligence); Anthropic, "Core Views on AI Safety" (https://www.anthropic.com/research)]
한눈에 정리하는 이번 챕터
- AI 에이전트는 자율적으로 계획하고, 도구를 사용하며, 다단계 작업을 수행하는 AI 시스템이다.
- Agentic AI는 AI Agent의 상위 개념으로, 자율성·적응성·주도성을 갖춘 AI 시스템 패러다임 전체를 의미한다. (**추가)
- 핵심 설계 패턴에는
ReAct,Plan-and-Execute,Tool Use,Multi-Agent협업, Reflection, Handoff 등이 있다. (**수정) - 주요 에이전트 프레임워크로는
LangGraph,AutoGen,CrewAI,OpenAI Agents SDK, Google ADK 등이 있다. (**수정) - Agentic RAG는 에이전트가 RAG 파이프라인을 동적으로 제어하여 검색 전략, 소스, 결과 평가를 자율적으로 수행하는 고급 패턴이다. (**추가)
- **MCP(Model Context Protocol)**는 AI 에이전트가 외부 도구에 접근하기 위한 표준 프로토콜이다.
- **A2A(Agent-to-Agent Protocol)**는 서로 다른 벤더·프레임워크의 에이전트들이 표준화된 방식으로 소통·협업하기 위한 프로토콜이다. MCP(에이전트→도구)와 보완 관계로, A2A(에이전트↔에이전트) 두 축이 업계 표준으로 수렴 중이다. (**추가)
- **Agentic AI Foundation(AAIF)**에 Anthropic·OpenAI·Google·Microsoft·AWS 등이 참여하여, 에이전트 상호운용성이 업계 공동 표준으로 자리잡고 있다. (**추가)
- SI 기업에서는 업무 자동화, 코딩, 고객 상담, 데이터 분석 등 다양한 분야에서 AI 에이전트를 활용할 수 있다.
- 코딩 에이전트(
SWE-Agent,Devin,Claude Code), 고객 서비스 에이전트(Klarna, Sierra), 데이터 분석 에이전트(Julius AI) 등 실제 서비스가 빠르게 확산되고 있다. (**추가) - AI 에이전트 도입 시 신뢰성, 보안, 비용, 모니터링 등의 고려사항을 충분히 검토해야 하며, 체계적인 평가 지표와 거버넌스 프레임워크 수립이 필수적이다. (**수정)
마무리
이번 챕터에서는 AI 에이전트의 개념, 핵심 패턴, 프레임워크, MCP, 그리고 SI 기업에서의 활용 사례를 종합적으로 살펴보았습니다.
AI 에이전트는 단순한 질의응답을 넘어 복잡한 업무를 자율적으로 수행할 수 있는 차세대 AI 기술로, SI 기업의 서비스 혁신과 생산성 향상에 핵심적인 역할을 할 것으로 기대됩니다.
특히 Agentic AI 패러다임의 확산과 함께, 다음과 같은 전환이 가속화되고 있습니다: (**추가)
- 단일 에이전트에서 Multi-Agent 시스템으로
- 고정된 파이프라인에서 Agentic RAG로
- 개별 도구 연동에서 MCP 기반 표준 연동으로
- 폐쇄적 에이전트에서 A2A 기반 개방형 에이전트 협업으로 (**추가)
이러한 변화는 SI 기업이 AI를 단순한 도구가 아닌, 비즈니스 프로세스의 자율적 참여자로 활용할 수 있는 새로운 기회를 열어주고 있습니다. (**추가)
Gartner는 2028년까지 기업 소프트웨어 애플리케이션의 33%가 Agentic AI를 포함하게 될 것으로 전망하며, 이는 현재 1% 미만에서 급격한 성장을 의미합니다. SI 기업으로서 이러한 변화에 선제적으로 대응하기 위해, 에이전트 프레임워크에 대한 기술 역량 확보와 함께 안전하고 효과적인 에이전트 거버넌스 체계를 수립하는 것이 중요합니다. (**추가)
다음 챕터에서는 AI Agent의 품질을 체계적으로 평가하고, 보안 위협에 대응하며, 안전한 Agent를 설계하기 위한 거버넌스 체계에 대해 다루겠습니다. (**수정)