Cloudflare Workers RPC 추적, 느린 고객 요청의 병목을 드러내다

2026년 9월 17일, Cloudflare는 느린 고객 요청의 병목을 더 쉽게 특정할 수 있도록 기능을 개선했습니다. 이제 Cloudflare Workers 트레이싱은 호출자에서 멈추지 않고 JavaScript RPC 호출을 따라 다른 Worker나 Durable Object까지 이어집니다. 수동 스팬을 추가하거나 전체 스택을 의심하기 전에 어느 서비스와 메서드가 요청을 지연시켰는지 확인할 수 있습니다.

Cloudflare Workers 트레이싱은 RPC 공백을 어떻게 메웠나

RPC는 이름만큼 복잡하지 않습니다. Cloudflare Workers에서 원격 프로시저 호출은 한 Worker가 바인딩을 통해 다른 Worker나 Durable Object에 공개된 JavaScript 메서드를 부르는 방식입니다. 코드는 로컬 메서드를 호출하는 것처럼 보이지만 실제 작업은 다른 곳에서 실행됩니다.

트레이스는 요청 하나가 처리되는 과정을 시간순으로 보여줍니다. 그 안에서 시간이 측정되는 각 구간이 스팬입니다. 이번 릴리스 전에는 호출자가 JavaScript RPC 경계를 넘는 순간 이 타임라인이 끊겼습니다. Worker A가 호출을 보냈다는 사실은 보여도, 그 호출과 Worker B 또는 Durable Object에서 실행되는 작업을 명확히 연결할 수 없었습니다.

Cloudflare의 9월 17일 릴리스는 이 공백을 메웁니다. 이제 하나의 트레이스에서 호출자 측 세션, 각 메서드 호출, 호출받는 쪽의 실행, 중첩 호출, 다른 Worker로 되돌아가는 콜백까지 확인할 수 있습니다. 트레이싱을 활성화하면 Cloudflare가 이 스팬들을 자동으로 기록합니다. 이 플랫폼 계측을 위해 옵저버빌리티 SDK를 추가하거나 애플리케이션 코드를 바꿀 필요는 없습니다.

세션 스팬은 호출자 측 RPC 세션을 담는 컨테이너입니다. 같은 세션을 재사용하는 호출은 그 안에 배치됩니다. 개별 호출 스팬에는 메서드 또는 속성 경로가 담기고, 호출받는 쪽에는 별도의 실행 스팬이 생깁니다. 실행 위치가 Worker 사이에서 이동하거나 Durable Object로 넘어가면 색상이 달라집니다.

비어 있던 경계가 이제 책임 소재를 보여주는 지도로 바뀝니다.

결제 요청 하나를 끝까지 따라가 보기

고객 요청 하나가 POST /checkout로 들어온다고 가정해 보겠습니다.

요청은 먼저 checkout Worker에 도착합니다. 이 Worker는 inventory Worker의 inventory.reserve()를 호출한 뒤 order Durable Object의 order.commit()을 호출합니다. 고객에게는 결제 한 번이 느려진 것으로 보이지만, 애플리케이션 안에는 대기가 발생할 수 있는 지점이 세 곳 있습니다.

이전에는 checkout 트레이스가 RPC 호출 지점에서 끝날 수 있었습니다. 나머지 경로를 재구성하려면 각 서비스의 로그와 서로 맞는 식별자를 모으거나 커스텀 스팬을 추가해야 했습니다.

이제는 요청 전체를 하나의 트레이스로 유지할 수 있습니다. RPC 세션을 펼쳐 reserve와 commit 메서드 스팬을 찾고, 하위 호출을 확인한 뒤, 실제 경과 시간이 어느 구간에 몰렸는지 비교할 수 있습니다. 루트 스팬에는 Cloudflare Ray ID, Worker 이름, 진입점, 결과, CPU 시간, 실제 경과 시간도 담길 수 있어 장애 대응 담당자가 정확한 요청을 찾는 데 필요한 단서를 얻습니다.

새 화면만으로 메서드가 느린 원인까지 입증되는 것은 아닙니다. 대신 다음으로 어디를 살펴봐야 하는지 알려줍니다. inventory 호출이 대기 시간의 대부분을 차지한다면 해당 스토리지나 업스트림 의존성을 확인해야 합니다. Durable Object 호출의 스팬이 가장 넓다면 그 객체의 핸들러와 스토리지 작업을 살펴봐야 합니다. 두 RPC가 시작되기 전부터 호출자가 느리다면 하위 서비스는 우선 의심할 대상이 아닙니다.

이 기능이 특히 유용한 팀

백엔드를 나눠 혼자 운영하는 창업자

checkout, inventory, order 상태를 각각 별도 Worker로 운영하는 창업자는 느린 구매 요청 하나를 재현해 Cloudflare 경로 전체를 따라갈 수 있습니다. 핵심 이점은 조사 범위가 좁아진다는 점입니다. 모든 서비스를 다시 열어보는 대신 지연이 발생한 Worker나 Durable Object를 조사하면 됩니다.

상태 기반 제품을 맡은 백엔드 리드

협업 앱은 room 작업을 에지 Worker에서 room Durable Object로 전달할 수 있습니다. 백엔드 리드는 호출자에서 쓴 시간과 상태 저장 객체 내부에서 쓴 시간을 분리한 뒤, 해당 경계를 담당하는 팀에 트레이스를 넘길 수 있습니다.

내부 Worker 서비스를 운영하는 플랫폼 엔지니어

플랫폼 팀은 서비스 바인딩으로 연결된 여러 Worker를 운영할 수 있으며, 반환된 스텁과 콜백 때문에 로그만으로는 경로를 재구성하기 어려울 수 있습니다. 세션 스팬과 메서드 스팬을 보면 어떤 호출이 세션을 재사용했는지, 각 구간을 어느 Worker가 실행했는지, 중첩 호출이 어디서 경로에 들어왔는지 알 수 있습니다.

고객 제보를 증거로 바꾸는 지원팀 리드

지원팀은 장애 상황의 세부 정보가 생생할 때 엔지니어링 팀에 같은 경로를 재현해 달라고 요청할 수 있습니다. 생성된 트레이스에는 “checkout이 느렸다”는 설명 대신 구체적인 서비스와 메서드 경계가 담깁니다. 최종 해결에 로그, 프로파일러 또는 데이터베이스 쿼리 플랜이 더 필요하더라도 이 정보는 유용합니다.

월요일에 바로 해볼 테스트

첫 적용은 모든 프로덕션 Worker가 아니라 요청 경로 하나에서 시작하는 편이 좋습니다.

1. 1

   고객에게 보이는 경로 선택

   이미 Worker 간 또는 Worker와 Durable Object 사이의 RPC 경계를 넘고, 느린 상황을 반복해서 재현할 수 있는 요청을 고릅니다. 경로, 예상되는 하위 메서드 호출, 재현할 시각을 적어 둡니다.

2. 2

   Wrangler에서 트레이스 활성화

   해당 경로를 처리하는 Worker의 Wrangler 설정에 Cloudflare가 안내한 다음 항목을 추가합니다.

   {
     "$schema": "./node_modules/wrangler/config-schema.json",
     "observability": {
       "traces": {
         "enabled": true
       }
     }
   }

   평소의 릴리스 절차를 통해 이 설정을 배포합니다. 이 스위치를 켜면 Cloudflare의 자동 스팬이 활성화됩니다. Worker 내부에 SDK를 넣을 필요는 없습니다.

3. 3

   느린 요청 하나 재현

   통제된 조건에서 같은 요청을 한 번 실행합니다. 지원 또는 로깅 흐름에서 이미 수집하고 있다면 경로, 타임스탬프, Cloudflare Ray ID를 보관합니다. 별도의 통제 환경이 더 깔끔합니다. 다른 비율을 설정하지 않으면 기본 트레이스 샘플링 비율이 1이어서 들어오는 요청의 100%가 추적되기 때문입니다.

4. 4

   트레이스를 바깥에서 안쪽으로 확인

   Cloudflare에서 Workers & Pages로 이동해 Worker를 선택한 다음 Observability를 엽니다. 재현한 요청을 찾아 트레이스를 펼칩니다. 루트 요청에서 시작해 RPC 세션, 호출자 측 메서드 스팬, 호출받는 쪽의 실행, 중첩된 Durable Object 호출 순으로 따라갑니다. 스팬 너비와 실제 경과 시간 필드를 보고 다음 조사가 필요한 경계를 찾습니다.

5. 5

   확대 적용 전에 비용 계산

   재현한 트레이스가 만든 스팬 수를 기록합니다. 그런 다음 월별 트레이스 이벤트를 sampled requests × average spans per sampled trace로 추정합니다. 같은 옵저버빌리티 할당량을 쓰는 기존 로그 이벤트도 더합니다. 이렇게 측정한 스팬 수가 프로덕션 샘플링을 결정할 때 사용할 입력값입니다.

비용은 요청이 아니라 스팬 단위입니다

Workers 트레이싱은 초기 베타 기간에 무료입니다. 2026년 10월 1일부터는 달라집니다. 그날부터 스팬 하나가 옵저버빌리티 이벤트 하나로 계산되며 Workers Logs와 같은 할당량과 요금 체계를 공유합니다.

Enterprise 팀은 계약을 확인해야 합니다. 그 외 사용자는 과금 단위를 주의해서 봐야 합니다. 고객 요청 하나에서도 루트 스팬, RPC 세션 스팬, 메서드 호출 스팬, 호출받는 쪽의 실행 스팬, 중첩 바인딩 스팬이 만들어질 수 있습니다. 요청 수만으로는 트레이스 비용을 알 수 없습니다.

Cloudflare의 트레이싱 문서에 따르면 기본 head_sampling_rate는 1, 즉 100%입니다. 트래픽이 많은 환경을 위한 예시에서는 0.05를 사용해 들어오는 요청 100건 가운데 다섯 건을 추적합니다. 이 값은 제어 방법을 보여주는 예시일 뿐, 모든 환경에 맞는 정답은 아닙니다.

헤드 샘플링의 절충점은 명확합니다. 비율을 낮추면 이벤트 수가 줄지만 어떤 요청을 추적할지는 요청 시작 시점에 결정됩니다. 드물게 발생하는 느린 요청이 선택되지 않을 수 있습니다. 통제된 재현이나 충분히 격리된 환경에서는 전수 샘플링을 사용하고, 프로덕션 비율은 실제 트래픽과 트레이스당 측정 스팬 수를 바탕으로 정해야 합니다.

보존 기간은 장애 대응 방식에도 영향을 줍니다. Free 요금제의 트레이스는 3일, Paid 요금제의 트레이스는 7일간 유지됩니다. 고객 제보가 이 기간을 지나 접수되면 필요했던 트레이스가 이미 사라졌을 수 있습니다. 운영 원칙은 간단합니다. 증거가 남아 있을 때 재현하고 확인하거나, 현재 프로세스에 필요한 보존 기간을 제공하는 시스템으로 트레이스를 내보내야 합니다.

한계를 정확히 알아야 합니다

Workers 트레이싱은 아직 오픈 베타입니다. 스팬과 속성 이름은 바뀔 수 있으며, Cloudflare에 따르면 일부 속성은 아직 불완전합니다.

I/O가 아닌 일부 스팬에는 실제 작업 시간이 더 길었어도 0 ms로 표시될 수 있습니다. Workers Runtime은 I/O 이벤트가 발생하기 전까지 시간을 갱신하지 않으므로 영이라는 값만으로 JavaScript 작업에 시간이 전혀 들지 않았다고 단정할 수 없습니다.

Cloudflare 밖에서는 자동 트레이싱도 끊깁니다. Workers 트레이스를 내보낼 때 Cloudflare는 아직 트레이스 ID를 외부 서비스로 전파하지 않습니다. 결제 사업자나 외부에 호스팅된 데이터베이스를 호출해도 공급업체 측 트레이스가 Workers 타임라인에 자동으로 연결되지는 않습니다.

마지막으로 이번 릴리스의 범위는 좁습니다. JavaScript RPC 경계가 없는 단일 Worker에는 새로운 서비스 간 추적 화면이 생기지 않습니다. 일반적인 Workers 트레이싱은 fetch, 바인딩, 핸들러를 파악하는 데 여전히 도움이 될 수 있지만, 9월 17일 변경 사항은 이미 여러 Worker나 Durable Object로 분리된 애플리케이션에서 가장 큰 효과를 냅니다.

지금 무엇을 해야 할까

고객 요청이 서비스 바인딩이나 Durable Object를 지나고, 느린 구간을 찾기 위해 팀이 여러 로그를 이어 붙이고 있다면 이번 주에 시작할 가치가 있습니다. 지원 또는 장애 대응 비용을 가장 많이 만드는 경로부터 고릅니다.

애플리케이션이 아직 Worker 하나로 구성돼 있거나 의심되는 지연이 전적으로 외부 서비스에 있다면 기다리는 편이 낫습니다. 이번 릴리스는 Cloudflare 외부까지 이어지는 연동 트레이스를 만들지 않습니다.

이미 트레이싱을 활성화했다면 커스텀 계측을 추가하기 전에 새 RPC 스팬부터 확인합니다. 자동 트레이스가 직접 소유한 메서드 내부에서 의미 있는 공백을 보여줄 때만 커스텀 스팬을 더합니다.

월요일에 할 일은 작습니다. 실제 요청 경로 하나에서 observability.traces.enabled를 활성화하고, 느린 요청을 재현하고, RPC 세션과 메서드 스팬을 확인한 뒤 적용 범위를 넓히기 전에 샘플링 비율, 트레이스당 평균 스팬 수, 보존 기간, 예상 할당량 사용량을 적어 둡니다.

플랫폼 변경이 업무나 비용에 영향을 줄 때 핵심만 정리한 운영 메모를 받고 싶다면 뉴스레터를 구독하세요.