TL;DR

각 항목은 “무엇을(목적) → 어떻게(기능/정책/라우팅) → 잘 되고 있나(지표/평가) → 안전하게 키운다(AgentEval·점진 배포)” 순서로 연결됩니다. 아래 체크리스트대로만 해도 실전 운영에 충분해요.

1) 목적/성공기준 정의

무엇을 해결하고, 성공을 어떻게 판정할지를 먼저 못 박아야 이후 선택이 쉬워집니다.

문제/목표: “주간 리서치 리포트 초안 자동 생성”, “고객 문의 60% 자동 응답” 등 업무 문장으로 명시
경계/입출력: 입력(문서·URL·DB) / 출력(요약, JSON, SQL, 코드) 형식 고정
성공기준(KPI): 예) 품질(정확도/근거율≥90%), 시간(p95 지연≤10s), 비용(건당 ≤ $0.03), 안전(정책 위반 0)
승인 방식: HITL 필요 여부(언제, 누가, 무엇을 승인?)
예시 템플릿
- Goal: ___
- Inputs/Outputs: ___
- KPIs: Quality __ / Latency __ / Cost __ / Safety __
- HITL: On/Off (조건: ___)

(툴사용, RAG, 긴 컨텍스트, 구조화 출력, 멀티모달, 코딩, 다국어)

업무 특성 → 필요한 능력만 고르기가 원칙입니다.

툴사용/브라우징: 웹/DB/API를 호출해 최신 정보가 필요하면 필수
RAG: 사내 문서·규정 기반으로 “근거 있는 답”이 필요하면 필수(검색+재순위화)
긴 컨텍스트: 100+ 페이지 문서, 다파일 코드 리포—> 긴 컨텍스트/리팩터 프롬프트
구조화 출력: 다운스트림 시스템이 먹을 JSON/DSL 스키마 강제(검증 필수)
멀티모달: 이미지·표·PDF 레이아웃 해석, 스크린샷 QA 등
코딩: 코드 생성/리팩터/테스트 합성/리뷰
다국어: 한국어↔영어 정밀 번역/요약, 톤/서식 유지
결정 질문
- 최신 외부 정보 필요한가? → 브라우징/툴
- 사내 지식에 근거해야 하나? → RAG
- 출력이 시스템 입력이어야 하나? → JSON 스키마

(지연, 비용, 로그)

보이는 만큼 개선됩니다. 최소 이 정도는 붙이세요.

지연(Latency): p50/p95 2개만 먼저 추적(요청→최종 응답)
비용(Cost): 건당 비용 = (입/출력 토큰 + 툴 호출) 총합
성공률/정확도: Acceptance Test 통과율, 근거(인용) 포함률
툴콜 품질: 호출 실패율, 파라미터 검증 실패율
로그/트레이스: run_id, 단계(plan/act/observe), 모델/버전, 프롬프트 요약, 도구/인자, 정책결과, 비용
대시보드 권장 카드: Success%, p95 Latency, Cost/Task, Tool Error%, Policy Violations, HITL Intervention%

(HITL, 권한, 예산, PII)

잘 달리는 것만큼, 잘 멈추는 법이 중요합니다.

HITL(승인 게이트): 고위험 작업(결제/정책 변경/대량 발송)은 반드시 승인
권한(Allow/Deny): 사용할 수 있는 툴 화이트리스트, 읽기/쓰기 분리
예산/레이트리밋: per-task/per-day 비용·호출 상한, 초과 시 중단+알림
PII/보안: 프롬프트 전 민감정보 마스킹, 비밀키는 절대 포함 금지
감사/재현: 모든 실행에 정책판정·버전·결과 로그 남기기
빠른 정책 스케치 guardrails: require_hitl: [ "send_mass_email", "update_policy" ] allow_tools: [ "read_docs", "query_db", "post_slack" ] deny_tools: [ "delete_db", "rotate_keys" ] budgets: { per_task_usd: 0.5, daily_usd: 100 } on_violation: halt_and_notify

한 모델로 만능 해결 X → 라우터가 정답.

라우팅: 작업 유형별 주 모델 + 폴백 지정(예: code, browse, rag_docs)
폴백(Fallback): 타임아웃/오류/비용 초과 시 2순위 모델로 자동 전환
캐시
- 결과 캐시: 동일 질의/문서에 대한 응답 저장
- 임베딩 캐시: RAG 인덱스/유사도 검색 비용 절감
회로차단(Circuit Breaker): 연속 실패/비용 급증 시 해당 경로 차단
간단 정책 예시 router: - when: task == "code" primary: gpt-4o fallbacks: [ claude-3-opus, starcoder2 ] - when: task == "web_browse" primary: gpt-4o-browse fallbacks: [ gemini-1.5-pro, perplexity ] cache: { response_ttl: "7d", embedding_store: "pgvector" }

운영 전에 반드시 “시나리오 평가 → 카나리 → 점진 확대”.

시나리오 세트: 실제 업무 20~50개(정답/허용 형식 포함), 악성/엣지 케이스도 포함
핵심 지표: Success%, Groundedness(근거율), JSON 유효성, Tool-Call 정확도, p95 지연, Cost/Task, 정책 위반률
하니스 흐름(의사코드) for case in scenarios: plan = agent.plan(case.goal, ctx=case.ctx) trace = agent.execute(plan) # tool calls 포함 score = evaluator.judge(case, trace) # 정답·스키마·정책 평가 log(score, trace)
배포 전략
1. 오프라인 평가(AgentEval v0) → 2) 스테이징 A/B → 3) 카나리 5~10%
2. 지표 안정 시 단계적 확장(25%→50%→100%), 실패 시 즉시 롤백
합격선 예시: Success ≥ 90%, Policy Violation = 0, p95 ≤ 10s, Cost/Task ≤ 목표, Tool Error ≤ 1%