2026년 최고의 오픈소스 LLM 평가 프레임워크 (하나는 사실 오픈소스가 아닙니다)

Arize Phoenix 저장소의 LICENSE 파일 1번째 줄에는 "Elastic License 2.0 (ELv2)"라고 적혀 있습니다. Apache가 아닙니다. MIT도 아닙니다. 많이 추천되는 오픈소스 LLM 평가 프레임워크 하나가 OSI 정의상 오픈소스가 아닌데도, 이 검색어로 상위 노출되는 거의 모든 페이지가 그렇다고 반복해서 씁니다. 오늘 이전까지는 저희 글도 그랬습니다. 2026-08-04, 8개 프레임워크의 라이선스 파일과 기본 브랜치 커밋 로그를 손으로 직접 확인하고, 상위 페이지들이 여전히 추천하는 3개를 추가로 살펴본 뒤, 6개를 설치해 동일한 10개 케이스를 돌렸습니다. 저희는 평가 프레임워크를 팔지 않으므로, 아래 어떤 판정도 특정 제품을 보호하기 위한 것이 아닙니다.

핵심 요약

• Arize Phoenix는 Elastic License 2.0으로 배포되며, OSI는 이를 오픈소스로 승인하지 않습니다.
• UpTrain의 main 마지막 커밋은 2024-07-29입니다. 새 프로젝트를 이 위에서 시작하지 마세요.
• pip install promptfoo는 서드파티 래퍼를 설치합니다. 실제 프로젝트는 npm에 있습니다.
• Ragas는 2026-02-24 이후 커밋이 없고, GitHub 조직을 vibrantlabsai로 옮겼습니다.

2026년, 어떤 오픈소스 LLM 평가 프레임워크를 설치해야 할까?

순위가 아니라 제약 조건으로 고르세요. 기존 테스트 스위트 안에 pytest 형식의 어서션을 넣으려면 DeepEval을 설치하세요. 어떤 언어 스택에도 맞는 YAML 설정과 CLI가 필요하면 promptfoo를 설치하세요. 저희가 측정한 것 중 좋은 답과 나쁜 답을 가장 깔끔하게 분리해낸 도구는 Opik입니다. 세 개 모두 Apache-2.0 또는 MIT입니다.

아래는 검증 결과입니다. 대상 8개 프레임워크에, 이 검색어 상위 페이지들이 여전히 추천하는 3개를 더했습니다.

날짜는 2026-08-04 기준 각 프로젝트 기본 브랜치의 최근 커밋입니다. GitHub 저장소 페이지는 모든 브랜치를 통틀어 최근 푸시를 보여주는데, 여기 두 프로젝트는 그 값이 더 늦습니다. UpTrain 2024-08-18, Deepchecks 2025-12-28. 둘 다 아카이브된 저장소는 아닙니다.

전환 비용 열은 사람들이 건너뛰었다가 나중에 후회하는 항목입니다. 점수는 그냥 숫자이므로 DeepEval, Ragas, Opik, phoenix-evals 사이를 옮기는 건 대체로 루프를 다시 쓰는 정도입니다. promptfoo나 Inspect AI에서 벗어나려면 다른 곳에는 동등한 형식이 없는 설정 또는 태스크 포맷을 새로 써야 하고, Evidently에서 벗어나려면 작성한 모든 임계값을 다시 감사해야 합니다. 스케일이 반대 방향으로 돌기 때문입니다. 이 검색어 상위 페이지들이 여전히 추천하는 프레임워크 중 두 개는 2024년 이후 릴리스를 내놓지 않았습니다.

등급, 호스팅 플랫폼, 명확한 순위가 필요하신가요? 그건 다른 작업이고, 저희는 유료 플랫폼을 포함한 LLM 평가 도구 순위 비교에서 이미 다뤘습니다.

8개 LLM 평가 프레임워크, 설치 방식으로 나누면

설치 형태가 곧 앞으로 계속 감당해야 할 부분이므로, 그 기준으로 묶었습니다.

테스트에 import하는 Python 라이브러리

DeepEval(pip install deepeval, Apache-2.0)은 LLM 지표를 pytest 형식의 어서션으로 감쌉니다. LLMTestCase를 만들어 assert_test에 넘기면, 임계값 이하일 때 테스트가 실패합니다. 이미 팀이 돌리고 있는 유닛 테스트 옆에 품질 게이트를 두는 데 가장 강합니다. 평가를 다른 모든 것과 같은 CI 잡 안에 두고 싶다면 이걸 고르세요.

한 가지만 밝혀두겠습니다. DeepEval은 Confident AI가 만들었고, 이 사이트의 다른 두 게시물의 유료 파트너입니다. 이 페이지가 링크하는 순위 비교 글도 그중 하나입니다. 여기서 특별 대우는 없으며, 이 페이지의 모든 DeepEval 링크는 GitHub 저장소를 가리킵니다.

Ragas(pip install ragas, Apache-2.0)는 RAG 전용 선택지입니다. evaluate()가 question, context, answer 행을 받아 지표별 점수를 비동기로 반환합니다. Python 파이프라인 안에서 검색 품질을 측정하는 데 가장 강합니다. 저장소는 explodinggradients에서 vibrantlabsai로 이동했고, 마지막 릴리스는 2026-01-13의 v0.4.3이며, 2026-02-24 이후 커밋이 없습니다. RAG 지표가 작업의 전부이고 조용한 저장소를 감수할 수 있다면 이걸 고르세요. 더 넓은 RAG 툴링 스택도 참고하세요.

Opik(pip install opik, Apache-2.0, Comet 제공)은 단독으로 호출할 수 있는 지표를 제공합니다. OPIK_TRACK_DISABLE=true를 설정하면 AnswerRelevance().score()가 계정도, 로컬 서버도, 설정 파일도 없이 실행됩니다. 제품 소개에는 잘 나오지 않는 부분입니다. 가장 적은 코드로 실제 점수를 얻는 데 강합니다. 지표는 지금 당장, 플랫폼은 나중에 원한다면 이걸 고르세요.

Evidently(pip install evidently, Apache-2.0)는 평가를 데이터셋 위의 descriptor로 취급하고, 부수 효과로 HTML 리포트를 씁니다. 이진 게이트보다는 여러 행에 걸친 배치 리포팅에 강합니다. LLM 점수는 반대 방향입니다. 1.0이면 근거가 부실하다는 뜻입니다. 누군가에게 보여줄 게 빨간 빌드가 아니라 공유 가능한 리포트라면 이걸 고르세요.

Giskard(pip install giskard, Apache-2.0)는 작성한 데이터셋에 점수를 매기는 대신 모델의 취약점을 스캔합니다. PyPI 패키지는 v2 라인을 설치하며, 프로젝트 자체 README는 v2가 "더 이상 적극적으로 유지되지 않는다"고 명시합니다. 자동화된 레드팀 스타일 스캔에 강합니다. 직접 정의하는 LLM-as-a-judge 지표 대신 취약점을 대신 찾아주길 원한다면 이걸 고르세요.

YAML 파일을 대상으로 실행하는 CLI + 설정 도구

promptfoo(npm install promptfoo, MIT)는 YAML 파일을 읽는 CLI입니다. provider, 테스트 케이스, 어서션을 선언하고 npx promptfoo eval을 실행하면, 케이스별 pass/fail과 로컬 결과 UI를 얻습니다. 앱이 Python으로 작성되지 않았을 때 프롬프트를 평가하는 데 강합니다. 품질 게이트가 Python을 모르는 팀원도 편집할 수 있는 설정 파일이어야 한다면 이걸 고르세요.

하니스급과 플랫폼 번들형

Inspect AI(pip install inspect-ai, MIT)는 영국 AI 안전연구소(UK AI Safety Institute)에서 나왔고, Python으로 정의한 태스크에 대해 모델을 평가하며, 실제 solver와 scorer 추상화, 실행 뷰어를 제공합니다. 재현 가능한 태스크 정의로 모델 단위 벤치마킹을 하는 데 강합니다. 테스트 대상이 애플리케이션이 아니라 모델 자체라면 이걸 고르세요.

Arize Phoenix(pip install arize-phoenix-evals)는 FaithfulnessEvaluator, CorrectnessEvaluator 같은 사전 구축 평가기를 제공하며, 이진 라벨과 점수를 함께 반환합니다. 컷오프를 직접 정하지 않고도 게이팅할 수 있는 결정론적 라벨에 강합니다. 이 글의 제목에 괄호가 붙은 이유가 바로 이 라이선스이며, 다음 섹션에서 따로 다룹니다.

Arize Phoenix는 오픈소스인가?

아닙니다. 오픈소스 이니셔티브(Open Source Initiative)가 유지하는 정의로는 그렇지 않습니다. Arize Phoenix는 **Elastic License 2.0 (ELv2)**으로 배포됩니다. 저장소의 LICENSE 파일 1번째 줄이 이를 명시하고, PyPI도 v19.15.0에서 독립적으로 license: Elastic-2.0이라고 밝힙니다. 소스는 읽을 수 있고, 포크할 수 있고, 셀프 호스팅할 수 있습니다. 제한되는 것은 한 가지 용도뿐입니다.

핵심 제한은 이렇습니다. ELv2는 소프트웨어를 호스팅형 또는 관리형 서비스로 제3자에게 제공하는 것을 금지합니다. 잘 읽어보세요. 겉보기보다 훨씬 적은 사람에게만 적용됩니다. arize-phoenix-evals를 설치해 자신의 애플리케이션에 점수를 매기는 용도라면 ELv2는 전혀 문제가 되지 않습니다. Phoenix를 외부 고객에게 판매하는 평가 서비스로 패키징하는 컨설팅사나 플랫폼 팀이라면 문제가 됩니다. 그게 차이의 전부이고, ELv2가 어긋나는 부분은 오픈소스 정의(Open Source Definition), 구체적으로는 사용 분야 제한(field-of-use restriction) 조항입니다.

현재 이 검색어로 상위 노출되는 모든 페이지가 Phoenix를 "오픈소스"로 분류하고 있고, 저희도 그랬습니다. 저희 LLM 평가 도구 순위 비교도 Phoenix를 완전한 오픈소스라고 설명했는데, 이는 틀렸고 지금 수정 중입니다. Phoenix는 소스 공개형(source-available)이지 오픈소스가 아니며, 이 차이는 그것을 서비스로 팔 계획이 있을 때만 문제가 됩니다. 스코어링이 아니라 트레이싱이 필요하다면, 그건 여기가 아니라 AI 관측 가능성 플랫폼의 영역입니다.

이 중 지금도 활발히 유지보수되는 것은?

대부분입니다. 저희가 확인한 11개 저장소 중 6개가 2026-08-03 또는 2026-08-04에 main에 커밋을 받았습니다. DeepEval, promptfoo, Opik, Arize Phoenix, Inspect AI, Giskard입니다. 두 개는 2024년 이후 릴리스가 없습니다. 하나는 GitHub 조직 변경 이후 2026년 들어 조용해졌습니다.

2026년에 새 프로젝트를 시작하지 않을 프레임워크

UpTrain은 죽었습니다. main 최근 커밋은 2024-07-29, 최근 릴리스 v0.7.1은 2024-05-14로, 두 기준 모두 2년 가까이 정체되어 있습니다. 저장소는 여전히 존재하고 여전히 Apache-2.0이니 막을 사람은 없지만, 방치된 평가 라이브러리 위에 새 작업을 시작하는 건 나중에 해명해야 할 결정입니다.

Deepchecks는 정확한 버전을 짚고 넘어갈 가치가 있습니다. 2024-12-15의 0.19.1 이후 릴리스가 없었지만, 저장소는 지금도 커밋을 받고 있으며 main의 최근 커밋은 2025-11-24입니다. 여전히 사람들이 작업 중인 프로젝트이며, 다만 18개월 넘게 아무도 버전을 자르지 않았을 뿐입니다. UpTrain과 Deepchecks 모두 GitHub에서 아카이브되지 않았고, 둘 다 기여를 막지도 않았습니다.

Ragas는 날짜 외에는 딱히 할 말이 없습니다. 최근 릴리스는 2026-01-13의 v0.4.3, 2026-02-24 이후 커밋 없음, 저장소는 explodinggradients에서 vibrantlabsai로 이동했습니다. 조직이 왜 바뀌었는지 검증 가능한 설명은 찾지 못했고, 지어내지 않겠습니다. 조용한 저장소가 곧 고장 난 저장소는 아닙니다. 오늘 신뢰도(faithfulness) 점수를 계산하는 Apache-2.0 코드는 내년에도 똑같이 계산할 것입니다. 위험은 패치되지 않는 의존성 쪽이고, 아래 테스트에서 실제로 저희를 발목 잡은 부분이 바로 그것입니다.

이 검색어 1페이지의 다른 글들은 UpTrain과 Deepchecks를 여전히 추천하면서 추천에 날짜를 붙이지 않습니다. 2024년 12월 이후 릴리스가 없는 프레임워크는 기능 문제가 아니라 의존성 문제입니다.

평가 프레임워크가 필요한가, 평가 하니스가 필요한가?

애플리케이션 평가 프레임워크는 자신의 데이터를 기준으로 자신의 앱 출력을 채점합니다. DeepEval, Ragas, promptfoo, Opik, phoenix-evals, Evidently가 모두 여기 속합니다. 모델 평가 하니스는 대신 표준화된 공개 태스크로 모델을 벤치마킹합니다. lm-evaluation-harness와 Inspect AI가 그렇습니다. 이 페이지에서 가장 비싼 실수는 잘못된 종류를 고르는 것입니다.

실패 사례는 구체적입니다. 누군가 lm-evaluation-harness를 RAG 챗봇 테스트에 연결해 MMLU 점수를 받고서, 자신의 리트리버가 맞는 문서를 가져오는지에 대해서는 정확히 아무것도 알아내지 못합니다. 점수는 진짜입니다. 다만 그건 아무도 걱정하지 않던 기반 모델을 측정한 것뿐입니다.

Inspect AI의 형태는 그 출신에서 나옵니다. 영국 AI 안전연구소가 MIT로 프런티어 모델 평가용으로 만들었기에 solver, scorer, task가 일급 개념이고, 애플리케이션이라는 개념 자체가 없습니다. 딱 그 용도로 쓸 좋은 이유입니다. 문제가 단일 턴이 아니라 에이전트라면 프로덕션에서 AI 에이전트 평가하기는 또 다른 영역이고, 도구 호출 서버는 MCP 서버와 도구 평가 가이드에서 따로 다룹니다.

6개를 설치하고 같은 10개 케이스를 돌린 결과

2026-08-04, 이 중 6개를 새 Python 3.11.14 venv에(promptfoo용 npm 포함) 설치하고, 동일한 10개 항목짜리 RAG 세트에 판정 모델 openai/gpt-4o-mini(OpenRouter 경유, 온도 0)로 점수를 매겼습니다. 7개 항목은 정답이었습니다. 나머지 3개는 세 가지 다른 방식으로 틀렸습니다. 하나는 자신의 컨텍스트와 모순되고, 하나는 세부 사항을 지어내고, 하나는 질문에 답하지 않은 채 유창한 산문만 늘어놓습니다. 각 프레임워크는 연속으로 두 번씩 돌렸습니다.

6개 중 5개의 근거 지표가 세 결함을 모두 잡아냈습니다. 아래 세 가지 발견 때문에 이 섹션을 따로 뒀습니다.

관련성(relevance) 지표는 품질 지표가 아니며, 그중 두 개는 자신 있는 거짓말에 정답보다 높은 점수를 줬습니다. Ragas의 ResponseRelevancy는 HTTP 404가 5xx 서버 오류라고 주장하는 항목에 0.777점을 줬는데, 이는 정답인 7개 항목 중 2개보다 높은 점수입니다. 존재하지 않는 rate limit을 지어낸 항목에는 0.813점을 줬고, 이는 정답 4개보다 높습니다. promptfoo의 answer-relevance도 마찬가지였습니다. 404 항목에 0.800점을 줘 0.7 임계값을 깔끔하게 통과시켰고, 정작 정답인 q01은 0.679점으로 떨어뜨렸습니다. 버그가 아닙니다. 자신 있는 오답은 질문에 완벽하게 "답변"하기 때문입니다. 하지만 관련성이 대시보드에 찍히는 숫자라면, 유창한 환각이 최고의 출력처럼 보입니다.

신뢰도(faithfulness)만 보는 게이트는 무관한 답변을 놓칩니다. DeepEval은 질문에 전혀 답하지 않은 항목에 1.000 faithfulness를 줘 깔끔하게 통과시켰는데, 이는 나름 타당합니다. 컨텍스트에 대해 아무것도 주장하지 않는 답변은 그 컨텍스트와 모순될 것도 없기 때문입니다. 관련성 지표만이 이를 잡아냈고, 점수는 0.000이었습니다. 위 표에서 유일하게 근거 지표가 놓친 사례입니다. 어느 한쪽 지표만으로는 구멍이 있고, 두 개를 같이 써야 둘 다 커버됩니다.

이진 평가기는 온도 0에서 안정적이었습니다. 등급형 지표는 그렇지 않았습니다. Phoenix와 DeepEval은 두 번의 동일한 실행에서 10개 중 0개도 움직이지 않았습니다. Opik은 AnswerRelevance에서 4개가 움직였고, 그 기준은 0.05 단위 격자였습니다. Evidently도 4개가 움직였습니다. 여기서는 어떤 흔들림도 판정을 뒤집지 않았지만, promptfoo의 정답 q01은 0.700 임계값에 대해 0.679였다가 0.642로 떨어졌는데, 이건 CI 게이트가 불안정해지는 전형적인 모양입니다.

작은 메모 두 가지입니다. 6개 중 3개(DeepEval, Opik, Phoenix)는 첫 시도부터 설치와 실행이 깔끔했던 반면, Ragas는 langchain-community<0.4로 버전을 고정하기 전까지 import조차 되지 않았습니다. 판정 모델 토큰 사용량을 보고한 건 promptfoo뿐이었고, 1회차 실행에서 16,011개, 2회차에서 16,010개의 어서션 토큰을 썼습니다.

여기서의 한계를 있는 그대로 밝힙니다. n=10은 스모크 테스트지 벤치마크가 아닙니다. 이 결과는 사용성과 사각지대에 대해 말해줄 뿐, 지표의 정확도를 말해주지 않습니다. 판정 모델은 하나뿐이었고, 더 큰 판정 모델이었다면 모든 수치가 움직였을 것이며, DeepEval과 Ragas가 같은 정답 항목에서 나란히 낸 두 건의 오탐도 아마 바뀌었을 것입니다. 두 번의 실행은 흔들림이 존재한다는 것만 증명할 뿐 그 성격을 특징짓지는 못합니다. 답변은 미리 작성해뒀으므로 생성, 트레이싱, 데이터셋 관리 어느 것도 실제로 테스트되지 않았고, 그래서 promptfoo의 337.9초짜리 설치 시간이 실제보다 더 나빠 보입니다. "최고"는 언제나 어떤 제약 조건에서의 최고를 뜻합니다. CI 게이트냐, RAG 지표냐, UI냐에 따라 답이 달라지고, 오프라인 평가와 온라인 평가의 구분도 마찬가지입니다.

같은 체크, 세 가지 방식으로 작성하면

인터페이스 형태를 가장 빠르게 비교하는 방법은 같은 어서션을 세 번 읽어보는 것입니다. 아래는 DeepEval, Ragas, promptfoo에서 한 항목에 대한 근거(grounding) 체크를 실제로 실행했던 스크립트에서 다듬어 가져온 것입니다. 지표 이름은 각기 다르므로, 여기서 다시 정의하는 대신 LLM-as-a-judge 지표가 실제로 어떻게 동작하는지를 링크로 대신합니다.

# DeepEval 4.1.5: pytest 형식, 임계값 미달 시 테스트 실패
from deepeval import assert_test
from deepeval.models import GPTModel
from deepeval.metrics import FaithfulnessMetric
from deepeval.test_case import LLMTestCase

judge = GPTModel(
    model="openai/gpt-4o-mini",
    base_url="https://openrouter.ai/api/v1",
    api_key=OPENROUTER_KEY,
)

def test_faithfulness():
    case = LLMTestCase(
        input=question,
        actual_output=answer,
        retrieval_context=[context],
    )
    assert_test(case, [FaithfulnessMetric(threshold=0.7, model=judge)])

# Ragas 0.4.3: import 경로에 유의. `from ragas.metrics import Faithfulness`는
# 이 버전에서 ImportError를 냅니다. 구체 지표의 위치가 옮겨졌습니다.
from ragas import evaluate, EvaluationDataset
from ragas.metrics._faithfulness import Faithfulness
from ragas.llms import LangchainLLMWrapper
from langchain_openai import ChatOpenAI

judge = LangchainLLMWrapper(
    ChatOpenAI(model="openai/gpt-4o-mini",
               base_url="https://openrouter.ai/api/v1")
)

result = evaluate(
    dataset=EvaluationDataset.from_list(rows),
    metrics=[Faithfulness(llm=judge)],
)

# promptfoo 0.121.20: npm install promptfoo, 그다음 npx promptfoo eval
providers:
  - id: echo          # 답을 새로 생성하지 않고 미리 작성된 답을 채점했습니다
defaultTest:
  assert:
    - type: context-faithfulness
      threshold: 0.7
tests:
  - vars:
      query: "Is HTTP 404 a client error or a server error?"
      context: "HTTP 404 Not Found is in the 4xx class, which denotes client errors."
      output: "HTTP 404 is a server error in the 5xx class."

설치 줄에는 코드보다 더 많은 함정이 숨어 있고, 아래 주석 하나하나는 2026-08-04에 실제로 저희 시간을 잡아먹은 항목입니다.

# 진짜 promptfoo는 npm에 있습니다. 같은 이름의 PyPI 패키지는
# 서드파티 래퍼입니다: https://pypi.org/project/promptfoo/ vs
# https://www.npmjs.com/package/promptfoo
npm install promptfoo

# pip install giskard는 v2 라인을 설치하며, 프로젝트 자체 README는
# 이를 더 이상 적극적으로 유지되지 않는다고 명시합니다.
pip install giskard

# lm-evaluation-harness는 패키지명 lm-eval로 설치됩니다.
pip install lm-eval

# Evidently는 openai를 함께 끌어오지 않으며, 판정 모델 호출은
# 이미 데이터셋을 다 만든 뒤, import 시점이 아니라 호출 시점에 죽습니다.
pip install evidently openai

# Ragas 0.4.3은 langchain-community 0.4.x에서는 import되지 않습니다.
pip install ragas "langchain-community<0.4"

평가 점수로 빌드를 실패시킬 수 있나?

가능합니다. 여기 나온 모든 프레임워크가 숫자 또는 이진 점수를 반환하고, 임계값 어서션이 실패하면 0이 아닌 코드로 종료합니다. GitHub Actions가 빌드를 빨갛게 만드는 데 필요한 건 그게 전부입니다. 종료 코드를 연결하는 건 쉬운 부분입니다. 판정 모델이 우연히도 넘지 않을 임계값을 고르는 것, 그게 일주일이 걸리는 부분입니다.

아래는 저희가 실제로 돌리는 워크플로 형태이며, 2026-08-04 테스트에 쓴 버전으로 고정했습니다.

name: evals
on: [pull_request]

jobs:
  eval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.11.14"
      - run: pip install deepeval==4.1.5

      - name: Score the golden set
        env:
          # 판정 모델을 고정하세요. 분기 중간의 모델 업그레이드는 모든 점수를 흔듭니다.
          JUDGE_MODEL: openai/gpt-4o-mini
          # 임계값은 한 곳에서 관리하고, 지표 생성자가 이를 읽습니다.
          EVAL_THRESHOLD: "0.7"
          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
        run: deepeval test run tests/evals/

임계값보다 먼저 걸려 넘어지는 함정이 두 가지 있습니다. 첫째, 판정 모델 호출은 네트워크 호출입니다. 저희 10개 항목짜리 DeepEval 실행은 126.8초가 걸렸는데, .measure()가 순차 실행이기 때문입니다. 200개 항목짜리 골든 세트라면 이 코드 경로에서는 풀 리퀘스트마다 커피 한 잔 시간이 걸립니다. 테스트한 다른 모든 프레임워크는 기본값이 병렬 실행이며, 이게 CI 소요 시간을 좌우하는 가장 큰 레버입니다.

둘째, 불안정성입니다. 온도 0에서도 Opik과 Evidently는 각각 연속 실행 사이에 10개 중 4개 항목이 움직였고, promptfoo의 정답은 0.700 게이트에 대해 0.679였다가 0.642로 떨어졌습니다. 대응책은 지루하지만 효과가 있습니다. 풀 리퀘스트에만 따라 바뀌는 고정 골든 데이터셋을 쓰고, 판정 모델을 고정하고, 가능하면 라벨로 충분한 이진 평가기를 우선하고, 절대값 하한이 아니라 델타를 기준으로 게이팅하세요. 마지막 항목은 멀티턴 평가에서 특히 중요합니다. 하나의 대화가 각기 흔들릴 수 있는 여러 점수를 만들어내기 때문입니다.

규모 참고로, LangChain의 State of Agent Engineering 설문(1,340개 응답, 2025년 11월 18일부터 12월 2일까지 조사, 2026년 6월 12일 발표)에 따르면 89%의 조직이 에이전트에 대해 어떤 형태로든 관측 가능성을 도입했지만, 테스트 세트에 대해 오프라인 평가를 실행하는 조직은 52.4%뿐이었습니다. 지켜보는 건 흔하지만, 게이팅하는 건 아직 흔하지 않습니다.

이번 주라면 무엇을 설치할 것인가

가져갈 것 네 가지입니다. Arize Phoenix는 Elastic License 2.0으로 소스 공개형이며 OSI 승인 오픈소스가 아닙니다. 대부분의 독자에게는 아무것도 바뀌지 않지만, 평가 도구를 재판매한다면 모든 게 바뀝니다. UpTrain은 죽었고, 날짜가 없는 페이지들은 여전히 이를 추천합니다. Deepchecks도 2024년 12월 이후 릴리스를 자르지 않았지만, 저장소는 지금도 커밋을 받고 있습니다. 근거 지표와 관련성 지표는 각각 상대가 커버하는 구멍이 있으니, 둘 다로 게이팅하세요. 그리고 등급형 점수는 온도 0에서도 흔들리니, 판정 모델을 고정하고 임계값에 여유를 두세요.

이번 주에 새 평가 스위트를 시작한다면, 저는 CI 게이트용으로 DeepEval을 설치하겠습니다. 어서션이 테스트 옆에 있어야 자연스럽기 때문입니다(위 공시 참고). 그리고 저희가 측정한 것 중 가장 깔끔한 분리를 보여준 Opik의 독립 지표를 더하겠습니다. 스택이 Python이 아니라면 망설임 없이 promptfoo입니다. 골든 세트와 워크플로를 대신 짜줄 사람이 필요하다면, 기꺼이 함께 이야기 나누겠습니다.

자주 묻는 질문

최고의 오픈소스 LLM 평가 프레임워크는 무엇인가요?

절대적인 승자는 없고, 제약 조건별로 최적의 선택만 있습니다. Python 테스트 스위트 안의 pass/fail 게이트라면 DeepEval, 언어 무관 YAML과 CLI 구성이라면 promptfoo, RAG 검색 지표라면 Ragas입니다. 다만 2026-02-24 이후 커밋이 없는 저장소를 감수할 수 있어야 합니다. 저희 2026-08-04 테스트에서 좋은 답과 나쁜 답을 가장 깔끔하게 갈라낸 건 Opik이었습니다.

Arize Phoenix는 오픈소스인가요?

오픈소스 이니셔티브의 정의로는 아닙니다. Arize Phoenix는 Elastic License 2.0으로 배포되며, PyPI는 v19.15.0에서 license: Elastic-2.0이라고 명시하고, 저장소 LICENSE 파일 1번째 줄도 이를 직접 밝힙니다. 소스 공개형입니다. 읽고, 포크하고, 수정하고, 셀프 호스팅할 수 있습니다. 유일한 제한은 소프트웨어를 호스팅형 또는 관리형 서비스로 제3자에게 제공하는 것입니다.

Ragas는 지금도 유지보수되고 있나요?

2026-08-04 기준 검증 가능한 사실은 이렇습니다. 최근 릴리스는 2026-01-13의 v0.4.3, 2026-02-24 이후 커밋 없음, 저장소는 explodinggradients 조직에서 vibrantlabsai로 이동했습니다. 저장소는 아카이브되지 않았습니다. 조직 변경에 대한 신뢰할 만한 공개 설명은 찾지 못했고, 추측하지 않겠습니다. Apache-2.0 코드는 여전히 동작합니다. 위험은 패치되지 않는 의존성 쪽입니다.

평가 프레임워크가 필요한가요, 관측 가능성 플랫폼이 필요한가요?

결국 둘 다 필요하지만, 둘은 다른 질문에 답합니다. 평가 프레임워크는 배포 전에, 직접 통제하는 데이터셋 위에서 변경이 출력을 더 좋게 했는지 나쁘게 했는지 알려줍니다. 관측 가능성 플랫폼은 배포 후 프로덕션에서 실제로 무슨 일이 일어났는지 알려줍니다. CI 파이프라인이 있다면 평가 프레임워크부터 시작하세요. 프로덕션 쪽은 AI 관측 가능성 플랫폼을 참고하세요.

CI/CD에서 LLM 평가를 실행할 수 있나요?

가능합니다. 여기 다룬 모든 프레임워크는 임계값 어서션 실패 시 0이 아닌 코드로 종료하며, GitHub Actions 잡에 필요한 건 그게 전부입니다. 실질적 제약은 소요 시간(판정 모델 호출은 네트워크 호출이며, 저희의 순차 실행 DeepEval은 10개 항목에 126.8초가 걸렸습니다)과 판정 모델의 비결정성입니다. 워크플로 형태와 대응책은 위 CI 섹션에 있습니다.

DeepEval과 Ragas의 차이는 무엇인가요?

품질이 아니라 인터페이스 형태와 범위의 차이입니다. DeepEval은 pytest 형식의 범용 도구입니다. 테스트 케이스를 작성해 지표 임계값에 대해 어서션하며, 다양한 종류의 애플리케이션 출력을 다룹니다. Ragas는 RAG 전용 라이브러리로, evaluate()가 question, context, answer 행으로 이뤄진 데이터셋 위에서 비동기로 실행됩니다. DeepEval은 CI 게이트에 더 자연스럽게 맞고, Ragas는 검색 쪽을 더 깊게 파고듭니다.

왜 pip install promptfoo는 잘못된 패키지를 주나요?

promptfoo는 Node 프로젝트이기 때문입니다. 진짜 프로젝트는 MIT로 npm에 공개되어 있고, npm install promptfoo로 설치합니다. 같은 이름의 PyPI 패키지는 업스트림 프로젝트가 아닌 서드파티 래퍼이며, 이를 설치하면 문서가 설명하는 것과 다른 CLI를 디버깅하게 되는 흔한 함정입니다.

lm-evaluation-harness는 LLM 평가 프레임워크인가요?

연관은 있지만 다른 작업인 모델 평가 하니스입니다. lm-evaluation-harness(pip install lm-eval로 설치)는 MMLU 같은 표준화된 공개 태스크에 대해 모델을 벤치마킹합니다. 리트리버가 맞는 문서를 가져왔는지는 알려주지 않습니다. 애플리케이션이라는 개념 자체가 없기 때문입니다. 프레임워크 대 하니스 구분은 위 섹션을 참고하세요.

이 프레임워크들은 무료인가요?

라이선스상으로는 그렇습니다. DeepEval, Ragas, Opik, Evidently, Giskard는 Apache-2.0이고, promptfoo, Inspect AI, lm-evaluation-harness는 MIT입니다. 두 라이선스 모두 상업적 이용, 수정, 재배포를 허용합니다. 예외는 Arize Phoenix입니다. Elastic License 2.0은 셀프 호스팅은 허용하지만 관리형 서비스로 제3자에게 제공하는 것은 허용하지 않습니다. 판정 모델 API 사용 요금은 각 제공사가 별도로 청구합니다.