🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

LangSmith는 장기 실행·중첩·멀티모달 에이전트 트레이스를 기존 관측성 저장소로 처리하기 어렵다고 보고, 이를 위해 Rust 기반의 객체 스토리지 지원 분산 데이터 계층인 SmithDB를 구축해 핵심 LangSmith 워크로드에 적용했다.

📌 핵심 요약

• 현대 에이전트 트레이스는 수백 개의 깊게 중첩된 span, 이미지·오디오 같은 멀티모달 콘텐츠, 몇 분에서 몇 시간 동안 열린 상태로 남는 이벤트를 포함하면서 데이터 규모와 질의 패턴이 크게 복잡해졌다.
• LangSmith가 요구하는 관측성 질의는 단일 run·trace 즉시 로드, 메타데이터·피드백·지연시간·오류·태그·시간 기준 필터링, 전체 텍스트 검색, JSON 필터링, 트리 인식 질의, 스레드 재구성, 비용·토큰·평가 점수 집계까지 포괄한다.
• SmithDB는 LangSmith의 에이전트 관측성과 평가 워크로드를 위해 만든 데이터 계층으로, Rust로 구현됐고 Apache DataFusion 쿼리 엔진과 Vortex 파일 툴킷을 활용하며 객체 스토리지, 작은 Postgres 메타스토어, stateless ingestion·query·compaction 서비스로 구성된다.
• 본문에 따르면 SmithDB는 trace tree load P50 92ms, single run load P50 71ms, runs filtering P50 82ms, full-text search P50 400ms 등의 지연시간을 제공하며, 핵심 LangSmith 경험을 이전보다 크게 빠르게 만들었다.
• SmithDB는 객체 스토리지 기반 LSM 구조, 최신 구간을 제한해 읽는 progressive querying, ingestion node의 SSD·메모리 캐시 활용, run을 여러 이벤트의 시퀀스로 다루는 모델, time-tiered compaction, 삭제·업그레이드 벡터, 큰 필드의 late materialization 같은 설계를 통해 에이전트 관측성에 맞춘 성능과 확장성을 확보한다.

🧩 주요 포인트

1. 현대 에이전트 트레이스는 수백 개의 깊게 중첩된 span, 이미지·오디오 같은 멀티모달 콘텐츠, 몇 분에서 몇 시간 동안 열린 상태로 남는 이벤트를 포함하면서 데이터 규모와 질의 패턴이 크게 복잡해졌다.
2. LangSmith가 요구하는 관측성 질의는 단일 run·trace 즉시 로드, 메타데이터·피드백·지연시간·오류·태그·시간 기준 필터링, 전체 텍스트 검색, JSON 필터링, 트리 인식 질의, 스레드 재구성, 비용·토큰·평가 점수 집계까지 포괄한다.
3. SmithDB는 LangSmith의 에이전트 관측성과 평가 워크로드를 위해 만든 데이터 계층으로, Rust로 구현됐고 Apache DataFusion 쿼리 엔진과 Vortex 파일 툴킷을 활용하며 객체 스토리지, 작은 Postgres 메타스토어, stateless ingestion·query·compaction 서비스로 구성된다.
4. 본문에 따르면 SmithDB는 trace tree load P50 92ms, single run load P50 71ms, runs filtering P50 82ms, full-text search P50 400ms 등의 지연시간을 제공하며, 핵심 LangSmith 경험을 이전보다 크게 빠르게 만들었다.
5. SmithDB는 객체 스토리지 기반 LSM 구조, 최신 구간을 제한해 읽는 progressive querying, ingestion node의 SSD·메모리 캐시 활용, run을 여러 이벤트의 시퀀스로 다루는 모델, time-tiered compaction, 삭제·업그레이드 벡터, 큰 필드의 late materialization 같은 설계를 통해 에이전트 관측성에 맞춘 성능과 확장성을 확보한다.

🧠 상세 정리

1. 에이전트 트레이스가 만든 새로운 데이터 문제

본문은 에이전트 관측성에서 trace가 에이전트의 핵심 행동 기록이라고 설명하며 시작한다. LangSmith가 처음 출시된 2023년에는 AI 애플리케이션이 상대적으로 단순해 RAG 파이프라인, 프롬프트 체인, 초기 형태의 에이전트가 중심이었다. 그러나 이후 에이전트는 더 널리 쓰이고 더 오래 실행되며, LLM 컨텍스트 윈도우도 커지고 이미지·오디오 같은 멀티모달 콘텐츠도 늘었다. 그 결과 현대 에이전트 trace는 개수와 개별 payload 크기 모두에서 커졌고, 수백 개의 깊게 중첩된 span을 포함할 수 있게 됐다. 또한 agent span의 시작 이벤트가 도착한 뒤 종료 이벤트가 몇 분 또는 몇 시간 뒤에 도착할 수 있어, 단순한 요청·응답 로그와 다른 저장·질의 문제가 생겼다.

2. 기존 관측성 저장소로 감당하기 어려운 질의 패턴

본문은 에이전트 관측성 데이터가 단지 크기만 커진 것이 아니라 분석에 필요한 질의 방식도 복잡해졌다고 말한다. 필요한 기능에는 개별 run이나 trace를 즉시 여는 random access, 대규모 trace 집합을 메타데이터·피드백·지연시간·오류·태그·시간으로 자르는 interactive filtering, 입력과 출력 내부의 문구를 찾는 full-text search가 포함된다. 여기에 사용자 정의 메타데이터와 구조화된 tool output을 대상으로 하는 JSON filtering, root run·child run·trace 내 임의 노드를 기준으로 하는 tree-aware query도 필요하다. 장기 실행 대화를 여러 에이전트 trace에 걸쳐 즉시 재구성하는 thread reconstruction, 비용·지연시간·토큰 사용량·evaluator score 집계도 핵심 요구사항으로 제시된다. 저지연으로 이 모든 기능을 지원하면서 self-hosting과 multi-cloud 요구까지 만족하려면 기존 범용 데이터베이스와 다른 아키텍처가 필요하다는 것이 SmithDB의 출발점이다.

3. SmithDB의 목적과 기본 구성

SmithDB는 LangSmith의 에이전트 관측성과 평가 워크로드를 위해 만든 전용 데이터 계층으로 소개된다. 본문은 SmithDB가 Rust로 작성됐고, Apache DataFusion 쿼리 엔진과 Vortex 파일 툴킷을 활용하되 LangSmith의 특수한 워크로드에 맞춰 강하게 커스터마이즈됐다고 설명한다. 높은 수준의 구성은 내구성 있는 trace data를 위한 object storage, segment metadata를 기록하는 작은 Postgres metastore, 그리고 stateless ingestion·query·compaction service로 나뉜다. 이 구조는 데이터의 내구성을 객체 스토리지에 맡기고, 서비스 노드는 상태를 덜 갖도록 만들어 배포와 확장을 단순화하는 방향이다. SmithDB는 전통적인 관측성 저장소가 설계되지 않았던 agent-native query pattern을 지원하기 위해 LangSmith의 핵심 워크로드 뒤에서 동작한다.

4. 성능 목표와 실제 지연시간

본문은 관측성에서 성능이 단순한 부가 기능이 아니라 개발 루프의 병목을 좌우하는 핵심 요소라고 강조한다. 인간 개발자와 에이전트 모두에게 관측성 도구가 느리면 디버깅과 개선 속도가 떨어지기 때문이다. SmithDB의 성능 수치로는 trace tree load P50 92ms·P99 595ms, single run load P50 71ms·P99 358ms, runs filtering P50 82ms·P99 434ms가 제시된다. trace ingestion은 P50 630ms·P99 1.47s, full-text search는 P50 400ms·P99 870ms, threads filtering은 P50 131ms·P95 268ms로 설명된다. 본문은 이런 성능이 핵심 LangSmith 경험을 이전보다 최대 12배 빠르게 만든다고 말하며, 상단 요약에서는 일부 핵심 경험이 최대 15배 빨라졌다고도 제시한다.

5. 객체 스토리지 기반의 이식성과 배포 상태

SmithDB의 중요한 특징으로는 이식성과 확장성이 제시된다. 객체 스토리지를 기반으로 하기 때문에 관리해야 할 로컬 디스크가 없고, query service와 ingestion service는 stateless로 설계된다. 시스템은 내구성 있는 데이터를 객체 스토리지에 두고 compute를 추가하는 방식으로 확장되므로, 로컬 디스크와 복잡한 sharding이 필요한 전통적 데이터베이스 클러스터보다 self-hosted 및 multi-cloud 환경에 배포하기 쉽다고 설명된다. 현재 SmithDB는 이미 production traffic을 처리하고 있으며, US Cloud ingestion의 100%와 threads를 포함한 tracing UI query traffic의 100%가 SmithDB로 간다고 본문은 밝힌다. metadata, feedback, text search, tree filter, trace filter 같은 주요 filter도 SmithDB가 지원하고 있으며, run rules, bulk export, experiments 같은 product integration은 완료에 가까운 상태로 언급된다.

6. 고객 워크로드 이전과 체감된 효과

본문은 지난 몇 달 동안 고객 워크로드를 SmithDB로 이전해 왔다고 설명하며 Clay, Vanta, Unify, Cogent Security의 피드백을 제시한다. Clay는 매일 수억 건의 agent observability event를 LangSmith에 기록한다고 말하며, SmithDB 덕분에 production agent 개선에 필요한 속도로 검색·디버깅·분석할 수 있게 됐다고 평가한다. Vanta는 SmithDB 이전 후 UX가 훨씬 민첩해졌고 데이터를 파고드는 과정이 더 빠르고 직관적이 됐다고 말한다. Unify는 큰 tool call을 포함한 많은 trace를 다루는 상황에서 프로젝트 전반의 trace를 조회하고 읽는 일이 쉬워졌고, edge case 파악과 eval dataset 구축, trace 반복 개선이 빨라졌다고 설명한다. Cogent Security는 background agent가 한 번에 많은 trace를 만들 수 있는데, 다른 제공자를 테스트했을 때는 몇 분이 걸리던 trace 확인을 SmithDB에서는 몇 초 안에 볼 수 있었다고 말한다.

7. LSM 기반 아키텍처와 주요 서비스 역할

본문은 SmithDB를 객체 스토리지 기반 log-structured merge tree, 즉 LSM으로 설명한다. LSM은 쓰기를 메모리에 버퍼링한 뒤 불변의 정렬된 batch로 durable storage에 flush하고, 이후 segment들을 주기적으로 compact하며, 질의 시 여러 segment를 하나의 정렬된 stream처럼 읽고 병합한다. SmithDB의 ingestion service는 trace write를 받아 partition과 time bucket별로 batch 처리한 뒤 immutable file을 쓴다. metastore는 segment 위치, 시간 범위, row count, update/delete vector 같은 metadata를 기록하고, query service는 LangSmith run semantics와 object storage를 이해하는 custom execution plan으로 질의 인터페이스를 제공한다. compaction service는 write-optimized segment를 query-optimized segment로 다시 쓰며 delete, upgrade, TTL expiry, index merging을 적용하고, cluster manager는 key range에 live service node를 배정해 반복 질의가 캐시된 데이터를 가진 노드에 도달할 가능성을 높인다.

8. 객체 스토리지 질의, 최신 데이터 읽기, 장기 span 처리

SmithDB의 핵심 엔지니어링 과제 중 하나는 객체 스토리지 위에서 최신 run을 빠르게 가져오는 것이다. 단순한 방식이라면 후보 파일을 모두 찾고 여러 파일을 열어 정렬 병합과 중복 제거를 한 뒤 limit을 적용해야 하지만, SmithDB는 시간을 거슬러 올라가며 최신 후보 segment에 대한 제한된 시간 창을 만들고, 필요한 만큼 stream·merge·dedupe한 뒤 정확성이 허용되는 시점에 멈춘다. 또한 객체 스토리지가 durable source of truth이지만 가장 최신 데이터는 작성한 ingestion node에 남아 있을 수 있으므로, writer가 온라인이면 query planner가 해당 노드의 local SSD와 memory cache에서 직접 scan할 수 있다. 에이전트 span은 오래 열려 있을 수 있어 SmithDB는 run을 단일 immutable row가 아니라 이벤트의 sequence로 다루며, query time에 이벤트를 효율적으로 merge한다. 이 모델은 filter fanout과 compaction 전략에도 영향을 주며, 장기 실행 agent workload를 기존 요청·응답 span과 다르게 처리하게 만든다.

9. Compaction, 삭제·보존 정책, 큰 payload 최적화

SmithDB는 ingestion에서 write latency를 우선하기 때문에 많은 작은 immutable segment가 만들어질 수 있고, 이를 계속 그대로 질의하면 file-open overhead와 deduplication 비용이 커진다. 그래서 compaction은 write-optimized segment를 query-optimized segment로 바꾸며, SmithDB는 최근 데이터와 오래된 데이터를 다르게 다루는 time-tiered 전략을 사용한다. 최근 데이터는 end event를 더 받을 가능성이 높아 너무 빨리 큰 파일로 compact하면 불필요한 write amplification이 생기고, 오래된 데이터는 더 안정적이며 반복적으로 scan될 가능성이 높기 때문에 더 큰 파일로 접는 것이 유리하다고 설명된다. 삭제, TTL, retention 변경처럼 immutable file과 충돌하기 쉬운 mutation은 매번 동기적으로 파일을 다시 쓰는 대신 metastore의 deletion·upgrade vector로 표현되고, query와 compaction path가 이를 해석한다. 또한 에이전트 trace의 큰 JSON payload를 매번 읽지 않도록 core run field와 large field를 분리하고, 목록 조회나 필터링에서는 포인터만 사용하다가 사용자가 run을 열거나 해당 field를 요청할 때만 큰 payload를 가져오는 late materialization을 적용한다.

🧾 핵심 주장 / 시사점

• SmithDB의 핵심 메시지는 에이전트 관측성이 단순 로그 저장 문제가 아니라, 중첩 trace·장기 span·부분 이벤트·멀티모달 payload·트리 질의를 동시에 처리해야 하는 별도 데이터 계층 문제라는 점이다.
• 객체 스토리지 기반 stateless 구조는 self-hosted와 multi-cloud 요구를 겨냥한 선택이며, 성능 문제는 progressive querying, ingestion node cache 활용, late materialization처럼 워크로드 특화 최적화로 보완하고 있다.
• 본문의 고객 사례는 SmithDB의 가치가 단순 벤치마크가 아니라 대규모 production agent 운영에서 trace 탐색, edge case 파악, eval dataset 구축, 디버깅 속도 개선으로 체감되고 있음을 보여준다.

✅ 액션 아이템

• 에이전트 트레이스의 수백 개 중첩 span, 멀티모달 이벤트, 장시간 유지 특성을 기준으로 관측성 처리 대상과 용량·질의 패턴 갭을 재정의한다.
• LangSmith 요구의 즉시 로드, 필터, 전체 텍스트 검색, 트리 인식 질의, 스레드 재구성, 비용·토큰·평가 점수를 아우르는 질의 경로를 단일 스키마로 정렬한다.
• SmithDB의 객체 스토리지 기반 LSM, progressive querying, SSD·메모리 캐시, time-tiered compaction, late materialization을 반영해 P50 지연 목표(trace tree 92ms, single run 71ms 등)에 맞춘 성능 체크를 설정한다.

❓ 열린 질문

• 멀티모달 이미지·오디오가 있는 수백 개 중첩 span 트레이스에서 trace tree load 92ms, single run load 71ms를 동시에 만족하려면 병목 판단은 어떤 지표로 할 것인가?
• 객체 스토리지 기반 LSM에서 긴 시간 열린 이벤트를 다룰 때 최신 구간 제한 progressive querying이 삭제·업그레이드 벡터와 어떻게 조합되어야 데이터 정합성이 유지되는가?
• 메타데이터·피드백·지연시간·오류·태그·시간 필터와 JSON 필터, tree-aware 질의를 결합했을 때 runs filtering 82ms와 full-text 400ms 성능 한계를 어떻게 정의할 것인가?