학원 자체 시스템, 개발자가 퇴사하면 누가 고칠까 — 유지보수 리스크의 진짜 비용

2026년 4월, 한 직장인이 퇴사 당일 자신이 만든 업무 자동화 엑셀 파일을 삭제했다가 회사로부터 업무방해 혐의로 고소당할 뻔한 사연이 온라인 커뮤니티를 달궜다. 8시간 걸리던 업무를 30분으로 줄여준 그 파일이었지만, 정작 그 파일이 어떻게 작동하는지 아는 사람은 만든 사람 단 한 명뿐이었다. 학원도 다르지 않다. '우리 학원만의 시스템'을 자체 개발이나 지인 찬스, 프리랜서 외주로 만들어 쓰는 학원이 늘고 있지만, 그 시스템을 만든 개발자가 연락이 끊기는 순간 원장님은 정확히 같은 상황에 놓인다. 수강생 명단도, 결제 내역도, 진도 기록도 전부 '그 사람만 아는 코드' 안에 갇혀버리는 것이다.

🕰️ 언제부터 학원들이 '우리 시스템'을 갖고 싶어했을까

학원이 '우리 시스템'을 원하는 이유는 분명하다. 사교육비 지형 자체가 바뀌고 있기 때문이다. 교육부가 2026년 3월 발표한 「2025년 초중고 사교육비조사」에 따르면 전체 사교육비 총액은 27조5000억원으로 전년보다 5.7% 줄었지만, 실제로 사교육에 참여한 학생 1인당 월평균 비용은 60만4000원으로 오히려 2.0% 늘었다. 넓고 얕은 사교육 대신 좁고 깊은 '고단가·고밀도·전략형' 사교육으로 시장이 재편되고 있다는 뜻이다.

살아남는 학원일수록 학부모에게 보여줄 '데이터'가 필요해졌다. 출결·진도·성적을 눈에 보이게 관리하는 시스템 없이는 학부모 상담 한 번을 제대로 하기 어려운 시대가 된 것이다. 그래서 학원 원장들은 두 갈래 길에 섰다. 저가형 범용 학원관리 프로그램으로는 부족하다고 느끼는 학원들은 개발 지식이 있는 지인이나 프리랜서에게 '우리만의 시스템'을 맡기기 시작했다. 문제는 이때부터 시작된다.

⚠️ 개발자 한 명에게 달린 학원 운영 — '버스팩터'라는 위험

소프트웨어 업계에는 '버스팩터(Bus Factor)'라는 개념이 있다. 프로젝트를 알고 있는 핵심 인력이 갑자기 사라졌을 때(비유적으로 '버스에 치였을 때') 프로젝트가 얼마나 위험해지는지를 나타내는 지표다. 버스팩터가 1이라는 것은 단 한 사람만 빠져도 시스템 전체가 멈춘다는 뜻이다.

학원 자체 개발 시스템 대부분이 정확히 이 상태다. 전담 IT팀을 둘 여력이 없는 학원은 보통 개발자 한 명, 혹은 프리랜서 한 팀에게 기획부터 구현, 서버 관리까지 전부 맡긴다. 코드에 대한 설명서나 인수인계 문서는 뒷전이 되기 쉽다. 업계에서는 이를 '기술 부채' 중에서도 '문서 부채'라 부른다. 급하게 고친 코드일수록 문서화되지 않은 채 남고, 그 코드를 고친 사람이 떠나면 그 코드가 왜, 어떻게 그렇게 짜였는지 아는 사람이 아무도 남지 않게 된다는 것이다. 학원 시스템에 그대로 대입하면, 결제 로직 한 줄, 수강권 계산식 한 줄이 통째로 '블랙박스'가 되는 셈이다.

📊 유지보수 비용이 개발비보다 무서운 이유 — 데이터로 보는 진실

'일단 만들어만 놓으면 끝'이라는 생각이 가장 위험하다. 소프트웨어 업계에서는 오래전부터 유지보수 비용이 초기 개발비보다 훨씬 크다는 사실이 정설로 통한다. 소프트웨어 생애주기 전체 비용에서 유지보수가 차지하는 비중은 60~80%, 경우에 따라 90%에 이른다는 분석도 있다. 초기 개발비의 3~4배가 유지보수 단계에서 다시 들어간다는 뜻이다.

국내에서 통용되는 소프트웨어 유지관리요율만 봐도 감이 온다. 공공기관 평균은 개발비의 11.1% 수준이지만, 민간·글로벌 기업은 20% 이상을 유지보수 예산으로 따로 책정하는 경우가 흔하다. 즉 500만원을 들여 학원 시스템을 만들었다면, 그 시스템을 계속 문제없이 쓰기 위해 앞으로 5~10년간 또 다른 500만~1000만원이 어떤 형태로든 들어간다고 봐야 한다. 학원처럼 IT 예산 항목 자체가 따로 없는 소규모 사업장에서는 이 비용이 '개발자에게 매번 부탁하는 인정(人情)'으로 대체되는 경우가 많다. 그 인정이 사라지는 순간, 숨어있던 유지보수 비용 전체가 한꺼번에 청구서로 날아온다.

🔍 실제로 이런 일이 있었다 — 학원 시스템 실패·분쟁 3장면

계약 분쟁

한국소비자원 분쟁조정 사례 중에는 교육 서비스 업체가 온라인 교육 프로그램과 웹사이트 개발을 외주업체에 맡겼다가, 개발비 7000만원(부가세 별도)을 단계별로 지급하기로 했는데 업체가 작업을 지연하고 보완 요청을 제대로 반영하지 않아 갈등을 빚은 사례가 있다. 발주사는 2차 중도금 지급을 미뤘고, 시스템은 끝내 완성되지 못한 채 분쟁조정으로 넘어갔다. 학원이 흔히 겪는 '개발은 시작했는데 끝나지 않는' 전형적인 패턴이다.

담당자 이탈

공공 부문 대형 소프트웨어 사업에서도 같은 일이 벌어진다. 국내 한 차세대 정보시스템 구축 사업단은 투입 인력 343명 중 300명 이상이 프로젝트 도중 이직한 것으로 보도된 적이 있다. 기업 규모나 예산과 무관하게, 시스템을 아는 사람이 바뀌면 인수인계 부실과 품질 저하로 이어진다는 걸 보여주는 사례다.

방치

한 조사에서는 국내 공공기관 애플리케이션 중 상당수에서 오류가 확인됐는데, 개발 이후 업그레이드와 유지보수를 제대로 하지 않은 것이 주원인으로 지목됐다. '일단 만들고 나면 끝'이라는 생각이 예산이 넉넉한 공공기관에서도 통하지 않는데, 예산이 훨씬 빠듯한 학원에서는 말할 것도 없다.

🧭 전문가들은 이렇게 말한다 — 자체개발 vs 구독형, 뭐가 다른가

소프트웨어 공학에서는 '기술 부채' 개념을 자주 인용한다. 빠르게 짠 코드일수록 문서화가 뒤로 밀리고, 그 코드를 만든 사람이 떠나면 회사에는 '왜 이렇게 짰는지' 아는 사람이 아무도 남지 않는다는 것이다. 정보시스템 감리 분야 연구에서도 자체 개발 소프트웨어를 감리 기준으로 놓고 평가·개선 방안을 다루는 논문이 꾸준히 나온다. 그만큼 '자체 개발은 끝이 아니라 시작'이라는 인식이 IT 업계에서는 상식에 가깝다.

반대로 SaaS(구독형 소프트웨어) 진영의 시각은 다르다. SaaS는 초기 구축 비용과 IT 관리 부담을 크게 줄여주고, 사업 규모에 맞춰 유연하게 확장·축소할 수 있으며, 데이터 백업·복구 체계를 공급자가 대신 책임진다는 게 핵심 강점으로 꼽힌다. 다만 조직 특유의 요구사항에 맞춘 커스터마이징에는 한계가 있을 수 있다는 지적도 함께 나온다. 결국 '내 마음대로 다 되는 것'과 '아무 것도 신경 안 써도 되는 것' 사이에서 학원은 선택을 해야 한다.

⚖️ 그렇다고 무조건 구독형이 답은 아니다 — 반론과 한계

자체 개발이 항상 나쁜 선택인 것은 아니다. IT 전담 인력을 상시로 둘 수 있는 대형 학원 프랜차이즈 본사나, 이미 몇 년간 안정적으로 운영해 온 시스템이 있고 유지보수 체계(정기 백업, 이중화 인력, 문서화)까지 갖춘 곳이라면 자체 개발의 유연성이 오히려 강점이 된다. 문제는 전담 인력도, 유지보수 체계도, 문서도 없이 개발자 한 명에게만 의존하는 대다수 중소형 학원이다.

또한 구독형 솔루션이라고 리스크가 전혀 없는 것도 아니다. 운영사가 서비스를 중단하거나, 커스터마이징 범위가 우리 학원의 특수한 운영 방식과 맞지 않을 수도 있다. 그래서 솔루션을 고를 때는 로고만 바꿔 끼우는 템플릿형인지, 우리 학원 로고·색상·기능·도메인까지 실제로 맞춤 설정이 가능한지, 계약이 끝나도 데이터를 그대로 들고 나올 수 있는지를 반드시 확인해야 한다. 이 세 가지를 확인하지 않고 아무 솔루션이나 고르면, 자체 개발의 리스크를 구독형 솔루션의 리스크로 바꾸는 것에 불과하다.

🗺️ 지금 당장 점검해야 할 5가지

지금 학원에 자체 시스템이 있다면, 아래 다섯 가지부터 점검해보자.

1. 소스코드와 서버 접근 권한이 학원(원장) 명의로 되어 있는지 확인한다. 개발자 개인 계정에 전부 묶여 있다면 그 자체가 위험 신호다.
2. 인수인계 문서가 있는지 확인한다. 없다면 지금이라도 개발자에게 요청해 코드 구조·데이터베이스 구조를 정리한 문서를 받아둔다.
3. 유지보수 계약이 서면으로 존재하는지 확인한다. '아는 사이라 그냥 봐주는' 구조라면 그 관계가 끝나는 순간 유지보수도 함께 끝난다.
4. 수강생·결제·진도 데이터를 별도로 백업할 수 있는지 확인한다. 시스템이 멈춰도 데이터만 지켜지면 최악은 피할 수 있다.
5. 지금 방식이 정말 '우리 학원만의 것'을 지키는 최선인지 다시 따져본다.

다섯 번째 항목이 가장 중요하다. NUGUNA LMS 같은 구독형 솔루션은 '로고만 바꾼 템플릿'이 아니라, 로고·색상·도메인·기능 구성을 학원에 맞춰 커스터마이징하면서도 서버 운영·기능 수정·장애 대응은 전담 매니저가 책임지는 구조로 만들어졌다. 자체 개발 대비 1/5 수준의 비용, 약 2달의 구축 기간이라는 수치도 결국 '개발자 한 명에게 우리 학원 운영을 걸지 않아도 된다'는 안전장치에서 나온다. 영상 진도율 서버 기록, 수강신청·결제, 수료증 발급, 관리자 대시보드처럼 학원 운영에 꼭 필요한 기능은 이미 만들어져 있고, 기능 수정과 장애 대응도 계약에 포함돼 있어 '그 사람 연락이 끊기면 어떡하지'라는 걱정 자체를 없애는 방식이다.

❓ 자주 묻는 질문

Q. 학원 관리 프로그램을 자체 개발했는데, 만든 사람이 퇴사하면 소스코드는 누구 것인가요?

계약서에 명시돼 있지 않다면 분쟁의 소지가 있다. 프리랜서나 지인에게 외주를 맡겼다면 저작권·소스코드 소유권을 학원(발주자) 명의로 명확히 하는 계약서를 반드시 남겨야 한다. 계약서 없이 구두로 진행했다면 지금이라도 서면으로 정리해두는 것이 좋다.

Q. 외주로 개발한 프로그램도 자체 개발과 같은 리스크가 있나요?

있다. 외주는 초기 개발 인력이 처음부터 학원 소속이 아니라는 점만 다를 뿐, 유지보수 단계에서는 결국 그 외주업체(또는 담당 개발자)에게 다시 의존하게 된다. 업체가 폐업하거나 담당자가 바뀌면 자체 개발과 똑같은 상황에 놓인다.

Q. LMS 같은 구독형 솔루션을 쓰면 유지보수 걱정이 완전히 사라지나요?

운영·장애 대응·기능 업데이트 부담은 대부분 사라진다. 다만 솔루션 운영사가 얼마나 안정적인지, 커스터마이징이 우리 학원 운영 방식과 맞는지는 계약 전에 반드시 확인해야 한다.

Q. 이미 자체 개발한 시스템을 쓰고 있는데, 지금이라도 옮길 수 있나요?

가능하다. 수강생 명단, 결제·진도 기록 같은 핵심 데이터는 대부분 엑셀이나 CSV 형태로 옮길 수 있다. 다만 시간이 걸리는 작업이니 기존 시스템이 완전히 멈추기 전에 미리 준비하는 것이 안전하다.

Q. 유지보수 계약 비용과 구독료, 어느 쪽이 결국 더 저렴한가요?

단순 비교는 어렵지만, 소프트웨어 유지보수 비용이 초기 개발비의 60~90%에 달한다는 업계 통계를 고려하면 '초기 비용만 보고 자체 개발이 더 싸다'고 단정하기는 어렵다. 장기간 누적되는 유지보수·장애 대응 비용까지 합산해 비교해야 한다.

Q. 학원 규모가 작아도 구독형 솔루션을 쓸 수 있나요?

가능하다. NUGUNA LMS는 업종·규모와 무관하게 로고·색상·기능·도메인을 맞춤 구성할 수 있도록 설계돼 있어, 원생 수가 적은 소형 학원도 대형 프랜차이즈와 동일한 수준의 시스템을 부담 없는 수준에서 도입할 수 있다.

💡 결론 — 학원의 진짜 자산은 시스템이 아니라 데이터다

학원의 진짜 자산은 시스템 그 자체가 아니라, 그 시스템 안에 쌓인 수강생·결제·진도 데이터다. 개발자 한 사람의 기억과 연락처에 그 자산을 걸어두는 구조라면, 언젠가 반드시 청구서가 날아온다. 지금 우리 학원 시스템의 소스코드가 누구 명의로 되어 있는지, 인수인계 문서가 있는지부터 점검해보자. 이미 늦었다는 생각이 든다면, 요금제 안내에서 NUGUNA LMS의 구독형 학원 시스템을 확인하거나, 데모 체험으로 직접 화면을 먼저 살펴보는 것도 방법이다. 우리 학원에 맞는 구성이 궁금하다면 상담 신청을 통해 문의할 수 있다.

📎 참고 자료

• 교육부, 「2025년 초중고 사교육비조사」 결과(2026년 3월 발표)
• ZDNet Korea, "반복되는 대형 공공 SW사업 오류 원인은?"(2022)
• 전자신문, "공공기관 앱 절반이 불량···유지보수 미흡 탓"(2018)
• 한국소비자원 소비자24, 교육 프로그램·웹사이트 개발 계약 분쟁조정 사례
• 서치라이트, "2026 하반기 채용 트렌드 총정리"
• 네이트뉴스, 퇴사 직원 업무자동화 엑셀 삭제 관련 보도(2026년 4월)