병원 홈페이지 문의 중복 제출, 같은 사람보다 같은 요청을 판별합니다

같은 전화번호로 5분 안에 두 번 들어왔다고 모두 중복은 아닙니다. 첫 문의 뒤 예약 날짜를 바꾸거나 다른 가족의 문의를 다시 남겼을 수 있습니다. 반대로 네트워크 지연으로 버튼을 여러 번 누른 한 요청은 이름 표기가 조금 달라도 중복일 수 있습니다. 개인을 기준으로 삭제하지 말고, 하나의 제출 시도에 부여한 토큰과 요청 내용·시간·처리 상태를 함께 비교해야 합니다.

화면에서 반복 제출 가능성을 먼저 줄입니다

첫 클릭 뒤 버튼을 잠그고 `접수 중` 상태를 보여 주되, 실패했을 때 다시 시도할 방법은 남깁니다. 브라우저가 멈춘 것처럼 보여 사용자가 새로고침하지 않도록 진행·성공·실패 상태를 분명히 구분합니다. 성공 화면에는 접수 번호를 표시하고 이전 화면으로 돌아가 재전송해도 새 요청이 무조건 만들어지지 않게 합니다.

클라이언트의 버튼 잠금만 믿지 않습니다. 두 탭, 뒤로 가기, 느린 이동통신망과 자동 재시도에서는 여러 요청이 서버에 도착할 수 있습니다. 제출 화면을 열거나 첫 제출을 시작할 때 충분히 고유한 토큰을 만들고 서버가 그 토큰의 첫 처리 결과를 기록하게 합니다.

재시도와 새로운 문의를 구별합니다

Stripe의 API 문서는 멱등 키를 사용하면 연결 오류 뒤 같은 요청을 안전하게 재시도하면서 작업이 두 번 수행되는 것을 피할 수 있다고 설명합니다. 서버는 같은 키의 첫 결과를 저장하고 뒤 요청에 같은 결과를 돌려줍니다. 멱등 요청 안내 이 원리를 문의 접수에 적용할 때에도 키의 유효 기간, 충돌 가능성, 실패 결과 처리와 개인정보 분리를 설계해야 합니다.

같은 토큰이면 동일 시도의 재전송 후보로 봅니다. 토큰이 다르면 시간 간격, 문의 유형, 정규화한 연락 수단과 본문의 유사도를 보조 신호로 쓰되 자동 삭제하지 않습니다. `예약 변경`처럼 같은 사람이 짧은 시간 안에 다른 내용을 보낼 수 있기 때문입니다.

중복 후보는 원본에 연결합니다

운영 화면에는 두 접수의 차이, 생성 시각, 유입 페이지, 첨부 여부와 현재 담당자를 나란히 보여 줍니다. 중복으로 확정하면 하나를 지우기보다 원본 접수 번호에 연결하고 `중복` 상태와 판단자를 남깁니다. 이미 서로 다른 담당자가 응답을 시작했다면 병합 전에 소유자를 조정해 상반된 답변이 나가지 않게 합니다.

개인정보를 해시하면 무조건 안전하거나 정확한 중복 판별이 되는 것은 아닙니다. 입력값 정규화와 해시 방식, 보관 기간, 접근 권한을 별도로 승인하고 원문을 분석 도구로 보내지 않습니다. 전화번호 일부만 같은 경우나 공용 연락처는 일치 신호로 단정하지 않습니다.

장애와 시간 차이를 넣어 시험합니다

더블클릭, 3초 지연, 응답 직전 연결 끊김, 새로고침, 다른 탭, 10분 뒤 내용 수정과 다음 날 재문의를 시험합니다. 각 경우에 저장 건수, 사용자 메시지, 알림 수, 담당자 배정과 분석 이벤트가 예상대로인지 기록합니다. 시험 건은 실제 문의 대기열에서 명확히 표시하고 완료 후 승인 절차에 따라 제거합니다.

주간 점검에서는 차단 건수만 보지 말고 자동 후보 중 실제 중복 비율과 잘못 합칠 뻔한 건도 봅니다. 가정으로 후보 20건 가운데 8건만 같은 요청이었다면 시간 기준을 넓히기보다 토큰 전달 누락과 후보 규칙을 먼저 고칩니다.

출처 확인일은 2026-10-26입니다. 기술 패턴과 수치는 설명용이며 실제 구현은 접수 시스템, 개인정보 처리 기준과 장애 복구 정책에 맞춰 검토해야 합니다.