LMS 도입 실패 사례로 보는 요구사항 정의의 함정과 대응법

🔍 벤더 데모 자리에서 처음 드러난 문제

미국 미시간 버추얼(Michigan Virtual)의 LMS 전환 사례는 자주 인용되는 반면교사다. 이 조직은 새 LMS 도입을 결정한 뒤 곧바로 벤더 데모부터 잡았다. 그런데 정작 핵심팀은 구성되지 않았고, 역할 분담도 없었으며, 요구사항은 문서화되지 않은 상태였다. 결과적으로 데모 자리에 참석한 미래의 핵심 구성원들은 "우리가 뭘 원하는지" 정리도 하지 못한 채 벤더의 화려한 기능 설명을 방어적으로 듣는 처지가 됐다. 이 조직은 뒤늦게 문제를 인식하고 절차를 되돌려 이해관계자 전원이 참여하는 요구 정의 단계부터 다시 밟았다. 이 사례가 상징적인 이유는, LMS 도입 실패의 대부분이 기술의 문제가 아니라 "무엇을 원하는지 합의하지 못한 채 시작한다"는 아주 기초적인 실수에서 비롯된다는 사실을 보여주기 때문이다. 이 글은 LMS 도입이 좌초하는 결정적 지점—요구사항 정의 단계—에서 실제로 어떤 함정들이 반복되는지, 그리고 이를 피하기 위한 실전 절차를 다큐먼트 수준으로 정리한다.

🕰️ 요구사항 정의 방법론의 역사 — 워터폴에서 애자일까지

요구사항을 어떻게 정의할 것인가라는 질문 자체는 소프트웨어 공학의 역사만큼 오래됐다. 1970년 윈스턴 로이스(Winston W. Royce)는 논문 "Managing the Development of Large Software Systems"에서 요구사항 분석·설계·구현·검증·통합·유지보수라는 6단계 순차 모델, 이른바 워터폴 모델을 제시했다. 워터폴은 초기에 요구사항을 포괄적으로 정의해 이후 단계를 상세히 계획할 수 있다는 장점이 있었지만, 순차적 구조 때문에 개발 후반에 나온 요구사항 변경이나 문제 발견에 대응하기 어려웠고, 고객은 테스트 단계가 되어서야 결과물을 보게 되어 오해와 불만이 쌓이는 구조적 약점을 안고 있었다.

이 약점에 대한 반작용으로 2001년 켄트 벡, 워드 커닝햄, 마틴 파울러 등 17명의 기술자가 '애자일 선언문'을 작성하면서 애자일 방법론이 공식 출범했다. 애자일은 요구사항 정의가 프로젝트 초반에 끝나는 것이 아니라 시스템의 생애 주기 내내 지속된다고 가정하며, 요구사항 수집·개발·테스트가 동시에 일어나는 지속적 협업을 통해 이를 구현한다. 오늘날 대형 LMS 구축 프로젝트에서는 두 방법론을 절충한 하이브리드 접근이 흔하다. 예산·규정 준수가 걸린 기획 단계에서는 워터폴식 순차 논리를 유지하되, 팀·스프린트 단위에서는 애자일 방식으로 유연성을 확보하는 식이다. 즉 "요구사항 정의는 한 번에 끝내는 게 아니라, 처음에 굵게 잡고 계속 다듬어가는 것"이라는 인식 전환이 이 역사가 남긴 교훈이다.

📊 데이터로 보는 실패 규모 — 요구사항은 실제로 가장 큰 원인이다

IT 프로젝트 실패를 가장 오래, 가장 폭넓게 추적해온 스탠디시 그룹의 CHAOS 리포트에 따르면 2023년 기준 소프트웨어 개발 프로젝트 중 온전히 성공(기한·예산·품질 목표 달성)한 비율은 29.7%에 불과했고, 49.2%는 '도전적(challenged, 지연·초과·기능 축소)', 21.1%는 완전 실패였다. 2020년 조사에서도 성공 31%, 도전적 50%, 실패 19%로 비슷한 분포를 보였다. 프로젝트 규모가 커질수록 상황은 더 나빠진다. 2021년 CHAOS 리포트 업데이트에서는 대형 소프트웨어 프로젝트의 실패·도전적 비율이 94%에 달한 반면, 소규모 프로젝트는 20%에 그쳤다.

요구사항은 이 실패의 핵심 변수로 반복 지목된다. CHAOS 리포트는 실패 원인으로 불완전한 요구사항, 이해관계자 참여 부족, 일정 지연을 꼽으며, 2014년 데이터에서는 '도전적' 프로젝트의 12.3%가 불완전한 요구사항·명세 때문으로 분류됐다. 반대로 명확하고 안정적인 요구사항은 실패 위험을 37% 낮춘다는 분석도 있다. 프로젝트 성공의 3대 요인으로 사용자 참여, 경영진의 지원, 그리고 명확한 요구사항 진술이 꼽히는 것도 같은 맥락이다. 국내 상황도 다르지 않다. 국내 대형 IT 프로젝트 실패 사례가 급증하는 배경에는 요구사항이 불명확해 사업 진행 단계에서 과업변경이 빈번히 발생하는 구조적 문제가 지목된다.

📌 한눈에 보기 — CHAOS 리포트 기준 완전 성공률은 30% 안팎, 대형 프로젝트는 실패·도전적 비율이 94%에 달한다. 그리고 그 실패의 상당 부분은 코딩 실력이 아니라 "무엇을 만들지 합의하지 못한 것"에서 시작된다.

🗺️ 왜 LMS 요구사항 정의가 유독 함정에 빠지기 쉬운가

LMS는 일반 사내 시스템과 달리 이해관계자가 유독 많고 다양하다. HR·교육 담당자, 현업 부서장, 학습자 본인, IT 보안팀, 때로는 규제 대응 부서까지 요구사항이 얽힌다. 그런데 실무에서는 흔히 HR 한 부서가 요구사항 수집을 주도하면서, 정작 시스템을 매일 써야 할 현업 부서나 학습자의 필수 요구가 통째로 빠지는 경우가 반복된다. 여기에 LMS는 '교육 관리'라는 명목상 단순한 목적 뒤에 법정의무교육 자동 배정, 직무·부서별 학습경로, 기존 그룹웨어·인사시스템과의 연동, 데이터 마이그레이션, 보안·권한 정책 등 숨은 요구사항이 켜켜이 쌓여 있다는 특징도 있다. 이런 항목들은 벤더 데모를 보기 전까지는 조직 스스로도 인식하지 못하는 경우가 많아, 뒤늦게 "이 기능도 필요했는데"라는 말이 나오는 순간 계약 범위와 일정이 흔들린다.

💼 함정 1 — 이해관계자를 절반만 모은다

LMS 도입 실패의 상당수는 광범위한 사업 부서와의 협의 부족에서 시작된다. HR 한 부서가 요구사항 수집을 주도하면 정작 필수적인 현업 니즈가 무시되는 경우가 흔하다는 지적은 국내외 컨설팅 사례에서 공통으로 나온다. 성공적인 도입은 벤더 제품 데모를 보기 전에 명확한 역할을 가진 핵심팀을 구성하고, LMS 도입의 영향을 받는 모든 이해관계자 그룹의 대표자를 포함시켜 문제·제약·요구사항을 함께 정의하는 단계를 거친다는 공통점이 있다. 요구사항 수집 자체도 인터뷰·설문·워크숍·관찰·문서분석·프로토타입 등 여러 기법을 병행해야 한 명의 목소리에 요구사항이 왜곡되는 것을 막을 수 있다.

이 함정이 특히 위험한 이유는 문제가 계약 체결 이후, 그것도 시스템이 어느 정도 완성된 뒤에야 드러난다는 점이다. HR 부서 기준으로 설계된 화면과 데이터 구조는 현업 부서장이 실제로 필요로 하는 부서별 이수 현황이나 직무별 학습 경로를 반영하지 못하는 경우가 흔하고, 뒤늦게 이를 보완하려면 이미 확정된 데이터 모델과 화면 설계를 뜯어고쳐야 하는 비용이 발생한다. 초기 요구사항 정의 단계에 하루 이틀 더 들여 이해관계자 워크숍을 여는 비용과, 계약 후반부에 데이터 모델을 재설계하는 비용은 자릿수 자체가 다르다.

💻 함정 2 — 텍스트로만 쓰인 요구사항 정의서

두 번째 함정은 요구사항을 문장으로만 적어두는 관행이다. 실무에서는 "텍스트 중심 요구사항 정의서는 위험하다"는 경고가 반복된다. 고객(발주 기업)은 머릿속에 이미 완성된 화면을 상상하고 있는 반면, 개발사는 문서에 적힌 문장을 기준으로 최소 구현만 하기 때문이다. 이 시점에서 화면 구성이나 사용자 경험(UI/UX) 방향이 어긋나면, 프로젝트는 사실상 재개발 수준의 재작업에 들어간다. 이를 막으려면 문장형 요구사항 정의서에 화면 와이어프레임·프로토타입·사용자 시나리오를 반드시 병기해, "글로는 같은 말인데 서로 다른 그림을 그리고 있는" 상황을 조기에 드러내야 한다. 비기능 요구사항(성능·보안·동시접속자 수 등)과 예외 케이스를 문서에서 누락하는 것도 같은 계열의 실수로 꼽힌다.

⚠️ 함정 3 — 통제되지 않은 요구사항 변경(과업변경)

현장 경험이 있는 기획자들은 한결같이 말한다. "요구사항 변경 자체를 막는 건 사실상 불가능하다. 중요한 건 통제되지 않은 변경을 막는 것이다." 국내 공공 SW 사업에서도 요구사항이 처음부터 불명확해 사업 진행 단계마다 과업변경이 반복되는 것이 대형 실패의 핵심 원인으로 지목된다. 문제는 변경 자체가 아니라, 변경이 발생했을 때 그것이 일정·예산·범위에 미치는 영향을 아무도 계산하지 않고 그냥 반영해버리는 관행이다. 이 때문에 프로젝트 관리 방법론에서는 변경 요청이 들어올 때마다 영향도를 평가하고 승인 절차를 거치는 '변경통제위원회' 같은 장치를 두라고 조언한다. LMS 프로젝트에서는 특히 "이번 김에 이 기능도"식의 스코프 크리프(scope creep)가 흔한데, 이는 요구사항 정의 단계에서 우선순위(필수/권장/선택)를 명확히 등급화해두지 않았기 때문에 벌어지는 경우가 대부분이다.

🔍 실무 사례 1 — 데모부터 잡았다가 되돌아간 미시간 버추얼

앞서 소개한 미시간 버추얼 사례를 좀 더 들여다보면, 이 조직의 실수는 기술 선택의 실수가 아니라 순서의 실수였다. 핵심팀 구성과 역할 분담, 요구사항 정의라는 준비 단계를 건너뛰고 벤더 데모부터 진행한 탓에, 참석자들은 자신들이 무엇을 판단해야 하는지도 모른 채 벤더의 설명을 수동적으로 들어야 했다. 이는 프로젝트 개발 단계에 문제·제약·요구사항을 정의하는 절차가 먼저 있어야 하고, 그 팀에는 영향을 받는 모든 이해관계자 그룹의 대표가 포함돼야 한다는 원칙을 정면으로 어긴 사례다.

🔍 실무 사례 2 — 국내 공공 SW 사업의 반복되는 과업변경

국내에서는 대형 공공 소프트웨어 사업에서 실패가 반복되는 원인으로 잦은 과업변경이 지목된다. 요구사항이 처음부터 불명확한 채로 사업이 발주되면, 진행 과정에서 발주기관의 요구가 계속 바뀌고, 이는 일정 지연과 예산 초과로 이어진다. 여기에 공공 SW 사업 특유의 저수익 구조와 불공정 거래 관행까지 겹치면서, 요구사항 재정의에 필요한 재작업 비용을 벤더가 감당하지 못해 사업이 유찰되거나 중도에 좌초하는 경우도 보고된다. 공공기관의 이러닝 운영 자체를 들여다본 연구에서도 이러닝의 필요성에 대한 인식 부족, 담당자의 전문성 부족, 콘텐츠 품질 저하, 교육효과 측정지표의 부재가 반복적인 운영상 문제로 지적된 바 있다. 이는 '도입'과 '운영'의 요구사항이 애초에 함께 정의되지 않았을 때 나타나는 전형적인 후유증이다.

이런 유형의 실패가 반복되는 이유는 단순하다. 발주 단계의 요구사항 정의서가 "교육을 효율화한다"처럼 추상적인 목표만 담고, 구체적으로 어떤 화면에서 어떤 데이터를 어떻게 다룰지에 대한 합의가 없었기 때문이다. 그 결과 사업이 진행되는 도중에야 "법정의무교육 이수 현황을 부서별로 자동 집계해야 한다"거나 "기존 인사시스템의 조직도 변경 이력을 실시간으로 반영해야 한다"는 식의 요구가 뒤늦게 튀어나오고, 이는 이미 확정된 일정과 예산 안에서는 소화할 수 없는 과업변경으로 이어진다. 결국 발주기관과 수행사 양측 모두 손해를 보는 구조가 반복되는 것이다.

🔍 실무 사례 3(반례) — 광범위한 이해관계자 참여로 성공한 경우

실패 사례의 반대편에는 처음부터 이해관계자 범위를 넓게 잡은 도입 사례가 있다. 여러 LMS 도입 가이드가 공통으로 강조하는 성공 패턴은, 벤더 제품 데모 이전에 핵심팀을 구성하고 역할을 명확히 하며, LMS의 영향을 받는 모든 그룹—HR, 현업 관리자, 학습자, IT 보안, 콘텐츠 제작 담당—의 대표를 참여시켜 문제 정의부터 함께 하는 것이다. 이렇게 초기에 시간을 들여 요구사항을 폭넓게 수집한 조직은 벤더 선정 단계에서 이미 우선순위가 정리되어 있어, 데모 자리에서 "이 기능이 우리에게 필요한가"를 판단하는 대신 "이 기능이 우리가 이미 합의한 요구사항 몇 번을 충족하는가"를 확인하는 방식으로 의사결정 속도와 정확도를 동시에 높일 수 있었다.

🧭 전문가 시각 — 문서화론과 애자일 지속정의론의 긴장

요구사항을 둘러싼 전문가 의견은 크게 두 갈래로 나뉜다. 첫째, 전통적 문서화 관점은 "요구사항 정의서는 프로젝트 초기에 무엇을 만들 것인지 명확히 정리해 모든 참여자가 같은 방향을 보게 만드는 장치이며, 계약 분쟁을 예방하는 법적 근거"라고 본다. 초기에 요구사항을 정리하지 않으면 개발 중간에 방향이 바뀌거나 불필요한 기능이 추가돼 예산 초과와 일정 지연으로 이어진다는 것이다. 둘째, 애자일 관점은 요구사항이 프로젝트 초반에 완결되는 문서가 아니라 시스템 생애주기 내내 지속적으로 다듬어지는 대상이라고 본다. 짧은 개발 주기로 점진적 결과물을 내고 고객 피드백을 즉시 반영하는 방식이 시장·조직 상황이 빠르게 바뀌는 오늘날 더 현실적이라는 입장이다. 이 두 관점은 대립한다기보다 적용 범위가 다르다고 보는 편이 정확하다. 계약·예산·규정 준수가 걸린 부분(예: 데이터 보안, 감사 로그, 법정의무교육 요건)은 문서화된 요구사항으로 못박아야 분쟁을 막을 수 있고, UI/UX나 학습 경험처럼 사용해봐야 아는 영역은 애자일식 반복 검증이 더 적합하다. 실무에서 두 관점이 실제로 충돌하는 지점은 '요구사항 변경을 어디까지 무상으로 받아줄 것인가'다. 문서화론은 계약서에 명시된 범위를 벗어난 요구는 변경 요청으로 분류해 별도 협의를 거쳐야 한다고 보는 반면, 애자일론은 스프린트 단위로 우선순위를 재조정하는 것 자체가 정상적인 프로세스라고 본다. LMS처럼 계약 기반 외주 구축이 많은 영역에서는 결국 문서화론 쪽의 원칙—범위를 벗어난 변경은 별도 협의—을 기본으로 하되, 학습자 화면이나 콘텐츠 배치처럼 저비용으로 반복 조정 가능한 영역에는 애자일식 유연성을 허용하는 것이 현실적인 절충안으로 자리잡고 있다.

⚖️ 워터폴식 사전정의 vs 애자일 지속정의 — 무엇을 어디에 쓸 것인가

⚖️ LMS RFP 요구사항 체크리스트 — 놓치기 쉬운 항목까지

LMS 요구사항을 정의할 때 실무에서 참고할 만한 항목 분류는 필수·권장·선택 세 등급으로 나누는 방식이다. 국내 LMS 비교 자료에서는 9개 카테고리에 걸쳐 60개 평가 항목(필수 32·권장 27·선택 1)을 두고, 항목별로 제출 증빙과 검증 방법까지 함께 정의하도록 권한다. 특히 놓치기 쉬운 항목으로는 법정의무교육 자동 배정, 직무·부서별 학습경로 설계, 학습자 군 분리 운영, 지식 공유 기능으로의 확장 가능성, 그리고 기존 LMS를 완전히 교체하지 않고 특정 구간만 4주 파일럿으로 검증할 수 있는지 여부가 꼽힌다. 여기에 최근에는 AI 기능이 포함된 LMS라면 AI가 생성한 콘텐츠의 검토·수정·재생성·확정 이력 관리, 고객 데이터가 모델 학습에 쓰이지 않는다는 근거자료, 민감정보 외부 전송 차단, 감사 로그 같은 항목도 구매 조건으로 명시해야 한다는 지적이 나온다.

🚀 실전 가이드 — LMS 요구사항 정의, 이 순서로 하라

1단계. 벤더 미팅보다 먼저 핵심팀부터 구성한다

미시간 버추얼의 실수를 반복하지 않으려면, 벤더 데모 일정을 잡기 전에 HR·현업·IT보안·학습자 대표가 포함된 핵심팀을 먼저 구성하고 각자의 역할을 문서로 못박는다.

2단계. 요구사항을 필수·권장·선택 3등급으로 나눈다

모든 요구사항을 똑같이 취급하면 협상에서 밀린다. 법정의무교육 자동배정처럼 계약 위반 시 리스크가 큰 항목은 필수로, AI 추천 같은 부가 기능은 선택으로 명확히 등급화한다.

3단계. 문장이 아니라 화면과 시나리오로 확인한다

텍스트 정의서만으로는 발주자와 벤더가 서로 다른 화면을 상상한다. 와이어프레임이나 프로토타입, 실제 학습자 시나리오를 함께 첨부해 조기에 인식 차이를 드러낸다.

4단계. 변경 요청은 영향도 평가를 거쳐서만 반영한다

요구사항 변경 자체를 막을 수는 없다. 대신 변경 요청이 들어올 때마다 일정·예산·범위에 미치는 영향을 평가하고 승인 절차를 거치는 변경통제 프로세스를 계약 단계에서부터 명시한다.

5단계. 전체 전환 전에 4주 파일럿으로 검증한다

기존 시스템을 한 번에 교체하기보다, 특정 부서나 특정 교육 과정 하나를 대상으로 4주 정도의 부분 파일럿을 돌려 요구사항이 실제로 충족되는지 확인한 뒤 전사 확산 여부를 결정한다.

6단계. 요구사항 정의서에 반드시 '검증 방법'을 함께 적는다

요구사항 항목만 나열하고 그것을 어떻게 확인할지 적어두지 않으면, 벤더가 "지원한다"고 답한 기능이 실제로는 조건부이거나 별도 유상 옵션인 경우를 계약 후에야 발견하게 된다. 필수 항목은 계약서 조항으로 명시하고 파일럿 단계에서 실측하며, 권장 항목은 벤더 레퍼런스 확인과 데모 시연으로, AI 기능처럼 최근에 추가된 선택 항목은 모델 학습 미사용 근거자료와 감사 로그 검토까지 요구사항 정의서 안에 검증 방법 칸을 따로 만들어 함께 관리하는 것이 뒤늦은 분쟁을 막는 가장 확실한 방법이다.

❓ 자주 묻는 질문

Q1. LMS 요구사항 정의서는 누가 작성해야 하나요?

HR·교육 담당 부서가 주도하되, 현업 부서 대표·IT 보안 담당·학습자 대표까지 포함한 핵심팀이 공동으로 작성해야 한다. 한 부서만 주도하면 필수 요구가 누락될 위험이 크다.

Q2. RFP에 꼭 넣어야 할 항목은 무엇인가요?

기능 요구사항 외에 기존 그룹웨어·인사시스템과의 연동 여부, 데이터 마이그레이션 방법, 보안(암호화 수준·권한관리·백업정책), 법정의무교육 자동배정 같은 비기능 요구사항을 반드시 명시해야 한다.

Q3. 요구사항이 프로젝트 중간에 바뀌면 어떻게 하나요?

변경을 무조건 막기보다, 변경 요청이 들어올 때마다 일정·예산에 미치는 영향을 평가하고 승인하는 절차(변경통제)를 계약 단계부터 마련해두는 것이 현실적인 대응이다.

Q4. 워터폴과 애자일 중 어느 쪽으로 요구사항을 정의해야 하나요?

계약·보안·규정처럼 되돌리기 어려운 영역은 워터폴식으로 사전에 문서화하고, UI·학습경험처럼 사용해봐야 아는 영역은 애자일식으로 반복 검증하는 하이브리드 방식이 현실적이다.

Q5. 소규모 조직도 이런 절차가 다 필요한가요?

대형 프로젝트의 실패·도전적 비율이 94%에 달하는 반면 소규모 프로젝트는 20% 수준이라는 조사 결과처럼, 규모가 작을수록 절차 부담은 줄여도 되지만 핵심팀 구성과 필수/권장 등급화 같은 최소한의 절차는 규모와 무관하게 필요하다.

Q6. 전체 시스템을 한 번에 바꾸는 게 나을까요, 나눠서 바꾸는 게 나을까요?

기존 LMS를 완전히 교체하기 전에 특정 구간만 4주 정도 파일럿으로 검증할 수 있는지가 놓치기 쉬운 체크 항목으로 꼽힌다. 전면 전환보다 부분 파일럿 후 확산이 리스크를 크게 낮춘다.

📎 출처

• Standish Group, CHAOS Report 2023 / 2020 / 2021 업데이트(프로젝트 성공·도전적·실패 비율)
• Michigan Virtual, "LMS Selection and Implementation: Michigan Virtual Case Study"
• ZDNet Korea, "반복되는 대형 공공 SW사업 오류 원인은?"
• 디지털데일리, "공공 소프트웨어 사업 실패 원인은 잦은 과업변경" (2023)
• DBpia, "공공기관 이러닝 운영상 문제점과 성공요인 탐색"
• 터치클래스, "국내 LMS 비교 60개 항목 평가 체크리스트" (2026), "AI LMS는 무엇이 다른가" (2026)
• 이랜서 블로그, "요구사항 정의서 작성법과 양식", "RFP 작성법"
• arXiv, "A Brief History of the Waterfall Model: Past, Present, and Future"
• InfoWorld, "A brief history of the agile methodology"

💡 결론 — 요구사항 정의는 프로젝트의 절반이다

LMS 도입 실패는 대개 화려한 기술 문제가 아니라 "누가, 무엇을, 어떤 우선순위로 원하는가"를 합의하지 못한 채 출발한 결과다. CHAOS 리포트가 반복적으로 보여주듯 명확하고 안정적인 요구사항은 실패 위험을 크게 낮추고, 반대로 이해관계자를 절반만 모으거나 텍스트로만 정의서를 쓰거나 변경을 통제하지 못하면 아무리 좋은 솔루션을 골라도 결과는 크게 달라지지 않는다. NUGUNA에서는 이런 함정을 줄이기 위해 기능별 상세 안내와 업종별 도입 사례를 업종별 사례에서 확인할 수 있고, 실제 화면을 데모 체험으로 먼저 만져본 뒤 요구사항을 구체화하는 것도 방법이다. 도입 전 요구사항을 함께 정리하고 싶다면 상담 신청을, 예산 범위를 먼저 가늠하고 싶다면 요금 안내를 참고하면 된다.