LLM 관측 가능성의 세션, 트레이스, 스팬: 이 중 하나는 구조적 레벨이 아닙니다

LLM 관측 가능성의 세션, 트레이스, 스팬: 이 중 하나는 구조적 레벨이 아닙니다

Datadog 용어 페이지는 LLM 관측 가능성 세션 트레이스 스팬이라는 검색어의 Google 1위 결과인데, 이 세 단어 중 두 가지만 정의합니다. 세 가지가 아닙니다. 빠진 하나는 gen_ai.conversation.id에 대응하며, 빠진 이유는 OpenTelemetry 명세가 이를 구조적 레벨로 만들지 않았기 때문입니다. 관측 가능성 자체에 대한 근거가 필요하다면 이 글부터 시작하세요. 이 글은 그 글이 멈춘 지점, 즉 데이터 모델에서 이어갑니다.

핵심 요약

• 스팬은 트레이스 안에 중첩되고, 트레이스는 세션으로 그룹화됩니다. 중첩은 안쪽에서 바깥쪽으로 이어집니다: 스팬, 그다음 트레이스, 그다음 세션.
• 스팬은 하나의 시간 측정 연산입니다. 트레이스는 하나의 종단 간 요청입니다. 세션은 하나의 다중 턴 대화입니다.
• OpenTelemetry의 GenAI 규칙은 스팬과 gen_ai.conversation.id 속성을 정의합니다. 세션 레벨은 정의하지 않습니다.
• 트레이스 ID와 스팬 ID는 컨텍스트를 통해 자동으로 전파됩니다. 세션 ID는 그렇지 않습니다. 매 턴마다 직접 설정해야 합니다.

세션 vs 트레이스 vs 스팬, 한눈에 보기

LLM 관측 가능성에서 스팬은 하나의 시간 측정 연산(모델 호출, 검색 단계)이고, 트레이스는 하나의 요청이 생성하는 스팬 트리이며, 세션은 같은 대화에서 나온 여러 트레이스를 그룹화합니다. 중첩은 안쪽으로 향합니다: 트레이스 안의 스팬, 세션 안의 트레이스. 세 번째 그룹핑이 겉보기와 다른 것입니다.

이 개수와 수명 수치는 RAG 챗봇이나 에이전트 루프에서 예상할 수 있는 일반적인 범위이며, 통제된 테스트의 측정값이 아닙니다. 실제 수치는 다를 수 있습니다. 변하지 않는 것: 세션 행이 명세에서 구조적 레벨이 아닌 것이며, "세션: 도구가 아마 발명했을 레벨" 섹션에서 이를 증명합니다.

스팬이란 무엇이며, 스팬 종류란 무엇인가?

스팬은 이름, 시작 타임스탬프, 종료 타임스탬프, 상태 코드, 키-값 속성 묶음을 가진 하나의 시간 측정 연산입니다. LLM 트레이싱에서 유용한 데이터는 속성에 있습니다: gen_ai.usage.input_tokens, gen_ai.usage.output_tokens, gen_ai.request.model이 연산 비용과 실행 모델을 알려줍니다.

스팬은 하나의 연산이지, 하나의 함수 호출이 아닙니다

모든 스팬은 트리를 구성하는 부모 스팬 ID 포인터를 가집니다(루트 스팬에서는 비어 있음). 속성 묶음은 열려 있습니다: 필요한 컨텍스트를 무엇이든 첨부할 수 있습니다. OpenTelemetry GenAI 스팬 규칙(상태: Development)은 모든 GenAI 스팬에 gen_ai.operation.name과 gen_ai.provider.name을 요구하며, 위 토큰 사용량 속성을 권장합니다.

Datadog 용어 페이지의 실용적 규칙 하나: LLM, Workflow, Agent 스팬은 루트 스팬이 될 수 있지만, Tool, Task, Embedding, Retrieval 스팬은 될 수 없습니다. 이것은 Datadog의 규칙이지 보편적 규칙은 아니지만, 이를 명시하는 유일한 벤더이며, 부모 없이 도구 호출에서 시작하는 트레이스를 만드는 실수를 막아줍니다.

스팬 종류: 같은 아이디어, 다섯 가지 어휘

모든 도구는 "이 스팬은 모델 호출이다"와 "이 스팬은 검색이다"를 구분하는 방법이 필요합니다. 다만 용어에 합의하지 못했습니다:

OpenInference 명세는 10가지 종류를 나열합니다. Datadog은 7가지를 나열합니다. OTel은 제3의 경로를 취합니다: GenAI 속성 레지스트리는 gen_ai.operation.name에 대해 15개의 잘 알려진 값(chat, create_agent, create_memory, create_memory_store, delete_memory, delete_memory_store, embeddings, execute_tool, generate_content, invoke_agent, invoke_workflow, plan, retrieval, search_memory, text_completion)을 공개하고, 이 중 하나가 해당하면 그 값을 반드시 사용해야 하며, 커스텀 값은 해당하는 것이 없을 때만 사용할 수 있다고 명시합니다. 즉 반개방 열거형이지, 열거형의 부재가 아닙니다. 세 개의 목록, 세 개의 길이, 그리고 서로 간 정렬 없음. 도구를 선택 중이라면, 이 어휘 간극이 기능 목록보다 중요합니다. 대시보드와 알림 필터가 이 어휘에 키를 맞추기 때문입니다.

트레이스란 무엇이며, 트리 형태가 왜 중요한가?

트레이스는 하나의 요청이 생성한 스팬 트리입니다. 하나의 루트 스팬이 꼭대기에 있고, 다른 모든 스팬은 부모 스팬 ID 간선으로 그 아래에 매달립니다. 트리 형태가 핵심입니다: 플랫 로그는 무언가가 느렸다고 알려주지만, 트리는 어떤 단계가 느렸는지, 어떤 단계가 잘못된 출력을 만들었는지 알려줍니다.

chat_request (root)                         2,340ms
├── retrieval                                 410ms
│   └── rerank                                 85ms
├── chat gpt-4o                             1,720ms
└── tool_call: search_calendar                190ms

이 트리를 읽으면 진단이 즉각적입니다: 지연의 74%가 모델 호출에 있었지, 검색에 있지 않았습니다. 다섯 타임스탬프의 플랫 로그는 같은 합계를 주지만, 귀속 정보는 전혀 주지 않습니다.

에이전트 루프는 일반 RAG 요청보다 이 트리를 더 깊고 넓게 만듭니다. 각 도구 호출은 자체 서브트리를 생성합니다. 5단계 에이전트 턴은 하나의 루트 아래 30개 이상의 스팬을 쉽게 생성할 수 있습니다. 이것은 정상이며, 아래 스팬 세분화 질문이 존재하는 이유입니다.

트레이싱과 로깅의 구분도 여기서 중요합니다: 로깅은 이벤트를 기록하고, 트레이싱은 인과관계를 기록합니다. 무엇을 로깅하고 무엇을 트레이싱할지 아직 결정 중이라면, LLM 로깅 모범 사례 글에서 그 경계를 그어줍니다.

세션: 도구가 아마 발명했을 레벨

아닙니다. 세션은 OpenTelemetry GenAI 규칙에서 구조적 레벨이 아닙니다. 명세는 스팬과 gen_ai.conversation.id 속성(조건부 필수, "사용 가능할 때", 상태: Development)을 정의하며, 메시지를 상관시키는 데 사용되는 대화 또는 스레드의 고유 식별자로 설명합니다. 벤더는 그 속성 위에 자체 세션 객체를 구축합니다. 이 SERP에서 명세 상태를 솔직하게 말하는 곳은 없으므로, 여기서 밝힙니다.

그 결과는 이 글 전체가 전달하기 위해 존재하는 문장입니다:

세션은 그룹핑 키이지, 부모 스팬이 아닙니다. 트레이스 ID처럼 전파되지 않으며, 매 턴마다 직접 설정해야 합니다.

한 턴을 빠뜨리면 그 턴은 세션에서 벗어납니다. 자동 컨텍스트 전파가 없습니다.

세션은 언제 시작하고 끝나는가?

벤더 정의입니다. 일부 도구는 새 대화 ID를 가진 첫 번째 트레이스에서 세션을 열고 비활성 타임아웃으로 닫습니다(Langfuse는 설정 가능한 윈도우가 기본값). 다른 도구는 명시적 종료 호출을 요구합니다. 명세는 라이프사이클에 대해 아무것도 말하지 않습니다. 명세는 세션을 객체로 모델링하지 않기 때문입니다.

턴 사이에 무엇이 전달되고, 무엇이 전달되지 않는가?

모델의 컨텍스트 윈도우는 세션이 아닙니다. 세션은 독립적 트레이스 위의 그룹핑 키입니다. 각 턴은 자체 트레이스, 자체 루트 스팬, 자체 토큰 수를 가집니다. 전달되는 것은 각 루트 스팬에 찍은 대화 ID 속성입니다. 전달되지 않는 것: 지연 시간, 토큰 사용량, 스팬 구조. 이것들은 트레이스 단위입니다.

세션 레벨 메트릭은 무엇을 측정하는가?

단일 트레이스가 측정할 수 없는 것들: 해결률(대화가 사용자 문제를 해결했는가?), 응답까지의 턴 수(사용자가 필요한 것을 얻기까지 몇 개의 트레이스가 있었는가?), 중단된 대화(종료 신호 없는 세션). 세션 레벨에서 실시간 트레이스에 대한 평가를 실행하면 턴 단위로는 정상으로 보이는 다중 턴 실패를 잡아낼 수 있습니다.

코드, 벤더 중립적

이 스니펫은 안정적인 OTel 프리미티브만 사용합니다. 벤더 SDK 없음. 하나의 턴에 대한 루트 스팬, 검색에 대한 자식 스팬, 모델 호출에 대한 자식 스팬을 생성하고, gen_ai.conversation.id를 설정하여 세 턴이 하나의 세션에 들어가게 합니다:

from opentelemetry import trace

tracer = trace.get_tracer("my-llm-app")

SESSION_ID = "conv-8f3a2c"  # same value on every turn

def handle_turn(user_message: str):
    with tracer.start_as_current_span("chat_request") as root:
        # You set this. It does not propagate automatically.
        root.set_attribute("gen_ai.conversation.id", SESSION_ID)

        with tracer.start_as_current_span("retrieval") as ret:
            ret.set_attribute("gen_ai.operation.name", "retrieval")
            docs = retrieve(user_message)

        with tracer.start_as_current_span("chat gpt-4o") as llm:
            llm.set_attribute("gen_ai.operation.name", "chat")
            llm.set_attribute("gen_ai.provider.name", "openai")
            llm.set_attribute("gen_ai.request.model", "gpt-4o")
            response = call_model(user_message, docs)
            llm.set_attribute("gen_ai.usage.input_tokens", 1_204)
            llm.set_attribute("gen_ai.usage.output_tokens", 312)

    return response

같은 SESSION_ID로 handle_turn을 세 번 호출하면, 이 속성을 읽는 모든 백엔드에서 세 트레이스가 하나의 세션 아래 그룹화됩니다. ID를 바꾸면 새 세션이 시작됩니다. 이것이 전체 메커니즘입니다.

벤더 5곳의 문서를 나란히 읽었습니다. 합의하지 못합니다.

2026-07-30에 Langfuse, LangSmith, OpenInference / Phoenix, Datadog의 현재 데이터 모델 문서를 나란히 읽고, OpenTelemetry GenAI 스팬 명세도 확인했습니다. 다섯 중 네 곳이 같은 객체를 다르게 부릅니다. 세션을 속성이 아닌 일급 객체로 다루는 곳은 하나뿐입니다. 이 검색어의 Google 1위 결과인 Datadog 용어 페이지는 세션을 아예 정의하지 않습니다.

첫 번째 행에 대한 출처 참고: OpenInference의 session.id는 위에 링크한 트레이스 명세에 없습니다. 그 명세는 10가지 스팬 종류를 다룹니다. session.id는 형제 파일인 OpenInference 시맨틱 컨벤션 파일에서 세션의 고유 식별자로 정의됩니다. 두 파일, 하나의 명세.

벤더 간 비교를 우리가 발명한 것은 아닙니다. FutureAGI도 OTel vs 벤더 테이블을 공개합니다. 우리의 두 가지 추가는 세션 행(FutureAGI는 빠뜨림)과 같은 단어-다른 의미 함정입니다: Langfuse의 "observation"과 LangSmith의 "run"은 스팬과 같은 객체이고, Datadog과 OpenInference의 스팬 종류는 같은 아이디어에 대한 다른 어휘입니다.

Langfuse는 observation이라 부르고, LangSmith는 run이라 부르고, Datadog은 span이라 부릅니다. 같은 객체, 마이그레이션하면 깨지는 세 개의 대시보드.

이것은 마이그레이션 비용에 대한 우리의 해석이지, 벤더의 주장이 아닙니다. 하지만 이것이 "observation"이나 "run"에 키를 맞춘 저장된 필터, 평가 설정, 알림 규칙이 도구를 전환하는 날 작동을 멈추는 이유입니다. 필드를 이름 변경하는 것이 아닙니다. 레벨을 이름 변경하는 것입니다. 이 두 도구를 구체적으로 저울질 중이라면, Langfuse vs LangSmith 비교에서 분기를 더 깊이 다룹니다.

독자의 스택에 이미 Opik, PostHog, Sentry, Weights & Biases가 있을 수 있습니다. Google은 이 네 가지 모두를 llm tracing과 연관시키며, 각각 이 개념을 약간 다르게 매핑합니다. 올바른 것을 선택하려면? 관측 가능성 플랫폼 라운드업에서 전체 분야를 다룹니다.

최신성 참고: GenAI 규칙은 메인 semantic-conventions 저장소에서 자체 저장소로 이동했습니다. 기존 opentelemetry.io/docs/specs/semconv/gen-ai/ 경로에는 이제 포인터만 있습니다.

어떤 ID가 어디에 가는가?

트레이스 ID는 하나의 요청을 식별하며 컨텍스트를 통해 자동으로 전파됩니다. 스팬 ID는 그 트레이스 내 하나의 연산을 식별하며, 역시 자동입니다. 상관 ID(또는 요청 ID)는 트레이싱이 시작되기 전에 웹 티어에서 오며, 트레이스 ID와 가장 많이 혼동하는 것입니다. 세션 ID는 특이한 경우입니다: 매 턴마다 직접 수동으로 설정해야 합니다.

실용적 규칙: gen_ai.conversation.id를 모든 턴의 루트 스팬에 스팬 속성으로 첨부하고, 사용자 ID도 함께 찍으세요. 한 턴을 건너뛰면 세션 레벨 메트릭이 그 턴을 조용히 잃습니다.

카디널리티에 대한 경고 하나: 사용자 ID와 세션 ID는 고카디널리티 값입니다. 이것은 백엔드의 인덱싱 비용에 영향을 미치며, 다음 섹션의 문제입니다.

스팬은 얼마나 세분화해야 하는가?

두 가지 실패 모드, 둘 다 흔합니다:

과도한 스팬. 함수 호출당 스팬을 만들면 아무도 읽을 수 없는 400스팬 트레이스와 아무도 승인하지 않은 스팬당 청구서가 생깁니다. 호스팅 백엔드(Datadog, Langfuse Cloud)는 스팬 양으로 과금합니다. 모든 문자열 연결을 계측하는 수다스러운 에이전트 루프는 오후 안에 무료 티어를 소진합니다.

부족한 스팬. "전체 체인"에 스팬 하나를 만들면 느렸다는 것은 알지만 어디인지는 모릅니다. 결국 print 문을 다시 넣게 되는데, 이것이 트레이싱이 대체하려고 했던 것입니다.

경험칙(측정값이 아닌 경험칙입니다): 결정이나 외부 호출이 일어나는 경계에 스팬을 만드세요.

• 검색 단계: 스팬 생성.
• Rerank 호출: 스팬 생성.
• 각 모델 호출: 스팬 생성.
• 각 도구 호출: 스팬 생성.
• 각 가드레일 체크: 스팬 생성.
• 순수 프로세스 내 변환(문자열 포매팅, JSON 파싱, 프롬프트 조립): 부모 스팬의 속성으로 처리, 자체 스팬 없음.

카디널리티, 샘플링, 보존에 대해:

• 고카디널리티 속성(사용자 ID, 전체 프롬프트)은 저장 비용을 부풀립니다. 샘플링하거나 잘라내세요.
• 대부분의 백엔드는 트레이스 레벨에서 샘플링을 허용합니다. 에러 트레이스는 100% 유지하고, 정상 경로를 샘플링하세요.
• 보존 기간은 다양합니다: 무료 티어 7일, 유료 30~90일. 데이터가 필요하기 전에 결정하세요.

스팬 양과 스팬당 가격 뒤에 있는 실제 비용 모델은 LLM 비용 모니터링 가이드를 참조하세요. 여기서 재구축하지 않습니다.

Techsy의 접근 방식

클라이언트 에이전트 작업에서 세 가지 규칙을 표준화합니다:

1. 턴당 하나의 트레이스. 에이전트가 내부적으로 루프하더라도, 두 사용자 턴을 하나의 트레이스로 합치지 않습니다.
2. 모든 루트 스팬에 세션 ID를 찍고, 애플리케이션 코드에서 설정하며, 절대 전파를 가정하지 않습니다.
3. 스팬 종류를 작은 고정 세트(검색, 추론, 도구, 가드레일)로 유지하여 대시보드가 벤더 변경에서 살아남게 합니다.

세 번째 규칙이 팀이 건너뛰는 것이고, 마이그레이션을 살리는 것입니다. 스팬 어휘가 하나의 벤더 열거형에 묶여 있으면, 전환하는 날 모든 알림과 저장된 뷰가 깨집니다.

에이전트 시스템을 구축 중이고 트레이싱 아키텍처에 대한 세컨드 오피니언을 원한다면, 무료 상담을 받으세요.

저자 소개

Mert Batur는 Techsy.io의 공동 창업자로, 팀은 B2B 클라이언트를 위한 AI 에이전트, 자동화 시스템, 음성/SDR 파이프라인을 구축합니다. Techsy 팀이 실제로 프로덕션에서 사용하는 LLM 도구 스택에 대해 씁니다. LinkedIn에서 연결하세요.

자주 묻는 질문

분산 트레이싱에서 스팬이란 무엇인가?

스팬은 하나의 시간 측정 작업 단위입니다: 이름, 시작 시간, 종료 시간, 상태, 속성 세트를 가집니다. 스팬은 부모 스팬 ID 참조로 서로 연결되어 트리를 형성합니다. LLM 애플리케이션에서 스팬은 일반적으로 하나의 모델 호출, 하나의 검색, 또는 하나의 도구 호출을 감쌉니다.

Datadog에서 스팬이란 무엇인가?

Datadog의 LLM Observability에서 스팬은 같은 시간 측정 연산이지만, Datadog은 스팬 종류 분류 체계를 추가합니다: LLM, Workflow, Agent, Tool, Task, Embedding, Retrieval. LLM, Workflow, Agent 종류만 루트 스팬이 될 수 있습니다. 이 분류 체계는 Datadog 고유이며, OpenTelemetry 표준의 일부가 아닙니다.

관측 가능성의 네 가지 기둥은 무엇인가?

네 가지 기둥은 로그, 메트릭, 트레이스, 그리고(누구의 프레임이냐에 따라) 프로파일 또는 이벤트입니다. 트레이스는 이 글이 속한 기둥입니다. LLM 경우는 주름을 추가합니다: 토큰 사용량과 모델 정체성은 트레이스 스팬의 속성이지 별도 메트릭 스트림이 아니므로, 두 기둥이 될 것이 하나의 쿼리로 수렴됩니다.

관측 가능성의 네 가지 골든 시그널은 무엇인가?

지연 시간, 트래픽, 에러, 포화도입니다. LLM 시스템에서 지연 시간은 첫 번째 토큰까지의 시간과 총 생성 시간을 의미하고, 트래픽은 모델당 초당 요청 수를 의미하며, 에러는 실패한 스팬(상태 코드 ERROR)을 의미하고, 포화도는 토큰 예산 소진 또는 큐 깊이를 의미합니다. 시그널은 같고, 단위가 다릅니다.

세션은 OpenTelemetry 명세의 일부인가?

구조적 레벨로는 아닙니다. OTel GenAI 스팬 규칙은 gen_ai.conversation.id를 대화 또는 스레드의 메시지를 상관시키기 위한 조건부 필수 속성("사용 가능할 때")으로 정의합니다. 이것은 스팬에 위치합니다. Langfuse와 LangSmith 같은 벤더가 그 위에 자체 세션 또는 스레드 객체를 구축합니다.

트레이스 ID, 스팬 ID, 상관 ID의 차이는 무엇인가?

트레이스 ID는 하나의 요청을 식별하며 모든 다운스트림 서비스를 통해 자동으로 전파됩니다. 스팬 ID는 그 트레이스 내 하나의 연산을 식별합니다. 상관 ID(또는 요청 ID)는 트레이싱이 시작되기 전에 웹 티어에서 생성되며, 사람들이 트레이스 ID와 가장 많이 착각하는 값입니다. 범위가 겹치지만, 생성 방식이 다릅니다.

하나의 트레이스에 스팬이 몇 개 있어야 하는가?

고정된 답은 없지만, 일반적 범위는 RAG 요청의 경우 330개, 여러 도구 호출이 있는 에이전트 루프의 경우 1050개 이상입니다. 경험칙: 외부 호출과 결정 지점에 스팬을 만들고, 프로세스 내 변환에는 만들지 마세요. 트레이스가 100스팬을 초과하면, 과도한 계측일 가능성이 높습니다.

Langfuse "observation"은 스팬과 같은 것인가?

네. Langfuse observation은 OTel 스팬과 같은 객체입니다: 속성을 가진 하나의 시간 측정 연산. Langfuse는 observation을 세 가지 유형(generation, span, event)으로 나누고, OTel은 gen_ai.operation.name을 사용합니다. 트레이스를 읽는 도구를 평가 중이라면, LLM 평가 도구 라운드업에서 두 어휘를 모두 받아들이는 도구를 다룹니다.

다중 턴 챗봇 대화를 하나의 세션으로 어떻게 그룹화하는가?

모든 턴의 루트 스팬에 같은 대화 식별자를 설정하세요. OTel 용어로는 gen_ai.conversation.id입니다. Langfuse에서는 트레이스 생성 시 session_id를 전달합니다. LangSmith에서는 session_id 또는 thread_id 메타데이터를 설정합니다. 한 턴을 빠뜨리면 그 턴은 그룹핑에서 벗어납니다.

단일 턴 요청만 처리한다면 세션이 필요한가?

아마 필요 없습니다. 세션은 여러 트레이스를 하나의 대화로 상관시키기 위해 존재합니다. 모든 요청이 독립적이라면(분류 API, 원샷 요약기), 트레이스 레벨 메트릭으로 충분합니다. 교차 턴 메트릭이 필요할 때 세션을 추가하세요: 해결률, 응답까지의 턴 수, 또는 대화 레벨 비용. LLM 평가 가이드에서 세션 레벨 평가가 가치를 발휘하는 시점을 다룹니다.

짧은 버전

스팬은 트레이스 안에 중첩되고, 트레이스는 세션으로 그룹화됩니다. 중첩은 실재하지만, 명세는 세 레벨 중 두 가지만 구조화합니다. gen_ai.conversation.id는 직접 설정하는 속성이지, 전파되는 부모 스팬이 아닙니다. 그리고 오늘 선택하는 벤더는 18개월 후 전환할 벤더와 이 객체들의 이름이 다르므로, 스팬 어휘를 작고 이식 가능하게 유지하세요.

플랫폼을 선택 중이라면, 관측 가능성 플랫폼 비교부터 시작하세요. 트레이스 위에 평가를 구축 중이라면, LLM 평가 가이드가 여기서 이어갑니다.