Chapter 4. AI Agent & Agentic AI
2026년 하반기 업데이트 안내 · 2026-10-12 기준
이 글은 2026년 상반기에 작성한 원문을 그대로 두고, 바뀐 내용을 각 섹션 아래 '2026년 하반기 업데이트' 박스로 덧붙였습니다. 핵심 변화:
- 원문 표의 추론 모델 상당수가 세대교체되었습니다. OpenAI는 GPT-6 계열이 현행이고 o1·o4-mini는 2026-10-23, o3 스냅샷은 2026-12-11 API 종료 예정이며, Anthropic은 수동 Extended Thinking(
budget_tokens)을 adaptive thinking + effort 방식으로 대체했습니다. - OpenAI Assistants API가 2026-08-26에 종료되었고(대체: Responses API + Conversations API), 노코드 Agent Builder도 2026-11-30 종료 예정입니다.
- MCP 스펙의 현행 버전이 2026-07-28로 바뀌면서
initialize핸드셰이크와 프로토콜 세션이 없는 무상태(stateless) 구조가 되었고, Roots·Sampling·Logging은 Deprecated 되었습니다. - A2A는 v1.0(첫 안정 스펙)이 나왔고, 2026-08-17 MCP와 같은 Agentic AI Foundation(AAIF) 산하로 옮겨졌습니다.
- 프레임워크·코딩 에이전트 이름이 여럿 바뀌었습니다. Microsoft Agent Framework 1.0 GA(AutoGen은 유지보수 모드), Windsurf는 Devin Desktop으로 개명, Amazon Q Developer IDE 플러그인은 Kiro로 이전(2027-04-30 지원 종료), GitHub Copilot의 원격 에이전트는 'Copilot cloud agent'로 불립니다.
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을 지원한다.
2026년 하반기 업데이트 · 2026-10-12 기준
상반기 원문 이후 달라진 점 — Function Calling 원리는 그대로지만, 이를 감싸는 API 표면이 바뀌어 OpenAI Assistants API 기반 실습은 더 이상 동작하지 않습니다.
- 확인된 사실: OpenAI Assistants API는 2025-08-26에 지원 중단이 공지되었고 2026-08-26에 종료되었습니다. 공식 대체 경로는 Responses API와 Conversations API입니다. (OpenAI Deprecations, 2026-10-12 확인)
- 확인된 사실: Anthropic은 Client SDK에서 도구 호출 루프를 직접 짜는 방식 외에, 루프를 대신 돌려 주는 베타 기능 tool runner와 Claude Code의 에이전트 루프를 라이브러리로 쓰는 Claude Agent SDK를 함께 안내하고 있습니다. (Claude Agent SDK overview, 2026-10-12 확인)
- 확인된 사실: MCP 현행 스펙(2026-07-28)은 도구의
inputSchema·outputSchema에 JSON Schema 2020-12 키워드를 모두 허용하도록 완화했습니다. 즉 'JSON Schema로 도구를 정의한다'는 원문 설명은 MCP 쪽에서도 그대로 유효합니다. (MCP 2026-07-28 Key Changes, 2026-10-12 확인) - 해석·전망: 벤더들이 '도구 정의 → 모델이 호출 생성 → 런타임 실행 → 결과 반환'이라는 저수준 루프를 SDK·관리형 런타임 안으로 숨기는 방향이라, 입문 교육에서는 원리를 한 번 손으로 구현해 보고 실무에서는 SDK 루프를 쓰는 2단계 구성이 적절해 보입니다.
교육·실습 관점: Assistants API(threads·runs)로 작성된 Function Calling 실습 코드는 종료된 API이므로 Responses API의 tools 파라미터 기반 예제로 다시 써야 합니다. 강의 자료에 Assistants API 화면이나 코드 캡처가 있다면 '종료된 API'임을 명시하거나 교체하는 것을 권장합니다.
메모리 (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
2026년 하반기 업데이트 · 2026-10-12 기준
상반기 원문 이후 달라진 점 — 심층 리서치가 '채팅 앱 기능'에서 '개발자가 API로 호출하는 에이전트'로 넘어가는 중이며, OpenAI의 전용 deep research 모델은 API에서 종료되었습니다.
- 확인된 사실: OpenAI API의
o3-deep-research·o4-mini-deep-research모델은 2026-04-22에 지원 중단이 공지되었고 2026-07-23에 종료되었습니다. 공식 대체 모델로는 GPT-5.6 계열(gpt-5.6-sol)이 안내되어 있습니다. (OpenAI Deprecations, 2026-10-12 확인) - 확인된 사실: Google은 Gemini 모델과 에이전트를 함께 다루는 Interactions API를 정식 출시(GA)하고 이를 '주력 인터페이스'로 소개했습니다. Deep Research 에이전트의 속도형·깊이형 두 버전, 원격 Linux 샌드박스를 띄우는 Managed Agents,
background=True비동기 실행이 함께 언급됩니다. (Google Blog, Interactions API GA, 2026-10-12 확인) - 해석·전망: 심층 리서치는 실행 시간이 수 분 이상 걸리므로, 백그라운드 실행 + 폴링 같은 비동기 API 설계가 사실상 기본이 되어 가는 흐름으로 보입니다.
- 확인하지 못한 것: Perplexity의 현재 제품명·요금, ChatGPT 앱 내 deep research 기능의 현재 이름과 사용 한도는 공식 문서로 확인하지 못했습니다.
교육·실습 관점: o3-deep-research 모델 ID를 호출하는 실습은 이제 오류가 납니다. 실습은 (1) 앱에서 결과물 비교하기, (2) Interactions API 같은 현행 API로 비동기 리서치 작업 생성·조회하기, (3) LangGraph 등으로 '검색 → 읽기 → 후속 질문' 루프를 직접 구현하기 중에서 고르는 편이 안전합니다.
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)**으로 발전하는 추세이다. 다만, 고성능 추론이 필요한 경우에는 여전히 별도의 설정이나 리소스 사용이 요구되기도 한다.
2026년 하반기 업데이트 · 2026-10-12 기준
상반기 원문 이후 달라진 점 — 위 표의 세 회사 모두 모델이 세대교체되었고, '추론 토큰 예산을 개발자가 숫자로 지정'하던 방식이 '노력 수준(effort/level)을 고르는' 방식으로 정리되었습니다.
- 확인된 사실(OpenAI): 현재 공식 모델 페이지의 대표 모델은 GPT-6 Astra, GPT-6.1 Sol, GPT-6 Luna이며 o-시리즈는 목록에 없습니다. 추론 강도는 low~max 수준으로 조절합니다. (OpenAI Models, 2026-10-12 확인)
- 확인된 사실(OpenAI): 원문이 '계속 제공 중'이라 쓴 o-시리즈는 단계적으로 종료됩니다.
o1·o4-mini는 2026-10-23,o3-2025-04-16·o3-pro-2025-06-10스냅샷은 2026-12-11에 API에서 종료 예정이고, 대체 모델은 GPT-5.6 계열로 안내됩니다. (OpenAI Deprecations, 2026-10-12 확인) - 확인된 사실(Anthropic): 현행 라인업은 Claude Fable 5.1, Opus 5.5, Sonnet 5.5, Haiku 5.5이고, Opus 4.6·Sonnet 4.6은 '레거시(아직 사용 가능)'로 분류됩니다. 원문의 'thinking budget' 방식(
thinking.type: "enabled"+budget_tokens)은 Opus 4.6·Sonnet 4.6에서 deprecated, 이후 모델에서는 받지 않으며, 모델이 생각할 양을 스스로 정하는 adaptive thinking을effort파라미터로 조절합니다. (Claude Models overview, 2026-10-12 확인) - 확인된 사실(Google): Gemini API 문서는 현행 Gemini 모델(3.x Flash·3.1 Pro 등)의 추론 깊이를
thinking_level(모델별로 minimal/low/medium/high 중 일부)로 조절한다고 안내합니다. (Gemini API Thinking, 2026-10-12 확인) 원문의thinkingBudget(0/-1/토큰 수)은 Gemini 2.5 이전 세대 방식이며, Gemini 3 모델에thinking_level과thinking_budget을 함께 넣으면 오류가 난다는 설명은 Vertex AI Thinking 문서에서 봤습니다(검색 결과로만 확인). - 해석·전망: 원문의 큰 흐름('추론은 별도 모델이 아니라 모델 내부 기능')은 오히려 더 강해졌습니다. 세 회사 모두 '얼마나 생각할지'를 토큰 수가 아니라 단계형 수준값으로 노출하는 쪽으로 수렴했습니다.
- 확인하지 못한 것: 원문의 'GPT-5.4 스마트 라우터 내장' 설명과 Gemini 3 Deep Think의 현재 제공 상태는 공식 문서에서 확인하지 못했습니다.
교육·실습 관점: 표를 그대로 가르치기보다 '모델명은 반년 단위로 바뀐다'는 점을 먼저 짚고, 실습 코드에서는 budget_tokens·thinkingBudget 대신 effort·thinking_level·reasoning.effort 같은 현행 파라미터를 쓰도록 바꾸는 것이 좋습니다. 모델 ID를 코드에 고정할 경우 각 사의 deprecation 페이지를 실습 전에 확인하는 습관을 함께 가르치길 권합니다.
에이전트 패턴에 미치는 영향
(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 |
2026년 하반기 업데이트 · 2026-10-12 기준
상반기 원문 이후 달라진 점 — Microsoft 쪽은 AutoGen에서 Agent Framework 1.0으로 완전히 넘어갔고, 표에 없던 Google ADK·Claude Agent SDK가 주요 선택지로 자리 잡았으며, OpenAI Agents SDK는 Python 전용이 아닙니다.
- 확인된 사실: AutoGen 저장소 README는 'AutoGen은 유지보수 모드이며 새 기능을 받지 않고 커뮤니티가 관리한다'고 밝히고, 신규 사용자에게 Microsoft Agent Framework(MAF)로 시작하라고 권합니다. (microsoft/autogen GitHub, 2026-10-12 확인)
- 확인된 사실: Microsoft Agent Framework는 2026-02 Release Candidate를 거쳐 2026-04-03에 .NET·Python 1.0(안정 API)으로 출시되었고, Semantic Kernel의 엔터프라이즈 기능과 AutoGen의 멀티 에이전트 오케스트레이션을 합친 후속작이며 A2A·MCP를 지원합니다. (Microsoft Agent Framework 1.0 블로그, 검색 결과로만 확인)
- 확인된 사실: OpenAI Agents SDK는 Python 외에 TypeScript/JavaScript 판(
@openai/agents)이 있으며, 핵심 개념(Agents·Handoffs·Guardrails)에 더해 Sessions, Tracing, MCP 연동, 격리된 작업 공간에서 도는 Sandbox Agents를 제공합니다. (OpenAI Agents SDK 문서, openai-agents-js GitHub, 2026-10-12 확인) - 확인된 사실: Google ADK(Agent Development Kit)는 Python·TypeScript·Go·Java·Kotlin을 지원하고, 문서 사이트가 adk.dev로 옮겨졌으며, 'ADK TypeScript 2.0 GA(그래프 워크플로 지원)'를 공지하고 있습니다. A2A 노출·호출 퀵스타트도 제공합니다. (ADK 공식 문서, 2026-10-12 확인)
- 확인된 사실: Claude Agent SDK(구 Claude Code SDK)는 Claude Code의 도구·에이전트 루프·컨텍스트 관리를 Python·TypeScript 라이브러리로 제공하며, Anthropic이 에이전트를 호스팅하는 Managed Agents와 구분됩니다. (Claude Agent SDK overview, 2026-10-12 확인)
- 확인된 사실: LangChain·LangGraph는 2025-10에 1.0에 도달해 2.0 전까지 호환성 깨짐 없는 안정성을 약속했고, 문서는 docs.langchain.com으로 통합되었습니다. (LangChain 블로그, 검색 결과로만 확인)
- 해석·전망: 주요 프레임워크가 '그래프 기반 워크플로 + 자율 에이전트 혼합', 'MCP·A2A 기본 지원'으로 비슷해지고 있어, 프레임워크 선택은 기능 차이보다 주력 모델 벤더·언어·배포 환경에 따라 갈리는 경향이 커 보입니다.
- 확인하지 못한 것: CrewAI의 현재 버전과 이번 하반기 변경 사항은 공식 출처로 확인하지 못했습니다.
교육·실습 관점: AutoGen 실습은 신규 과정에서는 MAF로 교체하는 것을 권장합니다(MAF 공식 마이그레이션 가이드 활용). 표를 갱신해 쓴다면 Google ADK와 Claude Agent SDK 행을 추가하고, OpenAI Agents SDK의 언어 칸에 TypeScript를 넣는 것이 정확합니다.
No-code/Low-code 에이전트 플랫폼
코드 작성 없이 또는 최소한의 코드로 AI 에이전트를 구축할 수 있는 플랫폼도 등장하고 있다. 비개발자도 에이전트를 설계·배포할 수 있어, 기업 내 AI 에이전트 도입의 진입 장벽을 낮추는 역할을 한다.
| 플랫폼 | 설명 | 주요 활용 |
|---|---|---|
| Dify | 오픈소스 LLM 애플리케이션 및 에이전트를 시각적으로 구축할 수 있는 플랫폼. 드래그 앤 드롭 방식의 워크플로우 설계 지원 | 프로토타이핑, 사내 AI 애플리케이션 빠른 구축 |
| n8n | AI 기능이 통합된 범용 워크플로우 자동화 플랫폼. 400개 이상의 외부 서비스 커넥터 제공. 에이전트 전용 플랫폼은 아니지만, AI 노드를 활용한 에이전트 워크플로우 구축이 가능 | 기존 업무 시스템과 AI 에이전트 연동 |
2026년 하반기 업데이트 · 2026-10-12 기준
상반기 원문 이후 달라진 점 — 노코드 영역에서는 벤더 종속 빌더가 정리되는 사례가 나왔고, 오픈소스 빌더는 MCP 양방향 지원으로 '에이전트 런타임'에 가까워지고 있습니다.
- 확인된 사실: OpenAI의 시각적 에이전트 빌더인 Agent Builder는 2026-06-03에 지원 중단이 공지되었고 2026-11-30에 종료 예정입니다. 공식 안내는 Agents SDK(코드) 또는 ChatGPT Workspace Agents로 옮기라는 것입니다. 같은 날
v1/prompts(재사용 프롬프트)와 Evals 플랫폼 종료도 함께 공지되었습니다. (OpenAI Deprecations, 2026-10-12 확인) - 확인된 사실: Dify는 v1.6.0에서 MCP를 양방향으로 지원한다고 발표했습니다. Dify 앱이 외부 MCP 서버를 쓰는 클라이언트도 되고, Dify 워크플로를 MCP 서버로 노출할 수도 있습니다. (Dify 블로그, v1.6.0, 검색 결과로만 확인)
- 해석·전망: 특정 모델 벤더가 운영하는 노코드 빌더는 그 회사의 제품 전략에 따라 언제든 접힐 수 있다는 사례가 생겼습니다. 사내 표준 도구를 고를 때 '내보내기(코드·워크플로 정의 이식성)'를 평가 항목에 넣을 필요가 있어 보입니다.
- 확인하지 못한 것: n8n의 현재 커넥터 수(원문 '400개 이상')와 n8n 2.0의 정확한 출시 시점·AI 노드 수는 공식 출처로 확인하지 못했습니다. Microsoft Copilot Studio 등 다른 노코드 플랫폼의 하반기 변경도 이번에는 확인하지 않았습니다.
교육·실습 관점: OpenAI Agent Builder로 만든 실습은 2026-11-30 이후 쓸 수 없으므로, 노코드 실습은 Dify·n8n처럼 자체 호스팅이 가능한 도구로 진행하고, 같은 시나리오를 Agents SDK 코드로 옮겨 보는 '노코드 → 코드' 전환 실습을 붙이면 교육 효과가 좋습니다.
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(프롬프트 템플릿)**의 세 가지 기능을 제공합니다.
2026년 하반기 업데이트 · 2026-10-12 기준
상반기 원문 이후 달라진 점 — MCP 현행 스펙이 2025-11-25에서 2026-07-28로 바뀌며 '연결을 맺고 세션을 유지하는' 구조에서 '요청마다 독립적인' 무상태 구조로 크게 재설계되었습니다.
- 확인된 사실: 현행(Current) 프로토콜 버전은 2026-07-28입니다. (MCP Versioning, 2026-10-12 확인)
- 확인된 사실: 2026-07-28 개정에서
initialize/notifications/initialized핸드셰이크가 제거되어, 모든 요청이_meta에 프로토콜 버전과 클라이언트 capability를 직접 싣습니다. 서버는 지원 버전·기능·정체를 알려 주는server/discoverRPC를 반드시 구현해야 합니다. (MCP 2026-07-28 Key Changes, 2026-10-12 확인) - 확인된 사실: Streamable HTTP에서 프로토콜 수준 세션과
Mcp-Session-Id헤더가 없어졌습니다. 호출 간 상태가 필요하면 서버가 발급한 핸들을 일반 도구 인자로 주고받습니다. SSE 스트림 재개(Last-Event-ID)도 제거되어 끊긴 요청은 새 요청으로 다시 보내야 합니다. 서버가 클라이언트에 되묻던 방식(sampling·elicitation 등)은 Multi Round-Trip Requests(MRTR) 패턴으로 대체되었고, 실험 기능이던 tasks는 공식 확장(extension)으로 분리되었습니다. (같은 출처, 2026-10-12 확인) - 확인된 사실: 원문 표의 Transport 구분(Stdio 로컬, Streamable HTTP 원격)은 여전히 유효합니다. 구형 HTTP+SSE 전송 방식은 Deprecated 상태로 재분류되었습니다. (MCP Deprecated Features, 2026-10-12 확인)
- 해석·전망: 무상태화는 MCP 서버를 일반 웹 API처럼 로드밸런서 뒤에 수평 확장하기 쉽게 만드는 변화로 보입니다. 다만 SDK·클라이언트가 새 버전을 따라오는 데 시간이 걸려, 당분간은 구 버전(핸드셰이크 방식)과 신 버전이 섞여 운영될 가능성이 높습니다.
교육·실습 관점: 2025년 기준 튜토리얼처럼 'initialize 후 세션 ID를 받아 요청한다'는 흐름을 그대로 가르치면 현행 스펙과 어긋납니다. 원리 설명은 Host-Client-Server와 Tools 중심으로 유지하고, 실습은 SDK 최신 버전을 쓰되 서버·클라이언트가 어느 프로토콜 버전을 협상했는지 로그로 확인하는 단계를 넣는 것을 권장합니다.
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 중심의 생태계가 형성되어 있습니다.
2026년 하반기 업데이트 · 2026-10-12 기준
상반기 원문 이후 달라진 점 — 세 가지 서버 Primitive(Tools·Resources·Prompts)는 그대로지만, 클라이언트 쪽 기능 일부가 공식적으로 퇴출 절차에 들어갔고 원문이 인용한 클라이언트 목록 페이지는 사라졌습니다.
- 확인된 사실: 2026-07-28 스펙에서 클라이언트 기능인 Roots·Sampling과 서버 유틸리티 Logging이 Deprecated 되었습니다. 대안은 각각 '도구 인자·리소스 URI·서버 설정으로 경로 전달', 'LLM 제공사 API 직접 연동', 'stdio는
stderr, 그 외는 OpenTelemetry'입니다. 가장 이른 제거 시점은 2027-07-28 이후 첫 개정입니다. (MCP Deprecated Features, 2026-10-12 확인) - 확인된 사실: 같은 개정에서 12개월 이상의 유예 기간을 두는 기능 수명주기·폐기 정책이 도입되었고, 목록 응답(
tools/list등)에 캐시용ttlMs·cacheScope필드가 필수가 되었습니다. (MCP 2026-07-28 Key Changes, 2026-10-12 확인) - 확인된 사실: 원문이 인용한
modelcontextprotocol.io/clients주소는 2026-10-12 현재 소개 페이지(/docs/2026-07-28/getting-started/intro)로 308 리다이렉트되어, 108개 클라이언트·지원 비율 표를 더 이상 그 주소에서 확인할 수 없습니다. (직접 접속 확인, 2026-10-12) - 해석·전망: 'Tools 중심 생태계'라는 원문 관찰은 스펙 방향과도 맞아떨어집니다. 스펙이 클라이언트에 많은 기능을 요구하던 부분을 줄이고 Tools·Resources·Prompts 같은 서버 측 핵심으로 좁히는 흐름으로 읽힙니다.
- 확인하지 못한 것: 현재 시점의 클라이언트 수와 Resources·Prompts 지원 비율은 공식 집계를 찾지 못했습니다. 원문의 108개·42%·39% 수치는 상반기 기준 값으로만 읽어 주십시오.
교육·실습 관점: Sampling(서버가 클라이언트 LLM을 빌려 쓰기)이나 Roots를 예제로 쓰는 실습은 신규 구현에서 권장되지 않으므로, Tools 위주로 실습하고 Resources·Prompts는 개념 소개 수준으로 다루는 것이 현실적입니다.
기업 활용 및 현황
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개 이상으로, 생태계가 빠르게 확장되고 있습니다.
2026년 하반기 업데이트 · 2026-10-12 기준
상반기 원문 이후 달라진 점 — AAIF가 MCP만의 재단에서 에이전트 표준 전반(A2A 포함)을 품는 재단으로 커졌고, 기업 도입 수치는 출처마다 크게 엇갈립니다.
- 확인된 사실: AAIF가 현재 호스팅하는 프로젝트는 MCP, goose, AGENTS.md, agentgateway, Agent2Agent(A2A), Agent Router입니다. 출범 당시 3개(MCP·goose·AGENTS.md)에서 늘었습니다. (AAIF Projects, 2026-10-12 확인)
- 확인된 사실: A2A는 2026-08-17 AAIF의 호스팅 프로젝트가 되었습니다(아래 A2A 섹션 업데이트 참고). (Techzine, 2026-10-12 확인)
- 확인된 사실: 공식 MCP Registry(
registry.modelcontextprotocol.io)는 2025-09-08 프리뷰로 공개되었고 현재 운영 중입니다. (MCP 블로그, Registry preview, 검색 결과로만 확인 / 레지스트리 사이트 접속은 직접 확인) - 확인하지 못한 것: AAIF 회원 수(2026-08 기준 242개라는 회원사 보도자료, 250개 이상이라는 언론 보도 등)는 AAIF 공식 페이지에서 직접 확인하지 못했습니다(검색 결과로만 확인). MCP Registry의 정식 GA 여부와 등록 서버 수(약 2,000개 ~ 약 17,000개로 출처마다 다름)도 공식 집계로 확인하지 못했습니다. Salesforce Agentforce의 MCP 클라이언트는 2026-06 기준 여전히 Beta라는 제3자 보도가 있으나 Salesforce 공식 문서로는 확인하지 못했습니다.
- 해석·전망: 'MCP 서버 N개'라는 숫자는 집계 기준(공식 레지스트리 등록 vs 커뮤니티 목록 vs GitHub 저장소)에 따라 몇 배씩 차이 나므로, 도입 근거로 쓸 때는 출처와 기준을 함께 적는 것이 안전합니다.
교육·실습 관점: 사내 도입 실습에서는 아무 GitHub 저장소의 MCP 서버를 바로 쓰기보다, 공식 레지스트리처럼 네임스페이스 소유 검증을 거친 출처를 우선 쓰고 사내 허용 목록(allowlist)을 운영하는 절차를 함께 가르치길 권합니다.
엔터프라이즈 적용 시 과제
MCP는 빠르게 성장하고 있으나, 기업 환경 적용을 위해서는 다음과 같은 과제가 남아 있습니다.
- 인증·인가: 초기 스펙에는 엔터프라이즈급 인증이 부재했으나, 2025년 11월 스펙 업데이트에서 OAuth 2.1 기반 인증 체계(CIMD)가 추가됨
- 보안: 경량 MCP 구현에서 API 키가 설정 파일에 평문 저장되는 사례, 프롬프트 인젝션을 통한 토큰 탈취 위험 등이 보고됨
- 거버넌스: 감사 로그, RBAC/ABAC 기반 권한 제어, 속도 제한 등 엔터프라이즈 거버넌스 체계 구축이 필요하며, 2026년 공식 로드맵에서 Enterprise Readiness를 핵심 우선순위로 제시하고 있음
2026년 하반기 업데이트 · 2026-10-12 기준
상반기 원문 이후 달라진 점 — 인증 쪽에서는 CIMD(Client ID Metadata Documents)가 기본 등록 방식으로 굳어지고, 관측성은 OpenTelemetry로 표준화되는 방향이 스펙에 반영되었습니다.
- 확인된 사실: 2026-07-28 스펙은 OAuth 2.0 Dynamic Client Registration(RFC 7591)을 클라이언트 등록 방식으로서 Deprecated 하고 CIMD를 우선 방식으로 지정했습니다. 또한 클라이언트 자격 증명을 발급한 인가 서버(issuer)에 묶어 다른 인가 서버에 재사용하지 못하게 했고, 인가 응답의
iss값 검증(RFC 9207)을 요구합니다. (MCP 2026-07-28 Key Changes, 2026-10-12 확인) - 확인된 사실: 같은 개정에서
_meta를 통한 OpenTelemetry 트레이스 컨텍스트(traceparent등) 전파 규약이 문서화되었고, Logging 기능 대신 OpenTelemetry 사용이 권장됩니다. 즉 원문이 말한 '감사 로그' 요구를 프로토콜 차원에서 분산 트레이싱으로 연결할 수 있게 되었습니다. (같은 출처, 2026-10-12 확인) - 해석·전망: 원문의 세 과제 중 '인증·인가'는 스펙상 상당 부분 정리되었고, 남은 과제는 '보안(도구 설명·결과를 통한 프롬프트 인젝션)'과 '거버넌스(누가 어떤 서버를 허용하는가)'처럼 스펙 밖 운영 영역으로 무게가 옮겨 가는 것으로 보입니다.
- 확인하지 못한 것: 원문이 언급한 '2026년 공식 로드맵'의 현재 우선순위가 바뀌었는지는 확인하지 못했습니다.
교육·실습 관점: 원격 MCP 서버 인증 실습을 Dynamic Client Registration 기준으로 만들었다면 CIMD 흐름으로 바꾸는 것을 권장합니다. 감사 로그 실습은 MCP Logging 대신 OpenTelemetry 트레이스를 수집해 도구 호출 단위로 추적하는 방식으로 구성하면 현행 스펙과 맞습니다.
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를 통해 다른 에이전트와 협업하는 구조가 일반적입니다.
2026년 하반기 업데이트 · 2026-10-12 기준
상반기 원문 이후 달라진 점 — A2A는 첫 안정 버전 v1.0을 냈고, Google 주도 프로젝트에서 MCP와 같은 중립 재단(AAIF) 소속으로 옮겨졌습니다.
- 확인된 사실: A2A 공식 스펙 사이트의 최신 릴리스는 1.0.0이며, 이전 버전으로 0.3.0·0.2.6·0.1.0이 남아 있습니다. (A2A Specification, 2026-10-12 확인)
- 확인된 사실: Linux Foundation은 2026-04-09 발표에서 A2A v1.0의 주요 내용으로 다중 프로토콜 지원, 엔터프라이즈 멀티테넌시, 서명된 Agent Card(암호학적 신원 검증), 초기 도입자용 마이그레이션 경로를 들었고, 150개 이상 조직 참여, 5개 SDK(Python·JavaScript·Java·Go·.NET), Azure AI Foundry·Copilot Studio·Amazon Bedrock AgentCore Runtime 등 주요 클라우드 지원을 밝혔습니다. (Linux Foundation 보도자료, 2026-10-12 확인)
- 확인된 사실: A2A는 2025-06 Linux Foundation으로 이관된 데 이어, 2026-08-17 Agentic AI Foundation(AAIF)의 호스팅 프로젝트가 되었습니다. 이로써 MCP와 A2A가 같은 재단 아래에 있게 되었습니다. (Techzine, AAIF Projects, 2026-10-12 확인)
- 해석·전망: 두 프로토콜이 한 재단에 모이면서 원문의 'MCP는 도구, A2A는 에이전트 간'이라는 역할 분담 구도는 더 공식화될 가능성이 큽니다. 다만 MCP 쪽에도 장시간 작업용 tasks 확장이 생기는 등 경계가 일부 겹치는 부분은 계속 지켜볼 필요가 있습니다.
교육·실습 관점: 0.x 시절 예제 코드는 v1.0과 필드·메서드가 다를 수 있으므로, 실습은 v1.0을 지원하는 공식 SDK 버전으로 진행하고 교재에 '기준 스펙 버전: 1.0.0'을 명시하는 것을 권장합니다.
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 완료 후 결과 반환
2026년 하반기 업데이트 · 2026-10-12 기준
상반기 원문 이후 달라진 점 — v1.0 스펙 기준으로 핵심 데이터 모델에 Part·Artifact가 명시되어 있고, 전송 방식이 세 가지 바인딩으로 정리되어 있습니다.
- 확인된 사실: v1.0 스펙의 표준 데이터 모델은 Task, Message, Part(텍스트·파일·구조화 데이터를 담는 단위), Artifact(작업 결과물), Agent Card로 구성됩니다. 원문의 3요소(Agent Card·Task·Message)에 Part·Artifact가 더해진 형태로 이해하면 됩니다. (A2A Specification, 2026-10-12 확인)
- 확인된 사실: 프로토콜 바인딩은 JSON-RPC 2.0, gRPC, HTTP+JSON(REST) 세 가지이며, 모두 같은 추상 연산에 대응됩니다. (같은 출처, 2026-10-12 확인)
- 확인된 사실: v1.0에서는 Agent Card에 서명을 붙여 신원을 검증할 수 있습니다. 원문 1단계 '탐색'에 '신원 검증'이 추가된 셈입니다. (Linux Foundation 보도자료, 2026-10-12 확인)
- 확인하지 못한 것: Agent Card를 게시하는 well-known 경로 등 세부 탐색 규칙은 이번에 스펙 본문에서 확인하지 못했습니다.
교육·실습 관점: 동작 방식 설명에 'Task 결과는 Artifact로, 내용물은 Part로 담긴다'는 한 줄을 보태면 SDK 코드를 읽을 때 혼란이 줄어듭니다. 원격 에이전트를 호출하는 실습에서는 서명된 Agent Card를 검증하는 단계를 보안 체크포인트로 함께 보여 주길 권합니다.
기업에서의 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)와는 별개의 제품
- 활용 분야: 코드 생성, 코드 리뷰, 버그 수정, 테스트 작성, 문서화, 레거시 코드 현대화
2026년 하반기 업데이트 · 2026-10-12 기준
상반기 원문 이후 달라진 점 — 목록의 7개 중 Windsurf·Amazon Q Developer는 이름이나 제품 자체가 바뀌었고, Codex·Copilot은 '하나의 제품'이 여러 실행 표면(앱·CLI·IDE·클라우드)으로 확장되었습니다.
- 확인된 사실: Windsurf는 2026-06-02 'Devin Desktop'으로 개명되었습니다. 2026-10-12 현재
windsurf.com은devin.ai/desktop으로 308 리다이렉트됩니다(직접 접속 확인). 기본 화면이 로컬·클라우드 에이전트를 관리하는 Agent Command Center로 바뀌었고, 원문에 나온 Cascade 에이전트는 Devin Local로 대체되었습니다(공식 FAQ는 "기존 Cascade는 7월까지 계속 사용 가능"이라고 안내 — Devin Desktop FAQ, 2026-10-12 확인). 또한 외부 에이전트를 편집기 안에서 돌리는 ACP(Agent Client Protocol)를 지원합니다. (Cognition 블로그 'Windsurf is now Devin Desktop' 검색 결과로만 확인 / Cascade 종료일은 Carly 정리 글에서 확인, 2026-10-12) - 확인된 사실: AWS는 Amazon Q Developer IDE 플러그인 지원을 2027-04-30에 종료하며, 같은 기능(인라인 제안·채팅·코드 생성)과 에이전틱 코딩·MCP 지원을 Kiro로 이전하라고 안내합니다. (AWS 문서, Q Developer IDE end of support, 2026-10-12 확인) 신규 가입이 2026-05-15부터 막혔다는 보도도 있습니다(검색 결과로만 확인).
- 확인된 사실: OpenAI Codex 문서는 이제
developers.openai.com/codex에서learn.chatgpt.com으로 리다이렉트되며, Codex를 ChatGPT 데스크톱·모바일·웹 앱, Codex CLI, Codex IDE 확장, Codex Cloud에서 쓸 수 있다고 안내합니다. 오픈소스는 Codex CLI(openai/codex)와 Codex SDK 등이고, IDE 확장과 Codex Cloud는 비공개입니다. 원문의 'Codex CLI와 클라우드 Codex는 별개 제품'이라는 구분은 지금은 '같은 Codex의 다른 실행 표면'으로 보는 편이 정확합니다. (Codex 문서, Codex Open Source, 2026-10-12 확인) - 확인된 사실: GitHub 문서는 원격으로 작업을 맡기는 Copilot 에이전트를 'Copilot cloud agent'라는 이름으로 설명하며, MCP 서버 연결을 지원합니다. 원문의 '코드 자동 완성 및 제안' 설명만으로는 현재 Copilot을 다 담지 못합니다. (GitHub Docs, 2026-10-12 확인) Copilot CLI가 정식 출시(GA)되었다는 공지도 있습니다(검색 결과로만 확인).
- 확인된 사실: Claude Code는 CLI 외에 Agent SDK(Python·TypeScript)로 같은 에이전트 루프를 애플리케이션에 내장할 수 있습니다. (Claude Agent SDK overview, 2026-10-12 확인)
- 해석·전망: 코딩 에이전트 시장은 'IDE 안의 도우미'에서 '여러 에이전트를 병렬로 돌리고 관리하는 관제 화면' 쪽으로 이동하고 있습니다. 동시에 ACP·MCP·AGENTS.md처럼 도구 간 이식성을 높이는 표준이 늘어, 특정 IDE에 묶이는 정도는 줄어드는 추세로 보입니다.
- 확인하지 못한 것: Cursor의 현재 제품 구성과 요금, GitHub Copilot의 요금·플랜 변경(사용량 기반 과금 전환 보도 등)은 공식 문서로 확인하지 못했습니다.
교육·실습 관점: 교재의 도구 목록에서 Windsurf는 'Devin Desktop(구 Windsurf)', Amazon Q Developer는 'Kiro(Q Developer IDE 플러그인 후속)'로 표기를 바꾸는 것을 권합니다. 실습용으로는 CLI형(Claude Code, Codex CLI, Copilot CLI) 하나와 원격 위임형(Copilot cloud agent, Codex Cloud, Devin) 하나를 짝지어 '동기 페어 프로그래밍 vs 비동기 작업 위임'을 비교하게 하면 원문의 Plan-and-Execute·Human-in-the-Loop 개념과 자연스럽게 연결됩니다.
(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"
2026년 하반기 업데이트 참고자료 (2026-10-12 확인)
- OpenAI, "Deprecations" — Assistants API 종료(2026-08-26), o1·o4-mini(2026-10-23)·o3 스냅샷(2026-12-11) 종료, deep research 모델 종료(2026-07-23), Agent Builder·
v1/prompts·Evals 종료(2026-11-30) - OpenAI, "Models" — 현행 대표 모델(GPT-6 Astra, GPT-6.1 Sol, GPT-6 Luna)과 추론 강도 설정
- Anthropic, "Models overview" — 현행 Claude 라인업, adaptive thinking·effort,
budget_tokens방식 deprecated - Google, "Gemini API: Thinking" — Gemini 모델별
thinking_level지원 값 - Google Cloud, "Vertex AI: Thinking" — Gemini 3의
thinking_level과 이전 세대thinking_budget구분(검색 결과로만 확인) - Google Blog, "Interactions API: our primary interface for Gemini models and agents" — Interactions API GA, Deep Research 에이전트, Managed Agents, 백그라운드 실행
- Microsoft AutoGen GitHub — AutoGen 유지보수 모드, MAF로 이전 권고
- Microsoft, "Microsoft Agent Framework Version 1.0" — MAF 1.0 GA(2026-04-03, 검색 결과로만 확인)
- OpenAI Agents SDK (Python) 문서 — Agents·Handoffs·Guardrails·Sessions·Tracing·MCP·Sandbox Agents
- OpenAI Agents SDK (JS/TS) GitHub — TypeScript 판 존재
- Google ADK 문서 — 5개 언어 지원, ADK TypeScript 2.0 GA, A2A 퀵스타트
- Anthropic, "Agent SDK overview" — Claude Agent SDK(Python·TypeScript), Managed Agents·tool runner와의 구분
- LangChain, "LangChain and LangGraph 1.0" — 1.0 안정화, docs.langchain.com 통합(검색 결과로만 확인)
- Dify, "v1.6.0: Built-in Two-Way MCP Support" — Dify MCP 양방향 지원(검색 결과로만 확인)
- MCP, "Versioning" — 현행 스펙 버전 2026-07-28
- MCP, "Key Changes (2026-07-28)" — 무상태화, 세션 제거,
server/discover, MRTR, tasks 확장 분리, 인증·OpenTelemetry 관련 변경 - MCP, "Deprecated Features" — Roots·Sampling·Logging·Dynamic Client Registration·HTTP+SSE deprecated
- MCP Blog, "Introducing the MCP Registry" — 공식 레지스트리 프리뷰 공개(검색 결과로만 확인)
- AAIF, "Projects" — AAIF 호스팅 프로젝트 목록(MCP, goose, AGENTS.md, agentgateway, A2A, Agent Router)
- A2A Specification — 최신 버전 1.0.0, 데이터 모델, 3개 프로토콜 바인딩
- Linux Foundation, "A2A Protocol Surpasses 150 Organizations…" — A2A v1.0 주요 기능, 참여 조직·SDK·클라우드 지원(2026-04-09)
- Techzine, "Google transfers A2A to the Agentic AI Foundation" — A2A의 AAIF 이관(2026-08-17)
- Cognition, "Windsurf is now Devin Desktop" — Windsurf 개명(검색 결과로만 확인)
- Carly, "Windsurf is now Devin Desktop" — 개명일(2026-06-02) 정리(제3자 자료). Cascade 종료 시점은 이 글의 '07-01'이 아니라 공식 FAQ의 '7월까지 사용 가능'을 따름
- Devin Desktop FAQ — Windsurf → Devin Desktop(2026-06-02), Cascade → Devin Local, 기존 Cascade는 7월까지 제공
- AWS, "Amazon Q Developer IDE plugins end of support" — Q Developer IDE 플러그인 2027-04-30 지원 종료, Kiro로 이전
- OpenAI, "Codex 문서" — Codex 실행 표면(앱·CLI·IDE 확장·Cloud)
- OpenAI, "Codex Open Source" — 오픈소스 구성 요소와 비공개 구성 요소
- GitHub Docs, "Copilot cloud agent" — Copilot 원격 에이전트 명칭과 MCP 지원