Session Replay는 사용자 화면을 실제로 보고 있는 것처럼 재생해주는 기능으로,

UX 개선, 오류 재현, 퍼널 이탈 분석, A/B 테스트 모니터링 등에서 매우 강력한 도구입니다.

하지만 동시에 이 기능은 한 가지 매우 큰 위험을 가지고 있습니다.

“사용자가 화면에 입력한 개인 정보가 그대로 Replay에 남는다.”

즉, 화면에 보이는 모든 요소가 Replay에도 그대로 기록되기 때문에, 아래와 같은 민감 정보가 노출될 위험이 존재합니다.

• 이메일 / 이름 / 전화번호
• 생년월일, 주소, 우편번호
• 비밀번호 입력 패턴
• SMS·이메일 인증번호
• 결제 정보(카드번호 등)
• 계정 ID·가구 ID·주문번호 등 서비스 내부 식별자

특히 회원가입, 로그인, 결제, 마이페이지 같은 화면은 사용자가 개인 정보를 가장 많이 입력하는 구역이기 때문에

Replay 기능을 켜는 순간부터 반드시 철저한 마스킹 전략이 필요합니다. Session Replay는 편리하지만, 한 개의 필드만 마스킹이 누락되어도 개인정보가 포함된 화면 기록이 그대로 저장소에 남는다는 점이 가장 큰 리스크입니다.

따라서 일부만 마스킹해도 되겠지가 아니라 전체를 먼저 막고, 필요한 영역만 제한적으로 공개하는 구조가 가장 안전한 접근입니다.

1. 왜 Session Replay에서 마스킹이 필수인가

Amplitude Session Replay는 DOM 기반으로 동작합니다. 즉, 사용자에게 보이는 모든 정보는 Replay에도 표시됩니다. 예를 들어 다음과 같은 상황에서는 위험도가 매우 높습니다.

• 사용자가 이메일을 입력하는 순간
  • Replay에서는 그대로 이메일 주소가 노출됩니다.
• 전화번호, 인증번호 입력
  • 입력창 내용뿐 아니라 입력 시점, 입력 패턴까지 Replay에 기록됩니다.
• 비밀번호 입력창(type=password)
  • 별표(****)로 보이더라도 Replay에서는 해당 필드의 변화가 모두 캡처됩니다.
• UI 텍스트 자체가 민감한 경우
  • 주문번호, 계정 정보, 내부 식별자 등도 그대로 Replay에 포함됩니다. (사용자 입력이 아니더라도 그냥 화면에 존재하면 기록됩니다.)

그렇기 때문에 Session Replay 도입 시 가장 우선해야 할 작업은

민감 정보가 들어갈 수 있는 모든 영역을 마스킹하는 것입니다.

2. Amplitude Session Replay 공식 마스킹 방법 총정리

1. DOM 요소 마스킹(data-attribute 기반)

Amplitude Session Replay는 CSS Selector 기반으로 마스킹 대상을 지정할 수 있습니다.

클래스 이름이 빌드 과정에서 해시로 변하는 Next.js/React 프로젝트에서는 data attribute 방식(data-amp-mask) 이 가장 안정적입니다.

• input, textarea 요소에 사용 가능
• Replay에서는 해당 요소 내부의 텍스트, 입력값이 모두 *** 마스킹 처리됨
• DOM 구조를 없애는 것이 아니라, 콘텐츠만 보이지 않게 처리
• 특정 민감 텍스트만 지정해서 마스킹 가능

2. 텍스트/비텍스트 요소 마스킹 (UI 전용 차단 영역)

• amp-block
  • div, section, span, button 등 텍스트가 아닌 UI 요소 전체를 블록 단위로 차단할 때 사용합니다.
  • 영역 내부의 텍스트·UI는 Replay에서 모두 보이지 않고, 동일한 크기의 placeholder 박스로 대체됩니다.
• amp-mask
  • p, h1 ~ h5, strong, label 등 주요 텍스트 요소에 적용하여 문구만 마스킹합니다.
  • 텍스트는 블러 처리 또는 숨김 처리되며, UI 레이아웃은 그대로 유지됩니다.

특징

• Replay는 마스킹된 요소를 화면과 동일한 크기의 블록 placeholder로 렌더링해 UX 흐름은 유지하면서 민감 정보만 안전하게 제거합니다.

3. PrivacyConfig 기반 셀렉터 마스킹

Session Replay 초기화 시점에 페이지 전체의 마스킹 정책을 한 번에 정의할 수도 있습니다.

• blockSelector
  • 해당 셀렉터에 매칭되는 DOM은 통째로 Replay 대상에서 제외됩니다.
  • 예: 광고 영역, 서드파티 위젯, 로그인 프레임 등
• defaultMaskLevel
  • 페이지 전체 기본 마스킹 레벨을 설정합니다.
  • 서비스 성격에 따라 none, medium, all 등으로 정책을 가져갈 수 있습니다.
• maskSelector
  • 지정한 CSS 셀렉터에 매칭되는 요소는 내용이 항상 마스킹됩니다.
  • 예: .sensitive-data, .user-email, .credit-card 등
  • 여기에는 DOM에서 붙인 클래스/속성(.amp-mask, [data-amp-mask])을 그대로 활용할 수 있습니다.
• unmaskSelector
  • 기본/상위 레벨이 마스킹이어도, 해당 셀렉터는 마스킹을 해제합니다.
  • 예: 페이지 전체를 medium으로 두되, 특정 공개 영역만 unmask해서 UI를 보고 싶을 때 사용

4. 자동 마스킹 커스텀 훅(useAutoMask) 적용

실제 운영을 하다 보면,

• 개발자가 input을 새로 추가했는데 data-amp-mask를 깜빡하고 안 넣거나,
• placeholder만 바뀌었는데 민감 필드로 인식하는 로직을 안 고쳤다거나

하는 사소한 실수가 Replay와 맞물려 치명적인 문제로 이어질 수 있습니다.

이 리스크를 줄이기 위해, DOM을 스캔해서 민감 필드를 자동으로 감지하고 마스킹을 추가하는 훅을 함께 두는 것이 좋습니다.

SignUpModal에 적용:

장점

• email, password, phone, name 등 민감 키워드 기반으로 input을 자동 스캔합니다.
• 새로운 input이 추가되어도, 이름/placeholder에 해당 키워드를 포함하면 자동으로 data-amp-mask가 붙습니다.

9. 개인정보 보호 체크리스트

Amplitude Session Replay를 서비스에 적용할 때는 단순히 input 마스킹만으로는 충분하지 않습니다. 사용자가 남기는 다양한 흔적 중 어떤 것이 개인정보로 분류될 수 있는지, 그리고 Replay에서 노출될 가능성은 없는지 사전 점검 체계가 필요합니다. 아래 체크리스트는 실무에서 Session Replay를 운영할 때 반드시 확인해야 하는 핵심 항목들입니다.

마무리

Session Replay는 단순한 화면 녹화 기능이 아니라, 제품의 UX 문제를 눈으로 확인하고, 버그를 빠르게 재현·분석하며,

사용자 흐름을 데이터와 정성적 관찰로 동시에 이해하게 해주는 강력한 기능입니다.

하지만 동시에, 민감 정보가 가장 쉽게 노출되는 고위험 기능이기도 합니다. 

따라서 이번 글에서 정리한 다음 세 가지 핵심 원칙은 Replay 도입 시 반드시 지켜야 하는 필수 안전 가이드입니다.

• 전체 마스킹 — 높은 민감도를 가진 화면은 완전히 숨기기
• 입력 영역 마스킹 — UI는 보되 개인정보는 숨기는 균형 전략
• 자동 마스킹 훅 — 개발 과정에서 빠지는 영역 없이 이중 보호
• DOM Attribute 마스킹 — 공식 문서 기준 확실한 차단
• 민감 정보 체크리스트 기반 검증 — 서비스 전체 보호 체계 강화

이 원칙만 잘 지켜도 Session Replay는 위험한 기능이 아니라, 안전하고, 확장 가능하며, 운영·개발팀 모두가 신뢰할 수 있는 분석 기능 으로 자리잡게 됩니다.

앞으로도 회원가입/로그인/결제/마이페이지 등 실제 서비스 환경에서 바로 사용할 수 있는 Session Replay 보호 패턴을 더 깊이 있게 정리해 계속 공유드리겠습니다.