세션 리플레이로 프론트엔드 에러 추적하기: 장애 재현부터 원인 분석까지

"버튼을 눌렀는데 아무 반응이 없었어요."

프론트엔드 장애 제보를 받으면 어디서부터 시작해야 할지 막막합니다. 사용자는 분명히 문제를 겪었지만, 개발자가 같은 상황을 다시 만드는 일은 쉽지 않습니다. 콘솔에 에러가 남아 있으면 다행이지만, 프론트엔드 장애는 로그를 남기지 않고 조용히 로그 없이 지나가는 경우도 있습니다. 결국 개발자는 사용자에게 다시 묻게 됩니다. 어떤 브라우저를 썼는지, 어느 화면에서 버튼을 눌렀는지, 클릭하기 전에 어떤 값을 입력했는지, 뒤로 가기나 새로고침을 했는지까지 확인해야 합니다. 그래도 문제가 재현되지 않으면 원인 분석은 더 길어집니다.

세션 리플레이(Session Replay)는 이 과정을 다른 방식으로 바꿉니다. 사용자가 웹사이트에서 수행한 클릭, 스크롤, 입력, 페이지 전환을 시간 순서대로 기록해 두었다가 나중에 다시 확인할 수 있는 기능입니다. 쉽게 말하면 사용자 화면에 블랙박스를 달아 두는 것과 비슷합니다.

‍

세션 리플레이가 필요한 이유

프론트엔드 장애는 서버 로그만으로 원인을 찾기 어렵습니다. 서버는 요청과 응답은 기록할 수 있지만, 사용자가 어떤 화면에서 어떤 순서로 행동했는지는 알 수 없기 때문입니다. 특히 에러 로그가 남지 않는 UI 문제라면 원인 분석은 더 어려워집니다. 세션 리플레이는 이런 상황에서 사용자의 행동 맥락을 복원합니다. 클릭, 스크롤, 입력, 페이지 전환 같은 화면 위의 움직임을 시간 순서대로 확인할 수 있어, “어떤 요청이 실패했는가”뿐 아니라 “그 요청이 어떤 사용자 행동에서 시작됐는가”까지 함께 볼 수 있습니다.

특히 다음과 같은 상황에서 세션 리플레이의 가치가 두드러집니다.

• 버튼은 클릭됐지만 API 요청이 발생하지 않는 경우
• 특정 순서로 화면을 이동했을 때만 UI가 깨지는 경우
• 렌더링은 됐지만 사용자 화면에서 보이지 않는 레이아웃 문제가 발생한 경우

이제 세션 리플레이는 일부 UX 분석 도구에만 있는 기능이 아니라, 클라우드 관측 도구에서도 점점 표준 기능으로 자리 잡고 있습니다. AWS도 2026년 5월 Amazon CloudWatch RUM에 웹 애플리케이션용 세션 리플레이 기능을 추가했습니다. 와탭은 여기서 한 단계 더 나아가 브라우저 모니터링과 APM을 연결합니다. 사용자가 화면에서 겪은 문제를 리플레이로 확인하고, 같은 흐름에서 백엔드 트랜잭션까지 추적할 수 있어 프론트엔드와 백엔드 사이의 원인 분석 시간을 줄일 수 있습니다.

‍

와탭 세션 리플레이 시작하기

와탭 브라우저 모니터링(RUM, Real User Monitoring, 실제 사용자 모니터링)에서 세션 리플레이를 활성화하려면 에이전트 설정 한 줄이면 충분합니다. 브라우저 에이전트 초기화 옵션에 sessionReplaySampleRate 값을 추가하면 됩니다. 이 값은 세션 리플레이를 수집할 비율을 정하는 설정입니다.

WhatapBrowserAgent.init({
  projectAccessKey: 'YOUR_PROJECT_ACCESS_KEY',
  pcode: YOUR_PROJECT_CODE,
  sampleRate: 100,
  sessionReplaySampleRate: 50,  // 세션의 50%에서 리플레이 수집
  sessionReplayMaskAllTexts: true,
  sessionReplayMaskAllInputs: true,
});

‍여기서 헷갈릴 수 있는 부분은 sampleRate와 sessionReplaySampleRate의 관계입니다. sampleRate가 전체 세션 수집 비율이라면, sessionReplaySampleRate는 그 안에서 리플레이를 기록할 비율입니다. 예를 들어 두 값이 각각 100과 50이면, 모든 세션을 수집하되 그 중 절반에 대해서만 리플레이를 기록합니다.

민감 정보 보호는 기본값으로 처리됩니다. sessionReplayMaskAllTexts와 sessionReplayMaskAllInputs가 기본적으로 true로 설정돼 있어, 텍스트 입력 내용과 폼 데이터는 마스킹해 수집할 수 있습니다. 사용자 화면을 재현하더라도 개인정보나 입력 데이터가 그대로 노출되지 않도록, 리플레이 수집 전 마스킹 정책을 먼저 점검할 필요가 있습니다.

‍

세션 리플레이로 장애 세션 찾기

장애 제보를 받았을 때 가장 먼저 해야 할 일은 문제가 발생한 세션을 찾는 것입니다. 개발자는 성능 저하, API 실패, 특정 사용자 제보 등 문제의 출발점에 따라 와탭이 제공하는 세션 리플레이 접근 경로를 선택할 수 있습니다.

• 분석 > 페이지 로드 히트맵: 특정 페이지에서 로딩 지연이 발생한 구간을 찾고, 해당 세션의 리플레이를 재생합니다. 사용자가 어떤 순서로 페이지를 이동했을 때 로딩이 길어졌는지 확인할 수 있습니다.
• 분석 > AJAX 히트맵: API 요청 실패나 지연이 발생한 구간을 시간축으로 찾고, 같은 세션의 리플레이를 열어 봅니다. 어떤 클릭이나 화면 조작이 해당 요청으로 이어졌는지 확인할 수 있습니다.
• 분석 > 사용자 세션 로그 검색: 특정 사용자, 시간대, 조건을 기준으로 세션을 검색한 뒤 결과 목록에서 리플레이를 열 수 있습니다. 고객이 직접 불편을 제보한 경우에 유용합니다.

예를 들어 “저장 버튼을 눌렀는데 아무 반응이 없었다”는 제보를 받았다면, 사용자 세션 로그에서 해당 사용자의 세션을 먼저 찾습니다. 리플레이를 열어 저장 버튼을 클릭한 시점으로 이동한 뒤, AJAX 요청이 발생했는지 확인합니다. 요청이 발생하지 않았다면 프론트엔드 이벤트 처리나 화면 상태를 의심할 수 있고, 요청이 실패했다면 API 응답과 연결된 백엔드 흐름을 이어서 확인할 수 있습니다.

리플레이 플레이어에서 재생 속도를 1배에서 4배까지 조절하거나 타임라인을 드래그해 원하는 시점으로 바로 이동할 수 있습니다. 전체 세션을 처음부터 끝까지 볼 필요 없이, 에러 발생 시점만 골라 빠르게 확인하면 됩니다.

‍

프론트 에러를 백엔드까지 연결하기

세션 리플레이만으로도 프론트엔드 장애 재현이 훨씬 빠릅니다. 와탭이 한 단계 더 나아가는 지점은 APM(애플리케이션 성능 관리, Application Performance Monitoring)과의 연결입니다.

브라우저에서 에러가 발생하면, 와탭은 해당 시점의 백엔드 트랜잭션까지 추적 정보를 이어 붙입니다. 프론트엔드에서 버튼을 눌렀을 때 어떤 API가 호출됐고, 그 API가 서버에서 어느 코드 경로를 탔는지까지 한 화면에서 볼 수 있습니다. 원인이 프론트에 있는지, 백엔드에 있는지 판단하는 시간이 크게 줄어듭니다.

‍

마치며

세션 리플레이는 사용자가 본 화면을 개발자도 다시 확인할 수 있게 하는 기능입니다. 재현이 어려운 프론트엔드 장애, 로그에 남지 않는 UI 깨짐, 특정 순서에서만 발생하는 버그를 빠르게 좁히는 데 도움이 됩니다.

와탭 브라우저 모니터링은 세션 리플레이와 APM 연계를 통해 프론트엔드 장애를 실제 사용자 경험에서 추적할 수 있도록 지원합니다. 에이전트 설정에 옵션 한 줄을 추가하는 것만으로 세션 리플레이를 시작할 수 있습니다. 와탭 모니터링 무료 체험으로 문제가 발생한 순간의 흐름을 직접 확인해 보세요.

‍

더 읽을거리

• 와탭 브라우저 모니터링 세션 리플레이 공식 문서
• 와탭 브라우저 에이전트 적용 가이드
• Amazon CloudWatch RUM 세션 리플레이 발표 (AWS, 2026.05)