이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- promptfoo, DeepEval, Ragas, Langfuse, Phoenix는 어떤 문제를 푸는가?
- eval 도구와 observability 도구는 어떻게 다르게 쓰는가?
- 백엔드 개발자는 도구와 무관하게 어떤 메타데이터를 남겨야 하는가?
개요
2026-06-30 GitHub API 확인 기준으로 promptfoo, DeepEval, Ragas, Langfuse, Phoenix는 모두 활발히 유지보수되고 있다. 이 범주의 도구는 AI 기능을 데모에서 운영으로 끌어올릴 때 중요하다.
eval은 변경 전후 품질을 검증하고, observability는 운영 호출을 추적한다.
도구별 학습 포인트
| 도구 | 배울 점 |
|---|---|
| promptfoo | prompt, agent, RAG 테스트와 red teaming을 설정으로 관리 |
| DeepEval | LLM app 평가를 테스트처럼 구성 |
| Ragas | RAG 품질 지표와 dataset 기반 평가 |
| Langfuse | prompt, trace, eval, dataset 연결 |
| Phoenix | LLM observability와 evaluation 흐름 |
도구 이름보다 중요한 것은 공통 구조다. dataset, run, metric, trace, prompt version이 필요하다.
Eval과 Observability 차이
Eval:
- 배포 전 변경을 검증한다.
- prompt/model/retrieval 변경 회귀를 잡는다.
- dataset과 expected behavior가 필요하다.
Observability:
- 배포 후 실제 호출을 추적한다.
- latency, token, error, retrieval source, tool call을 본다.
- incident debugging에 필요하다.
둘 중 하나만 있으면 부족하다.
코드로 이해하기
도구를 무엇으로 쓰든 공통 메타데이터는 남겨야 한다.
{
"trace_id": "trace-123",
"feature": "document_qa",
"prompt_version": "doc-qa-v4",
"model": "gpt-4.1-mini",
"retrieval_profile": "top8-rerank-v2",
"input_tokens": 2200,
"output_tokens": 430,
"source_ids": ["policy-1", "policy-2"],
"validation_status": "ok"
}이 정보가 있으면 도구를 바꿔도 운영 분석의 뼈대는 유지된다.
장애 상황과 대응
eval이 없으면 prompt 변경 후 품질 회귀를 늦게 발견한다. observability가 없으면 운영 장애의 원인을 찾기 어렵다.
대표 장애:
- 특정 prompt version에서 validation 실패율 증가
- 특정 retrieval profile에서 source 누락
- 특정 tenant에서 token 비용 폭증
- fallback model 사용 후 품질 저하
대응은 trace를 eval case로 전환하는 것이다. 실제 장애 입력을 개인정보 제거 후 regression dataset에 넣는다.
인프라 협업 포인트
observability 도구는 비용과 보안 이슈가 있다.
- prompt/context 원문 저장 여부
- trace sampling 비율
- 고카디널리티 tag 제한
- 보존 기간
- self-hosted와 SaaS 선택
- 민감정보 마스킹
인프라팀은 trace volume을 걱정한다. 백엔드 개발자는 어떤 필드가 꼭 필요한지 설명해야 한다.
실전 팁
- eval dataset은 작게 시작해 장애마다 추가한다.
- trace id는 API, worker, provider, tool call에 모두 전달한다.
- 평균 점수보다 failure type을 남긴다.
- prompt version 없이 observability를 붙이면 분석 가치가 떨어진다.
위험 신호!
- 운영 trace가 있지만 prompt version이 없다.
- eval dataset이 정상 케이스만 있다.
- prompt/context 원문을 무제한 저장한다.
- LLM-as-a-judge 점수 하나로 출시를 결정한다.
- 장애 후 eval case를 추가하지 않는다.
확인 질문
확인 질문
- eval과 observability를 함께 써야 하는 이유는 무엇인가?
- eval은 변경을 사전에 검증하고 observability는 운영 중 실제 문제를 추적하기 때문이다.
- AI trace에 반드시 포함하면 좋은 정보는 무엇인가?
- prompt version, model, token usage, source id, validation status, trace id다.