버튼 하나 화면에 뜨는 데 몇 ms? Qt Quick의 '보이기까지 걸리는 시간' 이야기

화면에 뭔가 띄우는 건 정말 '즉시'일까요?

우리가 앱을 만들 때 visible = true 한 줄, 혹은 새 화면을 push 하는 코드 한 줄 쓰고 나면 당연히 "이제 보이겠지" 하고 넘어가잖아요. 그런데 사실 그 순간부터 실제로 사용자 눈에 픽셀이 그려지기까지는 생각보다 여러 단계를 거치거든요. 그 사이에 걸리는 시간이 얼마인지, 그리고 그 시간이 왜 중요한지를 Qt(C++ 기반 크로스플랫폼 UI 프레임워크) 진영의 컨설팅 회사 KDAB가 꼼꼼하게 측정해봤어요.

왜 이게 주목할 만하냐면, 요즘 UI는 "느리다"는 느낌이 데이터 한두 개 늦게 오는 것보다 반응이 한 박자 늦는 것에서 더 크게 와닿거든요. 버튼을 눌렀는데 0.1초 뒤에 화면이 바뀌면 우리는 무의식적으로 "이 앱 좀 버벅이네"라고 느껴요. 그래서 '보이기까지 걸리는 시간(time to visible)'은 체감 성능을 좌우하는 핵심 지표예요.

Qt Quick에서 화면이 그려지는 과정

Qt Quick은 QML이라는 선언형 언어로 UI를 짜요. 우리가 Rectangle이나 Image 같은 걸 선언하면 내부적으로 QQuickItem이라는 객체가 만들어져요. 그런데 이 아이템이 만들어졌다고 바로 그려지는 게 아니에요. Qt Quick은 씬 그래프(Scene Graph)라는 구조를 써요. 이게 뭐냐면, UI 요소들을 트리 형태로 정리해두고, 그걸 한꺼번에 GPU가 이해하는 형태로 변환해서 그리는 방식이에요. 화가가 캔버스에 즉석에서 하나씩 그리는 게 아니라, 그릴 목록을 정리한 다음 한 프레임에 몰아서 그리는 거죠.

그래서 visible = true를 호출하는 순간 실제로 일어나는 일은 이래요. 먼저 그 아이템이 "이제 그려져야 함" 상태로 표시되고, 다음 렌더 루프(render loop)가 돌 때 씬 그래프가 갱신되고, GPU가 한 프레임을 그려서 모니터에 내보내요. 여기서 핵심은 모니터가 보통 1초에 60번(60Hz) 화면을 갱신한다는 거예요. 즉 한 프레임은 약 16.6ms거든요. 운이 나쁘면 내가 막 요청한 그 직후에 이번 프레임이 이미 지나가버려서, 다음 프레임까지 기다려야 해요.

또 하나 중요한 게 Qt Quick은 렌더링을 별도 스레드에서 돌리는 'threaded render loop'와, UI 스레드에서 같이 돌리는 'basic render loop'를 상황에 따라 골라 써요. 어느 쪽이냐에 따라, 그리고 그 아이템을 처음 만들 때 텍스처를 GPU로 올리는 비용(이미지 같은 경우)이 끼면 첫 프레임이 더 늦어질 수 있어요. KDAB의 측정이 흥미로운 지점이 바로 여기예요. "한 줄 코드와 픽셀 사이"에 숨어 있는 이 지연을 실제로 계측해서, 어디서 시간이 새는지를 눈으로 보여준다는 거죠.

다른 UI 프레임워크와 비교하면

이 고민은 사실 Qt만의 것은 아니에요. 안드로이드에서도 'Choreographer'와 'vsync'를 기준으로 프레임을 맞추고, 첫 프레임이 늦는 'jank'를 잡으려고 다들 애쓰거든요. 웹 프론트엔드도 마찬가지예요. React에서 상태를 바꿔도 실제 DOM 페인팅은 브라우저의 다음 페인트 타이밍에 일어나니까, requestAnimationFrame 같은 걸로 프레임을 의식하면서 짜잖아요. 결국 어느 플랫폼이든 "논리적으로 보이라고 시킨 시점"과 "물리적으로 픽셀이 뜨는 시점"은 다르고, 그 간극을 줄이는 게 성능 엔지니어링의 본질이에요.

다만 Qt Quick은 임베디드 기기(자동차 계기판, 의료 장비, 키오스크처럼 사양이 빡센 하드웨어)에서 많이 쓰여요. 이런 환경은 GPU도 약하고 프레임 예산도 빠듯하기 때문에, 1~2프레임의 지연이 곧바로 사용성 문제로 이어져요. 그래서 Qt 진영에서는 이 '보이기까지의 시간'을 진지하게 측정하고 최적화하는 문화가 강한 편이에요.

한국 개발자에게 주는 시사점

임베디드나 데스크톱 앱을 Qt로 만드는 분이라면, 화면 전환이 느리게 느껴질 때 "내 로직이 느린가?"보다 먼저 "렌더 루프와 프레임 타이밍 때문인가?"를 의심해볼 가치가 있어요. 특히 무거운 화면을 미리 만들어두고(preload) 보일 때는 visible만 토글하거나, 이미지 텍스처를 미리 GPU에 올려두는 식으로 첫 프레임 비용을 분산시키면 체감이 확 좋아지거든요.

그리고 Qt를 안 쓰더라도 교훈은 똑같아요. '코드를 실행한 순간'과 '사용자가 본 순간'은 다르다는 감각, 그리고 그 간극을 실제로 계측해보는 태도는 모든 UI 개발자에게 필요해요. 막연히 "느린 것 같다"가 아니라 ms 단위로 재보면, 의외로 범인은 내 코드가 아니라 프레임 경계에 있는 경우가 많답니다.

마무리

핵심은 이거예요. 화면에 뭔가 띄우는 건 즉시가 아니라 '다음 프레임을 기다리는 일'이고, 그 지연을 측정하면 체감 성능의 진짜 병목이 보인다. 여러분은 화면 전환이 느리다고 느껴질 때, 실제로 ms 단위로 시간을 재본 적이 있으세요? 어떤 도구로 UI 지연을 측정하시는지 궁금하네요.