내 컴퓨터에서 빠른 앱, 느린 환경에서도 쓸 만할까? — 측정 전에 멈춘 설계 기록

이 글은 제목의 질문에 답하지 못한다. 같은 조건에서 이미지 하나를 바꾸면 스크립트 과제의 정확한 완료 시간이 달라지는지 살펴보려 했지만, 실제 과제를 수행한 성능 측정은 한 번도 하지 않았다(NOT RUN). 여기서는 가상 상품 목록과 비교 절차를 어떻게 준비했고 왜 측정 전에 멈췄는지 설명한다. 계획한 측정을 끝냈더라도 사람에게 쓸 만한 앱인지까지 판단할 수는 없다. 마지막에는 별도 시험 환경에서 검토할 점검표를 남겼다.

이 글의 목차

빠르기 전에, 무엇이 완료인가?

준비한 앱에는 가상 상품 120개가 있다. 자동화 스크립트가 Desk 분류를 고르고, C037 상품의 이미지가 준비되기를 기다린 뒤 한 개를 장바구니에 넣고 확인 화면을 여는 과제다. 완료 기준은 Desk 선택, 화면에 보이는 C037의 이름 ‘Blue triangle stand’·가격 1200·재고 표시 ‘In stock’, 0보다 큰 원본 크기로 디코딩된(화면에 그릴 수 있게 푼) 목표 이미지, 다른 상품 없이 C037 한 행만 있는 장바구니, 수량 1·단가 1200·합계 1200, 완료 문구 ‘Basket confirmed’가 독립 정답표와 맞는 것이다. 금액은 가상 단위이며, 필요한 파일의 로딩 실패나 처리되지 않은 앱 오류도 없어야 한다.

앱이 스스로 내놓은 ‘성공’ 표시만 믿어서는 이 기준을 검사할 수 없다. 화면에 실제로 나타난 값과 앱 밖에 따로 적어 둔 정답을 맞춰야 한다. 빠르게 끝나도 수량이 틀리면 완료로 세지 않는다.

스크립트에는 목표 상품의 위치를 지정하는 선택자가 들어 있지만, 이번 실행에서 실제 화면의 상품을 찾아내는 동작은 검증하지 못했다. 사람이 상품을 찾고 판단하는 시간은 재지 않는다. 이 과제는 설계상 C037 이미지 준비를 기다리며, 미리 정한 변경 후보도 그 이미지의 축소다. 따라서 이미지 준비가 측정 경로에 들어가지만, 실제로 시간이 줄어들지와 그 크기, 사람의 일과 얼마나 맞는지는 모른다. 추적 기록에서 연결을 찾더라도 설계가 넣은 기다림일 수 있으며, 그것만으로 사람이 이미지를 기다렸다거나 축소가 시간 차이의 원인이라고 입증할 수 없다. 크기를 바꾸면 전송·디코딩 조건이 함께 바뀌고 메모리 영향도 따로 분리해 재지 않는다. 변경 후보의 320×240은 표시 크기 160×120에 계획한 DPR 2를 곱한 값이지만, 이 계산은 시각 품질을 검증한 결과가 아니다.

화면이 빨리 반응했다는 지표만으로 과제가 정확히 끝났다고 볼 수는 없다. 예를 들어 INP(Interaction to Next Paint)는 상호작용 뒤 다음 화면 갱신(next paint)까지의 반응을 다루며, 다른 페이지로 이동하는 시간이나 그 뒤 이어지는 모든 작업이 끝나는 시간을 뜻하지 않는다. 장바구니가 정확히 채워졌는지는 별도 확인이 필요하다. INP 설명

비교 조건과 기다린 구간을 먼저 적는다

계획은 같은 Mac과 Chrome에서 브라우저의 표시 영역 390×844 CSS 픽셀, 화면 표시 단위와 기기 픽셀의 비율(DPR) 2, 줌 100%를 고정하는 것이었다. 컴퓨터 처리 속도를 늦추는 CPU 4배 감속 설정, 내려받기 1600 Kbps(초당 킬로비트)·올리기 750 Kbps·지연 150ms도 예정했다. 이는 적용과 검증을 마친 측정 조건이 아니라 설계값이다. 좁은 화면과 감속 설정을 썼다고 특정 휴대전화를 시험한 것이 되지는 않는다. Chrome 문서도 숫자로 지정하는 통신 제한을 안내하지만, 문서가 있다는 사실은 이 실행 환경에서의 적용 증거가 아니다. 설정 안내

브라우저가 저장한 자원을 재사용하는 HTTP 캐시는 두 조건으로 나눴다. 캐시 비움 조건은 매번 HTTP 캐시와 과제 상태를 초기화하고 중립 페이지에서 새 문서로 진입한다. 측정 중에는 일반 캐시 기능을 켜 두며, 측정 내내 캐시를 막는 ‘Disable cache’와는 다르다. 매회 준비 후 재사용 조건은 매 측정 전에 다음 순서를 따른다. 해당 버전의 캐시를 비운다 → 시간을 재지 않고 과제를 한 차례 끝낸다 → 캐시는 유지하면서 장바구니를 포함한 과제 상태를 초기화한다 → 중립 페이지에서 새 상품 목록 문서로 이동해 측정하고 필요한 자원의 재사용을 확인한다. 방문 기록이나 이전 화면 전체를 복원하는 bfcache는 사용하지 않는다. 준비 실행은 측정 횟수에 넣지 않는다. 이 설계는 단순 새로고침만으로 두 조건을 구별하지 않으며, 서버·운영체제 캐시를 따로 통제하지 않아 캐시 외의 준비 효과도 섞일 수 있다.

타이머는 페이지 이동 명령 직전에 시작하고, 화면 갱신을 위한 콜백을 두 차례 거친 뒤 장바구니의 모든 독립 완료 기준이 여전히 맞는다고 실행기가 관측하면 멈추도록 설계했다. 조건은 50ms 간격으로 확인한다. 이 확인 간격, 이동·조작 대기, 자동화 도구와 브라우저 사이의 통신 시간은 포함하고 브라우저를 켜는 시간은 제외한다. 두 콜백은 화면을 그릴 기회를 줄 뿐 실제 디스플레이에 표시된 정확한 시각을 증명하지 않는다. 타이머 검증도 하지 않아 이런 부가 시간의 크기는 모른다. 과제 제한은 60초다. 목표 이미지 준비 전후 구간도 나눠 남기되, 준비 전 구간 전체를 이미지 다운로드 시간이라고 부르지 않는다.

이 설계에서는 변경 후보를 활성화하기 전에 기록을 확인하도록 했다. Chrome의 성능 기록은 화면 그리기와 실행 작업을 시간 순서로 살펴보는 도구다. 큰 파일이 있다는 사실만으로 그 파일이 과제를 늦췄다고 판단할 수는 없다. 성능 기록 안내

이 설계에서는 C037 이미지 작업이 기다림에 연결됐다는 기록이 있을 때만, 그 이미지 하나를 1200×900에서 320×240으로 바꾸기로 했다. 표시 크기는 160×120 CSS 픽셀로 유지하고 다른 상품·로직·로딩 정책은 그대로 둔다. 작은 이미지에서도 필요한 모양이 보이는지 확인해야 한다. 그 연결을 찾지 못하면 변경본 비교를 시작하지 않는다. 이번에는 진단 과제 자체를 실행하지 못했으므로 이미지가 병목인지도 모른다.

준비에서 확인한 것과 실제 실행 컴퓨터에서 멈춘 지점

2026년 10월 15일에는 원본 A와 별도로 아직 비교에 사용하지 않는 변경 후보 B, 정답표, 로컬 서버 코드와 검사 도구를 만들었다. 초기 오프라인 테스트 8개는 통과했다. 그러나 구현과 분리한 검토 단계에서 ‘한 개 추가’를 일부러 수량 2로 바꾸거나 완료 문구를 틀리게 만든 두 사례에서도 테스트 8개가 모두 통과해 정상 종료 코드 0을 반환했다. 이 검사들이 통과했다는 사실만으로 실제 완료 조건을 검증했다고 볼 수는 없다.

이후 화면 구조를 흉내 낸 오프라인 검사에서 두 오류를 거부하도록 보완했다. 실제 브라우저의 화면 배치·이미지 디코딩·클릭 동작까지 검증한 결과는 아니다. 10월 26일의 별도 검토도 실제 실행 컴퓨터의 준비 점검만 허용했으며, 성능 과제를 시작할 준비가 됐다는 판정은 아니었다. 실제 브라우저에서 전체 완료 기준을 검증하는 기능도 확인하지 못했다.

같은 날 실제 실행 컴퓨터에서 한 차례 설정 점검을 진행해 Chrome을 실행했다. 준비용 화면의 구조·문서·다운로드·업로드·캐시·저장된 데이터 재사용에 관한 여섯 검사 항목은 통과했다. 이는 준비용 자료에 대한 판정이며, 상품 과제 완료나 상품 자원의 전송·캐시 재사용, CPU 4배 감속과 1600/750 Kbps·150ms 설정의 실제 적용을 입증하지 않는다.

전체 판정은 실패였다. 브라우저 성능 기록의 파일 전송과 따로 남긴 전송 기록을 서로 연결하는 검사를 통과하지 못했다(linked-transfer). 이 연결은 어떤 전송이 기다림과 관련됐는지 추적하기 위한 근거다. 연결 실패의 원인은 밝혀지지 않았으며, 이 실패만으로 Chrome의 전송 자체가 잘못됐다거나 앱이 느리다고 결론낼 수 없다.

실패 즉시 중단했고 후속 검증 단계와 재시도는 하지 않았다. 미리 정한 ‘이번 시도가 실패하면 측정을 시작하지 않는다’는 중단 규칙에 따라 방법을 설명하는 글로 범위를 정했다. CPU·통신 제한의 실효 검증과 실제 과제 흐름 검증 등도 남아 있었으므로, 추적 문제 하나만 고치면 측정 준비가 끝난다고 말할 수도 없다.

결과가 없을 때도 남길 수 있는 점검표

계획은 각 캐시 조건에서 버전마다 다섯 번을 측정하는 것이었다. 캐시 비움 조건에서 A1/B1부터 A5/B5까지, 그다음 매회 준비 후 재사용 조건에서 B1/A1부터 B5/A5까지 진행한다. 이 순서로 시간 경과에 따른 변화를 없앨 수는 없다. 모든 B 측정은 이미지 경로 진단, 변경 범위 확인, 파일 해시 고정, 시각 품질 확인과 예비 실행을 통과해야 하는 조건부 계획이었다. 이 관문들은 완료되지 않았다. 아래는 결과값이 아닌 미실행 현황이다.

B는 비교에 사용하지 않는 후보로 남았다. 과제 진단·예비 실행·캐시 준비 실행도 하지 않았다. 중앙값·최솟값·최댓값은 모두 없으며, ‘0초’가 아니다.

이번 설계의 대상은 계정·개인정보·외부 추적이 없는 로컬 가상 앱이다. 아래 질문도 운영 서비스가 아닌 별도 시험 환경과 가상 데이터에 적용하는 범위로 제안한다. 실제 사용자 정보가 들어간 실행 기록을 외부에 보내거나 공유 시스템의 통신 설정을 바꾸는 절차는 포함하지 않는다.

• 무엇이 화면과 데이터에 남아야 정확한 완료인가?
• 그 완료를 기다리게 한 구간과 자원을 기록에서 연결할 수 있는가?
• 변경은 한 가지이며, 원래의 완료 조건과 시각적 정보를 유지하는가?
• 같은 기기·설정·캐시 절차로 반복하고 실패도 함께 남길 수 있는가?

이 설계에서 측정한다면 버전·캐시 조건별로 모든 예정 회차와 대체 회차를 보존하고, 시도 수·정확한 완료·시간 초과·완료 기준 오류·무효 시도를 구분해 보고한다. 느린 정상 결과도 버리지 않으며, 이상값 삭제나 중간 수리 후 같은 실험 재개는 허용하지 않는다. 60초 제한에 걸린 경우는 성공한 60초가 아니다. 프로토콜 변경 없이 일시적 원인이 해결된 무효 시도에만 조건별 최대 한 번의 표시된 대체 측정을 허용하며, 시간 초과나 느린 성공은 대체하지 않는다. 유효한 정상 완료가 다섯 번보다 적으면 불완전한 조건으로 표시한다. 성공한 시도만의 중앙값·범위를 제시하더라도 실제 횟수를 적고 다섯 번 비교의 속도 개선으로 주장하지 않는다. 비교는 같은 캐시 조건 안에서만 한다. 반복 결과는 기술적 요약이며, 다섯 번으로 일반 사용자 집단의 효과나 통계적 유의성을 주장하지 않는다.

AI에는 “빨라지게 고쳐줘”보다 “완료 기준은 이것이다. 느려 보이는 곳부터 고치기보다, 먼저 완료를 기다리게 한 구간의 근거와 아직 모르는 점을 보여주고, 근거가 있을 때 한 가지 변경을 제안해 달라”고 요청할 수 있다. 이는 이번 준비에서 정리한 방법이며 효과를 입증한 처방은 아니다. 이번 설계에서는 완료 기준과 기다림의 연결을 확인하지 못하면 변경본 비교를 시작하지 않고, 같은 비교 안에서 다른 수정으로 바꾸지도 않는다. 이는 이 실험의 중단 기준이며, 모든 결함 수정에 필요한 일반 법칙은 아니다.

이 글은 AI를 활용해 자료 조사와 초안 작성을 보조했으며, 작성자가 최종 원고를 검토하고 수정 방향을 결정했습니다.