작성자 Matt Connor
셀프호스팅 LLM 관측성 도구 4개 비교
Langfuse, Arize Phoenix, Helicone, OpenTelemetry를 VPS 운영 비용 기준으로 비교한다. 필요한 데이터스토어와 RAM 하한, 라이선스 제약, 개인정보 국외 이전 판단까지 정리했다. 트레이스가 늘면 무엇이 먼저 깨지는지도 짚는다.
셀프호스팅 LLM 관측성, 무엇을 고를지부터
셀프호스팅 LLM 관측성 도구는 현실적으로 네 가지 중 하나다. Langfuse, Arize Phoenix, Helicone, 그리고 OpenTelemetry 기반의 직접 구성이다. 기능 목록만 늘어놓고 비교하면 대개 Langfuse가 이긴다. 그런데 VPS 한 대에서 운영할 때 결과를 바꾸는 것은 기능이 아니라 각 도구가 함께 끌고 들어오는 데이터스토어다.
관측성(observability)은 실행 중인 애플리케이션이 무엇을 했는지 밖에서 확인할 수 있는 상태를 말한다. LLM 애플리케이션에서 그 대상은 프롬프트, 모델 응답, 도구 호출, 토큰 수, 지연 시간이다. 이 기록의 단위를 트레이스(trace)라고 부르고, 트레이스 안의 각 구간을 스팬(span)이라고 부른다. 네 도구 모두 결국 스팬을 받아서 저장하고 화면에 그려 주는 프로그램이다.
이 글은 그 네 가지를 운영 비용 기준으로 비교한다. 어떤 데이터스토어를 요구하는지, RAM 하한이 어디쯤인지, 라이선스가 무엇이고 셀프호스팅판에서 빠지는 기능이 무엇인지, 트레이스 양이 늘면 무엇이 먼저 깨지는지를 본다. 마지막은 순위가 아니라 상황별 선택표다. 혼자 에이전트 하나를 추적하는 사람과 평가 파이프라인을 돌리는 팀은 정답이 다르기 때문이다.
아래 설치 명령과 compose 예시는 공식 문서에서 확인한 형태를 그대로 옮긴 것이다. 독자가 직접 실행해 보는 예시로 읽어야 한다. 이 글을 쓰면서 각 명령을 테스트 컨테이너에서 실행해 검증하지는 않았으므로, 측정값처럼 읽히는 문장은 쓰지 않았다.
왜 셀프호스팅을 먼저 고민하게 되는가: 트레이스에는 원문이 남는다
트레이스는 로그가 아니다. 요청 하나가 시스템을 통과한 전체 기록이고, 거기에는 프롬프트 원문, 사용자가 입력한 문장, 검색 도구가 돌려준 문서, 모델이 만든 답변이 그대로 들어간다. 즉 관측성을 켜는 순간 대화 원문 보관소가 하나 생긴다.
고객 문의를 처리하는 에이전트라면 그 보관소에 이름, 연락처, 주문 번호, 결제 관련 문의가 같이 저장된다. 이 데이터를 미국 SaaS로 보내면 개인정보의 국외 이전에 해당한다. 개인정보보호법은 국외 이전에 별도의 근거를 요구한다(2023년 개정으로 정비된 제28조의8). 동의, 법령이나 조약, 계약 이행에 필요한 경우의 고지, 인증, 적정성 인정 중 어떤 근거로 처리하는지 설명할 수 있어야 한다.
이 글은 법률 자문이 아니고, 구체적 판단은 법무 검토의 영역이다. 엔지니어가 알아야 할 부분만 분명히 하면 된다: 트레이스 목적지를 정하는 일은 아키텍처 결정이 아니라 규정 준수 결정이다. 그래서 국내 팀에서는 도구 비교보다 목적지 결정이 먼저 온다.
선택지는 세 방향이다. 리전을 고르는 방법(예를 들어 Langfuse 클라우드는 EU, US, 일본 리전을 운영한다), 보내기 전에 애플리케이션 코드에서 개인정보를 지우는 방법, 그리고 직접 호스팅하는 방법이다. 국내 VPS에 직접 올리면 국외 이전 논의 자체가 사라진다. 그 대가가 이 글의 나머지 내용이다.
Langfuse: 기능이 가장 많고 컨테이너도 가장 많다
Langfuse는 트레이스 수집, 프롬프트 버전 관리, 평가, 데이터셋을 한 화면에서 다룬다. 핵심 기능과 API는 MIT 라이선스이고 무료판에 사용량 제한이 없다고 문서에 명시되어 있다. 셀프호스팅에서 가장 자주 추천되는 이유가 이것이다.
git clone https://github.com/langfuse/langfuse.git
cd langfuse
docker compose up -d
docker compose psdocker compose ps가 여섯 개 서비스를 healthy로 보여 주면 정상이다. 그 여섯 개는 langfuse-web, langfuse-worker, postgres, clickhouse, redis, minio다. 즉 애플리케이션 컨테이너 두 개와 데이터스토어 네 개다. ClickHouse는 선택 사항이 아니다. 문서는 "ClickHouse is currently a required component for self-hosting Langfuse"라고 못 박고 있고, 다른 OLAP(온라인 분석 처리) 데이터베이스는 지원하지 않는다. Postgres 하나로 대체하는 구성은 없다.
기본 compose 파일에서 langfuse-web은 3000 포트를, minio는 9090 포트를 모든 인터페이스에 열고, 나머지 서비스는 127.0.0.1에만 바인딩한다. 공용 IP가 붙은 VPS라면 이 두 포트가 그대로 인터넷에 노출된다는 뜻이다. 리버스 프록시와 방화벽을 먼저 준비하고 올리자. ss -ltnp | grep -E '3000|9090'으로 실제 바인딩 주소를 확인할 수 있다.
자원 권장값도 문서에 있다. VM 배포 기준으로 4코어 16GiB 메모리와 100GiB 정도의 저장 공간을 권장하고, 컨테이너 기준으로는 프로덕션에서 최소 2 CPU와 4GB RAM을 권장한다. 한 가지 함정도 같이 적혀 있다: Node.js는 컨테이너에 할당된 메모리와 무관하게 기본 힙을 약 1.7GiB로 잡으므로 NODE_OPTIONS로 힙 한도를 직접 지정해야 한다.
애플리케이션에서 보내는 쪽은 OpenTelemetry 표준을 그대로 쓴다.
AUTH=$(printf '%s' 'pk-lf-PUBLIC:sk-lf-SECRET' | base64 -w 0)
export OTEL_EXPORTER_OTLP_ENDPOINT='https://langfuse.example.com/api/public/otel'
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Basic ${AUTH},x-langfuse-ingestion-version=4"인증은 Basic Auth이고, x-langfuse-ingestion-version=4 헤더는 새 데이터가 v4 데이터 모델 화면에 실시간으로 보이게 한다. 설치와 첫 트레이스까지 단계별로 따라가려면 Langfuse로 에이전트 트레이스를 수집하는 설치 가이드를 같이 보면 된다.
Arize Phoenix: 컨테이너 하나로 시작한다
Phoenix는 반대쪽 극단이다. 데이터스토어를 하나도 요구하지 않는 구성이 존재한다. 기본값은 SQLite이고, 볼륨 하나만 붙이면 끝난다.
docker run -d --name phoenix \
-p 6006:6006 -p 4317:4317 \
-e PHOENIX_WORKING_DIR=/mnt/data \
-v phoenix-data:/mnt/data \
arizephoenix/phoenix:latest6006 포트가 UI와 OTLP/HTTP 수집기를 함께 제공하고, 4317 포트가 OTLP/gRPC 수집기다. OTLP HTTP로 보낼 때 트레이스 경로는 /v1/traces다. 문서는 프로덕션에서 latest 대신 사용할 버전을 고정하라고 권한다. 그대로 따르자. 관측성 도구가 어느 날 말없이 올라가면 화면이 바뀌고 저장 스키마도 바뀐다.
동시 수집량이 늘면 Postgres로 옮긴다. 문서는 PostgreSQL 14 이상을 요구한다.
services:
phoenix:
image: arizephoenix/phoenix:latest
depends_on:
- db
ports:
- "6006:6006"
- "4317:4317"
environment:
- PHOENIX_SQL_DATABASE_URL=postgresql://postgres:postgres@db:5432/postgres
db:
image: postgres:17
environment:
- POSTGRES_PASSWORD=postgres
volumes:
- phoenix-db:/var/lib/postgresql/data
volumes:
phoenix-db:공용 IP에 올릴 때 반드시 확인할 항목이 하나 있다. Phoenix는 인증이 기본으로 꺼져 있다. 즉 6006 포트를 그냥 열면 누구나 프롬프트 전문을 읽는다. 켜는 방법은 환경 변수 두 개다.
-e PHOENIX_ENABLE_AUTH=True
-e PHOENIX_SECRET=<32자 이상, 숫자와 대소문자 섞인 임의 문자열>문서에 적힌 주의 사항도 같이 기억하자. 인증을 켜면 API 접근이 전부 막히고 API 키를 만들 때까지 트레이스 수집도 멈춘다. 이미 돌고 있는 인스턴스라면 작업 시간을 잡고 켜야 한다.
라이선스는 주의해서 읽어야 한다. Phoenix는 Elastic License 2.0(ELv2)이다. 사내에서 쓰는 것은 자유롭지만 이 소프트웨어를 관리형 서비스로 만들어 제공하는 것은 허용되지 않는다. OSI 기준의 오픈소스가 아니므로, 사내 표준 라이선스 정책이 있는 조직은 도입 전에 확인이 필요하다.
Helicone: 게이트웨이 쪽에서 보는 관측성
Helicone은 SDK 계측이 아니라 프록시 경로에 초점이 있다. LLM 호출을 한 지점으로 모아 요청과 응답, 비용, 캐시 적중을 기록한다. 모든 호출을 한 지점으로 모으는 발상 자체는 LiteLLM 게이트웨이를 직접 운영하는 구성과 겹치므로, 이미 게이트웨이가 있다면 역할이 중복되는지 먼저 확인하자.
docker pull helicone/helicone-all-in-one:latest
docker run -d --name helicone \
-p 3000:3000 -p 8585:8585 -p 9080:9080 \
helicone/helicone-all-in-one:latest3000 포트가 대시보드, 8585가 Jawn API, 9080이 MinIO S3 저장소다. 이 단일 이미지 안에 Postgres, ClickHouse, MinIO가 함께 들어 있다. 컨테이너는 하나지만 데이터스토어는 셋이다. 문서에 굵게 적혀 있는 경고를 그대로 옮기면: 볼륨을 붙이지 않으면 컨테이너를 재시작할 때 데이터가 전부 사라진다. 프로덕션에서는 Postgres, ClickHouse, MinIO 각각의 데이터 경로에 볼륨을 붙여야 한다.
라이선스는 Apache 2.0이다. 네 도구 중 조건이 가장 단순하다. 대신 all-in-one 이미지는 평가와 소규모 운영을 겨냥한 형태이고, 프로덕션 규모에서는 별도의 Helm 차트를 엔터프라이즈 문의로 안내한다. 즉 라이선스는 열려 있지만 손이 많이 가는 쪽은 배포 형태다.
OpenTelemetry와 OpenLLMetry: 벤더를 고르지 않는 구성
네 번째 선택은 전용 도구를 쓰지 않는 것이다. OpenLLMetry는 Traceloop이 만든 Apache 2.0 라이선스 SDK로, LLM 호출과 벡터 데이터베이스, 프레임워크 호출을 OpenTelemetry 스팬으로 변환한다. 도착지는 표준 OTLP를 받는 아무 백엔드나 될 수 있다.
pip install traceloop-sdkfrom traceloop.sdk import Traceloop
Traceloop.init(api_endpoint="http://127.0.0.1:4317", disable_batch=True)api_endpoint를 http 또는 https로 시작하면 OTLP/HTTP를, 그렇지 않으면 OTLP/gRPC를 쓴다. SDK가 뒤에 /v1/traces를 붙여 준다. 환경 변수로 지정할 때는 TRACELOOP_BASE_URL과 TRACELOOP_HEADERS를 쓴다. disable_batch=True는 개발 중에 스팬이 즉시 넘어가게 해서 화면에 아무것도 안 보일 때 원인을 좁히는 데 도움이 된다.
받는 쪽은 예를 들어 Jaeger다. 2026년 9월 기준 최신 계열 태그를 고정해서 올린다.
docker run -d --name jaeger \
-p 16686:16686 -p 4317:4317 -p 4318:4318 \
cr.jaegertracing.io/jaegertracing/jaeger:2.21.016686 포트가 UI이고 4317과 4318이 OTLP 수집 포트다. 여기서 반드시 직접 확인할 항목이 있다. all-in-one 이미지는 기본 구성에서 트레이스를 영속 저장하지 않는 경우가 많으므로, 컨테이너를 한 번 재시작해 보고 트레이스가 남아 있는지 확인하자. 남아 있지 않으면 Cassandra, Elasticsearch, OpenSearch 같은 스토리지 백엔드를 붙여야 한다.
이 구성의 장점은 분명하다. LLM 스팬이 일반 애플리케이션 스팬과 같은 파이프라인에 들어가므로, HTTP 요청부터 모델 호출까지 하나의 트레이스로 이어진다. 단점도 분명하다. 프롬프트 비교, 프롬프트 버전 관리, 평가 실행 같은 LLM 전용 화면이 없다. 토큰과 비용 집계도 직접 만들어야 한다. Jaeger는 스팬을 보여 주는 도구이지 프롬프트를 다루는 도구가 아니다.
데이터스토어와 RAM을 숫자로 비교하면
아래 표의 datastores는 각 구성이 요구하는 데이터스토어 개수이고, ram_floor_gb는 그 구성으로 VPS 한 대에 올릴 때의 추정 하한이다. 앞의 숫자는 공식 문서와 compose 정의에서 센 값이고, 뒤의 숫자는 구성에서 계산한 추정값이다. 측정값이 아니며 실제 사용량은 트레이스 양과 보존 기간에 따라 달라진다.
The data behind this chart
[
{
"tool": "Langfuse v4",
"datastores": 4,
"ram_floor_gb": 8,
"notes": "Postgres, ClickHouse, Redis, MinIO \ud544\uc218. \ubb38\uc11c VM \uad8c\uc7a5\uc740 4\ucf54\uc5b4 16GiB"
},
{
"tool": "Helicone all-in-one",
"datastores": 3,
"ram_floor_gb": 6,
"notes": "\ub2e8\uc77c \uc774\ubbf8\uc9c0 \uc548\uc5d0 Postgres, ClickHouse, MinIO \ub0b4\uc7a5"
},
{
"tool": "Phoenix + Postgres",
"datastores": 1,
"ram_floor_gb": 2,
"notes": "SQLite \ubaa8\ub4dc\ub85c \uc4f0\uba74 \ub370\uc774\ud130\uc2a4\ud1a0\uc5b4 0\uac1c"
},
{
"tool": "OpenLLMetry + Jaeger",
"datastores": 0,
"ram_floor_gb": 1,
"notes": "\uc601\uc18d \uc800\uc7a5\uc744 \ubd99\uc774\uba74 \uc2a4\ud1a0\ub9ac\uc9c0 \ubc31\uc5d4\ub4dc \ube44\uc6a9\uc774 \ucd94\uac00\ub41c\ub2e4"
}
]차이가 큰 쪽은 RAM보다 운영 대상 개수다. Langfuse는 데이터스토어 4개를 함께 운영하겠다는 결정이고, 여기에는 백업 대상 4종, 업그레이드 대상 4종이 따라온다. Helicone all-in-one은 컨테이너 하나로 보이지만 그 안에 데이터스토어 3개가 들어 있어서, 하나가 메모리를 많이 쓰면 같은 컨테이너의 나머지가 함께 영향을 받는다.
반대쪽에서 Phoenix + Postgres는 데이터스토어 1개, 추정 RAM 하한 2GB다. OpenLLMetry와 Jaeger 조합은 1GB에서 시작한다. 2GB RAM VPS에서 LLM 관측성을 시작하고 싶다면 선택지는 사실상 이 두 줄뿐이다.
트레이스가 늘어나면 무엇이 먼저 깨지나
Langfuse에서는 저장 공간이 먼저 찬다. 이벤트 본문이 MinIO 같은 객체 스토리지에 쌓이고, 트레이스 한 건에 프롬프트 원문과 응답 전체가 들어가므로 검색 증강 파이프라인처럼 긴 컨텍스트를 다루는 애플리케이션에서는 건당 크기가 크다. 문서가 100GiB 저장 공간을 권장하는 이유가 여기에 있다. 그다음은 ClickHouse의 CPU와 메모리다. 문서 표현대로 ClickHouse는 분석 질의와 높은 동시 요청에서 CPU와 메모리를 많이 쓴다.
Phoenix에서는 SQLite의 쓰기 직렬화가 먼저 걸린다. SQLite는 쓰기 트랜잭션을 한 번에 하나만 처리하므로, 동시에 스팬을 밀어 넣는 워커가 늘면 수집이 밀린다. PHOENIX_SQL_DATABASE_URL을 Postgres로 바꾸는 것이 정해진 다음 단계다. 이 전환은 스키마 이전 작업이므로 데이터가 쌓인 뒤보다 시작할 때 결정하는 편이 싸다.
Helicone에서는 재시작이 먼저 문제가 된다. 볼륨을 붙이지 않았다면 컨테이너를 한 번 재시작하는 순간 기록이 사라진다. 문서에 명시된 동작이므로 놀랄 일은 아니지만, 대시보드가 잘 보인다는 이유로 볼륨 설정을 미루면 정확히 이 지점에서 손해가 난다.
OpenTelemetry 구성에서는 보존 정책이 먼저 문제가 된다. 표준 파이프라인은 무엇을 얼마나 오래 둘지 정해 주지 않는다. 샘플링 비율, 인덱스 보존 기간, 디스크 경보를 직접 정해야 한다. 이 작업은 새로운 종류의 일이 아니다. 원칙은 VPS에서 로그를 직접 관리하는 방법과 같고, 트레이스가 로그보다 건당 크기가 크다는 점만 다르다.
네 경우 모두 공통점이 하나 있다. 관측성 도구는 오류 추적을 대체하지 않는다. 스택 트레이스와 배포 단위 오류 집계가 필요하면 Sentry 대안을 직접 호스팅하는 방법을 따로 준비해야 한다.
라이선스와 셀프호스팅판에서 빠지는 기능
무료판의 경계를 미리 아는 것이 도입 결정의 절반이다. 이 확인 습관은 다른 도구에서도 똑같이 필요하다. n8n 커뮤니티판과 엔터프라이즈판의 차이를 정리한 글과 같은 방식으로 읽으면 된다.
Langfuse는 MIT이고, 유료 라이선스 키가 필요한 기능 목록이 문서에 공개되어 있다. 프로젝트 단위 RBAC 역할, 보호된 프롬프트 라벨, 데이터 보존 정책, 감사 로그, 서버 측 데이터 마스킹, UI 커스터마이징, 조직 생성자 관리, 조직 관리 API와 SCIM, 인스턴스 관리 API다. 활성화는 두 컨테이너에 LANGFUSE_EE_LICENSE_KEY 환경 변수를 넣는 방식이다.
이 목록에서 개인정보 관점으로 중요한 항목은 두 개다. 데이터 보존 정책과 서버 측 데이터 마스킹이 유료 기능이라는 점이다. 무료판에서 개인정보 노출을 줄이려면 보내기 전에 애플리케이션 코드에서 지우는 방식이 기본이 되고, 오래된 트레이스 삭제도 직접 만든 작업으로 돌려야 한다. 감사 로그가 없다는 점도 같이 기억하자. 누가 어떤 프롬프트 전문을 열어 봤는지 남기려면 다른 방법이 필요하다.
Phoenix는 ELv2다. 기능 제한보다 라이선스 성격이 결정 요소다. 사내 사용은 문제가 없지만 이것을 상품으로 재판매하거나 관리형 서비스로 제공할 수는 없다.
Helicone은 Apache 2.0이다. 문서에서 기능을 라이선스로 잠근다는 서술은 보이지 않고, 엔터프라이즈 문의는 프로덕션용 Helm 차트와 지원 쪽에 붙어 있다.
OpenLLMetry는 Apache 2.0이고, 받는 백엔드의 라이선스가 따로 붙는다. Jaeger는 Apache 2.0이다. 이 구성에서는 라이선스 위험이 가장 낮은 대신 화면을 직접 만들어야 하는 몫이 가장 크다.
상황별로 무엇을 고르나
- 혼자 에이전트 하나를 만드는 중이라면 Phoenix다. 컨테이너 하나, 볼륨 하나로 시작하고, 필요해지면 Postgres로 옮긴다. 2GB RAM VPS에서도 돌아가는 구성이다. 라이선스가 ELv2라는 점만 확인하면 된다.
- 프롬프트 버전 관리와 평가를 한곳에서 하는 팀이라면 Langfuse다. 데이터스토어 네 개를 운영할 각오가 필요하고, 8GB RAM은 시작점이며 문서 권장은 16GiB다. 평가를 파이프라인으로 돌리는 단계라면 에이전트 평가를 직접 호스팅하는 방법까지 같이 설계하는 편이 낫다.
- 비용과 사용량을 게이트웨이 지점에서 보고 싶다면 Helicone이다. 라이선스가 가장 단순하다. 볼륨 설정을 첫날에 끝내고, 프로덕션 규모에서는 배포 형태를 다시 검토하자.
- 이미 OpenTelemetry 스택이 돌고 있다면 OpenLLMetry다. 백엔드를 새로 고르지 말고 있는 것에 붙인다. LLM 전용 화면이 없다는 점을 팀이 받아들일 수 있는지가 유일한 질문이다.
- 원문을 남기면 안 되는 데이터를 다룬다면 도구 선택보다 마스킹이 먼저다. 어떤 도구를 골라도 SDK 앞단에서 지우지 않은 값은 그대로 저장된다. 네 도구 중 어느 것도 이 문제를 기본값으로 해결해 주지 않는다.
선택지는 계속 늘어난다. 이 네 가지가 맞지 않으면 AI 관측성 도구를 직접 올리는 다른 선택지도 같은 기준으로 재보면 된다. 기준은 늘 같다: 데이터스토어 몇 개, RAM 하한 얼마, 라이선스 무엇, 그리고 원문이 어디에 남는가.
올리기 전에 정해둘 두 가지
첫째, 보존 기간이다. 트레이스는 대화 원문이므로 오래 두면 그만큼 사고 범위가 커진다. 며칠 또는 몇 주로 정하고, 자동 삭제가 유료 기능인 도구에서는 직접 삭제 작업을 만들어 두자. 디스크가 100% 찬 뒤에 정하면 그때는 복구 작업이 된다.
둘째, 접근 제어다. Phoenix는 인증이 기본으로 꺼져 있고, Langfuse 기본 compose는 두 포트를 모든 인터페이스에 연다. 관측성 대시보드는 프롬프트 원문을 읽을 수 있는 화면이므로 내부 서비스와 같은 수준으로 막아야 한다. 리버스 프록시 뒤에 두고, 방화벽에서 원본 포트를 닫고, 가능하면 VPN이나 사설 네트워크 안에 둔다.
이 두 가지를 정한 다음에 도구를 고르면 비교가 훨씬 짧아진다. 남는 질문은 데이터스토어 몇 개를 운영할 수 있는지 하나뿐이다.
FAQ
LLM 트레이스를 해외 SaaS로 보내면 개인정보보호법 위반인가요?
자동으로 위반은 아니지만 근거가 필요한 처리다. 트레이스에는 프롬프트 원문과 도구 출력이 그대로 저장되고, 고객 문의를 다루는 서비스라면 그 안에 개인정보가 들어간다. 이를 해외 서버로 보내면 개인정보의 국외 이전에 해당하므로 동의, 법령이나 조약, 계약 이행에 필요한 경우의 고지, 인증, 적정성 인정 중 하나의 근거를 설명할 수 있어야 한다. 이 글은 법률 자문이 아니므로 구체적 판단은 법무 검토를 받아야 한다. 엔지니어링 쪽에서 줄일 수 있는 부분은 두 가지다. 보내기 전에 코드에서 개인정보를 제거하는 것, 그리고 국내 VPS에 직접 호스팅해서 국외 이전 자체를 없애는 것이다.
Langfuse를 ClickHouse 없이 Postgres만으로 운영할 수 있나요?
없다. 공식 문서는 ClickHouse가 셀프호스팅 Langfuse의 필수 구성 요소이며 현재 다른 OLAP 데이터베이스는 지원하지 않는다고 명시한다. 트레이스, 관측, 점수 엔티티가 ClickHouse에 저장되기 때문이다. Postgres도 함께 필요하고, 기본 compose에는 Redis와 MinIO까지 포함된다. 데이터스토어 하나로 끝내고 싶다면 Phoenix를 Postgres 모드로 쓰거나 SQLite 모드로 시작하는 편이 맞다.
RAM 2GB VPS에서 쓸 수 있는 LLM 관측성 도구가 있나요?
Phoenix의 SQLite 구성과 OpenLLMetry + Jaeger 구성이 현실적인 후보다. Phoenix는 컨테이너 하나와 볼륨 하나로 동작하고 데이터스토어를 따로 요구하지 않는다. Jaeger all-in-one도 단일 컨테이너다. 다만 이 급에서는 보존 기간을 짧게 잡아야 하고, Jaeger는 재시작 후 트레이스가 남는지 직접 확인한 뒤에 영속 스토리지를 붙일지 결정해야 한다. Langfuse는 데이터스토어 네 개를 띄우므로 이 사양에서는 권장되지 않는다.
Langfuse 셀프호스팅에서 못 쓰는 기능은 무엇인가요?
핵심 트레이스 수집, 프롬프트 관리, 평가, API는 MIT 라이선스 무료판에서 사용량 제한 없이 쓸 수 있다. 유료 라이선스 키가 필요한 기능은 문서에 목록으로 공개되어 있다. 프로젝트 단위 RBAC 역할, 보호된 프롬프트 라벨, 데이터 보존 정책, 감사 로그, 서버 측 데이터 마스킹, UI 커스터마이징, 조직 생성자 관리, 조직 관리 API와 SCIM, 인스턴스 관리 API다. 개인정보를 다루는 팀에게 중요한 항목은 데이터 보존 정책과 서버 측 마스킹이 유료라는 점이다. 무료판에서는 두 기능을 애플리케이션 코드와 운영 작업으로 대체해야 한다.