학술대회 당일 논문 심사 일정 운영에서 발생하는 심사위원 불참, 접속 장애, 노쇼, 집계 오류 등 장애 상황별 대응 절차를 시나리오로 정리했습니다. D-7 일정 확정부터 비상 연락망 구축까지 사무국이 미리 준비할 실전 가이드입니다.
- 결론 먼저: 심사 일정 장애 대응은 'D-7 확정 → 역할 지정 → 시나리오 매뉴얼' 3단계로 완성됩니다
- 준비물과 전제조건: D-7 심사 일정 확정부터 비상 연락망 구축까지
결론 먼저: 심사 일정 장애 대응은 'D-7 확정 → 역할 지정 → 시나리오 매뉴얼' 3단계로 완성됩니다
학회 사무국이 가장 혼란스러운 순간은 행사 당일 아침입니다. "심사위원님 연락이 안 됩니다"라는 보고가 들어왔을 때, 그 자리에서 누구에게 어떻게 연락할지 고민하기 시작하면 이미 늦었어요. 준비된 팀은 매뉴얼을 펴고, 준비 안 된 팀은 회의를 시작합니다.
판단이 아니라 '절차 진행'으로 바꾸는 3단계
1. D-7 심사 일정 확정 — 심사 배정과 발표 순서를 행사 7일 전까지 못 박고, 심사위원 전원에게 카카오 알림톡으로 공지합니다. e-Regi처럼 등록 완료·배지 발송·당일 안내를 알림톡으로 자동 발송하고 템플릿을 관리해주면, "연락 드렸는데 못 받으셨다"는 말다툼 자체가 사라집니다. 2. 장애 유형별 역할 지정 — 불참, 접속 장애, 집계 오류마다 담당자와 비상 연락망을 미리 정하고, 대체 심사위원 후보도 이때 확정해둡니다. 3. 시나리오 매뉴얼 작성 — 문제가 터졌을 때 고민이 아니라 "1번 케이스 → 2번 절차"로만 진행되게 만듭니다.
즉석 대응 vs 절차 대응
| 항목 | 즉석에서 판단할 때 | 절차로 진행할 때 |
|---|
| 심사위원 불참 | 개인 연락처를 하나씩 시도 | 템플릿 알림톡 일괄 발송 후 대체 위원
준비물과 전제조건: D-7 심사 일정 확정부터 비상 연락망 구축까지
심사 당일 아침 가장 자주 터지는 문제는 시스템 다운이 아니라 "그걸 누가 관리하기로 했더라? "입니다. 장애 대응은 당일에 만드는 게 아니라 D-7에 설계해두는 것이고, 판단 기준도 이때 정해둬야 합니다.
심사위원 불참은 대부분 일정을 잊거나 오해할 때 생깁니다. 그래서 공지를 두 번에 나눠 보냅니다. - D-7: 심사 배정 확정 공지 — 세션, 시간, 장소, 접속 방법을 한 템플릿에 담아 알림톡 대량 발송
- D-3: 재확인 공지 — 회신 요청을 붙여 불참 조기 감지
e-Regi처럼 등록·배지·당일 안내를 알림톡 템플릿으로 대량 발송하는 플랫폼이라면 심사위원 공지도 같은 채널로 관리할 수 있습니다. D-3에 회신이 없는 위원은 그날 전화까지 걸어두는 게 안전합니다.
"총괄에게 연락하세요"는 대응이 아닙니다. 장애 유형마다 첫 번째로 움직이는 사람이 달라야 합니다.
당일 장애 시나리오별 대응 절차: 심사위원 불참·접속 장애·노쇼·시간 초과
당일 아침 운영실을 흔드는 건 대개 시스템이 아니라 사람의 변수입니다. 심사위원 불참, 발표자 노쇼, 접속 오류는 예고 없이 오기 때문에, 유형별로 "현장에서 즉시 할 일"과 "행사 후에 마무리할 일"을 미리 나눠두는 게 대응의 절반입니다.
심사위원 당일 불참: 확정 명부가 기준
개회 직전 심사위원에게 연락이 닿지 않는 장면에서 먼저 볼 것은 확정 명부 기준 여부입니다. 발표 순서가 확정 명부로 굳어진 상태라면 순서를 함부로 바꾸기보다, 세션 간 심사위원 재배정으로 빈자리를 메우는 쪽이 안전합니다.
- 실시간 대시보드의 세션별 출결률을 보고 여유 있는 세션의 심사위원을 파악해 재배정합니다.
- 확정되면 카카오 알림톡으로 해당 발표자와 세션 진행자에게 변경 안내를 보냅니다.
접속 장애: 오프라인 채점표로 즉시 전환
관리자 페이지·심사 시스템에 접속이 안 되면 복구를 기다리지 말고 오프라인 채점표로 즉시 전환하세요. 판단 기준은 "복구 후 누가, 어떤 화면에 재입력할지"가 정해져 있는지입니다. 회수한 채점표는 사후 시스템 재입력 뒤 엑셀 보고서 내보내기 결과와 대조해 누락·이중 입력을 검증하면 됩니다.
점수 집계 오류 발견 시: 재집계 절차와 결과 발표 일정 조정 기준
발표 직전에 순위가 뒤집히거나, 심사위원별 점수를 더했는데 총점과 맞지 않는 순간이 온다. 이때 가장 위험한 반응은 "일단 다시 넣어보자"며 원본 위에 바로 재입력하는 것이다. 원본이 덮어쓰이면 무엇이 오류였는지 영원히 증명할 수 없다.
원본 확보 → 범위 특정 → 재집계, 순서를 지켜라
- 채점 원본(심사위원 제출분·입력 화면)을 별도 보관 후 수정 불가 상태로 잠그기
- 오류 범위 특정: 특정 심사위원 점수만 이상하면 입력 단계 오류, 전 논문·전 세션이 흔들리면 집계 설정 오류
- 시스템 재집계와 사람 손계산을 독립적으로 두 번 수행해 교차 검증
- 정정 전·후 점수를 나란히 기록해 변경 이력 남기기
범위를 먼저 좁히는 이유는 단순하다. 입력 오류인데 전체를 재집계하면 시간만 날리고, 집계 설정 오류인데 한 건만 고치면 같은 사고가 반복된다.
발표 일정, 순연할까 별도 공지할까
| 항목 | 발표 시점 순연 | 별도 정정 공지 |
|---|---|---|
| 오류 범위 | 전체 재집계 필요 | 일부 논문·소수 건 |
| 검증 상태 | 당일 내 교차 검증 불가 | 검증까지 완료 |
| 전달 방식 | 일정 재공지 후 재발표 | 해당 건만 정정 공지 |
장애 기록과 사후 보고서로 재발 방지하기: 사무국 체크리스트와 함께
장애가 터진 당일을 어떻게 기록하느냐가 다음 학술대회의 실력을 결정합니다. "그때 좀 헷갔었는데"라는 기억은 세 달 뒤면 흩어지지만, 시각과 소요시간이 적힌 기록은 그대로 개선 과제가 되니까요.
장애 기록은 행사 끝나고 몰아서 하면 안 됩니다. 정확도가 급격히 떨어지거든요. 장애가 인지된 순간 사무국 데스크에서 바로 적습니다. - [ ] 발생 시각 — 접수 데스크 시계 기준으로 통일
- 장애 유형 — 심사위원 불참 / 접속 장애 / 집계 오류 등으로 구분
- 조치 내용과 담당자 — 누가 무엇을 했는지
-
특히 소요시간이 중요합니다. "비상 연락망을 돌리는 데 20분이 걸렸다"는 기록이 쌓여야 연락 체계 개선이 예산과 우선순위를 갖는 개선 과제가 됩니다.
당일 기록을 모았다면 보고서에서는 원인을 유형별로 묶어 대책을 붙입니다.