음성 학습·합성을 관리하는 로컬 웹앱에서 ‘엔진 상태 확인’은 가벼운 생존 확인처럼 보인다. 실제로는 Python, PyTorch, CUDA, 한국어 처리 환경을 차례로 검사하는 무거운 사전 작업이었다. 결과를 5분 동안 캐시하면서도 검사 프로세스에는 최대 45초를 허용했다. 상태를 묻는 요청 하나가 작은 진단 API가 아니라 콜드 스타트 작업이 된 셈이다.
문제는 무거운 검사 자체보다 그 요청이 놓인 자리였다. 첫 화면은 스크립트, 녹음 목록, 엔진 상태를 한 묶음의 Promise.all로 기다렸다. 안내와 기존 녹음은 엔진 없이도 표시할 수 있지만, 세 요청 가운데 하나라도 끝나지 않으면 아무것도 그리지 않는 구조였다. 초기 요청에는 별도 마감이 없고 동시에 들어온 콜드 검사도 하나로 합쳐지지 않았다.
브라우저 측정에서 스크립트는 26ms, 녹음 목록은 30ms 만에 도착했다. 엔진 상태는 9,497ms가 걸렸다. 빠른 데이터 두 개를 이미 받은 브라우저가 약 9.5초를 더 기다린 이유는 네트워크나 화면 코드가 느려서가 아니다. 독립적으로 보여줄 수 있는 정보를 가장 무거운 진단과 함께 묶었기 때문이다.
뒤이은 캐시 경로의 직접 측정은 약 5ms, 8ms, 207ms였다. 이는 첫 지연을 반박하지 않는다. 콜드 경로와 웜 경로의 차이가 크면 평상시 측정은 빠르게 보이고 첫 방문만 오래 멈춘다. 평균 상태 응답만 기록하면 사용자가 마주치는 시작 병목을 놓치기 쉬운 조건이다.
스크립트와 녹음 목록은 먼저 그려야 한다. 엔진은 별도의 ‘확인 중’ 상태로 두고 요청에 제한 시간을 적용해야 한다. 무거운 콜드 검사는 직렬화하거나 진행 중인 한 번의 실행을 공유하는 편이 맞다. 이 변경은 아직 구현되지 않았다. 현재 구조에서는 진단 엔드포인트의 지연이나 실패가 엔진 기능만이 아니라 첫 화면 전체로 전파된다.