로그를 여러 군데 뒤지는 대신 요청 하나의 경로부터 본다
운영 중 특정 API가 느려졌다고 하자. 애플리케이션 로그만 보면 서버에서 처리한 시간은 확인할 수 있지만, 그 전에 Cloudflare에서 어떤 보안 규칙이 적용됐는지, URL이 변환됐는지, 캐시를 놓쳤는지, Worker가 끼어들었는지는 다른 화면과 설정을 따로 확인해야 했다. 같은 요청을 두고 WAF 로그, 캐시 상태, Worker 로그, 원본 서버 로그를 오가다 보면 원인이 어느 구간에 있는지 좁히는 데 시간이 많이 든다.
Cloudflare가 10월 2일 공개한 Cloudflare Traces는 실제 운영 요청을 요청 단위의 타임라인으로 묶는다. 공식 문서 기준으로 Rules, 요청 라우팅, Cache, Workers, 원본 연결처럼 지원되는 처리 단계를 span으로 기록하고 각 단계의 소요 시간, 결과, 관련 속성을 보여 준다. 여기서 span은 한 요청 안의 개별 작업 구간을 뜻한다.
이 기능은 기존 Cloudflare Trace와 이름이 비슷하지만 목적이 다르다. 기존 Cloudflare Trace는 특정 설정이 요청을 어떻게 처리할지 시뮬레이션하는 도구이고, Cloudflare Traces는 실제 운영 트래픽에서 발생한 요청을 기록한다. 설정 검증과 장애 분석을 같은 기능으로 생각하면 원문에서 말하는 차이를 놓치기 쉽다.
한 요청을 열면 보안 규칙과 캐시, Worker, 원본 시간이 같이 보인다
Traces 화면에서는 한 요청 아래에 처리 단계가 계층 형태로 펼쳐진다. 행 하나가 span이고, 막대의 위치와 길이로 언제 실행됐고 얼마나 걸렸는지 볼 수 있다. 특정 span을 선택하면 상태, 서비스, 트리거, trace ID와 span ID, 소요 시간, 기록된 속성까지 확인할 수 있다.
예를 들어 차단된 요청이라면 어떤 사용자 정의 규칙이나 관리형 보안 규칙이 실제로 동작했는지 확인할 수 있다. URL이 예상과 다르게 원본에 도착했다면 http_request_transform 구간에서 어떤 Transform Rule이 어떤 값을 바꿨는지 볼 수 있다. Worker 라우팅이 의심될 때는 workers_routing span에서 어떤 경로가 매칭됐는지 확인하는 식이다.
성능 문제에서도 같은 방식이 쓰인다. Cloudflare는 발표 글에서 총 539ms가 걸린 요청 중 cache miss 이후 원본 응답을 기다리는 데 527ms가 쓰인 예를 보여 줬다. 이 수치는 일반적인 성능을 뜻하는 벤치마크가 아니라 Cloudflare가 기능 설명을 위해 제시한 한 요청의 사례다. 중요한 점은 전체 지연을 한 숫자로 보는 대신 어느 구간에 시간이 몰렸는지 바로 분리할 수 있다는 것이다.
평소에는 적게 수집하고, 문제 요청만 Trace Rules로 올린다
모든 요청을 항상 100% 추적하면 조사할 정보는 많아지지만 데이터 양과 비용도 빠르게 늘어난다. 그래서 Cloudflare는 도메인마다 기본 샘플링 비율을 두고, 평소에는 일부 요청만 기록하도록 설계했다. 공식 문서의 예처럼 기본값을 1% 수준으로 두면 전체 흐름을 지속적으로 관찰하면서 수집량을 제한할 수 있다.
장애가 특정 고객이나 특정 API에서만 발생한다면 Trace Rules가 더 유용하다. 규칙은 기본 샘플링 비율을 덮어쓰며, 경로, HTTP 메서드, 헤더, IP 주소, 지역 등 Cloudflare Rules 언어로 표현할 수 있는 조건을 기준으로 다른 비율을 적용한다. 예를 들어 /api/v1 경로에만 100% 추적을 적용하고 나머지는 낮은 비율로 유지하는 식이다.
규칙 순서도 중요하다. 공식 설정 문서는 첫 번째로 일치한 Trace Rule을 사용한다고 설명한다. 여러 규칙을 만들 때는 더 구체적인 조사 조건을 위에 두지 않으면 넓은 규칙이 먼저 매칭돼 예상과 다른 샘플링 비율이 적용될 수 있다.
이 방식은 오류를 재현할 때 특히 편하다. 임시 디버그 헤더를 넣은 요청만 100% 추적하도록 만들면 전체 트래픽의 수집량을 크게 올리지 않고도 문제 요청의 경로를 자세히 확보할 수 있다. 조사가 끝난 뒤에는 해당 규칙을 끄거나 제거해 평소 수준으로 돌아가면 된다.
Cloudflare 밖의 서비스와 연결하려면 traceparent를 이어야 한다
Cloudflare 구간만 보려면 기능을 켜는 것만으로도 지원되는 span이 자동으로 만들어진다. 하지만 요청이 원본 서버를 지나 다른 API나 데이터베이스까지 이어지는 전체 분산 추적을 원한다면 애플리케이션 쪽 계측이 필요하다. Cloudflare Traces는 W3C Trace Context의 traceparent 헤더를 받아들이거나 원본으로 전달해 다른 OpenTelemetry 계측 서비스와 같은 trace로 연결할 수 있다.
여기서 중요한 제한이 하나 있다. 공식 설정 문서에 따르면 들어오는 trace context의 기본값은 Reject이며, Cloudflare는 외부에서 들어온 context가 신뢰할 수 있는 호출자에게서 왔는지 자체적으로 검증하지 않는다. 무조건 Accept로 바꾸면 외부 요청이 자신이 정한 trace 식별자를 들고 들어올 수 있으므로, 현재 오픈 베타에서는 신뢰 경계를 고려해 설정해야 한다.
원본으로 context를 전달한다고 해서 원본 서버의 span이 자동으로 생기는 것도 아니다. 원본 애플리케이션이 OpenTelemetry 같은 방식으로 직접 계측되어 있어야 하고, Cloudflare span과 애플리케이션 span을 하나의 화면에서 보려면 같은 OpenTelemetry 호환 백엔드로 보내야 한다. 기능을 켰다는 이유만으로 전체 스택의 분산 추적이 완성됐다고 보면 안 된다.
Cloudflare는 OTLP, 즉 OpenTelemetry Protocol로 trace를 외부 관측 플랫폼에 내보낼 수 있게 했다. 계정 수준의 목적지를 만든 뒤 도메인별로 어떤 trace를 보낼지 선택한다. 이미 Grafana, Honeycomb, Axiom 같은 도구를 중심으로 운영하고 있다면 Cloudflare 구간만 별도 화면에 가두기보다 기존 trace와 합치는 구성이 더 자연스럽다.
12월부터는 span 개수가 아니라 수집 데이터 양을 봐야 한다
Cloudflare Traces는 현재 오픈 베타지만 비용 기준은 이미 예고돼 있다. 2026년 12월 1일부터 Cloudflare Traces, Workers Logs, Workers Traces 등 여러 Observability 데이터가 같은 계정 수준의 수집·저장 한도를 공유한다. 현재 공식 가격 문서에서 Free는 하루 0.5GB 수집과 7일 보관이 포함되고, 한도를 넘으면 그날 추가 데이터 수집이 중단된다.
Paid는 청구 주기마다 50GB 수집과 12GB-month 저장이 포함된다. 초과분은 수집 1GB당 0.25달러, 저장 1GB-month당 0.10달러다. 쿼리, 대시보드, 알림, 분석 자체에는 추가 요금이 붙지 않는다고 문서가 설명한다. 수집량은 압축 전 데이터 기준이므로 속성 수가 많고 샘플링 비율이 높을수록 같은 요청 수에서도 사용량이 커질 수 있다.
공식 발표 글의 표에는 Paid 저장 포함량이 10GB-month로 적혀 있지만, 같은 날 갱신된 현재 가격 문서는 12GB-month를 명시한다. 발행 시점에는 별도 가격 문서가 더 구체적이고 최신 운영 기준을 담고 있으므로 12GB-month를 기준으로 보는 편이 맞다. Enterprise는 계약 갱신 시점에 새 가격 모델로 이동한다고 가격 문서가 따로 적고 있다.
따라서 도입할 때는 'trace 몇 개를 저장할까'보다 실제 수집 데이터 크기를 관찰하는 편이 낫다. 평소 낮은 샘플링, 문제 구간의 Trace Rule, 필요한 속성만 유지하는 방식이 비용과 조사 품질을 함께 조절하는 핵심이 된다.
| 구분 | 포함량 | 초과 요금 |
|---|---|---|
| Free | 0.5GB 수집/일, 7일 보관 | 추가 수집 불가 |
| Paid | 50GB 수집/청구 주기, 12GB-month 저장 | 수집 $0.25/GB, 저장 $0.10/GB-month |
2026-10-05 확인한 Cloudflare Observability 가격 문서 기준. 새 가격은 2026-12-01부터 적용 예정이며 Enterprise는 계약 갱신 시점이 다를 수 있다.
장애가 코드인지 Cloudflare 설정인지 먼저 나누는 도구다
Cloudflare 앞단을 많이 사용할수록 한 요청에 관여하는 설정도 늘어난다. WAF, Transform Rules, Cache Rules, Workers, 라우팅이 함께 있는 서비스에서 403이나 지연이 생기면 애플리케이션 로그만으로는 원인을 놓치기 쉽다. Cloudflare Traces의 가장 직접적인 용도는 이 구간을 한 요청의 실행 순서로 보여 줘 어디서 행동이 달라졌는지 확인하는 것이다.
처음 적용할 때는 모든 도메인과 모든 요청을 한꺼번에 켜기보다, 문제가 잦은 도메인 하나에서 낮은 기본 샘플링으로 시작하는 편이 안전하다. 실제 장애가 생기면 Ray ID나 경로, 헤더 같은 식별 조건으로 대상을 좁히고 Trace Rule의 비율을 올린다. 원본 서버까지 이어서 보고 싶다면 그다음에 traceparent 전달과 OpenTelemetry 계측을 추가하는 순서가 이해하기 쉽다.
에이전트 기반 디버깅도 같은 데이터에 접근할 수 있다. Cloudflare는 Observability MCP server와 SQL API를 통해 에이전트가 trace와 다른 관측 데이터를 조회하는 흐름을 발표 글에서 소개했다. 다만 운영 trace에는 요청 속성이나 인프라 정보가 포함될 수 있으므로, 자동화 도구에 접근 권한을 줄 때는 사람이 대시보드를 보는 것과 같은 권한 관리가 필요하다.
지금 바로 확인할 핵심은 세 가지다. 실제 운영 요청이 span으로 보이는지, 조사할 요청만 높은 비율로 잡을 수 있는지, 그리고 12월 가격 전환 뒤 예상 수집량이 어느 정도인지다. 이 세 가지가 맞으면 Cloudflare 설정과 애플리케이션 코드를 따로 추측하던 시간을 줄이는 데 실질적인 도움이 될 수 있다.