Langfuse, LLM 앱이 왜 그렇게 답했는지 호출 단위로 추적하는 오픈소스 플랫폼

LLM을 붙인 기능이 운영에 올라가면 질문의 성격이 바뀐다. 개발할 때는 “이 프롬프트가 답을 잘 내나”를 보지만, 운영에서는 “어제 그 사용자한테 왜 저렇게 답했나”를 봐야 한다. 그런데 애플리케이션 로그에는 보통 최종 응답 문자열 하나만 남아 있다. 어떤 프롬프트 버전이 쓰였는지, 검색 단계가 무엇을 가져왔는지, 그 요청 하나에 얼마가 나갔는지는 어디에도 없다. Langfuse는 그 빈자리를 메우는 오픈소스 플랫폼이다. 2023년에 시작해 지금은 GitHub 별 3만 4천 개를 넘겼고(2026년 9월 기준), 핵심 기능은 MIT 라이선스로 공개돼 있다.

한눈에 보기

호출 하나를 통째로 뜯어본다

Langfuse의 기본 단위는 트레이스다. 사용자의 요청 하나가 애플리케이션 안에서 거치는 단계를 중첩된 구조로 기록한다. LLM 호출만이 아니라 검색, 임베딩, 에이전트의 도구 사용 같은 중간 단계가 각각 하나의 관측 항목으로 남기 때문에, 답이 이상할 때 모델을 의심할지 검색 결과를 의심할지 화면에서 바로 가려낼 수 있다. 수집 방식이 OpenTelemetry를 따르는 점도 실무에서는 중요하다. 이미 분산 추적을 쓰고 있다면 같은 개념과 도구 위에 얹을 수 있다.

트레이스를 펼치면 단계마다 소요 시간과 토큰 수, 금액이 따라붙는다. 모델 이름과 temperature 같은 파라미터도 함께 기록되기 때문에, 비용이 튄 날에 “어느 기능이 얼마를 썼나”를 추측하지 않고 확인할 수 있다. 사용자 단위와 세션 단위로도 묶이므로 특정 고객의 사용량을 따로 떼어 보는 것도 가능하다.

프롬프트와 평가가 같은 화면에 붙는다

프롬프트 관리는 프롬프트를 코드 밖으로 빼내 버전을 매기고 배포하는 기능이다. 문구 한 줄 고치자고 배포를 다시 타지 않아도 되고, 어떤 버전이 언제부터 쓰였는지가 트레이스에 그대로 남는다. 서버와 클라이언트 양쪽에 캐시가 걸려 있어 이 구조를 쓴다고 응답이 느려지지는 않는다.

평가는 그 기록 위에서 점수를 매기는 쪽이다. 다른 모델에게 채점을 시키는 LLM-as-a-judge, 직접 짠 코드 평가기, 사람이 라벨을 다는 수동 평가, 사용자 피드백 수집을 모두 지원한다. 여기에 데이터셋을 붙이면 프롬프트나 모델을 바꿨을 때 예전 입력 묶음으로 같은 실험을 돌려 점수를 비교할 수 있다. 감으로 “이번 게 더 나은 것 같다”고 말하던 자리를 숫자로 바꾸는 부분이다.

ClickHouse에 인수됐지만 MIT는 그대로다

2026년 1월 16일, 분석 데이터베이스를 만드는 ClickHouse가 Langfuse 인수를 발표했다. 같은 날 공개한 4억 달러 시리즈 D와 함께 나온 소식이었다. 인수 발표문에서 ClickHouse는 발표 시점 기준으로 월 2,310만 건의 SDK 설치와 600만 건의 도커 풀, 포춘 50대 기업 중 19곳의 사용을 근거로 들었다.

오픈소스 프로젝트가 인수되면 라이선스부터 확인하게 되는데, 이 건에서는 핵심 기능이 MIT로 유지된다는 점이 함께 공지됐다. 실제로 저장소의 LICENSE 파일은 ee/ 계열 폴더만 별도 상업 라이선스로 두고 나머지는 MIT로 두고 있다. 저작권자 표기가 ClickHouse로 바뀌어 있을 뿐이다. 다만 Langfuse가 ClickHouse를 저장소로 쓰는 구조라는 점을 감안하면, 두 제품의 결합이 앞으로 더 깊어질 여지는 있다.

Datadog과는 무엇이 다른가

LLM 관측 도구를 검토하면 Datadog이 거의 항상 같이 올라온다. Datadog도 Agent Observability라는 이름으로 같은 영역을 다룬다. 프롬프트와 검색 단계, 도구 호출과 에이전트의 판단을 단계별로 추적하고, 운영 트레이스로 데이터셋을 만들어 프롬프트와 모델을 바꿔 가며 비교하는 실험 기능까지 갖췄다. 기능 목록만 늘어놓으면 두 제품은 꽤 비슷해 보인다.

갈리는 지점은 기능이 아니라 제품의 성격이다. Langfuse는 LLM만 보는 전용 도구이고 소스가 열려 있다. Datadog은 인프라와 APM, 실사용자 모니터링을 이미 담당하는 플랫폼이고, LLM 스팬을 그 신호들과 같은 화면에서 엮어 보는 것이 강점이다. 응답이 느려진 원인이 모델 쪽인지 뒤에 붙은 서비스 쪽인지를 추적해야 하는 상황이라면 후자가 유리하다.

그래서 선택 기준은 비교표의 항목 수가 아니라 이미 무엇을 쓰고 있느냐가 된다. 조직이 Datadog으로 관측을 표준화해 뒀다면 LLM 부분만 떼어 다른 도구에 넣을 이유는 크지 않다. 반대로 관측 스택이 아직 없거나, 프롬프트를 자주 고치며 버전을 관리해야 하거나, 데이터를 외부로 내보내기 어려운 조건이라면 Langfuse 쪽이 맞는다.

시작하기

1. 규모를 가늠하기 전이라면 클라우드 무료 티어로 시작한다. 카드 등록 없이 월 5만 유닛까지 쓸 수 있고 데이터는 30일간 조회된다.
2. 데이터를 외부에 두기 어려우면 자체 호스팅으로 간다. 저장소를 받아 docker compose up이면 로컬에서 5분 안에 뜨고, 운영에는 Helm 차트나 AWS, Azure, GCP용 테라폼 템플릿을 쓴다.
3. SDK를 붙인다. 파이썬이라면 pip install langfuse openai 후 공개키와 비밀키를 환경 변수에 넣고, 추적할 함수에 @observe() 데코레이터를 단다. OpenAI 연동을 쓰면 모델 파라미터까지 자동으로 수집된다.
4. 화면에서 트레이스가 들어오는 것을 확인한 뒤 프롬프트 관리와 평가를 차례로 켠다. 한 번에 다 켜면 무엇이 효과가 있었는지 구분되지 않는다.

LLM 기능을 실제 사용자에게 내보냈고 “왜 이렇게 답했지”를 사후에 확인해야 하는 팀이라면 도입 효과가 분명하다. 반대로 아직 프로토타입 단계이거나 호출량이 하루 수십 건 수준이라면 대시보드를 들여다볼 일 자체가 드물다. 그 단계에서는 로그를 잘 남기는 것으로 충분하고, 트래픽이 붙기 시작할 때 얹어도 늦지 않다.

주의점

• 유닛 단위 과금을 먼저 이해해야 한다. 클라우드 요금은 호출 수가 아니라 유닛으로 계산된다. 무료 티어는 월 5만 유닛에 30일 조회, 유료는 월 29달러부터 시작해 보관 기간과 지원 범위가 올라간다. 트레이스를 촘촘히 남길수록 유닛도 빨리 소모되므로 수집 범위를 정해 두는 편이 낫다.
• 프롬프트와 응답이 그대로 저장된다. 입력과 출력을 통째로 기록하는 것이 이 도구의 핵심이라, 개인정보나 민감정보가 들어오는 서비스라면 마스킹 설정과 보관 기간을 먼저 정해야 한다. 규제가 빡빡하면 자체 호스팅이 안전한 선택이다.
• 무료와 유료의 경계가 폴더로 나뉘어 있다. MIT가 적용되는 것은 ee/ 계열 폴더 바깥이다. 프로젝트 단위 권한 관리나 감사 로그 같은 기업용 기능은 별도 라이선스 영역이므로, 필요한 기능이 어느 쪽인지 도입 전에 확인해야 한다.
• 자체 호스팅은 운영 부담이 따라온다. 도커 컴포즈로 띄우는 것은 쉽지만 운영에서는 데이터베이스와 저장소를 직접 관리해야 한다. 팀에 인프라 담당이 없다면 클라우드 쪽 비용이 오히려 싸게 먹힐 수 있다.

정리

Langfuse는 LLM 기능을 운영하면서 생기는 질문, 즉 무엇이 얼마나 느렸고 얼마가 들었으며 어떤 프롬프트가 쓰였는지에 답하기 위한 도구다. 트레이싱으로 기록을 만들고, 프롬프트 관리로 변경 이력을 붙이고, 평가와 데이터셋으로 개선 여부를 숫자로 확인하는 흐름이 한 제품 안에 들어 있다. 인수 이후에도 MIT와 자체 호스팅이 유지된 덕분에 시험 도입의 문턱은 여전히 낮다. 사용자에게 나간 LLM 기능이 하나라도 있다면 클라우드 무료 티어에 트레이스를 하루치만 흘려 보내도 지금 무엇을 모르고 있었는지가 드러난다.