cmi5는 xAPI를 LMS의 패키지·등록·실행 규칙과 묶는 학습데이터 설계입니다. AU, registration, session ID, LRS, moveOn을 한 증거 사슬로 연결하고, LMS 밖 업무 경험을 과장 없이 결합하는 데이터 계약과 조달 기준을 설명합니다.

cmi5 학습데이터 설계: LMS 밖 업무 경험까지 증거로 연결하는 법

월요일 데이터 회의에 세 개의 화면이 열린다. LMS에는 과정 수료 명단이 있고, 현장 앱에는 점검 결과가 있으며, CRM에는 고객 대응 기록이 있다. 교육담당자는 “교육 뒤 업무가 달라졌는가”를 묻지만 세 시스템은 같은 사람, 같은 과제, 같은 시점을 서로 다른 방식으로 기록한다. 데이터팀은 이름과 날짜로 파일을 합친다. 동명이인과 재수강이 섞이고, 한 사람이 과정을 두 번 실행한 기록은 어느 업무사건과 연결해야 할지 알 수 없다.

문제는 데이터가 적어서가 아니다. 과정–등록–실행–행동–결과를 이어 주는 식별자와 규칙이 없다는 것이다. 수료 이벤트와 현장 수행 이벤트를 같은 저장소에 넣는 것만으로 증거가 되지는 않는다. 어떤 등록에서 어떤 학습활동을 실행했고, 누가 기록을 보냈으며, 어느 업무과제와 연결됐는지를 재구성할 수 있어야 한다.

cmi5는 xAPI를 전통적인 LMS의 과정 실행에 적용하기 위한 프로파일이다. 과정 구조를 가져오고, 학습자를 등록하고, LMS가 학습 콘텐츠인 AU(Assignable Unit)를 실행하며, 인증·세션·상태·완료 기준을 일관되게 전달하는 규칙을 더한다. cmi5 자체가 LRS도, 분석도구도, 역량평가 모형도 아니다. 데이터가 흩어지는 경계 가운데 LMS가 시작한 세션 학습을 안정적으로 묶는 계약이다.

기업교육이 내려야 할 판단은 “SCORM 대신 cmi5를 사자”가 아니다. 먼저 어떤 의사결정에 어떤 증거가 필요한지 정하고, cmi5가 책임질 범위와 LMS 밖 xAPI·업무시스템이 책임질 범위를 나눠야 한다. 그래야 과정 수료와 업무 경험을 연결하면서도 클릭을 역량으로, 상관을 교육효과로 과장하지 않는다.

수료와 현장 수행이 끊기는 곳은 이벤트가 아니라 식별자다

xAPI 문장은 보통 누가(actor), 무엇을 했고(verb), 어떤 대상에(object), 어떤 결과(result)를 남겼는지 표현한다. 표현력이 넓은 만큼 같은 행동을 서로 다른 동사·활동 ID·확장 필드로 기록할 수 있다. 공급자 A의 completed와 공급자 B의 완료 표현이 기술적으로 모두 유효해도, 조직이 같은 의미로 비교할 수 있다는 보장은 없다.

cmi5는 이 자유도 가운데 LMS 세션 학습에 필요한 공통 규칙을 고정한다. 공식 개념 문서가 보여 주듯 저자는 과정 패키지를 만들고, 관리자는 LMS에 가져와 학습자를 등록하며, LMS는 AU를 실행한다. LMS와 AU는 LRS에 문장을 보내고, AU는 LMS가 준비한 실행 정보를 가져온다.

cmi5 학습데이터 설계에서 과정 패키지·LMS·LRS·AU·등록·실행 관계를 보여 주는 공식 개념도

AICC/ADL cmi5 공식 문서의 개념도는 과정 패키지, LMS, LRS, AU와 세 역할의 관계를 보여 준다. 그림 자체는 DRAFT Nov 20 - 2020으로 표시된 설명용 개념도다. 현재 IEEE 승인 표준 상태를 뜻하지 않으며, 이 글에서는 데이터 흐름의 역할 분담을 설명하는 데만 사용한다.

한 줄의 수료 기록보다 중요한 것은 다음 식별자 층이다.

층	cmi5에서의 역할	끊겼을 때 생기는 오류
과정·AU	과정 구조와 별도 실행 가능한 학습 단위를 식별	어느 버전·활동을 수행했는지 구분 불가
actor	LMS가 인증한 학습자를 account로 표현	이메일·이름 변경과 동명이인 때문에 사람 연결 오류
registration	한 학습자의 한 과정 등록 인스턴스를 식별	재수강·반복교육·복습 기록이 섞임
session ID	한 번의 AU 실행 세션을 식별	중단·재실행·복수 탭의 문장을 구분하지 못함
statement ID·authority	한 사건과 그 기록 주체를 식별	중복·충돌·출처 불명 문장을 판정하지 못함
업무 증거 ID	티켓·작업지시·검사·산출물을 식별	학습 뒤 실제 적용을 추적할 수 없음

공식 규격에서 registration은 한 학습자의 한 과정 등록 인스턴스다. 과정 진행과 완료 뒤 review 동안 유지되며, 반복교육이나 재수강처럼 새 등록이면 새 registration을 만든다. session ID는 actor와 registration을 바탕으로 한 번의 AU 실행을 식별하며 LMS가 생성한다. 둘을 하나로 취급하면 “같은 과정에 다시 등록한 것”과 “같은 등록에서 콘텐츠를 다시 연 것”을 구분할 수 없다.

cmi5는 xAPI에 과정·등록·실행 규칙을 더한다

cmi5의 범위는 생각보다 명확하다. 현재 공개된 Quartz 규격은 LMS가 AU를 실행하는 과정, 실행·런타임 환경, LMS–AU 사이의 데이터 전송, AU가 사용하는 과정 정의, 과정 구조 가져오기·내보내기, LMS 보고 요구사항을 다룬다. 이 범위 밖의 xAPI 사용은 cmi5 규격 밖이라고 명시한다.

따라서 cmi5가 정하는 것은 “무엇이 역량인가”보다 “LMS 세션에서 누가 무엇을 어떤 조건으로 기록할 것인가”다.

저자는 하나 이상의 AU와 과정 구조 XML을 만든다.
AU는 ZIP 안에 포함할 수도 있고 외부 URL로 참조할 수도 있다.
관리자는 과정 구조를 LMS로 가져오고 학습자를 등록한다.
LMS는 endpoint, fetch, actor, registration, activityId를 실행 URL에 넣는다.
AU는 fetch URL에서 LRS 접근용 인증 토큰을 한 번 가져온다.
LMS와 AU는 같은 registration과 session ID를 문장에 넣는다.
LMS는 moveOn 규칙에 따라 AU·블록·과정의 충족 여부를 계산한다.

이 구조는 “콘텐츠가 LMS 밖에 있다”와 “활동이 cmi5 밖에 있다”를 구분하게 한다. 원격 서버나 모바일 앱의 콘텐츠도 LMS가 cmi5 규칙으로 AU를 실행하면 cmi5 세션 안에 들어올 수 있다. 반대로 CRM에서 자연스럽게 발생한 영업 활동은 같은 LRS에 저장하더라도 자동으로 cmi5 문장이 되지 않는다.

패키지–등록–세션–문장이 하나의 증거 사슬을 만든다

학습데이터 설계는 이벤트 목록이 아니라 증거 사슬을 설계하는 일이다. 각 단계는 앞뒤 단계의 식별자와 판정 규칙을 보존해야 한다.

과정 패키지·버전
  → 학습자 등록(registration)
    → AU 실행(session ID)
      → cmi5 defined / allowed statements
        → 적용할 업무과제
          → 업무 산출물·품질 결과
            → 교육의 기여에 대한 제한된 판단

과정 패키지는 cmi5.xml을 루트에 둔 ZIP일 수도 있고, 외부 콘텐츠를 참조하는 XML일 수도 있다. cmi5는 모든 자료를 하나의 ZIP 안에 넣도록 강제하지 않는다. 이 점은 분산 콘텐츠와 콘텐츠 서비스 운영에 유리하지만, URL·버전·폐기·접근권한의 책임까지 사라지는 것은 아니다.

registration은 등록 인스턴스를 묶고, session ID는 한 번의 실행을 묶는다. xAPI statement ID는 한 사건 기록을, authority는 누가 그 사실을 주장했는지를 보여 준다. 그 다음 업무시스템의 티켓·작업지시·검사 ID를 연결해야 실제 적용으로 이동한다. 마지막 단계에서야 품질·속도·안전·고객 결과를 볼 수 있다.

이 사슬이 있다고 인과가 자동으로 생기지는 않는다. 같은 사람이 학습 뒤 성과를 냈다는 연결은 시간순서와 공존을 보여 줄 뿐이다. 과제 난도, 관리자 지원, 도구 변경, 팀 구성 같은 다른 설명을 배제하지 못한다. cmi5는 인과평가 표준이 아니라 재현 가능한 노출과 활동 기록의 기반이다.

AU 한 번 실행에도 인증·상태·종료가 먼저 움직인다

AU는 단순한 콘텐츠 파일이 아니다. LMS에서 별도로 실행되고 추적·관리되는 단위다. 공식 AU 구현 흐름은 실행 전에 학습자 인증과 권한, registration이 준비돼 있어야 하며, 실행 뒤에는 토큰·상태 문서·에이전트 프로필을 가져오고 initialized 문장을 보낸 뒤 학습 이벤트를 처리하는 구조를 보여 준다.

cmi5 AU가 LMS 실행부터 인증 토큰·상태·프로필·initialized·completed·passed·failed·terminated 문장으로 이어지는 공식 구현 흐름

AICC/ADL 공식 AU 흐름도는 초기화와 종료 사이에서 추가 문장, 완료, 합격·불합격이 어떻게 분기되는지 보여 준다. 이 도표는 구현 순서를 설명하는 자료이며 모든 현업 업무사건이 AU여야 한다는 뜻은 아니다.

cmi5 defined 문장은 아홉 개 동사를 사용한다. 보내는 쪽과 의미가 다르므로 단일 완료 상태로 합치면 안 된다.

주체	동사	운영상 의미
LMS	`launched`	AU 실행을 시작하고 실행정보를 준비함
AU	`initialized`	AU가 상태를 읽고 세션 처리를 시작함
AU	`completed`	학습자가 AU의 관련 자료를 경험함
AU	`passed` / `failed`	정한 판정 기준을 통과하거나 통과하지 못함
LMS	`abandoned`	비정상 종료된 이전 활성 세션을 닫음
LMS	`waived`	다른 근거로 AU 요구를 면제·충족 처리함
AU	`terminated`	AU가 세션 처리를 정상 종료함
LMS	`satisfied`	블록 또는 과정의 moveOn 조건을 충족함

규격은 cmi5 defined 문장의 동사 중복을 제한하고, 같은 등록의 AU에서 passed와 failed를 함께 쓰지 못하게 하며, failed가 passed 뒤에 오지 못하게 한다. 이 제약은 상태를 일관되게 계산하기 위한 것이다. 그러나 “completed”가 곧 업무 숙련이라는 뜻은 아니다. 학습자가 관련 자료를 모두 경험했다는 사실과 직무 수행 품질은 다른 증거다.

moveOn에는 Passed, Completed, CompletedAndPassed, CompletedOrPassed, NotApplicable 다섯 값이 있다. LMS는 이 기준으로 AU가 충족됐는지 판정하고, 블록이나 과정의 모든 AU가 조건을 충족하면 satisfied를 기록할 수 있다. 어떤 값을 쓸지는 교육목표와 판정 위험에 따라 정해야 한다. 단순 안내를 Passed로 만들거나 고위험 실습을 Completed만으로 통과시키면 기술적으로 맞아도 교육적으로 틀린다.

아홉 개 동사를 모아도 업무성과가 되지는 않는다

cmi5는 규격이 정한 동사 외의 문장도 허용한다. AU가 보내는 cmi5 allowed 문장은 initialized와 terminated 사이에 있어야 하고 같은 cmi5 세션 식별자를 포함한다. 예를 들어 시뮬레이션 안의 선택, 도움요청, 반복시도처럼 과정의 세부 행동을 xAPI로 기록할 수 있다.

그러나 allowed 문장은 cmi5의 세션 관리와 충족 규칙에 자동으로 사용되지 않는다. 더 많이 기록한다고 moveOn 판정이 더 타당해지는 것도 아니다. 클릭, 영상 위치, 마우스 이동을 모두 수집하면 분석할 데이터는 늘지만 직원의 판단력이나 업무수행을 보여 주지 못할 수 있다.

행동 이벤트를 증거로 쓰려면 세 질문이 필요하다.

의미: 이 사건은 어떤 업무능력이나 판단을 나타내는가.
품질: 발생 여부뿐 아니라 정확성·난도·오류비용을 어떻게 판정하는가.
용도: 콘텐츠 개선, 코칭, 자격, 인사평가 가운데 어디에 사용할 것인가.

같은 데이터라도 용도가 바뀌면 필요한 품질과 권리보호가 달라진다. 학습경로 추천에는 대략적인 선호 신호가 쓸 수 있지만 자격 판정에는 검증된 과제와 평가자 일치도가 필요하다. 인사평가에 연결한다면 직원에게 자료원·판정 로직·정정·이의제기 경로를 더 분명히 알려야 한다.

LMS 밖 업무 경험은 cmi5가 아니라 증거 계약으로 잇는다

제목의 “LMS 밖”을 가장 조심해서 이해해야 한다. cmi5의 핵심 사용사례는 학습자가 LMS 화면에서 콘텐츠를 실행하는 상황이다. LMS 밖 CRM·MES·고객상담·코드저장소·현장점검에서 발생한 사건은 그 자체로 cmi5 범위가 아니다. 이 사건들은 별도의 xAPI 프로파일이나 업무데이터 계약으로 기록하고, 분석 단계에서 학습 증거와 연결해야 한다.

연결 계약에는 최소한 다음을 둔다.

계약 항목	cmi5 세션 학습	LMS 밖 업무 증거
사람	LMS가 제공한 actor account	HRIS·SSO와 매핑한 안정적 가명 식별자
활동	AU activityId·publisher ID	업무과제·역량·시스템의 영속 IRI 또는 기준 ID
묶음	registration·session ID	프로젝트·티켓·작업지시·평가 회차 ID
사건	defined·allowed statement	합의한 업무 동사와 결과 스키마
출처	LMS·AU authority	CRM·MES·평가자·센서 등 기록 주체와 생성 방식
품질	moveOn·masteryScore·중복 규칙	난도·루브릭·검증상태·결측·오류 규칙
사용	과정 진행·보고	코칭·운영개선·자격·인사판정별 허용 범위

actor를 이름이나 이메일 문자열로 직접 합치지 않는다. 조직의 신원관리 계층에서 안정적 내부 ID를 만들고, 원래 신원과의 대응표 접근을 최소화한다. 활동 ID도 과정명이나 티켓 제목처럼 바뀌는 문구가 아니라 지속되는 식별자를 사용한다. 역량과 업무과제를 연결할 때는 누가 언제 어떤 근거로 매핑했는지 버전을 남긴다.

학습세션과 업무사건의 시간 창도 정의해야 한다. 교육 종료 뒤 처음 만난 고객상담, 다음 설비점검, 다음 코드리뷰처럼 실제 적용기회를 기준으로 삼는다. 단순히 30일 안의 모든 성과를 교육에 귀속하지 않는다. 적용 기회가 없었던 직원과 있었던 직원, 과제 난도, 관리자 승인, 시스템 변화도 함께 기록한다.

사건 사전은 개발 문서가 아니라 HRD의 측정 계약이다

cmi5 프로젝트를 API 연동으로 시작하면 개발자는 필드를 만들 수 있어도 HRD가 무엇을 주장할지는 남는다. 먼저 한 장의 사건 사전(event dictionary)을 만든다.

질문	합의 예시
어떤 결정을 내릴 것인가	과정 개선, 코칭 배정, 인증 중 하나로 목적을 제한
어떤 사건이 필요한가	실행·초기화·완료·판정·종료와 핵심 연습 2~3개
무엇을 같은 활동으로 볼 것인가	AU·과정·버전·업무과제의 영속 ID 규칙
무엇이 성공인가	moveOn과 별도로 실제 업무품질 판정선 정의
누가 사실을 주장하는가	LMS, AU, 현업시스템, 관리자·평가자 authority 구분
언제 연결을 중단하는가	목적 종료, 보존기간 만료, 동의·권한 변경, 품질 미달

그 다음 가상의 학습자 한 명이 아니라 실패 사례로 테스트한다. 같은 과정 재수강, AU 중단 후 재실행, 네트워크 단절, 중복 문장, 잘못된 mastery score, 이전 세션 abandoned, 외부 콘텐츠 URL 변경, 계정 이동, 퇴직·재입사, 업무시스템의 지연 전송을 넣는다. 정상 경로만 통과하는 연동은 운영 증거가 아니다.

대시보드도 수료율보다 사슬의 건강도를 먼저 본다. registration 누락률, session 종료 완전성, 중복·거부 문장률, identity 매핑 실패율, 업무과제 연결률, 기록 지연, 출처 불명 비율, 삭제·보존 규칙 이행률을 본다. 이 지표가 안정된 뒤에야 전이와 성과를 해석한다.

IEEE 화면의 ‘Active PAR’은 조달 문구를 더 정확하게 만든다

2026년 7월 22일 기준 IEEE SA의 P9274.3.1 페이지는 상태를 Active PAR로 표시하고 PAR 승인일을 2023년 2월 15일로 제시한다. 같은 페이지의 Working Group Details에는 승인된 Active Standards가 없다고 나온다. 즉 P9274.3.1을 이미 승인·발행된 IEEE 표준처럼 표현하면 안 된다.

cmi5 관련 IEEE P9274.3.1이 2026년 7월 현재 Active PAR이며 승인된 Active Standard가 아님을 보여 주는 공식 화면

IEEE SA 공식 프로젝트 페이지는 P9274.3.1의 제목, Active PAR, PAR 승인일 2023-02-15, 오픈소스 프로젝트와 Apache 2.0 CLA를 표시한다. PAR은 표준 개발 프로젝트 승인 상태이지 완성 표준의 발행을 뜻하지 않는다. 완료 시점은 이 화면에서 추정하지 않는다.

현재 운영에 참고할 공개 cmi5 규격은 AICC/ADL 저장소의 Quartz 1st Edition이며 개정 이력은 2016년 6월 1일을 표시한다. ADL의 35쪽 Best Practices Guide는 2021년 6월 14일 자료이고, 현재 CATAPULT 공식 문서가 계속 연결하고 있다. 오래됐다는 사실과 공식 구현자료라는 역할을 함께 적어야 한다.

따라서 RFP와 계약서에는 “IEEE cmi5 인증” 같은 넓은 표현보다 다음을 쓴다.

구현 대상 cmi5 규격의 stone·edition·commit 또는 고정 URL
함께 쓰는 xAPI 버전과 LRS 적합성 범위
지원하는 과정 패키지 형식과 원격 AU 실행 방식
CATAPULT LMS Test Suite·Content Test Suite의 버전과 전체 결과
registration·session·재실행·abandoned·waived 테스트 케이스
defined와 allowed 문장의 보존·조회·내보내기 방식
공급자 종료 뒤 원본 문장·상태·과정 구조를 돌려받는 형식
보안, 개인정보, 보존·삭제, 접근권한은 상호운용성과 별도 심사

적합성 테스트를 통과해도 우리 회사의 업무 증거 설계가 타당하다는 뜻은 아니다. 규격 적합성, 보안 인증, 데이터 품질, 교육평가 타당성은 서로 다른 판정선이다.

작은 직무 하나에서 증거 사슬을 끝까지 검증한다

전사 학습기록을 한 번에 통합하지 않는다. 적용기회가 자주 생기고 결과를 비교할 수 있는 직무 하나를 고른다. 예를 들어 고객 문의 분류, 설비점검, 코드리뷰처럼 업무사건이 분명한 과제가 적합하다.

첫째, 과정 안에서 필요한 defined 문장과 핵심 allowed 문장만 정한다. 둘째, registration과 session이 재수강·재실행을 제대로 구분하는지 본다. 셋째, 다음 업무사건의 ID와 품질 판정을 연결한다. 넷째, 직원과 관리자가 기록을 읽고 실제 활동을 재구성할 수 있는지 확인한다. 다섯째, 연결되지 않은 사건과 잘못 연결된 사건을 별도 표본으로 감사한다.

성공 기준은 “LRS에 데이터가 들어왔다”가 아니다. 같은 등록과 세션을 재현할 수 있고, 현장 증거의 출처와 품질을 설명할 수 있으며, 직원이 어떤 데이터가 어떤 결정에 쓰였는지 이해할 수 있어야 한다. 연결률이 높아도 잘못된 연결이 늘면 실패다.

한국 기업에서는 LMS, HRIS, SSO, CRM·MES, 데이터웨어하우스의 소유 부서가 다르다. HRD는 기술팀에 필드 목록만 넘길 것이 아니라 학습 주장, 적용기회, 판정선, 데이터 용도와 이의제기 책임자를 정해야 한다. 보안·개인정보·노무 담당자는 actor 매핑, 업무행동 수집, 인사평가 전용, 보존·삭제를 별도 검토한다.

cmi5의 가치는 모든 경험을 한 형식으로 바꾸는 데 있지 않다. LMS가 시작한 학습의 경계를 분명하게 만들고, 그 밖의 업무 증거와 연결할 때 무엇이 cmi5이며 무엇이 아닌지를 설명할 수 있게 하는 데 있다. 좋은 학습데이터는 많이 이어진 데이터가 아니라, 어디서 시작해 어떤 규칙으로 연결됐는지 다시 설명할 수 있는 데이터다.