표지 한 장이 번호를 흔들었다: index에 너무 많은 의미를 담았던 경험

표지를 추가하는 일은 화면 하나를 넣는 작업처럼 보였다. 그런데 교육 뷰어에서는 표지를 학습 번호에 포함하면 안 됐고, 퀴즈는 원래 배열 위치와 별도의 번호가 필요했다. 기존 index를 그대로 쓰던 곳마다 의미를 다시 확인해야 했다.

번호가 틀렸다는 것은 규칙이 숨었다는 뜻

배열의 위치는 기계적으로 정해진다. 사용자에게 보이는 번호는 제품 규칙으로 정해진다. 모든 장면을 셀지, 표지를 뺄지, 퀴즈만 셀지에 따라 같은 장면의 번호가 달라진다. 이 규칙을 렌더링 중간에 index - coverCount처럼 흩어 놓으면 앞쪽 장면이 바뀔 때 영향을 추적하기 어렵다.

당시에는 원래 index를 유지하면서 quizIndex를 별도로 만들고, 표지를 제외한 번호를 보여 주는 방법을 고민했다. 돌아보면 원본 값을 덮어쓰지 않는 것이 중요했다. 화면 번호를 맞추려고 배열 위치까지 바꾸면 콘텐츠 조회와 이동 로직이 영향을 받기 때문이다.

한 번 계산하고 이름으로 구분하기

지금 다시 한다면 장면 목록에서 표시용 모델을 만드는 단계에 번호 규칙을 모으겠다. 아래는 그 방향을 설명하는 의사 데이터다.

type SceneView = {
  sceneId: string;
  sourceIndex: number;
  learningNumber: number | null;
  quizNumber: number | null;
};

번호가 없는 표지는 null로 표현할 수 있다. 0이라는 숫자에 “표지라서 없음”이라는 의미까지 부여하지 않는 것이다. 이렇게 하면 버튼 패널은 표지 수를 다시 계산하기보다 전달받은 표시 정보를 사용하면 된다.

조건 검사는 첫 항목에서 끝나지 않았다

콘텐츠 종류를 판단할 때 첫 번째 항목만 보는 것도 비슷한 문제였다. 한 장면에 여러 콘텐츠가 들어갈 수 있다면, 조건이 전체 목록에 대한 것인지 특정 항목에 대한 것인지 먼저 정해야 한다. some과 every의 선택은 문법 문제가 아니라 “하나라도”와 “모두” 중 어느 요구인지의 문제다.

이런 작은 번호 작업이 데이터 변환의 가치를 알려 줬다. 화면 컴포넌트가 매번 규칙을 해석하게 하기보다, 한 곳에서 의미를 계산해 이름을 붙이는 편이 변경에 강했다. 다음에는 표지 없는 자료와 연속 표지가 있는 자료를 함께 놓고 번호부터 확인하겠다.

관련 기록: 교육 콘텐츠 상태 경계 회고