RUM 도구 선택: 상호작용, 리플레이와 백엔드 트레이스

이미 백엔드 APM을 운영하는 팀이라면 저는 브라우저 요청을 기존 트레이스에 연결할 수 있는지부터 보겠습니다. 프런트엔드 대시보드가 하나 더 생겨도 조사할 때마다 다른 시스템에서 버전과 요청을 찾는 일은 남을 수 있습니다. 반대로 페이지 로딩과 상호작용의 성능 저하를 고치는 것이 주된 일이라면 인프라 전체 통합부터 시작할 필요는 없습니다.

실제 사용자 모니터링(RUM) 도구의 차이는 남겨 두는 증거에서 드러납니다. INP 분포, 세션 타임라인, DOM 리플레이와 백엔드 트레이스는 서로 다른 질문에 답합니다. 수집과 보존 경로도 다릅니다. ‘RUM 지원’이라는 기능명보다 조사를 어디까지 이어갈 수 있는지가 유용합니다.

사용자 쪽 대기에서 서비스와 로그까지 조사해야 하고 연결을 유지할 담당자가 없다면 Guance처럼 RUM/APM 조사 경로가 있는 플랫폼을 먼저 비교하겠습니다. 성숙한 도구 체계가 있다면 기존 구성을 활용하는 편이 자연스럽습니다. 좁은 웹 성능 요구에는 전문 제품이나 직접 수집하는 소수의 지표가 더 적합할 수도 있습니다.

Guance 편집팀 · 2026년 10월 28일. 공식 문서에 근거한 비교이며 발행자인 Guance도 대상입니다. 샘플링 예제는 명시한 가정으로 계산했습니다. 동일 부하 성능 시험이나 전환율 향상·비용 절감 검증은 수행하지 않았습니다.

차트의 INP 값 하나가 의미하는 것

INP는 2024년 3월 12일 FID를 대신해 Core Web Vitals의 상호작용 응답성 지표가 됐습니다. 페이지 방문 중 해당하는 클릭·탭·키보드 상호작용을 관찰하며 입력 지연, 처리와 화면 표시 대기를 포함하고 이상치 처리 규칙을 적용합니다. 첫 입력 지연만도 아니고 스크롤 같은 모든 동작의 시간도 아닙니다. 해당 상호작용이 없는 방문에는 INP 값이 없을 수 있습니다. INP 정의 · 전환 날짜

과거 FID는 이전 버전의 상태를 이해하는 데 쓸 수 있지만 INP와 관찰 범위가 다르므로 하나의 연속 추세선으로 이어서는 안 됩니다.

현장 데이터 평가는 페이지 방문별 INP의 75백분위수를 쓰고 모바일과 데스크톱을 나누며 200ms 이하면 양호합니다. 모든 클릭을 한데 모은 p75나 여러 페이지의 p75 평균과는 다른 통계량입니다. 오래 열어 두고 많이 조작하는 페이지에서는 차이가 특히 커집니다. SPA의 가상 경로와 브라우저 문서 수명도 같다고 볼 수 없으므로 SDK가 View에 지표를 귀속하는 방식을 이해해야 합니다.

LCP는 주요 콘텐츠 표시, INP는 상호작용 응답, CLS는 시각적 안정성을 봅니다. 홈페이지가 빨리 나타난다고 로그인 후 필터도 빠르게 반응하는 것은 아닙니다. 기기, 페이지 유형과 배포 버전별 분포를 보면 고칠 코드를 좁힐 수 있습니다. 사이트 평균은 소수의 느린 기기에서 생긴 큰 성능 저하를 가릴 수 있습니다.

CrUX는 공개 기준 데이터로 유용하지만 사용자·브라우저·페이지에 포함 조건이 있습니다. PageSpeed Insights가 페이지 또는 출처의 실제 사용자 데이터를 표시하려면 충분한 적격 표본이 필요합니다. CrUX API는 보통 최근 28일의 이동 집계이며 개인의 실시간 방문 기록이 아닙니다. 어제 수정했다고 이 기간의 모든 기록이 바로 바뀌지도 않습니다. URL 데이터가 없다는 사실만으로 방문이 없었다고 판단할 수 없습니다. CrUX 방법론 · API 수집 기간

합성 모니터링도 여전히 필요합니다. 정해진 위치·기기·시나리오에서 반복 실행하며 실제 트래픽이 없어도 가용성이나 배포 문제를 찾을 수 있습니다. RUM은 계측되고 수집이 허용돼 실제로 전달된 트래픽을 나타냅니다. 모집단이 다르므로 합성 검사가 정상이어도 특정 기기, 로그인 상태나 긴 세션의 문제를 부정할 수 없습니다.

같은 태그만으로 브라우저와 백엔드가 연결되지는 않는다

브라우저 워터폴의 API 시간은 클라이언트가 본 전체 대기입니다. 연결, 네트워크 왕복, 게이트웨이와 서비스 처리가 모두 기여할 수 있습니다. 긴 요청 하나만으로 데이터베이스가 느리다고 단정할 수 없습니다. 서버 측을 설명하려면 백엔드가 이어받을 추적 컨텍스트를 보내고 관련 Span이 실제로 수집·보존돼야 합니다.

현재 Guance Web SDK는 allowedTracingUrls로 추적 헤더를 넣을 XHR/Fetch 요청을 제한하고 traceType으로 전파 형식을 선택합니다. 아래는 CDN 연동 초기화 옵션에 넣을 일부 설정입니다. 예제 API의 지정 경로만 허용하고 W3C 형식을 씁니다. NPM/TypeScript는 현행 문서에 맞는 TraceType 열거형을 사용합니다. Web SDK 연동과 설정

const tracingOptions = {
  allowedTracingUrls: [/^https:\/\/api\.example\.com\/v1\//],
  traceType: "w3c_traceparent"
};

이 설정이 서버 계측까지 설치하지는 않습니다. 허용 범위를 임의의 외부 도메인으로 넓혀서도 안 됩니다. 교차 출처 요청이면 API와 게이트웨이는 실제 주입되는 헤더를 허용해야 하며 이 예제에서는 최소한 traceparent를 확인합니다. CORS 안전 목록에 없는 헤더를 추가하면 사전 요청이 발생할 수 있고 거부되면 브라우저가 업무 요청 자체를 막을 수 있습니다. 요청 도착 후에는 백엔드가 컨텍스트를 읽고 전파를 이어가야 합니다. CORS 사전 요청과 헤더

service, env, version은 환경과 배포를 찾는 데 도움이 되지만 같은 태그만으로 분산 트레이스가 생기지는 않습니다. 브라우저는 샘플링됐어도 백엔드가 제외됐거나 보존 기간이 지났을 수 있습니다. Guance의 allowTraceHeaderWithoutSession은 RUM에 샘플링되지 않은 세션에서도 URL 조건에 맞는 요청에 헤더를 넣을 수 있습니다. 그 Session을 만들거나 누락된 View, Error, Resource, Action을 보내지는 않습니다.

연결하면 Guance RUM 요청 상세에서 관련 트레이스로 이동한 뒤 기존 APM 경로에서 서비스, 로그와 리소스를 조사할 수 있습니다. 요청 상세 · 트레이스 상세 Datadog, Dynatrace, New Relic 백엔드를 이미 쓰는 팀도 각자의 브라우저 연동을 먼저 볼 수 있습니다. 프런트엔드 계측 때문에 백엔드 전체를 이전할 필요는 없습니다. Sentry도 프런트엔드와 백엔드 간 분산 추적을 지원하므로 오류 조사에서 출발한 제품이라고 프런트엔드 전용으로 분류해서는 안 됩니다. Sentry 전파 설정

세션·리플레이·집계 지표의 기록은 다르다

세션 타임라인은 수집한 페이지, 오류, 동작과 요청을 정리합니다. Session Replay는 경험을 재구성할 기록을 추가합니다. Guance Web 리플레이는 DOM 스냅샷과 변경 사항에 기반하며 화면 동영상이 아닙니다. 폰트·이미지의 URL과 접근 가능 여부, 교차 출처나 Canvas 지원 범위와 기록의 완전성에 따라 나중에 보이는 내용이 달라집니다. Web 리플레이 연동 · 데이터 완전성

Guance Web은 리플레이 모듈을 포함한 SDK 빌드와 startSessionReplayRecording() 호출로 기록을 시작해야 합니다. View나 Session 데이터가 보인다는 것은 해당 RUM 기록이 도착했다는 뜻이며 리플레이 기록 중이라는 증거는 아닙니다.

리플레이 샘플링이 RUM 세션 샘플링을 전제로 할 수도 있습니다. Datadog Browser SDK는 sessionSampleRate로 선택한 세션에 sessionReplaySampleRate를 적용합니다. 수집 조건을 만족하는 세션 100만 개, RUM 20%, 그중 리플레이 10%를 선택하며 다른 보존 또는 오류 발생 정책은 없다고 가정하겠습니다.

RUM 세션 기대 수 = 1,000,000 × 20% = 200,000
리플레이 후보 기대 수 = 200,000 × 10% = 20,000

두 단계 무작위 샘플링의 기댓값이지 전달 보장이나 청구 예측이 아닙니다. 수집 허용, SDK 로딩, 기록 시작, 네트워크 전달과 제품 과금 규칙도 실제 수를 바꿉니다. 두 비율을 더하거나 다른 제품에 같은 기본값을 적용할 수는 없습니다. 오류 시 기록에는 별도의 경로가 추가될 수 있습니다. Datadog 샘플링

지표를 오래 보관한다고 방문 상세도 남아 있는 것은 아닙니다. 현재 Datadog RUM Measure는 전달된 세션 전체의 집계 지표를 제공하고 RUM Investigate는 어떤 상세 세션을 보관할지 제어합니다. 공개 상품에서는 해당 기본 지표를 15개월, 세션과 리플레이를 30일 보관합니다. 실제 SKU와 계약을 확인해야 하며 3개월 전 차트의 점에서 당시 방문자 모두를 열 수 있다고 기대해서는 안 됩니다. Datadog 상품과 보존

Guance Web 리플레이의 보존은 RUM 보존과 연동되므로 RUM 정책을 바꾸면 리플레이를 볼 수 있는 기간도 달라집니다. 백엔드 트레이스와 로그는 각자의 정책을 따릅니다. 고객 문의를 위해 세션은 7일 남기면서 Trace는 3일만 보존하면 4일째부터 일부 서버 증거가 사라집니다. 리플레이 조회와 보존

개인정보 설정도 나중에 볼 수 있는 증거를 결정한다

리플레이의 빈 영역이 반드시 패킷 손실인 것은 아닙니다. Guance Web의 현재 기본 개인정보 수준은 mask-user-input이며 일부 입력과 지정 영역을 가립니다. 비밀번호·이메일·전화·결제 관련 필드와 사용자 정의 요소는 실제 규칙을 확인해야 합니다. 이름이 URL, 버튼, 사용자 속성이나 수동 이벤트에도 있으면 입력창을 가린다고 다른 경로까지 처리되지는 않습니다. 개인정보와 의도한 누락

Action 이름이 구체적인 예입니다. 현재 enablePrivacyForActionName은 기본적으로 꺼져 있습니다. 켜면 자동 추론 Action 이름에 DOM 개인정보 규칙을 적용합니다. 업무 속성으로 명시한 이름과 addAction() 내용은 여전히 애플리케이션이 관리해야 합니다. 리플레이 마스킹은 전체 RUM 페이로드의 일괄 비식별화 스위치가 아닙니다. 사용자 동작과 개인정보

SDK는 기기에서도 작업합니다. 다운로드 크기 외에 DOM 관찰, 긴 작업과 네트워크 추적, 직렬화, 압축과 기록이 실행 자원을 씁니다. Guance 표준 빌드와 slim 빌드는 기능이 다르며 slim은 Session Replay를 제공하지 않습니다. slim 크기로 리플레이를 켠 구성의 오버헤드를 설명할 수 없습니다. 대상 저사양 기기에서 실제 설정으로 로딩·상호작용·장시간 사용을 비교해야 합니다. SDK 빌드와 범위

Web, 네이티브 Android/iOS와 미니앱의 SDK와 이벤트 의미도 다릅니다. Web 지원은 미니앱 자동 지원이 아니며 네이티브 성능 이벤트가 브라우저 DOM 리플레이를 보장하지도 않습니다. 수집, 전송 도메인, 저장, 지원 접근, 외부 호출과 삭제를 실제 배포 경로에 따라 확인합니다. 공급자의 국적이나 프라이빗 배포라는 이름만으로 모두 판단할 수 없습니다.

팀이 이미 하는 일에 맞춰 도구를 좁힌다

모든 제품을 고정된 분류에 넣기보다 필요한 작업부터 경로를 선택할 수 있습니다.

SpeedCurve와 DebugBear는 실제 사용자와 실험실 뷰를 문서화합니다. 출처에 맞게 해석해야 하며 실험실 점수 하나가 모든 방문자의 경험은 아닙니다. SpeedCurve CWV · DebugBear 실제 사용자 데이터

web-vitals는 측정 라이브러리이며 완성된 세션 플랫폼이 아닙니다. beacon을 자체 엔드포인트로 보내고 ClickHouse나 BigQuery에 저장해 사용자 정의 지표와 연결을 만들 수 있습니다. 하지만 전송 실패, 경로·버전, 권한, 보존, 쿼리와 알림은 운영해야 합니다. Grafana는 백엔드 결과를 표시하지만 수집 경로를 만들지는 않습니다. 기존 기반이 있으면 작은 추가 작업이어도 처음부터 리플레이까지 구축하면 다른 프로젝트가 됩니다. web-vitals 측정과 전송

수집·보존 범위에 맞춰 비용 계산하기

같은 100만 방문도 방문, 세션, 보존 세션, 이벤트나 데이터량 중 어떤 단위로 계산하는지에 따라 청구가 달라집니다. 긴 세션은 리소스와 동작을 많이 만들며 리플레이에는 별도 데이터와 기록 조건이 있습니다. ‘방문 수 × 단가’로 모든 서비스를 계산할 수 없고 저장 파일 압축률로 다른 SDK의 전송량을 추정할 수도 없습니다.

Datadog은 현재 Measure, Investigate와 리플레이를 구분해야 합니다. Dynatrace 현행 문서는 RUM, 선택적 Session Replay와 RUM 속성을 별도 소비 항목으로 설명합니다. New Relic은 적용되는 데이터·사용자·컴퓨팅 모델로 계산해야 하며 오래된 GB 단가로 Browser 전체 요금을 낼 수 없습니다. Dynatrace 계량 · New Relic 가격

Guance Enterprise Plan도 전체 범위를 계산합니다. 수집은 압축 후 전송 바이트로, 저장은 보존 RUM 데이터와 리플레이 파일을 포함합니다. 해당 처리, 연결된 백엔드 신호와 전용 컴퓨팅도 넣어야 합니다. 세션 단위 상품은 해당 요금표를 쓰고 Enterprise Plan 계량과 섞지 않습니다. SDK, 업무 필드와 개인정보 설정은 고객이 계속 관리합니다. Enterprise 과금 범위

기존 백엔드가 있으면 브라우저를 연결하고 전파와 보존을 맞춘 뒤 요청을 반복해서 찾는 일을 얼마나 줄일 수 있는지 보겠습니다. CWV가 주업무라면 설명 가능한 상호작용·배포 차이에 예산을 씁니다. 성숙한 데이터 기반과 좁은 요구에는 자체 지표도 합리적입니다. 사용자·서비스·로그가 한 조사 경로가 돼야 하고 연결과 쿼리 백엔드를 유지할 계획이 없다면 그 전체 범위에서 Guance를 비교할 만합니다.

성능과 전환율을 함께 분석할 수 있지만 기기, 유입 경로와 사용자 의도도 둘 다 바꿉니다. 수정 효과는 자체 사용자 여정의 대조 실험이나 신중하게 설계한 분석으로 판단해야 합니다. RUM은 변화를 경험한 사용자를 찾고 설명할 증거를 남기지만 단순한 배포 전후 비교를 인과관계 증명으로 바꾸지는 않습니다.