장애를 찾기 위한 로그와 제품을 이해하기 위한 이벤트는 다르다. 이번 프로젝트에서는 페이지뷰보다 사용자의 결정 지점을 먼저 정의했다.

좋은 이벤트 이름
먼저 측정 가능한 기준을 정했습니다. 감으로 빠르다거나 편하다고 말하기보다, 응답 시간, 실패율, 유지보수 비용처럼 팀이 반복해서 볼 수 있는 지표를 앞에 뒀습니다.
track("checkout_step_completed", {
step: "shipping",
elapsedMs: 1840
});
샘플링 기준
작게 도입한 뒤 한 주 동안 운영 데이터를 모았습니다. 예상보다 좋았던 부분은 개발 경험이었고, 예상보다 까다로웠던 부분은 예외 상황의 디버깅이었습니다.
대시보드 피로 줄이기
마지막 체크리스트는 단순합니다. 되돌릴 수 있는가, 실패를 관찰할 수 있는가, 팀원이 같은 결정을 다시 설명할 수 있는가. 이 세 가지가 통과되면 도입 리스크는 꽤 낮아집니다.
운영 메모
새 기술은 성능보다 운영 루틴을 먼저 흔듭니다. 알림, 로그, 롤백 경로를 같이 설계해야 오래 갑니다.
Comments
Google 계정으로 로그인 후 댓글 작성