'괜찮아 보이네'로는 절대 규모를 키울 수 없어
모든 AI 제품은 비슷하게 시작해. 누군가 프롬프트 하나를 만들고, 출력 세 개를 흘끗 본 뒤 '괜찮아 보이네'라고 말하고 출시하지. 이런 주관적 점검은 탐색 단계에서는 괜찮아. 하지만 이후에 필요한 회귀 관리, 모델 업그레이드, 프롬프트 반복 개선, 검색 방식 변경, 도구 수정, 여러 버전의 A/B 실험에는 쓸 수 없어. 다른 사람이 시스템을 검토하는 순간부터 한 사람의 취향은 더 이상 판단 기준이 될 수 없거든.
실패 양상은 빠르게 쌓여:
- 확장할 수 없어. 일주일에 운영 출력 1만 개를 일일이 검사할 수는 없어.
- 재현할 수 없어. 한 사람이 판단한 '좋음'은 동료가 판단한 '좋음'과 다를 수 있고, 시간이 지난 뒤의 판단과도 다를 수 있어.
- 설득력이 없어. 이해관계자가 '이번 프롬프트 변경으로 품질이 좋아졌어?'라고 물으면 감이 아니라 숫자로 답해야 해.
- 회귀를 잡지 못해. 전체 사례의 80%를 고치면서 경계 사례 3%를 자기도 모르게 망가뜨릴 수 있어. 표본 점검으로는 드러나지 않아도 운영 환경에서는 치명적일 수 있지.
평가가 해결책이야
평가는 주관적 취향을 특정 동작에 관한 재현 가능한 증거로 바꿔 줘. 무엇이 사실이어야 하는지, 어떤 입력을 대상으로 삼을지, 어떻게 측정할지, 출시하려면 어느 기준값을 넘어야 하는지 명확히 정해. 한 번 적어 두면 프롬프트를 왜 그렇게 만들었는지 잊어버린 미래의 자신을 포함해 누구든 측정을 다시 실행하고 변경이 안전한지 판단할 수 있어.
원칙: 측정할 수 없으면 보호할 수 없어. 처음 작성한 평가는 '이 동작이 계속 제대로 작동하도록 지키겠다'는 첫 약속이야.
실전 운영 방식
프롬프트, 모델, 검색 파이프라인, 도구 정의를 바꾸기 전에 그대로 지켜야 할 동작과 그 동작이 망가졌을 때 감지할 방법을 쉬운 말로 적어 둬. 이 한 가지 습관이 LLM 기능을 자신 있게 출시하는 팀과 출시한 뒤 운에 맡기는 팀을 갈라.
자주 발생하는 실패: 가장 큰 평가 실패는 점수가 낮게 나오는 게 아니야. 쉬운 것만 측정하느라 정작 중요한 부분에서 제품이 망가지는 거야. 쓸모없는 지표에서 100%를 받고도 시스템은 눈에 띄지 않게 계속 나빠질 수 있어.