[Spring Boot] Micrometer Tracing 분산 트레이싱 TraceID, SpanID

 

🎯 오늘 학습 목표

분산 트레이싱의 기본 구조 (TraceID, SpanID) 를 이해하고 실제 Spring Boot 로그에서 TraceID 어떻게 활용되는지 확인해보기 !

 

 

1️⃣ TraceID / SpanID 개념

🧩 기본 용어 정리

용어 의미 비유

Trace	하나의 요청 전체 흐름	사용자가 “앱에서 버튼을 눌러 요청을 보낸 전체 여정”
Span	Trace 안의 한 단계 (작업 단위)	Controller → Service → DB 각각 한 “스텝”
TraceID	Trace 전체를 식별하는 고유 ID	“택배 송장번호”처럼 전체 여정을 추적하는 번호
SpanID	각각의 작업(Span)을 구분하는 고유 ID	송장 안의 “세부 구간 번호” (예: 허브 이동 단계)

TraceID 는 보통 ‘택배 송장번호’로 비유가 많이 되는 것 같다. 송장번호로 배송 과정을 추적하는 것처럼 TraceID로 하나의 요청 흐름을 추적할 수 있다. 택배의 송장번호 = TraceID 라고 생각하면 된다.

SpanID는 Trace 안의 각각의 작업을 의미하는 것으로 택배 송장 안의 세부 구간 번호 ? 라고 생각하면 된다.

 

• TraceID 와 SpanID 의 차이

  사용자 로그인 요청 (TraceID: abc123)
  │
  ├─ [span-001] API Gateway 통과
  │  │
  │  └─ [span-002] 인증 서비스
  │     │
  │     └─ [span-003] DB 조회
  │        │
  │        └─ [span-004] Redis 캐시 확인
  │
  └─ 응답 완료
  

• TraceID 는 전체 요청을 추적하기 때문에 시작부터 끝까지 동일하지만, SpanID는 각 단계를 구분하는 ID로 서비스마다 다르다. Trace는 여러 Span으로 이루어진 것 !

 

😱 TraceID가 없으면 무슨 문제가 발생할까 ?

서비스에는 한 고객만 요청하는게 아니라 여러 고객들이 동시에 요청을 보낸다. 따라서 TraceID 없이 로그를 찍게 되면 어떤 고객이 어떤 요청을 했는지 추적하기 어렵다. (실제로 현재 내가 운영하던 자녀폰지킴이 서비스는 TraceID 가 없어서 로그 추적이 너무 너무 어려움.. 민원 들어오면 가번으로 추적해야 해서 시간이 굉장히 오래걸리는 편)

 

로그가 이렇게 섞여있다면?

[15:30:01] UserService - 로그인 시작
[15:30:01] OrderService - 주문 생성 시작
[15:30:02] UserService - DB 조회 완료
[15:30:02] OrderService - 재고 확인
[15:30:03] UserService - 로그인 완료
[15:30:03] OrderService - 주문 완료

→ 동시에 100명이 요청하면 구분이 어려움,, 에러 발생 시 어떤 요청에서 발생한 문제인지도 찾기 어려움

 

TraceID, SpanID를 사용하면:

[15:30:01] [trace-001,span-A] UserService - 로그인 시작
[15:30:01] [trace-002,span-X] OrderService - 주문 생성 시작
[15:30:02] [trace-001,span-A] UserService - DB 조회 완료
[15:30:02] [trace-002,span-X] OrderService - 재고 확인
[15:30:03] [trace-001,span-A] UserService - 로그인 완료
[15:30:03] [trace-002,span-X] OrderService - 주문 완료

→ 이런식으로 TraceID와 SpanID를 사용하면 grep 으로 “trace-001” 만 검색하면 되니까 추적하기 훨씬 편하다.

 

 

🌐 마이크로서비스에서 TraceID

TraceID 는 MSA 구조에서 사용하면 그 진가를 발휘하는데 그 이유는 단일 서버에서는 비교적 로그 추적이 쉽지만 MSA 구조에서는 서비스마다 서버가 분리되어 있기 때문에 로그가 분산돼서 로그 추적이 어려워진다.

 

이때, TraceID 를 사용하면

[서버1] [trace-001,span-A] Gateway - 요청 받음 (0ms)
[서버2] [trace-001,span-X] Auth - 인증 시작 (5ms)
[서버3] [trace-001,span-B] User - 사용자 조회 (15ms) ⚠️ 느림!
[서버4] [trace-001,span-Y] Notify - 알림 발송 (2ms)

이런식으로 trace-001 로 검색하면 4개 서버에서 모두 로그를 확인할 수 있고, 서버 3에서 문제가 있다는 걸 확인할 수 있다.

 

⚙️ Trace Context 전파 (Propagation)

분산 시스템에서는 서비스가 여러 개로 나뉘어 있기 때문에 (MSA) TraceID와 SpanID가 다음 서버로 전달되어야 한다. 전파 방식은 주로 HTTP Header 를 사용한다.

 

traceparent 구조

00-{traceId}-{parentSpanId}-{flags}

 

예시

GET /api/users HTTP/1.1
Host: service-b.com
traceparent: 00-1234abcd5678ef90-7890abcd1234ef56-01
             ││  │                   │       └─ flags (01=sampled)
             ││  │                   └─────────── parent spanId
             ││  └─────────────────────── traceId (128bit)
             │└────────────────────────── version (00)
             
tracestate: vendor1=value1,vendor2=value2

• 00 : Version
• 1234abcd5678ef90: TraceID
• 7890abcd1234ef56 : SpanID
• 01 : Trace flags

서비스 A → 서비스 B로 요청을 보낼 때, HTTP 헤더에 Trace 정보를 실어 보내면 서비스 B에서도 같은 TraceID 로 로그를 남길 수 있는 구조다.

 

 

2️⃣ 예제 프로젝트 만들어보며 TraceID, SpanID 실습해보기

설정 (build.gradle, application.yml)

build.gradle

plugins {
	id 'java'
	id 'org.springframework.boot' version '3.5.7'
	id 'io.spring.dependency-management' version '1.1.7'
}

group = 'com.example'
version = '0.0.1-SNAPSHOT'
description = 'Demo project for Spring Boot'

java {
	toolchain {
		languageVersion = JavaLanguageVersion.of(17)
	}
}

repositories {
	mavenCentral()
}

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-web'
	implementation 'org.springframework.boot:spring-boot-starter-actuator'

    // Micrometer Tracing (OpenTelemetry bridge)
    implementation 'io.micrometer:micrometer-tracing-bridge-otel'
    implementation 'io.opentelemetry:opentelemetry-exporter-zipkin'

    // For @Observed (AOP-based observations around methods)
    implementation 'org.springframework.boot:spring-boot-starter-aop'

	testImplementation 'org.springframework.boot:spring-boot-starter-test'
	testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
}

tasks.named('test') {
	useJUnitPlatform()
}

 

 

application.yml

spring:
  application:
    name: spring-tracing-quickstart

server:
  port: 8085

management:
  tracing:
    enabled: true
    sampling:
      probability: 1.0 # sample 100% for practice
  zipkin:
    tracing:
      endpoint: <http://localhost:9411/api/v2/spans>
  endpoints:
    web:
      exposure:
        include: health,info

logging:
  pattern:
    console: '[%d{yyyy-MM-dd HH:mm:ss}] [%X{traceId},%X{spanId}] [%thread] %highlight(%-5level) %logger %msg%n'
  file:
    path: /var/www/log/tracing-study
    name: console.log
  level:
    root: info

 

Tracing 기본 설정 (Micrometer Tracing)

management:
  tracing:
    enabled: true
    sampling:
      probability: 1.0 # sample 100% for practice

• managment.tracing.enabled : Micrometer Tracing 기능을 키는 것
  • Micrometer Tracing 이 TraceID를 생성하고 관리해주는 것이기 때문에 이걸 안키면 TraceID가 생성되지도, 전파되지도 않음 !
• sampling.probability : 1.0 : 트레이스를 몇 % 수집할지 결정하는 샘플링 비율
  • 1.0 이면 100% 수집하겠다는 것으로 학습, 개발에 유용함
  • 운영에선 보통 0.01 ~ 0.2 정도로 낮춘다고 함. 트래픽이 많을수록 낮춰야 함

 

✏️ Micrometer Tracing 이란?

애플리케이션의 요청 흐름(Trace/Span) 을 추적하는 관측성 프레임워크

 

 

서비스 안에서 “이 요청이 어디서 시작되어, 어떤 컴포넌트를 거쳐, 어디서 지연이 발생했는가”를 추적하는 시스템 → 이 데이터를 기반으로 Zipkin, Jaeger, Tempo, Grafana 등에서 시각적으로 트레이스를 볼 수 있음

 

동작 방식

Client → Controller → Service → DB

1️⃣ Controller 진입 시 traceId, spanId 생성

2️⃣ 각 단계별로 child span 생성

3️⃣ MDC(Context)에 trace 정보 삽입 → 로그에 [traceId][spanId] 출력

4️⃣ Exporter가 Zipkin/Tempo/Jaeger 등으로 데이터 전송

 

 

✏️ 운영에선 샘플링 비율을 0.01 ~ 0.2 정도로 낮추는 이유 ?

TraceID, SpanID 를 100% 수집하면 부하가 커지기 때문

 

 

분산 트레이싱은 모든 요청의 실행 경로를 Span 단위로 기록하고 전송하고, 이 데이터는 Zipkin, Tempo, Jaeger 같은 저장소에 쌓임. 트래픽이 많으면 모든 Span이 Zipkin 서버로 전송되고 디스크/네트워크/CPU가 급격히 사용량이 올라감 !

따라서 Trace 데이터를 전부 수집하지 않고 일부 요청만 추적하도록 확률적으로 제한하는 것이 샘플링으로 모든 요청을 기록할 필요는 없고, 일정 비율만으로도 충분히 패턴과 병목을 파악할 수 있음.

 

➡️ 한마디로 샘플링 비율을 낮추는 이유는 트레이스 데이터가 방대하게 쌓여 시스템과 저장소에 부담을 주기 때문이며, 운영 환경에서는 일부 요청만 추적해도 충분히 성능 병목을 진단할 수 있기 때문이다.

 

 

Zipkin Exporter 설정

management:
  zipkin:
    tracing:
      endpoint: <http://localhost:9411/api/v2/spans>

• Micrometer Tracing이 수집한 Span 을 Zipkin 서버로 전송할 주소
• Zipkin의 기본 포트는 9411

 

Actuator 노출 (선택)

management: 
  endpoints:
    web:
      exposure:
        include: health,info

• Actuator에서 웹으로 노출할 엔드포인트를 지정함
• 최소한 health, info 정도만 열어두면 기본 상태 점검에 충분함
• 운영에선 노출 범위를 좁히고 보안 설정을 함께 고려해야 함

 

logging 설정

logging:
  pattern:
    console: '[%d{yyyy-MM-dd HH:mm:ss}] [%X{traceId},%X{spanId}] [%thread] %highlight(%-5level) %logger %msg%n'
    file:    '[%d{yyyy-MM-dd HH:mm:ss}] [%X{traceId},%X{spanId}] [%thread] %-5level %logger %msg%n'
  file:
    path: /var/www/log/tracing-study
  level:
    root: info

 

docker-compose.yml

services:
  zipkin:
    image: openzipkin/zipkin
    container_name: zipkin
    ports:
      - "9411:9411"

 

ObservationConfig

@Configuration
public class ObservationConfig {

    @Bean
    public ObservedAspect observedAspect(ObservationRegistry registry) {
        return new ObservedAspect(registry);
    }
}

• Micrometer Tracing 이 @Observed 어노테이션 인식하고 동작하게 만드는 설정
• ObservationRegistry: Micrometer 의 Observation 을 등록, 관리하는 중앙 허브 객체
  • @Observed가 달린 메서드를 실행할 때, Micrometer가 내부적으로 ObservationRegistry를 사용해 새 Observation(Span) 을 생성하고 실행 시간, 예외, 태그, 상태 등을 기록합니다.
• ObservedAspect : Spring AOP 기반으로 작동하는 Aspect

🧩 실행 흐름 예시

1️⃣ Controller → DemoService.work() 호출

2️⃣ AOP가 @Observed 감지

3️⃣ ObservedAspect가 ObservationRegistry에 새 Observation 등록

4️⃣ 실행 전후로 로그 + 트레이스 수집

5️⃣ Exporter(Zipkin 등)에 Span 전송

 

 

실습 코드 (Ctl, Service…)

TracingController

package com.example.spring_tracing_quickstart.ctl;

import com.example.spring_tracing_quickstart.service.DemoService;
import io.micrometer.tracing.Span;
import io.micrometer.tracing.Tracer;
import lombok.extern.slf4j.Slf4j;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

import java.util.Map;

@Slf4j
@RestController
public class TracingController {

    private final Tracer tracer;
    private final DemoService demoService;

    public TracingController(Tracer tracer, DemoService demoService) {
        this.tracer = tracer;
        this.demoService = demoService;
    }

    @GetMapping("/trace-test")
    public Map<String, String> test() {
        Span span = tracer.currentSpan();

        return Map.of(
                "traceId", span.context().traceId(),
                "spanId", span.context().spanId()
        );
    }

    @GetMapping("/trace")
    public Map<String, String> trace() throws InterruptedException {
        Span span = tracer.currentSpan();
        log.info("Controller - handling /trace");
        demoService.work();
        demoService.callDownstreamSimulation();

        return Map.of("Ok", span.context().traceId());
    }

}

 

 

DemoService

package com.example.spring_tracing_quickstart.service;

import io.micrometer.observation.annotation.Observed;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Service;

import java.util.concurrent.ThreadLocalRandom;

@Slf4j
@Service
public class DemoService {

    @Observed(name = "service.work", contextualName = "service#work")
    public void work() throws InterruptedException {
        log.info("Service - work()");
        Thread.sleep(50 + ThreadLocalRandom.current().nextInt(50));
        log.info("Service - work() done");
    }

    @Observed(name = "service.downstream", contextualName = "service#downstream")
    public void callDownstreamSimulation() throws InterruptedException {
        log.info("Service - callDownstreamSimulation() start");
        // Imagine an external API / DB call here
        Thread.sleep(100 + ThreadLocalRandom.current().nextInt(150));
        log.info("Service - callDownstreamSimulation() end");
    }
}

 

 

@Observed

메서드 실행을 자동으로 트레이스(Span) + 메트릭(Observation) 으로 기록하는 어노테이션

• name : 메트릭 이름으로 사용됨
• contextualName : 트레이스에 표시될 이름

 

실행

/trace 호출

• http://localhost:8080/trace

 

실행 로그

[2025-10-28 13:51:01] [749f01246a3dc717d386e80b295c4464,91313b104f8e24da] [http-nio-8085-exec-1] INFO  com.example.spring_tracing_quickstart.ctl.TracingController Controller - handling /trace
[2025-10-28 13:51:01] [749f01246a3dc717d386e80b295c4464,4df6a2ffd774bc93] [http-nio-8085-exec-1] INFO  com.example.spring_tracing_quickstart.service.DemoService Service - work()
[2025-10-28 13:51:01] [749f01246a3dc717d386e80b295c4464,4df6a2ffd774bc93] [http-nio-8085-exec-1] INFO  com.example.spring_tracing_quickstart.service.DemoService Service - work() done
[2025-10-28 13:51:01] [749f01246a3dc717d386e80b295c4464,af04e80269c1aea9] [http-nio-8085-exec-1] INFO  com.example.spring_tracing_quickstart.service.DemoService Service - callDownstreamSimulation() start
[2025-10-28 13:51:01] [749f01246a3dc717d386e80b295c4464,af04e80269c1aea9] [http-nio-8085-exec-1] INFO  com.example.spring_tracing_quickstart.service.DemoService Service - callDownstreamSimulation() end

Trace (하나의 HTTP 요청)
 ├─ [Span 1] Controller (/trace)
 │   ├─ [Span 2] Service.work()
 │   └─ [Span 3] Service.callDownstreamSimulation()

• TraceID : 요청 전체의 식별자
• SpanID : 작업 단위별 식별자
• ParentID : 어떤 Span 아래에 속하는지 나타냄

 

Zipkin UI

• http://localhost:9411/zipkin/

 

 

 

Zipkin UI에서 분석하는 방법

(1) Duration (소요 시간) 비교

• /trace : 전체 314ms
• service#work : 73ms
• service#downstream : 192ms

→ 서비스 내부의 어떤 로직이 상대적으로 오래 걸리는지 파악 가능함 (성능 병목 구간 분석용으로 자주 사용함)

 

(2) Time Overlap (겹침 여부)

• 두 Span 이 겹쳐 있으면 비동기 호출, 떨어져 있으면 동기 호출

(3) 서비스 간 호출 트레이스

• spring-tracing-quickstart 외에 다른 서비스명이 보이면 HTTP 요청 시 traceparent 헤더가 잘 전파된 것

→ 분산 트레이싱 확인용

 

등.. 실무에서 하는 Trace 분석 루틴

분석 목표 보는 위치 해석 포인트

느린 요청 찾기	Trace 리스트 Duration 정렬	상위 10개 Trace 열어서 병목 Span 확인
외부 API 느림 분석	각 Span의 Duration 비교	특정 외부 호출 (ex. payment API)이 대부분 지연인지 확인
내부 호출 병목 확인	Controller → Service → Repository 순	Service, Repository 중 어디서 시간이 많은지
장애 시 TraceID 기반 역추적	로그 traceId로 Zipkin 검색	요청 흐름 전체 재현 가능

 

 

⚠️ Zipkin 운영 환경 주의사항

1️⃣ 샘플링 비율 조정 (Sampling Rate)

• 개발 환경은 1.0 (100%) 로 두고, 운영 환경은 0.01 ~ 0.2 정도로 줄여야 함
• 트래픽이 많으면 Span 데이터폭증해서 Zipkin 서버가 버티지 못하기 때문에 대표 샘플만 수집해서 경향성 확인 필요

2️⃣ Zipkin 서버 저장소(Storage) 부하 관리

• 기본 Zipkin 서버는 in-memory storage 로 뜨기 때문에 재시작 시 데이터 사라짐
• 따라서 운영에서는 Elasticsearch, MySQL, Cassandra 중 하나로 교체한다고 함..!

→ 오래된 Trace 는 로그 분석이나 APM 으로 넘기고, Zipkin 은 단기 트러블슈팅용으로 사용하는게 일반적임

3️⃣ 보안 및 개인정보 노출 주의

• Trace/Span 데이터 안에는 URI, 요청 파라미터, 헤더 값이 그대로 들어갈 수 있기 때문에 민감한 데이터는 로그 전송 전 마스킹 or 제외 필터 적용 해야 함

4️⃣ TraceID 연동 로깅 일관성 유지

• Zipkin은 Tracer → MDC(TraceId/ SpanID) → Logback → 로그 수집기 (ELK) 로 이어지므로 로그 포맷이 일정하지 않으면 TraceID로 검색이 불가능함 !
• 실무에서는 Zipkin 보다 ELK 에서 traceID로 로그 필터링을 더 자주 함.

 

(추가) 비동기 처리에서의 전파

ClonedTaskDecorator

새 스레드에서도 traceId가 동일하게 유지되게 하는 래퍼

public class ClonedTaskDecorator implements TaskDecorator {
    @Override
    public Runnable decorate(Runnable runnable) {
        ContextSnapshot snapshot = ContextSnapshot.captureAll();
        return () -> snapshot.wrap(runnable).run();
    }
}

• Spring 의 @Async 는 새 스레드에서 메서드를 실행하는데 traceID, SpanID, MDC 같은 정보는 ThreadLocal 에 저장되기 때문에 새 스레드로 넘어가면 자동으로 사라진다.
• 따라서 현제 스레드(Controller) 에서 가지고 있던 관측 컨텍스트(Trace + MDC) 를 비동기 스레드(Service) 로 복제해주는 역할이 필요함
• ContextSnapshot.captureAll(); : Micrometer에서 제공하는 API로 현재 스레드의 ThreadLocal 기반 컨텍스트(MDC, Trace, Observation) 를 한 번에 사진 찍듯 복사함 → snapshot 은 그 시점에 traceId, spanId를 모두 담고 있음
• snapshot.wrap(runnable) : Mircometer 가 제공하는 래핑 함수로 원래 실행할 Runnable 를 감싸서 새 스레드에서 실행될 때 스냅샷으로 찍어둔 컨텍스트를 복원해줌
• 복원된 상태에서 runnable.run()이 실행되기 때문에 로그와 트레이스가 모두 부모 TraceID로 연결됨

 

AsyncConfig 설정

@Aysnc가 사용하는 비동기 스레드 풀을 직접 구성하면서 TaskDecorator 로 Trace, MDC 등 ThreadLocal 컨텍스트를 자동 복제해주는 설정

@Configuration
@EnableAsync
public class AsyncConfig implements AsyncConfigurer {

    @Override
    public Executor getAsyncExecutor() {
        ThreadPoolTaskExecutor taskExecutor = new ThreadPoolTaskExecutor();
        taskExecutor.setCorePoolSize(4);
        taskExecutor.setMaxPoolSize(40);
        taskExecutor.setQueueCapacity(160);
        taskExecutor.setThreadNamePrefix("springTask-");

        taskExecutor.setTaskDecorator(taskDecorator());

        taskExecutor.initialize();
        return taskExecutor;
    }

    @Bean
    public TaskDecorator taskDecorator() {
        return new ClonedTaskDecorator();
    }
}

• 스레드 풀 세부 설정설정 의미 설명

  corePoolSize	최소 스레드 개수	기본으로 항상 유지되는 작업 스레드 수
  maxPoolSize	최대 스레드 개수	요청이 몰릴 때 늘어날 수 있는 최대 스레드 수
  queueCapacity	작업 대기 큐 크기	실행 중인 스레드가 꽉 찼을 때 대기할 작업 수
  threadNamePrefix	스레드 이름 접두어	디버깅 시 로그에 [springTask-1] 이런 식으로 표시됨

  → 동시에 4개의 @Async 작업이 돌고, 필요하면 최대 40개까지 확장되며 그 이상은 160개까지만 큐에 대기
• taskExecutor.setTaskDecorator(taskDecorator()); : TaskDecorator는 각 Runnable 실행 전에 특정 로직을 감싸주는 훅(Hook)
• taskExecutor.initialize(); : 스레드 풀 초기화하고 Spring Bean으로 등록, 이후 @Async 메서드들은 이 Executor를 통해 실행됨

 

DemoService

    @Async
    @Observed(name = "service.async", contextualName = "service#async")
    public void workAsync() throws InterruptedException {
        Thread.sleep(100 + ThreadLocalRandom.current().nextInt(5000));
        log.info("Service - workAsync() start");
        Thread.sleep(100 + ThreadLocalRandom.current().nextInt(100));
        log.info("Service - workAsync() end");
    }

 

TracingController

    @GetMapping("/trace/async")
    public Map<String, String> async() throws InterruptedException {
        log.info("Controller - handling /trace/async");
        demoService.work();
        demoService.workAsync();

        return Map.of("Ok", tracer.currentSpan().context().traceId());
    }

 

실행 로그

[2025-10-28 15:20:45] [c1ac96986375abf055733ffde0f927dd,33e39c74ab39a193] [http-nio-8085-exec-1] INFO  com.example.spring_tracing_quickstart.ctl.TracingController Controller - handling /trace/async
[2025-10-28 15:20:45] [c1ac96986375abf055733ffde0f927dd,5c6a1a727850edf8] [http-nio-8085-exec-1] INFO  com.example.spring_tracing_quickstart.service.DemoService Service - work()
[2025-10-28 15:20:45] [c1ac96986375abf055733ffde0f927dd,5c6a1a727850edf8] [http-nio-8085-exec-1] INFO  com.example.spring_tracing_quickstart.service.DemoService Service - work() done
[2025-10-28 15:20:49] [c1ac96986375abf055733ffde0f927dd,e8d9e126ad2339a2] [springTask-1] INFO  com.example.spring_tracing_quickstart.service.DemoService Service - workAsync() start
[2025-10-28 15:20:49] [c1ac96986375abf055733ffde0f927dd,e8d9e126ad2339a2] [springTask-1] INFO  com.example.spring_tracing_quickstart.service.DemoService Service - workAsync() end

 

 

🔍 전체 실행 흐름 정리

1. Controller Thread
   ↓
   Micrometer Tracing이 TraceID, SpanID를 MDC/ThreadLocal에 저장
   ↓
2. @Async 메서드 호출
   ↓
   ThreadPoolTaskExecutor가 새로운 Worker Thread를 꺼냄
   ↓
   TaskDecorator (ClonedTaskDecorator)가 실행됨
      - ContextSnapshot.captureAll() → 현재 ThreadLocal 복사
      - snapshot.wrap(runnable).run() → 새 스레드에서 복원
   ↓
3. Service Thread
   ↓
   traceId, spanId가 복원된 상태로 실행
   ↓
   Zipkin / 로그 모두 동일 traceId로 연결

 

 

3️⃣요약

Trace vs Span

단위	전체 요청	세부 작업
식별자	TraceID	SpanID
관계	Span들의 상위 컨테이너	Trace 내의 개별 단위
전파 방식	HTTP 헤더, Context	Parent-Child 구조
목적	요청 전체 추적	각 구간 성능 측정