Blog

과정중심평가 이야기가 나오면서 '학생 화면을 비디오로 녹화하자'는 논의가 있었습니다. 그런데 비디오로 바꾸면 답안 하나가 10KB 안팎에서 50~100MB로 불고, 지금은 되는 자동 채점·검색·썸네일이 막힙니다. 정말 비디오여야 할까 따져보다 HLS까지 처음 만났고, 낯선 개념을 제가 이미 아는 것(델타 저장, 미러링 스트림, before/after 모델)에 대보며 이해한 기록입니다.

테스트를 안 쓰던 사람이 회귀 방어에 기대게 되고, 그 방어가 뚫리는 걸 보고 다시 테스트를 의심하게 된 과정입니다. 스토어 초기값 [[]] 때문에 빈 캔버스가 '데이터 있음'으로 통과했고, 예시 데이터 하나뿐인 테스트는 초록인 채로 다른 페이지를 깨뜨렸습니다. TDD는 이미 몇 년째 돌아가는 서비스라 순서를 못 지켰고, 대신 고친 것만 되돌려 테스트가 빨개지는지 확인하는 단계를 붙였습니다. 변이 테스트는 코드가 아니라 테스트를 위한 테스트입니다.

폴백을 기본으로 두자는 쪽과, 조용한 실패를 키우니 걷자는 쪽으로 팀에서 대치했습니다. 마침 그날 코드에서 양쪽 사례가 하나씩 나왔어요. 값을 문자열로 감싼 폴백 하나가 학생 7명 전원을 오판하게 만들었고, 반대로 대체 그림을 연결하지 않은 자리는 화면이 백지가 됐습니다. 결론은 한쪽이 이기는 게 아니었습니다 — '얼마나 두느냐'가 아니라 '무엇을 채우느냐'로 축을 바꾸니 둘 다 답이 나왔습니다.

학습 리포트의 썸네일이 세 가지 방식으로 비어 있었습니다. 카드가 캔버스를 최대 54% 잘라내고 있었고, 학생 7명 전원이 '활동 있음'으로 잘못 판정됐고, 배경색은 통째로 사라졌습니다. 증상은 셋인데 원인은 하나였어요 — 데이터를 합치는 코드가 응답의 일부만 읽고 나머지를 버리고 있었습니다. 코드만 읽고 세운 가설 세 개가 실제 데이터 앞에서 전부 뒤집혔고, 고치는 도중 제가 만든 회귀는 화면을 직접 열어본 뒤에야 잡혔습니다.

기획에서 받은 교구 오류 4건을 원인까지 찾아 고치고 완료로 보고했습니다. dev에서 눌러보니 2건이 그대로였어요. 하나는 수정이 완전히 무효였고(엉뚱한 층을 고쳤습니다), 하나는 규칙이 반쪽이었습니다(분기를 잘못된 위치에 끼웠습니다). 둘 다 의도는 맞았고, 그 의도를 기계가 실행하는 언어로 옮기는 마지막 구간에서 갈렸습니다. 하나는 0을 '값 없음'으로 본 조건문, 하나는 런타임이 나중에 덮어쓰는 초기 속성값이었어요.