AI

[AI] Agentic AI, 기대의 정점에 서다 — Gartner가 말하는 자율성과 통제의 간극

rubrub 2026. 9. 3. 23:41

요즘은 정말 “Agentic AI”라는 말을 안 듣고 지나가는 날이 없다.

데모만 보면 이미 사람이 할 일이 거의 없어 보인다. Agent가 목표를 받고, 검색하고, 코드를 짜고, 다른 Agent에게 일을 나누고, Tool을 호출해서 실제 시스템까지 움직인다.

그런데 한 가지 질문을 던져보면 분위기가 조금 달라진다.

THE AWKWARD QUESTION
“그래서 우리 회사 Production에서
Agent가 실제로 스스로 행동하고 있나요?”

대부분의 조직은 여기서 아직 “일부만”, 혹은 “아직”이라고 답한다.

Gartner의 2026 Hype Cycle for Agentic AI가 정확히 이 간극을 짚는다. Agentic AI는 지금 Peak of Inflated Expectations — 부풀려진 기대의 정점에 올라와 있다.

17%
현재 AI Agent를 배포한 조직
60%+
향후 2년 내 도입을 기대하는 조직
TL;DR
Agentic AI의 병목은 이제 “모델이 충분히 똑똑한가?”만이 아니다.
“기업이 그 자율성을 안전하게 운영할 준비가 되었는가?”가 더 큰 문제다.

01. 일단 Agentic AI가 정확히 뭐지?

Chatbot과 Agent를 구분하는 가장 쉬운 기준은 “답을 생성하느냐, 행동을 이어가느냐”다.

형태 동작 예시
Assistant 질문에 답하거나 초안을 생성 FAQ, 문서 요약, 이메일 작성
Workflow 정해진 순서대로 모델/도구 실행 분류 → 검색 → 답변
Agent 상태에 따라 다음 행동을 스스로 선택 Search / Tool / Retry / Delegate
Autonomous Agent 정해진 guardrail 안에서 실제 action까지 자율 실행 설정 변경, 주문, 운영 조치

핵심은 단순히 LLM에 Tool을 하나 붙였다는 게 아니다.

Goal
↓
Observe / Retrieve
↓
Plan
↓
Act
↓
Observe Result
↓
Re-plan ↺

행동 결과를 보고 다음 행동을 다시 결정하는 loop가 생기는 순간, 시스템의 성격이 크게 달라진다.

02. 지금 Agentic AI는 정말 “기대의 정점”에 있다

Gartner의 Hype Cycle은 신기술이 대중의 기대와 실제 검증을 거치며 어떻게 성숙하는지를 다섯 단계로 본다.

Expectations Maturity → Agentic AI Peak of Inflated Expectations Innovation Trigger Peak Trough of Disillusionment Slope of Enlightenment Plateau of Productivity
Gartner Hype Cycle 개념을 바탕으로 재구성한 개념도 · 2026 Agentic AI 위치는 Gartner 공개 자료 기준

이 위치를 “곧 망한다”고 이해하면 안 된다.

Peak의 뜻은 오히려 기술의 가능성은 크지만 시장의 기대가 현재의 production maturity보다 앞서 있다는 쪽에 가깝다.

실제 Gartner 조사에서는 현재 AI Agent를 배포한 조직은 17%지만, 60%가 넘는 조직이 향후 2년 안에 배포할 것으로 예상했다. Gartner는 이를 조사된 신흥 기술 중 가장 공격적인 adoption curve로 설명한다.

이 숫자가 재미있는 이유
17% → 60%+ 사이에는 모델 성능만 들어 있는 게 아니다. IAM, Tool 권한, Audit, Eval, 비용 통제, 운영 책임, 데이터 품질, legacy integration이 전부 들어 있다.

즉 이 간극 자체가 앞으로 몇 년간의 Agent Platform Engineering 시장이다.

03. 더 강한 경고도 있다: 40% 이상의 프로젝트가 취소될 수 있다

Gartner는 별도 전망에서 2027년 말까지 Agentic AI 프로젝트의 40% 이상이 취소될 것이라고 예측했다.

이유는 꽤 현실적이다.

COST
비용 증가
반복 추론 · tool · retry · context
VALUE
불명확한 ROI
Agent가 아니어도 되는 use case
CONTROL
불충분한 Risk Control
권한 · 감사 · rollback · governance

이건 Agent 자체가 쓸모없다는 이야기가 아니다.

오히려 “Agent를 써야 해서 Agent를 쓰는 프로젝트”와 “Agent가 실제로 문제를 더 잘 푸는 프로젝트”가 분리될 거라는 이야기다.

AGENTWASHING
Chatbot + API 하나 붙였다고 전부 Agent가 되는 것은 아니다.

Gartner는 기존 assistant, RPA, chatbot을 실질적 agentic capability 없이 Agent로 재브랜딩하는 현상을 “agent washing”이라고 지적했다.

04. 그러면 언제 Agent를 써야 할까?

모든 업무를 Agent로 만들 필요는 없다. 오히려 workflow가 확실하면 deterministic automation이 더 싸고 안전할 수 있다.

질문 Agent에 유리 Automation에 유리
경로가 매번 다른가? 상황별 판단 필요 순서가 거의 고정
비정형 정보가 많은가? 문서·메일·자연어 중심 정형 API / rule 중심
판단이 필요한가? context 기반 선택 조건문으로 충분
실패 비용은? 낮고 되돌릴 수 있음 높고 irreversible
내가 보는 Agent Suitability
Need for judgment ↑
Path variability ↑
Unstructured context ↑
Action reversibility ↑
Error impact ↓

이 조합일수록 초기 Agent use case로 좋다.

05. 더 중요한 질문: Agent를 쓸 것인가가 아니라 “어디까지 맡길 것인가”

Gartner가 2026년에 제시한 Agent governance 관점에서 특히 좋았던 부분은 자율성을 하나의 on/off switch로 보지 않았다는 점이다.

LEVEL 1
Observe
Read Only
검색 · 요약 · 지식 조회 · 코드 설명
↓ autonomy
LEVEL 2
Advise
Human Executes
추천 · 초안 · 의사결정 지원 · 제안된 action
↓ autonomy
LEVEL 3
Act with Approval
Write + HITL
메일 전송 · DB 변경 · 설정 변경 — 매 action마다 승인
↓ autonomy
LEVEL 4
Act Autonomously
Guardrailed Write
정해진 guardrail 안에서 사람 승인 없이 action 수행

이것이 금융권에서는 특히 중요하다.

모델 성능이 동일해도 자율성 Level이 올라가면 위험의 종류가 달라진다.

Level 핵심 Risk 필요 Control
Observe Data Exposure · Incorrect Output AuthN · Scoped Read · Logging · Eval
Advise Automation Bias Quality Eval · Human Training · Disclosure
Act + Approval Approval Fatigue · Tool Abuse Meaningful HITL · Audit · Least Privilege
Autonomous Scale / Speed of Wrong Actions Continuous Monitor · Circuit Breaker · Rollback

06. “모든 Agent에 같은 규칙”도 좋은 Governance가 아니다

2026년 Gartner는 더 구체적인 경고를 냈다. 2027년까지 기업의 40%가 governance 실패 때문에 autonomous agent를 강등하거나 폐기할 것이라고 전망했다.

재미있는 건 이유다. 통제가 약해서만 문제가 생기는 게 아니다.

UNDER-GOVERN
너무 많이 맡긴다
권한 과다 · tool abuse · 규제 위반 · operational incident
OVER-GOVERN
아무것도 못 하게 한다
단순 read-only Agent까지 과도한 승인 → 느린 delivery → shadow AI

결국 governance는 binary가 아니라 risk-proportional해야 한다.

Agent가 무엇을 할 수 있는지(capability)와 어디까지 허용받았는지(permission scope)를 분리해서 봐야 한다.

07. Agent Security의 중심도 Prompt에서 Action으로 이동한다

일반적인 Chatbot이라면 prompt injection의 가장 큰 피해는 잘못된 답변이나 정보 유출일 수 있다.

그런데 Agent가 write permission을 가지면 같은 공격이 실제 시스템 행동으로 번진다.

Malicious Document
↓
Indirect Prompt Injection
↓
Agent changes plan
↓
Calls privileged Tool
↓
Data exfiltration / configuration change / unintended action

OWASP의 Agent Security guidance도 prompt injection뿐 아니라 tool abuse, privilege escalation, data exfiltration, memory poisoning을 주요 위험으로 본다.

NIST 역시 2026년 AI Agent identity/authorization 논의에서 Agent가 다양한 데이터와 Tool에 접근하는 만큼 식별, 인증, 권한부여, audit, non-repudiation이 핵심이라고 강조했다.

FINANCE / SECURITY
Agent에게 “권한을 판단할 권한”까지 주면 안 된다.
LLM은 어떤 Tool을 쓰면 좋을지 제안할 수 있다. 하지만 실제 Tool 실행 허용 여부는 deterministic policy engine과 identity context가 결정해야 한다.

08. 그래서 Agent Platform의 핵심은 Model보다 Control Plane일 수 있다

Agentic AI를 production으로 가져가려면 Agent runtime 주변에 꽤 많은 통제 계층이 붙는다.

ENTERPRISE AGENT CONTROL PLANE
User / Application / Business Process
↓
Identity
Who is acting?
Policy
What is allowed?
Budget
How much?
↓
Agent Runtime / Orchestration
Plan · State · Tool · Memory · Retry · HITL
↓
Tool Registry
Scoped APIs
Model Gateway
Routing / Cost
Data Access
RAG / DB
↓
Trace / Eval / Audit
Circuit Breaker / Rollback / Kill Switch

2026년 8월 Gartner가 mission-critical Agent를 위해 coded guardrail을 강조한 것도 같은 맥락이다.

정책을 Word 문서에만 적는 것이 아니라 실제 runtime이 “이 action은 실행할 수 없다”고 강제해야 한다.

09. Agent의 숨은 병목: Intelligence가 아니라 Economics

Agent는 일반 LLM API보다 비용 구조가 복잡하다.

Cost / Task
= Model Calls
+ Reasoning Tokens
+ Retrieval
+ Reranking
+ Tool APIs
+ Sub-agents
+ Retries
+ Evaluation
+ Infrastructure

그리고 중요한 건 한 번의 호출 비용보다 업무 하나를 성공시키는 비용(cost per successful task)이다.

BETTER METRIC
Cost per API Call ✗
Cost per Successful Business Outcome ✓

Agent가 모델 호출을 10번 해서 95% 성공하는 구조와, 2번 호출해서 90% 성공하는 구조 중 무엇이 나은지는 업무의 가치와 실패 비용까지 같이 봐야 한다.

10. 그리고 Agent는 결국 “Context”만큼만 똑똑하다

Gartner가 2026년 별도 리서치에서 강조한 또 하나의 포인트는 Semantics다.

Agent가 기업 데이터를 이해하려면 단순히 Vector DB에 문서를 넣는 것만으로는 부족할 수 있다.

“Policy”는 보험 약관인가, IT 정책인가?
“Customer”는 계약자인가, 피보험자인가?
“Active”는 오늘 기준인가, 계약 효력일 기준인가?
같은 상품명이라도 가입 시점별 약관 version이 다른가?

이런 관계와 business rule이 명확하지 않으면 Agent가 추론을 잘해도 틀린 context 위에서 아주 논리적으로 틀릴 수 있다.

그래서 production Agent의 기반에는 RAG뿐 아니라 metadata, ontology/semantic layer, master data, policy versioning 같은 지루하지만 중요한 data engineering이 같이 붙는다.

11. 금융권이라면 “완전 자율 Agent”가 늦은 게 오히려 정상이다

금융권에서 Agent 도입이 소비자 서비스나 일반 SaaS보다 느리다고 해서 반드시 뒤처진 것은 아니다.

Action의 결과가 금전, 계약, 개인정보, 고객 권리와 연결되면 같은 오류라도 impact가 달라진다.

현실적인 금융권 순서
1. Read-only Agent — 내부 지식 검색, 분석, 요약
2. Advisory Agent — 상담/심사/운영 의사결정 보조
3. HITL Agent — 명시적 승인 후 제한된 action
4. Autonomous Agent — 낮은 위험 · reversible · 좁은 scope부터

예를 들어 고객의 보험금을 자동 지급하는 Agent보다, 먼저 “심사에 필요한 문서를 찾아 요약하고 누락 정보를 알려주는 Agent”가 훨씬 현실적이다.

자율성이 낮다고 기술적으로 덜 Agentic한 것이 아니다. 비즈니스 위험에 맞는 자율성 수준을 선택하는 것 자체가 architecture decision이다.

12. 지금 뭘 해야 하나 — “Agent First”가 아니라 “Control First”

지금 시점에 내가 기업에서 Agentic AI를 준비한다면 우선순위를 이렇게 잡을 것 같다.

1
좁고 측정 가능한 업무부터 선택
Task success를 객관적으로 판단할 수 있어야 한다.
2
Autonomy Level을 먼저 결정
Read-only인지, approval이 필요한지, autonomous write인지.
3
Tool permission과 Agent identity 설계
Least privilege · scoped credential · short-lived token.
4
Trace + Eval + Audit를 같이 설계
무엇을 했는지, 잘했는지, 누가 설정을 바꿨는지.
5
Budget / Rate / Loop limit
무한 reasoning과 runaway tool call을 runtime에서 차단한다.
6
Rollback / Circuit Breaker / Kill Switch
Autonomy가 높아질수록 “멈추는 능력”도 제품 기능이다.

13. Production Gate — 나는 이 질문에 답 못하면 아직 안 올릴 것 같다

□ Agent의 정확한 owner가 누구인가?
□ Agent identity를 다른 service account와 구분할 수 있는가?
□ 어떤 Tool에 어떤 permission이 있는지 목록화되어 있는가?
□ Prompt injection을 받아도 unauthorized action은 막히는가?
□ 모든 write action을 audit할 수 있는가?
□ 중요한 action은 idempotent / reversible한가?
□ 실패 시 rollback 경로가 있는가?
□ Loop / cost / token budget 상한이 있는가?
□ Agent가 “모르겠다”고 멈출 조건이 정의되어 있는가?
□ 모델 / prompt / tool 변경 전 regression eval이 있는가?
□ 운영 중 agent를 즉시 중단할 kill switch가 있는가?

이 질문들이 모델 benchmark보다 덜 화려해서 그렇지, 실제 Production readiness에는 훨씬 중요할 수 있다.

14. Peak에 있다는 건 기다리라는 뜻이 아니다

Hype Cycle을 보고 “그러면 2~3년 기다렸다가 안정되면 시작하지 뭐”라고 해석하는 것도 위험하다.

Agentic AI가 성숙할 때까지 기다렸다가 그제서야 IAM, eval, observability, tool governance, semantic layer를 처음 만드는 조직은 실제 도입 시점에도 준비가 안 되어 있을 가능성이 높다.

MY TAKE
Peak에서 해야 할 일은 “가장 자율적인 Agent를 만드는 것”이 아니다.
“자율성을 안전하게 늘릴 수 있는 기반을 만드는 것”이다.

그래서 금융권처럼 보수적인 조직도 지금 충분히 할 일이 많다.

Narrow Agent
↓
Measure
↓
Control
↓
Expand Permission
↓
Increase Autonomy

자율성은 기능이 아니라 권한이다.

그리고 권한은 성능 benchmark가 조금 좋아졌다고 한 번에 올리는 것이 아니라, 실제 운영 데이터와 control maturity를 증명하면서 단계적으로 올려야 한다.

결국 “우리 Agent가 얼마나 똑똑한가?”보다
“우리는 이 Agent에게 어디까지 맡겨도 되는가?”에 답할 수 있는 조직이
이 Hype Cycle을 가장 잘 통과할 가능성이 높다.


References

written by rubrub · AI / LLM / Agent Engineering