참여 지표는 지키고 진단 로그만 줄이기
참여 지표는 수집 대상에서 제외하지 않고 상세 진단만 기기 고정 2% 표본으로 줄였습니다. 데이터 플랫폼 담당자는 8월 적용 뒤 진단 이벤트 약 86%, 당시 BI 전체 이벤트 처리량 약 54% 감소를 보고했습니다. 표본 밖 문의를 위한 별도 조사 경로도 남겼습니다.
외부 콘텐츠를 읽고 돌아왔는데 리워드 안내가 사라지는 문제가 있었습니다. 서버에는 성공 기록이 있었고 화면에는 결과가 없었으며 예외도 없었습니다. 클릭부터 이동·복귀·상태 조회·안내 표시까지 순서를 이어 보려면 상세 진단이 필요했습니다. 하지만 상태와 버튼을 촘촘히 기록하자 수집량도 커졌습니다.
저는 수집량을 줄이되 제품 지표의 분모와 한 기기의 사건 순서를 함께 지킬 수 있는가를 기준으로 정책을 바꿨습니다. 8월에는 제품 지표와 상세 진단을 분리해 기기별 표본을 적용했습니다. 9월에는 표본 밖 기기를 지정해 조사할 보충 경로를 더했습니다. 두 변경은 시기와 검증 범위가 다릅니다.
줄이면 안 되는 이벤트부터 가렸다
제품 참여를 집계하는 이벤트와 문제를 재현하는 상세 진단은 소비 목적이 달랐습니다. 처음에는 자동 수령 성공 이벤트를 진단으로 분류했지만, 해당 KPI의 전체 집계에 쓰인다는 사실을 확인하고 제품 지표 이벤트로 되돌렸습니다. 이벤트 이름이나 만드는 코드만 보고 표본 대상을 정하면 지표의 분모가 바뀔 수 있었습니다.
제품 지표 이벤트는 클라이언트의 표본 정책에서 제외했습니다. 상세 진단만 줄였습니다. 이는 지표 이벤트의 전송·적재가 언제나 성공했다는 뜻은 아닙니다.
이벤트마다 뽑지 않고 기기를 고정했다
상세 진단은 유효한 서버 기기 ID로 매번 같은 표본 결과가 나오도록 계산해 2%를 선택했습니다. 선택된 기기에서는 관련 진단을 이어 수집했습니다. 이벤트마다 따로 뽑으면 참여 시작은 남고 완료는 빠질 수 있어, 한 흐름을 따라가기 어렵기 때문입니다.
이 정책은 사람 전체나 세션이 아니라 기기를 선택합니다. 모든 문의 기기의 상세 기록이 남는 방식도 아닙니다. 간결한 요약과 상세 기록에는 같은 흐름의 식별자·시각·기록 형식 버전을 넣어 서로 대조할 수 있게 했습니다.
클라이언트의 기존 전송 API와 이벤트 계약은 유지했습니다. 데이터 플랫폼팀에는 진단 이벤트를 별도로 저장·조회하자고 제안했습니다. 플랫폼팀은 적재와 기존 데이터 반영·정합성 확인을 맡았고, 저는 관리하던 조회의 소스를 옮겼습니다.
8월 적용 뒤 데이터 플랫폼 담당자는 진단 이벤트 약 86%, 당시 BI 전체 이벤트 처리량 약 54% 감소를 보고했습니다. 보고에는 비교 기간·변경 전후 건수의 상세가 없어 독립 재계산 값으로 제시하지 않습니다. 이 수치는 2% 표본 비율에서 계산한 값이나 청구 비용 절감률도 아닙니다.
표본 밖 문의가 들어오면
9월에는 조사 대상 기기의 상세 진단을 추가로 받을 수 있게 했습니다. 대상 판정이 첫 행동보다 늦으면 초기 기록이 빠지므로, 판정 전 진단을 제한된 메모리 공간에 발생 순서대로 보관했습니다. 대상이면 보내고, 아니면 비웠습니다. 페이지가 닫힌 뒤 과거 로그까지 복구하는 방식은 아닙니다.
제품 지표는 이 판정을 기다리지 않고 보냈습니다. 나중에 조사 대상임이 확인되면 같은 흐름을 연결하는 식별자로 상세를 보충했습니다. 정책상 수집하지 않는 진단은 호출자가 실패로 오해해 재발행하지 않도록 처리 완료로 반환하고, 실제 전송 실패만 실패로 남겼습니다.
9월의 보충 경로를 앞서 보고된 8월 감소 수치의 원인으로 합치지 않았습니다. 이 사례에서 제가 세운 경계는 KPI의 분모는 줄이지 않고, 진단은 한 기기의 사건을 이어 읽을 수 있게 줄이며, 표본 밖 사건은 별도의 조사 경로로 다룬다는 것입니다. 모든 기기를 항상 추적할 수 있다는 뜻은 아닙니다.