설문·평가 수집 시스템에 장애가 발생했을 때 운영자가 수동으로 데이터를 수집하고 복구하는 절차를 단계별로 안내합니다. 장애 인지 체크리스트, 종이 설문지·구글폼 등 대체 수단 비교, 복구 후 데이터 일괄 입력과 정합성 검증까지 현장 대응 매뉴얼을 확인하세요.
- 장애 인지 후 30분, 운영자가 확인해야 할 우선순위 체크리스트
- 온라인 수집 불가 시 대체 수집 수단 비교: 종이 설문지 vs 구글폼 vs 이메일 vs 카카오톡
장애 인지 후 30분, 운영자가 확인해야 할 우선순위 체크리스트
세션장 입구에서 참석자 하나가 스마트폰을 들고 "설문 QR이 안 열리는데요"라고 물어오는 순간, 장애 대응이 시작된다. 이때 운영자가 흔히 저지르는 실수는 원인부터 캐묻는 것이다. 원인 규명보다 수집 연속성 확보가 먼저다. 원인은 나중에 밝혀도 되지만, 무응답으로 흘러간 참석자의 평가는 행사가 끝나면 되돌릴 수 없다.
1순위: 마지막 저장 시점부터 대조하라
관리자 페이지에 접속해 가장 마지막에 저장된 응답 시각을 먼저 확인한다. 실시간 관제 대시보드를 갖춘 플랫폼이라면 응답 수가 급감한 지점이 곧 장애 시작 시각이므로, 그 사이 구간에 제출됐을 응답이 유실됐는지부터 가른다.
- 마지막 응답 저장 시각 확인
- 관제 화면의 응답 수 급감 시각과 대조
- 유실 의심 구간의 세션·시간대 기록
2순위: 부분 장애와 전면 장애를 갈라라
범위에 따라 대응이 완전히 달라지므로, 이 분류가 30분 안의 가장 큰 의사결정이다.
| 항목 | 부분 장애 | 전면 장애 |
|---|---|---|
| 증상 | 특정 화면·일부 기기만 오류 | 접속 자체가 불가 |
| 대응 | 안정적인 대체 경로 안내 | 종이 설문·외부폼 전환 |
| 안내 수단 | 현장 안내 문구, 알림톡·SMS 즉시 발송 | 회복 전망 없으면 지체 없이 전환 |
온라인 수집 불가 시 대체 수집 수단 비교: 종이 설문지 vs 구글폼 vs 이메일 vs 카카오톡
장애가 났다는 건 알겠는데, 그 다음이 문제죠. "그래서 뭘로 설문을 받지? " — 이 질문에 답이 없으면 현장은 그대로 멈춥니다. 대체 수단은 네 가지가 있는데, 각각 강점과 부담이 확연히 다릅니다.
| 항목 | 종이 설문지 | 구글폼 등 외부 폼 | 이메일 | 카카오톡 |
|---|---|---|---|---|
| 준비 속도 | 인쇄 필요, 즉시 배포는 가능 | 스마트폰으로 즉시 구성 | 참석자 명단 있으면 즉시 | 즉시 발송 가능 |
| 네트워크 의존 | 없음 | 참석자 데이터 필수 | 참석자·운영자 모두 필요 | 참석자 데이터 필수 |
| 세션 중 실시간 수집 | 어려움(배부·회수 동선) | QR 안내와 조합 시 유리 | 부적합 | 가장 유리 |
| 사후 수집 | 부적합 | 링크 유통 가능 | 적합하나 응답률 낮음 | 가능 |
| 가장 큰 부담 | 입력 인력, 개인정보 보관 | 도메인·디자인 불일치로 신뢰도 하락 | 응답률 관리 | 개인정보 수집 동의 별도 필요 |
학술대회 현장에서는 조합이 답입니다
학술대회는 세션이 짧고 참석자 이동이 잦아서, 한 가지 수단으로 버티면 반드시 구멍이 생깁니다. 실무에서 검증된 조합은 두 가지입니다.
시스템 복구 후 수동 데이터 일괄 입력과 정합성 검증 표준 절차
시스템이 살아났다고 끝이 아니다. 복구 직후 접수대에는 종이 설문지 뭉치가 쌓여 있고, 임시로 열어둔 외부폼에는 응답이 흩어져 있다. 이 데이터를 어떤 순서로 옮기고 검증하느냐가 사후 리포트의 신뢰도를 갈라놓는다.
1단계 — 입력보다 원본 보관이 먼저다
종이는 스캔이나 사진으로, 외부폼은 응답 내보내기 파일을 수정 없이 원본 그대로 보관한다. 이후 모든 작업은 복사본으로 한다. 원본은 나중에 "입력이 누락됐다"는 이야기가 나올 때 유일한 판단 근거가 되기 때문이다.
2단계 — 장애 구간을 정의하고 중복을 대조한다
마지막 정상 저장 시점부터 복구 시점까지가 장애 구간이다. 이 구간에 시스템에 들어온 응답과 수동 수집분이 겹칠 수 있다. QR 체크인처럼 시스템이 중복 스캔을 알아서 막아주는 영역과 달리, 이 작업은 사람이 직접 해야 한다.
- 기준키는 응답 이메일, 등록번호, 휴대폰 번호 등 응답자 식별키 하나로 통일
- 동일 키가 양쪽에 있으면 응답 시각을 비교해 어느 쪽을 남길지 기록
| 중복 상황 | 판단 기준 | 처리 |
|---|---|---|
| 장애 구간 내 시스템 응답과 수동분 겹침 | 식별키 일치 | 한 건만 남기고 제거 |
| 종이와 외부폼에 같은 사람이 이중 제출 | 동일 식별키 | 최신 응답 우선, 제외 사유 기록 |
현장 운영 체크리스트와 개인정보 안전 보관·폐기: 흔한 실수 vs 권장 기준
장애가 났을 때 사고는 대부분 '수집'이 아니라 수집 이후에서 벌어진다. 부스 테이블 위에 쌓여 방치된 종이 설문지, 개인 카카오톡으로 흩어진 응답, 입력은 끝냈는데 원본이 어디 있는지 아무도 모르는 상태. 시스템이 복구돼도 원본의 위치와 처분 상태를 모르면 개인정보 관리는 끝난 게 아니다.
흔한 실수 vs 권장 기준
| 항목 | 흔한 실수 | 권장 기준 |
|---|---|---|
| 보관 | 종이 설문지를 부스에 방치 | 수집 즉시 잠금 보관함으로 이관 |
| 수집 채널 | 개인 이메일·개인 카카오톡으로 응답 수집 | 사무국 공용 계정으로만 수집 |
| 폐기 | 입력 후 원본을 분쇄 없이 그냥 폐기 | 시스템 반영 확인 후 파쇄 또는 개인정보파일 삭제 |
| 기록 | "다 폐기했어요" 구두 보고 | 폐기 시점과 방법을 대장에 기록 |
판단 기준은 하나로 충분하다. "시스템 반영이 확인되기 전까지는 폐기하지 않는다." 반대로 개인 계정에 이미 들어온 응답은 회수하는 즉시 해당 계정에서 삭제하고, 삭제 사실을 기록으로 남긴다.
수동 수집에도 법 요건은 그대로 적용된다
장애 경과 보고서 작성과 재발 방지: 매뉴얼화까지의 사후 프로세스
장애가 복구됐다고 끝이 아닙니다. 다음 학술대회에서 같은 일이 반복되지 않도록 하는 게 이 단계의 진짜 목적이에요. 현장을 치운 뒤 3일 안에, 기억이 생생할 때 보고서를 써두는 게 좋습니다.
보고서에 반드시 들어갈 다섯 가지
- 타임라인: 장애 발생 시각 → 인지 시각 → 수동 전환 시각 → 복구 완료 시각. 특히 '발생'과 '인지' 사이 공백이 얼마였는지가 핵심입니다. 이 간격이 길면 모니터링 문제, 짧으면 대응 절차 문제라는 식으로 원인의 방향이 좁혀져요.
- 원인 분류: 서버, 네트워크, 앱 오류 중 어디서 시작됐는지. "그냥 먹통이었다"가 아니라 어느 계층에서 끊겼는지 기록해야 재발 대책이 성립합니다.
- 데이터 규모: 유실된 응답 수, 수동(구글폼 등)으로 수집한 응답 수, 사후 병합 완료 수.
- 대응 기록: 누가 무엇을 했고 인력이 몇 명 들었는지. 다음 행사 인력 계획의 근거가 됩니다.
- 재발 방지 대책: 아래에서 이어서 다룹니다.