리눅스 데스크톱 지연시간(latency) 측정과 컴포지터 튜닝: 마우스가 '착' 붙는 느낌의 비밀

0.01초의 세계, 왜 신경 써야 할까

게임을 하거나 그림을 그리거나 코드를 빠르게 스크롤할 때, "화면이 손을 따라온다"는 느낌이 들 때가 있고 "미세하게 늦는다"는 느낌이 들 때가 있어요. 이 차이를 만드는 게 바로 지연시간(latency), 즉 내가 입력을 한 순간부터 그 결과가 화면에 그려지기까지 걸리는 시간이에요.

이번 글은 리눅스 데스크톱에서 이 지연시간을 직접 측정하고, 화면을 합성하는 소프트웨어인 컴포지터(compositor)를 튜닝해서 줄여나가는 과정을 다뤄요. 막연히 "좀 빠른 것 같다"가 아니라, 숫자로 재고 근거를 가지고 개선한다는 점이 핵심이에요.

컴포지터가 뭐길래 지연이 생길까

먼저 컴포지터부터 짚어볼게요. 이게 뭐냐면, 여러 프로그램 창들을 받아서 하나의 최종 화면으로 합쳐주는 '편집장' 같은 존재예요. 브라우저 창, 터미널 창, 배경화면을 각각 그려놓으면, 컴포지터가 이걸 겹쳐서 모니터에 보낼 한 장의 그림으로 만들어요. 리눅스에선 X11 시절의 컴포지터부터 요즘의 Wayland 컴포지터(Sway, KWin, Hyprland 등)까지 다양하죠.

문제는 이 합성 과정과 화면 갱신 타이밍이 어긋나면 불필요한 대기가 생긴다는 거예요. 대표적인 게 VSync예요. 화면 찢어짐(tearing)을 막으려고 모니터의 새로고침 주기에 맞춰 그림을 내보내는 기능인데, 타이밍이 안 맞으면 "이미 다 그렸는데 모니터가 받아갈 때까지 한 프레임을 통째로 기다리는" 일이 벌어져요. 60Hz 모니터면 한 프레임이 약 16.7밀리초니까, 이게 쌓이면 체감되는 지연이 돼요.

어떻게 측정하나

측정이 핵심인데요, 감으로는 0.01초 차이를 알 수 없으니까 도구를 써요. 흔한 방법 몇 가지를 소개하면:

• 고속 카메라 측정: 마우스를 움직이거나 키를 누르는 순간과 화면이 반응하는 순간을 슬로우모션으로 찍어, 몇 프레임 차이가 나는지 세는 방식이에요. 가장 솔직하지만 번거롭죠.
• 타임스탬프 추적: 입력 이벤트가 커널에 들어온 시각과, 그 결과가 화면 버퍼에 올라간 시각을 코드로 찍어서 차이를 계산해요. Wayland의 presentation-time 프로토콜처럼 "이 프레임이 실제로 화면에 표시된 정확한 시각"을 알려주는 기능을 활용하면 꽤 정밀하게 잴 수 있어요.
• 프레임 페이싱 분석: 프레임이 일정한 간격으로 나오는지(jitter가 없는지)를 보는 거예요. 평균 지연이 낮아도 들쭉날쭉하면 체감은 더 나빠지거든요.

어떤 튜닝을 하나

대표적인 레버들을 보면, 우선 버퍼링 단계를 줄이는 것이에요. 트리플 버퍼링처럼 그림을 여러 장 미리 쌓아두면 부드럽긴 한데 지연이 늘어요. 반대로 버퍼를 줄이면 반응은 빨라지지만 끊김 위험이 커지니 트레이드오프죠. 또 직접 스캔아웃(direct scanout)이라는 게 있는데, 전체 화면 앱일 때 컴포지터의 합성 단계를 건너뛰고 앱이 그린 화면을 곧장 모니터로 보내는 최적화예요. 합성 한 단계를 통째로 생략하니 지연이 확 줄어요. 여기에 모니터 주사율을 동적으로 맞추는 가변 주사율(VRR, FreeSync/G-Sync)까지 더하면 VSync 대기를 더 줄일 수 있고요.

업계 맥락

사실 "입력에서 화면까지"를 줄이는 싸움은 모든 플랫폼의 공통 과제예요. 윈도우엔 NVIDIA Reflex 같은 솔루션이 있고, 게임 콘솔도 모드별로 지연을 광고하죠. 리눅스 진영에선 Wayland로 넘어오면서 presentation-time, direct scanout, tearing 제어 프로토콜 등 "지연을 측정 가능하고 조절 가능하게" 만드는 표준들이 정비돼 왔어요. 예전엔 "리눅스 데스크톱은 게임/창작용으론 좀…" 하던 평가가 있었는데, 이런 작업들이 그 인식을 바꾸고 있는 흐름이에요.

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

게임 클라이언트, 그래픽 툴, 실시간 협업 캔버스 같은 걸 만든다면 "내 앱의 입력 지연을 숫자로 재는 습관"이 정말 중요해요. 사용자는 "왠지 굼뜨다"고만 말하지 원인을 짚어주지 않거든요. 측정 파이프라인을 갖춰두면 막연한 불만을 구체적 개선으로 바꿀 수 있어요. 또 Wayland의 presentation-time 같은 API를 알아두면, 모바일·임베디드 그래픽 최적화에서도 비슷한 사고방식을 그대로 적용할 수 있고요.

마무리

한 줄 정리하면, "체감은 감이 아니라 측정이고, 측정한 만큼만 개선할 수 있다"예요. 마우스가 손에 '착' 붙는 그 쾌감 뒤엔 밀리초 단위의 집요한 측정과 튜닝이 있는 거죠.

여러분은 본인이 쓰는 환경의 입력 지연을 한 번이라도 측정해본 적 있나요? 부드러움(끊김 없음)과 반응성(낮은 지연) 사이에서 여러분은 어느 쪽을 더 중요하게 생각하세요?