Breadcrumb

Breadcrumb는 코드 의존성으로 설치한다. 즉 트레이스 데이터를 위한 외부 계정도, 네트워크 왕복도 없다. 인스턴스를 하나 만들고 자신의 데이터베이스로 향하면 자신의 프로세스 안에서 돈다. 스스로 정하지 않는 한 어떤 것도 인프라 밖으로 나가지 않는다. 예상 밖의 일은 없다. 데이터 규칙이 엄격한 팀에게는 이 점이 결정적 요인인 경우가 많다.

스팬은 breadcrumb_spans라는 단일 테이블로 정규화되어, 앱이 이미 쓰고 있는 데이터베이스에 존재한다. 내보내기도, 웹훅도, 남의 스키마 위의 읽기 전용 API도 아니다. 분석은 쓰는 ORM으로 하는 평범한 쿼리가 되므로, 트레이스를 사용자, 주문, 그 밖에 보관하는 무엇과도 조인할 수 있다. 예컨대 Prisma 사용자는 이 테이블을 끌어와 다른 모델처럼 다룰 수 있다.

모델 호출은 스스로 계측된다. Vercel AI SDK가 experimental_telemetry를 기대하는 곳에 bc.telemetry()를 넘기면, Breadcrumb는 SDK가 이미 내보내는 속성에서 모델, 제공자, 토큰 수, 비용, 페이로드를 읽는다. 호출마다 수작업으로 스팬을 조립할 필요가 없다. 설정이 작게 유지되고, 기존 프로젝트를 다시 쓰지 않고도 추적을 더하기 쉬워진다.

모델 호출 주변 작업은 스스로 계측되지 않으므로 bc.trace()로 감싼다. 검색, 도구 호출, 마지막 데이터베이스 쓰기가 모델 스팬과 같은 타임라인에 놓인다. 요청이 느리게 느껴질 때 지연이 검색에 있는지, 도구에 있는지, 모델 자체에 있는지를 추측 대신 확인할 수 있다.

Breadcrumb는 MCP로 트레이스를 노출하므로, 에이전트가 개발자처럼 쿼리할 수 있다. 코딩 에이전트에 키를 주고 프로덕션 트레이스를 파헤치게 하거나, 직접 대시보드를 읽어도 된다. hidePayloads 옵션은 원본 프롬프트를 에이전트가 보는 범위 밖으로 둔다. 트레이스에 민감한 사용자 입력이 담길 때 중요하다.

대시보드는 컴포넌트이지 고정된 SaaS 화면이 아니다. 호스팅 도구는 모두의 앱을 제공하므로 범용으로 남을 수밖에 없지만, 자신의 것은 자신의 앱만 제공하면 된다. 자신의 인증 뒤에 마운트하고, 추가 패널을 그 안의 페이지로 낼 수 있다. 대시보드 UI가 남의 도메인에 있고 모든 고객의 앱을 제공해야 할 때는 이런 유연성을 얻기 어렵다.

보존은 환경별로 정하는 기간이며, 트레이스가 들어올 때마다 정리된다. 이벤트 단위로 과금되는 것이 없으므로, 청구서를 낮게 유지하려고 페이로드를 샘플링하거나 버릴 필요가 없다. 데이터를 얼마나 두는지는 직접 정하고, 그 기간 동안 완전한 트레이스를 유지한다.