저작도구 라이선스 함정 — 클라우드 종속과 콘텐츠 이전 비용의 실체

🔍 요금제 하나 바뀌었을 뿐인데, 콘텐츠 전부가 발이 묶였다

기업교육 담당자 B씨는 클라우드 기반 저작도구로 3년간 사내 이러닝 과정 80여 개를 만들어 왔다. 어느 날 저작도구 업체가 요금제 구조를 개편하면서 팀 단위 라이선스 비용이 크게 올랐고, 예산 재검토에 들어간 회사는 다른 도구로 갈아타는 방안을 검토했다. 그런데 막상 콘텐츠를 옮기려 하니 문제가 드러났다. 완성된 과정들은 그 저작도구의 클라우드 편집 화면 안에서만 수정할 수 있는 독점 포맷으로 저장돼 있었고, SCORM으로 내보낸 결과물은 재생은 가능하지만 원본 편집은 불가능한 '박제된' 패키지였다. 결국 회사는 80개 과정 중 상당수를 처음부터 다시 만들어야 했다. 저작도구 라이선스 계약이 콘텐츠의 자유를 얼마나 제한할 수 있는지, 이 사례는 조용히 보여준다.

이 상황은 특정 기업 하나의 불운이 아니라 클라우드 저작도구 업계 전반에서 반복적으로 보고되는 구조적 패턴이다. 실제로 업계를 대표하는 저작도구 업체조차 자사 블로그에서 "잠긴 이러닝 코스에서 벗어나는 방법"이라는 글을 따로 게재해 이 문제를 공식적으로 다루고 있을 정도다. 클라우드 종속과 콘텐츠 이전 비용은 더 이상 추상적인 리스크가 아니라, 예산 담당자가 계약서에 서명하기 전에 반드시 계산해야 할 구체적인 숫자다.

더 까다로운 점은, 이 문제가 계약서를 아무리 꼼꼼히 읽어도 잘 보이지 않는다는 것이다. 라이선스 계약서는 대부분 '이용 요금'과 '이용 기간', '저작물 이용 범위' 정도만 다루지, "구독을 해지하면 편집 가능한 원본을 어떤 형태로 돌려받는가"라는 질문에는 침묵한다. 발주 담당자 입장에서는 계약서에 없는 내용을 문제 삼기 어렵고, 공급자 입장에서도 먼저 나서서 설명할 유인이 크지 않다. 그 결과 락인 리스크는 계약이 끝난 후, 즉 가장 협상력이 약해진 시점에야 비로소 눈에 보이게 된다.

🕰️ 저작도구가 클라우드로 옮겨가기까지, 표준은 무엇을 해결하려 했나

SCORM이 태어난 이유

미국 국방부 산하 ADL(Advanced Distributed Learning) 이니셔티브는 1999년 웹 기반 학습 콘텐츠를 서로 다른 시스템에서도 재사용할 수 있게 하자는 목표로 프로젝트를 시작했고, 2001년 SCORM(Sharable Content Object Reference Model)의 첫 공식 버전을 내놓았다. 이후 여러 차례 개정을 거쳐 2009년 'SCORM 2004 4th Edition'을 끝으로 사실상 표준화가 마무리됐다. SCORM의 핵심 아이디어는 콘텐츠를 ZIP 패키지로 감싸 어떤 LMS에도 넣을 수 있게 만드는 것이었지만, 동시에 콘텐츠가 반드시 LMS와 같은 서버·도메인에 있어야 한다는 구조적 제약도 함께 따라왔다.

xAPI와 cmi5, 그리고 여전히 남은 숙제

2011년 SCORM의 차세대 버전으로 'Tin Can API' 초안이 공개됐고, 2013년 4월 정식으로 'xAPI(Experience API)' 1.0.0이 발표되며 모바일·오프라인 학습 기록까지 추적할 수 있는 유연한 표준으로 자리잡았다. 2016년 6월에는 xAPI의 실행·인증·구조 규칙을 표준화한 cmi5가 공개되면서, SCORM과 달리 콘텐츠를 LMS와 다른 서버에 두고도 통신할 수 있는 길이 열렸다. 표준 자체는 20년 넘게 발전해 왔지만, 정작 상용 저작도구들이 이 표준을 얼마나 충실히 지원하고 내보내기를 자유롭게 허용하는지는 업체마다 크게 다르다 — 이것이 오늘날 락인 문제의 기술적 뿌리다.

💰 클라우드 저작도구, 가격은 어떻게 움직였나

업계를 대표하는 클라우드 저작도구 스위트의 2026년 기준 공개 가격을 보면, 개인·소규모 팀 기준 연간 약 1,399달러(전체 스위트) 또는 스탠드얼론 제품 기준 약 499달러 수준이며, 좌석(seat) 수가 늘어날수록 15~30%의 볼륨 할인이 적용되는 구조다. 이 업체는 2024년 7월 1일 요금 체계를 개편한 바 있는데, 이는 클라우드 SaaS 특성상 공급자가 언제든 가격 정책을 바꿀 수 있고 고객은 이를 그대로 받아들이거나 이탈해야 하는 전형적인 SaaS 협상력 구조를 보여준다.

클라우드 비용 전반으로 시야를 넓히면 문제는 더 뚜렷해진다. Flexera의 2024 클라우드 현황 보고서에 따르면 응답 기업의 89%가 멀티클라우드 전략을 갖고 있다고 답했으며, 그 핵심 이유 중 하나가 벤더 락인 방지였다. 같은 보고서에서 기업의 절반 이상이 클라우드 예산의 40% 이상이 방지 가능한 실수나 비효율로 낭비되고 있다고 추산했다. 저작도구 하나에 국한된 통계는 아니지만, '클라우드 서비스에 묶이는 비용'이 결코 사소하지 않다는 업계 전반의 인식을 보여주는 수치다.

📌 한눈에 보기 — 클라우드 저작도구의 연간 라이선스 비용은 겉으로 보이는 구독료뿐이다. 여기에 전환 시 콘텐츠 재제작 인건비, 전환 기간 중 이중 라이선스 비용, 신규 도구 학습 비용까지 더하면 실제 '락인 비용'은 표면 가격의 몇 배에 달할 수 있다.

💻 왜 저작도구는 유독 락인이 심한가

독점 포맷과 클라우드 전용 편집

많은 클라우드 저작도구는 편집 가능한 원본을 자체 클라우드 서버에만 저장하고, 사용자에게는 최종 결과물(SCORM/HTML5 패키지)만 내보내도록 허용한다. 이 경우 구독을 해지하면 이미 만든 콘텐츠를 '재생'은 할 수 있어도 '수정'은 할 수 없는 상태가 된다. 문제집 한 페이지를 고치기 위해 처음부터 다시 만들어야 하는 상황이 발생하는 이유다.

SCORM 표준 자체의 구조적 한계

SCORM 콘텐츠는 원칙적으로 LMS와 같은 서버·도메인에 있어야 정상 작동한다는 제약이 있다. 이는 콘텐츠를 다른 LMS로 옮길 때마다 재패키징과 재검증 작업이 필요하다는 뜻이며, 저작도구가 cmi5나 최신 xAPI를 지원하지 않는다면 이 제약에서 벗어날 방법이 없다.

전환 비용은 계약서에 적히지 않는다

구독료 인상이나 정책 변경 자체는 계약서·공지사항에 명시되지만, 콘텐츠를 다른 도구로 옮길 때 드는 재제작 인건비나 검수 시간은 어떤 계약서에도 적혀 있지 않다. 그 결과 예산 담당자는 '월 구독료'만 비교하고 전환 비용을 과소평가하는 실수를 반복한다.

표준 지원 여부는 마케팅 문구만으로 알 수 없다

또 하나의 함정은 저작도구 소개 페이지 대부분이 "SCORM 지원"이라고만 표기할 뿐, SCORM 1.2인지 2004인지, xAPI나 cmi5까지 지원하는지는 세부 문서를 뒤져야 확인할 수 있다는 점이다. 담당자가 도입 검토 단계에서 이 부분을 놓치면, 나중에 "SCORM은 지원하는데 원본 편집은 안 된다"는 사실을 전환 시점에야 알게 되는 경우가 많다.

📊 락인 리스크를 보여주는 산업 데이터

국내 클라우드 서비스 시장을 보면 2023년 기준 클라우드 서비스 공급기업은 총 2,389개였고, 이 중 SaaS 기업이 1,642개(68.7%)로 압도적 비중을 차지했다. 한국 클라우드 컴퓨팅 시장 자체는 2024년 약 39억 달러에서 2033년 116억 달러 규모로 연평균 12.36% 성장할 것으로 전망된다. SaaS가 클라우드 시장의 절대다수를 차지하는 흐름은 저작도구 시장에도 그대로 반영돼, 신규 출시되는 저작도구 대부분이 설치형이 아닌 구독형 클라우드 서비스로 나오고 있다.

시장이 SaaS 중심으로 재편될수록 '언제든 떠날 수 있는 자유'의 가치는 커진다. 그러나 실제로는 콘텐츠 이전 계획을 미리 세우지 않은 채 플랫폼을 도입했다가, 전환 시점에야 예상치 못한 시간과 비용을 마주하는 경우가 실무에서 반복적으로 보고된다.

🔍 실무에서 확인되는 세 가지 락인 패턴

업계 스스로 인정한 '잠긴 코스' 문제

업계를 대표하는 저작도구 업체가 직접 "잠긴 이러닝 코스에서 벗어나는 방법"이라는 지원 콘텐츠를 운영한다는 사실 자체가 의미심장하다. 이는 구독이 만료되거나 라이선스가 해지된 뒤 편집 권한을 잃은 콘텐츠가 실제로 다수 존재하며, 이것이 고객 문의로 이어질 만큼 흔한 문제라는 걸 공급자 스스로 인정한 셈이다.

구독 경제 전반의 '락인의 재무적 효과'

구독형 크리에이티브 소프트웨어를 둘러싼 국내 분석 콘텐츠는 사용자가 특정 도구에 익숙해지고 파일 생태계가 그 안에 쌓일수록, 가격에 불만이 있어도 전환하지 못하고 결제를 지속하는 심리적·구조적 현상을 "락인의 재무적 효과"로 짚는다. 이는 창작 도구 시장 전반에 나타나는 패턴이며, 저작도구 시장도 예외가 아니다 — 콘텐츠가 쌓일수록 이탈 비용은 기하급수적으로 커진다.

표준 미지원으로 인한 재제작 사례

이러닝 콘텐츠 제작 실무를 다루는 국내 업계 콘텐츠들은 플랫폼을 전환할 때 기존에 쌓인 콘텐츠와 데이터를 새 플랫폼으로 옮기는 과정에서 예상치 못한 시간과 비용이 발생할 수 있다고 공통적으로 경고하며, 애초에 이전 계획을 염두에 두고 콘텐츠를 관리해야 한다고 조언한다. 이는 원본 편집 파일을 저작도구 밖으로 정기적으로 백업해 두지 않으면, 전환 시점에 사실상 '콘텐츠를 다시 만드는' 선택지밖에 남지 않는다는 뜻이다. 재제작은 단순 반복 작업이 아니라 기획·스토리보드·검수를 처음부터 다시 거쳐야 하는 프로젝트이기 때문에, 콘텐츠 수가 많을수록 소요 인건비와 일정 지연 폭도 함께 커진다.

🧭 전문가들의 시각 — 락인은 피할 수 없는가

• 클라우드 개념을 설명하는 기술 문서들은 락인을 "제품·서비스의 품질과 무관하게 그것에서 벗어나는 것이 실질적으로 불가능해 계속 사용을 강제당하는 상태"로 정의한다. 즉 락인은 도구의 성능 문제가 아니라 전환 구조의 문제라는 시각이다.
• 구독 경제를 분석하는 국내 콘텐츠는 사용자가 도구를 욕하면서도 결제를 지속하는 현상의 배경에, 파일 포맷·협업 히스토리·팀 워크플로가 특정 생태계에 종속되는 '전환 마찰'이 있다고 짚는다.
• 클라우드 마이그레이션 실무를 다루는 분석은 전환 실패의 첫 번째 원인으로 "명확한 전략 부재와 부족한 계획"을 꼽으며, 마이그레이션은 단순히 데이터를 옮기는 작업이 아니라 조직의 기술·비즈니스 목표가 함께 맞물려야 성공하는 프로젝트라고 강조한다.

세 관점을 종합하면 결론은 명확하다. 락인은 도구 자체의 결함이 아니라 계약·아키텍처 설계 단계에서 전환 가능성을 얼마나 고려했는지의 문제이며, 사후에 해결하기보다 도입 전에 예방하는 편이 훨씬 저렴하다.

다만 세 시각 사이에는 온도차도 있다. 기술 문서들은 락인을 구조적 현상으로 담담하게 설명하는 반면, 구독 경제 분석 콘텐츠는 이를 소비자 심리·전환 마찰의 문제로 좀 더 비판적으로 짚는다. 마이그레이션 실무 분석은 반대로 "락인 자체보다 계획 부재가 더 큰 원인"이라며 책임의 무게중심을 공급자보다 도입 조직의 준비 부족 쪽에 둔다. 세 시각의 차이는 결국 "누구의 책임인가"에 대한 답이 다르다는 것이며, 실무자 입장에서는 어느 쪽이 맞든 결국 도입 전 점검이라는 같은 결론에 도달한다는 점이 흥미롭다.

⚠️ "클라우드는 무조건 위험하다"는 반론에 대하여

여기서 균형을 잡을 필요가 있다. 클라우드 저작도구가 곧 락인이고, 온프레미스나 자체 구축 도구가 곧 안전하다는 이분법은 지나치게 단순하다. 온프레미스 도구도 특정 서버 환경·라이선스 서버·레거시 포맷에 종속되는 사례가 있고, 유지보수 인력과 서버 비용이라는 별도의 고정비가 발생한다. 클라우드 저작도구는 초기 도입 비용이 낮고 협업·버전 관리가 편리하다는 명확한 장점도 있다.

또한 모든 클라우드 저작도구가 동일한 수준으로 폐쇄적인 것도 아니다. SCORM·xAPI·cmi5 표준을 충실히 지원하고 원본 소스(편집 가능한 프로젝트 파일) 내보내기를 허용하는 도구라면, 클라우드 기반이라 해도 전환 시 리스크는 크게 줄어든다. 즉 문제의 본질은 '클라우드냐 아니냐'가 아니라 '표준을 얼마나 지키고, 원본을 사용자에게 얼마나 돌려주는가'에 있다.

실제로 조직 규모와 예산 상황에 따라 최선의 선택은 달라진다. 소규모 팀이 빠르게 콘텐츠를 만들어야 한다면 클라우드 저작도구의 초기 비용 이점이 훨씬 크게 작용할 수 있고, 반대로 수백 개의 콘텐츠를 장기간 운영해야 하는 대규모 조직이라면 원본 소유권을 명확히 챙길 수 있는 구조(자체 구축이거나, 원본 반출을 보장하는 SaaS)가 장기적으로 더 유리하다. 결국 이 글의 목적은 클라우드를 피하라는 것이 아니라, 어떤 선택을 하든 '전환 가능성'이라는 변수를 계약 전 의사결정표에 반드시 포함시키라는 것이다.

⚠️ 주의 — "클라우드=위험, 설치형=안전"이라는 단순화는 오해를 낳는다. 실제 위험 요인은 배포 방식이 아니라 원본 파일 반출 가능 여부와 표준 준수 수준이다.

⚖️ SCORM·xAPI·cmi5 이식성 비교

🗺️ 클라우드 저작도구 vs 자체 구축·온프레미스 비교

🗺️ 계약 전 반드시 확인할 락인 방지 체크리스트

1. 원본 파일 내보내기 가능 여부 확인 — 완성된 SCORM 패키지만이 아니라, 편집 가능한 프로젝트 원본(예: 슬라이드·인터랙션 소스)을 사용자가 직접 다운로드할 수 있는지 계약 전에 문서로 확인한다.
2. 지원 표준의 버전까지 확인 — 단순히 "SCORM 지원"이라고만 표기돼 있는지, xAPI·cmi5까지 지원하는지 구체적 버전을 확인한다. cmi5를 지원하면 콘텐츠 위치 제약에서 자유로워진다.
3. 요금제 변경 이력 조사 — 해당 업체가 최근 2~3년간 가격 정책을 몇 차례 바꿨는지 공개 자료·커뮤니티를 통해 확인한다.
4. 전환 시나리오를 미리 시뮬레이션 — 도입 전에 "만약 3년 뒤 다른 도구로 옮긴다면 무엇을, 어떻게 옮길 것인가"를 구체적으로 그려보고 계약서에 반영할 조항을 정리한다.
5. 정기 백업 체계 수립 — 원본 소스를 저작도구 내부에만 두지 않고 사내 저장소에 주기적으로 백업하는 프로세스를 운영 초기부터 마련한다.

🚀 저작도구, 이렇게 도입하면 락인을 줄일 수 있다

담당자가 실제로 적용할 수 있는 절차는 다음과 같다.

1. 도입 검토 단계에서 후보 도구별로 '원본 반출 가능 여부'와 '지원 표준 버전'을 나란히 표로 정리해 비교한다.
2. 계약 전 공급자에게 "구독 해지 시 편집 가능한 원본을 어떤 형태로 받을 수 있는가"를 서면으로 질의하고 답변을 남겨둔다.
3. 파일럿 기간 동안 실제로 소규모 콘텐츠 하나를 만들어 내보낸 뒤, 다른 저작도구나 LMS에서 재편집·재생이 되는지 직접 검증한다.
4. 운영 단계에서는 원본 파일을 정기적으로 사내 스토리지에 백업하고, 특정 도구의 클라우드에만 의존하지 않는 이중 보관 체계를 유지한다.
5. 계약 갱신 시점마다 요금제 변동 이력과 표준 지원 현황을 다시 점검해, 조건이 악화됐다면 전환 비용과 잔류 비용을 비교해 재협상하거나 이전을 검토한다.

이 다섯 단계는 결국 하나의 원칙으로 요약된다 — 콘텐츠는 도구의 부산물이 아니라 회사의 자산이며, 자산의 소유권과 이동 가능성은 계약 전에 확인해야 할 협상 항목이라는 것이다.

특히 여러 부서·현업 담당자가 동시에 저작도구를 쓰는 조직이라면, 계약 담당자 한 명이 아니라 실제 콘텐츠를 만드는 실무자들이 함께 파일럿 테스트에 참여하는 것이 좋다. 계약서상의 조건과 실제 편집 화면에서 체감하는 제약은 다를 때가 많고, 현업 담당자가 미리 한계를 파악해야 나중에 "계약할 때는 몰랐다"는 상황을 줄일 수 있다.

❓ 자주 묻는 질문

Q1. SCORM으로 내보내기만 되면 락인 걱정은 없는 건가요?

아니다. SCORM 내보내기가 된다는 것은 '재생'이 가능하다는 뜻일 뿐, 편집 가능한 원본을 확보했다는 뜻은 아니다. 완성된 SCORM 패키지를 수정하려면 원래 저작도구로 다시 열어야 하는 경우가 많아, 구독이 끊기면 사실상 수정이 불가능해진다.

Q2. cmi5를 지원하면 어떤 점이 달라지나요?

cmi5는 콘텐츠가 LMS와 같은 서버에 있어야 한다는 SCORM의 제약에서 벗어나게 해준다. 콘텐츠를 다른 위치에 두고도 xAPI 기반으로 학습 기록을 주고받을 수 있어, LMS나 저작도구를 교체할 때 유연성이 크게 높아진다.

Q3. 클라우드 저작도구 요금이 갑자기 오르면 어떻게 대응해야 하나요?

먼저 원본 파일 반출이 가능한지부터 확인해야 한다. 반출이 가능하다면 다른 도구로 이전하는 협상력을 가질 수 있고, 불가능하다면 재계약 외에는 선택지가 좁아진다. 계약 갱신 시점마다 이 조건을 재점검하는 것이 좋다.

Q4. 온프레미스나 자체 구축 저작도구로 바꾸면 락인 문제가 완전히 사라지나요?

락인의 형태가 바뀔 뿐 완전히 사라지지는 않는다. 자체 인력 의존, 서버 유지보수 비용, 특정 개발자에 대한 지식 종속 같은 다른 형태의 종속이 생길 수 있다. 다만 콘텐츠 원본의 소유권만큼은 명확해진다는 차이가 있다.

Q5. 이미 특정 저작도구로 많은 콘텐츠를 만들어 둔 상태인데, 지금이라도 대비할 수 있나요?

가능하다. 지금부터라도 원본 파일을 사내에 정기적으로 백업하고, 신규 제작분부터는 표준 지원 수준이 높은 도구나 형식을 우선 검토하는 것으로 리스크를 줄일 수 있다. 기존 콘텐츠 전체를 한 번에 옮기기보다, 조회수·수강 인원이 많아 활용도가 높은 핵심 과정부터 우선순위를 정해 단계적으로 전환하는 편이 현실적이며, 사용 빈도가 낮은 콘텐츠는 굳이 즉시 이전하지 않고 자연스럽게 폐기 수순을 밟도록 두는 것도 하나의 방법이다.

Q6. 저작도구를 고를 때 가격 외에 가장 먼저 봐야 할 것은 무엇인가요?

가격은 눈에 보이는 비용일 뿐이다. 더 중요한 것은 '해지 시 무엇을 가져갈 수 있는가'다. 편집 가능한 원본 반출 정책과 지원 표준 버전을 가격표보다 먼저 확인하는 것이 장기적으로 훨씬 큰 비용을 아낀다. 계약서에 이 조건이 명시돼 있지 않다면, 서명 전에 반드시 서면으로 질의해 답변을 근거 자료로 남겨두는 절차도 함께 챙기는 것이 좋다.

Q7. 저작도구 전환 비용은 대략 어떻게 추산해야 하나요?

구독료 차액만 비교해서는 안 된다. 기존 콘텐츠 중 재제작이 필요한 과정 수, 과정당 평균 제작 인건비, 전환 기간 중 발생하는 이중 라이선스 비용, 신규 도구 학습에 드는 시간까지 더해 총소유비용(TCO) 관점에서 계산해야 실제 전환 비용에 가까운 수치가 나온다. 예를 들어 과정당 재제작에 기획·스토리보드·촬영·편집·검수를 포함해 며칠에서 몇 주가 걸린다면, 콘텐츠 수십 개를 옮겨야 하는 조직은 그 인건비만으로도 새 도구의 몇 년 치 구독료를 넘어설 수 있다. 전환을 결정하기 전에 이 계산을 먼저 해보는 것이 순서다.

📎 참고 자료

• Cloudflare — 벤더 종속(Vendor Lock-in)이란 무엇인가
• Articulate — How to Get Rid of Locked E-Learning Courses
• Articulate — Pricing for Articulate 360
• Articulate Support — We Updated Articulate 360 Pricing on July 1, 2024
• xAPI.com — Comparison of SCORM, xAPI and cmi5 eLearning Standards
• SCORM.com — SCORM Versions: The Evolution of the eLearning Standards
• ADL Initiative — cmi5 and the xAPI SCORM Profile
• 클로브 블로그 — 락인(Lock-in)의 재무적 효과
• 디지털서비스 이용지원시스템 — 2025 플렉세라(Flexera) 클라우드 보고서 분석

콘텐츠 원본의 소유권과 표준 준수를 처음부터 확보하고 싶다면 저작도구 페이지에서 SCORM 1.2·2004·cmi5를 지원하는 제작 구조를 확인할 수 있다. 도입 전 상담이 필요하다면 상담 신청을, 요금 구조는 요금제 페이지를, 실제 화면은 데모를 참고하면 된다.