[출결 앱 개발 로그 08] 배포 직전 전체 흐름 다시 보기 #성능 #운영QA
기능이 모두 보인다고 운영 준비가 끝난 것은 아니었다. 실제 도장에서는 태블릿 카메라가 오랫동안 켜져 있고, 여러 회원이 연달아 QR을 보여주며, 사범님은 모바일에서 기록을 빠르게 고쳐야 한다.
배포 직전에는 개별 컴포넌트가 아니라 사용자 행동에서 데이터 저장과 화면 피드백까지의 전체 흐름을 다시 점검했다.
느림을 한 가지 원인으로 보지 않았다
처음 측정한 홈 HTML은 약 18KB였고 반복 요청은 약 0.52초, 첫 요청은 약 0.86초였다. 그런데 사용자는 4초 이상 느리다고 느꼈다. 앱 시작 시 의도적으로 재생한 웰컴 영상이 가장 큰 이유였다.
영상은 유지하되 최초 실행 한 번으로 제한했다. 서버 쪽에서는 실행 지역을 데이터베이스와 가까운 싱가포르로 옮겼다. 홈의 월간 출석왕은 매초 바뀔 필요가 없어 60초 동안 재사용하고, 출석이 바뀌면 즉시 새로 계산하게 했다.
이후 같은 환경의 홈 응답은 약 224~390ms로 줄었다.
로그인 뒤 모든 정보를 기다리지 않았다
회원 로그인 뒤 QR, 기록, 배지, 칭호를 모두 불러오면 첫 화면이 늦었다. QR 토큰과 이름을 먼저 표시하고 대표 칭호는 가벼운 후속 요청으로 가져왔다. 기록과 리워드는 별도 메뉴에서 로드한다.
속도 개선은 계산을 빠르게 하는 일만이 아니라, 지금 필요한 결과를 먼저 전달하는 일이었다.
장시간 카메라를 가정했다
키오스크에서 가장 오래 살아 있는 기능은 QR 스캐너다. 화면을 나간 뒤에도 카메라 스트림이나 타이머가 남으면 배터리와 발열에 영향을 줄 수 있다.
다음 항목을 집중적으로 확인했다.
- 화면 전환 시 카메라 스트림 종료
- 자동 재시작이 겹치지 않는지
- 빠른 연속 인식이 여러 요청을 만들지 않는지
- 앱이 백그라운드로 갔을 때 불필요한 동작을 멈추는지
- timer, event listener, audio 자원을 정리하는지
- 요청 중 화면을 떠났을 때 뒤늦은 응답이 잘못된 상태를 만들지 않는지
스캔이 성공하면 카메라를 잠시 멈추고 결과를 보여준 뒤 다음 사람을 받을 준비를 한다. 처리 중 같은 QR이 계속 보이더라도 화면이 반복해서 바뀌지 않게 했다.
성공과 실패를 같은 색으로 보여주지 않았다
출석 시스템에서 가장 중요한 문장은 “출석이 저장됐다”이다. 단순히 QR을 읽었다는 사실과 서버가 기록을 완료했다는 사실을 분리했다.
- 처리 중: 기다리는 상태
- 완료: 이름, 큰 체크, 짧은 소리와 진동
- 이미 처리됨: 중복임을 분명히 설명
- 실패: 개발자 오류 대신 다시 시도할 방법 제공
- 카메라 문제: 원인별 안내와 PIN 대안
회원 화면에는 오늘 출석 상태와 저장 시각을 표시해 태블릿 화면을 놓쳤더라도 다시 확인할 수 있게 했다.
회귀 테스트 범위를 넓혔다
초기 12개 수준이던 테스트는 기능이 늘면서 33개까지 확대됐다. 다음 흐름을 반복해서 확인했다.
- 회원 로그인과 QR 표시
- 같은 날 여러 수업과 같은 수업의 반복 입력
- 주간·월간 경계와 서로 다른 날짜 계산
- Open Mat와 특별 세미나
- 출석 수정 뒤 보상 재계산
- 관리자 회원 추가·상태 변경·승급 이력
- 모바일·태블릿·PC의 주요 페이지
- 카메라 거부와 네트워크 실패 뒤 복구
- typecheck, lint, production build
화면 크기도 모바일, 세로 태블릿, 가로 태블릿, 데스크톱으로 나눠 확인했다. 특히 가로형 태블릿에서는 카메라와 상태가 스크롤 없이 보이는지를 완료 조건으로 삼았다.
아직 남은 현장 검증
자동 테스트로 확인하기 어려운 부분도 있다. 실제 태블릿을 하루 종일 켰을 때의 발열, 도장 조명에서의 QR 인식 거리, 성공음 크기, 불안정한 Wi-Fi에서의 체감은 현장에서 확인해야 한다.
현재 단계의 결론은 “모든 위험이 사라졌다”가 아니다. 다만 문제가 생겼을 때 사용자가 멈추지 않고 다음 행동을 선택할 수 있고, 개발자가 어느 흐름에서 문제가 발생했는지 다시 확인할 수 있는 제품에 가까워졌다.
출결 앱의 완성도는 기능 개수가 아니라, 매일 반복되는 작은 행동이 얼마나 흔들림 없이 이어지는지에서 결정됐다.