들어가며
2026년 4월까지의 AI 에이전트는 "병렬화"가 키워드였습니다. Claude Code Agent Teams, OpenAI Swarm 2, LangGraph 0.4 같은 프레임워크가 동시에 "여러 에이전트를 한꺼번에 굴리는 법"에 답을 내놨죠. 그런데 막상 프로덕션에 올려보니 새로운 한계가 드러났습니다.
"병렬로 굴리는 건 됐는데, 24시간 동안 자율적으로 일하게 두면 비용 폭주·메모리 망각·다른 회사 에이전트와 협업 불가 같은 문제가 터진다"는 겁니다. 4월에 Uber $3.4B 예산 소진 사고를 봤던 그 패턴이 정확히 이 한계입니다.
2026년 5월 현재, 이 4가지 한계를 직접 겨냥한 트렌드들이 동시다발적으로 떠오르고 있습니다. 오늘은 실무에서 곧 부딪힐 다섯 가지 신규 흐름 — 장기 자율 실행, A2A 프로토콜, 영구 메모리 레이어, 비용 자가 관리, Computer Use 표준화 — 를 정리합니다. 각 트렌드별로 "왜 떠오르는가", "무엇을 풀어주는가", "언제 도입할지"의 세 축으로 봅니다.
1. 트렌드 #1 - 장기 자율 실행 (Long-running Agents)
지금까지 Claude Code, Cursor, Codex 같은 도구는 "한 번 호출하면 한 번 응답"하는 단발성 세션이 기본이었습니다. 이걸 수 시간~수 일 단위로 늘리는 흐름이 본격화되고 있습니다.
대표 사례
- Claude Code Long Sessions: v2.2 베타에서 12시간+ 백그라운드 실행 지원. 자동 컨텍스트 압축으로 토큰 한계 돌파.
- Devin Async Mode: 작업을 던져두면 PR 생성까지 비동기로. 사용자는 다른 일.
- OpenAI Codex Agents: 4월 업데이트로 "Codex 24h" 모드 발표. Codex 4월 업데이트 정리에 잠깐 언급됐던 그 기능이 이제 GA.
기술적 핵심
| 요소 | 해결 방식 |
|---|---|
| 컨텍스트 한계 | 주기적 자동 요약 + 영구 메모리 레이어 (트렌드 #3과 연결) |
| 중간 실패 복구 | checkpoint 저장 → 마지막 성공 지점부터 재개 |
| 사용자 부재 시 결정 | 위험도 기반 게이트: 저위험은 자율, 고위험은 알림 후 대기 |
| 비용 폭주 방지 | token budget + 시간당 한도 + 이상 패턴 감지 (트렌드 #4) |
도입 판단 기준
- 한 작업이 2시간 이상 걸리는 패턴이 주기적으로 반복되는가?
- 사용자 응답을 기다리지 않고 진행 가능한 "검증된 자율 결정" 영역이 명확한가?
- 실패 시 롤백 가능한 작업 단위로 쪼갤 수 있는가?
3가지 모두 YES일 때만 가치가 있습니다. 그렇지 않으면 단순히 비용만 늘고 사고만 잦아집니다.
2. 트렌드 #2 - A2A 프로토콜 (Agent-to-Agent)
지금까지 에이전트는 "사람과 대화" 또는 "한 회사 내부 에이전트끼리"만 협업했습니다. 회사 A의 에이전트가 회사 B의 에이전트와 직접 통신하는 표준이 본격화되는 게 5월의 큰 흐름입니다.
왜 지금 떠오르나
MCP가 "AI ↔ 시스템" 연결을 표준화했다면, A2A는 "AI ↔ AI" 연결을 표준화합니다. 4월에 사내 MCP 서버 구축이 일반화되면서 자연스럽게 다음 단계로 넘어가고 있는 겁니다.
핵심 사양 (드래프트 단계)
# A2A 메시지 포맷 (예시)
{
"version": "a2a/0.2",
"sender": {
"agent_id": "company-a/order-bot",
"capability_card": "https://company-a.com/.well-known/a2a.json"
},
"receiver": {
"agent_id": "company-b/inventory-bot"
},
"intent": "check_stock_availability",
"params": {
"sku": "WIDGET-01",
"quantity": 100
},
"auth": {
"type": "oauth2",
"token": "..."
},
"trace_id": "01HX9YZ..."
}A2A가 풀어주는 것
- B2B 자동화: 발주 시스템이 공급사 시스템에 자동 재고 확인 → 주문 → 결제까지 사람 없이 협상
- 크로스 플랫폼 협업: Slack 봇 ↔ Notion 봇 ↔ GitHub 봇이 사용자 한 명 거치지 않고 직접 협의
- 표준 인증: OAuth2 기반 권한 위임으로 "어떤 에이전트가 어디까지 할 수 있는가" 명확화
위험 요소
에이전트끼리 자율적으로 거래/결정하면 책임 소재가 모호해집니다. "우리 에이전트가 상대 에이전트의 거짓말에 속아 잘못 발주했다" 같은 사고가 가능. 4월에 정리한 LLM 가드레일이 "내 에이전트가 외부에 보내는 메시지" 영역으로 확장돼야 합니다.
3. 트렌드 #3 - 영구 메모리 레이어 (Persistent Memory)
대화 끝나면 잊어버리는 에이전트의 한계를 푸는 흐름입니다. 컨텍스트 윈도우가 1M 토큰이 되어도, 매번 전체를 로드하면 비용이 천문학적이죠. 영구 메모리 레이어는 "필요할 때만 관련 기억을 꺼내 쓰는" 구조입니다.
대표 솔루션
| 제품 | 특징 |
|---|---|
| Mem0 | 벡터 + 그래프 하이브리드. 사용자별/세션별/조직별 분리 기억 |
| Letta (구 MemGPT) | OS 페이징처럼 컨텍스트 in/out. 장기 작업에 강점 |
| Claude Memory | Anthropic 내장 메모리. 사용자 동의 기반 자동 학습 |
| OpenAI Memory v3 | 4월 업데이트로 워크스페이스 단위 공유 메모리 지원 |
실무 도입 패턴
# 영구 메모리를 쓰는 에이전트 의사 코드
class DevAssistantAgent:
def __init__(self, user_id):
self.memory = Mem0(user_id=user_id)
def respond(self, message):
# 1. 관련 기억 검색 (의미 기반)
relevant = self.memory.search(message, top_k=5)
# 2. 컨텍스트에 주입
context = self.build_context(relevant)
# 3. LLM 호출
response = self.llm.complete(message, context)
# 4. 새 기억 저장 (자동 분류 - 사용자 선호 / 사실 / 작업 이력)
self.memory.add(
content=f"{message} → {response}",
category=self.memory.classify(message)
)
return response주의점
- 잘못된 기억의 영구화: 한 번 잘못 학습된 사실이 반복 인용되며 굳어짐. LLM-as-Judge로 메모리 품질을 주기적으로 검증해야 함
- 개인정보: 메모리에 PII가 쌓이면 GDPR 삭제권 대응이 까다로움. 카테고리별 자동 만료 정책 필수
- 워크스페이스 분리: 사용자 A의 코드 컨텍스트가 사용자 B에게 노출되면 정보 유출. 멀티테넌트 격리 검증 필요
4. 트렌드 #4 - 비용 자가 관리 (Cost-aware Self-throttling)
장기 실행과 영구 메모리가 결합되면 비용이 사일런트하게 폭주합니다. 이를 막기 위해 에이전트가 자기 비용을 인지하고 스스로 조절하는 패턴이 표준화되고 있습니다.
왜 자가 관리인가
외부 모니터링만으로는 한계가 있습니다. 에이전트가 어떤 결정의 비용·가치를 가장 잘 알고, 동적으로 "비싼 모델 → 싼 모델", "긴 추론 → 짧은 추론"으로 전환할 수 있어야 효율적입니다.
핵심 패턴 3가지
- 모델 캐스케이드: 단순 분류는 Haiku, 복잡 추론은 Opus. 에이전트가 작업 난이도를 먼저 판정 후 모델 선택
- 예산 인지 결정: 남은 예산이 적으면 자율적으로 "덜 정밀한 답"으로 내려가거나 사용자에게 결정 위임
- 캐시 우선: 같은 질의는 캐시 히트 우선, 캐시 미스 시에만 LLM 호출
실전 코드 (의사 코드)
class CostAwareAgent:
def __init__(self, daily_budget_usd=50):
self.budget = daily_budget_usd
self.spent = self.fetch_today_spent()
def select_model(self, task_complexity):
remaining = self.budget - self.spent
budget_pressure = self.spent / self.budget
# 예산 80% 이상 소진 → 무조건 저비용 모델
if budget_pressure > 0.8:
return "haiku-4.5"
# 작업 복잡도 기반 선택
if task_complexity < 0.3:
return "haiku-4.5" # 단순
elif task_complexity < 0.7:
return "sonnet-4.6" # 보통
else:
return "opus-4.7" # 복잡
def execute(self, task):
complexity = self.estimate_complexity(task)
model = self.select_model(complexity)
# 캐시 우선
cached = self.cache.get(self.task_hash(task))
if cached:
return cached
result = self.llm(model).run(task)
self.cache.set(self.task_hash(task), result, ttl=3600)
self.spent += self.estimate_cost(model, result)
return result예산 위반 시 동작 정책
- 경고 단계 (50% 소진): 모델을 한 단계 다운그레이드
- 하드 게이트 (80% 소진): 신규 task는 사용자 승인 대기 큐에 적재
- 긴급 정지 (100% 소진): 모든 신규 호출 차단, 대시보드 알림
자가 관리는 외부 모니터링을 대체하는 게 아니라 보완합니다. 둘이 함께 있어야 사고를 막습니다.
5. 트렌드 #5 - Computer Use 표준화
2024년 말 Anthropic이 처음 공개했던 Computer Use가 1년 반의 안정화를 거쳐 실무 적용 단계에 들어왔습니다. 5월의 변화는 "실험 → 표준"입니다.
달라진 점
| 항목 | 2024 초기 | 2026 5월 |
|---|---|---|
| 지연시간 | 스크린샷당 3~5초 | 1초 이내 (스트림 기반) |
| 정확도 | 좌표 미스 빈번 | DOM/접근성 트리 보조로 안정 |
| 샌드박싱 | 가상머신 권장 | OS 수준 권한 격리 표준 |
| 오디트 로그 | 비디오 녹화 부담 | 액션 단위 구조화 로그 |
| 레거시 SaaS | 실험적 | 주류 ERP/CRM 자동화 사례 누적 |
실전 활용 시나리오
- 레거시 백오피스 자동화: API가 없는 사내 ERP에 사용자처럼 로그인해서 데이터 입력/추출
- 웹 데이터 수집: API 미제공 사이트 정기 모니터링 (단, 약관/저작권 검토 필수)
- 크로스 시스템 워크플로우: "Salesforce에서 리드 보고 → Notion에 요약 정리 → Slack에 공유"를 사람 클릭 없이
- QA 자동화: 사람이 작성한 테스트 시나리오를 그대로 실행해 회귀 검증
위험 관리
Computer Use는 가장 사고 가능성이 큰 영역입니다. 화면 보고 클릭하니 어디든 갈 수 있죠. 4월 정리한 AI 에이전트 방어선 구축이 그대로 적용됩니다. 추가로:
- 금융/결제 화면은 항상 사람 승인 게이트
- 관리자 권한 OS에서는 절대 실행 금지 (전용 저권한 계정 + 격리 가상머신)
- 스크린샷에 PII가 잡힐 가능성 → 로그 보관 정책에 마스킹 단계 포함
6. 다섯 트렌드의 상호 의존성
이 다섯 트렌드는 독립적이지 않습니다. 서로를 강하게 끌어당깁니다.
장기 자율 실행 ──── 영구 메모리 (긴 작업의 컨텍스트 보존)
│ │
└────► 비용 자가 관리 (장기 실행 비용 폭주 방지)
│
└────► A2A (외부 에이전트 호출 비용도 관리)
│
└────► Computer Use (외부 시스템과 직접 상호작용)예: "24시간 자율 발주 에이전트"를 만들려면, 장기 실행 + 영구 메모리(과거 발주 이력) + 비용 자가 관리(LLM·외부 결제) + A2A(공급사 에이전트와 거래) + Computer Use(레거시 ERP 입력) 다섯 개가 모두 필요합니다.
7. 도입 우선순위 - 무엇부터 시작할까
다섯 트렌드 모두를 한 번에 도입하는 건 비현실적입니다. 단계적 도입 추천 순서.
| 단계 | 우선순위 | 이유 |
|---|---|---|
| 1단계 | 비용 자가 관리 | 다른 트렌드 도입의 "안전망". 먼저 깔아두지 않으면 나머지 도입 시 사고 직결 |
| 2단계 | 영구 메모리 (작은 범위) | 사용자 선호 학습부터. 도메인 지식 누적은 그 다음 |
| 3단계 | 장기 자율 실행 | 1·2단계 안전판이 검증된 후. 작은 작업 (1시간 이내)부터 |
| 4단계 | Computer Use (격리) | 레거시 자동화 ROI가 명확한 영역만. 격리 환경 필수 |
| 5단계 | A2A | 표준이 더 안정화된 후. 내부 시스템 자동화가 충분히 성숙해졌을 때 |
스타트업 vs 엔터프라이즈
- 스타트업: 1·2·3을 빠르게. Computer Use는 기존 SaaS API 부재 영역에만 핀포인트로
- 엔터프라이즈: 1을 6개월 이상 안정화. 그 후 영역별 PoC. A2A는 컴플라이언스 정비 후 1년 시야
8. 안 쓰는 게 나은 경우
모든 워크플로우에 에이전트를 박을 필요는 없습니다. 다음 경우는 명시적으로 "안 한다"가 정답.
- 결정의 결과가 비가역: 자동 송금, 데이터 파괴적 마이그레이션, 외부 발신 (메일·SNS)은 사람 승인 유지
- 저빈도 고난도: 1년에 몇 번 하는 복잡한 작업은 LLM 학습 데이터 부족. 사람이 더 빠름
- 법규/감사가 엄격: 의료 진단·법률 판단·세무 등은 책임 소재 명확화가 우선
- 단순 자동화로 충분: cron + bash 스크립트로 풀리는 걸 굳이 LLM으로 부풀릴 이유 없음
마치며
2026년 5월의 AI 에이전트 5대 트렌드를 정리하면 이렇습니다.
- 장기 자율 실행은 "비용·복구 설계가 선행"되어야 의미가 있다. 12시간 돌아가는 에이전트는 인간이 잘 시간에 사고를 칠 수 있고, checkpoint와 budget 가드 없이 도입하면 첫 사고로 ROI가 날아갑니다.
- A2A는 MCP의 자연스러운 다음 단계. "AI ↔ 시스템"을 푼 다음에는 "AI ↔ AI"가 필연. 다만 표준 안정화까지는 1년 이상 시야로 보고, 지금은 사양 추적만 하면서 내부 자동화에 집중.
- 영구 메모리는 "무엇을 잊을지" 설계가 핵심. 무한히 쌓는 게 능사가 아닙니다. 카테고리별 만료 정책, PII 자동 삭제, 잘못된 기억 검증이 도입 전제.
- 비용 자가 관리는 다른 모든 트렌드의 안전판. 가장 먼저 도입해야 할 한 가지가 있다면 이것. 외부 모니터링과 자가 관리는 둘 다 필요합니다.
- Computer Use는 "API 없는 영역"에만 핀포인트로. 만능 자동화 도구가 아니라 마지막 수단. 격리·감사·승인 게이트 없이 돌리면 가장 큰 사고가 터지는 영역입니다.
다섯 트렌드 모두 "기술적으로 가능하다"와 "실무에 안전하게 도입할 수 있다" 사이의 거리가 깁니다. 방어선 구축·LLM-as-Judge·가드레일·중앙 MCP 가드레일 같은 4월의 "방어선 트랙"이 결국 이 5월 트렌드들의 도입 속도를 결정합니다. 다음 글에서는 이 다섯 트렌드 중 가장 실무 적용이 빠른 "비용 자가 관리" 패턴을 Spring Boot + Resilience4j 조합으로 실제 구현해 볼 예정입니다.