LLM Wiki

Harrison Chase — LangSmith의 Trace·Thread·Trajectory

Properties2
descriptionHarrison Chase가 LangSmith의 trace·thread·trajectory 구분과 관측 데이터의 메모리·학습 활용을 소개한 X 게시물.
tagsai-agents, dev-tools, monitoring, research

5 min read

원문: Harrison Chase의 X 게시물 · 게시일: 2026-08-14
“some great new LangSmith docs on traces vs threads vs trajectories (new concept)”

게시물은 LangSmith의 새 관측가능성 문서를 소개하며, 관측 데이터가 운영 모니터링만이 아니라 에이전트의 memory와 learning에도 쓰일 수 있다고 강조한다. 핵심은 같은 실행 데이터를 목적에 따라 서로 다른 뷰로 읽을 수 있도록 명확한 정신 모델을 갖는 것이다.

핵심 요지

  • Trace·thread·trajectory는 같은 실행 데이터를 서로 다른 해상도로 보는 모델이다. trace는 한 작업의 실행 구조를, thread는 멀티턴 세션을, trajectory는 사용자가 실제로 주고받은 메시지 경로를 보기 위한 단위다.
  • Observability 데이터는 사후 로그에 머물지 않는다. 실패한 도구 호출·반복되는 패턴·사용자 피드백을 추출하면 평가, 디버깅, 장기 메모리 갱신, 다음 실행의 컨텍스트 개선으로 이어질 수 있다. 이 확장은 게시물의 주장과 공식 문서를 바탕으로 한 해석이다.
  • 기록과 학습을 분리해서 설계할 수 있다. 모든 실행을 trace로 보존하되, thread와 trajectory를 평가·리뷰·메모리 작성에 맞는 투영으로 사용하면 같은 원천 데이터를 여러 운영 루프에서 재사용할 수 있다.

Trace·Thread·Trajectory 구분

개념구조적합한 질문
Trace하나의 작업을 구성하는 run들의 트리왜 한 번의 실행이 실패했거나 느렸는가? 어떤 모델·도구 호출이 원인이었는가?
Thread한 멀티턴 세션의 trace 시퀀스여러 턴에 걸쳐 에이전트가 어떻게 행동했으며 중첩·타이밍은 어땠는가?
Trajectory중복을 제거한 메시지의 순서 있는 평탄화실행 세부사항을 덜어내고 사용자·AI·도구 메시지의 경로를 어떻게 읽을 것인가?

공식 문서 기준으로 trace 안에는 전체 run의 입력·출력이 들어가고, thread는 연결된 trace들의 run을 유지하며, trajectory는 연결된 trace에서 메시지를 한 번씩만 포함한다. 따라서 디버깅은 trace, 세션 행동 분석은 thread, 대화 경로·학습 데이터 검토는 trajectory라는 선택이 자연스럽다.

적용 메모

  1. 운영 디버깅: trace를 기준으로 latency, 실패한 tool call, 잘못된 출력의 원인을 찾는다.
  2. 세션 평가: thread를 기준으로 멀티턴에서 컨텍스트가 누적·오염·회복되는 과정을 본다.
  3. 메모리·학습 루프: trajectory에서 반복되는 사용자 의도, 교정, 성공 패턴을 추출한 뒤 평가셋·프로시저 메모리·스킬 문서로 승격하기 전에 검토한다.
  4. 프라이버시 경계: 메시지·입출력 원문을 장기 보존하거나 학습에 사용할 때는 PII, 보존 기간, 삭제 정책을 별도로 정한다.

첨부 이미지

이미지는 LangSmith 공식 문서의 비교표를 보여 준다. trace는 run tree, thread는 trace sequence, trajectory는 flat ordered message list로 대비된다.

관련 노트

백링크