77. 사용자 만족도 조사 결과 분석 및 개선 조치 (운영 감리)
⚠️ 이 문서는 시스템 오픈 직후 개발팀과 발주처가 자기들끼리 샴페인을 터뜨리며 "버그 0개, 성공적 오픈!"이라고 자화자찬하는 우물 안 개구리식 평가를 철저히 박살 내고, 실제로 그 시스템을 매일 8시간씩 두드려야 하는 말단 공무원이나 현업 부서 직원(End-User)들에게 직접 설문지를 돌려 "진짜 쓸만한가요?"를 묻고, 그 뼈 때리는 불만들을 모아 시스템을 뜯어고치도록 강제하는 '사용자 만족도 조사(CSAT) 기반 개선 조치' 감리 지침을 다룹니다.
핵심 인사이트 (3줄 요약)
- 본질: 기계(서버)가 안 뻗고 잘 돌아간다고 끝이 아니다. 사용자가 화면 UI가 너무 복잡해서 결재 버튼을 찾지 못하거나 속도가 느려 엑셀을 쓰는 게 낫다고 느끼면 그 IT 프로젝트는 수백억 원짜리 실패작이다. 감리인은 이 정성적 분노를 정량적 수치로 번역하여 들이민다.
- 가치: 개발사(SI)가 철수하기 전 마지막 꼬투리를 잡는 핵심 근거 자료다. 만족도 조사에서 5점 만점에 3점 이하가 나온 화면/기능에 대해서는, 감리인이 이를 '보완 요망 결함'으로 잡아 개발사가 억지로라도 화면을 뜯어고치고 나가게 만드는 법적 족쇄 역할을 한다.
- 기술 체계: 단순히 "좋아요/싫어요"를 묻는 게 아니라, 시스템의 기능성(원하는 게 있나), 사용성(UI가 편한가), 응답성(클릭하면 바로 뜨나), 신뢰성(오류 안 나나) 등 소프트웨어 품질 표준(ISO 25010)에 기반한 객관적 지표 설문과 이를 반영한 후속 개선 조치(Action Item) 매트릭스가 핵심 산출물이다.
Ⅰ. 우리끼리 파티의 함정과 현장의 분노 (침묵하는 다수)
서버 CPU가 쾌적하다고 사용자의 속도 쾌적한 것은 아니다.
- UAT(사용자 인수 테스트)의 기만성:
- 오픈 전 현업 부서 부장님 한 분을 모셔다 대충 화면을 보여주고 사인받는 UAT는 실제 1,000명의 말단 직원이 겪을 지옥을 대변하지 못한다.
- 오픈 후 현장 직원들은 "결재 한 번 올리는 데 화면을 5번 넘겨야 한다", "버튼이 화면 바깥에 숨어있다"라며 욕을 하지만, 정식으로 콜센터(서비스 데스크)에 항의하기 귀찮아서 그냥 시스템을 안 쓰고 옛날 수기 엑셀 장부를 쓰는 끔찍한 섀도우 IT(Shadow IT) 현상이 발생한다.
- 사용자 만족도 조사의 강제성:
- 감리인은 시스템 오픈 1~2주 차 안정화 기간에, 개발사와 발주처를 협박하여 전체 시스템 사용자의 최소 10~20% 이상의 표본에게 시스템 팝업창이나 이메일로 끈질기게 설문조사를 돌려 민심(Raw Data)을 수집하도록 명령한다.
📢 섹션 요약 비유: 셰프(개발자)와 식당 사장(발주처)이 자기들끼리 주방에서 요리(시스템)를 맛보고 "소금이 딱 맞아, 완벽해!"라며 박수를 칩니다. 하지만 홀에 나간 음식을 먹은 실제 손님(현업 사용자)들은 너무 짜서 물을 들이켜고 다시는 이 식당에 안 오겠다고 결심합니다. 감리관은 사장님의 혀를 믿지 않고, 직접 홀에 나가 손님 100명의 테이블에 만족도 설문지를 돌려 진짜 민심의 회초리를 가져오는 암행어사입니다.
Ⅱ. ISO 표준 기반의 뼈 때리는 설문조사 설계
질문이 날카로워야 도망갈 구멍을 막을 수 있다.
- 시스템 만족도 측정 지표 (Metrics):
- "시스템 좋습니까?" 같은 모호한 주관식 질문은 감리에서 배척당한다. 철저히 항목을 쪼개 5점 척도(Likert Scale)로 숫자를 받아내야 한다.
- 기능성(Functionality): "기존 구형 시스템에서 쓰던 핵심 업무 기능이 새 시스템에 100% 빠짐없이 이관되었습니까?" (기능 누락 색출)
- 사용성(Usability): "메뉴 구조가 직관적이고, 최소한의 클릭 수로 업무 처리가 가능합니까?" (UI/UX 붕괴 색출)
- 응답성/성능(Performance): "조회 버튼을 눌렀을 때, 3초 이내에 멈춤 없이 결과 화면이 뜹니까?" (DB 인덱스 누락, 로딩 지연 색출)
- 신뢰성(Reliability): "하루 업무 중 '알 수 없는 오류' 팝업이나 시스템 튕김 현상을 몇 번 겪으셨습니까?"
- 자유 기술(VoC)의 텍스트 마이닝:
- 점수보다 더 무서운 것은 주관식 칸에 쏟아지는 현장의 날 것 그대로의 원성(Voice of Customer)이다. "결재 대기함 창이 너무 작아서 스크롤 내리다 손가락 부러지겠음." 같은 텍스트를 감리인은 하나하나 형광펜을 그어 분류한다.
📢 섹션 요약 비유: 자동차 만족도 조사를 할 때 "차 좋나요?"라고 묻지 않습니다. "핸들을 꺾을 때 직관적으로 꺾이나요?(사용성)", "에어컨을 틀고 언덕을 오를 때 시동이 꺼지진 않나요?(신뢰성)", "가속 페달을 밟으면 3초 내에 시속 100km에 도달하나요?(성능)"라고 자동차 품질 검사 룰(ISO 25010)에 맞춰 현미경처럼 쪼개어 물어봐야만, 정비사(개발자)가 정확히 어느 부품을 뜯어고쳐야 할지 견적이 나옵니다.
Ⅲ. 감리의 칼날: 개선 조치 (Action Plan) 매트릭스 강제
설문지만 돌리고 엑셀로 통계 내서 보고서로 끝내면 최악의 감리다.
- 불만 사항의 정량화 및 필터링:
- 만족도 평균 5점 만점에 3.5점 미만으로 나온 뻘건색 낙제점 문항들을 싹 다 추려낸다.
- 주관식 의견 중 "화면 색깔이 맘에 안 듦" 같은 개인적 취향은 버리고, "엑셀 다운로드가 3분 걸려서 멈춰요" 같은 시스템 결함성 의견만 필터링한다.
- 개선 조치 및 이행 계획서 제출 (Remediation Plan):
- 감리인은 이 추려낸 '사용자 불만 리스트 Top 30' 엑셀 표를 개발팀 PM 얼굴에 집어 던진다.
- 개발팀은 이 30개의 불만에 대해 각각 ① 개선 조치 완료(코드 수정 끝), ② 차기 고도화 예산으로 이관(불가 항력), ③ 시스템 정책상 수용 불가(합당한 거절 사유) 중 하나의 도장을 찍고 사유를 쓴 조치 결과서를 제출해야 한다.
- 감리인의 최종 크로스 체크 (Sign-off):
- "엑셀 다운로드 속도 개선 완료"라고 적어왔으면, 감리인이 직접 시스템에 들어가 엑셀 다운로드 버튼을 눌러 스톱워치로 3초 안에 뜨는지 확인한다. 이것이 해결되어야만 '종료 감리 합격' 판정을 내려주고 개발사가 잔금을 받고 집에 갈 수 있다.
📢 섹션 요약 비유: 식당 손님들이 "김치찌개가 너무 짜요"라고 설문지에 1점을 줬습니다. 사장님이 "아, 손님들 입맛이 까다롭네" 하고 엑셀 통계만 내고 서랍에 넣으면 가게는 망합니다. 감리관(백종원)은 그 설문지를 주방장 이마에 붙여놓고, "지금 당장 찌개 레시피에서 소금을 10g 줄이고 육수를 반 컵 더 붓는 조치(Action Plan)를 취해! 내가 직접 맛보고 덜 짠 게 확인될 때까지 주방에서 퇴근 금지야!"라고 멱살을 잡고 체질을 고쳐놓는 하드트레이닝입니다.