인증서 발급 시스템 개발 시 참가자·수료자 중복 등록을 방지하는 검증 규칙 설계 방법을 소개합니다. 유니크 키 선정, 개인 식별자 조합 검증, 엑셀 일괄 등록 전 사전 검증과 오류 리포트 구현까지 실무 기준을 정리했습니다.
- 중복 방지 검증 규칙, 왜 인증서 발급 시스템의 핵심인가
- 개인 식별자 조합과 유니크 키·복합 유니크 인덱스 설계 기준
중복 방지 검증 규칙, 왜 인증서 발급 시스템의 핵심인가

인증서 발급 직전, 명단에 같은 이름이 두 줄 보이는 순간이 문제의 시작입니다. 이름만 같은 다른 사람인지, 한 사람이 이중 등록한 건지 구분하지 못하면 잘못된 인증서가 나가고, 보수교육 평점과 수료 이력까지 함께 오염됩니다. 되돌리려면 발급 취소부터 이력 정정까지 손이 여러 번 갑니다.
이름만 같은 참가자 vs 실제 중복 등록
| 항목 | 이름만 같은 참가자 | 실제 중복 등록 |
|---|---|---|
| 회원증번호 | 서로 다른 번호 | 동일하거나 한쪽이 공백 |
| 회원 유형(정회원·준회원·학생회원) | 유형·소속이 다름 | 유형·소속까지 일치 |
| 이메일+전화번호+수강번호 조합 | 하나 이상이 다름 | 전부 일치하거나 일부만 다름 |
이 표를 사람 눈으로 하나하나 대조하면 규모가 클수록 반드시 놓칩니다. 그래서 식별 기준을 시스템 규칙으로 심는 것이 핵심입니다.
- 회원증번호 + 회원 유형 검증: 등록 단계에서 정회원·준회원·학생회원 구분과 회원증번호 유효성을 확인
- 개인 식별자 조합 매칭: 이름 단독이 아니라 이메일·전화번호·수강번호를 묶어 판단
- 실시간 차단 구조: e-Regi가 동일 QR 재사용을 실시간으로 차단하듯, 중복 신호가 생기는 순간 시스템이 걸러내는 방식
개인 식별자 조합과 유니크 키·복합 유니크 인덱스 설계 기준

현장에서 가장 잦은 사고는 "같은 사람이 발급 목록에 두 줄로 존재하는" 상황이다. 접수대에서 이름 검색으로 등록하고, 온라인 예약에서 이메일로 또 등록하면 시스템은 이 둘을 전혀 다른 사람으로 본다. 인증서 이중 발급, 이수 기록이 갈라지는 문제는 대부분 이 지점에서 시작된다.
입장 게이트에서 동일 QR 재사용을 실시간 차단해 부정 입장을 원천 방지하는 e-Regi의 방식과 같은 원리가 등록 단계에도 필요하다. 유니크 제약이 걸려 있으면 중복 레코드 자체가 만들어지지 않는다.
유니크 키 필드는 '검증되고 잘 바뀌지 않는 값'으로 고른다
- 이메일: 거의 항상 수집되지만, 공유 메일과 재입력 오타 리스크가 있다.
- 전화번호: 가족이 한 번호를 함께 쓰면 식별자로는 부적합하다.
- 수강번호: 기관이 부여한 값이라 안정적이지만, 발급 시점 이전에는 존재하지 않는다.
- 회원증번호: 정회원·준회원·학생회원 구분과 함께 검증을 거치는 값이라 가장 강력한 후보다.
판단 기준은 하나다. "이 필드가 이 사람을 시스템 어디에서나 한결같이 가리키는가." 알림 발송에 쓰이고 검증 절차를 통과하는 값일수록 좋은 유니크 키다.
엑셀 일괄 등록 전 중복 행 사전 검증 절차와 오류 리포트 구현

발급 명단 엑셀을 올리고 "전체 반영"을 누르는 그 버튼이 사고의 시작일 수 있다. 발급 데스크에서 "증명서가 두 장 나왔는데요"라는 문의가 들어올 때쯤이면 중복 행은 이미 시스템 안에 들어간 뒤고, 되돌리는 작업은 전부 사람 몫이 된다. e-Regi가 동일 QR 재사용을 실시간으로 차단하는 것도 같은 이유다. 사후 정리보다 입구 차단이 늘 싸다.
반영 전 5단계 사전 검증 절차
1. 형식 검증 — 회원증번호 형식, 회원 유형(정회원·준회원·학생회원) 컬럼 누락 확인 2. 파일 내 중복 탐지 — 같은 번호가 엑셀 안에 두 번 이상 존재하는지 3. 기존 DB 대조 — 이미 등록·발급 이력이 있는 번호인지 4. 오류 리포트 산출 — 걸러진 행만 별도 추출 5. 확정 반영 — 통과분만 일괄 처리
오류 리포트에 들어갈 최소 항목
"오류 있음" 한 줄로는 현장에서 못 쓴다. 최소 세 가지가 함께 나와야 담당자가 바로 손볼 수 있다.
- 행 번호 — 엑셀에서 몇 번째 줄인지
- 중복 사유 — 파일 내 중복 / 기존 DB 중복 / 형식 오류
- 유형 구분 — 수정 대상, 삭제 대상, 재발급 대상
사전 검증 없을 때 vs 적용했을 때
| 항목 | 사전 검증 없음 | 사전 검증 적용 |
|---|
동일인의 정당한 복수 인증서 예외 처리와 발급 결과 중복 방지

"한 사람 = 인증서 한 개"로 설계했다가 낭패 보는 경우가 의외로 많습니다. 학술대회에서는 한 참가자가 학회 참가 인증서, 보수교육 이수증, 워크숍 수료증을 동시에 받는 게 정상이거든요. 즉 참가자는 중복이 아니지만 인증서는 1:N 구조로 여러 개를 가질 수 있어야 하고, 중복 방지의 기준을 "사람"이 아니라 "인증서 발급 건"에 두는 것이 설계의 출발점입니다.
1:N 구조에서 "진짜 중복"의 정의
이 구조에서 막아야 할 중복은 두 가지로 나뉩니다.
- 정당한 발급: 참가자가 조건을 충족한 서로 다른 인증서를 보유 (예: 학회 참가 + 보수교육 이수)
- 부정 중복: 같은 인증서를 같은 사람에게 여러 번 발급, 또는 조건 미충족자 발급
판단 기준은 단순합니다. "이 발급 건이 고유한 인증번호를 가지는가"입니다. e-Regi가 회원 등록 시 정회원·준회원·학생회원을 구분하고 회원증번호를 검증하는 것처럼, 발급 전에 소속 등급과 회원증번호 같은 식별 정보를 먼저 검증한 뒤 인증번호를 유니크하게 부여하면, 정당한 복수 발급은 살리고 부정 중복은 걸러낼 수 있습니다.
QR 중복 스캔, 실시간 차단이 핵심
기존 시스템의 중복 데이터 탐지·병합·정리 프로세스와 최종 체크리스트

수료자 명단을 정리하다 같은 사람이 두 줄로 올라와 있고, 인증서까지 두 장 발급된 걸 발견한 순간이 정리의 시작입니다. 이때 감으로 한 줄 지워버리면 나중에 큰일 납니다. 탐지 → 병합 검토 → 이력 보존 병합 → 재발급·폐기 순서를 지켜야 합니다.
1단계: 탐지 — 유사도 스캔
먼저 '동일인 판별 키'를 정합니다. 성명 단독은 동명이인 때문에 위험하고, 회원증번호·생년월일·이메일 조합이 기준이 됩니다. e-Regi처럼 회원 등록 시점에 회원증번호 검증을 하면 중복이 원천적으로 줄지만, 이미 쌓인 데이터는 전수 스캔이 필요합니다.
- 완전 일치: 키 조합이 동일한 레코드
- 부분 일치: 성명 같음, 번호·이메일 다름
- 의심 그룹: 번호 같음, 성명 다름(오타·개명)
2~3단계: 병합 후보 검토 → 이력 보존하며 병합
| 항목 | 흔한 실수 | 권장 기준 |
|---|---|---|
| 병합 판단 | 성명만 보고 자동 병합 | 복합 키 + 사람 최종 확인 |
| 수료 이력 | 레코드 삭제와 함께 소실 | 병합 이력 보존 후 통합 |
|