Chapter 4. AI Agent & Agentic AI
AI Agent의 개념
AI Agent란?
AI Agent의 정의
AI Agent란 주어진 목표를 달성하기 위해 환경(Environment)을 인식하고(Perception), 상황을 판단하여 의사결정을 내린 뒤(Action Selection), 실제 행동을 수행하는 자율적 소프트웨어 시스템입니다. 기존의 LLM은 주로 단일 요청에 대해 텍스트 응답을 생성하는 방식으로 사용되는 반면, AI Agent는 LLM을 핵심 추론 엔진으로 활용하면서 외부 도구 호출과 다단계 실행을 통해 실제 작업을 수행할 수 있습니다. 예를 들어, "다음 주 서울 출장 일정을 잡아줘"라는 요청을 받으면
- 일반 LLM: "출장 일정을 잡으려면 항공편과 호텔을 예약하세요"라고 텍스트 응답만 생성
- AI Agent: 캘린더를 확인하고 → 항공편을 검색하고 → 호텔을 예약하고 → 캘린더에 일정을 등록하는 일련의 행동을 자율적으로 수행
에이전트와 기존 AI 챗봇의 차이
| 비교 항목 | 기존 AI 챗봇 | AI Agent |
|---|---|---|
| 동작 방식 | 질문-응답(Q&A) 방식 | 목표 기반 자율 행동 |
| 외부 도구 사용 | 불가 또는 매우 제한적 | 다양한 도구(API, DB, 파일 등) 활용 가능 |
| 계획 수립 | 없음 | 작업을 분해하고 실행 계획을 수립 |
| 다단계 작업 | 한 번의 요청에 한 번의 응답 | 여러 단계의 작업을 연속적으로 수행 |
| 오류 처리 | 사용자가 직접 수정 | 결과를 평가하고 스스로 수정 |
| 예시 | 일반 ChatGPT 대화 | 코딩 에이전트, 업무 자동화 에이전트 |
에이전트 기본 용어
뒤에서 나오는 ReAct, Plan-and-Execute, 멀티 에이전트 패턴을 이해하려면 먼저 아래 용어를 구분하는 것이 좋습니다.
| 용어 | 의미 | 예시 |
|---|---|---|
| Goal(목표) | 에이전트가 최종적으로 달성해야 하는 상위 목적 | "출장 일정을 확정한다" |
| Task(작업) | 목표를 이루기 위해 나눈 하위 작업 | 항공권 조회, 호텔 예약, 일정 등록 |
| Action(행동) | 특정 시점에 실제 수행하는 개별 행위 | 캘린더 API 호출, 검색 쿼리 실행 |
| Action Space(행동 공간) | 에이전트가 선택할 수 있는 전체 행동 집합 | 검색, 파일 읽기, 이메일 발송, DB 조회 |
| Observation(관찰) | 행동 후 환경에서 받은 결과나 피드백 | API 응답, 검색 결과, 오류 메시지 |
| Policy(정책) | 에이전트가 특정 상황에서 어떤 행동이나 도구를 선택할지를 결정하는 규칙 또는 전략 | "민감 데이터는 승인 전 외부 전송 금지" |
핵심 구성 요소
AI Agent는 사용자의 요청을 받아 자율적으로 작업을 수행하는 시스템으로, 다음과 같은 계층 구조로 이루어집니다.
사용자(User): 에이전트에게 목표와 지시를 제공하는 주체. 에이전트의 자율성 수준에 따라 개입 정도가 달라짐 (Human-in-the-Loop)
오케스트레이션(Orchestration): 에이전트의 제어 계층으로, 사용자의 요청을 해석하고 작업을 계획(Planning)하며 실행(Execution)을 관리합니다. ReAct, Plan-and-Execute와 같은 에이전트 패턴이 이 계층에서 구현됨
모델(Model): 오케스트레이션의 핵심 엔진인 LLM. 자연어 이해·생성, 추론, 판단을 담당하며, 어떤 도구를 사용할지, 다음에 무엇을 할지를 결정함
도구(Tools): 에이전트가 외부 세계와 상호작용하는 수단. API 호출, 코드 실행, 파일 처리, 웹 검색 등. MCP 등 표준 프로토콜을 통해 연결됨
메모리(Memory): 에이전트의 상태와 맥락을 유지하는 저장소
- 단기 메모리(Short-term): 현재 세션의 대화·실행 이력 (컨텍스트 윈도우)
- 장기 메모리(Long-term): 세션 간 유지되는 사용자 선호, 학습된 패턴
지식베이스(Knowledge Base): 에이전트가 참조하는 외부 지식 저장소. 벡터DB, 문서 저장소, 사내 위키 등. RAG를 통해 검색·활용됨
Agentic AI의 정의와 특징
Agentic AI란?
Agentic AI는 단순히 하나의 AI Agent를 지칭하는 것이 아니라, AI 시스템이 자율성(Autonomy), 적응성(Adaptability), **주도성(Proactivity)**을 갖추고 복잡한 목표를 독립적으로 달성하는 패러다임 전체를 의미합니다. Gartner는 2025년 전략 기술 트렌드에서 Agentic AI를 다음과 같이 정의하였습니다.
Agentic AI의 핵심은 인간의 개입을 최소화하면서 다단계 의사결정과 실행을 자율적으로 수행하는 것을 지향한다는 점입니다. 이는 단순한 자동화(Automation)를 넘어, AI가 상황을 판단하고 최적의 전략을 선택하는 자율적 의사결정(Autonomous Decision-Making) 단계로의 진화를 의미합니다.
AI Agent vs. Agentic AI
| 구분 | AI Agent (에이전트) | Agentic AI (에이전틱 AI) |
|---|---|---|
| 범위 | 특정 작업을 수행하는 개별 소프트웨어 단위 | 자율적 AI 시스템의 설계 철학·패러다임 전체 |
| 자율성 수준 | 정해진 도구와 규칙 내에서 행동 | 여러 에이전트·도구·워크플로우를 조합해 더 높은 수준의 자율성을 지향 |
| 적응성 | 사전 정의된 워크플로우에 의존 | 환경 변화와 피드백에 따라 계획·협업 구조를 조정 |
| 학습 | 제한적 (세션 내 컨텍스트 유지) | 피드백 루프, 메모리, 거버넌스, 멀티 에이전트 조합을 통해 운영 수준에서 개선 |
| 협업 | 단독 또는 제한된 협업 | 다수 에이전트 간 동적 협업 (Multi-Agent) |
| 비유 | 숙련된 직원 한 명 | 자율적으로 운영되는 팀 전체 |
쉽게 말하면, AI Agent는 개별 실행 단위이고, Agentic AI는 이런 실행 단위를 어떤 방식으로 설계·조합·운영할 것인가에 대한 상위 접근입니다.
Agentic AI의 도입 수준 분류
Salesforce는 기업의 Agentic AI 도입 수준을 4단계(L1~L4)로 분류하는 Agentic Maturity Model을 제안하였습니다. 일부 자료에서는 기존 규칙 기반 자동화를 L0로 별도 구분하기도 합니다. 업계에서 합의된 표준은 아니지만, 에이전트의 자율성과 오케스트레이션 복잡도에 따라 도입 수준을 가늠하는 참고 프레임워크로 활용할 수 있습니다.
| Level | 단계 | 설명 | 예시 |
|---|---|---|---|
| L0 | Fixed Rules & Repetitive Tasks | 사전 정의된 규칙에 따라 동작하며 추론·학습 능력이 없음 | FAQ 챗봇, 비밀번호 재설정 봇 |
| L1 | Information Retrieval Agents | 데이터를 검색하고 사람에게 다음 행동을 추천하지만, 직접 실행하지는 않음 | 고객 문의 시 관련 문서를 검색하여 상담원에게 추천 |
| L2 | Simple Orchestration, Single Domain | 단일 도메인 내에서 저복잡도 작업을 자율적으로 수행 | 캘린더·이메일 시스템을 사용해 회의 일정 자동 조율 |
| L3 | Complex Orchestration, Multiple Domains | 여러 데이터 소스와 부서를 아우르는 복잡한 워크플로우를 자율적으로 관리 | CRM·서비스 티켓·재무 데이터를 통합하여 영업 파이프라인 관리 |
| L4 | Multi-Agent Orchestration | 독립적인 에이전트들이 이종 시스템 간에 협업하며, 거버넌스 프레임워크와 사람의 감독 하에 동작 | 주문 처리·재고 관리·피드백 라우팅 에이전트가 부서 간 동시 협업 |
참고: Salesforce는 상위 단계로의 진입에는 기술 구현뿐 아니라 데이터 준비도, 보안, 인력의 협업 역량이 함께 갖춰져야 한다고 강조합니다.
AI Agent의 핵심 구성 요소
앞서 소개한 에이전트의 계층 구조---사용자 → 오케스트레이션 → 모델/도구/메모리/지식베이스---를 구성하는 각 요소를 상세히 살펴봅니다.
오케스트레이션 (Orchestration)
오케스트레이션은 **에이전트의 제어 계층(control layer)**으로, 사용자의 요청을 받아 목표를 달성할 때까지 모델·도구·메모리·지식베이스의 실행 흐름을 조율하고 관리하는 핵심 컴포넌트입니다. 오케스트레이션 계층은 사용자 요청을 처리하기 위해 여러 구성 요소의 실행 순서를 결정하고 상호작용을 관리하며, 목표 달성 여부를 판단하면서 작업을 반복적으로 진행합니다. 일반적으로 이러한 동작은 에이전틱 루프(Agentic Loop) 형태로 수행됩니다.
- 입력 해석 : 사용자의 요청을 분석하여 목표를 파악
- 작업 계획 : 목표 달성을 위한 단계와 실행 전략을 수립
- 행동 실행 : 모델, 도구, 메모리, 지식베이스 등을 호출하여 실제 작업 수행
- 관찰(Observation) : 도구 실행 결과나 환경 변화를 수집
- 결과 평가 : 현재 결과를 검증하고 목표 달성 여부를 판단하여 루프 계속 여부 결정
오케스트레이션 계층에서 구현되는 구체적인 동작 패턴(ReAct, Plan-and-Execute 등)은 아래 "AI Agent의 핵심 패턴" 섹션에서 상세히 다룹니다.
모델 (Model)
오케스트레이션의 핵심 추론 엔진인 LLM(Large Language Model)입니다. 에이전트의 판단과 결정은 궁극적으로 모델의 추론 능력에 의존합니다.
역할: 자연어 이해·생성, 논리적 추론, 판단, 의사결정
핵심 기능:
- 사용자의 요청을 이해하고 의도를 파악
- 현재 상황에서 다음에 수행할 행동(도구 호출, 응답 생성 등)을 결정
- 도구 호출에 필요한 파라미터를 생성
- 도구 실행 결과를 해석하고 다음 단계를 추론
에이전트용 모델 선택 시 고려사항:
| 기준 | 설명 |
|---|---|
| 추론 능력 | 복잡한 다단계 추론이 필요하면 고성능 모델 선택 |
| 비용 | 에이전트는 다수의 LLM 호출을 반복하므로, 토큰당 비용이 전체 운영 비용에 직접 영향 |
| 응답 속도 | 실시간 상호작용이 필요한 에이전트는 저지연 모델이 유리 |
| 컨텍스트 윈도우 | 긴 대화 이력이나 대량의 도구 결과를 처리해야 하면 대용량 컨텍스트 모델 필요 |
도구 (Tools)
에이전트가 외부 세계와 상호작용하는 수단입니다. LLM 단독으로는 수행할 수 없는 작업(데이터 조회, 코드 실행, API 호출 등)을 도구를 통해 수행합니다.
| 분류 | 설명 | 예시 |
|---|---|---|
| 검색 도구 | 외부 정보 검색 | 웹 검색, 데이터베이스 조회 |
| 코드 실행 | 프로그래밍 언어 실행 | Python, SQL 등의 코드 실행 |
| API 호출 | 외부 서비스 연동 | 이메일 발송, 캘린더 관리, 결제 처리 |
| 파일 처리 | 파일 시스템 조작 | 문서 읽기, 파일 생성/수정 |
도구 사용 메커니즘
모델(LLM)이 각 도구의 **설명(Description)**을 읽고, 현재 상황에 가장 적합한 도구를 자율적으로 선택합니다. 따라서 도구의 이름과 설명을 명확하고 구체적으로 작성하는 것이 에이전트 성능에 직접적인 영향을 줍니다.
[오케스트레이션]
↓ "이 상황에 어떤 도구를 사용할까?"
[모델(LLM)] ──→ 도구 설명(Description) 참조
↓
도구 선택 + 파라미터 생성
↓
[도구 실행] ──→ 결과 반환
↓
[모델(LLM)] ──→ 결과 해석 → 다음 행동 결정도구 연결을 위한 오픈 프로토콜인 MCP(Model Context Protocol)는 아래 "MCP (Model Context Protocol)" 섹션에서 상세히 다룹니다.
Function Calling(함수 호출) 동작 원리
에이전트가 도구를 사용하기 위한 핵심 메커니즘이 **Function Calling(함수 호출)**이다. LLM이 직접 외부 함수를 실행하는 것이 아니라, 호출할 함수명과 인자를 구조화된 형태로 출력하면, 런타임(애플리케이션)이 이를 받아 실제 실행하고 결과를 LLM에게 반환하는 방식으로 동작한다.
동작 흐름:
도구 정의(Tool Definition): 개발자가 사용 가능한 함수의 이름, 설명(Description), 파라미터를 정의하여 LLM에게 전달
도구 선택 및 호출 생성: LLM이 사용자 요청을 분석하고, 각 도구의 설명(Description)을 참고하여 적합한 함수를 선택한 뒤, 함수명과 인자를 구조화된 형태(일반적으로 JSON 형식)로 출력 (이 시점에서 실제 실행은 일어나지 않음)
런타임 실행: 애플리케이션(런타임)이 LLM의 출력을 파싱하여 해당 함수를 실제로 호출하고 결과를 획득
결과 해석: 함수 실행 결과를 LLM에게 다시 전달하면, LLM이 이를 해석하여 최종 응답을 생성하거나 추가 함수 호출을 결정
LLM은 도구의 **이름(name)**과 **설명(description)**을 보고 어떤 도구를 사용할지 판단하므로, 도구 설명을 명확하고 구체적으로 작성하는 것이 도구 선택 정확도에 직접적인 영향을 준다. 예를 들어 LangChain에서는 @tool 데코레이터의 docstring이 곧 LLM이 참고하는 도구 설명이 되며, 이 설명이 모호하면 LLM이 잘못된 도구를 선택할 수 있다. OpenAI, Anthropic, Google 등 주요 플랫폼 모두 이와 동일한 방식(도구 목록을 JSON Schema로 정의하여 API에 전달)으로 Function Calling을 지원한다.
메모리 (Memory)
에이전트의 상태와 맥락을 유지하는 저장소입니다. 메모리를 통해 에이전트는 이전 상호작용의 결과를 기억하고, 일관된 행동을 유지합니다.
| 유형 | 범위 | 저장 내용 | 구현 방식 |
|---|---|---|---|
| 단기 메모리 | 현재 세션 | 대화 이력, 도구 실행 결과, 중간 추론 과정 | 컨텍스트 윈도우 (프롬프트에 포함) |
| 장기 메모리 | 세션 간 유지 | 사용자 선호, 학습된 패턴, 과거 작업 이력 | 외부 저장소 (DB, 파일 등) |
단기 메모리(Short-term Memory): 현재 작업 세션 내의 정보로, LLM의 컨텍스트 윈도우에 직접 포함됩니다. 대화가 길어지면 컨텍스트 윈도우 한계에 도달하므로, 오래된 정보를 요약·압축하는 전략이 필요합니다.
장기 메모리(Long-term Memory): 세션이 종료된 후에도 유지되는 정보입니다. 사용자 프로필, 과거 대화 요약, 자주 사용하는 도구 패턴 등을 외부 저장소에 기록하여, 에이전트가 시간이 지날수록 더 개인화된 서비스를 제공할 수 있게 합니다.
- 일부 에이전트 시스템에서는 장기 메모리를 Episodic Memory(경험 기반 기록)와 Semantic Memory(지식 기반 정보)로 구분하기도 합니다.
지식베이스 (Knowledge Base)
에이전트가 참조하는 외부 지식 저장소입니다. 모델의 학습 데이터에 포함되지 않은 최신 정보, 사내 문서, 도메인 전문 지식 등을 제공하여 에이전트의 응답 품질과 정확도를 높입니다.
| 유형 | 설명 | 예시 |
|---|---|---|
| 벡터 DB | 문서를 임베딩하여 시맨틱 검색 지원 | Pinecone, Weaviate, ChromaDB |
| 관계형 DB | 구조화된 데이터 저장·조회 | PostgreSQL, MySQL |
| 문서 저장소 | 비정형 문서 관리 | Confluence, SharePoint, Notion |
| 웹 소스 | 실시간 외부 정보 | 웹 검색, RSS 피드 |
- 활용 방식: 에이전트는 사용자의 질의에 답하기 위해 지식베이스에서 관련 정보를 **검색(Retrieval)**하고, 이를 모델의 컨텍스트에 주입하여 정확하고 근거 있는 응답을 생성합니다. 이 과정이 RAG(Retrieval-Augmented Generation)이며, 에이전트가 질의 생성, 반복 검색, 정보 통합 등을 자율적으로 수행하는 방식이 Agentic RAG입니다.
AI Agent의 핵심 패턴
AI Agent가 작업을 수행하는 방식에는 여러 가지 패턴이 있습니다. ReAct, Plan-and-Execute 등 핵심 패턴은 2022~2023년에 제안되어 에이전트 구현의 기초가 되었으며, 이후 Reasoning Model(o1, o3, Claude Extended Thinking 등)의 등장으로 패턴의 적용 방식이 진화하고 있습니다. 단순한 반사형부터 자율적으로 심층 조사를 수행하는 리서치 에이전트까지, 복잡도에 따라 대표적인 패턴들을 살펴보겠습니다.
반사형 에이전트 (Reactive Agent)
가장 단순한 형태의 에이전트로, 현재 입력만 보고 즉각 반응하는 패턴입니다. 내부 상태나 과거 기억 없이 사전에 정의된 조건-행동 규칙(IF-THEN)에 따라 동작합니다. 중간 추론 작업을 생략하므로 지연시간이 매우 짧고 성능이 예측 가능해 키워드 기반 라우팅, 단일 단계 데이터 조회, 간단한 자동화 같은 용도에 적합합니다.
동작 방식: 입력(Percept) → 조건 매칭 → 행동(Action) (추론이나 계획 없이 즉시 반응)
예시:
- "안녕하세요" → "안녕하세요! 무엇을 도와드릴까요?" (규칙 기반 챗봇)
- 특정 키워드 감지 시 → 미리 정해진 답변 반환 (FAQ 봇)
- 이상 수치 감지 시 → 알림 발송 (모니터링 봇)
장점: 구현이 간단하고, 응답이 빠르며, 동작을 예측하기 쉬움
단점: 복잡한 상황이나 예상하지 못한 입력에 대응할 수 없음, 맥락을 고려하지 못함
ReAct 패턴 (Reasoning + Acting)
ReAct는 **추론(Reasoning)**과 **행동(Acting)**을 번갈아 수행하며 문제를 해결하는 패턴입니다. 모델이 **사고(Thought)**를 생성하고 도구를 선택해 호출한 뒤 결과를 관찰하고 다시 계획을 갱신하며 동작합니다.
동작 방식: 사고(Thought) → 행동(Action) → 관찰(Observation) → 사고 → ... 반복
예시 (고객 주문 조회):
- 사고: "고객 ID 12345의 최근 주문을 조회해야 한다"
- 행동: 주문 DB 조회 API 호출
- 관찰: 주문 #A100, #A101, #A102 반환됨
- 사고: "가장 최근 주문 #A102의 상세 정보를 확인해야 한다"
- 행동: 주문 상세 API 호출
- 관찰: 주문 상세 정보 반환
- 최종 응답 생성
장점:
- 탐색적 시나리오(예: 동적 데이터 분석, 다중 소스 통합, 문제 해결)에 강하며 중간에 전략을 조정할 수 있는 유연성
- 도구 호출, 관찰 결과, 단계별 의사결정 등 실행 과정을 로그로 남기 쉬워 디버깅과 감사에 유리
단점: 루프 구조로 인해 API 비용과 응답 시간이 늘어남
현재 동향: ReAct는 2022년 제안 이후 에이전트 구현의 사실상 표준이었으나, 2024~2025년 Reasoning Model(o1, o3, Claude Extended Thinking 등)의 등장으로 모델 자체가 내부적으로 다단계 추론을 수행할 수 있게 되었다. 이에 따라 단순한 도구 호출 시나리오에서는 명시적 ReAct 루프 없이도 모델이 스스로 추론→행동을 수행하는 추세가 나타나고 있다. 그러나 복잡한 멀티 도구 시나리오에서는 여전히 명시적 ReAct 루프가 실행 과정의 투명성과 제어 가능성 측면에서 유효하다.
Plan-and-Execute 패턴 (계획 후 실행 에이전트)
먼저 모델이 다단계 계획을 생성하는 계획 단계가 있고 이어서 계획된 각 단계를 도구 호출을 통해 수행하는 실행 단계가 있습니다. 이렇게 역할을 분리하면 계획 단계에서 장기적인 추론에 집중하고 실행 단계는 필요한 툴만 호출해 불필요한 LLM 호출을 줄입니다.
동작 방식: 전체 계획 수립 → 단계별 실행 → 필요 시 계획 수정
예시:
- 계획: ① 데이터 수집 → ② 데이터 정제 → ③ 분석 수행 → ④ 보고서 작성
- 각 단계를 순차적으로 실행하되, 중간 결과에 따라 계획을 수정 가능
장점: 복잡한 작업을 체계적으로 분해하여 실행, 진행 상황 추적이 용이
단점: 초기 계획 수립에 시간이 소요, 예상치 못한 상황에 유연한 대응이 어려울 수 있음
현재 동향: Plan-and-Execute는 현재 코딩 에이전트(Claude Code, Cursor, Devin 등)에서 널리 활용되는 패턴이다. Reasoning Model의 발전으로 계획 단계의 품질이 크게 향상되어 계획 수정(Re-planning) 빈도가 줄어들고 있으며, 이는 전체 에이전트 실행의 효율성을 높이는 데 기여하고 있다.
쿼리 분해 에이전트 (Query Decomposition Agent)
복잡한 질문이나 요청을 여러 개의 하위 질문으로 분해한 후, 각각을 처리하고 결과를 종합하는 패턴입니다. 이 패턴은 '자문 후 검색(self-ask with search)'이라고 부르며 모델이 스스로에게 이렇게 묻도록 유도합니다.
동작 방식: 복잡한 질문 수신 → 하위 질문으로 분해 → 각 하위 질문을 개별 처리 → 결과를 종합하여 최종 답변 생성
예시 ("삼성전자와 SK하이닉스의 최근 실적을 비교 분석해줘"):
- 분해: ① "삼성전자의 최근 분기 실적은?" ② "SK하이닉스의 최근 분기 실적은?" ③ "두 회사의 주요 지표를 비교하면?"
- 각 하위 질문을 개별적으로 처리 (검색, 데이터 조회 등)
- 개별 결과를 종합하여 비교 분석 보고서 생성
장점: 복잡한 질문도 체계적으로 처리 가능, 각 하위 질문을 병렬로 처리하면 속도 향상
단점: 분해 자체가 잘못되면 전체 결과가 부정확해질 수 있음
성찰형 에이전트 (Reflection Agent)
에이전트가 자신의 출력을 스스로 평가하고 개선하는 패턴입니다. 한 번에 완벽한 결과를 내기보다, 반복적으로 자기 비평과 수정을 거쳐 품질을 높입니다.
동작 방식: 초기 출력 생성 → 자체 비평(Self-Critique) → 개선된 출력 생성 → 품질 충분할 때까지 반복
예시 (코드 생성):
- 에이전트가 코드를 작성
- 작성된 코드를 스스로 리뷰: "이 코드에 에러 처리가 부족하고, 변수명이 불명확하다"
- 피드백을 반영하여 코드를 개선
- 다시 리뷰하여 품질이 충분한지 확인 → 충분하면 최종 결과 반환
장점: 단일 LLM 호출 대비 출력 품질이 크게 향상됨
단점: 반복 횟수만큼 LLM 호출 비용과 지연 시간이 증가
구현 방식: 단일 에이전트가 "생성자"와 "비평가" 역할을 번갈아 수행하거나, 별도의 비평 에이전트를 둠
심층 리서치 에이전트 (Deep Research Agent)
주어진 주제에 대해 다수의 소스를 탐색하며 깊이 있는 조사를 목표 기반으로 반복 수행하는 리서치 시스템입니다. 단순 검색을 넘어 정보를 탐색 → 읽기 → 후속 질문 생성 → 추가 탐색의 사이클을 반복하며 종합적인 리서치 보고서를 작성합니다. 심층 리서치 에이전트는 여러 패턴이 결합되어 있습니다. 연구 워크플로우를 설계하는 계획 및 실행 단계, 큰 질문을 목표 지향 검색으로 쪼개는 쿼리 분해, 새로운 발견에 따라 가설을 반복적으로 다듬는 리액트 루프 등을 함께 사용합니다.
동작 방식: 연구 질문 수신 → 초기 검색 계획 수립 → 웹/문서 탐색 → 핵심 정보 추출 → 추가 질문 도출 → 반복 탐색 → 최종 보고서 작성
예시 ("국내 반도체 산업의 2026년 전망을 분석해줘"):
- 초기 검색: 반도체 시장 규모, 주요 기업 실적, 기술 트렌드 등 탐색
- 핵심 정보 추출: 수출 통계, 투자 계획, 정부 정책 등
- 후속 질문: "AI 반도체 수요 증가가 국내 기업에 미치는 영향은?" → 추가 탐색
- 여러 소스의 정보를 종합하여 구조화된 보고서 작성
장점: 사람이 수 시간~수 일 걸리는 리서치를 수 분 내에 수행, 다양한 관점을 종합
단점: 소스의 신뢰성 검증이 필요, 최신 정보 접근에 제약이 있을 수 있음
대표 서비스: OpenAI Deep Research, Google Gemini Deep Research, Perplexity Deep Research
Reasoning Model이 에이전트 패턴에 미치는 영향
Reasoning Model은 LLM이 응답을 생성하기 전에 추가적인 계산(test-time compute)을 활용하여 문제를 단계적으로 분석하고, 보다 정확한 결과를 생성하도록 설계된 모델 계열이다.
일반적인 LLM이 비교적 직접적으로 응답을 생성하는 것과 달리, Reasoning Model은 내부적으로 다단계 추론을 수행한 뒤 최종 답변을 생성하는 특징을 가진다. 이 과정에서 추가적인 토큰 사용 또는 내부 계산이 수반될 수 있다.
추론 기능의 통합 흐름
초기에는 추론 능력을 강화한 모델이 별도의 계열로 제공되는 경우가 있었으나, 최근에는 추론 기능을 단일 모델 내에서 선택적으로 활용할 수 있도록 통합하는 방향으로 발전하고 있다. 2026년 기준, 주요 모델 제공사들은 다음과 같은 접근을 취하고 있다.
| 제공사 | 접근 방식 | 주요 모델 | 비고 |
|---|---|---|---|
| OpenAI | GPT-5 이후 추론 기능이 통합되어 제공되며, 기존 o-시리즈도 병행 운영 중 | GPT-5.x 계열 (Thinking / Pro), o-시리즈 (o3, o4-mini) | GPT-5.4는 작업 복잡도에 따라 추론 깊이를 자동 조절하는 스마트 라우터 내장. 기존 추론 전용 모델인 o-시리즈도 API·ChatGPT에서 계속 제공 중 |
| Anthropic | 별도의 추론 전용 모델 라인을 두기보다, 단일 모델 내에서 추론 기능(Extended Thinking)을 확장하는 방식 | Claude Opus 4.6, Sonnet 4.6 | 개발자가 thinking budget(추론 토큰 상한)을 설정. Interleaved Thinking으로 도구 호출 사이에도 추론 수행 |
| 추론을 설정 가능한 파라미터 형태로 제공 | Gemini 계열 (3 Pro, 3 Deep Think) | thinkingBudget 파라미터로 추론 깊이 조절 (0: 비활성, -1: 모델 자율 판단, 또는 특정 토큰 수 지정). Deep Think는 과학·공학 분야 심층 추론 특화 |
이처럼 **추론은 점점 '별도 모델'이라기보다, 모델 내부에서 필요에 따라 활성화되는 기능(capability)**으로 발전하는 추세이다. 다만, 고성능 추론이 필요한 경우에는 여전히 별도의 설정이나 리소스 사용이 요구되기도 한다.
에이전트 패턴에 미치는 영향
(1) 추론 내재화(Internalized Reasoning)
기존에는 ReAct와 같은 패턴을 통해 외부에서 추론 과정을 명시적으로 구성해야 했으나, 추론 기능이 강화된 모델은 내부적으로 다단계 추론을 수행할 수 있다. 이에 따라 일부 시나리오에서는 오케스트레이션 로직이 단순화될 수 있다. 다만, 복잡한 제어가 필요한 경우에는 여전히 외부 제어 구조가 함께 사용된다.
(2) 계획 품질 향상
Plan-and-Execute 패턴에서 계획 단계의 정확도가 향상되면서, 계획 수정(Re-planning)의 빈도가 감소하는 경향이 있다. 이는 전체 에이전트 실행 과정에서 토큰 사용량과 지연시간을 줄이는 데 기여할 수 있다.
(3) 복잡한 도구 사용 개선
여러 도구를 조합해야 하는 상황에서, 도구 선택 및 파라미터 생성의 정확도가 향상되는 경향이 있다. 그 결과, 도구 호출 실패율이 감소하고 전체 실행 안정성이 높아질 수 있다.
(4) 모델 선택의 단순화
기존에는 작업 유형에 따라 추론 모델과 일반 모델을 구분하여 사용하는 경우가 많았으나, 최근에는 단일 모델 내에서 추론 수준을 조절하는 방식이 점점 확산되고 있다. 다만, 비용과 성능 요구사항에 따라 모델을 분리하여 사용하는 전략도 여전히 함께 사용된다.
주의점
추론 기능은 추가적인 계산을 수반하므로, 일반적으로 다음과 같은 trade-off가 존재한다.
- 토큰 사용량 증가
- 응답 지연 시간 증가
따라서 단순한 작업에서는 추론 사용을 최소화하고, 복잡한 문제에 대해서만 높은 추론 수준을 적용하는 방식이 권장된다.
AI Agent 핵심 패턴 비교
| 에이전트 유형 | 강점 | 약점 | 최적 사용 사례 |
|---|---|---|---|
| 반사형 에이전트 | 밀리초 단위 응답 | 다단계 추론 불가 | 키워드 라우팅, 단순 조회 |
| 리액트 에이전트 | 유연한 적응력 | 더 높은 지연시간과 비용 | 탐색형 워크플로, 트러블 슈팅 |
| 계획 후 실행 에이전트 | 명확한 작업 분해 | 계획 수립 오버헤드 | 복잡한 다단계 프로세스 |
| 쿼리 분해 에이전트 | 근거가 명확한 검색 정확도 | 다수의 도구 호출 필요 | 리서치, 사실 기반 Q&A |
| 성찰형 에이전트 | 초기 오류 감지 | 추가 연산 및 지연시간 | 고위험, 안전이 중요한 작업 |
| 심층 리서치 에이전트 | 다단계 및 적응형 조사 관리 | 높은 연산 비용과 매우 긴 지연시간 | 장문의 문헌 리뷰 |
에이전트 설계 원칙
에이전트 시스템을 설계할 때 가장 중요한 원칙은 "가능한 한 단순한 접근부터 시작하고, 성능 개선이 필요할 때만 복잡성을 추가하라"는 것입니다. 적절한 에이전트의 개수와 구성 방식은 작업의 난이도, 도구의 개수, 환경의 복잡성에 따라 크게 달라집니다.
Workflow vs Agent: 무엇을 선택할 것인가?
Anthropic은 "Building Effective Agents"에서 에이전틱 시스템을 Workflow(워크플로우)와 Agent(에이전트) 두 가지로 구분할 것을 제안합니다.
Workflow(워크플로우)
- LLM과 도구가 사전에 정의된 코드 경로에 따라 오케스트레이션되는 시스템.
- 개발자가 실행 흐름을 결정론적으로 설계하며, LLM은 각 단계 내에서만 판단을 수행한다.
Agent(에이전트)
- LLM이 자체적으로 프로세스와 도구 사용을 동적으로 지시하며, 실행 경로를 스스로 결정하는 시스템.
- 개발자는 도구와 가이드라인만 제공하고, 실행 흐름은 LLM이 자율적으로 제어한다.
Workflow vs Agent 비교
| 구분 | Workflow (워크플로우) | Agent (에이전트) |
|---|---|---|
| 실행 흐름 | 개발자가 사전 정의 (결정론적) | LLM이 자율적으로 결정 (동적) |
| 유연성 | 낮음 (정해진 경로만 실행) | 높음 (상황에 따라 경로 변경) |
| 예측 가능성 | 높음 | 낮음 |
| 적합한 상황 | 명확하고 반복적인 작업 | 복잡하고 열린 문제 |
"가능한 경우 Workflow로 시작하고, 필요에 따라 Agent 접근을 확장하는 전략이 권장됩니다."
에이전트는 몇 개나 필요할까?
에이전트 시스템 설계 시 가장 흔한 실수는 처음부터 복잡한 멀티 에이전트 구조를 도입하는 것입니다. 단일 에이전트로 시작하여 필요할 때만 확장하는 것이 모범 사례입니다.
단일 에이전트 시나리오
단일 에이전트 시스템은 하나의 에이전트가 사용자에게 응답하기 전에, 필요할 경우 정해진 제한 횟수까지 도구를 호출하는 구조입니다. 에이전트가 작업을 수행하면서 언제 도구를 호출할지, 언제 답변을 제출할지를 스스로 결정합니다.
적합 상황:
- 난이도가 그리 높지 않은 작업
- 사용하는 도구의 수가 제한적인 경우
- 환경의 복잡성이 낮은 경우
주요 장점:
- 단순성: 구현과 관리가 쉬움
- 낮은 리소스 요구사항: 계산 오버헤드가 적음
- 빠른 응답: 에이전트 간 상호작용이 없어 지연시간이 짧음
- 빠른 검증: 핵심 기능을 빠르게 검증하고 효율적으로 개선 가능
멀티 에이전트로 확장하는 시점
다음과 같은 상황이 발생할 때 멀티 에이전트 시스템으로의 전환을 고려합니다:
| 확장 신호 | 설명 |
|---|---|
| 도구 수 증가 | 사용 가능한 도구가 20개 이상으로 늘어나 단일 에이전트가 적절한 선택을 하기 어려움 |
| 작업 복잡도 증가 | 서로 다른 전문 지식이 필요한 하위 작업이 많아짐 |
| 병렬 처리 필요 | 독립적인 작업을 동시에 처리해야 전체 처리 시간을 줄일 수 있음 |
| 역할 분리 필요 | 검증·비평·실행 등 서로 다른 역할을 분리해야 품질이 보장됨 |
핵심 원칙: 복잡성, 도구셋, 작업 조율 요구사항이 단일 에이전트가 감당할 수 있는 범위를 넘어설 때에만 멀티 에이전트 시스템으로 전환해야 합니다. 멀티 에이전트 시스템은 에이전트 간 여러 번 상호작용해야 하므로, 사용자 관점에서 지연시간이 늘어나고 비용도 증가합니다.
멀티 에이전트의 조율 (Coordination)
멀티 에이전트 시스템에서 여러 에이전트가 협력하려면, 누가 언제 무엇을 할지 조율하는 방식이 필요합니다. 조율 방식에 따라 시스템의 유연성, 효율성, 확장성이 크게 달라집니다.
쉽게 말하면, 여러 사람이 함께 일할 때 "다수결로 정할지, 팀장이 지시할지, 조직 체계를 만들지"를 정하는 것과 같습니다.
민주적 조율 (Democratic Coordination)
여러 에이전트가 동등한 입장에서 의견을 제시하고, 투표나 합의를 통해 최종 결정을 내리는 방식입니다.
- 동작 방식: 각 에이전트가 독립적으로 판단 → 결과를 공유 → 다수결 또는 합의로 최종 결정
- 예시: 코드 리뷰 시 3개의 리뷰 에이전트가 각각 평가 → 2개 이상이 "승인"하면 통과
- 장점: 단일 에이전트의 편향을 줄이고, 더 균형 잡힌 결과를 도출
- 단점: 의사결정에 시간이 걸리며, 에이전트 간 의견 충돌 시 교착 상태 가능
- 적합 상황: 정확도가 중요한 판단 작업 (분류, 평가, 검증)
관리자 중심 조율 (Manager-Directed Coordination)
하나의 **관리자 에이전트(Manager/Orchestrator)**가 전체 작업을 파악하고, 각 전문 에이전트에게 작업을 할당하고 결과를 취합하는 방식입니다.
- 동작 방식: 관리자 에이전트가 작업을 분석 → 적절한 전문 에이전트에게 위임 → 결과를 수집하여 종합
- 예시: 오케스트레이터가 고객 문의를 분석 → "기술 문의"로 판단 → 기술 지원 에이전트에게 위임
- 장점: 명확한 지휘 체계, 작업 분배가 효율적
- 단점: 관리자 에이전트가 병목이 될 수 있음, 관리자의 판단력에 전체 성능이 의존
- 적합 상황: 역할이 명확히 구분된 업무 처리 (고객 상담, 문서 처리 파이프라인)
계층형 조율 (Hierarchical Coordination)
관리자 중심 조율을 다단계로 확장한 방식입니다. 상위 관리자가 중간 관리자에게 위임하고, 중간 관리자가 다시 하위 에이전트에게 위임하는 트리 구조입니다.
- 동작 방식: 최상위 관리자 → 중간 관리자들 → 실행 에이전트들 (군대의 지휘 체계와 유사)
- 예시: 프로젝트 관리 에이전트 → 프론트엔드 팀 리더 에이전트 → 개별 코딩 에이전트들
- 장점: 대규모 시스템에서도 관리 가능, 각 계층이 관리할 범위가 제한적
- 단점: 계층이 깊어지면 지연시간 증가, 상위 계층의 오류가 하위 전체에 전파
- 적합 상황: 대규모·복합 작업 (대형 소프트웨어 개발, 기업 전사 자동화)
액터-크리틱 접근법 (Actor-Critic Approach)
**실행 에이전트(Actor)**와 **평가 에이전트(Critic)**를 분리하여, 실행 결과를 지속적으로 평가하고 개선하는 방식입니다. 강화학습의 Actor-Critic 알고리즘에서 영감을 받았습니다.
- 동작 방식: Actor가 작업 수행 → Critic이 결과를 평가 → 피드백을 Actor에게 전달 → Actor가 개선 → 반복
- 예시: 코드 생성 에이전트(Actor)가 코드 작성 → 코드 리뷰 에이전트(Critic)가 버그·품질 평가 → 피드백 반영하여 코드 개선
- 장점: 실행과 평가의 분리로 높은 품질 달성, 자기 개선 루프 형성
- 단점: 반복 횟수에 따라 비용과 시간 증가
- 적합 상황: 품질이 매우 중요한 작업 (코드 생성, 보고서 작성, 콘텐츠 제작)
멀티 에이전트 조율 방식 비교
| 조율 방식 | 구조 | 장점 | 단점 | 적합 상황 |
|---|---|---|---|---|
| 민주적 조율 | 수평적 (동등) | 편향 감소, 균형적 결과 | 의사결정 느림 | 판단·평가 작업 |
| 관리자 중심 | 중앙 집중 | 효율적 작업 분배 | 관리자 병목 | 역할 분담 명확한 업무 |
| 계층형 조율 | 트리 구조 | 대규모 확장 가능 | 지연시간 증가 | 대규모 복합 작업 |
| 액터-크리틱 | 실행+평가 분리 | 높은 품질 달성 | 반복 비용 증가 | 품질 중시 작업 |
에이전트 프레임워크
AI Agent를 효율적으로 개발하기 위한 다양한 프레임워크가 제공되고 있습니다.
코드 기반 에이전트 프레임워크
| 프레임워크 | 개발사 | 특징 | 적합 용도 | 언어 |
|---|---|---|---|---|
| LangGraph | LangChain | 그래프 기반으로 에이전트의 워크플로우를 정의, 상태 관리와 조건 분기를 유연하게 구현 가능 | 복잡한 멀티 스텝 에이전트, 조건 분기가 많은 워크플로우 | Python, JavaScript/TypeScript |
| Autogen | Microsoft | 여러 에이전트 간의 대화 기반 협업을 지원, 멀티 에이전트 시스템 구축에 특화. (AutoGen은 Microsoft Agent Framework으로 통합되었고, 유지보수 모드) | 다수의 에이전트가 토론/협업하여 문제를 해결하는 시나리오 | Python |
| CrewAI | CrewAI | 에이전트에게 역할(Role), 목표(Goal), 배경(Backstory)을 부여하여 팀처럼 협업하도록 설계 | 역할 기반 멀티 에이전트 시스템, 비즈니스 프로세스 자동화 | Python |
| OpenAI Agents SDK | OpenAI | OpenAI 모델과 통합된 에이전트 개발 SDK, 도구 사용과 핸드오프(Handoff) 기능 내장 | OpenAI 생태계 기반의 에이전트 개발 | Python |
No-code/Low-code 에이전트 플랫폼
코드 작성 없이 또는 최소한의 코드로 AI 에이전트를 구축할 수 있는 플랫폼도 등장하고 있다. 비개발자도 에이전트를 설계·배포할 수 있어, 기업 내 AI 에이전트 도입의 진입 장벽을 낮추는 역할을 한다.
| 플랫폼 | 설명 | 주요 활용 |
|---|---|---|
| Dify | 오픈소스 LLM 애플리케이션 및 에이전트를 시각적으로 구축할 수 있는 플랫폼. 드래그 앤 드롭 방식의 워크플로우 설계 지원 | 프로토타이핑, 사내 AI 애플리케이션 빠른 구축 |
| n8n | AI 기능이 통합된 범용 워크플로우 자동화 플랫폼. 400개 이상의 외부 서비스 커넥터 제공. 에이전트 전용 플랫폼은 아니지만, AI 노드를 활용한 에이전트 워크플로우 구축이 가능 | 기존 업무 시스템과 AI 에이전트 연동 |
MCP (Model Context Protocol)
MCP 개념
MCP(Model Context Protocol)는 AI Agent가 외부 도구와 데이터 소스에 일관된 인터페이스로 접근할 수 있도록 설계된 오픈 프로토콜입니다. 기존에는 API, SDK, 플러그인 등 서로 다른 방식으로 도구를 연동해야 했지만, MCP는 이를 공통 프로토콜로 추상화하여 다양한 도구와 데이터 소스를 하나의 방식으로 연결할 수 있도록 합니다. MCP는 호스트(Host), 클라이언트(Client), 서버(Server) 간의 표준 메시지 형식을 정의하여 에이전트와 외부 도구 간의 상호작용을 단순화합니다.
MCP 구조
MCP는 Host-Client-Server 구조로 동작합니다.
| 구성 요소 | 설명 | 예시 |
|---|---|---|
| MCP Host | MCP 프로토콜을 지원하는 애플리케이션으로, 내부에 하나 이상의 MCP Client를 생성하여 MCP Server에 연결 | Claude Desktop, Cursor, IDE |
| MCP Client | Host 내부에서 MCP Server와 1:1 세션을 유지하는 프로토콜 연결 모듈 | Host가 생성·관리 |
| MCP Server | 도구나 데이터 소스를 MCP 프로토콜로 제공하는 측 | GitHub, Slack, DB 접근 MCP Server |
| Transport | Client-Server 간 통신 방식 | Stdio(로컬), Streamable HTTP(원격) |
MCP Server는 Tools(실행 가능한 기능), Resources(참조 데이터), **Prompts(프롬프트 템플릿)**의 세 가지 기능을 제공합니다.
MCP 기능 (Primitives)
MCP Server는 다음 세 가지 기능(Primitive)을 제공합니다.
| 기능 | 설명 | 제어 주체 | 예시 |
|---|---|---|---|
| Tools | LLM이 실행할 수 있는 함수/액션 | 모델(Model-controlled) | DB 쿼리 실행, Slack 메시지 전송, GitHub 이슈 생성, Jira 티켓 업데이트 |
| Resources | 읽기 전용 참조 데이터 | 애플리케이션(App-controlled) | 프로젝트 파일 내용, DB 스키마, API 문서, 설정 파일, 로그 데이터 |
| Prompts | 특정 작업에 최적화된 프롬프트 템플릿 | 사용자(User-controlled) | 코드 리뷰 템플릿, SQL 생성 프롬프트, 장애 분석 템플릿, 문서 요약 프롬프트 |
다만 2026년 현재, MCP 공식 클라이언트 목록(modelcontextprotocol.io/clients) 기준으로 등록된 108개 클라이언트 전체(100%)가 Tools를 지원하는 반면, Resources(약 42%)와 Prompts(약 39%)는 절반에 못 미쳐 실질적으로 Tools 중심의 생태계가 형성되어 있습니다.
기업 활용 및 현황
MCP는 Anthropic이 2024년 11월 오픈 표준으로 공개한 이후, 1년여 만에 주요 AI 기업과 엔터프라이즈 벤더가 지원을 선언하며 AI Agent 연동의 사실상 표준(de facto standard)으로 자리잡고 있습니다. 2025년 12월에는 Linux Foundation 산하 Agentic AI Foundation(AAIF)에 이관되어 개방형 거버넌스 체계로 전환되었습니다.
주요 기업의 MCP 지원
| 시기 | 기업 | 내용 |
|---|---|---|
| 2024.11 | Anthropic | MCP 오픈 표준 공개 (Python/TypeScript SDK) |
| 2025.03 | OpenAI | Agents SDK, ChatGPT 데스크톱 앱에 MCP 지원 |
| 2025.04 | Gemini 모델 및 SDK에 MCP 지원 | |
| 2025.05 | Microsoft | GitHub Copilot Agent 모드, Copilot Studio에 MCP 통합 (Build 2025) |
| 2025.12 | Linux Foundation | MCP를 Agentic AI Foundation(AAIF)에 이관. Anthropic, OpenAI, Block이 공동 설립하고, AWS, Google, Microsoft, Bloomberg, Cloudflare 등이 Platinum 멤버로 참여 |
엔터프라이즈 영역에서도 도입이 시작되고 있습니다. Salesforce는 Agentforce에 네이티브 MCP 클라이언트를 탑재(2025.07 Pilot)하였고, Autodesk는 MCP 스펙의 엔터프라이즈 보안 강화에 직접 참여하는 등 주요 SaaS 벤더들이 자사 플랫폼에 MCP를 통합하는 움직임을 보이고 있습니다. 2025년 12월 기준 공개된 MCP Server는 10,000개 이상으로, 생태계가 빠르게 확장되고 있습니다.
엔터프라이즈 적용 시 과제
MCP는 빠르게 성장하고 있으나, 기업 환경 적용을 위해서는 다음과 같은 과제가 남아 있습니다.
- 인증·인가: 초기 스펙에는 엔터프라이즈급 인증이 부재했으나, 2025년 11월 스펙 업데이트에서 OAuth 2.1 기반 인증 체계(CIMD)가 추가됨
- 보안: 경량 MCP 구현에서 API 키가 설정 파일에 평문 저장되는 사례, 프롬프트 인젝션을 통한 토큰 탈취 위험 등이 보고됨
- 거버넌스: 감사 로그, RBAC/ABAC 기반 권한 제어, 속도 제한 등 엔터프라이즈 거버넌스 체계 구축이 필요하며, 2026년 공식 로드맵에서 Enterprise Readiness를 핵심 우선순위로 제시하고 있음
A2A 프로토콜 (Agent-to-Agent Protocol)
A2A(Agent-to-Agent Protocol)는 Google이 2025년 4월 발표한 오픈 프로토콜로, 서로 다른 프레임워크·벤더의 AI Agent들이 표준화된 방식으로 소통하고 협업할 수 있도록 설계되었습니다. MCP가 "에이전트가 도구를 쓰는 규격"이라면, A2A는 "에이전트끼리 대화하는 규격"입니다.
| 구분 | MCP | A2A |
|---|---|---|
| 목적 | 에이전트 → 도구 연결 | 에이전트 ↔ 에이전트 협업 |
| 비유 | USB-C 포트 | 외교 프로토콜 |
| 통신 대상 | 도구/데이터 소스 | 다른 AI Agent |
| 관계 | 상호 보완 | 상호 보완 |
하나의 에이전트가 내부적으로 MCP를 통해 도구를 사용하면서, 외부적으로 A2A를 통해 다른 에이전트와 협업하는 구조가 일반적입니다.
A2A의 핵심 개념
A2A는 단순 메시지 교환을 넘어, 에이전트 간 **작업 위임(Task Delegation)**과 협업을 표준화하는 데 초점을 둔다. 기본적으로 다음과 같은 구조를 따른다.
- Client Agent: 작업을 요청하는 에이전트
- Remote Agent: 작업을 수행하는 에이전트
핵심 구성요소
| 구성요소 | 설명 |
|---|---|
| Agent Card | 에이전트가 자신의 이름, 능력, 인터페이스 등을 JSON 형태로 공개하는 메타데이터. 다른 에이전트가 이를 통해 협업 가능 여부를 판단하고 대상 에이전트를 발견(Discovery) |
| Task | 에이전트 간 협업의 기본 단위. 요청 에이전트가 작업을 생성하면 수행 에이전트가 이를 처리하고 상태를 갱신하며 결과를 반환 |
| Message | Task 수행 과정에서 교환되는 데이터 단위. 텍스트, 파일, 구조화된 데이터 등 다양한 형식을 포함 가능 |
동작 방식 (요약)
- Client Agent가 Agent Card를 통해 협업 가능한 Agent를 탐색
- 적절한 Remote Agent를 선택하여 Task 생성
- Task 수행 과정에서 Message를 주고받으며 협업 진행
- Task 완료 후 결과 반환
기업에서의 AI Agent 활용
(1) 업무 자동화 에이전트
- 문서 처리 자동화: 계약서 검토, 보고서 생성, 이메일 분류 및 응답
- 데이터 처리 자동화: 정기 보고서 생성, 데이터 마이그레이션, ETL 파이프라인 관리
- 워크플로우 자동화: 승인 프로세스, 작업 할당, 일정 관리
(2) 코딩 에이전트
소프트웨어 개발 과정을 AI가 지원하는 에이전트로, SI 기업의 핵심 생산성 도구입니다.
- Cursor: AI 네이티브 IDE로, 코드 편집·생성·리팩토링을 AI가 통합 지원
- Claude Code: Anthropic의 CLI 기반 코딩 에이전트로, 파일 편집·터미널 명령·Git 작업을 자율적으로 수행
- GitHub Copilot: IDE 내에서 코드 자동 완성 및 제안, GitHub 생태계와 통합
- Windsurf: AI 네이티브 IDE로, Cascade 에이전틱 플로우를 통해 멀티 파일 편집과 명령 실행을 자율적으로 수행
- Devin (Cognition): 자율형 AI 소프트웨어 엔지니어를 표방하는 코딩 에이전트로, 코드 작성·디버깅·배포까지 전체 개발 라이프사이클을 자율적으로 수행
- Amazon Q Developer: AWS 기반 AI 코딩 어시스턴트로, AWS 서비스 연동과 코드 변환·보안 스캔 기능 제공
- Codex CLI: OpenAI의 오픈소스 CLI 기반 코딩 에이전트로, 터미널에서 자연어 명령으로 코드 생성·실행 수행. 클라우드 기반 비동기 코딩 에이전트인 Codex(구 codex-1)와는 별개의 제품
- 활용 분야: 코드 생성, 코드 리뷰, 버그 수정, 테스트 작성, 문서화, 레거시 코드 현대화
(3) 고객 상담 에이전트
- 지능형 고객 상담: FAQ 응답을 넘어 고객의 계정 조회, 주문 처리, 환불 요청 등을 자율적으로 처리
- 옴니채널 지원: 전화, 채팅, 이메일 등 다양한 채널을 통합하여 일관된 고객 경험 제공
- 에스컬레이션: 에이전트가 처리할 수 없는 복잡한 문제는 사람 상담원에게 자동 전달
(4) 데이터 분석 에이전트
- 자연어 기반 데이터 분석: "지난 분기 매출 상위 10개 제품을 보여줘"와 같은 자연어 질의를 SQL로 변환하여 실행
- 자동 보고서 생성: 데이터 분석 결과를 차트와 함께 보고서로 자동 작성
- 이상 탐지: 데이터의 이상 패턴을 자동으로 감지하고 알림
AI Agent의 한계와 고려사항
AI Agent는 강력한 가능성을 가지고 있지만, 실제 도입 시 다음과 같은 한계와 고려사항이 있습니다.
(1) 신뢰성과 예측 가능성
에이전트의 자율적 특성상 오류가 복합적으로 누적(Compounding Errors)될 수 있으며, Deloitte는 "현재의 에이전트는 사람의 감독 없이 업무를 전적으로 맡기기에는 너무 많은 오류를 발생시킨다"고 지적합니다.
- 권장 대응: 중요한 행동(외부 API 호출, 데이터 삭제 등)에 대해 사람의 승인을 요구하는 "Human-in-the-Loop" 체크포인트를 설계하고, 실행 단계마다 중간 결과를 검증하여 오류 누적을 조기 차단한다.
(2) 보안 위험
에이전트가 외부 도구에 접근할 수 있으므로, 과도한 권한 부여 시 보안 사고 발생 가능. OWASP는 에이전트 목표 탈취(Goal Hijack), 도구 오남용(Tool Misuse), 권한 남용(Privilege Abuse), 에이전트 간 통신 위조 등을 주요 위험으로 선정하였습니다.
- 권장 대응: 최소 권한 원칙(Principle of Least Privilege)을 적용하여 각 에이전트에 필요한 도구·데이터만 허용하고, 도구 호출 시 입력값 검증(Input Validation)과 접근 범위 제한(Scope Restriction)을 설정한다.
(3) 비용 관리
에이전트는 작업 성능을 높이기 위해 지연시간과 비용을 교환(Trade-off)하는 구조이므로, 여러 단계의 LLM 호출과 도구 사용이 반복되면 토큰 사용량과 API 비용이 급증할 수 있습니다.
- 권장 대응: 최대 실행 단계 수(Max Steps)와 토큰 사용량 상한을 사전에 설정하고, 실시간 비용 모니터링 대시보드를 통해 예산 초과를 방지하며, 불필요한 LLM 호출을 줄이는 효율적인 프롬프트를 설계한다.
(4) 디버깅과 모니터링
에이전트의 자율적 행동 과정을 추적하고 디버깅하는 것이 복잡합니다. Anthropic은 프레임워크의 추가 추상화 계층이 내부 프롬프트와 응답을 가려 디버깅을 어렵게 만들 수 있다고 지적합니다.
- 권장 대응: 각 단계의 입력·출력·도구 호출을 상세히 기록하는 실행 트레이스(Execution Trace)를 남기고, LangSmith·Arize 등 관찰 가능성(Observability) 도구를 도입하며, 프로덕션 배포 전 샌드박스 환경에서 충분히 테스트한다.
(5) 환각(Hallucination) 전파
멀티 에이전트 시스템에서는 한 에이전트의 환각이 다른 에이전트로 전파되어, 잘못된 단계를 밟고 부정확한 답변을 생성하도록 유도할 수 있습니다.
- 권장 대응: 각 에이전트의 출력을 다음 단계로 전달하기 전 사실 여부를 검증하는 가드레일(Guardrail)을 구현하고, 검증 실패 시 재생성 또는 에스컬레이션하는 방어 로직을 설계한다.
한눈에 정리하는 이번 챕터
AI Agent는 자율적으로 환경을 인식·판단하고 도구를 활용해 다단계 작업을 수행하는 AI 시스템으로, 오케스트레이션·모델·도구·메모리·지식베이스의 5대 구성 요소로 이루어진다. 도구 사용의 핵심 메커니즘은 Function Calling이며, LLM이 도구의 설명(Description)을 참고해 적합한 함수를 선택·호출한다.
Agentic AI는 개별 에이전트를 넘어 AI가 자율적으로 목표를 설정·계획·실행하는 패러다임 전체를 의미하며, 지식베이스 활용에서도 에이전트가 질의를 재구성하고 반복 검색하는 등 자율적인 RAG 활용 방식이 확산되고 있다.
핵심 패턴으로는 반사형·ReAct·Plan-and-Execute·쿼리 분해·성찰형·심층 리서치의 6가지가 있으며, Reasoning Model의 등장으로 오케스트레이션 계층이 단순해지는 방향으로 진화하고 있다.
MCP(에이전트→도구 연결)와 A2A(에이전트↔에이전트 협업)는 상호 보완적인 오픈 프로토콜이다.
기업에서는 코딩 에이전트, 업무 자동화, 고객 상담, 데이터 분석 등에 활용하며, LangGraph·OpenAI Agents SDK 등 프레임워크와 Dify·n8n AI 같은 No-code 플랫폼으로 구축할 수 있다.
다만 신뢰성, 보안, 비용, 환각 전파 등의 한계가 있으며, Human-in-the-Loop, 최소 권한 원칙, 가드레일 등으로 대응한다. (상세는 Ch.5 AI Agent 품질 및 보안 참조)
참고자료 (References)
- Anthropic, "Building Effective Agents"
- Gartner, "Top Strategic Technology Trends 2025: Agentic AI"
- McKinsey, "Why agents are the next frontier of generative AI"
- Google Cloud, "What is agentic AI?"
- IBM, "What are AI Agents?"
- Salesforce, "The Agentic Maturity Model"
- LangChain, "Memory in LangGraph"
- LlamaIndex, "Building Agentic RAG"
- OpenAI, "Introducing deep research"
- Google, "Deep Research in Gemini"
- OpenAI, "Learning to Reason with LLMs"
- Anthropic, "Extended Thinking"
- OpenAI, "A Practical Guide to Building Agents"
- Microsoft AutoGen
- Google Developers Blog, "A2A: A new era of agent interoperability"
- A2A Specification
- OWASP, "Top 10 for Agentic Applications 2026"
- Deloitte, "Autonomous Generative AI Agents Still Under Development"