scene1과 UUID 사이: 교육 뷰어에서 ID의 역할을 다시 생각했다

교육 뷰어의 JSON을 만들 때 어떤 ID는 scene1, scene2처럼 직접 정해야 했고, 어떤 ID는 UUID로 생성해도 됐다. 처음에는 문자열 생성 방식의 차이로 보였다. 하지만 작업을 이어 갈수록 핵심은 이름이 아니라 그 값을 누가 참조하느냐에 있었다.

순서처럼 보이는 식별자

장면 이름에 숫자가 들어가면 배열 순서와 같다고 생각하기 쉽다. 그런데 앞에 장면을 삽입하거나 표지를 추가하면 문제가 달라진다. 화면의 세 번째 장면이 학습 문제의 세 번째 항목이라는 보장이 없다. 외부 도구가 특정 장면을 참조하고 있다면 화면 순서를 바꾸는 일이 참조를 바꾸는 일로 번질 수도 있다.

당시 CreateJson에서 장면과 내부 콘텐츠를 구성하며, 자동 생성할 값과 호출하는 쪽에서 넣어야 할 값을 구분할 필요가 있었다. 모두 UUID로 바꾸면 기존 규약을 놓치고, 모두 순번으로 만들면 독립적으로 다뤄야 할 콘텐츠까지 순서에 묶인다.

지금이라면 세 가지를 따로 적겠다

값	맡길 역할	바뀌는 시점
장면 ID	저장 상태와 외부 참조 연결	장면의 정체성이 바뀔 때
배열 위치	현재 재생 순서	장면을 이동할 때
표시 번호	사용자에게 보이는 학습 번호	표지·문항 포함 규칙이 바뀔 때

이 표는 당시 구현이 완벽히 이랬다는 뜻은 아니다. 그때의 질문을 지금 설계 기준으로 다시 정리한 것이다. 기존 형식이 scene1을 요구한다면 먼저 호환성을 지키되, 번호를 해석하는 규칙이 여러 컴포넌트에 퍼지지 않게 경계를 두겠다.

생성 시점도 계약의 일부였다

UUID 자체보다 중요한 것은 언제 생성하느냐다. 콘텐츠를 처음 만들 때 한 번 생성한 ID와 화면을 다시 그릴 때 생성한 ID는 전혀 다른 결과를 만든다. 후자는 저장해 둔 풀이 상태와 연결되지 않을 수 있다. JSON 생성기는 데이터를 만드는 도구이면서 이후 화면과 저장소 사이의 약속을 만드는 도구이기도 했다.

나는 이 일을 통해 사람이 읽기 좋은 이름과 시스템이 오래 참조할 이름을 구별하게 됐다. 작은 ID 규칙을 먼저 정하는 일은 과한 설계가 아니었다. 나중에 콘텐츠 순서를 바꿀 자유를 확보하는 작업이었다.

관련 기록: 교육 콘텐츠 플랫폼 개발 경험