참가자 등록 시스템 중복 데이터 검증 규칙 설계 가이드

중복 등록은 왜 생기는가 — 사전등록·현장등록·초록접수 폼이 갈라지는 지점

학회 당일 아침 가장 많이 벌어지는 장면이 이겁니다. 사전등록을 마친 참가자가 현장등록 데스크에 다시 줄을 서고, 안내 자원봉사자는 "이미 오셨는데요?"를 확인할 방법 없이 새로 접수합니다. 그 순간 한 사람이 두 개의 레코드로 쌓입니다. 초록접수까지 붙으면 세 개가 됩니다.

같은 사람, 세 개의 기록이 만들어지는 경로

문제는 담당자의 실수가 아니라 폼마다 입력 주체와 순간이 다르다는 점에 있습니다.

특히 한영 다국어로 폼이 운영되는 학회라면 소속 표기가 갈라지기 딱 좋습니다. 성균관대학교와 Sungkyunkwan University를 시스템은 다른 조직으로 봅니다.

판단 기준은 하나 — 폼이 DB를 공유하는가

1단계: 중복 판단 키 필드 선정 — 이메일·전화번호·이름+소속·회원증번호

접수 마감 전날 밤 명단을 정리하는데, 같은 사람이 두 줄로 들어와 있는 걸 발견한 적 있으신가요? 회사 이메일로 한 번, 개인 이메일로 한 번. 결제도 두 번, 명찰도 두 장이죠. 중복 등록 사고의 출발점은 대부분 "무엇을 같은 사람으로 볼 것인가"를 정하지 않은 것입니다.

키 필드 후보, 무엇이 다른가

| 휴대폰 번호 | 높음 | 하이

2단계: 클라이언트 검증과 서버 중복 검증의 역할 분리

"브라우저에서 이미 걸렀는데 왜 서버에서 또 검사하나요?" — 검증 설계를 처음 하는 분들이 가장 많이 묻는 질문입니다. 결론부터 말하면, 둘은 목적이 다른 검사이고, 이 둘을 하나로 뭉뚱그리는 순간 중복 등록이 새어 나가기 시작합니다.

브라우저 검증은 '참가자를 위한 것'

브라우저 측 유효성 검사는 이메일 형식이 맞는지, 소속기관·회원증번호 같은 필수값이 비어 있지 않은지를 입력 순간에 알려주는 역할입니다. 저장을 눌렀는데 서버에서 에러가 돌아오는 것보다, 입력 필드 바로 옆에서 "이메일 형식을 확인해 주세요"라고 알려주는 편이 참가자 경험은 훨씬 낫습니다.

다만 여기서 흔한 착각이 하나 있습니다. 브라우저 검증은 요청을 조작하면 우회할 수 있다는 점입니다. 개발자 도구로 스크립트만 돌리면 필수값 검사 없이 서버에 바로 등록 요청을 보낼 수 있어요. 그래서 이 단계는 어디까지나 UX용이고, 중복 차단의 최종 책임은 서버에 있어야 합니다.

3단계: 현장 등록·명찰(QR) 발급 전 중복 확인 흐름

현장 등록대는 중복 등록이 가장 자주 터지는 곳이에요. 사전등록을 깜빡하고 걸어 들어온 참가자, 동료 대신 등록해 준 사람, 이름을 달리 적은 사람까지 하루에 몇 건씩 생기거든요. 여기서 아무 대조 없이 새로 등록하고 QR을 발급해 버리면, 행사가 끝난 뒤 데이터 정리 단계에서 같은 사람이 두 레코드로 존재하게 됩니다.

조회 화면에서 무엇을 먼저 볼까

관리자가 현장에서 신규 등록 창을 열면, 이름 입력 전에 휴대폰 번호 조회가 먼저 떠야 합니다. 번호를 누르는 순간 시스템이 사전등록 DB를 대조해서 결과를 보여주는 흐름이죠.

• 조회 결과 없음 → 신규 등록 진행, QR·명찰 발급
• 기존 신청 건 존재 → 결제 상태, 발급 이력과 함께 팝업으로 안내
• 이름은 다른데 번호 동일 → 병합 처리 여부를 관리자가 선택

핵심은 "새로 만들기" 버튼이 항상 열려 있으면 안 된다는 점이에요. 기존 건이 조회되면 추가 등록(부속 행사 등)인지, 중복인지를 관리자가 판단하는 절차가 화면에 들어가 있어야 합니다. 회원 대상 행사라면 여기에 회원증번호 검증을 얹어, 학회 포털의 학회원 DB와 대조하는 방식도 쓸 수 있습니다. e-Regi가 등록·결제 단계에서 회원증번호 검증과 회원 등급별 요금 자동 계산을 처리하는 것과 같은 맥락이죠.

흔한 실수와 사후 병합, 그리고 운영 체크리스트

흔한 실수와 사후 병합, 그리고 운영 체크리스트

아무리 사전에 검증 규칙을 잘 세워도, 이미 중복 데이터가 쌓여 있는 상태에서 시스템을 시작하는 학회가 많습니다. 이럴 때 문제는 "중복이 있느냐"가 아니라 "어떤 레코드를 기준으로 남길 것이냐"입니다.

사후 병합, 무엇을 기준 레코드로 삼을까

병합의 기준은 의외로 단순합니다. 비즈니스 이력이 남은 레코드가 진짜입니다.

• 결제 이력이 있는 레코드: 사전등록만 하고 결제 안 한 건과 결제 완료된 건이 나뉘어 있으면 결제 완료건을 기준으로 삼습니다.
• 출석(QR 체크인) 기록이 있는 레코드: 참가자가 실제로 스캔을 통과한 쪽이 신원의 사실상 증거입니다. 특히 입·퇴장 시간이 자동 기록되는 구조라면, 그 시간 데이터까지 병합 대상에서 지켜야 합니다.
• 회원증번호가 검증된 레코드: 정회원·준회원·학생회원 등급별 요금이 회원증번호 검증으로 계산되는 구조라면, 검증을 통과한 쪽이 등급·요금 정보의 기준이 됩니다.

반대로 말하면, 결제도 출석도 없는 "사전등록만 하고 노쇼한 건"은 병합 후 보조 이력으로 남기거나 정리 대상이 됩니다.

가장 흔한 분리 실수: 사전등록 노쇼 vs 현장 등록