여정 내 '마찰 지점(Friction Point)' 식별: 결제 퍼널, 본인인증 등 유저가 가장 많이 탈락하는 구간의 데이터적 포착

마찰 지점(Friction Point)은 CJM의 감정 곡선이 급격히 떨어지거나, 정량 데이터 상 이탈률이 유독 높게 튀는 구간으로 나타납니다. 여정 전체를 하나의 선으로 그렸을 때 대부분의 구간은 완만하게 이어지지만, 특정 지점에서만 뚝 떨어지는 형태를 보인다면 그 지점이 우선 조사 대상입니다. 이 급락이 일회성 이벤트(시스템 장애, 프로모션 종료)로 인한 것인지, 아니면 구조적으로 매번 반복되는 문제인지부터 구분해야 합니다 — 여러 주에 걸쳐 반복적으로 같은 지점에서 급락이 나타난다면 구조적 마찰 지점으로 볼 수 있습니다.

CJM 작성 시 피해야 할 실수는 고객 기준이 아닌 내부 프로세스 기준으로 여정을 그리는 것, 데이터 없이 추측만으로 작성하는 것입니다. 예를 들어 회사 내부에서는 "주문 접수 → 상품 준비 → 배송 → 완료"라는 물류 프로세스 순서로 여정을 그리기 쉽지만, 실제 고객은 "주문했는데 언제 오는지 확인하고 싶다 → 문의했는데 답이 늦다 → 불안해서 취소했다"는 전혀 다른 감정 흐름을 겪고 있을 수 있습니다. 내부 프로세스 기준으로 그린 지도는 마찰 지점을 회사 입장에서 문제없어 보이는 구간에 숨겨버리는 경우가 많아, 반드시 고객의 실제 행동·문의 데이터를 기준으로 재작성해야 진짜 마찰 지점이 드러납니다.

결제 퍼널처럼 배송지 입력, 결제수단 선택, 본인인증, 최종 확인 같은 여러 하위 스텝을 거쳐야 하는 구간은 마찰 지점이 숨어 있을 확률이 특히 높습니다. 각 하위 스텝마다 별도의 입력·검증·대기 시간이 발생하기 때문에, 어느 한 스텝만 조금 불편해도 전체 완료율에 누적된 영향을 미칩니다. 이런 구간은 전체 완료율 하나만 보지 말고, 스텝별 진입률·이탈률을 따로 추적해야 어느 하위 스텝이 실제 병목인지 정확히 짚을 수 있습니다. 본인인증처럼 외부 시스템(PASS, 카드사 인증 등)에 의존하는 스텝은 특히 실패율이나 타임아웃 로그를 별도로 확인해야 하는 경우가 많습니다.

마찰 지점을 찾았다고 해서 원인까지 자동으로 밝혀지는 것은 아닙니다. 이탈률 수치는 "여기서 문제가 있다"는 신호일 뿐, "정확히 무엇이 문제인가"는 별도로 확인해야 합니다. 그 구간의 CS 문의 로그를 검토해 반복되는 불만 키워드가 있는지 확인하고, 가능하다면 세션 리플레이 툴로 실제 유저가 그 화면에서 어떤 행동을 하다 이탈했는지(반복 클릭, 뒤로가기, 장시간 멈춤 등)를 관찰하는 것이 원인을 특정하는 가장 직접적인 방법입니다. 정량 데이터가 '어디'를 알려준다면, 정성 데이터와 행동 관찰이 '왜'를 알려주는 역할을 합니다.

한 번에 여러 마찰 지점이 발견되면 우선순위를 정해야 합니다. 실무에서 효과적인 기준은 '영향도'로, 그 구간을 지나는 트래픽 규모와 이탈률을 함께 곱해서 판단하는 방식입니다. 트래픽이 적은 구간의 이탈률이 아무리 높아도 전체 매출에 미치는 영향은 제한적일 수 있고, 반대로 이탈률이 상대적으로 낮아도 전체 유저가 반드시 거치는 핵심 구간이라면 작은 개선만으로도 큰 효과를 낼 수 있습니다. 개선 리소스가 제한적인 상황에서는 이 영향도 기준으로 상위 1~2개 마찰 지점부터 집중해서 해결하고, 효과를 확인한 뒤 다음 지점으로 넘어가는 방식이 합리적입니다.

마찰 지점을 개선했다면, 그 구간의 이탈률이 실제로 낮아졌는지 반드시 재확인해야 합니다. 개선이 의도한 효과를 냈는지 확인하지 않으면, 다음 분기에 같은 지점을 다시 마찰 지점으로 재발견하는 비효율이 반복될 수 있습니다. 또한 한 구간의 마찰을 해결하면 그 다음 구간으로 유입되는 트래픽이 늘어나면서, 이전에는 드러나지 않았던 새로운 마찰 지점이 다음 구간에서 나타나는 경우도 흔합니다. 마찰 지점 관리는 한 번의 프로젝트로 끝나는 것이 아니라, 개선 → 검증 → 다음 지점 발견으로 이어지는 지속적인 사이클로 운영해야 합니다.

마찰 지점을 공개적으로 발표하면, 그 구간을 담당하는 부서가 방어적으로 반응하는 경우가 종종 있습니다. 예를 들어 본인인증 마찰이 발견되면 개발팀은 "외부 인증사 문제"라 하고, CS팀은 "고객이 원래 불편해하는 절차"라 하는 식으로 책임을 서로 미루기 쉽습니다. 이런 반응을 줄이려면 마찰 지점 리포트를 특정 부서의 실패로 프레이밍하지 않고, 데이터로 확인된 개선 기회로 제시하는 방식이 효과적입니다. 데이터(이탈률 추이)와 정성 근거(CS 문의 인용)를 함께 제시하면 감정적 반박보다 실질적인 해결책 논의로 대화를 이끌기 쉬워집니다.