OpenLLMetry
OpenTelemetry 표준으로 LLM 호출을 계측하는 확장
지표
GitHub API 에서 직접 읽은 값입니다
별 수 추이는 기록이 쌓인 뒤에 보여 줍니다 — 과거 값은 소급해 만들 수 없습니다.
무엇을 하는 도구인가
LLM 호출과 그 전후 체인(프롬프트, 완료 응답, 임베딩, 벡터DB 조회, 에이전트 단계 등)을 OpenTelemetry 스펙에 맞춰 자동으로 계측해, 운영 중 어떤 호출이 일어났고 어떤 입력·출력이 오갔는지를 추적 가능하게 만드는 SDK/확장입니다. 애플리케이션 코드에 수동으로 로깅을 심는 대신, 지원 라이브러리(LLM SDK, 프레임워크, 벡터DB 클라이언트 등)를 자동 계측해서 스팬(span) 형태로 데이터를 생성하고, 이를 표준 OTel 익스포터를 통해 원하는 백엔드로 전송합니다. 같은 관측 층의 Langfuse·Arize Phoenix·Opik 등이 자체 수집·저장·UI를 통합 제공하는 플랫폼형인 반면, OpenLLMetry는 계측 표준과 데이터 생성 부분에 집중하고 저장·분석·시각화는 OTel을 지원하는 별도 백엔드(자체 운영 또는 Traceloop의 관리형 서비스 등)에 맡기는 구조입니다.
이럴 때 고른다
- 이미 OpenTelemetry 기반 관측 스택(APM, 트레이싱 백엔드)을 운영 중이고 LLM 호출도 같은 파이프라인에 편입시키고 싶을 때
- 특정 벤더에 종속되지 않는 계측 표준으로 데이터를 생성해 두고, 분석 백엔드는 나중에 바꾸거나 복수로 두고 싶을 때
- 여러 LLM SDK·프레임워크·벡터DB 클라이언트를 한 애플리케이션에서 함께 쓰며 호출 체인을 하나의 트레이스로 엮어 보고 싶을 때
- 직접 호스팅할지 Traceloop의 관리형 백엔드를 쓸지 선택권을 열어 두고 싶을 때
어디까지만 하나
- 계측(데이터 생성) 중심의 확장이라, 수집된 트레이스를 실제로 보고 분석할 백엔드(자체 OTel 수집기·저장소·UI 또는 관리형 서비스)를 별도로 준비해야 합니다
- 프롬프트 품질 평가, 회귀 테스트, LLM-as-judge 같은 평가 기능은 이 도구의 핵심 영역이 아니므로 같은 층의 Promptfoo·DeepEval 같은 평가 도구와 조합이 필요할 수 있습니다
- 지원되지 않는 라이브러리나 커스텀 호출 경로는 자동 계측 범위에서 빠져 수동 계측을 추가해야 할 수 있습니다
- LLM 입출력 전체를 트레이스에 담을 경우 민감정보·개인정보가 관측 백엔드로 그대로 전송될 수 있어, 데이터 보존 정책과 마스킹 여부를 직접 검토해야 합니다
관측·평가 층은 무엇을 푸나
무엇이 호출됐고 왜 그 답이 나왔는지 기록하고, 바뀐 뒤에도 품질이 유지되는지 본다
언제 필요해지나 — 운영에 올린 뒤 — 이 층이 없으면 품질 저하를 알아차릴 방법이 없다
같은 층의 다른 도구
층이 같다는 것은 푸는 문제가 같다는 뜻입니다 — 비교가 되는 자리입니다
| 도구 | 하는 일 | 별 | 라이선스 |
|---|---|---|---|
| OpenLLMetry 보는 중 | OpenTelemetry 표준으로 LLM 호출을 계측하는 확장 | 7,495 | Apache-2.0 |
| Langfuse | 호출 추적·프롬프트 관리·평가를 한곳에서 보는 LLM 관측 도구 | 35,850 | — |
| Promptfoo | 프롬프트·모델을 테스트 케이스로 비교하고 회귀를 잡는 평가 도구 | 26,004 | MIT |
| Opik | 추적·평가·실험 비교를 함께 두는 오픈소스 LLM 플랫폼 | 22,616 | Apache-2.0 |
| DeepEval | 단위 테스트처럼 쓰는 LLM 출력 평가 프레임워크 | 18,879 | Apache-2.0 |
| Arize Phoenix | OpenTelemetry 기반 추적과 평가를 묶은 오픈소스 관측 도구 | 11,841 | — |
관련 용어
지표는 GitHub API 실측값입니다. 설명은 이 사이트가 작성했으며 공식 문서를 대체하지 않습니다 — 도입 전에 원문을 확인하세요.