출입 통제 시스템 대량 업로드·일괄 수정 설계 가이드 5단계

왜 대량 등록에서 실패하는가: 문제 구조와 설계 전제조건

개막 전날 밤, 운영팀이 사전등록 엑셀 파일을 올리는 장면을 상상해 보세요. 진행 바만 빙글빙글 돌다가 에러가 뜨고, 다시 올려도 같은 자리에서 멈춥니다. 수천~수만 명 규모에서 이런 실패는 운이 나쁜 게 아니라 구조가 못 버티는 것입니다.

단발성 업로드가 무너지는 두 지점

• 한 번에 파싱 — 파일 전체를 메모리에 올려 한꺼번에 해석하니 요청이 타임아웃에 걸리기 쉽습니다.
• row별 단건 INSERT — 한 줄씩 DB에 반영하고 커밋을 반복하면, 통신 왕복이 인원 수만큼 쌓입니다.

그래서 판단 기준은 "얼마나 빠른가"가 아니라 "실패했을 때 어느 구간까지 반영됐는지 추적 가능한가"입니다. 청크 단위 파싱, DB 벌크 삽입, 배치 커밋은 이 질문에 답할 수 있게 해주는 세 가지 전제입니다.

1단계~3단계: 파일 검증과 대량 업로드 절차

1단계~3단계: 파일 검증과 대량 업로드 절차

수천 명, 수만 명의 출입 대상자 명단을 엑셀 하나로 등록하는 순간이 사실 행사 준비에서 가장 긴장되는 구간이에요. 여기서 한 번 꼬이면 QR 체크인 현장까지 그 오류가 그대로 전파되거든요. 그래서 첫 단계는 "빨리 넣는 것"이 아니라 저장하기 전에 걸러내는 것부터입니다.

업로드 파일을 시스템에 바로 반영하지 않고, 먼저 임시 검증 단계를 거치게 하는 구조입니다. 이때 체크하는 항목은 딱 세 가지로 압축돼요. - 중복 사번(고유 식별자) — 같은 사번이 두 줄 있으면 출입 기록이 뒤섞입니다

• 형식 오류 — 날짜, 전화번호, 사번 형식이 규칙에서 벗어난 행
• 필수값 누락 — 이름, 소속, 식별자처럼 없으면 입장 처리가 불가능한 칸

실제 운영에서 가장 자주 터지는 게 중복 사번이에요. 본사 명단과 지부 명단을 합치는 과정에서 같은 사람이 두 번 들어가는 경우가 많거든요. 이걸 저장 전에 잡느냐, 저장 후에 발견하느냐가 작업량을 몇 배 차이로 갈라놓습니다.

4단계: 일괄 수정의 트랜잭션·재개 설계와 동기화 방식

4단계: 일괄 수정의 트랜잭션·재개 설계와 동기화 방식

수천 명의 참가자 정보를 일괄 수정하다가 정전이나 네트워크 중단으로 작업이 끊겼다고 상상해 보세요. 진짜 문제는 중단 자체가 아니라 "어디까지 적용됐는지 아무도 모르는 상태"입니다. 3천 명 중 1,847번째에서 끊겼는지, 아니면 롤백도 안 된 채 절반만 반영됐는지 알 수 없으면 처음부터 다시 올리는 수밖에 없습니다.

청크 단위 커밋과 재개(이어하기) 설계

일괄 수정을 설계할 때 핵심은 두 가지 원칙입니다.

• 전체를 한 트랜잭션으로 묶지 않는다: 수만 건을 하나의 트랜잭션으로 처리하면 실패 시 전체 롤백 때문에 시간과 부하 모두 감당하기 어렵습니다.
• 청크(예: 수백~수천 건 단위)로 나눠 커밋한다: 각 청크가 성공할 때마다 "처리 완료 시점"을 기록해 두면, 중단 이후 마지막 커밋 지점부터 이어서 재개할 수 있습니다.

재개가 안전하려면 상태를 세 단계로 관리해야 합니다.

• 처리 대상 전체에 고유한 배치 작업 번호 부여
• 청크별 상태(대기·성공·실패) 기록
• 재실행 시 이미 성공한 청크는 건너뛰는 중복 실행 방지 로직 확인

5단계: 성능·보안 설계 — 인덱스, 메시지 큐, 감사 로그, 승인 워크플로우

수천 명 명단을 클릭 한 번에 바꾸는 순간, 가장 무서운 건 "잘못됐는데 되돌릴 수 없다"는 상황이에요. 성능과 보안은 나중에 붙이는 게 아니라, 업로드 설계 단계부터 같이 깔아야 합니다.

성능: 조회와 등록을 나눠라

현장에서 가장 먼저 느려지는 건 "참가자 검색"이에요. 접수대에서 이름을 찾는데 5초씩 걸리면 QR 체크인이 아무리 3초 입장을 지원해도 줄이 밀립니다. 그래서 이름·등록번호·소속 같은 검색 조건 컬럼에는 인덱스를 걸고, 등록(쓰기) 작업은 별도 트랜잭션·별도 큐로 분리하는 게 기본입니다.

• 참가자 검색용 인덱스(이름, 등록번호, QR 키) 우선 지정
• 대량 등록은 동기 요청이 아니라 메시지 큐로 비동기 처리 → 업로드 후 "처리 중" 상태 노출
• 진행률·성공/실패 건수를 관리자 화면에서 실시간 확인 가능하게

이 구조면 수만 건 업로드 중에도 접수대 조회는 멈추지 않습니다. e-Regi처럼 실시간 대시보드로 참가 현황을 라이브 모니터링하는 환경이라면, 업로드 진행 상황도 같은 화면에서 보이는 게 이상적이에요.

보안: 감사 로그는 "되돌리기"의 전제다

로깅 없는 직접 수정은 사고가 나면 원인도, 복구 지점도 못 찾습니다. 감사 로그 테이블은 최소 이렇게 남기세요.

요약 체크리스트와 검증된 용량 기준, 개발 파트너 선택

지금까지 살펴본 검증 단계를 사무국 회의에서 한 번에 훑을 수 있도록, 최종 점검표로 정리해둘게요. 엑셀 파일을 열기 전에 이 목록을 통과하지 못하면 뒤 단계로 넘어가지 않는 것이 원칙입니다.

사무국용 최종 체크리스트

• 사전 검증 리포트: 업로드 전 오류 행 미리 보기 — 전체 커밋 전에 실패 목록을 받아볼 수 있는가
• 청크 처리: 수만 건을 나눠 저장하고 중간 실패 시 나머지는 그대로 유지되는가
• 롤백·재개: 업로드 직전 상태로 되돌리거나, 실패 지점부터 다시 시작할 수 있는가
• 감사 로그: 누가, 언제, 어떤 필드를 바꿨는지 행 단위로 남는가
• 승인 단계: 일괄 수정이 즉시 반영되지 않고 담당자 확인 후 확정되는 흐름인가
• 동기화 방식 문서화: 등록·결제·출입 데이터가 어느 시점에 어떻게 맞춰지는지 문서 한 장으로 정리되어 있는가

이 여섯 가지는 앞서 설명한 5단계 각각의 '완료 조건'이기도 합니다. 하나라도 "그건 개발자한테 물어봐야 알아요"라는 답이 나오면, 그 단계는 아직 끝난 게 아니에요.

용량은 실적으로 확인하세요