Langfuse와 Arize Phoenix, 운영 스택으로 선택하기

자체 호스팅을 전제로 Langfuse와 Arize Phoenix를 고른다면, 먼저 팀이 운영할 시스템의 범위를 정해야 한다. 노트북에서 추적과 평가를 살펴보는 흐름에는 Phoenix가, 여러 사람이 지속해서 사용하는 공용 관측 서비스에는 Langfuse가 더 자연스럽다. QASkills의 비교도 Phoenix의 로컬 분석 흐름과 Langfuse의 상시 서비스 운영을 구분한다.

두 제품 모두 추적, 평가, 데이터셋을 제공하므로 기능 이름만 세어서는 선택이 어렵다. 실제로 갈리는 것은 데이터를 어디에 저장하고 누가 배포와 백업을 맡으며, 개인의 분석 결과를 언제 팀의 공용 자산으로 옮길 것인가다. Phoenix도 공유 서버로 운영할 수 있으므로 로컬에서 시작하기 쉽다는 사실을 개인 전용이라는 뜻으로 받아들여서는 안 된다.

공통 기능을 걷어내면 남는 질문

한 개발자가 검색 증강 생성(RAG)의 검색 결과를 살피고 평가 실험을 반복하는 일이 주된 목적이라면, 분석 환경을 빠르게 띄울 수 있는지가 중요하다. 반대로 여러 애플리케이션의 실행 기록과 평가 결과를 같은 서비스에 쌓아야 한다면 저장소의 지속성, 사용자 접근 권한, 장애 대응 책임이 앞선다. 두 경우 모두 추적과 평가가 필요하지만, 그 기능을 유지해야 하는 시간과 참여하는 사람의 범위가 다르다.

이 차이는 도입 뒤의 업무에도 영향을 준다. 개인 실험에서는 추적을 보고 원인을 찾은 뒤 실험을 다시 실행하는 짧은 주기가 가치 있다. 공용 운영에서는 담당자가 바뀌어도 데이터셋과 평가 결과를 찾을 수 있어야 하고, 저장소 복구를 누가 맡는지도 정해야 한다. 따라서 기능표의 같은 표시가 팀에 같은 운영 부담을 뜻하지는 않는다.

저장소 구성이 자체 호스팅 부담을 바꾼다

Langfuse의 자체 호스팅 요구 사항에는 웹 컨테이너와 워커 컨테이너, PostgreSQL, Redis 또는 Valkey, ClickHouse, 객체 저장소가 각각 나온다. 팀이 이미 이 저장소들을 관리한다면 기존 운영 체계에 편입할 수 있다. 처음 도입한다면 구성 요소 사이의 연결뿐 아니라 각 저장소의 용량, 백업과 장애 대응까지 설계해야 한다. 애플리케이션 컨테이너 하나를 실행하는 수준으로 작업량을 잡으면 실제 운영 부담을 낮게 계산하게 된다.

구성 요소가 나뉜다는 것은 장애를 살펴볼 지점도 나뉜다는 뜻이다. 요청을 받는 웹 계층, 비동기 작업을 처리하는 워커, 분석 데이터를 담는 ClickHouse와 그 밖의 저장소를 각각 운영해야 한다. 반면 이미 데이터 플랫폼과 백업 체계를 갖춘 조직에는 이런 분리가 익숙한 배포 방식일 수 있다. 같은 구성이 작은 실험 팀에는 추가 책임이고, 상시 서비스를 운영하는 팀에는 기존 업무의 연장이 되는 이유다.

Phoenix 배포 문서는 기본 SQLite를 로컬 개발과 단일 사용자에, PostgreSQL을 운영 환경과 다중 사용자에 권한다. SQLite에서는 별도 데이터베이스 서버 없이 시작할 수 있지만, 기록을 유지하려면 저장 경로를 영속화해야 한다. 공유 서버로 옮길 때는 PostgreSQL의 백업과 접근 관리가 새 운영 책임이 된다. 처음에 간단한 구성으로 출발했다는 이유만으로 이후의 협업 운영까지 자동으로 간단해지는 것은 아니다.

Phoenix 인스턴스 하나는 하나의 테넌트다. 한 인스턴스 안에서는 역할에 따라 접근을 제어할 수 있지만, 서로 다른 팀이나 환경의 데이터를 분리하려면 인스턴스와 데이터베이스의 경계를 설계해야 한다. 성능을 위해 여러 인스턴스가 같은 데이터베이스를 쓰는 구성과, 팀별로 독립된 데이터베이스를 쓰는 구성은 목적이 다르다. 여러 팀이 이용할 예정이라면 단일 컨테이너로 시작할 수 있다는 장점과 데이터 분리 비용을 함께 계산해야 한다.

노트북 실험이 공용 서비스가 되는 순간

Phoenix는 노트북에서 모델 응답이나 검색 결과를 반복해서 확인하며 평가 방식을 바꾸는 흐름에 잘 맞는다. 이 단계에서는 공용 관측 서비스를 먼저 구축하지 않고도 분석을 시작할 수 있다. 다만 다른 사람이 실험을 이어받아야 한다면 사용한 데이터셋, 평가 기준, 실행 환경과 결과의 보존 위치를 팀이 정해야 한다. 로컬에서 실행하기 쉬운 것과 결과를 재현하며 공유하기 쉬운 것은 서로 다른 조건이다.

Langfuse는 여러 사람이 계속 접속할 관측 서비스를 운영하려는 팀에 어울린다. 여러 애플리케이션의 추적과 평가 결과를 한곳에 축적한다면 서비스 가용성과 저장소 권한, 업데이트 및 복구 절차가 설치 속도보다 중요해진다. 이미 데이터베이스와 애플리케이션 서비스를 맡는 담당자가 있는 팀은 이 책임을 기존 운영 업무에 배분할 수 있다. 실험 담당자만 있는 팀에는 같은 구성이 새로운 운영 업무가 된다.

그렇다고 Phoenix를 개인 전용, Langfuse를 협업 전용으로 고정하면 선택지가 왜곡된다. Phoenix도 PostgreSQL을 붙인 다중 사용자 서버로 운영할 수 있고, Langfuse에서도 한 프로젝트의 실험 데이터를 다룰 수 있다. 중요한 차이는 어느 기능이 존재하느냐보다 팀이 원하는 상태에 도달하고 그 상태를 유지하는 데 필요한 인프라다. 특히 사용자 수가 늘어나는 것과 팀 사이에 데이터 경계를 만드는 것은 별도의 요구다.

OpenTelemetry는 공통 출발점이다

Phoenix 추적 문서에 따르면 OpenInference 계측 도구가 만든 span은 OTLP를 통해 Phoenix 수집기로 전송되며, 문서는 HTTP 방식의 OTLP 수신을 설명한다. 이미 OpenInference로 LLM 호출이나 검색 단계를 계측하는 팀이라면 기록 중인 span의 속성을 Phoenix 분석에 이어 쓸 수 있는지 살펴볼 수 있다. 이때 핵심은 단순히 추적이 도착하는지가 아니라 검색 단계와 모델 호출을 원하는 문맥으로 읽을 수 있는지다.

Langfuse SDK 문서는 자사 SDK가 OpenTelemetry를 기반으로 하며, 애플리케이션에서 OpenTelemetry span을 전송할 수 있는 경로도 제시한다. 따라서 OpenTelemetry 지원 여부만으로 두 제품의 우열은 갈리지 않는다. 팀이 프롬프트 관리나 평가까지 연결하려면 일반 span 전송으로 표현할 정보와 Langfuse SDK 또는 공개 API로 다룰 정보를 구분해야 한다. 계측 표준을 공유하더라도 제품 안에서 기록을 조직하는 방식은 같지 않다.

기존 계측을 재사용하려는 팀에는 span의 의미가 실제 화면과 평가 흐름에서 어떻게 이어지는지가 선택 기준이다. 예컨대 검색 결과와 모델 응답이 따로 수집되지만 한 실행의 맥락으로 묶이지 않는다면, 추적을 확보해도 문제의 원인을 찾는 일은 번거롭다. 평가 점수를 어느 실행 기록과 연결할지도 같은 문제에 속한다. 프로토콜 호환성은 출발점이고, 팀이 조사할 수 있는 기록의 구조가 실질적인 차이를 만든다.

팀 상황별 선택표

기능 목록 대신 현재의 운영 상태를 기준으로 보면 선택이 선명해진다. 아래 판단은 성능 순위가 아니라 자체 호스팅 준비와 협업 범위에 관한 권고다.

개인 또는 소규모 탐색: 노트북에서 추적을 확인하고 평가 실험을 자주 바꾸며 공용 운영 환경이 아직 없다면 Phoenix의 SQLite 시작 방식이 적합하다. 결과를 공유하기 시작할 때 저장 위치와 재현 방법을 정해야 한다.
한 팀의 공유 서버: Phoenix에 PostgreSQL을 연결하는 구성을 검토할 만하다. 여기서는 첫 실행의 간편함보다 사용자 접근, 데이터베이스 백업, 서비스 운영을 맡을 사람이 있는지가 중요하다.
여러 애플리케이션의 상시 관측: 웹·워커와 여러 저장소를 관리할 수 있고 추적 및 평가 데이터를 공용 서비스로 축적하려는 팀에는 Langfuse가 자연스러운 후보다. 배포할 구성 요소와 장애 대응 범위를 운영 계획에 포함해야 한다.
팀별 데이터 분리: Phoenix에서는 인스턴스와 데이터베이스를 어떻게 나눌지 결정해야 한다. Langfuse에서는 서비스와 저장소를 기존 배포·권한 체계에 어떻게 편입할지 살펴야 한다.

여러 팀이 같은 관측 환경을 쓰게 될 예정이라면 사용자 접근 권한과 데이터 분리 요구를 먼저 구별하는 편이 좋다. 전자는 공유 서버 안에서 다룰 수 있지만, 후자는 별도 인스턴스나 저장소 경계를 요구할 수 있다. 이 차이까지 포함해야 처음 실행할 때 편한 도구가 장기 운영에도 맞는지 판단할 수 있다.

함께 읽기: