단계별 사실을 정의합니다
요청 수신, 유효성 통과, 저장, 후속 알림, 성공 응답, 화면 안내와 분석 이벤트를 나눕니다. 서버가 접수를 저장한 뒤 브라우저 연결이 끊길 수도 있습니다. 이 경우 사용자가 실패로 느껴 다시 보낼 수 있어 업무 중복 방지와 화면 안내가 함께 필요합니다.
원장과 로그의 역할
원장은 실제 처리 상태를 관리하고 기술 로그는 오류를 조사하는 데 씁니다. 로그 한 줄이 출력됐다는 이유만으로 저장이 완료됐다고 판단하지 않습니다. 가정한 예로 ‘접수 시작’ 로그만 남고 저장이 실패했다면 완료 원장에 들어가서는 안 됩니다.
중복 책임을 정합니다
브라우저와 서버가 같은 전환을 각각 보내면 수집 도구가 어떤 중복 제거를 지원하는지 확인해야 합니다. 임의의 동일 필드를 추가하면 자동 통합될 것이라고 가정하지 않습니다. 필요 없는 이중 전송은 줄이고 유지해야 한다면 공식 지원 조건과 재시도 정책까지 명세합니다.
장애 시험
- 서버 저장 전 실패와 저장 후 연결 종료를 나눕니다.
- 브라우저 분석 차단 상황을 시험합니다.
- 재전송에서 접수가 중복되는지 확인합니다.
- 원장·화면·이벤트의 결과를 시나리오별로 적습니다.
실제 고객 자료를 사용하지 않고 시험 환경이나 승인된 테스트 한도를 정합니다. 후속 메일 실패 때문에 이미 저장한 접수가 사라지거나 브라우저가 성공을 반복 전송하는지도 확인합니다. 장애 위치에 따라 사용자의 재시도 안내가 달라져야 합니다.
운영 완료 기준
보존 기간이 다른 로그와 원장도 구분합니다. 조사가 필요한 시점에 어떤 증거가 남아 있는지 알아야 사고 범위를 확인할 수 있습니다.
접수 담당자가 어느 자료를 믿고 처리할지 알고, 개발 담당자가 실패 구간을 찾아 재처리할 수 있어야 합니다. 서버 기록이 있다는 사실과 고객에게 성공 화면이 보였다는 사실을 따로 보고합니다. 측정 숫자의 일치보다 처리 사실을 잃지 않고 관측의 한계를 설명하는 체계가 중요합니다. 원장 접근 권한과 민감 정보 최소화도 이 책임 구분에 포함합니다.
자주 묻는 질문
- 서버에서만 이벤트를 보내면 누락이 없어지나요?
- 서버 전송도 요청 실패·재시도·중복과 정책 검토가 필요합니다. 수집 위치 변경이 모든 누락을 해결한다고 보지 말고 어떤 업무 사실을 어느 경로가 소유하는지 정해야 합니다.
- 브라우저 완료가 없는데 원장에 있으면 어느 쪽이 맞나요?
- 접수 사실은 원장의 처리 상태를 확인하고 사용자의 화면 경험은 브라우저 관찰로 봅니다. 둘이 다른 목적의 증거일 수 있으므로 한쪽을 지워 숫자만 맞추지 않습니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.