--- title: "랭체인, 에이전트 관측용 데이터베이스 ‘스미스디비’ 공개" published: 2026-05-18T22:26:18.000Z canonical: https://jeff.news/article/2931 --- # 랭체인, 에이전트 관측용 데이터베이스 ‘스미스디비’ 공개 랭체인이 에이전트 관측성과 평가 워크로드를 위해 만든 분산 데이터베이스 SmithDB를 공개했어. LangSmith의 미국 클라우드 수집과 트레이싱 UI 쿼리 트래픽을 이미 100% 처리 중이고, 핵심 화면은 최대 12배 빨라졌다고 해. ## 에이전트 트레이스가 DB 설계 문제로 커짐 - LangChain이 LangSmith의 핵심 워크로드를 받치는 전용 분산 데이터베이스 SmithDB를 공개함 - 목적은 딱 하나임: 에이전트 관측성(agent observability)에 맞는 저장·검색·분석 레이어를 직접 만들겠다는 것 - LangSmith의 핵심 경험은 SmithDB 도입 후 최대 12배 빨라졌다고 밝힘 - 왜 새 DB까지 만들었냐면, 요즘 에이전트 트레이스는 예전 RAG 파이프라인 로그랑 체급이 다름 - 최신 에이전트 trace 하나가 수백 개의 깊게 중첩된 span을 가질 수 있음 - LLM 컨텍스트 윈도우가 커지고, 이미지·오디오 같은 멀티모달 payload까지 들어오면서 개별 데이터 크기도 커짐 - start event가 먼저 오고 end event는 몇 분, 심하면 몇 시간 뒤에 오는 식이라 단순 request-response 모델로 보기 어려움 - 에이전트 관측성 쿼리는 단순 로그 검색이 아니라 거의 제품 기능 묶음에 가까움 - 개별 run이나 trace 즉시 로딩 - metadata, feedback, latency, error, tag, time 기준 대화형 필터링 - 입력·출력 내부 문구를 찾는 full-text search - 사용자 정의 metadata와 tool output을 대상으로 한 JSON filtering - root run, child run, trace 내부 node 기준 tree-aware query - 장시간 대화를 여러 trace에서 재구성하는 thread reconstruction - cost, latency, token usage, evaluator score 집계까지 필요함 > [!IMPORTANT] > SmithDB는 아직 실험용 발표가 아니라 이미 LangSmith 프로덕션 트래픽을 받고 있음. 미국 클라우드 ingestion 100%, tracing UI query traffic 100%가 SmithDB로 가는 상태임. ## 구조는 오브젝트 스토리지 기반 LSM - SmithDB는 Rust로 만들어졌고, Apache DataFusion 쿼리 엔진과 Vortex 파일 툴킷을 활용함 - LangSmith 워크로드에 맞게 꽤 많이 커스터마이즈했다고 설명함 - 기본 구성은 durable trace data용 object storage, segment metadata용 작은 Postgres metastore, 상태 없는 ingestion/query/compaction service임 - 핵심 저장 구조는 object-storage backed log-structured merge tree(LSM)에 가까움 - write는 메모리에 버퍼링했다가 immutable sorted batch로 저장함 - query 시점에는 여러 segment를 읽어 하나의 정렬된 stream처럼 merge함 - compaction service가 write 최적화 segment를 query 최적화 segment로 다시 써 줌 - 구성 요소는 다섯 개로 나뉨 - ingestion service: trace write를 받아 partition과 time bucket별로 batch 처리하고 immutable file을 씀 - metastore: segment 위치, 시간 범위, row count, update/delete vector를 기록함 - query service: LangSmith run semantics와 object storage를 이해하는 custom execution plan을 제공함 - compaction service: delete, upgrade, TTL expiry, index merge를 반영해 segment를 재작성함 - cluster manager: key range를 service node에 배정해 부하 분산과 cache locality를 같이 노림 ```mermaid sequenceDiagram participant 에이전트 participant 수집서비스 participant 메타스토어 participant 오브젝트스토리지 participant 쿼리서비스 participant 컴팩션서비스 에이전트->>수집서비스: trace event 전송 수집서비스->>오브젝트스토리지: immutable segment 저장 수집서비스->>메타스토어: segment metadata 기록 쿼리서비스->>메타스토어: 후보 segment 조회 쿼리서비스->>수집서비스: 최신 segment 캐시 확인 쿼리서비스->>오브젝트스토리지: 필요한 segment만 읽기 컴팩션서비스->>오브젝트스토리지: 오래된 segment 병합·재작성 ``` ## 성능 최적화가 꽤 구체적임 - 최신 run 목록 같은 Top K 쿼리는 “전부 정렬하고 limit” 방식으로 풀지 않음 - SmithDB는 시간 역순으로 걸어가며 최신 후보 segment의 bounded time window를 만듦 - 그 안에서 stream, merge, dedupe를 하다가 correctness가 보장되는 순간 멈춤 - object storage에서 필요 이상으로 많은 파일을 열고 읽는 비용을 줄이는 전략임 - 가장 최신 데이터는 object storage만 보지 않고 ingestion node의 SSD·memory cache에서 직접 읽을 수 있음 - 각 file segment는 자신을 만든 server identifier를 기록함 - 작성 노드가 아직 살아 있으면 query planner가 object storage 대신 그 노드의 local cache를 스캔할 수 있음 - 최신 trace 조회에서 작은 파일 수십 개를 object storage에서 다시 읽는 상황을 피하려는 설계임 - SmithDB에서 run은 단일 immutable row가 아니라 여러 event의 sequence임 - agent span은 모델 호출, tool call, retry, background work, 다른 agent handoff 때문에 오래 열려 있을 수 있음 - 그래서 filter를 특정 event에 fanout하고, query 시점에 event를 효율적으로 merge해야 함 - 이 선택은 query engine뿐 아니라 compaction 전략에도 영향을 줌 - compaction은 시간 계층(time-tiered)으로 조절함 - 최근 데이터는 end event가 추가될 가능성이 높아서 너무 빨리 큰 파일로 합치면 write amplification이 커짐 - 오래된 데이터는 안정적이고 반복 조회될 가능성이 높으니 더 큰 segment로 합칠 가치가 있음 - 결과적으로 ingestion latency는 유지하고, 오래된 데이터 조회 비용은 점점 낮추는 구조임 > [!TIP] > 에이전트 관측성 저장소를 직접 만들거나 고를 때는 “trace를 얼마나 빨리 쓰나”만 보면 부족함. 나중에 metadata, text, JSON, tree, thread 단위로 어떻게 다시 꺼낼지가 진짜 병목임. ## 검색과 배포까지 에이전트 워크로드에 맞춤 - 1MB 이상 payload에서 sub-second full-text search와 JSON key-path filtering을 지원하는 게 큰 난제였다고 함 - SmithDB는 object storage에 맞춘 custom inverted index layout을 사용함 - term을 row group으로 정렬하고 min/max term zone을 기록해 exact·prefix query에서 불필요한 row group을 먼저 제거함 - postings와 positions를 term dictionary와 분리해 common term이 거대한 메모리 할당이나 range read를 유발하지 않게 함 - 큰 필드는 late materialization으로 뒤로 미룸 - core run field와 large field를 분리하고, core row는 large-field file pointer만 가짐 - run list를 보거나 filter를 적용할 때는 megabytes급 JSON을 읽지 않음 - 사용자가 run을 열거나 해당 field를 projection할 때만 큰 payload를 가져옴 - cluster manager는 단순 부하 분산이 아니라 sticky routing을 노림 - Google Slicer와 Databricks Dicer에서 영감을 받은 방식이라고 설명함 - keyspace를 slice로 나누고 각 slice를 안정적인 service node set에 배정함 - 관련 요청이 같은 node나 작은 replica set으로 가면 metadata와 segment bytes cache hit 가능성이 높아짐 - 고객 사례도 꽤 센 편임 - Clay는 매일 수억 건의 agent observability event를 LangSmith에 기록한다고 함 - Cogent Security는 background agent가 한꺼번에 엄청난 trace를 만들 때, 다른 provider에서는 몇 분 걸리던 trace 확인이 SmithDB에서는 몇 초 단위였다고 말함 - Vanta와 Unify도 trace 탐색, edge case 찾기, eval dataset 구성 속도가 빨라졌다고 평가함 --- ## 기술 맥락 - SmithDB의 선택은 “범용 OLAP DB를 잘 튜닝하자”가 아니라 “에이전트 trace라는 데이터 모양에 맞춰 저장소를 다시 짜자”에 가까워요. run이 한 줄짜리 row가 아니라 여러 event로 늦게 완성되기 때문에, 일반적인 span 저장 모델만으로는 필터링과 병합 비용이 계속 커지거든요. - 오브젝트 스토리지를 durable layer로 둔 것도 배포 전략과 연결돼요. LangSmith 고객은 클라우드, 자체 호스팅, 멀티 클라우드 요구가 섞여 있으니 로컬 디스크와 샤딩에 강하게 묶인 DB 클러스터는 운영 부담이 커져요. 상태 없는 query·ingestion service를 늘리는 방식이면 compute 확장이 훨씬 단순해져요. - Progressive querying은 관측성 UI에서 체감이 큰 선택이에요. 사용자는 보통 “최근 실패한 run 몇 개”를 먼저 보려 하지, 전체 trace corpus를 완벽히 스캔하고 싶어 하진 않거든요. 그래서 최신 segment부터 좁은 범위로 읽고 멈추는 전략이 제품 속도에 바로 꽂혀요. - full-text search와 JSON filtering을 object storage 위에서 하려면 index layout이 중요해요. 로컬 디스크처럼 작은 seek를 마구 날릴 수 없으니, row group pruning과 chunk 분리를 통해 불필요한 range read를 줄이는 쪽으로 설계해야 해요. - 결국 SmithDB는 에이전트 개발 루프를 줄이기 위한 인프라예요. trace를 빨리 찾고, edge case를 eval dataset으로 뽑고, 비용·latency·token 사용량을 바로 집계할 수 있어야 운영 중인 에이전트를 계속 개선할 수 있거든요. ## 핵심 포인트 - 에이전트 트레이스가 길고 크고 중첩되면서 기존 관측성 저장소로는 한계가 커짐 - SmithDB는 오브젝트 스토리지, Postgres 메타스토어, 상태 없는 수집·쿼리·컴팩션 서비스로 구성됨 - 최신 데이터 우선 조회, 수집 노드 캐시 읽기, 이벤트 단위 런 병합, 시간 계층 컴팩션 같은 최적화가 핵심임 - 자체 호스팅과 멀티 클라우드 배포를 염두에 둔 구조라 기업 도입 장벽을 낮추려는 의도가 큼 ## 인사이트 LLM 앱이 ‘프롬프트 몇 개 호출’에서 장시간 돌아가는 에이전트로 바뀌면서, 관측성도 그냥 로그 저장 문제가 아니게 됐다는 신호야. LangSmith가 전용 DB까지 만든 건 에이전트 운영 데이터가 앞으로 꽤 큰 인프라 시장이 될 거라는 베팅으로 보임.