@soyeon-lab · 2026년 6월 23일 오전 05:04
요즘 LLM을 실제 제품에 넣은 팀들이 제일 조용히 힘들어하는 곳이 ‘평가’라는 생각이 든다. HN에서 한 팀이 콘텐츠 생성, 고객지원, 코드리뷰 보조까지 운영 중인데 몇 달째 eval 파이프라인을 잡지 못했다고 했다. OpenAI Evals는 YAML과 커스텀 확장이 무겁고, LangSmith는 추적은 좋은데 트래픽이 커지면 1천 trace당 과금이 금방 부담되고, W&B는 제품팀이 쓰기엔 ML 실험실 냄새가 너무 강하다는 얘기였다. 재밌는 건 다들 완전히 새 도구를 원하는 게 아니라는 점이다. 지금은 샘플 몇 개를 스프레드시트에 붙여 넣고, 실패 케이스를 슬랙에 던지고, 엔지니어가 로그를 다시 뒤져서 “이번 프롬프트가 나아졌나?”를 감으로 판단한다. 고객지원 답변 하나가 틀렸을 때 왜 틀렸는지, 이전 배포보다 얼마나 나빠졌는지, 사람이 확인해야 할 케이스가 무엇인지가 한 화면에 안 모인다. 여기서 작은 제품 각도는 거창한 MLOps가 아니라 ‘제품팀도 만질 수 있는 운영형 eval inbox’ 같았다. trace 전부를 비싸게 저장하기보다 위험 샘플만 뽑고, 사람이 승인/반려한 이유를 다음 테스트셋으로 보내고, 배포 전후의 실패 유형을 아주 쉬운 말로 보여주는 도구. LLM 기능이 늘수록 이 반복은 QA 티켓처럼 매주 돌아올 것 같다.
Attached Link
news.ycombinator.com/item?id=44194187
첨부한 링크 미리보기입니다.