Ch14. Enterprise Patterns
Eve로 고객지원, 내부 리서치, 코드 작업, 백오피스 자동화, 데이터 분석 에이전트를 설계하는 패턴을 정리한다.
핵심 요약
- 엔터프라이즈 Eve 패턴은 기능 유형보다 권한, 컨텍스트, 도구, 샌드박스, 평가 기준으로 분류해야 합니다.
- 고객지원, 리서치, 코드 작업, 백오피스, 데이터 분석, incident response는 서로 다른 approval과 sandbox posture가 필요합니다.
- 패턴을 템플릿으로 정리해두면 신규 에이전트 설계 시간을 줄이고 거버넌스 리뷰도 반복해서 돌릴 수 있습니다.
이 장은 Eve의 기능을 실제 엔터프라이즈 에이전트로 조합하는 패턴을 다룹니다. 패턴마다 권한, 컨텍스트, 도구, 샌드박스, 평가 기준을 함께 봅니다.
패턴 1. 고객지원 에이전트
목표: 고객 질문에 답하고, 필요 시 티켓을 만들고, 위험한 조치는 escalation합니다.
구성:
| 표면 | 설계 |
|---|---|
| channel | web chat 또는 Slack |
| route auth | app session/JWT |
| instructions | 답변 톤, disclosure, escalation 기준 |
| skills | 환불 정책, 장애 공지, 계정 보안 절차 |
| connections | CRM, ticket system read/write 분리 |
| tools | create_ticket, summarize_account |
| approval | 환불/계정 변경은 always() |
| evals | no hallucinated policy, ticket creation gate |
read와 write를 분리하는 게 핵심입니다. 고객 정보를 조회하는 read tool에는 최소권한 token을 쓰고, 고객 상태를 바꾸는 write tool에는 approval과 audit hook을 둡니다.
패턴 2. 내부 리서치 에이전트
목표: 사내 문서, warehouse, 외부 웹 자료를 바탕으로 분석 보고서를 만듭니다.
구성:
| 표면 | 설계 |
|---|---|
| skills | research method, citation policy |
| connections | docs MCP, warehouse MCP/OpenAPI |
| sandbox | report artifact 생성, scripts |
| subagents | researcher, analyst, critic |
| output schema | findings/sources/uncertainty |
| hooks | source usage audit |
| evals | cited answer, forbidden unsupported claim |
리서치 에이전트에서 중요한 건 “답변”보다 “근거와 불확실성”입니다. toModelOutput으로 tool result를 요약하되 source id는 그대로 남깁니다.
패턴 3. 코드 작업 에이전트
목표: repo를 읽고 수정하고 테스트를 실행합니다.
구성:
| 표면 | 설계 |
|---|---|
| sandbox | repo clone/seed, package install |
| built-ins | bash, read_file, write_file, grep, glob |
| skills | coding standard, test strategy |
| subagents | built-in agent로 병렬 작업 |
| network | allow-list 또는 deny-all after bootstrap |
| approval | destructive command/tool 제한 |
| evals | fixture repo task, no unrelated edits |
코딩 에이전트에서는 sandbox workspace가 핵심입니다. app runtime secrets는 repo 작업에 닿지 않게 막습니다. private repo access는 credential brokering이나 별도 clone tool로 제한합니다.
패턴 4. 승인형 백오피스 자동화
목표: 내부 요청을 받아 시스템 변경을 제안하고, 사람 승인 후 실행합니다.
구성:
| 표면 | 설계 |
|---|---|
| channel | Slack/Teams/Linear |
| route auth | employee identity |
| tools | dry-run tool과 execute tool 분리 |
| approval | execute tool always() |
| state | request budget, selected options |
| hooks | approval audit, action ledger |
| evals | dry-run before execute, denial path |
권장 workflow:
- 요청 수집
- read-only validation
- dry-run 결과 제시
- approval request
- idempotency key로 실행
- audit log와 사용자-facing summary
패턴 5. 데이터 분석 에이전트
목표: 자연어 질문을 SQL/분석 결과로 바꿉니다.
구성:
| 표면 | 설계 |
|---|---|
| dynamic tools | tenant별 table/query tools |
| skills | metric definitions, SQL style guide |
| connections | read-only warehouse MCP |
| sandbox | notebook/report generation |
| state | query budget |
| approval | expensive/export query |
| evals | no write SQL, correct metric tool |
중요 방어선:
- SQL은 read-only parser/runner를 통과한다.
- row limit과 timeout을 둔다.
- export/download는 approval로 분리한다.
- metric definition은 skill 또는 connection resource로 버전 관리한다.
패턴 6. Incident response 에이전트
목표: 알림을 받아 triage하고, runbook을 로드하고, Slack/Linear에 작업을 전파합니다.
구성:
| 표면 | 설계 |
|---|---|
| custom channel | incident webhook |
| cross-channel handoff | Slack incident channel |
| skills | severity matrix, runbook |
| schedules | heartbeat, stale incident sweep |
| hooks | timeline audit |
| subagents | investigator, communicator |
| evals | severity classification, no unauthorized action |
Incident agent는 자동 실행 유혹이 큽니다. 그래도 production impact가 있는 조치에는 approval과 ownership 검증을 꼭 둡니다.
패턴별 공통 아키텍처
Capability design matrix
| Capability | 기본 위치 | 보안 조치 |
|---|---|---|
| 읽기 전용 API | connection/tool | least privilege token |
| 외부 쓰기 | tool | approval + idempotency |
| 긴 절차 | skill | version/source |
| 코드/파일 실행 | sandbox | network policy |
| 전문 역할 | declared subagent | 최소 tool set |
| 장기 상태 | defineState | session scope 명시 |
| 영구 지식 | external DB/connection | access control |
운영 템플릿
새 Eve agent를 설계할 때 다음 질문에 답합니다.
| 질문 | 산출물 |
|---|---|
| 누가 호출하는가? | channel/auth design |
| 어떤 세션 소유권이 필요한가? | session ACL schema |
| 모델이 어떤 정보를 항상 봐야 하는가? | instructions |
| 어떤 절차를 필요할 때 로드할까? | skills |
| 어떤 실행 권한이 필요한가? | tools/connections inventory |
| 어떤 작업이 승인을 요구하는가? | approval policy |
| 어떤 파일/코드를 실행할까? | sandbox policy |
| 어떤 하위 역할이 필요한가? | subagent graph |
| 무엇을 통과해야 배포할까? | eval suite |
| 운영 중 무엇을 볼까? | hooks/OTel/dashboard |
좋은 Eve 아키텍처는 feature list가 아니라 capability inventory에서 출발합니다.