'괜찮아 보이네'는 절대 scale 안 돼
모든 AI product는 똑같이 시작해. 누가 prompt 하나 짜고, output 세 개 흘끗 보고, '괜찮아 보이네' 한 마디 하고 ship 해. 이 주관적 검사는 exploration 단계엔 괜찮아. 하지만 그 뒤에 오는 모든 것 — regression control, 모델 upgrade, prompt iteration, retrieval 변경, tool 수정, multi-version A/B — 에선 무용지물이야. 두 번째 사람이 시스템을 보는 순간, 네 취향이 더 이상 권위가 아니거든.
실패 양상이 빠르게 쌓여:
- scale 안 돼. 일주일에 production output 만 개를 손으로 검사할 순 없어.
- 재현 안 돼. 네가 보는 'good'은 동료가 보는 'good'이 아니고, 미래의 네가 보는 'good'도 아니야.
- 설득 안 돼. 이해관계자가 '이번 prompt 변경이 quality를 올렸어?' 라고 물으면 vibe 가 아니라 숫자가 필요해.
- regression 못 잡아. 80% case 를 fix 하면서 edge case 3% 를 조용히 깨는 변경 — spot check 로는 안 보이는데 production 에선 치명적이야.
Eval 이 해결책
evaluation 은 주관적 취향을 특정 동작에 대한 재현 가능한 증거 로 바꿔. 무엇이 사실이어야 하는지, 어떤 input 위에서, 어떻게 측정하는지, ship 하려면 어떤 threshold 가 필요한지를 못박아. 한 번 적어두면 — 미래의 네 (왜 prompt 가 그렇게 생겼는지 까먹은 그 사람) 포함해서 누구든 — 측정을 다시 돌려서 변경이 안전한지 결정할 수 있어.
원칙: 측정할 수 없으면 보호할 수 없어. 처음 쓴 eval 은 처음으로 '계속 작동시키겠다' 고 약속한 동작이야.
실전 운영 패턴
prompt, model, retrieval pipeline, tool 정의를 바꾸기 전에 — 평이한 말로 — regress 시키지 말아야 할 동작과 어떻게 감지할지 적어둬. 이 한 가지 습관이 LLM 기능을 자신 있게 ship 하는 팀과 ship 하고 기도하는 팀을 갈라.
자주 터지는 실패: 가장 큰 eval 실패는 낮은 score 가 아니야. 쉬운 걸 측정하는 동안 정작 중요한 곳에서 product 가 깨지는 거야. 의미 없는 metric 에서 100% 받고도 시스템이 조용히 썩어가는 게 가능해.