프롬프트를 바꿨는데 결과가 나아졌는지 나빠졌는지 모르겠다면, 도구가 필요한 시점이다. LLM 평가 도구는 그 판단을 사람 눈대중에서 데이터로 옮겨 준다.
LLM 평가 도구가 필요한 순간
프롬프트 테스트를 손보는 일은 반복된다. 문장 하나를 바꿀 때마다 다른 답이 나온다. 문제는 이 변화가 좋은 방향인지 알기 어렵다는 점이다.
혼자 쓰는 챗봇이라면 감으로도 버틴다. 하지만 서비스에 붙여 쓰기 시작하면 상황이 달라진다. 프롬프트 하나를 바꿨을 때 기존 기능이 망가지지 않았는지 확인해야 하고, 모델을 교체할 때 성능이 떨어지지 않았는지도 재야 한다. 평가 도구는 이 확인 작업을 자동화한다.
도구는 크게 두 갈래다. 하나는 오프라인 평가로, 미리 준비한 시험 문항에 모델을 돌려 점수를 매긴다. 다른 하나는 운영 추적(tracing)으로, 실제 서비스에 들어온 요청과 응답을 기록하고 품질을 모니터링한다.
코드 우선 도구
개발팀이 코드로 평가를 돌리는 쪽은 파이썬 생태계가 강하다.
딥이밸(DeepEval)은 파이썬과 pytest에 붙여 쓴다. 테스트 코드를 쓰듯 평가를 작성하고, 통과 여부로 배포를 막을 수 있다. MIT 라이선스에 로컬 실행이 가능해 계정 없이도 돌아간다.
프롬프트푸(promptfoo)는 설정 파일과 명령줄 도구로 접근한다. YAML 파일 하나에 테스트 문항 몇십 개를 넣고, CI 단계에서 한 번 돌리는 식이다. 여러 모델을 나란히 비교하기 좋고, 보안 취약점을 겨냥한 레드팀 테스트에도 쓴다.
라가스(Ragas)는 검색 증강 생성(RAG) 구조에 특화됐다. 문서 검색 품질과 답변의 근거 충실도를 따로 재는 지표를 제공한다.
도구 | 방식 | 잘 맞는 팀 |
|---|---|---|
딥이밸 | 파이썬·pytest | 코드로 평가를 관리하는 팀 |
프롬프트푸 | YAML·명령줄 | 모델 비교, CI 게이트 |
라가스 | 파이썬 | RAG 구조 평가 |
아리즈 피닉스 | 오픈소스, 자체 호스팅 | 데이터를 밖으로 못 보내는 팀 |
이들은 대개 무료로 시작할 수 있다. 유료 전환 없이도 충분히 쓸 수 있는 점이 강점이다.
운영 추적 도구
실제 서비스 품질을 계속 지켜보려면 추적 도구가 필요하다.
랭퓨즈(Langfuse)는 자체 호스팅이 가능한 오픈소스 도구다. 실제 요청을 기록하고, 그중 일부를 평가로 돌려 품질 추이를 본다. 클라우드 버전도 제공된다.
랭스미스(LangSmith)는 랭체인(LangChain)과 랭그래프(LangGraph)를 쓰는 팀에 자연스럽다. 이미 그 프레임워크로 서비스를 만들었다면 별도 도구를 붙이는 수고가 줄어든다.
브레인트러스트(Braintrust)는 평가와 배포 관리를 한 시스템에 묶는다. 프롬프트를 바꿀 때 점수가 기준 아래로 떨어지면 병합을 막는 식의 게이트를 만들 수 있다.
선택 기준은 단순하다. 이미 쓰는 개발 프레임워크가 있으면 거기 붙는 도구를 고른다. 데이터를 외부로 보낼 수 없으면 자체 호스팅이 되는 도구로 좁힌다.
자체 평가 세트를 만드는 법
도구를 골랐으면 채점할 문항이 필요하다. 공개 벤치마크는 출발점일 뿐이고, 내 업무에 맞는 세트는 직접 만들어야 한다.
절차는 네 단계다. 먼저 애플리케이션이 처리할 작업을 다섯에서 열다섯 가지로 나눈다. 다음으로 각 유형마다 실제 사례를 모은다. 사내 문서나 과거 문의처럼 이미 있는 자료를 쓰면 된다. 그다음 사람이 정답이나 채점 기준을 붙인다. 마지막으로 지표를 정해 자동 채점한다.
여기서 대표성이 관건이다. 실제 입력이 들어오는 모습 그대로를 반영해야 한다. 오타와 줄임말이 섞인 실제 문의를 정돈된 예시로 바꾸면, 평가는 좋게 나오지만 실전에서 무너진다.
세트는 한 번 만들고 끝이 아니다. 새로 발견된 실패 사례를 계속 편입해야 한다. 모델이 바뀌고 사용자 요구가 바뀌면 시험지도 따라 바뀌어야 한다.
심사 모델을 쓸 때 주의할 점
주관적인 품질을 재려면 심사 모델(LLM-as-judge)을 붙이는 방식이 널리 쓰인다. 사람이 일일이 채점하는 비용을 줄이면서 자연스러움이나 유용성 같은 항목을 잴 수 있다.
문제는 심사 모델도 편향을 갖는다는 점이다. 자기 답이나 비슷한 스타일을 더 높게 주는 경향이 있고, 답의 순서에 따라 점수가 흔들린다. 그래서 심사 모델 점수는 사람 평가와 교차 검증을 거쳐야 신뢰할 수 있다.
가장 흔한 실수는 심사 점수 하나를 절대 기준으로 삼는 것이다. 심사 점수는 추세를 보는 지표로 쓰고, 최종 판단은 실제 사용 결과로 내리는 편이 안전하다.
정리: 작게 시작해 게이트로 쓴다
LLM 평가 도구는 프롬프트 변경과 모델 교체를 눈대중에서 데이터로 옮긴다. 코드 중심이면 딥이밸과 프롬프트푸, 운영 추적이면 랭퓨즈와 랭스미스가 출발점이다.
지금 할 일은 하나다. 자주 하는 작업 스무 개짜리 작은 평가 세트를 만들어, 프롬프트를 바꿀 때마다 돌려 보는 것이다. 이 습관 하나가 나중에 배포 사고를 막는 검문소가 된다.
