요구사항 관리 부실이 프로젝트 실패의 주된 원인입니다. 반복되는 네 가지 실패 패턴과, 학원이 쓸 수 있는 사용자 이야기·MoSCoW 요구사항 정리법을 소개합니다.
"우리 학원에 필요한 기능이 뭐예요?" 시스템 도입 상담에서 가장 자주 받는 질문이고, 가장 답하기 어려운 질문입니다. 원장님은 출결, 결제, 성적, 알림톡 같은 익숙한 단어를 나열하다가 정작 중요한 것을 빠뜨립니다. 몇 달 뒤 "이건 원래 하려던 게 아닌데요"라는 말이 나오고, 그때 발견된 요구는 추가 개발 견적이 됩니다. 이 글은 실제 특정 학원의 실패담을 소개하는 것이 아니라 도입 과정에서 반복되는 실패 패턴을 분석하고, 그것을 막는 요구사항 정리법을 제시합니다.
프로젝트 관리협회(PMI)의 2014년 조사에서 부정확한 요구사항 수집은 프로젝트 실패의 주요 원인 37%를 차지했고 전년의 32%에서 늘었습니다. 요구사항 관리 부실이 원인으로 꼽힌 프로젝트가 목표 미달 프로젝트의 47%였고, 프로젝트에 쓰는 돈의 5.1%가 이 때문에 낭비된다는 추정도 있습니다. 시스템이 나빠서가 아니라 무엇을 원하는지를 제대로 정하지 못해서 실패하는 경우가 그만큼 많다는 뜻입니다.
⚠️ 반복되는 네 가지 실패 패턴
아래는 도입 과정에 대한 분석으로, 특정 사례가 아니라 실무에서 반복되는 패턴입니다.
| 패턴 | 어떻게 나타나는가 | 결과 |
|---|---|---|
| ① 기능 나열형 | "출결, 결제, 성적, 알림톡"처럼 이름만 나열하고 실제 업무 흐름은 정하지 않음 | 기능은 있는데 우리 업무와 안 맞음 |
| ② 예외 누락형 | 평소의 흐름만 정의하고 환불, 반 이동, 결석 같은 예외를 빠뜨림 | 운영 초기에 예외가 쏟아져 수기 작업으로 복귀 |
| ③ 이해관계자 누락형 | 원장의 관점만 반영하고 실장·강사·학부모의 요구는 빠짐 | 실제 사용자가 시스템을 외면 |
| ④ 우선순위 부재형 | 모든 요구를 똑같이 중요하게 취급해 비용이 부풀거나 핵심이 흐려짐 | 범위 확대와 일정 지연, 추가 견적 |
네 패턴은 서로 다른 얼굴을 하고 있지만 공통점은 하나입니다. 요구사항이 "기능의 이름"에 머물고 "누가, 언제, 무엇을 위해"로 내려오지 못했다는 점입니다.
🗺️ 요구사항을 문장으로 바꾸는 법
요구사항을 기능 이름이 아니라 사용자 이야기 형태로 적으면 빠진 부분이 드러납니다. 형식은 단순합니다. "(역할)로서, (목적)을 위해, (행위)를 하고 싶다." 여기에 "어떻게 되면 충분한가"라는 완료 기준을 덧붙입니다.
| 역할 | 요구사항 문장 예시 | 완료 기준 |
|---|---|---|
| 학부모 | 학부모로서, 아이의 수업 진행 상황을 알기 위해, 결석과 진도 알림을 받고 싶다 | 결석 당일 알림을 받고 문구는 학원이 정한 어조 |
| 실장 | 실장으로서, 환불 분쟁을 막기 위해, 수강 중도 해지 시 법정 기준으로 반환액이 계산되길 원한다 | 경과 교습시간에 따른 금액이 자동 산출 |
| 강사 | 강사로서, 수업 준비 시간을 줄이기 위해, 내 반의 진도 미달 학생을 한눈에 보고 싶다 | 로그인 후 첫 화면에서 확인 |
| 원장 | 원장으로서, 이번 달 경영 상태를 알기 위해, 매출과 재원 추이를 대시보드에서 보고 싶다 | 월 마감 전에도 조회 가능 |
이 형식은 애자일 개발에서 널리 쓰이는 사용자 스토리에서 온 것으로, 전문가가 아니어도 쓸 수 있고 "왜"가 문장에 포함돼 있어 나중에 우선순위를 정하기도 쉽습니다.
📊 우선순위 정하기 — MoSCoW
모든 요구를 똑같이 중요하게 다루면 비용이 커지고 핵심이 흐려집니다. 요구사항을 네 등급으로 나누는 MoSCoW 기법은 소프트웨어 개발 방법론(DSDM)에서 나온 것으로 학원에도 그대로 쓸 수 있습니다.
| 등급 | 의미 | 학원 예시(가정) |
|---|---|---|
| Must(반드시) | 없으면 운영이 불가능 | 수강 신청·결제, 학부모 알림, 환불 계산 |
| Should(가능하면) | 중요하지만 임시 대안이 있음 | 강사별 정산 리포트, 진도 미달 알림 |
| Could(있으면 좋음) | 여유가 있을 때 | 학습 통계 시각화 고도화 |
| Won't(이번에는 안 함) | 이번 도입에서 제외 | 다지점 통합 정산(확장 시 재검토) |
표의 예시는 이해를 돕기 위한 가정이며 학원마다 다르게 분류해야 합니다. 핵심은 Won't를 명시하는 것입니다. "이번에는 하지 않는다"고 적어 두면 나중에 그것이 "빠졌다"는 오해가 아니라 합의된 제외가 됩니다.
🧭 두 가지 시각 — 사전에 꼼꼼히 vs 쓰면서 다듬기
사전 정리를 강조하는 시각. 도입 후 발견된 요구는 추가 비용이 되므로 사전에 최대한 정리해야 한다는 견해입니다. 요구사항 관리 부실이 실패의 주된 원인이라는 조사가 이를 뒷받침합니다.
점진적 접근을 지지하는 시각. 반대편에서는 사전에 완벽한 요구를 정의하는 것은 불가능하고 오히려 지연을 부르므로 핵심만 정하고 써 보면서 다듬는 편이 낫다고 봅니다. 학원의 운영은 매 학기 달라지기 때문입니다.
📌 한눈에 보기 — 접점은 "핵심은 사전에, 나머지는 점진적으로"입니다. Must만 명확히 하고 시스템이 수정과 확장에 유연한지를 함께 확인하세요. 사전 정리의 목적은 완벽한 문서가 아니라 합의입니다.
🗺️ 실전 가이드 — 요구사항 정리 6단계
- 하루를 그린다 — 등원부터 마감까지 원장·실장·강사·학부모 각자의 하루를 적습니다.
- 예외 목록을 만든다 — 환불, 반 이동, 결석, 보강, 이월 같은 예외를 최대한 나열합니다.
- 사용자 이야기로 바꾼다 — 각 항목을 "역할로서, 목적을 위해, 하고 싶다" 문장과 완료 기준으로 정리합니다.
- MoSCoW로 분류한다 — Must 비율을 절반 이하로 줄이고 Won't를 명시합니다.
- 이해관계자와 검토한다 — 실장·강사가 초안을 보고 빠진 것을 채웁니다.
- 시연으로 검증한다 — Must 항목을 후보 시스템이 어떻게 처리하는지 시나리오로 확인합니다.
💻 NUGUNA LMS와 요구사항 정리
정리한 요구사항은 도입 상담에서 그대로 활용하실 수 있습니다. NUGUNA LMS는 학원·교육기관 업종에서 강사별 정산, 수강권 기간 관리, 학부모 알림, 라이브 강의 연동을 필요 기능으로 다루고, 로고·색상·기능·도메인 맞춤과 기능 수정 포함 조건으로 학원의 요구를 반영하는 구조입니다. Must에 해당하는 항목이 어떻게 처리되는지 시나리오 시연으로 확인하시길 권합니다.
| 요구 영역 | 확인된 구성 요소 | 상담에서 시연으로 확인할 것 |
|---|---|---|
| 수강 신청·결제·환불 | 카드·계좌이체·간편결제, 쿠폰·할인, 환불 자동 계산(청약철회 규정 기준) | 학원법 반환 기준의 반영 여부 |
| 학부모 알림 | 이메일·카카오 알림톡, 알림 문구 직접 수정 | 결석·진도 알림의 발송 조건 |
| 경영 지표 | 수강생·매출·수료율 실시간 통계, 엑셀 다운로드 | 원하는 지표의 포함 여부 |
| 강의·평가 | 영상·PDF·퀴즈·과제, 자동·강사 채점 | 학원의 평가 방식과의 적합성 |
| 항목 | 자체 개발 | 외주 개발 | NUGUNA LMS |
|---|---|---|---|
| 기능 수정(요구 변경 대응) | 개발자 필요 | 추가 견적 | 포함 |
| 유지보수 | 직접 | 별도 계약 | 포함 |
| 오픈 후 지원 | 없음 | 유상 | 전담 매니저 |
요구는 도입 후에도 계속 바뀝니다. 기능 수정이 포함된 구조에서는 사전에 완벽하게 정하지 못한 요구를 운영하면서 보완할 수 있지만, "수정 포함"의 범위는 계약 전에 문서로 확인하셔야 합니다.
❓ 자주 묻는 질문
Q1. 요구사항은 얼마나 자세히 써야 하나요?
Must 항목은 문장과 완료 기준까지, 나머지는 한 줄이면 충분합니다. 전체가 A4 두 장 안에 들어오게 하세요.
Q2. 누구와 함께 정리해야 하나요?
원장뿐 아니라 실장, 담임·강사와 함께 정리하세요. 학부모의 입장은 자주 묻는 질문과 상담 내용에서 뽑을 수 있습니다.
Q3. 예외 상황은 어떻게 찾나요?
지난 1년간 가장 골치 아팠던 학생 사례 5건을 떠올려 보세요. 대부분의 예외가 거기에 들어 있습니다.
Q4. Won't를 꼭 적어야 하나요?
적는 편이 좋습니다. 제외를 합의해 두면 나중에 빠졌다는 오해와 분쟁을 줄일 수 있습니다.
Q5. 정리한 요구를 시스템이 다 못 채우면요?
Must가 충족되는지가 핵심입니다. Must가 채워지지 않는다면 그 후보는 제외하고, Should는 대안 운영 방식이 있는지 확인하세요.
Q6. 도입 후에 요구가 바뀌면 어떻게 하나요?
변경 절차와 비용을 계약에서 정해 두세요. 수정이 포함된 구조인지, 어디까지가 수정인지를 확인하는 것이 중요합니다.
🚀 결론 — 요구사항은 기능의 이름이 아니라 합의다
도입 실패의 상당수는 시스템의 문제가 아니라 요구를 정하지 못한 문제입니다. 하루를 그리고, 예외를 찾고, 사용자 이야기로 바꾸고, MoSCoW로 분류해 합의하세요. NUGUNA LMS의 기능과 업종별 안내를 살펴보고, 데모를 확인한 뒤 상담에서 정리한 Must 목록을 그대로 시연해 달라고 요청해 주세요. 비용은 요금제 안내에서 확인하실 수 있습니다.
