평가를 건너뛰면 당장은 아껴도 나중에 더 큰 부담이 생겨
팀이 평가를 건너뛰는 이유는 비용이 많이 들어 보이기 때문이야. 주석 작업은 느리고, 판정 모델을 호출하려면 돈이 들며, 데이터셋 구축은 ‘실제’ 작업을 시작하기 전에 해야 하는 추가 일처럼 느껴져. 하지만 실제 비용 구조는 정반대야. 평가 없이 출시를 반복할 때마다 부채가 쌓여.
검증되지 않은 LLM 시스템이 만드는 비용
- 조용한 회귀. 화요일에 바꾼 프롬프트가 사용자 집단의 4%에게 문제를 일으켜도 목요일에 고객 문의가 들어오고 나서야 알아차려. 그때는 이미 고객 피해가 발생한 뒤야.
- 모델 전환이 막힘. 새 모델이 나와도 어떤 동작이 깨질지 알 수 없어 업그레이드하지 못해. 결국 ‘이전 버전을 계속 유지하기’가 유일하게 안전한 선택이 돼.
- 공급사 종속. 평가가 없으면 공급사별 품질을 비교하고 이전할 근거도 없어. 공급사를 바꾸는 일이 단순한 교체가 아니라 시스템 재구축이 돼.
- 이해관계자의 불신. ‘이 변경이 실제로 도움이 됐어?’라는 질문에 ‘사용자들이 만족하는 것 같아’라고 답하면 신뢰와 영향력을 잃게 돼.
- 당직 업무로 인한 소진. 운영 장애가 생겨도 재현하거나 디버깅하거나 예방할 수 없어. 감에 의존해 출시하는 팀에서는 개발자가 지쳐 떠나게 돼.
- 느린 개선. 평가가 없으면 어떤 프롬프트 변경이 효과가 있었는지 알 수 없어. 반복 개선은 추측과 원상 복구의 연속이 돼.
원칙: 평가는 단순한 보험이 아니야. ‘변경했어’를 ‘변경으로 무엇이 달라졌는지 알아’로 바꾸는 유일한 수단이야. 평가 없이 시스템을 운영하는 건 안갯속을 헤매는 것과 같아.
비용 구조가 뒤집혀
평가 체계를 갖추면 위에서 말한 비용이 모두 반대로 바뀌어. 회귀는 PR 단계에서 잡히고, 모델 업그레이드는 일상적인 작업이 돼. 공급사 전환은 측정 가능한 비교 작업이 되고, 이해관계자는 숫자로 결과를 확인해. 당직 부담은 줄고 반복 개선은 빨라져. 추가 부담처럼 보였던 평가 모음이 오히려 팀의 개발 속도를 높여 줘.