HN에서 LLM 평가 도구 얘기가 6점짜리 작은 글로 지나갔는데, 오히려 그래서 더 실제 팀 냄새가 났다. 글쓴이는 이미 콘텐츠 생성, 고객지원, 코드 리뷰 보조에 LLM을 운영으로 쓰고 있는데, 몇 달째 제대로 된 평가 파이프라인을 못 잡고 있다고 했다. OpenAI Evals는 YAML 설정과 커스텀 확장이 부담스럽고 배치 처리 쪽에 가깝고, LangSmith는 추적은 좋은데 평가가 부가 기능처럼 느껴지며 무료 구간 뒤에는 trace 1천 개당 0.50달러가 쌓인다고 했다. W&B는 강력하지만 전통 ML 실험관리 감각이라 제품팀이 쓰기 어렵다는 말도 있었다. 임시방편은 대충 상상이 간다. 중요한 프롬프트 몇 개를 스프레드시트에 적어두고, 릴리즈 전후로 샘플을 돌리고, 이상한 답변은 Slack에 붙여 사람이 판정하고, 엔지니어가 tracing 화면을 뒤진다. 댓글에서도 “비결정적인 LLM을 어떻게 디버깅하느냐”는 질문이 바로 나왔다. 문제는 한 번 세팅하면 끝나는 테스트가 아니라, 콘텐츠·상담·코드리뷰처럼 쓰임새가 다른 세 제품팀이 계속 새 예외를 만들어낸다는 점이다. 여기서 필요한 건 거대한 MLOps 플랫폼보다, 운영 중인 LLM 기능별로 ‘이번 주에 깨진 시나리오’를 PM도 볼 수 있게 모아주는 얇은 평가 조종석 같아 보인다. trace를 전부 저장해 과금 폭탄을 맞기보다 샘플링과 실패 후보만 잡고, 사람 검수가 필요한 케이스를 큐로 보내고, 릴리즈 전후 점수 변화와 실제 사용자 불만을 한 화면에 묶는 정도. LLM을 이미 제품에 넣은 팀이 늘수록 “모델이 좋아졌나?”보다 “어제보다 덜 망가졌나?”를 확인하는 작은 도구가 더 자주 열릴 것 같다.