LLM 관측은 LangSmith가 아니라 Langfuse로 간다
맥락
배포 후 LLM 실행이 왜 느리고 왜 실패했는지 볼 수단이 없었다. LangChain 스택을 이미 쓰고 있으니 LangSmith가 "의존성 0개, 코드 0줄"로 켜지는 선택지로 보였다. 그래서 같은 날 먼저 채택했다. 실측에서는 그 근거가 하나도 성립하지 않았다.
"코드 0줄"이 특히 그랬다. Settings는 .env를 읽지만 값을 os.environ에 넣지 않는데 LangSmith SDK는
os.environ만 본다. README가 안내한 .env 경로는 한 번도 동작한 적이 없다. 결정적인 것은 세 번째다.
클라우드 전용이라 회의 녹취 원문이 외부로 나가는 것을 막을 방법이 없다. 회의 녹취는 우리가 소유한
데이터가 아니다.
결정
- Langfuse로 간다. 핵심 근거는 자체 호스팅이다. 개인정보 판단이 필요해지면
LANGFUSE_BASE_URL만 바꿔 옮길 수 있다. 지금은 클라우드로 시작한다. - 키는 SDK에 환경변수로 맡기지 않고
Settings로 받아 클라이언트에 명시적으로 넘긴다. 관리 지점이 둘이 되는 것보다 안 켜지는 게 나쁘다 — "안 도는 0줄보다 도는 10줄이 낫다". - 되돌리는 조건 셋을 함께 적는다: 자체 호스팅 이전 / LangSmith 복귀 / 둘 다 제거.
대안
대안 1 — LangSmith 유지. 같은 날 먼저 채택했던 안이고 LangChain과 한 몸이다. 기각한 이유: 클라우드 전용이라 회의 녹취 반출을 막을 수단이 없다. "0줄로 켜진다"는 채택 근거도 실측에서 틀렸다.
대안 2 — 둘 다 안 쓰고 로그로만 보기. 의존성이 하나도 안 는다. 기각한 이유: 지금 로그는 서비스 흐름만 보고 그래프 내부는 안 본다. 정작 알고 싶은 "왜 느리고 왜 실패했나"에 답하지 못한다.
결과
- 데이터 반출에 출구가 생겼다. 필요해지면 URL 하나로 자체 호스팅으로 옮긴다.
- 그 위에서 프롬프트(APP-129)와 평가 데이터셋(APP-131)까지 Langfuse로 이관됐다. APP-192 프로덕션 장애 진단에서는 Langfuse trace가 원인을 밝혀낸 결정적 도구였다.
- 새 패키지 10개(
langfuse+ OpenTelemetry 7개 +protobuf+langchain본체)를 받아들였다. "만들지 않는 것"으로 뺐던 OpenTelemetry가 Langfuse SDK의 내부 구현으로 딸려 들어온 것을 알고 수용했다. - 키를
Settings로 넘기면서 SDK 환경변수와 관리 지점이 둘로 갈릴 수 있다. - 핵심 근거인 자체 호스팅은 아직 잠재적 이점이다. 클라우드로 쓰는 동안은 근거가 실현되지 않은 채 결정만 서 있다.