Ch15. Migration과 Governance
기존 에이전트와 자동화 시스템을 Eve로 전환하고 운영 거버넌스를 세우는 방법을 정리한다.
핵심 요약
- 기존 에이전트 마이그레이션은 코드 포팅이 아니라 capability를 Eve의 파일 슬롯과 durable runtime으로 다시 쪼개는 작업입니다.
- prompts, tools, long procedures, cron jobs, memory, approvals를 Eve 표면에 맞추고 각각에 소유자와 gate를 붙입니다.
- 운영 거버넌스는 CODEOWNERS, PR checklist, release policy, data governance를 에이전트별로 강제할 때 비로소 효과가 납니다.
기존 에이전트를 Eve로 옮길 때 목표는 코드를 그대로 포팅하는 게 아닙니다. 기존 capability를 Eve의 파일 슬롯, durable session, sandbox, approval, eval 구조로 다시 쪼개는 것입니다.
마이그레이션 지도
| 기존 구성 | Eve 표면 |
|---|---|
| system prompt | instructions.md 또는 instructions.ts |
| 긴 작업 절차 | skills/<name>/SKILL.md |
| function calling | tools/<name>.ts |
| external API plugin | connections/ 또는 custom tool |
| memory object | defineState 또는 external DB |
| cron job | schedules/ |
| webhook endpoint | channels/ |
| child agent | subagents/ 또는 defineRemoteAgent |
| code execution | sandbox/ + built-in tools |
| test prompts | evals/*.eval.ts |
이 매핑을 먼저 만들고 그다음에 구현합니다.
단계별 전환
1. Capability inventory
기존 agent가 할 수 있는 일을 모두 추려 나눕니다.
| 분류 | 예 |
|---|---|
| read | CRM 조회, 문서 검색, warehouse query |
| write | ticket 생성, 환불, 이메일 발송 |
| compute | 코드 실행, report 생성 |
| memory | 사용자 선호, 진행 상태 |
| delivery | Slack/웹/이메일 응답 |
| background | 정기 점검, batch job |
각 capability에 owner, data classification, approval requirement, audit requirement를 붙입니다.
2. Prompt decomposition
기존 긴 prompt를 다음으로 나눕니다.
| 부분 | 이동 |
|---|---|
| 정체성/안전 원칙 | instructions.md |
| 업무별 절차 | skills/ |
| 팀/테넌트 정책 | dynamic instructions/skills |
| tool 사용 방법 | tool description + skill |
| 금지 규칙 | instructions + eval |
3. Tool hardening
기존 function call을 defineTool로 옮길 때는 그대로 포팅하면 안 됩니다.
필수 보강:
- Zod/Standard Schema input validation
toModelOutputredaction- idempotency key
needsApproval- auth scope
- error shape
- eval
4. Runtime split
기존 agent가 shell, file, browser, script를 직접 실행했다면 Eve sandbox로 떼어냅니다. app runtime에는 secret이 필요한 tool만 남깁니다.
5. Eval baseline
마이그레이션 전후 결과가 똑같을 필요는 없습니다. 다만 핵심 계약만큼은 eval로 고정합니다.
| Baseline | 예 |
|---|---|
| 성공 경로 | 주요 업무 10개 |
| 금지 경로 | 위험 action 10개 |
| 권한 경로 | tenant/user auth case |
| 회귀 경로 | 과거 production incident |
Governance 모델
Eve agent 운영에는 최소 네 역할이 필요합니다.
| 역할 | 책임 |
|---|---|
| Agent owner | 목적, scope, business KPI |
| Platform owner | deployment, sandbox, auth, observability |
| Security reviewer | tools, connections, data flow, approval |
| Eval owner | regression suite, dataset, release gate |
소규모 팀에서는 한 사람이 여러 역할을 맡아도 되지만 책임은 따로 떼어 기록해 둡니다.
CODEOWNERS 예시
agent/tools/ @security-team @platform-team
agent/connections/ @security-team @data-platform
agent/channels/ @platform-team @security-team
agent/sandbox/ @platform-team @security-team
agent/subagents/ @agent-platform
agent/skills/ @domain-owners
evals/ @eval-owner @agent-owner파일시스템 우선 구조는 CODEOWNERS와 잘 맞습니다.
PR 체크리스트
| 변경 | 필수 리뷰 |
|---|---|
instructions.md | prompt behavior, safety eval |
skills/** | source/version, prompt injection risk |
tools/** | schema, auth, approval, idempotency |
connections/** | token scope, allow-list, approval |
channels/** | route auth, signature, session ACL |
sandbox/** | network, secrets, retention |
subagents/** | 권한 축소/확대 여부 |
evals/** | coverage와 flake risk |
Release 정책
| 릴리즈 유형 | 게이트 |
|---|---|
| prompt-only | core eval + negative eval |
| tool 추가 | security review + tool eval |
| connection 추가 | data flow review + auth eval |
| model 변경 | full eval + cost snapshot |
| channel auth 변경 | auth/ACL integration test |
| sandbox 변경 | sandbox smoke + network policy test |
| Eve version upgrade | manifest/durable session change review |
Data governance
Eve agent에는 다음 데이터 경로가 생길 수 있습니다.
- inbound channel data
- model provider 또는 AI Gateway
- app runtime tools
- connections/MCP/OpenAPI servers
- sandbox network egress
- telemetry exporter
- eval reporter
- durable workflow/session state
각 경로에 대해 다음을 기록합니다.
| 항목 | 기록 |
|---|---|
| data category | public/internal/confidential/regulated |
| processor | provider/service |
| retention | 기간과 삭제 방식 |
| access | 누가 볼 수 있는가 |
| redaction | 어디서 최소화되는가 |
| audit | 어떤 event/log로 증명되는가 |
Responsible Use 기준
공식 Responsible Use 문서는 법적·운영적 책임을 deployer가 진다고 못 박습니다. 엔터프라이즈 운영 표준이라면 최소한 다음 결정은 남겨 둬야 합니다.
| 통제 영역 | 질문 |
|---|---|
| approval policies | 민감·되돌릴 수 없는·규제·금융·의료·고용·주거·법률·안전·사용자 영향 action이 approval 없이 실행되지 않는가? |
| tool restrictions | default/custom/MCP/OpenAPI tool 중 production data에 닿는 tool이 최소권한인가? |
| route/session authorization | route auth와 session ownership ACL이 별도로 검증되는가? |
| sandbox controls | shell/file/web access와 network egress가 use case에 맞게 제한되는가? |
| telemetry exports | full input/output, reasoning, tool result가 외부 exporter/reporter로 나가는지 검토했는가? |
모델이 "알아서 조심할 것"이라는 기대는 통제가 아닙니다. Eve는 approval을 생략한 tool 실행이나 기본 allow-all sandbox network 같은 permissive 설정으로 돌아갈 수 있으니, production에 올리기 전에 통제를 명시해야 합니다.
운영 성숙도
| 레벨 | 상태 | 다음 단계 |
|---|---|---|
| L1 Prototype | instructions/tools만 있음 | eval과 route auth |
| L2 Controlled | approval/auth/evals 기본 | observability와 incident runbook |
| L3 Reliable | CI gate, audit hook, sandbox policy | cost/latency SLO |
| L4 Governed | ownership, data flow, release policy | trace-to-eval loop |
| L5 Platform | reusable patterns, shared controls | agent portfolio governance |
도입 순서
- low-risk internal read-only agent부터 시작한다.
- route auth와 eval baseline을 먼저 만든다.
- write tool은 approval과 audit ledger가 준비된 뒤 추가한다.
- sandbox network는 production 전에 deny/allow-list로 바꾼다.
- production trace에서 실패를 수집해 eval로 승격한다.
- agent portfolio가 늘어나면 shared skill/tool/connection policy를 만든다.
Eve로는 에이전트를 빠르게 만들 수 있지만, 엔터프라이즈 가치는 빠른 생성보다 검토 가능한 표면과 재현 가능한 운영 루프에서 나옵니다.