브라우저를 넣은 앱도 일상 작업은 빨라야 한다

데이비 슈스터(Dayvi Schuster)는 브라우저 기반 데스크톱 앱이 여러 플랫폼과 기능을 지원하더라도 메뉴를 열고 파일을 탐색하는 기본 작업까지 느려서는 안 된다고 주장한다. 프레임워크나 하드웨어를 탓하기보다 실제 사용 조건에서 지연을 측정하고, 백그라운드 작업이 인터페이스를 막지 않도록 설계해야 한다는 의견이다.

그는 200ms 이하의 응답을 좋은 수준으로 보는 웹 지표인 Interaction to Next Paint를 소개하면서도, 이 기준 아래라고 사람에게 지연이 보이지 않는 것은 아니라고 짚는다. 60Hz 화면의 한 번 새로고침 간격은 약 16.7ms이므로 200ms는 약 12회에 해당한다. 모든 작업을 한 프레임 안에 끝내야 한다는 뜻은 아니지만, 앱이 반응을 보여주기 전에 꼭 끝나야 하는 일이 무엇인지 따져야 한다는 설명이다.

슈스터는 Electron이 Chromium의 프로세스 모델과 레이아웃·렌더링·접근성 기능을 제공하는 장점이 있지만, 앱이 무엇을 불러오고 메모리에 유지하며 사용자 입력과 동시에 처리할지는 별도로 결정해야 한다고 말한다. Electron의 성능 안내도 메인 프로세스와 렌더러 프로세스를 막지 말고 작업을 미루거나 상호작용에 우선순위를 두라고 권한다.

그가 제시하는 실무적인 점검 방법은 실제 사용에 가까운 조건에서 데이터를 넣고 다른 앱도 켠 채 백그라운드 작업 중 탐색해 보는 것이다. 평균뿐 아니라 느린 경우도 살펴야 한다. 파일을 동기화하는 동안에도 이미 저장된 파일을 열거나 설정을 보는 작업은 가능해야 하며, 앱이 느리다는 사용자의 불만을 원인 분석이 부족하다는 이유로 무시해서는 안 된다고 강조한다.

슈스터는 자신이 Zig와 Qt로 만든 zenkai에서도 의도적으로 넣은 페이드 효과가 지연을 만들었다고 설명한다. 그의 성능 측정에서 애니메이션을 끈 리눅스 빌드는 창의 페인트 핸들러에 약 47ms 만에 도달했지만, 페이드가 끝날 때까지는 약 270ms가 걸렸다. 이 수치는 페인트 처리 진입과 페이드 완료 시점을 측정한 것이며 모니터에 픽셀이 표시되는 시점은 측정하지 않았다. 그는 네이티브 도구를 쓰는 것만으로 빠른 앱이 보장되지 않으며, 작은 로컬 도구에 브라우저 실행 환경을 포함하기로 했다면 사용자에게 드는 비용을 확인해야 한다고 말한다.

결론적으로 슈스터는 버튼이 느리다고 매번 프레임워크를 바꾸거나 앱을 다시 쓰라는 뜻은 아니라고 선을 긋는다. 먼저 앱이 무엇을 하는지 찾아 불필요하게 인터페이스를 막는 작업을 고치고, 원하는 경험을 현재 도구로 구현하기 어렵다면 프레임워크 선택도 다시 검토하라는 주장이다.