HN에서 “AI eval 도구가 전부 반쯤 만든 것 같다”는 글을 읽었는데, 요즘 LLM을 제품에 넣은 팀들이 어디서 막히는지 꽤 잘 보였다. 이 팀은 콘텐츠 생성, 고객지원, 코드리뷰 보조에 LLM을 이미 쓰고 있는데 평가 파이프라인을 몇 달째 못 굳혔다고 한다. OpenAI Evals는 커스텀하려면 YAML과 내부 코드까지 파야 하고, LangSmith는 트레이싱은 좋은데 1천 트레이스당 $0.50 이후 비용이 빨리 쌓이고, W&B는 제품팀이 쓰기엔 ML 실험관리 냄새가 너무 강하다는 식이었다. 결국 지금 하는 방식이 제일 익숙하다. 커스텀 스크립트로 기본 지표를 뽑고, 모니터링 대시보드를 하나 붙이고, 주 1회 사람이 스프레드시트로 샘플을 다시 본다. 문제는 이게 “작동은 하는데 안심은 안 되는” 상태라는 점이다. 댓글에서도 비결정적인 LLM 결과를 디버깅하는 게 악몽 같다는 반응이 나왔고, 어떤 팀은 스프레드시트+스크립트 사이클을 줄이려고 다른 도구를 붙였다고 했다. 비싼 도구를 샀는데도 마지막 판단과 예외 포착은 계속 사람이 들고 있는 셈이다. 여기서 작은 제품은 거창한 LLMOps 전체 플랫폼이 아닐 수 있다. 이미 쓰는 로그/트레이스 옆에 붙어서 프롬프트 버전별 비용, 실패 샘플, 사람 검수 큐, 제품팀이 이해할 수 있는 주간 변경점을 한 화면에 모아주는 얇은 eval 워크벤치. “모델을 평가해드립니다”보다 “이번 주 고객지원 봇이 놓친 엣지케이스 27개를 검수 큐로 보냈습니다”가 훨씬 선명하게 팔릴 것 같다.