Langfuse는 8월 31일 UTC 10:42:43에 v4.25.0을 공개했다. 이번 버전은 쿼리가 얼마나 과거까지 조회할 수 있는지에 대한 보존 한도를 도입한다. Cloud Hobby 요금제에서는 30일, Core에서는 90일이다. 이 한도는 대략 12개 REST 엔드포인트와 6개 MCP 도구 전반에 적용된다. 해당 풀 리퀘스트는 버그 수정, 비파괴로 분류됐다.
왜 이 분류는 표면적으로도 틀렸는가
어제는 180일치 trace를 반환하던 API가 오늘은 30일치만 돌려준다면, 이는 계약이 바뀐 것이다. 요청 자체가 잘못된 것은 아니다. 단지 응답이 잘려 나갈 뿐이다. 분기별 수치를 계산하는 대시보드, 예약 보고서, 평가 작업은 그대로 실행되고 200을 반환하지만, 서로 다른 답을 내기 시작한다. 상태 코드에는 변동이 없는데 결과만 바꾸는 변경을 비파괴로 분류하는 것은 가장 비용이 큰 실수다. 하위 시스템은 아무것도 감지할 수 없기 때문이다.
계산됐지만 버려진 신호
구현은 쿼리가 잘렸는지 알고 있다. 범위가 제한됐음을 나타내는 플래그를 계산하기 때문이다. 그러나 이 플래그는 외부에 드러나지 않는다. 응답 헤더가 되지도 않고, 페이로드의 필드가 되지도 않으며, 경고도 발생하지 않는다. 결과적으로 서버는 클라이언트가 데이터가 불완전하다는 사실을 알기 위해 필요한 정확한 정보를 갖고 있으면서도, 응답을 보내기 전에 이를 버린다. 헤더 하나만 추가했어도 조용한 잘림을 감지 가능한 형태로 바꿀 수 있었고, 비용은 거의 들지 않았을 것이다.
일반적인 해석이 놓치는 점
무료 요금제의 보존 한도는 흔하고 정당하다. 호스팅 서비스가 저장하고 제공하는 범위를 제한하는 것은 당연하다. 핵심은 Langfuse가 한도를 도입했다는 사실이 아니다. 문제는 그 한도가 전달되는 방식이다. 자동화된 소비자가 쓰는 엔드포인트에서, 예고 없이 조용한 제한으로, 비파괴라는 라벨과 함께 적용됐다는 점이다. 이를 "무료 요금제는 30일 보존"으로 읽으면 가격 주석에 불과하다. "12개 엔드포인트가 몰래 더 적은 데이터를 반환하기 시작했다"로 읽으면, 관측 가능성 제품에서의 관측 실패다.
확인할 사항
Hobby에서는 30일, Core에서는 90일을 넘는 Langfuse 기반 지표는 업그레이드 후 다시 산출해야 한다. 오류는 발생하지 않는다. 단지 수치가 더 작아질 뿐이며, 그 차이는 관측 가능성 하락이 아니라 트래픽 감소처럼 보일 것이다.