학술대회 초록 접수 시스템 장애 발생 시 사무국이 수동으로 초록을 접수하고 복구·중복 검증까지 처리하는 절차를 단계별로 정리했습니다. 장애 판별 기준, 대체 채널 선택, 접수 인정 기준 안내입니다.
- 1단계: 장애 감지와 접수자 대상 공지, 그리고 접수 기준일시 인정 원칙 먼저 정하기
- 2단계: 대체 접수 채널 선택과 운영 — 이메일·구글폼 장단점 비교
1단계: 장애 감지와 접수자 대상 공지, 그리고 접수 기준일시 인정 원칙 먼저 정하기
초록 마감일 오후, 접수 페이지가 먹통이었다는 문의전화가 사무국에 몰려오는 순간이 사실상 장애 대응의 시작입니다. 문제는 이때부터입니다. "접수가 됐는데 안 된 것 같다", "결제는 했는데 확인 메일이 안 온다"는 문의가 섞이면서 뭐가 진짜 장애인지부터 가려야 하니까요.
장애인지, 개인 오류인지 먼저 판별하세요
- 사무국 담당자가 직접 접속 테스트(PC·모바일·외부 네트워크 각각)를 해서 동일 증상이 재현되는지 확인합니다.
- 같은 문의가 정해진 임계값(예: 동일 증상 문의 일정 건수 도달)을 넘으면 개인 문제가 아닌 시스템 장애로 분류합니다.
- 결제 미응답, 메일 발송 실패, 접수 완료 페이지 무반응 등 증상 유형별로 구분해 기록해두면 복구 후 중복 검증 때 그대로 씁니다.
참고로 대규모 접수 인프라에서는 실시간 관제, 매크로 방지, CAPTCHA, 알림톡이 세트로 갖춰지는 이유가 바로 이런 순간 때문입니다. 이중 하나라도 죽으면 접수 폭주와 장애가 동시에 터지거든요. 클라우드 SaaS 형태의 통합 플랫폼(e-Regi는 99.9% 가동률 표방)을 쓰더라도, 사무국이 감지 기준을 문서로 갖고 있지 않으면 대응은 늦어집니다.
2단계: 대체 접수 채널 선택과 운영 — 이메일·구글폼 장단점 비교
다. "지금부터 초록을 어디로 받을 것인가." 이 순간부터 선택한 채널이 곧 시스템이다. 마감 두세 시간 전 몰려드는 발표자들의 메일과 파일을 감당할 구조인지, 그 자리에서 따져봐야 한다.
채널별 장단점 비교
| 항목 | 전용 이메일 | 구글폼 | 임시 업로드 드라이브 |
|---|---|---|---|
| 파일 원본 보존 | 첨부 원본 그대로 보관 | 폼 첨부 형태로 보관 | 원본 그대로 보관 |
| 메타데이터 입력 | 자유 기입이라 누락 잦음 | 저자·소속·발표 형식 필수 입력 강제 가능 | 별도 안내 없으면 미입력 |
| 주요 리스크 | 첨부 용량 초과, 메일 누락 | 파일 용량 제한으로 첨부 거부 | 링크 유출 시 개인정보 노출 |
| 사무국 작업 | 수신 확인을 건별 회신 | 응답 시트에서 한눈에 집계 | 업로드 목록과 신청자 수기 대조 |
정리하면 이렇다. 파일 무결성이 최우선이면 이메일, 입력 누락을 막고 싶으면 구글폼, 속도가 급하면 드라이브. 단일 채널에 올인하지 말고 주 채널 하나와 백업 채널 하나를 공지에 함께 적는 것이 안전하다.
접수 인정 기준을 공지에 못 박는다
3단계: 수동 접수 초록 정리 — 파일명 규칙과 메타데이터 양식 표준화
3단계: 수동 접수 초록 정리 — 파일명 규칙과 메타데이터 양식 표준화
시스템이 복구된 뒤 가장 큰 골칫거리는 "이메일로 흩어진 초록을 어떻게 시스템에 다시 넣느냐"입니다. 이때 손이 많이 가는 건 초록 내용 자체가 아니라 파일과 데이터가 제각각인 상태예요. 파일명이 "최종본_진짜최종. hwp"로 도착하고, 연락처가 메일 본문 어딘가에 묻혀 있으면, 복구 후 등록 작업이 며칠 단위로 늘어납니다. 그래서 수동 접수를 시작하기 전에 두 가지 규칙을 먼저 못 박아두세요.
수동 접수 건은 아래 형식으로 통일합니다. `` 접수일시_접수번호_제1저자_발표형식 예) _M-0031_김OO_구두 ``
왜 파일명까지 규칙을 정하냐면, 나중에 일괄 등록·심사 위원 배정·이중 확인 단계에서 파일만 열어봐도 어떤 접수인지 식별되어야 하기 때문입니다. 메타데이터 목록과 파일 폴더를 번갈아 왔다 갔다 하는 시간이 사라져요.
수동 접수 대장은 시스템 복구 후 일괄 등록을 전제로 설계해야 합니다. 즉, 시스템의 데이터 항목과 같은 컬럼 구조로 만들어두면 복구 후 복사·붙여넣기만으로 등록이 끝납니다.
4단계: 시스템 복구 후 일괄 등록과 중복 접수 검증, 마감 연장 및 심사 일정 영향 관리
4단계: 시스템 복구 후 일괄 등록과 중복 접수 검증, 마감 연장 및 심사 일정 영향 관리
"시스템이 살아났으니 끝났다"고 안심하면 안 되는 순간이 바로 여기입니다. 복구 직후에 가장 많이 터지는 사고는 중복 접수 미검증이에요. 장애 때 수동으로 받은 초록과, 시스템이 죽기 직전에 이미 접수된 초록이 겹치는 경우가 생기거든요. 심사 배정이 시작된 뒤에 중복이 발견되면 심사위원에게 같은 논문이 두 번 가고, 접수번호가 뒤엉키면서 사후 정리가 훨씬 고생스러워집니다.
복구 후 검증 순서
- 장애 직전 시스템 접수 목록 백업 확보 — 시스템이 멈춘 시점 기준으로 이미 들어와 있던 접수 내역을 먼저 확정합니다. 이 목록이 없으면 대조 자체가 불가능해요.
- 수동 접수 목록과 대조 — 교신저자 성명과 논문 제목을 기준으로 양쪽 목록을 겹쳐 보고, 같은 건이 두 곳에 있으면 시스템 접수 또는 수동 접수 중 하나만 남기고 제거합니다.
- 일괄 등록 후 접수 확인 메일 재발송 — 수동으로만 받은 건을 시스템에 일괄 등록하고, 모든 저자에게 접수 완료 메일을 다시 보내 "내 초록이 정상 접수됐다"는 확신을 줍니다.
- 접수번호 최종 확정 통지 — 중복 제거가 끝난 뒤 접수번호를 확정하고 별도 통지로 마무리합니다. 저자 입장에서는 이 통지가 진짜 "접수 끝" 신호예요.
5단계: 재발 방지 — 장애 원인 분석과 비상 대응 매뉴얼 표준화, 체크리스트 총정리
5단계: 재발 방지 — 장애 원인 분석과 비상 대응 매뉴얼 표준화, 체크리스트 총정리
장애가 끝난 뒤 가장 아까운 순간은 "그때 뭐 했더라?" 하고 아무도 기억하지 못할 때입니다. 그래서 마지막 단계는 감정 정리가 아니라 기록의 표준화입니다.
원인 분석, 양식부터 만들어 두세요
장애 직후에는 시간 감각이 흐트러져 있어서 구두로 공유하면 반드시 유실됩니다. 아래 다섯 칸짜리 양식을 사무국 공유 문서에 미리 만들어 두세요.
- 발생 시각: 최초 감지 시점과 접수 마감 임박 여부
- 증상: 오류 화면, 응답 없음, 결제 오류 등 참가자가 겪은 그대로
- 원인: 서버, 네트워크, 트래픽 집중, 설정 오류 등
- 조치: 수동 접수 전환, 복구 작업, 공지 발송 내용
- 소요 시간: 감지부터 복구 등록 완료까지
이 기록이 쌓이면 다음 대회에서 "접수 마감 2시간 전에는 담당자를 상시 대기시킨다" 같은 구체적인 운영 규칙이 나옵니다. 막연히 "조심하자"가 아니라요.