LRS: 학습기록이 무엇인지부터

LRS(Learning Record Store) 작업에서 내가 먼저 묻는 질문은 “어디에 쌓을까”가 아니다. 한 건의 학습기록이 무엇인지다. 단위가 없으면 대시보드도, 표준 연동도 해석 다툼으로 끝난다.

이 글은 정의가 숫자보다 먼저다의 프로젝트 단위 적용이다. 제품 구현 스펙이 아니라, 합의선을 긋는 순서다.

LRS가 하는 일

LRS는 학습 활동 기록을 받아 저장하고, 질의할 수 있게 두는 저장소다. 업계에서 자주 붙는 규약은 xAPI(Experience API)다. xAPI는 활동을 Actor / Verb / Object 형태의 statement로 표현한다.

이 정의를 공유하지 않은 채 이벤트 파이프만 올리면, 같은 “완료”가 제품마다 다른 뜻이 된다.

왜 저장소보다 정의가 먼저인가

현장에서는 대개 LMS 로그, 퀴즈 결과, 시청 시간, 출석처럼 이미 생긴 데이터부터 모으고 싶어 한다. 그건 자연스럽다. 다만 모은 뒤에 정의를 붙이면 비용이 크다.

• 같은 verb를 다른 팀이 다르게 쓴다.
• Object ID가 수업/콘텐츠/세션 중 무엇을 가리키는지 흔들린다.
• “진도 80%”가 시청 길이인지, 필수 활동 완료인지 갈라진다.

xAPI 스펙이 강조하는 것도 형식만이 아니다. statement가 다른 시스템에서도 같은 의미로 읽히게 만드는 계약이다. (ADL xAPI Spec)

내가 고정하는 순서

1. 관측 단위: 한 statement에 넣을 최소 사건
2. 식별자: Actor / Object를 무엇으로 안정적으로 가리킬지
3. 허용 Verb 집합: 팀이 쓸 동사와 쓰지 않을 동사
4. 실패 조건: 어떤 입력이 오면 저장하지 않고 거절할지
5. 그다음 LRS 적재, 질의, 화면

제품 UI는 5번 이후에야 의미가 있다. 4번이 없으면 “일단 다 넣자”가 되고, 나중에 지표가 서로 안 맞는다.

아직 관측하지 않는 것

이 사이트 LRS 프로젝트에 붙인 시그널은 xAPI / 해석이다. 공개 가능한 KPI 퍼센트는 아직 없다. 그래서 붙이지 않는다. 대신 남아 있는 질문은 분명하다.

• 어떤 활동을 statement로 승격할지
• 어떤 로그는 운영 이벤트에만 둘지
• 해석 레이어가 statement 원문을 깨지 않게 하는 방법

한 줄로

LRS를 “학습 데이터 창고”로만 보면 설계가 늦는다. 학습기록의 단위를 계약으로 고정한 뒤 창고를 짓는 편이 싸다.

다음 편은 STLink 쪽에서 명부/프로파일이 같은 역할을 하는 순간을 적을 예정이다.