관측성·평가
AI Gateway, Workflow, Vercel Observability, AI SDK telemetry를 연결해 품질과 운영 신호를 하나의 루프로 관리하는 방법을 정리합니다.
핵심 요약
- 평가는 별도 연구 환경이 아니라 운영 신호의 일부로 취급해 App trace·Gateway usage·Workflow state·AI SDK telemetry를 같은 리뷰 루프에 연결합니다.
- 정답률 하나가 아니라 TTFT·총 지연시간·step retry·tool/schema failure·spend·approval rate를 함께 봅니다.
- 평가 루프는 offline eval → canary → human review → production monitor로 이어지며 rollback 또는 확대 결정을 내립니다.
- 실패는 retrieval·tool·reasoning·contract·governance 유형으로 분류해 각각 다른 조치를 연결합니다.
- 실시간·품질·비용·안정성 대시보드를 주기별로 나눠 운영 신호를 따로 관리합니다.
AI SDK 7의 telemetry 등록
pnpm add @ai-sdk/otelOTel span 수집은 ai에서 **@ai-sdk/otel**로 분리됐습니다. 앱 시작 때 integration을 한 번 등록하고 기존 OTel provider·exporter 설정에 연결합니다. Next.js의 예입니다.
// instrumentation.ts
import { registerTelemetry } from 'ai'
import { OpenTelemetry } from '@ai-sdk/otel'
export function register() {
registerTelemetry(new OpenTelemetry())
// 팀의 기존 OpenTelemetry provider·exporter 등록도 이 시작 경로에 연결한다.
}integration 등록 후 호출의 telemetry는 기본 활성화됩니다. 호출별 telemetry 옵션으로 정책을 적용하고, payload에 tenant 식별자·문서 본문·tool input이 포함될 수 있는지 확인합니다. 키 이름만 바꾸고 exporter의 실제 span 수신을 확인하지 않은 상태를 관측 완료로 판정하지 않습니다.
LLM 서비스는 "정답률" 하나로 운영되지 않습니다.
실제 운영에서는 TTFT, 총 지연시간, step retry, tool failure, schema failure, spend, approval rate가 같이 움직입니다. 평가 체계도 이 신호들 위에서 굴러가야 합니다.
어떤 신호를 봐야 하는가
| 계층 | 핵심 지표 | 질문 |
|---|---|---|
| App | request latency, stream drop rate | 사용자가 느리다고 느끼는가 |
| AI Gateway | spend, request count, model usage, TTFT | 어떤 모델이 비싸고 느린가 |
| Workflow | step duration, retry count, stuck executions | 장기 작업이 어디서 멈추는가 |
| Tool / Sandbox | command failure, policy denial | tool surface가 안전한가 |
| Output Quality | schema failure, human escalation, offline eval score | 서비스 품질이 유지되는가 |
통합 관측 구조
운영 대시보드 권장 구성
| 보드 | 포함할 것 | 주기 |
|---|---|---|
| 실시간 운영 보드 | p95 latency, Gateway spend, workflow backlog | 실시간 |
| 품질 보드 | schema success, human escalation, top failure classes | 일간 |
| 비용 보드 | model별 spend, customer tier별 cost | 주간 |
| 안정성 보드 | incident count, timeout rate, retry burn | 주간 |
평가 루프
| 단계 | 입력 | 출력 |
|---|---|---|
| Offline eval | golden set, regression set | prompt/model candidate 점수 |
| Canary | 실사용 일부 트래픽 | latency / spend / failure rate |
| Human review | low confidence, approval-required tasks | 정책 보완 포인트 |
| Production monitor | trace + logs + budgets | rollback 또는 확대 |
AI SDK telemetry와 Vercel observability의 연결
| 기능 | 목적 | 적용 포인트 |
|---|---|---|
| AI SDK telemetry | generation/tool 단계 추적 | route handler, worker |
| AI SDK DevTools | 개발 중 trace 확인 | local/preview |
| Vercel Observability | 앱 레벨 trace와 runtime 신호 | prod |
| Gateway observability | 모델/비용 시야 확보 | 모든 호출 |
실무 해석
엔터프라이즈에서 평가는 별도 랩 환경이 아니라 운영 신호의 일부여야 합니다. 모델을 바꿨는데 latency, spend, approval rate가 같이 보이지 않으면 실제 영향은 알 수 없습니다.
실패 분류 기준 예시
| 실패 유형 | 예시 | 조치 |
|---|---|---|
| Retrieval failure | 필요한 문맥을 못 찾음 | resource 품질 개선 |
| Tool failure | API timeout, sandbox denial | retry/policy 개선 |
| Reasoning mismatch | 요약/판단 오류 | prompt/model reevaluation |
| Contract failure | JSON schema 미준수 | structured output 강화 |
| Governance failure | 승인 없는 action 시도 | rule/approval 강화 |
ADR 스타일 결론
Decision
평가는 별도 연구 환경이 아니라 운영 신호의 일부로 취급합니다. App trace, Gateway usage, Workflow state, AI SDK telemetry를 같은 리뷰 루프에 연결합니다.
실무 체크리스트
- App, Gateway, Workflow 지표를 같은 대시보드에서 볼 수 있는가
- schema failure와 human escalation이 품질 지표에 포함되는가
- canary와 production의 비용/지연시간 차이를 비교할 수 있는가
- 실패 유형이 retrieval, tool, reasoning, governance로 분류되는가