에이전틱 AI, 도구에서 동료로 - 2026년 4월 기업 AI 현황

마이크로소프트는 이달 기준 유료 Copilot 좌석 1,500만 개를 팔았다. ARR $54억. 숫자만 보면 에이전틱 AI의 기업 대중화가 완성된 것처럼 보인다.

같은 시기, Siddharth Dhar는 인터뷰에서 이렇게 말한다.

"우리의 기업 환경은 아직 에이전틱 AI를 받아들일 준비가 되어 있지 않다."

둘 다 맞는 말이다. 이 역설이 2026년 에이전트 AI의 실체다.

"에이전틱"이라는 단어가 오염되고 있다

Microsoft Wave 3 Copilot이 에이전틱이라고 불리는 이유는 이전보다 더 많은 단계를 자동으로 처리하기 때문이다. 이메일 요약, 회의록 작성, 문서 초안 생성. 그런데 이건 에이전트가 아니다. 더 복잡한 자동화다.

진짜 에이전틱 AI의 기준은 단순하다: 목표를 받고, 스스로 계획을 세우고, 실패했을 때 방법을 바꾸는가? Copilot은 이걸 하지 않는다. 정해진 워크플로우 위에서 LLM을 더 깊이 쓰는 구조다.

이 차이가 중요한 이유는 명확하다. "기업이 에이전틱 AI를 도입했다"는 헤드라인과 "실제로 에이전트가 자율적으로 비즈니스 판단을 내리고 있다"는 현실 사이의 간극을 측정하는 기준이 달라지기 때문이다. 지금 1,500만 기업 사용자 중 실제 자율 에이전트를 운영 중인 비율은 거의 0에 가깝다. 그게 잘못된 게 아니다. 시작이 그렇다는 것이다.

기업 환경이 "준비 안 된" 이유는 기술이 아니다

흔히 드는 착각: 에이전트가 못 쓰이는 이유가 모델 성능 때문이라는 것. GPT-4o, Claude, Gemini 3 — 이미 웬만한 추론 과제는 된다. 문제는 모델 바깥에 있다.

에이전트가 기업 환경에서 작동하려면 세 가지가 필요하다.

1. 신뢰할 수 있는 데이터 접근 레이어

에이전트는 툴을 호출해 데이터를 읽는다. 그런데 대부분 기업의 데이터는 사일로다. CRM, ERP, 마케팅 플랫폼, 데이터 웨어하우스가 API로 연결돼 있지 않거나, 연결돼 있어도 권한 체계가 엉망이다. "2분기 영업 실적 분석해서 다음 분기 전략 제안해"라고 에이전트에 시키려면, 먼저 그 데이터가 에이전트가 읽을 수 있는 형태로 존재해야 한다.

Kyndryl이 이달 출시한 Agentic Service Management가 에이전트 배포 전에 "성숙도 모델 평가"를 먼저 제시하는 이유가 여기 있다. 데이터 파이프라인, 권한 관리, API 표준화가 안 된 상태에서 에이전트를 붙이면 아무 일도 안 일어난다.

2. 감사 가능성(Auditability)

사람이 판단을 내릴 때는 의사결정 근거를 설명할 수 있다. 에이전트는? 현재로선 어렵다. "왜 이 결정을 내렸는가"를 사후에 추적하기 어렵고, 이게 컴플라이언스 요건이 강한 금융·의료·법무 분야의 도입을 막는 핵심 이유다.

Exabeam이 이달 배포한 행동 분석(Behavioral Analytics)은 이 문제에 대한 첫 번째 실용적 응답이다. AI 에이전트의 "평소와 다른" 행동을 감지하는 시스템 — 이건 보안 문제이기도 하지만, 거버넌스 문제이기도 하다. 에이전트가 어디서 무슨 툴을 호출했는지 로그가 있어야 사후 감사가 가능하다.

3. 실패에 대한 책임 구조

에이전트가 자율적으로 행동한다는 건 에이전트가 틀릴 수도 있다는 뜻이다. 잘못된 이메일을 보내거나, 잘못된 데이터를 삭제하거나, 잘못된 계약서를 생성하는 시나리오. 누가 책임지는가? 이 질문에 대한 법적·제도적 답이 없는 상태에서 기업 법무팀이 자율 에이전트를 허용할 이유가 없다.

제조업이 먼저 뚫린다

Deloitte가 최근 에이전틱 AI가 제조업 현상 유지를 뒤흔들 가능성을 제기했다. 이게 빈말이 아닌 이유가 있다.

제조 현장의 데이터는 구조화돼 있고, 도메인이 명확하며, 판단 결과가 즉각 측정 가능하다. "설비 X의 진동 패턴이 임계값을 넘으면 Y 조치를 취하라"는 규칙은 에이전트에게 이상적인 작업 환경이다. 앞서 말한 세 가지 조건 — 데이터 접근, 감사 가능성, 책임 구조 — 이 제조 도메인에서는 상대적으로 정비하기 쉽다.

포스코DX가 이달 국산 NPU를 제조 현장에 직접 붙이는 실험을 시작한 것도 이 흐름의 연장이다. 데이터를 클라우드에 올려서 판단받는 게 아니라, 엣지에서 실시간으로 결정하는 구조. 레이턴시도 줄고, 인터넷 연결 의존도도 낮아진다. 그리고 역설적으로, 에이전트의 자율성이 더 안전하게 작동할 수 있는 환경이기도 하다 — 도메인이 좁고, 실패의 영향 반경이 제한적이니까.

폭넓고 불분명한 사무직 업무보다 좁고 측정 가능한 현장 업무에서 에이전트가 먼저 실용화되는 건 우연이 아니다.

지금 코드 짜는 사람이 알아야 할 것

MCP가 de facto 표준이 됐다. Model Context Protocol — 에이전트가 외부 툴을 호출하는 방식의 표준화 시도가 업계 기본값이 되어가고 있다. 지금 내부 시스템을 MCP 호환으로 설계해두면, 어떤 모델을 쓰든 에이전트와 연결하기 쉬워진다. 새 시스템 설계할 때 MCP 서버로 노출하는 걸 기본으로 고려할 시점이다.

멀티 에이전트가 기본 아키텍처다. Microsoft Agent Framework, Google Antigravity 모두 단일 에이전트가 아닌 에이전트 네트워크를 전제로 설계됐다. 복잡한 태스크를 쪼개서 전문화된 에이전트가 나눠 처리하는 구조. 에이전트를 설계할 때 "이 에이전트가 다른 에이전트와 어떻게 협업하는가"를 처음부터 고려해야 한다. 나중에 붙이려고 하면 인터페이스 설계부터 다시 해야 한다.

Eval이 가장 어렵고 가장 중요하다. 에이전트는 단위 테스트가 안 된다. 실행 경로가 동적이고 외부 상태에 의존하기 때문이다. 지금 에이전트 팀들이 가장 많이 투자하는 영역이 eval 프레임워크다. 에이전트를 만들기 전에 어떻게 평가할지를 먼저 설계해야 한다. 그게 없으면 "잘 되는 것 같다"와 "잘 된다" 사이의 차이를 영원히 알 수 없다.

1,500만 좌석과 "준비 안 됨" 사이의 간극은 모순이 아니다. 지금 기업들이 사는 건 에이전틱 AI의 1단계 — 복잡한 자동화 레이어다. 진짜 에이전트는 그 위에, 데이터 파이프라인과 감사 구조와 책임 체계가 갖춰진 다음에야 올 수 있다. 그게 1년이 걸릴지 3년이 걸릴지는 기술의 속도가 아니라 제도와 조직의 속도에 달렸다.

Sources - Enterprise environments not ready for agentic AI — The Week - Microsoft Solidifies Enterprise AI Dominance — FinancialContent - Kyndryl Agentic Service Management — PR Newswire - Securing the Agentic Enterprise — Exabeam - Agentic AI in Manufacturing — Deloitte/Manufacturing Dive - From Assistant to Actor — Morgan Lewis