Executive Summary
- AI Agent의 본질은 기능 확장이 아니라 기업의 업무 실행 구조를 재편하는 데 있습니다.
- 기업 경쟁력은 Agent 자체보다 Skill, Connector, Plugin, Governance를 운영하는 체계에서 결정됩니다.
- 향후 핵심 과제는 Agent 도입이 아니라 여러 Agent를 안전하게 조율하고 통제하는 협업형 실행 구조를 구축하는 것입니다.
Executive Summary
AI Agent의 본질은 더 많은 AI 기능을 추가하는 데 있지 않습니다. 기업의 업무 실행 구조가 소프트웨어 안에서 재편되는 변화에 있습니다. 따라서 기업은 이제 ‘어떤 Agent를 도입할 것인가’보다 ‘Agent가 어떤 권한과 정책 아래에서 업무를 수행하게 할 것인가’를 먼저 설계해야 합니다.
AI Agent의 경쟁력도 더 이상 개별 기능의 우수성만으로 결정되지 않습니다. 생성형 AI가 개인의 생산성을 높이는 도구였다면, AI Agent는 업무의 실행 방식은 물론 권한, 승인, 감사 체계까지 바꾸는 실행 계층으로 이동하고 있습니다. 기업이 이 변화에 주목해야 하는 이유는 명확합니다. 실행 권한이 이미 소프트웨어 내부로 들어오고 있기 때문입니다. Salesforce, ServiceNow, SAP, Microsoft, Atlassian 등 주요 벤더들의 발표는 Agent가 단순한 데모 단계를 넘어 실제 업무 단위로 상용화되고 있음을 보여줍니다. 이제 핵심은 개별 모델의 성능이 아니라 여러 Agent와 업무 시스템을 어떻게 조율하고 통제할 것인가입니다.
결국 기업의 첫 과제는 특정 제품을 먼저 고르는 일이 아닙니다. 어떤 업무를 Agent에게 맡길지, 어떤 데이터와 시스템 Action을 허용할지, 어느 지점에서 사람의 승인을 요구할지를 정의하는 것입니다.
[그림 1. AI Agent의 변화 (출처: GPT-5.5 활용 제작)]
핵심은 기능의 확장이 아닌, "목표 달성을 위한 실행 주체"로의 변화
사용자 명령 (Prompt) - "이메일 초안 작성해줘","문서 요약해줘',"회의륵 정리해줘","코드 만들어워","변역해줘" → AI(생성형 도템) - 답변 / 산출물 생성 → 결과 제공 - 텍스트 답변,요약문,초안/문서,코드,변역문
사옹자 목표 (Goal) - "다음 주 고객 미팅 준비해줘" (목표 증심의 자연어 요청) Al Agent - 1.의도 이해 및 계획 수립 → 2.정보 탐색 (문서/테이터/시스템) → 3.도구/시스템 선택 및 실행 (API, Connector 호출) → 4.실행 결과 검증 및 보완 (필요 시 반복) - 5.결과 제공 및 후속 조치 (보고/업데이트/알림) 업무 결과 (Outcome) - 브리핑 자료 생성,관런 문서 요약,일정 조율 제안,CRM 정보 업데이트,후속 이메일 초안
AI Agent는 사용자의 목표를 이해하고, 필요한 데이터와 도구를 선택한 뒤, 정해진 권한과 정책 안에서 업무 결과를 만들어내는 ‘실행형 AI’입니다. 기존 AI Assistant가 질문에 답하거나 산출물을 생성하는 데 초점을 맞췄다면, AI Agent는 업무 목적을 기준으로 실행 단계를 직접 구성하고 외부 시스템과 상호작용합니다.
이러한 변화는 기존 AI 활용의 연장선에 있지만 단순한 기능 확장은 아닙니다. 조회형 AI는 필요한 지식을 찾아주었고, 생성형 AI는 콘텐츠를 만들어냈으며, 자동화형 AI는 정해진 절차를 반복 실행했습니다. 반면 AI Agent는 업무 맥락을 해석하고, 적절한 도구를 선택하며, 실행 결과를 검증하는 역할까지 수행합니다.
따라서 AI Agent의 본질은 단순히 ‘더 똑똑한 챗봇’이 아닙니다. 사람의 요청과 기업 시스템 사이에서 업무를 해석하고 실행하는 새로운 소프트웨어 계층입니다. 이 관점이 중요한 이유는 Agent를 기능이 아닌 실행 계층으로 바라볼 때, 자연스럽게 다음 질문이 ‘무엇을 할 수 있는가’에서 ‘어디에서 실행되며 무엇을 통제해야 하는가’로 바뀌기 때문입니다.
AI Agent를 하나의 범주로만 바라보면 도입 전략이 흐려질 수 있습니다. 솔루션 AI Agent, Cloud Workspace AI Agent, Local AI Agent는 모두 Agent라는 이름을 사용하지만, 접근하는 데이터와 실행 권한, 리스크, 성과 지표가 서로 다릅니다. 기업은 이러한 차이를 기준으로 투자 우선순위와 통제 방식을 구분해야 합니다.
[그림 2. 세 가지 실행 레이어 (출처: GPT-5.5 활용 제작)]
| 구분 | 1 솔루션 Al Agent | 2 Cloud Workspace Al Agent | 3 Local Al Agent |
| 핵심 역할 | 업무 시스템 안에서 프로세스 실행 | 업무 맥락 조율과 지식업무 실행 | 개인 실행환경에서 실제 작업 수행 |
| 주요 데이터 | CRM, ERP, ITSM, HR, 고객, 계약, 티켓 등 | 매일, 문서, 일정, 회의, 채팅, 프로젝트 등 | 로컬 파일, 화면, 브라우저, IDE, 터미널 등 |
| 실행 권한 | 솔루션 API, workflow, business rule | 사용자 계정, Connector, cross-app action | OS, 브라우저, 앱, 파일, terminal |
| 대표 가치 | 업무 처리량, SLA, 오류 감소 | 생산성, 협업, 업무 준비 | 프라이버시, 저지연, 실제 작업 조작 |
| 주요 KPI | 처리량 증가, SLA 준수율, 오류을 감소, 업무 사이클 타임 단축 | 업무 준비 시간 단축, 협업 효을 향상, 콘텐츠 생산성 중가 | 작업 완료 시간 단축, 사용자 생산성, 로컬 자동화 성공률 |
| 주요 리스크 | 시스템 변경 오류, 데이터 무결성, 권한 오남용 | 데이터 외부 유출, 과도한 권한, 콘텐츠 장확성/기일성 | 악성 실행/파일 손상, 프라이버시 침해, 로컬 데이터 유출 |
이 세 유형은 경쟁 관계가 아니라 역할 분담 관계에 가깝습니다. 솔루션 Agent는 CRM, ERP, ITSM, HR과 같은 업무 시스템 안에서 프로세스를 실행합니다. Workspace Agent는 메일, 문서, 회의, 일정, 프로젝트를 연결해 업무 맥락을 조율합니다. Local Agent는 PC, 브라우저, IDE, 파일, 화면 등 사용자의 실제 작업환경 안으로 들어옵니다.
따라서 기업은 어느 Agent가 더 우수한지를 비교하기보다, 각 레이어에 어떤 업무를 배치하고 어떤 수준의 권한을 부여할 것인지를 먼저 설계해야 합니다. 이제 중요한 것은 각 레이어가 얼마나 빠르게 성장하는가가 아니라, 각 레이어가 기업 운영에 어떤 의미를 갖는가입니다. 그렇다면, 글로벌 시장 지표가 보여주는 핵심 변화를 세 가지 관점에서 살펴보겠습니다.
솔루션 AI Agent에서 가장 중요한 변화는 AI가 SaaS의 부가 기능이 아니라 업무 시스템 내부의 실행 계층으로 흡수되고 있다는 점입니다. 주요 벤더들의 발표 역시 ‘AI 기능 출시’보다 실제 업무 단위에서의 활용과 고객 확산을 강조하는 방향으로 바뀌고 있습니다.
이 수치들이 중요한 이유는 매출 규모 자체 때문이 아닙니다. Agent가 더 이상 ‘기능 사용량’이 아니라 ‘업무 처리량’의 언어로 설명되기 시작했다는 점에 있습니다. CRM에서는 고객 대응과 영업 활동이, ITSM에서는 티켓·변경·장애 대응이, ERP에서는 주문·재고·구매·재무 프로세스가 Agent의 실행 대상이 됩니다. 즉, 성과 측정 역시 AI 사용 횟수가 아니라 처리시간, 오류율, SLA, 고객 응답 품질, 업무 처리량 중심으로 이동해야 합니다.
국내 기업 환경에서도 시사점은 분명합니다. 이미 ERP, 그룹웨어, SCM, HCM, ITSM이 복잡하게 연결된 조직이라면, Agent 도입은 특정 SaaS 기능을 켜는 문제가 아니라 업무 프로세스 소유자, 데이터 권한, 승인 절차를 함께 재설계하는 문제입니다. 특히 기간계 시스템과 연결되는 Agent는 PoC 단계부터 업무 KPI와 통제 기준을 같이 정의해야 합니다.
Workspace Agent의 핵심은 특정 애플리케이션 하나를 더 똑똑하게 만드는 데 있지 않습니다. 메일, 문서, 회의, 일정, 프로젝트, 조직 관계를 하나의 Work Graph로 연결해 업무의 시작점을 바꾸는 데 있습니다. 주요 사례도 개별 앱 기능보다 업무 맥락 연결과 Agent 관리 체계로 초점이 이동하고 있음을 보여줍니다.
이 흐름이 의미하는 바는 명확합니다. 사용자는 더 이상 어떤 애플리케이션에서 업무를 시작해야 하는지를 먼저 고민하지 않습니다. 대신 ‘무엇을 완료해야 하는가’를 Agent에게 제시하게 됩니다. Agent는 관련 메일, 회의록, 문서, 이슈, 프로젝트 맥락을 찾아 업무 초안을 작성하거나 다음 Action을 제안합니다.
국내 기업에서는 그룹웨어, M365, Jira, Confluence, 사내 포털, 문서 저장소가 병존하는 경우가 많습니다. Workspace Agent를 제대로 쓰려면 검색 품질만 높여서는 부족합니다. 문서 등급, 메일 접근 권한, 프로젝트별 정보 경계, 퇴직자·전보자 권한 회수, 외부 공유 정책이 work graph 수준에서 정리되어야 합니다.
[그림 3. Cloud Workspace Agent를 통한 사용자 Work Graph 중심의 데이터 연결 (출처: GPT-5.5 활용 제작)]
특정 업무 트랜잭션 데이터가 아니라 사용자의 Work Graph가 핵심 자산
매일, 문서, 일정, 조직 관계, 회의, 파일, 미팅, 프로책트 - 모든 업무 맥락이 연결되어 Agent가 이해하고 활용
사용자가 목표를 말하면, Agent가 맥락을 이해하고 필요한 앱과 대이터를 연결하여 결과를 만듭니다.
사용자 요청 (에시) : "내일 고객 미팅 준비해줘","프로팩트 헌황 정리해줘","이번 주 증요한 메일 요약해줘","보고서 초안 작성해줘" → Cloud Workspace Al Agent → Agent가 수행하는 일 : 맥락 이해 (메임, 문서, 일정, 회의, 채팅 등),관련 정보 탐색 및 연결,필요한 앱과 도구 호출,문서/슬라이드/요약 동 결과 생성,후속 조치 및 알림
연결 가능한 주요 업무 공간 Microsoft 365(Outlook, Teams,SharePoint &),Google Workspace(Gmail, Drive,Calendar 등),Slack,Jira,Confluence,ChatGPT Enterprise
회의 준비, 이메일 요약과 답변, 문서 작성, 프로젝트 현항 정리, 고객 미팅 브리핑, 일정 조율, 보고서 초안 작성, 여리 앱을 넙나드는 업무 조율 - 여러 앱과 데이터를 넘나들며 업무 맥락을 연결하고 생산성을 높입니다.
Local AI Agent는 사용자의 실제 작업환경에 가장 가깝게 위치합니다. 이 영역의 핵심 변화는 Agent가 단순히 답변을 생성하는 데 그치지 않고, 코드, 브라우저, 파일, 화면, 터미널과 같이 사람이 직접 다루던 실행 환경으로 들어오고 있다는 점입니다.
Local Agent의 의미는 단순한 개발자 생산성 향상에 그치지 않습니다. 브라우저 세션, 로컬 파일, IDE, 터미널, 사내 포털처럼 API가 정리되지 않은 작업환경까지 Agent의 실행 범위가 넓어질 수 있습니다. 그만큼 파일 삭제, 코드 수정, 이메일 발송, 인증 세션 조작, 내부 데이터 접근 같은 리스크도 함께 커집니다.
국내 기업에서는 Local Agent를 “개인 생산성 도구”로만 보면 위험합니다. 개발 환경, 업무 PC, 브라우저, 문서 저장소를 다루는 Agent에는 sandbox, 권한 분리, 로그 수집, 민감정보 차단, 중요 action 승인 정책이 필요합니다. 특히 소스코드와 고객 데이터가 함께 존재하는 환경에서는 Agent의 실행 범위를 업무별로 제한해야 합니다.
세 가지 Agent 레이어가 기업 안으로 확산될수록 공통 문제가 생깁니다. Agent마다 업무 방식이 다르고, 시스템 연결 방식이 다르며, 권한과 감사 방식이 제각각이면 운영 복잡도가 빠르게 커집니다. 그래서 Agent 확산의 핵심은 개별 Agent 수를 늘리는 것이 아니라, Agent가 일하는 방식을 표준화하는 데 있습니다.
Skill은 반복 가능한 업무 절차와 산출물 형식을 정의합니다. Skill은 특정 작업을 더 일관되게 수행하기 위한 reusable, shareable workflow로, instructions, examples, code를 포함할 수 있습니다[10]. Connector는 Agent가 접근할 수 있는 데이터, 시스템, 도구의 연결 방식을 정의합니다. MCP는 AI 애플리케이션이 데이터 소스와 도구에 연결되는 방식을 표준화하는 open-source standard로 설명됩니다[11].
Plugin은 이 둘을 결합해 특정 업무 결과를 만들어내는 실행 단위로 볼 수 있습니다. 예를 들어 “고객 미팅 준비”라는 Plugin은 CRM 고객 이력 조회, 관련 메일 요약, 회의자료 생성, 후속 메일 초안, CRM 활동 업데이트를 하나의 업무 결과로 묶을 수 있습니다. 이때 중요한 것은 API 호출 자체가 아니라, 어떤 권한으로 어떤 조건에서 실행할지까지 정의하는 것입니다.
[그림 4. 재사용 가능한 표준 업무 실행 단위, Plugin 구조 (출처: GPT-5.5 활용 제작)]
Skill과 Connector를 결합하고, Policy와 감사 기준을 포함해 하나의 업무 흐름으로 실행합니다.
"고객 미팅 준비" 목표만 제시
Skill·Connector·Policy를 결합한 재사용 가능한 업무 실행 패키지 Skill: 회의 준비 SOP,요약 형식,검토 기준 Policy: 권한 범위,승인 조건,감사 로그 Connector: CRM,Email,Calendar / Drive Plugin 실행 - 승인된 절차와 연결만 호출하고, 필요 시 사람 승인을 요청
회의자료 생성,브리핑 요약,Follow-up 메일,CRM 업데이트
Plugin은 API 호출 묶음이 아니라 Skill-Connector·Policy를 결합해 업무 결과를 만드는 실행 단위입니다.
Agent가 늘어나면 기업은 곧바로 운영상의 질문에 직면하게 됩니다. 어떤 Agent 기능이 존재하는지, 누가 만들었는지, 어떤 데이터에 접근하는지, 어떤 Action을 수행하는지, 보안 검토를 통과했는지, 비용은 어떻게 추적되는지, 오래되거나 위험한 Plugin은 어떻게 폐기할 것인지에 대한 기준이 필요해집니다.
Public Marketplace는 외부 벤더와 파트너가 만든 Agent 기능을 발견하는 공개 유통 채널입니다. 구체 제품별 기능을 본문에서 길게 나열하기보다, 여기서는 주요 벤더들이 Agent 기능을 actions, connectors, templates, partner agents, apps 형태로 유통하기 시작했다는 흐름만 확인하면 충분합니다. 기업 관점에서 중요한 것은 외부 Marketplace 자체가 아니라, 외부와 내부에서 만들어진 Agent 기능을 어떤 기준으로 선별하고 운영할 것인가입니다.
[그림 5. 엔터프라이즈 환경에서의 안전한 재사용을 위한 Plugin 관리 프레임워크 (출처: GPT-5.5 활용 제작)]
Agentforce용 actions, topics, templates를 제공하는 marketplace 공개 (출시 시정에 200개+ 파트너 참여)
Marketplace, 200게+ 파트너Power Platform connectors와 custom connector를 통해 외부 앱과 서비스를 Agent tool로 연결
Connectors, Custom ConnectorThird-party agents와 tools를 MCP, A2A 기반으로 연결하고, multi-agent workflow orchestration 지원
MCP / A2A 인결, Multi-agent OrchestrationMCP와 A2A 감은 공유 프로토를 삶용, Workday 및 partner agents가 협업하도록 설계
Agent Gateway, Marketplace (Workday & Partner Agents)Google Drive, SharePoint, Teams, Figma & third-party SaaS 데이터를 연결하고, Rovo Search, Chat, Agent 경험을 강화
3rd-party Connectors, Atlassian MarketplaceCRM,ERP,ITSM,이에일,캘린더,문서 저장소,데이터베이스,코드 저장소,브라우저,로걸 파일,터미널
따라서 기업에는 내부 기준으로 검증된 Skill, Connector, Plugin을 공유하고 통제하는 Private Enterprise Marketplace가 필요합니다. 이 공간에는 승인된 Plugin만 등록되어야 하며, 각 Plugin의 소유자, 사용 권한, 연결 시스템, 보안 검토 상태, 버전, 비용 기준, 폐기 여부가 함께 관리되어야 합니다. 즉 내부 Marketplace는 Agent 기능을 모아두는 저장소가 아니라, 검증된 업무 실행 단위를 안전하게 재사용하기 위한 운영 공간입니다.
Control Plane은 이러한 Marketplace 위에서 Agent의 신원, 등록 현황, 사용 이력, 실행 상태, 보안 정책을 통합 관리하는 기반입니다. 국내 기업은 이미 계정·권한·감사 체계가 복잡하므로, Agent 운영 체계를 기존 IAM, DLP, SIEM, ITSM, 데이터 거버넌스 체계와 연결해야 합니다.
앞으로의 경쟁은 하나의 Agent가 모든 업무를 처리하는 방향으로 가기보다, 여러 Agent가 역할을 나누고 동일한 정책과 통제 체계 아래에서 협업하는 방향으로 전개될 가능성이 높습니다. 이미 주요 플랫폼들은 외부 Agent와 내부 업무 시스템을 연결하고, Agent 간 역할 분담과 orchestration을 지원하는 방향으로 움직이고 있습니다[12][13].
여기서 중요한 것은 Agent의 수가 많아지는 것이 아닙니다. 각 Agent가 어떤 역할을 맡고, 어떤 데이터에 접근하며, 어떤 Action을 실행하고, 어느 시점에 사람의 승인을 받아야 하며, 실행 결과를 어디에 기록할 것인지가 명확하게 정의되어야 합니다. Collaborative AI Agents는 여러 AI가 단순히 대화하는 구조가 아니라, 표준화된 Skill, Connector, Plugin, Policy, Audit 체계 위에서 역할을 분담하고 협력하는 기업형 실행 구조입니다.
AI Agent 전략은 특정 제품을 먼저 고르는 문제가 아닙니다. 먼저 Agent가 실제 업무를 수행해도 되는 영역과 사람의 승인 없이 실행해서는 안 되는 영역을 구분해야 합니다. 아래 그림은 이를 운영 관점에서 점검하기 위한 기본 항목입니다.
[그림 6. AI Agent의 설계 전략 (출처: GPT-5.5 활용 제작)]
| 준비 영역 | 핵심 설계 원칙 | 기업 운영 관점의 체크포인트 |
| Agent Use Case Portfolio | 생산성 과제와 실행형 업무를 분리해 우선순위를 정합니다. | 요약·작성 중심 과제와 시스템 action이 필요한 과제를 구분하고, 후자는 별도 리스크 등급을 부여합니다. |
| Skill 표준화 | 반복 업무 절차, 산출물 형식, 검토 기준을 조직 자산으로 패키징합니다. | 부서별 프롬프트가 아니라 승인된 Skill library로 관리하고, 변경 이력과 소유자를 둡니다. |
| Connector/ Plugin 관리 | Agent가 호출할 수 있는 도구를 업무 목적 단위로 제한합니다. | 읽기 ·쓰기 권한, parameter constraint, 승인 조건, rate limit, 비용 기준을 명시합니다. |
| Agent Control Plane | Agent identity, registry, observability, governance, security를 중앙에서 관리합니다. | Agent 등록, 소유자, 권한, 실행 로그, 실패율, 비용, 비활성 Agent 페기 기준을 운영합니다. |
| Human-in-the-loop | 업무 영향이 큰 action은 사람의 검토와 승인을 통과하게 합니다. | 고객 통지, 외부 발송, 결제, 계약, 계정 권한 변경, 운영 시스템 수정은 승인 단계를 둡니다. |
| Audit & Compliance | Agent가 무엇을 보고, 판단하고, 실행했는지 재현 가능해야 합니다. | 입력, 참조 데이터, 호출 도구, 실행 결과, 승인자, 실패 ·롤백 이력을 로그로 남깁니다. |
첫째, 업무를 “조회·초안·추천·실행” 단계로 나누고, Agent가 어디까지 수행할 수 있는지 정해야 합니다. 특히 고객 통지, 계약, 결제, 권한 변경, 운영 시스템 수정처럼 영향도가 큰 업무는 별도 승인 대상으로 분류해야 합니다.
둘째, 반복 업무는 Skill로 표준화하고, 외부 시스템 접근은 Connector와 Plugin 단위로 제한해야 합니다. 중요한 것은 연결 자체가 아니라 읽기·쓰기 권한, 실행 조건, 승인 기준, 로그 위치를 함께 정의하는 것입니다.
셋째, Agent와 Plugin의 소유자, 접근 시스템, 사용 현황, 비용, 실패율, 폐기 여부를 한 곳에서 관리해야 합니다. 이 운영 기반이 Control Plane이며, 기존 IAM, 보안 관제, ITSM, 데이터 거버넌스와 연결되어야 합니다.
마지막으로, 고위험 action에는 Human-in-the-loop을 기본값으로 두어야 합니다. 모든 단계에 사람을 넣는 것이 아니라, 업무 영향도가 큰 지점에 명확한 승인선을 두는 것이 핵심입니다.
AI Agent의 진화는 Assistant가 더 많은 기능을 갖게 되는 과정이 아닙니다. 기업 업무의 실행 구조가 바뀌는 과정입니다. 솔루션 Agent는 업무 시스템 안에서 프로세스를 실행하고, Workspace Agent는 업무 맥락을 연결하며, Local Agent는 사용자의 실제 작업환경 안으로 들어옵니다.
이 변화 속에서 기업이 주목해야 할 것은 어떤 Agent 제품을 먼저 선택할 것인가가 아닙니다. 더 중요한 질문은 Agent에게 어떤 업무를 맡길 것인지, 어떤 데이터와 시스템 Action을 허용할 것인지, 그리고 어떤 기준으로 성과와 위험을 통제할 것인지입니다.
결국 AI Agent 전략은 기술 도입 전략이 아니라, 기업의 업무 실행 구조와 운영 체계를 재설계하는 문제입니다. 지금까지 살펴본 내용을 종합하면, 기업이 AI Agent 시대에 주목해야 할 핵심 변화는 다음 네 가지로 정리할 수 있습니다.
앞으로의 경쟁력은 더 많은 Agent를 확보하는 데서 나오지 않습니다. 여러 Agent가 동일한 정책과 감사 체계 아래에서 역할을 나누고, 필요한 데이터와 도구를 안전하게 활용하며, 사람의 승인과 통제 안에서 업무를 수행할 수 있도록 만드는 운영 역량에서 결정될 것입니다.
AI Agent 도입의 첫 단계는 제품 선정이 아닙니다. 어떤 업무를 Agent에게 맡길 것인지, 어떤 데이터와 시스템 Action을 허용할 것인지, 그리고 어느 시점에 사람의 승인을 받을 것인지를 먼저 정의해야 합니다.
솔루션 Agent는 CRM·ERP·ITSM과 같은 업무 시스템 안에서 프로세스를 수행합니다. Workspace Agent는 메일, 문서, 회의, 일정 등 업무 맥락을 연결하며, Local Agent는 PC, 브라우저, IDE와 같은 실제 작업환경에서 업무를 수행합니다. 각 레이어는 접근 데이터와 권한, 리스크가 다르므로 별도의 통제 체계가 필요합니다.
기업 환경에서는 하나의 Agent가 모든 업무를 처리하기 어렵습니다. 여러 Agent와 업무 시스템이 함께 동작해야 하므로, 역할을 분담하고 실행 과정을 조율하는 Orchestration이 핵심 경쟁력이 됩니다. 앞으로는 개별 모델의 성능보다 Agent 간 협업 구조가 더욱 중요해질 것으로 예상됩니다.
기업이 수십 개 이상의 Agent를 운영하게 되면 업무 수행 방식의 표준화가 필요합니다. Skill은 업무 절차를, Connector는 데이터와 시스템 연결을, Plugin은 실제 업무 실행 단위를 정의합니다. 이는 Agent를 반복 가능하고 통제 가능한 방식으로 운영하기 위한 기반입니다.
Agent가 실제 업무를 수행하기 시작하면 권한, 승인, 감사, 보안 관리가 중요해집니다. 따라서 기업은 Agent의 사용 현황과 권한, 연결 시스템, 비용, 실행 이력을 통합 관리할 수 있는 Control Plane과 Governance 체계를 함께 구축해야 합니다.
▶ 해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶ 해당 콘텐츠는 사전 동의 없이 2차 가공 및 영리적인 이용을 금하고 있습니다.
![]()