목차
LLM 앱은 데모에서 잘 작동해도 운영에서는 프롬프트 변경, 검색 품질 저하, 도구 호출 실패, 비용 급증 때문에 쉽게 흔들린다. agentops 관점에서 필요한 관찰성은 일반 APM보다 LLM 호출·프롬프트·툴 사용·검색 단계·평가 결과를 이해하는 도구다.
비교 표
| 도구 | 강점 | 적합한 팀 |
|---|---|---|
| LangSmith | LangChain·LangGraph 네이티브 추적, 평가 데이터셋, 휴먼 어노테이션 | LangChain 생태계 중심 팀 |
| langfuse | 오픈소스, OpenTelemetry 기반, 프롬프트 관리·평가 통합 | 셀프호스팅과 데이터 통제가 필요한 팀 |
| Arize Phoenix | OpenInference·OpenTelemetry, RAG 평가, 노트북·Docker 실행 | RAG 평가를 깊게 해야 하는 팀 |
| Datadog LLM Observability | 인프라·APM·로그와 LLM 호출을 한 대시보드에서 연결 | 이미 Datadog을 쓰는 엔터프라이즈 |
| Lunary | 가벼운 설정, 비용 추적, 사용자 세션 분석 | 초기 제품팀과 빠른 계측이 필요한 팀 |
| TruLens | RAG Triad(답변 관련성·컨텍스트 관련성·근거성) 중심 평가 | 평가 우선 RAG 프로젝트 |
| Helicone | HTTP 프록시 방식, 빠른 요청 로깅·캐싱·비용 추적 | 코드 변경을 최소화하려는 팀 |
선택 기준
1. 프레임워크에 붙을 것인가, 독립 계층으로 둘 것인가
LangSmith는 LangChain·LangGraph를 쓰는 팀에 가장 자연스럽다. 반대로 여러 프레임워크와 직접 SDK 호출이 섞여 있다면 OpenTelemetry 기반의 Langfuse나 Phoenix가 더 오래 간다.
2. 평가가 핵심인가, 비용·요청 로깅이 핵심인가
RAG 품질과 환각을 줄이는 것이 목표라면 Phoenix나 TruLens처럼 평가 기능이 강한 도구가 우선이다. 초기 서비스에서 “누가 어떤 모델로 얼마를 쓰는지”가 더 급하면 Helicone이나 Lunary가 빠르다.
3. 기존 운영 스택과 연결할 것인가
이미 Datadog으로 인프라와 애플리케이션을 보고 있다면 LLM Observability 모듈을 추가하는 것이 조직 변경 비용이 낮다. 자체 호스팅과 데이터 주권이 중요하면 Langfuse, Phoenix, Helicone의 오픈소스 배포를 검토한다.
실무 도입 순서
- 모든 LLM 호출에 trace id, user id, session id를 붙인다.
- 토큰·비용·지연·에러율을 모델과 기능 단위로 본다.
- RAG라면 검색 결과, chunk id, 재랭킹 점수, 최종 답변을 한 trace에 묶는다.
- 좋은/나쁜 실제 요청을 평가 데이터셋으로 승격한다.
- 프롬프트 변경 전후의 회귀 평가를 배포 파이프라인에 넣는다.
관련 문서
- agentops — 에이전트 운영을 위한 관찰·제어 레이어
- langfuse — 오픈소스 LLM 관찰성 플랫폼
- rag — 검색 증강 생성 기본 구조
- llm-guardrails — 출력 품질과 안전성 제어
참고 자료
- LLM Observability Tools for Reliable AI Applications — Machine Learning Mastery (2026-05-12)