r/langchain•3개월 전•7•10

이미 LangSmith를 쓰고 있다면, 두 번째 관측성(observability)이나 평가(eval) 도구가 필요한 시점은 언제일까?

You already run LangSmith. When does a second observability or eval tool actually earn its place?

핵심 요약

LangSmith 사용 중 추가적인 관측성 도구가 필요한 상황과 그 기준에 대한 논의입니다.

비용 문제 — 트래픽 증가에 따른 인당/추적당 과금 부담 발생
데이터 보안 — 인프라 외부로 나갈 수 없는 추적 데이터 요구사항
평가 깊이 — LLM-as-judge 등 전문적인 평가 라이브러리 필요성
런타임 가드레일 — 실행 전 도구 호출을 차단하거나 제어하는 기능의 부재

대부분의 에이전트 팀은 LangSmith로 시작하며, 이는 합리적인 선택입니다. LangChain 및 LangGraph와 가장 깊게 연동되어 있고, 거의 별도의 설정 없이도 그래프와 추적이 일치하며, 인당 과금이 시작되기 전까지 무료 티어로도 충분히 활용할 수 있기 때문입니다.

우리가 계속 마주하는 질문은 두 번째 도구가 실제로 도입할 가치가 있는 시점이 언제인가 하는 것입니다. 도구가 하나 추가될 때마다 SDK, 대시보드, 청구서가 하나씩 늘어나기 때문입니다. 팀들이 도구를 추가하거나 교체하게 만드는 몇 가지 요인을 관찰했습니다:

비용: 트래픽이 증가하면 문제가 됩니다. 규모가 커질수록 인당, 추적당 과금은 현실적인 부담이 됩니다. 이 지점에서 Langfuse가 자주 언급되는데, 핵심 코드가 MIT 라이선스이고 전체를 무료로 자체 호스팅할 수 있기 때문입니다.
데이터 보안: 추적 데이터가 인프라를 벗어나면 안 되는 경우입니다. 이것이 필수 요구사항이라면 자체 호스팅 가능한 도구가 유리합니다. Langfuse가 다시 언급되며, Elastic License 2.0 기반의 소스 공개형이자 OpenTelemetry 네이티브인 Arize Phoenix도 있어 계측 데이터의 이식성을 유지할 수 있습니다. LangSmith도 자체 호스팅을 지원하지만 엔터프라이즈 티어에서만 가능합니다.
평가 깊이: 제대로 된 메트릭 라이브러리와 LLM-as-judge가 핵심 기능으로 필요하다면 도구 간 차이가 발생합니다. Braintrust는 강력하며 자체 최적화 도구인 Loop를 제공합니다.
런타임 가드레일: 추적은 실행 후 무슨 일이 일어났는지 알려줍니다. 도구 호출이 실행되기 전에 차단하거나 에스컬레이션하는 것은 다른 작업이며, 많은 관측성 도구는 이를 지원하지 않습니다.

마지막 지점이 우리를 움직이게 했고, 그래서 우리는 Future AGI를 만들고 모든 것을 오픈소스로 공개하여 이 기능들을 하나로 통합했습니다. 평가, OpenTelemetry 추적, 런타임 가드레일, 도구 및 MCP 게이트웨이를 하나의 Apache-2.0 패키지로 자체 호스팅할 수 있어, 단일 실행이 여러 도구로 쪼개지지 않고 전체 과정에서 하나로 유지됩니다.

우리가 해결하려는 것은 이것입니다: 이미 LangSmith를 사용 중인 분들 중, 무엇 때문에 두 번째 도구를 추가하거나 옮기게 되었나요? 그리고 단일 도구로 다시 통합해서 만족감을 느낀 분이 계신가요, 아니면 규모가 커지면 다중 도구 설정이 현실이 되는 건가요?

원문

커뮤니티 목록

r/langchain•3개월 전•7•10

이미 LangSmith를 쓰고 있다면, 두 번째 관측성(observability)이나 평가(eval) 도구가 필요한 시점은 언제일까?

You already run LangSmith. When does a second observability or eval tool actually earn its place?

핵심 요약

LangSmith 사용 중 추가적인 관측성 도구가 필요한 상황과 그 기준에 대한 논의입니다.

비용 문제 — 트래픽 증가에 따른 인당/추적당 과금 부담 발생
데이터 보안 — 인프라 외부로 나갈 수 없는 추적 데이터 요구사항
평가 깊이 — LLM-as-judge 등 전문적인 평가 라이브러리 필요성
런타임 가드레일 — 실행 전 도구 호출을 차단하거나 제어하는 기능의 부재

비용: 트래픽이 증가하면 문제가 됩니다. 규모가 커질수록 인당, 추적당 과금은 현실적인 부담이 됩니다. 이 지점에서 Langfuse가 자주 언급되는데, 핵심 코드가 MIT 라이선스이고 전체를 무료로 자체 호스팅할 수 있기 때문입니다.
데이터 보안: 추적 데이터가 인프라를 벗어나면 안 되는 경우입니다. 이것이 필수 요구사항이라면 자체 호스팅 가능한 도구가 유리합니다. Langfuse가 다시 언급되며, Elastic License 2.0 기반의 소스 공개형이자 OpenTelemetry 네이티브인 Arize Phoenix도 있어 계측 데이터의 이식성을 유지할 수 있습니다. LangSmith도 자체 호스팅을 지원하지만 엔터프라이즈 티어에서만 가능합니다.
평가 깊이: 제대로 된 메트릭 라이브러리와 LLM-as-judge가 핵심 기능으로 필요하다면 도구 간 차이가 발생합니다. Braintrust는 강력하며 자체 최적화 도구인 Loop를 제공합니다.
런타임 가드레일: 추적은 실행 후 무슨 일이 일어났는지 알려줍니다. 도구 호출이 실행되기 전에 차단하거나 에스컬레이션하는 것은 다른 작업이며, 많은 관측성 도구는 이를 지원하지 않습니다.

주요 댓글

r/langchain

두 번째 툴 도입의 필요성을 단순히 시점이 아닌 구체적인 페인 포인트와 배포 전후의 통합된 평가 체계 구축 관점에서 논의하고 있습니다.

일주일 뒤에 다른 걸 고장 내는 수정 사항을 배포하기 전까지는 두 번째 툴이 왜 필요한지 이해가 안 됐음. 그때 비로소 트레이싱이랑 평가(eval)가 서로 다른 문제를 해결하고 있다는 걸 깨달았지. Braintrust를 계속 쓰게 된 이유는 프로덕션 이슈가 생길 때마다 맥락이 생생할 때 바로 평가 케이스로 만들 수 있어서, 별다른 노력 없이도 테스트 스위트가 계속 커졌기 때문임.

회귀가 eval이 되는 그 루프가 핵심이지. tracing이랑 eval이 서로 다른 질문에 답하고 있다는 네 말이 정확해. 우리가 추가하고 싶은 건 세 번째 요소인 예방이야. Future AGI를 쓰면 똑같은 신선한 컨텍스트 오류가 eval이자 런타임 가드레일이 될 수 있어. 그래서 다음에 똑같은 유형의 버그가 나타나면 다음 eval 실행에서 잡히는 게 아니라 배포되기 전에 차단되는 거지.

나한테는 기능보다는 워크플로우가 트리거였음. 트레이스는 문제 터지고 나서 확인하는 거고, eval은 배포하기 전에 돌리는 거니까. 대시보드에서 확인하는 게 아니라 CI에서 리그레션(회귀 오류)을 잡고 싶어지는 순간, 그건 한 툴이 할 일이 아니게 됨. 사후 디버깅만 할 거면 두 번째 툴은 그냥 돈만 더 나가는 꼴이지.

배포 전과 배포 후로 나누는 게 두 번째 툴이 제값을 하는지 판단하는 가장 확실한 기준인 것 같네. 사후 디버깅만 할 거면 굳이 툴을 늘릴 필요 없다는 말도 맞고. Future AGI에서 생각하는 방식은 툴을 하나 더 추가하는 게 아니라, 배포 전 CI 게이트로 실행되는 eval 정의 하나를 만들어서 배포 후에도 프로덕션 트레이스를 계속 스코어링하는 거야. 그래야 나중에 대시보드에서 확인하는 게 아니라 리그레션이 발생했을 때 바로 빌드를 실패시킬 수 있으니까.

두 번째 툴이 언제 필요한지가 중요한 게 아닌 것 같음. 어쩌면 영원히 필요 없을지도... 진짜 문제는 페인 포인트가 뭐냐는 거지. 그게 두 번째 툴이 필요한지, 아니면 지금 쓰는 툴로 해결 가능한지를 결정하는 거니까.

-1

필요하다면 레포 참고: github.com/future-agi/future-agi, Apache-2.0 라이선스, 자체 호스팅 가능, 추적/평가/가드레일/게이트웨이 번들.

왜 다들 이 데이터 저장소 백엔드 스택을 고집하는지 궁금함. 우린 하루에 약 1테라바이트의 LLM 추적 데이터를 생성하는데, 제대로 버티는 솔루션이 없음. 훨씬 확장성 있는 백엔드가 많은데. 그냥 직접 만드는 쪽으로 기울고 있음.

-1

EU 데이터 레지던시가 필요한데 엔터프라이즈 티어 없이는 안 돼서 LangSmith에서 갈아탔음.. orqai로 정착했는데... 트레이싱, eval, 게이트웨이 레이어를 한곳에서 다 처리해주고, 컴플라이언스 문제가 우리한테는 결정적이었음... 대시보드 사이에서 컨텍스트 스위칭 안 해도 되는 것만으로도 단일 창(single pane)으로 통합한 보람이 있더라....

컴플라이언스가 결정적인 이유였다니 이해가 가네. 솔직히 대시보드 4개씩 띄워놓고 써보기 전까진 단일 창(single pane)의 장점을 잘 모름. 우리도 Future AGI로 똑같이 올인원 방식을 택했는데, 차이점은 Apache-2.0 기반에 셀프 호스팅이 가능하다는 거임. 그래서 트레이싱, eval, 게이트웨이 스택 전체를 그냥 우리 인프라 안에서 돌리면 되니까 따로 돈 주고 티어를 살 필요 없이 EU 레지던시가 해결되는 거지.

원문r/langchain