실시간 프론트엔드 텔레메트리 플랫폼

문제

일부 사용자는 길고 여러 단계로 된 흐름에서 조용히 이탈했습니다. 서드파티와의 연동이 깨져도 아무도 알아채지 못했고, 원인 파악은 흩어진 서버 로그를 손으로 읽는 일이라 며칠이 걸렸습니다. 그 하루하루가 끝내 완료하지 못한 실제 사용자였습니다.

접근 방식

• 작고 타입이 있는 SDK. 하나의 TypeScript 트래커가 모든 화면과 플랫폼에서 같은 사용자 행동 데이터를 수집하므로, 이벤트가 어디서든 같은 의미를 갖습니다.
• 안전장치가 있는 스로틀링. SDK는 이벤트를 묶어 짧은 타이머나 크기 한도 중 먼저 도달하는 쪽에서 전송합니다. 클릭마다 요청 하나를 보내면 브라우저의 네트워크 스레드가 고갈되고, 너무 오래 쥐고 있으면 탭을 닫을 때 유실될 수 있어서 페이지를 떠날 때는 navigator.sendBeacon을 씁니다.
• 검증하는 BFF. 묶음 이벤트는 Backend for Frontend로 들어가 TypeScript 정의에 맞춰 스키마를 확인하고, 타임스탬프가 타당한지 검사하며, 예상치 못한 필드와 개인 데이터를 제거하고, 세션 메타데이터를 붙입니다. 백엔드의 판정과 UI가 보여 준 내용을 비교하자 둘 사이의 상태 불일치가 드러났습니다.
• 컬럼형 저장소로 이어지는 스트리밍 파이프라인. 스트리밍은 트래픽 급증을 흡수하고, 컬럼형 저장소는 행 기반 저장소가 느려지는 매우 크고 카디널리티 높은 이벤트 집합의 집계를 밀리초 안에 처리합니다.
• 조용한 장애 처리. 파이프라인이 멈추면 SDK는 작은 버퍼를 로컬에 보관하고, 수동형 서킷 브레이커가 전송을 멈춥니다. 서버에 상태를 확인하려고 핑을 보내지 않고, 다음 성공 응답을 기다립니다.

결과

사고 감지 시간이 며칠에서 5분 미만으로 줄었습니다. 고장 난 단계가 수많은 실패로 이어지는 상황에서는, 사후 분석 문서의 한 줄로 끝나느냐 그날 아침에 고치느냐의 차이입니다.