Agentic Cloud란 무엇인가: AI 에이전트 실행 환경의 핵심 개념
AI 에이전트를 처음 쓰면 대화창 하나면 충분해 보입니다. 질문을 던지고, 답을 받고, 코드를 복사하면 됩니다.
하지만 에이전트가 실제 일을 하기 시작하면 이야기가 달라집니다.
에이전트는 파일을 만들어야 합니다. 터미널 명령을 실행해야 합니다. 브라우저로 확인해야 합니다. 로그를 읽고, 테스트를 돌리고, API를 호출하고, 때로는 배포까지 해야 합니다.
그 순간 AI 에이전트에게 필요한 것은 단순한 채팅창이 아니라 자기만의 컴퓨터와 안전한 작업장입니다.
Cloudflare는 2026년 Agents Week 글에서 이 흐름을 agentic cloud라는 말로 설명했습니다. AI 에이전트가 안전하게 일할 sandbox, 권한, 도구, 로그, 배포 경로를 묶은 실행 인프라입니다. 이 글에서는 그 개념을 개인 개발자와 홈서버 운영자 관점으로 풀어봅니다.
출처 확인 기준: 2026-07-01에 Cloudflare, OpenAI, Google 공식 원문 URL을 확인했으며, 제품별 세부 명칭은 발표 시점 기준입니다.
1. 핵심 요약 — 이 글에서 기억할 3가지
Agentic Cloud는 AI 에이전트가 실제 작업을 수행하기 위한 실행 인프라입니다.
이 글의 핵심은 세 가지입니다.
- AI 에이전트는 단순 API 호출자가 아니라 실행 주체가 되고 있습니다. 그래서 shell, filesystem, browser, memory, credential, log가 필요합니다.
- Agentic Cloud는 그 실행 환경을 안전하게 묶는 인프라입니다. 핵심 축은 컴퓨터, 권한, 관측성, 배포 경로입니다.
- 홈서버에서도 작은 Agentic Cloud를 만들 수 있습니다. Proxmox, LXC, Docker, Hermes를 조합하되 격리 강도와 secret 관리를 먼저 설계해야 합니다.
Agentic Cloud는 AI 에이전트를 안전하게 일시키기 위한 컴퓨터, 권한, 관측성, 배포 경로를 묶은 인프라입니다.
2. 왜 에이전트에게 ‘컴퓨터’가 필요한가요?
챗봇은 답변만 하면 됩니다. 하지만 에이전트는 일을 해야 합니다.
예를 들어 “블로그 글을 하나 발행해줘”라는 작업을 생각해봅시다. 제대로 하려면 에이전트는 다음을 해야 합니다.
- 최신 자료를 검색한다.
- 기존 위키나 노트를 읽는다.
- 초안을 작성한다.
- 이미지를 만든다.
- 브라우저에서 화면을 확인한다.
- WordPress API나 WP-CLI로 발행한다.
- Search Console sitemap을 제출한다.
- 결과를 로그로 남긴다.
이건 단순 텍스트 생성이 아닙니다. 작은 작업 환경이 필요합니다.
그래서 에이전트에게 필요한 컴퓨터는 보통 다음 요소를 가집니다.
| 구성요소 | 필요한 이유 |
|---|---|
| Shell | 빌드, 테스트, 배포 명령 실행 |
| Filesystem | 코드, 초안, 로그, 산출물 저장 |
| Browser | UI 검증, 스크린샷, 자동화 |
| Network | API 호출, 패키지 다운로드, 배포 |
| Credential | GitHub, Cloudflare, WordPress 등 권한 사용 |
| Observability | 로그, 메트릭, trace를 읽고 수정 판단 |
| Memory | 이전 작업 맥락과 프로젝트 지식 재사용 |
이 요소를 안전하게 묶은 실행 환경이 Agentic Cloud의 출발점입니다.
3. 기존 클라우드와 무엇이 다른가요?
전통적인 클라우드는 보통 “앱 하나가 여러 사용자 요청을 처리한다”는 모델에 맞춰져 있습니다.
Agentic Cloud는 관점이 다릅니다.
| 구분 | 기존 클라우드 | Agentic Cloud |
|---|---|---|
| 주 workload | 웹앱, API 서버, batch job | 장시간 agent session |
| 실행 단위 | request, container, function | task, workspace, sandbox |
| 사용자 관계 | 앱이 사용자에게 응답 | agent가 사용자 대신 행동 |
| 상태 | DB/캐시 중심 | 파일, 브라우저, 로그, memory, tool state |
| 보안 | service account, IAM | non-human identity, scoped credential, approval |
| 관측성 | 사람이 보는 로그/메트릭 | agent가 읽고 판단할 수 있는 evidence bundle |
기존 클라우드가 필요 없어지는 것은 아닙니다. 다만 AI 에이전트가 늘어나면 그 위에 agent 전용 실행 계층이 필요해집니다.
4. 벤더 사례로 보는 Agentic Cloud 흐름
아래 세 사례는 모두 2026-07-01에 공식 원문 URL을 확인했습니다.
Cloudflare: Agentic Cloud 전면화
Cloudflare는 Agents Week 2026 정리 글에서 agentic cloud를 전면에 내세웠습니다.
핵심 메시지는 이렇습니다.
- Cloudflare는 지식 노동자가 여러 agent를 병렬·상시 실행하면 기존 앱 중심 클라우드와 다른 대규모 동시 session 수요가 생긴다고 설명합니다.
- 에이전트는 compute만이 아니라 security, identity, toolbox, deployment path가 필요하다.
- 에이전트가 만든 코드와 앱은 prototype에서 production으로 갈 수 있어야 한다.
- 에이전트가 인터넷 트래픽의 일부가 되면 웹 자체도 agentic web에 대응해야 한다.
Cloudflare Agents Week 2026 글에서 언급된 구성요소를 단순화하면 다음과 같습니다. 정확한 제품명과 제공 범위는 공식 문서 확인 시점에 따라 달라질 수 있습니다.
| 영역 | 예시 |
|---|---|
| Compute | Sandboxes, Dynamic Workers, durable execution |
| Storage | Git-compatible Artifacts, per-agent workspace |
| Security | egress controls, Mesh, scoped permissions |
| Identity | Managed OAuth, Temporary Accounts |
| Tooling | browser, email, voice, search, memory |
| Governance | Enterprise MCP architecture, Gateway policy |
중요한 점은 이것들이 각각 따로 떨어진 기능이 아니라, agent runtime을 위한 한 묶음이라는 점입니다.
OpenAI: Harness Engineering
OpenAI의 2026-02-11 글 Harness engineering: leveraging Codex in an agent-first world는 “Humans steer. Agents execute.”라는 표현으로 이 변화를 설명합니다. 사람은 방향을 잡고, 에이전트가 실행한다는 뜻입니다.
그런데 에이전트가 실행하려면 환경이 필요합니다. 같은 글에서 OpenAI는 Codex가 UI를 검증할 수 있도록 Chrome DevTools Protocol 기반 브라우저 검증 흐름을 붙이고, 로그·메트릭·트레이스를 agent가 읽을 수 있게 만들었다고 설명합니다.
이건 Agentic Cloud의 개발자 버전입니다.
- 에이전트가 앱을 실행한다.
- 브라우저로 실제 화면을 확인한다.
- 로그와 메트릭을 읽는다.
- 실패를 고친다.
- 다시 테스트한다.
- PR을 만든다.
즉, 좋은 에이전트는 좋은 모델만으로 만들어지지 않습니다. 좋은 실행 환경과 피드백 루프가 필요합니다.
Google: Antigravity CLI 전환
Google Developers Blog는 2026-05-19 글 Transitioning Gemini CLI to Antigravity CLI에서 Gemini CLI와 Gemini Code Assist 개인/무료 흐름을 Antigravity CLI·Antigravity 2.0 쪽으로 전환한다고 안내했습니다. 이 내용은 해당 발표 시점의 제품 전환 안내이며, 실제 지원 범위와 일정은 Google의 최신 문서 확인이 필요합니다. 핵심 이유는 터미널 도구의 역할이 단일 CLI를 넘어 multi-agent platform으로 바뀌었기 때문입니다.
Gemini CLI는 터미널에서 AI agent 작업이 가능하다는 것을 보여줬습니다. 하지만 사용자의 workflow는 더 복잡해졌습니다.
- 여러 agent가 동시에 일해야 합니다.
- 장기 작업을 background로 돌려야 합니다.
- CLI, IDE, desktop app이 같은 backend를 공유해야 합니다.
- hooks, skills, subagents, extensions가 하나의 platform으로 묶여야 합니다.
이 흐름은 Agentic Cloud와 맞닿아 있습니다. 터미널은 여전히 중요하지만, 터미널 하나만으로는 부족합니다. 뒤에는 unified harness와 server-side execution layer가 필요합니다.
5. Agentic Cloud의 핵심 구성요소는 무엇인가요?
Agentic Cloud를 직접 설계한다면 아래 7가지를 기준으로 보면 됩니다. 이 목록은 글 전체의 핵심 점검표입니다.
| 요소 | 한 줄 정의 |
|---|---|
| Sandbox | 에이전트 작업을 격리하는 임시 컴퓨터 |
| Egress Control | 외부 네트워크로 나가는 통로를 제한하는 정책 |
| Credential Broker | 장기 secret 대신 짧은 권한을 발급하는 중간 계층 |
| Tool Registry | 에이전트가 호출할 수 있는 도구 목록과 정책 |
| Observability | 로그·스크린샷·trace를 agent가 읽기 좋게 묶은 증거 |
| Durable Execution | 오래 걸리는 작업을 재개·취소·복구하는 실행 모델 |
| Human Approval | 위험 행동 앞에서 사람 승인을 요구하는 게이트 |
5-1. Sandbox란 무엇인가요?
Sandbox는 에이전트가 작업할 격리된 임시 컴퓨터입니다. 예를 들어 의심스러운 dependency를 설치하거나 테스트를 돌릴 때, 내 홈 디렉터리와 production token을 그대로 노출하지 않는 역할을 합니다.
- 파일 시스템 격리
- 프로세스 격리
- 패키지 설치 가능
- 작업 종료 후 폐기 또는 snapshot
- production secret 미포함
5-2. Egress Control이란 무엇인가요?
Egress control은 에이전트의 외부 네트워크 통로를 제한하는 정책입니다. 예를 들어 새 도메인으로 HTTP 요청을 보내기 전에 차단하거나 승인받게 만들 수 있습니다. 다만 npm, PyPI, GitHub, CDN, OAuth redirect처럼 정상 작업에도 동적 도메인이 많아 운영 비용이 생깁니다. 도메인 기반 allowlist만으로는 IP 직접 접속, 터널링, 도메인 프론팅류 우회를 완전히 막기 어렵다는 한계도 있습니다.
- 기본 차단
- 도메인 allowlist
- HTTP proxy
- secret redaction
- 새 도메인 승인
5-3. Credential Broker란 무엇인가요?
Credential broker는 장기 secret 대신 짧은 권한을 발급하는 중간 계층입니다. 예를 들어 전체 Cloudflare token 대신 특정 작업에만 쓰이는 임시 token을 짧게 발급합니다. 임시 token도 유효 시간 안에 탈취되면 오용될 수 있으므로 만료 시간, 범위 제한, 작업·세션 binding, append-only 감사 로그, broker 자체의 최소 권한이 필요합니다.
- 임시 token 발급
- 권한 범위 제한
- 만료 시간 설정
- 사용 로그 기록
- 작업 후 회수
5-4. Tool Registry란 무엇인가요?
Tool registry는 에이전트가 호출할 수 있는 도구 목록과 정책입니다. 예를 들어 WordPress 발행 도구, 브라우저 검증 도구, GitHub API, MCP 서버를 역할별로 등록하고 승인 조건을 붙일 수 있습니다.
- MCP 서버
- CLI 명령
- browser tool
- API connector
- internal script
중요한 것은 “많이 연결하기”가 아니라 “필요한 도구만 명확하게 연결하기”입니다. MCP/tool registry는 공급망 위험도 가집니다. 신뢰할 수 없는 MCP 서버나 prompt injection에 취약한 tool description은 sandbox 안에서도 임시 토큰을 오용할 수 있습니다. 신뢰 도구가 반환한 웹페이지·파일 내용이 agent 지시문처럼 섞이는 간접 프롬프트 인젝션도 별도로 봐야 합니다.
5-5. Observability란 무엇인가요?
Observability는 에이전트가 읽을 수 있는 증거 묶음입니다. 사람이 읽는 긴 로그 파일을 그대로 던지는 것보다, 실패한 테스트·스크린샷·핵심 trace를 구조화해 주는 쪽이 agent 판단에 유리합니다.
- stdout/stderr
- application log
- browser screenshot
- DOM snapshot
- metrics
- traces
- test report
사람이 보는 로그와 agent가 판단하기 좋은 evidence bundle은 다릅니다. 에이전트가 읽을 수 있도록 구조화해야 합니다.
5-6. Durable Execution이란 무엇인가요?
에이전트 작업은 한 번에 끝나지 않을 수 있습니다.
- 장시간 refactor
- 대량 테스트
- 크롤링/리서치
- PR 리뷰 반복
- 배포 후 모니터링
따라서 background 실행, checkpoint, resume, cancel, rollback이 필요합니다. 다만 checkpoint 재개는 같은 작업을 두 번 실행하는 중복 side effect를 만들 수 있습니다. 결제, 배포, DB write처럼 멱등성이 약한 작업은 idempotency key와 외부 상태 확인을 붙여야 합니다.
5-7. Human Approval은 어디에 필요한가요?
위험한 행동은 사람이 승인해야 합니다.
- 결제
- 삭제
- production 배포
- DB write
- secret 접근
- 외부 데이터 전송
Agentic Cloud는 자동화를 늘리는 시스템이지만, 동시에 어디서 멈춰야 하는지도 알아야 합니다. 다만 approval gate가 너무 많으면 승인 대기와 승인 피로가 생깁니다. 그래서 삭제·배포·결제·secret 접근처럼 피해가 큰 행동에 집중하는 편이 현실적입니다. background/cron agent는 승인 대기 때문에 장시간 멈출 수 있으므로, 승인 만료와 자동 중단 정책도 필요합니다.
6. 홈서버에서 만드는 작은 Agentic Cloud
대규모 Cloudflare 플랫폼이 없어도, 개인 홈서버에서 작은 Agentic Cloud를 만들 수 있습니다.
예를 들어 TH님 같은 홈랩 환경에서는 이런 구조가 가능합니다.
Proxmox Host
├─ LXC: Hermes Agent
│ ├─ Telegram gateway
│ ├─ cron jobs
│ ├─ skills
│ └─ browser automation
├─ LXC: WordPress
├─ VM/LXC: Agent sandbox
│ ├─ disposable workspace
│ ├─ restricted network
│ └─ no production secrets by default
└─ OPNsense / Firewall
└─ outbound policy, DNS log, allowlist
여기서 핵심은 agent별로 권한과 작업공간을 나누는 것입니다.
운영 트레이드오프도 있습니다.
- 격리 강도: LXC는 가볍지만 VM보다 격리 강도가 낮고 커널 공유에 따른 컨테이너 탈출 위험을 고려해야 합니다. 더 강한 격리가 필요하면 VM, gVisor, Kata Containers를 검토할 수 있지만 시스템콜 호환성, GPU·디바이스 접근, 성능 비용을 함께 봐야 합니다.
- 재생성 비용: sandbox를 매번 새로 만들면 안전성은 올라가지만 콜드스타트, 패키지 설치, 디스크 스냅샷, 메모리 사용량이 늘어납니다.
- broker 단일 실패점: credential broker는 secret 노출을 줄이지만 broker 자체가 단일 실패점이 될 수 있습니다.
- redaction: observability evidence bundle에도 secret·PII redaction이 필요합니다. 브라우저 자동화는 Chromium/Playwright
--no-sandbox, GPU·디바이스 접근 권한 때문에 별도 프로파일이나 전용 컨테이너로 분리하는 편이 안전합니다.
개인용 최소 구현은 이렇게 시작할 수 있습니다.
- agent 전용 Linux 사용자 또는 LXC를 만든다.
- 작업 디렉터리를 분리한다.
- production
.env를 기본 mount하지 않는다. - 외부 네트워크는 필요한 도메인만 허용한다.
- 브라우저 자동화는 별도 profile로 실행한다.
- tool call log와 shell output을 저장한다.
- 배포·삭제·결제는 수동 승인한다.
7. Hermes 운영과 연결하면 어떻게 보이나요?
Hermes는 제가 홈서버에서 운영하는 다중 프로파일 에이전트 환경입니다. 이 섹션은 초심자가 반드시 따라 할 부분이라기보다, 개인 홈서버에 Agentic Cloud 원칙을 적용한 예시로 보면 됩니다.
Hermes 같은 multi-profile agent 환경은 개인 Agentic Cloud의 좋은 예가 될 수 있습니다.
- PM/default profile은 총괄과 routing을 담당합니다.
- dev/researcher/media/curator profile은 역할별 agent worker가 됩니다.
- skills는 반복 업무의 tool registry이자 runbook입니다.
- cron은 durable/background execution입니다.
- browser automation은 UI 검증 도구입니다.
- Home Assistant/Telegram/WordPress/GSC 연동은 실제 tool surface입니다.
- Kanban은 human approval과 work tracking 계층이 됩니다.
이렇게 보면 Agentic Cloud는 먼 미래의 클라우드 용어가 아닙니다. 이미 개인 자동화 환경에서도 비슷한 구조가 필요합니다.
8. 도입 전 체크리스트
Agentic Cloud를 구축하거나 관련 서비스를 선택할 때 확인할 질문들입니다.
- [ ] 에이전트별 sandbox가 있는가?
- [ ] 작업이 끝난 뒤 workspace를 폐기하거나 snapshot할 수 있는가?
- [ ] 장기 secret 없이 임시 credential로 작업할 수 있는가?
- [ ] 외부 네트워크 egress 정책이 있는가?
- [ ] MCP/tool registry를 검토할 수 있는가?
- [ ] 브라우저/CLI 실행 결과를 agent와 사람이 함께 볼 수 있는가?
- [ ] 실패한 작업을 resume/cancel/rollback할 수 있고, 외부 API에는 idempotency key나 상태 확인을 쓰는가?
- [ ] 위험한 행동에 human approval gate가 있는가?
- [ ] 로그가 agent transcript와 tool call 단위로 남는가?
- [ ] 비용과 quota를 agent별로 제한할 수 있는가?
9. FAQ
Agentic Cloud는 그냥 서버리스 아닌가요?
서버리스는 주로 짧은 request/function 실행에 맞춰져 있습니다. Agentic Cloud는 장시간 작업, 파일 상태, 브라우저, 도구 호출, credential, approval, observability까지 함께 봅니다.
개인 개발자에게도 필요한가요?
필요합니다. 규모는 작아도 agent가 shell과 secret과 network를 함께 가진다면 같은 문제가 생깁니다. Docker/LXC 하나로 시작해도 충분히 의미가 있습니다.
클라우드 서비스를 써야 하나요?
Cloudflare 같은 플랫폼은 managed path를 제공하지만, 홈서버에서는 Proxmox/LXC/Docker/OPNsense/Hermes 조합으로 일부 원칙을 구현할 수 있습니다.
가장 먼저 만들 것은 무엇인가요?
agent 전용 sandbox입니다. 그다음 egress allowlist와 secret 분리를 붙이면 됩니다.
10. 마무리 — 에이전트 시대의 인프라는 작업장을 설계하는 일
AI 에이전트가 발전할수록 “모델이 얼마나 똑똑한가”만으로는 부족합니다. 실제 일을 하려면 작업장이 필요합니다.
그 작업장은 안전해야 합니다. 관측 가능해야 합니다. 실패하면 되돌릴 수 있어야 합니다. 그리고 사람이 승인해야 할 지점에서는 멈출 줄 알아야 합니다.
Agentic Cloud는 결국 이런 질문에 대한 답입니다.
AI 에이전트가 마음껏 일하되, 사고는 치지 않게 하려면 어떤 컴퓨터와 규칙이 필요한가?
개인 개발자라면 거창하게 시작할 필요는 없습니다. 작은 sandbox 하나, 제한된 token 하나, 로그 하나부터 시작하면 됩니다.
함께 읽으면 좋은 글
- MCP 보안 가이드: AI 에이전트 도구 연결의 위험과 방어법 — Agentic Cloud의 실행 환경을 설계할 때 가장 먼저 확인해야 할 도구 연결 보안 체크리스트입니다.
- Hermes Agent와 LLM Wiki로 AI 비서 장기 기억 설계하기 — 개인 홈서버에서 여러 에이전트와 장기 기억을 운영하는 실제 구조를 함께 볼 수 있습니다.
- Obsidian LLM Wiki란? — AI 에이전트에게 장기기억을 주는 가장 현실적인 방법 — 에이전트 실행 환경에 붙일 지식 저장소를 설계할 때 참고하기 좋습니다.
문서 메타데이터
- 작성자: welltip.org
- 발행 예정일: 2026-07-01
- 최종 수정일: 2026-07-01
- 예상 canonical URL: https://blog.welltip.org/ai/agentic-cloud-ai-agents/
- 주요 인용 출처: Cloudflare Agents Week 2026, OpenAI Codex Harness Engineering, Google Developers Blog Antigravity CLI 전환 안내
참고 자료
- Cloudflare, Building the agentic cloud: everything we launched during Agents Week 2026
- OpenAI, Harness engineering: leveraging Codex in an agent-first world
- Google Developers Blog, Transitioning Gemini CLI to Antigravity CLI
