LLM 모니터링 도구 비교 2026 — Langfuse·LangSmith·Phoenix, 셀프호스팅과 과금 단위

LLM 모니터링(옵저버빌리티)은 서버 APM 의 LLM 판이 아니다. APM 은 「느린 요청」을 찾지만, LLM 애플리케이션에서 사고는 대개 빠르게 성공한 요청에서 난다 — 200 을 돌려주고 응답 시간도 정상인데 내용이 틀린 경우다. 그래서 봐야 하는 것이 지연·에러율이 아니라 입력 프롬프트 · 검색된 문맥 · 모델이 고른 도구 · 최종 출력의 연쇄다.

결론부터 말하면, 세 도구를 고르는 기준은 기능 목록이 아니라 셋이다. ① 셀프호스팅이 필수인가 ② 특정 프레임워크에 묶여도 되는가 ③ 우리 월 trace 수가 몇인가. 이 셋이 정해지면 선택은 거의 자동으로 좁혀지고, 반대로 기능표부터 보면 세 도구가 다 비슷해 보인다.

세 이름은 같은 층위가 아니다

비교표를 보기 전에 이 구분이 필요하다. 「Langfuse 대 LangSmith 대 Phoenix」로 나란히 놓으면 성격이 다른 것을 같은 칸에 넣게 된다.

마지막 줄이 중요하다. OpenTelemetry 의 GenAI 계열 규약은 제품이 아니라 계측 포맷이다. 세 도구가 이 규약을 얼마나 따르는지가 나중에 도구를 바꿀 때의 비용을 정한다. Phoenix 는 OpenInference 라는 OTel 확장을 쓰고, Langfuse 는 OTel 호환 수집 경로를 제공한다. LangSmith 는 LangChain 생태계 안에서 가장 매끄럽지만 그만큼 바깥으로 나갈 때 계측을 다시 깐다.

비교표 — 선택이 실제로 갈리는 축

금액은 적지 않는다. 이 영역의 무료 한도와 단가는 분기 단위로 바뀌어서, 글에 적어 두면 그 숫자가 틀린 채로 남는다. 금액은 결정일에 공급사 가격 페이지에서 직접 확인하고, 이 표에서는 과금 단위만 본다 — 단위가 다르면 같은 트래픽에서 비용 곡선의 모양이 다르다.

라이선스와 셀프호스팅이 먼저 갈린다

폐쇄망이거나 고객 데이터가 바깥으로 못 나가는 조건이면 이 한 줄에서 후보가 둘로 줄어든다. 그리고 「셀프호스팅이 된다」와 「셀프호스팅이 기본값이다」는 운영 부담이 다르다 — 전자는 우리가 Postgres·오브젝트 스토리지·업그레이드를 책임지는 구성이고, 후자는 노트북에서 한 줄로 뜨지만 영속화를 따로 설계해야 한다.

온프레미스 전체 구성을 어디까지 끌고 갈지는 온프레미스 LLM 구축 가이드에 따로 정리했다.

가격은 금액이 아니라 과금 단위를 본다

세 번째 줄이 가장 자주 과소평가된다. 입력 프롬프트와 검색된 문맥을 전부 저장하면 trace 하나가 수십 KB 가 되고, RAG 응답은 문맥이 커서 더 무겁다. 「무료니까 셀프호스팅」으로 시작해 보관 정책 없이 석 달을 돌리면 그 비용이 호스팅 요금을 넘기는 구간이 온다.

우리 trace 수를 먼저 센다 — 30분 절차

플랜의 「월 trace N건」과 우리가 생각하는 「요청 N건」은 같은 단위가 아니다. 이것을 맞춰 보지 않고 플랜을 고르면 둘 중 하나가 된다 — 과하게 큰 플랜을 사거나, 둘째 주에 한도를 넘긴다.

trace · span · observation 이 각각 세어진다

대체로 trace 하나 = 사용자 요청 하나이고, 그 안의 단계 하나하나가 span(또는 observation)으로 쌓인다. 그래서 같은 「요청 1건」이 구성에 따라 이렇게 갈린다.

측정 절차는 이렇게 한다.

1. 대표 요청 10건을 실제 구성으로 돌리고 관측 수를 센다. 가장 단순한 것과 가장 복잡한 것을 둘 다 넣는다.
2. 요청당 관측 수의 중위수와 최대치를 적는다. 평균만 적으면 에이전트의 긴 턴이 가려진다.
3. 월 요청 수를 곱한다. 이때 배치·재시도·평가 실행을 빼먹지 마라 — 야간 평가 작업이 프로덕션 트래픽보다 큰 경우가 흔하다.
4. trace 하나의 바이트 크기를 같이 재라. 보관 기간을 곱하면 스토리지 추정이 나온다.
5. 그 숫자로 샘플링 비율을 정한다. 전량 수집은 기본값이 아니라 선택이다.

샘플링은 균일하게 걸지 마라. 에러·낮은 평가 점수·비정상 지연이 붙은 trace 는 전량 남기고, 성공한 평범한 요청만 비율로 줄이는 것이 맞다. 사고 분석은 꼬리에서 하는 일이고, 균일 샘플링은 그 꼬리를 똑같은 비율로 버린다.

OpenTelemetry 를 기준으로 두면 교체 비용이 내려간다

지금 고른 도구를 1년 뒤에도 쓸 거라고 가정하지 않는 것이 안전하다. 이 분야는 제품 수명이 짧고 가격 모델이 자주 바뀐다. 그래서 계측을 도구 SDK 가 아니라 규약에 맞춰 깔아 두면, 수집기 주소만 바꿔 다른 도구로 보낼 수 있다.

실무에서 이 선택이 갈리는 지점은 하나다 — 프레임워크가 제공하는 자동 계측을 쓸 것인가. 자동 계측은 첫날이 빠르고, 대신 그 프레임워크를 떠날 때 계측이 같이 떠난다. 중립 규약으로 깔면 첫 설정이 하루 더 걸리고 교체가 거의 공짜가 된다.

LangGraph 로 짠 구성에 계측을 붙이는 쪽은 LangGraph 챗봇 만들기의 구조를 먼저 보면 어디에 trace 경계를 둘지가 잡힌다. 에이전트가 여러 개로 늘어나면 경계 설계가 더 중요해진다 — 멀티 에이전트 시스템에 정리한 조율 구조가 그대로 trace 트리가 된다.

평가를 도구 안에서 돌릴 것인가, 밖에서 돌릴 것인가

세 도구 모두 평가 기능을 갖고 있지만 무게중심이 다르다. Phoenix 는 평가를 중심에 두고 설계됐고, Langfuse 는 데이터셋과 LLM-as-judge 를 운영 흐름에 붙이는 쪽이고, LangSmith 는 LangChain 코드와의 거리가 가장 짧다.

판단 기준은 「평가 결과를 누가 보는가」다. 개발자만 보면 도구 안에서 돌리는 것이 빠르다. 도메인 전문가가 라벨을 붙이고 그 라벨이 회귀 테스트가 되는 단계면, 평가 데이터셋을 도구 밖(우리 저장소)에 두고 도구를 실행기로만 쓰는 쪽이 오래 간다. 도구를 바꿀 때 라벨이 따라오기 때문이다.

RAG 쪽 평가 지표를 어떻게 잡을지는 RAG 시스템 도입 전 알아야 할 3가지에 따로 적었다.

프롬프트 관리까지 붙일 것인가

프롬프트를 도구에 올려 두면 코드 배포 없이 문구를 바꿀 수 있다. 장점이 분명한 만큼 대가도 분명하다 — 프롬프트가 코드 리뷰와 git 이력 밖으로 나간다.

섞는 구성이 실무에서 가장 많다. 뼈대(역할·금지사항·출력 형식)는 저장소에, 자주 손보는 문구와 예시만 도구에 둔다. 다만 프롬프트가 둘로 나뉘면 「지금 프로덕션에 뭐가 들어가 있나」를 한 곳에서 못 본다 — 그래서 최종 조립된 프롬프트를 trace 에 그대로 남겨야 한다. 이것을 안 남기면 사고가 났을 때 재현이 안 된다.

용도별 선택 — 네 가지 경우

마지막 줄이 가장 저평가된다. 도구 선택을 미루는 것이 아무것도 안 하는 것은 아니다 — 규약에 맞춘 계측을 먼저 깔아 두면 그 사이에 쌓인 trace 가 나중에 어느 도구로든 들어간다.

국내에서 먼저 걸리는 것 — 데이터 소재와 개인정보

trace 에는 사용자가 쓴 문장이 그대로 들어간다. 그래서 이 도구는 로그 시스템이 아니라 개인정보가 흐르는 경로로 취급해야 한다. 실무에서 걸리는 순서는 대개 이렇다.

• 소재 — 해외 호스팅이면 국외 이전 사안이 된다. 처리위탁·이전 고지 범위를 먼저 확인한다.
• 마스킹 위치 — 도구에 들어가기 전에 지워야 한다. 들어간 뒤 가리는 설정은 「저장은 됐다」는 뜻이다.
• 보관 기간 — 사고 분석에 필요한 기간과 최소 수집 원칙이 부딪히는 자리다. 기간을 먼저 정하고 그에 맞춰 샘플링을 설계한다.
• 접근 권한 — 프롬프트 전문이 보이는 화면은 CS·마케팅까지 열어 줄 대상이 아니다.

프롬프트로 들어오는 공격을 어디서 막을지는 프롬프트 인젝션 방어에 따로 정리했다. 관측 도구는 공격을 막지 않지만 사후에 무엇이 들어왔는지 보여 주는 유일한 경로라, 둘은 같이 설계한다.

Langfuse 를 올려 보는 최소 경로

「써 보고 정한다」가 가장 빠른 영역이다. 셀프호스팅 쪽 최소 경로는 이렇다.

git clone https://github.com/langfuse/langfuse
cd langfuse
docker compose up -d        # Postgres·서버·워커가 함께 뜬다
# 브라우저로 접속 → 조직·프로젝트 생성 → 공개/비밀 키 발급

그다음 애플리케이션 쪽에서 키를 넣고 대표 요청 10건을 흘려 보낸 뒤, 위의 측정 절차대로 요청당 관측 수와 trace 바이트 크기를 적는다. 이 10건이 플랜 선택의 근거가 된다 — 공급사 페이지의 숫자를 보고 역산하지 말고, 우리 숫자를 먼저 만든 뒤 플랜을 맞춘다.

운영으로 넘기기 전에 둘을 정해 둔다. 보관 기간과 마스킹 지점이다. 이 둘은 나중에 바꾸면 이미 저장된 데이터를 손봐야 하므로, 시작할 때 정하는 것이 가장 싸다.

사람이 받아야 하는 요청을 어디서 끊을지는 RAG 챗봇 운영 경계에 적었다 — 관측 지표가 그 경계를 정하는 근거가 된다.

자주 묻는 질문

Q: 이미 Datadog 이나 기존 APM 이 있는데 또 필요한가요?

필요한 경우가 많다. APM 은 요청 단위 성능을 보지만, 프롬프트·검색 문맥·도구 호출 인자를 구조화해 보여 주지 않는다. 다만 둘을 따로 두면 같은 사고를 두 화면에서 쫓게 되니, trace ID 를 공유하도록 맞춰 두는 것이 좋다.

Q: 셀프호스팅이 정말 무료인가요?

소프트웨어 비용이 0인 것과 총비용이 0인 것은 다르다. 서버·DB·스토리지·업그레이드·백업이 우리 몫으로 넘어온다. trace 보관량이 커지는 구간에서는 호스팅 요금을 넘기는 경우도 있다 — 그래서 위의 바이트 크기 측정이 필요하다.

Q: 전량 수집해야 하나요?

아니다. 다만 버릴 것을 고르는 규칙이 필요하다. 에러·저평가·비정상 지연은 전량 남기고 평범한 성공 요청만 비율로 줄인다. 균일 샘플링은 사고 분석에 필요한 꼬리를 같은 비율로 버린다.

Q: LangSmith 를 쓰면 LangChain 에 묶이나요?

계측은 묶인다. 애플리케이션 코드까지 묶이는 것은 아니지만, 다른 도구로 옮길 때 계측을 다시 깔아야 한다. 그 비용이 걱정되면 중립 규약으로 먼저 깔고 수집기만 그쪽으로 보내는 구성이 가능하다.

Q: 평가 점수가 떨어졌는데 원인을 어떻게 찾나요?

점수만으로는 못 찾는다. 같은 trace 안에 검색된 문맥이 남아 있어야 원인이 검색 품질인지 생성인지 갈린다. 그래서 trace 에 무엇을 남길지가 평가보다 먼저 정해져야 한다.

정리

LLM 모니터링 도구 선택은 기능표 비교가 아니라 세 질문이다 — 셀프호스팅이 필수인가, 프레임워크에 묶여도 되는가, 우리 월 관측 수가 몇인가. 세 번째는 대표 요청 10건으로 30분 안에 셀 수 있고, 그 숫자가 없으면 어떤 플랜 비교도 추측이 된다.

그리고 도구보다 오래 사는 것은 계측 규약과 평가 라벨이다. 둘을 우리 쪽에 두면 도구는 언제든 바꿀 수 있고, 둘을 도구 안에 두면 도구가 우리를 고른다.