7부. Delivery company, control plane, agent-readable SSOT

24장. Agent sprawl 이후에는 control plane이 필요하다

에이전트 컴퍼니 v0.4.0

에이전트는 쉽게 늘어난다.

Copilot 안의 agent, Teams 안의 agent, Claude Code, OpenClaw, SaaS agent, local assistant, cloud agent, 부서별 custom agent, 외주사가 만든 agent. 처음에는 생산성처럼 보이지만, 곧 sprawl이 된다.

누가 어떤 agent를 만들었는가.

그 agent는 어디서 도는가.

어떤 credential을 쓰는가.

어떤 MCP server와 연결돼 있는가.

어떤 파일과 SaaS와 cloud resource에 접근할 수 있는가.

무슨 행동을 했고, 비용은 얼마였고, 실패하면 누가 책임지는가.

Microsoft Agent 365는 이 문제를 control plane으로 잡는다. 목적은 agent를 observe, govern, secure하는 것이다. delegated access agent뿐 아니라 own credential로 뒤에서 도는 agent, team workflow에 참여하는 agent, local agent, cloud-hosted agent, SaaS agent까지 inventory와 governance 안으로 넣으려 한다.

이것은 11장의 권한/게이트/책임을 enterprise scale로 확장한 것이다.

Control plane 기능
Registry
필요한 이유
agent inventory, owner, scope 관리
Control plane 기능
Discovery
필요한 이유
shadow AI와 unmanaged local/cloud agent 찾기
Control plane 기능
Identity mapping
필요한 이유
agent가 어떤 identity와 credential로 행동하는지 확인
Control plane 기능
MCP/resource mapping
필요한 이유
agent가 어떤 tool, server, cloud resource에 닿는지 확인
Control plane 기능
Policy control
필요한 이유
허용/차단/least privilege 적용
Control plane 기능
Runtime monitoring
필요한 이유
악성 행동, oversharing, exfiltration 시도 감지
Control plane 기능
Audit evidence
필요한 이유
compliance와 사고 대응을 위한 trace 확보

Agent-run company는 agent가 많은 회사가 아니다.

Agent가 많은데도 통제 가능한 회사다.

Early Reader Feedback

원고 피드백 남기기

읽다가 헷갈린 곳, 더 듣고 싶은 사례, 동의하기 어려운 문장을 알려주세요. 공개 댓글이 아니라 저자에게만 전달되는 피드백입니다.

본문에서 문장을 드래그한 뒤 누르면 선택 문장이 함께 저장됩니다.

피드백 유형

BiteMark Press는 Cloudflare Web Analytics로 익명 트래픽을 보고, 동의한 경우에만 GA4와 Microsoft Clarity를 켭니다.