LangChain: LangSmith의 LLM 관측성을 떠받치는 ClickHouse
LangChain: LangSmith의 LLM 관측성을 떠받치는 ClickHouse

LangChain: LangSmith의 LLM 관측성을 떠받치는 ClickHouse

ClickHouse 분류
Customer Story
Type
Introduction
작성자

Ken

원문: LangChain - Why we Choose ClickHouse to Power LangSmith

LangSmith는 LangChain이 만든 LLM 애플리케이션을 위한 통합 개발자 플랫폼으로, 관측성(Observability)과 평가(Evaluation)를 핵심 기능으로 합니다. LangSmith가 GA(General Availability)로 출시되면서, LangChain 공동 창업자 Ankush Gola는 "왜 ClickHouse를 선택했는가"에 대해 인터뷰를 진행했습니다.

LangSmith가 해결하는 문제

1. Observability (관측성)

LLM 애플리케이션은 본질적으로 복잡합니다:

  • 여러 API 호출이 체인처럼 연결됨
  • Agent의 의사결정 흐름이 복잡
  • 무한 루프, 과도한 토큰 사용 등 디버깅이 어려운 케이스 다수

LangSmith는 LLM 시퀀스의 각 단계에서 명확한 가시성과 디버깅 정보를 제공해 이 문제를 해결합니다.

2. Evaluation (평가)

관측성에서 출발한 LangSmith는 점차 LLM 개발 라이프사이클 전반을 포괄하는 플랫폼으로 진화했습니다:

  • 프롬프트·모델 변경의 영향 측정
  • 벤치마킹/파인튜닝용 데이터셋 구성
  • A/B 테스트
  • 온라인 평가

Postgres의 한계

LangSmith는 초기에 100% Postgres로 부트스트랩되었습니다. 빠른 출시가 가능했지만, 사용자 행동을 본격적으로 관찰하기 시작하면서 문제가 드러났습니다.

사용자들은 LangSmith를 단순히 "평가용 sparse logging" 도구로 쓰는 게 아니라, 프로덕션 데이터의 상당 부분을 로깅해 다음과 같은 용도로 활용하기 시작했습니다:

  • 트레이싱과 데이터셋 구축
  • 평가 잡 실행
  • A/B 테스트
  • 시간에 따른 핵심 메트릭 모니터링 차트의 자유로운 필터링

이에 따라 Postgres에서 다음과 같은 문제가 발생했습니다:

  • 고처리량 ingest를 따라가기 어려움
  • 분석 워크로드 처리 비효율
  • 통계를 미리 머티리얼라이즈해봤지만, 사용자가 사전 정의된 차원으로만 자르는 한계 + 막대한 컴퓨팅 비용
  • 요청 수가 늘면서 Lock contention 발생
"Ultimately, it was clear that we needed to add another database to complement Postgres for our use case and to unlock real-time insights for our users." — Ankush Gola

왜 ClickHouse였는가

1. High-throughput ingest + low-latency analytical queries

자연스럽게 OLAP / 실시간 분석 DB가 필요하다는 결론에 도달.

2. 로컬·자체 호스팅·클라우드 모두 지원

  • 개발과 CI/CD를 위해 로컬 실행 필요
  • self-managed 배포 옵션 필요
  • 동시에 Cloud 서비스도 제공해야 함

→ 기존의 closed-source 클라우드 솔루션 대부분이 탈락 → 오픈소스 솔루션이 필수

3. 아키텍처적 단순함

"We looked at Druid and Pinot, but these required dedicated services for ingestion, connected to queuing services such as Kafka, rather than simply accepting INSERT statements. We were keen to avoid this architectural complexity, especially given our self-managed requirements." — Ankush Gola

ClickHouse는 단순한 INSERT 문만으로도 동작 가능 — self-managed 환경에서 인프라를 복잡하게 만들지 않음.

4. 이미 검증된 평판

"When you're in the database space, it's hard not to hear about ClickHouse!"

Cloudflare 등 고처리량 워크로드에서의 검증된 성과가 신뢰를 줌.

도입 시 직면한 과제와 해결

Ankush는 "ClickHouse를 Postgres나 BigQuery처럼 생각하면 안 된다"고 강조합니다.

1. Sorting key와 엔진 선택의 중요성

  • 자주 사용하는 쿼리 패턴에 맞춰 sorting key 신중하게 설계
  • 주기적 업데이트를 지원하기 위해 ReplacingMergeTree 엔진 사용

2. 쿼리 플래너 차이

  • Postgres만큼 자동 최적화되지 않음
  • 내부 동작과 EXPLAIN API에 대한 이해 필요
  • 새로운 analyzer가 많은 부분을 해결해줄 것으로 기대

3. 트레이스 단건 조회 문제

LangSmith는 차트와 통계 외에도 개별 트레이스의 모든 span 시각화가 필요합니다.

  • 일반 워크플로우: feedback score, tenant, session 같은 sorting key 차원으로 필터 → 디테일 뷰로 드릴다운
  • 문제: 마지막 단계는 trace ID로 단건 조회가 필요한데, trace ID는 sorting key의 앞 자리에 있지 않음 → 풀 테이블 스캔 위험

4. 해결책: Materialized View를 "역인덱스"로 활용

LangChain은 materialized view를 생성하여 target 테이블의 sorting key를 (trace_id, run_id)로 구성했습니다.

  • 이 뷰에는 메인 테이블의 sorting key 값들이 컬럼으로 저장됨
  • trace ID로 조회 → 메인 테이블의 sorting key 값 획득 → 메인 테이블에 그 키 값으로 필터하여 최소 row만 스캔
  • Secondary index나 bloom filter보다 셋업이 쉽고 효율적
이 접근은 OpenTelemetry ClickHouse 통합에서도 동일하게 사용되는 패턴입니다.

ClickHouse Cloud를 선택한 이유

"We didn't want to manage a ClickHouse cluster ourselves. Being able to spin up a Cloud service in the GCP region of our choice was pretty effortless and a no-brainer with respect to cost." — Ankush Gola

전체 아키텍처에서의 위치

  • ClickHouse: 트레이스, 메트릭, 분석 쿼리의 메인 엔진
  • Postgres: 트랜잭션이 필요한 애플리케이션 상태 관리
  • Redis: 캐시 및 비동기 잡 큐
  • Cloud Object Storage: 멀티모달(이미지 등) 데이터의 주 저장소

향후 기대

Ankush는 production-ready한 inverted index(현재 실험적 기능)에 큰 관심을 표명했습니다. 현재는 data-skipping index로 텍스트 검색을 가속화하고 있지만, 풀텍스트 검색 측면에서 더 큰 개선 여지가 있다고 평가합니다.

또한 엔터프라이즈 고객이 늘면서 RBAC, SSO 같은 기능을 ClickHouse와 더 긴밀히 통합해야 할 필요성도 언급되었습니다.

교훈과 시사점

LLM 시대의 새로운 관측성 패러다임

LLM 애플리케이션은 기존 마이크로서비스와는 다른 체인·에이전트 구조를 가지며, 이에 특화된 관측성 도구가 필요합니다. LangSmith는 그 새로운 패러다임의 선두주자이며, 그 핵심 백엔드를 ClickHouse가 떠받치고 있습니다.

Postgres + ClickHouse 조합의 일반화

트랜잭션은 Postgres가, 고처리량 분석은 ClickHouse가 담당하는 이중 데이터베이스 패턴은 LLM 스타트업뿐 아니라 많은 SaaS 제품에서 점점 표준이 되어가고 있습니다.

아키텍처 단순함 = 운영 비용

Druid/Pinot이 아닌 ClickHouse를 선택한 가장 큰 이유는 "INSERT 한 줄로 동작한다"는 운영의 단순함이었습니다. 도구 선택에서 종종 간과되지만, 자체 호스팅을 지원해야 하는 SaaS에서는 결정적인 차이를 만듭니다.

결론

"We've had a positive experience with ClickHouse. It allowed us to scale LangSmith to production workloads and provide a service where users can log all of their data. We couldn't have accomplished this without ClickHouse." — Ankush Gola, co-founder of LangChain

LangChain의 사례는 LLM 시대의 새로운 관측성·평가 도구가 어떤 데이터 인프라 위에서 만들어지는지를 보여줍니다. 그 답은 명확합니다 — ClickHouse.