AI 에이전트 관측 도구는 기능표보다 운영 방식과 데이터 경계로 골라야 한다. 빠른 SaaS 도입과 팀 워크플로가 우선이면 LangSmith, 오픈소스와 프롬프트·평가의 균형은 Langfuse, 로컬 분석과 OpenTelemetry 기반 실험은 Phoenix가 유리하다. OpenTelemetry는 이들과 경쟁하는 완성형 화면이 아니라 trace를 특정 제품에서 분리하는 수집 표준에 가깝다.
핵심 요약
- Langfuse: 자체 호스팅과 클라우드를 모두 고려하며 관측·프롬프트 관리·평가를 한곳에 묶고 싶을 때 적합하다.
- LangSmith: SaaS로 빨리 시작하고 대시보드·알림·온라인 평가·팀 협업을 붙일 때 편하다.
- Phoenix: OTLP와 OpenInference를 중심으로 로컬 디버깅, 평가, 데이터셋 실험을 구성할 때 강하다.
- OpenTelemetry: 교체 가능한 수집 계층을 만들고 기존 APM·백엔드와 연결할 때 먼저 깔아둘 표준이다.
- 도구를 고르기 전에 trace ID, 사용자·팀, 모델, 비용, 지연, 오류, 평가 점수 속성을 먼저 정해야 한다.
네 도구의 역할은 완전히 같지 않다
Langfuse·LangSmith·Phoenix는 trace를 저장하고 탐색하며 평가와 운영 화면을 제공하는 플랫폼이다. 반면 OpenTelemetry는 애플리케이션에서 span·metric·log를 만들고 OTLP로 보내기 위한 계측 규약과 SDK·Collector 생태계다. 따라서 “OpenTelemetry와 Langfuse 중 하나”보다 “OpenTelemetry로 계측하고 Langfuse나 Phoenix로 본다”는 조합이 더 자연스러울 수 있다.
| 선택지 | 가장 잘 맞는 상황 | 강점 | 먼저 확인할 제약 |
|---|---|---|---|
| Langfuse | 오픈소스·자체 호스팅과 관리형 클라우드를 함께 검토 | trace, prompt, eval, 비용·지연 분석을 통합 | 자체 호스팅 시 DB·스토리지·업그레이드 운영 |
| LangSmith | 소규모 팀이 SaaS로 빠르게 관측과 평가를 시작 | 대시보드, 알림, 자동화, 피드백 흐름 | 좌석·trace·저장 사용량과 데이터 반출 정책 |
| Phoenix | 로컬 우선 분석, RAG·에이전트 실험, OTLP 연계 | OpenInference, 평가, 데이터셋·실험 기능 | 운영형 접근 제어·보존·백업 설계 |
| OpenTelemetry | 특정 관측 제품에 종속되지 않는 계측 계층 | 표준 속성, OTLP, Collector, 기존 APM 연계 | 완성형 AI 관측 UI가 아니므로 백엔드가 별도로 필요 |
출처: 각 제품 공식 문서(2026-08-18 확인)

출처: 각 제품 공식 문서 기반 자체 정리
Langfuse: 자체 호스팅과 통합 기능의 균형
Langfuse는 관측, 프롬프트 버전 관리, 평가를 같은 플랫폼에 넣는다. 공식 문서는 Python·JavaScript SDK, 다수의 프레임워크 통합, OpenTelemetry, LiteLLM 같은 게이트웨이를 통한 trace 수집을 안내한다. 세션과 사용자 단위로 비용·사용량을 묶고 에이전트 그래프와 타임라인을 보는 흐름도 갖춘다.
2026년 8월 18일 공식 가격표 기준 Langfuse Cloud Hobby는 월 5만 unit과 30일 데이터 접근을 포함한 무료 구간이다. Core는 월 29달러에 10만 unit과 90일 데이터 접근을 포함하며 초과분은 10만 unit당 8달러로 안내한다. Pro는 월 199달러와 3년 데이터 접근을 제시한다. unit 정의와 이벤트 크기에 따라 실제 비용이 달라지므로 “trace 개수”만으로 예산을 잡으면 안 된다.
자체 호스팅은 라이선스 비용을 줄일 수 있지만 무료 운영을 뜻하지 않는다. trace 본문에는 프롬프트, 검색 문서, 도구 입력·출력이 들어가므로 데이터베이스 용량, 객체 스토리지, 백업, 암호화, 버전 업그레이드 비용을 함께 계산해야 한다.
LangSmith: SaaS로 빠르게 운영 루프를 만들 때
LangSmith 공식 문서는 개별 trace 탐색뿐 아니라 대시보드, 알림, 규칙·웹훅 자동화, 온라인 평가, 사람 피드백 큐를 한 흐름으로 제공한다. LangChain 전용으로 오해하기 쉽지만 OpenAI, Anthropic, CrewAI, Vercel AI SDK, Pydantic AI 등 여러 통합을 안내한다.
현재 가격표의 Developer는 좌석당 0달러이며 월 5천 base trace 이후 사용량 과금 구조다. Plus는 좌석당 월 39달러에 월 1만 base trace를 포함한다. Enterprise에는 자체 호스팅·하이브리드 배포, SSO와 세분화된 권한 기능이 표시돼 있다. 팀이 빨리 시작하기는 쉽지만 trace·저장·좌석이 각각 어떤 단위로 늘어나는지 부하 테스트 데이터로 확인해야 한다.
데이터를 외부 SaaS로 보낼 수 없는 환경이라면 도입 속도보다 반출 정책이 우선이다. 프롬프트와 검색 결과에 개인정보나 영업 비밀이 섞일 수 있으므로 저장 전 마스킹과 payload 샘플링을 애플리케이션 계층에서 적용해야 한다.
Phoenix: OTLP 기반 로컬 분석과 평가 실험
Arize Phoenix는 OpenTelemetry 위에서 동작하며 OpenInference 계측을 사용한다. 공식 문서에 따르면 trace는 모델 호출, 검색, 도구 사용, 사용자 로직을 한 실행으로 묶는다. OTLP 수신과 함께 LlamaIndex, LangChain, DSPy, Mastra, Vercel AI SDK, OpenAI, Bedrock, Anthropic 등에 대한 자동 계측을 제공한다.
평가는 LLM 기반 평가자, 코드 기반 검사, 사람 라벨을 trace와 span에 붙이는 방식이다. Ragas·DeepEval 같은 외부 평가 도구도 연결할 수 있다. 로컬에서 RAG 검색 실패를 살피고 데이터셋 실험으로 이어가려는 팀에 특히 잘 맞는다. 다만 노트북에서 잘 보이는 것과 다중 사용자 운영은 다른 문제다. 인증, RBAC, 데이터 보존, 백업, 고가용성을 별도 체크리스트로 다뤄야 한다.
OpenTelemetry: 도구 교체 비용을 줄이는 수집 계층
OpenTelemetry의 Generative AI semantic conventions에는 에이전트 span, 모델·제공자별 span, 이벤트와 metric을 표현하는 항목이 정리돼 있다. 이 규약으로 계측하면 애플리케이션 코드가 특정 관측 제품의 데이터 모델에 깊게 묶이는 문제를 줄일 수 있다.
하지만 표준 속성을 붙였다고 운영 화면이 자동으로 생기지는 않는다. Collector의 메모리 제한, 배치 전송, 재시도, 백프레셔, 민감정보 필터, 샘플링을 설계해야 하고, 실제 저장·검색·알림을 담당할 백엔드도 필요하다. 소규모 서비스는 완성형 플랫폼으로 먼저 문제를 정의한 뒤 OTLP export를 병행하는 편이 과도한 초기 설계를 피하기 쉽다.
도입 전에 반드시 정할 데이터 스키마
도구 화면보다 먼저 “실패한 사용자 작업 하나를 어떻게 찾을 것인가”를 정해야 한다. 최상위 trace는 사용자 목표 한 건으로 잡고 모델 호출, 검색, 도구 실행, 승인 단계를 자식 span으로 둔다. 이는 기존 AI 에이전트 관측성 가이드와 AI 에이전트 비용 추적 가이드의 운영 모델을 실제 제품 선택에 연결하는 핵심이다.
- 식별자: trace_id, session_id, user_id, team_id, project_id, environment를 넣는다.
- 모델 호출: provider, model, input/output token, cache read/write, latency, retry를 분리한다.
- 도구 실행: tool_name, duration, status, error_type, approval 여부를 기록한다.
- 품질: 정답성, 근거성, 도구 선택, 정책 위반 여부를 평가 점수로 붙인다. 평가 설계는 AI Evals 실무 가이드처럼 작은 대표 질문 세트부터 시작한다.
- 비용: 성공 실행당 비용과 실패 비용을 분리하고 가격표 버전을 보존한다.
2주 파일럿 절차
| 단계 | 해야 할 일 | 통과 기준 |
|---|---|---|
| 1. 범위 | 사용자 작업 한 종류와 실패 유형 세 개를 고른다. | trace 한 건으로 전체 실행을 재구성할 수 있다. |
| 2. 계측 | LLM·검색·도구·승인 span과 비용 속성을 넣는다. | 누락 span 비율과 비용 오차를 측정한다. |
| 3. 보안 | 프롬프트·문서·도구 결과에서 민감정보를 마스킹한다. | 원문 secret과 개인정보가 저장되지 않는다. |
| 4. 부하 | 정상·오류·대용량 payload를 포함해 1주일 수집한다. | 수집 지연, 저장량, 예상 월비용을 계산한다. |
| 5. 운영 | 실패율·p95 지연·성공 실행당 비용 알림을 만든다. | 실제 장애 한 건을 대시보드에서 찾아 원인을 좁힌다. |
실패하기 쉬운 조건
- 모든 프롬프트와 검색 문서를 무제한 저장해 비용과 보안 위험이 함께 커진다.
- trace 이름과 속성이 팀마다 달라 대시보드 집계가 깨진다.
- 성공률만 보고 결과 품질과 사람 승인 거부율을 측정하지 않는다.
- LLM 비용만 기록하고 검색 API, 브라우저, 코드 샌드박스, 재시도 비용을 뺀다.
- 자체 호스팅을 선택하면서 백업·업그레이드·보존 정책의 운영 인건비를 0원으로 계산한다.
FAQ
LangChain을 쓰지 않아도 LangSmith를 쓸 수 있나?
쓸 수 있다. 공식 문서는 여러 모델 제공자와 에이전트 프레임워크 통합을 안내한다. 다만 현재 코드의 계측 난이도와 필요한 SDK 변경량은 파일럿에서 확인해야 한다.
OpenTelemetry만 설치하면 AI 에이전트 관측이 끝나나?
끝나지 않는다. OpenTelemetry는 수집과 전송의 표준 계층이다. trace 검색, 비용 계산, 평가, 알림, 보존을 담당할 백엔드와 운영 규칙이 별도로 필요하다.
처음에는 어떤 도구로 시작하는 편이 좋은가?
외부 SaaS 사용이 가능하면 LangSmith나 Langfuse Cloud로 2주 파일럿을 빠르게 돌리는 편이 단순하다. 데이터 반출이 어렵거나 로컬 RAG 분석이 중심이면 Langfuse 자체 호스팅이나 Phoenix를 먼저 검토한다. 어떤 선택이든 OTLP export 가능성과 데이터 내보내기 경로를 확인해야 한다.
참고 자료
- Langfuse 공식 문서
- Langfuse Cloud 공식 가격표
- LangSmith Observability 공식 문서
- LangSmith 공식 가격표
- Arize Phoenix 공식 문서
- OpenTelemetry Generative AI semantic conventions