리플레이는 재구성이지 영상이 아닙니다
세션 리플레이에 관한 가장 흔한 오해는 화면을 녹화한다는 생각입니다. 그렇지 않습니다. 리플레이가 기록하는 것은 DOM, 즉 페이지의 구조와 그에 가해진 모든 변경, 그리고 클릭, 스크롤, 입력 이벤트, 네트워크 소요 시간, 콘솔 오류입니다. 재생할 때는 그 데이터로 브라우저에서 페이지를 다시 조립합니다.
바로 이 차이가 핵심입니다. 리플레이는 픽셀이 아니라 구조화된 데이터이기 때문에 검색할 수 있고, 오류가 발생한 정확한 순간으로 건너뛸 수 있으며, 그 시점의 DOM 상태를 읽을 수 있습니다. 화면 녹화로는 그 어느 것도 할 수 없고, 대역폭은 훨씬 더 많이 씁니다.
스택 트레이스가 주지 못하는 것
에러 트래커는 214번째 줄에서 TypeError가 발생했다고 알려줍니다. 하지만 그 사용자가 이미 폼을 두 번 제출했다는 사실도, 두 번째 시도가 느린 연결에서 이뤄졌다는 사실도, 그 후 버튼이 계속 비활성 상태였다는 사실도 알려주지 않습니다. 리플레이는 코드가 걸려 넘어진 그 상태를 만들어낸 일련의 사건을 제공합니다.
실무에서 이것은 디버깅에서 가장 오래 걸리는 단계인 재현을 없애줍니다. 한 줄짜리 버그 리포트로 단계를 추측하는 대신, 사용자가 실제로 지나간 경로를 그대로 봅니다.
버그가 접수됐을 때 쓰는 법
세션 처음부터 따라가지 말고 실패 지점에서 거꾸로 올라가세요. 모니터링에서 오류를 찾고, 연결된 리플레이를 열어 해당 타임스탬프로 이동합니다. 그런 다음 30초를 되감으세요. 원인은 거의 언제나 증상 직전 30초 안에 있지, 세션 시작 지점에 있지 않습니다.
다음 세 가지를 순서대로 확인하세요. 사용자가 바로 직전에 무엇을 클릭했는가. 실패했거나 응답이 오지 않은 요청이 있었는가. 그리고 화면에 보인 것이 렌더링될 것으로 기대한 것과 일치했는가. 대부분의 버그는 이 셋 중 하나에서 해결됩니다.
리플레이로 풀리지 않는 것
리플레이는 무슨 일이 있었는지를 보여줄 뿐, 그 사람이 왜 그렇게 했는지는 보여주지 않습니다. 사용자가 폼을 포기했다면 기록은 어느 입력란에서 멈췄는지 알려주지만, 그 질문이 헷갈렸는지, 지나치게 사적이라 느꼈는지, 단지 너무 길었는지는 알려주지 못합니다. 그 답은 직접 물어봐야 나옵니다.
집계 질문에도 약합니다. 녹화 한 건은 일화일 뿐입니다. 어떤 일이 얼마나 자주 일어나는지 알아야 한다면 그것은 퍼널이나 이벤트 조회의 몫입니다. 리플레이는 이탈을 설명하는 데 쓰는 도구이지, 측정하는 도구가 아닙니다.
디버깅용으로 고를 때의 기준
디버깅이 목적이라면 무엇보다 세 가지를 따지세요. 콘솔과 네트워크 기록 — 이것이 없으면 무성영화를 보는 셈입니다. 오류에서 리플레이로 이어지는 연결 — 예외에서 그것을 만들어낸 세션으로 곧장 갈 수 있어야지, 목록을 뒤지게 해서는 곤란합니다. 그리고 도구를 쓸모 있게 유지할 만큼 세밀한 개인정보 제어입니다. 모든 입력을 가리면 사용자는 보호되지만 버그를 유발한 바로 그 값까지 숨겨집니다. 전부 아니면 전무인 스위치 대신 항목 단위 규칙을 갖춘 것을 고르세요.