폼 제출이 왜 중복으로 들어오나요?
폼이 실제로 두 번 이상 제출되었고, 받는 쪽에서 아무도 그것을 알아채지 못했기 때문입니다. 페이지가 같은 문의를 두 번 보내는 흔한 이유만 해도 최소 다섯 가지입니다 — 두 번째 클릭, 이미 성공한 요청의 재시도, 새로고침, 하나의 폼에 연결된 두 개의 처리기, 그리고 봇입니다. 그래서 첫 누름 뒤 버튼을 비활성화해도 그중 하나만 해결되고 나머지는 남습니다. 오래가는 해법은 받는 쪽에 있습니다. 같은 폼에서 온 동일한 제출을 짧은 시간창 안에서는 무시하고, 그 반복에 대해 마치 정상 접수된 것과 똑같이 응답하는 것입니다.
문의 하나가 셋이 되는 다섯 가지 경로
본능적으로 폼을 의심하게 되지만 폼은 대개 멀쩡합니다. 중복은 평범한 페이지가 평범한 네트워크를 만났을 때 생기는 일이고, 첫 번째로 쓸모 있는 수는 수정이 아닙니다. 지금 보고 있는 것이 이 중 어느 것인지 가려내는 일입니다. 각각 답이 다르기 때문입니다.
- 방문자가 제출을 두 번 눌렀다. 첫 누름 뒤에 눈에 보이는 변화가 없어서 다시 눌렀습니다. 가장 흔한 원인이고, 버튼을 비활성화하라는 흔한 조언이 실제로 다루는 유일한 원인입니다.
- 이미 성공한 요청이 재시도되었다. 제출은 처리기에 도달했고, 처리기는 저장했으며, 응답이 돌아오는 길에 사라졌습니다. 보내는 쪽에서는 실패이므로 다시 시도합니다. 몇 초 차이로 완전히 동일한 사본이 생기는 것이 이 경우이고, 페이지를 아무리 정성껏 만들어도 막지 못합니다.
- 페이지를 새로고침했거나 뒤로 가기로 다시 들어왔다. 제출한 뒤 같은 자리에 자체 감사 화면을 그리는 폼은, 누군가 새로고침하면 기꺼이 전부 다시 보내겠다고 제안합니다. 이 사본들은 몇 분에서 몇 시간 간격으로 도착하고, 그것이 단서입니다.
- 하나의 폼을 두 가지가 처리하고 있다. 호스팅에 내장된 폼 처리기와, 생성 도구나 플러그인이 덧붙인 스크립트가 각자 자기 사본을 보냅니다. 거의 동시에 도착하고 모양이 다른 경우도 많습니다 — 한쪽은 모든 항목을 담고 다른 쪽은 절반쯤 비어 옵니다.
- 사람이 아니었다. 링크 미리 가져오기, 보안 스캐너, 평범한 봇이 폼 엔드포인트에 도달하고 때로는 제출까지 합니다. 이 사본들은 단지 반복된 것이 아니라 쓸모가 없습니다. 빈 항목, 의미 없는 값, 여러 주소에서 오는 동일한 내용 같은 것들입니다. 허니팟 항목 — 사람은 결코 보지도 채우지도 않는 입력칸 — 을 두면 거의 힘들이지 않고 대부분을 걸러냅니다.
두 가지만 읽으면 대부분의 경우가 정리됩니다. 사본 사이의 간격을 보세요. 거의 동시면 처리기가 둘이거나 봇, 몇 초 차이면 두 번째 클릭이나 재시도, 몇 분 이상이면 새로고침입니다. 그다음 사본들이 완전히 같은지 보세요. 실제 사람이 보낸 진짜 두 번째 문의는 단어 하나라도 거의 언제나 어딘가 다릅니다.
고칠 자리는 받는 쪽이다
그 목록에서 봇을 뺀 나머지는 전부 정상적인 동작이지 없앨 수 있는 결함이 아닙니다. 네트워크는 응답을 잃고, 사람은 두 번 클릭하며, 브라우저는 보내라고 시킨 것을 다시 보냅니다. 그중 무엇도 멈추지 않습니다. 그러니 바뀌어야 하는 것은 같은 문의가 두 번째로 도착했을 때 무슨 일이 벌어지는가입니다.
구조는 작습니다. 제출 내용에서 짧은 지문을 뽑아 몇 분만 기억해 두고, 동일한 내용이 그 시간창 안에 다시 도착하면 두 번째 사본을 저장하지 않는 것입니다. 이것으로 두 번째 클릭, 네트워크 재시도, 새로고침이 한 번에 덮입니다. 그중 무엇이 일어났는지는 신경 쓰지 않고, 이 문의를 이미 본 적이 있다는 한 가지만 보기 때문입니다.
틀리기 쉬운 대목은 그 중복에 무엇을 응답하느냐입니다. 우리는 고객이 게시하는 페이지를 호스팅하고 있어서 고객들의 문의 폼이 모두 우리 엔드포인트 한 곳으로 들어옵니다. 그리고 중복은 계속 돌아오는 불만이었습니다. 서로 다른 고객 사이트 세 곳에서 문의 하나가 각각 세 번, 다섯 번, 두 번 저장되어 있었습니다. 엔드포인트가 중복에 대해 정상 접수된 것과 바이트 단위로 같은 응답을 돌려주기 시작할 때까지 재발했습니다. 중복을 거부하는 엔드포인트는 아무리 정중하고 친절한 문구를 쓰더라도 앞에 있는 페이지에 무언가 잘못되었다고 알립니다. 그러면 페이지 자체의 재시도 로직이나 오류를 읽은 방문자가 한 번 더 보냅니다. 중복을 걸러내면서 실패처럼 보이는 엔드포인트는 중복 생성기입니다.
시간창 고르기, 그리고 버리면 안 되는 것
시간창의 길이만이 진짜 판단의 영역이고, 한쪽 실수를 다른 쪽 실수와 맞바꿉니다. 너무 짧으면 늦게 온 재시도가 그대로 들어옵니다. 너무 길면 진짜 두 번째 문의를 소리 없이 버립니다 — 아침에 썼는데 답이 없어서 같은 문장으로 다시 쓴 사람 말입니다. 기계적인 원인은 모두 빠르게 일어나므로 몇 분이면 충분합니다. 우리는 10분으로 정했고, 문의 폼은 이 지점에서 너그러운 편입니다. 그렇게 가까운 간격의 진짜 두 번째 문의는 드물기 때문입니다.
지문은 방문자가 채운 항목에서만 뽑고 그 밖의 것에서는 뽑지 마세요. 요청 전체를 요약하고 싶어지는데, 그렇게 하면 이 장치 전체가 소리 없이 꺼집니다. 타임스탬프, 세션 토큰, 추적 파라미터는 보낼 때마다 달라지므로 모든 중복이 고유해 보이고 아무것도 걸리지 않습니다. 방문자가 입력을 마친 뒤 당신의 페이지가 제출에 덧붙이는 것에도 같은 주의가 필요합니다.
마지막으로, 버리는 중복을 소리 없이 흘려보내지 말고 세어 두세요. 중복을 걸러내는 엔드포인트와 망가진 전달 경로는 빈 편지함에서 보면 똑같아 보이는데, 둘 중 하나는 훨씬 급합니다. 문의가 아예 도착하지 않는 경우는 다른 조사이고, 내 수정이 메시지를 먹은 건 아닌지 고민하는 대신 이쪽을 빠르게 배제할 수 있어야 합니다.
자주 묻는 질문
- 첫 클릭 뒤 제출 버튼을 비활성화하면 해결되나요?
- 다섯 원인 중 하나가 해결되고, 그래도 할 가치는 있습니다. 그 원인이 가장 흔하고 변경도 사소하기 때문입니다. 누름이 접수되었다는 신호를 방문자에게 즉시 보여 주고, 요청이 오가는 동안에는 컨트롤을 비활성화하세요. 이것이 건드리지 못하는 것은 페이지 아래 계층에서 일어나는 재시도, 새로고침, 두 번째 처리기, 그리고 봇입니다. 그러니 이건 마감 손질로 두고 받는 쪽의 확인을 본 해법으로 삼으세요.
- 내용을 요약하는 대신 폼마다 고유 토큰을 써야 하나요?
- 양쪽 끝을 모두 통제한다면 그렇습니다. 그쪽이 더 강한 방식이고 결제 API가 하는 방식이기도 합니다. 보내는 쪽이 폼이 그려질 때 키를 하나 만들어 재시도마다 그대로 다시 쓰면, 받는 쪽은 추론이 아니라 정확하게 재시도임을 알아봅니다. 그런데도 내용으로 지문을 뽑는 이유는 보내는 쪽에 아무것도 요구하지 않기 때문입니다. 폼을 사이트 빌더나 생성 도구, 또는 통제할 수 없는 플러그인이 만들었을 때 이 차이가 드러납니다.
- 이미 쌓인 중복은 어떻게 정리하나요?
- 타임스탬프가 아니라 내용으로 묶고, 각 묶음에서 가장 오래된 것을 남기고, 무언가를 지우기 전에 표본을 읽어 보세요. 답이 없어 다시 연락한 경우라면 정말로 별개인 두 문의가 한 글자도 다르지 않을 수 있기 때문입니다. 사본이 메일로 편지함에 들어왔다면 같은 묶기가 거기서도 통하고, 내 답장이 그중 하나에만 갔는지 확인해 볼 가치가 있습니다. 엔드포인트를 먼저 고치세요. 그러지 않으면 다음 주에 이 작업을 또 하게 됩니다.