사내 설문 미응답 알림과 응답률 집계 시스템 구축 방법

사내 설문을 제출한 직원에게 독촉 메일이 가거나 응답률이 맞지 않는다면, 제출 로그를 사람 수로 세고 있지 않은지 확인해야 합니다. 설문 운영 시스템은 확정한 대상자 명단에서 최종 제출자를 한 번씩 세고, 미완료자 중 발송 가능한 사람만 알림 대상으로 골라야 합니다. 아래는 가상의 사내 설문을 위한 구축 예시이며 실제 고객 운영 자료가 아닙니다.

대상자 명단을 먼저 확정합니다

운영자는 설문 개설 화면에서 기간, 대상자, 제외 사유를 입력합니다. 이 예시에서는 접수 기간을 7일로 정하고 승인자가 명단을 확정한 뒤 초대 메일을 보냅니다. 중간 입사자를 넣거나 퇴사자를 빼는 변경은 사유와 승인 이력을 남기고, 변경 전후 대상자 수를 함께 표시하는 규칙을 둡니다. 7일은 법정 기준이 아닌 예시 운영값입니다.

실제 명단에는 설문 ID와 직원 ID 조합으로 고유 키를 두어 같은 직원을 중복 등록하지 않도록 설계합니다. 발송 실패자는 대상자에서 자동으로 빼지 않습니다. 주소 오류로 초대를 받지 못했어도 이번 설문의 대상 자격은 그대로입니다. 대시보드는 대상 인원, 최종 제출 인원, 발송 실패 인원을 나눠 보여줍니다. 담당자가 응답률을 높이려고 미응답자를 명단에서 지우는 변경도 승인 없이 허용하지 않습니다.

제출 기록 4건이 완료자 4명은 아닙니다

• E01~E05는 대상자이며 E06은 승인된 제외자입니다.
• E01의 최종 제출 이벤트가 재전송되어 2건 남았고 E02는 1건 제출했습니다.
• E03은 임시저장만 했고 E04는 기록이 없습니다. E05는 초대 발송에 실패했습니다.
• E06에도 최종 제출 기록이 있지만 이번 집계에서는 제외합니다.

최종 제출 이벤트만 세면 4건입니다. 중복을 제거해도 E01, E02, E06의 3명이 남습니다. 대상자 조건까지 적용해야 완료자는 2명, 응답률은 40.0%가 됩니다. 임시저장은 완료가 아니며, 미응답 표시만 보고 참여를 거부했다고 판단하지는 않습니다.

다음 SQL은 명단과 상태 기록만 만든 읽기 전용 예시입니다. check.sql로 저장하고 sqlite3 :memory: < check.sql로 실행합니다. SQLite 3.54.0에서 실제 결과를 확인했으며 업무 DB나 메일 발송 시스템에는 연결하지 않았습니다.

WITH roster(id, eligible, delivery) AS (
  VALUES ('E01',1,'OK'), ('E02',1,'OK'),
         ('E03',1,'OK'), ('E04',1,'OK'),
         ('E05',1,'FAIL'), ('E06',0,'OK')
), events(id, status) AS (
  VALUES ('E01','SUBMITTED'), ('E01','SUBMITTED'),
         ('E02','SUBMITTED'), ('E03','DRAFT'),
         ('E06','SUBMITTED')
), checked AS (
  SELECT r.*, EXISTS (
    SELECT 1 FROM events e
    WHERE e.id=r.id AND e.status='SUBMITTED'
  ) AS done
  FROM roster r WHERE eligible=1
)
SELECT COUNT(*) AS eligible,
       COALESCE(SUM(done),0) AS completed,
       ROUND(100.0*SUM(done)/NULLIF(COUNT(*),0),1) AS rate,
       COUNT(CASE WHEN done=0 AND delivery='OK'
                  THEN 1 END) AS remind,
       COUNT(CASE WHEN done=0 AND delivery='FAIL'
                  THEN 1 END) AS delivery_check
FROM checked;

열 순서는 대상자 수, 완료자 수, 응답률, 알림 후보 수, 발송 점검 인원입니다. 실행 결과는 5|2|40.0|2|1입니다. E03과 E04는 알림 후보, E05는 주소와 발송 상태를 먼저 확인할 대상입니다. EXISTS는 최종 제출 기록의 존재만 확인하므로 E01을 두 번 세지 않습니다. COUNT와 SUM의 집계 동작은 SQLite 공식 문서에서 확인할 수 있습니다.[1]

알림 승인 뒤에도 제출 상태를 다시 확인합니다

운영 화면에서는 알림 후보 명단과 발송 보류 사유를 미리 보여주고 승인자가 발송을 확정하도록 설계합니다. 발송 작업은 실제 전송 직전에 제출 여부와 설문 마감 여부를 다시 검사해야 합니다. 승인 대기 중 설문을 마친 직원에게 이전 명단 그대로 메일을 보내는 일을 막으려는 절차입니다. 같은 설문·대상자·알림 회차는 한 번만 처리하도록 발송 이력의 중복 방지도 별도로 구현합니다.

E05의 주소를 고친 뒤 재발송이 성공했다고 가정해 첫 번째 FAIL 값만 OK로 바꾸면 결과는 5|2|40.0|3|0이 됩니다. 알림 후보는 늘지만 완료자는 그대로입니다. 이 수정 실험은 발송 상태에 따른 분류만 확인하며 실제 메일 수신이나 설문 제출을 증명하지 않습니다. 후보 수가 곧 발송 성공 건수도 아닙니다.

대상자가 없는 경우도 구분합니다. 예제의 WHERE eligible=1을 WHERE eligible=2로 바꾸면 0|0||0|0이 나오고 응답률은 NULL입니다. 화면에는 0% 대신 대상자 없음으로 표시하는 편이 명확합니다. 이 예시는 제출 취소가 없다는 조건입니다. 취소나 재개를 허용하는 서비스라면 과거 제출의 존재만 보지 말고 현재 유효한 완료 상태를 조회해야 합니다.

참여 여부와 답변 열람 권한은 분리합니다

이 예시의 집계 테이블에는 답변 점수나 서술 내용을 넣지 않았습니다. 운영 담당자는 참여 상태와 연락처만, 결과 분석 담당자는 허용된 결과만 보도록 권한을 나누는 설계를 제안합니다. 다만 테이블을 나누거나 화면에서 이름을 숨겼다는 이유만으로 익명 설문이라고 안내하지는 않습니다. 연결 가능한 식별자와 로그까지 따져야 하며 익명과 비밀보장의 차이는 Qualtrics의 설명도 참고할 수 있습니다.[2]

구축 범위는 대상자 승인, 제출 완료 판정, 발송 직전 재검사, 결과 열람 권한으로 나눠 합의하면 됩니다. 부분 응답과 무응답을 구별하는 알림 운영 사례는 SurveyMonkey 안내에서 확인할 수 있습니다.[4] 위 SQL은 집계 기준을 시험한 것이며 인증, 동시 제출 처리, 메일 발송, 익명성을 구현하거나 검증한 코드는 아닙니다.

확인 자료

[1] SQLite 집계 함수
[2] Qualtrics 익명·비밀보장 설문 구분
[4] SurveyMonkey 알림 메일 안내

업무 시스템 개발 안내는 softmoa.com에서 확인할 수 있습니다.

소프트모아는 해당 시스템을 구축합니다. 문의하기