시나리오: AI 제품 팀
AI 제품 팀에서 하네스가 eval set, safety policy, online telemetry, model rollout 시스템으로 작동하는 방식을 설명합니다.
핵심 요약
- AI 제품 팀의 하네스는 코드 팀과 닮았지만, 모델 비결정성과 드리프트까지 다뤄야 하는 non-deterministic system control입니다.
- load-bearing 요소는 eval set, prompt/policy spec, canary/shadow rollout, telemetry 네 가지로, 감이 아니라 측정으로 품질을 판단합니다.
- 권장 루프는 prompt/policy 변경 → offline eval → safety checks → shadow/canary → online telemetry이고, 건강하지 않으면 rollback합니다.
- prompt 변경은 코드 변경보다 가볍게 취급하지 말고
prompt-spec.md와 eval report를 필수화하며, safety policy는 task contract·evaluator 입력에 포함합니다. - 30일 도입은 사용자 흐름 20~50개로 작은 eval-set.jsonl 만들기, prompt/spec/policy diff 남기기, 5% canary와 rollback threshold 고정 순으로 진행합니다.
AI 제품 팀의 하네스는 코드 팀의 하네스와 닮았지만, 여기에 모델 비결정성과 드리프트까지 다뤄야 합니다.
문제 구조
- 같은 변경이라도 모델 응답이 항상 같지 않음
- prompt/spec 수정이 품질 저하로 이어져도 코드 리뷰에서 바로 안 보임
- offline에서는 좋아 보였는데 online에서 무너질 수 있음
- safety policy와 cost budget이 기능 구현과 분리되면 운영이 흔들림
load-bearing 하네스 요소
| 요소 | 왜 중요한가 |
|---|---|
| eval set | 감으로 품질을 판단하지 않게 함 |
| prompt / policy spec | 무엇이 바뀌었는지 비교 가능하게 함 |
| canary / shadow rollout | 온라인 영향 반경 축소 |
| telemetry | 품질, 비용, 실패 패턴을 지속 관찰 |
권장 루프
아티팩트 구조 예시
prompt-spec.md
safety-policy.md
tool-permissions.md
eval-set.jsonl
rubric.md
baseline-report.md
rollout-plan.yaml
online-observations.md
rollback-thresholds.yaml
rollout plan 예시
model_change:
offline_must_pass:
- "task success >= baseline"
- "safety violation <= baseline"
online_canary:
traffic_percent: 5
watch:
- "completion success"
- "tool failure rate"
- "cost per successful task"
rollback_if:
- "success drops > 10%"
- "safety incidents increase"왜 이게 엔지니어링인가
AI 제품 하네스는 사실상 non-deterministic system control입니다.
- prompt/spec을 versioned artifact로 관리합니다.
- offline eval로 최소 품질선을 고정합니다.
- online telemetry로 실제 품질과 비용을 봅니다.
- shadow/canary로 변경의 실패 반경을 제한합니다.
결국 모델이 똑똑하냐보다 품질을 어떻게 측정하고 언제 롤백할지가 핵심입니다.
자주 망하는 패턴
| 실패 패턴 | 하네스로 막는 방식 |
|---|---|
| prompt 변경을 코드 변경보다 가볍게 취급 | prompt-spec.md와 eval report 필수화 |
| offline 성공만 믿고 전체 롤아웃 | canary / shadow 단계 강제 |
| safety policy가 구현 바깥에 존재 | policy를 task contract와 evaluator 입력에 포함 |
| 비용 문제를 뒤늦게 발견 | telemetry에 cost 지표 포함 |
30일 도입 순서
- 가장 중요한 사용자 흐름 20~50개로 작은
eval-set.jsonl을 만든다. - prompt/spec/policy를 문서화하고 변경 시 diff를 남긴다.
- 전체 롤아웃 전에 5% canary와 rollback threshold를 고정한다.