분산 추적에서 Baggage는 요청에 연결해 서비스 사이로 전달할 수 있는 애플리케이션 정의 키·값 문맥입니다. trace ID나 span ID처럼 추적 위치를 식별하는 값과는 역할이 다릅니다. 예를 들어 실험 그룹이나 내부 작업 분류를 담을 수 있지만, 값의 의미와 안전성은 이를 넣는 애플리케이션이 결정합니다. 따라서 “추적 메타데이터”라는 이유만으로 민감정보가 아니라고 간주해서는 안 됩니다.

서비스 요청과 함께 이동하는 키·값 Baggage를 신뢰 경계에서 점검하는 개념도

Baggage는 trace 식별자가 아니라 요청 문맥

분산 추적은 여러 서비스의 작업을 trace와 span으로 연결해 흐름과 지연을 살핍니다. Baggage는 그 흐름에 실어 보낼 수 있는 별도 키·값 묶음입니다. OpenTelemetry 문서는 애플리케이션이 정의한 속성이 요청이나 작업 흐름에 붙는다고 설명하며, W3C 문서의 HTTP 헤더 형식은 이를 baggage 헤더의 멤버로 표현합니다. 키와 값 자체가 trace를 식별하거나 표준 의미를 갖는 것은 아닙니다.

예컨대 experiment=blue 같은 값은 서비스가 내부 분기나 관측 맥락에 활용할 수 있습니다. 그러나 소비 서비스가 그 키를 이해한다는 보장은 없고, 이름만 보고 개인정보가 아님을 보장할 수도 없습니다. trace context와 baggage를 별도 데이터로 취급하면 추적 연결 정보와 애플리케이션 문맥의 수명·접근 범위를 따로 설계할 수 있습니다.

HTTP 헤더 형식과 전달 한계

W3C 형식 초안은 헤더를 쉼표로 나열되는 멤버로 설명하고, 키는 토큰 문법을 따르며 허용 범위 밖의 값은 퍼센트 인코딩하도록 합니다. 중복 키가 나타날 수 있고, 선택적 속성은 애플리케이션별 의미를 가질 수 있습니다. 이는 모든 수신자가 임의의 값을 동일하게 해석한다는 뜻이 아닙니다. 직렬화·파싱 과정에서 문자 인코딩과 중복 처리 동작도 구현 간 확인 대상입니다.

같은 초안은 총 64개 멤버와 8192바이트 이내의 baggage에 대해 모두 전달되도록 보장합니다. 이 한도를 넘는 경우 구현은 일부 멤버를 버릴 수 있으며, 잘린 멤버를 부분적으로 전달해서는 안 됩니다. 이를 안전한 저장 공간이나 무제한 전달 약속으로 읽으면 안 됩니다. 운영자는 실제 프록시와 라이브러리의 헤더 제한도 함께 확인해야 합니다.

신뢰 경계에서 제거·허용 규칙을 정하기

Baggage는 사용자 입력이나 상위 서비스에서 온 데이터일 수 있으므로 신뢰할 수 없는 입력으로 다루세요. W3C의 보안 문서는 값 검증·정화와 경계 간 전파에 주의를 요구합니다. 개인정보 문서는 값에 식별 정보가 들어갈 수 있고, 키·값에 정해진 의미가 없다고 경고합니다. 외부 파트너, 브라우저, 로그 수집기처럼 신뢰 수준이 달라지는 지점에서는 허용 키 목록, 길이 제한, 값 형식, 제거 규칙을 정하고 기본값은 최소 전달로 두는 편이 안전합니다.

먼저 어느 구성 요소가 키를 설정하는지 추적하고, 각 홉에서 값이 덮어써지거나 추가될 수 있는지 확인하세요. 외부 경계에서는 필요한 키만 명시적으로 복사하고 나머지는 삭제하는 정책을 검토합니다. 토큰, 이메일, 계정 식별자, 원시 검색어처럼 노출 시 피해가 큰 값을 넣지 말고, 로그와 오류 보고에서 헤더 전체가 기록되는지도 살펴보세요. OpenTelemetry API는 신뢰할 수 없는 프로세스로 보내기 전에 baggage를 비우는 선택지도 제시합니다.

배포 전 점검 순서

  • 키별 소유자와 목적을 문서화하고, 개인정보·인증정보가 들어갈 수 있는지 검토합니다.
  • 서비스 경계마다 전파 허용 목록과 제거 규칙을 정하고, 임의 키가 다음 홉에 남는지 테스트합니다.
  • 최대 멤버 수·바이트 길이, 퍼센트 인코딩, 중복 키, 부분 헤더 입력을 파서와 프록시에서 시험합니다.
  • 로그·메트릭·오류 추적에 값이 복제되는 경로와 보존 기간을 확인합니다.

전문가 관점: 편의 메타데이터도 데이터 흐름으로 관리

관측성 설계에서 중요한 판단은 baggage를 추적 ID의 일부처럼 무조건 전달할지, 애플리케이션 데이터로 분류해 경계마다 심사할지입니다. 키 이름에 tenant, user, region이 포함되어도 조직마다 의미가 다르고, 같은 값이 내부 서비스에서는 무해해 보여도 외부 분석업체로 나가면 식별 단서가 될 수 있습니다. 따라서 스키마 소유자, 목적, 허용 대상, 보존·삭제 정책을 기록하고 변경 시 개인정보 검토를 다시 수행해야 합니다.

W3C에서 제공되는 형식·보안·개인정보 문서는 에디터 초안 소스이며, 여기서 인용한 문장을 확정된 W3C Recommendation 요건으로 표시하지 않습니다. 구현 기준은 실제 채택 문서의 상태와 사용하는 OpenTelemetry SDK·프록시 버전을 확인해 정하세요.

출처 및 참고 문서