설문 평가 수집 시스템 개발 시 담당자가 바뀌어도 끊기지 않는 인수인계 구조를 설계하는 방법을 소개합니다. 계정·서버·DB 소유권 정리, 인수인계 문서 필수 항목, 외부 폼 서비스와 자체 개발 비교까지 실무 관점으로 정리했습니다.
- 왜 설문·평가 시스템은 담당자 교체에 취약한가 — 문제 진단과 설계 원칙
- 인수인계 문서에 반드시 들어갈 5가지 — 계정·서버·DB·배포·담당자
왜 설문·평가 시스템은 담당자 교체에 취약한가 — 문제 진단과 설계 원칙
많은 조직에서 설문·평가 시스템은 이렇게 무너집니다. 담당자 한 명이 퇴사했는데, 그 사람의 개인 계정으로 만든 설문 페이지에 아무도 접근하지 못하는 겁니다. 서버 관리자 권한도, 응답 데이터 원본도, 설문 수정 권한도 전부 그 사람 안에 묻혀버리죠. 새 담당자는 응답자 명단조차 못 꺼내서, 기존 데이터를 포기하고 처음부터 다시 만드는 상황까지 생깁니다.
문제의 본질: 시스템이 아니라 '사람'에 종속된 구조
흔한 실패 패턴을 정리하면 이렇습니다.
| 항목 | 사람에게 종속된 구조 | 조직에 귀속된 구조 |
|---|---|---|
| 설문 생성·수정 | 담당자 개인 계정에서만 가능 | 관리자 페이지에서 역할 기반으로 접근 |
| 응답 데이터 | 개인 계정·개인 서버에 저장 | 조직 계정으로 통합 보관, 엑셀 내보내기 |
| 운영 노하우 | 담당자 머리·개인 메모 | 시스템 안 매뉴얼로 저장 |
| 담당자 교체 시 | 접근 단절, 사실상 재구축 | 권한만 넘기면 즉시 인수인계 |
즉, 문제는 담당자가 실수해서가 아니라 시스템 설계 단계에서 인수인계를 고려하지 않은 것입니다.
###
인수인계 문서에 반드시 들어갈 5가지 — 계정·서버·DB·배포·담당자
인수인계 문서를 작성할 때 가장 흔한 실수는 "화면 캡처와 매뉴얼"만 넘기는 겁니다. 매뉴얼은 시스템을 어떻게 쓰는지를 알려주지만, 인수인계 문서가 진짜 답해야 할 질문은 따로 있습니다. "이 시스템의 각 요소를 지금 누가 소유하고 있는가?" — 이걸 조직 명의로 다시 정리해두지 않으면, 담당자가 퇴사하는 순간 로그인도, 결제 조회도, 데이터 백업도 안 되는 상황이 벌어집니다.
다섯 가지 항목을 하나씩 짚어볼게요.
1. 계정 — 소유자 이메일이 곧 생명선
- 도메인 등록 정보 (등록처, 만료일, 소유자 이메일이 개인이 아닌 조직 명의인지)
- 호스팅·SSL 인증서 만료일과 갱신 담당
- 결제 PG사 계정 (정산 조회, 환불 처리 권한이 누구에게 있는지)
- 문자·이메일 발송 API 키와 잔여 발송량 확인 방법
특히 API 키는 담당자 개인 계정에서 발급된 경우가 많아서, 사람이 바뀌면 키가 만료되거나 재발급 절차 자체를 아무도 모르게 됩니다. 소유자 이메일을 공용 계정(예: admin@ 조직 도메인)으로 이전해두는 게 첫 단계입니다.
2. 서버 — SaaS인지, 자체 서버인지에 따라 문서가 완전히 달라짐
외부 폼 서비스 vs 자체 개발 — 인수인계 관점 비교표
전임자가 퇴사하고 가장 먼저 듣는 질문이 "작년 만족도 조사, 어느 계정에 있죠?"라면 인수인계는 이미 반쯤 꼬인 상태다. 구글폼·네이버폼은 폼 하나 띄우기는 쉽지만, 소유권이 담당자 개인 계정에 묶여 있어 사람이 바뀌는 순간 접근 자체가 막히기 때문이다.
인수인계 관점에서 본 두 선택지
| 항목 | 구글폼·네이버폼 | 자체 개발·통합 플랫폼 |
|---|---|---|
| 계정 소유 | 담당자 개인 계정에 귀속 | 조직 관리자가 권한을 부여·회수 |
| 데이터 이전 | 응답 시트 공유를 넘겨받는 방식, 누락 위험 | DB 단위 인계, 행사 종료 후 엑셀 보고서로 일괄 내보내기 |
| 기능 확장 | 만족도 조사 수준에서 확장이 멈춤 | 사전등록·결제·QR 출결·평점 집계와 데이터 연동 |
| 통계 재사용 | 행사마다 폼을 처음부터 다시 만듦 | 올해 설정을 템플릿처럼 복제해 다음 행사에 재사용 |
판단 기준: 설문이 '혼자 쓰이는가, 연결되어야 하는가'
결국 기준은 하나다. 설문이 만족도 조사 하나로 끝나는지, 아니면 결제·출결·평점과 묶여야 하는지.
데이터 백업 주기·인계 절차와 다음 연도 재사용을 위한 템플릿화 설계
"작년 만족도 설문 응답 원본, 어디서 볼 수 있을까요?" 인계 첫 미팅에서 이 질문에 바로 답하지 못하면 인계는 이미 반쯤 실패한 상태입니다. 데이터가 클라우드에 살아 있어도 백업본과 접근 권한이 함께 넘어가지 않으면, 새 담당자에겐 없는 데이터나 다름없습니다.
백업은 '행사 중'과 '종료 후'로 나눠 설계한다
실시간 대시보드로 참가 현황·세션별 출결률·결제 통계를 라이브 모니터링하는 기간엔 데이터
인수인계 실패 사례로 보는 운영 매뉴얼 작성법과 최종 체크리스트
인수인계가 무너지는 순간은 대부분 비슷합니다. 담당자가 퇴사한 뒤 개인 계정으로 만든 설문 폼에 접근할 수 없어 소유권 분쟁이 벌어지거나, 배포 구조를 개발 업체만 알아서 수정 요청 하나에 며칠씩 걸리거나, "물어보면 알려줄게"라는 구두 인수인계만 하고 떠나는 경우죠. 시스템이 아니라 사람 머릿속에만 존재하는 운영 노하우가 문제입니다.
실패 유형별 원인과 예방책
| 항목 | 흔한 실패 | 예방 기준 |
|---|---|---|
| 폼·계정 소유권 | 개인 계정으로 폼 생성 | 단체·회사 계정으로만 생성, 관리자 2인 이상 |
| 배포 구조 | 업체만 아는 설정 | 화면 캡처 포함 매뉴얼 사내 보관 |
| 인수인계 방식 | 구두 전달만 | 문서 기반 태스크 목록 체크리스트 |
운영 매뉴얼에 반드시 들어갈 것
매뉴얼은 예쁘게 쓸 필요가 없습니다. 새 담당자가 혼자 따라 할 수 있는가가 유일한 기준이에요.
- 설문 생성부터 배포까지 단계별 절차 + 해당 화면 캡처
- 관리자 계정 목록과 권한 등급, 소유권 이전 절차
- 수집 데이터 조회·다운로드·삭제 위치와 개인정보 처리 기준
- 장애·오류 시 1차 대응 순서와 업체 연락 채널
-