OpenTelemetry의 소급 샘플링(Retroactive Sampling) — 버릴 수 없는 트레이스를 붙잡는 법

관측성 엔지니어들의 오래된 고민

마이크로서비스를 운영하다 보면 트레이스(trace) 데이터가 폭발적으로 늘어나요. 트레이스가 뭐냐면, 하나의 사용자 요청이 프론트엔드에서 시작해서 API 게이트웨이, 주문 서비스, 결제 서비스, 데이터베이스를 거쳐 응답으로 돌아오는 전체 경로를 기록한 데이터예요. 한 번의 클릭에 수십 개의 스팬(span, 각 서비스 구간 기록)이 쌓이죠.

문제는 이걸 다 저장하면 비용이 천문학적이에요. 그래서 대부분의 팀이 샘플링을 해요. 100개 요청 중 1개만 저장하는 식으로요. 근데 여기서 고전적인 딜레마가 생겨요. 에러가 난 요청은 반드시 저장하고 싶은데, 에러가 났는지는 요청이 끝나봐야 알잖아요. 무작위 샘플링을 하면 정작 중요한 에러 트레이스를 99% 확률로 버려버리게 되는 거죠.

이 문제에 대해 VictoriaMetrics가 KubeCon EU 2026에서 발표한 접근이 "소급 샘플링(retroactive sampling)" 이에요. 기존의 헤드 샘플링과 테일 샘플링의 한계를 넘는 새로운 방식이라서 꽤 흥미롭거든요.

기존 방식 — 헤드 샘플링과 테일 샘플링

먼저 배경부터 정리할게요. 헤드 샘플링(head sampling) 은 요청이 들어오자마자 "이건 저장할지 말지" 결정하는 방식이에요. 빠르고 단순하지만, 아직 에러가 날지 모르니까 중요한 트레이스를 놓칠 수 있어요. 반면 테일 샘플링(tail sampling) 은 요청이 끝난 뒤에 "에러 있었네, 저장하자" 또는 "느렸네, 저장하자" 같은 판단을 해요. 더 똑똑하지만 모든 스팬을 일단 메모리에 버퍼링해야 하니까 콜렉터(collector)가 무거워져요.

게다가 분산 시스템에서는 스팬들이 여러 콜렉터로 흩어져서 들어와요. 같은 트레이스의 조각들이 서로 다른 장비에 있으면 테일 샘플링 판단을 하려고 해도 "어디서 모을까" 가 문제가 돼요. 그래서 로드밸런서 앞에서 trace_id로 해시해서 같은 트레이스는 같은 콜렉터로 보내는 식의 구성이 필요한데, 이게 실제로 해보면 복잡하고 장애 지점도 많아요.

소급 샘플링이 다른 점

소급 샘플링의 아이디어는 "일단 모든 스팬을 저장 계층에 스트리밍으로 쏟아붓되, 저장은 짧게 하고, 의미 있는 트레이스만 장기 보관소로 승격시키자" 예요. 정확히는 이런 흐름이에요.

먼저 모든 스팬은 고속 단기 저장소(예: 인메모리 버퍼나 고성능 TSDB)로 일단 들어가요. 보관 기간은 짧아요 — 몇 분에서 길어야 몇 시간 수준. 그다음 별도의 평가 엔진이 트레이스가 완성되는 시점을 감지해요. 루트 스팬이 끝났거나, 일정 시간 동안 새 스팬이 안 들어오면 "이 트레이스는 완성됐다" 하고 판정하죠.

완성된 트레이스에 대해 규칙을 적용해서 보존 여부를 결정해요. "HTTP 500이 하나라도 있으면 보존", "전체 레이턴시가 2초 초과면 보존", "특정 고객 ID면 100% 보존" 같은 정책을 만들 수 있어요. 보존 결정이 나면 단기 저장소에서 장기 저장소로 트레이스 전체를 복사하고, 나머지는 TTL에 맞춰 자연 삭제되게 둬요.

이 방식의 장점은 콜렉터 메모리 버퍼링이 필요 없다는 거예요. 스팬은 그냥 스트리밍으로 저장소로 흘러가고, 판단은 저장소 쪽에서 일괄로 하니까요. 또 여러 콜렉터가 각자 받은 스팬을 같은 저장소로 쏘기만 하면 되니까 trace_id 기반 라우팅이 필요 없어요. 운영이 훨씬 단순해지죠.

성능과 규모

VictoriaMetrics 블로그에 따르면 이 방식으로 수백 배 수준의 트레이스 유실률 감소와 함께 장기 저장 비용을 90% 이상 절감한 사례가 나와요. 핵심은 "단기 저장은 저렴하고, 장기 저장은 선별된 것만"이라는 경제학이에요. 단기 저장소는 압축률 높은 컬럼형 포맷을 쓰고, 장기 저장소는 S3 같은 오브젝트 스토리지로 밀어넣는 식이죠.

구현 상으로는 ClickHouse나 VictoriaLogs 같은 엔진과 궁합이 좋아요. 둘 다 append-only 쓰기에 강하고 TTL 관리가 간단하거든요. OpenTelemetry Collector의 exporter 쪽에서 이런 저장소로 바로 쏘고, 별도 작업자가 위의 승격 로직을 돌리는 구성이 자연스러워요.

업계 흐름 속에서

Datadog, Honeycomb, Grafana Tempo 같은 상용 관측성 도구들도 비슷한 고민을 해왔어요. Honeycomb은 "BubbleUp" 이라는 사후 분석에 강점을 두고 사실상 모든 이벤트를 저장하는 전략이고, Tempo는 "모든 트레이스를 저장하되 오브젝트 스토리지에 싸게" 를 택했어요. 소급 샘플링은 이 두 흐름의 중간 지점에 있다고 볼 수 있어요. 모든 걸 저장하진 않지만 "저장할지 말지"를 끝까지 미뤄서 가장 정확한 판단을 내리는 거죠.

또 하나 맥락을 짚자면, OpenTelemetry가 점점 성숙하면서 이제 관심사가 "어떻게 수집할까"에서 "어떻게 효율적으로 보관/질의할까"로 옮겨가고 있다는 거예요. 수집 SDK는 거의 표준화됐고, 이제 전선은 저장소 사이드로 이동했어요.

한국 개발자에게 주는 시사점

국내에서도 쿠버네티스와 마이크로서비스를 쓰는 팀이 늘면서 관측성 비용이 실제 이슈로 떠오르고 있어요. 네이버, 카카오, 쿠팡 같은 큰 회사는 자체 솔루션을 만들어서 해결하지만, 중견/스타트업 입장에서는 Datadog 청구서 보고 놀라는 일이 흔하거든요.

실무적으로 당장 해볼 수 있는 건 이래요. 첫째, 지금 팀이 헤드 샘플링(고정 비율)만 쓰고 있다면 tail_sampling_processor를 한 번 검토해보세요. 둘째, 규모가 일정 수준을 넘어서 테일 샘플링 콜렉터가 부담스러워진 팀이라면 소급 샘플링 아키텍처를 파일럿으로 돌려볼 만해요. ClickHouse + OTel Collector 조합이 국내에서도 레퍼런스가 늘고 있어요. 셋째, "어떤 트레이스를 꼭 보존해야 하는가" 하는 비즈니스 규칙을 먼저 정의해두세요. 기술보다 이 정책 합의가 더 어려운 일이거든요.