AI 에이전트와 에이전틱 AI

개요

**에이전틱 AI(Agentic AI)**는 단순히 질문에 답하는 모델을 넘어, 스스로 도구를 사용해 여러 단계를 거쳐 목표를 달성하는 AI 시스템이다. 상위 문서AI 모델의 분류 체계에서 "규모 및 활용 형태" 축의 "에이전틱 AI"에 해당한다.

핵심적인 변화는 모델의 능력보다 통합(Integration) 패턴이 중요해졌다는 점이다. 2026년 현재 에이전트 개발의 실질적 병목은 LLM 성능이 아니라, 모델이 외부 데이터·도구·시스템과 어떻게 안전하게 결합될 것인가에 있다.

에이전트의 구조적 구성요소

일반적인 에이전트 시스템은 다음 구성요소로 나뉜다.

구성요소	역할	구현 방식
호스트(Host)	에이전트 앱의 실행 주체	CLI, 웹앱, IDE 플러그인, 자동화 플랫폼
모델(LLM)	추론·계획 담당	오픈 LLM 또는 프론티어 API
도구(Tools)	모델이 호출할 외부 기능	함수 호출, API 래퍼, MCP 서버
메모리(Memory)	대화/작업 이력 유지	단기(컨텍스트) + 장기(벡터DB, 파일)
오케스트레이션	단계 실행·재시도·실패 처리	상태 기계, 플로우 엔진, 이벤트 루프

위 구조는 상위 문서의 "멀티모달" 및 "학습 방식" 분류와는 별개로, 시스템 설계 관점의 분류다. 어떤 LLM을 쓰든 에이전트 시스템은 대략 이 골격을 따른다.

도구 연결 표준: MCP (Model Context Protocol)

도구 통합에서 가장 중요한 developments는 MCP(Model Context Protocol) 다. Anthropic이建立的 open 표준으로, LLM 애플리케이션과 외부 데이터 소스·도구 사이의 통합을 하나의 프로토콜로 표준화한다. 이 프로토콜은 JSON-RPC 2.0 메시지를 기반으로 하며, 호스트(Hosts)–클라이언트(Clients)–서버(Servers) 3자 구조를 사용한다.

호스트(Host): LLM 애플리케이션(연결을 시작하는 쪽)
클라이언트(Client): 호스트 내부의 커넥터
서버(Server): 컨텍스트와 capability를 제공하는 서비스

MCP의 목표는 각 데이터 소스마다 별도의 커넥터를 유지해야 했던 파편화된 통합을 단일 프로토콜로 대체하는 것이다. 즉, 데이터 소스 N개에 커넥터 N개가 필요했던 구조가 프로토콜 하나로 단순해진다.

2026-07-28 스펙의 주요 변경

MCP는 stateless(무상태) 방향으로 큰 전환을 이루었다. 주요 변경사항은 다음과 같다.

변경 항목	내용
stateless protocol core	양방향 stateful 프로토콜에서 request/response 무상태로 전환
MRTR (Multi Round-Trip Requests)	sampling·elicitation 등 서버→클라이언트 요청의 재설계. 항상 열린 양방향 stream 불필요해짐
헤더 기반 라우팅	메서드·툴명이 `Mcp-Method`, `Mcp-Name` HTTP 헤더로 전달. 게이트웨이가 헤더로 라우팅/인가 가능
세션 폐기	`initialize`/`initialized` 교환과 `Mcp-Session-Id` 헤더 폐기(SEP-2575, SEP-2567). 각 요청이 자체적으로 프로토콜 버전·클라이언트 신원·capability를 `_meta`로 전달
extensions 프레임워크	Tasks, MCP Apps, Enterprise Managed Authorization(EMA) 등 공식 확장 정의
캐시 가능 list 결과	list 계열 결과 캐싱 지원
Tier 1 SDK	TypeScript, Python, Go 등 주요 언어 SDK가 당일 `2026-07-28` 스펙 대응

출처: MCP 공식 블로그(2026-07-28 스펙 발표) 및 modelcontextprotocol.io 공식 스펙 문서.

MCP는 Anthropic이 시작했지만 open source 프로젝트·생태계로 운영되며, AWS 등 주요 클라우드 벤더도 지원을|Committed|하고 있다. AWS는 Bedrock AgentCore에서 무상태 MCP 서버를 표준 스케일 인프라에 배포할 수 있다고 밝혔다.

에이전트 개발 패턴

1) ReAct (Reasoning + Acting)

추론과 행동을 번갈아 수행하는 패턴. 모델이 "생각 → 도구 호출 → 결과 관찰 → 다시 생각" 사이클을 반복한다. 단순한 도구 사용에서 가장 널리 쓰이는 기본 패턴이다.

2) 계획-실행 분리 (Plan-and-Execute)

먼저 전체 작업 계획을 세우고, 이후 실행에 집중하는 패턴. 여러 단계가 확정된 워크플로우(예: 데이터 수집 → 분석 → 보고서 생성)에 적합하며, 재현성과 감사 가능성이 높아진다.

3) 다중 에이전트 (Multi-Agent)

역할을 나눈 여러 에이전트가 협업하는 패턴. 상위 문서의 멀티모달/계층 분류와 유사하게, 상위·하위 에이전트를 두어 병렬 처리하거나 서로 검증하게 한다. 복잡도는 높지만 확장성이 크다.

에이전트 도입 시 고려사항

고려사항	설명
도구 호출 신뢰성	모델이 잘못된 도구를 호출하거나 잘못된 인자를 넘길 수 있음. 입력 검증·권한 제한이 필수
권한과 격리	에이전트에게 파일 시스템·Shell·외부 API 접근 권한을 줄 경우, 샌드박스와 최소 권한 원칙 적용
비용 예측	다단계 에이전트는 호출 횟수가 늘기 쉬워 토큰 비용이 누적됨. 단계별 예산 상한 설정
오류 처리	도구 실패·타임아웃 시 재시도/대체 경로 설계. 무한 재시도는 비용 폭탄 위험
감사 가능성	어떤 도구를 어떤 인자로 언제 호출했는지 로깅. 문제 발생 시 추적 가능해야 함
평가(Eval)	단일 정답 없는 환경이므로 성공 기준을 명시적으로 정의하고 반복 평가

에이전트 vs 단순 LLM 호출

구분	단순 LLM 호출	에이전틱 AI
작업 범위	단일 질의응답	다단계 목표 달성
외부 interaction	없음(또는 단일 API)	반복적 도구·시스템 호출
소요 시간	초 단위	분~시간 단위
실패 모드	잘못된 답변	잘못된 도구 호출, 비용 초과, 무한 루프
필요한 설계	프롬프트	권한·검증·로깅·예산·평가까지
상위 문서 분류	"파운데이션 모델" 활용	"에이전틱 AI" (활용 형태)

에이전트는 모델이 아니라 시스템 설계다. 강한 LLM을 골라도 권한·검증·평가 설계가 없으면 실전에 투입하기 어렵다.

선택 가이드

사용 목적	접근 방식	확인 포인트
단순 질의응답 자동화	에이전트 도입 불필요, RAG/파인튜닝 고려	상위 문서 "파운데이션 모델" 활용
여러 시스템 연동 작업	MCP 서버 + 단일 에이전트	MCP 클라이언트/서버 구현체 선택
확정적 다단계 워크플로우	계획-실행 분리 패턴	각 단계 검증·재시도 설계
대규모 병렬 처리	다중 에이전트	에이전트 간 통신 비용·일관성
고위험 시스템 자동화	에이전트 대신 결정론적 코드	자동화 위험도 평가 우선
표준화된 도구 통합	MCP 채택	무상태 전환(2026-07-28) 호환 고려

다음 단계: 에이전트가 이해할 수 있는 멀티모달 입력(문서·이미지·영상)은 멀티모달 AI 모델 참고. 모델 자체 선택은 오픈 소스 LLM 모델 참고.

참고 자료

MCP 공식 스펙: https://modelcontextprotocol.io/specification/2026-07-28
MCP 공식 블로그(2026-07-28 스펙 발표): https://blog.modelcontextprotocol.io/posts/2026-07-28/
Anthropic MCP 발표: https://www.anthropic.com/news/model-context-protocol

상위 문서: ← AI 模型 출처: [주제 가이드 — AI 에이전트와 에이전틱 AI] (자체 조사·작성 2026-10-02) — MCP 구조·스펙 변경은 modelcontextprotocol.io 공식 스펙과 Anthropic 공식 발표 기준 공급사: 자체 작성 + MCP 공식 스펙 / Anthropic 공식 자료

변경 이력

날짜	변경
2026-10-02	초안 작성 — 에이전트 구성요소 + MCP 표준/2026-07-28 스펙 변경 + 개발 패턴 + 도입 고려사항

개요