교육을 대신 운영해 주는 조직은 고객사가 셋을 넘어가는 순간 같은 질문에 부딪힙니다. 고객사마다 시스템을 따로 만들어야 하나, 아니면 하나에 다 넣어도 되나. 여러 고객사의 교육을 한 LMS(학습관리시스템, Learning Management System)에서 나눠 운영하는 방법의 핵심은 사이트를 쪼개는 것이 아니라 회원 소속·관리자 권한·데이터 조회 범위 세 가지를 분리하는 것입니다. 이 세 층만 제대로 잡히면 하나의 시스템 안에서도 고객사끼리는 서로의 존재를 모르는 상태로 운영됩니다. 이 글은 위탁·다계정 운영을 설계할 때 무엇을 나누고 무엇을 공통으로 둘지, 계약 단계에서 미리 정해야 할 것은 무엇인지 정리합니다.
이 고민을 하는 곳은 생각보다 많다
'위탁 운영'이라는 말은 잘 안 쓰지만 구조가 같은 조직이 꽤 됩니다.
교육대행사와 컨설팅 회사가 대표적입니다. 여러 기업의 법정의무교육이나 직무교육을 대신 열고, 이수 결과를 각 기업에 보고합니다. 협회와 학회는 지회·분과가 자기 교육을 따로 열면서 본부는 전체를 봐야 합니다. 지주회사와 그룹사는 계열사별로 교육이 다르지만 그룹 차원의 공통 교육도 함께 돌립니다. 훈련기관은 다른 기관에서 위탁받은 과정을 자기 과정과 나란히 운영합니다. 프랜차이즈 본사는 가맹점 단위로 교육을 배정하고 이수 여부를 관리합니다.
이름은 달라도 요구는 같습니다. 한 시스템 안에 여러 조직의 학습자가 섞여 있는데, 각 조직 담당자에게는 자기 조직만 보여야 하고, 우리는 전체를 봐야 한다.
고객사 수만큼 시스템을 늘리면 어떻게 되나
가장 먼저 떠오르는 답은 고객사마다 시스템을 하나씩 두는 것입니다. 확실히 분리되긴 합니다. 문제는 고객사가 다섯을 넘어갈 때부터 드러납니다.
| 항목 | 고객사마다 시스템을 따로 | 한 시스템에서 소속으로 분리 |
|---|---|---|
| 초기·유지 비용 | 고객사 수만큼 늘어난다 | 고객사가 늘어도 시스템은 하나 |
| 공통 과정 재사용 | 같은 강의를 시스템마다 다시 등록 | 한 번 등록해 차수만 나눠 배정 |
| 전체 현황 취합 | 시스템마다 엑셀을 받아 손으로 합산 | 소속 기준으로 한 화면에서 집계 |
| 담당자 계정 | 우리 직원이 시스템마다 로그인 | 계정 하나로 담당 고객사 전체 조회 |
| 학습자 중복 | 여러 고객사 교육을 듣는 사람은 계정이 여러 개 | 한 계정에 소속을 붙여 관리 |
| 고객사 전용 요구 | 도메인·디자인을 완전히 다르게 가져갈 수 있다 | 전용 도메인·별도 브랜딩은 별도 검토 사항 |
| 맞는 경우 | 고객사가 자기 사이트를 요구하거나 데이터 분리 보관이 계약 조건일 때 | 운영 대행이 주업무이고 고객사가 계속 늘어나는 구조 |
정리하면 시스템을 나누는 기준은 고객사 수가 아니라 고객사가 '자기 사이트'를 요구하느냐입니다. 고객사가 원하는 것이 자기 브랜드의 교육 사이트라면 분리가 맞고, 원하는 것이 자기 직원의 이수 현황이라면 한 시스템 안에서 소속으로 나누는 편이 거의 항상 유리합니다.
실제로 분리해야 하는 건 세 층이다
한 시스템 안에서 고객사를 나눈다는 말은 막연하게 들리지만, 뜯어보면 층이 셋입니다.
1층 — 회원 소속: 이 학습자는 누구의 사람인가
모든 분리의 출발점입니다. 맑은이러닝 LMS는 회원정보관리에 회원소속관리·회원그룹관리·회원등급관리를 두고 있어, 고객사를 소속으로 등록하고 그 아래 부서나 차수를 그룹으로 묶는 구조를 만들 수 있습니다. 회원 목록에서도 회원소속으로 필터가 걸리기 때문에, 명단을 뽑거나 발송 대상을 고를 때 고객사가 첫 번째 기준이 됩니다.
여기서 실무적으로 걸리는 지점이 하나 있습니다. 한 사람이 두 고객사의 교육을 듣는 경우입니다. 계열사 이동, 파견, 겸직처럼 드물지 않게 생깁니다. 계정을 두 개 만들면 이수 이력이 갈라져 나중에 증빙을 뽑을 때 곤란해집니다. 소속을 어떻게 바꿔 달 것인지, 이전 소속에서 들은 과정의 이력을 어떻게 유지할 것인지는 구축 전에 규칙으로 정해 두는 편이 좋습니다.
2층 — 관리자 권한: 고객사 담당자에게 어디까지 열어줄까
두 번째 층이 다계정 운영의 진짜 어려운 부분입니다. 고객사 담당자가 "우리 직원 이수 현황 좀 보내 달라"고 매번 연락해 오면 그 응대만으로 하루가 갑니다. 그렇다고 관리자 계정을 그냥 열어 주면 다른 고객사 데이터까지 보입니다.
맑은이러닝 LMS는 회원유형을 회원·과정운영자·소속운영자·운영자·최고관리자로 나눠 관리하므로, 고객사 담당자를 소속운영자로 열어 자기 소속 회원과 과정만 다루게 하는 설계가 가능합니다. 본사는 최고관리자로 전체를 보고, 우리 회사 담당자는 맡은 고객사 범위만, 고객사 담당자는 자기 회사만 보는 3단 구조가 만들어집니다.
권한을 나눌 때 실제로 결정해야 하는 것은 기능 목록이 아니라 책임의 경계입니다. 명단 등록을 고객사에 맡길지, 수강 취소를 고객사가 직접 하게 할지, 수료 확정 권한은 누가 쥘지. 이 결정이 흐린 채 계정만 열면, 나중에 "왜 우리 직원이 수료 처리가 안 됐냐"는 문의가 생겼을 때 책임 소재를 가리기 어렵습니다. 지회·분과 단위로 같은 고민을 하는 조직이라면 협회·학회 교육운영에 LMS가 필요한 이유에서 회원 구조와 권한 위임을 함께 다룬 부분을 참고하시면 좋습니다.
3층 — 과정과 콘텐츠: 공통과 전용을 처음에 가른다
세 번째 층은 과정 설계입니다. 위탁 운영에서 가장 아까운 낭비가 같은 강의를 고객사 수만큼 다시 등록하는 일입니다.
기준은 단순합니다. 콘텐츠와 과정은 공통으로 만들고, 달라지는 것만 차수로 나눕니다. 강의와 문제은행은 한 벌만 두고, 개강일·수료 기준·안내 문구처럼 고객사마다 다른 항목은 차수 단위로 다르게 잡습니다. 고객사 전용으로 제작한 콘텐츠만 해당 소속에 한정해 노출하면 됩니다. 과정카테고리를 내부·외부·고객사 전용처럼 트리로 나눠 두면 관리자 화면에서도 섞이지 않습니다.
업무별로 무엇을 공통으로 두고 무엇을 나눌까
설계를 시작하면 항목마다 "이건 공통인가 분리인가"를 판단하게 됩니다. 자주 걸리는 것들을 미리 정리했습니다.
| 업무 | 보통 이렇게 간다 | 미리 정해야 할 것 |
|---|---|---|
| 회원 등록 | 고객사별 명단을 엑셀로 일괄 등록하고 소속을 붙인다 | 등록 주체가 우리인지 고객사인지 |
| 과정 개설 | 공통 과정을 만들고 고객사별 차수를 연다 | 전용 과정이 필요한 고객사가 어디인지 |
| 수강신청 | 담당자가 일괄 배정하거나 학습자가 직접 신청 | 승인 절차를 둘지, 누가 승인할지 |
| 수료 기준 | 과정 차수 단위로 진도·평가 기준을 설정 | 고객사마다 기준이 다른지, 통일할지 |
| 수료증 | 인증서템플릿을 만들어 발급 | 고객사 로고가 들어간 서식이 필요한지 |
| 독려 발송 | 미이수자를 걸러 메일·SMS·쪽지로 일괄 발송 | 발신 명의를 우리로 할지 고객사로 할지 |
| 보고·정산 | 소속 기준으로 이수 현황과 매출을 집계 | 보고 주기와 양식, 정산 단위 |
| 공지·게시판 | 전체 공지와 고객사별 공지를 나눈다 | 고객사 전용 공지가 필요한지 |
이 중 담당자 시간을 가장 많이 잡아먹는 것은 보고와 독려입니다. 고객사가 열 곳이면 매달 열 번 같은 엑셀을 만들고, 마감 전에 열 번 미이수자를 추립니다. 회원 목록과 수강 목록에서 소속으로 걸러 바로 메일·SMS·쪽지를 보내고 EXCEL로 내려받는 흐름을 처음부터 소속 기준으로 잡아 두면, 이 반복이 클릭 몇 번으로 줄어듭니다. 마감 관리 방법은 미이수자 자동 독려 세팅에 따로 정리해 두었습니다.
시스템보다 먼저 정할 것: 계약과 개인정보
기술 설계보다 앞서는 것이 있습니다. 남의 직원 정보를 우리 시스템에 담는 일이기 때문입니다.
교육을 대신 운영한다는 것은 고객사의 개인정보를 넘겨받아 처리한다는 뜻입니다. 위탁하는 쪽과 받는 쪽의 역할, 처리 목적과 항목, 보관 기간, 재위탁 가능 여부, 계약이 끝났을 때 데이터를 어떻게 돌려주고 파기할지가 계약 문서에 정리되어 있어야 합니다. 개인정보 처리 위탁에 관한 구체적 요건은 관계 법령과 지침에 따르므로, 실제 계약서 문구는 발행 시점(2026-08) 기준으로 관할 지침과 법률 자문을 통해 확인하시기 바랍니다.
시스템 쪽에서 미리 잡아 둘 것은 세 가지입니다. 첫째, 계약 종료 시 그 고객사 데이터만 골라낼 수 있는가. 소속으로 구분되어 있지 않으면 이 작업이 통째로 어려워집니다. 둘째, 고객사 담당자 계정을 회수하는 절차가 있는가. 담당자가 퇴사했는데 계정이 살아 있으면 그대로 구멍이 됩니다. 회원 상태를 정상·중지로 관리해 즉시 막을 수 있어야 합니다. 셋째, 이수 기록을 언제까지 보관할 것인가. 교육 이력의 보관과 파기 기준은 학습자 개인정보와 교육이력, 얼마나 보관하고 언제 파기하나에 정리해 두었습니다.
여러 고객사의 명단과 이수 기록이 한 시스템에 모이는 구조라, 인프라의 신뢰도가 곧 계약의 조건이 되기도 합니다. 맑은소프트의 LMS는 국내 최초 CSAP(클라우드 보안인증, Cloud Security Assurance Program) 인증을 받은 LMS이며, 상용 LMS 중 유일한 CSAP 인증 LMS입니다. 운영 사양으로는 동시접속 약 5,000명 대응과 데이터 4중 백업을 갖추고 있어, 고객사별 교육 마감이 겹치는 시기의 접속과 이수 기록 보존을 함께 뒷받침합니다.
도입 전에 정리해 둘 여섯 가지
시스템을 보러 다니기 전에 손에 쥐고 있어야 비교가 정확해집니다.
첫째, 고객사 목록과 예상 증가 속도. 지금 몇 곳이고 1년 뒤 몇 곳일지에 따라 설계가 달라집니다.
둘째, 고객사가 요구하는 것이 사이트인가 현황인가. 이 한 줄이 시스템 분리 여부를 가릅니다.
셋째, 권한 3단 그림. 본사·우리 담당자·고객사 담당자가 각각 무엇을 할 수 있는지 종이에 적습니다.
넷째, 공통 과정과 전용 과정의 비율. 대부분 공통이라면 한 시스템 설계의 이점이 큽니다.
다섯째, 보고 양식과 주기. 고객사에 보내는 문서를 실제로 한 장 가져와서, 그 항목이 시스템에서 그대로 나오는지 확인합니다.
여섯째, 계약 종료 시나리오. 데이터 반환·파기 절차가 계약서와 시스템 양쪽에 있어야 합니다.
정리: 나누는 것은 시스템이 아니라 경계다
위탁·다계정 운영의 어려움은 시스템이 부족해서가 아니라 경계가 흐려서 생깁니다. 누구의 학습자인지, 누가 어디까지 볼 수 있는지, 무엇을 공통으로 쓰고 무엇을 전용으로 둘지 — 이 세 가지가 정해지면 나머지는 설정의 문제입니다. 반대로 이 셋이 흐린 채 시스템만 늘리면, 고객사가 열 곳일 때 엑셀 열 개와 로그인 열 개를 관리하게 됩니다.
고객사가 늘면서 운영이 무거워지고 있다면, 먼저 위의 여섯 가지를 정리해 보시길 권합니다. 자체 구축과 클라우드 임대 중 무엇이 맞는지는 자체개발 vs 클라우드 임대 LMS에서 비용·리스크 기준으로 비교해 두었고, 우리 고객사 구조에 어떤 분리 설계가 맞는지는 무료 상담에서 실제 운영 방식에 맞춰 함께 짚어 드립니다.